모듈 4 복습: 계층형 Azure VM 보안을 설계하고 증명하는 방법

Coursera의 Azure Cybersecurity Solutions and Microsoft Defender 과정은 Module 4에서 전체 내용을 정리한다. 공개된 구성에는 Course Recap, Scenario 기반의 “Securing virtual machines” Project, 평가, 학습 Reflection과 Next Step이 포함된다. 이 단원을 제대로 복습하려면 하나의 이상적인 Portal 설정을 외우기보다 어떤 위협 때문에 통제를 선택했고, 어떻게 안전하게 검증하며, 무엇을 증적으로 남길 것인지 설명할 수 있어야 한다.

이 글은 강의의 Assignment 지시문이나 평가 문제, 정답을 재현하지 않는다. 사용자가 아래 통제를 실제 Tenant에 배포했거나 Course를 완료했다고 주장하지도 않는다. 여기의 Virtual Machine 설계는 독립적으로 구성한 가상 복습 Framework다. Production에 적용할 때는 최신 Microsoft 공식 문서를 다시 확인하고, 승인된 Lab Test와 Change Approval을 거쳐야 한다.

1. 네 개 Module을 하나의 보안 시스템으로 다시 조립한다

과정의 네 Module은 개별 제품 목록이 아니라 다음 순서로 이어진다.

Module	핵심 범위	운영 관점의 질문
1. Azure Basic Security Capabilities	DDoS Protection, Virtual Network, Azure Firewall, WAF, JIT, Key Management, Encryption	외부에 노출된 Attack Surface를 어떻게 줄이는가?
2. Security Management in Azure	Cloud Security, Defender for Cloud, Bastion, Azure Policy, SIEM, Sentinel, SOAR	Guardrail과 Detection을 어떻게 일관되게 운영하는가?
3. Defender Threat Protection	Defender Portal, XDR Incident, Endpoint, Identity, Information Protection, Sentinel Connector	여러 신호를 어떻게 하나의 Attack Story로 연결하는가?
4. Assessment and Wrap-up	VM Security Scenario, 전체 복습, Reflection, Next Step	지식을 검증 가능한 설계로 바꾸고 Trade-off를 설명할 수 있는가?

전체 과정을 한 줄로 기억하면 다음과 같다.

Prevent -> Limit -> Detect -> Respond -> Recover -> Prove

• Prevent: 불필요한 Public Exposure를 없애고, Patch와 Safe Default를 적용하며, Credential을 보호한다.
• Limit: Network를 분리하고, 권한과 Management Path를 최소화해 침해의 Blast Radius를 줄인다.
• Detect: Control Plane, Network, Identity, Endpoint, Workload, Data Signal을 수집한다.
• Respond: Incident Owner를 정하고, 영향 받은 Entity를 격리하고, Root Cause를 제거한다.
• Recover: 신뢰 가능한 상태로 Service를 복구하고 공격자의 접근이 제거되었는지 확인한다.
• Prove: Configuration, Log, Test, Approval, Incident Record로 통제가 작동함을 보여 준다.

초보 설계는 Prevent에서 끝나는 경우가 많다. 탐지 성숙도가 높은 팀도 Respond까지만 고민할 수 있다. 실제 운영 가능한 설계에는 Recover와 Prove가 반드시 포함되어야 한다.

2. Azure 제품 목록이 아니라 Workload Context에서 시작한다

복습 대상은 가상의 업무 Application이라고 가정한다. 두 대의 Azure VM이 Web Entry Point 뒤에서 동작하고, 관리자는 가끔 RDP 또는 SSH가 필요하다. Application은 Managed Disk에 고객 데이터를 저장하고 중앙 Workspace로 Log를 전송하며, Network 또는 Region 장애에도 정해진 시간 안에 복구되어야 한다.

제품을 선택하기 전에 다음 Context를 적는다.

1. Business Impact: Service 중단, Data 변조, 정보 유출이 발생하면 어떤 손실이 생기는가?
2. Data: 어떤 Classification, Retention, Encryption, Residency 요구가 있는가?
3. User와 Identity: VM 관리자는 누구이며 어떤 Managed Identity와 Service Principal을 사용하는가? Emergency Account는 무엇인가?
4. Connectivity: 실제 필요한 Inbound와 Outbound Flow는 무엇인가? Public IP가 정말 필요한가?
5. Platform Boundary: 어떤 Subscription, Resource Group, VNet, Policy Scope, Defender Plan이 보호하는가?
6. Operations: 누가 Patch, Monitoring, Incident Response, Restore, Cost를 책임지는가?
7. Recovery: RTO와 RPO는 무엇이며 마지막 Restore Test는 언제였는가?

이 Context 없이 “보안 기능을 모두 켠다”는 방식은 비싸면서도 위험하다. Application Flow를 모른 채 Firewall을 강화하면 장애가 발생한다. Remediation Owner 없는 High Severity Policy는 영구적인 Non-compliance를 만든다. Key Recovery를 테스트하지 않은 Encryption은 Confidentiality Control이 아니라 Availability Failure의 원인이 될 수 있다.

3. 위협·통제·검증·증적 Matrix를 만든다

다음 표는 Course Project의 정답이 아니라 가상 Workload에 적용할 수 있는 독립적인 설계 Worksheet다. 각 행은 현실적인 Threat와 Layered Control, 안전한 Validation, 보존할 Evidence를 연결한다.

위협 또는 실패	계층형 통제 선택지	안전한 검증 방법	보존할 증적
Public Endpoint에 대한 대규모 Traffic Attack	Resilient Architecture, 필요 시 Azure DDoS Protection, Autoscale, Health Probe, Incident Plan	보호 대상 IP Coverage 검토, Metric과 Alert 설정, 승인된 Testing Service만 사용	Protection Plan Assignment, Protected IP Inventory, Alert Rule, DDoS Metric과 Attack Report
SQL Injection 같은 Web Attack	Secure Coding과 Patch, WAF Policy, Backend Access 제한	Non-production에서 승인된 정상·비정상 Request로 Mode와 Log 검증	WAF Policy Version, Rule Tuning 결정, Request Log, Remediation Ticket
불필요하게 열린 RDP/SSH	VM Public IP 제거, Bastion 또는 Private Path, NSG Default Deny, 필요 시 JIT	Effective NSG Rule 조회, 제한된 JIT Request, 만료 후 차단 확인	Effective Rule Export, Bastion 설정, JIT Audit, Source IP와 Expiry
통제되지 않은 Ingress/Egress	NSG, Application Security Group, Azure Firewall Policy, Route, DNS Strategy	Required Flow Matrix와 실제 Route/Rule 비교, 승인된 Test Flow 생성	Source-controlled Firewall Policy, Rule Collection, Flow/Application Log, Change Approval
관리자 Credential 탈취	Phishing-resistant MFA, Conditional Access, PIM, Least-privilege RBAC, Privileged Workstation	전용 Test Account로 Role Eligibility와 Activation 확인, Emergency Access 별도 검증	Role Assignment와 PIM Log, Sign-in/CA Result, Access Review 결정
VM의 Malware 또는 취약점 악용	Patch Management, Endpoint Protection/EDR, Defender for Servers, Application Control, ASR	Agent Health와 Update Compliance 확인, Vendor의 안전한 Test Artifact만 사용	Patch Report, Onboarding Status, Alert/Incident ID, Isolation/Remediation 기록
Boot 또는 Kernel 변조	Trusted Launch, Secure Boot, vTPM, Guest Attestation	VM Security Type과 Attestation Health, Defender Recommendation 확인	ARM Resource Property, Attestation 결과, Secure Boot/vTPM Compliance
Disk/Snapshot 노출 또는 Key 오용	Managed Disk SSE, 필요 시 Encryption at Host/Confidential Option, 정당한 경우 CMK, Disk Export 제한	Encryption과 Network Access 설정 확인, Lab에서 Key Rotation/Recovery Test	Disk Encryption 설정, Key Vault Access/Rotation Log, Policy Compliance, Recovery Test
Configuration Drift	Azure Policy Initiative, Defender for Cloud Recommendation, IaC, 검토된 Exemption	Test Scope에서 Audit/Deny/Modify와 Remediation 검증, 만료 예정 예외 Simulation	Assignment ID, Compliance State, Deployment Record, Exemption Owner/Expiry
탐지 누락 또는 Fragmented Incident	Defender for Cloud/XDR, Microsoft Sentinel, Diagnostic Setting, Notification와 Ownership	승인된 Signal을 Source Alert에서 Incident, Owner, Action, Closure까지 추적	Alert/Incident ID, Entity Timeline, Connector Health, Analyst Comment, Classification
파괴적 변경 또는 Ransomware	Least Privilege, 적절한 Resource Lock, 보호된 Backup, Immutable/Soft Delete Option, 격리된 Recovery Credential	정기 Restore Test와 Application Integrity 확인	Backup Policy, Protected Item Inventory, Restore 결과, 실제 RTO/RPO, 승인 기록

이 Matrix는 단순 Product Checklist가 숨기는 빈틈을 보여 준다. Validation 방법이 없는 Control은 가정일 뿐이다. 결과를 보존하지 않는 Test는 Audit나 Post-incident Learning에 사용할 수 없다. Owner 없는 Evidence는 곧 오래된 정보가 된다.

4. Network는 바깥쪽에서 안쪽으로 설계한다

4.1 DDoS Protection과 WAF는 서로 다른 계층이다

Azure DDoS Protection은 지원되는 Public IP Resource를 대상으로 Network Layer의 Availability Attack을 완화한다. DDoS Network Protection과 DDoS IP Protection은 과금 모델과 부가 기능이 다르다. Protected IP 수, Workload 중요도, 지원 요구, Architecture, 비용을 근거로 선택해야 한다. 모든 VM에 개별 Plan이 반드시 필요하다는 뜻은 아니다.

DDoS Protection은 HTTP Request의 Business 의미를 분석하는 통제가 아니다. Layer 7의 Web Attack에는 Secure Development, Patch, Rate Control, 필요 시 Azure Web Application Firewall이 필요하다. WAF도 조정해야 한다. Detection Mode에 영구적으로 두면 Visibility는 얻지만 Block하지 못한다. False Positive 분석 없이 즉시 Prevention Mode로 전환하면 정상 Traffic을 중단시킬 수 있다.

검증 증적에는 Protected Resource Coverage, Alert/Metric 설정, WAF Policy Mode, Rule Exclusion의 Owner와 Expiry, Incident Escalation Runbook이 포함된다. 승인되지 않은 Load Test나 DDoS Test를 Public Service에 실행해서는 안 된다.

4.2 NSG와 Azure Firewall의 역할은 다르다

Network Security Group은 Subnet 또는 NIC Scope에서 분산형 Layer 3/4 Filtering을 제공한다. Azure Firewall은 Network와 Application Traffic에 대해 중앙집중형 Stateful Policy와 Logging Point를 제공한다. 하나를 사용한다고 다른 하나가 자동으로 불필요해지는 것은 아니다.

Rule을 작성하기 전에 Flow Matrix를 만든다.

Source	Destination	Protocol/Port	Business Purpose	Owner	Log Requirement
Web Entry Tier	Application VM Subnet	Application Port만	승인된 Backend Request 전달	App Team	Allow/Deny Visibility
Admin Path	VM Management Interface	시간 제한 RDP/SSH	승인된 Maintenance	Platform Team	Identity와 Session Evidence
Application VM	필요한 Platform/Dependency	명시된 Service	Update, Telemetry, 업무 Dependency	App Owner	Egress Review

Template의 의도만 보지 말고 Effective Route와 Effective Security Rule을 확인한다. Firewall Rule이 정확해도 Route가 Firewall을 우회하면 통제는 작동하지 않는다. 광범위한 Service Tag나 Wildcard는 이유가 필요하고, Temporary Rule에는 Owner와 Expiry가 있어야 한다.

4.3 Bastion과 JIT는 연관되지만 같은 통제가 아니다

Azure Bastion은 Private IP를 통해 VM으로 연결되는 Managed RDP/SSH Path를 제공해 VM Public IP의 필요를 줄인다. Defender for Servers Plan 2의 Just-in-time Machine Access는 선택한 Management Port를 제한하고, 승인된 Source와 Duration에만 열도록 돕는다.

Bastion은 어떤 경로로 연결하는가를 바꾸고, JIT는 언제 어디에서 Port 접근을 허용하는가를 바꾼다. 서로 보완할 수 있지만 MFA, Conditional Access, PIM, RBAC, Privileged Workstation, Session Accountability, Emergency Access까지 대체하지는 않는다.

가장 먼저 “Interactive Login이 정말 필요한가?”라고 질문해야 한다. Automation, Configuration Management, Run Command, Immutable Image로 관리 Session 자체를 줄일 수 있다. Login이 필요하다면 User, Source, Reason, Approval, Start/End Time, Target, Change Result를 기록한다.

5. Identity와 Azure Control Plane을 함께 보호한다

Guest OS를 완벽하게 Hardening해도 Control Plane Permission이 과도하면 VM은 위험하다. 강한 권한을 가진 Principal은 Extension을 변경하고, Credential을 Reset하고, Disk를 Attach하고, Network를 바꾸고, Evidence를 삭제할 수 있다.

Identity 유형을 구분한다.

• Human Administrator: 개인 Account, Strong Authentication, Conditional Access, 가능하면 상시 권한 대신 PIM Eligible Role, 정기 Access Review를 사용한다.
• Workload Identity: Embedded Secret보다 Managed Identity를 우선하고, 필요한 Management/Data Plane Permission만 부여한다.
• Automation Identity: Pipeline Scope를 제한하고, Federation 또는 Credential을 보호하며, Reviewed Change만 배포하고 Log를 남긴다.
• Emergency Access Identity: 최소 수만 유지하고, 감시하고, 주기적으로 Test하며, Recovery 설계상 필요한 Policy에서만 제외한다.

Azure RBAC는 Azure Resource의 Management Plane 작업을 제어한다. Guest OS Permission과 Application/Data Plane Authorization은 별도다. Resource Group Contributor라는 사실만으로 Application Data를 읽을 수 있는지 알 수 없고, VM Administrator라고 Subscription 전체 권한이 정당화되는 것도 아니다.

검증 질문은 다음과 같다. 누가 VM, Network, Disk, Key, Policy, Monitoring, Backup을 변경할 수 있는가? 어떤 Role이 Permanent인가? 사용되지 않는 Identity는 무엇인가? Workload Identity가 불필요한 Secret에 접근할 수 있는가? Role 변경이 Monitoring으로 전송되는가? Access Review 결과, PIM Activation, Role Assignment Change, Exception을 증적으로 남긴다.

6. VM, OS, Data를 Hardening한다

6.1 신뢰 가능한 Build와 Lifecycle에서 시작한다

지원되는 Image를 사용하고, 설치 Software와 Service를 최소화하고, Patch 주기와 Vulnerability Remediation SLA를 정한다. Trusted Launch는 지원되는 VM Generation과 구성에서 Secure Boot, vTPM, Boot Integrity Monitoring을 제공한다. Boot Chain을 보호하는 통제이지 Application Patch나 Stolen Credential을 해결하는 통제는 아니다.

Defender for Servers와 Defender for Endpoint는 Plan과 Onboarding Architecture에 따라 Posture, Vulnerability, Endpoint, Workload Detection을 제공할 수 있다. Coverage와 Sensor Health를 확인해야 한다. 유료 Plan을 켰지만 실제 Onboarding이 60%라면 전체 보호가 아니다.

검증 순서: Supported Image와 End-of-support Date 확인 → Patch Baseline과 Maintenance Window 정의 → Trusted Launch Compatibility 확인 → Endpoint/Workload Sensor Onboarding → Health와 Update Compliance 확인 → 승인된 Safe Test Signal → Alert Routing과 Response 권한 확인.

증적: Image Reference, Patch Compliance, Vulnerability Backlog, Secure Boot/vTPM Resource Property, Sensor Health, Test Incident와 Remediation Ticket.

6.2 Encryption은 Threat Model로 선택한다

Azure Managed Disk는 기본적으로 Server-side Encryption at Rest를 사용하지만 추가 옵션은 서로 다른 Threat를 다룬다. 현재 Managed Disk Encryption Overview는 Server-side Encryption, Encryption at Host, Confidential Disk Encryption, 기존 Azure Disk Encryption을 구분한다.

Customer-managed Key가 더 전문적으로 보인다는 이유로 선택해서는 안 된다. CMK는 Key Availability, Rotation, Permission, Separation of Duties, Backup, Recovery 책임을 추가한다. 규제나 통제 요구가 이 운영 모델을 정당화할 때 선택하고, Key가 Rotate, Disable, Delete되거나 접근 불가능할 때 어떤 일이 발생하는지 Lab에서 테스트한다.

현재성 검토도 필요하다. 이 글의 검증일 기준으로 Microsoft는 Azure Disk Encryption의 2028년 9월 15일 Retirement를 문서화하고, 신규 VM에는 Encryption at Host 또는 목적에 맞는 Confidential Computing Option을 검토하도록 안내한다. 오래된 강의 화면을 그대로 복제하지 말고 최신 Migration Guidance를 확인해야 한다.

Encryption at Rest는 승인된 Process나 침해된 Administrator가 Decrypted Data를 읽는 것을 막지 못한다. Identity Control, Data Classification, Disk Export 제한, Monitoring, Backup 보호와 함께 적용한다.

7. Governance를 실행 가능하고 검토 가능한 Baseline으로 만든다

Azure Policy는 지정 Scope에서 Resource 설정을 Audit, Deny, Modify하거나 필요한 구성을 배포할 수 있다. Defender for Cloud는 Posture 정보를 사용해 Security Recommendation을 제공한다. Infrastructure as Code는 의도한 Architecture를 Review하고 반복 배포하게 한다. 세 Mechanism은 서로 강화하지만 같은 것은 아니다.

안전한 Policy Rollout 순서는 다음과 같다.

1. 단순히 제품 기능을 켜는 것이 아니라 줄이려는 Risk와 측정할 Property를 정의한다.
2. 대표 Resource에서 Definition과 Parameter를 Test한다.
3. Audit Mode로 Assignment하고 False Positive와 Unsupported Case를 확인한다.
4. Non-compliance마다 Remediation Owner와 Deadline을 정한다.
5. Exemption에는 이유, Approver, Scope, Compensating Control, Expiry를 둔다.
6. 영향 Test 후에만 Deny, Modify, DeployIfNotExists로 강화한다.
7. Compliance Latency, Managed Identity Permission, Remediation Failure, Drift를 감시한다.

Module 2에는 Azure Blueprints가 등장하지만 현재는 역사적 내용이다. 2026년 8월 현재 Azure Blueprints는 단계적 Retirement 중이며 신규 Definition과 Version 생성 단계부터 제한되기 시작했다. Microsoft는 Lifecycle과 Deny 동작에는 Azure Deployment Stacks, Template 저장·Version에는 Template Specs 또는 Git을 권장한다. 새로운 표준을 Blueprint 기반으로 설계해서는 안 된다.

Governance 증적에는 Policy Definition/Assignment, Version Control Review, Deployment Record, Compliance Export, Remediation Task Result, Exemption Register가 포함된다. Dashboard의 백분율만으로는 부족하다. 어떤 Scope를 언제 평가했으며, 제외된 Resource가 어떤 Residual Risk를 갖는지 기록한다.

8. Go-live 전에 Detection, Response, Recovery를 설계한다

Baseline에 “모든 Log를 보낸다”고 적혀 있어서가 아니라 Threat Model이 특정 Signal을 요구하기 때문에 Diagnostic Setting과 Endpoint/Workload Protection을 켜야 한다. 각 Data Source, Destination, Retention, 예상 Volume, Cost, Operational Query를 정의한다.

Defender for Cloud는 Posture Issue와 Workload Threat를 찾는다. Defender XDR는 Endpoint와 Identity Evidence를 상관분석할 수 있다. Microsoft Sentinel은 이 Incident를 Firewall, Identity, Application, Third-party Data와 연결해 SIEM/SOAR Workflow로 확장한다. Module 3에서 확인한 것처럼 Duplicate Incident Path를 피하고, 어떤 Alert와 Entity가 Sync되는지 검증하며, Connector Health를 감시한다.

High-priority Scenario마다 작은 Runbook을 만든다.

Trigger와 Severity 기준
  -> 최초 Triage Evidence
  -> Containment 권한과 안전한 Action
  -> 조사·Scope Query
  -> Remediation Owner
  -> Recovery Validation
  -> Communication과 Closure Evidence

Recovery는 Detection과 별도로 Test한다. Backup Job의 Green 상태는 Job이 실행되었다는 사실만 증명한다. Operator가 목표 시간 안에 Application을 Restore하고, 필요한 Key를 찾고, Dependency를 다시 연결하고, Data Integrity를 확인하고, Attacker Persistence 없이 Service를 시작할 수 있음을 증명하지 않는다. Restore Exercise를 일정화하고 실제 RTO/RPO를 기록한다.

9. 비용, License, 운영 주의사항

Security Control은 비용과 운영 Attention을 소비한다. 정확한 Price는 변하므로 오래된 금액을 문서에 고정하기보다 Assumption과 Review Date를 기록한다.

• Defender for Cloud Protection Plan과 Defender for Servers Capability는 Plan별로 다르다.
• JIT에는 Plan Prerequisite가 있으므로 Access Process를 설계하기 전에 확인한다.
• Azure Bastion, Azure Firewall, DDoS Protection, WAF, Log Analytics/Sentinel Ingestion, Retention, Automation, Egress에 각각 비용이 발생할 수 있다.
• CMK는 직접 비용이 작더라도 Key Operation과 Recovery 책임을 늘린다.
• 대량 Network/Endpoint Log는 Filtering과 Retention 결정이 필요하지만 비용 절감을 이유로 Incident/규제 증적을 제거해서는 안 된다.
• 운영 담당자가 없는 통제는 Alert, Exception, Outage, Failed Audit라는 숨은 비용을 만든다.

Control Cost는 Workload Business Impact와 Alternative를 함께 비교한다. 소규모 Internal VM이라면 Public IP를 제거하고 기존 Private Management Path를 사용하는 것이 여러 Edge Service를 새로 구매하는 것보다 효과적일 수 있다. 중요 Public Application이라면 Layered DDoS/WAF, Resilient Architecture, Rapid-response Plan이 정당화될 수 있다. Decision Record에 이유를 남긴다.

10. 흔한 오해와 바로잡기

1. “VM에 Public IP가 없으니 안전하다.” Peering, VPN, Compromised Host, Control Plane, 과도한 Identity 권한을 통해 접근할 수 있다.
2. “Bastion은 RDP/SSH용 MFA다.” Bastion은 Managed Connection Path다. Identity Assurance와 Authorization은 별도다.
3. “JIT가 모든 Management Path를 닫는다.” 선택된 Port와 지원 Network Resource를 제어한다. Effective Rule과 대체 경로를 확인해야 한다.
4. “DDoS Protection이 WAF를 대체한다.” Network-layer Availability와 Application-layer Request Inspection은 다른 위협을 다룬다.
5. “Encryption이면 Data 유출이 불가능하다.” Authorized Process가 Decrypt한 Data까지 보호하지는 않는다.
6. “Policy Compliance면 Workload가 안전하다.” 정의된 Resource Property를 평가할 뿐 Secure Code와 Incident Response를 증명하지 않는다.
7. “Defender를 Enable하면 모든 Resource가 감시된다.” Plan, Extension, Connector, Permission, 지원 Resource, Sensor Health가 Coverage를 결정한다.
8. “Backup 성공이면 Recovery 준비가 끝났다.” End-to-end Restore와 Integrity Test가 있어야 한다.
9. “Log가 많을수록 Detection이 좋아진다.” Owner, Query, Retention, Cost Plan이 없는 Log는 Noise를 늘린다.
10. “평가를 통과하면 Production 준비가 끝났다.” Production에는 Architecture Review, Controlled Implementation, Validation, Ownership, Continuous Improvement가 필요하다.

11. 단계별 설계와 검증 Plan

Phase A: Discover와 Design

• VM, Image, Extension, Public IP, NIC, NSG, Route, Disk, Identity, Role, Key, Backup Policy, Diagnostic, Owner를 Inventory한다.
• Workload Criticality와 Data를 분류하고 필요한 Inbound, Outbound, Admin Flow를 문서화한다.
• Threat Modeling 후 위협·통제·검증·증적 Matrix를 완성한다.
• License, Platform, Logging, Staffing, Recovery Cost를 추정한다.
• RACI, Exception Process, Maintenance Window, Rollback 기준에 합의한다.

Phase B: 안전한 Pilot

• 격리된 Subscription 또는 Resource Group에 대표 Workload를 재현한다.
• Identity와 Network Control을 가장 영향이 적은 순서로 적용한다.
• Policy는 Enforcement 전 Audit부터 시작한다.
• Defender Sensor를 Onboarding하고 Alert에 의존하기 전에 Health를 확인한다.
• 필요한 Log만 Enable하고 Timestamp, Field, Retention, Query Access를 확인한다.
• Vendor가 지원하는 Simulation과 Benign Check만 사용하며 승인 없이 공격 Test를 하지 않는다.

Phase C: End-to-end Control 증명

• Unauthorized Management Traffic이 차단되고 승인된 Access가 만료되는지 보여 준다.
• 안전한 Detection을 Source Alert부터 Correlation, Assignment, Response, Closure까지 추적한다.
• Encryption, Key Rotation/Recovery, Trusted Launch, Update Compliance를 검증한다.
• Drift가 Policy/Defender에 나타나고 Remediation Owner가 배정되는지 확인한다.
• Backup에서 Application을 복구하고 RTO/RPO 대비 결과를 측정한다.
• Evidence를 Sensitivity에 맞는 Access와 Retention이 적용된 장소에 보관한다.

Phase D: Release와 Operation

• Review된 IaC Change로 배포한다.
• Coverage, Control Health, Incident, Exception, Cost, Failure Queue를 감시한다.
• Privilege와 Firewall Rule을 정기 검토하고 만료된 Access를 제거한다.
• Scenario Exercise와 Restore Test를 정기 실행한다.
• Architecture Change와 Incident 이후 Threat Model을 갱신한다.

12. 반복 운영용 최종 Checklist

• 모든 VM과 Dependency에 Business/Technical Owner가 있다.
• Required Network Flow가 문서화되어 있고 불필요한 Public Exposure를 제거했다.
• DDoS/WAF 선택이 Public Endpoint Risk와 Application Architecture에 맞는다.
• Admin Access는 통제된 Path, Least Privilege, Strong Identity, Time Limit를 사용한다.
• NSG, Firewall, Route의 Effective Behavior를 Template 추측이 아니라 Test로 확인했다.
• Supported Image, Patch, Vulnerability, Endpoint/Workload Protection, Sensor Health를 감시한다.
• Disk, Host, Key, Export Control이 Data Threat Model에 맞는다.
• Policy가 Version 관리되고 Test/단계적 적용되며 Exemption과 Remediation Owner가 있다.
• Log와 Connector에 Owner, Retention, Cost Limit, Health Check, Tested Query가 있다.
• Incident Runbook에 Containment 권한, Rollback, Recovery, Closure Evidence가 있다.
• Backup이 보호되고 End-to-end Restore를 정기 측정한다.
• Evidence Package에 Approval, Configuration, Test, Incident, Open Risk가 포함된다.

13. 스스로 설명하는 복습 질문

1. Azure 제품을 선택하기 전에 Threat Model을 작성해야 하는 이유는 무엇인가?
2. 같은 VM Scenario에서 Prevent, Limit, Detect, Respond, Recover, Prove를 담당하는 통제는 각각 무엇인가?
3. 언제 DDoS Network Protection, DDoS IP Protection, WAF, 추가 유료 DDoS Tier 없음이 합리적 선택인가?
4. NSG, Azure Firewall, Bastion, JIT는 어떻게 다르고 어디에서 함께 사용할 수 있는가?
5. Management Access가 Default Deny이고 승인된 Session에만 열렸음을 어떤 Evidence로 증명할 수 있는가?
6. 선택한 Disk Encryption Option은 어떤 Threat를 줄이고 어떤 Key Recovery Risk를 추가하는가?
7. Azure Policy를 Deny 전에 Audit와 Impact Review로 시작해야 하는 이유는 무엇인가?
8. Defender Onboarding 누락이나 Sentinel Connector 장애를 어떻게 탐지하는가?
9. Incident Status를 Resolved로 바꾸는 것 외에 Closure에 무엇이 필요한가?
10. 성공한 Backup Job으로 증명할 수 없고 Restore Test로만 증명할 수 있는 것은 무엇인가?
11. Azure Blueprints나 Azure Disk Encryption 같은 강의의 역사적 내용은 왜 최신 문서를 확인해야 하는가?
12. Workload Owner, SOC Analyst, Auditor, Recovery Operator가 모두 이해할 Evidence Package를 만들 수 있는가?

14. 한 페이지 기억 요약

기억 문장	의미
SKU보다 Threat가 먼저다	정의된 Risk를 줄일 때만 Service 선택이 정당하다
단일 Control로 VM을 보호할 수 없다	Identity, Network, Host, Data, Monitoring, Recovery가 겹쳐야 한다
Configuration은 Evidence가 아니다	실제 동작을 검증하고 결과를 보존해야 한다
Private Network가 자동으로 Trusted는 아니다	모든 Identity, Route, Workload, Action을 검증한다
Owner 없는 Detection은 Noise다	중요한 Signal에는 Triage와 Response Route가 있어야 한다
Backup은 약속이고 Restore가 증명이다	End-to-end Exercise로 Recovery를 측정한다
Exception은 일시적인 Risk Decision이다	Owner, Reason, Compensating Control, Expiry를 둔다

최종 Reflection

Module 4의 가치는 여러 기능을 하나의 설계로 종합하게 한다는 점에 있다. DDoS Protection, Firewall, Bastion, JIT, Encryption, Policy, Defender, Sentinel은 서로 떨어진 시험 주제가 아니다. 한 Workload 주위에 겹쳐지는 보안 계층이다. 각 계층의 경계를 설명하고 Prevention부터 Recovery까지 전체 경로를 테스트할 수 있어야 Architecture가 신뢰를 얻는다.

과정에서 오래 남아야 할 결과물은 “보안 설정이 켜진 VM” Screenshot이 아니다. 다음 Reasoning Process다.

Asset과 Threat를 설명한다.
비례적이고 계층화된 Control을 선택한다.
Ownership과 Cost를 정한다.
실제 동작을 안전하게 검증한다.
Evidence를 보존하고 Response/Recovery를 Test한다.
Change, Incident, Exception을 계속 Review한다.

이 과정은 한 VM이나 한 Subscription, 한 Course를 넘어 모든 Cloud Security Design에 재사용할 수 있다. 보안 기능을 학습하는 단계에서 방어 가능한 Service를 운영하는 단계로 넘어가는 다리이기도 하다.

공식 참고 자료

• Coursera 과정 및 Module 4 구성
• Azure IaaS Workload Security Best Practices
• Azure Virtual Machine에 Zero Trust 원칙 적용
• Azure DDoS Protection Overview
• Azure Web Application Firewall Overview
• Azure Bastion Overview
• Just-in-time Machine Access
• Trusted Launch for Azure VMs
• Managed Disk Encryption Options
• Azure Policy Documentation
• Microsoft Defender for Cloud Overview
• Microsoft Defender XDR와 Microsoft Sentinel 통합