From 96354b74bae1339b2cc947b5eca9e94cbd45f216 Mon Sep 17 00:00:00 2001 From: XTRA_xty <3212559507@qq.com> Date: Sat, 6 Jun 2026 06:47:48 +0800 Subject: [PATCH] Add Azure managed identity evidence gates --- skills/cloud/azure-review/SKILL.md | 42 ++++++- .../cloud/azure-review/benchmark-checklist.md | 108 ++++++++++++++++++ 2 files changed, 149 insertions(+), 1 deletion(-) diff --git a/skills/cloud/azure-review/SKILL.md b/skills/cloud/azure-review/SKILL.md index ac6d6ac7..56959a73 100644 --- a/skills/cloud/azure-review/SKILL.md +++ b/skills/cloud/azure-review/SKILL.md @@ -6,7 +6,8 @@ description: > Entra ID configurations, NSG rules, Defender for Cloud settings, or Key Vault access policies. Walks through all nine benchmark sections, evaluates each recommendation, and produces a prioritized findings report with remediation - guidance mapped to specific CIS control IDs. + guidance mapped to specific CIS control IDs, including effective managed + identity access and Privileged Identity Management evidence. tags: [cloud, azure, cis-benchmark] role: [cloud-security-engineer, security-engineer] phase: [assess, operate] @@ -54,6 +55,9 @@ The CIS Microsoft Azure Foundations Benchmark v2.1.0 is a consensus-driven secur - Entra ID (Azure AD) configuration files or policy documents - NSG and firewall rule definitions - Key Vault access policies and RBAC assignments +- Managed identity inventory, role assignments, PIM eligibility/activation + exports, Conditional Access policy evidence, and privileged role audit logs + when identity posture is in scope --- @@ -74,6 +78,10 @@ Use Glob to locate all Azure-related infrastructure definitions. **/terraform/**/*.tf **/policies/**/*.json **/blueprints/**/*.json +**/role-assignments/**/*.json +**/rbac/**/*.json +**/pim/**/*.json +**/entra/**/*.json ``` Record all discovered files. If no Azure configurations are found, report that finding and halt. @@ -84,6 +92,22 @@ Record all discovered files. If no Azure configurations are found, report that f Evaluate all Azure configurations against CIS Azure v2.1.0 Sections 1 through 9, covering Identity and Access Management, Microsoft Defender for Cloud, Storage Accounts, Database Services, Logging and Monitoring, Networking, Virtual Machines, Key Vault, and App Service. +Before scoring Identity and Key Vault controls, build an effective-access +inventory for high-impact principals: + +- user-assigned and system-assigned managed identities; +- service principals and app registrations with federated credentials; +- users or groups eligible for privileged Entra or Azure RBAC roles; +- inherited role assignments from management groups, subscriptions, resource + groups, and data-plane resources such as Key Vault. + +For each high-impact assignment, record principal type, role definition, scope, +inheritance source, data-plane versus management-plane effect, PIM eligibility, +activation controls, and monitoring evidence. Treat a benign low-privilege +managed identity, such as `Reader` at subscription scope, differently from +`Owner`, `User Access Administrator`, `Key Vault Administrator`, or custom roles +with `Microsoft.Authorization/*` or secret/key management permissions. + For detailed CIS benchmark checklist items with specific Terraform patterns, Bicep examples, and configuration checks for all nine sections, see [benchmark-checklist.md](benchmark-checklist.md) in this skill directory. --- @@ -119,6 +143,7 @@ Produce the final report using the structure defined in the Output Format sectio - Date: - Framework: CIS Microsoft Azure Foundations Benchmark v2.1.0 - Files reviewed: +- Effective identity sources reviewed: ### Executive Summary - Total CIS recommendations evaluated: @@ -148,12 +173,20 @@ Produce the final report using the structure defined in the Output Format sectio - **Status:** Pass / Fail / Not Evaluable - **Severity:** Critical / High / Medium / Low - **CIS Profile:** Level 1 / Level 2 +- **Identity scope:** Management plane / Data plane / PIM eligibility / Not identity-related - **File:** - **Line(s):** - **Description:** - **Evidence:** - **Remediation:** +### Effective Identity and PIM Evidence + +| Principal | Type | Role | Scope | Plane | Assignment Source | PIM Status | Required Evidence | +|-----------|------|------|-------|-------|-------------------|------------|-------------------| +| app-prod-mi | User-assigned managed identity | Key Vault Administrator | key vault | Data | Terraform role assignment | Not Evaluable | scope justification, activation/approval if eligible, assignment-change alerts | +| breakglass-admins | Group | Privileged Role Administrator | tenant | Management | Entra PIM export | Eligible | MFA on activation, approval, duration, justification, audit logs | + ### Prioritized Remediation Plan 1. **[Critical]** CIS X.Y.Z -- @@ -200,6 +233,10 @@ Produce the final report using the structure defined in the Output Format sectio 4. **NSG rules using service tags.** A rule with `source_address_prefix = "Internet"` is equivalent to `0.0.0.0/0`. Both must be flagged for CIS 6.1 and 6.2. 5. **Key Vault purge protection is irreversible.** CIS 8.5 requires `purge_protection_enabled = true`. Note this cannot be disabled once enabled -- flag this for awareness during remediation. 6. **App Service TLS version on both Linux and Windows.** Check `azurerm_linux_web_app` and `azurerm_windows_web_app` resources separately. +7. **Static RBAC assignments are not effective access.** A subscription-local IaC export can miss inherited assignments from management groups, group membership, PIM eligibility, and workload identity federation. Record what evidence was available before marking privileged identity posture as pass. +8. **Managed identity role risk depends on role, scope, and attachability.** Do not flag every managed identity assignment as equally risky. Reader at narrow scope is different from Owner, User Access Administrator, or Key Vault Administrator on a production vault, and user-assigned identities can be attached to additional compute after review. +9. **PIM eligibility is not proof of safe access.** For privileged roles, require activation settings, MFA-on-activation, approval, maximum duration, justification, alerts, and activation audit logs before treating eligibility as controlled. +10. **Key Vault RBAC and access-policy mode use different evidence paths.** In RBAC mode, inspect Azure role assignments and inherited scopes. In access-policy mode, inspect explicit key/secret/certificate permissions and identity attachment paths. --- @@ -222,9 +259,12 @@ Produce the final report using the structure defined in the Output Format sectio - CIS Microsoft Azure Foundations Benchmark v2.1.0: https://www.cisecurity.org/benchmark/azure - Microsoft Defender for Cloud Documentation: https://learn.microsoft.com/en-us/azure/defender-for-cloud/ - Microsoft Entra ID Security: https://learn.microsoft.com/en-us/entra/identity/ +- Microsoft Entra Privileged Identity Management: https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/ - Azure Storage Security: https://learn.microsoft.com/en-us/azure/storage/common/storage-security-guide - Azure Key Vault Best Practices: https://learn.microsoft.com/en-us/azure/key-vault/general/best-practices +- Azure Key Vault RBAC guide: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide - Azure App Service Security: https://learn.microsoft.com/en-us/azure/app-service/overview-security +- Azure managed identities overview: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/overview - Terraform AzureRM Provider Documentation: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs --- diff --git a/skills/cloud/azure-review/benchmark-checklist.md b/skills/cloud/azure-review/benchmark-checklist.md index 41a67846..407f7554 100644 --- a/skills/cloud/azure-review/benchmark-checklist.md +++ b/skills/cloud/azure-review/benchmark-checklist.md @@ -95,6 +95,77 @@ resource "azuread_directory_role_assignment" { ... } #### CIS 1.3.3 -- Ensure that 'Restrict access to Microsoft Entra admin center' is set to 'Yes' +### Identity Supplement -- Managed Identity and PIM Effective Access + +Use this supplement when reviewing privileged role posture, managed identities, +Key Vault administration, or workload identity access paths. + +#### Managed Identity Effective-Access Evidence + +Build an inventory of user-assigned and system-assigned managed identities and +the Azure RBAC assignments that affect them. Include direct and inherited +assignments from management groups, subscriptions, resource groups, and +resource-level scopes. + +```hcl +# Lower-risk example: read-only assignment at subscription scope +resource "azurerm_role_assignment" "app_reader" { + scope = data.azurerm_subscription.current.id + role_definition_name = "Reader" + principal_id = azurerm_user_assigned_identity.app.principal_id +} +``` + +Do not report the previous example as a critical finding unless additional +evidence shows privileged scope, data-plane access, broad attachability, or +missing change monitoring. + +```hcl +# High-risk example: workload identity can administer production vault secrets +resource "azurerm_role_assignment" "mi_kv_admin" { + scope = azurerm_key_vault.prod.id + role_definition_name = "Key Vault Administrator" + principal_id = azurerm_user_assigned_identity.app.principal_id +} +``` + +For high-impact assignments, require these evidence fields: + +| Evidence | What to record | Fail when | +|----------|----------------|-----------| +| Principal type | user-assigned MI, system-assigned MI, service principal, group, user | Principal cannot be mapped to an owned workload or operator | +| Role definition | built-in/custom role, permissions, data actions | Role includes owner, access admin, Key Vault admin, or wildcard permissions without justification | +| Scope | management group, subscription, resource group, resource, data-plane resource | Assignment is broader than required or inherited from an unreviewed parent | +| Attachment path | compute resources that can use the identity | User-assigned identity can be attached to new compute without approval | +| Federated credentials | workload identity federation subject/audience/issuer | Broad subject patterns or missing environment/branch constraints allow unintended use | +| Monitoring | alerts for assignment changes and identity attachment changes | No activity log, alert, or periodic review evidence exists | + +#### PIM Eligibility and Activation Evidence + +For privileged Entra and Azure RBAC roles, eligibility alone is not sufficient. +Capture activation policy and activation logs. + +| Evidence | Pass condition | Fail condition | +|----------|----------------|----------------| +| MFA on activation | MFA is required when activating privileged roles | Eligible users can activate without MFA | +| Approval | High-impact roles require approval or break-glass process | Self-activation is allowed for Owner, User Access Administrator, Global Administrator, or Privileged Role Administrator without compensating controls | +| Duration | Activation maximum duration is short and role-specific | Long or unlimited activations are allowed | +| Justification/ticket | Activation requires a reason or ticket number | No business justification is captured | +| Audit | Activation, assignment, extension, and renewal logs are retained and reviewed | No activation logs or alerts are available | +| Alerts | Alerts exist for permanent assignment, activation outside approved hours, and privileged assignment changes | Privileged access changes are not monitored | + +#### Key Vault Identity Mode Evidence + +Key Vault authorization can be RBAC-based or access-policy-based. Review the +right evidence path: + +- **RBAC mode:** inspect Azure role assignments, inherited scopes, data actions, + PIM eligibility, and principal attachment paths. +- **Access-policy mode:** inspect explicit key, secret, certificate, and storage + permissions in `access_policy` blocks and verify principal ownership. +- **Mixed migrations:** flag drift where RBAC mode is enabled but stale access + policies remain in IaC or documentation as if they were still authoritative. + --- ## Section 2 -- Microsoft Defender for Cloud @@ -617,6 +688,43 @@ resource "azurerm_key_vault" { } ``` +When `enable_rbac_authorization = true`, review effective Azure RBAC access to +the vault: + +```hcl +# Review as high impact unless scope and operational controls are justified. +resource "azurerm_role_assignment" "kv_admin" { + scope = azurerm_key_vault.prod.id + role_definition_name = "Key Vault Administrator" + principal_id = azurerm_user_assigned_identity.app.principal_id +} +``` + +Required RBAC-mode evidence: + +- role definition and whether it includes key/secret/certificate data actions; +- scope and inherited parent assignments; +- whether the principal is a managed identity, service principal, group, or user; +- whether PIM eligibility/activation controls apply to privileged human roles; +- whether user-assigned managed identities can be attached to additional compute; +- alerts or activity-log rules for role assignment and managed identity changes. + +When `enable_rbac_authorization = false`, inspect access policies instead: + +```hcl +resource "azurerm_key_vault_access_policy" "app" { + key_vault_id = azurerm_key_vault.prod.id + tenant_id = data.azurerm_client_config.current.tenant_id + object_id = azuread_service_principal.app.object_id + secret_permissions = ["Get", "List"] +} +``` + +Do not mix the two evidence models. RBAC-mode findings should focus on role +assignments and effective scope; access-policy-mode findings should focus on +explicit key/secret/certificate permissions, principal ownership, and whether +permissions exceed the workload's need. + ### CIS 8.7 -- Ensure that Private Endpoints are used for Azure Key Vault Check for private endpoint connections to Key Vault: