큐에 대한 클라이언트 쪽 암호화
.NET 및 Python용 Azure Queue Storage 클라이언트 라이브러리는 Azure Storage에 업로드하기 전에 클라이언트 애플리케이션 내에서 데이터를 암호화하고, 클라이언트에 다운로드하는 동안 데이터의 암호를 해독하도록 지원합니다. 또한 클라이언트 라이브러리는 스토리지 계정 키 관리를 위해 Azure Key Vault와의 통합을 지원합니다.
Important
Azure Storage는 서비스 쪽 암호화 및 클라이언트 쪽 암호화를 모두 지원합니다. 대부분의 시나리오에서 데이터를 쉽게 보호할 수 있도록 서비스 쪽 암호화 기능을 사용하는 것이 좋습니다. 서비스 쪽 암호화에 대한 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
클라이언트 쪽 암호화 정보
Azure Queue Storage 클라이언트 라이브러리는 사용자 데이터를 암호화하기 위해 AES를 사용합니다. 클라이언트 라이브러리에서 사용할 수 있는 클라이언트 쪽 암호화에는 두 가지 버전이 있습니다.
- 버전 2는 AES에서 GCM(Galois/Counter Mode) 모드를 사용합니다.
- 버전 1은 AES에서 CBC(암호화 블록 체인) 모드를 사용합니다.
Warning
클라이언트 라이브러리의 CBC 모드 구현에 있는 보안 취약성으로 인해 클라이언트 쪽 암호화 버전 1을 더 이상 사용하지 않는 것이 좋습니다. 이 보안 취약성에 대한 자세한 내용은 보안 취약성을 해결하기 위해 SDK에서 클라이언트 쪽 암호화를 업데이트하는 Azure Storage를 참조하세요. 현재 버전 1을 사용하는 경우 버전 2를 사용하도록 애플리케이션을 업데이트하고 데이터를 마이그레이션하는 것이 좋습니다. 추가 지침은 애플리케이션의 보안 취약성 완화 섹션을 참조하세요.
애플리케이션의 보안 취약성 완화
Queue Storage 클라이언트 라이브러리의 CBC 모드 구현에서 검색된 보안 취약성으로 인해 다음 작업 중 하나 이상을 즉시 수행하는 것이 좋습니다.
클라이언트 쪽 암호화 대신 서비스 쪽 암호화 기능을 사용하는 것이 좋습니다. 서비스 쪽 암호화 기능에 대한 자세한 내용은 미사용 데이터에 대한 Azure Storage 암호화를 참조하세요.
클라이언트 쪽 암호화를 사용해야 하는 경우 애플리케이션을 클라이언트 쪽 암호화 v1에서 클라이언트 쪽 암호화 v2로 마이그레이션합니다.
다음 표에서는 애플리케이션을 클라이언트 쪽 암호화 v2로 마이그레이션하도록 선택하는 경우 수행해야 하는 단계가 요약하고 있습니다.
| 클라이언트 쪽 암호화 상태 | 권장 조치 |
|---|---|
| 애플리케이션에서 클라이언트 쪽 암호화 v1만 지원하는 클라이언트 라이브러리 버전을 통해 클라이언트 쪽 암호화를 사용합니다. | 클라이언트 쪽 암호화 v2를 지원하는 클라이언트 라이브러리 버전을 사용하도록 애플리케이션을 업데이트합니다. 지원되는 버전 목록은 클라이언트 쪽 암호화에 대한 SDK 지원 매트릭스를 참조하세요. 클라이언트 쪽 암호화 v2를 사용하도록 코드를 업데이트합니다. |
| 애플리케이션에서 클라이언트 쪽 암호화 v2를 지원하는 클라이언트 라이브러리 버전을 통해 클라이언트 쪽 암호화를 사용합니다. | 클라이언트 쪽 암호화 v2를 사용하도록 코드를 업데이트합니다. |
또한 데이터를 보호하기 위해 다음 단계를 수행하는 것이 좋습니다.
- 프라이빗 엔드포인트를 사용하도록 스토리지 계정을 구성하여 프라이빗 링크를 통해 VNet(가상 네트워크)과 스토리지 계정 간의 모든 트래픽을 보호합니다. 자세한 내용은 Azure Storage에 프라이빗 엔드포인트 사용을 참조하세요.
- 네트워크 액세스를 특정 네트워크로만 제한합니다.
클라이언트 쪽 암호화에 대한 SDK 지원 매트릭스
다음 표에서는 .NET 및 Python용 클라이언트 라이브러리 버전에서 지원하는 클라이언트 쪽 암호화 버전을 보여 줍니다.
| .NET | Python | |
|---|---|---|
| 클라이언트 쪽 암호화 v2 및 v1 | 버전 12.11.0 이상 | 버전 12.4.0 이상 |
| 클라이언트 쪽 암호화 v1만 | 버전 12.10.0 이하 | 버전 12.3.0 이하 |
애플리케이션에서 이전 버전의 .NET 또는 Python 클라이언트 라이브러리를 통해 클라이언트 쪽 암호화를 사용하는 경우 먼저 코드를 클라이언트 쪽 암호화 v2를 지원하는 버전으로 업그레이드해야 합니다. 다음으로 클라이언트 쪽 암호화 v2를 사용하여 데이터의 암호를 해독하고 다시 암호화해야 합니다. 필요한 경우 코드를 마이그레이션하는 동안 이전 버전의 클라이언트 라이브러리를 통해 클라이언트 쪽 암호화 v2를 지원하는 클라이언트 라이브러리 버전을 사용할 수 있습니다.
클라이언트 쪽 암호화의 작동 방식
Azure Queue Storage 클라이언트 라이브러리는 봉투 암호화를 사용하여 클라이언트 쪽의 데이터를 암호화하고 암호 해독합니다. 봉투 암호화는 하나 이상의 추가 키를 사용하여 키를 암호화합니다.
Queue Storage 클라이언트 라이브러리는 Azure Key Vault를 사용하여 클라이언트 쪽 암호화에 사용되는 키를 보호합니다. Azure Key Vault에 대한 자세한 내용은 Azure Key Vault란?을 참조하세요.
봉투(Envelope) 기술을 통해 암호화 및 암호 해독
봉투 기술을 통한 암호화의 작동 방식은 다음과 같습니다.
Azure Storage 클라이언트 라이브러리에서 일회용 대칭 키인 CEK(콘텐츠 암호화 키)를 생성합니다.
사용자 데이터가 CEK를 사용하여 암호화됩니다.
그런 다음 키 암호화 KEK를 사용하여 CEK를 래핑(암호화)합니다. KEK는 키 식별자로 식별되고 비대칭 키 쌍 또는 대칭 키가 될 수 있습니다. KEK는 로컬로 관리하거나 Azure Key Vault에 저장할 수 있습니다.
Azure Storage 클라이언트 라이브러리 자체는 KEK에 액세스할 수 없습니다. 라이브러리는 자격 증명 모음에서 제공되는 키 래핑 알고리즘을 호출합니다. 사용자는 원하는 경우 키 래핑/래핑 해제를 위해 사용자 지정 공급자를 사용하도록 선택할 수 있습니다.
그런 다음, 암호화된 데이터가 Azure Queue Storage에 업로드됩니다. 일부 추가 암호화 메타데이터와 함께 래핑된 키는 암호화된 데이터로 보간됩니다.
봉투 기술을 통한 암호 해독의 작동 방식은 다음과 같습니다.
- Azure Storage 클라이언트 라이브러리에서 사용자가 KEK를 로컬로 또는 Azure Key Vault에서 관리한다고 가정합니다. 사용자는 암호화에 사용된 특정 키를 알 필요가 없습니다. 대신 다른 키 식별자를 키로 확인하는 키 확인자를 설정하여 사용할 수 있습니다.
- 클라이언트 라이브러리에서 Azure Storage에 저장된 암호화 자료와 함께 암호화된 데이터를 다운로드합니다.
- 그런 다음, 래핑된 CEK가 KEK를 사용하여 래핑 해제(암호 해독)됩니다. 클라이언트 라이브러리는 이 프로세스 중에 KEK에 액세스할 수 없지만 Azure Key Vault 또는 다른 키 저장소의 래핑 해제 알고리즘만 호출합니다.
- 클라이언트 라이브러리에서 CEK를 사용하여 암호화된 사용자 데이터의 암호를 해독합니다.
메시지 암호화/암호 해독
큐 메시지의 모든 형식이 될 수, 있으므로 클라이언트 라이브러리는 IV (Initialization Vector) 및 암호화 된 콘텐츠 암호화 키 (CEK) 메시지 텍스트에 포함 된 사용자 지정 형식을 정의 합니다.
암호화 하는 동안 클라이언트 라이브러리는 32 바이트의 임의 CEK 함께 16 바이트의 임의 IV를 생성하고 이 정보를 사용하여 큐 메시지 텍스트의 봉투 (envelope) 암호화를 수행 합니다. 래핑된 CEK 및 일부 추가 암호화 메타 데이터를 암호화 된 큐 메시지에 추가합니다. 이 수정된 메시지는 서비스에 저장됩니다.
<MessageText>{"EncryptedMessageContents":"6kOu8Rq1C3+M1QO4alKLmWthWXSmHV3mEfxBAgP9QGTU++MKn2uPq3t2UjF1DO6w","EncryptionData":{…}}</MessageText>
암호를 해독 하는 동안, 래핑된 키는 큐 메시지에서 추출되고 래핑이 해제됩니다. IV 또한 큐메시지에서 추출되고 큐 메시지 데이터를 암호해독하기 위해 래핑해제된 키와 함께 사용 됩니다. 암호화 메타데이터는 작으므로(500바이트 미만) 큐 메시지에 대한 64KB 제한에 포함되지만 효과는 관리할 수 있습니다. 암호화된 메시지는 위의 코드 조각과 같이 Base64로 인코딩됩니다. 이 경우 보내는 메시지의 크기도 확장됩니다.
큐에 있는 메시지의 수명이 짧으므로 클라이언트 쪽 암호화 v2로 업데이트한 후 큐 메시지를 암호 해독하고 다시 암호화할 필요가 없습니다. 보안 수준이 낮은 메시지는 일반적인 큐 사용 과정에서 회전됩니다.
클라이언트 쪽 암호화 및 성능
스토리지 데이터를 암호화하면 추가 성능 오버헤드가 발생합니다. 애플리케이션에서 클라이언트 쪽 암호화를 사용하는 경우 클라이언트 라이브러리에서 CEK 및 IV를 안전하게 생성하고, 콘텐츠 자체를 암호화하고, 키 봉투를 위해 선택한 키 저장소와 통신하고, 추가 메타데이터의 형식을 지정하고 업로드해야 합니다. 이 오버헤드는 암호화되는 데이터의 양에 따라 달라집니다. 고객은 항상 개발 중에 애플리케이션 성능을 테스트하는 것이 좋습니다.