View a markdown version of this page

비컨 길이 및 파티션 선택 - AWS 데이터베이스 암호화 SDK

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

비컨 길이 및 파티션 선택

클라이언트 측 암호화 라이브러리의 이름이 AWS Database Encryption SDK로 변경되었습니다. 이 개발자 안내서는 여전히 DynamoDB Encryption Client에 대한 정보를 제공합니다.

검색 가능한 암호화를 위해 구성된 암호화된 필드에 새 값을 작성하면 AWS Database Encryption SDK는 파티션 식별자와 결합된 일반 텍스트 값을 통해 HMAC를 계산합니다. 지정된 파티션 내에서 전체 HMAC는 일반 텍스트 값을 고유하게 나타냅니다. 그런 다음 SDK는 여러 개의 고유한 일반 텍스트 값이 동일한 비컨에 매핑될 수 있도록 HMAC 출력을 잘라냅니다. 거짓 긍정이라고도 하는 이러한 충돌은 권한이 없는 사용자가 기본 일반 텍스트에 대한 구별되는 정보를 유추할 수 있는 능력을 제한합니다.

각 비컨에 대해 생성된 평균 거짓 긍정 수는 잘린 후 남아 있는 비컨 길이와 사용 중인 파티션 수에 따라 결정됩니다. 표준 비컨을 구성할 때 비컨 길이만 정의하면 됩니다. 복합 비컨은 구성된 표준 비컨의 비컨 길이를 사용합니다. 여러 파티션에 값을 분산하면 각 파티션 내에서 충돌이 유지되므로 올바른 쿼리 동작을 유지하면서 빈도 집중을 줄이는 데 도움이 됩니다.

비컨은 필드의 암호화된 상태를 변경하지 않습니다. 그러나 비컨을 사용할 때 쿼리의 효율성과 데이터 분포에 대해 공개되는 정보의 양 사이에는 본질적인 균형이 있습니다. 비컨 길이와 추가 파티션이 짧을수록 충돌이 증가하고 빈도 누출이 감소하는 반면, 비컨 길이가 길고 파티션이 적을수록 쿼리 정밀도가 향상됩니다.

검색 가능한 암호화의 목표는 비컨을 사용하여 암호화된 데이터에 대한 쿼리를 수행함으로써 클라이언트측 암호화된 데이터베이스와 관련된 성능 비용을 줄이는 것입니다. 비컨은 비컨이 계산되는 암호화된 필드와 함께 저장됩니다. 이는 데이터 세트의 분포에 대한 구별되는 정보를 공개할 수 있음을 의미합니다. 극단적인 경우 권한이 없는 사용자가 배포에 대해 공개된 정보를 분석하고 이를 사용하여 필드의 일반 텍스트 값을 식별할 수 있습니다. 적절한 비컨 길이와 파티션 수를 선택하면 이러한 위험을 완화하고 데이터의 기밀성을 유지하는 데 도움이 됩니다.

위협 모델을 검토하여 필요한 보안 수준을 결정합니다. 예를 들어, 데이터베이스에 액세스할 수 있지만 일반 텍스트 데이터에 액세스할 수 없는 개인이 많을수록 데이터 세트 배포의 기밀성을 더 많이 보호해야 할 수 있습니다. 기밀성을 높이려면 일반적으로 더 짧은 비컨 길이, 추가 파티션 또는 둘 다를 통해 더 많은 오탐지를 생성해야 하므로 쿼리 성능이 저하될 수 있습니다.

파티셔닝 체계 선택

파티셔닝 체계는 비컨이 파생될 때 항목이 파티션에 배포되는 방법을 결정합니다. 개인 정보 보호, 성능 및 운영 예측 가능성의 균형을 맞추려면 적절한 체계를 선택하는 것이 중요합니다.

파티셔닝 체계를 선택할 때 다음 목표를 고려하세요.

  • 고주파 값을 분산하여 대규모 비컨 동등성 클래스를 줄입니다.

  • 민감한 정보가 유출될 수 있는 예측 가능한 패턴을 도입하지 마세요.

  • 쓰기 및 쿼리 전반에 걸쳐 안정적인 동작을 유지합니다.

기본 임의 분포

권장되는 기본값은 무작위 배포 체계입니다. 이 모델에서 각 항목은 암호화 방식으로 안전한 임의 값을 사용하여 파티션에 할당됩니다. 임의 분포는 시간이 지남에 따라 거의 동일한 파티션 크기를 생성하며 빈번한 값이 균등하게 분산되도록 합니다.

다음과 같은 경우 무작위 분포를 사용합니다.

  • 가치 분포에 대한 강력한 도메인 지식이 없습니다.

  • 데이터 세트에는 알 수 없거나 진화하는 스큐가 포함되어 있습니다.

  • 속성 종속 누출을 최소화하려고 합니다.

결정적 분포

경우에 따라 파티션 할당이 결정적이어야 합니다. 결정적 체계는 항목 속성의 안정적인 함수를 기반으로 파티션을 할당합니다. 왜곡되거나 민감한 입력은 고르지 않은 파티셔닝이나 의도하지 않은 정보 유출을 초래할 수 있으므로 이러한 체계는 신중하게 설계해야 합니다.

다음과 같은 경우 결정적 분포를 사용합니다.

  • 운영 워크플로는 일관된 파티션 배치에 따라 달라집니다.

  • 의도적으로 단일 파티션으로 그룹화된 고유한 값 집합이 있습니다.

알려진 핫 값 처리

데이터 세트에 잘 알려진 핫 값이 포함된 경우 무작위 전략과 결정론적 전략을 결합할 수 있습니다. 예를 들어 다른 모든 값을 결정론적으로 할당하면서 작은 고주파 값 집합을 무작위로 분산할 수 있습니다.

이 접근 방식은 핫 값에 대한 집중을 줄이는 동시에 나머지 데이터 세트에 대해 예측 가능한 동작을 유지합니다. 추가 복잡성이 발생하므로 신중하게 검토하여 의도하지 않은 정보 유출을 방지하세요.

파티셔닝 체계 예제

다음 예제에서는 일반적인 파티셔닝 체계를 설명하고 다양한 데이터 특성이 파티션 할당에 미치는 영향을 보여줍니다. 각 예제는 프라이버시, 성능 및 운영 단순성의 균형을 맞추는 방법을 보여줍니다.

예제 1: 균일하게 분산된 데이터

전화번호에 대한 비컨을 생성하고 있으며 데이터 세트의 값은 거의 균일하게 분포되어 있습니다. 단일 전화번호가 다른 전화번호보다 훨씬 더 자주 표시되지 않습니다.

이 경우 단일 파티션을 구성하는 것으로 충분합니다. 추가 파티션은 거의 이점을 제공하지 않으며 쿼리 팬아웃만 증가시킵니다.

예제 2: 왜곡된 빈도의 이진 결과

의료 테스트 결과를 NEGATIVE와 POSITIVE라는 두 가지 값으로 저장하는 데이터베이스가 있습니다. 부정 결과는 긍정적 결과보다 약 5배 더 자주 발생합니다.

빈도 누출을 줄이려면 혼합 전략을 사용합니다.

  • 5개의 파티션에 부정적 결과를 무작위로 할당합니다.

  • 단일 파티션에 POSITIVE 결과를 결정적으로 할당합니다.

이 접근 방식은 더 드문 값을 안정적으로 유지하면서 과도하게 표현된 값을 분산시켜 불필요한 팬아웃 없이 대규모 동등성 클래스를 줄입니다.

예제 3: 대규모 도메인의 알려진 핫 값

이름의 데이터베이스가 미국에 있습니다. 비교적 작은 일반 이름 집합(예: 가장 빈번한 상위 500개 이름)은 나머지 이름보다 훨씬 더 자주 나타납니다.

  • 상위 500개의 가장 빈번한 이름을 4개의 파티션에 무작위로 할당합니다.

  • 나머지 모든 이름을 단일 파티션에 결정적으로 할당합니다.

  • 각 파티션에 할당된 데이터가 거의 균일한 분포를 보일 때까지 파티션 수를 점진적으로 늘립니다.

이 하이브리드 접근 방식은 대부분의 이름에 대해 파티셔닝을 간단하고 예측 가능하게 유지하면서 알려진 핫 값을 대상으로 합니다.

이 예제에서는 파티셔닝 체계를 다양한 데이터 특성에 맞게 조정하는 방법을 보여줍니다. 대부분의 경우 무작위 배포로 충분하지만 도메인 지식을 통합하면 신중하게 적용할 때 프라이버시와 성능을 더욱 개선할 수 있습니다.

비컨 길이 계산

비컨 길이는 비트 단위로 지정되며 잘린 후 보존되는 HMAC 출력의 비트 수를 결정합니다. 권장 길이는 각 파티션 내에서 값이 분산되는 방식, 데이터에 상관관계가 있는 값이 포함되어 있는지 여부, 보안 및 성능 요구 사항에 따라 달라집니다. 적절한 파티셔닝 체계를 적용한 후 데이터 세트가 거의 균일한 경우 간단한 방정식과 튜닝 절차를 사용하여 효과적인 비컨 길이를 추정할 수 있습니다. 이러한 방정식은 비컨이 생성할 수 있는 평균 오탐 수의 추정치를 제공하지만 데이터 세트의 모든 고유 값에 대해 특정 수의 오탐을 보장하지는 않습니다. 첫 번째 단계는 모집단을 추정하는 것입니다.

참고

이러한 방정식의 효과는 각 파티션 내의 데이터 세트 분포에 따라 달라집니다. 데이터세트가 균일하게 분포되지 않은 경우 비컨이 내 데이터 세트에 적합한가? 섹션을 참조하세요.

모집단 추정

모집단은 표준 비컨을 구성하는 필드의 예상 고유 값 수이며, 필드에 저장된 총 예상 값 수가 아닙니다. 예를 들어 직원 회의 위치를 식별하는 암호화된 Room 필드를 고려하세요. Room 필드에는 총 100,000개의 값이 저장될 것으로 예상되지만 직원이 회의를 위해 예약할 수 있는 공간은 50개뿐입니다. 즉, Room 필드에 저장할 수 있는 고유 값은 50개뿐이므로 모집단은 50개입니다.

참고

표준 비컨이 가상 필드에서 구성된 경우 비컨 길이를 계산하는 데 사용되는 인구는 가상 필드에서 생성된 고유 조합의 수입니다.

모집단을 추정할 때 데이터 세트의 예상 증가를 고려해야 합니다. 비컨으로 새 레코드를 작성한 후에는 비컨 길이를 업데이트할 수 없습니다. 위협 모델과 기존 데이터베이스 솔루션을 검토하여 향후 5년 동안 이 필드에 저장할 것으로 예상되는 고유 값의 수에 대한 추정치를 생성합니다.

모집단은 정확할 필요는 없습니다. 먼저, 현재 데이터베이스의 고유 값 수를 식별하거나 첫 해에 저장할 것으로 예상되는 고유 값 수를 추정합니다. 다음으로, 다음 질문을 사용하여 향후 5년 동안 고유한 가치의 예상 성장을 결정하는 데 도움을 받으세요.

  • 고유한 값에 10이 곱해질 것이라고 예상하시나요?

  • 고유한 값에 100이 곱해질 것이라고 예상하시나요?

  • 고유한 값에 1000이 곱해질 것이라고 예상하시나요?

50,000개와 60,000개의 고유 값 사이의 차이는 중요하지 않으며 둘 다 동일한 권장 비컨 길이가 됩니다. 그러나 50,000과 500,000의 고유 값 사이의 차이는 권장 비컨 길이에 큰 영향을 미칩니다.

우편번호나 성 등 일반적인 데이터 유형의 빈도에 대한 공개 데이터를 검토하는 것이 좋습니다. 예를 들어, 미국에는 41,707개의 우편번호가 있습니다. 사용하는 모집단은 자신의 데이터베이스에 비례해야 합니다. 데이터베이스의 ZIPCode 필드에 미국 전역의 데이터가 포함되어 있는 경우 ZIPCode 필드에 현재 41,707개의 고유 값이 없더라도 모집단을 41,707로 정의할 수 있습니다. 데이터베이스의 ZIPCode 필드에 단일 주의 데이터만 포함되고 향후에도 단일 주의 데이터만을 포함하는 경우 모집단을 41,704가 아닌 해당 주의 총 우편 번호 수로 정의할 수 있습니다.

모집단 크기에서 비컨 길이 계산

데이터가 각 파티션 내에 거의 균일하게 분산되고 상관관계가 있는 값이 포함되지 않은 경우 간단한 모집단 기반 공식을 사용하여 적절한 비컨 길이를 추정할 수 있습니다.

p를 비컨의 모집단 크기, 즉 비컨이 단일 파티션 내에서 구성되는 고유한 일반 텍스트 값의 수로 가정합니다. 비컨 길이 b(비트)의 일반적인 시작점은 다음과 같습니다.

b = log₂(p) − 1

이 공식은 거짓 긍정 수를 관리할 수 있도록 유지하면서 충돌 가능성을 무시할 수 없는 수준으로 유지합니다. 로그에서 1비트를 빼면 여러 개의 고유 값이 동일한 비컨에 매핑될 것으로 예상되므로 주파수 누출을 제한하고 익명성을 지원하는 데 도움이 됩니다.

이 계산은 데이터 세트 전체의 평균 충돌 동작에 대한 추정치를 제공합니다. 모든 값이 동일한 수의 거짓 긍정을 생성한다고 보장하지 않으며 왜곡된 분포, 상관관계가 있는 값 또는 적대적 데이터 패턴을 고려하지도 않습니다.

엄격한 요구 사항이 아닌이 공식을 초기 지침으로 사용합니다. 항상 위협 모델, 성능 기대치 및 관찰된 데이터 특성에 대해 결과 구성을 검증하고 필요에 따라 비컨 길이 또는 파티션 수를 조정합니다.

비컨 길이에 대한 고급 주제

고급 사용자는 솔루션에 적합한 비컨 길이를 선택할 때 유연성이 향상됩니다. 쿼리 성능에 대한 불필요한 영향을 최소화하면서 데이터의 기밀성을 적절하게 보호하는 길이를 선택해야 합니다. 비컨에 의해 유지되는 보안 수준은 데이터 세트의 분포와 비컨이 구성된 필드의 상관 관계에 따라 달라집니다.

  • 비컨 길이가 너무 길면 오탐이 너무 적어 데이터 세트 분포에 대한 구별 정보가 공개될 수 있습니다.

  • 비컨 길이가 너무 짧으면 오탐지가 너무 많아지고 데이터베이스를 더 광범위하게 스캔해야 하므로 쿼리의 성능 비용이 증가합니다.

데이터 세트가 거의 균일하게 분산된 경우 다음 방정식과 절차를 사용하여 구현에 적합한 비컨 길이를 추정할 수 있습니다. 이러한 방정식은 비컨이 생성할 수 있는 평균 오탐 수의 추정치를 제공하지만 데이터 세트의 모든 고유 값에 대해 특정 수의 오탐을 보장하지는 않습니다. 다음 주제에서는 비컨이 균일하게 분포되어 있고 상관된 데이터를 포함하지 않는다고 가정합니다.

  1. 예상 충돌 횟수에 대한 권장 범위 계산

    특정 필드에 대한 적절한 비컨 길이를 결정하려면 먼저 예상되는 충돌 횟수에 대한 적절한 범위를 식별해야 합니다. 예상 충돌 수는 특정 HMAC 태그에 매핑되는 고유 일반 텍스트 값의 평균 예상 수를 나타냅니다. 하나의 고유한 일반 텍스트 값에 대해 예상되는 오탐 수는 예상되는 충돌 수보다 1이 적습니다.

    예상되는 충돌 횟수는 2보다 크거나 같고 인구의 제곱근보다 작은 것이 좋습니다. 다음 방정식은 모집단에 16개 이상의 고유 값이 있는 경우에만 작동합니다.

    2 ≤ number of collisions < √(Population)

    충돌 횟수가 2회 미만이면 비컨은 너무 적은 양의 오탐을 생성합니다. 평균적으로 필드의 모든 고유 값이 하나의 다른 고유 값에 매핑되어 최소한 하나의 오탐을 생성한다는 의미이므로 예상되는 최소 충돌 수로 2를 권장합니다.

  2. 비컨 길이에 대한 권장 범위 계산

    예상되는 충돌의 최소 및 최대 횟수를 식별한 후 다음 방정식을 사용하여 적절한 비컨 길이의 범위를 식별합니다.

    number of collisions = Population * 2-(beacon length)

    먼저, 예상 충돌 횟수가 2(예상 충돌의 최소 권장 횟수)인 비컨 길이를 구합니다.

    2 = Population * 2-(beacon length)

    그런 다음 예상되는 충돌 횟수가 모집단의 제곱근(예상되는 최대 권장 충돌 횟수)과 동일한 비컨 길이를 구합니다.

    √(Population) = Population * 2-(beacon length)

    이 방정식으로 생성된 출력을 더 짧은 비컨 길이로 반내림하는 것이 좋습니다. 예를 들어 방정식이 15.6의 비컨 길이를 생성하는 경우 해당 값을 16비트로 반올림하는 대신 15비트로 반내림하는 것이 좋습니다.

  3. 비컨 길이 선택

    이 방정식은 해당 분야에 권장되는 비컨 길이 범위만 식별합니다. 가능하면 데이터 세트의 보안을 유지하기 위해 더 짧은 비컨 길이를 사용하는 것이 좋습니다. 그러나 실제로 사용하는 비컨 길이는 위협 모델에 따라 결정됩니다. 해당 분야에 가장 적합한 비컨 길이를 결정하기 위해 위협 모델을 검토할 때 성능 요구 사항을 고려하세요.

    더 짧은 비컨 길이를 사용하면 쿼리 성능이 저하되고, 더 긴 비컨 길이를 사용하면 보안이 저하됩니다. 일반적으로 데이터 세트가 고르지 않게 분포되어 있거나 상관된 필드에서 별도의 비컨을 구성하는 경우 더 짧은 비컨 길이를 사용하여 데이터 세트 분포에 대해 공개되는 정보의 양을 최소화해야 합니다.

    위협 모델을 검토하고 필드 분포에 대해 밝혀진 구별 정보가 전체 보안에 위협이 되지 않는다고 판단하는 경우 계산한 권장 범위보다 긴 비컨 길이를 사용하도록 선택할 수 있습니다. 예를 들어, 필드에 대한 권장 비컨 길이 범위를 9~16비트로 계산한 경우 성능 손실을 방지하기 위해 24비트의 비컨 길이를 사용하도록 선택할 수 있습니다.

    비컨 길이를 신중하게 선택하세요. 비컨으로 새 레코드를 작성한 후에는 비컨 길이를 업데이트할 수 없습니다.

고급 비컨 길이 예제

unit 필드를 암호화 작업ENCRYPT_AND_SIGN로 표시한 데이터베이스를 고려하세요. unit 필드에 대한 표준 비컨을 구성하려면 unit 필드에 대한 예상 오탐 수와 비컨 길이를 결정해야 합니다.

  1. 모집단 추정

    위협 모델과 현재 데이터베이스 솔루션을 검토한 결과 unit 필드는 결국 100,000개의 고유 값을 갖게 될 것으로 예상됩니다.

    이는 모집단 = 100,000을 의미합니다.

  2. 예상 충돌 횟수에 대한 권장 범위 계산.

    이 예제에서 예상되는 충돌 횟수는 2~316 사이여야 합니다.

    2 ≤ number of collisions < √(Population)
    1. 2 ≤ number of collisions < √(100,000)
    2. 2 ≤ number of collisions < 316
  3. 비컨 길이에 대한 권장 범위를 계산합니다.

    이 예제에서 비컨 길이는 9~16비트 사이여야 합니다.

    number of collisions = Population * 2-(beacon length)
    1. 예상되는 충돌 횟수가 2단계에서 식별된 최소 횟수와 동일한 비컨 길이를 계산합니다.

      2 = 100,000 * 2-(beacon length)

      비컨 길이 = 15.6 또는 15비트

    2. 예상되는 충돌 횟수가 2단계에서 식별된 최대 횟수와 동일한 비컨 길이를 계산합니다.

      316 = 100,000 * 2-(beacon length)

      비컨 길이 = 8.3 또는 8비트

  4. 보안 및 성능 요구 사항에 적합한 비컨 길이를 결정합니다.

    15개 미만의 비트마다 성능 비용과 보안이 두 배로 늘어납니다.

    • 16비트

      • 평균적으로 각 고유 값은 1.5개의 다른 단위에 매핑됩니다.

      • 보안: 잘린 HMAC 태그가 동일한 두 레코드는 동일한 일반 텍스트 값을 가질 가능성이 66%입니다.

      • 성능: 쿼리는 실제로 요청한 레코드 10개마다 레코드 15개를 검색합니다.

    • 14비트

      • 평균적으로 각 고유 값은 6.1개의 다른 단위에 매핑됩니다.

      • 보안: 잘린 HMAC 태그가 동일한 두 레코드는 동일한 일반 텍스트 값을 가질 가능성이 33%입니다.

      • 성능: 쿼리는 실제로 요청한 레코드 30개마다 레코드 10개를 검색합니다.