Microsoft Cloud for Sovereignty에서 고객 관리형 키를 사용한 암호화

  • 아티클

Microsoft Cloud for Sovereignty를 구현하려는 고객은 데이터 주권 요구 사항을 충족하기 위해 데이터 암호화 기능을 사용해야 할 수 있습니다. 엄격한 데이터 주권 요구 사항이 있는 고객은 클라우드에서 키 관리를 구현하기 위한 계획을 개발해야 합니다. 이 문서에서는 클라우드 설계자, 암호화 시스템 소유자 및 기타 기술 의사 결정자가 Azure에서 플랫폼 수준 암호화를 구현하기 위한 계획을 개발하도록 안내합니다. 플랫폼 수준의 암호화 계획에는 일반적으로 키 관리 요구 사항 식별, 기술 선택, 사용할 Azure 서비스에 대한 디자인 및 구성 선택이 포함됩니다. 이 프로세스에는 다음 세 가지 영역에 걸쳐 기술적 결정을 내리는 것이 포함됩니다.

  • 키 관리 요구 사항 정의: 조직은 중요한 고객 데이터와 중요한 암호화 자료를 보호하기 위해 무엇을 해야 하는가?
  • 고객 데이터를 보호하기 위한 데이터 암호화 기능 선택: Azure에서 고객 데이터를 언제, 어디서, 어떻게 암호화해야 합니까?
  • 고객 키를 보호하기 위한 키 관리 솔루션 선택: Azure에서 고객 데이터를 암호화하는 데 사용되는 데이터 암호화 키를 보호하려면 어떤 키 저장소를 사용해야 하는가?

키 관리 요구 사항 정의

키 관리에 대한 요구 사항에는 사용되는 암호화 서비스에 대한 기술적 요구 사항과 성능, 보안 및 주권과 관련된 운영 요구 사항이 포함될 수 있습니다. Azure 워크로드에서 데이터를 암호화하는 시기와 방법을 결정하기 위해 권장되는 시작점은 조직의 데이터 분류 시스템입니다. 특정 시스템이나 솔루션이 아닌 데이터 분류에 따라 암호화 요구 사항을 조정함으로써 조직은 워크로드 마이그레이션 계획 중에 최적의 암호화 수준을 선택할 수 있는 유연성을 갖게 됩니다.

데이터 분류에 대한 암호화 요구 사항을 기반으로 하면 중요도가 낮은 워크로드는 더 간단한 솔루션을 활용하는 동시에 더 높은 수준의 고유 위험이 있는 워크로드에 대해 가장 복잡한 구성을 예약할 수 있는 계층형 접근 방식이 가능해집니다. 이 접근 방식의 예로는 Microsoft 관리형 키를 사용하여 개발 환경의 스토리지 계정을 암호화하는 동시에 프로덕션 스토리지 계정에서 고객 관리형 암호화 키를 사용하도록 요구하는 것입니다.

조직은 암호화 요구 사항이 데이터 분류와 어떤 관련이 있는지 명확하게 이해한 후 사용하려는 Azure 서비스에 대한 기능 선택 프로세스를 시작할 수 있습니다. 이러한 기능 중 일부는 유사한 온-프레미스 시스템과 다르게 작동할 수 있으므로 조직은 Azure에서 암호화가 작동하는 방식을 숙지하고 암호화 솔루션 설계에 대한 권장 사항 및 모범 사례를 검토하는 것이 좋습니다. 다음 문서는 고객이 선택해야 하는 일부 기술적 선택에 대한 추가 관점을 제공하며 조직의 클라우드 키 관리 목표에 대한 대화를 시작하는 데 유용한 출발점이 될 수 있습니다.

데이터 암호화 기능 선택

많은 Azure 서비스에서는 고객 상호 작용 없이 전적으로 Azure에서 생성, 저장 및 관리되는 키를 사용하여 암호화를 활성화합니다. 이러한 플랫폼 관리형 키는 운영 간접비가 거의 없이 조직이 암호화를 구현하는 데 도움이 될 수 있습니다. 그러나 엄격한 데이터 주권 요구 사항이 있는 고객은 특정 Azure 서비스에 저장된 중요한 데이터를 보호하기 위해 특정 플랫폼 암호화 기능을 선택해야 할 수도 있습니다.

매우 중요한 데이터의 경우 일반적으로 사용되는 많은 Azure 서비스를 통해 고객은 CMK(고객 관리형 키)를 사용하여 이중 암호화를 구현할 수 있습니다. Azure 서비스에서 고객 관리형 키를 구현하면 고객이 해당 서비스에 저장된 데이터를 무단 액세스로부터 보호하는 데 도움이 될 수 있습니다.

Azure에서 고객 관리형 키를 구현하면 워크로드의 비용과 복잡성이 증가할 수 있으므로 조직은 각 워크로드 및 데이터 분류 수준에 대해 이 기능의 필요성을 평가하는 것이 좋습니다. 필요한 워크로드 및 데이터 유형에 대해서만 고객 관리형 키를 구현하면 중요한 데이터를 처리하지 않는 워크로드에 대한 운영 간접비를 줄이는 데 도움이 될 수 있습니다.

고객 관리형 키가 필요한 경우 각 Azure 서비스에 대해 구성해야 합니다. 조직은 이러한 기능을 구현하기 위한 조직 전체의 표준과 반복 가능한 디자인 패턴을 설정하여 배포 또는 마이그레이션 계획 노력을 간소화하는 데 도움을 줄 수 있습니다. 다음 문서에서는 Azure에서 미사용 데이터 암호화를 구성하는 방법에 대한 자세한 정보를 제공합니다.

고객 관리형 키를 사용하여 미사용 데이터를 암호화하기 위해 일반적으로 사용되는 Azure 서비스를 구성하는 방법을 알아보세요.

키 관리 솔루션 선택

고객 관리형 키를 사용한 이중 암호화와 같은 기능은 Azure 서비스에서 유지 관리되는 고객 데이터를 보호하는 데 도움이 될 수 있지만, 클라우드 기반 키 관리 솔루션은 중요한 데이터를 암호화하는 데 사용되는 암호화 키 및 기타 암호화 자료를 보호하는 데 도움이 됩니다. 엄격한 데이터 주권 요구 사항이 있는 고객은 보증 요구 사항과 워크로드의 위험 프로필을 기반으로 적합한 키 관리 솔루션을 선택해야 합니다.

중요한 데이터를 처리하는 워크로드는 저장된 암호화 자료를 보호하기 위한 추가 보안 제어 기능을 갖춘 FIPS-140-2 Level-3 검증 하드웨어 보안 모듈을 포함하여 Azure 관리형 HSM과 같은 솔루션이 제공하는 추가 보증의 이점을 누릴 수 있습니다.

다음 문서에서는 고객이 식별된 시나리오에 적합한 키 저장소를 선택하는 데 사용할 수 있는 지침을 제공합니다. 또한 고객이 암호화 솔루션의 일부로 사용하는 암호화 서비스를 Microsoft가 관리하는 방법에 대한 정보도 제공합니다.

키 관리를 위한 운영 모델

Azure Key Vault는 Azure Key Vault의 표준/프리미엄 계층을 사용하는지 아니면 Azure Key Vault 관리형 HSM을 사용하는지에 따라 다양한 방식으로 역할 기반 액세스 제어를 구현합니다. 액세스 제어의 이러한 차이는 조직이 이러한 기능을 사용하는 방식에 영향을 미칠 수 있습니다. 이 섹션에서는 이러한 차이점과 조직이 클라우드 키 관리를 위한 운영 프로세스를 설계하는 방식에 어떤 영향을 미칠 수 있는지에 대해 설명합니다.

FIPS-140 레벨 3 유효성 검사에 대한 규정 준수 제약 조건

FIPS-140 레벨 3 유효성 검사에는 ID 기반 운영자 식별이 필요합니다. 이러한 보호 장치는 Azure에서 Key Vault 서비스를 지원하는 기본 HSM 하드웨어에 배포되고 검증됩니다. 결과적으로 Azure Key Vault의 RBAC 기능은 기본 하드웨어의 RBAC 기능에 의존합니다.

Azure Key Vault 관리형 HSM은 하드웨어 수준에서 구현되는 로컬 RBAC 할당을 활용하고 보안 도메인 범위(예: HSM 전체)에서 또는 키별로 역할 할당을 허용합니다. 즉, 아직 존재하지 않는 키에는 권한을 할당할 수 없으므로 키를 생성하려면 전체 보안 도메인에 대한 관리 권한이 필요합니다. 이 설계의 영향은 mHSM 인스턴스에 키를 저장해야 하는 사람은 누구나 해당 보안 도메인에 저장된 모든 키에 대한 전체 권한을 가지고 있거나 보안 도메인에 대해 필요한 권한이 있는 중앙 집중식 팀에 키를 요청해야 한다는 것입니다. 이는 각 애플리케이션에 대해 별도의 키 자격 증명 모음 생성을 권장하는 Azure Key Vault 지침이 바뀌었음을 나타냅니다.

Azure Key Vault 관리형 HSM의 키 관리 작업

키 관리를 위한 운영 프로세스를 개발하려면 고객은 솔루션 아키텍처의 일부로 Azure Key Vault 관리형 HSM이 필요한지 결정해야 합니다. 관리형 HSM을 사용하려는 조직은 먼저 관리 및 암호화 작업에 사용되는 액세스 제어 모델을 숙지하고 역할 기반 액세스 제어가 할당되는 방식을 이해해야 합니다.

관리형 HSM의 액세스 제어에 대해 자세히 알아보세요.

Azure Key Vault HSM을 사용하려는 조직은 기본 제공 RBAC 역할 목록과 관리형 HSM에 대해 허용되는 작업 목록을 검토하고 특히 다음 작업 시나리오를 해결하기 위한 계획을 세워야 합니다.

  • 관리형 HSM에서 새 키 생성
  • 키 업데이트 또는 키 순환과 같은 컨트롤 플레인을 사용하는 기존 키의 관리 작업
  • 애플리케이션 또는 서비스에서 기존 키의 데이터 플레인 사용

현재 새 키를 생성하기 위한 권한을 할당하는 유일한 방법은 키 순환 및 삭제와 같은 다른 권한도 포함하는 Crypto User와 같은 역할을 할당하는 것입니다. 결과적으로 애플리케이션 팀 구성원에게 관리형 HSM에서 자체 키를 생성하는 데 필요한 권한을 부여하면 해당 사용자가 HSM의 모든 키에 대한 관리 권한도 가지게 되므로 최소 권한 원칙을 위반할 가능성이 높습니다. 이 문제는 키 생성 요청을 용이하게 할 수 있는 높은 권한을 갖춘 중앙 집중식 팀을 도입하거나 관리형 HSM REST API를 활용하는 IT 서비스 관리 프로세스를 통해 새로운 키 생성 요청을 용이하게 할 수 있는 자동화를 도입함으로써 해결될 수 있습니다.

관련 콘텐츠