모듈 3 복습: Microsoft Defender 위협 신호를 하나의 사건으로 연결하기

Coursera의 Azure Cybersecurity Solutions and Microsoft Defender 과정에서 Module 3의 제목은 “Microsoft 365 Defender threat protection”이다. 공개된 강의 구성은 Defender Portal과 Incident에서 출발해 Endpoint Security, Identity Defense, Information Protection으로 범위를 넓히고, Microsoft Sentinel에 Microsoft Defender Data Connector를 연결하는 연습으로 이어진다.

이 글은 강의 목차를 다시 나열하는 짧은 후기가 아니다. 시간이 지난 뒤에도 반복해서 참고할 수 있도록 각 제품이 어떤 위협을 줄이고, 어떤 신호와 증적을 만들며, 어디까지 책임지는지를 하나의 운영 흐름으로 재구성한 복습 교재다. 강의에 남아 있는 이전 제품명은 현재 Microsoft 명칭으로 바로잡았다.

다만 이 글은 실제 Production Tenant에 기능을 배포했다는 기록도, 강의의 모든 Exercise를 완료했다는 주장도 아니다. 평가 문제와 정답도 재현하지 않는다. License, Portal 화면, 지원되는 Connector와 Table은 계속 변할 수 있으므로 실제 도입 전에는 최신 공식 문서와 조직의 계약을 확인하고, 승인된 Lab에서 먼저 검증해야 한다.

1. 가장 먼저 기억할 문장: 제품이 아니라 공격 경로를 보호한다

현실의 공격은 한 제품 안에서 시작하고 끝나지 않는다. 예를 들어 사용자가 Phishing Mail의 Link를 누르면 다음 흐름이 이어질 수 있다.

악성 메일 수신
  -> Token 또는 Credential 탈취
  -> 평소와 다른 Sign-in
  -> Endpoint에서 의심스러운 Process 실행
  -> Directory 권한 상승과 Lateral Movement
  -> Cloud Workload 또는 중요 Data 접근
  -> 외부 공유 또는 반출 시도

각 단계는 서로 다른 보안 제품에서 Alert를 만들 수 있다. Mail, User, Device, IP Address, Process, Application, Cloud Resource, File이라는 Entity도 서로 다르다. Analyst가 각각의 Alert를 별개의 Ticket으로만 처리하면 Alert 수는 늘어나지만 공격 전체의 이야기와 영향 범위는 보이지 않는다.

Microsoft Defender XDR의 핵심 가치는 Microsoft 보안 영역의 신호를 서로 연관시켜 Incident, 즉 조사 가능한 사건 단위로 만드는 데 있다. Alert는 특정 탐지 규칙이 반응했다는 사실이고, Incident는 관련 Alert와 Entity, Timeline, Evidence를 묶어 “누가, 어떤 Device와 Mailbox를 거쳐, 무엇을 시도했는가”를 설명해야 한다.

반복해서 기억할 운영 순서는 다음과 같다.

노출 감소 -> 의심 행위 탐지 -> 신호 상관분석 -> 범위 조사
        -> Containment와 Remediation -> 증적 보존 -> 통제 개선

여기서 “통합”은 모든 제품이 하나의 제품이 되었다는 뜻이 아니다. 서로 다른 Sensor와 Control Plane이 같은 공격 이야기에 기여한다는 뜻이다.

2. 강의의 옛 이름을 현재 이름으로 번역한다

제품명 변경을 놓치면 검색 결과, License, Architecture Diagram, Portal 위치가 서로 다른 것처럼 보일 수 있다. 다음 표는 강의의 역사적 표현과 현재 표현을 연결한다.

강의 또는 이전 문서의 이름	현재 이름	현재 관점에서 기억할 역할
Microsoft 365 Defender	Microsoft Defender XDR	여러 보안 영역의 탐지, Incident 상관분석, 조사와 대응
Microsoft 365 Defender portal	Microsoft Defender portal	security.microsoft.com의 통합 Security Operations 경험
Azure Defender	Microsoft Defender for Cloud	Cloud Posture, DevSecOps, Workload Protection을 묶은 CNAPP
Azure Advanced Threat Protection	Microsoft Defender for Identity	Identity 기반 공격의 탐지, 조사, 대응 Context
Azure Active Directory	Microsoft Entra ID	Cloud Identity와 Access Service
Azure AD Identity Protection	Microsoft Entra ID Protection	User Risk와 Sign-in Risk 탐지 및 Risk 기반 Access 제어
Azure Information Protection	Microsoft Purview Information Protection 기능	Sensitive Data 발견, 분류, Label, Encryption, 보호
Microsoft Cloud App Security	Microsoft Defender for Cloud Apps	SaaS 가시성, App Control, Cloud App 위협 보호

이 표를 기계적인 “찾아 바꾸기” 목록으로 사용해서는 안 된다. 제품은 이름만 바뀐 것이 아니라 기능, Portal, License Package, Integration 범위가 계속 진화했다. 설계서에는 Suite 이름만 적지 말고 “Defender for Endpoint EDR를 어느 Device에 Onboarding한다”, “Entra ID Protection의 Sign-in Risk를 Conditional Access에 사용한다”처럼 실제 Capability와 Scope를 적어야 한다.

3. Defender XDR와 Defender for Cloud의 경계를 먼저 그린다

Module 3에서 가장 자주 생기는 혼동은 이름에 Defender가 포함된 제품을 모두 같은 것으로 보는 것이다.

Microsoft Defender XDR

Defender XDR는 Endpoint, Identity, Email과 Collaboration, Cloud App 등 사용자 중심 Attack Surface의 Security Operations에 초점을 둔다. Defender for Endpoint, Defender for Identity, Defender for Office 365, Defender for Cloud Apps 등의 신호를 Incident로 연관시키고, Analyst가 Timeline, Entity Page, Evidence, Advanced Hunting, Automated Investigation and Response를 이용해 조사하도록 돕는다.

핵심 질문은 다음과 같다.

• 이 User, Device, Mailbox, Application에 걸친 활동이 하나의 공격인가?
• Attack Chain의 시작점과 현재 영향 범위는 어디인가?
• 어떤 Containment와 Remediation을 누가 승인하고 실행해야 하는가?

Microsoft Defender for Cloud

Microsoft Defender for Cloud은 Cloud Native Application Protection Platform, 즉 CNAPP다. Cloud Resource의 설정과 위험을 지속적으로 평가하는 CSPM, Code와 Pipeline 단계의 DevSecOps Security, Server·Container·Storage·Database·Serverless 같은 Workload를 보호하는 CWPP를 포함한다. Azure뿐 아니라 지원되는 AWS, GCP, Hybrid Resource까지 범위를 넓힐 수 있다.

핵심 질문은 다르다.

• 이 Subscription과 Resource가 기준선에서 벗어났는가?
• Internet Exposure, 과도한 권한, 취약한 설정이 있는가?
• 필요한 Defender Plan이 켜져 있고 Sensor가 정상인가?
• Server나 Cloud Service에서 실제 Threat Activity가 탐지되었는가?

둘 중 무엇을 선택하는가

둘은 경쟁 제품이 아니므로 “하나만 고르는” 질문 자체가 잘못될 수 있다. 직원 Device와 Identity, Email Attack을 연계 조사하려면 Defender XDR 영역이 필요하다. VM, Container, Storage, Database의 Posture와 Workload Threat Protection에는 Defender for Cloud가 필요하다. Cloud Incident를 조직 전체 SIEM 흐름에 넣으려면 Sentinel Integration까지 고려한다.

또한 Portal이 통합되었다고 책임도 자동 통합되는 것은 아니다. Cloud Platform Team은 Defender for Cloud Onboarding과 Posture Remediation을, SOC는 Alert Triage와 Incident Response를, Identity Team은 Account Remediation을, Workload Team은 Patch와 Service Recovery를 맡을 수 있다. 이 RACI가 없으면 같은 Incident를 모두가 보고도 아무도 조치하지 않는 상황이 생긴다.

4. 각 신호 영역은 공격 이야기의 다른 조각을 제공한다

4.1 Defender for Endpoint: Device와 Process의 이야기

Microsoft Defender for Endpoint는 예방 보호와 침해 이후 탐지·대응을 함께 제공한다. 복습할 때는 다음 세 층으로 구분하면 이해하기 쉽다.

1. 사전 예방: Next-generation Protection, Attack Surface Reduction, 방화벽과 각종 Hardening Policy로 실행 가능성을 낮춘다.
2. 탐지와 조사: EDR, Device Timeline, Process Tree, File과 Network Evidence로 실행 이후의 행위를 보여 준다.
3. 대응: Device Isolation, File Quarantine, Automated Investigation 같은 Action으로 확산을 줄인다.

Endpoint Encryption은 분실된 Device의 저장 데이터를 보호한다. EDR는 켜져 있는 Device에서 발생하는 행위를 관찰한다. Patch Management는 알려진 취약점의 악용 가능성을 낮춘다. 세 통제는 서로 대체 관계가 아니다.

설계 단계에서는 지원 OS와 Device Inventory, Onboarding 방식, Policy 배포 도구, Network Requirement, Tamper Protection, Device Group, Alert Routing, Offboarding 절차를 정한다. 검증 단계에서는 단순히 “Portal에 Device가 보인다”가 아니라 Sensor Health, 마지막 Check-in, Policy 적용, 안전한 Test Alert, Timeline 생성, 권한별 Response Action, Offboarding 후 Data 보존을 확인한다.

증적 예시: Onboarding Coverage Report, Sensor Health Export, Policy Assignment, Test Alert의 Timestamp, Incident에 연결된 Device ID, Isolation 승인 기록, Remediation Ticket.

흔한 오해: License를 구매하면 모든 Device가 자동 보호된다고 생각하는 것. License, Onboarding, Policy, 운영 인력이 모두 있어야 실제 통제가 작동한다.

4.2 Defender for Cloud Apps: SaaS와 App-to-app의 이야기

Microsoft Defender for Cloud Apps는 관리되는 Endpoint만으로 보기 어려운 위험을 다룬다. 사용자가 승인되지 않은 SaaS를 업무에 사용하거나, Unmanaged Device에서 Sensitive File을 내려받거나, 악성 OAuth Application에 회사 Data를 읽을 수 있는 넓은 권한을 동의할 수 있다. 이런 공격에는 사용자 Laptop에서 실행되는 Malware가 없어도 된다.

주요 기능에는 Cloud App 사용의 발견과 Risk 평가, 지원되는 Connected App의 SaaS Security Posture Management, Activity와 Anomaly Policy, Information Protection Integration, 지원되는 구성의 Adaptive Access 또는 Session Control, OAuth App을 위한 App Governance가 있다. 모든 낯선 Service를 차단하는 것이 목표는 아니다. 승인된 업무 사용과 위험한 App·User·Session·App-to-app 행위를 구분하고 위험에 비례하는 통제를 적용하는 것이 목표다.

제품 경계를 함께 기억해야 한다. Microsoft Entra ID는 Identity를 인증하고 Access와 Consent를 제어한다. Microsoft Purview는 Sensitive Data를 분류하고 보호한다. Defender for Cloud Apps는 SaaS 사용 가시성, Application Risk Context와 지원되는 Activity/Session Control을 더한다. Defender XDR는 이 Alert를 Endpoint, Identity, Email Evidence와 상관분석할 수 있다. 서로 보완하지만 같은 제품은 아니다.

안전한 도입은 승인된 Application Inventory, Data Owner, App Connector 또는 Discovery Source, License, Privacy Requirement, Response 권한을 정하는 일부터 시작한다. 가능하면 Policy를 Alert 또는 Monitoring 상태로 Pilot하고 정상 행위를 파악한 뒤, 업무를 중단할 수 있는 Session이나 Governance Action을 적용하기 전에 Tuning한다. 승인된 Test에서는 예상 User, Application, IP Address, Activity, OAuth Permission, 영향 받은 File/Resource가 Alert와 상관분석된 Incident에 나타나는지 확인한다.

증적 예시: Connector와 Discovery Coverage, Application Risk Assessment, Policy Version, Alert/Activity ID, 영향 받은 Entity, 승인된 Permission 또는 Session Control 변경, 기한이 있는 Remediation 결정. 발견된 App 개수만으로는 위험한 SaaS Access를 이해하고 통제했다는 사실이 증명되지 않는다.

4.3 Defender for Identity: Credential과 Lateral Movement의 이야기

Microsoft Defender for Identity는 On-premises, Cloud, Hybrid Identity Signal을 분석해 Credential Abuse, 비정상 Authentication, Privilege Escalation, Lateral Movement 같은 Identity 기반 공격을 탐지하고 조사 Context를 제공한다. Endpoint의 의심 Process가 Privileged Account의 비정상 활동과 연결되면 우선순위가 크게 달라진다.

배포는 Sensor 설치로 끝나지 않는다. Domain과 Identity Source Coverage, Sensor Health, 필요한 Permission, Service Account Owner, Network 경로, Update, Directory Naming, Privacy와 Retention, Compromised Account 대응 절차를 확인해야 한다. Hybrid Identity에서는 Cloud Policy만 강화한다고 On-premises AD의 Legacy Protocol과 과도한 Privilege가 사라지지 않는다.

증적 예시: Sensor Health, Directory Service Coverage, Identity Security Posture Recommendation, Alert에 매핑된 User와 Device, MITRE ATT&CK Technique, Account Disable 또는 Password Reset의 승인·실행 기록.

흔한 오해: Defender for Identity와 Entra ID Protection을 같은 제품으로 보는 것. 하나는 Identity Environment의 행위와 공격 경로를 폭넓게 분석하고, 다른 하나는 주로 User 및 Sign-in Risk를 Access Decision과 Remediation에 연결한다.

4.4 Entra ID Protection: User Risk와 Sign-in Risk의 이야기

Microsoft Entra ID Protection은 Identity Risk를 탐지하고 조사·Remediation하도록 돕는다. 반드시 구분해야 할 두 용어가 있다.

• Sign-in risk: 지금 발생한 특정 Authentication이 정당한 사용자가 아닐 가능성
• User risk: 해당 Identity 자체가 이미 침해되었을 가능성

Risk Signal은 Conditional Access의 의사결정에 사용할 수 있고 SIEM 조사로 보낼 수도 있다. 하지만 Risk Level만 보고 무조건 차단하면 정상 사용자의 업무를 중단시킬 수 있다. 반대로 High Risk를 모두 알림으로만 두면 통제 효과가 약하다.

단계적 설계는 License와 대상 User를 확인하고, Break-glass Account와 Service Identity를 별도로 다루며, Report-only 결과를 관찰하고, 예상되는 Remediation Experience를 테스트한 뒤, 제한된 Group부터 Enforcement를 확대하는 순서가 안전하다. MFA 등록, Secure Password Change, Help Desk 대응과 Token Revocation 같은 후속 과정도 함께 설계한다.

증적 예시: Risky Sign-in Report, Risky User 상태, Conditional Access Report-only 결과, Policy 변경 승인, Block·Self-remediation·Admin Remediation 결과, 예외 만료일.

비용·License 주의: Risk Detection과 상세 기능은 Entra License Tier 또는 연결된 Defender Product License에 따라 달라질 수 있다. Portal에 메뉴가 보인다는 사실만으로 모든 User가 적절히 License되었다고 판단하면 안 된다.

현재성 보정도 필요하다. Microsoft 공식 문서에 따르면 ID Protection에서 구성한 기존 User Risk 및 Sign-in Risk Policy는 2026년 10월 1일에 은퇴한다. 신규 설계와 Migration 대상은 Microsoft Entra Conditional Access의 Risk-based Policy다. 기존 Policy를 Inventory하고, User Risk와 Sign-in Risk를 각각 별도의 Conditional Access Policy로 Report-only 상태에서 만든 뒤, 대상·예외·Remediation·사용자 영향을 검증한다. 대체 Policy를 Enable한 후 기존 Policy를 Disable하며, 영향 분석 없이 두 경로를 동시에 강제하면 중복되거나 예상하지 못한 Access Decision이 발생할 수 있다. 오래된 ID Protection Portal 절차 대신 최신 Microsoft Entra Risk Policy Migration 안내를 따른다.

4.5 Microsoft Purview: Data 자체의 이야기

Microsoft Purview Information Protection은 Sensitive Information을 발견하고, 분류하고, Label과 Encryption을 적용하며, Data Loss를 줄이는 데 초점을 둔다. Defender 제품이 Device나 Identity의 의심 행위를 찾는다면 Purview는 “어떤 Data가 어디에 있었고, 누가 어떻게 취급했으며, 어떤 보호 Policy가 적용되었는가”라는 Context를 더한다.

기술팀만 Label 이름을 정하면 사용자는 의미를 이해하지 못하고 무조건 낮은 등급을 선택하거나 모든 문서를 최고 등급으로 표시할 수 있다. 먼저 Business Data Owner와 함께 정보 유형, 보존·공유 요구, 보호 수준, 예외, User Experience를 정의해야 한다. Pilot에서는 False Positive와 업무 마찰을 측정하고, 자동 Label 또는 DLP Blocking은 단계적으로 강화한다.

증적 예시: Sensitivity Label Policy, Data Classification 결과, DLP Alert, 적용된 보호 Action, User Override와 정당화, 외부 공유 사건의 File·User·Destination Context.

흔한 오해: Purview가 Anti-malware 제품이라고 생각하는 것. Purview Signal이 Security Incident에 도움을 줄 수 있지만 주된 목적은 Data Security, Governance, Risk, Compliance다.

5. Alert에서 Incident로 바뀌면 Analyst의 작업 단위도 바뀐다

Microsoft의 Incident 조사 가이드는 Incident를 공격 이야기를 구성하는 관련 Alert와 Data의 모음으로 설명한다. 상관분석의 장점은 Alert 수를 줄이는 것만이 아니다. 시간 순서와 Entity 관계를 복원해 대응 우선순위를 바꾸는 데 있다.

초기 Triage에서 다음 순서로 질문한다.

1. 신뢰도: 탐지 근거와 원본 Evidence는 무엇인가?
2. 범위: 관련 User, Device, Mailbox, Application, Cloud Resource, Data는 무엇인가?
3. 시간: 최초 접근, 실행, 권한 상승, 확산, 반출 시점은 언제인가?
4. 중요도: Privileged Identity나 중요 Asset이 포함되었는가?
5. 현재 상태: 공격이 진행 중인가, 자동 Action이 실행되었는가?
6. 대응 권한: 누가 Device 격리, Account 차단, Token 취소, Workload 중지를 승인하는가?
7. 완료 기준: 무엇을 복구하고 어떤 Root Cause와 개선 항목을 남겨야 하는가?

Incident에는 Owner, Severity, Status, Classification, Comment, Action Timeline을 남긴다. “Resolved”로 닫는 것만으로는 충분하지 않다. 탐지가 True Positive인지, 어떤 Control이 실패했는지, Containment가 언제 실행되었는지, 영향 받은 Asset이 무엇인지, 후속 Ticket이 누구에게 배정되었는지가 증적으로 남아야 한다.

상관분석도 틀릴 수 있다. 관련 없는 Alert가 묶이거나, 같은 공격의 Alert가 서로 다른 Incident에 남을 수 있다. Asset Criticality, Privilege, Change Record, Threat Intelligence, Business Context와 Hunting Query를 함께 사용해야 한다. 자동 대응은 속도를 높이지만 Device Isolation이나 Account Disable처럼 업무 영향을 주는 Action에는 승인 경계와 Rollback Plan이 필요하다.

6. Microsoft Sentinel은 어디에 위치하는가

Defender XDR가 모든 SIEM 요구를 대체하는 것은 아니다. Microsoft Sentinel은 Microsoft와 Third-party, Cloud와 On-premises Data를 폭넓게 수집·분석하고, Analytics, Hunting, Incident Management, Automation을 제공하는 SIEM/SOAR다.

Defender XDR와 Sentinel의 Integration을 사용하면 Defender Incident를 Sentinel 흐름에서 보고, 지원되는 범위에서 Status, Owner, Closing Reason을 동기화하며, 다른 Network·Application·Infrastructure Log와 상관분석할 수 있다. 장점은 Portal 수를 줄이는 것보다 조직 전체 Incident Queue에 Microsoft 365 Attack Story를 연결하는 데 있다.

Module 3에는 Microsoft Sentinel과 Microsoft Defender Data Connector를 다루는 Exercise가 포함되어 있다. 이 노트에서는 실제 Tenant에 연결했다고 주장하지 않고 다음을 설계와 검증 관점의 복습 절차로 정리한다.

Connector 설계 절차

1. 대상 Tenant, Workspace 또는 Defender Portal Onboarding Model, Region, Retention, License와 RBAC Role을 확인한다.
2. 수집 목적을 먼저 적는다. Incident 동기화가 필요한지, Alert와 Entity가 필요한지, Advanced Hunting Data가 필요한지 구분한다.
3. 현재 지원되는 Defender XDR Connector의 Data Scope와 Table 제한을 공식 문서에서 확인한다.
4. Defender for Cloud Incident까지 가져올 경우 관련 Alert와 Entity가 비어 보이지 않도록 필요한 Defender for Cloud Connector 구성을 별도로 검토한다.
5. 기존 개별 Product Connector와 Analytics Rule이 같은 Alert로 중복 Incident를 만들지 조사한다.
6. 예상 Daily Volume, Retention, Archive, Query 빈도와 비용을 추정하고 Budget Alert를 둔다.
7. 장애 감지, Connector Health Owner, 변경 승인, Rollback 절차를 운영 문서에 넣는다.

안전한 검증 절차

1. 승인된 Test Account와 Device, 시간대를 정한다.
2. Vendor가 제공하는 Simulation 또는 안전한 Test Signal만 사용한다.
3. Source Portal의 Alert ID, 발생 시간, Entity, Severity를 기록한다.
4. Target Incident에 동일 Entity와 Alert가 연결되는지, Deep Link가 작동하는지 확인한다.
5. Owner, Status, Closing Reason의 양방향 동기화 범위를 검증한다.
6. 수집 지연, Table, Retention, Query 결과와 예상 비용을 기록한다.
7. Test Incident를 정해진 Classification으로 닫고 Evidence와 Cleanup을 남긴다.

Connector를 “Connected”로 표시하는 화면은 시작점일 뿐이다. Incident가 완전한 Context로 도착하고, 운영자가 배정되며, 누락과 중복을 감지하고, 비용을 통제할 수 있어야 완료다. 지원 범위는 최신 Sentinel Data Connector Reference에서 확인한다.

7. 위협·통제·신호·증적 연결표

위협 시나리오	주요 예방·탐지 통제	Incident에 필요한 신호	운영 증적 예시
Phishing 후 악성 실행	Defender for Office 365, Defender for Endpoint	Mail, URL, User, Device, Process	Message ID, Alert ID, Device Timeline, 격리 기록
Credential 탈취와 비정상 Sign-in	Entra ID Protection, Conditional Access	User Risk, Sign-in Risk, IP, Token Context	Sign-in Log, CA Result, Token 취소 기록
AD Lateral Movement	Defender for Identity, 최소 권한	Authentication, Directory Entity, Device 관계	Identity Alert, Sensor Health, Account 조치
Sensitive Data 외부 공유 또는 위험한 SaaS App Access	Purview Label/DLP, Defender for Cloud Apps, Sharing/Session Control	File, Label, User, Application, Destination, Activity, Policy	DLP 또는 Cloud App Alert, Override 사유, 공유·권한 Remediation 결과
Cloud VM 침해	Defender for Cloud/Servers, Defender for Endpoint	Resource, Host, Process, Network, Recommendation	Cloud Alert, Endpoint Timeline, Remediation Ticket
여러 영역에 걸친 공격	Defender XDR, Sentinel	상관된 Alert와 Entity, 외부 Log	Incident Timeline, Owner, Classification, Closure Note

이 표의 핵심은 Tool 이름이 아니라 “위협 → 통제 → 관찰 가능한 신호 → 감사 가능한 증적”의 연결이다. Signal이 없으면 통제가 작동하는지 알기 어렵고, Evidence가 없으면 대응을 나중에 설명하거나 개선하기 어렵다.

8. 자주 하는 오해와 교정

1. Portal이 하나면 Data도 모두 하나다. 실제 수집 범위, Retention, Table, 동기화 방향은 Connector와 License에 따라 다르다.
2. Alert가 많으면 더 안전하다. Noise가 많으면 중요한 공격을 놓친다. 품질, Context, Owner, Response Time을 함께 측정해야 한다.
3. 자동 상관분석은 항상 정확하다. 잘못 묶이거나 누락될 수 있으므로 Hunting과 Business Context가 필요하다.
4. EDR가 있으면 Patch와 Hardening이 불필요하다. 탐지는 노출 감소를 대체하지 않는다.
5. MFA가 있으면 Identity 공격이 끝난다. Token Theft, Consent Phishing, Legacy Protocol, Session Abuse, Privilege Misuse를 별도로 다뤄야 한다.
6. Connector를 켜면 SOC 운영이 완성된다. Triage 기준, On-call, 승인 권한, Playbook, 증적과 개선 과정이 필요하다.
7. License 비용만 계산하면 된다. Log Ingestion, Retention, Automation, Staff, Training, False Positive 처리 비용도 운영비다.

9. 반복 점검용 운영 Checklist

• 현재 제품명, Portal, License, Region, Service Owner를 Architecture 문서에 기록했다.
• Device, Identity, Mailbox, App, Subscription, Data Store의 보호 범위를 수치로 알고 있다.
• Endpoint와 Identity Sensor의 Onboarding 및 Health를 정기적으로 감시한다.
• 승인된 SaaS/OAuth Application, Discovery 또는 Connector Coverage, Policy Owner와 허용된 Response Action을 Inventory했다.
• High-value User, Privileged Account, Critical Device, Sensitive Data를 Incident 우선순위에 반영한다.
• Severity, Assignment, Escalation, Containment 승인, Closure 기준이 문서화되어 있다.
• 안전한 Simulation으로 Incident Correlation과 Response 권한을 검증했다.
• Conditional Access Risk Policy를 Report-only 또는 제한된 Group부터 검증한다.
• Sentinel Connector의 Scope, 중복 경로, Sync, Retention, Cost를 확인했다.
• Incident Comment, Action, Timestamp, Classification, 후속 Ticket을 보존한다.
• Post-incident Lesson을 Prevention, Policy, Training, Detection Engineering에 반영한다.

10. 스스로 설명해 보는 복습 질문

1. Portal 이름을 사용하지 않고 Defender XDR와 Defender for Cloud의 경계를 설명할 수 있는가?
2. 같은 Account Compromise 사건에 Defender for Endpoint, Defender for Cloud Apps, Defender for Identity, Entra ID Protection, Purview가 각각 어떤 Evidence를 더하는가?
3. 여러 Alert가 모두 정확한데도 Incident Response가 실패할 수 있는 이유는 무엇인가?
4. User Risk와 Sign-in Risk는 어떻게 다르고, 각각 어떤 Access Decision에 영향을 줄 수 있는가?
5. Device Encryption, EDR, Patch Management가 서로 대체되지 않는 이유는 무엇인가?
6. Defender와 Sentinel을 연결할 때 어떤 중복 Incident 경로가 생길 수 있는가?
7. Connector 검증에서 “Connected” 표시 외에 어떤 Evidence가 필요한가?
8. 자동 Containment Action에 승인과 Rollback이 필요한 이유는 무엇인가?
9. Platform, SOC, Identity, Compliance, Workload Team의 책임을 어떻게 나눌 것인가?
10. 강의의 옛 제품명이 현재 Architecture나 License 판단을 어떻게 왜곡할 수 있는가?

11. 한 페이지 기억 요약

기억 문장	의미
제품이 아니라 공격 경로를 본다	Mail, Identity, Endpoint, Cloud, Data를 연결한다
Alert는 단서, Incident는 이야기다	Entity와 Timeline, Evidence, Action을 함께 조사한다
XDR와 CNAPP는 목적이 다르다	Defender XDR는 교차 영역 조사, Defender for Cloud는 Cloud Posture와 Workload 보호다
Risk는 차단값이 아니라 의사결정 입력이다	Entra Risk를 단계적 Conditional Access와 Remediation에 연결한다
통합보다 Ownership이 먼저다	연결된 Incident에도 명확한 담당자와 승인 경계가 필요하다
Connector 상태보다 End-to-end Evidence가 중요하다	생성, 수집, 상관분석, 동기화, 종료까지 검증한다

마무리

Module 3의 제품군은 하나씩 외우면 이름이 비슷해 쉽게 섞인다. 반대로 하나의 Attack Path를 놓고 “어떤 노출을 줄이는가, 어떤 Signal을 만드는가, 누가 어떤 Action을 취하는가, 어떤 Evidence로 완료를 증명하는가”를 반복해서 질문하면 역할이 분명해진다.

Defender for Endpoint는 Device와 Process, Defender for Identity는 Credential과 Lateral Movement, Entra ID Protection은 User와 Sign-in Risk, Purview는 Sensitive Data Context를 제공한다. Defender XDR는 Microsoft 보안 신호를 Incident Story로 묶고, Defender for Cloud는 Cloud Resource의 Posture와 Workload Protection을 담당한다. Sentinel은 그 Story를 조직 전체 SIEM/SOAR 범위와 연결한다.

결국 오래 남는 기술은 Portal Menu를 외우는 능력이 아니다. 위협, 통제, Signal, Ownership, Response, Evidence를 하나의 운영 체계로 설명하고 검증하는 능력이다.

공식 참고 자료

• Coursera 과정 및 Module 3 구성
• Microsoft Defender XDR Documentation
• Microsoft Defender for Cloud Overview
• Microsoft Defender for Endpoint Documentation
• Microsoft Defender for Cloud Apps Overview
• Microsoft Defender for Identity Overview
• Microsoft Entra ID Protection Overview
• Microsoft Entra Risk Policy 구성 및 Migration
• Microsoft Purview Information Protection
• Microsoft Defender XDR와 Microsoft Sentinel 통합