모듈 1 복습: Azure 기본 보안 기능

Coursera의 Azure Cybersecurity Solutions and Microsoft Defender 과정에서 첫 번째 단원은 Azure: Basic security capabilities다. Virtual Machine과 Virtual Network를 만든 뒤 DDoS Protection, Azure Firewall, Web Application Firewall, Just-in-time access와 암호화를 차례로 다룬다. 입문 단원치고 범위가 넓기 때문에 Portal 화면을 순서대로 외우는 방식으로는 오래 기억하기 어렵다. “무슨 위협을, 어느 경계에서, 어떤 통제로 줄이는가?”라는 질문으로 다시 연결해야 한다.

이 글은 강의 대본이나 평가 문제의 답안이 아니라 반복해서 읽기 위한 독립적인 복습 노트다. 아래 실습 항목은 안전한 학습 목표와 검증 방법을 새로 구성한 것이며, 필자나 수강자가 특정 실습을 완료했다고 주장하지 않는다. 제품 명칭과 서비스 상태는 2026년 8월 10일 Microsoft 공식 문서를 기준으로 보정했다.

1. 이 단원에서 답해야 할 네 가지 질문

모듈 1의 긴 콘텐츠 목록은 다음 네 질문으로 압축할 수 있다.

1. 인터넷에 노출된 서비스가 비정상적으로 많은 트래픽을 받아도 어떻게 가용성을 유지할 것인가?
2. 출발지에서 목적지로 가는 네트워크 흐름 중 무엇을 허용하고 무엇을 차단할 것인가?
3. 관리자가 VM에 접속해야 할 때 RDP나 SSH 포트를 항상 열어 두지 않는 방법은 무엇인가?
4. 저장·전송되는 데이터와 암호화 키를 수명주기 전체에서 어떻게 보호할 것인가?

강의의 Windows VM 생성, Azure Firewall 구성, JIT로 포트 보호 실습은 이 질문을 눈에 보이는 리소스로 확인하기 위한 장치다. VM 생성 자체가 보안 목표는 아니다. 하나의 VM 주변에 Identity, Network, Access, Logging, Encryption이라는 통제가 어떻게 배치되는지를 관찰하는 것이 목표다.

초보자는 보통 “무엇을 켜야 안전한가?”라고 묻는다. 운영자는 질문을 더 구체적으로 바꿔야 한다.

보호 대상은 무엇인가?
신뢰할 수 없는 행위자는 누구인가?
어떤 경로로 공격할 수 있는가?
어디에서 차단하고 어디에서 탐지할 것인가?
통제가 실패하면 누가 무엇을 할 것인가?

제품을 고르기 전에 이 다섯 줄을 적으면 불필요한 기능 구매와 잘못된 기대를 크게 줄일 수 있다.

2. 방어 계층을 먼저 지도처럼 그린다

이 단원에 등장하는 어떤 제품도 혼자서 “Azure를 안전하게 만드는 스위치”가 아니다. 각 통제는 서로 다른 계층과 질문을 담당한다.

방어 목적	대표 통제	주된 질문
인터넷 가용성	Azure DDoS Protection	대규모 L3/L4 트래픽을 어떻게 흡수·완화할까?
웹 요청 검사	Web Application Firewall	이 HTTP 요청이 공격 패턴인가?
중앙 네트워크 정책	Azure Firewall	여러 네트워크의 통신을 어디에서 일관되게 허용·기록할까?
Subnet/NIC 단위 필터	Network Security Group	이 source, destination, port, protocol 조합을 허용할까?
관리 포트 노출 시간 축소	Defender for Cloud JIT	누가 어느 IP에서 얼마 동안 관리 포트를 열 수 있는가?
저장·전송 데이터의 기밀성	암호화와 관리되는 key lifecycle	어느 구간을 어떤 key로 암호화하고 누가 회전·복구할 수 있는가?

두 가지 혼동을 특히 경계한다. 첫째, DDoS Protection은 WAF의 대체재가 아니다. TCP SYN flood를 완화하는 일과 SQL injection 패턴을 검사하는 일은 계층이 다르다. 둘째, Firewall은 Azure 관리 권한을 결정하지 않는다. Firewall과 NSG는 packet 흐름을 제한하지만, 사용자 인증은 Microsoft Entra ID가, Azure resource에 대한 control-plane 권한은 Azure RBAC가 담당한다.

하나의 위협 시나리오로 연결하기

공개 쇼핑몰을 예로 들어 보자. 공격자는 먼저 대량의 L3/L4 트래픽으로 Public IP의 가용성을 떨어뜨릴 수 있다. 이 구간은 DDoS Protection이 담당한다. 정상적인 연결처럼 보이는 HTTP 요청 안에 injection payload를 넣을 수도 있다. 이 구간은 WAF가 더 적합하다. 웹 서버가 침해된 뒤 Database subnet으로 이동하려 할 때는 NSG와 중앙 Firewall의 east-west 정책이 blast radius를 줄인다. 공격자가 인터넷에서 RDP 포트를 탐색한다면 Public IP 제거, Bastion 같은 private 관리 경로 또는 JIT가 노출을 줄인다. Disk를 복사하거나 credential을 얻더라도 저장 데이터와 key access가 별도로 통제되어야 한다.

이 시나리오에서 한 제품을 추가한다고 공격 경로 전체가 사라지지 않는다. Defense in depth는 제품의 개수가 아니라, 서로 다른 실패를 독립적으로 막고 탐지하는 구조다.

3. DDoS Protection은 보안이면서 가용성 설계다

DDoS 공격은 네트워크 대역폭, protocol state 또는 애플리케이션 처리 능력을 소진시켜 정상 사용자가 서비스를 이용하지 못하게 한다. Azure 플랫폼은 기본적인 인프라 수준 보호를 제공하고, 고객이 특정 Public IP 리소스에 대해 강화된 보호와 telemetry를 구성할 수 있도록 Azure DDoS Protection을 제공한다.

2026년 기준 강화 tier는 다음 두 가지다.

Tier	선택하기 좋은 상황	꼭 구분할 점
DDoS IP Protection	보호할 지원 대상 Public IP가 적은 환경	Public IP별 과금 모델
DDoS Network Protection	보호 대상 VNet과 Public IP가 여러 개이고 조직 차원의 대응이 필요한 환경	현재 조건에 따라 DDoS Rapid Response, cost protection 같은 부가 혜택 포함

두 tier 모두 지원 리소스에 대해 상시 traffic monitoring, adaptive tuning, L3/L4 자동 완화, metric, alert 및 attack report를 제공한다. 하지만 “Azure 안에 있으니 보호된다”는 문장만으로 강화 보호 범위가 증명되지는 않는다. 선택한 tier가 실제 Public IP 유형과 배포 모델을 지원하는지, VNet과 protection plan이 올바르게 연결되었는지를 inventory로 확인해야 한다.

구매 전에 결정할 것

• 정말 Public endpoint가 필요한지 검토하고, 필요 없으면 Private Endpoint 또는 private network 경로로 제거한다.
• 한 region이나 한 instance가 실패해도 서비스가 버틸 수 있도록 redundancy와 autoscale을 설계한다.
• 눈에 띄는 VM 하나가 아니라 범위 안의 모든 지원 대상 Public IP를 목록화한다.
• HTTP/S workload에는 L7 공격을 위한 WAF가 별도로 필요한지 판단한다.
• DDoS metric과 diagnostic log를 어느 Log Analytics workspace, Storage 또는 SIEM으로 보낼지 정한다.
• Alert가 발생했을 때 누가 incident를 선언하고 Microsoft 지원에 연락하며 고객에게 공지할지 runbook으로 남긴다.

흔한 오해

“DDoS Protection을 켜면 애플리케이션이 절대 중단되지 않는다.” 그렇지 않다. Origin의 잘못된 autoscale, backend database 병목, application-layer 공격, DNS 문제와 배포 오류는 별도의 가용성 설계가 필요하다.

“WAF가 있으니 DDoS tier는 필요 없다.” WAF의 처리 용량에 요청이 도달하기 전의 volumetric 공격과 protocol 공격은 다른 계층의 문제다. 반대로 DDoS Protection만으로 악성 HTTP payload를 충분히 검사한다고 기대해서도 안 된다.

“시험하려면 직접 트래픽을 많이 보내면 된다.” 허가되지 않은 부하 생성은 서비스 약관, 비용, 주변 리소스에 영향을 줄 수 있다. Azure의 공식 절차와 승인된 simulation partner 범위 안에서만 시험한다. 학습 환경에서는 구성, metric, alert route와 대응 절차를 검증하는 것만으로도 충분하다.

좋은 증적의 예

보호 계획 이름만 캡처하는 것보다 public IP inventory + tier + 연결 VNet + 보호 상태 + alert destination + 담당자 + 최근 검증일을 한 표로 남기는 편이 낫다. 공격 시점의 mitigation metric, 시작·종료 alert, sanitized report 및 incident timeline은 사후 검증 증적이 된다.

4. NSG, Azure Firewall과 WAF의 경계를 구분한다

이름에 Firewall이 들어가도 enforcement point는 다르다.

NSG: 가까운 곳에서 최소 흐름만 허용

NSG는 subnet 또는 Network Interface에 적용되는 stateful L3/L4 필터다. 작은 workload에서 source/destination, port, protocol 중심의 segmentation을 수행하기에 적합하다. 그러나 여러 subscription과 VNet의 egress domain 정책을 한곳에서 관리하고 고급 inspection을 수행하는 중앙 장비와는 목적이 다르다.

Azure Firewall: 중앙 통신 정책과 가시성

Azure Firewall은 관리형 stateful Firewall service다. Resource를 생성했다고 traffic이 자동으로 통과하는 것은 아니다. Route table과 network topology가 의도한 흐름을 Firewall로 보내야 하며, application rule을 쓸 때는 DNS 동작도 함께 설계해야 한다. Rule의 owner와 만료일, log 보존 및 장애 대응도 필요하다.

현재 SKU 선택은 세 가지다.

• Basic: 처리량과 기능 요구가 작은 환경을 위한 기본 선택지다.
• Standard: threat intelligence filtering, DNS proxy, custom DNS, web category 등 일반적인 enterprise 기능이 필요할 때 검토한다.
• Premium: IDPS, TLS inspection, 더 세밀한 URL filtering처럼 민감한 workload에 필요한 고급 통제를 제공한다.

가장 비싼 SKU가 무조건 정답은 아니다. 예를 들어 TLS inspection은 암호화 traffic 안의 위협을 볼 수 있지만, private CA와 certificate 배포, privacy, 규제, 성능 및 애플리케이션 호환성이라는 새로운 책임을 만든다. 실제 traffic으로 충분히 검증하고 예외 정책을 관리할 조직이 없다면 기능을 켠 사실보다 운영 실패가 더 큰 위험이 될 수 있다.

WAF: HTTP 요청의 의미를 검사

Azure Web Application Firewall은 Application Gateway 또는 Front Door 같은 지원 edge에서 HTTP/S 요청을 검사한다. SQL injection, cross-site scripting 같은 일반적인 web exploit 패턴을 중앙에서 완화한다. WAF도 application의 secure coding, dependency patching, authentication 및 authorization을 대체하지 않는다. 처음에는 detection mode로 false positive를 관찰하고, exclusion은 이유·owner·만료일과 함께 관리한 뒤 prevention 전환을 검토하는 방식이 안전하다.

선택 기준을 한 문장으로 기억하기

NSG는 “이 연결이 가능한가”,
Azure Firewall은 “조직의 네트워크 정책상 이 통신을 허용하고 기록할 것인가”,
WAF는 “이 웹 요청의 내용이 안전한가”를 묻는다.

5. Firewall rule을 단계적으로 설계하고 검증한다

Firewall 실습의 핵심은 resource 생성이 아니라 의도한 흐름만 정책 지점을 통과한다는 사실을 증명하는 것이다.

1. 흐름을 평문으로 쓴다. “App subnet의 HTTPS egress가 승인된 update endpoint로 나가야 한다”처럼 source, destination, protocol, business purpose, owner를 기록한다.
2. 경로를 확인한다. User-defined route, peering, default route와 next hop을 통해 traffic이 실제 Firewall로 향하는지 확인한다.
3. 최소 범위로 rule을 만든다. Any source와 destination을 빠른 해결책으로 사용하지 않는다. Service tag, FQDN, IP group 등 유지 가능한 표현을 선택한다.
4. Rule 종류와 우선순위를 확인한다. Network, application 및 DNAT rule을 목적에 맞게 분리하고 policy hierarchy의 상속을 확인한다.
5. 관측성을 먼저 연결한다. 허용과 차단을 모두 검색할 수 있도록 diagnostic setting과 query를 준비한다.
6. Positive/negative test를 함께 한다. 승인된 목적지는 성공하고 바로 옆의 미승인 목적지는 실패해야 한다.
7. 예외의 끝을 정한다. 임시 rule에는 ticket, owner, 만료 시간과 rollback을 붙인다.

“Firewall이 배포됨”은 약한 증적이다. 의도 문서, effective route, rule export, 허용·차단 test matrix와 동일 시간대 log record가 함께 있어야 강한 증적이 된다.

운영상 놓치기 쉬운 비용

Firewall instance의 시간당 비용과 처리 데이터 비용뿐 아니라 Public IP, Log Analytics ingestion/retention, cross-region 또는 inter-zone data path, Premium inspection에 필요한 운영 인력까지 고려해야 한다. 비용을 줄이려고 log를 완전히 끄면 사고 때 검증 능력을 잃는다. 모든 log를 무기한 보관하면 비용이 통제되지 않는다. 필요한 table, retention, archive 및 query 빈도를 threat model과 감사 요구에 맞춰 정한다.

6. JIT는 공격 표면의 ‘시간’을 줄인다

인터넷에서는 RDP 3389와 SSH 22가 지속적으로 scan된다. 가장 안전한 기본값은 VM에 Public IP를 주지 않고 private 관리 경로를 사용하는 것이다. 설계상 제한된 inbound 관리가 필요하다면 Just-in-time VM access가 선택한 port의 노출 시간을 줄일 수 있다.

2026년 현재 JIT는 Microsoft Defender for Cloud의 Defender for Servers Plan 2 기능이다. 지원되는 NSG 또는 Azure Firewall 구성을 통해 지정 port에 deny 상태를 두고, 권한 있는 사용자의 요청이 승인되면 정해진 source IP 또는 range, port, duration에 한해 임시 allow rule을 만든다. 시간이 끝나면 제한 상태로 돌아간다.

JIT가 제공하는 가치는 “더 강한 password”가 아니라 상시 노출된 공격 표면을 줄이는 것이다. 다음 통제는 여전히 필요하다.

• 누가 접근을 요청할 수 있는지 제한하는 Azure RBAC
• Microsoft Entra sign-in 보호와 MFA
• 요청자의 실제 source IP를 반영한 좁은 source 범위
• 업무에 필요한 최소 duration과 port
• shared credential 대신 관리되는 host authentication
• OS patch, endpoint protection 및 login/activity log
• JIT workflow나 network control이 작동하지 않을 때의 break-glass 절차

JIT, Bastion, VPN을 경쟁 제품으로만 보지 않는다

JIT는 port가 열리는 시간과 요청 권한을 제어한다. Azure Bastion은 VM에 Public IP 없이 관리 연결을 전달하는 접속 경로다. VPN/ExpressRoute는 관리 client가 private network에 들어오는 연결 기반을 제공한다. 위협 모델과 비용에 따라 Bastion 또는 private connectivity와 JIT를 조합할 수도 있다. “JIT를 켰으니 Public IP를 유지해도 항상 안전하다”는 결론은 옳지 않다.

또한 JIT는 모든 Azure Firewall Manager와 Firewall Policy topology를 지원한다고 가정하면 안 된다. 공식 prerequisites와 제한사항을 현재 문서에서 확인한다.

7. 암호화는 알고리즘보다 수명주기 문제다

암호화 요구는 세 구간으로 나눠야 한다.

• 전송 중(in transit): TLS, IPsec, SSH 등 적절한 protocol로 network 상의 data를 보호한다.
• 저장 중(at rest): Storage service의 암호화를 사용하고 platform-managed key와 customer-managed key 중 요구에 맞는 방식을 고른다.
• 사용 중 및 host 경계(in use/host boundary): threat model에 따라 confidential computing, encryption at host 같은 workload별 통제를 검토한다.

암호화가 직접 보호하는 핵심 속성은 기밀성이다. 적절한 key 없이는 data를 읽기 어렵게 만든다. 그러나 “암호화됨”이라는 상태만으로 resource, application, file 또는 backup이 변경되지 않았다는 무결성을 증명할 수는 없다. 인증된 protocol, hash/signature, access control, immutable record, versioning 및 검증된 recovery는 서로 다른 무결성 문제를 담당한다. Key Vault도 지원되는 key, secret, certificate의 lifecycle을 관리하는 서비스이며, Vault를 하나 만들었다고 VM disk가 자동으로 암호화되거나 data의 무결성이 보장되는 것은 아니다.

현재 Azure Managed Disk 암호화 옵션을 구분한다

Managed Disk 암호화 개요는 흔히 “Disk Encryption”이라고 한데 묶는 통제를 다음과 같이 구분한다.

옵션	적용 지점과 범위	선택 경계
Azure Disk Storage server-side encryption(SSE)	Azure Storage cluster에 저장되는 Managed OS/Data Disk에 항상 적용된다. Platform-managed key가 기본이며 Disk Encryption Set으로 customer-managed key를 연결할 수 있다.	기본 at-rest 암호화다. Temporary disk와 disk cache는 포함하지 않는다.
Encryption at host	Temporary disk와 disk cache를 at rest로 암호화하고 VM host의 data가 Storage로 이동할 때도 암호화 상태를 유지하는 VM 옵션이다. Cache는 선택한 disk key model을 따르고 temporary disk는 platform-managed key를 사용한다.	Compute host 경계까지 범위에 포함해야 할 때 평가한다. 지원 VM size, region과 구성 제한을 확인해야 한다.
Azure Disk Encryption(ADE)	Windows에서는 BitLocker, Linux에서는 dm-crypt를 사용하는 guest-level 기술이다.	은퇴 예정인 legacy 설계다. 새 VM의 선택지로 사용하지 않는다.
Confidential disk encryption	지원되는 Confidential VM 시나리오를 위한 기능이다.	Confidential computing threat model이 있을 때 별도 검토하며 보편적 기본값으로 보지 않는다.

SSE가 기본 활성화돼 있다고 VM과 관련된 모든 byte가 같은 범위로 보호되는 것은 아니다. Temporary disk와 host cache가 encryption at host가 확장하는 중요한 경계다. 반대로 encryption at host는 Azure Storage SSE의 대체재가 아니라 end-to-end 범위를 확장한다. 또한 현재 또는 과거에 ADE를 사용한 VM에는 encryption at host를 활성화할 수 없고, encryption at host를 사용하는 disk에 ADE를 켤 수도 없다. 변경 전에 migration과 공존 가능성을 반드시 확인해야 한다.

ADE 은퇴를 Inventory와 Migration risk로 다룬다

Azure Disk Encryption은 2028년 9월 15일 은퇴 예정이다. Microsoft의 현재 안내는 새 VM에 encryption at host를 사용하거나, 지원되는 confidential-computing workload에는 적합한 Confidential VM 옵션을 검토하라는 것이다. 은퇴일 뒤에도 ADE workload가 당장 멈추지 않을 수 있지만, reboot하면 암호화된 disk를 unlock하지 못해 service disruption이 발생할 수 있다.

따라서 ADE가 적용된 VM과 관련 backup에는 owner, migration plan, 검증 증적과 deadline이 필요하다. 공식 migration은 in-place toggle이 아니며 새 disk와 VM을 만들어야 한다. 안전한 전환은 Windows/Linux ADE inventory, application·recovery dependency mapping, 대상 VM size와 region의 encryption-at-host 지원 확인, restore/rollback rehearsal, wave별 migration, reboot 검증 및 기존 경로 decommission 순서로 수행한다.

Threat model에서 옵션을 선택한다

기능 이름보다 질문부터 사용한다.

• Azure Managed Disk에 저장되는 data가 우려라면 현재 SSE 상태와 platform-managed key가 요구를 충족하는지 확인한다.
• 조직이 key custody를 직접 통제해야 한다면 Disk Encryption Set과 Key Vault를 통한 customer-managed key를 평가하고 availability·운영 책임을 함께 승인한다.
• Temporary disk, host cache 및 compute-to-Storage path가 범위에 들어가면 encryption at host와 compatibility requirement를 검토한다.
• Confidential-computing 요구가 있다면 지원되는 Confidential VM과 disk 옵션을 별도의 architecture decision으로 평가한다.
• 이미 ADE가 있다면 “더 강한 최신 통제”라는 증적으로 보지 말고 deadline이 있는 migration obligation으로 관리한다.

Customer-managed key는 rotation과 revoke에 더 큰 통제력을 줄 수 있지만 운영 책임도 가져온다. Key에 접근할 수 없으면 data에도 접근할 수 없으므로 보안 강화가 availability 사고로 바뀔 수 있다.

Azure Key Vault는 key, secret, certificate를 application code에서 분리한다. 제대로 운영하려면 다음 항목이 필요하다.

• management plane과 data plane 각각의 least privilege
• source code나 pipeline variable에 고정 credential을 넣는 대신 Managed Identity 사용
• rotation 주기와 새 key version을 따라갈 application의 호환성
• 복구 요구에 맞는 soft delete와 purge protection
• key read, change, delete 같은 민감 동작의 log와 alert
• backup, region 장애, accidental delete를 포함한 recovery 절차
• workload 관리자와 key 관리자의 역할 분리
• 비상 시 key 접근을 복구하는 승인·감사 가능한 break-glass 절차

구성과 복구 가능성을 함께 증명한다

좋은 증적은 control-plane 상태와 운영 test를 함께 보여 준다.

• Region, disk type, encryption type, encryptionAtHost 상태와 해당 시 Disk Encryption Set을 표시한 VM/disk inventory
• Platform-managed key 또는 customer-managed key를 고른 이유가 있는 승인된 threat model과 key decision
• Key Vault/Disk Encryption Set role assignment, key version/rotation, soft delete, purge protection 및 diagnostic setting
• 신규 resource에 의도한 구성을 적용하는 Policy 또는 Infrastructure as Code 증적
• Rotation 뒤 application access까지 확인한 sanitized key rotation/recovery test
• 대표 VM의 reboot/restore 증적, 특히 ADE migration 전후 결과
• Owner, target pattern, migration wave, validation date와 deadline을 포함한 ADE inventory

Screenshot과 학습 노트에는 secret value, key material, 전체 resource identifier 또는 production data를 넣지 않는다. 증적은 구성을 입증해야 하지만 새로운 정보 노출 위험이 되어서는 안 된다.

흔한 오해

“암호화됨이라고 표시되면 끝이다.” 어떤 data가 어느 구간에서 어떤 key로 보호되는지, key를 누가 관리하는지, plaintext가 memory·log·backup에 남는지까지 확인해야 한다.

“Managed Disk는 기본 암호화되므로 cache와 temporary disk도 같은 방식으로 보호된다.” SSE는 Storage cluster의 Managed OS/Data Disk를 보호한다. 추가 host 경계는 encryption at host가 담당한다.

“ADE와 encryption at host를 함께 켜면 더 강해진다.” 두 방식에는 명시적인 비호환 조건이 있다. ADE는 은퇴 예정이므로 둘을 겹치는 것이 아니라 migration을 설계해야 한다.

“암호화가 무결성을 보장한다.” 암호화는 인증된 보호의 구성 요소가 될 수 있지만 무결성은 별도 통제와 증적이 필요하다. Key Vault도 unauthorized application change를 복구하지 않는다.

“Customer-managed key가 항상 더 안전하다.” 규제 또는 key custody 요구가 있다면 유용하지만, 준비되지 않은 rotation과 revoke는 대규모 장애를 일으킬 수 있다. CMK의 이점과 복구 책임을 함께 승인해야 한다.

“Key Vault에 넣으면 누구도 볼 수 없다.” 허용된 Identity와 application은 data-plane 권한으로 secret이나 key operation을 사용할 수 있다. RBAC, network access, audit log와 secret 소비 방식이 함께 안전해야 한다.

8. 강의 실습을 안전하게 다시 보는 방법

다음은 개인의 완료 기록이 아니라 재현 가능한 학습 패턴이다.

실습 패턴 A: Windows VM 만들기

학습 목표: 새 VM 주변의 security default와 선택 사항을 모두 식별한다.

배포 전에 region, image, authentication method, VNet/subnet, Public IP 여부, NSG inbound rule, disk encryption, Managed Identity, monitoring 및 owner를 표로 작성한다. 배포 후 creation wizard의 요약만 보지 말고 effective security rule과 route를 확인한다. Production credential이나 개인정보를 실습 데이터로 사용하지 않는다.

검증 질문: VM에 Public IP가 꼭 필요한가? RDP/SSH source가 Any인가? OS와 extension은 patch 가능한 상태인가? Diagnostic data는 어디로 가는가? Resource delete와 disk cleanup은 함께 되는가?

남길 증적: 민감정보를 제거한 architecture note, resource inventory, effective rule export, 예상 기준과 실제 상태의 차이 목록.

실습 패턴 B: Azure Firewall 구성

학습 목표: workload traffic이 명시적인 policy point를 통과함을 입증한다.

격리된 resource group과 겹치지 않는 address plan을 만들고, 요구에 맞는 Firewall SKU와 subnet을 배포한다. UDR로 test subnet의 traffic을 Firewall에 보낸 뒤 승인된 flow 하나만 만든다. 승인 flow가 성공하는지와 유사하지만 승인하지 않은 flow가 실패하는지를 모두 시험한다. 두 결과가 log destination에서 검색되는지도 확인한다.

검증 질문: Route가 없을 때와 있을 때 next hop이 어떻게 달라지는가? DNS가 application rule과 일치하는가? Rule collection의 우선순위가 의도와 같은가? 장애 시 traffic은 fail-open인가 fail-closed인가?

남길 증적: Address/route intent, rule purpose, positive/negative test matrix, timestamp, sanitized log query와 결과.

실습 패턴 C: JIT로 port 보호

학습 목표: 상시 open port와 시간 제한 access의 차이를 관찰한다.

먼저 Plan 2 entitlement와 network topology 지원 여부를 확인한다. 요청 전 effective inbound 상태를 기록하고, 통제된 source에서 가장 짧은 실용적 시간으로 access를 요청한다. 임시 변경을 검증한 뒤 만료 후 새 connection이 차단되는지 확인한다. 이미 성립한 TCP session은 새 connection과 다르게 동작할 수 있으므로 시험 조건을 명확히 한다.

검증 질문: 요청 권한은 누가 갖는가? Source IP를 넓게 지정했는가? 만료 후 rule과 새 connection이 모두 제한되는가? 요청·승인 event가 감사 가능한가?

남길 증적: RBAC 결정, 요청 source/port/duration, approval event, 전후 rule 상태와 종료 검증.

모든 일회성 실습에는 tag와 budget alert를 적용한다. 필요한 sanitized 증적만 남긴 뒤 resource group, Public IP, disk, Log Analytics workspace, Key Vault, Firewall 및 유료 Defender plan의 cleanup 여부를 각각 확인한다. Cleanup도 보안 실습이다. 방치된 Identity와 Public IP는 공격 표면이고, 방치된 Firewall과 log는 비용 표면이다.

9. 2026년 기준 명칭과 서비스 상태 보정

강의의 개념은 유효해도 화면과 제품명은 바뀔 수 있다.

• Azure Active Directory의 현재 이름은 Microsoft Entra ID다. Identity 개념은 이어지지만 최신 Portal과 문서는 새 명칭을 사용한다.
• Azure Security Center와 Azure Defender는 Microsoft Defender for Cloud로 발전했다. 현재는 CSPM, DevSecOps와 workload protection을 결합한 CNAPP로 설명된다.
• Azure Firewall은 Basic, Standard, Premium 세 SKU의 기능·처리량·운영 요구를 비교한다.
• 강화된 DDoS option은 DDoS IP Protection과 DDoS Network Protection이다. Azure 플랫폼의 기본 infrastructure protection과 구분한다.
• JIT VM access의 현재 entitlement는 Defender for Servers Plan 2에 연결되며 network topology 제한을 확인해야 한다.

강의는 질문과 원리를 배우는 출발점으로 사용하고, 실제 배포 직전에는 현재 Microsoft Learn에서 SKU, region 지원, licensing, 가격 및 Portal workflow를 다시 검증한다.

10. 비용·라이선스·운영 판단표

항목	비용 또는 조건	운영 전에 물을 질문
DDoS Protection	IP 또는 network protection 모델과 부가 혜택이 다름	보호할 Public IP 수와 사고 대응 요구는 무엇인가?
Azure Firewall	SKU 시간, 처리 data, Public IP, log 비용	중앙 policy가 줄이는 위험이 비용과 복잡성보다 큰가?
WAF	Gateway/Front Door SKU, rule 운영, log	False positive를 누가 검토하고 exception을 만료시킬까?
JIT	Defender for Servers Plan 2 필요	보호할 서버 수와 다른 Plan 2 기능의 가치까지 확인했는가?
Key Vault/CMK	Operation, premium key/HSM, network와 운영 비용 가능	Rotation·recovery 책임을 수행할 owner가 있는가?
Log Analytics	Ingestion, retention, archive와 query 비용	어떤 log를 얼마 동안 어떤 탐지에 사용할 것인가?

가격 숫자를 문서에 고정하면 금방 낡는다. 대신 cost model과 사용량 driver를 기록하고 Azure Pricing Calculator와 실제 Cost Management 데이터를 배포 전에 다시 확인한다.

11. 운영 체크리스트

• 모든 Public endpoint에 필요성, owner와 종료 조건이 있다.
• DDoS coverage가 실제 지원 대상 Public IP와 연결되어 있다.
• L3/L4 DDoS와 L7 WAF의 책임을 혼동하지 않는다.
• Route를 통해 traffic이 실제 Azure Firewall을 통과함을 증명했다.
• NSG/Firewall/WAF rule에 목적, owner, test, 만료 또는 review date가 있다.
• 허용 test와 차단 test를 모두 수행했다.
• 관리 port는 기본적으로 private이거나 문서화된 시간 제한 절차로 보호된다.
• JIT의 Plan 2, RBAC, source, duration과 topology 호환성을 확인했다.
• 암호화 요구를 전송 중, 저장 중, 사용 중으로 나눴다.
• Key rotation, deletion protection, monitoring과 recovery를 검증했다.
• Diagnostic log가 owner가 있는 목적지에 도착하고 retention이 정해져 있다.
• Lab resource와 유료 plan의 cleanup 및 비용 확인 절차가 있다.

12. 스스로 설명해 볼 질문

1. 하나의 Web Application에 DDoS Protection과 WAF가 동시에 필요한 이유는 무엇인가?
2. Subnet traffic이 실제 Azure Firewall을 통과한다는 사실을 어떤 증적으로 입증할 수 있는가?
3. NSG만으로 충분한 상황과 중앙 Firewall이 필요한 상황은 어떻게 다른가?
4. Basic, Standard, Premium Azure Firewall 중 하나를 고를 때 기능 외에 무엇을 고려해야 하는가?
5. JIT가 줄이는 공격 표면은 무엇이며, JIT 이후에도 남는 Identity와 host 위험은 무엇인가?
6. Bastion과 JIT는 어떤 점에서 다르고 어떻게 함께 사용할 수 있는가?
7. Customer-managed key가 보안을 높이면서 availability 위험도 높일 수 있는 이유는 무엇인가?
8. VM만 삭제했을 때 Public IP, disk, Identity, key와 log 중 무엇이 남을 수 있는가?
9. DDoS, Firewall, JIT 및 key alert를 실제로 받는 사람은 누구이며 어떤 권한이 필요한가?
10. 이 통제 중 하나가 실패했을 때 탐지 방법과 rollback은 무엇인가?

마지막 기억 문장

DDoS는 가용성, WAF는 웹 요청, Firewall은 경로, NSG는 가까운 흐름,
JIT는 노출 시간, Encryption은 데이터와 키의 수명주기를 지킨다.

각 답을 scope, owner, evidence, failure behavior라는 네 단어로 설명할 수 있다면 이 단원은 제품 목록이 아니라 운영 가능한 보안 모델이 된다.

참고 자료

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Azure DDoS Protection 개요
• Microsoft Learn: Azure Firewall SKU 선택
• Microsoft Learn: Azure Web Application Firewall 개요
• Microsoft Learn: Just-in-time VM access
• Microsoft Learn: Azure Key Vault 개요
• Microsoft Learn: Managed Disk 암호화 옵션
• Microsoft Learn: Azure Disk Encryption에서 encryption at host로 migration
• Microsoft Learn: Microsoft Defender for Cloud 개요