eveses / field notes검색
Azure AZ-500/STUDY NOTES

Azure 보안 기본 구조: Entra ID부터 네트워크·데이터 보호까지

Azure의 리소스 계층, Entra ID와 RBAC, 네트워크·컴퓨팅·스토리지·데이터베이스 보안을 AZ-500 관점에서 연결해 정리합니다.

AzureAZ-500EntraIDRBACNetworkingSecurity
목차 15 SECTIONS +

먼저 잡아야 할 큰 그림

Azure 보안은 다음 네 가지 경계를 함께 이해해야 한다.

  1. ID 경계: Microsoft Entra tenant 안의 사용자, 그룹, 애플리케이션, 관리형 ID
  2. 리소스 경계: Management group → Subscription → Resource group → Resource
  3. 네트워크 경계: VNet, subnet, NSG, Private Endpoint, Firewall
  4. 데이터 경계: 서비스별 인증·권한, 암호화, 키와 비밀 관리

Entra ID는 사용자를 인증하고, Azure RBAC은 인증된 주체가 Azure 리소스에서 할 수 있는 작업을 결정한다. 둘을 같은 기능으로 보면 권한 문제를 풀기 어렵다.

Azure 리소스 계층

Azure 계정 및 리소스 계층 예시

계층역할보안 관점
TenantMicrosoft Entra ID의 전용 인스턴스사용자·그룹·앱 ID의 기본 경계
Management group여러 구독을 계층적으로 관리Azure Policy와 RBAC을 하위 구독에 상속
Subscription리소스, 할당량, 청구의 경계환경·조직·규정별 격리에 사용
Resource group수명 주기가 비슷한 리소스의 논리적 컨테이너배포·권한·삭제 단위 설계
ResourceVM, VNet, Storage account 등 실제 서비스가장 세밀한 RBAC·Policy 적용 대상

Management group은 root management group 아래에 최대 6단계의 계층을 만들 수 있다. 정책과 권한은 상위 범위에서 하위 범위로 상속되므로, 넓은 범위의 Owner·Contributor 할당은 신중해야 한다.

리소스 그룹은 폴더처럼 보이지만 네트워크 또는 보안 격리 경계는 아니다. 서로 다른 리소스 그룹의 리소스도 같은 VNet에서 통신할 수 있다.

Microsoft Entra ID

Microsoft Entra ID는 클라우드 기반 ID 및 액세스 관리 서비스다. 사용자 로그인, MFA, SSO, 애플리케이션 ID, 디바이스 ID, 조건부 액세스를 제공한다.

Microsoft Entra ID 개요

인증 수단

  • 암호와 Microsoft Authenticator 같은 MFA
  • FIDO2 보안 키, 패스키, Windows Hello for Business 같은 피싱 방지 인증
  • Temporary Access Pass를 이용한 암호 없는 인증 등록
  • 외부 ID(B2B)를 이용한 파트너·게스트 협업

MFA가 모든 위험을 해결하지는 않는다. 관리자 역할에는 피싱 방지 인증, 조건부 액세스, 별도 관리자 계정, Privileged Identity Management(PIM)를 함께 사용한다.

애플리케이션 ID

  • App registration: 애플리케이션의 전역 정의와 인증 설정
  • Service principal: 특정 tenant에서 애플리케이션을 나타내는 보안 주체
  • Managed identity: Azure가 자격 증명 수명 주기를 관리하는 서비스 주체

Azure 리소스에서 다른 서비스에 접근할 때는 클라이언트 비밀을 코드에 저장하기보다 관리형 ID를 우선 사용한다. System-assigned identity는 리소스와 수명 주기를 공유하고, User-assigned identity는 여러 리소스가 재사용할 수 있다.

Azure RBAC

RBAC 역할 할당은 보안 주체 + 역할 정의 + 범위로 구성된다.

보안 주체

  • 사용자와 그룹
  • 서비스 주체
  • 관리형 ID

역할

  • Owner: 모든 리소스를 관리하고 권한도 위임
  • Contributor: 리소스를 관리하지만 역할 할당은 할 수 없음
  • Reader: 리소스 조회만 가능
  • 세분화 역할: Key Vault Secrets User, Storage Blob Data Reader처럼 데이터 작업을 제한
  • Custom role: 기본 제공 역할이 요구사항보다 넓을 때 필요한 작업만 정의

관리 평면 권한과 데이터 평면 권한을 구분해야 한다. 예를 들어 Storage Account Contributor가 계정 설정을 관리한다고 해서 Blob 데이터까지 자동으로 읽을 수 있는 것은 아니다.

범위와 최소 권한

역할은 Management group, Subscription, Resource group, Resource 범위에 할당할 수 있으며 하위로 상속된다. 가장 좁은 범위에 필요한 역할만 할당하고, 관리자 권한은 PIM으로 시간 제한 활성화와 승인을 적용한다.

Virtual Network

VNet은 Azure 리전 범위의 사설 네트워크다. VNet 주소 공간을 subnet으로 나누며, Azure subnet은 특정 가용 영역에 묶이지 않는다.

  • Private IP: VNet 내부와 연결된 네트워크의 통신
  • Public IP: 인터넷에서 리소스로 들어오는 명시적 주소
  • VNet peering: Azure 백본을 통해 VNet을 직접 연결
  • VPN Gateway / ExpressRoute: 온프레미스와 암호화 터널 또는 전용 회선 연결
  • Hub-spoke: 중앙 허브에 방화벽·DNS·게이트웨이를 두고 워크로드 VNet을 spoke로 분리

아웃바운드 연결 변화

Basic SKU Public IP는 2025년 9월 30일에 사용 중지되었으며 Standard Public IP를 사용해야 한다. 또한 2026년 3월 31일 이후 API로 생성한 새 VNet의 subnet은 기본적으로 private subnet이 되어 명시적 아웃바운드 방식이 필요하다. 안정적인 인터넷 송신에는 NAT Gateway, Firewall 또는 명시적인 Public IP 구성을 사용한다.

암묵적인 기본 아웃바운드 접근에 의존하지 않고 송신 IP, 경로, 로깅을 설계하는 것이 핵심이다.

네트워크 보안 제어

NSG와 ASG

NSG(Network Security Group)는 subnet 또는 NIC에 연결하는 상태 저장형 L3/L4 필터다. 우선순위가 낮은 숫자의 규칙부터 평가하며 허용과 거부 규칙을 모두 사용할 수 있다.

  • Service tag: Azure 서비스의 IP 범위를 이름으로 표현
  • Application Security Group: VM NIC를 역할별 그룹으로 묶어 IP 대신 애플리케이션 계층으로 규칙 작성
  • subnet과 NIC에 NSG가 모두 있으면 양쪽 규칙을 모두 통과해야 한다.

NSG는 AWS Security Group과 NACL을 합친 것이라기보다 Azure 고유의 상태 저장 필터로 이해하는 편이 정확하다.

Private Endpoint와 Service Endpoint

  • Private Endpoint: PaaS 서비스에 VNet의 사설 IP를 부여한다. Private DNS Zone과 public network access 설정을 함께 확인한다.
  • Service Endpoint: PaaS 서비스가 선택한 subnet의 트래픽을 신뢰하도록 확장하지만 서비스에는 여전히 공용 엔드포인트가 존재한다.

데이터 유출 방지와 사설 주소 기반 접근이 요구되면 Private Endpoint가 더 강한 격리를 제공한다.

Azure의 트래픽 분산 서비스

서비스범위·계층핵심 용도
Azure Load BalancerRegional, L4TCP/UDP VM 트래픽 분산
Application GatewayRegional, L7웹 라우팅, TLS 종료, WAF
Azure Front DoorGlobal edge, L7글로벌 HTTP 가속, 장애 조치, CDN, WAF
Traffic ManagerGlobal DNSDNS 기반 엔드포인트 선택

Azure Load Balancer

프런트엔드 IP, 백엔드 풀, 상태 프로브, 부하 분산 규칙으로 구성된다. Public 또는 Internal Load Balancer로 만들 수 있으며 5-tuple 해시를 사용해 흐름을 분배한다. 인바운드 NAT 규칙은 특정 프런트엔드 포트를 개별 VM 포트에 연결할 때 사용한다.

Application Gateway

HTTP/HTTPS 요청을 호스트·경로에 따라 라우팅하는 리전 L7 서비스다. 리스너에서 TLS를 종료하거나 종단 간 TLS를 구성할 수 있고, WAF_v2 SKU는 OWASP 규칙과 사용자 지정 규칙을 제공한다.

Application Gateway 구성

Azure Front Door

사용자와 가까운 엣지에서 HTTP/HTTPS 트래픽을 받아 Microsoft 글로벌 네트워크로 원본에 연결한다. 여러 리전의 App Service, Application Gateway, 외부 원본 등을 상태 기반으로 선택할 수 있다. WAF, TLS, 캐싱, 규칙 엔진을 글로벌 진입점에 통합할 때 적합하다.

Virtual Machines

VM은 운영체제까지 직접 관리하는 IaaS다. OS 패치, 애플리케이션, 계정, 네트워크 보안은 고객 책임이다.

크기와 디스크

  • General purpose: 균형 잡힌 웹·업무 서버
  • Compute optimized: CPU 중심 배치·연산
  • Memory optimized: 대용량 메모리 DB·분석
  • Storage optimized: 높은 로컬 디스크 처리량
  • GPU: 렌더링, AI 학습·추론

Managed Disk는 Standard HDD, Standard SSD, Premium SSD, Premium SSD v2, Ultra Disk 등에서 성능과 비용을 선택한다. 임시 디스크는 호스트 장애·재배치 시 데이터를 잃을 수 있으므로 영구 데이터에 사용하지 않는다.

가용성·접속·비용

  • Availability Zone: 리전 안의 독립된 데이터센터 장애 도메인
  • VM Scale Sets: 동일한 VM 집합을 자동 확장하고 로드 밸런서와 통합
  • Azure Bastion: VM에 공용 IP를 부여하지 않고 브라우저 또는 네이티브 클라이언트로 SSH/RDP
  • JIT VM access: Defender for Cloud를 통해 관리 포트를 필요한 시간과 IP에만 개방
  • Reservations / Savings plan: 예측 가능한 사용량 할인
  • Spot VM: 회수 가능한 여유 용량으로 중단 허용 작업에 사용

디스크는 플랫폼에서 기본적으로 암호화되며, 고객 관리형 키 또는 게스트 OS 내부 암호화가 필요한 규정인지 별도로 판단한다.

App Service와 Functions

App Service

App Service는 웹 앱과 API를 호스팅하는 PaaS다. App Service Plan이 컴퓨팅 크기·인스턴스 수·가격 계층을 정의하고, 여러 앱이 같은 Plan의 자원을 공유할 수 있다.

  • Deployment slots로 staging 배포 후 swap
  • 인스턴스 수를 늘리는 scale-out과 등급을 높이는 scale-up
  • VNet Integration으로 앱의 아웃바운드를 VNet에 연결
  • Private Endpoint로 앱의 인바운드를 사설 IP로 제공
  • 관리형 ID로 Key Vault, Storage, SQL 등에 비밀 없는 인증
  • Access Restrictions와 내장 인증으로 진입점 통제

VNet Integration과 Private Endpoint는 방향이 다르다. 전자는 앱이 VNet 쪽으로 나가는 경로, 후자는 클라이언트가 앱으로 들어오는 사설 경로다.

Azure Functions

Functions는 HTTP, Timer, Queue, Event Grid 같은 트리거로 실행되는 이벤트 기반 컴퓨팅이다. 함수당 트리거는 하나이며 입력·출력 바인딩으로 서비스 연결 코드를 줄일 수 있다.

플랜특징선택 기준
Flex Consumption0까지 축소, 빠른 확장, VNet, 선택적 always-ready신규 서버리스 워크로드의 우선 선택
Premium항상 준비된 인스턴스, VNet, 긴 실행콜드 스타트 최소화와 고성능
DedicatedApp Service Plan 자원 사용기존 Plan 공유 또는 고정 자원
Container Apps컨테이너 기반 Functions사용자 이미지와 Container Apps 기능 필요

기존 Consumption 플랜은 네트워크 기능과 확장 방식에 제약이 있다. 신규 설계에서는 지원 리전·런타임을 확인한 뒤 Flex Consumption을 먼저 비교한다.

컨테이너

Azure Container Apps

Kubernetes API를 직접 운영하지 않고 컨테이너 앱과 마이크로서비스를 배포하는 관리형 플랫폼이다. KEDA 기반 이벤트 확장, revision·트래픽 분할, Dapr 통합, 내부 ingress를 제공한다. 단순 웹 API, 작업자, 이벤트 처리에 적합하다.

Azure Kubernetes Service

AKS는 Kubernetes 제어 평면을 Azure가 관리하는 서비스다. 네트워크 정책, 워크로드 ID, Key Vault CSI Driver, private cluster, Microsoft Defender for Containers를 조합해 보호한다. Kubernetes API와 클러스터 수준 제어가 꼭 필요한지 확인하고, 그렇지 않으면 Container Apps가 운영 부담이 낮다.

스토리지 서비스

Storage account는 Blob, Files, Queue, Table 등의 공통 네임스페이스와 보안·복제 설정을 제공한다.

서비스모델대표 용도
Blob Storage객체이미지, 로그, 백업, 데이터 레이크
Azure FilesSMB/NFS 파일 공유공유 드라이브, 애플리케이션 파일
Queue Storage메시지 큐비동기 작업 분리
Table StorageNoSQL key-value대규모 구조화 비관계형 데이터
Managed Disks블록Azure VM의 OS·데이터 디스크

보안과 복제

  • Microsoft Entra ID와 Azure RBAC을 공유 키보다 우선 사용한다.
  • 공유 키가 필요하면 SAS로 권한·대상·기간·IP를 제한하고 가능하면 user delegation SAS를 사용한다.
  • Secure transfer required, 최소 TLS 버전, Firewall과 Private Endpoint를 구성한다.
  • 저장 데이터는 기본 암호화되며, 요구 시 고객 관리형 키를 사용한다.
  • Soft delete, versioning, immutable storage로 삭제·변조 위험을 줄인다.

복제 옵션은 LRS, ZRS, GRS/GZRS와 읽기 가능한 RA 변형으로 나뉜다. ZRS는 같은 리전의 영역 장애, GRS/GZRS는 보조 리전 복제를 목표로 한다. 보조 리전 전환 방식과 복제 지연에 따른 RPO를 확인한다.

데이터베이스 서비스

Azure SQL

Azure SQL Database는 관리형 SQL Server 호환 PaaS다. Microsoft Entra 인증, SQL auditing, Defender for SQL, Transparent Data Encryption, Always Encrypted, Dynamic Data Masking을 요구사항에 맞게 조합한다. Private Endpoint를 쓰더라도 공용 네트워크 접근을 별도로 끄고 DNS를 구성해야 한다.

Azure Cosmos DB

글로벌 분산 NoSQL 데이터베이스로 여러 API와 일관성 수준을 제공한다. 파티션 키 선택이 성능과 비용을 크게 좌우한다. 계정 키보다 관리형 ID와 데이터 평면 RBAC을 우선하고, Private Endpoint, 고객 관리형 키, 백업 모드를 함께 설계한다.

Azure Database for PostgreSQL

Flexible Server는 패치, 백업, 고가용성을 관리하는 PaaS다. private access 또는 Private Link, Microsoft Entra 인증, TLS, 서버 로그를 사용하고, 고가용성 구성과 읽기 복제본의 목적을 구분한다.

핵심 보안 서비스

Azure Policy

리소스 구성이 조직 표준을 따르도록 평가하고 효과에 따라 거부, 감사, 수정, 관련 리소스 배포를 수행한다. Initiative는 여러 정책을 하나의 규정 준수 묶음으로 관리한다. RBAC이 “누가 무엇을 할 수 있는가”라면 Policy는 “어떤 상태의 리소스가 허용되는가”를 통제한다.

Key Vault

비밀, 암호화 키, 인증서를 관리한다. Microsoft Entra ID로 인증하고 Azure RBAC으로 데이터 평면 권한을 부여하는 방식을 권장한다. 관리형 ID, Private Endpoint, soft delete, purge protection, 진단 로그를 함께 사용한다.

Defender for Cloud

클라우드 보안 태세 관리(CSPM)와 서버·스토리지·데이터베이스·컨테이너 등 워크로드 보호를 제공한다. 권장 사항과 Secure Score로 잘못된 구성을 찾고, Defender 플랜으로 위협 탐지 범위를 확장한다.

DDoS Protection과 WAF

  • DDoS Protection: VNet의 공용 IP를 대상으로 L3/L4 대규모 공격을 완화
  • WAF: Front Door 또는 Application Gateway에서 SQL injection, XSS 같은 L7 웹 공격을 필터링

서로 대체 관계가 아니며 공격 계층이 다르다. 인터넷 공개 웹 서비스라면 두 통제를 함께 검토한다.

Azure Firewall

Azure Firewall은 허브 VNet에 배치할 수 있는 관리형 상태 저장 네트워크 방화벽이다. 네트워크·애플리케이션·DNAT 규칙, 위협 인텔리전스, SKU별 TLS 검사와 IDPS 등을 제공한다. UDR로 트래픽이 실제 방화벽을 통과하도록 경로를 구성하고 Azure Firewall Policy로 여러 방화벽의 규칙을 중앙 관리한다.

AZ-500 판단 체크리스트

  • 인증은 Entra ID, Azure 리소스 권한은 RBAC, 구성 표준은 Policy로 구분했는가?
  • 장기 비밀 대신 관리형 ID를 사용할 수 있는가?
  • PaaS의 공용 접근을 끄고 Private Endpoint와 Private DNS를 함께 구성했는가?
  • NSG, Firewall, WAF, DDoS Protection의 계층과 범위를 구분했는가?
  • 관리 권한은 PIM으로 필요할 때만 활성화하는가?
  • 로그를 Log Analytics와 Microsoft Sentinel 등 중앙 분석 지점으로 보낼 수 있는가?
  • 데이터 복제 옵션과 실제 장애 조치의 RPO/RTO를 확인했는가?

공식 문서

← All notesBack to top ↑

Last updated · 2026.09.05