50개 문제와 45분 시간 제한으로 실제 시험을 시뮬레이션하세요. AI 검증 답안과 상세 해설로 학습하세요.
AI 기반
모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
Microsoft 365에서 information barrier 정책을 구현하는 사용 사례는 무엇입니까?
오답입니다. Microsoft 365에 대한 인증되지 않은 액세스를 제한하는 것은 일반적으로 Microsoft Entra ID 인증, Conditional Access, MFA, 테넌트 액세스 설정으로 해결하는 ID/액세스 제어 시나리오입니다. information barriers는 인증된 사용자를 전제로 하며, 서비스에 대한 익명 액세스를 차단하는 것이 아니라 특정 내부 그룹 간 커뮤니케이션/협업을 방지하는 데 초점을 둡니다.
정답입니다. 대표적인 information barrier 사용 사례는 특정 내부 그룹이 Microsoft Teams(채팅, 통화, 모임, 팀 멤버십)에서 커뮤니케이션하지 못하도록 방지하는 것입니다. 이는 규제 또는 윤리적 분리(예: 금융 “wall” 시나리오)를 지원합니다. IB 정책은 세그먼트를 정의하고 그 사이의 커뮤니케이션을 차단하여 내부 직무 분리를 강제합니다.
정답입니다. information barriers는 정의된 세그먼트 간 Exchange Online 커뮤니케이션도 제한하여, 조직 내 특정 그룹 간 이메일 상호작용을 방지할 수 있습니다. 이는 내부 커뮤니케이션을 통제해야 하는 컴플라이언스 요구 사항(예: 법무/insider trading 제한)에 부합합니다. 정책 모델은 세그먼트 기반이며 지원되는 워크로드 전반에 적용됩니다.
오답입니다. 외부 이메일 수신자에게 데이터 공유를 제한하는 것은 일반적으로 Exchange Online 메일 흐름 규칙, anti-spam 정책, 테넌트 외부 공유 제어, DLP 정책, sensitivity labels/암호화를 통해 처리합니다. IB는 내부 세그먼테이션과 내부 그룹 간 커뮤니케이션 방지에 초점을 두며, 주로 외부 수신자 공유 제어를 위해 설계된 것은 아닙니다.
핵심 개념: Microsoft 365의 information barriers(IB)는 특정 사용자 또는 그룹이 서로 커뮤니케이션하거나 협업하지 못하도록 방지하기 위해 설계된 규정 준수(컴플라이언스) 제어입니다. 이는 규제, 법적 또는 윤리적 요구 사항을 충족하기 위해 일반적으로 사용됩니다(예: 금융 서비스에서 트레이딩과 자문 팀 같은 “insider” 그룹을 분리). 정답이 맞는 이유: information barriers의 주요 사용 사례는 Microsoft 365 워크로드 전반에서 조직의 특정 세그먼트 간 커뮤니케이션을 제한하는 것입니다. 여기에는 정의된 그룹 간 Microsoft Teams 상호작용(채팅, 통화, 모임, 팀 멤버십)을 방지하는 것과, 해당 그룹 간 Exchange Online 커뮤니케이션(이메일 및 관련 디렉터리 기반 상호작용)을 방지하는 것이 포함됩니다. 따라서 Teams 채팅 제한(B)과 Exchange Online 이메일 제한(C) 모두 유효한 사용 사례입니다. 주요 기능 및 구성 포인트: IB 정책은 “segments”(부서, 역할 또는 사용자 지정 특성과 같은 특성으로 그룹화된 사용자)를 기반으로 구성됩니다. 그런 다음 정책은 세그먼트가 커뮤니케이션할 수 있는지(“allow”) 또는 차단되어야 하는지(“block”)를 정의합니다. IB는 Microsoft Purview compliance 기능과 통합되며, 디렉터리 특성(Microsoft Entra ID)에 의존하여 사용자를 세그먼트에 배치합니다. 실제로 조직은 Azure Well-Architected Framework의 Security(최소 권한 및 직무 분리)와 Operational Excellence(정책 수명 주기 관리) 원칙에 맞춘 거버넌스 관행(명확한 세그먼테이션 전략, 변경 관리, 테스트)과 함께 IB를 구현합니다. 일반적인 오해: information barriers는 주로 인증되지 않은 액세스를 차단하기 위한 것이 아닙니다(이는 Conditional Access 같은 ID 및 액세스 관리 영역). 또한 외부 수신자에 대한 공유를 제한하는 주요 도구도 아닙니다. 이는 일반적으로 외부 공유 설정, DLP, sensitivity labels, Exchange 메일 흐름 규칙으로 처리합니다. 시험 팁: SC-900에서는 다음을 기억하세요: Information barriers = “그룹 간 내부 커뮤니케이션/협업 방지”(대개 규제 목적). Teams/Exchange에서 부서 간 커뮤니케이션을 분리한다는 선택지가 나오면 information barriers를 떠올리세요. 외부 공유 또는 인증되지 않은 액세스를 언급하면 다른 제어(Conditional Access, DLP, sensitivity labels, sharing policies)를 생각하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Azure Sentinel과 다른 보안 소스 간의 실시간 통합을 제공하기 위해 무엇을 사용합니까?
Azure AD Connect는 on-premises Active Directory와 Microsoft Entra ID 간에 identity를 동기화하는 데 사용됩니다. 그 목적은 user, group 및 authentication 관련 설정 동기화와 같은 hybrid identity 활성화입니다. 이것은 security telemetry를 위한 Microsoft Sentinel ingestion 또는 integration 기능으로 동작하지 않습니다. identity 관련 log를 Sentinel에서 모니터링할 수는 있지만, Azure AD Connect는 해당 log를 Sentinel에 연결하는 데 사용하는 도구가 아닙니다.
Log Analytics workspace는 Microsoft Sentinel이 사용하는 기본 data store이자 analytics engine입니다. 수집된 log가 저장되고 쿼리되는 위치이지만, 외부 security source와의 연결을 설정하는 기능 자체는 아닙니다. 즉, workspace는 대상이자 분석 계층이고, connector는 통합 메커니즘입니다. 따라서 이것은 Sentinel의 필수 구성 요소이지만, 이 문제에 대한 최선의 답은 아닙니다.
Azure Information Protection은 민감한 정보를 분류, 레이블 지정 및 보호하기 위한 service입니다. 데이터 보호 및 규정 준수 목적을 위해 문서와 email에 encryption 및 사용 제한을 적용하도록 조직을 지원합니다. 이것은 외부 security data source를 통합하기 위한 Microsoft Sentinel 기능이 아닙니다. 관련 service의 event가 최종적으로 Sentinel에서 모니터링될 수는 있지만, Azure Information Protection 자체는 해당 source를 연결하는 데 사용되는 메커니즘이 아닙니다.
connector는 Microsoft Sentinel이 Microsoft 및 third-party security source와 통합하기 위해 data connector를 사용하므로 정답입니다. 이러한 connector는 API, agent, Syslog/CEF 또는 Microsoft-native integration을 통해 데이터가 어떻게 수집되고 Sentinel로 수집되는지를 정의합니다. 구성이 완료되면 유입되는 security data를 analytics rule, hunting query, incident 조사에 사용할 수 있습니다. 시험에서는 source를 Sentinel에 연결하는 표준 용어로 'connector' 또는 'data connector'를 사용합니다.
핵심 개념: Microsoft Sentinel(이전 명칭 Azure Sentinel)은 cloud-native SIEM/SOAR입니다. 그 가치는 여러 소스(Microsoft 및 third-party)로부터 security data를 수집하는 데 달려 있습니다. 실시간 또는 near-real-time 통합은 기본 제공 data connector(및 API 기반 수집, agent 기반 수집, streaming과 같은 관련 ingestion 방법)를 통해 이루어집니다. 정답인 이유: connector(data connector)는 다른 security source를 통합하고 해당 logs/alerts를 Sentinel로 지속적으로 수집하는 데 사용되는 Sentinel 기능입니다. connector는 Microsoft Defender 제품, Microsoft Entra ID, AWS, Palo Alto, Cisco 등 다양한 소스로부터 데이터를 가져오거나 수신하기 위한 구성과 연결 방식을 제공합니다. 많은 connector는 near-real-time ingestion을 지원하며, 해당 소스에 맞춘 incident 생성, analytics rule template, workbook과 같은 추가 기능도 제공합니다. 주요 기능 / 구성 포인트: - connector는 Microsoft Sentinel의 Content management / Data connectors에서 관리합니다. - connector는 일반적으로 다음 패턴 중 하나를 사용합니다: Azure Monitor Agent/Log Analytics agent, REST API, Event Hubs/CEF/Syslog 또는 Microsoft-native integration. - 데이터는 Sentinel이 연결된 Log Analytics workspace의 table로 저장되며, 이후 analytics rule이 해당 데이터(KQL)를 쿼리하여 alert/incident를 생성합니다. - 모범 사례(Azure Well-Architected Framework – Security and Operational Excellence): 지원되는 connector로 ingestion을 표준화하고, data health(connector 상태, data volume)를 검증하며, API permission에는 least privilege를 사용합니다. 일반적인 오해: 많은 학습자가 Log Analytics workspace를 통합 메커니즘과 혼동합니다. workspace는 storage/analytics backend이지만, 그 자체로 새로운 source를 실시간으로 “통합”하지는 않습니다. 데이터를 workspace로 가져오려면 여전히 connector(또는 custom ingestion)가 필요합니다. 마찬가지로 Azure AD Connect와 Azure Information Protection은 security/identity service이지만 Sentinel 통합 메커니즘은 아닙니다. 시험 팁: SC-900에서는 다음을 기억하세요: Sentinel은 “data connector”를 통해 data source를 통합합니다. Log Analytics workspace는 Sentinel에 필요하지만, 다른 security source의 데이터를 가져오는 데 사용하는 것은 connector입니다. 문제에서 “Sentinel을 다른 security source와 통합”한다고 하면, 가장 안전한 답은 일반적으로 “connector”입니다.
규제 표준(예: International Organization for Standardization (ISO))에 대해 Microsoft 클라우드 서비스가 어떻게 준수하는지에 대한 정보를 제공하는 Microsoft 포털은 무엇입니까?
Microsoft Endpoint Manager admin center (Intune)는 디바이스, 앱, 엔드포인트 보안 정책(예: 규정 준수 정책, 구성 프로필, conditional access 통합)을 관리하는 데 사용됩니다. 디바이스가 조직의 규정 준수 규칙을 충족하는지 보고할 수는 있지만, Microsoft 클라우드 서비스에 대한 Microsoft의 제3자 감사 증명서(예: ISO 인증서)를 제공하지는 않습니다. 이는 규정 준수 증빙 저장소가 아니라 운영 관리 포털입니다.
Azure Cost Management + Billing은 재무 거버넌스에 초점을 둡니다. 지출, 예산, 비용 할당, 청구 계정/구독을 추적합니다. 비용 최적화(Azure Well-Architected cost pillar)에는 도움이 되지만 ISO와 같은 표준에 대한 규제 준수를 입증하는 것과는 관련이 없습니다. 그곳에서는 감사 보고서나 규정 준수 증명서를 찾을 수 없으며, 비용 분석 및 청구 관리를 위한 것입니다.
Microsoft Service Trust Portal이 정답인 이유는 ISO/IEC 27001과 같은 표준에 대한 인증, 감사 보고서, 증명서를 포함하여 Microsoft 클라우드 서비스에 대한 공식 규정 준수 문서와 증빙을 제공하기 때문입니다. 이는 고객의 실사, 감사, 규제 요구사항을 지원하도록 설계되었으며, Microsoft가 인정된 프레임워크와 표준을 준수함을 보여주는 다운로드 가능한 보고서와 규정 준수 리소스를 제공합니다.
Azure Active Directory admin center(현재 Microsoft Entra admin center)는 ID, 인증 방법, conditional access, 테넌트 보안 설정을 관리하는 데 사용됩니다. 보안 통제를 구현하는 데는 도움이 되지만, Microsoft의 규정 준수 증명서(예: ISO 감사 보고서)를 제공하는 권위 있는 출처는 아닙니다. 외부 표준에 대한 Microsoft의 규정 준수 증빙이 필요하다면 Service Trust Portal을 사용해야 합니다.
핵심 개념: 이 문제는 Microsoft가 자사의 클라우드 서비스(Microsoft 365, Azure, Dynamics 365)가 외부 규제 표준 및 인증(예: ISO/IEC 27001, SOC, PCI DSS)을 어떻게 충족하는지에 대한 공식 준수 문서를 어디에 게시하는지에 대한 지식을 평가합니다. SC-900에서는 기본 보안/규정 준수 개념에 해당하며, 조직이 클라우드 제공업체의 규정 준수 상태를 어떻게 검증하는지 이해하는 것을 다룹니다. 정답이 맞는 이유: Microsoft Service Trust Portal (STP)은 규정 준수 리소스를 제공하는 Microsoft의 주요 공개 포털입니다. 이 포털은 Microsoft 클라우드 서비스가 다양한 규제 및 산업 표준을 충족함을 입증하는 감사 보고서, 규정 준수 가이드, 인증서 및 문서에 대한 액세스를 제공합니다. 특히 ISO의 경우, STP에서 일반적으로 ISO 인증서, 감사 증명서, 관련 규정 준수 문서를 찾습니다. 이는 거버넌스 및 리스크 관리 요구사항에 부합하며 Azure Well-Architected Framework의 Security pillar(리스크 관리, 보증, 규정 준수 증빙)와도 일치합니다. 주요 기능: STP에는 Compliance Manager(평가 기반 규정 준수 상태 추적), 다운로드 가능한 감사 보고서(예: SOC 보고서), 인증서/증명서(예: ISO/IEC 인증), 그리고 Microsoft 클라우드 보안 및 규정 준수 “trust” 콘텐츠와 같은 상세 문서가 포함됩니다. 이는 실사(due diligence), 벤더 리스크 관리, 규제 감사에 필요한 증빙을 요구하는 감사인, 규정 준수 담당자, 보안 팀을 위해 설계되었습니다. 흔한 오해: 학습자들은 Purview가 DLP, 보존, eDiscovery, 감사와 같은 규정 준수 기능을 구성하는 곳이기 때문에 STP를 Microsoft Purview compliance portal과 혼동하는 경우가 많습니다. 그러나 Purview는 주로 조직의 규정 준수 통제 및 데이터 거버넌스를 관리하기 위한 것이며, Microsoft의 제3자 감사 보고서 및 인증을 가져오는 용도가 아닙니다. 마찬가지로 Microsoft 365 admin center는 테넌트 관리용이고, Azure Cost Management는 지출/차지백용으로, 어느 쪽도 규정 준수 증명서 제공을 목적으로 하지 않습니다. 시험 팁: 문제에서 “감사 보고서”, “인증”, “증명서”, “ISO/SOC/PCI 문서”, 또는 “Microsoft가 어떻게 준수하는지”를 묻는다면 Service Trust Portal을 떠올리세요. DLP, 보존 레이블, eDiscovery처럼 규정 준수 정책을 “구성”하는 위치를 묻는다면 Microsoft Purview compliance portal을 떠올리세요. 사용자/테넌트 설정을 묻는다면 Microsoft 365 admin center, 비용/예산을 묻는다면 Azure Cost Management + Billing을 떠올리면 됩니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Conditional Access 정책은 디바이스 상태를 신호로 사용할 수 있습니다.
예. Conditional Access 정책은 디바이스 상태를 신호로 사용할 수 있습니다. Microsoft Entra에서 디바이스 관련 조건에는 디바이스 플랫폼(iOS, Android, Windows, macOS)과—“상태”와 더 관련이 큰 것으로—디바이스가 Microsoft Intune에 의해 준수(compliant)로 표시되었는지(디바이스 준수) 여부 및/또는 디바이스가 Hybrid Azure AD joined / Microsoft Entra joined인지 여부가 포함됩니다. Conditional Access는 또한 디바이스 필터(filter for devices)를 사용하여 디바이스 특성에 따라 디바이스를 포함/제외할 수 있습니다. 이러한 디바이스 신호를 통해 “준수 디바이스 필요(Require a compliant device)” 또는 “Hybrid Azure AD joined 디바이스에서만 액세스 허용(Allow access only from Hybrid Azure AD joined devices)”과 같은 정책을 적용할 수 있습니다. 이는 민감한 앱에 대한 액세스를 부여하기 전에 디바이스 상태/건강을 검증하는 일반적인 Zero Trust 패턴입니다. “아니요”는 디바이스 컨텍스트가 액세스 결정을 내리는 데 사용되는 핵심 Conditional Access 입력(신호) 중 하나이므로 틀립니다.
Conditional Access 정책은 1차 인증이 완료되기 전에 적용된다.
아니오. Conditional Access 정책은 1차 인증이 완료되기 전에 적용되지 않습니다. Conditional Access 평가는 Entra ID가 사용자를 식별하고 로그인 컨텍스트(누가 로그인하는지, 어떤 app/resource에 액세스하는지, 기타 조건)를 이해할 수 있어야 합니다. 이러한 식별은 사용자가 기본 자격 증명(첫 번째 factor)을 제출한 후에 이루어집니다. 첫 번째 factor 이후에 Conditional Access가 평가되며, 그 다음에 MFA 프롬프트, compliant device 요구, 또는 액세스 차단과 같은 추가 요구 사항(controls)을 적용할 수 있습니다. 즉, CA는 사용자가 알려지기 전에 실행되는 pre-authentication 게이트가 아니라, 초기 인증 이후 추가 단계를 요구할 수 있는 로그인 프로세스의 일부입니다. “예”라고 답하면 Conditional Access를 네트워크 계층의 pre-auth controls(일부 VPN/NAC 시나리오 등)와 혼동한 것입니다. Entra에서 CA는 로그인 중에 평가되는 identity 기반 정책이며, 1차 인증 완료 이전에는 적용되지 않습니다.
Conditional access 정책은 사용자가 특정 애플리케이션에 액세스하려고 시도할 때 multi-factor authentication (MFA)을 트리거할 수 있습니다.
예. Conditional Access는 사용자가 특정 애플리케이션에 액세스하려고 시도할 때 MFA를 트리거할 수 있습니다. 가장 일반적인 Conditional Access 구성 중 하나는 다음과 같습니다. 정책을 특정 사용자/그룹에 할당하고, 하나 이상의 cloud app(예: Exchange Online, SharePoint Online, Azure Management 또는 특정 enterprise application)을 대상으로 지정한 다음, grant control을 “Require multi-factor authentication”으로 설정합니다. 이를 통해 애플리케이션별 step-up authentication이 가능해집니다. 사용자는 저위험 앱에는 비밀번호만으로 sign in할 수 있지만, 민감한 애플리케이션에 액세스할 때는 Conditional Access가 액세스를 허용(토큰 발급)하기 전에 MFA를 요구합니다. “아니요”라고 답하는 것은 부정확합니다. “Require MFA”는 Conditional Access에 기본 제공되는 grant control이며, 정책 범위를 특정 cloud app으로 지정하는 것은 고가치 리소스를 보호하는 데 사용되는 핵심 기능이기 때문입니다.
HOTSPOT - 다음 각 문장에 대해, 문장이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Sensitivity labels는 문서를 암호화하는 데 사용할 수 있습니다.
예. Sensitivity labels는 문서를 암호화하도록 구성할 수 있습니다. Microsoft Purview Information Protection에서 label은 암호화 및 사용 권한(예: 누가 열기, 편집, 인쇄 또는 전달할 수 있는지 제한)을 포함하는 보호 설정을 적용할 수 있습니다. 이 보호는 Microsoft Purview Message Encryption/Azure Rights Management 기술을 사용하여 적용되며, 지속적(persistent)으로 설계되어 구성에 따라 파일이 조직 외부로 복사되더라도 보호가 파일과 함께 유지됩니다. 이는 시험의 핵심 개념입니다. labels는 단순한 “태그”가 아니라, 실제로 제어를 강제할 수 있습니다. 반대 선택지(아니요)는 잘못된데, 암호화는 조직이 Sensitivity labels를 배포하는 주요 이유 중 하나이기 때문입니다. 즉, 재무 보고서, HR 데이터 또는 고객 PII와 같은 민감한 콘텐츠에 대한 무단 액세스를 방지하기 위함입니다.
Sensitivity labels는 문서에 머리글과 바닥글을 추가할 수 있습니다.
예. Sensitivity labels는 콘텐츠 표시의 일부로 문서에 머리글과 바닥글을 추가할 수 있습니다. 레이블을 구성할 때 관리자는 머리글(예: “Confidential”), 바닥글, 그리고 Office 문서에 대한 워터마크와 같은 시각적 표시를 정의할 수 있습니다. 이러한 표시는 사용자가 민감도 수준을 인식하는 데 도움이 되며, 실수로 공유하는 일을 줄여 거버넌스 및 규정 준수를 지원합니다. 이 기능은 Microsoft 365 앱의 Word, Excel, PowerPoint 문서에 일반적으로 적용됩니다. 아니요라고 답하는 것은 잘못인데, 머리글과 바닥글은 문서에 대해 명시적으로 지원되는 레이블 작업이며 Microsoft Purview Information Protection 기본 사항에서 자주 언급되기 때문입니다.
Sensitivity labels는 이메일에 워터마크를 적용할 수 있습니다.
아니요. Sensitivity labels는 이메일에 보호를 적용할 수 있습니다(예: 메시지 암호화 및 수신자 권한 제어). 또한 지원되는 클라이언트에서는 이메일에 특정 시각적 표시(예: 제목 접두사 또는 헤더/푸터 텍스트)를 추가할 수도 있습니다. 그러나 “워터마크”는 문서 중심의 표시 기능(Word/Excel/PowerPoint)이며, Office 문서가 지원하는 방식처럼 이메일에 워터마크로 일반적으로 적용되지는 않습니다. SC-900에서는 워터마킹을 이메일 기능이 아니라 문서 표시 기능으로 취급하세요. 따라서 예를 선택하면 이메일 메시지에 동일한 워터마크 기능 세트가 존재한다는 의미로 오해를 불러일으킬 수 있으며, 이는 Sensitivity labels의 기대 동작이 아닙니다.
Microsoft Defender for Endpoint의 두 가지 기능은 무엇인가요? 각 정답 선택지는 완전한 솔루션을 제시합니다. 참고: 각 정답 선택지는 1점입니다.
정답입니다. Automated investigation and remediation (AIR)은 Defender for Endpoint의 핵심 기능입니다. 경고와 관련 아티팩트(process trees, files, persistence, lateral movement indicators)를 자동으로 분석하고 malware 격리, 악성 프로세스 중지, persistence mechanisms 제거, 디바이스 격리와 같은 조치를 수행할 수 있습니다. 이는 보안 운영을 확장하는 데 도움이 되며 위협을 억제하는 데 걸리는 시간을 줄입니다.
오답입니다. Transport encryption(예: 전송 중 데이터에 대한 TLS/SSL)은 여러 서비스 전반에서 사용되는 일반적인 보안 메커니즘이지만, 일반적으로 Microsoft Defender for Endpoint의 주요하고 구별되는 기능으로 시험에서 다뤄지지는 않습니다. MDE는 network transport encryption 기능을 제공하기보다는 엔드포인트 예방, 탐지, 조사, 대응에 초점을 둡니다.
오답입니다. Shadow IT detection은 Microsoft Defender for Cloud Apps(CASB)와 가장 밀접하게 연관됩니다. 해당 서비스는 traffic logs 및 signals를 분석하여 승인되지 않은 cloud applications을 발견하고 평가함으로써 cloud app 사용에 대한 거버넌스 및 정책 적용을 가능하게 합니다. Defender for Endpoint는 Cloud Apps에 디바이스 signals를 제공할 수는 있지만, shadow IT detection은 MDE의 핵심 기능이 아닙니다.
정답입니다. Attack surface reduction은 예방에 초점을 둔 Defender for Endpoint의 주요 기능입니다. 여기에는 ASR rules(Office child processes와 같은 위험한 동작 차단), controlled folder access(anti-ransomware), network protection(악성 domains/IPs 차단), exploit protection이 포함됩니다. 이러한 제어는 일반적인 공격 벡터에 대한 노출을 줄이며 엔드포인트 보안 시험 목표에서 자주 언급됩니다.
핵심 개념: Microsoft Defender for Endpoint (MDE)는 Microsoft의 엔드포인트 보안 플랫폼(Microsoft Defender XDR의 일부)으로, Windows, macOS, Linux, iOS, Android와 같은 디바이스에 대해 예방, 탐지, 조사, 대응(EDR/XDR)을 제공합니다. SC-900에서는 MDE의 핵심적인 엔드포인트 중심 기능을 인지하는 것이 기대됩니다. 정답인 이유: A(자동화된 조사 및 수정)는 MDE의 핵심 기능입니다. 경고가 생성되면(예: 의심스러운 PowerShell, malware, credential theft 동작), MDE는 관련 엔터티(processes, files, registry keys, persistence mechanisms)를 자동으로 조사하고 파일 격리, 프로세스 중지, 디바이스 격리, persistence 제거와 같은 수정 조치를 수행할 수 있습니다. 이는 평균 대응 시간을 줄이고 탐지/대응을 개선하며 blast radius를 제한함으로써 Azure Well-Architected Framework의 security pillar를 지원합니다. D(공격 표면 감소) 또한 MDE의 핵심 기능입니다. Attack Surface Reduction (ASR)에는 ASR rules, controlled folder access, network protection, exploit protection과 같은 제어가 포함됩니다. 이는 일반적인 공격 기법(macro 악용, credential theft, ransomware 동작)에 대한 기회를 줄이는 예방 조치로, “shift-left” 보안 및 least privilege 원칙에 부합합니다. 주요 기능 및 모범 사례: MDE에는 EDR telemetry, threat and vulnerability management, device isolation, advanced hunting (KQL), indicators, 그리고 Microsoft Intune 및 Microsoft Defender for Cloud Apps와의 통합이 포함됩니다. 모범 사례는 ASR rules를 먼저 audit mode로 배포한 다음 적용(enforce)하고, noise를 피하기 위해 적절한 permissions/roles 및 alert tuning과 함께 automated investigation을 사용하는 것입니다. 일반적인 오해: Transport encryption(B)은 일반적인 보안 제어(예: 전송 중 데이터에 대한 TLS)지만 Defender for Endpoint의 대표적인 “기능”으로 보기는 어렵습니다. 이는 보통 networking, email 또는 service-to-service 보안과 연관됩니다. Shadow IT detection(C)은 주로 Microsoft Defender for Cloud Apps(CASB)의 기능으로, network logs 및 signals에서 승인되지 않은 cloud app 사용을 발견하는 데 초점을 둡니다. 시험 팁: SC-900에서는 제품을 해당 “주요” 기능과 매핑하세요: endpoints = MDE(EDR, ASR, automated investigation), cloud app discovery/shadow IT = Defender for Cloud Apps, email protection = Defender for Office 365, identity protection = Entra ID Protection. “attack surface reduction” 또는 “automated investigation”을 보면 Defender for Endpoint를 떠올리세요.
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
______는 경고 탐지, 위협 가시성, 선제적 헌팅, 그리고 위협 대응을 위한 단일 솔루션을 제공하는 데 사용되는 cloud-native security information and event management (SIEM) 및 security orchestration automated response (SOAR) 솔루션입니다.
정답: D. Azure Sentinel (현재 Microsoft Sentinel). Azure Sentinel은 Microsoft의 cloud-native SIEM 및 SOAR 솔루션입니다. Azure 서비스, Microsoft 보안 제품(예: Microsoft Defender), 그리고 third-party 소스에서 데이터를 수집한 다음, analytics rules와 threat intelligence를 사용해 경고를 탐지합니다. 또한 조사(investigation)를 위한 incident management를 제공하고, KQL (Kusto Query Language)을 사용한 선제적 위협 헌팅을 지원하며, playbooks (Azure Logic Apps integration)을 사용해 자동화된 대응을 활성화하는데, 이것이 SOAR 구성 요소입니다. 다른 선택지가 틀린 이유: - A. Azure Advisor는 비용, 안정성, 성능, 운영 우수성, 그리고 보안 상태 개선을 위한 best-practice 권장 사항에 초점을 맞추며, SIEM/SOAR가 아닙니다. - B. Azure Bastion은 Azure portal을 통해 TLS로 VM에 대한 안전한 RDP/SSH 액세스를 제공하는 액세스 솔루션이며, 보안 운영 플랫폼이 아닙니다. - C. Azure Monitor는 인프라와 앱을 위한 telemetry/metrics/log 모니터링 및 경고(alerting)를 위한 것이며, SIEM/SOAR가 아닙니다(다만 Sentinel은 Azure Monitor의 일부인 Log Analytics workspaces를 사용할 수 있습니다).
HOTSPOT - 문장을 올바르게 완성하는 답을 선택하세요. 핫 영역:
Compliance Manager는 조직의 규정 준수 데이터를 ______ 평가합니다.
정답: A (지속적으로). Compliance Manager는 테넌트의 현재 구성과 사용 가능한 신호를 기반으로 기술적 통제를 자동으로 평가하여 규정 준수 데이터를 지속적으로 평가합니다. 설정이 변경되면(예: MFA 활성화, 보존 정책 조정, 또는 DLP 구성) 규정 준수 상태와 점수가 새로운 상태를 반영하도록 업데이트될 수 있습니다. 이러한 지속적 평가는 규정 준수를 주기적 이벤트로 취급하기보다 지속적인 규정 준수 관리를 지원합니다. 다른 선택지가 틀린 이유: - B (매월) 및 D (분기별): 이는 고정된 감사 주기를 의미합니다. 조직이 해당 일정으로 규정 준수를 검토하도록 선택할 수는 있지만, Compliance Manager 자체는 지속적인 평가와 추적을 제공하도록 설계되었습니다. - C (요청 시): 보고서를 생성하거나 대시보드를 요청 시 검토할 수는 있지만, 기본 평가가 요청할 때만 수행되는 것으로 제한되지는 않으며, 서비스 운영의 일부로 지속적으로 유지됩니다.
HOTSPOT - 다음 각 진술에 대해, 진술이 참이면 Yes를 선택합니다. 그렇지 않으면 No를 선택합니다. 참고: 각 정답 선택은 1점입니다. 핫 영역:
가상 네트워크당 Azure Bastion을 하나 생성할 수 있습니다.
예. Azure Bastion은 전용 AzureBastionSubnet을 사용하여 특정 virtual network의 resource로 배포되므로, 개별 virtual machine이 아니라 단일 VNet에 연결됩니다. 기초 시험의 표현에서는 이를 virtual network당 하나의 Bastion deployment로 간주합니다. "No"는 올바르지 않습니다. Bastion은 VM별 서비스가 아니며, 이 진술은 표준 VNet 범위 deployment 모델과 일치합니다.
Azure Bastion은 RDP를 사용하여 안전한 사용자 연결을 제공합니다.
예. Azure Bastion은 RDP를 사용하여 Windows VM에 대한 안전한 사용자 연결을 제공하며(그리고 SSH를 사용하여 Linux VM에 연결합니다). Bastion은 중개자 역할을 합니다. 사용자 세션은 브라우저(Azure portal)에서 HTTPS를 통해 Bastion으로 설정되고, 이후 Bastion이 VNet 내부에서 RDP(TCP 3389)를 사용하여 대상 VM에 연결합니다. 이것이 안전하다고 간주되는 이유: VM에 public IP를 통해 인터넷에 RDP를 직접 노출할 필요가 없고, 일반적으로 인터넷에서 3389를 허용하는 inbound NSG 규칙도 필요하지 않습니다. 이는 공격 표면을 줄이고 노출된 RDP 엔드포인트에 대한 brute-force 공격과 같은 일반적인 위협을 완화하는 데 도움이 됩니다. “아니요”가 틀린 이유: RDP는 Bastion이 지원하는 주요 프로토콜 중 하나이며(SSH와 함께) 명시적으로 지원됩니다.
Azure Bastion은 Azure portal을 사용하여 Azure virtual machine에 대한 보안 연결을 제공합니다.
예. Azure Bastion의 핵심 기능 중 하나는 Azure portal에서 직접 Azure virtual machine에 대한 보안 연결을 제공하는 것입니다. 사용자는 portal에서 세션을 시작하며, 연결은 TLS(HTTPS/443)를 통해 Bastion 서비스로 설정되고, 이후 Bastion 서비스가 VNet 내 private IP를 통해 RDP 또는 SSH를 사용하여 VM에 연결합니다. 이는 시험에서의 핵심 포인트입니다. Bastion은 VM에 public IP를 요구하지 않고, 인터넷에 인바운드 관리 포트를 열지 않은 상태로 “portal 내” RDP/SSH를 가능하게 합니다. 또한 관리 액세스를 중앙화하고 제어함으로써 보안 모범 사례를 지원합니다. “아니요”가 틀린 이유: Azure portal을 통한 연결은 Bastion의 대표적인 사용자 경험입니다(일부 tier/기능은 native client 시나리오도 지원할 수 있지만). portal 기반의 보안 연결은 서비스 설명의 근본적인 요소입니다.
HOTSPOT - 다음 각 문장에 대해, 문장이 참이면 Yes를 선택하십시오. 그렇지 않으면 No를 선택하십시오. 참고: 각 정답 선택은 1점입니다. 핫 영역:
Microsoft Intune은 Android 디바이스를 관리하는 데 사용할 수 있습니다.
예. Microsoft Intune은 Mobile Device Management (MDM)을 사용하여 Android 디바이스를 관리할 수 있습니다. Intune을 사용하면 조직은 Android 디바이스(Work Profile for BYOD, Fully Managed, Dedicated, Corporate-Owned Work Profile과 같은 Android Enterprise 시나리오 포함)를 등록한 다음 구성 프로필, 규정 준수 정책, 앱 보호 정책을 적용할 수 있습니다. 여기에는 PIN/생체 인식, 암호화, OS 버전 최소 요구 사항 적용, 루팅된 디바이스 차단과 같은 요구 사항을 강제하는 것이 포함됩니다. Intune은 또한 Managed Google Play에서 앱을 배포 및 관리하고, 앱 보호 정책(MAM)을 사용하여 앱 간 데이터 이동을 제어할 수 있으며, 경우에 따라 전체 디바이스 등록 없이도 가능합니다. 따라서 이 문장은 Android가 Intune 엔드포인트 관리에서 1차적으로 지원되는 플랫폼이므로 참입니다.
Microsoft Intune은 Azure subscriptions를 프로비저닝하는 데 사용할 수 있습니다.
아니요. Microsoft Intune은 Azure subscriptions를 프로비저닝하는 데 사용되지 않습니다. subscriptions 프로비저닝은 Azure에서 수행되는 관리 및 거버넌스 작업입니다(예: Azure portal, Azure billing/account administration, Azure Resource Manager, management groups, 그리고 ARM/Bicep/Terraform 같은 자동화 도구를 통해). Intune의 범위는 엔드포인트 및 애플리케이션 관리입니다. 즉, 디바이스 등록, 앱 배포, 설정 구성, 디바이스 규정 준수 평가 등을 수행합니다. Intune은 Microsoft Entra ID (Azure AD) 및 Conditional Access와 통합되며(여기서 디바이스 규정 준수는 클라우드 앱에 대한 액세스를 허용/차단하는 신호로 사용될 수 있음), Azure subscriptions를 생성하거나 할당하지는 않습니다. 따라서 이 진술은 엔드포인트 관리(Intune)와 클라우드 subscription 프로비저닝 및 거버넌스(Azure 플랫폼 기능)를 혼동하고 있으므로 거짓입니다.
Microsoft Intune은 조직 소유 디바이스와 개인 디바이스를 관리하는 데 사용할 수 있습니다.
예. Microsoft Intune은 조직 소유(회사) 디바이스와 개인(BYOD) 디바이스를 모두 관리할 수 있습니다. 이는 SC-900에서 다루는 Intune의 핵심 개념으로, 적절한 제어를 통해 다양한 소유 모델을 지원하는 것입니다. 회사 디바이스의 경우, Intune은 구성 기준선, 준수 정책, 앱 배포, 디바이스 제한, 그리고(플랫폼에 따라) 원격 초기화 또는 재설정과 같은 작업을 포함하여 전체 디바이스 관리(MDM)를 적용할 수 있습니다. 개인 디바이스의 경우, Intune은 일반적으로 Android Work Profile 또는 iOS User Enrollment와 같은 BYOD 친화적 접근 방식 및/또는 Mobile Application Management (MAM) 앱 보호 정책을 사용하여 디바이스 전체를 완전히 제어하지 않고도 관리되는 앱 내에서 조직 데이터를 보호합니다. 이러한 유연성은 조직이 보안과 사용자 프라이버시의 균형을 맞추면서도 준수 요구 사항을 충족할 수 있게 해주므로, 해당 진술은 참입니다.
