모듈 2 복습: Azure 보안 관리

Coursera Azure Cybersecurity Solutions and Microsoft Defender 과정의 두 번째 단원은 Security management in Azure다. 개별 Network control을 넘어 cloud security 원칙, Microsoft Defender, Azure Bastion, Azure Policy와 표준, SIEM, Microsoft Sentinel 및 SOAR를 하나의 운영 체계로 연결한다.

이 단원의 중심 교훈은 보안이 한 번의 배포가 아니라 계속 반복되는 운영 loop라는 점이다. 조직은 원하는 상태를 정의하고, 일탈을 예방하거나 발견하고, 신뢰할 수 있는 signal을 수집하고, 중요한 activity를 조사하고, 통제된 방식으로 대응한 뒤, 결과를 다시 baseline에 반영해야 한다.

이 글은 강의 문장이나 quiz 답안을 옮긴 것이 아닌 독립적인 복습 교재다. 특정 수강자가 실습을 완료했다는 주장도 하지 않는다. 실습 부분은 개인 학습에 안전하게 사용할 수 있도록 목표·검증·증적 중심으로 다시 구성했다. 특히 Azure Blueprints와 Microsoft Sentinel portal은 강의 제작 후 상태가 달라졌기 때문에 2026년 8월 10일 공식 문서를 기준으로 보정했다.

1. 개별 통제에서 보안 관리 loop로

모듈 1이 Network path, 관리 port, encryption key를 어떻게 보호할지 물었다면, 모듈 2는 누가 표준을 정하고 여러 resource에 반복 적용하며 실패를 어떻게 알아내는지를 묻는다.

Asset과 owner를 발견한다
        ↓
원하는 상태를 정의한다
        ↓
Drift를 예방하거나 평가한다
        ↓
Security signal을 수집한다
        ↓
탐지하고 조사한다
        ↓
대응하고 복구한다
        ↓
교훈을 표준에 다시 반영한다

각 서비스는 loop의 서로 다른 지점을 담당한다.

기능	주된 역할	이것만으로 증명되지 않는 것
Microsoft Defender for Cloud	Posture 가시성, recommendation, workload protection	모든 recommendation이 해결됐거나 모든 유료 plan이 활성화됨
Azure Bastion	VM으로 가는 관리형 RDP/SSH 연결 경로	접속한 사용자가 VM 관리자여야 한다는 권한 판단
Azure Policy	원하는 resource 상태 평가와 선택적 강제·교정	Workload가 runtime 공격에서 안전함
Microsoft Sentinel	수집, 상관분석, 탐지, 조사, hunting, response orchestration	연결된 모든 log가 완전하고 유용함
SOAR automation	반복 가능한 response workflow 실행	모든 incident에서 자동 action이 안전함

초보자는 dashboard가 green이면 안전하다고 느끼기 쉽다. 그러나 coverage, owner, evidence와 failure test가 없는 green 상태는 운영 보증이 아니다.

2. Shared responsibility와 scope부터 적는다

Cloud security는 shared responsibility model을 따른다. Microsoft는 datacenter, host infrastructure와 각 service model에서 약속한 구성 요소를 운영·보호한다. 고객은 Identity privilege, data classification, network exposure, resource configuration, endpoint hygiene와 incident handling 같은 결정을 여전히 책임진다. 경계는 IaaS, PaaS, SaaS에 따라 달라진다.

Azure VM에서는 고객이 guest OS, installed software, account와 상당 부분의 network exposure를 관리한다. Managed PaaS database에서는 Microsoft가 아래 계층을 더 많이 관리하지만, 누가 query할 수 있는지, public access를 허용할지, 어떤 data를 넣을지는 고객이 결정한다. Managed service는 책임이 사라진다는 뜻이 아니라 책임 경계가 이동한다는 뜻이다.

Control을 선택하기 전에 scope를 네 차원으로 쓴다.

• Asset scope: 어느 tenant, management group, subscription, resource, identity, endpoint 또는 data set인가?
• Threat scope: misconfiguration, credential theft, malware, network intrusion, data exfiltration 또는 outage 중 무엇인가?
• Lifecycle scope: 예방, 탐지, 대응, 복구 중 어디에 속하는가?
• Operating scope: 구성, monitoring, exception 승인과 증적을 누가 소유하는가?

이 구분이 없으면 posture tool로 incident response coverage를 주장하거나, 실제 문제는 owner 없는 public endpoint인데 detection product부터 구매하는 식의 불일치가 생긴다.

3. Microsoft Defender 제품과 Portal을 정확히 구분한다

Defender는 하나의 제품이 아니라 제품군 이름이다. 무엇을 보호하는지로 구분하면 쉽다.

Microsoft Defender for Cloud

Microsoft Defender for Cloud는 cloud resource와 application lifecycle을 위한 CNAPP(Cloud-Native Application Protection Platform)다.

• CSPM(Cloud Security Posture Management): Resource inventory, security recommendation, secure score, regulatory view를 제공하고 plan에 따라 attack path와 cloud graph 같은 context를 확장한다.
• DevSecOps: Code와 pipeline context를 연결해 delivery 초기부터 risk를 찾고 줄이도록 돕는다.
• CWPP(Cloud Workload Protection Platform): Server, Storage, Database, Container, API 등 지원 workload별 Defender plan으로 active threat protection을 제공한다.

기본 posture 기능과 유료 workload plan은 coverage와 가격이 다르다. Defender for Cloud 화면을 열 수 있다고 Defender for Servers, Storage, SQL, Containers가 전부 켜진 것은 아니다. subscription × resource type × plan × extension/sensor 상태 × owner matrix를 유지해야 한다.

Secure score는 recommendation을 기반으로 한 우선순위 signal이지 침해가 없다는 인증서가 아니다. 많은 resource에 적용되는 쉬운 recommendation을 해결하면 score가 크게 오를 수 있지만, 소수의 business-critical asset에 남은 internet-facing attack path가 더 위험할 수 있다. Score를 asset criticality, exploitability, reachability, data sensitivity와 active threat context와 함께 평가한다.

Microsoft Defender XDR와 Microsoft Defender portal

Microsoft Defender XDR는 license된 service 범위에서 endpoint, identity, email, Microsoft 365 service와 SaaS app의 signal을 연결하고 incident로 상관분석한다. Microsoft Defender portal은 Defender XDR, Microsoft Sentinel 및 점차 확대되는 Defender for Cloud experience를 분석가가 함께 사용할 수 있는 통합 interface다.

Portal은 license가 아니다. 같은 URL에 접속해도 role, onboard된 product와 subscription에 따라 서로 다른 기능이 보일 수 있다. 강의에서 “Defender interface”라고 부르면 실제로 어느 workload, product와 portal인지 구체적으로 기록해야 한다.

Defender for Cloud: Cloud workload가 얼마나 노출되고 보호되는가?
Defender XDR:       User, device, email과 app을 가로지르는 공격 signal은 어떻게 연결되는가?
Defender portal:    활성화된 기능을 analyst가 어디에서 운영하는가?

흔한 오해

“Defender라는 이름이 같으니 하나를 사면 모두 포함된다.” 각 Defender plan과 Microsoft 365 entitlement가 다르다. Product family, portal, data source와 license를 한 줄에 섞지 않는다.

“Recommendation은 즉시 적용해도 된다.” Recommendation은 조사 시작점이다. Business context, dependency, service impact와 rollback을 확인해야 한다.

“Secure score 100%가 최종 목표다.” Applicability와 risk acceptance가 있는 실제 환경에서 숫자 최대화가 가장 좋은 risk reduction 순서와 같지 않을 수 있다.

4. Posture finding을 운영 결정으로 바꾼다

중요 recommendation마다 다음 과정을 수행한다.

1. Resource, subscription, environment와 owner가 정확한지 확인한다.
2. Recommendation logic을 읽고 resource가 실제 applicable한지 확인한다.
3. Criticality, internet exposure, data, dependency 및 retire 계획을 추가한다.
4. 대표적인 nonproduction scope에서 remediation을 시험한다.
5. 기대하는 risk reduction, workload 영향, 비용, rollback과 증적을 기록한다.
6. 가능하면 정상 IaC와 deployment pipeline을 통해 변경한다.
7. Recommendation 재평가와 별개로 의도한 control을 직접 test한다.

예를 들어 “management port를 닫으라”는 finding의 해법은 deny rule 하나가 아니라 Public IP를 없애고 Bastion을 도입하는 것일 수 있다. “Storage public access를 차단하라”는 항목은 enforcement 전에 Private Endpoint, private DNS와 application routing 변경이 필요할 수 있다. Context 없이 대량 ticket을 만들면 alert fatigue와 위험한 일괄 변경이 생긴다.

좋은 finding record에는 다음이 들어간다.

finding ID | asset | owner | severity + business context | decision
change ID  | test evidence | rollback | due date | residual-risk approver

적용하지 않는 경우 not applicable, 기간이 있는 exemption, 공식 risk acceptance, 또는 검증된 compensating control 중 무엇인지 남긴다. 아무 기록도 없는 상태는 risk decision이 아니다.

5. Azure Bastion은 VM 관리 경로를 보호한다

Azure Bastion은 TLS를 통해 VM에 RDP와 SSH 연결을 제공하는 managed PaaS다. 일반적인 배포에서는 VM의 Private IP로 연결하므로 대상 VM에 Public IP, agent 또는 인터넷에 열린 RDP/SSH inbound가 필요하지 않다. SKU에 따라 Portal browser client 또는 지원되는 native client를 사용할 수 있다.

위협 시나리오는 명확하다. Public IP와 열린 RDP가 있는 VM은 계속 scan된다. Password가 강해도 exploit, credential spraying과 대량의 보안 noise에 노출된다. Bastion은 연결 지점을 중앙화하고 각 VM의 public management endpoint를 제거한다.

하지만 Bastion이 관리 권한까지 자동으로 안전하게 만드는 것은 아니다.

• Azure RBAC는 관련 Azure resource 사용 권한을, guest OS authorization은 실제 VM login 권한을 관리한다.
• 관리 Identity에는 적용 가능한 Microsoft Entra Conditional Access와 MFA가 필요하다.
• NSG, route, DNS와 전용 Bastion subnet은 지원 requirements를 따라야 한다.
• Platform, session 및 guest log를 어디에 얼마나 보관할지 정해야 한다.
• VM의 patch, endpoint protection, least privilege와 credential hygiene는 그대로 필요하다.
• Bastion이나 region/network 장애 시 emergency access 방법을 별도로 설계해야 한다.

관리 접속 방식 비교

방식	바꾸는 것	적합성을 검토할 상황	남는 위험
Public IP + 상시 RDP/SSH	인터넷 도달성을 제한하지 않음	기본값으로 피해야 함	영구 공격 표면
Public IP + JIT	Source와 노출 시간을 제한	임시 inbound가 불가피한 legacy/제약 환경	Public path와 Plan 2/topology dependency
Azure Bastion	VM public management endpoint를 제거하고 연결 중계	Azure VM을 위한 중앙 관리 경로	Bastion 비용, Identity, Network, Log, resilience
VPN/ExpressRoute + private access	관리자를 private network path에 연결	더 넓은 hybrid/private 운영	Client trust, routing, lateral movement 통제 필요

Bastion은 경로를, JIT는 노출 시간과 요청 권한을 주로 다룬다. 완전히 경쟁하는 기능으로만 보지 않는다. Threat model, 관리자 수, 연결 구조, 가용성 목표, 기능 및 비용에 따라 고른다.

2026년 현재 Bastion에는 Developer, Basic, Standard, Premium SKU가 있고 architecture와 기능이 다르다. Premium은 private-only deployment를 지원한다. 강의 화면을 그대로 따라가기보다 현재 region과 feature requirement를 확인한다.

단계별 설계와 검증

1. VM에서 Public IP를 제거할 수 있는지 먼저 검토한다.
2. 관리자의 위치, client 방식, file transfer 등 필요한 기능으로 SKU를 고른다.
3. 지원되는 subnet, Public IP 또는 private-only topology와 NSG rule을 문서화한다.
4. Azure role과 guest account를 최소화하고 MFA/Conditional Access 적용 범위를 확인한다.
5. 승인 Identity의 성공과 비승인 Identity의 실패를 모두 시험한다.
6. 접속과 guest activity가 예상 log에 남는지 확인한다.
7. Bastion 장애, region 장애, credential 분실 시 recovery 절차를 table-top test한다.

6. Azure Policy는 원하는 Resource 상태를 표현한다

Azure Policy는 Resource를 definition과 비교해 평가하고 구성된 effect를 적용한다.

Definition:  condition + effect
Initiative:  하나의 목표를 위한 여러 definition 묶음
Assignment:  definition/initiative를 parameter와 함께 scope에 적용
Evaluation:  applicable resource의 compliance state 계산
Remediation: modify/deployIfNotExists gap을 task로 교정
Exemption:   적용 대상이지만 공식 사유와 metadata로 예외 처리

Definition은 management group이나 subscription에 저장된다. Definition location 아래의 scope에 assignment할 수 있다. Assignment는 management group, subscription, resource group 또는 resource에 적용되고, 하위 scope로 상속된다. Exclusion, exemption, resource selector와 applicability condition이 실제 평가 범위를 바꾼다.

Effect는 서로 다른 운영 결정이다

• audit, auditIfNotExists: Request를 막지 않고 gap을 보고한다.
• deny: 조건에 맞지 않는 create/update request를 차단한다.
• modify: 지원되는 request property를 바꾸고 필요한 Identity와 remediation task로 기존 resource를 교정할 수 있다.
• deployIfNotExists: 평가 후 관련 구성을 배포할 수 있으며 기존 resource 교정에는 Identity와 task가 필요하다.
• disabled: Initiative 안의 특정 definition을 assignment에서 비활성화한다.

Non-compliant가 resource 중단을 의미하지는 않으며, Compliant도 runtime attack에서 안전함을 증명하지 않는다. Compliance는 해당 evaluation cycle에서 적용 가능한 resource가 policy rule을 충족했는지를 뜻한다.

인접 통제와 구분하기

통제	답하는 질문
Azure Policy	Resource 상태를 허용·요구·보고할 것인가?
Azure RBAC	어느 Identity가 이 scope에서 어떤 control-plane action을 수행할 수 있는가?
Resource lock	일반 RBAC가 허용하더라도 실수로 delete/change하는 것을 막을 것인가?
Defender for Cloud recommendation	어떤 posture/workload risk를 조사하고 우선 처리할 것인가?

Policy는 Public IP 구성을 deny할 수 있지만 VM 사용자를 인증하지 않는다. RBAC는 Contributor에게 Storage Account 배포 권한을 주고, Policy는 허용 region과 public-access 상태를 제한할 수 있다. 서로 교차하지만 대체하지 않는다.

7. Policy를 장애 없이 단계적으로 적용한다

좋아 보이는 rule을 관찰 없이 넓은 scope에 강제하면 정상 deployment를 막을 수 있다.

1. Intent와 owner를 작성한다. Threat/standard, resource type, desired state, exception authority와 success metric을 명시한다.
2. 요구와 맞는 built-in을 우선 검토한다. Custom definition은 test와 version 유지 책임을 만든다.
3. Alias와 mode를 확인한다. Resource provider가 평가할 property를 제공하는지, all과 indexed 중 무엇이 맞는지 검증한다.
4. 대표 pilot scope에서 시작한다. Test subscription이나 좁은 resource selector를 사용한다. Deny 가능 effect도 enforcement를 끄고 먼저 평가할 수 있다.
5. 기존·신규 resource를 관찰한다. Policy 평가는 항상 즉시 끝나지 않는다. Applicability, conflict와 false positive를 기록한다.
6. Remediation prerequisites를 준비한다. modify, deployIfNotExists에는 적절한 managed identity 권한이 필요하고 기존 resource에는 보통 remediation task가 필요하다.
7. Pipeline을 시험한다. 예상하지 못한 deny는 IaC release를 중단한다. 넓게 강제하기 전에 template이 required state를 만들도록 수정한다.
8. 숨은 workaround 대신 exemption을 정의한다. Category, owner, justification, compensating control, expiry와 review date를 남긴다.
9. 단계적으로 enforce하고 deny를 monitoring한다. Rollback 권한과 incident route를 준비한다.

강한 증적에는 versioned definition 또는 built-in version, assignment scope/parameter, enforcement mode, exclusion, exemption, compliance export, remediation result, deny test, pipeline test와 change approval이 포함된다.

Policy의 흔한 오해

“Policy가 과거 resource도 자동 수정한다.” Audit는 보고만 한다. modify와 deployIfNotExists도 정해진 동작, Identity permission과 기존 resource용 remediation task가 필요하다.

“Exclusion과 exemption은 같다.” Excluded scope는 평가에서 빠지고 compliance 화면에서 applicable exempt resource처럼 보이지 않는다. Exemption은 예외 이유와 governance context를 유지한다.

“Regulatory initiative가 compliant면 인증이 끝난다.” 기술 resource의 평가를 standard control과 mapping한 것이다. 사람, 절차, data handling, Azure 밖의 통제와 감사 증적은 별도다.

8. 2026년 필수 보정: Azure Blueprints는 은퇴 중이다

강의는 Azure Blueprints를 소개하지만 이제는 lifecycle을 반드시 함께 설명해야 한다. Azure Blueprints retirement 안내에 따르면 Preview service는 2027년 1월 31일 은퇴하며 2026년 7월 31일부터 단계적 제한이 시작됐다. 이 글의 작성일에는 새 blueprint definition과 version을 더 이상 만들 수 없다. 2026년 후반에 modification과 새 assignment 제한이 이어진다.

새 governance platform을 Blueprints에 의존해 설계하지 않는다. Microsoft 권장 migration은 기존에 한 서비스가 하던 일을 나눈다.

• Deployment definition을 Template Specs 또는 Git에 저장하고 version 관리한다.
• Grouped resource lifecycle과 필요한 deny-assignment 방식 보호에는 Azure Deployment Stacks를 사용한다.
• Desired-state 평가와 enforcement에는 계속 Azure Policy를 사용한다.

기존 사용자는 definition과 assignment inventory, source와 parameter export, artifact별 대체 기술 mapping, lock/lifecycle 의미의 test를 거쳐 최종 은퇴 전에 migration해야 한다. 일반적인 architecture 의미의 “blueprint”와 은퇴 중인 Azure Blueprints resource provider를 구분한다.

9. SIEM은 Telemetry를 조사 가능한 사건으로 바꾼다

SIEM(Security Information and Event Management)은 여러 source의 security data를 수집하고 분석한다. Microsoft Sentinel은 cloud-native SIEM이자 unified security platform으로, multicloud/multiplatform data collection, analytics, incident investigation, hunting, threat intelligence 및 response automation을 지원한다.

Source telemetry
  → connector / collection path
    → query 가능한 data와 normalization
      → analytics/detection rule
        → alert
          → 상관분석된 incident
            → investigation과 response

화살표마다 실패 지점이 있다. Connector가 configured여도 table에 최근 record가 없을 수 있다. Query가 실행돼도 field를 잘못 골라 실제 공격을 놓칠 수 있다. Alert가 발생해도 incident grouping이 잘못되어 noise가 될 수 있다. 정확한 incident도 owner가 없으면 대응되지 않는다. 따라서 SIEM onboarding은 connector 작업이 아니라 data quality와 operating model 설계다.

각 source마다 다음을 기록한다.

• Owner, environment와 구체적인 security use case
• 인증 방식과 least-privilege collection permission
• 예상 table, event type, daily volume과 latency
• Parser 또는 normalization dependency
• Retention과 archive requirement
• 비용 추정과 daily-volume alert
• Heartbeat 또는 last-event-received health check
• 실제 data를 사용하는 detection, hunting, investigation 목록

모든 log를 무기한 모으는 것은 성숙도가 아니다. 사용처 없는 high-volume data는 비용과 analyst noise를 늘린다. 반대로 Identity와 control-plane record를 너무 빨리 삭제하면 incident timeline을 복구할 수 없다. Retention을 명시적인 탐지·조사·규제 요구와 연결한다.

연결되었다는 것과 유용하다는 것의 차이

Connector 화면의 green icon은 시작일 뿐이다. 최근 event timestamp, 예상 event와 실제 schema 비교, parser health, analytics rule hit, alert-to-incident grouping, analyst가 사건을 재구성할 수 있는지까지 검증해야 한다. Data source owner가 configuration을 바꿨을 때 SOC에 알리는 change path도 필요하다.

10. SOAR는 통제된 대응을 자동화한다

SOAR(Security Orchestration, Automation, and Response)는 도구를 연결하고 반복 가능한 workflow를 수행한다. Sentinel에서 automation rule은 incident triage와 관리를 수행하거나 playbook을 실행할 수 있다. Playbook은 Azure Logic Apps와 connector로 더 넓은 action을 수행한다.

초기에 자동화하기 좋은 작업은 deterministic하고 되돌리기 쉽다.

• Incident에 asset owner와 criticality를 enrichment한다.
• 알려진 rule에 따라 tag와 investigation task를 추가한다.
• 안정적인 incident link를 on-call channel에 알린다.
• Human decision 전에 volatile evidence를 수집한다.
• 엄격히 시험된 조건에서 확실한 duplicate를 처리한다.

High-impact containment에는 더 강한 guardrail이 필요하다. 임원 account 비활성화, production server isolation, shared IP 차단, 넓은 session revoke는 정상 운영을 중단하거나 공격자가 DoS를 유발하는 수단이 될 수 있다. 적절한 approval, 좁은 permission, idempotent action, timeout, retry limit, audit log와 test된 rollback을 둔다.

Playbook은 production code다. Version 관리하고 connector identity를 review하며 secret을 workflow에 직접 넣지 않는다. Failure branch와 partial success를 test하고 run을 monitoring하며 deployment control과 owner를 둔다. Automated는 accountable하지 않다는 뜻이 아니다.

SIEM은 security data 중 무엇을 조사할지 결정하고,
SOAR는 결정된 대응을 반복 가능한 절차로 조정한다.

11. Microsoft Sentinel의 현재 Portal 방향

오래된 학습 자료는 Sentinel을 Azure Portal에서 보여 주는 경우가 많다. 2026년 Microsoft는 Sentinel 운영을 Microsoft Defender portal로 옮기고 있으며, Sentinel incident를 다른 Defender signal과 통합할 수 있다.

일정을 정확히 말해야 한다. Microsoft 공식 문서에 따르면 2027년 3월 31일 이후 Sentinel은 Azure Portal에서 더 이상 지원되지 않고 Defender portal에서만 제공된다. 따라서 2026년 8월 현재 “Azure Portal Sentinel이 이미 모두 종료됐다”고 말하는 것은 틀리고, migration을 미뤄도 된다고 보는 것도 위험하다.

Portal마다 navigation과 일부 capability 차이가 있으므로 URL만 바꾸는 작업이 아니다. Team은 analyst workflow, role, bookmark, automation, incident queue와 training을 inventory하고 전환을 검증해야 한다. 2025년 7월 이후 신규 customer의 first workspace onboarding은 permission과 tenant 조건에 따라 Defender portal 자동 연결 동작도 바뀌었다. 정확한 제약과 menu mapping은 현재 Sentinel in the Defender portal 문서를 확인한다.

12. 하나의 위협 시나리오로 전체 통제를 연결한다

작은 Platform team이 관리하고 SOC가 monitoring하는 Developer VM을 생각해 보자.

1. Azure Policy가 VM Public IP pattern을 audit/deny하고 필요한 diagnostic setting을 요구한다.
2. VM은 Private IP만 사용하고 Azure Bastion이 관리 연결을 중계한다.
3. Azure RBAC와 guest OS role이 연결 시작 권한과 login 권한을 각각 제한한다.
4. Defender for Cloud가 posture를 평가하고, 활성화된 workload plan이 관련 alert를 만든다.
5. Log가 monitoring되는 connector를 통해 Sentinel로 흐른다.
6. Analytics rule이 비정상 sign-in과 host activity를 하나의 incident로 연결한다.
7. Automation rule이 incident를 담당자에게 배정하고 owner/criticality를 enrichment한다.
8. Analyst가 영향 범위를 확인한 뒤 high-risk containment playbook 실행을 승인한다.
9. Post-incident review가 Policy baseline, access architecture, detection 또는 playbook을 개선한다.

이 흐름에서 Policy는 resource state를, Bastion은 path를, RBAC/host는 사람의 권한을, Defender는 posture/workload signal을, Sentinel은 evidence correlation을, SOAR는 승인된 workflow를 담당한다. 하나가 나머지를 대체하지 않는다.

13. 반복 학습을 위한 안전한 실습 패턴

다음 항목은 완료 기록이나 평가 답안이 아니다.

실습 A: Bastion으로 VM 보호

목표: Public management path와 private management path의 차이를 검증한다.

격리된 subscription/resource group에서 대상 VM address, NSG, route와 login model을 먼저 문서화한다. 현재 subnet 및 public/private requirement를 확인해 적절한 Bastion SKU를 고른다. Target VM에 Public IP가 없는지 확인하고 승인된 Identity의 connection 성공과 비승인 Identity/path의 실패를 모두 시험한다. Credential이나 민감한 화면 내용은 증적에 남기지 않는다.

증적: Sanitized diagram, role assignment, effective network rule, 성공/실패 test matrix, log timestamp, 비용과 cleanup record.

실습 B: Azure Policy pilot assignment

목표: Definition, assignment, evaluation, enforcement와 remediation을 구분한다.

Lab scope에서 allowed location 또는 tag audit처럼 영향이 작은 built-in을 고른다. Rule과 alias를 읽고 넓은 enforcement 없이 assignment한다. 기준을 만족하는 resource와 만족하지 않는 test resource를 하나씩 만들고 compliance latency를 관찰한다. Effect가 remediation을 지원하면 자동으로 고쳐질 것이라 가정하지 말고 Identity와 task를 확인한다.

증적: Definition version, parameter, scope, enforcement mode, test resource, compliance timestamp, exception 판단과 cleanup.

실습 C: 최소 Sentinel use case 설계

목표: 유용한 signal 하나를 source health부터 incident response까지 추적한다.

Low-volume supported source와 명확한 detection goal 하나를 고른다. 연결 전 ingestion을 추정하고 bounded query로 최근 data와 field를 확인한다. Use case에 필요한 content만 활성화한다. 실제 공격을 만들지 말고 승인된 benign event 또는 vendor가 문서화한 simulation method로 test한다. 개인 lab에 production secret이나 개인 data를 ingest하지 않는다.

증적: Source owner, connector health, last-record timestamp, query, alert/incident 관계, response task, automation run result, retention과 cost.

모든 실습에서 synthetic name/data, budget, least privilege와 cleanup 일정을 사용한다. Bastion, Public IP, Log Analytics workspace, connector, Logic App, managed identity 및 유료 Defender plan을 각각 확인한다. VM 삭제만으로 모든 dependent 유료 resource가 없어지지 않는다.

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

기능	주요 비용/Entitlement 요인	기록할 결정
Defender for Cloud	보호 resource/workload별 활성 plan 및 feature dependency	어느 subscription/resource type에 기본 CSPM 또는 유료 plan이 필요한가?
Azure Bastion	SKU, 실행 기간, scale/feature와 관련 network	VM별 노출보다 shared path가 적합한가? 어떤 가용성이 필요한가?
Azure Policy	평가 자체보다 remediation이 생성하는 billable resource	deployIfNotExists가 만든 resource 비용을 누가 부담하고 deny를 누가 처리하는가?
Microsoft Sentinel	Ingestion, retention, data lake/analytics 선택, query, automation	어느 use case가 각 source와 retention을 정당화하는가?
Logic Apps/playbook	Trigger/action 실행, connector와 integration service	어느 action에 승인이 필요하고 retry/rollback은 무엇인가?

Architecture 문서에 가격 숫자를 고정하면 빠르게 낡는다. Meter와 usage assumption을 기록한 뒤 승인 직전에 공식 pricing, license terms, region availability와 calculator를 다시 확인한다. Lab에서는 유료 plan이나 계속 실행되는 service를 켜기 전에 budget과 cleanup calendar reminder를 둔다.

15. 운영 체크리스트

• 모든 security control에 asset scope, threat, owner와 failure response가 있다.
• Defender for Cloud 기본 기능과 유료 plan coverage를 subscription/resource type별로 inventory했다.
• Secure score를 인증서처럼 사용하지 않고 asset context로 우선순위를 정했다.
• Defender for Cloud, Defender XDR, Defender portal 및 Sentinel을 정확히 구분한다.
• 문서화된 예외가 아니라면 VM에 public management endpoint가 없다.
• Bastion SKU, Identity path, Network, Log, resilience와 비용을 검증했다.
• Policy intent, definition version, scope, parameter, enforcement mode와 exemption을 version 관리한다.
• 넓은 rollout 전에 deny/remediation과 deployment pipeline을 함께 시험했다.
• 새 governance design이 은퇴 중인 Azure Blueprints에 의존하지 않는다.
• 모든 Sentinel source에 use case, health check, volume, retention과 owner가 있다.
• Analytics가 severity, grouping, assignment 및 response step이 있는 actionable incident를 만든다.
• Playbook은 least privilege, bounded retry, high-impact approval과 rollback을 갖는다.
• 2027년 Azure Portal 지원 종료 전에 portal transition workflow를 시험한다.
• 비용 계산에 visible VM뿐 아니라 log, automation과 dependent resource를 포함한다.

16. 스스로 설명해 볼 질문

1. Azure VM과 managed PaaS Database의 shared responsibility는 어떻게 다른가?
2. Defender for Cloud, Defender XDR와 Defender portal의 차이는 무엇인가?
3. Secure score가 올라도 critical attack path가 남을 수 있는 이유는 무엇인가?
4. Bastion이 줄이는 위험과 여전히 남는 Identity/host 위험은 무엇인가?
5. Bastion과 JIT는 각각 path와 time 중 어떤 차원을 주로 통제하는가?
6. Policy definition, initiative, assignment와 remediation task는 어떻게 연결되는가?
7. Deny policy를 observation과 pipeline test부터 시작해야 하는 이유는 무엇인가?
8. Exclusion과 exemption의 governance 차이는 무엇인가?
9. 2026년 8월 새 설계에서 Azure Blueprints를 피해야 하는 이유는 무엇인가?
10. Sentinel connector가 단지 configured된 것이 아니라 유용하다는 사실을 어떻게 증명하는가?
11. 승인 없이 자동화해도 되는 response와 human approval이 필요한 response는 어떻게 구분하는가?
12. Azure Portal에서 Defender portal로 analyst workflow를 옮기기 전에 무엇을 시험해야 하는가?

마지막 기억 지도

Defender for Cloud는 posture와 workload risk를 본다.
Bastion은 VM 관리 경로를 통제한다.
Policy는 resource 상태를 정의하고 평가한다.
Sentinel은 telemetry를 investigation으로 바꾼다.
SOAR는 승인된 결정을 반복 가능한 action으로 바꾼다.

각 문장을 threat scenario, scope, owner, evidence, cost와 failure behavior로 설명할 수 있다면 모듈 2는 Azure menu 소개가 아니라 반복 사용할 수 있는 운영 모델이 된다.

참고 자료

• Coursera: Azure Cybersecurity Solutions and Microsoft Defender
• Microsoft Learn: Microsoft Defender for Cloud 개요
• Microsoft Learn: Microsoft Defender XDR in the Defender portal
• Microsoft Learn: Azure Bastion 개요
• Microsoft Learn: Azure Policy 개요
• Microsoft Learn: Azure Policy definition structure
• Microsoft Learn: Azure Blueprints 은퇴
• Microsoft Learn: Azure Blueprints를 Template Specs로 migration
• Microsoft Learn: Microsoft Sentinel 개요
• Microsoft Learn: Microsoft Sentinel in the Microsoft Defender portal