Practice Test #4

stored access policy는 blob, file, queue 또는 table에 대한 shared access signature를 제어하기 위해 Azure Storage에서 사용됩니다. 이것은 Azure SQL Database Always Encrypted와는 관련이 없습니다. Always Encrypted는 Storage access policy가 아니라 SQL key metadata와 Azure Key Vault 같은 외부 key store에 의존합니다. 따라서 이 옵션은 SQL 데이터 decrypt와 관련이 없습니다.

shared access signature는 Azure Storage 리소스에 대한 delegated access를 부여하며 Azure SQL Database Always Encrypted에서는 사용되지 않습니다. Always Encrypted 데이터의 decryption은 Storage token이 아니라 CEK와 CMK hierarchy에 따라 달라집니다. Azure Key Vault가 관련되어 있더라도 access는 SAS가 아니라 identity와 key permission을 통해 관리됩니다. 따라서 이 시나리오에서 SAS는 관련이 없습니다.

user credentials는 개발자 또는 애플리케이션이 Azure SQL Database에 authenticate할 수 있게 해주지만, decryption에 필요한 Always Encrypted의 두 가지 특정 정보 중 하나는 아닙니다. 이 문제는 CEK와 CMK에 의존하는 encryption architecture에 초점을 맞추고 있습니다. client가 필요한 key metadata와 CMK에 대한 access 권한도 가지고 있지 않다면 authentication만으로는 decryption이 가능하지 않습니다. 따라서 credentials는 운영상 필요할 수는 있지만, 이 문제의 의도된 정답은 아닙니다.

새 subnet을 만드는 것은 요구 사항이 추가 세분화, 주소 공간 분리 또는 서비스용 전용 subnet(예: AzureFirewallSubnet, GatewaySubnet)을 명시적으로 요구할 때만 적절합니다. 이는 routing/NSG/firewall과 함께 사용되지 않는 한 본질적으로 보안 상태를 개선하지 않습니다. 문제의 원인이 기존 subnet에 NSG가 없다는 것이라면, 새 subnet을 추가하는 것은 불필요하며 즉각적인 제어 요구 사항을 충족하지 못합니다.

Subnet11 및 Subnet13에서 NSG를 제거하면 네트워크 세분화가 줄어들고 최소 권한 원칙을 위반합니다. NSG는 일반적으로 인바운드/아웃바운드 흐름을 제한하고 east-west 트래픽을 제어하는 데 필요합니다. 누군가 NSG가 연결 문제를 일으킨다고 가정하면 이 옵션이 그럴듯해 보일 수 있지만, 질문은 VNetwork1의 기술 요구 사항 충족에 관한 것이며, 이는 일반적으로 제어를 추가/적용하는 것을 의미하지 제거하는 것을 의미하지는 않습니다.

VNetwork1에 대해 DDoS protection(일반적으로 DDoS Network Protection Standard)을 구성하면 대규모 volumetric attack 및 protocol attack을 완화하고 향상된 telemetry와 비용 보호를 제공합니다. 그러나 이는 subnet 간 또는 인터넷으로부터 어떤 port/protocol이 허용되는지를 제어하지 않습니다. 요구 사항이 subnet 보안 규칙 또는 트래픽 제한에 관한 것이라면, DDoS protection은 가장 먼저 또는 주요하게 구현해야 하는 제어가 아닙니다.

Azure AD Privileged Identity Management (PIM)는 Global Administrator 또는 Owner와 같은 Azure AD 및 Azure RBAC의 privileged roles에 대해 just-in-time elevation을 제공합니다. 누가 administrative permissions를 활성화할 수 있는지와 그 기간을 제어하는 데 도움이 되지만, VM에 대한 inbound network access는 관리하지 않습니다. 사용자가 PIM을 통해 privileged role을 활성화하더라도 TCP 3389는 여전히 networking rules를 통해 별도로 제어되어야 합니다. 따라서 PIM은 RDP port의 임시 개방 및 차단이 아니라 identity governance를 다룹니다.

application security group (ASG)은 NSG rules가 해당 groups를 더 쉽게 대상으로 지정할 수 있도록 virtual machine NICs를 논리적으로 그룹화하는 데 사용됩니다. 이는 특히 여러 VMs에 동일한 network policy가 필요할 때 rule 관리를 단순화하지만, 요청 기반 또는 시간 제한 access를 제공하지는 않습니다. ASG를 참조하는 NSG rule을 통해 RDP가 허용되면, 관리자가 rule을 변경할 때까지 해당 access는 계속 유지됩니다. 결과적으로 ASG는 security rules를 구성하는 데는 도움이 되지만, authorized user가 access를 요청할 때까지 RDP를 닫아 두어야 한다는 요구 사항은 충족하지 못합니다.

Azure AD Conditional Access는 MFA, compliant devices 또는 trusted locations 요구와 같이 Azure AD로 인증되는 applications 및 services에 대한 sign-in conditions를 평가합니다. 이는 identity layer에서의 authentication 및 authorization 결정에 초점을 맞추며, VM의 network port로 들어오는 inbound traffic 제어에는 초점을 두지 않습니다. TCP 3389에서의 Remote Desktop 노출은 Conditional Access policies가 아니라 NSGs, Azure Firewall 또는 유사한 network controls에 의해 관리됩니다. 따라서 Conditional Access는 사용자가 temporary access를 요청할 때까지 RDP port가 닫혀 있도록 보장할 수 없습니다.

Azure Storage account는 일반적으로 로그를 저렴하게 보관하거나 장기 보존 요구 사항을 충족하기 위한 diagnostic 대상에 사용됩니다. 그러나 Azure Monitor alert rules(특히 log query alerts)는 Storage account의 존재를 요구하지 않습니다. Storage는 보존/보관을 위한 선택 사항이며, Azure Monitor에서 보안 alerts를 생성하기 위한 주요 필수 조건이 아닙니다.

Azure Event Hub는 로그/이벤트를 외부 시스템(예: 타사 SIEM)으로 스트리밍하거나 거의 실시간 event processing에 사용됩니다. diagnostic 대상으로 사용할 수는 있지만, Azure Monitor alerting에는 Event Hubs가 필요하지 않습니다. 이는 통합/스트리밍 선택 사항이지, Azure Monitor 보안 alerts를 위해 Azure subscription을 준비하는 첫 단계가 아닙니다.

Azure Automation account는 runbook, update management(legacy), automation 작업에 사용됩니다. alert action에 의해(예: webhook/logic app를 통해) 호출되어 문제를 수정할 수 있지만, Azure Monitor alerts를 생성하는 데 필요하지는 않습니다. 일반적으로 automation은 alerts가 존재하고 응답 워크플로를 정의한 후에 생성합니다.

Security administrator는 주로 보안 관련 기능(보안 정책, 경고, identity protection 구성, 그리고 범위에 따라 일부 Conditional Access 관련 작업)을 관리합니다. 이 역할은 application lifecycle management를 위한 것이 아니며 일반적으로 application permissions에 대해 테넌트 전체 admin consent를 부여하는 기능을 포함하지 않습니다. 광범위한 권한이 있는 것처럼 들리기 때문에 흔한 오답 유도 선택지이지만, app consent에 필요한 올바른 기능은 아닙니다.

User administrator는 사용자와 그룹을 만들고 관리하며 일부 액세스 관련 작업(예: 암호 재설정 및 사용자 속성)을 처리할 수 있습니다. 그러나 테넌트 수준에서 application consent를 관리하는 데 필요한 권한은 제공하지 않습니다. 관리 역할이기 때문에 그럴듯해 보일 수 있지만, application permission governance보다는 identity objects에 중점을 둡니다.

Application developer(또는 유사한 개발자 중심 권한)는 일반적으로 테넌트 설정(예: 사용자가 애플리케이션을 등록할 수 있는지 여부)에 따라 app registrations를 만들고 관리할 수 있게 합니다. 그러나 권한에 대해 테넌트 전체 admin consent를 제공할 권한은 부여하지 않습니다. 개발자는 권한을 요청할 수는 있지만, 조직에 대해 admin consent를 승인/부여하려면 admin 역할이 필요합니다.

Security administrator는 tenant 전반의 보안 설정, 경고 및 보안 관련 정책을 관리하도록 설계되었습니다. 이 role은 Azure AD Connect 동기화 옵션이나 directory 동기화 동작을 재구성하는 데 필요한 권한을 제공하지 않습니다. 동기화가 보안에 영향을 미치기는 하지만, 이 role의 범위는 hybrid identity 동기화 관리를 위한 것이 아닙니다. 따라서 이 작업에 적절한 role이 아닙니다.

Global administrator는 Azure AD Connect 동기화 옵션을 수정할 수 있는 충분한 권한을 확실히 가지고 있지만, 이 문제에서는 최소 권한 원칙을 위반합니다. 선택지 중 더 낮은 권한의 role이 필요한 작업을 수행할 수 있으므로, Global administrator를 할당하면 tenant 전체에 대한 불필요한 권한을 부여하게 됩니다. Microsoft 시험에서는 더 낮은 권한의 유효한 role이 있으면 일반적으로 그것이 정답입니다. 따라서 여기서 Global administrator는 최선의 답이 아닙니다.

Assigned membership를 가진 security group은 정적이며 새 virtual machine이 추가될 때마다 수동 관리가 필요합니다. 이는 새로운 Windows Server 2019 virtual machine을 자동으로 추가해야 한다는 요구 사항과 직접적으로 충돌합니다. 또한 Azure Automation Update Management는 deployment targeting 메커니즘으로 Azure AD security group을 사용하지 않습니다. 따라서 이 옵션은 기능적으로도 아키텍처적으로도 적절하지 않습니다.

Dynamic Device membership를 가진 security group은 Azure AD에서 membership를 자동으로 업데이트할 수 있지만, Azure Automation Update Management는 Azure AD device group을 통해 update deployment의 대상을 지정하지 않습니다. group에 VM이 올바르게 포함되어 있더라도 deployment scope는 해당 group에서 결정되지 않습니다. 이는 identity grouping과 operational targeting을 혼동하는 일반적인 사례입니다. 따라서 Update1에 대한 올바른 구성이 아닙니다.

'Dynamic group query'는 이 시나리오에서 Azure Automation Update Management deployment scope를 정의할 때 실제로 사용되는 구성 요소가 아닙니다. 동적 동작은 별도의 'dynamic group query' object를 선택하는 것이 아니라 Kusto query를 기반으로 하는 Log Analytics saved search를 통해 달성됩니다. 표현상 그럴듯하게 들릴 수 있지만, 테스트되는 서비스 기능에 대해서는 부정확합니다. Microsoft 시험에서는 Update Management의 이러한 유형의 동적 포함에 대해 일반적으로 KQL query 옵션이 정답입니다.