Azure Confidential Computing과 Managed HSM을 통한 클라우드 주권 확보 전략
클라우드 환경에서 데이터는 물리적 경계를 넘어 저장되고 처리되며, 이는 데이터 주권(Digital Sovereignty)과 보안 통제에 대한 새로운 도전 과제를 야기합니다. 특히 정부 기관과 규제가 엄격한 산업군에서는 데이터의 위치, 접근 권한, 암호화 키 관리에 대한 철저한 통제가 필수적입니다.
KT SPC(Secure Public Cloud)는 Microsoft Azure에서 제공하는 Confidential Computing과 Managed HSM 기술을 활용하여, 조직이 어떻게 클라우드 상에서 디지털 주권을 확보할 수 있는지를 설명할 수 있는 사례입니다. 아래 기술적 개념부터 MS와 협업 사례, 실제 환경 구성까지 포괄적으로 다루어 독자의 이해를 돕고자 합니다.
1. Confidential Computing이 뭘까?
Azure에서 제공하는 Azure Confidential Computing은 하드웨어 기반의 신뢰 실행 환경(TEE, Trusted Execution Environment)을 통해 데이터가 사용 중(in use)일 때도 암호화된 상태로 보호되도록 합니다.
즉, 사용 중(in use) 암호화란 하드웨어 수준에서 자동으로 메모리를 암호화하고 VM(Virtual Machine)이 신뢰할 수 있는 상태(TEE)에서 부팅되었는지 외부에서 검증할 수 있는 기술입니다.
그렇다면 사용 중(in use) 암호화가 왜 중요하고, 데이터 주권을 지킬 수 있을까요? 일반적인 클라우드에서는
- 데이터를 저장할 때는 암호화할 수 있고,
- 전송할 때도 암호화할 수 있지만,
- 실제로 데이터를 처리할 때는 암호화가 풀려야 했어요.
Confidential Computing은 이 마지막 단계, 즉 "데이터를 사용하는 순간"에도 암호화를 유지할 수 있게 해주는 기술이에요. 그래서 운영자, 해커, 심지어 클라우드 제공자조차도 데이터를 볼 수 없게 됩니다.
Confidential Computing을 통해 Public Cloud의 장점을 이용하면서도, Cloud를 제공하는 사업자(AWS, Azure, Google Cloud Platform 등)가 접근할 수 없기 때문에 데이터 주권을 지킬 수 있는 필수적인 요소입니다.
2. Azure Managed HSM: 키 관리의 주권 확보
Azure Managed HSM은 FIPS 140-2 Level 3 인증을 받은 하드웨어 보안 모듈로, 고객이 직접 암호화 키를 생성, 저장, 관리할 수 있도록 지원합니다. 쉽게 설명드리면, Cloud 사업자가 접근할 수 없는 고객 전용 키 저장소에요.
주요 이점:
- 고객 전용 HSM 인스턴스 제공
- Microsoft도 접근할 수 없는 키 격리
- Bring Your Own Key (BYOK) 및 Hold Your Own Key (HYOK) 시나리오 지원
- 규제 준수 (GDPR, eIDAS, ISO/IEC 27001 등)
이를 통해 기업은 암호화 키에 대한 완전한 통제권을 유지하면서도 Azure의 확장성과 유연성을 활용할 수 있습니다.
그렇다면 KT SPC는 Azure Managed HSM을 어떻게 활용할까?
KT SPC 환경에서 Confidential VM은 앞서 말씀드렸듯이, "데이터를 사용하는 순간"에도 암호화를 유지할 수 있어 CSP(Cloud Service Provider) 사업자도 접근이 불가능 합니다.
하지만, Azure에서 기본적으로 제공하는 Public Managed Key가 아닌, 고객 전용키(Customer Managed Key)를 고객 전용 키 저장소(Managed HSM)에 생성하여 참조하도록 한번 더 보안을 강화합니다.
| KT SPC 환경내의 Confidential VM 생성 흐름도 |
위 그림에 대해서 아래와 같이 설명드리겠습니다.
① Confidential VM이 부팅되고, TEE가 초기화됨
- AMD SEV-SNP 기반의 Confidential VM이 시작되며, 하드웨어 기반의 TEE(Trusted Execution Environment)가 활성화됩니다.
- 이 환경은 VM 내부의 메모리와 실행 상태를 외부(하이퍼바이저 포함)로부터 격리합니다.
② 애플리케이션이 Microsoft Azure Attestation(MAA)에 Attestation 요청
- VM 내부의 애플리케이션은 자신이 신뢰할 수 있는 환경에서 실행 중임을 증명하기 위해 MAA에 Attestation 요청을 보냅니다.
- 이 요청에는 플랫폼 상태 보고서(Platform Report)가 포함됩니다.
③ MAA가 플랫폼 상태를 검증하고 토큰 발급
- MAA는 해당 플랫폼이 정상적인 SEV-SNP 기반 Confidential VM인지 확인합니다.
- 검증이 완료되면, Attestation Token을 발급합니다. 이 토큰은 VM이 신뢰할 수 있는 상태임을 증명하는 역할을 합니다.
④ 애플리케이션이 Azure Key Vault에 키 요청 (Attestation Token 포함)
- 애플리케이션은 Attestation Token을 포함한 요청을 Azure Key Vault 또는 Managed HSM에 보냅니다.
- 이 요청은 "나는 신뢰할 수 있는 환경에서 실행 중이니, 키를 주세요"라는 의미입니다.
⑤ Key Vault가 정책에 따라 요청을 검증
- Key Vault는 사전에 설정된 Key Release Policy를 기반으로 요청을 검토합니다.
- 이 정책은 "어떤 조건을 만족하는 VM에만 키를 제공할 수 있다"는 규칙을 포함합니다 (예: 특정 MAA, 특정 VM 속성 등).
⑥ 조건이 충족되면 키를 암호화된 형태로 반환
- 요청이 정책을 만족하면, Key Vault는 암호화된 키를 애플리케이션에 반환합니다.
- 이 키는 TEE 내부에서만 복호화 가능하도록 설계되어 있습니다.
⑦ 애플리케이션이 TEE 내부에서 키를 사용
- 애플리케이션은 받은 키를 TEE 내부에서만 복호화 및 사용합니다.
- 이로써 키는 전송 중, 저장 중, 사용 중 모두 보호됩니다.
위 아키텍처로 Azure Managed HSM을 생성은 했지만..
단순히 기밀 컴퓨팅을 생성하고 사용하는데는 무리가 없었습니다만, 아키텍처는 큰 그림일뿐……Soverign 환경을 구축하는 과정에서 크고 작은 오류와 난관들이 기다리고 있었어요. Bring Your Own Key (BYOK)의 관점에서 Azure에서 제공하는 Public Managed Key가 아닌, 키 관리 주권 확보를 위한 고객 전용 키(Customer Managed Key)와 결합하는데 많은 사전적 정보들이 필요했습니다.
- Entra App
- 권한
- Managed HSM 생성을 위한 선제 조건
- Managed HSM이 Korea Region에 GA되지 않음에 따른 작업/운영 방향 등..
위와 같은 사전적 정의와 구성이 필요한 상태에서 MS의 문서와, 업데이트 되지 않은 정보들이 필요했고 해당 이슈를 해결하는데 거의 한달이 걸렸답니다.
3. 클라우드 주권 확보 전략: 기술과 정책의 결합
Azure Confidential Computing과 Managed HSM을 함께 활용하면 다음과 같은 주권 중심의 클라우드 전략을 수립할 수 있습니다
- 데이터 주권(Data Sovereignty): 데이터가 특정 지역 내에서만 저장 및 처리되도록 보장
- 운영 주권(Operational Sovereignty): 클라우드 운영에 대한 고객의 통제력 강화
- 정책 주권(Policy Sovereignty): 국가 및 산업별 규제에 맞춘 정책 적용 가능
위 전략을 충족시키기 위해 KT SPC는 기밀 컴퓨팅과 Managed HSM 외에 여러 정책으로 기술 주권을 지키고 있어요.
Azure Public Cloud로 KT SPC 환경을 구축하고 느낀 점
이번 프로젝트는 단순한 클라우드 보안 강화를 넘어, 기밀 컴퓨팅과 고객 관리형 키(CMK)를 결합한 고신뢰 환경을 구축하는 것이 핵심 목표였습니다. 이 두 기술을 통합하는 과정은 생각보다 훨씬 복잡하고 도전적이었습니다.
기밀 컴퓨팅은 실행 중인 데이터까지 보호해야 하기에, 하드웨어 기반의 신뢰 실행 환경(TEE)을 이해하고 적용하는 데 많은 시간과 노력이 필요했습니다. 동시에, 고객이 직접 키를 관리하는 CMK를 결합하는 환경은 Microsoft Azure에서 설계한 in Memory와 Disk의 Encryption에 대한 자세한 이해, TEE에서 Key를 참조하고, Attestation하는 과정에 대한 자세한 이해가 필수적 이었습니다. 이 두 기술을 동시에 적용하면서도 성능 저하 없이 안정적인 서비스를 제공할 수 있도록 주요 기술에 대한 검증이 필수적이었습니다.
특히 어려웠던 순간은, 기밀컴퓨팅 환경에서 기술 검증을 진행하는 데 수많은 테스트와 검증이 필요했습니다. 예상치 못한 오류와 제약 조건에 부딪힐 때마다 좌절도 있었지만, 그만큼 배움도 컸습니다.
그럼에도 불구하고 이 프로젝트를 통해 얻은 보람은 매우 컸습니다. 이번 경험은 단순한 기술 구현을 넘어, 신뢰 기반의 클라우드 보안이 어떻게 현실화될 수 있는지를 몸소 체험한 여정이었습니다. 앞으로도 이러한 경험을 바탕으로, 더 많은 조직이 데이터 주권과 보안을 동시에 확보할 수 있는 환경을 구축할 수 있도록 기여하고 싶습니다.