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

검색 가능한 암호화

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

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

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

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

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

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

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

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

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

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

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

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

회사의 직원 데이터를 추적하는 Employees이라는 데이터베이스를 예제로 들어 보겠습니다. 데이터베이스의 각 레코드에는 EmployeeID LastName, FirstName, 주소라는 필드가 있습니다. 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

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

전체 해시

2aa4e9b404c68182562b6ec761fcca5306de527826a69468885e59dc36d0c3f824bdd44cab45526f70a2a18322000264f5451acf75f9f817e2b35099d408c833

잘린 해시

b35099d408c833

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

LastName = Jones

AWS 데이터베이스 암호화는 오탐을 SDK 자동으로 필터링하고 쿼리의 일반 텍스트 결과를 반환합니다.