가명처리는 민감한 정보 값을 암호화 방식으로 생성된 토큰으로 대체하는 익명화 기법입니다. 가명처리는 금융 및 의료와 같은 산업에서 널리 사용되고 있으며 데이터 사용 위험을 줄이고, 규정 준수 범위를 좁히고, 데이터 유틸리티와 정확성을 유지하면서 시스템에 민감한 정보의 노출을 최소화하는 데 유용합니다.
민감한 정보 보호는 익명화의 세 가지 가명처리 기술을 지원하며 세 가지 암호화 변환 방법 중 하나를 원래 민감한 정보 값에 적용하여 토큰을 생성합니다. 그런 다음 각 원래 민감한 값이 해당 토큰으로 대체됩니다. 가명처리를 토큰화 또는 서로게이트 대체라고도 합니다.
가명처리 기술은 단방향 또는 양방향 토큰을 사용 설정합니다. 단방향 토큰은 변환되면 되돌릴 수 없지만 양방향 토큰은 되돌릴 수 있습니다. 토큰은 대칭형 암호화를 통해 생성되므로 새 토큰을 생성할 수 있는 동일한 암호화 키가 토큰을 되돌릴 수도 있습니다. 되돌릴 필요가 없는 상황에서는 보안 해싱 메커니즘을 사용하는 단방향 토큰을 사용할 수 있습니다.
가명처리가 민감한 데이터를 보호하는 동시에 비즈니스 운영과 분석 워크플로가 필요한 데이터에 쉽게 액세스하고 사용할 수 있는 방식을 이해하는 데 유용합니다. 이 주제에서는 가명처리의 개념과 민감한 정보 보호에서 지원하는 데이터를 변환하는 세 가지 암호화 방법을 설명합니다.
이러한 가명처리 방법을 구현하는 방법과 민감한 정보 보호 사용 예시를 더 보려면 민감한 정보 익명화를 참조하세요.
민감한 정보 보호에서 지원되는 암호화 방법
민감한 정보 보호는 세 가지 가명처리 기술을 지원하며 이 기술 모두 암호화 키를 사용합니다. 사용 가능한 방법은 다음과 같습니다.
- AES-SIV를 사용한 확정적 암호화: 입력 값이 암호화 키와 함께 AES-SIV 암호화 알고리즘을 사용하여 암호화되고 base64를 사용하여 인코딩된 값으로 바뀝니다. 그런 다음 지정된 경우 서로게이트 주석이 추가됩니다. 이 방법은 해시된 값을 생성하므로 문자 집합이나 입력 값의 길이를 보존하지 않습니다. 암호화되고 해시된 값은 원본 암호화 키와 서로게이트 주석을 포함한 전체 출력 값을 통해 재식별될 수 있습니다. AES-SIV 암호화를 사용하여 토큰화되는 값 형식을 자세히 알아보세요.
- 형식 보존 암호화: 입력 값은 암호화 키와 함께 FPE-FFX 암호화 알고리즘을 사용하여 암호화된 값으로 대체된 후 지정된 경우 서로게이트 주석이 추가됩니다. 설계 시 문자 집합과 입력 값 길이 모두 출력 값에서 보존됩니다. 암호화된 값은 원본 암호화 키와 서로게이트 주석을 포함한 전체 출력 값을 통해 재식별될 수 있습니다. 이 암호화 방법 사용에 대한 중요한 고려사항은 이 주제 뒷부분의 형식 보존 암호화를 참조하세요.
- 암호화 해싱: 입력 값은 암호화 키와 함께 입력 값에 해시 기반 메시지 인증 코드(HMAC)-보안 해시 알고리즘(SHA)-256을 통해 암호화된 값으로 대체됩니다. 해시된 변환 출력 길이는 항상 동일하며 재식별될 수 없습니다. 암호화 해싱을 사용하여 토큰화된 값의 형식을 자세히 알아보세요.
다음 표에는 이러한 가명처리 방법은 요약되어 있습니다. 표 다음에는 테이블 행이 설명되어 있습니다.
| AES-SIV를 사용한 확정적 암호화 | 형식 보존 암호화 | 암호화 해싱 | |
|---|---|---|---|
| 암호화 유형 | AES-SIV | FPE-FFX | HMAC-SHA-256 |
| 지원되는 입력 값 | 최소 1자 이상이며 문자 집합 제한이 없습니다. | 최소 2자 이상이고 ASCII로 인코딩되어야 합니다. | 문자열 또는 정수 값이어야 합니다. |
| 서로게이트 주석 | 선택사항 | 선택사항 | 해당 없음 |
| 컨텍스트 조정 | 선택사항 | 선택사항 | 해당 없음 |
| 문자 집합과 길이 보존 | ✗ | ✓ | ✗ |
| 회수 | ✓ | ✓ | ✗ |
| 참조 무결성 | ✓ | ✓ | ✓ |
- 암호화 유형: 익명화 변환에 사용되는 암호화 종류입니다.
- 지원되는 입력 값: 입력 값의 최소 요구사항입니다.
- 서로게이트 주석: 사용자에게 컨텍스트를 제공하고 익명화된 값을 재식별하는 데 사용할 민감한 정보 보호에 정보를 제공하도록 암호화된 값을 추가한 사용자별 주석입니다. 구조화되지 않은 데이터를 재식별하는 데 서로게이트 주석이 필요합니다.
RecordTransformation을 사용하여 구조화되거나 테이블 형식의 데이터 열을 변환하는 경우의 선택사항입니다. - 컨텍스트 조정: 동일한 입력 값을 다른 출력 값으로 익명화할 수 있도록 입력 값을 '조정'하는 데이터 필드에 대한 참조입니다. 컨텍스트 조정은
RecordTransformation을 사용하여 구조화되거나 테이블 형식의 데이터 열을 변환하는 경우의 선택사항입니다. 자세한 내용은 컨텍스트 조정 사용을 참조하세요. - 문자 집합과 길이 보존: 익명화된 값이 원본 값과 동일한 문자 집합으로 구성되었는지 여부와 익명화된 값의 길이가 원래 값의 길이와 일치하는지 여부입니다.
- 회수: 암호화 키, 서로게이트 주석, 컨텍스트 조정을 사용하여 재식별할 수 있습니다.
- 참조 무결성: 참조 무결성을 사용하면 데이터가 개별적으로 익명화된 후에도 레코드가 다른 레코드와의 관계를 유지할 수 있습니다. 동일한 암호화 키와 컨텍스트 조정이 적용되면 데이터 테이블은 변환될 때마다 동일한 난독화된 형식으로 바뀌어 값(및 구조화된 데이터를 사용하는 경우 레코드) 간의 연결이 테이블 전체에 보존됩니다.
민감한 정보 보호에서 토큰화 작동 방식
토큰화의 기본 프로세스는 민감한 정보 보호에서 지원하는 세 가지 방법 모두 동일합니다.
1단계: 민감한 정보 보호가 토큰화할 데이터를 선택합니다. 이 작업을 수행하는 가장 일반적인 방법은 기본 제공 또는 커스텀 infoType 감지기를 사용하여 원하는 민감한 정보 값과 일치시키는 것입니다. 구조화된 데이터(예: BigQuery 테이블)를 스캔하는 경우 레코드 변환을 사용하여 전체 데이터 열에서 토큰화를 수행할 수도 있습니다.
infoType 및 레코드 변환이라는 두 가지 변환 카테고리에 대한 자세한 내용은 익명화 변환을 참조하세요.
2단계: 암호화 키를 사용하여 민감한 정보 보호에서 각 입력 값을 암호화합니다. 이 키를 다음 세 가지 방법 중 하나로 제공할 수 있습니다.
- Cloud Key Management Service (Cloud KMS)를 사용하여 래핑. 가장 강력한 보안을 위해 Cloud KMS가 선호하는 방법입니다.
- 민감한 정보 보호가 익명화 시점에 생성한 후 삭제하는 임시 키 사용. 임시 키는 API 요청당 무결성만 유지합니다. 무결성이 필요하거나 이 데이터를 다시 식별하려는 경우에는 이 키 유형을 사용하지 마세요.
- 원시 텍스트 양식을 직접 사용합니다. (권장하지 않음)
자세한 내용은 이 주제 뒷부분에 있는 암호화 키 사용 섹션을 참조하세요.
3단계(AES-SIV만 사용한 암호화 해싱 및 확정적 암호화): 민감한 정보 보호에서 base64를 사용하여 암호화된 값을 인코딩합니다. 암호화 해싱을 사용하면 이 인코딩된 암호화된 값은 토큰이며 프로세스는 6단계로 진행합니다. AES-SIV를 사용하는 확정적 암호화의 경우 인코딩된 암호화된 값은 토큰 구성요소 중 하나인 서로게이트 값입니다. 이 프로세스는 4단계로 진행합니다.
4단계(형식 보존 및 확정적 암호화(AES-SIV만 사용)): 민감한 정보 보호는 암호화된 값에 선택적 서로게이트 주석을 추가합니다. 서로게이트 주석은 개발자가 정의한 설명 문자열에 값을 추가하여 암호화된 서로게이트 값을 식별하는 데 유용합니다. 예를 들어 주석이 없으면 익명화된 전화번호와 익명화된 주민등록번호 또는 기타 식별 번호를 구분할 수 없습니다. 또한 형식 보존 암호화나 확정적 암호화를 사용하여 익명화된 구조화되지 않은 데이터의 값을 재식별하려면 서로게이트 주석을 지정해야 합니다. RecordTransformation을 사용하여 구조화되거나 테이블 형식의 데이터 열을 변환하는 경우에는 서로게이트 주석이 필요 없습니다.
5단계(구조화된 데이터의 AES-SIV만 사용한 형식 보존 및 확정 암호화): 민감한 정보 보호에서 다른 필드의 선택적 컨텍스트를 사용하여 생성된 토큰을 '조정'할 수 있습니다. 이렇게 하면 토큰 범위를 변경할 수 있습니다. 예를 들어 이메일 주소가 포함된 마케팅 캠페인 데이터의 데이터베이스가 있고 캠페인 ID로 '조정된' 동일한 이메일 주소에 고유한 토큰을 생성하려는 경우를 가정해 보겠습니다. 이렇게 하면 다른 사용자가 다른 캠페인에서가 아닌 동일한 캠페인 내 동일한 사용자의 데이터를 조인할 수 있습니다. 토큰을 만드는 데 컨텍스트 조정을 사용하는 경우 익명화 변환을 되돌리려면 이 컨텍스트 조정이 필요합니다. 형식 보존 및 확정적 암호화에서는 AES-SIV 지원 컨텍스트를 사용합니다. 컨텍스트 조정 사용을 자세히 알아보세요.
6단계: 민감한 정보 보호는 원래 값을 익명화된 값으로 바꿉니다.
토큰화된 값 비교
이 섹션에서는 이 주제에서 설명한 세 가지 방법을 모두 사용하여 익명화된 일반적인 토큰의 모습을 보여줍니다. 민감한 정보 값 예시는 북미 전화번호(1-206-555-0123)입니다.
AES-SIV를 사용한 확정적 암호화
확정적 암호화와 AES-SIV를 사용한 익명화를 사용하면 입력 값(및 선택적으로 지정한 컨텍스트 조정)이 암호화 키와 함께 AES-SIV를 통해 암호화되고 base64로 인코딩된 후 지정된 경우 선택적으로 서로게이트 주석이 추가됩니다. 이 방법은 입력 값의 문자 집합(또는 'alphabet')을 보존하지 않습니다. 출력 가능한 출력을 생성하기 위해 결과 값은 base64로 인코딩됩니다.
결과 토큰은 서로게이트 infoType이 지정되었다고 가정합니다.
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
다음 주석이 추가된 다이어그램은 토큰 예시인 1-206-555-0123 값에서 AES-SIV가 있는 확정적 암호화를 사용한 익명화 작업 출력을 보여줍니다. 선택적 서로게이트 infoType은 NAM_PHONE_NUMB로 설정되어 있습니다.
- 서로게이트 주석
- 서로게이트 infoType(사용자가 정의)
- 변환된 값의 문자 길이
- 서로게이트(변환) 값
서로게이트 주석을 지정하지 않으면 결과 토큰은 변환된 값 또는 주석이 추가된 다이어그램의 #4와 동일합니다. 구조화되지 않은 데이터를 다시 식별하려면 서로게이트 주석을 포함하여 이 전체 토큰이 필요합니다. 테이블과 같은 구조화된 데이터를 변환하는 경우 서로게이트 주석은 선택사항입니다. 민감한 정보 보호는 서로게이트 주석 없이 RecordTransformation을 사용하여 전체 열에서 익명화와 재식별을 모두 수행할 수 있습니다.
형식 보존 암호화
형식 보존 암호화를 사용하여 익명화하면 입력 값(및 선택적으로 지정된 컨텍스트 조정)은 암호화 키와 함께 형식 보존 암호화의 FFX 모드('FPE-FFX')를 사용하여 암호화됩니다. 그런 다음 선택적으로 지정된 경우 서로게이트 주석이 추가됩니다.
이 주제에서 설명하는 다른 토큰화 방법과 달리 출력 서로게이트 값 길이는 입력 값과 동일하고 base64를 통해 인코딩되지 않습니다. 암호화된 값으로 구성된 문자 집합(또는 '알파')을 정의합니다. 출력 값에 사용할 민감한 정보 보호의 알파벳을 지정하는 방법에는 세 가지가 있습니다.
- 가장 일반적인 문자 집합/알파벳 4개를 나타내는 열거된 값 4개 중 하나를 사용합니다.
- 알파벳 크기를 지정하는 radix 값을 사용합니다. 최소 radix 값
2를 지정하면0와1로만 구성된 알파벳이 생성됩니다. 최대 radix 값95를 지정하면 모든 숫자 문자, 대문자, 소문자, 기호 문자가 포함된 알파벳이 생성됩니다. - 사용할 문자를 정확히 나열하여 알파벳을 빌드합니다. 예를 들어
1234567890-*을 지정하면 숫자, 하이픈, 별표만으로 구성된 서로게이트 값이 생성됩니다.
다음 표에는 각 열거형 값(FfxCommonNativeAlphabet), radix 값, 세트의 문자 목록 등 일반적인 문자 집합 4개가 나와 있습니다. 마지막 행에는 최대 radix 값에 해당하는 전체 문자 집합이 나열됩니다.
| 알파벳/문자 집합 이름 | Radix | 문자 목록 |
|---|---|---|
NUMERIC |
10 |
0123456789 |
HEXADECIMAL |
16 |
0123456789ABCDEF |
UPPER_CASE_ALPHA_NUMERIC |
36 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ |
ALPHA_NUMERIC |
62 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz |
| - | 95 |
0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz~`!@#$%^&*()_-+={[}]|\:;"'<,>.?/ |
결과 토큰은 서로게이트 infoType이 지정되었다고 가정합니다.
SURROGATE_INFOTYPE(SURROGATE_VALUE_LENGTH):SURROGATE_VALUE
아래 주석이 추가된 다이어그램은 95 ralix를 사용하여 1-206-555-0123 값에 형식 보존 암호화를 사용한 민감한 정보 보호 익명화 작업 출력입니다. 선택적 서로게이트 infoType은 NAM_PHONE_NUMB로 설정되어 있습니다.
- 서로게이트 주석
- 서로게이트 infoType(사용자가 정의)
- 변환된 값의 문자 길이
- 입력 값과 길이가 동일한 서로게이트(변환된) 값
서로게이트 주석을 지정하지 않으면 결과 토큰은 변환된 값 또는 주석이 추가된 다이어그램의 #4와 동일합니다. 구조화되지 않은 데이터를 다시 식별하려면 서로게이트 주석을 포함하여 이 전체 토큰이 필요합니다. 테이블과 같은 구조화된 데이터를 변환하는 경우 서로게이트 주석은 선택사항입니다. 민감한 정보 보호는 서로게이트 없이 RecordTransformation을 사용하여 전체 열에서 익명화와 재식별을 모두 수행할 수 있습니다.
암호화 해싱
암호화 해싱을 사용하는 익명화의 경우 입력 값은 암호화 키와 함께 HMAC-SHA-256을 사용하여 해시된 후 base64로 인코딩됩니다. 익명화된 값의 길이는 키 크기에 따라 항상 균일합니다.
이 주제에서 설명하는 다른 토큰화 방법과 달리 암호화 해싱은 단방향 토큰을 만듭니다. 즉, 암호화 해싱을 사용한 익명화는 되돌릴 수 없습니다.
다음은 1-206-555-0123 값에서 암호화 해시를 사용하는 익명화 작업의 출력입니다. 이 출력은 해시된 값이 base64로 인코딩된 표현입니다.
XlTCv8h0GwrCZK+sS0T3Z8txByqnLLkkF4+TviXfeZY=
암호화 키 사용
민감한 정보 보호의 암호화 익명화 방법과 함께 사용할 수 있는 암호화 키에는 세 가지 옵션이 있습니다.
Cloud KMS 래핑 암호화 키: 민감한 정보 보호 익명화 방법과 함께 사용할 수 있는 가장 안전한 유형의 암호화 키입니다. Cloud KMS 래핑 키는 다른 키를 사용하여 암호화된 128비트, 192비트 또는 256비트 암호화 키로 구성됩니다. 첫 번째 암호화 키를 제공한 후 Cloud Key Management Service에 저장된 암호화 키를 사용하여 래핑합니다. 이러한 종류의 키는 나중에 재식별할 수 있도록 Cloud KMS에 저장됩니다. 익명화 및 재식별 목적으로 키를 만들고 래핑하는 방법에 대한 자세한 내용은 빠른 시작: 민감한 텍스트 익명화 및 재식별을 참조하세요.
임시 암호화 키: 임시 암호화 키는 익명화될 때 민감한 정보 보호에 의해 생성된 후 삭제됩니다. 이러한 이유로 되돌리려는 암호화 익명화 방법에 임시 암호화 키를 사용하지 마세요. 임시 암호화 키는 API 요청당 무결성만 유지합니다. API 요청 두 개 이상에서 무결성이 필요하거나 데이터를 다시 식별하려는 경우에는 이 키 유형을 사용하지 마세요.
래핑되지 않은 암호화 키: 래핑되지 않은 키는 DLP API에 대한 익명화 요청 내에서 제공하는 원시 base64로 인코딩된 128비트, 192비트 또는 256비트 암호화 키입니다. 개발자는 나중에 재식별할 수 있도록 이러한 종류의 암호화 키를 보존해야 합니다. 실수로 키를 유출할 위험이 있으므로 이러한 유형의 키는 권장되지 않습니다. 이러한 키는 테스트에 유용할 수 있지만 프로덕션 워크로드의 경우에는 대신 Cloud KMS 래핑 암호화 키를 사용하는 것이 좋습니다.
암호화 키를 사용하는 경우에 사용할 수 있는 옵션에 대한 자세한 내용은 DLP API 참조의 CryptoKey를 참조하세요.
컨텍스트 조정 사용
기본적으로 모든 익명화의 암호화 변환 방법에는 출력 토큰이 단방향이거나 양방향인지에 관계없이 참조 무결성이 있습니다. 즉, 동일한 암호화 키가 제공되면 입력 값은 항상 동일한 암호화된 값으로 변환됩니다. 반복되는 데이터 또는 데이터 패턴이 발생할 수 있으면 재식별 위험이 증가합니다. 대신 동일한 입력 값이 항상 다른 암호화된 값으로 변환되도록 하려면 고유한 컨텍스트 조정을 지정하면 됩니다.
조정이 식별자와 같은 데이터 열에 대한 효과적인 포인터이므로 테이블 형식의 데이터를 변환할 때 컨텍스트 조정(간단히 DLP API의 context라고 함)을 지정합니다.
민감한 정보 보호는 입력 값을 암호화할 때 컨텍스트 조정에서 지정된 필드의 값을 사용합니다. 암호화된 값이 항상 고유한 값이 되도록 하려면 고유 식별자가 포함된 조정에 열을 지정합니다.
이 간단한 예시를 살펴보세요. 다음 표에서는 여러 의료 기록을 보여줍니다. 이 중 일부는 중복된 환자 ID가 포함되어 있습니다.
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 43789 | E11.9 |
| 5438 | 43671 | M25.531 |
| 5439 | 43789 | N39.0, I25.710 |
| 5440 | 43766 | I10 |
| 5441 | 43766 | I10 |
| 5442 | 42989 | R07.81 |
| 5443 | 43098 | I50.1, R55 |
| ... | ... | ... |
민감한 정보 보호가 테이블의 환자 ID를 익명화하도록 지시하면 기본적으로 다음 표에 표시된 대로 반복 환자 ID가 동일한 값으로 익명화됩니다. 예를 들어 환자 ID '43789'의 인스턴스가 모두 '47222'로 익명화됩니다. patient_id 열은 FPE-FFX를 사용한 가명처리 후 토큰 값을 보여주며 서로게이트 주석을 포함하지 않습니다. 자세한 내용은 형식 보존 암호화를 참조하세요
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 47222 | E11.9 |
| 5438 | 82160 | M25.531 |
| 5439 | 47222 | N39.0, I25.710 |
| 5440 | 04452 | I10 |
| 5441 | 04452 | I10 |
| 5442 | 47826 | R07.81 |
| 5443 | 52428 | I50.1, R55 |
| ... | ... | ... |
즉, 참조 무결성 범위는 전체 데이터 세트입니다.
이 동작을 방지하도록 범위를 좁히려면 컨텍스트 조정을 지정합니다. 모든 열을 컨텍스트 조정으로 지정할 수 있지만 익명화된 각 값이 고유하도록 보장하려면 모든 값이 고유한 열을 지정합니다.
동일한 환자가 icd10_codes 값마다 표시되는지 알려고 하지만 동일한 환자가 다른 icd10_codes 값에 표시되지 않는다고 가정해 보겠습니다. 이렇게 하려면 icd10_codes 열을 컨텍스트 조정으로 지정합니다.
다음은 컨텍스트 조정으로 icd10_codes 열을 사용하여 patient_id 열을 익명화한 테이블입니다.
| record_id | patient_id | icd10_codes |
|---|---|---|
| 5437 | 18954 | E11.9 |
| 5438 | 33068 | M25.531 |
| 5439 | 76368 | N39.0, I25.710 |
| 5440 | 29460 | I10 |
| 5441 | 29460 | I10 |
| 5442 | 23877 | R07.81 |
| 5443 | 96129 | I50.1, R55 |
| ... | ... | ... |
원래 patient_id 값만 동일할 뿐 아니라 두 행의 icd10_codes 값도 동일하므로 4번째 값과 5번째 익명화된 patient_id 값(29460)이 동일합니다. icd10_codes 값의 범위 내에서 일관된 환자 ID로 분석을 실행해야 했으므로 이 동작이 필요합니다.
patient_id 값과 icd10_codes 값 사이의 참조 무결성을 완전히 차단하려면 대신 record_id 열을 컨텍스트 조정으로 사용하면 됩니다.
| record_id | patient_id | icd10_code |
|---|---|---|
| 5437 | 15826 | E11.9 |
| 5438 | 61722 | M25.531 |
| 5439 | 34424 | N39.0, I25.710 |
| 5440 | 02875 | I10 |
| 5441 | 52549 | I10 |
| 5442 | 17945 | R07.81 |
| 5443 | 19030 | I50.1, R55 |
| ... | ... | ... |
이제 테이블의 각 익명화된 patient_id 값이 고유해집니다.
DLP API에서 컨텍스트 조정을 사용하는 방법은 다음 변환 방법 참조 주제의 context 사용을 참조하세요.
- 형식 보존 암호화:
CryptoReplaceFfxFpeConfig - AES-SIV를 사용한 확정적 암호화:
CryptoDeterministicConfig - 날짜 이동:
DateShiftConfig
다음 단계
래핑된 키를 만들고 콘텐츠를 토큰화하고 토큰화된 콘텐츠를 재식별하는 방법을 보여주는 엔드 투 엔드 예시를 살펴보세요.
DLP API를 사용하여 데이터를 익명화하는 방법에 대해 알아보세요.