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

검색 가능한 암호화

검색 가능한 암호화를 사용하면 전체 데이터베이스를 복호화하지 않고도 암호화된 레코드를 검색할 수 있습니다. 이는 필드에 기록된 일반 텍스트 값과 데이터베이스에 실제로 저장된 암호화된 값 사이의 맵을 생성하는 비컨을 사용하여 수행됩니다. AWS Database Encryption SDK는 레코드에 추가하는 새 필드에 비컨을 저장합니다. 사용하는 비컨의 유형에 따라 암호화된 데이터에 대해 정확히 일치하는 검색을 수행하거나 보다 맞춤화된 복합 쿼리를 수행할 수 있습니다.

비컨은 일반 텍스트 필드 값을 암호화되고 검색 가능한 식별자에 매핑하는 잘린 해시 기반 메시지 인증 코드(HMAC) 태그입니다. 검색 가능한 암호화를 위해 구성된 암호화된 필드에 값을 쓰면 AWS Database Encryption SDK는 일반 텍스트 값을 통해 HMAC를 계산합니다. 이 HMAC 출력은 해당 필드의 일반 텍스트 값과 일대일(1:1) 일치합니다. SDK는 HMAC 출력을 의도적으로 잘라내어 여러 개의 고유한 일반 텍스트 값이 동일한 비컨에서 충돌하도록 합니다. 이러한 충돌(거짓 긍정)은 권한이 없는 사용자가 빈도 패턴에서 민감한 정보를 유추할 수 있는 능력을 제한합니다. 비컨을 쿼리하면 AWS Database Encryption SDK가 이러한 오탐을 자동으로 필터링하고 쿼리의 일반 텍스트 결과를 반환합니다. 이러한 주파수 누출 문제를 추가로 해결하기 위해 비컨이 분할되어 동일한 일반 텍스트 값이 파티션 간에 서로 다른 비컨 값을 생성할 수 있습니다. 테이블이 단일 파티션만 사용하는 경우이 동작은 파티션이 없는 기존 비컨과 자연스럽게 일치합니다.

각 비컨의 평균 오탐 수는 잘린 후 남은 비컨 길이와 파티션 수에 따라 달라집니다. 구현에 적합한 비컨 길이를 결정하는 데 도움이 필요하면 비컨 길이 결정을 참조하세요.

비컨이 내 데이터 세트에 적합한가?

비컨을 사용하여 암호화된 데이터에 대한 쿼리를 수행하면 클라이언트측 암호화된 데이터베이스와 관련된 성능 비용을 줄일 수 있습니다. 비컨을 사용할 때 쿼리의 효율성과 데이터 분포에 대해 공개되는 정보의 양 사이에는 본질적인 균형이 있습니다. 비컨은 필드의 암호화된 상태를 변경하지 않습니다. AWS Database Encryption SDK로 필드를 암호화하고 서명하면 필드의 일반 텍스트 값이 데이터베이스에 노출되지 않습니다. 데이터베이스는 필드의 무작위화되고 암호화된 값을 저장합니다.

비컨은 계산된 암호화된 필드와 함께 저장됩니다. 즉, 인증되지 않은 사용자가 암호화된 필드의 일반 텍스트 값을 볼 수 없더라도 비컨에 대한 통계 분석을 수행하여 데이터 세트 분포에 대해 자세히 알아보고, 극단적인 경우에는 비컨이 매핑하는 일반 텍스트 값을 식별할 수 있습니다. 이러한 위험을 완화하려면 적절한 비컨 구성이 필수적입니다. 적절한 비컨 길이 및 파티셔닝 체계를 선택하면 단일 비컨의 값 농도를 제한하여 충분한 충돌을 보장하고 빈도 기반 공격을 완화하여 기밀성이 유지됩니다.

많은 실제 시나리오에서 잘 선택된 구성은 이러한 경쟁 목표의 균형을 맞출 수 있습니다. 그러나 검색 가능한 암호화는 모든 데이터 세트에 대해 원하는 수준의 보안 및 성능을 제공하지 못할 수 있습니다.

비컨을 구성하기 전에 위협 모델, 보안 요구 사항 및 성능 요구 사항을 주의 깊게 검토하고 데이터 세트의 고유성 특성을 고려하여 검색 가능한 암호화가 적절한 선택인지 확인합니다.

데이터 세트에 상관 관계가 있는 필드가 포함되어 있거나 분포가 고르지 않은 경우에도 비컨 길이를 줄이면 데이터 세트의 기밀성을 유지하는 비컨을 구성할 수 있습니다. 하지만 비컨 길이가 데이터 세트의 모든 고유한 값이 다수의 오탐을 생성하여 데이터 세트에 대해 드러나는 식별 정보의 양을 효과적으로 최소화할 수 있다는 보장은 없습니다. 비컨 길이는 생성된 오탐의 평균 횟수만 추정합니다. 데이터 세트가 고르지 않게 분산될수록 생성되는 평균 오탐 수를 결정할 수 있는 비컨 길이의 효율성이 떨어집니다.

비컨화하도록 선택한 필드의 분포를 신중하게 평가하고 보안 요구 사항을 충족하는 데 필요한 잘림 정도를 결정합니다. 이 장의 다음 주제에서는 각 파티션 내에서 비컨 값이 균일하게 분산되고 기본 데이터에서 이러한 가정을 약화시키는 상관관계가 발생하지 않는다고 가정합니다.

검색 가능한 암호화 시나리오

다음 예제에서는 검색 가능한 암호화 솔루션을 보여주고이 장에서 설명하는 핵심 개념을 보여줍니다. 이 시나리오에서는 특정 필드 값이 매우 자주 발생하므로 단일 파티션을 사용할 경우 동등성 클래스가 크고 빈도 누출이 증가합니다. 이를 해결하기 위해 구성은 여러 파티션을 사용하므로 빈도가 높은 값이 더 균등하게 분산되어 누출을 줄이는 동시에 효율적인 평등 검색을 수행할 수 있습니다.

회사의 직원 데이터를 추적하는 Employees이라는 데이터베이스를 예제로 들어 보겠습니다. 데이터베이스의 각 레코드에는 EmployeeID, LastName, FirstName, 및 Address라는 필드가 포함되어 있습니다. Employees 데이터베이스의 각 필드는 프라이머리 키 EmployeeID로 식별됩니다.

다음은 데이터베이스의 일반 텍스트 레코드의 예제입니다.

{
    "EmployeeID": 101,
    "LastName": "Jones",
    "FirstName": "Mary",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

LastName 및 FirstName 필드를 암호화 작업과 같이 ENCRYPT_AND_SIGN으로 표시한 경우 이러한 필드의 값은 데이터베이스에 업로드되기 전에 로컬로 암호화됩니다. 업로드되는 암호화된 데이터는 완전히 무작위화되며 데이터베이스는 이 데이터를 보호 대상으로 인식하지 않습니다. 일반적인 데이터 입력만 탐지합니다. 즉, 데이터베이스에 실제로 저장되는 레코드는 다음과 같이 보일 수 있습니다.

{
    "PersonID": 101,
    "LastName": "1d76e94a2063578637d51371b363c9682bad926cbd",
    "FirstName": "21d6d54b0aaabc411e9f9b34b6d53aa4ef3b0a35",
    "Address": {
                "Street": "123 Main",
                "City": "Anytown",
                "State": "OH",
                "ZIPCode": 12345
    }
}

데이터베이스에서 LastName 필드가 정확히 일치하는지 쿼리해야 하는 경우 LastName 필드에 기록된 일반 텍스트 값을 데이터베이스에 저장된 암호화된 값에 매핑하도록 LastName이라는 표준 비컨을 구성합니다.

이 비컨은 LastName 필드의 일반 텍스트 값을 기반으로 HMAC를 계산합니다. 각 HMAC 출력은 잘려서 더 이상 일반 텍스트 값과 정확히 일치하지 않습니다. 예를 들어, Jones에 대한 전체 해시와 잘린 해시는 다음과 같이 보일 수 있습니다.

전체 해시

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

잘린 해시

b35099d408c833

직원이 많은 데이터 세트에서는 존스, 스미스 또는 존슨과 같은 특정 성이 다른 성보다 훨씬 더 자주 발생할 수 있습니다. 빈도 누출을 줄이고 비컨 동등성 클래스의 크기를 제한하려면 둘 이상의 파티션을 사용하도록 LastName 비컨을 구성해야 합니다.

파티션이 활성화되면 각 항목이 쓰기 시 파티션에 할당되고 파티션 번호가 비컨 파생에 통합됩니다. 따라서 성이 같은 직원은 파티션 간에 서로 다른 비컨 값에 매핑될 수 있습니다. 이렇게 하면 여러 파티션에 이름이 매우 자주 분산되므로 단일 비컨 값의 과다 표현이 줄어듭니다.

표준 비컨을 구성한 후 LastName 필드에서 동등 검색을 수행할 수 있습니다. 예를 들어, Jones에 대해 검색하려는 경우 LastName 비컨을 사용하여 다음 쿼리를 수행합니다.

LastName = Jones

Jones와 같은 특정 고주파 성을 쿼리할 때 애플리케이션은 LastName 비컨을 사용하여 파티션당 하나의 쿼리를 실행해야 합니다. 그런 다음 AWS Database Encryption SDK는 결과를 해독하고 거짓 긍정을 자동으로 필터링하여 올바른 일반 텍스트 레코드를 반환합니다.