Azure Defense in Depth: 한 계층이 실패해도 작동하는 보안 설계

Azure 아키텍처 다이어그램에 보안 제품이 많이 그려져 있다고 해서 바로 Defense in Depth, 즉 심층 방어가 되는 것은 아니다. 같은 관리자, 같은 route, 같은 예외 정책에 의존하는 Firewall 두 개는 하나의 실수로 동시에 무너질 수 있다. Storage Account가 암호화되어 있어도 과도한 권한을 가진 Identity는 모든 문서를 읽을 수 있다. 로그를 모아도 Alert를 맡은 사람이 없거나 격리 권한이 없다면 방어가 아니라 기록 보관에 그친다.

따라서 실무에서 물어야 할 질문은 “보안 통제를 몇 개 배치했는가?”가 아니다.

통제 하나가 실패했을 때, 공격자의 다음 행동을 막는 독립 계층은 무엇이며, 어떤 신호로 시도를 발견하고, 누가 격리하며, 어떻게 안전한 상태로 복구할 것인가?

이 글은 Coursera Azure Cybersecurity Solutions and Microsoft Defender 강좌 Module 1을 12개 주제로 분해한 학습 계획의 첫 번째 상세 노트다. 기존 Module 1 복습 글은 DDoS Protection, Firewall, JIT, Encryption을 한눈에 보는 지도 역할을 유지한다. 여기서는 한 단계 더 내려가, 계층형 보안을 실제 아키텍처와 증적 설계로 바꾸는 방법에 집중한다.

이 글은 강의 transcript나 평가 답안이 아니라 개인 복습과 기술 검증을 위한 독립적인 설명이다. 강좌에서 얻은 개념, Microsoft 공식 문서에서 확인한 사실, 이 글에서 구성한 설계 판단을 구분했다. 제품명과 프레임워크 설명은 2026년 8월 10일 Microsoft Learn을 기준으로 검토했다. 실제 Azure 리소스를 배포하거나 Lab 검증을 완료했다고 주장하지 않는다.

1. 이 글에서 해결할 질문

Azure 보안 계층이 서로 다른 실패 원인을 줄이도록 설계하려면 어떻게 해야 하는가?

이 글을 반복해서 살펴본 뒤에는 다음을 설명할 수 있어야 한다.

• 제품 이름 없이 Defense in Depth의 목적을 설명한다.
• Defense in Depth와 Zero Trust, 공동 책임 모델, Landing Zone의 역할을 구분한다.
• 현실적인 공격 경로를 Identity, Edge, Network, Compute, Application, Data 경계로 나눈다.
• 각 단계에 예방, 탐지, 격리, 복구, 증적 및 책임자를 연결한다.
• 서로 다른 계층처럼 보이지만 하나의 공통 실패 지점을 가진 통제를 발견한다.
• Azure 리소스 비용을 쓰기 전에 Architecture Tabletop으로 설계를 검토한다.

Subscription, Virtual Network, Identity, Application, Data Store의 기본 개념 정도만 알고 있으면 된다. 이 글은 검증하지 않은 배포 절차를 만들지 않기 위해 Portal, CLI, Terraform 단계를 억지로 포함하지 않는다. 결과물은 리소스가 아니라 위협에 근거한 설계다.

2. Defense in Depth를 실무 언어로 정의하기

Microsoft의 Azure 입문 모델은 Physical Security, Identity and Access, Perimeter, Network, Compute, Application, Data의 일곱 계층을 설명한다. 이 모델은 좋은 점검표지만 숫자 7은 구매 목록이 아니다. 모든 Workload가 서로 다른 Azure 제품 7개를 반드시 가져야 한다는 의미도 아니다.

실무에서는 다음처럼 기억하는 편이 유용하다.

Defense in Depth
= 서로 다른 공격·실패 조건을 줄이는 통제
+ 통제가 작동하거나 우회된 사실을 보여주는 신호
+ 예방 실패 후의 격리와 복구
+ 정해진 시간 안에 행동할 수 있는 책임자

계층은 공격자에게 반복적으로 새로운 결정을 요구해야 한다. Public Application Edge를 통과했다고 Application Tier 접근이 자동 허용되어서는 안 된다. Application에서 Code 실행 권한을 얻었다고 광범위한 Data 권한이 따라와서는 안 된다. Data Credential을 획득했다고 Recovery Copy까지 삭제할 수 있어서는 안 된다. 하나의 관리자 Role로 통제 변경, 로그 억제, Backup 파괴가 모두 가능해서도 안 된다.

다음 네 가지 질문으로 계층의 실효성을 확인할 수 있다.

1. 서로 다른 실패인가? 다음 통제가 이전 통제로는 줄이지 못한 실패 원인을 다루는가?
2. 실제 강제 지점인가? 공격이 반드시 그 통제를 통과하는가, 아니면 다른 Endpoint, Route, Identity, Protocol로 우회할 수 있는가?
3. 결과를 볼 수 있는가? 정상 허용, 차단, 우회, 통제 비활성화를 구분할 수 있는가?
4. 신뢰 상태로 복구할 수 있는가? 공격이 성공하거나 통제가 정상 업무까지 막았을 때 안전한 상태로 돌아갈 수 있는가?

네 질문에 답하지 못하는 통제는 비용과 다이어그램 아이콘을 늘릴 수는 있어도 믿을 수 있는 방어 계층은 아니다.

3. Azure 서비스보다 책임 경계를 먼저 그린다

Defense in Depth는 각 Stack을 누가 책임지는지 확인하는 데서 시작한다. Cloud 공동 책임 모델에 따르면 Microsoft는 기반 Cloud Infrastructure를 보호하고, 고객의 책임은 서비스 모델에 따라 달라진다.

경계	IaaS 예시	PaaS 예시	고객에게 계속 남는 책임
물리 시설, Host, Hypervisor	Microsoft가 운영	Microsoft가 운영	Provider 범위를 이해하고 Workload 복원력을 설계
Guest OS와 Runtime	고객이 VM OS와 Runtime 운영	Microsoft가 더 많은 Stack 운영	서비스를 안전하게 구성하고 Platform이 관리하지 않는 범위 확인
Application	고객이 Code와 Configuration을 배포·운영	공동 책임: Microsoft는 Platform과 Runtime을 운영하고 고객은 배포한 Code와 Configuration을 책임	안전한 설계, Dependency, 인증, 권한 부여, 입력 처리
Identity와 Access	고객이 Role과 Access Path 관리	고객이 Role과 Access Path 관리	Account, MFA, Conditional Access, RBAC, 특권 접근, 정기 검토
Data	Workload의 고객 Data	Managed Service의 고객 Data	분류, 권한, 보존, 암호화 선택, Backup, 법적 의무

이 모델은 책임을 반씩 나누는 표가 아니다. 실제 Solution은 Virtual Machine, Managed Database, SaaS Administration, Third-party Service를 섞어 사용한다. 따라서 Workload 전체에 하나의 책임 구분을 일괄 적용하지 말고 Component별로 판단해야 한다.

책임 경계를 건너뛰면 두 가지 오류가 생긴다.

• “Azure에서 실행되므로 Microsoft가 Workload도 보호한다.” Microsoft는 Provider Layer를 보호하지만 고객의 RBAC를 선택하거나, 고객이 관리하는 Guest OS를 Patch하거나, Application 입력을 검증하거나, Data 보존을 승인하지 않는다.
• “내가 구성했으므로 모든 실패가 내 책임이다.” 고객이 Physical Host와 Hypervisor를 위한 통제를 새로 만들 필요는 없다. 해당 경계에서는 Provider Commitment, Service Health 정보, 가용성 기능 및 복구 전략을 이용해야 한다.

모든 계층 옆에 Owner를 적는다. Owner가 “Azure”라면 설계가 의존하는 Service Commitment 또는 Provider Capability를 적는다. 고객이라면 담당 Team, Configuration Source, Signal, Response Action을 적는다.

4. Defense in Depth, Zero Trust, Landing Zone은 서로 다르다

서로를 보완하지만 답하는 질문은 다르다.

개념	답하는 질문	위험한 축약
Defense in Depth	통제 하나가 실패했을 때 다음 공격 단계를 독립적으로 예방·탐지·격리하거나 복구하게 하는 것은 무엇인가?	“보안 제품을 더 배치한다.”
Zero Trust	이 Identity, Device, Workload 또는 Flow가 지금 이 작업을 수행하도록 어떤 근거로, 어느 정도의 최소 권한까지 허용할 것인가?	“Conditional Access를 켜면 완료다.”
공동 책임 모델	이 Component와 Service Model에서 Microsoft, 고객 또는 양쪽이 맡는 보안 작업은 무엇인가?	“Cloud Security는 Azure 책임이다.”
Azure Landing Zone	모든 Workload가 상속해야 할 조직 차원의 Platform 경계, 정책, 연결성, Logging, 책임 위임은 무엇인가?	“Accelerator를 배포하면 모든 Workload가 안전하다.”
Well-Architected Security	Reliability, Cost, Performance, Operations와 균형을 이루며 이 Workload의 Confidentiality, Integrity, Availability를 어떻게 보호할 것인가?	“Checklist를 한 번 통과한다.”

Microsoft의 Zero Trust 지침은 Verify Explicitly, Least Privilege, Assume Breach라는 세 원칙을 중심으로 한다. Defense in Depth는 이 결정을 적용할 경계와 계층을 제공한다. 두 개념을 직접 연결하는 원칙은 Assume Breach다. 첫 통제가 실패할 수 있으므로 다음 통제가 Blast Radius를 제한하고 새로운 판단이나 신호를 제공해야 한다.

Zero Trust는 Network 통제를 없애지 않는다. Network 위치만으로 암묵적으로 신뢰하지 않는다는 뜻이다. Private Network 안의 관리자도 검증된 Identity, 적절한 Device와 Session Context, 시간 제한 권한, 승인된 접근 경로, 감사 가능한 행동이 필요하다. 인증된 Identity나 Workload도 침해될 수 있으므로 Segmentation은 여전히 중요하다.

Azure Landing Zone은 Management Group 구조, Policy 상속, 중앙 Identity, Connectivity, Security Monitoring, Subscription 책임 위임 같은 조직 수준의 Guardrail을 만들 수 있다. 그러나 Application Code를 안전하게 만들거나, Data Permission을 선택하거나, 모든 Workload의 Incident Recovery를 대신 운영하지는 않는다. Platform Team이 안전한 도로와 Guardrail을 만들더라도 Workload Team은 차량을 설계하고 운전하며, 상태를 관찰하고 사고 후 복구해야 한다.

5. 일곱 계층을 보안 질문으로 읽는다

각 계층을 질문과 증적으로 바꾸면 훨씬 실용적이다.

계층	설계 질문	고객의 결정 또는 의존성	대표 증적
Physical/Provider	시설, Hardware, Physical Network, Virtualization Layer를 누가 보호하는가?	Service Model, Region·Zone 선택, Provider Commitment, 복구 가정	Service 문서, Architecture Decision, 복원력 Test
Identity and Access	누가 또는 무엇이 Azure Resource를 변경하고 Workload 기능에 접근할 수 있는가?	Microsoft Entra, RBAC, PIM, Managed Identity, Emergency Access	Sign-in 기록, Role Assignment, Activation 기록, Activity Log
Perimeter/Edge	신뢰하지 않는 Traffic이 Public Endpoint에 어떻게 도달하며 가용성을 어떻게 보호하는가?	Public 노출, DDoS 설계, HTTP Edge, Origin 제한	Endpoint Inventory, WAF·DDoS Metric, Origin 접근 Test
Network	Traffic이 진입하거나 Workload가 침해된 뒤 어디까지 이동할 수 있는가?	Segmentation, NSG, Route, Firewall, Private Connectivity, Egress Policy	Effective Route·Rule, Flow·Firewall Log, Deny Test
Compute	VM, Container, Host의 실행 환경을 어떻게 Hardening하고 관찰하는가?	Patch, Baseline, Endpoint Protection, Image Provenance, 관리 경로	Vulnerability 상태, Process Alert, Configuration 기록, Rebuild Test
Application	허용된 Protocol 안에 들어온 악성 요청을 Application이 어떻게 거부하는가?	인증, 권한 부여, 입력 검증, Dependency·Secret 처리, 안전한 Delivery	Test 결과, Application Event, WAF Correlation, Release 증적
Data	누가 최종 자산을 읽고, 변경하고, 반출하고, 삭제하고, 복구할 수 있는가?	Data-plane Permission, Encryption·Key 선택, Retention, Soft Delete, Backup	Access Log, Key Event, Delete Protection, Restore 결과

Monitoring과 Recovery는 일곱 계층 전체를 가로지른다. SIEM은 약한 통제를 자동으로 고치는 여덟 번째 벽이 아니다. 관측과 대응 Plane의 일부다. Backup도 Data Layer의 Checkbox로 끝나지 않는다. Backup의 Identity, Network Path, Key Dependency, Immutability, Restore Authority 자체에 계층형 설계가 필요하다.

하나의 Service가 여러 계층에 기여할 수도 있다. Key Vault는 Application Secret 처리와 Data Key Governance 양쪽에 연결된다. Azure Firewall은 Edge 또는 내부 Network Boundary에서 역할을 할 수 있다. Microsoft Defender for Cloud는 여러 Resource Type의 Posture와 Workload Protection Signal을 제공한다. 이 모델은 보안 질문을 정리하는 것이지 제품 하나를 계층 하나에 강제로 대응시키는 표가 아니다.

6. 공격 경로에서 설계를 시작한다

통제를 고르기 전에 다음 Worksheet를 작성한다.

보호할 자산:
노출·변조·중단 시 Business Impact:
공격자와 목표:
진입점:
넘어야 할 Trust Boundary:
공격 단계:
각 단계의 예방 통제:
관찰 가능한 신호:
격리 책임자와 목표 시간:
복구 경로와 증명 방법:
잔여 위험과 승인자:

이 Worksheet는 Business Impact, Technical Flow, Operations, Evidence를 연결한다. “Azure Security Service로 Data를 보호한다” 같은 문장은 여기서 구체성을 잃는다. 어떤 Data인가? 누구로부터 지키는가? 어떤 Identity나 Endpoint를 거치는가? 보호란 Confidentiality, Integrity, Availability 중 무엇을 의미하는가? 예방이 공격을 놓치면 어떻게 되는가?

중요한 Workload라면 최소 세 가지 공격 경로를 만든다.

1. 외부 공격자가 Public Application Path를 악용하는 경로
2. 침해된 Identity 또는 관리자가 Control Plane을 변경하는 경로
3. 침해된 Workload가 내부로 이동하거나 자신의 Data Permission을 악용하는 경로

세 경로는 서로 다른 계층을 시험하고, Perimeter 중심 Threat Model이 놓치는 공통 의존성을 보여준다.

7. 시나리오: Partner 문서 업로드 서비스

개인정보가 포함된 문서를 Business Partner로부터 받는 서비스를 가정한다. Public Edge는 HTTPS Upload를 받는다. Private Processing Workload가 허용된 Field를 추출해 Private Data Service에 기록한다. Processor는 Managed Identity를 사용한다. 관리자는 통제된 Private Management Path를 이용한다. Security Log와 Activity Log는 별도 Governance 범위로 전송한다. Recovery Copy에는 삭제 보호가 적용되고 Restore 절차를 시험한다.

외부 Partner
    │ 인증된 HTTPS Upload
    ▼
Public Application Edge
    │ 허용된 Application Flow
    ▼
Private Document Processor ── Managed Identity ──► Data Service
    │                                                │
    └──────── Workload·Security Signal ───────────────┤
                                                     ▼
Control Plane: Microsoft Entra ID + RBAC + Policy + Activity Log
Observation: Workload Log + Security Alert + Incident Workflow
Recovery: 신뢰할 수 있는 Source + 보호된 Backup + 재배포 절차

의도적으로 제품 이름을 최소화한 Diagram이다. Front Door, Application Gateway, Web Application Firewall, Azure Firewall, Private Link, Virtual Machine, Container 또는 Managed Application Service가 설계의 일부를 구현할 수 있다. 그러나 올바른 조합은 Protocol, Scale, Threat, Latency, Cost, 운영 역량에 따라 달라진다. 모든 Service를 추가한다고 자동으로 안전해지지 않는다.

다음 공격 흐름을 따라가 보자.

1. 공격자가 Partner Account를 탈취한다.
2. 정상 HTTPS를 사용해 악성 문서를 업로드한다.
3. Parser Vulnerability를 이용해 Processing Workload에서 Code를 실행한다.
4. 침해된 Processor가 내부 Endpoint를 탐색한다.
5. Processor의 Managed Identity로 필요한 범위를 넘어 문서를 읽으려 한다.
6. Network Rule을 변경하거나 Log Path를 억제하려 한다.
7. Data와 Recovery Copy를 파괴한 뒤 협박하거나 Data를 반출하려 한다.

하나의 Firewall로는 이 흐름을 설명할 수 없다. 처음 Traffic은 인증된 사용자가 허용된 Protocol로 보낸다. 다음 방어는 Application Validation과 Isolation, Workload Hardening, Identity Scope, Network Segmentation, Control-plane Authorization, 독립된 Logging, 보호된 Recovery에서 나와야 한다.

8. 모든 공격 단계를 운영 계약으로 바꾼다

공격 단계	예방·위험 감소	탐지	격리·복구	남길 증적	잔여 위험
Partner Account 탈취	강한 인증, 위험 기반 접근, 최소 권한, 짧은 Session	Risky Sign-in, 비정상 Device·Session, Upload 이상	Session 회수, Account 제한, Request Context 보존	Sign-in·Application Correlation ID, 대응 Timeline	탐지 전까지 정상 Session이 악용될 수 있음
악성 Upload	인증, File Type·Size Policy, Content Validation, 격리된 Processing	WAF·Application Event, Parser Error, Sandbox Signal	Object 격리, Processing 중지, 반복 Source 행동 차단	비식별 Request Metadata, File Hash, 탐지 결과	새로운 Payload가 기존 검사를 우회할 수 있음
Processor 침해	Hardened Image, Patch, 최소 Runtime, Endpoint Protection, 실행 제한	Process·Behavior Alert, Integrity 변경, 비정상 Outbound 연결	Workload 격리, Identity 회수, 신뢰 Source에서 Rebuild	Alert Timeline, Image Version, 변경 Resource Inventory	Zero-day가 탐지 전 실행될 수 있음
내부 이동	명시적 Route, Subnet Boundary, Private Endpoint, 좁은 East-west·Egress Rule	Denied Flow, Firewall Event, 비정상 DNS·Destination	Source Segment·Workload 격리, Destination Path 차단	Effective Route·Rule, 허용·차단 Flow Test	정상 Business Traffic이 악용될 수 있음
Workload Identity 기반 Data 접근	Resource별 Identity, 최소 Data-plane Role, Read·Write·Delete 분리	Data Access·Key Operation 이상	Role Assignment·Identity 회수, 의존 Material Rotation, 조사 범위 확정	Role Assignment, Access 기록, 변경 전후 Permission	승인된 Operation처럼 보이는 오용 가능
Control-plane 변경	PIM, 승인, Conditional Access, Policy Guardrail, Separation of Duties	Activity Log, Policy Drift, Role 변경 Alert	Session 비활성화, Known-good Configuration 복원, Emergency Process 실행	Activation 기록, Change Diff, Rollback 결과	Privileged Insider가 승인 경로를 악용할 수 있음
Data·Backup 파괴	별도 Recovery Authority, Soft Delete, 지원되는 Immutability, 보호된 Key·Backup Scope	Delete·Retention·Backup·Key Alert	파괴 권한 동결, 격리 범위로 Restore, Integrity 검증	Restore Test, Recovery Point·Time, 승인 기록	Recovery가 Business 허용 시간을 넘을 수 있음

이 표는 제품 Checklist가 아니라 운영 계약이다. 각 행을 Team에 배정하고 시험할 수 있다. 예방은 있지만 Signal이 없으면 통제 우회를 알 수 없다. Signal은 있지만 Owner나 격리 권한이 없으면 Detection은 알림 서비스에 그친다. Backup은 있지만 Restore 증적이 없으면 Recovery는 가정일 뿐이다.

9. 진짜 방어 계층인지 확인하는 다섯 가지 Test

9.1 독립성

두 통제가 같은 Identity, Configuration Source, Path, Region, Key 또는 Administrator에 의존하는지 확인한다. NSG와 중앙 Firewall은 서로 다른 지점에서 Filtering할 수 있다. 그러나 하나의 과도한 Automation Identity가 둘 다 비활성화하고 로그까지 지울 수 있다면 운영상 독립적이지 않다.

모든 통제에 다른 Vendor가 필요하다는 뜻은 아니다. Correlated Failure를 이해하는 것이 핵심이다. Role 분리, 보호된 Log Destination, Policy Enforcement, Change Approval, Recovery Ownership을 통해 하나의 Cloud Platform 안에서도 의미 있는 독립성을 만들 수 있다.

9.2 강제 지점

Policy Diagram이 실제 Packet Path를 증명하지는 않는다. 의도한 Traffic이 반드시 Enforcement Point를 지나가는지 확인한다.

• Application Edge를 우회해 Origin에 직접 접근할 수 있는가?
• Route가 Egress 또는 East-west Traffic을 의도한 Firewall로 실제 전달하는가?
• Private Endpoint가 있는데 불필요한 Public Endpoint도 함께 열려 있는가?
• Workload가 다른 Identity, Credential 또는 Data API를 사용할 수 있는가?
• Emergency Path가 보완 Monitoring 없이 모든 정상 승인을 우회하는가?

허용 Flow 하나와 가까운 차단 Flow 하나를 함께 시험한다. 성공한 Request는 Availability만 증명한다. Negative Test가 Broad Rule, Bypass Path, Shadowed Control을 드러낸다.

9.3 관측 가능성

각 통제에 대해 다음 네 상태를 관찰할 수 있어야 한다.

1. 정상적으로 허용된 활동
2. 통제가 차단한 활동
3. 통제를 우회하거나 회피한 활동
4. 통제가 비활성화·성능 저하·오구성된 상태

세 번째가 가장 어렵다. Bypass는 예상 Enforcement Point에 Log를 남기지 않을 수 있다. Identity, Control Plane, Network, Workload, Application, Data Event를 연결해야 한다. 불필요한 민감정보를 기록하지 않으면서도 조사에 필요한 Timestamp와 Correlation Identifier는 보존한다.

9.4 소유권

Alert Owner에게 행동할 권한과 맥락이 있어야 한다. 중앙 Security Team이 Application 이상을 탐지해도 안전하게 Processing을 멈추려면 Workload Team의 판단이 필요할 수 있다. Platform Team은 Firewall을 소유하지만 특정 Destination이 Business Critical인지 모를 수 있다. 사고 전에 의사결정 경로를 정한다.

다음을 기록한다.

• 누가 Alert를 접수하는가?
• 누가 Identity, Network, Workload, Data Access를 격리할 수 있는가?
• 각 결정의 목표 시간은 얼마인가?
• 위험한 예외는 누가 승인하는가?
• Business Owner에게 어떻게 알리는가?
• 복구된 상태를 신뢰할 수 있다고 누가 선언하는가?

9.5 복구 가능성

복구된 상태가 신뢰 가능함을 증명해야 Recovery가 보안 계층이 된다. 침해된 Image, 과도한 Role Assignment, 공격자가 장악한 Secret을 그대로 복원하면 사고도 함께 재현된다.

Recovery Test는 다음을 확인해야 한다.

• Recovery Copy가 존재하며 침해된 권한으로부터 보호되는가?
• 필요한 Key와 Identity가 복구 과정에서도 사용 가능한가?
• Infrastructure와 Application Artifact가 신뢰할 수 있는 Source에서 오는가?
• 복원한 Data가 Integrity와 Access Test를 통과하는가?
• Service 재개 전에 Network와 Monitoring이 동작하는가?
• Recovery Time과 Data Loss가 승인된 Business Tolerance 안에 있는가?

10. 공통 실패 지점은 여러 계층을 동시에 무너뜨린다

가장 위험한 약점은 제품 하나의 부재보다 서로 독립적이라고 생각했던 계층이 공유하는 하나의 의존성인 경우가 많다.

공통 의존성	여러 계층이 함께 실패하는 이유	더 나은 설계 질문
영구 권한을 가진 관리자 한 명	Identity, Network, Logging, Key, Recovery 설정을 모두 변경 가능	어떤 파괴적 작업에 시간 제한 권한, 승인 또는 별도 Authority가 필요한가?
광범위한 Managed Identity 하나	Processor 침해가 Data와 Control Access 전체로 확장	Read, Write, Delete, Management Permission을 분리하고 Resource Scope를 좁힐 수 있는가?
직접 접근 가능한 Public Origin	DDoS·WAF Edge Policy와 Telemetry를 우회	Origin 접근을 의도한 Service Path로 제한할 수 있는가?
같은 권한 경계의 Log	공격자가 Workload를 바꾸고 증적까지 삭제	중요 Telemetry를 별도 Governance Destination에 보존하는가?
삭제 가능한 Backup과 Key	파괴 권한이 Production과 Recovery를 함께 제거	Recovery Authority, Retention, 필수 Key를 독립적으로 보호하는가?
영구 예외	임시 Bypass가 실제 Production Policy로 고착	모든 예외에 사유, Owner, Scope, Expiry, Review Signal이 있는가?
하나의 Region, DNS Path, Certificate, Firewall	Security Dependency가 Availability Dependency가 됨	안전한 Degraded Mode와 검증된 Recovery Path는 무엇인가?
대응 권한 없는 Alert Owner	탐지는 하지만 격리가 지연	On-call Role과 Runbook에 제한된 Emergency Action 권한이 있는가?

“통제가 많을수록 항상 좋다”는 말이 틀릴 수 있는 이유도 여기에 있다. Inspection, Identity, Certificate, Route, Policy Dependency가 늘면 Latency, Cost, Failure State, 운영 부담도 늘어난다. Azure Well-Architected Security 원칙은 Reliability, Cost Optimization, Operational Excellence, Performance Efficiency와 함께 균형을 맞춰야 한다. 운영하지 못하는 고급 기능보다 위험에 맞고 반복 검증된 통제가 강하다.

11. 비용 없이 수행하는 Architecture Tabletop

Azure Resource를 만들기 전에 설계 논리를 시험할 수 있다.

1. 실제 또는 제안 Data Flow를 그린다. Control Plane, 관리자 경로, Telemetry, Recovery Path도 포함한다.
2. 중요한 자산 세 개를 표시하고 각 자산의 Confidentiality, Integrity, Availability 영향을 작성한다.
3. 모든 외부·내부 Trust Boundary를 표시한다.
4. Public Application 악용, Privileged Identity 침해, Compromised Workload 이동이라는 세 공격 경로를 그린다.
5. 모든 단계에 예방, Signal, 격리 Owner, Recovery Action, Residual Risk를 적는다.
6. 통제를 하나씩 제거한다. 남은 설계가 피해를 제한하고 공격 시도를 보여주는지 확인한다.
7. 공유 Identity, Route, Key, Region, Log Destination, Administrator를 찾는다.
8. 각 Enforcement Point에 Positive Test와 Negative Test를 하나씩 정의한다.
9. Evidence Artifact를 정의하고 보존·공개 전에 식별정보와 민감정보를 제거한다.
10. 미해결 Risk, 승인 Owner, Review Date를 기록한다.

기대 결과는 Azure Icon이 가득한 Diagram이 아니다. 중요한 모든 공격 단계에 독립적인 Decision, 관찰 가능한 Signal, 권한 있는 Owner, Recovery Path, 명시적으로 승인된 Residual Risk가 있는 Matrix다.

12. 증적이 증명하는 것과 증명하지 못하는 것

증적	뒷받침할 수 있는 주장	이것만으로는 증명하지 못하는 것
Architecture·Data-flow Diagram	범위, Component, Trust Boundary, 의도한 Path	Production Traffic이 실제 그 경로를 따름
Effective Route·Rule Export	현재 Enforcement Point의 Configuration	지속적인 운영, 다른 Path의 부재
Positive·Negative Flow Test	의도한 Flow 하나 허용, 의도하지 않은 Flow 하나 차단	모든 공격 차단
Sign-in·Activity·Security·Application Event	Event가 관찰 System에 도착	사람이 조사하고 격리했다는 사실
Incident Timeline	Exercise에서 Detection과 Response가 진행된 순서	재발 방지 완료
Restore Test	선택한 Recovery Point를 Test 조건에서 복원 가능	모든 Backup이 최신이며 완전하고 신뢰 가능
Owner·Review Date	책임과 유지 의도	통제 자체의 기술적 효과

좋은 증적은 주장을 반복 가능한 관찰에 연결한다. 기대 결과가 없는 Screenshot 열 장보다, 무엇을 시도했고 어디서 강제되며 어떤 Signal이 나와야 하고 실제로 무엇이 나타났으며 어떤 한계가 남았는지 기록한 Test 한 건이 강하다.

Public Learning Note에서는 Tenant Name, Subscription Identifier, Resource Identifier, Address, Account Detail, 보안상 민감한 Topology를 비식별 처리한다. 실제 환경의 Attack Map을 공개하지 않으면서도 방법은 증명할 수 있어야 한다.

13. 자주 나오는 여섯 가지 반론

“중앙 Firewall 하나면 충분하지 않은가?”

아니다. Firewall은 선택한 Network Flow를 강제할 수 있지만, 모든 Application Request를 검증하거나 Azure Control-plane Privilege를 관리하거나 모든 Data Permission을 제한하거나 Workload를 Patch하거나 Recovery를 증명하지 않는다. 전체 공격 경로 중 하나의 Enforcement Point다.

“Azure가 이미 전부 보호해 주지 않는가?”

Azure는 Provider Infrastructure를 보호하고 Security Capability를 제공한다. 고객 책임 경계 안의 노출, Identity, Role, Configuration, Application 동작, Data Policy, Monitoring Owner, Recovery는 고객이 결정하고 운영한다.

“Zero Trust를 쓰면 계층형 보안은 오래된 개념 아닌가?”

아니다. Zero Trust는 암묵적 신뢰를 거부하고 Access Decision을 안내한다. Defense in Depth는 잘못되거나 침해된 Decision 하나가 무제한 진행으로 이어지지 않게 한다. Identity가 Primary Perimeter라는 사실은 맞지만, Identity가 침해될 수 있기 때문에 Network, Workload, Application, Data, Detection, Recovery 계층이 필요하다.

“Data가 암호화되어 있으면 Data Layer는 끝난 것 아닌가?”

아니다. Encryption은 정의된 Key와 Access 조건에서 Confidentiality를 보호할 수 있다. 권한 있는 Identity의 Data Read, Application의 Plaintext 노출, Retention, Integrity, Key와 Backup의 파괴 가능성까지 해결하지는 않는다.

“모든 Log를 SIEM으로 보내면 Detection은 해결되지 않는가?”

아니다. 올바른 Source, 조사 가능한 Field, 시간 Correlation, Retention, Detection Rule, Tuning, Ownership, Response Authority, 검증된 Playbook이 필요하다. 대응 계약 없는 중앙 Log 수집은 Storage이지 Defense가 아니다.

“Posture Score가 높으면 안전하다고 볼 수 있지 않은가?”

아니다. Posture Finding은 Configuration 작업의 우선순위를 정하는 데 도움을 준다. Threat Modeling, Path Validation, Application Test, Negative Security Test, Incident Exercise, Restore Evidence를 대체하지 않는다. Score는 Risk Management의 입력이지 안전 인증서가 아니다.

14. Architecture Review Checklist

범위와 설계

• 중요한 자산과 Business Impact를 작성했다.
• Control-plane과 Data-plane Action을 구분했다.
• 외부·내부 Trust Boundary가 보인다.
• 현실적인 공격 경로를 최소 세 개 작성했다.
• Component별 Microsoft와 고객 책임이 명시되어 있다.
• 각 통제가 다른 Failure Condition을 줄이거나, 중복 이유가 문서화되어 있다.

강제와 관측

• 실제 Enforcement Point와 Traffic·Identity Path를 확인했다.
• 의도하지 않은 Public Endpoint, Route, Credential, Emergency Path가 통제를 우회하지 않는다.
• 허용 Test와 가까운 차단 Test를 모두 정의했다.
• 중요한 모든 공격 단계에 검색 가능한 Signal이 있다.
• 통제 비활성화와 Policy Drift를 관찰할 수 있다.
• 중요 Log가 Workload 침해 권한으로부터 보호된다.

운영과 복구

• Alert Owner가 사고를 격리할 맥락과 제한된 권한을 가진다.
• 예외에 사유, Scope, Owner, Expiry, Review Signal이 있다.
• Identity, Key, Route, Region, Log, Backup의 Common-mode Failure를 검토했다.
• Isolation, Rollback, Rebuild, Restore 절차에 Expected Result가 있다.
• Recovery가 Identity, Network, Monitoring, Data를 신뢰 상태로 되돌린다.
• Residual Risk와 승인 Owner를 기록했다.

15. 스스로 설명해 볼 질문

1. 보안 제품 세 개를 배치하는 것과 Defense in Depth의 차이는 무엇인가?
2. Administrator Identity가 침해되었을 때 Network Control이 줄일 수 있는 피해와 줄이지 못하는 피해는 무엇인가?
3. Web Application Firewall이 허용된 HTTPS Payload를 놓쳤을 때 Application과 Data Layer는 결과를 어떻게 제한해야 하는가?
4. NSG와 중앙 Firewall이 모두 있는데도 Segmentation이 실패할 수 있는 경로는 무엇인가?
5. 모든 Log가 하나의 Workspace에 있어도 Detection이 실패할 수 있는 이유는 무엇인가?
6. Encryption이 권한 있는 Identity의 Data Exfiltration을 막지 못하는 이유는 무엇인가?
7. 현재 설계에서 Identity, Route, Key, Region, Administrator 중 가장 큰 공통 실패 지점은 무엇인가?
8. 선택한 통제 하나를 제거하면 어떤 Residual Risk가 생기는가?
9. Architecture가 의도대로 동작한다는 것을 가장 강하게 보여주는 증적 세 개는 무엇인가?
10. Prevention이 실패하면 누가 Containment를 맡고, 복구 상태를 신뢰할 수 있다고 누가 선언하는가?

답이 Azure 제품 이름 하나로 끝난다면 다시 묻는다. 그 제품은 어떤 Attack Step, Enforcement Point, Signal, Owner, Recovery Action, Residual Risk를 담당하는가?

16. 한 페이지 기억 카드

Asset
→ Business Impact
→ Trust Boundary
→ Attack Path
→ Independent Control
→ Observable Signal
→ Containment Owner
→ Recovery Evidence
→ Residual Risk

마지막 기억 문장은 다음과 같다.

Defense in Depth는 한 번의 완벽한 차단을 약속하는 설계가 아니다. 공격자가 다음 단계로 이동할 때마다 별도의 신뢰 판단, 통제, 증적을 요구하는 설계다.

다음 Module 1 상세 노트에서는 우선 DDoS Protection 범위, DDoS IP Protection과 Network Protection 비교, Public IP 없는 VM, VNet·NSG 기초, Azure Firewall 설계·검증, JIT Access, Key Vault Key Lifecycle, Managed Disk Encryption을 포함한 주제를 다룬다. 각 글이 완성되기 전까지는 planned 상태이며 빈 URL을 만들지 않는다.

참고 자료

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Defense in Depth 설명
• Microsoft Learn: Cloud 공동 책임 모델
• Microsoft Learn: Zero Trust 개요
• Microsoft Learn: Azure Well-Architected Security 설계 원칙
• Microsoft Learn: Azure Well-Architected Security Checklist
• Microsoft Learn: Azure Landing Zone
• Microsoft Learn: Azure Landing Zone Security 설계 영역
• Microsoft Learn: Security Architecture 설계
• Microsoft Learn: Network Security와 Connectivity 전략
• Microsoft Learn: Microsoft Cloud Security Benchmark