Sensitive Data Protection을 사용하여 대규모 데이터 세트에서 PII 익명화 및 재식별

Last reviewed 2022-08-11 UTC

이 문서에서는 민감한 정보 보호를 사용하여 자동 데이터 변환 파이프라인을 만들어 개인 식별 정보(PII)와 같은 민감한 정보를 익명화하는 방법을 설명합니다. 토큰화(가명처리)와 같은 익명화 기술을 사용하면 데이터를 조인 또는 분석에 활용하면서 민감한 원시 식별자를 난독화하여 데이터 처리 위험을 줄일 수 있습니다. 자동 데이터 변환 파이프라인을 사용하여 익명화된 복제본을 만들면 대량의 민감한 정보 처리 시의 위험을 최소화할 수 있습니다. 민감한 정보 보호에서는 수정, 마스킹, 토큰화, 버케팅, 기타 익명화 방법과 같은 변환을 사용 설정합니다. 데이터 세트가 특성화되지 않은 경우 민감한 정보 보호는 100개가 넘는 기본 제공 분류 기준을 사용하여 데이터에 민감한 정보가 있는지 검사할 수도 있습니다.

이 문서는 데이터 보안, 데이터 처리, 데이터 분석 등을 담당하는 기술 관련 사용자를 대상으로 합니다. 이 가이드에서는 독자가 전문가 수준은 아니어도 데이터 처리 및 데이터 개인 정보 보호에 대해 잘 알고 있다고 가정합니다.

참조 아키텍처

다음 다이어그램은 Google Cloud 제품의 익명화 기술을 사용하여 민감한 데이터 세트의 보안을 강화하는 참조 아키텍처를 보여줍니다.

익명화 파이프라인, 구성 관리, 재식별 파이프라인의 아키텍처

이 아키텍처는 다음과 같이 구성됩니다.

  • 데이터 익명화 스트리밍 파이프라인: Dataflow를 사용하여 텍스트에서 민감한 정보를 익명화합니다. 파이프라인을 여러 변환 및 사용 사례에 재사용할 수 있습니다.

  • 구성(민감한 정보 보호 템플릿 및 키) 관리: 보안 관리자와 같은 소규모 그룹만 액세스할 수 있는 관리형 익명화 구성으로, 익명화 방법 및 암호화 키가 노출되지 않도록 합니다.

  • 데이터 유효성 검사 및 재식별 파이프라인: 익명화된 데이터 복사본의 유효성을 검사하고 Dataflow 파이프라인을 사용하여 대규모로 데이터를 재식별합니다.

민감한 정보 보호 지원

기업의 주요 업무 중 하나는 사용자 및 직원 데이터의 보안을 보장하는 것입니다. Google Cloud는 저장된 데이터와 전송 중 데이터의 암호화를 비롯해 데이터 보안을 강화하는 보안 대책을 기본 제공합니다.

저장 데이터 암호화: Cloud Storage

대부분의 조직에서 데이터 보안을 유지하는 것이 중요합니다. 다소 민감한 정보라도 무단 액세스된다면 고객과의 신뢰, 관계, 평판이 훼손될 수 있습니다. Google에서는 기본적으로 저장 데이터를 암호화합니다. 기본적으로 Cloud Storage 버킷에 업로드되는 객체는 모두 Google 관리 암호화 키를 통해 암호화됩니다. 데이터 세트가 기존 암호화 방법을 사용하고 업로드 전에 기본 옵션이 아닌 옵션을 필요로 하는 경우 Cloud Storage에서 제공하는 다른 암호화 옵션이 있습니다. 자세한 내용은 데이터 암호화 옵션을 참조하세요.

전송 중인 데이터 암호화: Dataflow

데이터가 전송 중일 때는 저장 데이터 암호화가 작동하지 않습니다. 전송 중인 데이터는 전송 중인 데이터 암호화라는 보안 네트워크 프로토콜로 보호됩니다. 기본적으로 Dataflow는 Google 관리 암호화 키를 사용합니다. 이 문서와 연결된 가이드에서는 기본 Google 관리 암호화 키를 사용하는 자동 파이프라인을 사용합니다.

민감한 정보 보호 데이터 변환

민감한 정보 보호에서 수행하는 변환에는 크게 두 가지 유형이 있습니다.

recordTransformations 메서드와 infoTypeTransformations 메서드 모두 데이터의 민감한 정보를 익명화 및 암호화할 수 있습니다. 예를 들어 US_SOCIAL_SECURITY_NUMBER 열 값을 식별할 수 없게 변환하거나 토큰화를 사용하여 모호하게 만들어 참조 무결성을 유지할 수 있습니다.

infoTypeTransformations 메서드를 사용 설정하면 민감한 정보를 검사하고 발견된 결과를 변환할 수 있습니다. 예를 들어 구조화되지 않은 텍스트 또는 자유 텍스트 데이터가 있는 경우 infoTypeTransformations 메서드를 사용하면 문장 내에서 SSN을 식별하고 SSN 값을 암호화하면서 나머지 텍스트를 그대로 유지할 수 있습니다. 커스텀 infoTypes 메서드도 정의할 수 있습니다.

recordTransformations 메서드를 사용 설정하면 구조화된 데이터 또는 테이블 형식 데이터를 사용할 때 필드별로 변환 구성을 적용할 수 있습니다. recordTransformations 메서드를 사용하면 SSN 열을 필드 또는 헤더 이름으로 하여 열의 각 값을 해싱 또는 토큰화하는 등 동일한 변환을 해당 필드의 각 값에 적용할 수 있습니다.

recordTransformations 메서드와 함께 지정된 필드의 값에만 적용되는 infoTypeTransformations 메서드를 사용할 수도 있습니다. 예를 들어 comments 필드에 recordTransformations 메서드 내 infoTypeTransformations 메서드를 사용하여 필드의 텍스트에서 발견된 모든 US_SOCIAL_SECURITY_NUMBER를 수정할 수 있습니다.

익명화 프로세스는 다음과 같습니다(복잡성 순).

  • 수정: 콘텐츠를 대체하지 않고 민감한 콘텐츠를 삭제합니다.
  • 마스킹: 민감한 콘텐츠를 고정 문자로 바꿉니다.
  • 암호화: 민감한 콘텐츠를 암호화된 문자열로 (가능하면 역으로) 바꿉니다.

구분 데이터 작업

데이터는 종종 CSV 파일처럼 각 열에서 선택한 문자로 구분된 고정 유형의 레코드로 구성됩니다. 이 데이터 클래스의 경우 데이터를 검사하지 않고 익명화 변환(recordTransformations)을 적용할 수 있습니다. 예를 들어 SSN이라는 열에는 SSN 데이터만 포함될 수 있습니다. infoType 탐지기가 US_SOCIAL_SECURITY_NUMBER인지 알아보기 위해 데이터를 검사할 필요가 없습니다. 그러나 Additional Details라는 자유 형식 열은 민감한 정보를 포함할 수 있지만 infoType 클래스를 미리 알 수 없습니다. 자유 형식 열의 경우 익명화 변환을 적용하기 전에 먼저 infoTypes 탐지기(infoTypeTransformations)를 검사해야 합니다. 민감한 정보 보호에서는 이러한 변환 유형 모두 단일 익명화 템플릿에 공존할 수 있습니다. 민감한 정보 보호에는 infoTypes 탐지기가 100개 넘게 기본 제공됩니다. 커스텀 유형을 만들거나 기본 제공 infoTypes 탐지기를 수정하여 조직 고유의 민감한 정보를 찾을 수도 있습니다.

변환 유형 확인

recordTransformations 또는 infoTypeTransformations 메서드 사용 여부는 사용 사례에 따라 다릅니다. infoTypeTransformations 메서드를 사용하려면 더 많은 리소스가 필요하고 이로 인해 비용이 많이 발생하므로 데이터 유형을 알 수 없는 상황에서만 이 메서드를 사용하는 것이 좋습니다. Google Cloud 가격 계산기를 사용하여 민감한 정보 보호 실행 비용을 알아볼 수 있습니다.

변환 예시를 위해 이 문서에서는 다음 표에 표시된 것처럼 고정된 열이 있는 CSV 파일이 포함된 데이터 세트를 참조합니다.

열 이름 검사 infoType(커스텀 또는 기본 제공) 민감한 정보 보호 변환 유형
Card Number 해당 없음 확정적 암호화(DE)
Card Holder's Name 해당 없음 확정적 암호화(DE)
Card PIN 해당 없음 암호화 해싱
SSN (Social Security Number) 해당 없음 마스킹
Age 해당 없음 버케팅
Job Title 해당 없음 버케팅
Additional Details 기본 제공:
IBAN_CODE, EMAIL_ADDRESS, PHONE_NUMBER
커스텀:
ONLINE_USER_ID
대체

이 표에서는 열 이름을 나열하고 각 열에 필요한 변환 유형을 설명합니다. 예를 들어 Card Number 열에는 암호화해야 하는 신용카드 번호가 있지만 데이터 유형(infoType)이 알려져 있으므로 이 번호를 검사할 필요가 없습니다.

검사 변환이 권장되는 유일한 열은 Additional Details 열입니다. 이 열은 자유 형식이며 PII를 포함할 수 있으므로 이 예시에서는 감지 및 익명화가 필요합니다.

이 표의 예시는 서로 다른 익명화 변환 5개를 나타냅니다.

  • 양방향 토큰화: 원본 데이터를 참조 무결성을 유지하면서 확정적인 토큰으로 바꿉니다. 토큰을 사용하면 데이터를 조인하거나 집계 분석에서 토큰을 사용할 수 있습니다. 토큰을 만들 때 사용한 키와 동일한 키를 사용하여 데이터를 원래 상태로 되돌리거나 토큰을 해제할 수 있습니다. 다음 두 가지 방법으로 양방향 토큰화를 수행할 수 있습니다.

    • 확정적 암호화(DE): 원본 데이터를 base64로 인코딩된 암호화된 값으로 바꾸고 원래 문자 집합이나 길이를 보존하지 않습니다.
    • FFX를 사용한 형식 보존 암호화(FPE-FFX): 원본 데이터를 FFX 모드에서 형식 보존 암호화를 통해 생성된 토큰으로 바꿉니다. 설계상 FPE-FFX는 입력 텍스트의 길이와 문자 집합을 보존합니다. 인증 및 초기화 벡터가 없으므로 출력 토큰에서 길이가 확장될 수 있습니다. 기존 데이터 시스템과의 호환성과 같이 길이와 문자 집합 보존이 엄격하게 요구되는 경우를 제외하고는 DE와 같은 다른 방법이 더 강력한 보안을 제공하며 토큰화 사용 사례에 권장됩니다.
  • 암호화 해싱을 사용한 단방향 토큰화: 참조 무결성을 유지하면서 원래 값을 해시 값으로 바꿉니다. 단, 양방향 토큰화와 달리 단방향 방법은 되돌릴 수 없습니다. 입력 값에 SHA-256 기반 메시지 인증 코드(HMAC-SHA-256)를 사용하면 해시 값이 생성됩니다.

  • 마스킹: 원본 데이터 일부 또는 전체를 지정된 문자로 바꿉니다.

  • 버케팅: 보다 식별 가능한 값을 덜 특징적인 값으로 바꿉니다.

  • 대체: 감지된 경우 원래 데이터를 토큰 또는 infoType의 이름으로 바꿉니다.

방법 선택

가장 좋은 익명화 방법은 사용 사례에 따라 달라질 수 있습니다. 예를 들어 기존 앱이 익명화된 레코드를 처리하는 경우 형식 보존이 중요할 수 있습니다. 엄격하게 형식이 지정된 10자리 숫자를 처리할 경우 FPE는 기존 시스템을 지원할 수 있도록 입력의 길이(10자리)와 문자 집합(숫자)을 유지합니다.

단, Card Holder's Name 열의 값처럼 기존과의 호환성에 엄격한 형식이 요구되지 않으면 더 강력한 인증 방법인 DE를 선택하는 것이 좋습니다. FPE와 DE 모두 토큰을 되돌리거나 해제할 수 있습니다. 토큰 해제가 필요하지 않은 경우 암호화 해싱은 무결성을 제공하지만 토큰을 되돌릴 수 없습니다.

마스킹, 버케팅, 날짜 이동, 대체 등 다른 방법은 완전한 무결성을 유지할 필요가 없는 값에 적합합니다. 예를 들어 연령 값(예: 27)을 연령 범위(20~30)로 버케팅하더라도 여전히 분석은 가능하지만 개인 식별로 이어질 수 있는 고유성은 줄어듭니다.

토큰 암호화 키

암호화 익명화 변환에는 토큰 암호화 키라고도 하는 암호화 키가 필요합니다. 익명화 암호화에 사용되는 토큰 암호화 키는 원래 값을 다시 식별하는 데에도 사용됩니다. 토큰 암호화 키의 안전한 생성 및 관리는 이 문서의 범위를 벗어납니다. 하지만 나중에 관련 가이드에서 사용되는 몇 가지 중요한 원칙이 있습니다.

  • 템플릿에서 일반 텍스트 키를 사용하지 않고 대신 Cloud KMS를 사용하여 래핑된 키를 만듭니다.
  • 키 훼손 위험을 줄이기 위해 각 데이터 요소에 별도의 토큰 암호화 키를 사용합니다.
  • 토큰 암호화 키를 순환합니다. 랩핑된 키를 순환할 수 있지만 토큰 암호화 키를 순환하면 토큰화 무결성이 훼손됩니다. 키가 순환되면 전체 데이터 세트를 다시 토큰화해야 합니다.

민감한 정보 보호 템플릿

대규모로 배포할 경우 민감한 정보 보호 템플릿을 사용하여 다음을 수행합니다.

  • Identity and Access Management(IAM)로 보안 제어를 사용 설정합니다.
  • 요청 구현으로부터 구성 정보와 이 정보를 익명화하는 방법을 분리합니다.
  • 일련의 변환을 재사용합니다. 익명화 및 재식별 템플릿을 여러 데이터 세트에서 사용할 수 있습니다.

BigQuery

참조 아키텍처의 마지막 구성요소는 BigQuery에서 익명화 데이터를 보고 작업하는 것입니다. BigQuery는 서버리스 인프라, BigQuery ML, 민감한 정보 보호를 기본 도구로 실행할 수 있는 기능이 포함된 Google의 데이터 웨어하우스 도구입니다. 다음 참조 아키텍처 예시에서 BigQuery는 익명화 데이터의 데이터 웨어하우스 역할과 Pub/Sub를 통해 데이터를 공유할 수 있는 자동화된 재식별 데이터 파이프라인의 백엔드 역할을 합니다.

다음 단계