Azure 보안 격리 지침

Microsoft Azure는 AI, 기계 학습, IoT 서비스, 빅 데이터 분석, 인텔리전트 에지 등과 같은 최신 클라우드 혁신을 통합하여 기능이 풍부한 환경에 대한 액세스를 제공하는 하이퍼스케일 퍼블릭 다중 테넌트 클라우드 서비스 플랫폼입니다. 이 플랫폼은 효율성을 높이고 운영과 성능에 대한 인사이트를 얻는 데 도움이 됩니다.

다중 테넌트 클라우드 플랫폼에서는 여러 고객의 애플리케이션과 데이터가 동일한 물리적 하드웨어에 저장됩니다. Azure는 논리적 격리를 사용하여 애플리케이션과 데이터를 다른 고객과 분리합니다. 이 방법은 다중 테넌트 클라우드 서비스의 규모와 경제적 이점을 제공하는 동시에 다른 고객이 사용자의 데이터 또는 애플리케이션에 액세스하지 못하도록 엄격하게 방지합니다.

Azure는 다음과 같은 일반적인 원칙 세트를 사용하여 확실하게 암호화되고 논리적으로 격리된 다중 테넌트 클라우드 서비스를 보장할 수 있도록 신뢰할 수 있는 기반을 제공하여 인식된 리소스 공유 위험을 해결합니다.

1. 인증 및 ID 분리를 통한 사용자 액세스 제어
2. 컴퓨팅 처리 격리
3. 전송 중 데이터 암호화를 포함한 네트워킹 격리
4. 미사용 데이터 암호화를 통한 스토리지 격리
5. 논리적으로 격리된 서비스를 올바르게 개발하기 위해 서비스 설계에 포함된 보안 보증 프로세스

퍼블릭 클라우드의 다중 테넌트는 저렴한 비용으로 서로 다른 고객 간에 리소스를 멀티플렉싱하여 효율성을 향상시킵니다. 그러나 이 방법에는 리소스 공유와 관련된 인식된 위험이 있습니다. Azure는 그림 1에 표시된 다계층 접근 방식을 사용하여 격리된 클라우드 서비스에 대한 신뢰할 수 있는 기반을 제공함으로써 이러한 위험을 해결합니다.

그림 1. Azure 격리 방법

격리 방법에 대한 간략한 요약은 다음과 같습니다.

• 인증 및 ID 분리를 통한 사용자 액세스 제어 – 유형 또는 스토리지 위치에 관계없이 Azure의 모든 데이터는 구독과 연결됩니다. 클라우드 테넌트는 Microsoft 클라우드 서비스에 등록할 때 조직에서 받고 소유하는 Microsoft Entra ID의 전용 인스턴스로 볼 수 있습니다. ID 및 액세스 스택은 구독 내의 리소스에 대한 액세스를 권한 있는 사용자로만 제한하는 것을 포함하여 구독 간 격리를 적용하는 데 도움이 됩니다.

• 컴퓨팅 격리 – Azure는 논리적 및 물리적 컴퓨팅 처리 격리를 모두 제공합니다. 논리적 격리는 다음을 통해 구현됩니다.

  • 하이퍼바이저 격리 - 별도의 가상 머신과 Azure 하이퍼바이저 격리를 사용하여 확실하게 암호화된 격리를 제공하는 서비스를 위한 것입니다.
  • Drawbridge 격리 - Drawbridge에서 제공하는 격리를 사용하여 확실하게 암호화된 격리를 동일한 가상 머신에서 실행되는 워크로드에 제공하는 서비스를 위한 것이며 VM(가상 머신) 내에 구현됩니다. 이러한 서비스는 고객 코드를 사용하여 작은 처리 단위를 제공합니다.
  • 사용자 컨텍스트 기반 격리 - Microsoft 제어 코드로만 구성되고 고객 코드 실행이 허용되지 않는 서비스를 위한 것입니다.
    

  모든 Azure 테넌트에서 계획적으로 사용할 수 있는 강력한 논리적 컴퓨팅 격리 외에도 물리적 컴퓨팅 격리를 원하는 경우 단일 고객 전용 서버 하드웨어에 배포되는 Azure Dedicated Host 또는 격리된 Virtual Machines를 사용할 수 있습니다.

• 네트워킹 격리 – Azure VNet(Virtual Network)은 프라이빗 네트워크 트래픽을 다른 고객에게 속한 트래픽과 논리적으로 격리하는 데 도움이 됩니다. 서비스는 공용 IP 또는 개인(VNet) IP를 사용하여 통신할 수 있습니다. VM 간의 통신은 VNet 내에서 비공개로 유지됩니다. 대역폭, 대기 시간, 암호화 요구 사항을 포함한 연결 옵션에 따라 VNet 피어링 또는 VPN 게이트웨이를 통해 VNet을 연결할 수 있습니다. NSG(네트워크 보안 그룹)를 사용하여 네트워크 격리를 달성하고 퍼블릭 엔드포인트가 있는 Azure 서비스에 액세스하는 동안 인터넷에서 Azure 리소스를 보호할 수 있습니다. Virtual Network 서비스 태그를 사용하여 네트워크 보안 그룹 또는 Azure Firewall에 대한 네트워크 액세스 제어를 정의할 수 있습니다. 서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. Microsoft에서 서비스 태그에 포함되는 주소 접두사를 관리하고 주소 변경에 따라 서비스 태그를 자동으로 업데이트하므로 네트워크 보안 규칙을 자주 업데이트하는 복잡성이 줄어듭니다. 또한 Private Link를 사용하여 VNet의 프라이빗 엔드포인트를 통해 Azure PaaS 서비스에 액세스할 수 있습니다. 그러면 VNet과 서비스 간의 트래픽이 Microsoft 글로벌 백본 네트워크를 통해 이동하므로 서비스를 공용 인터넷에 노출할 필요가 없습니다. 마지막으로 Azure는 Key Vault 인증서를 사용한 TLS(전송 계층 보안) 종료가 있는 네트워크 트래픽의 TLS 엔드투엔드 암호화, IPsec을 사용한 VPN 암호화 및 CMK(고객 관리형 키) 지원이 포함된 MACsec을 사용한 Azure ExpressRoute 암호화를 포함하여 전송 중 데이터를 암호화하는 옵션을 제공합니다.

• 스토리지 격리 – 논리적 데이터 격리의 암호화 확실성을 보장하기 위해 Azure Storage는 여러 암호화가 포함된 고급 알고리즘을 사용하여 미사용 데이터 암호화를 사용합니다. 이 프로세스는 Azure Key Vault 및 Microsoft Entra ID와 같은 여러 암호화 키와 서비스를 사용하여 보안 키 액세스 및 중앙 집중식 키 관리를 보장합니다. Azure Storage 서비스 암호화는 데이터를 Azure Storage에 유지하기 전에 자동으로 암호화하고 검색하기 전에 암호를 해독하도록 합니다. Azure Storage에 기록된 모든 데이터는 FIPS 140 유효성이 검사된 256비트 AES 암호화를 통해 암호화되며 Key Vault를 CMK(고객 관리형 키)에 사용할 수 있습니다. Azure Storage 서비스 암호화는 Azure Virtual Machine 디스크를 저장하는 페이지 Blob을 암호화합니다. 또한 Azure Disk Encryption은 필요에 따라 Azure Windows 및 Linux IaaS Virtual Machine 디스크를 암호화하여 스토리지 격리를 강화하고 Azure에 저장된 데이터의 암호화 확실성을 보장하는 데 사용할 수 있습니다. 이 암호화에는 관리되는 디스크가 포함됩니다.

• 보안 보증 프로세스 및 사례 – 공격 표면을 보호하고 위협을 완화하기 위해 Microsoft에서 SDL(보안 개발 수명 주기) 및 기타 강력한 보안 보증 프로세스를 내부적으로 사용하여 Azure 격리 보증이 더 강화됩니다. Microsoft는 Azure 격리 보장에 대한 높은 신뢰도를 제공하는 업계 최고의 프로세스와 도구를 구축했습니다.

클라우드 컴퓨팅의 공동 책임 모델에 따라 워크로드를 온-프레미스 데이터 센터에서 클라우드로 마이그레이션함으로써 사용자와 클라우드 서비스 공급자 간의 책임에 대한 설명은 클라우드 서비스 모델에 따라 달라집니다. 예를 들어 IaaS(서비스 제공 인프라) 모델을 사용하는 경우 Microsoft의 책임은 하이퍼바이저 계층에서 끝나고 사용자는 게스트 VM의 기본 운영 체제 유지 관리를 포함하여 가상화 계층 위의 모든 계층에 대한 책임을 집니다. Azure 격리 기술을 사용하여 클라우드에 배포된 애플리케이션과 데이터에 대해 원하는 수준의 격리를 달성할 수 있습니다.

이 문서 전체의 설명 상자에는 사용자 책임의 일부로 간주되는 중요한 고려 사항 또는 작업이 간략하게 설명되어 있습니다. 예를 들어 Azure Key Vault를 사용하여 사용자가 제어하는 암호화 키를 포함하여 비밀을 저장할 수 있습니다.

참고 항목

Azure Key Vault를 CMK(고객 관리형 키)에 사용하는 것은 선택 사항이며 사용자의 책임입니다.

추가 리소스:

• Key Vault 인증서룰 시작하는 방법

이 문서에서는 클라우드 채택과 관련된 일반적인 보안 및 격리 문제를 해결하기 위한 기술 지침을 제공합니다. 또한 보안 격리 목표를 달성하는 데 도움이 되고 Azure에서 사용할 수 있는 설계 원칙과 기술을 살펴봅니다.

팁

Azure에 배포된 애플리케이션 및 데이터의 보안을 향상시키는 방법에 대한 권장 사항은 Azure Security Benchmark 설명서를 검토해야 합니다.

ID 기반 격리

Microsoft Entra ID는 사용자, 그룹 및 개체에 대한 인증, 권한 부여 및 액세스 제어를 제공하는 ID 리포지토리 및 클라우드 서비스입니다. Microsoft Entra ID는 독립 실행형 클라우드 디렉터리로 사용하거나 기존 온-프레미스 Active Directory와 통합 솔루션으로 사용하여 디렉터리 동기화 및 Single Sign-On과 같은 주요 엔터프라이즈 기능을 사용하도록 설정할 수 있습니다.

각 Azure 구독은 Microsoft Entra 테넌트와 연결됩니다. Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하면 Azure 구독의 리소스에 대한 액세스 권한을 해당 디렉터리의 사용자, 그룹 및 애플리케이션에 부여할 수 있습니다. 예를 들어 스토리지 계정을 리소스 그룹에 배치하여 Microsoft Entra ID를 사용하여 해당 특정 스토리지 계정에 대한 액세스를 제어할 수 있습니다. Azure Storage는 Blob 또는 큐 데이터에 액세스하는 데 사용되는 일반 권한을 포함하는 Azure 기본 제공 역할 세트를 정의합니다. Azure Storage에 대한 요청에는 Microsoft Entra 계정 또는 Storage 계정 키를 사용하여 권한이 부여될 수 있습니다. 이 방식으로 특정 사용자에게만 Azure Storage의 데이터에 액세스할 수 있는 권한을 부여할 수 있습니다.

제로 트러스트 아키텍처

유형 또는 스토리지 위치에 관계없이 Azure의 모든 데이터는 구독과 연결됩니다. 클라우드 테넌트는 Microsoft 클라우드 서비스에 등록할 때 조직에서 받고 소유하는 Microsoft Entra ID의 전용 인스턴스로 볼 수 있습니다. Azure Portal에 대한 인증은 Microsoft Entra ID에서 만들거나 온-프레미스 Active Directory와 페더레이션된 ID를 사용하여 Microsoft Entra ID를 통해 수행됩니다. ID 및 액세스 스택은 구독 내의 리소스에 대한 액세스를 권한 있는 사용자로만 제한하는 것을 포함하여 구독 간 격리를 적용하는 데 도움이 됩니다. 이 액세스 제한은 네트워크가 손상되었으며 경계 보안 모델에서 근본적인 전환이 필요하다고 가정하는 제로 트러스트 모델의 매우 중요한 목표입니다. 액세스 요청을 평가할 때 요청하는 모든 사용자, 디바이스 및 애플리케이션은 제로 트러스트 설계 원칙에 따라 무결성 유효성이 검사될 때까지 신뢰할 수 없는 것으로 간주되어야 합니다. Microsoft Entra ID는 제로 트러스트 프레임워크에 필요한 강력한 적응형 표준 기반 ID 확인을 제공합니다.

참고 항목

추가 리소스:

• Azure에서 제로 트러스트 아키텍처를 구현하는 방법에 대한 자세한 내용은 제로 트러스트 지침 센터를 참조하세요.
• 정의 및 일반 배포 모델은 NIST SP 800-207제로 트러스트 아키텍처를 참조하세요.

Microsoft Entra ID

클라우드 애플리케이션을 관리하는 데 사용되는 계정을 분리하는 것은 논리적 격리를 달성하는 데 매우 중요합니다. Azure의 계정 격리는 Microsoft Entra ID 및 세분화된 Azure RBAC(Azure 역할 기반 액세스 제어)를 지원하는 기능을 사용하여 달성됩니다. 각 Azure 계정은 하나의 Microsoft Entra 테넌트와 연결됩니다. 해당 디렉터리의 사용자, 그룹 및 애플리케이션은 Azure에서 리소스를 관리할 수 있습니다. Azure Portal, Azure 명령줄 도구 및 Azure 관리 API를 사용하여 적절한 액세스 권한을 할당할 수 있습니다. 각 Microsoft Entra 테넌트는 고유하며 다른 Azure AD와 별개입니다. Microsoft Entra 인스턴스는 고객 데이터 및 ID 정보가 혼합되지 않도록 방지하기 위해 보안 경계를 사용하여 논리적으로 격리됩니다. 이에 따라 Microsoft Entra ID의 사용자 및 관리자는 악의적이거나 실수로 다른 Microsoft Entra 인스턴스의 데이터에 액세스하거나 손상시킬 수 없습니다. Microsoft Entra ID는 전용 네트워크 세그먼트로 논리적으로 격리되고 호스트 수준 패킷 필터링 및 Windows 방화벽 서비스가 신뢰할 수 없는 트래픽으로부터 추가 보호를 제공하는 전용 서버에서 물리적으로 격리되어 실행됩니다.

Microsoft Entra ID는 테넌트 격리 및 액세스 제어, 전송 중 데이터 암호화, 비밀 암호화 및 관리, 디스크 수준 암호화, 다양한 Microsoft Entra 구성 요소에서 사용되는 고급 암호화 알고리즘, 참가자 액세스에 대한 데이터 운영 고려 사항 등 광범위한 데이터 보호 기능을 구현합니다. 자세한 내용은 Microsoft Entra 데이터 보안 고려 사항 백서에서 확인할 수 있습니다.

Microsoft Entra ID의 테넌트 격리에는 다음 두 가지 기본 요소가 포함됩니다.

• 테넌트 간 데이터 유출 및 액세스를 방지합니다. 즉, 테넌트 A의 명시적 권한 부여 없이 테넌트 B의 사용자가 테넌트 A에 속한 데이터를 얻을 수 없습니다.
• 테넌트 간 리소스 액세스를 격리합니다. 즉, 테넌트 A가 수행하는 작업은 테넌트 B의 리소스에 대한 액세스에 영향을 주지 않습니다.

그림 2와 같이 Microsoft Entra ID를 통해 액세스하려면 STS(보안 토큰 서비스)를 통한 사용자 인증이 필요합니다. 권한 부여 시스템은 디렉터리 서비스 API 및 Azure RBAC를 통해 사용자의 존재 여부 및 사용 상태에 대한 정보를 사용하여 대상 Microsoft Entra 인스턴스에 대해 요청된 액세스 권한이 세션의 사용자에게 부여되었는지 여부를 확인합니다. 사용자에게 직접 연결된 토큰 기반 인증 외에도 Microsoft Entra ID는 다음을 통해 Azure에서 논리적 격리를 추가로 지원합니다.

• Microsoft Entra 인스턴스는 개별 컨테이너이며 서로 간에 아무 관계가 없습니다.
• Microsoft Entra 데이터는 파티션에 저장되며 각 파티션에는 기본 주 복제본으로 간주되는 미리 결정된 복제본 세트가 있습니다. 복제본을 사용하면 Microsoft Entra 서비스의 고가용성이 제공되어 ID 분리 및 논리적 격리를 지원합니다.
• Microsoft Entra 인스턴스 관리자가 다른 Microsoft Entra 인스턴스의 사용자 계정 페더레이션 또는 프로비전을 통해 권한을 부여하는 경우를 제외하고는 Microsoft Entra 인스턴스 전체에서 액세스가 허용되지 않습니다.
• Microsoft Entra 서비스를 구성하는 서버에 대한 물리적 액세스 및 Microsoft Entra ID의 백 엔드 시스템에 대한 직접 액세스는 JIT(Just-In-Time) 권한 있는 액세스 관리 시스템을 사용하여 적절하게 권한이 부여된 Microsoft 운영 역할로 제한됩니다.
• Microsoft Entra 사용자는 물리적 자산 또는 위치에 액세스할 수 없으므로 논리적 Azure RBAC 정책 검사를 무시할 수 없습니다.

그림 2. Microsoft Entra 논리적 테넌트 격리

요약하면, 논리적 테넌트 격리에 대한 Azure의 방법은 Azure RBAC를 통해 리소스 및 권한 부여에 대한 테넌트 수준 액세스를 제공하기 위한 첫 번째 논리적 제어 경계로 Microsoft Entra ID를 통해 관리되는 ID를 사용합니다.

데이터 암호화 키 관리

Azure는 다음과 같은 다양한 암호화 모델을 포함하여 데이터 암호화를 통해 데이터를 보호하기 위한 광범위한 지원을 제공합니다.

• 서비스 관리형 키, Azure의 고객 관리형 키 또는 고객 제어 하드웨어의 고객 관리형 키를 사용하는 서버 쪽 암호화
• 온-프레미스 또는 다른 보안 위치에서 키를 관리하고 저장할 수 있는 클라이언트 쪽 암호화

데이터 암호화는 암호화(cryptographic) 키 액세스와 직접 연결되는 격리 보증을 제공합니다. Azure는 강력한 암호를 데이터 암호화에 사용하므로 암호화 키에 액세스할 수 있는 엔터티만 데이터에 액세스할 수 있습니다. 암호화 키를 삭제하거나 철회하면 해당 데이터에 액세스할 수 없게 됩니다. 전송 중 데이터 암호화에 대한 자세한 내용은 네트워킹 격리 섹션에서 제공하고, 미사용 데이터 암호화는 스토리지 격리 섹션에서 설명합니다.

Azure를 사용하면 이중 암호화를 미사용 데이터와 전송 중 데이터 모두에 적용할 수 있습니다. 이 모델을 사용하면 암호화 계층의 손상으로부터 보호하기 위해 둘 이상의 암호화 계층이 사용하도록 설정됩니다.

Azure Key Vault

데이터 보안을 위해 암호화 키를 적절하게 보호하고 관리하는 것이 필수적입니다. Azure Key Vault는 비밀을 안전하게 저장하고 관리하기 위한 클라우드 서비스입니다. Key Vault 서비스는 이 섹션의 나머지 부분에서 설명하는 두 가지 리소스 종류를 지원합니다.

• 자격 증명 모음은 소프트웨어 보호 모듈 비밀 및 HSM(하드웨어 보안 모듈) 보호 비밀, 키, 인증서를 지원합니다.
• 관리되는 HSM은 HSM으로 보호되는 암호화 키만 지원합니다.

Azure 서비스에 저장된 가장 중요한 고객 데이터에 대한 추가 보안이 필요한 경우 Key Vault에서 제어하는 사용자 고유의 암호화 키를 사용하여 해당 데이터를 암호화할 수 있습니다.

Key Vault 서비스는 기본 HSM에 대한 추상화를 제공합니다. 클라우드 애플리케이션에서 서비스를 사용할 수 있도록 하는 REST API와 Microsoft Entra ID를 통한 인증을 제공하여 인증, 재해 복구, 고가용성 및 탄력성을 중앙 집중화하고 사용자 지정할 수 있습니다. Key Vault는 RSA 및 타원 곡선 키를 포함하여 다양한 유형, 크기 및 곡선의 암호화 키를 지원합니다. 관리되는 HSM을 사용하여 AES 대칭 키에도 지원을 사용할 수 있습니다.

Key Vault를 사용하면 그림 3과 같이 HSM에서 암호화 키를 가져오거나 생성하여 키가 HSM 보호 경계를 벗어나지 않도록 함으로써 BYOK(Bring Your Own Key) 시나리오를 지원할 수 있습니다.

그림 3. BYOK(Bring Your Own Key)에 대한 Azure Key Vault 지원

Key Vault HSM 내에서 생성된 키는 내보낼 수 없으며, HSM 외부에는 일반 텍스트 버전의 키가 있을 수 없습니다. 이 바인딩은 기본 HSM을 통해 적용됩니다. BYOK 기능은Key Vault 및 관리형 HSM 모두에서 사용할 수 있습니다. HSM 보호 키를 Key Vault로 전송하는 방법은 온라인 설명서에서 설명한 대로 기본 HSM에 따라 달라집니다.

참고 항목

Azure Key Vault는 Microsoft 및 해당 에이전트에서 암호화 키를 포함하여 서비스에 저장된 모든 데이터에 액세스, 사용 또는 추출하지 못하도록 설계, 배포 및 운영됩니다. 자세한 내용은 Azure Key Vault는 키를 어떻게 보호하나요?를 참조하세요.

Key Vault는 암호화 키 수명 주기 관리를 위한 강력한 솔루션을 제공합니다. 만들 때 모든 키 자격 증명 모음 또는 관리되는 HSM은 구독을 소유한 Microsoft Entra 테넌트와 자동으로 연결됩니다. 키 자격 증명 모음 또는 관리되는 HSM에서 콘텐츠를 관리하거나 검색하려는 모든 사용자는 올바르게 인증되고 권한을 부여받아야 합니다.

• 인증은 호출자(사용자 또는 애플리케이션)의 ID를 설정합니다.
• 권한 부여는 Azure RBAC(Azure 역할 기반 액세스 제어)와 키 자격 증명 모음 액세스 정책 또는 관리되는 HSM 로컬 RBAC의 조합에 따라 호출자가 수행할 수 있는 작업을 결정합니다.

Microsoft Entra ID는 이전의 Microsoft Entra ID 섹션에서 설명한 대로 테넌트 격리를 적용하고 권한이 없는 당사자의 액세스를 방지하기 위한 강력한 조치를 구현합니다. 키 자격 증명 모음 또는 관리되는 HSM에 대한 액세스는 관리 평면과 데이터 평면이라는 두 개의 인터페이스 또는 평면을 통해 제어됩니다(두 평면 모두에서 Microsoft Entra ID를 인증에 사용).

• 관리 평면을 사용하면 키 자격 증명 모음 또는 관리되는 HSM 자체를 관리할 수 있습니다. 예를 들어 키 자격 증명 모음 또는 관리되는 HSM을 만들고 삭제하거나, 키 자격 증명 모음 또는 관리되는 HSM 속성을 검색하고, 액세스 정책을 업데이트할 수 있습니다. 권한 부여를 위해 관리 평면은 키 자격 증명 모음 및 관리되는 HSM 모두에서 Azure RBAC를 사용합니다.
• 데이터 평면을 사용하면 데이터 추가, 삭제, 수정을 포함하여 키 자격 증명 모음 및 관리되는 HSM에 저장된 데이터를 사용할 수 있습니다. 자격 증명 모음의 경우 저장되는 데이터에는 키, 비밀 및 인증서가 포함될 수 있습니다. 관리되는 HSM의 경우 저장되는 데이터는 암호화 키로만 제한됩니다. 권한 부여를 위해 데이터 평면은 키 자격 증명 모음을 통해 Key Vault 액세스 정책 및 Azure RBAC를 데이터 평면 작업에 사용하거나 관리되는 HSM을 통해 관리되는 HSM 로컬 RBAC를 사용합니다.

Azure 구독에서 키 자격 증명 모음 또는 관리되는 HSM을 만들면 구독의 Microsoft Entra 테넌트와 자동으로 연결됩니다. 두 평면의 모든 호출자는 키 자격 증명 모음 또는 관리되는 HSM에 액세스하기 위해 이 테넌트에 등록하고 인증을 받아야 합니다.

액세스 권한을 제어하고 Azure Key Vault 서비스에서 자세한 활동 로그를 추출할 수 있습니다. Azure Key Vault에서 로그하는 정보는 다음과 같습니다.

• 인증된 모든 REST API 요청(실패한 요청 포함)
  • 키 자격 증명 모음에 대한 작업(예: 액세스 정책 만들기, 삭제, 설정 등)
  • 키 자격 증명 모음의 키 및 비밀에 대한 작업(예: a) 키 또는 비밀 만들기, 수정 또는 삭제, b) 키 서명, 확인, 암호화 등)
• 인증되지 않은 요청(예: 전달자 토큰이 없거나, 형식이 잘못되었거나, 만료되었거나, 유효하지 않은 토큰이 있는 요청)

참고 항목

Azure Key Vault를 사용하면 키 자격 증명 모음 및 관리되는 HSM에 액세스하는 방법과 시기, 액세스하는 사용자를 모니터링할 수 있습니다.

추가 리소스:

• Azure Key Vault에 대한 모니터링 및 경고 구성
• Azure Key Vault에 로깅 사용
• Azure Key Vault 로그에 대한 스토리지 계정을 보호하는 방법

또한 Azure Monitor에서 Azure Key Vault 솔루션을 사용하여 Key Vault 로그를 검토할 수 있습니다. 이 솔루션을 사용하려면 Key Vault 진단 로깅을 사용하도록 설정하고 진단을 Log Analytics 작업 영역으로 보내야 합니다. 이 솔루션을 사용하면 Azure Blob Storage에 로그를 쓸 필요가 없습니다.

참고 항목

Azure Key Vault 보안 권장 사항에 대한 전체 목록은 Key Vault에 대한 Azure 보안 기준을 참조하세요.

Vault

자격 증명 모음은 가장 일반적인 클라우드 애플리케이션 시나리오에 적합한 저렴하고, 배포하기 쉽고, 영역 복원력(사용 가능한 경우) 및 고가용성을 갖춘 다중 테넌트 키 관리 솔루션을 제공합니다. 자격 증명 모음은 비밀, 키 및 인증서를 저장하고 보호할 수 있습니다. 소프트웨어 보호(표준 계층) 또는 HSM 보호(프리미엄 계층) 중 하나일 수 있습니다. 표준 계층과 프리미엄 계층을 비교하려면 Azure Key Vault 가격 책정 페이지를 참조하세요. 소프트웨어 보호 비밀, 키 및 인증서는 업계 표준 알고리즘 및 키 길이를 사용하여 Azure에서 보호됩니다. 추가 보증이 필요한 경우 다중 테넌트 HSM으로 보호되는 자격 증명 모음에서 비밀, 키 및 인증서를 보호하도록 선택할 수 있습니다. 해당 HSM은 FIPS 140 표준에 따라 유효성이 검사되었으며 물리적 변조 증거 및 역할 기반 인증에 대한 요구 사항을 포함하는 전체 보안 수준 2 등급에 속합니다.

자격 증명 모음을 사용하면 HSM에서 사용자 고유의 키를 제어하고 이러한 키를 사용하여 다양한 Azure 서비스에 대한 미사용 데이터를 암호화할 수 있는 CMK(고객 관리형 키)를 지원할 수 있습니다. 앞에서 설명한 대로 HSM에서 암호화 키를 가져오거나 생성하여 키가 HSM 경계를 벗어나지 않도록 함으로써 BYOK(Bring Your Own Key) 시나리오를 지원할 수 있습니다.

Key Vault는 TLS(전송 계층 보안) 인증서를 포함하여 자격 증명 모음에서 인증서 요청 및 갱신을 처리할 수 있으므로 지원되는 공용 인증 기관에서 인증서를 등록하고 자동으로 갱신할 수 있습니다. Key Vault 인증서 지원은 키를 기반으로 하여 빌드되고 자동화된 갱신 기능을 제공하는 X.509 인증서 관리를 제공합니다. 인증서 소유자는 Azure Key Vault를 통하거나 기존 인증서를 가져와서 인증서를 만들 수 있습니다. 자체 서명된 인증서와 인증 기관에서 생성한 인증서가 모두 지원됩니다. 또한 Key Vault 인증서 소유자는 프라이빗 키와 상호 작용하지 않고 X.509 인증서의 안전한 저장 및 관리를 구현할 수 있습니다.

키 자격 증명 모음을 리소스 그룹에 만들 때 Microsoft Entra ID를 사용하여 액세스를 관리할 수 있습니다. 그러면 적절한 Azure 역할을 할당하여 특정 범위 수준에서 액세스 권한을 부여할 수 있습니다. 예를 들어 사용자에게 키 자격 증명 모음을 관리할 수 있는 액세스 권한을 부여하려면 구독, 리소스 그룹 또는 특정 리소스를 포함한 특정 범위의 사용자에게 미리 정의된 키 자격 증명 모음 기여자 역할을 할당할 수 있습니다.

Important

키 자격 증명 모음에 대한 기여자 역할 액세스 권한이 있는 사용자는 엄격하게 제어해야 합니다. 사용자에게 키 자격 증명 모음 관리 평면에 대한 기여자 권한이 있는 경우 해당 사용자는 키 자격 증명 모음 액세스 정책을 설정하여 데이터 평면에 대한 액세스 권한을 얻을 수 있습니다.

추가 리소스:

• 키 자격 증명 모음에 대한 액세스를 보호하는 방법.

관리형 HSM

관리되는 HSM은 암호화 키를 저장하고 관리하기 위한 서비스로서 고가용성 및 영역 복원력(사용 가능한 경우)을 갖춘 완전 관리형 단일 테넌트 HSM을 제공합니다. 높은 값의 키를 처리하는 애플리케이션 및 사용 시나리오에 가장 적합합니다. 또한 가장 엄격한 보안, 규정 준수 및 규제 요구 사항을 충족하는 데 도움이 됩니다. 관리되는 HSM은 FIPS 140 수준 3 유효성이 검사된 HSM을 사용하여 암호화 키를 보호합니다. 각 관리되는 HSM 풀은 사용자가 제어하고 다른 고객에게 속한 인스턴스로부터 암호화 방식으로 격리된 자체 보안 도메인을 갖춘 격리된 단일 테넌트 인스턴스입니다. 암호화 격리는 암호화된 코드와 데이터를 제공하여 암호화 키에 대한 제어를 보장하는 Intel SGX(Software Guard Extensions) 기술을 사용합니다.

관리되는 HSM이 만들어지면 요청자는 데이터 평면 관리자 목록도 제공합니다. 이러한 관리자만 관리되는 HSM 데이터 평면에 액세스하여 주요 작업을 수행하고 데이터 평면 역할 할당(관리되는 HSM 로컬 RBAC)을 관리할 수 있습니다. 관리 평면과 데이터 평면 모두에 대한 권한 모델은 동일한 구문을 사용하지만, 권한은 서로 다른 수준에서 적용되고 역할 할당에서 서로 다른 범위를 사용합니다. 관리 평면 Azure RBAC는 Azure Resource Manager에서 적용되지만, 데이터 평면 관리되는 HSM 로컬 RBAC는 관리되는 HSM 자체에서 적용됩니다.

Important

키 자격 증명 모음과 달리 사용자에게 관리되는 HSM에 대한 관리 평면 액세스 권한을 부여해도 액세스 키에 대한 데이터 평면 또는 데이터 평면 역할 할당 관리되는 HSM 로컬 RBAC에 대한 액세스 권한이 부여되지 않습니다. 이 격리는 관리되는 HSM에 저장된 키에 대한 액세스에 영향을 미치는 부주의한 권한 확장을 방지하기 위해 계획적으로 구현됩니다.

앞에서 설명한 대로 관리되는 HSM은 온-프레미스 HSM에서 생성된 키 가져오기를 지원하여 키가 HSM 보호 경계를 벗어나지 않도록 합니다. 이는 BYOK(Bring Your Own Key) 시나리오로도 알려져 있습니다. 관리되는 HSM은 Azure Storage, Azure SQL Database, Azure Information Protection 등과 같은 Azure 서비스와의 통합을 지원합니다. 관리되는 HSM에서 작동하는 Azure 서비스의 전체 목록은 데이터 암호화 모델을 참조하세요.

관리되는 HSM을 사용하면 설정된 Azure Key Vault API 및 관리 인터페이스를 사용할 수 있습니다. 다중 테넌트 자격 증명 모음 또는 단일 테넌트 관리되는 HSM 과 같은 키 관리 솔루션에 관계없이 동일한 애플리케이션 개발 및 배포 패턴을 모든 애플리케이션에 사용할 수 있습니다.

컴퓨팅 격리

Microsoft Azure 컴퓨팅 플랫폼은 컴퓨터 가상화를 기반으로 합니다. 이 방법은 PaaS 작업자 역할 또는 IaaS 가상 머신에 배포된 코드가 Windows Server Hyper-V 하이퍼바이저에서 호스트하는 가상 머신에서 실행됨을 의미합니다. 노드라고도 하는 각 Azure 물리적 서버에는 그림 4와 같이 하드웨어를 통해 직접 실행되고 노드를 다양한 수의 게스트 VM(가상 머신)으로 나누는 유형 1 하이퍼바이저가 있습니다. 각 노드에는 루트 VM이라고도 하는 하나의 특수 호스트 VM이 있습니다. 이 호스트 VM은 공격 표면을 줄이고 노드 관리에 필요한 구성 요소만 포함하기 위해 제거되는 최신 Windows Server의 사용자 지정되고 강화된 버전인 호스트 OS를 실행합니다. 게스트 VM에서 루트 VM을 격리하고 게스트 VM을 서로 격리하는 것은 Microsoft 온라인 설명서에서 설명한 대로 Azure 컴퓨팅 격리를 기반으로 하는 Azure 보안 아키텍처의 핵심 개념입니다.

그림 4. 하이퍼바이저, 루트 VM 및 게스트 VM 격리

VM을 호스트하는 물리적 서버는 클러스터로 그룹화되며 FC(패브릭 컨트롤러)라고 하는 스케일 아웃되고 중복된 플랫폼 소프트웨어 구성 요소에서 독립적으로 관리됩니다. 각 FC는 제어되는 하드웨어의 상태 프로비전 및 모니터링을 포함하여 클러스터에서 실행되는 VM의 수명 주기를 관리합니다. 예를 들어 서버가 실패했다고 확인되면 FC에서 VM 인스턴스를 정상 서버에 다시 만들어야 합니다. 또한 인프라 리소스를 테넌트 워크로드에 할당하고 호스트에서 가상 머신으로의 단방향 통신을 관리합니다. 컴퓨팅 인프라를 클러스터로 분할하면 FC 수준에서 오류를 격리하고 특정 오류 클래스가 발생하는 클러스터 외부의 서버에 영향을 주지 않도록 방지합니다.

FC는 Azure 컴퓨팅 플랫폼의 핵심이고, 호스트 에이전트는 해당 프록시로서 FC가 사용자와 Azure 클라우드 서비스에서 사용하는 가상 머신을 배포, 모니터링 및 관리할 수 있도록 서버를 플랫폼에 통합합니다. 하이퍼바이저/호스트 OS 페어링은 게스트 VM의 강력한 격리를 제공하기 위해 Microsoft Hyper-V에 대한 보안 중심 투자를 포함하여 운영 체제 보안에 대한 수십 년간의 Microsoft 경험을 활용합니다. 하이퍼바이저 격리는 하이퍼바이저에서 적용되는 강력하게 정의된 보안 경계에 대한 보증, 심층 방어 익스플로잇 완화 및 강력한 보안 보증 프로세스를 포함하여 이 섹션의 뒷부분에서 설명합니다.

관리 네트워크 격리

그림 5와 같이 각 컴퓨팅 하드웨어 클러스터에는 3개의 VLAN(가상 Local Area Network)이 있습니다.

• 기본 VLAN - 신뢰할 수 없는 고객 노드를 상호 연결합니다.
• FC(패브릭 컨트롤러) VLAN - 신뢰할 수 있는 FC 및 지원 시스템을 포함합니다. 그리고
• 디바이스 VLAN - 신뢰할 수 있는 네트워크 및 기타 인프라 디바이스를 포함합니다.

FC VLAN에서 기본 VLAN으로의 통신은 허용되지만 기본 VLAN에서 FC VLAN으로의 통신은 시작할 수 없습니다. FC VLAN에서 기본 VLAN으로의 브리지는 전반적인 복잡성을 줄이고 네트워크의 안정성/복원성을 향상시키는 데 사용됩니다. 연결은 명령을 신뢰할 수 있고 성공적으로 라우팅하도록 여러 가지 방법으로 보호됩니다.

• FC에서 FA(패브릭 에이전트)로의 통신은 단방향이며 인증서를 통한 상호 인증이 필요합니다. FA는 FC의 요청에만 응답하는 TLS로 보호되는 서비스를 구현합니다. FC 또는 기타 권한 있는 내부 노드에 대한 연결은 시작할 수 없습니다.
• FC는 에이전트 서비스의 응답을 신뢰할 수 없는 것처럼 처리합니다. 에이전트와의 통신은 각 물리적 노드의 방화벽 규칙과 경계 게이트웨이의 회람 규칙을 사용하여 권한 있는 IP 주소 세트로 더 제한됩니다.
• 제한은 고객 VM이 라우팅되는 네트워크 및 관리 명령을 포화시킬 수 없도록 하는 데 사용됩니다.

또한 기본 VLAN에서 디바이스 VLAN으로의 통신은 차단됩니다. 이렇게 하면 고객 코드를 실행하는 노드가 손상되더라도 FC 또는 디바이스 VLAN의 노드를 공격할 수 없습니다.

이러한 제어는 하이퍼바이저에 대한 관리 콘솔의 액세스가 항상 유효하고 사용할 수 있도록 보장합니다.

그림 5. VLAN 격리

하이퍼바이저와 호스트 OS는 네트워크 패킷 필터를 제공하여 신뢰할 수 없는 VM에서 스푸핑된 트래픽을 생성하거나, 주소가 지정되지 않은 트래픽을 받거나, 트래픽을 보호된 인프라 보내거나 받을 수 없도록 보장합니다. 기본적으로 VM이 만들어지면 트래픽을 차단한 다음, FC 에이전트에서 권한이 부여된 트래픽을 허용하는 규칙 및 예외를 추가하도록 패킷 필터를 구성합니다. 네트워크 트래픽 격리 및 테넌트 트래픽 분리에 대한 자세한 내용은 네트워킹 격리 섹션에서 제공합니다.

관리 콘솔 및 관리 평면

Azure 관리 콘솔 및 관리 평면은 테넌트 처리를 보호하고 격리하기 위해 최소 권한의 엄격한 보안 아키텍처 원칙을 따릅니다.

• MC(관리 콘솔) – Azure 클라우드의 MC는 Azure Portal GUI 및 Azure Resource Manager API 계층으로 구성됩니다. 둘 다 사용자 자격 증명을 사용하여 모든 작업을 인증하고 권한을 부여합니다.
• MP(관리 평면) – 이 계층은 실제 관리 작업을 수행하며 CRP(컴퓨팅 리소스 공급자), FC(패브릭 컨트롤러), FA(패브릭 에이전트) 및 통신 서비스를 제공하는 자체 하이퍼바이저 에이전트가 있는 기본 하이퍼바이저로 구성됩니다. 이러한 계층은 모두 작업을 수행하는 데 필요한 최소 권한이 부여된 시스템 컨텍스트를 사용합니다.

Azure FC는 인프라 리소스를 테넌트에 할당하고 호스트 OS에서 게스트 VM으로의 단방향 통신을 관리합니다. Azure FC의 VM 배치 알고리즘은 매우 정교하며 예측이 거의 불가능합니다. FA는 호스트 OS에 상주하며 테넌트 VM을 관리합니다. 그림 4와 같이 Azure 하이퍼바이저, 호스트 OS 및 FA, 고객 VM의 컬렉션은 컴퓨팅 노드를 구성합니다. FC는 컴퓨팅 노드 외부에 있지만 FC는 FA를 관리합니다. 컴퓨팅 및 스토리지 클러스터를 관리하는 별도의 FC가 있습니다. MC에서 실행하는 동안 애플리케이션의 구성 파일을 업데이트하는 경우 MC는 CRP를 통해 FC와 통신하고, FC는 FA와 통신합니다.

CRP는 Azure Compute에 대한 프런트 엔드 서비스이며, Azure Resource Manager를 통해 일관된 컴퓨팅 API를 공개하므로 간단한 템플릿을 통해 가상 머신 리소스 및 확장을 만들고 관리할 수 있습니다.

다양한 구성 요소 간의 통신(예: Azure Resource Manager와 CRP 간, CRP와 FC 간, FC와 하이퍼바이저 에이전트 간)은 모두 서로 다른 ID와 권한 세트를 사용하는 서로 다른 통신 채널에서 작동합니다. 이 설계는 일반적인 최소 권한 모델을 따르므로 단일 계층이 손상되면 더 많은 작업이 방지됩니다. 별도의 통신 채널을 통해 통신에서 체인의 어떤 계층도 우회할 수 없도록 합니다. 그림 6에서는 사용자의 Microsoft Entra ID에 대한 OAuth 2.0 인증에서 시작된 하이퍼바이저와 상호 작용하기 위해 MC와 MP가 Azure 클라우드 내에서 안전하게 통신하는 방법을 보여줍니다.

그림 6. 보안 관리 흐름에 대한 관리 콘솔과 관리 평면의 상호 작용

모든 관리 명령은 RSA 서명 인증서 또는 JWT(JSON Web Token)를 통해 인증됩니다. 인증 및 명령 채널은 전송 중 데이터 암호화 섹션에서 설명한 대로 TLS(전송 계층 보안) 1.2를 통해 암호화됩니다. 서버 인증서는 TLS 연결을 별도의 권한 부여 메커니즘이 사용되는 인증 공급자(예: Microsoft Entra ID 또는 dSTS(데이터 센터 보안 토큰 서비스))에 제공하는 데 사용됩니다. dSTS는 Microsoft 데이터 센터로 격리되고 서비스 수준 통신에 사용되는 Microsoft Entra ID와 같은 토큰 공급자입니다.

그림 6에서는 가상 머신을 중지하는 사용자 명령에 해당하는 관리 흐름을 보여줍니다. 표 1에 열거된 단계에서는 다른 관리 명령에도 동일한 방식으로 적용되며 동일한 암호화 및 인증 흐름을 사용합니다.

표 1. 다양한 MC, MP 구성 요소와 관련된 관리 흐름

단계	설명	인증	암호화
1.	사용자가 자격 증명을 제공하여 Microsoft Entra ID를 통해 인증하고, 토큰이 발급됩니다.	사용자 자격 증명	TLS 1.2
2.	브라우저에서 사용자를 인증하기 위해 토큰을 Azure Portal에 제공합니다. Azure Portal에서 토큰 서명과 유효한 서명 키를 사용하여 토큰을 확인합니다.	JSON Web Token(Microsoft Entra ID)	TLS 1.2
3.	사용자가 Azure Portal에서 "VM 중지" 요청을 발급합니다. Azure Portal에서 "VM 중지" 요청을 Azure Resource Manager에 보내고, Microsoft Entra ID에서 제공한 사용자 토큰을 제시합니다. Azure Resource Manager에서 토큰 서명과 유효한 서명 키를 사용하여 토큰을 확인하고 사용자에게 요청된 작업을 수행할 수 있는 권한이 있는지 확인합니다.	JSON Web Token(Microsoft Entra ID)	TLS 1.2
4.	Azure Resource Manager에서 Azure Resource Manager에 있는 클라이언트 인증서를 기반으로 하여 dSTS 서버에서 토큰을 요청하여 dSTS에서 올바른 ID 및 역할을 사용하여 JSON Web Token을 부여할 수 있도록 합니다.	클라이언트 인증서	TLS 1.2
5.	Azure Resource Manager에서 요청을 CRP에 보냅니다. 호출은 dSTS의 Azure Resource Manager 시스템 ID를 나타내는 JSON Web Token을 사용하여 OAuth를 통해 인증되므로 사용자에서 시스템 컨텍스트로 전환됩니다.	JSON Web Token(dSTS)	TLS 1.2
6.	CRP가 요청에 대한 유효성을 검사하고 요청을 완료할 수 있는 패브릭 컨트롤러를 결정합니다. CRP가 명령의 대상인 특정 FC(패브릭 컨트롤러)에 연결할 수 있도록 클라이언트 인증서를 기반으로 하여 dSTS에서 인증서를 요청합니다. CRP가 FC와 통신할 수 있는 경우 토큰은 해당 특정 FC에만 권한을 부여합니다.	클라이언트 인증서	TLS 1.2
7.	그런 다음, CRP가 dSTS에서 만든 JSON Web Token을 사용하여 올바른 요청을 FC에 보냅니다.	JSON Web Token(dSTS)	TLS 1.2
8.	그런 다음, FC에서 명령이 허용되고 신뢰할 수 있는 원본에서 제공되는지 확인합니다. 그런 다음 대상 FA 및 FC에 고유한 인증서를 사용하여 명령을 실행할 수 있는 클러스터의 올바른 FA(패브릭 에이전트)에 대한 보안 TLS 연결을 설정합니다. 보안 연결이 설정되면 명령이 전송됩니다.	상호 인증서	TLS 1.2
9.	FA에서 명령이 허용되고 신뢰할 수 있는 원본에서 제공되는지 다시 확인합니다. 유효성이 검사되면 FA에서 상호 인증서 인증을 사용하여 보안 연결을 설정하고 명령을 FA에서만 액세스할 수 있는 하이퍼바이저 에이전트에 실행합니다.	상호 인증서	TLS 1.2
10.	호스트의 하이퍼바이저 에이전트에서 내부 호출을 실행하여 VM을 중지합니다.	시스템 컨텍스트	해당 없음

시스템 상태를 모니터링하고 보안 이벤트 및 패턴을 추적할 수 있도록 이 섹션에서 식별된 프로세스의 모든 단계를 통해 생성하여 각 노드의 FC 및 FA에 보내는 명령은 로컬 감사 로그에 기록되고 스트림 처리를 위해 여러 분석 시스템에 배포됩니다. 추적에는 성공적으로 처리된 이벤트와 잘못된 이벤트가 포함됩니다. 잘못된 요청은 변칙을 검색하기 위해 침입 탐지 시스템에서 처리됩니다.

논리적 격리 구현 옵션

Azure는 다음을 포함한 다계층 접근 방식을 통해 컴퓨팅 처리를 격리합니다.

• 하이퍼바이저 격리 - 별도의 가상 머신과 Azure 하이퍼바이저 격리를 사용하여 확실하게 암호화된 격리를 제공하는 서비스를 위한 것입니다. 예: App Service, Azure Container Instances, Azure Databricks, Azure Functions, Azure Kubernetes Service, Azure Machine Learning, Cloud Services, Data Factory, Service Fabric, Virtual Machines, Virtual Machine Scale Sets
• Drawbridge 격리 - Drawbridge에서 제공하는 격리를 사용하여 확실하게 암호화된 격리를 동일한 가상 머신에서 실행되는 워크로드에 제공하는 서비스를 위한 것이며 VM 내에 구현됩니다. 이러한 서비스는 고객 코드를 사용하여 작은 처리 단위를 제공합니다. 보안 격리를 제공하기 위해 Drawbridge는 pico-process 내에서 경량 버전의 Windows 커널(라이브러리 OS)과 함께 사용자 프로세스를 실행합니다. pico-process는 호스트 시스템의 서비스 또는 리소스에 직접 액세스할 수 없는 보안 프로세스입니다. 예: Automation, Azure Database for MySQL, Azure Database for PostgreSQL, Azure SQL Database, Azure Stream Analytics
• 사용자 컨텍스트 기반 격리 - Microsoft 제어 코드로만 구성되고 고객 코드 실행이 허용되지 않는 서비스를 위한 것입니다. 예: API Management, Application Gateway, Microsoft Entra ID, Azure Backup, Azure Cache for Redis, Azure DNS, Azure Information Protection, Azure IoT Hub, Azure Key Vault, Azure Portal, Azure Monitor(Log Analytics 포함), 클라우드용 Microsoft Defender, Azure Site Recovery, Container Registry, Content Delivery Network, Event Grid, Event Hubs, Load Balancer, Service Bus, Storage, Virtual Network, VPN Gateway, Traffic Manager

이러한 논리적 격리 옵션은 이 섹션의 나머지 부분에서 설명합니다.

하이퍼바이저 격리

Azure의 하이퍼바이저 격리는 Microsoft Hyper-V 기술을 기반으로 하며, 이를 통해 Azure 하이퍼바이저 기반 격리에서 운영 체제 보안 분야에 대한 수십 년간의 Microsoft 경험과 Hyper-V 기술에 대한 가상 머신 격리 투자를 활용할 수 있습니다. NIAP(National Information Assurance Partnership) CCEVS(Common Criteria Evaluation and Validation Scheme) 보고서(예: 여기서 설명하는 2021년 2월에 게시된 보고서)를 포함하여 Hyper-V 보안 기능에 대한 독립적인 타사 평가 보고서를 검토할 수 있습니다.

TOE(평가 대상)는 Microsoft Windows Server, Microsoft Windows 10 버전 1909(2019년 11월 업데이트) 및 Microsoft Windows Server 2019(버전 1809) Hyper-V("Windows")로 구성되었습니다. 보고서에서 설명한 대로 TOE에서 적용하는 보안 정책은 다음과 같습니다.

• 보안 감사 – Windows에는 감사 데이터를 수집하고, 감사 로그를 검토하고, 감사 로그가 오버플로되지 않도록 보호하고, 감사 로그에 대한 액세스를 제한하는 기능이 있습니다. 시스템에서 생성되는 감사 정보에는 이벤트 날짜 및 시간, 이벤트를 생성한 사용자 ID, 기타 이벤트 관련 데이터가 포함됩니다. 권한 있는 관리자는 감사 레코드를 검토, 검색 및 정렬할 수 있습니다. 권한 있는 관리자는 여러 특성에 따라 감사할 잠재적으로 감사 가능한 이벤트를 포함하거나 제외하도록 감사 시스템을 구성할 수도 있습니다. 이 평가의 컨텍스트에서 보호 프로필 요구 사항에는 감사 이벤트 생성, 저장된 감사 레코드에 대한 권한 있는 검토 및 감사 이벤트 항목에 대한 보안 스토리지 제공이 포함됩니다.
• 암호화 지원 – Windows는 암호화/암호 해독, 암호화 서명, 암호화 해싱 및 난수 생성을 지원하는 유효성이 검사된 암호화 기능을 제공합니다. Windows는 IPsec, TLS 및 HTTPS 프로토콜 구현을 지원하기 위해 이러한 기능을 구현합니다. 또한 Windows는 가상화된 운영 체제에서 강력한 암호화를 구현할 수 있도록 게스트 VM에서 엔트로피 데이터에 액세스할 수 있도록 합니다.
• 사용자 데이터 보호 – Windows는 게스트 VM에서 특정 컴퓨팅 서비스를 사용할 수 있도록 하지만, 이러한 서비스에 대한 액세스가 적절한 기준에 따라 부여되고 이러한 인터페이스로 인해 게스트 VM과 Windows 간 또는 여러 게스트 VM 간에 무단 데이터 유출이 발생하지 않도록 하는 수단을 구현합니다.
• 식별 및 인증 – Windows는 신뢰할 수 있는 프로토콜에 필요한 X.509 인증서를 포함하여 몇 가지 사용자 인증 방법을 제공합니다. Windows는 암호 강도 메커니즘을 구현하고 무차별 암호 대입 추측(암호, PIN)이 적용되는 방법을 사용하여 과도한 인증 시도 실패로 인해 잠금 동작이 발생하도록 합니다.
• 보안 관리 – Windows에는 보안 정책을 관리하는 여러 기능이 포함되어 있습니다. 관리 기능에 대한 액세스는 관리 역할을 통해 적용됩니다. 또한 Windows에는 관리 네트워크와 운영 네트워크의 분리를 지원하고 게스트 VM 간의 데이터 공유를 금지하는 기능도 있습니다.
• TSF(TOE 보안 기능) 보호 – 게스트 VM에 저장된 데이터에 대한 무단 액세스를 얻기 위한 플랫폼으로 사용될 수 없고, TSF와 게스트 VM의 무결성이 유지되며, 잘 문서화된 인터페이스를 통해서만 게스트 VM에 액세스할 수 있도록 Windows는 다양한 자체 보호 메커니즘을 구현합니다.
• TOE 액세스 – 이 평가의 컨텍스트에서 Windows에서는 권한 있는 관리자가 로그온 대화 상자 앞에 로그온 배너를 표시하도록 시스템을 구성할 수 있습니다.
• 신뢰할 수 있는 경로/채널 – Windows는 원격 관리, 감사 데이터를 운영 환경으로 전송, 관리 및 운영 네트워크 분리를 위해 IPsec, TLS, HTTPS 신뢰할 수 있는 채널과 경로를 구현합니다.

자세한 내용은 타사 인증 보고서에서 확인할 수 있습니다.

중요한 하이퍼바이저 격리는 다음을 통해 제공됩니다.

• 하이퍼바이저에서 적용하는 강력하게 정의된 보안 경계
• 심층 방어 익스플로잇 완화
• 강력한 보안 보증 프로세스

이러한 기술은 이 섹션의 나머지 부분에서 설명합니다. 이러한 기술을 사용하면 Azure 하이퍼바이저에서 다중 테넌트 클라우드의 테넌트 분리에 대한 강력한 보안 보증을 제공할 수 있습니다.

강력하게 정의된 보안 경계

그림 7과 같이 코드는 하이퍼바이저 VM에서 실행되며 하이퍼바이저에서 적용하는 보안 경계의 이점을 활용할 수 있습니다. Azure 하이퍼바이저는 Microsoft Hyper-V 기술을 기반으로 합니다. Azure 노드를 노드의 루트 파티션에서 실행되는 호스트 OS와 병렬로 작동하는 OS(운영 체제) 및 애플리케이션을 로드할 수 있는 별도의 주소 공간이 있는 다양한 수의 게스트 VM으로 나눕니다.

그림 7. Azure 하이퍼바이저를 사용하는 컴퓨팅 격리(온라인 용어집 참조)

Azure 하이퍼바이저는 마이크로 커널처럼 작동하여 VSC(가상화 서비스 클라이언트)를 사용하는 게스트 VM의 모든 하드웨어 액세스 요청을 처리하기 위해 VMBus라는 공유 메모리 인터페이스를 사용하여 호스트 OS에 전달합니다. 호스트 OS는 사용자가 시스템에 대한 원시 읽기/쓰기/실행 액세스 권한을 얻지 못하도록 방지하고 시스템 리소스 공유 위험을 완화하는 VSP(가상화 서비스 공급자)를 사용하여 하드웨어 요청을 프록시합니다. 호스트 OS라고도 하는 권한 있는 루트 파티션은 시스템의 물리적 디바이스와 주변 장치(예: 스토리지 컨트롤러, GPU, 네트워킹 어댑터 등)에 직접 액세스할 수 있습니다. 호스트 OS를 사용하면 가상 디바이스를 각 게스트 파티션에 공개하여 게스트 파티션에서 이러한 물리적 디바이스의 사용을 공유할 수 있습니다. 따라서 게스트 파티션에서 실행되는 운영 체제는 루트 파티션에서 실행되는 VSP에서 제공하는 가상화된 주변 장치에 액세스할 수 있습니다. 이러한 가상 디바이스 표현은 다음 세 가지 형식 중 하나를 사용할 수 있습니다.

• 에뮬레이트된 디바이스 – 호스트 OS는 해당 물리적 디바이스에서 제공하는 것과 동일한 인터페이스를 사용하여 가상 디바이스를 공개할 수 있습니다. 이 경우 게스트 파티션의 운영 체제는 실제 시스템에서 실행되는 경우와 동일한 디바이스 드라이버를 사용합니다. 호스트 OS는 게스트 파티션에 대한 물리적 디바이스의 동작을 에뮬레이트합니다.
• 반가상화된 디바이스 – 호스트 OS는 호스트 OS와 게스트 간의 VMBus 공유 메모리 인터페이스를 사용하여 가상화 관련 인터페이스에서 가상 디바이스를 공개할 수 있습니다. 이 모델에서 게스트 파티션은 가상화된 인터페이스를 구현하도록 특별히 설계된 디바이스 드라이버를 사용합니다. 이러한 반가상화된 디바이스를 "가상" 디바이스라고도 합니다.
• 하드웨어 가속 디바이스 – 호스트 OS는 실제 하드웨어 주변 장치를 게스트 파티션에 직접 공개할 수 있습니다. 이 모델은 게스트 파티션에서 호스트 OS를 통하지 않고 하드웨어 디바이스 리소스에 직접 액세스할 수 있으므로 게스트 파티션에서 높은 I/O 성능을 허용합니다. Azure 가속화된 네트워킹은 하드웨어 가속 디바이스의 예입니다. 이 모델의 격리는 I/O MMU(입출력 메모리 관리 단위)를 사용하여 주소 공간을 제공하고 각 파티션에 대한 격리를 중단합니다.

호스트 CPU의 가상화 확장을 사용하면 Azure 하이퍼바이저에서 파티션 간 격리를 적용할 수 있습니다. 하이퍼바이저 격리를 위한 하드웨어 구성 요소를 제공하는 기본 CPU 기능은 다음과 같습니다.

• 2차 수준 주소 변환 – 하이퍼바이저는 CPU의 메모리 관리 단위(MMU)에서 제공하는 2차 수준 페이지 테이블을 사용하여 파티션에서 액세스할 수 있는 메모리 리소스를 제어합니다. CPU의 MMU는 하이퍼바이저에서 제어하는 2차 수준 주소 변환을 사용하여 다음을 통해 수행되는 메모리 액세스에 대한 보호를 적용합니다.
  • CPU(파티션 컨텍스트에서 실행되는 경우)
  • I/O 디바이스(게스트 파티션에서 직접 액세스)
• CPU 컨텍스트 – 하이퍼바이저는 CPU의 가상화 확장을 사용하여 게스트 파티션이 실행되는 동안 액세스할 수 있는 권한과 CPU 컨텍스트를 제한합니다. 또한 하이퍼바이저는 이러한 기능을 통해 CPU를 여러 파티션 간에 공유할 때 상태를 저장하고 복원하여 파티션 간에 CPU 상태를 격리합니다.

Azure 하이퍼바이저는 이러한 프로세서 기능을 광범위하게 사용하여 파티션 간 격리를 제공합니다. 투기적인 부채널 공격이 출현함으로써 이러한 프로세서 격리 기능 중 일부에서 잠재적인 약점이 확인되었습니다. 다중 테넌트 아키텍처에서 서로 다른 테넌트에 대한 VM 간 공격에는 두 단계가 포함됩니다. 먼저 악의적 사용자가 제어하는 VM을 희생자 VM 중 하나와 동일한 호스트에 배치한 다음, 논리적 격리 경계를 위반하여 부채널 공격을 수행하는 것입니다. Azure는 논리적 격리를 위해 메모리 및 프로세스 분리를 적용하는 고급 VM 배치 알고리즘과 하이퍼바이저에서 암호화 확실성을 갖춘 보안 네트워크 트래픽 라우팅을 사용하여 두 위협 벡터로부터 보호합니다. 이 문서의 뒷부분에 있는 가상화 기술의 취약성 악용 섹션에서 설명한 대로 Azure 하이퍼바이저는 하이퍼바이저 내에서 직접 강력한 격리를 제공하여 다양하고 정교한 부채널 공격을 완화하는 데 도움이 되도록 설계되었습니다.

Azure 하이퍼바이저에서 정의한 보안 경계는 공유 하드웨어에서 코드, 데이터 및 리소스를 잠재적으로 적대적인 다중 테넌트 간에 강력하게 구분하기 위한 기본 수준 격리 기본 요소를 제공합니다. 이러한 격리 기본 요소는 다음을 포함한 다중 테넌트 리소스 격리 시나리오를 만드는 데 사용됩니다.

• 잠재적으로 적대적인 게스트 간 네트워크 트래픽 격리 – VNet(Virtual Network)은 나중에 테넌트 네트워크 트래픽 분리 섹션에서 설명한 대로 기본 설계의 일환으로 테넌트 간 네트워크 트래픽 격리를 제공합니다. VNet은 VNet 내의 VM에서 서로 간에만 통신할 수 있는 격리 경계를 형성합니다. 적절한 정책이 구성되지 않은 VNet 또는 외부 발신기 내에서 VM으로 향하는 모든 트래픽은 호스트에서 삭제되고 VM에 전달되지 않습니다.
• 암호화 키 및 암호화 자료에 대한격리 – 하드웨어 보안 관리자 또는 특수 키 스토리지사용하여 격리 기능을 더 보강할 수 있습니다(예: Azure Key Vault통해 FIPS 140 유효성이 검사된 HSM(하드웨어 보안 모듈)에 암호화 키 저장).
• 시스템 리소스 예약 – Azure 설계에는 컴퓨팅, 메모리, 스토리지, 직접 및 반가상화 디바이스 액세스의 보장된 가용성과 구분이 포함됩니다.

Azure 하이퍼바이저는 표 2에 나와 있는 보안 목표를 충족합니다.

표 2. Azure 하이퍼바이저 보안 목표

목표	원본
격리	Azure 하이퍼바이저 보안 정책은 VM 간 정보 전송을 요구하지 않습니다. 이 정책에는 메모리, 디바이스, 네트워킹, 관리되는 리소스(예: 지속형 데이터)를 격리하기 위한 VMM(Virtual Machine Manager) 및 하드웨어의 기능이 필요합니다.
VMM 무결성	무결성은 가상화 시스템의 핵심 보안 목표입니다. 시스템 무결성을 달성하기 위해 각 하이퍼바이저 구성 요소의 무결성이 설정되고 유지됩니다. 이 목표는 VM 내에서 실행되는 물리적 플랫폼 또는 소프트웨어의 무결성이 아니라 하이퍼 바이저 자체의 무결성에만 해당됩니다.
플랫폼 무결성	하이퍼바이저의 무결성은 사용하는 하드웨어와 소프트웨어의 무결성에 따라 달라집니다. 하이퍼바이저는 플랫폼의 무결성을 직접 제어할 수 없지만 Azure는 Cerberus 보안 마이크로 컨트롤러와 같은 하드웨어 및 펌웨어 메커니즘을 사용하여 기본 플랫폼 무결성을 보호합니다. 이에 따라 플랫폼 무결성이 손상되면 VMM과 게스트가 실행되지 않습니다.
관리 액세스	관리 기능은 권한 있는 관리자만 실행하며, 세분화된 역할 액세스 제어 메커니즘에서 적용되는 최소 권한 원칙에 따라 보안 연결을 통해 연결됩니다.
감사	Azure는 나중에 검사할 수 있도록 시스템 데이터를 캡처하고 보호하는 감사 기능을 제공합니다.

심층 방어 익스플로잇 완화

보안 손상 위험을 더 완화하기 위해 Microsoft는 Azure 시스템 소프트웨어, 하드웨어 및 펌웨어에 대한 수많은 심층 방어 완화에 투자하여 Azure 고객에게 강력한 실제 격리 보장을 제공했습니다. 앞에서 설명한 대로 Azure 하이퍼바이저 격리는 Microsoft Hyper-V 기술을 기반으로 하며, 이를 통해 Azure 하이퍼바이저에서 운영 체제 보안 분야에 대한 수십 년간의 Microsoft 경험과 Hyper-V 기술에 대한 가상 머신 격리 투자를 활용할 수 있습니다.

Microsoft에서 Hyper-V를 보호하기 위해 채택한 몇 가지 주요 설계 원칙은 다음과 같습니다.

• 설계 수준 문제가 제품에 영향을 주지 않도록 방지
  • Hyper-V로 변경될 때마다 설계 검토가 적용됩니다.
• 더 안전한 코딩을 사용하여 일반적인 취약성 클래스 제거
  • VMSwitch와 같은 일부 구성 요소는 공식적으로 입증된 프로토콜 파서를 사용합니다.
  • 많은 구성 요소는 원시 포인터 대신 gsl::span을 사용하므로 버퍼 오버플로 및/또는 범위를 벗어난 메모리 액세스 가능성을 제거합니다. 자세한 내용은 GSL(지침 지원 라이브러리) 설명서를 참조하세요.
  • 많은 구성 요소는 스마트 포인터를 사용하여 use-after-free(해제 후 사용) 버그 위험을 제거합니다.
  • 대부분의 Hyper-V 커널 모드 코드는 할당 시 0이 되는 힙 할당자를 사용하여 초기화되지 않은 메모리 버그를 제거합니다.
• 컴파일러 완화를 사용하여 일반적인 취약성 클래스 제거
  • 모든 Hyper-V 코드는 초기화되지 않은 스택 변수를 제거하는 InitAll을 사용하여 컴파일됩니다. 이 방법은 Hyper-V의 많은 기록 취약성이 초기화되지 않은 스택 변수로 인해 발생했기 때문에 구현되었습니다.
  • 모든 Hyper-V 코드는 스택 오버플로 취약성의 위험을 크게 줄이기 위해 스택 카나리아를 사용하여 컴파일됩니다.
• 제품으로 전개될 수 있는 문제 찾기
  • 모든 Windows 코드에는 전체에서 실행되는 일단의 정적 분석 규칙이 있습니다.
  • 모든 Hyper-V 코드는 코드 검토 및 퍼지 테스트를 거칩니다. 퍼지 테스트에 대한 자세한 내용은 이 문서의 뒷부분에 있는 보안 보증 프로세스 및 사례 섹션을 참조하세요.
• 남은 취약성의 악용을 더 어렵게 만들기
  • VM 작업자 프로세스에 적용되는 완화는 다음과 같습니다.
    • 임의 코드 가드 – 동적으로 생성된 코드는 VM 작업자 프로세스에 로드할 수 없습니다.
    • 코드 무결성 가드 – Microsoft 서명 코드만 VM 작업자 프로세스에 로드할 수 있습니다.
    • CFG(제어 흐름 가드) – 간접 호출 및 점프에 대해 세분화된 과정별 제어 흐름 보호를 제공합니다.
    • NoChildProcess – 작업자 프로세스는 자식 프로세스를 만들 수 없습니다(CFG를 우회하는 데 유용함).
    • NoLowImages/NoRemoteImages – 작업자 프로세스는 네트워크를 통해 DLL을 로드하거나 샌드박스 프로세스를 통해 디스크에 작성된 DLL을 로드할 수 없습니다.
    • NoWin32k – 작업자 프로세스는 Win32k와 통신할 수 없으므로 샌드박스 이스케이프가 더 어려워집니다.
    • 힙 임의화 – Windows는 운영 체제의 가장 안전한 힙 구현 중 하나를 제공합니다.
    • ASLR(주소 공간 레이아웃 임의화) – 주소 공간에서 힙, 스택, 이진 파일 및 기타 데이터 구조의 레이아웃을 임의화하여 악용 안정성을 낮춥니다.
    • DEP/NX(데이터 실행 방지) – 코드를 포함할 메모리 페이지만 실행할 수 있습니다.
  • 커널에 적용된 완화는 다음과 같습니다.
    • 힙 임의화 – Windows는 운영 체제의 가장 안전한 힙 구현 중 하나를 제공합니다.
    • ASLR(주소 공간 레이아웃 임의화) – 주소 공간에서 힙, 스택, 이진 파일 및 기타 데이터 구조의 레이아웃을 임의화하여 악용 안정성을 낮춥니다.
    • DEP/NX(데이터 실행 방지) – 코드를 포함할 메모리 페이지만 실행할 수 있습니다.

Hyper-V 보안에 대한 Microsoft의 투자는 직접적인 이점을 Azure 하이퍼바이저에 제공합니다. 심층 방어 완화는 공격자에게 가능한 한 많은 비용이 드는 취약성의 무기화된 악용을 만들어 영향을 제한하고 탐지 기간을 최대화하기 위한 것입니다. 모든 익스플로잇 완화는 악의적 사용자가 사용할 수 있는 방법을 사용하여 Azure 하이퍼바이저 공격 표면에 대한 철저한 보안 검토를 통해 효율성을 평가합니다. 표 3에는 하이퍼바이저 격리 경계와 하드웨어 호스트 무결성을 보호하기 위한 몇 가지 완화 방법이 요약되어 있습니다.

표 3. Azure 하이퍼바이저 심층 방어

완화	보안 영향	완화 세부 정보
제어 흐름 무결성	제어 흐름 무결성 공격(예: 반환 지향 프로그래밍 익스플로잇)을 수행하는 데 드는 비용이 증가합니다.	CFG(제어 흐름 가드)는 간접 제어 흐름 전송이 컴파일 시간에 계측되고 커널(사용자 모드) 또는 보안 커널(커널 모드)에서 적용되어 스택 반환 취약성을 완화합니다.
사용자 모드 코드 무결성	사용자 모드에서 악의적이고 원치 않는 이진 파일 실행으로부터 보호합니다.	호스트 파티션의 모든 이진 파일에 강제 적용된 ASLR(주소 공간 레이아웃 임의화), SDL 보안 검사를 사용하여 컴파일된 모든 코드(예: strict_gs), 호스트 프로세스에 적용된 임의 코드 생성 제한은 런타임 생성 코드의 삽입을 방지합니다.
하이퍼바이저에서 적용하는 사용자 및 커널 모드 코드 무결성	코드의 신뢰성이 확인될 때까지 실행으로 표시된 코드 페이지에 로드된 코드가 없습니다.	VBS(가상화 기반 보안)는 메모리 격리를 사용하여 정책을 적용하고 중요한 코드와 비밀을 저장할 수 있는 보안 영역을 만듭니다. HVCI(하이퍼바이저에서 적용하는 코드 무결성)를 사용하면 서명되지 않은 코드가 일반 영역 커널에 삽입되지 않도록 방지하기 위해 보안 영역이 사용됩니다.
플랫폼 보안 부팅을 사용하는 하드웨어 신뢰 루트	호스트에서 필요한 정확한 펌웨어 및 OS 이미지만 부팅하도록 합니다.	Windows 보안 부팅은 Azure 하이퍼바이저 인프라가 Azure 펌웨어, 하드웨어 및 커널 프로덕션 버전에 맞게 조정된 잘 알려진 구성에서만 부팅할 수 있는지 확인합니다.
감소된 공격 표면 VMM	VMM 사용자 기능의 권한 에스컬레이션으로부터 보호합니다.	Azure 하이퍼바이저 VMM(Virtual Machine Manager)에는 사용자 모드 구성 요소와 커널 모드 구성 요소가 모두 포함되어 있습니다. 사용자 모드 구성 요소는 수많은 계층적 완화 외에도 커널 모드 기능으로의 분리를 방지하기 위해 격리됩니다.

또한 Azure는 Red Teaming을 통해 구현된 위반 가정(assume-breach) 보안 전략을 채택했습니다. 이 방법은 Azure 인프라 및 플랫폼 엔지니어링 또는 운영 팀의 사전 지식 없이 라이브 프로덕션 인프라에 대한 실제 악의적 사용자와 동일한 전술, 기술 및 절차를 사용하여 Azure 시스템 및 운영에 대해 지속적인 테스트를 수행하는 보안 연구원 및 엔지니어로 구성된 전담 팀에 의존합니다. 이 방법은 보안 검색 및 대응 기능을 테스트하고, 구성 오류, 잘못된 가정 또는 기타 보안 문제를 포함하여 Azure 하이퍼바이저 및 기타 시스템의 프로덕션 취약성을 제어된 방식으로 식별하는 데 도움이 됩니다. Microsoft는 지속적인 Azure 위협 완화를 위해 이러한 혁신적인 보안 조치에 많은 투자를 하고 있습니다.

강력한 보안 보증 프로세스

Hyper-V의 공격 표면은 잘 알려져 있습니다. 이는 지속적인 연구와 철저한 보안 검토의 주제였습니다. Microsoft는 2018년 Black Hat 컨퍼런스의 공개 프레젠테이션에서 입증한 대로 Hyper-V 공격 표면과 기본 보안 아키텍처를 투명하게 공개했습니다. Microsoft는 Hyper-V에서 보고된 중요한 RCE(원격 코드 실행), 정보 공개 및 DOS(서비스 거부) 취약성에 대해 $250,000 버그 장려금 프로그램을 통해 Hyper-V 격리의 견고성과 품질을 뒷받침하고 있습니다. Windows Server 및 Azure 클라우드 플랫폼에서 동일한 Hyper-V 기술을 사용하여 공개적으로 사용 가능한 설명서와 버그 장려금 프로그램을 통해 Microsoft 제품 및 서비스의 모든 사용자에게 보안이 향상되도록 보장합니다. 표 4에는 Black Hat 프레젠테이션의 주요 공격 표면 포인트가 요약되어 있습니다.

표 4. Hyper-V 공격 표면 세부 정보

공격 표면 영역	손상되면 부여되는 권한	대략적인 구성 요소
Hyper-V	하이퍼바이저: 다른 게스트가 손상될 수 있는 기능을 포함한 전체 시스템 손상	- 하이퍼콜 - 가로채기 처리
호스트 파티션 커널 모드 구성 요소	커널 모드의 시스템: 다른 게스트가 손상될 수 있는 기능을 포함한 전체 시스템 손상	- VID(가상 인프라 드라이버) 가로채기 처리 - 커널 모드 클라이언트 라이브러리 - VMBus(가상 머신 버스) 채널 메시지 - VSP(스토리지 가상화 서비스 공급자) - 네트워크 VSP - VHD(가상 하드 디스크) 파서 - Azure 네트워킹 VFP(가상 필터링 플랫폼) 및 VNet(가상 네트워크)
호스트 파티션 사용자 모드 구성 요소	사용자 모드의 작업자 프로세스: 호스트 공격 및 권한 에스컬레이션 기능을 포함한 제한된 손상	- VDEV(가상 디바이스)

이러한 공격 표면을 보호하기 위해 Microsoft는 Azure 격리 보장에 대한 높은 신뢰도를 제공하는 업계 최고의 프로세스와 도구를 구축했습니다. 이 문서의 뒷부분에 있는 보안 보증 프로세스 및 사례 섹션에서 설명한 대로 이 방법에는 용도에 맞게 빌드된 퍼지 테스트, 침투 테스트, 보안 개발 수명 주기, 필수 보안 교육, 보안 검토, 게스트-호스트 위협 지표에 따른 보안 침입 탐지, 공격 표면 영역 변경에 대한 자동화된 빌드 경고가 포함됩니다. 이 완성된 다차원 보증 프로세스는 보안 취약성의 위험을 완화하여 Azure 하이퍼바이저에서 제공하는 격리 보증을 보강하는 데 도움이 됩니다.

참고 항목

Azure는 가상 머신 격리 Hyper-V 기술에 대한 Microsoft의 20년 투자를 통해 강화되고 향상된 하이퍼바이저 기반 테넌트 분리를 보장하기 위해 업계 최고의 방법을 채택했습니다. 이 방법의 결과는 1) 강력하게 정의된 보안 경계, 2) 심층 방어 익스플로잇 완화, 3) 강력한 보안 보증 프로세스를 통해 테넌트 분리를 보장하는 데 도움이 되는 강력한 하이퍼바이저입니다.

Drawbridge 격리

고객 코드를 사용하여 작은 처리 단위를 제공하는 서비스의 경우 여러 테넌트의 요청이 단일 VM 내에서 실행되고 Microsoft Drawbridge 기술을 사용하여 격리됩니다. 보안 격리를 제공하기 위해 Drawbridge는 pico-process 내에서 경량 버전의 Windows 커널(라이브러리 OS)과 함께 사용자 프로세스를 실행합니다. pico-process는 커널 API 표면이 최소화되고 호스트 시스템의 서비스 또는 리소스에 직접 액세스하지 않는 간단하고 안전한 격리 컨테이너입니다. 그림 8과 같이 pico-process에서 수행할 수 있는 유일한 외부 호출은 Drawbridge ABI(애플리케이션 이진 인터페이스)를 통해 Drawbridge 보안 모니터를 호출하는 것입니다.

그림 8. Drawbridge를 사용하는 프로세서 격리

보안 모니터는 시스템 디바이스 드라이버와 사용자 모드 구성 요소로 나뉩니다. ABI는 라이브러리 OS와 호스트 간의 인터페이스입니다. 전체 인터페이스는 50개 미만의 상태 비저장 함수 호출로 구성된 닫힌 세트로 구성됩니다.

• pico-process에서 호스트 OS로 내려가는 호출은 스레드, 가상 메모리 및 I/O 스트림과 같은 추상화를 지원합니다.
• pico-process로 올라가는 호출은 초기화를 수행하고, 예외 정보를 반환하고, 새 스레드에서 실행됩니다.

인터페이스의 의미 체계는 고정되어 있으며 애플리케이션이 모든 운영 체제에서 요구하는 일반적인 추상화를 지원합니다. 이 설계를 사용하면 라이브러리 OS와 호스트가 별도로 진화할 수 있습니다.

ABI는 다음 두 가지 구성 요소 내에서 구현됩니다.

• PAL(플랫폼 적응 계층)은 pico-process의 일부로 실행됩니다.
• 호스트 구현은 호스트의 일부로 실행됩니다.

pico-process는 샌드박스라는 격리 단위로 그룹화됩니다. 샌드박스는 pico-process에서 사용할 수 있는 애플리케이션, 파일 시스템 및 외부 리소스를 정의합니다. pico-process 내에서 실행되는 프로세스에서 새 자식 프로세스를 만들면 동일한 샌드박스 내의 별도 pico-process에서 자체 라이브러리 OS로 실행됩니다. 각 샌드박스는 보안 모니터와 통신하며, 허용된 I/O 채널(소켓, 명명된 파이프 등)을 통한 경우를 제외하고는 다른 샌드박스와 통신할 수 없습니다. 이는 서비스 요구 사항에 따른 기본 옵트인 방법을 고려할 때 구성에서 명시적으로 허용해야 합니다. 따라서 pico-process 내에서 실행되는 코드는 자체 리소스에만 액세스할 수 있으며 호스트 시스템 또는 공동 배치된 샌드박스를 직접 공격할 수 없습니다. 자체 샌드박스 내부의 개체에만 영향을 줄 수 있습니다.

pico-process에 시스템 리소스가 필요한 경우 Drawbridge 호스트를 호출하여 요청해야 합니다. 가상 사용자 프로세스에 대한 일반적인 경로는 라이브러리 OS를 호출하여 리소스를 요청한 다음, 라이브러리 OS에서 ABI를 호출하는 것입니다. 리소스 할당 정책이 드라이버 자체에 설정되지 않으면 보안 모니터에서 요청이 허용되는지 확인하기 위해 정책을 확인한 다음, 요청을 처리하여 ABI 요청을 처리합니다. 이 메커니즘은 모든 시스템 기본 요소에 사용되므로 pico-process에서 실행되는 코드가 호스트 컴퓨터의 리소스를 남용할 수 없도록 보장합니다.

pico-process는 샌드박스 내에서 격리되는 것 외에도 서로 실질적으로 격리됩니다. 각 pico-process는 자체 가상 메모리 주소 공간에 상주하며 자체 사용자 모드 커널을 사용하여 라이브러리 OS의 자체 복사본을 실행합니다. 사용자 프로세스가 Drawbridge 샌드박스에서 시작될 때마다 새 라이브러리 OS 인스턴스가 부팅됩니다. 이 작업은 Windows에서 격리되지 않은 프로세스를 시작하는 것보다 시간이 더 많이 걸리지만 논리적 격리를 수행하면서 VM을 부팅하는 것보다 훨씬 빠릅니다.

일반적인 Windows 프로세스는 1,200개가 넘는 함수를 호출하여 Windows 커널에 액세스할 수 있습니다. 그러나 pico-process의 전체 인터페이스는 호스트에 대한 50개 미만의 호출로 구성됩니다. 운영 체제 서비스에 대한 대부분의 애플리케이션 요청은 pico-process의 주소 공간 내의 라이브러리 OS에서 처리됩니다. Drawbridge는 훨씬 더 작은 인터페이스를 커널에 제공하여 애플리케이션이 호스트 시스템의 변경과 새 OS 릴리스에서 도입된 비호환성보다 훨씬 덜 취약한 더 안전하고 격리된 운영 환경을 만듭니다. 더 중요한 것은 Drawbridge pico-process가 가장 악의적인 원본의 신뢰할 수 없는 코드라도 호스트 시스템을 손상시킬 위험 없이 실행할 수 있는 강력하게 격리된 컨테이너라는 것입니다. 호스트는 pico-process 내에서 실행되는 코드를 신뢰할 수 없다고 가정합니다. 호스트는 보안 검사를 통해 pico-process의 모든 요청에 대한 유효성을 검사합니다.

가상 머신과 마찬가지로 pico-process는 훨씬 작고, 상태 비저장이며, 고정되고 쉽게 설명되는 의미 체계가 있으므로 기존 OS 인터페이스보다 훨씬 쉽게 보호할 수 있습니다. 작은 ABI/드라이버 syscall 인터페이스의 또 다른 추가 이점은 약간의 노력으로 드라이버 코드를 감사/퍼지 테스트할 수 있는 기능입니다. 예를 들어 syscall 퍼지 테스트기(fuzzer)는 높은 적용 범위 숫자를 사용하여 ABI를 비교적 짧은 시간 내에 퍼지 테스트할 수 있습니다.

사용자 컨텍스트 기반 격리

Azure 서비스가 Microsoft에서 제어하는 코드로 구성되어 있고 고객 코드를 실행하도록 허용되지 않는 경우 사용자 컨텍스트를 통해 격리가 제공됩니다. 이러한 서비스는 사용자 구성 입력과 처리할 데이터만 허용하며 임의 코드는 허용되지 않습니다. 이러한 서비스의 경우 액세스할 수 있는 데이터와 허용되는 Azure RBAC(Azure 역할 기반 액세스 제어) 작업을 설정하기 위해 사용자 컨텍스트가 제공됩니다. 이 컨텍스트는 이전의 ID 기반 격리 섹션에서 설명한 대로 Microsoft Entra ID에서 설정됩니다. 사용자가 식별되고 권한이 부여되면 Azure 서비스에서 요청의 실행이 진행됨에 따라 요청에 연결되는 애플리케이션 사용자 컨텍스트를 만들어 사용자 작업이 분리되고 제대로 격리되도록 보장합니다.

물리적 격리

모든 Azure 테넌트에서 계획적으로 사용할 수 있는 강력한 논리적 컴퓨팅 격리 외에도 물리적 컴퓨팅 격리를 원하는 경우 모두 단일 고객 전용 서버인 Azure Dedicated Host 또는 격리된 Virtual Machines를 사용할 수 있습니다.

참고 항목

물리적 테넌트 격리는 배포 비용을 증가시키고 Azure에서 제공하는 강력한 논리적 격리 보증을 고려할 때 대부분의 시나리오에서 필요하지 않을 수 있습니다.

Azure Dedicated Host

Azure Dedicated Host는 하나 이상의 Azure VM을 호스트할 수 있는 물리적 서버를 제공하며 하나의 Azure 구독에만 적용됩니다. 지역, 가용성 영역 및 장애 도메인 내에서 전용 호스트를 프로비저닝할 수 있습니다. 그런 다음, 요구 사항에 가장 적합한 구성을 사용하여 Azure VM의Windows, Linux 및 SQL Server를 프로비전된 호스트에 직접 배치할 수 있습니다. Dedicated Host는 물리적 서버 수준에서 하드웨어 격리를 제공하므로 회사 규정 준수 요구 사항을 충족하기 위해 Azure VM을 조직의 워크로드만 실행하는 격리된 전용 물리적 서버에 배치할 수 있습니다.

참고 항목

전용 호스트는 Azure Portal, Azure PowerShell 및 Azure CLI를 사용하여 배포할 수 있습니다.

서버 및 CPU 유형, 코어 수, 추가 기능을 선택하여 Windows 및 Linux 가상 머신을 모두 전용 호스트에 배포할 수 있습니다. Dedicated Host를 사용하면 프로비전된 서비스에 대한 잠재적인 영향을 줄이기 위해 유지 관리 기간을 옵트인하여 플랫폼 유지 관리 이벤트를 제어할 수 있습니다. 대부분의 유지 관리 이벤트는 VM에 거의 또는 전혀 영향을 주지 않습니다. 그러나 규제가 엄격한 산업에 종사하거나 중요한 워크로드를 사용하는 경우 잠재적인 유지 관리 영향을 제어할 수 있습니다.

Microsoft는 Azure Portal, Azure PowerShell 및 Azure CLI를 사용하여 Windows 및 Linux Azure Virtual Machine 프로비전에 대한 자세한 고객 지침을 제공합니다. 표 5에는 Azure에서 프로비전된 가상 머신에 사용할 수 있는 보안 지침이 요약되어 있습니다.

표 5. Azure 가상 머신에 대한 보안 지침

VM	보안 지침
Windows	보안 정책 Azure 디스크 암호화 기본 제공 보안 컨트롤 보안 권장 사항
Linux	보안 정책 Azure 디스크 암호화 기본 제공 보안 컨트롤 보안 권장 사항

격리된 Virtual Machines

Azure Compute는 특정 하드웨어 유형으로 격리되고 단일 고객 전용인 가상 머신 크기를 제공합니다. 이러한 VM 인스턴스를 사용하면 워크로드를 전용 물리적 서버에 배포할 수 있습니다. 격리된 VM을 사용하면 기본적으로 VM이 해당 특정 서버 노드에서 실행되는 유일한 VM이 됩니다. 중첩된 Virtual Machines에 대한 Azure 지원을 사용하여 이러한 격리된 VM의 리소스를 더 세분화하도록 선택할 수도 있습니다.

네트워킹 격리

퍼블릭 다중 테넌트 클라우드에서 테넌트 인프라를 논리적으로 격리하는 것은 기본적인 보안 유지 관리입니다. 가상화된 솔루션의 가장 중요한 원칙은 가상화된 솔루션이 작동하는 데 필요한 연결과 통신만 허용하고 기본적으로 다른 모든 포트 및 연결을 차단하는 것입니다. Azure VNet(Virtual Network)은 프라이빗 네트워크 트래픽을 다른 고객에게 속한 트래픽과 논리적으로 격리하는 데 도움이 됩니다. 동일한 고객이 두 VNet을 만든 경우에도 한 VNet의 VMs(Virtual Machines)는 다른 VNet의 VMs와 직접 통신할 수 없습니다. 네트워킹 격리는 VM 간의 통신이 VNet 내에서 비공개로 유지되도록 보장합니다. 대역폭, 대기 시간, 암호화 요구 사항을 포함한 연결 옵션에 따라 VNet 피어링 또는 VPN 게이트웨이를 통해 VNet을 연결할 수 있습니다.

이 섹션에서는 Azure에서 네트워크 트래픽을 테넌트 간에 격리하고 암호화 확실성을 사용하여 해당 격리를 적용하는 방법을 설명합니다.

테넌트 네트워크 트래픽 분리

VNet(가상 네트워크)은 기본 설계의 일부로 테넌트 간의 네트워크 트래픽 격리를 제공합니다. Azure 구독에는 논리적으로 격리된 여러 프라이빗 네트워크가 포함될 수 있으며 방화벽, 부하 분산 및 네트워크 주소 변환이 포함될 수 있습니다. 각 VNet은 기본적으로 다른 VNet과 격리됩니다. 구독 내의 여러 배포를 동일한 VNet에 배치한 다음, 개인 IP 주소를 통해 서로 통신할 수 있습니다.

VM에 대한 네트워크 액세스는 네트워크 에지, 부하 분산 장치 및 호스트 OS 수준의 패킷 필터링을 통해 제한됩니다. 또한 연결을 인터넷에서 허용할지 아니면 동일한 클라우드 서비스 또는 VNet 내의 역할 인스턴스에서만 허용할지 여부를 각 수신 대기 포트에 지정하여 연결을 추가로 제한하도록 호스트 방화벽을 구성할 수 있습니다.

Azure는 각 배포에 대한 네트워크 격리를 제공하고 다음 규칙을 적용합니다.

• VM 간의 트래픽은 항상 신뢰할 수 있는 패킷 필터를 트래버스합니다.
  • ARP(주소 확인 프로토콜), DHCP(동적 호스트 구성 프로토콜) 및 VM의 기타 OSI 계층 2 트래픽과 같은 프로토콜은 속도 제한 및 스푸핑 방지 보호를 사용하여 제어됩니다.
  • VM은 트래픽을 의도되지 않은 네트워크에서 캡처할 수 없습니다.
• VM은 트래픽을 Azure 프라이빗 인터페이스 및 인프라 서비스 또는 다른 고객에게 속한 VM으로 보낼 수 없습니다. VM은 사용자가 소유하거나 제어하는 다른 VM 및 퍼블릭 통신에 대한 Azure 인프라 서비스 엔드포인트와만 통신할 수 있습니다.
• VM을 VNet에 배치하면 해당 VM은 표시되지 않는 자체 주소 공간을 가져오므로 배포 또는 VNet 외부의 VM에서 연결할 수 없습니다(공용 IP 주소를 통해 표시되도록 구성하지 않은 경우). 사용자 환경은 퍼블릭 액세스에 대해 지정한 포트를 통해서만 열립니다. VM이 공용 IP 주소를 갖도록 정의되면 퍼블릭 액세스에 대한 모든 포트가 열립니다.

패킷 흐름 및 네트워크 경로 보호

Azure의 하이퍼스케일 네트워크는 다음을 제공하도록 설계되었습니다.

• 서버 간 균일한 대용량
• 고객을 포함한 서비스 간 성능 격리
• 이더넷 계층 2 의미 체계

Azure는 다음과 같은 목표를 달성하기 위해 여러 네트워킹 구현을 사용합니다.

• 서비스 인스턴스를 네트워크의 어디에나 배치할 수 있도록 하는 플랫 주소 지정
• 트래픽을 네트워크 경로 전체에 균일하게 분산시키는 부하 분산
• 복잡성을 네트워크 컨트롤 플레인에 도입하지 않고 대규모 서버 풀로 크기 조정할 수 있는 최종 시스템 기반 주소 확인

이러한 구현은 할당된 모든 서버와 간섭하지 않는 단일 이더넷 스위치인 VL2(가상 계층 2)에서 이러한 서버만 연결한 것처럼 보이는 환상을 각 서비스에 제공하고, 각 서비스의 크기가 하나의 서버에서 수십만 개의 서버까지 다양하더라도 이러한 환상을 유지합니다. 이 VL2 구현은 트래픽 성능 격리를 달성하여 각 서비스가 별도의 물리적 스위치를 통해 연결된 것처럼 한 서비스의 트래픽이 다른 서비스의 트래픽에서 영향을 받을 수 없도록 보장합니다.

이 섹션에서는 패킷이 Azure 네트워크를 통해 흐르는 방법과 토폴로지, 라우팅 설계 및 디렉터리 시스템이 결합되어 기본 네트워크 패브릭을 가상화하는 방법을 설명하여 서버가 간섭하지 않는 대규모 데이터 센터 전체 계층 2 스위치에 연결된 것처럼 보이게 합니다.

Azure 네트워크는 두 개의 서로 다른 IP 주소 패밀리를 사용합니다.

• CA(고객 주소)는 고객이 정의하고 선택한 VNet IP 주소이며, VIP(가상 IP)라고도 합니다. 네트워크 인프라는 외부에서 라우팅할 수 있는 CA를 사용하여 작동합니다. 모든 스위치와 인터페이스에는 CA가 할당되며, 스위치는 이러한 CA만 전파하는 IP 기반(계층 3) 링크 상태 라우팅 프로토콜을 실행합니다. 이 설계를 사용하면 스위치에서 전체 스위치 수준 토폴로지를 얻고 가장 짧은 경로를 따라 CA를 사용하여 캡슐화된 패킷을 전달할 수 있습니다.
• PA(공급자 주소)는 사용자에게 표시되지 않는 Azure 할당 내부 패브릭 주소이며, DIP(동적 IP)라고도 합니다. 트래픽이 인터넷에서 서버로 직접 이동하지 않습니다. 인터넷의 모든 트래픽은 SLB(소프트웨어 부하 분산 장치)를 통과해야 하며, 패킷을 유효한 Azure 내부 IP 주소 및 포트로만 라우팅하여 내부 Azure 주소 공간을 보호하도록 캡슐화해야 합니다. NAT(Network Address Translation)는 내부 네트워크 트래픽을 외부 트래픽과 분리합니다. 내부 트래픽은 외부에서 라우팅할 수 없는 RFC 1918 주소 공간 또는 개인 주소 공간(PA(공급자 주소))을 사용합니다. 변환은 SLB에서 수행됩니다. 외부에서 라우팅할 수 있는 CA(고객 주소)는 Azure 내에서만 라우팅할 수 있는 내부 PA(공급자 주소)로 변환됩니다. 가상 머신 마이그레이션 또는 다시 프로비전으로 인해 이러한 주소는 서버 위치 변경과 관계없이 변경되지 않습니다.

각 PA는 서버가 연결된 ToR(Top of Rack) 스위치의 식별자인 CA와 연결됩니다. VL2는 확장성 있고 안정적인 디렉터리 시스템을 사용하여 PA와 CA의 매핑을 저장하고 유지 관리하며, 이 매핑은 서버가 서비스에 프로비전되고 PA 주소가 할당될 때 만들어집니다. VL2 에이전트라고 하는 모든 서버의 네트워크 스택에서 실행되는 에이전트는 디렉터리 시스템의 확인 서비스를 호출하여 대상의 실제 위치를 파악한 다음, 원본 패킷을 이 위치로 터널링합니다.

Azure는 토폴로지에 유의하지 않고 이름만으로 작동하는 서버 IP 주소를 할당합니다. Azure의 VL2 주소 지정 체계는 이러한 서버 이름(PA)을 해당 위치(CA)와 구분합니다. 계층 2 의미 체계를 제공하는 핵심은 서버에서 단일 대규모 IP 서브넷, 즉 전체 PA 공간을 동일한 서비스의 다른 서버와 공유한다고 믿게 하는 동시에 대규모 이더넷 배포를 방해하는 ARP(주소 확인 프로토콜) 및 DHCP(동적 호스트 구성 프로토콜) 크기 조정 병목 상태를 제거합니다.

그림 9에서는 발신기 S에서 IP-in-IP 캡슐화를 사용하여 임의로 선택한 중간 스위치를 통해 패킷을 대상 D로 보내는 샘플 패킷 흐름을 보여줍니다. CA는 20/8부터이고 CA는 10/8부터입니다. H(ft)는 원본 IP, 원본 포트, 대상 IP, 대상 포트, 프로토콜 유형으로 구성된 5튜플의 해시를 나타냅니다. ToR은 PA를 CA로 변환하고 중간 스위치로 보내며, 중간 스위치는 대상 CA ToR 스위치로 보내고 대상 PA로 변환합니다.

그림 9. 샘플 패킷 흐름

디렉터리 서비스에서 패킷을 라우팅할 수 있는 CA 제공을 거부하는 경우 서버는 패킷을 PA에 보낼 수 없습니다. 즉, 디렉터리 서비스에서 액세스 제어 정책을 적용합니다. 또한 디렉터리 시스템에서 조회를 처리할 때 요청을 수행하는 서버를 알고 있으므로 세분화된 격리 정책을 적용할 수 있습니다. 예를 들어 동일한 서비스에 속한 서버만 서로 통신할 수 있는 정책을 적용할 수 있습니다.

트래픽 흐름 패턴

CA 주소에 대한 경로를 알고 있는 기본 네트워크에서 PA 주소를 사용하는 서버 간에 트래픽을 라우팅하기 위해 각 서버의 VL2 에이전트는 호스트에서 패킷을 캡처하고 이러한 패킷을 대상 ToR 스위치의 CA 주소로 캡슐화합니다. 패킷이 CA(즉, 대상 ToR 스위치)에 도착하면 대상 ToR 스위치는 패킷을 캡슐화 해제하여 내부 헤더에 전달된 대상 PA로 전달합니다. 패킷은 먼저 중간 스위치 중 하나로 전달되고, 스위치에서 캡슐화 해제되고, ToR의 CA로 전달되고, 다시 캡슐화 해제된 다음, 마지막으로 대상으로 보내집니다. 그림 10에서는 두 가지 가능한 트래픽 패턴, 즉 1) Azure ExpressRoute 또는 인터넷을 통해 VNet으로 트래버스하는 외부 트래픽(주황색 선)과 2) 두 VNet 간의 내부 트래픽(파란색 선)을 사용하여 이 방법을 설명하고 있습니다. 두 트래픽 흐름은 모두 비슷한 패턴을 따라 네트워크 트래픽을 격리하고 보호합니다.

그림 10. VNet을 사용하여 테넌트 네트워크 트래픽 분리

외부 트래픽(주황색 선) – 외부 트래픽의 경우 Azure는 트래픽 패턴에 따라 격리를 적용하기 위해 여러 계층의 보증을 제공합니다. 공용 IP를 VNet 게이트웨이에 배치하면 해당 IP 주소로 향하는 공용 인터넷 또는 온-프레미스 네트워크의 트래픽이 인터넷 Edge 라우터로 라우팅됩니다. 또는 ExpressRoute 연결을 통해 개인 피어링을 설정하면 VNet Gateway를 통해 Azure VNet과 연결됩니다. 이 설정은 물리적 회로의 연결을 조정하고 온-프레미스 위치의 개인 IP 주소 공간을 주소로 지정할 수 있게 만듭니다. 그런 다음, Azure는 BGP(Border Gateway Protocol)를 통해 라우팅 세부 정보를 온-프레미스 네트워크와 공유하여 엔드투엔드 연결을 설정합니다. VNet 내의 리소스와 통신이 시작되면 네트워크 트래픽은 MSEE(Microsoft ExpressRoute Edge) 라우터에 도달할 때까지 정상적으로 트래버스됩니다. 두 경우 모두에서 VNet은 Azure VM이 온-프레미스 네트워크의 일부로 작동할 수 있는 수단을 제공합니다. 암호화로 보호되는 IPsec/IKE 터널이 Azure와 내부 네트워크 간에 설정되어(예: Azure VPN Gateway 또는 Azure ExpressRoute 개인 피어링을 통해) VM이 마치 해당 네트워크에 직접 있는 것처럼 온-프레미스 리소스에 안전하게 연결할 수 있습니다.

인터넷 Edge 라우터 또는 MSEE 라우터에서 패킷은 GRE(일반 라우팅 캡슐화)를 사용하여 캡슐화됩니다. 이 캡슐화는 VNet 대상 및 대상 주소와 관련된 고유 식별자를 사용하며, 이 식별자는 식별된 VNet으로 트래픽을 적절하게 라우팅하는 데 사용됩니다. Azure VNet 외부의 트래픽을 수락하는 데만 사용되는 특수 VNet인 VNet Gateway에 도달하면 Azure 네트워크 패브릭에서 캡슐화를 확인하여 다음을 확인합니다. a) 패킷을 수신하는 엔드포인트가 데이터를 라우팅하는 데 사용되는 고유한 VNet ID와 일치하고, b) 요청된 대상 주소가 이 VNet에 있는지 확인합니다. 확인되면 패킷은 VNet Gateway에서 VNet 내의 최종 요청 대상 주소로 내부 트래픽으로 라우팅됩니다. 이 방법을 사용하면 외부 네트워크의 트래픽이 대상인 Azure VNet으로만 이동하여 격리가 적용됩니다.

내부 트래픽(파란색 선) – 내부 트래픽도 GRE 캡슐화/터널링을 사용합니다. Azure VNet의 두 리소스에서 서로 간의 통신을 설정하려고 하면 Azure 네트워크 패브릭이 Azure 네트워크 패브릭의 일부인 Azure VNet 라우팅 디렉터리 서비스에 연결됩니다. 디렉터리 서비스는 CA(고객 주소)와 요청된 대상 주소를 사용하여 PA(공급자 주소)를 확인합니다. VNet 식별자, CA 및 PA를 포함한 이 정보는 GRE를 사용하여 트래픽을 캡슐화하는 데 사용됩니다. Azure 네트워크는 이 정보를 사용하여 PA를 통해 캡슐화된 데이터를 적절한 Azure 호스트로 올바르게 라우팅합니다. 캡슐화는 Azure 네트워크 패브릭에서 검토하여 다음을 확인합니다.

1. PA가 일치합니다.
2. CA는 이 PA에 있습니다. 그리고
3. VNet 식별자가 일치합니다.

세 가지 항목이 모두 확인되면 캡슐화가 제거되고 일반 트래픽(예: VM 엔드포인트)으로서 CA로 라우팅됩니다. 이 방법은 클라우드 서비스 간의 올바른 트래픽 라우팅에 따라 VNet 격리 보증을 제공합니다.

Azure VNet은 테넌트 간의 보안 트래픽을 보장하기 위해 여러 메커니즘을 구현합니다. 이러한 메커니즘은 기존 업계 표준 및 보안 사례에 부합하며 다음을 포함하여 잘 알려진 공격 벡터를 방지합니다.

• IP 주소 스푸핑 방지 – VNet에서 캡슐화된 트래픽을 전송할 때마다 서비스에서 전송 수신 종료에 대한 정보를 다시 확인합니다. 전송 시작 시 트래픽을 독립적으로 조회하고 캡슐화하며, 수신 엔드포인트에서 다시 확인하여 전송이 적절하게 수행되었는지 확인합니다. 이 확인은 원본과 대상이 유효하고 통신이 허용되는지 확인하는 SpoofGuard라는 내부 VNet 기능을 사용하여 수행됩니다. 이를 통해 스푸핑을 허용할 수 있는 예상 캡슐화 패턴의 불일치를 방지합니다. Azure 네트워크 패브릭에서 수행되지 않은 GRE 캡슐화 및 암호화는 삭제된 트래픽으로 처리되므로 GRE 캡슐화 프로세스는 스푸핑을 방지합니다.
• 겹치는 네트워크 공간을 사용하여 고객 전체에 네트워크 구분 제공 – Azure VNet 구현은 GRE와 같은 설정된 터널링 표준을 사용하며, 이를 통해 클라우드 전체에서 고객별 고유 식별자(VNet ID)를 사용할 수 있습니다. VNet 식별자는 범위 지정 식별자로 사용됩니다. 이 방법을 사용하면 테넌트와 Azure 네트워크 패브릭 간의 주소 공간이 겹치는 고유한 주소 공간 내에서 항상 작동합니다. 유효한 VNet ID를 사용하여 캡슐화되지 않은 모든 항목은 Azure 네트워크 패브릭 내에서 차단됩니다. 이전에 설명한 예에서는 Azure 네트워크 패브릭에서 수행되지 않는 캡슐화된 트래픽이 모두 삭제됩니다.
• VNet 간 트래픽 교차 방지 – VNet 간 트래픽 교차 방지는 주소 겹침을 처리하고 스푸핑을 방지하는 동일한 메커니즘을 통해 수행됩니다. VNet 간의 트래픽 교차는 원본 및 대상의 모든 트래픽 확인과 함께 테넌트별로 설정된 고유한 VNet ID를 사용하여 렌더링할 수 없습니다. 사용자는 캡슐화를 수행하기 위해 이러한 ID를 사용하는 기본 전송 메커니즘에 액세스할 수 없습니다. 따라서 이러한 메커니즘을 캡슐화하고 시뮬레이션하려고 하면 트래픽이 감소합니다.

이러한 주요 보호 기능 외에도 인터넷에서 발생하는 모든 예기치 않은 트래픽은 기본적으로 삭제됩니다. Azure 네트워크에 들어오는 모든 패킷은 먼저 Edge 라우터를 만나게 됩니다. Edge 라우터는 스푸핑된 트래픽을 제외하고 Azure 네트워크에 대한 모든 인바운드 트래픽을 의도적으로 허용합니다. 이 기본 트래픽 필터링은 알려진 잘못된 악성 트래픽으로부터 Azure 네트워크를 보호합니다. Azure는 네트워크 계층에서 DDoS 보호도 구현하여 실시간 및 기록 데이터 분석에 따라 트래픽을 제한하거나 차단하고 요청 시 공격을 완화하기 위해 로그를 수집합니다.

또한 Azure 네트워크 패브릭은 스푸핑된 Azure 네트워크 패브릭 공간에서 발생하는 모든 IP의 트래픽을 차단합니다. Azure 네트워크 패브릭은 GRE 및 VXLAN(Virtual Extensible LAN)을 사용하여 허용되는 모든 트래픽이 Azure에서 제어하는 트래픽이고 모든 비 Azure GRE 트래픽이 차단되는지 확인합니다. Azure는 GRE 터널과 VXLAN을 통해 고객 고유 키를 사용하여 트래픽을 분할함으로써 RFC 3809 및 RFC 4110을 충족합니다. Azure VPN Gateway를 ExpressRoute와 함께 사용하는 경우 Azure는 RFC 4111 및 RFC 4364를 충족합니다. 외부 및 내부 네트워크 트래픽을 포함하는 격리에 대한 포괄적인 방법을 사용하면 Azure VNet은 Azure에서 트래픽을 VNet 간에 성공적으로 라우팅하고, 적절한 네트워크 구분을 주소 공간이 겹치는 테넌트에 허용하고, IP 주소 스푸핑을 방지한다고 보증할 수 있습니다.

또한 Azure 서비스를 사용하여 리소스를 추가로 격리하고 보호할 수 있습니다. Azure Virtual Network의 기능인 네트워크 보안 그룹(NSG)을 사용하면 기본적으로 분산 가상 방화벽 및 IP 기반 네트워크 ACL(액세스 제어 목록)로 작동하는 여러 인바운드 및 아웃바운드 보안 규칙을 통해 원본 및 대상 IP 주소, 포트, 프로토콜별로 트래픽을 필터링할 수 있습니다. NSG를 가상 머신의 각 NIC에 적용하고, NSG를 NIC 또는 다른 Azure 리소스가 연결된 서브넷에 적용하고, 가상 머신 확장 집합에 직접 적용하여 인프라를 더 세부적으로 제어할 수 있습니다.

인프라 계층에서 Azure는 하이퍼바이저 방화벽을 구현하여 하이퍼바이저 기반의 가상 머신 내에서 실행되는 모든 테넌트를 무단 액세스로부터 보호합니다. 이 하이퍼바이저 방화벽은 그림 4와 같이 호스트에 배포되고, 하이퍼바이저에서 구현되며, 패브릭 컨트롤러 에이전트에서 구성되는 NSG 규칙의 일부로 배포됩니다. 호스트 OS 인스턴스는 기본 제공 Windows 방화벽을 사용하여 라우터 ACL보다 더 세분화된 ACL을 구현합니다. 이는 테넌트를 프로비전하는 동일한 소프트웨어에서 유지 관리되므로 결코 최신 상태가 아닙니다. 세분화된 ACL은 MCF(컴퓨터 구성 파일)를 사용하여 Windows 방화벽에 적용됩니다.

운영 체제 스택의 맨 위에는 운영 체제로 사용하는 게스트 OS가 있습니다. 기본적으로 이 계층은 클라우드 서비스 또는 가상 네트워크에 대한 인바운드 통신을 허용하지 않으므로 기본적으로 프라이빗 네트워크의 일부가 됩니다. PaaS 웹 및 작업자 역할의 경우 원격 액세스가 기본적으로 허용되지 않습니다. RDP(원격 데스크톱 프로토콜) 액세스를 명시적 옵션으로 사용하도록 설정할 수 있습니다. Azure Portal을 사용하여 만든 IaaS VM의 경우 RDP 및 원격 PowerShell 포트가 기본적으로 열립니다. 그러나 포트 번호는 임의로 할당됩니다. PowerShell을 통해 만든 IaaS VM의 경우 RDP 및 원격 PowerShell 포트를 명시적으로 열어야 합니다. 관리자가 RDP 및 원격 PowerShell 포트를 인터넷에 열어 두도록 선택하는 경우 RDP 및 PowerShell 연결을 만들 수 있는 계정은 강력한 암호로 보호해야 합니다. 포트가 열려 있더라도 원하는 경우 추가 보호를 위해 공용 IP에서 ACL을 정의할 수 있습니다.

서비스 태그

Virtual Network 서비스 태그를 사용하여 네트워크 격리를 달성하고 퍼블릭 엔드포인트가 있는 Azure 서비스에 액세스하는 동안 인터넷에서 Azure 리소스를 보호할 수 있습니다. 서비스 태그를 사용하여 네트워크 보안 그룹 또는 Azure Firewall에서 네트워크 액세스 제어를 정의할 수 있습니다. 서비스 태그는 지정된 Azure 서비스의 IP 주소 접두사 그룹을 나타냅니다. Microsoft에서 서비스 태그에 포함되는 주소 접두사를 관리하고 주소 변경에 따라 서비스 태그를 자동으로 업데이트하므로 네트워크 보안 규칙을 자주 업데이트하는 복잡성이 줄어듭니다.

참고 항목

인바운드/아웃바운드 네트워크 보안 그룹 규칙을 만들어 인터넷 간 트래픽을 거부하고 Azure 간 트래픽을 허용할 수 있습니다. 서비스 태그는 네트워크 보안 그룹 규칙에서 사용하기 위해 다양한 Azure 서비스에 사용할 수 있습니다.

추가 리소스:

• 특정 Azure 서비스에 사용 가능한 서비스 태그

Azure Private Link

Private Link를 사용하여 VNet의 프라이빗 엔드포인트를 통해 Azure PaaS 서비스 및 Azure 호스팅 고객/파트너 서비스에 액세스할 수 있으므로 VNet과 서비스 간의 트래픽이 Microsoft 글로벌 백본 네트워크를 통해 이동할 수 있습니다. 이 방법을 사용하면 서비스를 공용 인터넷에 공개할 필요가 없습니다. 또한 사용자 고유의 VNet에서 고유한 프라이빗 링크 서비스를 만들어 고객에게 제공할 수도 있습니다.

Azure 프라이빗 엔드포인트는 Private Link에서 제공하는 서비스에 비공개로 안전하게 연결하는 네트워크 인터페이스입니다. 프라이빗 엔드포인트는 VNet의 개인 IP 주소를 사용하여 서비스를 VNet에 효과적으로 가져옵니다.

네트워킹 격리 관점에서 Private Link의 주요 이점은 다음과 같습니다.

• 원본 또는 대상에서 공용 IP 주소 없이 VNet을 Azure의 서비스에 연결할 수 있습니다. Private Link는 Microsoft 글로벌 백본 네트워크를 통해 서비스와 해당 소비자 간의 연결을 처리합니다.
• 프라이빗 엔드포인트를 사용하여 Azure ExpressRoute 개인 피어링, VPN 터널 및 피어링된 가상 네트워크를 통해 온-프레미스에서 Azure에서 실행되는 서비스에 액세스할 수 있습니다. Private Link를 사용하면 공용 피어링을 설정하거나 인터넷을 트래버스하여 서비스에 연결할 필요가 없습니다.
• 다른 Azure 지역에서 실행되는 서비스에 비공개로 연결할 수 있습니다.

참고 항목

Azure Portal을 사용하여 Azure PaaS 리소스에 대한 프라이빗 엔드포인트 연결을 관리할 수 있습니다. 고객/파트너 소유 Private Link 서비스의 경우 Azure PowerShell 및 Azure CLI는 프라이빗 엔드포인트 연결을 관리하는 데 선호되는 방법입니다.

추가 리소스:

• Azure PaaS 리소스에서 프라이빗 엔드포인트 연결을 관리하는 방법
• 고객 또는 파트너 소유 Private Link 서비스에서 프라이빗 엔드포인트 연결을 관리하는 방법

전송 중 암호화

Azure는 전송 중인 데이터를 암호화하기 위한 여러 옵션을 제공합니다. 전송 중 데이터 암호화는 다른 트래픽에서 네트워크 트래픽을 격리하고 데이터를 가로채지 못하도록 보호합니다. 전송 중 데이터는 다음 사이의 데이터 이동과 관련된 시나리오에 적용됩니다.

• 최종 사용자 및 Azure 서비스
• 온-프레미스 데이터 센터 및 Azure 지역
• 예상되는 Azure 서비스 작업의 일부인 Microsoft 데이터 센터

Azure 서비스에 대한 최종 사용자의 연결

TLS(전송 계층 보안) – 데이터가 최종 사용자와 Azure 서비스 간에 이동하는 경우 Azure는 TLS 프로토콜을 사용하여 데이터를 보호합니다. 대부분의 최종 사용자는 인터넷을 통해 Azure에 연결하며, 네트워크 트래픽의 정확한 라우팅은 인터넷 인프라에 기여하는 많은 네트워크 공급자에 따라 달라집니다. Microsoft 제품 및 서비스 DPA(데이터 보호 부록)에서 명시한 대로 Microsoft는 사용자 또는 사용자의 최종 사용자가 고객 데이터에 액세스하거나 이동할 수 있는 지역을 제어하거나 제한하지 않습니다.

Important

전송 중 암호화를 사용하도록 설정하여 보안을 강화할 수 있습니다. 예를 들어 Application Gateway를 사용하여 네트워크 트래픽의 엔드투엔드 암호화를 구성하고 Key Vault 통합을 TLS 종료에 사용할 수 있습니다.

Azure 서비스 전체에서 서비스 간 트래픽은 RSA-2048을 키 교환에 사용하고 AES-256을 데이터 암호화에 사용하는 TLS 1.2를 통해 보호됩니다. 해당 암호화 모듈은 Microsoft Windows FIPS 유효성 검사 프로그램의 일환으로 FIPS 140 유효성 검사를 받았습니다.

강력한 인증, 메시지 개인 정보 보호 및 무결성을 제공합니다. PFS(완전 순방향 비밀성)는 시작하는 모든 세션에 대해 고유한 세션 키를 생성하여 클라이언트 시스템과 Microsoft 클라우드 서비스 간의 연결을 보호합니다. PFS는 향후 잠재적인 키 손상에 대해 과거 세션을 보호합니다. 이러한 조합을 통해 누군가가 전송 중 데이터를 가로채거나 액세스하기 어렵게 할 수 있습니다.

VM에 대한 전송 중 암호화 – Azure에 배포된 Windows 및 Linux VM에 대한 원격 세션은 전송 중 데이터 암호화를 보장하는 프로토콜을 통해 수행될 수 있습니다. 예를 들어 클라이언트 컴퓨터에서 Windows 및 Linux VM으로 시작된 RDP(원격 데스크톱 프로토콜)를 사용하면 전송 중 데이터에 대한 TLS 보호를 사용할 수 있습니다. 또한 SSH(Secure Shell)를 사용하여 Azure에서 실행되는 Linux VM에 연결할 수도 있습니다. SSH는 Azure에서 호스트되는 Linux VM의 원격 관리에 기본적으로 사용할 수 있는 암호화된 연결 프로토콜입니다.

Important

무차별 암호 대입 공격(brute force attack)을 완화하여 Azure Virtual Machines에 액세스할 수 있도록 인터넷에서 Virtual Machines에 대한 RDP/SSH 액세스를 사용하지 않도록 설정하는 지침을 포함하여 네트워크 보안에 대한 모범 사례를 검토해야 합니다. 원격 관리를 위한 VM 액세스는 지점 및 사이트 간 VPN, 사이트 간 VPN 또는 Azure Express 경로를 통해 수행할 수 있습니다.

Azure Storage 트랜잭션 – Azure Portal을 통해 Azure Storage와 상호 작용하는 경우 모든 트랜잭션은 HTTPS를 통해 발생합니다. 또한 스토리지 계정에 대해 "보안 전송 필요" 속성을 설정하여 보안 연결의 요청만 수락하도록 스토리지 계정을 구성할 수 있습니다. Azure Portal에서는 스토리지 계정을 만들 때 ‘보안 전송 필요’ 옵션이 기본적으로 사용하도록 설정되어 있습니다.

Azure Files는 산업 표준 SMB(서버 메시지 블록) 프로토콜을 통해 액세스할 수 있는, 클라우드에서 완전 관리형 파일 공유를 제공합니다. 기본적으로 모든 Azure 스토리지 계정에는 전송 중 암호화가 사용하도록 설정되어 있습니다. 따라서 SMB를 통해 공유를 탑재하거나 Azure Portal(또는 Azure PowerShell, Azure CLI 및 Azure SDK)을 통해 공유에 액세스하는 경우 Azure Files는 암호화 또는 HTTPS를 통해 SMB 3.0 이상을 사용하여 만든 경우에만 연결을 허용합니다.

Azure 지역에 대한 데이터 센터 연결

VPN 암호화 – VNet(Virtual Network)은 Azure VMs(Virtual Machines)가 내부(온-프레미스) 네트워크의 일부로 작동할 수 있는 수단을 제공합니다. VNet을 사용하면 전역적으로 라우팅할 수 없는 IP 주소의 주소 범위를 VM에 할당하여 다른 곳에서 사용하는 주소와 충돌하지 않도록 선택할 수 있습니다. 온-프레미스 인프라 또는 원격 위치에서 VNet에 안전하게 연결하는 옵션이 있습니다.

• 사이트 간(IPsec/IKE VPN 터널) – Azure와 내부 네트워크 간에 암호화로 보호되는 "터널"이 설정되어 Azure VM이 마치 해당 네트워크에 직접 있는 것처럼 백 엔드 리소스에 연결할 수 있습니다. 이 유형의 연결에는 외부 연결 공용 IP 주소가 할당된 온-프레미스에 있는 VPN 디바이스가 필요합니다. Azure VPN Gateway를 사용하여 공용 인터넷을 통해 VNet과 온-프레미스 인프라 간에 암호화된 트래픽을 보낼 수 있습니다. 예를 들어 사이트 간 VPN은 IPsec을 전송 암호화에 사용합니다. VPN Gateway는 FIPS 140 유효성이 검사된 다양한 암호화 알고리즘을 지원합니다. 또한 기본 Azure 정책을 사용하는 대신 특정 암호화 알고리즘 및 키 강도가 포함된 사용자 지정 IPsec/IKE 정책을 사용하도록 VPN Gateway를 구성할 수 있습니다. IPsec은 IP 수준(네트워크 계층 3)에서 데이터를 암호화합니다.
• 지점 및 사이트 간(SSTP, OpenVPN 및 IPsec을 통한 VPN) – SSTP(Secure Socket Tunneling Protocol), OpenVPN 또는 IPsec을 사용하여 개별 클라이언트 컴퓨터에서 VNet으로의 보안 연결이 설정됩니다. 지점 및 사이트 간 VPN 구성의 일부로 클라이언트 컴퓨터에서 VNet 내의 모든 VM에 연결할 수 있도록 허용하는 인증서와 VPN 클라이언트 구성 패키지를 설치해야 합니다. 지점 및 사이트 간 VPN 연결에는 VPN 디바이스 또는 공용 IP 주소가 필요하지 않습니다.

Azure는 VPN 연결에 지원되는 알고리즘 유형을 제어하는 것 외에도 VNet에서 나가는 모든 트래픽이 VNet Gateway(예: Azure VPN Gateway)를 통해서만 라우팅될 수 있도록 적용하는 기능을 제공합니다. 이 적용을 통해 트래픽이 암호화되지 않고 VNet에서 나가지 못하도록 할 수 있습니다. VPN Gateway는 VNet 간 연결에 사용할 수 있으며 IPsec/IKE를 통한 보안 터널을 제공합니다. Azure VPN은 VPN 터널이 만들어질 때 Microsoft에서 PSK를 생성하는 PSK(사전 공유 키) 인증을 사용합니다. 자동 생성된 PSK는 사용자 고유의 PSK로 변경할 수 있습니다.

Azure ExpressRoute 암호화 – Azure ExpressRoute를 사용하면 프라이빗 연결을 Microsoft 데이터 센터와 온-프레미스 인프라 또는 공동 배치 시설 간에 만들 수 있습니다. ExpressRoute 연결은 공용 인터넷을 통해 이동하지 않으며, IPsec 보호 VPN 연결보다 대기 시간이 짧고 안정성이 높습니다. ExpressRoute 위치는 Microsoft의 글로벌 네트워크 백본에 대한 진입점이며 Azure 지역의 위치와 일치할 수도 있고 그렇지 않을 수도 있습니다. 네트워크 트래픽이 Microsoft 백본에 들어오면 공용 인터넷 대신 해당 프라이빗 네트워킹 인프라를 트래버스하는 것이 보장됩니다. MACsec 암호화 키를 Azure Key Vault에 저장할 수 있게 하는 MACsec을 포함하여 여러 데이터 암호화 옵션에서 ExpressRoute를 사용할 수 있습니다. MACsec은 미디어 액세스 제어(MAC) 수준, 즉 데이터 링크 계층(네트워크 계층 2)에서 데이터를 암호화합니다. AES-128 및 AES-256 블록 암호는 모두 암호화에 지원됩니다. ExpressRoute Direct를 통해 Microsoft에 연결하는 경우 MACsec을 사용하여 네트워크 디바이스와 Microsoft 네트워크 디바이스 간의 물리적 링크를 암호화할 수 있습니다. ExpressRoute Direct를 사용하면 파이버를 에지에서 피어링 위치의 Microsoft Enterprise 에지 라우터로 직접 연결할 수 있습니다.

그림 11과 같이 ExpressRoute Direct 포트에서 MACsec 외에도 IPsec을 사용하도록 설정할 수 있습니다. VPN Gateway를 사용하면 온-프레미스 네트워크와 Azure VNet 간 ExpressRoute 회로의 Microsoft 피어링을 통한 IPsec 터널을 설정할 수 있습니다. MACsec은 온-프레미스 네트워크와 Microsoft 간의 물리적 연결을 보호합니다. IPsec은 온-프레미스 네트워크와 Azure의 VNet 간의 엔드투엔드 연결을 보호합니다. MACsec 및 IPsec은 독립적으로 사용하도록 설정할 수 있습니다.

그림 11. 전송 중 데이터에 대한 VPN 및 ExpressRoute 암호화

Microsoft 글로벌 네트워크 백본 간 트래픽

특히 재해 복구 시나리오에서 내구성과 고가용성을 보장하기 위해 Storage 및 SQL Database와 같은 Azure 서비스를 지역 복제용으로 구성할 수 있습니다. Azure는 쌍을 이루는 지역을 사용하여 GRS(지역 중복 스토리지)를 제공하며, Azure SQL Database에 대한 활성 지역 복제를 구성하는 경우에도 쌍을 이루는 지역을 사용하는 것이 좋습니다. 쌍을 이루는 지역은 동일한 지리 내에 있습니다. 그러나 네트워크 트래픽이 항상 한 Azure 지역에서 다른 지역으로 동일한 경로를 따르도록 보장하지는 않습니다. Azure 클라우드에 필요한 안정성을 제공하기 위해, Microsoft는 최적의 안정성을 보장하기 위한 실패 발생 시 실행되는 자동 라우팅 기능이 있는 물리적 네트워크 경로를 많이 갖추고 있습니다.

또한 한 지역 내에서 또는 지역 간에 이동하는 모든 Azure 트래픽은 AES-128 블록 암호를 암호화에 사용하는 MACsec을 사용하여 Microsoft에서 암호화됩니다. 이 트래픽은 전적으로 Microsoft 글로벌 네트워크 백본 내에 유지되며 공용 인터넷에 들어가지 않습니다. 백본은 250,000km가 넘는 광섬유 및 해저 케이블 시스템을 갖춘 세계 최대 규모 중 하나입니다.

Important

전송 중인 모든 데이터가 암호화되도록 하려면 전송 중 데이터 보호에 대한 Azure의 모범 사례를 검토해야 합니다. 주요 Azure PaaS 스토리지 서비스(예: Azure SQL Database, Azure SQL Managed Instance 및 Azure Synapse Analytics)의 경우 전송 중 데이터 암호화가 기본적으로 적용됩니다.

타사 네트워크 가상 어플라이언스

Azure는 클라우드용 Microsoft Defender, Azure Monitor, Azure Firewall, VPN Gateway, 네트워크 보안 그룹, Application Gateway, Azure DDoS Protection, Network Watcher, Microsoft Sentinel 및 Azure Policy를 포함하여 보안 및 격리 목표를 달성하는 데 도움이 되는 다양한 기능을 제공합니다. Azure에서 제공하는 기본 제공 기능 외에도 타사 네트워크 가상 어플라이언스를 사용하여 특정 네트워크 격리 요구 사항을 수용하는 동시에 기존 내부 기술을 적용할 수 있습니다. Azure는 F5, Palo Alto Networks, Cisco, Check Point, Barracuda, Citrix, Fortinet 등의 제품을 포함하여 다양한 어플라이언스를 지원합니다. 네트워크 어플라이언스는 가상 네트워크 및 배포에서 네트워크 기능 및 서비스를 VM의 형태로 지원합니다.

네트워크 격리 제한의 누적 효과는 각 클라우드 서비스가 클라우드 서비스 내의 VM에서 서로 통신할 수 있는 격리된 네트워크에 있는 것처럼 작동하고 다른 당사자가 피어 VM을 가장할 수 없다는 확신을 가지고 원본 IP 주소를 통해 서로를 식별한다는 것입니다. 또한 특정 포트 및 프로토콜을 통해 인터넷에서 들어오는 연결을 허용하고 가상 네트워크에서 나가는 모든 네트워크 트래픽이 항상 암호화되도록 구성할 수도 있습니다.

팁

네이티브 보안 기능을 사용하여 데이터를 보호하는 방법에 대한 지침은 게시된 Azure 네트워킹 설명서를 검토해야 합니다.

추가 리소스:

• Azure 네트워크 보안 개요
• Azure 네트워크 보안

스토리지 격리

Microsoft Azure는 기본 설계의 일부로 VM 기반 컴퓨팅 리소스를 스토리지와 분리합니다. 분리를 통해 컴퓨팅과 스토리지를 독립적으로 크기 조정할 수 있으므로 다중 테넌트 및 격리를 더 쉽게 제공할 수 있습니다. 따라서 Azure Storage는 논리적 격리를 제외하고는 Azure Compute에 대한 네트워크 연결이 없는 별도의 하드웨어에서 실행됩니다.

각 Azure 구독에는 하나 이상의 스토리지 계정이 있을 수 있습니다. Azure 스토리지는 다음을 포함하여 다양한 인증 옵션을 지원합니다.

• 공유 대칭 키 – 스토리지 계정을 만들 때 Azure는 스토리지 계정에 대한 액세스를 제어하는 두 개의 512비트 스토리지 계정 키를 만듭니다. 이후에는 애플리케이션과 조정하지 않고도 언제든지 이러한 키를 회전하고 다시 생성할 수 있습니다.
• Microsoft Entra ID 기반 인증 – Azure Storage에 대한 액세스는 테넌트 격리를 적용하고 Microsoft 참가자를 포함하여 권한이 없는 당사자의 액세스를 방지하기 위한 강력한 조치를 구현하는 Microsoft Entra ID에서 제어할 수 있습니다. Microsoft Entra 테넌트 격리에 대한 자세한 내용은 Microsoft Entra 데이터 보안 고려 사항 백서에서 확인할 수 있습니다.
• SAS(공유 액세스 서명) – 공유 액세스 서명 또는 "미리 서명된 URL"은 공유 대칭 키에서 만들 수 있습니다. 이러한 URL은 사용 가능한 공격 표면을 줄이기 위해 범위를 크게 제한할 수 있지만, 이와 동시에 애플리케이션에서 스토리지 액세스 권한을 다른 사용자, 서비스 또는 디바이스에 부여할 수 있도록 합니다.
• 사용자 위임 SAS – 위임된 인증은 SAS와 비슷하지만 공유 대칭 키가 아닌 Microsoft Entra 토큰을 기반으로 합니다. 이 방법을 사용하면 Microsoft Entra ID로 인증하는 서비스에서 제한된 범위의 미리 서명된 URL을 만들고 임시 액세스 권한을 다른 사용자, 서비스 또는 디바이스에 부여할 수 있습니다.
• 익명 퍼블릭 읽기 액세스 – 인증 또는 권한 부여 없이 스토리지의 일부에 공개적으로 액세스할 수 있도록 허용할 수 있습니다. 더 엄격한 제어를 원하는 경우 구독 수준에서 이 기능을 사용하지 않도록 설정할 수 있습니다.

Azure Storage는 다음을 포함하여 다양한 워크로드에 대한 스토리지를 제공합니다.

• Azure Virtual Machines(디스크 스토리지)
• 빅 데이터 분석(HDInsight용 HDFS, Azure Data Lake Storage)
• 애플리케이션 상태, 사용자 데이터 저장(Blob, Queue, Table Storage)
• 장기 데이터 스토리지(Azure Archive Storage)
• 클라우드의 네트워크 파일 공유(파일 스토리지)
• 인터넷에서 웹 페이지 제공(정적 웹사이트)

Azure Storage는 다양한 외부 연결 고객 스토리지 시나리오를 지원하지만, 내부적으로 위 서비스에 대한 실제 스토리지가 일반적인 API 세트에서 관리됩니다. 내구성과 가용성을 제공하기 위해 Azure Storage는 테넌트 간에 공유되는 스토리지 리소스 간의 데이터 복제 및 데이터 분할을 사용합니다. 논리적 데이터 격리의 암호화 확실성을 보장하기 위해 Azure Storage는 이 섹션에서 설명한 대로 여러 암호화가 포함된 고급 알고리즘을 사용하여 미사용 데이터 암호화를 사용합니다.

데이터 복제

Azure Storage 계정의 데이터는 내구성과 고가용성을 보장하기 위해 항상 복제됩니다. Azure Storage는 일시적인 하드웨어 오류, 네트워크 또는 정전, 심지어 대규모 자연 재해가 일어나도 보호할 수 있도록 사용자 데이터를 복사합니다. 일반적으로 동일한 데이터 센터 내, 동일한 지역 내의 가용성 영역 또는 지리적으로 분리된 지역에 걸쳐 데이터를 복제하도록 선택할 수 있습니다. 특히 스토리지 계정을 만드는 경우 다음 중복성 옵션 중 하나를 선택할 수 있습니다.

• LRS(로컬 중복 스토리지)는 단일 데이터 센터 내에서 데이터의 3개 복사본(또는 나중에 설명하는 초기화 코딩에 상응하는 복사본)을 복제합니다. LRS 스토리지 계정에 대한 쓰기 요청은 데이터가 3개 복제본 모두에 기록된 후에만 성공적으로 반환됩니다. 각 복제본은 배율 단위(데이터 센터 내의 스토리지 랙 집합) 내에서 별도의 장애 도메인 및 업그레이드 도메인에 상주합니다.
• ZRS(영역 중복 스토리지)는 단일 지역에 있는 3개 스토리지 클러스터에 걸쳐 데이터를 동기적으로 복제합니다. 각 스토리지 클러스터는 다른 클러스터와 물리적으로 분리되어 있으며 자체 AZ(가용성 영역)에 있습니다. ZRS 스토리지 계정에 대한 쓰기 요청은 데이터가 세 클러스터에 있는 모든 복제본에 기록된 후에만 성공적으로 반환됩니다.
• GRS(지역 중복 스토리지)는 데이터를 주 지역에서 수백 킬로미터 떨어져 있는 보조(쌍을 이루는) 지역에 복제합니다. GRS 스토리지 계정은 전체 지역 중단 또는 주 지역을 복구할 수 없는 재해가 발생하는 경우에도 내구성이 있습니다. GRS 또는 RA-GRS가 사용하도록 설정된 스토리지 계정의 경우 모든 데이터는 먼저 LRS를 사용하여 복제됩니다. 업데이트는 먼저 기본 위치에 커밋되고 LRS를 사용하여 복제됩니다. 그런 다음, 업데이트는 GRS를 사용하여 보조 지역에 비동기적으로 복제됩니다. 데이터가 보조 위치에 기록되는 경우 LRS를 사용하여 해당 위치 내에도 복제됩니다.
• RA-GRS(읽기 액세스 지역 중복 스토리지)는 GRS를 기준으로 합니다. 두 지역 간의 지역 복제 외에도 보조 위치의 데이터에 대한 읽기 전용 액세스를 제공합니다. RA-GRS를 사용하면 Microsoft에서 주 지역에서 보조 지역으로 장애 조치(failover)를 시작하는지 여부에 관계없이 보조 지역에서 읽을 수 있습니다.
• GZRS(지역 영역 중복 스토리지)는 ZRS의 고가용성과 GRS에서 제공하는 지역 중단 방지 기능을 결합합니다. GZRS 스토리지 계정의 데이터는 주 지역의 3개 AZ에 복제되고 지역 재해로부터 보호하기 위해 보조 지리적 지역에도 복제됩니다. 각 Azure 지역은 동일한 지리 내의 다른 지역과 쌍을 이루어 지역 쌍을 만듭니다.
• RA-GZRS(읽기 액세스 지역 영역 중복 스토리지)는 GZRS를 기반으로 합니다. 주 지역에서 재해가 발생한 후 애플리케이션에서 데이터를 읽을 수 있어야 하는 경우 필요에 따라 RA-GZRS를 사용하여 보조 지역의 데이터에 대한 읽기 액세스를 사용하도록 설정할 수 있습니다.

대략적인 Azure Storage 아키텍처

Azure Storage 프로덕션 시스템은 그림 12와 같이 스토리지 스탬프와 LS(위치 서비스)로 구성됩니다. 스토리지 스탬프는 스토리지 노드 랙의 클러스터이며, 각 랙은 중복 네트워킹 및 전원을 갖춘 별도의 장애 도메인으로 구축됩니다. LS는 모든 스탬프에서 모든 스토리지 스탬프와 계정 네임스페이스를 관리합니다. 부하 분산 및 재해 복구를 위해 계정을 스토리지 스탬프에 할당하고 스토리지 스탬프 전체에서 관리합니다. LS 자체는 자체 재해 복구를 위해 두 지리적 위치에 분산됩니다(Calder 외, 2011).

그림 12. 대략적인 Azure Storage 아키텍처(출처: Calder 외, 2011)

스토리지 스탬프에는 프런트 엔드, 파티션, 스트림의 세 가지 계층이 있습니다. 이러한 계층은 이 섹션의 나머지 부분에서 설명합니다.

프런트 엔드 계층

FE(프런트 엔드) 계층은 들어오는 요청을 받아서 인증하고 권한을 부여한 다음, 이러한 요청을 파티션 계층의 파티션 서버로 라우팅하는 상태 비저장 서버 세트로 구성됩니다. FE 계층은 각 프런트 엔드 서버에서 파티션 맵을 캐시하므로 각 요청을 전달할 파티션 서버를 인식하고 있습니다. 파티션 맵은 액세스되는 서비스에 대한 파티션과 시스템의 각 파티션에 대한 액세스를 제어(제공)하는 파티션 서버를 추적합니다. FE 서버는 스트림 계층에서 직접 큰 개체를 스트림합니다.

인터넷을 통해 대량의 데이터를 전송하는 것은 본질적으로 신뢰할 수 없습니다. Azure 블록 Blob 서비스를 사용하면 큰 파일을 더 작은 데이터 블록으로 분할하여 큰 파일을 효율적으로 업로드하고 저장할 수 있습니다. 이 방식으로 블록 Blob을 사용하면 그림 13과 같이 대규모 업로드의 안정성을 위해 데이터를 개별 블록으로 분할할 수 있습니다. 각 블록의 크기는 최대 100MB이며, 블록 Blob에는 최대 50,000개의 블록이 포함될 수 있습니다. 블록이 올바르게 전송되지 않는 경우 전체 파일을 다시 보내지 않고 해당 특정 블록만 다시 보내면 됩니다. 또한 블록 Blob을 사용하면 여러 블록을 병렬로 보내 업로드 시간을 줄일 수 있습니다.

그림 13. 데이터를 개별 블록으로 분할하는 블록 Blob

블록을 원하는 순서로 업로드하고 최종 차단 목록 커밋 단계에서 순서를 결정할 수 있습니다. 또한 새 블록을 업로드하여 동일한 블록 ID의 커밋되지 않은 기존 블록을 대체할 수 있습니다.

파티션 계층

파티션 계층에서 수행하는 작업은 다음과 같습니다.

• 더 높은 수준의 데이터 추상화(Blob, 테이블, 큐) 관리,
• 확장성 있는 개체 네임스페이스 제공,
• 개체에 대한 트랜잭션 순서 지정 및 강력한 일관성 제공,
• 스트림 계층 위에 개체 데이터 저장 및
• 디스크 I/O를 줄이기 위해 개체 데이터 캐싱

또한 이 계층은 데이터의 비동기 지역 복제를 제공하며 스탬프 간 데이터 복제에 중점을 둡니다. 스탬프 간 복제는 재해 복구를 위해 백그라운드에서 수행되어 데이터 복사본을 두 위치에 유지합니다.

Blob이 FE 계층에서 수집되면 파티션 계층에서 데이터가 스트림 계층에 배치되는 위치를 추적하고 저장합니다. 각 스토리지 테넌트에는 약 200~300개의 개별 파티션 계층 노드가 있을 수 있으며, 각 노드는 해당 Storage 테넌트에 저장된 데이터의 파티션을 추적하고 처리합니다. HTBB(높은 처리량 블록 Blob) 기능을 사용하면 단일 Blob 내에서 데이터를 분할할 수 있으므로 여러 파티션 계층 서버에서 큰 Blob에 대한 워크로드를 공유할 수 있습니다(그림 14). 여러 파티션 계층 서버 간에 부하를 분산하면 가용성, 처리량 및 내구성이 크게 향상됩니다.

그림 14. 트래픽과 데이터가 여러 파티션 서버 및 스트림에 분산되는 처리량이 높은 블록 Blob

스트림 계층

스트림 계층은 비트를 디스크에 저장하고, 여러 서버에서 데이터를 배포하고 복제하여 스토리지 스탬프 내에서 데이터 내구성을 유지합니다. 스탬프 내에서 분산 파일 시스템 계층 역할을 합니다. 실제 하드 드라이브의 익스텐트와 비슷한 익스텐트라고 하는 데이터 블록의 순서가 지정된 목록인 스트림이라는 파일을 처리합니다. 큰 Blob 개체는 여러 익스텐트, 잠재적으로 여러 물리적 EN(익스텐트 노드)에 저장할 수 있습니다. 데이터는 스트림 계층에 저장되지만 파티션 계층에서 액세스할 수 있습니다. 파티션 서버와 스트림 서버는 스탬프의 각 스토리지 노드에 공동 배치됩니다.

스트림 계층은 스탬프 내에서 데이터 지속성을 유지하기 위해 서로 다른 장애 도메인의 여러 노드에서 동기 복제(스탬프 내)를 제공합니다. 각 익스텐트의 3개 로컬 복제 복사본을 만듭니다. 스트림 계층 관리자는 세 복사본을 개별 디스크/노드/랙 장애 및 업그레이드로 인한 계획된 가동 중지 시간에 대해 복원할 수 있도록 이러한 복사본이 모두 서로 다른 장애 도메인 및 업그레이드 도메인의 서로 다른 실제 랙과 노드에 배포되도록 합니다.

초기화 코딩 – Azure Storage는 디스크 오류로 인해 일부 데이터가 누락된 경우에도 데이터를 재구성할 수 있는 초기화 코딩이라는 기술을 사용합니다. 이 방법은 데이터가 여러 디스크에 분산되어 있는 개별 디스크에 대한 RAID 스트라이핑 개념과 비슷하므로 디스크가 손실되는 경우 다른 디스크에 있는 데이터의 패리티 비트를 사용하여 누락된 데이터를 다시 구성할 수 있습니다. 그림 15와 같이 초기화 코딩은 익스텐트를 별도의 EN에 저장되는 동일한 데이터 및 패리티 조각으로 분할합니다.

그림 15. 장애로부터 보호하기 위해 EN 서버 전체에서 익스텐트 데이터를 추가로 분할하는 초기화 코딩

스트림 익스텐트 노드에 저장된 모든 데이터 블록에는 64비트 CRC(순환 중복 검사)와 익스텐트 노드(EN) 데이터 무결성을 제공하기 위해 해시 서명으로 보호되는 헤더가 있습니다. CRC와 서명은 모든 디스크 쓰기, 디스크 읽기 및 네트워크 수신 전에 확인됩니다. 또한 스크러버 프로세스는 정기적으로 모든 데이터를 읽어 CRC를 확인하고 비트 부패를 찾습니다. 잘못된 익스텐트가 있으면 잘못된 익스텐트를 대체하기 위해 해당 익스텐트의 복사본이 새로 만들어집니다.

Azure Storage의 데이터는 미사용 데이터 암호화를 사용하여 논리적 데이터 격리에 대한 암호화 확실성을 제공합니다. Microsoft 관리형 암호화 키(플랫폼 관리형 암호화 키라고도 함) 또는 CMK(고객 관리형 암호화 키) 중에서 선택할 수 있습니다. 다음 섹션에서 설명한 대로 데이터 암호화 및 암호 해독 처리는 고객에게 투명합니다.

휴지 상태의 암호화

Microsoft 관리형 암호화 키와 고객 관리형 암호화 키를 모두 사용하는 경우 Azure는 데이터를 보호하고 규정 준수 요구 사항을 충족하는 데 도움이 되는 미사용 데이터 암호화에 대한 광범위한 옵션을 제공합니다. 자세한 내용은 데이터 암호화 모델을 참조하세요. 이 프로세스는 Azure Key Vault 및 Microsoft Entra ID와 같은 여러 암호화 키와 서비스를 사용하여 보안 키 액세스 및 중앙 집중식 키 관리를 보장합니다.

참고 항목

Azure 서비스에 저장된 가장 중요한 데이터에 대한 추가 보안 및 격리 보증이 필요한 경우 Azure Key Vault에서 제어하는 사용자 고유의 암호화 키를 사용하여 암호화할 수 있습니다.

일반적으로 키 액세스를 제어하고 데이터의 효율적인 대량 암호화 및 암호 해독을 보장하는 것은 다음 유형의 암호화 키(그림 16 참조)를 통해 수행됩니다. 하지만 Storage 서비스 암호화 섹션에서 설명한 대로 다른 암호화 키를 사용할 수도 있습니다.

• DEK(데이터 암호화 키)는 파티션 또는 데이터 블록의 대량 암호화 및 암호 해독에 사용되는 대칭 AES-256 키입니다. 암호화 모듈은 Windows FIPS 유효성 검사 프로그램의 일환으로 FIPS 140 유효성 검사를 받았습니다. DEK에 대한 액세스는 특정 데이터 블록을 암호화하고 암호 해독하는 리소스 공급자 또는 애플리케이션 인스턴스에 필요합니다. 단일 리소스에는 많은 파티션과 많은 DEK가 있을 수 있습니다. DEK가 새 키로 대체되면 연결된 블록의 데이터만 새 키로 다시 암호화해야 합니다. DEK는 항상 KEK(키 암호화 키)로 암호화되어 저장됩니다.
• KEK(키 암호화 키)는 사용자가 필요에 따라 제공하는 비대칭 RSA 키입니다. 이 키 암호화 키는 Azure Key Vault 또는 관리되는 HSM을 사용하여 DEK(데이터 암호화 키)를 암호화하는 데 사용됩니다. 이전의 데이터 암호화 키 관리 섹션에서 설명한 대로 Azure Key Vault는 FIPS 140 유효성이 검사된 HSM(하드웨어 보안 모듈)을 사용하여 암호화 키를 보호할 수 있습니다. 관리되는 HSM은 항상 FIPS 140 유효성이 검사된 하드웨어 보안 모듈을 사용합니다. 이러한 키는 내보낼 수 없으며 KEK의 일반 텍스트 버전이 HSM 외부에 있을 수 없습니다. 바인딩은 기본 HSM에서 적용됩니다. KEK는 리소스 공급자 또는 다른 서비스에 직접 공개되지 않습니다. KEK에 대한 액세스는 Azure Key Vault의 권한으로 제어되며, Azure Key Vault에 대한 액세스는 Microsoft Entra ID를 통해 인증되어야 합니다. 이러한 권한을 철회하여 이 키에 대한 액세스를 차단하고, 더 나아가 이 키를 키 체인의 루트로 사용하여 암호화된 데이터에 대한 액세스도 차단할 수 있습니다.

그림 16. Azure Key Vault에 저장된 키를 사용하여 암호화되는 데이터 암호화 키

따라서 암호화 키 계층 구조에는 DEK와 KEK가 모두 포함됩니다. DEK는 KEK로 암호화되고 대량 암호화 및 암호 해독 작업에서 리소스 공급자가 효율적으로 액세스할 수 있도록 별도로 저장됩니다. 그러나 KEK에 액세스할 수 있는 엔터티만 DEK를 해독할 수 있습니다. KEK에 액세스할 수 있는 엔터티는 DEK가 필요한 엔터티와 다를 수 있습니다. DEK를 암호 해독하려면 KEK가 필요하므로 KEK는 실질적으로 KEK 삭제를 통해 DEK를 삭제할 수 있는 단일 지점입니다.

다양한 데이터 암호화 모델에 대한 자세한 정보와 여러 Azure 플랫폼 서비스의 키 관리에 대한 구체적인 사항은 온라인 설명서에서 확인할 수 있습니다. 또한 일부 Azure 서비스는 클라이언트 쪽 암호화를 포함한 다른 암호화 모델을 제공하여 더 세부적인 제어를 통해 데이터를 추가로 암호화합니다. 이 섹션의 나머지 부분에서는 IaaS Virtual Machines에 대한 Storage 서비스 암호화 및 디스크 암호화와 같은 주요 Azure 스토리지 시나리오에 대한 암호화 구현에 대해 설명합니다.

팁

데이터를 보호하는 방법에 대한 지침은 게시된 Azure 데이터 암호화 설명서를 검토해야 합니다.

추가 리소스:

• 미사용 데이터 암호화 개요
• 데이터 암호화 모델
• 데이터 암호화 모범 사례

스토리지 서비스 암호화

미사용 데이터에 대한 Azure Storage 서비스 암호화는 데이터를 Azure Storage에 유지하기 전에 자동으로 암호화하고 검색하기 전에 암호를 해독하도록 보장합니다. Azure Storage에 기록된 모든 데이터는 FIPS 140 유효성이 검사된 256비트 AES 암호화를 통해 암호화되며, Storage 서비스 암호화의 암호화, 암호 해독 및 키 관리 처리는 고객에게 투명합니다. 기본적으로 Microsoft는 암호화 키를 제어하고 키 회전, 사용 및 액세스를 담당합니다. 키는 안전하게 저장되며 Microsoft 키 저장소 내에서 보호됩니다. 이 옵션은 모든 Azure Storage 서비스가 지원된다는 점을 고려할 때 가장 편리한 기능을 제공합니다.

그러나 다음을 지정하여 사용자 고유의 키를 사용하여 암호화를 관리하도록 선택할 수도 있습니다.

• Azure Storage 암호화를 관리하기 위한 고객 관리형 키. 이 키는 Azure Key Vault에 저장됩니다. 이 옵션은 고객 관리형 키에 대한 액세스를 만들고, 회전하고, 사용하지 않도록 설정하고, 철회할 수 있는 많은 유연성을 제공합니다. 고객 관리형 키를 저장하려면 Azure Key Vault를 사용해야 합니다. 이전의 Azure Key Vault 섹션에서 설명한 대로 키 자격 증명 모음과 관리되는 HSM이 모두 지원됩니다.
• 규정 준수 요구 사항을 충족하기 위해 키를 Azure Key Vault 또는 온-프레미스의 다른 키 저장소에 저장할 수 있는 Blob 스토리지만 암호화 및 암호 해독하기 위한 고객 제공 키. 고객 제공 키를 사용하면 읽기 또는 쓰기 작업의 일환으로 Blob API를 사용하여 암호화 키를 Storage 서비스에 전달할 수 있습니다.

참고 항목

Azure Key Vault에서 CMK(고객 관리형 키)는 Azure Portal, Azure PowerShell 또는 Azure CLI를 사용하여 구성할 수 있습니다. .NET을 사용하여 고객 제공 키를 Blob 스토리지에 대한 요청에 지정할 수 있습니다.

Storage 서비스 암호화는 기본적으로 모든 새 스토리지 및 기존 스토리지 계정에 사용하도록 설정되며 사용하지 않도록 설정할 수 없습니다. 그림 17과 같이 암호화 프로세스는 다음 키를 사용하여 미사용 데이터 격리의 암호화 확실성을 보장합니다.

• DEK(데이터 암호화 키)는 대량 암호화에 사용되는 대칭 AES-256 키이며 Azure Storage의 스토리지 계정별로 고유합니다. 이는 스토리지 계정 만들기의 일환으로 Azure Storage 서비스에서 만들어지며 각 데이터 블록에 대한 고유 키를 파생하는 데 사용됩니다. 고객이 고객 관리형 키 암호화를 구성한 경우 Storage 서비스는 항상 스탬프 키 또는 키 암호화 키를 사용하여 DEK를 암호화합니다.
• KEK(키 암호화 키)는 고객이 관리하는 비대칭 RSA(2048 이상) 키이며, Azure Key Vault 또는 관리되는 HSM을 사용하여 DEK(데이터 암호화 키)를 암호화하는 데 사용됩니다. Azure Storage 서비스 또는 다른 서비스에 직접 공개되지 않습니다.
• SK(스탬프 키)는 Azure Storage에서 관리하는 대칭 AES-256 키입니다. 이 키는 고객 관리형 키를 사용하지 않을 때 DEK를 보호하는 데 사용됩니다.

이러한 키는 Azure Storage에 기록된 모든 데이터를 보호하고 Azure Storage의 논리적 데이터 격리에 대한 암호화 확실성을 제공합니다. 앞에서 설명한 대로 Azure Storage 서비스 암호화는 기본적으로 사용하도록 설정되며 사용하지 않도록 설정할 수 없습니다.

그림 17. Storage 서비스 암호화에 대한 암호화 흐름

스토리지 계정은 성능 계층(표준 또는 프리미엄) 또는 배포 모델(Azure Resource Manager 또는 클래식)에 관계없이 암호화됩니다. 모든 Azure Storage 중복성 옵션은 암호화를 지원하며 스토리지 계정의 모든 복사본이 암호화됩니다. BLOB, 디스크, 파일, 큐 및 테이블 등 모든 Azure Storage 리소스가 암호화됩니다. 모든 개체 메타데이터도 암호화됩니다.

데이터 암호화는 Storage 서비스에서 수행되므로 CMK를 사용하는 서버 쪽 암호화를 사용하면 VM에 대한 모든 운영 체제 유형 및 이미지를 사용할 수 있습니다. Windows 및 Linux IaaS VM의 경우 Azure는 다음 섹션에서 설명한 대로 호스트에서 바로 디스크 데이터를 암호화하는 게스트 VM 또는 EncryptionAtHost 내에서 CMK를 사용하여 관리 디스크를 암호화할 수 있는 Azure Disk Encryption도 제공합니다. 또한 Azure Storage 서비스 암호화는 미사용 디스크 데이터의 이중 암호화도 제공합니다.

Azure Disk Encryption

Azure Storage 서비스 암호화는 Azure Virtual Machine 디스크를 저장하는 페이지 Blob을 암호화합니다. 또한 필요에 따라 Azure Disk Encryption을 사용하여 Azure Windows 및 Linux IaaS Virtual Machine 디스크를 암호화하여 스토리지 격리를 강화하고 Azure에 저장된 데이터의 암호화 확실성을 보장할 수 있습니다. 이 암호화에는 이 섹션의 뒷부분에서 설명한 대로 관리 디스크가 포함됩니다. Azure Disk Encryption은 Windows의 업계 표준 BitLocker 기능과 Linux의 DM-Crypt 기능을 사용하여 Azure Key Vault와 통합되는 OS 기반 볼륨 암호화를 제공합니다.

BitLocker 및 DM-Crypt를 통한 드라이브 암호화는 운영 체제와 통합되어 분실, 도난 또는 부적절하게 서비스 해제된 컴퓨터로부터의 데이터 도난 또는 공개 위협을 해결하는 데이터 보호 기능입니다. BitLocker 및 DM-Crypt는 TPM(신뢰할 수 있는 플랫폼 모듈) 버전 1.2 이상에서 사용할 때 가장 많은 보호를 제공합니다. TPM은 통합 암호화 키를 통해 하드웨어를 보호하도록 설계된 마이크로 컨트롤러이며, 일반적으로 최신 컴퓨터에 사전 설치됩니다. BitLocker와 DM-Crypt는 이 기술을 사용하여 디스크 볼륨을 암호화하는 데 사용되는 키를 보호하고 무결성을 컴퓨터 부팅 프로세스에 제공할 수 있습니다.

관리 디스크의 경우 Azure Disk Encryption을 사용하면 IaaS 가상 머신에서 사용하는 OS 및 데이터 디스크를 암호화할 수 있습니다. 그러나 먼저 OS 볼륨을 암호화한 후에 데이터를 암호화할 수 있습니다. 이 솔루션은 Azure Key Vault를 사용하여 키 자격 증명 모음의 디스크 암호화 키를 제어하고 관리하는 데 도움을 줍니다. 이전의 데이터 암호화 키 관리 섹션에서 설명한 대로 BYOK(Bring Your Own Key) 시나리오를 지원하기 위해 Azure Key Vault에서 보호되는 사용자 고유의 암호화 키를 제공할 수 있습니다.

Azure Disk Encryption은 관리되는 HSM 또는 온-프레미스 키 관리 서비스를 지원하지 않습니다. Azure Key Vault 서비스에서 관리하는 키 자격 증명 모음만 Azure Disk Encryption에 대한 고객 관리형 암호화 키를 보호하는 데 사용할 수 있습니다. 관리되는 HSM과 관련된 다른 옵션은 호스트에서 암호화를 참조하세요.

참고 항목

자세한 지침은 Windows 및 Linux VM 모두에서 Azure Disk Encryption에 대한 키 자격 증명 모음을 만들고 구성하는 데 사용할 수 있습니다.

Azure Disk Encryption은 앞에서 설명한 대로 구현을 위해 다음 두 개의 암호화 키를 사용합니다.

• DEK(데이터 암호화 키)는 BitLocker 또는 DM-Crypt를 통해 OS 및 데이터 볼륨을 암호화하는 데 사용되는 대칭 AES-256 키입니다. DEK 자체는 암호화되어 데이터와 가까운 내부 위치에 저장됩니다.
• KEK(키 암호화 키)는 데이터 암호화 키를 암호화하는 데 사용되는 비대칭 RSA-2048 키입니다. KEK는 Microsoft Entra ID를 통한 액세스 권한 부여를 포함하여 사용자가 제어할 수 있는 Azure Key Vault에 유지됩니다.

KEK로 암호화된 DEK는 별도로 저장되며, KEK에 액세스할 수 있는 엔터티만 DEK의 암호를 해독할 수 있습니다. KEK에 대한 액세스는 키를 FIPS 140 유효성이 검사된 하드웨어 보안 모듈에 저장하도록 선택할 수 있는 Azure Key Vault에서 보호됩니다.

Windows VM의 경우 Azure Disk Encryption은 Windows 버전에 따라 BitLocker의 암호화 방법을 선택합니다(예: Windows Server 2012 이상에서는 XTS-AES 256비트). 이러한 암호화 모듈은 Microsoft Windows FIPS 유효성 검사 프로그램의 일부로 유효성이 검사된 FIPS 140입니다. Linux VM의 경우 Azure Disk Encryption은 Microsoft Azure Marketplace의 Linux IaaS VM 이미지 공급업체에서 획득한 DM-Crypt 유효성 검사의 일환으로 FIPS 140 유효성이 검사된 256비트 볼륨 마스터 키와 함께 aes-xts-plain64 암호 해독 기본값을 사용합니다.

관리 디스크에 대한 서버 쪽 암호화

Azure 관리 디스크는 Azure에서 관리하고 Azure Windows 및 Linux 가상 머신에서 사용되는 블록 수준 스토리지 볼륨입니다. 스토리지 계정 관리를 투명하게 처리하여 Azure IaaS VM에 대한 디스크 관리를 간소화합니다. Azure 관리 디스크는 기본적으로 FIPS 140 유효성이 검사된 256비트 AES 암호화를 사용하여 데이터를 자동으로 암호화합니다. 암호화 키 관리의 경우 다음과 같은 선택 사항이 있습니다.

• 플랫폼 관리형 키는 Microsoft에서 키를 관리하는 관리 디스크에 대해 투명한 미사용 데이터 암호화를 제공하는 기본 선택 사항입니다.
• 고객 관리형 키를 사용하면 Azure Key Vault 또는 관리되는 HSM으로 가져오거나 내부에서 생성할 수 있는 사용자 고유의 키를 제어할 수 있습니다. 이 방법은 앞에서 설명한 대로 DEK와 KEK라는 두 가지 키 세트를 사용합니다. DEK는 AES-256 기반 암호화를 사용하여 데이터를 암호화하고 Azure Key Vault 또는 관리되는 HSM에 저장된 RSA KEK를 통해 암호화됩니다.

CMK(고객 관리형 키)를 사용하면 암호화 키를 완전히 제어할 수 있습니다. DEK를 암호화 및 암호 해독하는 데 키를 사용할 수 있도록 Azure Key Vault에서 관리 디스크에 대한 액세스 권한을 부여할 수 있습니다. 언제든지 키를 사용하지 않도록 설정하거나 관리 디스크에 대한 액세스를 철회할 수도 있습니다. 마지막으로, Azure Key Vault 모니터링을 통해 키 사용에 대한 감사를 완전히 제어하여 관리 디스크 또는 권한 있는 다른 리소스만 암호화 키에 액세스하고 있는지 확인할 수 있습니다.

호스트에서 암호화

호스트에서 암호화는 서버 쪽 암호화에서 사용하여 VM 호스트에 저장된 데이터가 미사용 시 암호화되고 Storage 서비스에 암호화된 채로 이동하도록 합니다. VM을 호스트하는 서버는 성능에 영향을 주지 않거나 게스트 VM에서 실행되는 코드에 대한 요구 사항 없이 데이터를 암호화하고, 암호화된 데이터는 서버 쪽 암호화에 대해 구성된 키를 사용하여 Azure Storage로 이동합니다. 자세한 내용은 호스트에서 암호화 - VM 데이터에 대한 엔드투엔드 암호화를 참조하세요. CMK를 사용하는 호스트에서 암호화는 관리 디스크에 대한 서버 쪽 암호화와 마찬가지로 관리되는 HSM 또는 Key Vault에 저장된 키를 사용할 수 있습니다.

고객 데이터는 항상 Azure에서 제어할 수 있습니다. Azure에 저장된 고객 데이터에 자유롭게 액세스하고, 추출하고, 삭제할 수 있습니다. Azure 구독이 종료되면 Microsoft는 사용자가 고객 데이터를 계속 소유할 수 있도록 필요한 단계를 수행합니다. 데이터 삭제 또는 구독 종료와 관련된 일반적인 문제는 다른 고객 또는 Azure 관리자가 삭제된 데이터에 액세스할 수 있는지 여부입니다. 다음 섹션에서는 Azure에서 데이터 삭제, 보존 및 폐기가 작동하는 방식을 설명합니다.

데이터 삭제

스토리지는 드물게 할당됩니다. 즉, 가상 디스크를 만들면 디스크 공간이 전체 용량으로 할당되지 않습니다. 대신 가상 디스크의 주소를 실제 디스크의 영역에 매핑하는 테이블이 만들어지며, 이 테이블은 처음에는 비어 있습니다. 데이터를 가상 디스크에 처음 쓰면 실제 디스크의 공간이 할당되고 이에 대한 포인터가 테이블에 배치됩니다. 자세한 내용은 Azure 데이터 보안 - 데이터 정리 및 유출을 참조하세요.

Blob 또는 테이블 엔터티를 삭제하면 기본 위치에서 데이터를 찾고 액세스하는 데 사용되는 인덱스에서 즉시 삭제된 다음, 지역 중복 스토리지를 프로비전한 경우 지역에서 복제된 데이터 복사본에서 삭제가 비동기적으로 수행됩니다. 기본 위치에서는 Blob 또는 엔터티에 즉시 액세스하려고 시도할 수 있지만 Azure는 삭제에 대한 강력한 일관성을 제공하므로 인덱스에서 찾을 수 없습니다. 따라서 데이터가 삭제되었는지 직접 확인할 수 있습니다.

Azure Storage에서 모든 디스크 쓰기는 순차적으로 기록됩니다. 이 방법은 디스크 "검색" 양을 최소화하지만 개체가 기록될 때마다 해당 개체에 대한 포인터를 업데이트해야 합니다. 포인터의 새 버전도 순차적으로 기록됩니다. 이 설계의 부작용은 디스크의 비밀을 다른 데이터로 덮어써서 사라지도록 보장할 수 없다는 것입니다. 원본 데이터는 디스크에 그대로 유지되고 새 값은 순차적으로 기록됩니다. 삭제된 값을 더 이상 찾을 수 없도록 포인터가 업데이트됩니다. 그러나 디스크가 가득 차면 시스템에서 새 로그를 오래된 데이터를 삭제하여 확보된 디스크 공간에 작성해야 합니다. 디스크 섹터에서 직접 로그 파일을 할당하는 대신 로그 파일이 NTFS를 실행하는 파일 시스템에 만들어집니다. Azure Storage 노드에서 실행되는 백그라운드 스레드는 가장 오래된 로그 파일을 살펴보고, 가장 오래된 로그 파일에서 여전히 참조되는 블록을 현재 로그 파일에 복사하고, 진행되는 모든 포인터를 업데이트하여 공간을 확보합니다. 그런 다음, 가장 오래된 로그 파일을 삭제합니다. 따라서 디스크에는 다음 두 가지 범주의 사용 가능한 디스크 공간이 있습니다. (1) NTFS에서 인식하는 사용 가능한 공간이며, 이 풀에서 새 로그 파일이 할당됩니다. (2) Azure Storage에서 인식하는 이러한 로그 파일 내의 공간이며, 현재 포인터가 없으므로 사용 가능합니다.

삭제된 데이터와 연결된 실제 디스크의 섹터는 즉시 다시 사용할 수 있게 되며, 해당 스토리지 블록을 다른 데이터 저장에 다시 사용할 때 덮어쓰여집니다. 덮어쓰는 시간은 디스크 사용률 및 작업에 따라 달라집니다. 이 프로세스는 모든 쓰기가 디스크에 순차적으로 기록되는 로그 구조 파일 시스템의 작업과 일치합니다. 이 프로세스는 결정적이지 않으며 실제 스토리지에서 특정 데이터가 사라지는 시기를 보장할 수 없습니다. 그러나 정확히 삭제된 데이터를 덮어쓰거나 다른 고객에게 할당한 해당 실제 스토리지가 삭제 후 데이터를 복구할 수 없다는 키 격리 보증과 관련이 없는 경우 다음과 같습니다.

• 고객이 다른 고객의 삭제된 데이터를 읽을 수 없습니다.
• 사용자가 아직 쓰지 않은 가상 디스크의 영역을 읽으려고 하면 실제 공간이 해당 영역에 할당되지 않았으므로 0만 반환됩니다.

고객에게는 기본 실제 스토리지에 대한 직접 액세스 권한이 제공되지 않습니다. 고객 소프트웨어는 가상 디스크에만 주소를 지정하므로 다른 고객이 사용자에게 할당된 실제 주소 또는 사용 가능한 실제 주소에 대한 읽기 또는 쓰기 요청을 표현할 수 없습니다.

개념적으로 이 근거는 읽기 및 쓰기를 추적하는 소프트웨어에 관계없이 적용됩니다. Azure SQL Database의 경우 이러한 적용은 SQL Database 소프트웨어에서 수행합니다. Azure Storage의 경우 Azure Storage 소프트웨어입니다. VM의 비내구성 드라이브의 경우 호스트 OS의 VHD 처리 코드입니다. 가상 주소에서 실제 주소로의 매핑은 고객 VM 외부에서 수행됩니다.

마지막으로, 미사용 데이터 암호화 섹션과 그림 16에서 설명한 대로 암호화 키 계층 구조는 사용자가 제어하는 Azure Key Vault에 보관하고(즉, CMK(고객 관리형 키)) DEK(데이터 암호화 키)를 암호화하여 AES-256 대칭 암호화를 통해 미사용 데이터를 암호화하는 데 사용할 수 있는 KEK(키 암호화 키)를 사용합니다. Azure Storage의 데이터는 기본적으로 미사용 시 암호화되며 사용자가 암호화 키를 직접 제어하도록 선택할 수 있습니다. 이 방식으로 Azure에 저장된 데이터에 대한 액세스도 방지할 수 있습니다. 또한 DEK를 암호 해독하려면 KEK가 필요하므로 KEK는 실질적으로 KEK 삭제를 통해 DEK를 삭제할 수 있는 단일 지점입니다.

데이터 보존

Azure 구독 기간 동안 사용자는 항상 Azure에 저장된 데이터에 액세스하고, 추출하고, 삭제할 수 있습니다.

구독이 만료되거나 종료되는 경우 Microsoft는 사용자가 데이터를 추출하거나 구독을 갱신할 수 있도록 90일 보존 기간 동안 고객 데이터를 유지합니다. 이 보존 기간이 지나면 Microsoft는 향후 90일 이내에 모든 고객 데이터를 삭제합니다. 즉, 고객 데이터는 만료 또는 종료로부터 180일 후에 영구적으로 삭제됩니다. 데이터 보존 절차를 고려할 때 Microsoft와 협력하여 서비스를 종료하는 타이밍에 따라 데이터가 저장되는 기간을 제어할 수 있습니다. 나중에 데이터가 누락되었음을 알게 되는 경우 초기 90일 보존 기간이 안전 버퍼 역할을 할 수 있도록 모든 데이터를 추출할 때까지 서비스를 종료하지 않는 것이 좋습니다.

전체 스토리지 계정을 실수로 삭제한 경우 Azure 지원에 즉시 문의하여 복구 지원을 받아야 합니다. Azure Portal에서 지원 요청을 만들고 관리할 수 있습니다. 구독 내에서 삭제된 스토리지 계정은 실수로 인한 삭제를 복구할 수 있도록 2주 동안 유지되며, 그 후에는 영구적으로 삭제됩니다. 그러나 스토리지 개체(예: Blob, 파일, 큐, 테이블) 자체가 삭제되면 삭제 작업은 즉각적이고 되돌릴 수 없습니다. 백업한 경우에만 삭제된 스토리지 개체를 복구할 수 있습니다. Blob 스토리지의 경우 일시 삭제를 사용하도록 설정하여 실수이거나 잘못된 수정 또는 삭제에 대한 추가 보호를 구현할 수 있습니다. 일시 삭제가 스토리지 계정에 사용하도록 설정되면 해당 스토리지 계정의 Blob, Blob 버전 및 스냅샷은 삭제된 후 지정된 보관 기간 내에 복구할 수 있습니다. 스토리지 계정 또는 구독 삭제 후 데이터 보존을 방지하려면 스토리지 계정 또는 구독을 삭제하기 전에 스토리지 개체를 개별적으로 삭제할 수 있습니다.

Azure SQL Database와 관련하여 실수로 삭제된 경우 서비스에서 자동으로 만드는 백업을 확인하고 특정 시점 복원을 사용해야 합니다. 예를 들어 전체 데이터베이스 백업은 매주 수행되고 차등 데이터베이스 백업은 매시간 수행됩니다. 또한 개별 서비스(예: Azure DevOps)에는 실수로 인한 데이터 삭제에 대한 자체 정책이 있을 수 있습니다.

데이터 파기

하드웨어 오류가 스토리지에 사용되는 디스크 드라이브에 발생하면 서비스 해제되기 전에 해당 드라이브가 안전하게 초기화되거나 폐기됩니다. 데이터를 어떤 방법으로도 복구할 수 없도록 드라이브의 데이터가 초기화됩니다. 이러한 디바이스가 서비스 해제되면 Microsoft는 FIPS 199 Moderate에 맞춘 데이터 분류를 사용하여 NIST SP 800-88 R1 폐기 프로세스를 따릅니다. 자기, 전자 또는 광학 미디어는 NIST SP 800-88 R1에 설정된 요구 사항에 따라 제거되거나 폐기됩니다. 여기서 용어는 다음과 같이 정의됩니다.

• 제거 – "실험실 공격으로부터 정보의 기밀성을 보호하는 미디어 삭제 프로세스"입니다. 여기에는 "신호 처리 장비 및 특별히 훈련된 인력"을 사용하여 "일반 운영 환경 외부의 미디어에 대한 데이터 복구 시도를 수행하는 비표준 시스템을 사용하는 데 필요한 리소스 및 지식"이 포함됩니다. 참고: 하드 디스크 드라이브(ATA, SCSI, SATA, SAS 등 포함)의 경우 펌웨어 수준 보안 초기화(secure-erase) 명령(단일 패스)이 허용되거나 복구 영역이 있는 경우 이를 포함하여 전체 물리적 미디어에 대한 소프트웨어 수준의 3패스 덮어쓰기 및 확인(1, 0, 임의)이 허용됩니다. SSD(반도체 디스크)의 경우 펌웨어 수준 보안 초기화 명령이 필요합니다.
• 폐기 – 미디어를 "원래 의도한 대로 재사용할 수 없는" "분해, 소각, 분쇄, 파쇄, 용융을 포함한 다양한 방법"입니다.

제거 및 폐기 작업은 Microsoft 보안에서 승인한 도구 및 프로세스를 사용하여 수행해야 합니다. 자산의 초기화 및 폐기에 대한 기록을 보관해야 합니다. 제거를 성공적으로 완료하지 못한 디바이스는 자기를 소거하거나(자기 미디어만 해당) 폐기해야 합니다.

Azure 컴퓨팅, 네트워킹 및 스토리지 격리를 가능하게 하는 기술 구현 세부 정보 외에도 Microsoft는 다음 섹션에서 설명한 대로 논리적으로 격리된 서비스 및 시스템을 올바르게 개발하기 위해 보안 보증 프로세스 및 사례에 많은 투자를 했습니다.

보안 보증 프로세스 및 사례

공격 표면을 보호하고 위협을 완화하기 위해 Microsoft에서 SDL(보안 개발 수명 주기) 및 기타 강력한 보안 보증 프로세스를 내부적으로 사용하여 Azure 격리 보증이 더 강화됩니다. Microsoft는 Azure 격리 보장에 대한 높은 신뢰도를 제공하는 업계 최고의 프로세스와 도구를 구축했습니다.

• SDL(보안 개발 수명 주기) – Microsoft SDL은 개발 프로세스의 모든 단계에서 보안 및 개인 정보 보호 고려 사항을 도입하여 개발자가 매우 안전한 소프트웨어를 구축하고, 보안 규정 준수 요구 사항을 처리하며, 개발 비용을 절감할 수 있도록 지원합니다. Microsoft SDL의 지침, 모범 사례, 도구 및 프로세스는 모든 Azure 서비스를 구축하고 더 안전한 제품과 서비스를 만들기 위해 내부적으로 사용되는 사례입니다. 또한 이 프로세스는 Microsoft의 학습을 더 광범위한 업계와 공유하고 업계 피드백을 통합하여 더 강력한 보안 개발 프로세스를 만들기 위해 공개적으로 문서화되어 있습니다.
• 도구 및 프로세스 – 모든 Azure 코드에는 잠재적인 취약성, 비효율적인 보안 패턴, 메모리 손상, 사용자 권한 문제 및 기타 중요한 보안 문제를 식별하는 광범위한 정적 및 동적 분석 도구 세트가 적용됩니다.
  • 용도에 맞게 빌드된 퍼지 테스트 – 소프트웨어 제품 및 서비스의 보안 취약성을 찾는 데 사용되는 테스트 기술입니다. 수정되거나 퍼지 테스트된 데이터를 소프트웨어 입력에 반복적으로 공급하여 중단, 예외 및 크래시를 트리거하는 것으로 구성됩니다. 이러한 항목은 공격자가 애플리케이션 및 서비스를 중단하거나 제어하는 데 사용할 수 있는 오류 조건입니다. Microsoft SDL에서는 소프트웨어 제품의 모든 공격 표면, 특히 데이터 파서를 신뢰할 수 없는 데이터에 노출하는 표면을 퍼지 테스트하도록 권장합니다.
  • 라이브 사이트 침투 테스트 – Microsoft는 이 섹션의 뒷부분에서 설명하는 Red Teaming 프로그램의 일환으로 클라우드 보안 제어 및 프로세스를 향상시키기 위해 지속적인 라이브 사이트 침투 테스트를 수행합니다. 침투 테스트는 해커의 행동을 시뮬레이트하는 숙련된 보안 전문가가 수행하는 소프트웨어 시스템에 대한 보안 분석입니다. 침투 테스트의 목적은 코딩 오류, 시스템 구성 오류 또는 기타 운영 배포 약점으로 인해 발생할 수 있는 잠재적 취약성을 파악하는 것입니다. 테스트는 Azure 인프라 및 플랫폼과 Microsoft 고유의 테넌트, 애플리케이션 및 데이터에 대해 수행됩니다. Azure에서 호스트되는 테넌트, 애플리케이션 및 데이터는 대상으로 지정되지 않습니다. 그러나 Azure에 배포된 애플리케이션에 대해 사용자 고유의 침투 테스트를 수행할 수 있습니다.
  • 위협 모델링 – Microsoft SDL의 핵심 요소입니다. 애플리케이션과 서비스에 영향을 줄 수 있는 위협, 공격, 취약성 및 대책을 식별하는 데 사용되는 엔지니어링 기술입니다. 위협 모델링은 Azure 일상적인 개발 수명 주기의 일부입니다.
  • 공격 표면 영역 변경에 대한 자동화된 빌드 경고 – 공격 표면 분석기는 대상 시스템의 공격 표면을 분석하고, 소프트웨어 설치 또는 시스템 구성 오류 중에 발생할 수 있는 잠재적인 보안 취약성을 보고하는 Microsoft에서 개발한 오픈 소스 보안 도구입니다. 공격 표면 분석기의 핵심 기능은 소프트웨어 구성 요소가 설치되기 전과 후에 운영 체제의 보안 구성을 "비교(diff)"하는 기능입니다. 대부분의 설치 프로세스에는 상승된 권한이 필요하고, 일단 권한이 부여되면 의도하지 않은 시스템 구성 변경이 발생할 수 있으므로 이 기능이 중요합니다.
• 필수 보안 교육 – Microsoft Azure 보안 교육 및 인식 프로그램에서는 Azure 개발 및 운영을 담당하는 모든 직원이 개별 작업 요구 사항에 따른 필수 교육 및 추가 교육을 받아야 합니다. 이러한 절차는 인식 프로그램을 구현하고 유지하는 데 사용되는 표준 방법, 도구 및 기술을 제공합니다. Microsoft는 모든 Azure 엔지니어링 담당자에게 보안 인식에 대한 월별 이메일 통신을 제공하고, 직원이 직접 등록하거나 또는 온라인 보안 인식 교육에 등록할 수 있도록 하는 STRIKE라는 보안 인식 프로그램을 구현했습니다. STRIKE는 보안 인식, 교육, 문서화 및 커뮤니티 참여를 위한 중앙 집중식 온라인 리소스인 STRIKE Central과 함께 연중 내내 일련의 보안 교육 이벤트를 제공합니다.
• 버그 장려금 프로그램 – Microsoft는 학계 및 업계 연구원과의 긴밀한 파트너십을 통해 사용자와 사용자의 데이터에 대해 더 높은 수준의 보안 보증을 추진한다고 굳게 믿고 있습니다. 보안 연구원은 소프트웨어 개발 프로세스에서 누락된 취약성을 검색하여 Azure 에코시스템에서 필수적인 역할을 수행합니다. Microsoft 버그 장려금 프로그램은 Azure 인프라와 데이터를 더 효율적으로 보호하기 위해 관련 기술(예: 암호화, 스푸핑, 하이퍼바이저 격리, 권한 상승 등)에 대한 연구를 보완하고 장려하도록 설계되었습니다. 예를 들어 Azure 하이퍼바이저에서 식별된 각 중요한 취약성에 대해 Microsoft는 보안 연구원에게 참여 및 취약성 공개를 장려하기 위한 상당한 금액인 최대 250,000달러를 보상합니다. Azure 서비스 취약성 보고서에 대한 장려금 범위는 최대 60,000달러입니다.
• 레드 팀 활동 – Microsoft는 Microsoft에서 관리하는 인프라, 서비스 및 애플리케이션에 대한 라이브 사이트 침투 테스트의 한 형태인 Red Teaming을 사용합니다. Microsoft는 실제 위반을 시뮬레이션하고, 보안을 지속적으로 모니터링하고, 보안 인시던트 대응을 수행하여 Azure 보안을 테스트하고 개선합니다. Red Teaming은 위반 가정 보안 전략을 기반으로 하며, 레드 팀(공격자)과 블루 팀(방어자)의 두 가지 핵심 그룹을 통해 실행됩니다. 이 방법은 인프라 및 플랫폼 엔지니어링 또는 운영 팀의 사전 지식 없이 라이브 프로덕션 인프라에 대한 실제 악의적 사용자와 동일한 전술, 기술 및 절차를 사용하여 Azure 시스템 및 운영을 테스트하도록 설계되었습니다. 이 방법은 보안 검색 및 대응 기능을 테스트하고, 프로덕션 취약성, 구성 오류, 잘못된 가정 또는 기타 보안 문제를 제어된 방식으로 식별하는 데 도움이 됩니다. 모든 레드 팀 위반은 레드 팀과 블루 팀 간의 완전한 공개로 이어져 격차를 식별하고, 결과를 처리하며, 위반 대응을 크게 향상시킵니다.

기존 온-프레미스 데이터 센터 배포에 익숙한 경우 일반적으로 위험 평가를 수행하여 위협 노출을 측정하고 클라우드로 마이그레이션할 때의 완화 조치를 작성합니다. 이러한 대부분의 경우 기존 온-프레미스 배포에 대한 보안 고려 사항은 잘 이해되는 경향이 있지만, 해당 클라우드 옵션에는 새로운 경향이 있습니다. 다음 섹션은 이 비교를 돕기 위한 것입니다.

논리적 격리 고려 사항

다중 테넌트 클라우드 플랫폼에서는 여러 고객의 애플리케이션과 데이터가 동일한 물리적 하드웨어에 저장됩니다. Azure는 논리적 격리를 사용하여 애플리케이션과 데이터를 다른 고객과 분리합니다. 이 방법은 다중 테넌트 클라우드 서비스의 규모와 경제적 이점을 제공하는 동시에 다른 고객이 데이터 또는 애플리케이션에 액세스하지 못하도록 설계된 제어를 엄격하게 적용하는 데 도움을 줍니다. 물리적으로 격리된 기존 온-프레미스 인프라에서 클라우드로 마이그레이션하는 경우 이 섹션에서는 관심 있는 문제를 해결합니다.

물리적 및 논리적 보안 고려 사항

표 6에는 물리적으로 격리된 온-프레미스 배포(운영 체제 미설치)와 논리적으로 격리된 클라우드 기반 배포(Azure)에 대한 주요 보안 고려 사항이 요약되어 있습니다. 공유 클라우드 환경과 관련된 것으로 식별된 위험을 조사하기 전에 이러한 고려 사항을 검토하는 것이 유용합니다.

표 6. 물리적 및 논리적 격리에 대한 주요 보안 고려 사항

보안 고려 사항	온-프레미스	Azure
방화벽, 네트워킹	- 물리적 네트워크 적용(스위치 등) - 손상된 애플리케이션에서 물리적 호스트 기반 방화벽을 조작할 수 있음 - 2계층 적용	- 물리적 네트워크 적용(스위치 등) - VM 내부에서 Hyper-V 호스트 가상 네트워크 스위치 적용을 변경할 수 없음 - 손상된 애플리케이션에서 VM 호스트 기반 방화벽을 조작할 수 있음 - 3계층 적용
공격 표면 영역	- 복잡한 워크로드에 노출되는 대규모 하드웨어 공격 표면, 펌웨어 기반 APT(Advanced Persistent Threat) 사용	- VM에 직접 노출되지 않은 하드웨어, APT가 VM의 펌웨어에 지속될 가능성이 없음 - VM에 노출된 기록 버그 수가 적은 소규모 소프트웨어 기반 Hyper-V 공격 표면 영역
부채널 공격	- 부채널 공격은 축소된 하드웨어와 공유 하드웨어를 비교해도 요인이 될 수 있음	- 부채널 공격은 애플리케이션 전체의 VM 배치를 제어한다고 가정, 대규모 클라우드 서비스에서 실용적이지 않을 수 있음
패치	- 호스트 시스템 전체에 적용되는 다양하고 효과적인 패치 정책 - 하드웨어 및 펌웨어에 대한 매우 다양하고 취약한 업데이트	- 호스트와 VM 전체에 적용되는 균일한 패치 정책
보안 분석	- 호스트/보안 소프트웨어가 손상되지 않았다고 가정하는 호스트 기반 보안 솔루션에 종속된 보안 분석	- 외부 VM(하이퍼바이저 기반) 포렌식/스냅샷 기능을 통해 잠재적으로 손상된 워크로드를 평가할 수 있음
보안 정책	- 손상된 호스트에서 변조할 수 있는 보안 정책 확인(패치 검사, 취약성 검사 등) - 고객 엔터티 전체에 적용되는 일관되지 않은 보안 정책	- 보안 정책에 대한 외부 VM 확인 - 균일한 보안 정책을 고객 엔터티 전체에 적용할 수 있음
로깅 및 모니터링	- 다양한 로깅 및 보안 분석 솔루션	- 일반적인 Azure 플랫폼 로깅 및 보안 분석 솔루션 - 대부분의 기존 온-프레미스/다양한 로깅 및 보안 분석 솔루션도 작동
악의적인 참가자	- 일반적으로 고용 기간 동안 높은 액세스 권한이 있는 시스템 관리자로 인해 발생하는 지속적인 위협	- 관리자에게 기본 액세스 권한이 없으므로 위협이 크게 감소

아래에는 중요한 데이터와 워크로드를 수용할 때 해결해야 할 수 있는 공유 클라우드 환경 고유의 주요 위험이 나와 있습니다.

가상화 기술의 취약성 악용

기존 온-프레미스 호스팅 시스템과 비교하여 Azure는 잠긴 Windows Server 코어를 하이퍼바이저 위에 계층화된 호스트 OS에 사용하여 공격 표면 영역을 크게 줄였습니다. 또한 기본적으로 게스트 PaaS VM에는 들어오는 원격 연결을 수락할 사용자 계정이 없으며 기본 Windows 관리자 계정이 사용하지 않도록 설정됩니다. PaaS VM의 소프트웨어는 기본적으로 낮은 권한 계정으로 실행되도록 제한되며, 이렇게 하면 자체 최종 사용자의 공격으로부터 서비스를 보호하는 데 도움이 됩니다. 이러한 권한을 수정할 수 있으며, 원격 관리 액세스를 허용하는 VM을 구성하도록 선택할 수도 있습니다.

PaaS VM은 기존의 물리적 서버 솔루션보다 더 향상된 지속적인 맬웨어 감염에 대한 보호를 제공합니다. 이러한 맬웨어는 공격자가 손상시킨 경우 취약성이 수정된 후에도 치료하기 어려울 수 있습니다. 공격자는 재진입을 허용하는 시스템을 수정하지 않았을 수 있으며, 이러한 변경 내용을 모두 찾는 것은 어렵습니다. 극단적인 경우에는 모든 소프트웨어를 다시 설치하여 시스템을 처음부터 이미지로 다시 설치해야 하며, 이로 인해 애플리케이션 데이터가 손실되는 경우도 있습니다. PaaS VM을 사용하면 이미지로 다시 설치하는 작업은 일상적인 부분이며 탐지되지 않은 침입을 정리하는 데 도움이 될 수 있습니다. 이 방법을 사용하면 손상이 지속되기가 더 어려워집니다.

부채널 공격

Microsoft는 하이퍼스레딩을 사용하는 최신 프로세서에서 하드웨어 취약성을 악용하는 투기적 실행 부채널 공격을 완화하는 데 앞장서 왔습니다. 여러 가지 면에서 이러한 문제는 2018년에 공개된 Spectre(변형 2) 부채널 공격과 비슷합니다. 2022년 Intel 및 AMD 모두에서 여러 가지 새로운 투기적 실행 부채널 문제를 공개했습니다. 이러한 취약성을 해결하기 위해 Microsoft는 포괄적인 고성능 부채널 취약성 완화 아키텍처인 Hyper-V HyperClear를 개발하고 최적화했습니다. HyperClear는 다음 세 가지 주요 구성 요소를 사용하여 강력한 VM 간 격리를 보장합니다.

• 코어 스케줄러 - CPU 코어의 프라이빗 버퍼 및 기타 리소스를 공유하지 않도록 방지합니다.
• 가상 프로세서 주소 공간 격리 - 다른 가상 머신의 메모리 또는 다른 가상 CPU 코어의 비공개 상태에 대한 투기적 액세스를 방지합니다.
• 중요한 데이터 스크러빙은 프라이빗 데이터를 가상 프로세서의 개인 주소 공간 이외의 하이퍼바이저 메모리의 다른 위치에 남겨 두지 않도록 하여 나중에 이 데이터에 투기적으로 액세스할 수 없도록 합니다.

이러한 보호는 Azure에 배포되었으며 Windows Server 2016 이상 지원 릴리스에서 사용할 수 있습니다.

참고 항목

Hyper-V HyperClear 아키텍처는 성능에 미치는 영향을 무시할 수 있는 다양한 투기적 실행 부채널 공격에 대해 강력한 격리 경계를 제공하는 데 도움이 되는 쉽게 확장 가능한 설계임이 입증되었습니다.

서로 다른 고객에게 속한 VM이 동일한 물리적 서버에서 실행되는 경우 다른 고객의 VM에서 수행하는 작업에 대해 중요한 내용을 알아볼 수 없도록 하는 것이 하이퍼바이저의 작업입니다. Azure는 의도적으로 무단 직접 통신을 차단하는 데 도움이 됩니다. 그러나 한 고객이 다른 고객이 수행하는 작업의 특징을 파악할 수 있는 미묘한 효과가 있습니다. 이러한 효과 중 가장 중요한 것은 서로 다른 VM이 동일한 리소스를 위해 경쟁할 때 발생하는 타이밍 효과입니다. CPU의 작업 수와 경과 시간을 신중하게 비교하면 VM에서 동일한 서버의 다른 VM이 수행하는 작업에 대해 알아볼 수 있습니다. 이러한 익스플로잇은 연구원이 피어 VM에서 진행되고 있는 상황에 대한 더 구체적인 정보를 얻으려고 노력하는 학술 언론에서 많은 관심을 받았습니다.

특히 흥미로운 관심은 특정 메모리 액세스의 타이밍을 측정하고 희생자 VM에서 읽고 업데이트하는 캐시 줄을 유추하여 피어 VM의 암호화 키를 알아보려는 노력입니다. 하이퍼스레딩을 사용하는 VM 관련의 제어된 조건에서 상업적으로 사용 가능한 암호화 알고리즘 구현에 대한 성공적인 공격이 입증되었습니다. 앞에서 언급한 Azure에서 사용 중인 Hyper-V HyperClear 완화 아키텍처 외에도 Azure에는 이러한 공격의 위험을 줄이는 몇 가지 추가 완화 방법이 있습니다.

• 표준 Azure 암호화 라이브러리는 사용되는 암호화 키에 따라 캐시 액세스 패턴이 달라지지 않도록 하여 이러한 공격에 저항하도록 설계되었습니다.
• Azure는 매우 정교하고 예측이 거의 불가능한 고급 VM 호스트 배치 알고리즘을 사용하므로 악의적 사용자가 제어하는 VM이 대상 VM과 동일한 호스트에 배치될 가능성을 줄이는 데 도움이 됩니다.
• 모든 Azure 서버에는 8개 이상의 물리적 코어가 있으며, 일부 서버에는 더 많이 있습니다. 다양한 VM에서 배치한 로드를 공유하는 코어 수를 늘리면 노이즈가 이미 약한 신호에 추가됩니다.
• 물리적 격리 섹션에서 설명한 대로 Azure Dedicated Host 또는 격리된 VM을 사용하여 VM을 단일 고객 전용 하드웨어에 프로비전할 수 있습니다. 그러나 물리적 테넌트 격리는 배포 비용을 증가시키고 Azure에서 제공하는 강력한 논리적 격리 보증을 고려할 때 대부분의 시나리오에서 필요하지 않을 수 있습니다.

전반적으로 PaaS(또는 VM을 자동으로 만드는 모든 워크로드)는 임의 VM 할당으로 이어지는 VM 배치의 변동에 기여합니다. VM을 임의로 배치하면 공격자가 동일한 호스트에 액세스하기가 훨씬 더 어려워집니다. 또한 공격 표면이 크게 줄어들어 호스트 액세스가 강화되므로 이러한 유형의 익스플로잇을 지속하기가 어렵습니다.

요약

다중 테넌트 클라우드 플랫폼에서는 여러 고객의 애플리케이션과 데이터가 동일한 물리적 하드웨어에 저장됩니다. Azure는 논리적 격리를 사용하여 애플리케이션과 데이터를 다른 고객과 분리합니다. 이 방법은 다중 테넌트 클라우드 서비스의 규모와 경제적 이점을 제공하는 동시에 다른 고객이 사용자의 데이터 또는 애플리케이션에 액세스하지 못하도록 엄격하게 방지합니다.

Azure는 다음과 같은 일반적인 원칙 세트를 사용하여 확실하게 암호화되고 논리적으로 격리된 다중 테넌트 클라우드 서비스를 보장할 수 있도록 신뢰할 수 있는 기반을 제공하여 인식된 리소스 공유 위험을 해결합니다.

• Microsoft Entra ID 및 Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하는 인증 및 ID 분리를 통한 사용자 액세스 제어
• 논리적 및 물리적 컴퓨팅 격리를 모두 포함한 컴퓨팅 처리 격리
• 네트워크 트래픽 분리 및 전송 중 데이터 암호화를 포함한 네트워킹 격리
• 여러 암호 및 암호화 키와 사용자가 Azure Key Vault에서 제어하는 CMK(고객 관리형 키) 프로비전이 포함된 고급 알고리즘을 사용하는 미사용 데이터 암호화를 통한 스토리지 격리
• SDL(보안 개발 수명 주기) 및 공격 표면을 보호하고 위험을 완화하는 기타 강력한 보안 보증 프로세스를 포함하여 논리적으로 격리된 서비스를 올바르게 개발하기 위해 서비스 설계에 포함된 보안 보증 프로세스

클라우드 컴퓨팅의 공동 책임 모델에 따라 이 문서에서는 사용자의 책임에 속하는 활동에 대한 지침을 제공합니다. 또한 보안 격리 목표를 달성하는 데 도움이 되고 Azure에서 사용할 수 있는 설계 원칙과 기술을 살펴봅니다.

다음 단계

자세히 알아보기:

• Azure 보안 기본 사항 설명서
• Azure 인프라 보안
• Azure 플랫폼 무결성 및 보안
• Azure Government 개요
• Azure Government 보안
• Azure Government 규정 준수
• Azure 및 기타 Microsoft 서비스 규정 준수 제품