Practice Test #1

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)를 위한 것입니다.

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 선택은 아닙니다.

정답: 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를 부여할 때 사용되며, 내부 오용 시나리오를 해결하기 위한 방법은 아닙니다. 대응은 보통 새 권한을 추가하는 것이 아니라 기존 권한을 강화하거나 제거하는 것입니다.

정답: 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에 도달할 수 있는 대상을 제한하는 기본 제어 수단도 아닙니다.

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 생성”에 부합하는 유일한 옵션입니다.

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입니다.