기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

C3R 암호화 클라이언트에 대한 지침

C3R 암호화 클라이언트는 조직이 민감한 데이터를 한데 모아 데이터 분석에서 새로운 인사이트를 도출할 수 있도록 지원하는 도구입니다. 이 도구는 모든 당사자가 그 과정에서 학습할 수 있는 내용을 암호화하여 제한합니다. AWS 이는 매우 중요하지만, 데이터를 암호화하여 보호하는 과정은 컴퓨팅 및 스토리지 리소스 측면에서 상당한 오버헤드를 유발할 수 있습니다. 따라서 각 설정 사용의 장단점을 이해하고 원하는 암호화 보장을 유지하면서 설정을 최적화하는 방법을 이해하는 것이 중요합니다. 이 항목에서는 C3R 암호화 클라이언트 및 스키마의 다양한 설정이 성능에 미치는 영향을 중점적으로 다룹니다.

모든 C3R 암호화 클라이언트 암호화 설정은 서로 다른 암호화 보장을 제공합니다. 공동 작업 수준 설정은 기본적으로 가장 안전합니다. 공동 작업을 생성하는 동안 추가 기능을 활성화하면 개인정보 보호가 약화되어 빈도 분석과 같은 활동이 사이퍼텍스트에서 수행될 수 있습니다. 이러한 설정이 사용되는 방식 및 그 영향에 대한 자세한 내용은 Clean Rooms에 대한 암호화 컴퓨팅을 참조하세요.

열 유형에 대한 성능 영향

C3R은 세 가지 열 유형(cleartext, fingerprint 및 sealed)을 사용합니다. 각 열 유형은 서로 다른 암호화 보장을 제공하며 용도도 다릅니다. 다음 섹션에서는 열 유형이 성능에 미치는 영향과 각 설정이 성능에 미치는 영향에 대해 설명합니다.

Cleartext 열

Cleartext 열은 원래 형식에서 변경되지 않으며 어떤 방식으로도 암호화 처리되지 않습니다. 이 열 유형은 구성할 수 없으며 스토리지 또는 컴퓨팅 성능에 영향을 주지 않습니다.

Fingerprint 열

Fingerprint 열은 여러 테이블의 데이터를 조인하는 데 사용됩니다. 이를 위해서는 결과 사이퍼텍스트 크기가 항상 같아야 합니다. 그러나 이러한 열은 공동 작업 수준 설정의 영향을 받습니다. Fingerprint 열은 입력에 포함된 cleartext 열에 따라 출력 파일 크기에 다양한 정도의 영향을 미칠 수 있습니다.

fingerprint 열의 기본 오버헤드

fingerprint 열에 대한 기본 오버헤드가 있습니다. 이 오버헤드는 일정하며 cleartext 바이트 크기를 대체합니다.

fingerprint 열의 데이터는 해시 기반 메시지 인증 코드(HMAC) 함수를 통해 암호화 처리되며, HMAC(해시 기반 메시지 인증 코드) 함수는 데이터를 32바이트 메시지 인증 코드(MAC)로 변환합니다. 그런 다음 이 데이터는 base64 인코더를 통해 처리되어 바이트 크기에 약 33% 가 추가됩니다. 데이터가 속하는 열의 유형과 해당 열을 생성한 클라이언트 버전을 지정하는 8바이트 C3R 지정이 앞에 추가됩니다. 최종 결과는 52바이트입니다. 그런 다음 이 결과에 행 수를 곱하여 총 기본 오버헤드를 구합니다 (preserveNulls이 참으로 설정된 경우 null이 아닌 총 값의 수 사용).

다음 이미지는 BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33) 방법을 보여줍니다

fingerprint 열의 출력 사이퍼텍스트은 항상 52바이트입니다. 입력 cleartext 데이터가 평균 52바이트를 초과하는 경우(예: 전체 주소) 스토리지가 크게 감소할 수 있습니다. 입력 cleartext 데이터가 평균 52바이트 미만인 경우(예: 고객 사용 기간) 스토리지가 크게 증가할 수 있습니다.

fingerprint 열에 대한 공동 작업 설정

preserveNulls 설정

공동 작업 수준 설정 preserveNulls이(가) false(기본값)인 경우, 각 null 값은 고유한 임의의 32바이트로 대체되어 null이(가) 아닌 것처럼 처리됩니다. 그 결과 이제 각 null 값은 52바이트가 되었습니다. 이렇게 하면 이 설정이 true이고 null 값이 null로 전달될 때와 비교하여 매우 희소한 데이터를 포함하는 테이블에 대한 스토리지 요구 사항이 크게 증가할 수 있습니다.

이 설정의 개인정보 보호가 필요하지 않고 데이터 세트 내에 null 값을 보관하고 싶다면 공동 작업을 만들 때 preserveNulls 설정을 활성화하세요. 공동 작업을 생성한 후에는 preserveNulls 설정을 변경할 수 없습니다.

fingerprint 열의 예제 데이터

다음은 재현할 설정이 있는 fingerprint 열의 입력 및 출력 데이터 세트 예제입니다. allowCleartext와(과) allowDuplicates같은 다른 공동 작업 수준 설정은 결과에 영향을 주지 않으므로 로컬에서 재현하려는 경우, true 또는 false(으)로 설정할 수 있습니다.

공유 비밀의 예: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

공동 작업 ID 예시: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True 이 설정은 성능이나 스토리지 요구 사항에 영향을 주지 않습니다. 하지만 이 설정을 사용하면 다음 표에 표시된 값을 재현할 때 열 이름을 선택할 필요가 없습니다.

문제 해결 fingerprint 열

fingerprint 열의 사이퍼텍스트 텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 큰 이유는 무엇인가요?

fingerprint 열의 사이퍼텍스트 길이는 항상 52바이트입니다. 입력 데이터가 작을 경우(예: 고객 연령) 크기가 크게 증가합니다. preserveNulls 설정이 false(으)로 설정된 경우에도 이런 일이 발생할 수 있습니다.

fingerprint 열의 사이퍼텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 작은 이유는 무엇인가요?

fingerprint 열의 사이퍼텍스트 길이는 항상 52바이트입니다. 입력 데이터가 큰 경우(예: 고객의 전체 주소) 크기가 크게 줄어듭니다.

preserveNulls에서 제공하는 암호화 보증이 필요한지 어떻게 알 수 있나요?

안타깝게도 답은 상황에 따라 다르다는 것입니다. 최소한 preserveNulls 설정이 데이터를 어떻게 보호하는지 암호화 컴퓨팅 파라미터을 검토해야 합니다. 하지만 조직의 데이터 처리 요구 사항 및 각 공동 작업에 적용되는 모든 계약을 참조하는 것이 좋습니다.

base64의 오버헤드가 발생해야 하는 이유는 무엇입니까?

CSV와 같은 표 형식 파일 형식과의 호환성을 허용하려면 base64 인코딩이 필요합니다. Parquet와 같은 일부 파일 형식은 데이터의 바이너리 표현을 지원할 수 있지만 올바른 쿼리 결과를 얻으려면 공동 작업의 모든 참여자가 동일한 방식으로 데이터를 나타내는 것이 중요합니다.

Sealed 열

Sealed 열은 공동 작업 구성원 간에 데이터를 전송할 때 사용됩니다. 이러한 열의 사이퍼텍스트는 결정적이지 않으며 열 구성 방식에 따라 성능과 스토리지 모두에 상당한 영향을 미칩니다. 이러한 열은 개별적으로 구성할 수 있으며 대개 C3R 암호화 클라이언트의 성능과 결과 출력 파일 크기에 가장 큰 영향을 미칩니다.

sealed 열의 기본 오버헤드

sealed 열에는 기본 오버헤드가 있습니다. 이 오버헤드는 일정하며, cleartext 및 패딩(있는 경우) 바이트의 크기와 함께 발생합니다.

암호화하기 전에는 sealed 열의 데이터 앞에 포함되는 데이터 유형을 지정하는 1바이트 문자가 추가됩니다. 패딩을 선택하면 데이터가 채워지고 패드 크기를 나타내는 2바이트가 추가됩니다. 이러한 바이트가 추가되면 AES-GCM을 사용하여 데이터를 암호화 처리하여 IV (12바이트), nonce (32바이트) 및 (16바이트) 로 저장합니다. Auth Tag 그런 다음 이 데이터는 base64 인코더를 통해 처리되어 바이트 크기에 약 33% 가 추가됩니다. 데이터 앞에 7바이트 C3R 지정이 추가되어 데이터가 속하는 열 유형과 데이터를 생성하는 데 사용된 클라이언트 버전을 지정합니다. 결과적으로 최종 베이스 오버헤드는 91바이트입니다. 그런 다음 이 결과에 행 수를 곱하여 총 기본 오버헤드를 구할 수 있습니다(preserveNulls이 참으로 설정된 경우 null이 아닌 총 값 수 사용).

다음 이미지는 BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33) 방법을 보여줍니다

sealed 열에 대한 공동 작업 설정

preserveNulls 설정

공동 작업 수준 설정 preserveNulls이(가) false(기본값)인 경우 각 null 값은 고유한 32바이트의 무작위 값이며, null이(가) 아닌 것처럼 처리됩니다. 그 결과 이제 각 null 값은 91바이트가 됩니다(패딩된 경우 더 많음). 이렇게 하면 이 설정이 true이고 null 값이 null로 전달될 때와 비교하여 매우 희박한 데이터가 포함된 테이블의 경우 상당한 스토리지 요구 사항이 추가될 수 있습니다.

이 설정의 개인정보 보호가 필요하지 않고 데이터 세트 내에 null 값을 보관하고 싶다면 공동 작업을 만들 때 preserveNulls 설정을 활성화하세요. 공동 작업을 생성한 후에는 preserveNulls 설정을 변경할 수 없습니다.

스키마 설정 sealed 열: 패딩 유형

패드 유형: none

none 패드 유형을 선택하면 패딩이 cleartext에 추가되지 않으며 앞서 설명한 기본 오버헤드에 추가 오버헤드가 추가되지 않습니다. 패딩이 없으면 출력 크기가 가장 공간 효율적입니다. 그러나 fixed 및 max 패딩 유형과 동일한 개인 정보 보호 보장을 제공하지는 않습니다. 이는 사이퍼텍스트의 크기로 기본 cleartext 파일의 크기를 식별할 수 있기 때문입니다.

패드 유형: fixed

fixed 패드 유형을 선택하면 개인 정보 보호를 위해 열에 포함된 데이터의 길이를 숨길 수 있습니다. 이는 암호화하기 전에 모든 cleartext를 제공된 pad_length에 패딩하는 방식으로 수행됩니다. 데이터가 이 크기를 초과하면 C3R 암호화 클라이언트가 실패합니다.

암호화되기 전에 cleartext에 패딩이 추가된다는 점을 감안할 때, AES-GCM은 cleartext를 사이퍼텍스트 바이트에 1대 1로 매핑합니다. base64 인코딩은 33% 를 추가할 것입니다. 패딩의 추가 스토리지 오버헤드는 pad_length의 값에서 cleartext의 평균 길이를 뺀 다음 1.33을 곱하여 계산할 수 있습니다. 결과는 레코드당 평균 패딩 오버헤드입니다. 그런 다음 이 결과에 행 수를 곱하여 총 패딩 오버헤드를 구할 수 있습니다(preserveNulls이 true로 설정된 경우 null이 아닌 총 값의 수 사용).

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

열의 가장 큰 값을 포함하는 최소 pad_length를 선택하는 것이 좋습니다. 예를 들어, 가장 큰 값이 50바이트인 경우 50의 pad_length면 충분합니다. 이보다 큰 값은 스토리지 오버헤드만 추가될 뿐입니다.

고정 패딩은 큰 컴퓨팅 오버헤드를 추가하지 않습니다.

max의 패드 유형

max의 패드 유형을 선택하면 개인 정보 보호를 위해 열에 포함된 데이터의 길이를 숨길 수 있습니다. 암호화하기 전에 모든 cleartext를 열의 가장 큰 값에 더한 추가 pad_length로 모두 채워 넣으면 됩니다. 일반적으로 max 패딩은 단일 데이터 세트의 fixed 패딩과 동일한 보장을 제공하지만 열의 가장 큰 cleartext을(를) 알 수 없도록 합니다. 그러나 개별 데이터 세트에서 가장 큰 값이 다를 수 있으므로 max 패딩은 업데이트 전반의 fixed 패딩과 동일한 개인정보 보호 보장을 제공하지 않을 수 있습니다.

max 패딩을 사용할 때는 pad_length를 0으로 추가 선택하는 것이 좋습니다. 이 길이는 모든 값을 열의 가장 큰 값과 같은 크기로 채웁니다. 이보다 큰 값은 스토리지 오버헤드만 추가될 뿐입니다.

해당 열의 최대 cleartext 값이 알려진 경우 fixed 패드 유형을 대신 사용하는 것이 좋습니다. fixed 패딩을 사용하면 업데이트된 데이터 세트 간에 일관성을 유지할 수 있습니다. max 패딩을 사용하면 각 데이터 하위 집합이 하위 집합에 있었던 가장 큰 값으로 채워집니다.

sealed 열에 대한 예제 데이터

다음은 재현할 설정이 있는 sealed 열의 입력 및 출력 데이터 세트 예제입니다. allowCleartext, allowJoinsOnColumnsWithDifferentNames, 및 allowDuplicates같은 기타 공동 작업 수준 설정은 결과에 영향을 주지 않으며 로컬에서 재현하려는 경우 true 또는 false(으)로 설정할 수 있습니다. 이러한 설정이 재현을 위한 기본 설정이긴 하지만 sealed 열은 결정적이지 않으므로 값이 매번 변경됩니다. 목표는 입력 바이트와 출력 바이트를 비교하여 표시하는 것입니다. 예제 pad_length 값은 의도적으로 선택되었습니다. fixed 패딩을 사용하면 권장되는 최소 pad_length 설정 또는 추가 패딩이 필요한 경우 max 패딩과 동일한 값을 얻을 수 있습니다.

공유 비밀의 예: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

공동 작업 ID 예시: a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

none의 패드 유형

fixed의 패드 유형(예 1)

이 예제에서 pad_length는 62이고 최대 입력은 62바이트입니다.

fixed의 패드 유형(예 2)

이 예제에서 pad_length는 162이고 최대 입력은 62바이트입니다.

max의 패드 유형(예시 1)

이 예제에서 pad_length는 0이고 최대 입력은 62바이트입니다.

패드 유형 max (예 2)

이 예제에서 pad_length 는 100이고 최대 입력은 62바이트입니다.

문제 해결 sealed 열

sealed 열의 사이퍼텍스트가 그 안에 들어간 cleartext 열의 크기보다 몇 배나 큰 이유는 무엇인가요?

이는 여러 요인에 따라 달라집니다. 예를 들어, Cleartext 열의 사이퍼텍스트 길이는 항상 91바이트 이상입니다. 입력 데이터가 작을 경우(예: 고객 연령) 크기가 크게 증가합니다. 둘째, preserveNulls이 false로 설정되어 있고 입력 데이터에 null 값이 많이 포함되어 있는 경우, 각 null 값은 91바이트의 사이퍼텍스트로 변환됩니다. 마지막으로, 패딩을 사용하면 정의상 데이터가 암호화되기 전에 cleartext 데이터에 바이트가 추가됩니다.

sealed 열에 있는 대부분의 데이터는 매우 작아서 패딩을 사용해야 합니다. 스페이스를 절약하기 위해 큰 값을 제거하고 개별적으로 처리해도 될까요?

큰 값을 삭제하고 별도로 처리하지 않는 것이 좋습니다. 이렇게 하면 C3R 암호화 클라이언트가 제공하는 개인 정보 보호 보장이 변경됩니다. 위협 모델로서 관찰자가 암호화된 데이터 세트를 모두 볼 수 있다고 가정해 봅시다. 관찰자는 한 데이터 하위 집합의 열이 다른 하위 집합보다 훨씬 많거나 적게 채워진 것을 발견하면 각 하위 집합의 데이터 크기를 추론할 수 있습니다. 예를 들어 한 파일에서는 fullName 열이 총 40바이트로 채워지고 다른 파일에서는 800바이트로 채워져 있다고 가정해 보겠습니다. 관찰자는 한 데이터 세트에 세계에서 가장 긴 이름 (747바이트) 이 포함되어 있다고 가정할 수 있습니다.

max 패딩 유형을 사용할 때 추가 패딩을 제공해야 하나요?

max 패딩을 사용하는 경우 열에서 가장 큰 값을 초과하는 추가 패딩이라고도 하는 pad_length를 0으로 설정하는 것이 좋습니다.

가장 큰 값이 맞을지 걱정하지 않도록 fixed 패딩을 사용할 때 큰 pad_length를 선택해도 되나요?

네, 하지만 패드 길이가 길면 비효율적이며 필요 이상으로 많은 저장 공간을 사용합니다. 가장 큰 값이 얼마나 큰지 확인하고 pad_length를 해당 값으로 설정하는 것이 좋습니다.

preserveNulls에서 제공하는 암호화 보증이 필요한지 어떻게 알 수 있나요?

안타깝게도 답은 상황에 따라 다르다는 것입니다. 최소한 preserveNulls 설정이 데이터를 어떻게 보호하는지 Clean Rooms에 대한 암호화 컴퓨팅을 검토해야 합니다. 하지만 조직의 데이터 처리 요구 사항 및 각 공동 작업에 적용되는 모든 계약을 참조하는 것이 좋습니다.

base64의 오버헤드가 발생해야 하는 이유는 무엇입니까?

CSV와 같은 표 형식 파일 형식과의 호환성을 허용하려면 base64 인코딩이 필요합니다. Parquet같은 일부 파일 형식은 데이터의 바이너리 표현을 지원할 수 있지만 올바른 쿼리 결과를 얻으려면 공동 작업의 모든 참여자가 동일한 방식으로 데이터를 나타내는 것이 중요합니다.

예상하지 못한 사이퍼텍스트 크기 증가 문제 해결

데이터를 암호화했는데 결과 데이터의 크기가 놀라울 정도로 크다고 가정해 보겠습니다. 다음 단계는 크기 증가가 발생한 위치와 취할 수 있는 조치(있는 경우)를 식별하는 데 도움이 될 수 있습니다.

크기 증가가 발생한 위치 식별

암호화된 데이터가 cleartext 데이터보다 훨씬 큰 이유를 해결하려면 먼저 크기가 어디서 증가했는지 확인해야 합니다. Cleartext 열은 변경되지 않으므로 무시해도 됩니다. 나머지 fingerprint 열과 sealed 열을 살펴보고 중요해 보이는 열을 선택하세요.

크기 증가가 발생한 원인 파악

fingerprint 열 또는 sealed 열이 크기 증가에 영향을 줄 수 있습니다.

fingerprint 열에서 크기가 커졌나요?

스토리지 증가에 가장 큰 영향을 미치는 fingerprint 열인 경우, cleartext 데이터가 적기 때문일 수 있습니다(예: 고객 연령). 결과로 생성되는 각 fingerprint 사이퍼텍스트의 길이는 52바이트입니다. 유감스럽게도 이 문제에 대해서는 어떠한 조치도 취할 수 없습니다 column-by-column . 이 열이 스토리지 요구 사항에 미치는 영향을 포함하여 이 열에 대한 자세한 내용은 fingerprint 열의 기본 오버헤드을(를) 참조하세요.

fingerprint 열의 크기가 증가하는 다른 가능한 원인은 공동 작업 설정인 preserveNulls입니다. preserveNulls에 대한 공동 작업 설정을 사용하지 않도록 설정하면(기본 설정) fingerprint 열의 모든 null 값이 52바이트의 사이퍼텍스트가 됩니다. 현재 공동 작업에서는 이에 대해 수행할 수 있는 작업이 없습니다. preserveNulls 설정은 공동 작업을 생성할 때 설정되며 올바른 쿼리 결과를 얻으려면 모든 협업자가 동일한 설정을 사용해야 합니다. preserveNulls 설정 및 설정 활성화가 데이터의 개인 정보 보장에 미치는 영향에 대한 자세한 내용은 Clean Rooms에 대한 암호화 컴퓨팅을 참조하세요.

sealed 열을 통해 크기가 커졌나요?

저장용량 증가에 가장 큰 영향을 미치는 sealed 열이 열인 경우 크기 증가에 기여할 수 있는 몇 가지 세부 정보가 있습니다.

cleartext 데이터가 작은 경우(예: 고객 연령) 결과로 생성되는 각 sealed 사이퍼텍스트의 길이는 91바이트 이상입니다. 안타깝게도 이 문제에 대해서는 아무 것도 할 수 없습니다. 스토리지 요구 사항에 미치는 영향을 포함하여 이 열에 대한 자세한 내용은 sealed 열의 기본 오버헤드에 대한 세부 정보를 참조하세요.

sealed 열 스토리지 증가의 두 번째 주요 원인은 패딩입니다. 패딩은 데이터 세트에서 개별 값의 크기를 숨기기 위해 암호화하기 전에 cleartext에 추가 바이트를 추가합니다. 패딩을 데이터 세트의 가능한 최소값으로 설정하는 것이 좋습니다. 최소한 열에서 가능한 가장 큰 값을 포함하도록 fixed에 대한 pad_length 패딩을 설정해야 합니다. 이보다 높게 설정해도 개인 정보 보장이 추가되지는 않습니다. 예를 들어 열의 가능한 최대 값이 50바이트라는 것을 알고 있는 경우 pad_length를 50바이트로 설정하는 것이 좋습니다. 그러나 sealed 열이 max 패딩을 사용하는 경우에는 pad_length를 0바이트로 설정하는 것이 좋습니다. 이는 max 패딩이 열의 가장 큰 값을 초과하는 추가 패딩을 의미하기 때문입니다.

sealed 열의 크기가 커질 수 있는 마지막 원인은 공동 작업 설정인 preserveNulls입니다. preserveNulls에 대한 공동 작업 설정을 사용하지 않도록 설정하면(기본 설정) sealed 열의 모든 null 값이 91바이트의 사이퍼텍스트가 됩니다. 현재 공동 작업에서는 이에 대해 수행할 수 있는 작업이 없습니다. preserveNulls 설정은 공동 작업이 생성될 때 설정되며 올바른 쿼리 결과를 얻으려면 모든 협업자가 동일한 설정을 사용해야 합니다. 이 설정의 영향 및 활성화가 데이터의 개인 정보 보호 보장에 미치는 영향에 대한 자세한 내용은 Clean Rooms에 대한 암호화 컴퓨팅을 참조하세요.