관리되는 HSM의 키 주권, 가용성, 성능, 확장성
암호화 키는 온-프레미스 또는 클라우드에서 최신 컴퓨터 시스템을 보호하기 위한 신뢰점입니다. 따라서 안전하고 규정을 준수하는 애플리케이션을 빌드할 때 이러한 키에 대한 권한이 있는 사용자를 제어하는 것이 중요합니다.
Azure에서 Microsoft가 클라우드의 키 관리 방법에 대해 제시하는 비전은 키 주권입니다. 키 주권이란 키에 액세스하고 키 관리 정책을 변경할 수 있는 사람과 이러한 키를 사용하는 Azure 서비스를 고객의 조직이 완전하게 그리고 배타적으로 제어한다는 뜻입니다. 고객이 이러한 결정을 내린 후에는 Microsoft 직원이 고객의 결정을 변경할 수 있는 기술적 수단이 없습니다. 키 관리 서비스 코드는 고객이 다른 지시를 내릴 때까지 고객의 결정을 실행하며, Microsoft 직원이 개입할 수 없습니다.
동시에 Microsoft는 클라우드의 모든 서비스가 완전 관리형 서비스여야 한다고 믿습니다. 서비스는 SLA(서비스 수준 계약)를 통해 지원되는 필수 가용성, 복원력, 보안 및 클라우드 기본 프라미스를 제공해야 합니다. 관리되는 서비스를 제공하려면 Microsoft는 키 관리 서버를 패치하고, HSM(하드웨어 보안 모듈) 펌웨어를 업그레이드하고, 오류가 발생한 하드웨어를 수리하고, 장애 조치(failover)를 수행하고, 기타 높은 권한 작업을 수행해야 합니다. 대부분의 보안 전문가가 알고 있듯이, 시스템에 대한 높은 액세스 권한을 갖고 있거나 시스템에 물리적으로 접근할 수 있는 사람이 시스템 내의 데이터에 액세스하는 것을 거부하는 것은 어려운 문제입니다.
이 문서에서는 Azure Key Vault 관리되는 HSM 서비스에서 이 문제를 해결하고, HSM과 쌍을 이루는 기밀 컴퓨팅 기술을 사용하여 고객에게 완전한 키 주권과 완전 관리형 서비스 SLA를 모두 제공하는 방법을 설명합니다.
관리되는 HSM 하드웨어 환경
모든 Azure 지역에 있는 고객의 관리되는 HSM 풀은 안전한 Azure 데이터 센터에 있습니다. 3개의 인스턴스가 여러 서버에 분산됩니다. 각 인스턴스는 중복성을 보장하기 위해 서로 다른 랙에 배포됩니다. 각 서버에는 FIPS 140-2 수준 3 유효성 검사를 마쳤으며 여러 암호화 코어를 포함하고 있는 Marvell LiquidSecurity HSM 어댑터가 있습니다. 이러한 코어는 완전히 격리된 자격 증명, 데이터 스토리지 및 액세스 제어를 포함하여 완전히 격리된 HSM 파티션을 만드는 데 사용됩니다.
단일 구성 요소(예: 랙의 Top-of-Rack 스위치 또는 전원 관리 장치)의 손실이 풀의 모든 인스턴스에 영향을 주지 않도록 데이터 센터 내에서 인스턴스를 물리적으로 분리하는 것이 중요합니다. 이러한 서버는 Azure Security HSM 팀 전용입니다. 서버는 다른 Azure 팀과 공유되지 않으며, 이러한 서버에는 고객 워크로드가 배포되지 않습니다. 잠긴 랙을 비롯한 물리적 액세스 제어는 서버에 대한 무단 액세스를 방지하는 데 사용됩니다. 이러한 제어는 FedRAMP-High, PCI, SOC 1/2/3, ISO 270x와 기타 보안 및 개인 정보 보호 표준을 충족하며, Azure 규정 준수 프로그램에서 정기적으로, 독립적으로 확인됩니다. HSM은 물리적 보안을 강화했으며, FIPS 140-2 수준 3 요구 사항을 충족하는 것으로 확인되었습니다. 관리되는 HSM 서비스 전체는 신뢰할 수 있는 시작을 비롯한 표준 보안 Azure 플랫폼을 기반으로 빌드되며, 발전된 영구적 위협으로부터 보호합니다.
HSM 어댑터는 수십 개의 격리된 HSM 파티션을 지원할 수 있습니다. 각 서버에서는 Node Service라는 제어 프로세스가 실행됩니다. Node Service는 각 어댑터를 소유하며, 어댑터 소유자(여기서는 Microsoft)의 자격 증명을 설치합니다. HSM은 어댑터 소유권이 고객 파티션에 저장된 데이터에 대한 액세스 권한을 Microsoft에 제공하지 않도록 설계되었습니다. Microsoft가 고객 파티션을 만들고, 크기를 조정하고, 삭제하는 권한만 허용합니다. HSM은 고객을 위해 파티션의 블라인드 백업을 지원합니다. 블라인드 백업에서는 고객이 제공한 키로 백업을 래핑하며, 이러한 키는 고객이 소유하고 Microsoft가 콘텐츠를 읽을 수 없는, 관리되는 HSM 인스턴스 내에서만 서비스 코드로 복원할 수 있습니다.
관리되는 HSM 풀의 아키텍처
그림 1은 가용성을 지원하기 위해 자체 데이터 센터 랙의 HSM 서버에서 각각 실행되는 3개의 Linux VM으로 구성된 HSM 풀의 아키텍처를 보여줍니다. 중요한 구성 요소는 다음과 같습니다.
- HFC(HSM 패브릭 컨트롤러)는 서비스의 컨트롤 플레인입니다. HFC는 풀의 자동 패치와 복구를 구동합니다.
- 3개의 FIPS 140-2 수준 3 호환 HSM 인스턴스에 연결된 3개의 Intel SGX(Intel Secure Guard Extensions) 기밀 엔클레이브로 구성된 각 고객을 위한 제외적인 암호화 경계입니다. 이 경계의 루트 키가 생성되어 3개의 HSM에 저장됩니다. 이 문서의 뒷부분에서 설명하겠지만, Microsoft와 연결된 사람은 이 경계 안에 있는 데이터에 액세스할 수 없습니다. 고객을 대신하여 작동하는 Intel SGX 엔클레이브(Node Service 에이전트 포함)에서 실행되는 서비스 코드만 액세스할 수 있습니다.
TEE(신뢰 실행 환경)
관리되는 HSM 풀은 3개의 서비스 인스턴스로 구성됩니다. 각 서비스 인스턴스는 Intel SGX 기능과 Open Enclave SDK를 사용하는 TEE(신뢰 실행 환경)로 구현됩니다. TEE 내에서 실행하면 서비스를 호스트하는 VM(가상 머신) 또는 VM의 호스트 서버 중 어느 누구도 고객의 비밀, 데이터 또는 HSM 파티션에 액세스할 수 없습니다. 각 TEE는 특정 고객 전용이며 HSM 파티션에 대한 TLS 관리, 요청 처리 및 액세스 제어를 실행합니다. 보안 도메인 패키지에 포함된 경우를 제외하고, 이 TEE 외부에서는 자격 증명 또는 고객 관련 데이터 암호화 키가 일반 텍스트로 존재하지 않습니다. 이 패키지는 고객이 제공한 키로 암호화되며, 풀이 처음 만들어질 때 다운로드합니다.
TEE는 증명된 TLS를 사용하여 서로 통신합니다. 증명된 TLS는 Intel SGX 플랫폼의 원격 증명 기능을 TLS 1.2와 결합합니다. 이렇게 하면 TEE의 관리되는 HSM 코드가 동일한 관리되는 HSM 서비스 코드 서명 키로 서명된 다른 코드로만 통신할 수 있도록 제한하여 중간자(man-in-the-middle) 공격을 차단할 수 있습니다. 관리되는 HSM 서비스의 코드 서명 키는 Microsoft 제품 릴리스 및 보안 서비스(Windows 코드 서명 키를 저장하는 데도 사용됨)에 저장됩니다. 이 키는 관리되는 HSM 팀이 제어합니다. 변경 관리에 대한 Microsoft의 규제 및 규정 준수 의무에 따라 이 키는 다른 Microsoft 팀이 코드에 서명하는 데 사용할 수 없습니다.
TEE 간 통신에 사용되는 TLS 인증서는 서비스 코드를 통해 TEE 내에서 자체 발급됩니다. 인증서에는 서버의 Intel SGX 엔클레이브가 생성한 플랫폼 보고서가 포함되어 있습니다. 플랫폼 보고서는 제작할 때 Intel이 CPU에 융합한 키에서 파생된 키로 서명됩니다. 이 보고서는 코드 서명 키와 이진 해시를 통해 Intel SGX 엔클레이브에 로드되는 코드를 식별합니다. 이 플랫폼 보고서에서, 서비스 인스턴스는 피어가 관리되는 HSM 서비스 코드 서명 키로도 서명되었는지 확인할 수 있으며, 플랫폼 보고서를 통해 암호화 얽힘을 약간만 하면 외부 가장을 방지하기 위해 TEE 내에도 자체 발급된 인증서 서명 키가 생성되었는지 확인할 수 있습니다.
완전한 고객 관리형 키 제어를 사용하여 가용성 SLA 제공
고가용성을 보장하기 위해 HFC 서비스는 고객이 선택한 Azure 지역에 3개의 HSM 인스턴스를 만듭니다.
관리되는 HSM 풀 만들기
관리되는 HSM 풀이 고가용성을 제공하는 비결은 항상 동기화된 상태로 유지되는 자동 관리형 삼중 중복 HSM 인스턴스(또는 다중 지역 복제를 사용하는 경우 6개 인스턴스를 모두 동기화된 상태로 유지)입니다. 풀 만들기는 고객이 선택하는 Azure 지역의 가용 하드웨어에 풀을 할당하는 HFC 서비스에서 관리합니다.
새 풀이 요청되면 HFC는 HSM 어댑터에 가용 공간이 있는 여러 랙에서 3개의 서버를 선택한 다음, 풀을 만들기 시작합니다.
HFC는 3개의 TEE에 있는 각 노드 서비스 에이전트에게 매개 변수 집합을 사용하여 새 서비스 코드 인스턴스를 시작하라고 지시합니다. 매개 변수는 고객의 Microsoft Entra 테넌트, 세 인스턴스의 내부 가상 네트워크 IP 주소 및 기타 서비스 구성을 확인합니다. 무작위로 한 파티션이 주 파티션으로 할당됩니다.
3개의 인스턴스가 시작됩니다. 각 인스턴스는 로컬 HSM 어댑터의 파티션에 연결한 다음, 무작위로 생성된 사용자 이름과 자격 증명을 사용하여 파티션을 제로화하고 초기화합니다(인간 운영자 또는 다른 TEE 인스턴스가 파티션에 액세스할 수 없도록 하기 위해).
주 인스턴스는 HSM에 생성된 프라이빗 키를 사용하여 파티션 소유자 루트 인증서를 만듭니다. 그리고 이 루트 인증서를 사용하여 HSM 파티션의 파티션 수준 인증서에 서명하여 풀의 소유권을 설정합니다. 또한 주 인스턴스는 서비스 내의 모든 미사용 고객 데이터를 보호하는 데 사용되는 데이터 암호화 키를 생성합니다. 키 자료의 경우 HSM이 키 자료 자체를 보호하기 때문에 이중 래핑이 사용됩니다.
다음으로, 이 소유권 데이터가 두 보조 인스턴스에 동기화됩니다. 각 보조 인스턴스는 증명된 TLS를 사용하여 주 인스턴스에 연결합니다. 주 인스턴스는 파티션 소유자 루트 인증서를 프라이빗 키 및 데이터 암호화 키와 공유합니다. 이제 보조 인스턴스는 파티션 루트 인증서를 사용하여 자체 HSM 파티션에 파티션 인증서를 발급합니다. 이 작업이 완료되면 3개 서버 각각에 동일한 파티션 루트 인증서 소유의 HSM 파티션이 있습니다.
증명된 TLS 링크를 통해 주 인스턴스의 HSM 파티션은 HSM 공급업체에서 제공하는 보안 API를 사용하여 보조 인스턴스와 생성된 데이터 래핑 키(세 HSM 간의 메시지를 암호화하는 데 사용)를 공유합니다. 이렇게 교환하는 동안 HSM은 파티션 소유자 인증서가 동일한지 확인한 다음, Diffie-Hellman 체계를 사용하여 Microsoft 서비스 코드가 메시지를 읽을 수 없도록 메시지를 암호화합니다. 서비스 코드는 HSM 간에 불투명 BLOB을 전송하는 것만 가능합니다.
이제 3개 인스턴스 모두 고객의 가상 네트워크에 풀로 노출할 준비가 완료되었습니다. 3개 인스턴스는 동일한 파티션 소유자 인증서와 프라이빗 키, 동일한 데이터 암호화 키, 공통 데이터 래핑 키를 공유합니다. 그러나 각 인스턴스의 HSM 파티션에 대한 자격 증명은 고유합니다. 이제 최종 단계가 완료되었습니다.
각 인스턴스는 공용 TLS 인증서에 사용할 RSA 키 쌍과 CSR(인증서 서명 요청)을 생성합니다. CSR은 Microsoft 퍼블릭 루트를 사용하여 Microsoft PKI(공개 키 인프라) 시스템에 의해 서명되고, 최종 TLS 인증서는 인스턴스에 반환됩니다.
3개 인스턴스 모두 로컬 CPU에서 자체 Intel SGX 봉인 키를 가져옵니다. 이 키는 CPU의 고유 키와 TEE의 코드 서명 키를 사용하여 생성됩니다.
풀은 Intel SGX 봉인 키에서 고유의 풀 키를 파생시키고, 이 풀 키를 사용하여 모든 비밀을 암호화한 다음, 암호화된 BLOB을 디스크에 씁니다. 이러한 BLOB은 동일한 물리적 CPU에서 실행되는 Intel SGX 봉인 키로 코드 서명하는 방법으로만 암호 해독할 수 있습니다. 비밀은 해당 인스턴스에 바인딩됩니다.
이제 보안 부트스트랩 프로세스가 완료되었습니다. 이 프로세스를 통해 삼중 중복 HSM 풀을 만들고 고객 데이터 주권의 암호화 보장을 만들 수 있습니다.
기밀 서비스 복구를 사용하여 런타임에 가용성 SLA 유지
이 문서에 설명된 풀 만들기 스토리는 관리되는 HSM 서비스가 서비스의 기반이 되는 서버를 안전하게 관리하여 고가용성 SLA를 제공하는 방법을 설명할 수 있습니다. 서버, HSM 어댑터 또는 랙의 전원 공급 장치가 고장 난다고 가정하겠습니다. 관리되는 HSM 서비스의 목표는 고객의 개입 없이 또는 비밀이 TEE 외부에서 명확한 텍스트로 노출될 가능성 없이 풀을 정상 인스턴스 3개로 복구하는 것입니다. 이 목표는 기밀 서비스 복구를 통해 달성됩니다.
가장 먼저 HFC는 오류가 발생한 서버에서 어떤 풀에 인스턴스가 있는지 검색합니다. HFC는 풀의 지역 내에서 대체 인스턴스를 배포할 새로운 정상 서버를 찾습니다. HFC가 새 인스턴스를 시작하면 해당 인스턴스는 초기 프로비전 단계에서 정확히 보조 인스턴스로 취급됩니다. 즉, HSM을 초기화하고, 주 인스턴스를 찾고, 증명된 TLS를 통해 안전하게 비밀을 교환하고, HSM을 소유권 계층 구조에 서명한 다음, 서비스 데이터를 새 CPU에 봉인합니다. 이제 서비스가 완전히 자동으로, 완전히 기밀로 복구됩니다.
보안 도메인을 사용하여 재해 복구
보안 도메인은 HSM 파티션을 처음부터 다시 빌드하는 데 필요한 모든 자격 증명(파티션 소유자 키, 파티션 자격 증명, 데이터 래핑 키 및 HSM의 초기 백업)을 포함하고 있는 보안 BLOB입니다. 서비스가 라이브 상태가 되기 전에, 고객은 보안 도메인을 보호할 수 있도록 RSA 암호화 키를 입력하여 보안 도메인을 다운로드해야 합니다. 보안 도메인 데이터는 TEE에서 시작되며, 생성된 대칭 키와 고객이 선택한 쿼럼 매개 변수에 따라 고객이 제공한 RSA 공개 키 간에 키 공유를 분할하는 Shamir 비밀 공유 알고리즘 구현을 통해 보호됩니다. 이 프로세스 중에 서비스 키 또는 자격 증명은 TEE에서 실행되는 서비스 코드 외부에서 일반 텍스트로 노출되지 않습니다. 오직 고객만이 TEE에 RSA 키의 쿼럼을 제공하여 복구 시나리오 중에 보안 도메인을 암호 해독할 수 있습니다.
재해로 인해 Azure 지역 전체가 손실되고 Microsoft가 풀의 인스턴스 3개를 모두 동시에 손실하는 경우에만 보안 도메인이 필요합니다. 인스턴스 하나 또는 2개가 손실되면 기밀 서비스 복구는 고객 개입 없이 조용히 정상 인스턴스 3개로 복구합니다. Intel SGX 봉인 키가 CPU마다 고유하기 때문에 전체 지역이 손실된 경우 Microsoft는 HSM 자격 증명 및 파티션 소유자 키를 복구할 방법이 없습니다. 이러한 자격 증명 및 파티션 소유자 키는 인스턴스의 컨텍스트 내에만 존재합니다.
이 재해가 발생할 가능성이 매우 낮은 경우 고객은 비어 있는 새 풀을 만들어서 보안 도메인에 삽입한 다음, RSA 키 쿼럼을 제시하여 보안 도메인의 소유권을 증명하는 방법으로 이전 풀 상태와 데이터를 복구할 수 있습니다. 고객이 다중 지역 복제를 사용하도록 설정한 경우 두 지역이 동시에 재해로 인해 완전히 중단되어 고객이 개입하여 보안 도메인에서 풀을 복구해야 하는 상황이 발생할 가능성은 훨씬 낮아집니다.
서비스 액세스 제어
앞에서 설명한 것처럼, 필요한 자격 증명이 고객 또는 다른 사람에게 제공되지 않기 때문에 TEE의 서비스 코드는 HSM 자체에 액세스할 수 있는 유일한 엔터티입니다. 대신 고객의 풀은 고객의 Microsoft Entra 인스턴스에 바인딩되며 인증 및 권한 부여에 사용됩니다. 초기 프로비전 시에 고객은 풀에 대한 관리자 역할을 할당할 초기 직원을 선택할 수 있습니다. 이러한 개인과 고객 Microsoft Entra 테넌트 전역 관리자 역할이 할당된 직원은 풀 내에서 액세스 제어 정책을 설정할 수 있습니다. 해당 서비스는 모든 액세스 제어 정책을 마스킹된 키와 동일한 데이터베이스에 저장하며, 이러한 액세스 제어 정책은 암호화됩니다. TEE의 서비스 코드만이 이러한 액세스 제어 정책에 액세스할 수 있습니다.
요약
관리되는 HSM을 사용하면 고객이 첨단 하드웨어 지원 기밀 엔클레이브 기술을 사용하여 가용성과 암호화 키 제어권 간에 절충할 필요가 없습니다. 이 문서에서 설명한 대로, 이 구현에서는 관리되는 HSM 호스트 컴퓨터와 HSM에 물리적으로 접근할 수 있는 Microsoft 직원 또는 담당자조차도 고객 관리형 키 자료 또는 관련 비밀에 액세스할 수 없습니다. 금융 서비스, 제조, 공공 부문, 국방 및 기타 수직 분야의 고객은 이러한 보안 체계를 믿고 신속하게 클라우드로 마이그레이션할 수 있습니다.