알려진 문제

이 페이지에서는 Sensitive Data Protection의 알려진 문제와 다음 문제를 방지하거나 복구하는 방법을 설명합니다.

일반적인 문제

BigQuery에 결과 저장

작업 또는 검색 스캔이 결과를 BigQuery에 저장하면 로그에 Already exists 오류가 표시됩니다. 이 오류는 문제가 있음을 나타내지 않으며 결과는 예상대로 저장됩니다.

BigQuery 스캔

이 섹션에서는 BigQuery 데이터를 검사 또는 프로파일링할 때 발생할 수 있는 문제에 대해 설명합니다.

검사 및 프로파일링 작업의 일반적인 문제

다음 문제는 BigQuery 검사 및 프로파일링 작업에 모두 적용될 수 있습니다.

행 수준 보안이 설정된 행을 스캔할 수 없음

행 수준 보안 정책은 Sensitive Data Protection에서 보호된 BigQuery 테이블을 검사하고 프로파일링할 수 없게 할 수 있습니다. BigQuery 테이블에 행 수준 보안 정책을 적용한 경우 TRUE 필터를 설정하고 부여자 목록에 서비스 에이전트를 포함하는 것이 좋습니다.

중복 행

BigQuery 테이블에 데이터를 기록할 때 Sensitive Data Protection이 중복 행을 기록할 수 있습니다.

최근에 스트리밍된 데이터

Sensitive Data Protection은 최근에 스트리밍된 데이터(이전에는 스트리밍 버퍼라고 함)를 스캔하지 않습니다. 자세한 내용은 BigQuery 문서에서 스트리밍 데이터 가용성을 참조하세요.

BigQuery 검사 문제

다음 문제는 BigQuery 데이터의 검사 작업에만 적용됩니다. 데이터 프로필에는 영향을 주지 않습니다.

내보낸 발견 항목에 row_number 필드 값 없음

BigQuery에 발견 항목을 저장하도록 Sensitive Data Protection을 구성하면 입력 테이블을 스캔할 때 생성된 BigQuery 테이블에서 location.content_locations.record_location.record_key.big_query_key.row_number 필드가 추론됩니다. 이 값은 확정적이지 않으며 쿼리할 수 없으며 검사 작업에서 null일 수 있습니다.

결과가 존재하는 특정 행을 식별해야 하는 경우 작업 생성시 inspectJob.storageConfig.bigQueryOptions.identifyingFields를 지정합니다.

식별 필드는 location.content_locations.record_location.record_key.id_values 필드의 생성된 BigQuery 테이블에서 확인할 수 있습니다.

새 BigQuery 콘텐츠로 스캔 제한

새 콘텐츠만 스캔하도록 제한하고 BigQuery Storage Write API를 사용하여 입력 테이블을 작성하는 경우 Sensitive Data Protection이 일부 행의 스캔을 건너뛸 수 있습니다.

이 문제를 해결하려면 검사 작업에서 TimespanConfig 객체의 timestampField가 BigQuery에서 자동 생성되는 커밋 타임스탬프인지 확인합니다. 그러나 Sensitive Data Protection이 최근 스트리밍된 데이터에서 읽기를 수행하지 않으므로 행을 건너뛰지 않는다고 보장하지 않습니다.

열의 커밋열에 대해 커밋 타임스탬프를 자동 생성하고 기존 스트리밍 API를 사용하여 입력 테이블을 작성하려면 다음을 수행합니다.

  1. 입력 테이블의 스키마에서 타임스탬프 열이 TIMESTAMP 유형인지 확인합니다.

    스키마 예시

    다음 예시에서는 commit_time_stamp 필드를 정의하고 유형을 TIMESTAMP로 설정합니다.

    ...
{
 "name": "commit_time_stamp",
 "type": "TIMESTAMP"
}
...

  2. tabledata.insertAll 메서드의 rows[].json 필드에서 타임스탬프 열의 값이 AUTO로 설정되었는지 확인합니다.

    JSON 예시

    다음 예시에서는 commit_time_stamp 필드 값을 AUTO로 설정합니다.

    {
  ...
  "commit_time_stamp": "AUTO",
  ...
}

최대 비율 또는 행을 설정하여 스캔 제한

총 테이블 행 수(rowsLimitPercent)의 비율을 기반으로 샘플링 한도를 설정하면 Sensitive Data Protection이 예상보다 많은 행을 검사할 수 있습니다. 스캔할 행 수를 엄격하게 제한해야 하는 경우에는 대신 최대 행 수(rowsLimit)를 설정하는 것이 좋습니다.

BigQuery 프로파일링 문제

다음 문제는 BigQuery 데이터의 프로파일링 작업에만 적용됩니다. 자세한 내용은 BigQuery 데이터의 데이터 프로필을 참조하세요.

테이블이 5억 개를 초과하는 조직 또는 프로젝트

테이블이 5억 개를 초과하는 조직이나 프로젝트를 프로파일링하려고 하면 Sensitive Data Protection에서는 오류를 반환합니다. 이 오류가 발생하면 오류 메시지의 안내를 따르세요.

조직의 테이블 수가 5억 개 이상이고 테이블 수가 더 적은 프로젝트가 있으면 프로젝트 수준 스캔을 대신 시도하세요.

테이블 및 열 제한에 대한 자세한 내용은 데이터 프로파일링 한도를 참조하세요.

검사 템플릿

검사 템플릿은 프로파일링할 데이터와 동일한 리전에 있어야 합니다. 여러 리전에 데이터가 있는 경우 데이터가 있는 리전마다 하나씩 여러 검사 템플릿을 사용합니다. global 리전에 저장된 검사 템플릿을 사용할 수도 있습니다. global 리전에 템플릿을 포함하면 Sensitive Data Protection은 리전별 템플릿이 없는 모든 데이터에 이 템플릿을 사용합니다. 자세한 내용은 데이터 상주 고려사항을 참조하세요.

저장된 infoType

검사 템플릿에서 참조되는 저장된 infoType(저장된 커스텀 사전 감지기라고도 함)은 다음 중 하나에 저장해야 합니다.

  • global 리전
  • 검사 템플릿과 동일한 리전입니다.

그렇지 않으면 프로파일링 작업이 Resource not found 오류와 함께 실패합니다.

리소스 공개 상태

테이블 데이터 프로필에서 BigQuery 테이블에 지정된 리소스 공개 상태 분류는 테이블의 공개 상태가 아닌 테이블을 포함하는 데이터 세트의 공개 상태에 따라 달라집니다. 따라서 테이블의 IAM 권한이 데이터 세트의 IAM 권한과 다른 경우 데이터 프로필에 표시된 테이블의 리소스 공개 상태가 잘못될 수 있습니다. 이 문제는 BigQuery 검색 및 Vertex AI 검색에 영향을 미칩니다.

Google Cloud 콘솔에서 리소스 공개 상태는 테이블 데이터 프로필의 공개 필드에 표시됩니다. Cloud Data Loss Prevention API에서 리소스 공개 상태는 TableDataProfile의 resourceVisibility 필드에 표시됩니다.

Cloud Storage 스캔

이 섹션에서는 데이터를 검사 또는 익명화할 때 발생할 수 있는 문제에 대해 설명합니다.

대형 커스텀 사전 감지기로 XLSX 파일 검사

대형 커스텀 사전 감지기(저장된 커스텀 사전 감지기라고도 함)를 사용하여 Microsoft Excel .xlsx 파일을 검사하면 검사 작업이 느리게 실행되고 중단된 것처럼 보이며 대량의 Cloud Storage B 클래스 작업이 발생할 수 있습니다. 이는 Sensitive Data Protection이 .xlsx 파일의 각 셀에서 대형 커스텀 사전의 소스 용어 목록을 한 번 읽을 수 있기 때문입니다. 읽기 작업 볼륨으로 인해 Sensitive Data Protection 검사 작업이 거의 진행되지 않은 것으로 표시되고 중단된 것처럼 보일 수 있습니다.

관련 Cloud Storage 청구 요금에 대한 자세한 내용은 작업 요금의 B 클래스 작업 요금을 참조하세요.

바이너리 모드에서 스캔 중인 구조화된 파일

경우에 따라 일반적으로 구조화된 파싱 모드로 스캔되는 파일이 구조화된 파싱 모드의 개선사항을 포함하지 않는 바이너리 모드로 스캔될 수 있습니다. 자세한 내용은 구조화된 파싱 모드에서 구조화된 파일 스캔을 참고하세요.

구분된 파일 익명화

검사 작업으로 구분된 파일 (예: CSV 파일)을 익명화하면 일부 행에 출력에 빈 셀이 추가될 수 있습니다. 이러한 추가 셀을 방지하는 해결 방법은 대신 content.deidentify 메서드를 사용하여 데이터의 식별 정보를 삭제하는 것입니다.

Cloud SQL용 탐색

Security Command Center 중복 발견 항목

Cloud SQL 데이터 프로파일링은 Security Command Center에 발견 항목 게시를 지원합니다.

2024년 4월 25일 이전에는 버그로 인해 Sensitive Data Protection이 Security Command Center에서 Cloud SQL 인스턴스에 대한 중복 발견 항목을 생성하는 경우가 있었습니다. 이러한 발견 항목은 고유한 발견 항목 ID로 생성되었지만 동일한 Cloud SQL 인스턴스와 관련이 있습니다. 문제가 해결되었지만 중복된 발견 항목이 여전히 존재합니다. 중복 항목을 숨기기하여 Security Command Center 발견 항목 페이지에서 숨길 수 있습니다.

Amazon S3용 검색

Sensitive Data Protection이 Security Command Center로 전송하는 Amazon S3 관련 발견 항목에는 영향을 받는 리소스의 AWS 계정 ID 또는 표시 이름에 관한 정보가 없을 수 있습니다. 이는 일반적으로 다음과 같은 경우에 발생합니다.

  • 발견 항목이 Security Command Center로 전송될 때 AWS 커넥터는 약 24시간 동안만 유효했습니다.
  • 발견 항목이 Security Command Center로 전송될 때까지 AWS 계정이 AWS 커넥터에 포함된 지 약 24시간이 지났습니다.

이 문제를 해결하려면 약 24시간 후에 데이터 프로필을 삭제하거나 프로파일링 일정을 설정하여 데이터 프로필을 다시 생성합니다. 전체 발견 항목 세부정보가 Security Command Center로 전송됩니다.

지능형 문서 파싱

이 섹션에는 문서 파싱과 관련된 알려진 문제가 포함되어 있습니다.

DocumentLocation 객체가 채워지지 않음

location.content_locations.document_location.file_offset 필드는 지능형 문서 파싱 스캔 모드의 경우 채워지지 않습니다.

감지

유니코드 표준의 보조 다중 언어 영역에 있는 문자가 포함된 사전 단어는 예상치 않은 발견 항목을 발생시킬 수 있습니다. 이러한 문자의 예시에는 그림 이모티콘, 과학 기호, 고대 문자가 있습니다.