Azure IaaS 방어 심층(DiD) 아키텍처, SFI 원칙으로 완성하는 클라우드 보안 실전 가이드

들어가며: 클라우드 인프라 보안, 더 이상 경계 방어만으로는 안 됩니다

과거 온프레미스 환경에서는 네트워크 경계(Firewall, DMZ)만 튼튼하면 비교적 안전했습니다. 하지만 클라우드, 특히 IaaS 환경에서는 공격 표면이 훨씬 넓고 다양합니다. 아이덴티티, 소프트웨어 공급망, 컨트롤 플레인, 네트워크, 데이터가 동시에 표적이 될 수 있습니다.

Azure IaaS는 이러한 현대적 위협에 대응하기 위해 방어 심층(Defense in Depth, DiD) 아키텍처를 채택했습니다. 단일 보안 제어에 의존하지 않고, 여러 독립적인 보호 계층을 쌓아 올려 하나의 계층이 뚫려도 전체 시스템이 무너지지 않도록 설계되었습니다.

이 글에서는 Azure IaaS의 방어 심층 구조를 Secure by Design, Secure by Default, Secure in Operation 세 가지 SFI 원칙으로 풀어내고, 실무에 바로 적용할 수 있는 구체적인 설정과 코드 예제를 공유합니다. 이 내용은 Azure 공식 블로그 시리즈에서 다룬 Best Practice를 바탕으로, 국내 개발자/인프라 엔지니어의 맥락에 맞게 재구성했습니다.

💡 이 글은 Azure IaaS 시리즈의 일부입니다. 함께 보면 좋은 글: "90일 걸리던 인프라 구축, 몇 시간으로 줄인 산탄데르의 플랫폼 엔지니어링 전략"

Secure by Design: 설계 단계에서 보안을 내장하라

Azure IaaS의 보안은 가장 낮은 계층(하드웨어) 에서부터 시작됩니다. 소프트웨어만으로는 막을 수 없는 펌웨어 공격, 부트킷, 커널 루트킷을 원천 차단하는 것이 핵심입니다.

하드웨어 및 호스트 수준 신뢰

Azure 서버는 TPM(Trusted Platform Module), Secure Boot, Measured Boot를 통해 호스트 펌웨어와 부트로더, OS가 변조되지 않았음을 검증합니다. 또한 Azure Boost라는 전용 하드웨어로 스토리지, 네트워킹, 관리 작업을 호스트 OS에서 분리하여 공격 표면을 줄입니다.

VM 수준 신뢰: Trusted Launch + 기밀 컴퓨팅

Azure VM의 경우 Trusted Launch를 기본 활성화하는 것이 권장됩니다. Trusted Launch는 Secure Boot, vTPM, 무결성 모니터링을 결합하여 VM을 저수준 공격으로부터 보호합니다.

# Azure CLI로 Trusted Launch가 활성화된 VM 생성 예시
az vm create \
  --resource-group myResourceGroup \
  --name mySecureVM \
  --image Ubuntu2204 \
  --admin-username azureuser \
  --security-type TrustedLaunch \
  --enable-secure-boot true \
  --enable-vtpm true

⚠️ Trusted Launch는 Gen2 VM, 지원 OS 이미지, 특정 VM 크기에서만 사용 가능합니다. Portal, ARM, Bicep, Terraform, SDK 등 모든 배포 방식에서 지원됩니다.

더 높은 보안이 필요한 워크로드에는 Azure 기밀 컴퓨팅(Confidential Computing) 을 고려하세요. AMD SEV-SNP 또는 Intel TDX 기반의 TEE(Trusted Execution Environment)를 사용하여 사용 중인 데이터(In-use data) 도 암호화합니다. 호스트나 하이퍼바이저조차 데이터에 접근할 수 없습니다.

# Terraform으로 기밀 VM 생성 예시 (AMD SEV-SNP)
resource "azurerm_linux_virtual_machine" "confidential_vm" {
  name                = "confidential-vm"
  resource_group_name = azurerm_resource_group.example.name
  location            = azurerm_resource_group.example.location
  size                = "Standard_DC2as_v5"
  admin_username      = "adminuser"
  network_interface_ids = [azurerm_network_interface.example.id]

  admin_ssh_key {
    username   = "adminuser"
    public_key = file("~/.ssh/id_rsa.pub")
  }

  os_disk {
    caching              = "ReadWrite"
    storage_account_type = "StandardSSD_LRS"
  }

  source_image_reference {
    publisher = "Canonical"
    offer     = "ubuntu-24_04-lts"
    sku       = "server"
    version   = "latest"
  }

  # 기밀 컴퓨팅 활성화
  vtpm_enabled          = true
  secure_boot_enabled   = true
}

핵심 인사이트: 보안은 '나중에 추가'하는 것이 아니라, 아키텍처의 설계 속성이어야 합니다. Azure IaaS는 하드웨어 루트 오브 트러스트부터 시작하여 VM, 네트워크, 데이터까지 모든 계층에 보안을 내장하고 있습니다.

Secure by Default: 마찰 없는 기본 보안

'기본값이 가장 안전한 선택'이 되도록 설계하는 것이 Secure by Default의 핵심입니다. 사용자가 별도로 보안 설정을 조립하지 않아도, 기본적으로 보호받을 수 있어야 합니다.

네트워킹 기본값: Zero Trust 원칙

Azure IaaS의 가상 네트워크(VNet)는 기본적으로 격리되어 있습니다. VM으로의 인바운드 트래픽은 명시적으로 허용하지 않으면 모두 차단됩니다.

# NSG(Network Security Group) 규칙 예시: SSH만 허용
az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name myNSG \
  --name AllowSSH \
  --protocol tcp \
  --priority 1000 \
  --destination-port-ranges 22 \
  --access Allow \
  --source-address-prefixes 203.0.113.0/24  # 특정 IP만 허용

추가 Secure by Default 기능:

• Azure Private Link / Private Endpoint: 퍼블릭 인터넷 노출 없이 서비스에 접근
• Azure DDoS Protection: 플랫폼 엣지에서 자동 적용 (별도 설정 불필요)
• Azure Firewall: 중앙 집중식 정책 적용 및 트래픽 검사

암호화 기본값: 항상 켜져 있음

Azure IaaS 스토리지는 기본적으로 미사용 데이터(Data at Rest) 암호화를 활성화합니다. 플랫폼 관리 키를 사용하며, 필요 시 Azure Key Vault 또는 Managed HSM을 통해 고객 관리 키로 전환할 수 있습니다.

# 디스크 암호화 설정 확인 (Azure CLI)
az disk show \
  --resource-group myResourceGroup \
  --name myOSDisk \
  --query encryption.type
# 출력: EncryptionAtRestWithPlatformKey

전송 중 암호화(Encryption in Transit) 는 Azure 백본 네트워크에서 기본 적용됩니다. 별도 설정 없이 서비스 간 트래픽이 보호됩니다.

컴퓨팅 보호 기본값

다음은 Azure 테넌트가 비활성화할 수 없는 기본 보안입니다:

• 서명 및 측정된 Azure 호스트 부트
• 보안 호스트 OS 강화
• 호스트 수준 모니터링 및 패치 (Microsoft가 수행)
• 하이퍼바이저 기반 테넌트 간 격리

또한 Trusted Launch는 지원되는 Gen2 VM, VM Scale Set에서 새로 생성 시 기본 활성화됩니다. Portal, ARM, Bicep, Terraform, SDK 등 모든 배포 방법에서 적용됩니다.

💡 국내 SI/클라우드 전환 환경에서는 '기본값이 최선'이라는 인식이 아직 부족한 경우가 많습니다. 보안 정책을 수립할 때 '기본 활성화' 항목을 먼저 점검하고, '비활성화해야만 하는 예외'를 최소화하는 방향으로 접근하는 것이 좋습니다.

Secure in Operation: 지속적인 런타임 보호

보안은 배포로 끝나지 않습니다. 운영 중 지속적인 모니터링, 탐지, 대응이 필요합니다.

모니터링 및 위험 탐지

Azure는 컴퓨팅, 네트워크, 스토리지 계층의 텔레메트리를 Azure Monitor와 Microsoft Defender for Cloud로 중앙 수집합니다. 이를 통해:

• 노출된 관리 포트 식별
• 누락된 디스크 암호화 탐지
• 안전하지 않은 네트워크 설정 감지
• 환경 전반의 위협 신호 상관 분석

# Defender for Cloud의 보안 점수 확인 (Azure CLI)
az security secure-scores list --query "[].{name:name, score:score.current}"

아이덴티티 중심 제어 (Zero Trust)

Azure IaaS는 Microsoft Entra ID와 통합하여 아이덴티티 기반 접근 제어, 최소 권한, 조건부 액세스 정책을 적용합니다. 특히 JIT(Just-In-Time) VM 액세스는 관리 포트를 항상 열어두지 않고, 승인된 아이덴티티가 필요할 때만 제한된 시간 동안 열어줍니다.

# JIT VM 액세스 정책 활성화 (Azure CLI)
az security jit-policy create \
  --resource-group myResourceGroup \
  --location eastus \
  --vm-name mySecureVM \
  --ports 22 3389 \
  --max-request-access-duration 3h

국내 적용 맥락: 운영 보안의 현실

국내 많은 기업이 클라우드 전환 후에도 기존 온프레미스 운영 방식을 그대로 가져오는 경우가 많습니다. 예를 들어:

• 관리 포트(SSH/RDP)를 모든 IP에 오픈
• Bastion Host 없이 퍼블릭 IP로 직접 접근
• 정기적인 보안 패치를 수동으로 진행

Azure IaaS의 Secure in Operation 원칙을 적용하려면:

1. JIT VM Access를 모든 관리자 VM에 적용
2. Azure Bastion을 통해 퍼블릭 IP 없이 VM 접근
3. Defender for Cloud의 추천 사항을 주간 단위로 리뷰
4. 자동 패치 관리를 위한 Azure Update Manager 활용

결론: 계층적이고 체계적인 보안이 답이다

Azure IaaS의 방어 심층 아키텍처는 단순한 기능 목록이 아닌 시스템 수준의 보안 설계입니다. Secure by Design으로 설계 단계에서 보안을 내장하고, Secure by Default로 마찰 없는 기본 보호를 제공하며, Secure in Operation으로 운영 중 지속적인 적응과 대응을 보장합니다.

이 세 가지 원칙이 함께 작동할 때:

• 계층화: 단일 제어에 의존하지 않음
• 내재화: 보안이 부가 기능이 아닌 플랫폼 아키텍처의 일부
• 일관성: 기본값과 정책이 설정 드리프트를 최소화
• 적응성: 지속적인 모니터링과 운영 제어가 위협 환경에 대응

다음 단계 학습 방향:

• Azure IaaS Resource Center에서 Compute, Storage, Networking별 Best Practice 학습
• Azure Policy를 활용한 보안 준수 자동화
• Azure Landing Zone 아키텍처로 엔터프라이즈급 보안 설계

함께 보면 좋은 글:

• "90일 걸리던 인프라 구축, 몇 시간으로 줄인 산탄데르의 플랫폼 엔지니어링 전략"
• "UCP(Universal Commerce Protocol) 완벽 가이드 에이전트 커머스의 표준이 열린다"