검색 가능한 암호화

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

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

참고

AWS Database Encryption SDK의 검색 가능한 암호화는 검색 가능한 대칭 암호화와 같이 학술 연구에 정의된 검색 가능한 대칭 암호화와는 다릅니다.

비컨은 필드의 일반 텍스트와 암호화된 값 사이에 맵을 생성하는 잘린 해시 기반 메시지 인증 코드(HMAC) 태그입니다. 검색 가능한 암호화를 위해 구성된 암호화된 필드에 새 값을 쓰면 AWS Database Encryption SDK는 일반 텍스트 값에 대해 HMAC를 계산합니다. 이 HMAC 출력은 해당 필드의 일반 텍스트 값과 일대일(1:1) 일치합니다. 여러 개의 고유한 일반 텍스트 값이 잘린 동일한 HMAC 태그에 매핑되도록 HMAC 출력이 잘립니다. 이러한 오탐은 일반 텍스트 값에 대한 구별 정보를 식별하는 권한이 없는 사용자의 능력을 제한합니다. 비컨을 쿼리하면 AWS Database Encryption SDK는 이러한 오탐을 자동으로 필터링하고 쿼리의 일반 텍스트 결과를 반환합니다.

각 비컨에 대해 생성된 평균 오탐 수는 잘린 후 남은 비컨 길이에 따라 결정됩니다. 구현에 적합한 비컨 길이를 결정하는 데 도움이 필요하면 비컨 길이 결정을 참조하세요.

참고

검색 가능한 암호화는 채워지지 않은 새 데이터베이스에 구현되도록 설계되었습니다. 기존 데이터베이스에 구성된 모든 비컨은 데이터베이스에 업로드된 새 레코드만 매핑하며, 비컨이 기존 데이터를 매핑할 방법은 없습니다.

주제

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

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

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

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

비컨은 비컨이 계산되는 암호화된 필드와 함께 저장됩니다. 즉, 인증되지 않은 사용자가 암호화된 필드의 일반 텍스트 값을 볼 수 없더라도 비컨에 대한 통계 분석을 수행하여 데이터 세트 분포에 대해 자세히 알아보고, 극단적인 경우에는 비컨이 매핑하는 일반 텍스트 값을 식별할 수 있습니다. 비컨을 구성하는 방식으로 이러한 위험을 완화할 수 있습니다. 특히 올바른 비컨 길이를 선택하면 데이터 세트의 기밀을 유지하는 데 도움이 될 수 있습니다.

보안과 성능 비교

• 비컨 길이가 짧을수록 보안이 더 많이 보존됩니다.

• 비컨 길이가 길수록 성능이 더 많이 보존됩니다.

검색 가능한 암호화는 모든 데이터 세트에 대해 원하는 수준의 성능과 보안을 모두 제공하지 못할 수 있습니다. 비컨을 구성하기 전에 위협 모델, 보안 요구 사항 및 성능 요구 사항을 검토하세요.

검색 가능한 암호화가 데이터 세트에 적합한지 결정할 때 다음 데이터 세트 고유성 요구 사항을 고려하세요.

배포

비컨이 보존하는 보안 수준은 데이터 세트의 배포에 따라 달라집니다. 검색 가능한 암호화를 위해 암호화된 필드를 구성하면 AWS Database Encryption SDK는 해당 필드에 기록된 일반 텍스트 값에 대해 HMAC를 계산합니다. 주어진 필드에 대해 계산된 모든 비컨은 동일한 키를 사용하여 계산됩니다. 단, 각 테넌트에 대해 고유한 키를 사용하는 멀티테넌트 데이터베이스는 예외입니다. 즉, 동일한 일반 텍스트 값을 필드에 여러 번 기록하면 해당 일반 텍스트 값의 모든 인스턴스에 대해 동일한 HMAC 태그가 생성됩니다.

매우 일반적인 값을 포함하는 필드에서 비컨을 생성하지 않아야 합니다. 일리노이주의 모든 거주자의 주소를 저장하는 데이터베이스를 예로 들어 보겠습니다. 암호화된 City 필드를 기반으로 비컨을 구성하면 일리노이주 인구 중 시카고에 거주하는 인구가 많기 때문에 “시카고”를 기준으로 계산된 비컨이 과다 표시될 수 있습니다. 인증되지 않은 사용자는 암호화된 값과 비컨 값만 읽을 수 있더라도 비컨이 이 배포를 보존한다면 시카고 거주자에 대한 데이터가 들어 있는 레코드를 식별할 수 있을 것입니다. 배포에 대해 드러나는 식별 정보의 양을 최소화하려면 비컨을 충분히 잘라야 합니다. 이 고르지 않은 분포를 숨기는 데 필요한 비컨 길이로 인해 성능 비용이 많이 들기 때문에 애플리케이션의 요구 사항을 충족하지 못할 수 있습니다.

데이터 세트의 분포를 주의 깊게 분석하여 비컨을 잘라야 하는 정도를 결정해야 합니다. 잘린 후 남은 비컨 길이는 분포에 대해 식별할 수 있는 통계 정보의 양과 직접적인 상관 관계가 있습니다. 데이터 세트에 대해 드러나는 식별 정보의 양을 충분히 최소화하려면 더 짧은 비컨 길이를 선택해야 할 수도 있습니다.

성능과 보안의 균형을 효과적으로 유지하는 고르지 않게 분산된 데이터 집합의 비컨 길이를 계산할 수 없는 경우도 있습니다. 예를 들어, 희귀 질환에 대한 의료 검사 결과를 저장하는 필드에서 비컨을 구성해서는 안 됩니다. NEGATIVE 결과가 데이터셋 내에서 훨씬 더 널리 퍼질 것으로 예상되므로, POSITIVE 결과가 얼마나 희귀한지에 따라 결과를 쉽게 식별할 수 있습니다. 필드에 가능한 값이 두 개뿐인 경우 분포를 숨기기가 매우 어렵습니다. 분포를 숨길 만큼 짧은 비컨 길이를 사용하면 모든 일반 텍스트 값이 동일한 HMAC 태그에 매핑됩니다. 더 긴 비컨 길이를 사용하면 어떤 비컨이 일반 텍스트 POSITIVE 값에 매핑되는지 명확히 알 수 있습니다.

상관 관계

상관 관계가 있는 값을 포함한 필드에서 별개의 비컨을 생성하지 않는 것이 좋습니다. 상관 관계가 있는 필드로 구성된 비컨은 각 데이터 세트가 인증되지 않은 사용자에게 배포되는 과정에서 노출되는 정보의 양을 충분히 최소화하기 위해 비컨 길이를 줄여야 합니다. 엔트로피와 상관 관계가 있는 값의 공동 분포 등 데이터 세트를 주의 깊게 분석하여 비컨을 얼마나 잘라야 하는지 결정해야 합니다. 결과 비컨 길이가 성능 요구 사항을 충족하지 못하면 비컨이 데이터 세트에 적합하지 않을 수 있습니다.

예를 들어 우편번호가 한 도시에만 연결될 가능성이 높으므로 City 및 ZIPCode 필드로 분리된 두 개의 비컨을 만들면 안 됩니다. 일반적으로 비컨에서 생성되는 오탐은 승인되지 않은 사용자가 데이터세트에 대한 식별 가능한 정보를 식별하는 능력을 제한합니다. 그러나 City 및 ZIPCode 필드 사이의 상관 관계를 통해 권한이 없는 사용자도 어떤 결과가 오탐인지 쉽게 식별하고 서로 다른 우편 번호를 구별할 수 있습니다.

또한 동일한 일반 텍스트 값을 포함하는 필드에서 비컨을 구성하지 않아야 합니다. 예를 들어, 두 개의 필드는 동일한 값을 가질 가능성이 높으므로 mobilePhone 및 preferredPhone 필드에서 비컨을 생성해서는 안 됩니다. 두 필드에서 서로 다른 비컨을 생성하는 경우 AWS Database Encryption SDK는 각 필드에 대해 서로 다른 키 아래에 비컨을 생성합니다. 그 결과 동일한 일반 텍스트 값에 대해 서로 다른 두 개의 HMAC 태그가 생성됩니다. 서로 다른 두 개의 비컨은 동일한 오탐을 가질 가능성이 낮으며, 인증되지 않은 사용자가 서로 다른 전화번호를 구별할 수도 있습니다.

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

비컨을 구성하는 필드의 분포를 신중하게 고려하고 보안 요구 사항을 충족하기 위해 비컨 길이를 얼마나 줄여야 하는지 생각해야 합니다. 이 장의 다음 주제에서는 비컨이 균일하게 분산되어 있으며 상관 관계가 있는 데이터를 포함하지 않는다고 가정합니다.

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

다음의 예제는 간단한 검색 가능한 암호화 솔루션을 보여줍니다. 애플리케이션에서 이 예제에 사용된 예제 필드는 비컨에 대한 배포 및 상관 관계 고유성 권장 사항을 충족하지 않을 수 있습니다. 이 장의 검색 가능한 암호화 개념에 대해 읽을 때 이 예제를 참조용으로 사용할 수 있습니다.

회사의 직원 데이터를 추적하는 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 필드에서 동등 검색을 수행할 수 있습니다. 예를 들어, Jones에 대해 검색하려는 경우 LastName 비컨을 사용하여 다음 쿼리를 수행합니다.

LastName = Jones

AWS Database Encryption SDK는 오탐을 자동으로 필터링하고 쿼리의 일반 텍스트 결과를 반환합니다.