모든 답안은 3개의 최고 AI 모델로 교차 검증하여 최고의 정확도를 보장합니다. 선택지별 상세 해설과 심층 문제 분석을 제공합니다.
GPT Pro
Claude Opus
Gemini Pro
선택지별 상세 해설
심층 문제 분석
3개 모델 합의 정확도
연습 문제
1
문제 1
귀사는 10,000개가 넘는 IoT 디바이스의 경고를 관리하기 위해 Azure Sentinel을 사용합니다.
회사 보안 관리자는 많은 수의 incident로 인해 보안 위협을 추적하는 것이 점점 더 어려워지고 있다고 보고합니다.
위협 조사를 단순화하기 위한 custom visualization을 제공하고 machine learning을 사용하여 위협을 추론할 수 있는 솔루션을 권장해야 합니다.
권장 사항에 무엇을 포함해야 합니까?
Microsoft Sentinel의 built-in queries는 분석가가 일반적인 시나리오를 빠르게 hunting하거나 조사할 수 있도록 도와주는 미리 작성된 KQL query입니다. 속도와 일관성을 향상시키지만, 주로 query template이며 advanced custom visualization이나 machine learning environment를 본질적으로 제공하지는 않습니다. triage와 hunting에는 유용하지만, ML을 사용해 위협을 추론해야 한다는 요구 사항은 충족하지 못합니다.
Microsoft Sentinel의 Livestream은 이벤트가 도착하는 즉시 near-real-time으로 모니터링하는 데 사용되며, 분석가가 활동을 관찰하고 진행 중인 조사 중 빠르게 pivot할 수 있도록 도와줍니다. 모니터링을 단순화할 수는 있지만, 표준 query 결과를 넘어서는 custom visualization을 구축하도록 설계된 것은 아니며, 위협 추론을 위한 machine learning model을 실행할 수 있는 notebook 스타일 environment도 제공하지 않습니다.
Notebooks(Microsoft Sentinel과 통합된 Jupyter notebooks)는 Python 및 data science library를 사용한 advanced hunting과 조사를 위해 설계되었습니다. custom visualization, enrichment, 대규모 dataset 전반의 correlation, 그리고 machine learning 기법(예: anomaly detection, clustering) 적용을 통해 위협을 추론할 수 있습니다. 이는 custom visualization과 IoT 규모에서의 ML 기반 추론이라는 두 요구 사항을 모두 직접 충족합니다.
Microsoft Sentinel의 Bookmarks는 분석가가 흥미로운 이벤트, query 결과 또는 조사 artifact를 저장하고 태그 지정하여 증거를 보존하고 협업할 수 있게 해줍니다. 조사 관리와 결과 문서화에는 도움이 되지만, custom visualization 기능이나 machine learning 기반 analytics는 제공하지 않습니다. Bookmarks는 advanced analytics보다는 조사 workflow와 기록 보관에 관한 기능입니다.
문제 분석
핵심 개념:
이 문제는 기본 KQL query를 넘어서는 Microsoft Sentinel 조사 도구, 특히 대규모 환경에서 custom visualization과 machine learning 기반 위협 추론을 지원하는 기능을 테스트합니다. Sentinel에서는 이것이 Notebooks(Sentinel/Log Analytics와 통합된 Jupyter notebooks)로 제공되며, advanced analytics, enrichment, visualization을 지원합니다.
정답인 이유:
10,000개 이상의 IoT 디바이스에서 발생하는 경고를 처리하려면 분석가는 조사 복잡성을 줄이고 data science 기법을 적용할 수 있는 방법이 필요합니다. Microsoft Sentinel Notebooks는 Log Analytics에서 데이터를 가져오고, 외부 소스로 enrichment를 수행하며, ML model(예: clustering, anomaly detection, classification)을 실행하고, custom visualization(timeline, graph, entity relationship, geo map)을 생성할 수 있는 interactive environment(일반적으로 Python)를 제공합니다. 이는 “custom visualization 제공” 및 “machine learning을 사용한 위협 추론” 요구 사항과 직접적으로 일치합니다.
주요 기능 및 모범 사례:
- Notebooks는 Azure Machine Learning/Jupyter 기반이며 API와 Log Analytics workspace를 통해 Sentinel 데이터와 통합됩니다.
- 반복 가능한 조사 playbook을 가능하게 합니다. parameterized notebook은 많은 유사 incident에 대한 triage를 표준화할 수 있습니다.
- advanced visualization(예: matplotlib/plotly) 및 graph analysis(예: 디바이스, IP, alert 간 network relationship)를 지원하며, 이는 IoT 규모의 correlation에 유용합니다.
- Azure Well-Architected 관점에서 notebooks는 Operational Excellence(반복 가능한 분석), Reliability(일관된 workflow), Security(더 나은 탐지/조사 심층도)를 향상시킵니다. notebook 액세스와 data connector에는 RBAC와 least privilege를 사용해야 합니다.
일반적인 오해:
built-in queries와 bookmarks는 조사 효율성에 도움이 되지만, 완전한 ML 지원 custom visualization environment를 제공하지는 않습니다. Livestream은 near-real-time monitoring 및 hunting에 초점을 맞추며, ML 기반 추론과 풍부한 custom visual에는 적합하지 않습니다.
시험 팁:
Sentinel에서 “custom visualization”과 “machine learning”이 함께 나오면 Notebooks를 떠올리십시오. “증거/중요 결과 저장”이 나오면 Bookmarks를 떠올리십시오. “real-time view”가 나오면 Livestream을 떠올리십시오. “KQL 시작점”이 나오면 built-in queries를 떠올리십시오.
이동 중에도 모든 문제를 풀고 싶으신가요?
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
Cloud Pass를 다운로드하고 모든 Microsoft SC-200 학습 문제를 무료로 이용하세요.
이동 중에도 모든 문제를 풀고 싶으신가요?
무료 앱 받기
Cloud Pass를 무료로 다운로드하세요 — 모의고사, 학습 진도 추적 등을 제공합니다.
2
문제 2
참고: 이 질문은 동일한 시나리오를 제시하는 일련의 질문 중 일부입니다. 시리즈의 각 질문에는 명시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 질문 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 질문 세트에는 올바른 솔루션이 없을 수도 있습니다.
이 섹션의 질문에 답한 후에는 해당 질문으로 돌아갈 수 없습니다. 따라서 이러한 질문은 검토 화면에 표시되지 않습니다.
사용자는 Azure Security Center를 사용합니다.
Security Center에서 보안 경고를 받습니다.
Security Center에서 경고를 해결하기 위한 권장 사항을 확인해야 합니다.
솔루션: Regulatory compliance에서 보고서를 다운로드합니다.
이것이 목표를 충족합니까?
예는 오답입니다. Regulatory compliance 보고서는 개별 보안 경고를 해결하기 위한 권장 사항을 확인하는 의도된 메커니즘이 아니기 때문입니다. 이러한 보고서는 프레임워크에 대한 규정 준수 요약을 제공하고 제어 관련 권장 사항을 포함할 수는 있지만, 기본적인 경고 수정 워크플로로 기능하지는 않습니다. 목표를 충족하려면 사용자는 Security Center/Defender for Cloud에서 경고와 관련 권장 사항에 직접 액세스해야 합니다.
아니요가 정답인 이유는 Regulatory compliance에서 보고서를 다운로드해도 보안 경고를 해결하는 데 필요한 경고별 권장 사항이 제공되지 않기 때문입니다. Regulatory compliance는 환경 전반의 표준, 제어 및 전반적인 규정 준수 상태에 중점을 둡니다. 보안 경고는 Security Center/Defender for Cloud 내의 경고 세부 정보와 관련 권장 사항에서 조사해야 하며, 여기서 수정 지침은 실제 경고 컨텍스트에 연결됩니다.
문제 분석
핵심 개념:
이 질문은 Azure Security Center(현재 Microsoft Defender for Cloud)에서 보안 경고를 조사하고 수정하는 방법을 테스트합니다. 경고별 수정 지침은 일반적으로 보안 경고 자체 또는 workload protection/security alerts 환경의 관련 권장 사항에서 액세스하며, regulatory compliance 보고서를 다운로드해서 액세스하는 것이 아닙니다.
이 솔루션이 올바르지 않은 이유:
Security Center의 Regulatory compliance는 Azure CIS, NIST 또는 PCI DSS와 같은 규정 준수 표준에 대해 환경을 평가하는 데 사용됩니다. Regulatory compliance에서 보고서를 다운로드하면 규정 준수 상태 요약 및 제어 상태를 제공하지만, 특정 보안 경고를 해결하기 위한 권장 사항을 확인하는 워크플로로 사용되지는 않습니다. 따라서 Regulatory compliance를 사용하여 경고를 해결하는 것은 명시된 목표를 충족하지 않습니다.
주요 기능 및 모범 사례:
경고를 조사하려면 Security Center/Defender for Cloud에서 경고 세부 정보를 열고 경고 설명, 영향을 받는 리소스, 조사 단계 및 수정 지침을 검토합니다. 보안 권장 사항은 일반적으로 Recommendations 영역에 표시되거나 경고 컨텍스트에서 직접 연결됩니다. Regulatory compliance는 개별 경고를 분류하는 것보다 거버넌스, 감사 및 표준 준수 추적에 더 적합합니다.
일반적인 오해:
흔한 실수는 Security Center의 모든 권장 사항을 Regulatory compliance를 통해 사용할 수 있다고 가정하는 것입니다. 실제로 규정 준수 권장 사항은 표준 및 제어에 매핑되는 반면, 경고 수정 지침은 경고를 트리거한 특정 위협 또는 잘못된 구성에 연결됩니다. 이들은 관련은 있지만 서로 다른 환경입니다.
시험 팁:
SC-200의 경우, 경고 조사 도구와 규정 준수 보고 도구를 구분하세요. 작업이 특정 경고를 해결하거나 조사하는 것이라면 Security alerts, incident details 및 Recommendations를 떠올리세요. 작업이 표준 준수를 입증하거나 감사/규정 준수 증거를 내보내는 것이라면 Regulatory compliance를 떠올리세요.
3
문제 3
(2개 선택)
Azure Sentinel을 구성하고 있습니다.
의심스러운 IP address에서 sign-in이 감지될 때마다 channel에 Microsoft Teams 메시지를 보내야 합니다.
Azure Sentinel에서 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 나타냅니다.
참고: 각 정답 선택에는 1점이 부여됩니다.
playbook 추가가 필요한 이유는 Microsoft Sentinel이 Azure Logic Apps 기반의 playbook을 사용하여 응답 작업을 자동화하기 때문입니다. playbook에는 트리거될 때 channel에 직접 메시지를 게시하는 Microsoft Teams connector를 포함할 수 있습니다. 이것이 실제로 알림 작업을 수행하는 구성 요소입니다. playbook이 없으면 Sentinel에는 Teams 메시지를 보내기 위한 정의된 workflow가 없습니다.
incident에 playbook을 연결하는 것은 관련 보안 이벤트가 감지되어 incident로 표시될 때 playbook이 실행되도록 하는 데 필요합니다. Sentinel에서 automation은 incident 처리와 연결되어 있으므로 analytics rule에 의해 생성된 감지에 대응하여 playbook이 실행될 수 있습니다. 이 연결을 통해 수동 실행이 아니라 Teams 알림이 자동으로 트리거되도록 보장합니다. 이것은 감지를 응답 workflow에 연결하는 운영 단계입니다.
Microsoft Sentinel에서 UEBA라고도 하는 Entity behavior analytics는 시간 경과에 따라 사용자와 entity를 분석하여 비정상적인 동작을 식별하는 데 도움이 됩니다. 이는 조사 컨텍스트를 향상시키고 감지에 기여할 수 있지만 Microsoft Teams 메시지를 보내는 메커니즘을 제공하지는 않습니다. 이 문제는 specifically 알림 automation에 관한 것이며, 이를 위해서는 playbook 기반 응답이 필요합니다. 따라서 이 기능을 사용하도록 설정하는 것은 메시징 요구 사항을 충족하지 않습니다.
Microsoft Sentinel의 workbook은 데이터 시각화, dashboard 및 보고에 사용됩니다. 이는 분석가가 의심스러운 sign-in 또는 추세를 모니터링하는 데 도움이 될 수 있지만 Microsoft Teams에 게시하는 것과 같은 자동화된 작업을 실행하지는 않습니다. workbook은 응답 메커니즘이 아니라 수동적인 분석 도구입니다. 따라서 workbook을 만드는 것은 이벤트가 발생할 때 channel 메시지를 보내야 한다는 요구 사항을 충족하지 못합니다.
Fusion rule은 Microsoft Sentinel의 기본 제공 상관관계 기능으로, 여러 개의 낮은 신뢰도의 alert를 더 높은 신뢰도의 incident로 결합합니다. 이는 복잡한 공격의 감지를 향상시킬 수 있지만, 그 자체로 Microsoft Teams에 알림을 보내지는 않습니다. Fusion이 incident를 생성하더라도 메시지를 게시하려면 여전히 playbook과 automation 연결이 필요합니다. 따라서 Fusion을 사용하도록 설정하는 것은 필요한 응답 작업을 직접적으로 해결하지 않습니다.
문제 분석
핵심 개념:
이 문제는 보안 이벤트가 감지될 때 Microsoft Teams와 같은 외부 협업 도구에 알리기 위해 Microsoft Sentinel이 playbook과 automation을 사용하여 응답 작업을 자동화하는 방법에 대한 이해를 평가합니다.
정답인 이유:
의심스러운 sign-in이 감지될 때 Microsoft Teams 메시지를 보내려면 Microsoft Sentinel playbook을 사용합니다. Sentinel의 playbook은 Azure Logic Apps를 기반으로 하며 Teams에 메시지 게시, 이메일 전송, 티켓 생성 또는 다른 서비스 호출과 같은 자동화된 작업을 수행할 수 있습니다. playbook을 만든 후에는 감지가 발생할 때 실행되도록 관련 incident 또는 automation 흐름에 연결해야 합니다. 이 두 단계가 모두 없으면 workflow는 존재하더라도 incident에 대응하여 트리거되지 않습니다.
주요 기능 / 구성:
- Microsoft Sentinel playbook은 Azure Logic Apps를 기반으로 합니다.
- playbook은 기본 제공 connector를 사용하여 Microsoft Teams와 통합할 수 있습니다.
- Sentinel automation은 incident가 생성되거나 업데이트될 때 playbook을 트리거할 수 있습니다.
- incident는 analytics rule에서 생성되며, 자동화된 응답 작업을 해당 incident에 연결할 수 있습니다.
- playbook을 연결하면 지정된 보안 이벤트가 감지될 때 알림 작업이 자동으로 실행됩니다.
일반적인 오해:
- Entity Behavior Analytics를 사용하도록 설정하면 조사를 풍부하게 하는 데 도움이 되지만 Teams 알림을 보내지는 않습니다.
- workbook은 시각화 및 보고용이지 자동화된 응답용이 아닙니다.
- Fusion은 alert를 상호 연관시켜 신뢰도 높은 incident를 생성하지만, 그 자체로 Teams 메시지를 전달하지는 않습니다.
- playbook만 만드는 것으로는 충분하지 않으며, incident workflow 또는 automation rule에도 연결해야 합니다.
시험 팁:
- 문제에서 Sentinel의 자동화된 응답을 묻는다면 playbook을 떠올리십시오.
- 요구 사항에 Teams, email, ServiceNow 또는 기타 외부 시스템에 대한 알림이 포함되어 있다면 일반적으로 Azure Logic Apps 통합이 관련됩니다.
- workbook = dashboard/시각화이며, 응답 자동화가 아닙니다.
- Fusion 및 UEBA는 감지 품질을 향상시키지만 알림 전달은 하지 않습니다.
- 문제가 automation 생성과 트리거를 모두 묻는지 주의 깊게 보십시오. 종종 두 단계가 모두 필요합니다.
4
문제 4
참고: 이 문제는 동일한 시나리오를 제시하는 일련의 문제 중 일부입니다. 시리즈의 각 문제에는 제시된 목표를 충족할 수 있는 고유한 솔루션이 포함되어 있습니다. 일부 문제 세트에는 둘 이상의 올바른 솔루션이 있을 수 있지만, 다른 문제 세트에는 올바른 솔루션이 없을 수도 있습니다.
이 섹션의 문제에 답한 후에는 해당 문제로 돌아갈 수 없습니다. 따라서 이러한 문제는 검토 화면에 표시되지 않습니다.
Azure Security Center를 사용합니다.
Security Center에서 보안 경고를 받습니다.
Security Center에서 경고를 해결하기 위한 권장 사항을 확인해야 합니다.
솔루션: Security alerts에서 경고를 선택하고, Take Action을 선택한 다음, Prevent future attacks 섹션을 확장합니다.
이것이 목표를 충족합니까?
이 옵션이 정답인 이유는 Azure Security Center에서 보안 경고를 열고 Take Action 환경을 사용하여 수정 지침을 검토할 수 있기 때문입니다. Prevent future attacks 섹션에는 특히 근본 원인을 해결하고 재발 가능성을 줄이는 데 도움이 되는 권장 사항이 포함되어 있습니다. 즉, 제안된 단계는 경고를 해결하거나 완화하는 데 필요한 권장 사항을 실제로 제공합니다. 이는 Security Center 내에서 직접 권장 사항을 확인한다는 목표와 일치합니다.
이 옵션이 오답인 이유는 설명된 솔루션이 실제로 요구 사항을 충족하기 때문입니다. Azure Security Center에서 경고를 선택한 다음 Take Action을 선택하면 조사, 수정 및 예방과 관련된 지침이 표시됩니다. Prevent future attacks 섹션은 해당 경고와 관련된 권장 사항을 확인하는 적절한 위치입니다. 따라서 이 솔루션이 목표를 충족하지 않는다고 말하는 것은 부정확합니다.
문제 분석
핵심 개념:
이 문제는 Azure Security Center(현재는 Microsoft Defender for Cloud의 일부)에서 경고를 조사하고 수정하는 방법에 대한 지식을 평가합니다. 구체적으로, 보안 경고와 관련된 수정 지침 및 권장 사항을 어디에서 찾는지에 초점을 맞춥니다.
정답인 이유:
Azure Security Center에서 보안 경고를 열고 Take Action을 선택하면, 인터페이스에서 대응 지침과 수정 단계를 제공합니다. Prevent future attacks 섹션을 확장하면 유사한 사고가 다시 발생할 가능성을 줄이기 위한 권장 사항이 표시됩니다. 이는 Security Center에서 경고를 해결하기 위한 권장 사항을 확인해야 한다는 요구 사항을 직접적으로 충족합니다. 포털이 경고 워크플로 자체에서 실행 가능한 보안 지침을 제공하기 때문입니다.
주요 기능 / 구성:
- Security alerts는 사고 세부 정보, 영향을 받는 리소스 및 조사 컨텍스트를 제공합니다.
- 경고의 Take Action 영역에는 수정 지침이 포함됩니다.
- Prevent future attacks에는 보안 강화를 수행하고 향후 위험을 줄이기 위한 권장 사항이 포함됩니다.
- Azure Security Center는 경고 조사와 보안 상태 개선 권장 사항을 통합합니다.
- 권장 사항은 현재 노출을 수정하고 지속적인 보호를 개선하는 데 도움이 되도록 설계되었습니다.
일반적인 오해:
- 응시자는 종종 Security alerts와 Recommendations 블레이드를 혼동합니다. Recommendations 영역은 일반적인 보안 상태 문제를 보여주지만, 경고별 수정 지침은 경고 자체에서 직접 액세스할 수 있습니다.
- 일부는 Take Action이 워크플로 또는 자동화 작업에만 사용된다고 생각하지만, 실제로는 수정 및 예방을 위한 지침도 포함합니다.
- 또 다른 일부는 경고가 탐지 세부 정보만 보여준다고 생각하지만, 실제로 Security Center는 권장되는 다음 단계도 제공합니다.
시험 팁:
- 문제가 경고별 수정 지침을 묻는다면, 경고 자체에서 시작하십시오.
- Security Center 경고를 조사할 때는 Take Action을 찾으십시오.
- Prevent future attacks는 보안 강화 권장 사항이 일반적으로 표시되는 위치입니다.
- 일반적인 보안 권장 사항과 특정 경고에 연결된 권장 사항을 구분하십시오.
5
문제 5
DRAG DROP -
Azure 구독이 있습니다.
다음 요구 사항을 충족하도록 권한을 위임해야 합니다:
✑ Azure Defender를 사용 및 사용 안 함으로 설정합니다.
✑ 리소스에 보안 권장 사항을 적용합니다.
해결 방법은 최소 권한 원칙을 사용해야 합니다.
각 요구 사항에 대해 어떤 Azure Security Center 역할을 사용해야 합니까? 정답을 입력하려면 적절한 역할을 올바른 요구 사항으로 끌어다 놓으세요. 각 역할은 한 번, 여러 번 또는 전혀 사용되지 않을 수 있습니다. 콘텐츠를 보려면 창 사이의 분할 막대를 끌거나 스크롤해야 할 수 있습니다.
참고: 각 정답 선택에는 1점이 부여됩니다.
선택 후 배치:
파트 1:
아래 이미지에서 올바른 답을 선택하세요.
올바른 매핑은 다음과 같습니다: Azure Defender 활성화 및 비활성화 -> Security Admin; 리소스에 보안 권장 사항 적용 -> Subscription Contributor. Microsoft Defender for Cloud의 Security Admin은 전체 subscription 소유권 없이도 보안 정책과 Defender 플랜을 관리할 수 있으며, 여기에는 Azure Defender/Defender for Cloud 보호를 활성화하거나 비활성화하는 작업이 포함됩니다. 보안 권장 사항을 적용하는 작업은 일반적으로 기본 Azure 리소스 구성을 변경하므로, 해당 리소스를 수정하려면 subscription에 대한 Contributor 권한이 필요합니다. Resource Group Owner는 필요한 것보다 더 많은 권한을 가지며, Subscription Owner는 액세스 관리 기능도 부여하므로 최소 권한 원칙을 초과합니다.
6
문제 6
HOTSPOT -
Azure Sentinel을 배포합니다.
Azure에서 Microsoft Teams 및 Linux virtual machines를 모니터링하기 위해 Azure Sentinel에서 connector를 구현해야 합니다. 솔루션은 관리 작업을 최소화해야 합니다.
각 workload에 대해 어떤 data connector type을 사용해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요.
참고: 각 정답 선택에는 1점이 부여됩니다.
Hot Area:
파트 1:
Microsoft Teams: ______
Microsoft Teams 로그는 Microsoft 365 감사 데이터(Unified Audit Log) 및 관련 Microsoft 365 서비스 telemetry를 통해 수집됩니다. Microsoft Sentinel에서 이러한 SaaS 신호를 위한 기본 제공 connector는 Office 365 (Microsoft 365) data connector입니다. 이는 기본 통합이므로 관리 노력 측면에서 가장 적은 옵션입니다. connector를 활성화하고, 필요한 권한을 부여하면, 사용자 지정 ingestion을 구축하지 않아도 Sentinel이 관련 감사/활동 데이터를 가져옵니다.
다른 선택지가 틀린 이유:
- A. 사용자 지정: 사용자 지정 ingestion pipeline(Graph API polling, custom tables, DCRs 등)을 생성하고 유지해야 하므로 노력이 증가합니다.
- C. 보안 이벤트: Teams가 아니라 Windows 보안 event logs를 대상으로 합니다.
- D. Syslog: Microsoft 365 SaaS 감사 로그가 아니라 syslog 기반 device/host(일반적으로 Linux/network devices)를 위한 것입니다.
파트 2:
Azure의 Linux virtual machines: ______
Linux virtual machines의 경우, 표준 로그 소스는 syslog입니다(예: auth, authpriv, daemon, kern). Microsoft Sentinel에서 Linux 로그 수집은 일반적으로 Log Analytics agent 또는 Azure Monitor Agent (AMA)를 통해 Syslog collection을 활성화하고, 해당 syslog 이벤트를 Sentinel에 연결된 Log Analytics workspace로 전송하도록 구성됩니다. 이는 Linux의 기본 로깅 방식 및 Sentinel의 기본 제공 syslog 수집 패턴과 일치하므로, 보기 중 가장 직접적이고 가장 적은 노력으로 구성할 수 있는 connector 유형입니다.
다른 보기가 틀린 이유:
- A. Custom: syslog 형식이 아니거나 특수한 수집 요구 사항이 있는 경우가 아니라면 불필요하며, 운영 오버헤드를 증가시킵니다.
- B. Office 365: Microsoft 365 서비스에 적용되며, IaaS Linux VM에는 해당하지 않습니다.
- C. Security Events: 주로 Windows Event Logs(Security log)에 사용되며, Linux에 대한 일반적인 connector 선택은 아닙니다.
7
문제 7
(2개 선택)
Azure Sentinel을 구성하고 있습니다.
Azure Sentinel에서 sign-in risk event를 나타내는 incident가 활성화될 때마다 channel에 Microsoft Teams 메시지를 보내야 합니다.
Azure Sentinel에서 어떤 두 가지 작업을 수행해야 합니까? 각 정답은 솔루션의 일부를 나타냅니다.
참고: 각 정답 선택에는 1점이 부여됩니다.
Entity behavior analytics (UEBA)는 entity(user, host)의 행동을 분석하고 incident에 insight를 추가하여 비정상적인 행동을 식별하는 데 도움을 줍니다. 그러나 UEBA는 Teams 메시지 전송과 같은 outbound action을 수행하지 않습니다. 이는 detection/enrichment 기능이지 incident notification을 위한 automation 메커니즘이 아닙니다.
playbook을 analytics rule에 연결하면 해당 rule이 alert/incident를 생성할 때 playbook이 자동으로 실행됩니다. 이것이 Logic App workflow를 automated response로 전환하는 핵심 단계입니다. 이 연결(또는 automation rule)이 없으면 sign-in risk incident가 활성화될 때 Teams notification이 트리거되지 않습니다.
Fusion rule은 ML을 사용하여 여러 alert를 더 높은 신뢰도의 incident로 결합하는 Microsoft Sentinel correlation 기능입니다. incident 품질을 향상시킬 수는 있지만 Teams로 notification을 보내지는 않습니다. Fusion은 detection 및 correlation에 관한 것이지 automated response action에 관한 것이 아닙니다.
Microsoft Teams channel에 메시지를 게시하는 작업을 구현하려면 playbook을 추가(생성)해야 합니다. Sentinel에서 playbook은 Teams connector를 사용하여 channel 메시지를 게시할 수 있는 Logic Apps입니다. 이것이 incident가 생성/활성화될 때 실행될 실제 workflow를 제공합니다.
workbook은 monitoring 및 investigation을 위한 dashboard와 interactive report를 제공합니다. action을 실행하거나 response를 자동화하지는 않습니다. workbook을 생성하면 sign-in risk incident를 시각화하는 데는 도움이 될 수 있지만, incident가 활성화될 때 Teams 메시지를 보내지는 않습니다.
문제 분석
핵심 개념:
이 문제는 Playbook (Azure Logic Apps)을 사용한 Microsoft Sentinel incident response automation을 테스트합니다. Sentinel에서 analytics rule은 alert를 생성하고 incident를 만들 수 있습니다. 특정 incident 유형(sign-in risk event)이 활성화될 때 Microsoft Teams에 알리려면, playbook으로 응답을 자동화하고 incident가 생성/업데이트될 때 실행되도록 해야 합니다.
정답이 맞는 이유:
(1) Teams channel에 메시지를 게시하는 playbook을 생성/추가하고, (2) 해당 playbook을 analytics rule(또는 incident trigger)에 연결하여 rule이 incident를 생성할 때 자동으로 실행되도록 해야 합니다. Sentinel에서 playbook은 outbound notification(Teams, email, ServiceNow 등)을 위한 메커니즘입니다. workspace에 playbook이 단순히 존재하는 것만으로는 충분하지 않으며, 적절한 시점에 실행되도록 rule(automation)에 연결되어야 합니다.
주요 기능 및 구성 포인트:
- Playbook은 Azure Logic Apps를 기반으로 합니다. Teams의 경우 일반적으로 “Post message in a chat or channel”과 같은 Microsoft Teams connector action을 사용합니다.
- playbook trigger는 template 및 요구 사항에 따라 일반적으로 “When a response to an Azure Sentinel alert is triggered”(alert 기반) 또는 “When an incident is created/updated”(incident 기반)입니다.
- 연결은 analytics rule의 “Automated response”(또는 Sentinel의 Automation rules)를 통해 수행됩니다. 시험 관점에서는 incident를 트리거한 analytics rule에 playbook을 연결하는 것이 설명된 직접적인 연결 방식입니다.
- 권한을 확인해야 합니다: Sentinel playbook에는 적절한 role assignment(예: Microsoft Sentinel Responder/Contributor 및 Logic App 권한)와 Teams용 connector authorization이 필요합니다.
일반적인 오해:
- Fusion 또는 Entity Behavior Analytics를 활성화하면 detection/correlation은 향상되지만 notification을 보내지는 않습니다.
- workbook은 visualization/reporting용이지 automation용이 아닙니다.
- playbook을 생성만 하고 rule(또는 automation rule)에 연결하지 않으면 메시지가 자동으로 트리거되지 않습니다.
시험 팁:
“alert/incident가 발생할 때 메시지 보내기 / ticket 생성 / webhook 호출”과 같은 요구 사항이 나오면, Playbook (Logic App) + analytics rule automated response 또는 automation rule을 통한 연결을 떠올리세요. detection 기능(Fusion, UEBA)과 response automation(playbook)을 구분하세요.
8
문제 8
Azure Sentinel에서 hunting query를 생성합니다.
hunting query가 query에서 일치 항목을 감지하는 즉시 Azure portal에서 알림을 받아야 합니다. 이 솔루션은 노력을 최소화해야 합니다.
무엇을 사용해야 합니까?
playbook은 알림 전송과 같은 자동화된 작업을 위해 설계된 유일한 옵션입니다. Microsoft Sentinel에서 playbook은 Azure Logic Apps를 기반으로 하며, 보안 이벤트가 감지될 때 분석가에게 알리거나 응답 작업을 수행하는 데 일반적으로 사용됩니다. hunting query 자체는 기본 alert 소스가 아니지만, 알림을 생성하도록 탐지 흐름을 운영 환경에 적용하려면 automation에 의존해야 하며, 선택지 중 관련된 Sentinel 기능은 playbook입니다. 따라서 최소한의 추가 사용자 지정 분석 도구로 알림을 받기 위한 가장 적절한 답입니다.
notebook은 대화형 조사, enrichment, 고급 분석에 사용되며, 주로 Python 및 data science workflow와 함께 사용됩니다. hunting query를 지속적으로 모니터링하거나 일치 항목이 발생할 때 Azure portal에서 알림을 생성하도록 설계되지 않았습니다. notebook을 사용하면 수동 실행과 분석 설정이 필요하므로 노력을 최소화하기보다 오히려 증가시킵니다. 따라서 즉각적인 알림 요구 사항을 충족하지 않습니다.
livestream은 분석가가 query 결과가 거의 실시간으로 업데이트되는 것을 볼 수 있게 해 주며, 이는 활성 조사 중에 유용합니다. 그러나 이는 주로 시각화 및 모니터링 환경이지, Azure portal에서 alert를 발생시키는 알림 메커니즘은 아닙니다. 문제는 구체적으로 알림을 받는 것을 요구하며, livestream은 그 목적을 위한 표준 alerting 또는 automation 기능이 아닙니다. 따라서 여기서는 최선의 답이 아닙니다.
bookmark는 조사 중 흥미로운 이벤트나 결과를 저장하여 나중에 다시 보거나 incident에 첨부할 수 있도록 하는 데 사용됩니다. query를 실행하거나, 향후 일치 항목을 모니터링하거나, 알림을 생성하지 않습니다. bookmark는 순수한 조사 아티팩트이며 자동화된 탐지 또는 alerting 기능을 제공하지 않습니다. 따라서 제시된 요구 사항을 충족할 수 없습니다.
문제 분석
핵심 개념: Microsoft Sentinel hunting query는 주로 조사 목적이며, 일치 항목을 찾았다고 해서 기본적으로 alert 또는 portal 알림을 생성하지는 않습니다. 일치하는 활동이 감지될 때 알림을 받으려면 alerting 또는 incident workflow에 연결된 automation이 필요합니다. 정답인 이유: 제공된 옵션 중에서 playbook만이 알림 전송 및 Sentinel의 응답 작업 자동화와 관련된 기능입니다. 주요 기능: playbook은 Azure Logic Apps를 기반으로 하며, Sentinel alert 또는 incident에 의해 트리거될 때 이메일, Teams 메시지를 보내거나 다른 응답 작업을 수행할 수 있습니다. 일반적인 오해: livestream은 query 결과를 대화형으로 거의 실시간에 가깝게 보는 데 사용되지만, 표준 알림 메커니즘은 아닙니다. notebook과 bookmark는 조사 보조 도구이지 alerting 도구가 아닙니다. 시험 팁: 요구 사항이 알림 또는 자동화된 응답이라면 playbook/automation을 떠올리십시오. 요구 사항이 탐색적 분석이라면 hunting query, notebook, bookmark를 떠올리십시오.
9
문제 9
HOTSPOT -
Fabrikam에 대한 Azure Defender 경고의 수정 조치를 권장해야 합니다.
각 위협에 대해 무엇을 권장해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요.
참고: 각 정답 선택에는 1점이 부여됩니다.
Hot Area:
파트 1:
내부 위협: ______
정답: B. key vault의 access policy 설정을 수정합니다.
Key Vault에 대한 “internal threat” 경고는 일반적으로 이미 access 권한이 있는 principal이 의심스러운 작업을 수행하고 있음을 의미합니다(예: 비정상적인 secret 검색 패턴, 일반적이지 않은 위치에서의 access, 또는 과도한 권한 사용). 가장 직접적인 대응 방법은 기존 access policy(또는 RBAC가 활성화된 vault의 경우 RBAC role assignment)를 수정하여 권한을 줄이거나 바로잡고 최소 권한 원칙을 적용하는 것입니다. 예를 들어, 광범위한 Secret/Get/List 권한을 제거하고, 필요한 작업으로만 범위를 제한하며, 승인된 identity만 access를 갖도록 해야 합니다.
A가 아닌 이유: Resource lock은 management-plane 변경(delete/update)으로부터 보호하지만, 권한이 있는 identity가 secret/key/certificate를 읽는 것과 같은 data-plane 작업은 방지하지 않습니다.
C가 아닌 이유: 새 access policy를 생성하는 것은 일반적으로 access를 부여할 때 사용되며, 내부 오용 시나리오를 해결하기 위한 방법은 아닙니다. 대응은 보통 새 권한을 추가하는 것이 아니라 기존 권한을 강화하거나 제거하는 것입니다.
파트 2:
외부 위협: ______
정답: B. Key Vault firewall 설정을 수정합니다.
“외부 위협” 경고는 일반적으로 vault가 public internet 또는 신뢰할 수 없는 IP 범위로부터의 액세스 시도에 노출되어 있을 수 있음을 나타냅니다. Key Vault는 선택한 네트워크로 액세스를 제한하고, 특정 public IP만 허용하거나, private endpoint 액세스를 요구할 수 있는 기본 firewall(“Networking” 설정)을 제공합니다. 이러한 설정을 강화하면 공격 표면이 직접적으로 줄어들며, PaaS endpoint에 대한 외부/네트워크 기반 위협에 가장 적합한 대응입니다.
A가 아닌 이유: Azure Firewall는 VNet의 outbound/inbound 트래픽 제어에 도움이 될 수 있지만, public endpoint에 대한 Key Vault 자체 네트워크 제어를 대체하지 않으며 Key Vault 노출 경고에 대한 가장 직접적인 해결책도 아닙니다.
C가 아닌 이유: NSG는 VNet의 subnet/NIC에 적용됩니다. 이는 Key Vault의 public endpoint에 대한 액세스를 제어하지 않으며, vault에 도달할 수 있는 대상을 제한하는 기본 제어 수단도 아닙니다.
10
문제 10
HOTSPOT -
Azure Defender를 사용하는 Azure subscription이 있습니다.
Azure Defender threat alert에 대응하기 위해 Azure Security Center workflow automation을 사용할 계획입니다.
threat remediation을 자동으로 수행할 Azure policy를 만들어야 합니다.
해결 방법에 무엇을 포함해야 합니까? 답하려면, 답안 영역에서 적절한 옵션을 선택하세요.
참고: 각 정답은 1점의 가치가 있습니다.
Hot Area:
파트 1:
사용 가능한 effect를 다음으로 설정하세요: ______
DeployIfNotExists는 필요한 리소스/구성이 없을 경우 policy가 이를 자동으로 배포하도록 해야 할 때 올바른 Azure Policy effect입니다. 이 경우 목표는 자동 위협 remediation에 필요한 구성 요소(예: Defender for Cloud automation configuration 및/또는 Logic App)가 대상 scope에 존재하도록 보장하는 것입니다. DeployIfNotExists는 remediation task를 지원하며, non-compliance가 감지되면 ARM template를 통해 리소스를 생성할 수 있습니다.
Append는 생성/업데이트 중 리소스 요청에 필드를 추가하는 데 사용됩니다(예: tag 추가). 이는 workflow automation 또는 Logic App와 같은 별도의 리소스를 배포하지 않습니다. EnforceRegoPolicy는 policy-as-code 시나리오(OPA/Rego)와 관련이 있으며, Defender for Cloud workflow automation 리소스를 배포하기 위한 표준 메커니즘이 아닙니다. 따라서 DeployIfNotExists만이 자동 배포/remediation 기능으로 이어지는 “Azure policy 생성”에 부합하는 유일한 옵션입니다.
파트 2:
수정을 수행하려면 다음을 사용합니다: ______
workflow automation을 사용하여 Defender for Cloud threat alert에 대응해 수정을 수행하려면, 가장 적합한 것은 Defender for Cloud alert trigger인 “When an Azure Security Center (Defender for Cloud) Alert is created or triggered”가 있는 Azure Logic Apps workflow입니다. 이 트리거는 alert 기반 automation을 위해 특별히 설계되었으며, 자동화된 대응 작업(containment, notification, ticketing, enrichment)을 구현할 때 시험에서 일반적으로 정답으로 사용됩니다.
webhook이 있는 Azure Automation runbook도 automation에 사용할 수 있지만, 이 문맥에서 Defender for Cloud alert 기반 workflow automation에 대해 언급되는 기본/네이티브 패턴은 아니며, 일반적으로 추가 연결 작업(예: action group/Logic App에서 webhook 호출)이 필요합니다. “When a response to an Azure Security Center alert is triggered” 옵션은 Defender for Cloud alert 생성 이벤트에 사용되는 표준 Logic Apps trigger가 아닙니다. 정식 trigger는 alert-created/triggered 이벤트입니다. 따라서 가장 정확한 답은 옵션 B입니다.
