SC-900에서 틀리는 문제의 상당수는 개념을 몰라서가 아니라 이름이 비슷한 서비스를 바꿔 골라서 생깁니다. Defender라는 이름이 붙은 제품만 일곱 개가 넘고, 보안 상태를 점수로 보여 주는 기능도 세 가지나 됩니다. 보기 두 개가 Defender for Cloud와 Defender for Cloud Apps처럼 한 쌍으로 나오면 각각의 정의를 아는 것만으로는 부족하고, 둘을 가르는 기준을 한 문장으로 말할 수 있어야 합니다.
이 글은 SC-900 학습자료 시리즈의 복습편입니다. 도메인별 글에서 따로 설명한 서비스 가운데 시험에서 서로의 오답 보기로 자주 함께 나오는 묶음만 골라, 구분 기준과 문제에 등장하는 단서 표현으로 다시 정리했습니다.
---
헷갈리는 서비스를 가르는 세 가지 질문
비슷한 서비스 둘을 만났을 때 아래 세 가지를 차례로 물어보면 대부분 갈립니다.
| 질문 | 무엇을 가르나 | 예시 | |------|------|------| | 무엇을 지키는가? | 대상 (사람·ID, 디바이스·메일·앱, 클라우드 인프라, 데이터) | Entra ID Protection은 클라우드 로그인, Defender for Identity는 온프레미스 AD | | 언제 동작하는가? | 시점 (예방, 탐지·대응, 사후 조사) | DLP는 유출을 막고, 감사는 일어난 일을 기록 | | 어디에 있는가? | 환경 (Azure 리소스, Microsoft 365, 온프레미스) | Defender for Cloud는 Azure 리소스, Defender for Cloud Apps는 SaaS 앱 |
제품군 단위로 먼저 나누면 더 쉽습니다. Microsoft의 보안·규정 준수 제품은 크게 네 묶음이고, 묶음마다 답하는 질문과 쓰는 포털이 다릅니다.
!제품군마다 답하는 질문이 다르다
---
도메인 1: 개념에서 헷갈리는 쌍
인증 vs 권한 부여
| 구분 | 인증 (Authentication, AuthN) | 권한 부여 (Authorization, AuthZ) | |------|------|------| | 묻는 질문 | 당신은 누구인가? | 무엇을 할 수 있는가? | | 순서 | 먼저 | 인증이 끝난 뒤 | | 문제 속 단서 | "암호와 MFA로 신원을 증명" | "읽기만 허용", "관리자 역할 부여" |
제로 트러스트 vs 심층 방어
| 구분 | 제로 트러스트 | 심층 방어 | |------|------|------| | 성격 | 보안 모델 (생각하는 방식) | 보안 전략 (방어를 쌓는 방식) | | 핵심 | 명시적으로 확인, 최소 권한 액세스, 침해 가정 | 물리적 보안부터 데이터까지 7개 계층을 겹겹이 | | 문제 속 단서 | "네트워크 안이라도 신뢰하지 않음" | "한 계층이 뚫려도 다음 계층이 막음" |
암호화 vs 해싱
| 구분 | 암호화 | 해싱 | |------|------|------| | 되돌릴 수 있나 | 키로 복호화 가능 | 되돌릴 수 없는 단방향 | | 용도 | 데이터를 읽지 못하게 숨김 | 암호 저장, 변조 여부 확인 |
관련 글: 보안, 규정 준수, ID 핵심 개념, 암호화·해싱·ID 공급자·디렉터리 서비스
---
도메인 2: Microsoft Entra에서 헷갈리는 쌍
Entra ID vs Active Directory Domain Services vs Entra Domain Services
| 구분 | Microsoft Entra ID | AD DS (온프레미스) | Microsoft Entra Domain Services | |------|------|------|------| | 성격 | 클라우드 ID 서비스 | 회사 서버에서 직접 운영하는 디렉터리 | Microsoft가 관리하는 도메인 서비스 | | 주요 프로토콜 | OAuth 2.0, OpenID Connect, SAML | Kerberos, NTLM, LDAP | Kerberos, NTLM, LDAP | | 문제 속 단서 | "SaaS 앱에 SSO" | "도메인 컨트롤러", "그룹 정책" | "도메인 컨트롤러 없이 레거시 앱을 클라우드로" |
보안 기본값 vs 조건부 액세스 vs ID Protection
| 구분 | 보안 기본값 | 조건부 액세스 | Microsoft Entra ID Protection | |------|------|------|------| | 하는 일 | 모든 사용자에게 미리 정해진 기본 보호(MFA 등)를 한 번에 켬 | 사용자·디바이스·위치 같은 신호로 허용·차단·MFA 요구를 세밀하게 결정 | 로그인 위험과 사용자 위험을 탐지 | | 라이선스 | 무료 | Entra ID P1 | 위험 기반 정책은 Entra ID P2 | | 문제 속 단서 | "추가 비용 없이 기본 보호" | "회사 밖에서 접속하면 MFA 요구" | "유출된 자격 증명", "익명 IP 로그인" |
PIM vs 액세스 검토 vs 권한 관리
| 구분 | PIM | 액세스 검토 | 권한 관리 (Entitlement management) | |------|------|------|------| | 핵심 | 필요한 시간에만 관리자 권한 활성화 (JIT) | 이미 가진 권한이 아직 필요한지 정기 점검 | 필요한 권한을 묶은 액세스 패키지를 요청·승인 | | 문제 속 단서 | "승인을 받아 2시간만 전역 관리자" | "분기마다 게스트 접근 재확인" | "외부 협력사가 프로젝트 리소스를 한 번에 요청" |
Entra 역할 vs Azure RBAC
| 구분 | Microsoft Entra 역할 | Azure RBAC | |------|------|------| | 관리 대상 | Entra ID 자체 (사용자, 그룹, 앱 등록) | Azure 리소스 (VM, 스토리지 등) | | 대표 역할 | 전역 관리자, 사용자 관리자 | 소유자, 기여자, 읽기 권한자 |
Entra ID Protection vs Defender for Identity
ID Protection은 클라우드 로그인의 위험을, Defender for Identity는 도메인 컨트롤러 센서로 온프레미스 Active Directory의 공격(측면 이동, 자격 증명 도용)을 탐지합니다. 문제에 "온프레미스"나 "도메인 컨트롤러"가 보이면 Defender for Identity입니다.
관련 글: Entra 인증 방법·암호 보호·하이브리드 ID, 액세스 관리와 ID 거버넌스
---
도메인 3: 보안 솔루션에서 헷갈리는 쌍
NSG vs Azure Firewall vs WAF vs DDoS Protection
| 구분 | NSG | Azure Firewall | WAF | DDoS Protection | |------|------|------|------|------| | 막는 것 | IP·포트 기반 트래픽 | 여러 VNet의 트래픽을 중앙에서 (FQDN 필터, 위협 인텔리전스) | SQL 삽입, 교차 사이트 스크립팅 같은 웹 공격 | 대량 트래픽으로 서비스를 마비시키는 공격 | | 적용 위치 | 서브넷, 네트워크 인터페이스 | 허브 VNet의 관리형 방화벽 | Application Gateway, Front Door | 가상 네트워크의 공용 IP | | 문제 속 단서 | "서브넷에 들어오는 포트 3389 차단" | "모든 아웃바운드를 중앙에서 통제" | "웹 앱의 OWASP 위협" | "대규모 트래픽 폭주" |
Defender for Cloud vs Defender for Cloud Apps vs Defender XDR
| 구분 | Defender for Cloud | Defender for Cloud Apps | Defender XDR | |------|------|------|------| | 지키는 것 | Azure·AWS·GCP·온프레미스의 인프라 리소스 | 직원이 쓰는 SaaS 앱 | 메일·디바이스·ID·앱 전체 | | 핵심 기능 | 보안 태세 관리(CSPM)와 워크로드 보호(CWP) | CASB, 섀도 IT 발견 | 경고를 인시던트로 묶어 탐지·대응 | | 문제 속 단서 | "VM과 스토리지의 잘못된 설정" | "승인되지 않은 클라우드 앱" | "피싱부터 계정 탈취까지 하나의 공격으로" |
Microsoft Sentinel vs Defender XDR
Sentinel은 Microsoft 제품이 아닌 방화벽, 서버, 다른 클라우드의 로그까지 모으는 SIEM·SOAR이고, Defender XDR은 Microsoft Defender 제품들의 신호를 깊게 연관 짓는 XDR입니다. "타사 데이터 원본까지 수집"이 보이면 Sentinel입니다.
보안 점수 세 가지
| 점수 | 위치 | 무엇을 평가하나 | |------|------|------| | Microsoft Secure Score | Defender 포털 | Microsoft 365의 ID·디바이스·앱 보안 태세 | | 보안 점수 (Defender for Cloud) | Defender for Cloud | Azure 등 클라우드 리소스의 보안 태세 | | 규정 준수 점수 | Compliance Manager | 규정·표준 요구 사항에 대한 개선 작업 진행도 |
관련 글: Microsoft Defender XDR 서비스 완전 정리, Defender for Cloud 보안 정책·표준·보안 점수, Azure 보안 서비스
---
도메인 4: 규정 준수 솔루션에서 헷갈리는 쌍
Service Trust Portal vs Compliance Manager
| 구분 | Service Trust Portal | Compliance Manager | |------|------|------| | 누구의 이야기인가 | Microsoft가 규정을 지키고 있다는 증거 | 우리 조직이 규정을 지키고 있는지 | | 제공하는 것 | 감사 보고서(SOC, ISO), 신뢰 문서 | 평가, 개선 작업, 규정 준수 점수 |
개인 정보 위험과 데이터 주체 요청을 다루는 Microsoft Priva도 보기로 함께 나올 수 있습니다. 2026년 10월 출제 범위의 세부 항목에는 Priva라는 이름이 따로 없지만, "조직의 개인 정보 처리 위험"을 다루는 제품이라는 점은 구분해 두세요.
민감도 레이블 vs 보존 레이블
| 구분 | 민감도 레이블 | 보존 레이블 | |------|------|------| | 정하는 것 | 누가 열 수 있나 (암호화, 워터마크) | 얼마나 보관하고 언제 지우나 | | 문제 속 단서 | "기밀 문서를 회사 밖에서 못 열게" | "7년 보관 후 삭제", "레코드로 선언" |
DLP vs 내부자 위험 관리 vs 통신 규정 준수 vs 정보 장벽
| 기능 | 하는 일 | 문제 속 단서 | |------|------|------| | DLP | 민감한 정보가 담긴 공유·전송을 차단하거나 경고 | "신용카드 번호가 담긴 메일을 외부로 보내면 차단" | | 내부자 위험 관리 | 사용자 활동에서 유출·도용 위험 패턴 탐지 | "퇴사 예정자가 대량으로 파일 다운로드" | | 통신 규정 준수 | 메시지 내용의 부적절한 표현·규정 위반 탐지 | "Teams 채팅의 괴롭힘 표현 검토" | | 정보 장벽 | 특정 그룹끼리 소통·공유 자체를 막음 | "투자 부서와 리서치 부서의 Teams 대화 금지" |
eDiscovery vs 감사
eDiscovery는 소송이나 조사에 필요한 콘텐츠를 찾고 보존(hold)하고 내보내는 도구이고, 감사는 사용자와 관리자가 언제 무엇을 했는지 활동 기록을 남기고 검색하는 도구입니다. 감사(Standard)는 기록을 180일, 감사(Premium)는 기본 1년 보관합니다.
관련 글: Purview 데이터 분류·민감도 레이블·보존 레이블 완전 정리, 내부자 위험, eDiscovery, 감사, Service Trust Portal과 개인 정보 보호
---