diff --git a/skills/cloud/azure-review/SKILL.md b/skills/cloud/azure-review/SKILL.md index ac6d6ac7..106ec06a 100644 --- a/skills/cloud/azure-review/SKILL.md +++ b/skills/cloud/azure-review/SKILL.md @@ -5,15 +5,16 @@ description: > Foundations Benchmark v2.1.0. Auto-invoked when reviewing Azure infrastructure, 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. + recommendation, checks managed-identity and PIM effective assignment evidence, + and produces a prioritized findings report with remediation guidance mapped + to specific CIS control IDs. tags: [cloud, azure, cis-benchmark] role: [cloud-security-engineer, security-engineer] phase: [assess, operate] frameworks: [CIS-Azure-v2.1.0] difficulty: intermediate time_estimate: "60-90min" -version: "1.0.0" +version: "1.0.1" author: unitoneai license: MIT allowed-tools: Read, Grep, Glob @@ -27,7 +28,7 @@ argument-hint: "[target-file-or-directory]" This skill performs a structured security assessment of Azure environments against the **CIS Microsoft Azure Foundations Benchmark v2.1.0**. The benchmark is organized into nine sections covering identity management, security center, storage, database services, logging and monitoring, networking, virtual machines, Key Vault, and App Service. Each recommendation is evaluated by inspecting infrastructure-as-code definitions (Terraform, Bicep, ARM templates), Azure CLI output, or configuration files available in the repository. -The CIS Azure Foundations Benchmark v2.1.0 provides prescriptive guidance across nine domains. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps. +The CIS Azure Foundations Benchmark v2.1.0 provides prescriptive guidance across nine domains. This skill evaluates each applicable control and produces a findings report with CIS recommendation IDs, severity ratings, and actionable remediation steps. When a review makes identity-risk claims, distinguish static role assignment text from effective access across management groups, subscriptions, resource groups, data-plane scopes, managed identities, Privileged Identity Management (PIM), Conditional Access, and workload identity federation. --- @@ -74,6 +75,10 @@ Use Glob to locate all Azure-related infrastructure definitions. **/terraform/**/*.tf **/policies/**/*.json **/blueprints/**/*.json +**/entra/**/*.json +**/rbac/**/*.json +**/role-assignments/**/*.json +**/pim/**/*.json ``` Record all discovered files. If no Azure configurations are found, report that finding and halt. @@ -88,10 +93,66 @@ For detailed CIS benchmark checklist items with specific Terraform patterns, Bic --- +### Step 11: Managed Identity and PIM Effective Assignment Review + +Perform this step when the target includes managed identities, service principals, app registrations, role assignments, Key Vault access, privileged Entra roles, or claims about least privilege. Do not flag a managed identity solely because it has a role assignment; score the effective access path, role impact, scope, activation controls, and who can change or attach the identity. + +**Evidence to locate:** + +``` +Microsoft.Authorization/roleAssignments +Microsoft.Authorization/roleDefinitions +azurerm_role_assignment +azurerm_role_definition +azurerm_user_assigned_identity +azurerm_linux_virtual_machine +azurerm_windows_virtual_machine +azurerm_function_app +azurerm_app_service +azurerm_key_vault_access_policy +role_definition_id +role_definition_name +principal_id +principalType +federatedIdentityCredentials +privilegedAccess +eligibleAssignments +roleEligibilityScheduleInstances +roleAssignmentScheduleInstances +``` + +For each managed identity, service principal, or privileged user/group assignment, record: + +- Principal ID, display name, principal type, tenant, and whether it is system-assigned or user-assigned. +- Role definition name/ID, built-in vs custom role, data-plane vs management-plane impact, and allowed actions/dataActions. +- Assignment scope, including inherited management group, subscription, resource group, resource, Key Vault, storage, SQL, or other data-plane scope. +- User-assigned identity attachment points and who can attach the identity to new compute, functions, containers, or automation resources. +- Key Vault authorization mode: RBAC vs access-policy mode, plus secret/key/certificate data-plane permissions. +- PIM eligibility and activation policy for privileged roles, including MFA on activation, approval, duration, justification, notification, and audit log evidence. +- Conditional Access and operator controls for users or groups that can assign roles, activate PIM, modify app registrations, or update managed identity attachments. +- Federated credentials and workload identity federation paths that can assume the identity indirectly. +- Activity log, Entra audit log, and PIM log coverage for role assignment creation, activation, approval, and removal. + +**Evaluation gates:** + +- Separate eligible from active assignments. PIM eligibility is not automatically safe; require activation policy, approval/MFA, duration, justification, alerting, and log evidence. +- Separate management-plane roles from data-plane roles. Reader at subscription scope is different from Owner, User Access Administrator, Key Vault Administrator, Storage Blob Data Owner, or custom roles with broad `dataActions`. +- Check inherited assignments from management groups and parent scopes. Subscription-local IaC is insufficient when privileged roles are inherited. +- For user-assigned managed identities, review both the identity's permissions and the resources allowed to attach it. A low-risk identity can become high-impact if attach permissions are broad. +- For Key Vault, distinguish RBAC authorization mode from access-policy mode before recommending role removal, custom roles, or access-policy changes. +- Mark effective identity access **Not Evaluable** when only local role-assignment snippets are available and no expanded role definitions, inherited scopes, PIM policy, or audit-log evidence is present. +- Remediation should distinguish scope reduction, custom least-privilege roles, data-plane permission removal, PIM eligibility, activation controls, workload identity constraints, and monitoring for assignment changes. + +**Severity guidance:** + +- **Critical / High:** Owner, User Access Administrator, Privileged Role Administrator, Key Vault Administrator, broad data-plane owner roles, or custom roles with high-impact actions assigned actively without PIM controls or assigned to attachable workload identities. +- **Medium:** PIM eligibility lacks MFA/approval/duration evidence, inherited privileged scopes are not reviewed, Key Vault authorization mode is ambiguous, or user-assigned identity attachment paths are broad. +- **Low:** Access appears least-privilege but reviewer evidence is incomplete or stale. +- **Informational:** Managed identity or PIM is not in scope and no least-privilege claim depends on it. --- -### Step 11: Compile Assessment Report +### Step 12: Compile Assessment Report Produce the final report using the structure defined in the Output Format section. @@ -107,6 +168,10 @@ Produce the final report using the structure defined in the Output Format sectio | **Low** | Hardening recommendation or defense-in-depth measure | HTTP/2 not enabled, FTP not fully disabled, missing CMK on non-sensitive storage | | **Informational** | Best practice observation, no direct security impact | Naming conventions, tag policies, documentation gaps | +### Identity Severity Addendum + +For managed identities and PIM, severity is based on effective assignment impact rather than role-assignment existence alone. Consider the role definition, inherited scope, data-plane permissions, activation controls, attachability, federated credential paths, and audit evidence before recommending removal or accepting least-privilege claims. + --- ## Output Format @@ -154,6 +219,24 @@ Produce the final report using the structure defined in the Output Format sectio - **Evidence:** - **Remediation:** +### Managed Identity and PIM Evidence + +| Principal | Type | Role / Scope | Active or Eligible | Data Plane | PIM / CA Controls | Status | +|-----------|------|--------------|--------------------|------------|-------------------|--------| +| | | | | | | Pass / Fail / Not Evaluable | + +#### [IDENTITY] +- **Status:** Pass / Fail / Not Evaluable +- **Severity:** Critical / High / Medium / Low / Informational +- **Principal:** +- **Role / Scope:** +- **File:** +- **Line(s):** +- **Description:** +- **Evidence:** +- **Effective access:** +- **Remediation:** + ### Prioritized Remediation Plan 1. **[Critical]** CIS X.Y.Z -- @@ -200,6 +283,11 @@ 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. **Treating managed identities generically.** Review system-assigned and user-assigned identities differently, especially who can attach a user-assigned identity to new compute or automation resources. +8. **Missing inherited role assignments.** Management group and parent-scope assignments may not appear in subscription-local IaC but still determine effective access. +9. **Equating PIM eligibility with control.** Eligibility still needs activation policy, MFA, approval, duration, justification, notifications, and audit evidence. +10. **Mixing Key Vault RBAC and access-policy mode.** Remediation depends on the vault authorization model; do not recommend the wrong control path. +11. **Ignoring workload identity federation.** Federated credentials and app registrations can reach service-principal or managed-identity paths indirectly. --- @@ -225,10 +313,16 @@ Produce the final report using the structure defined in the Output Format sectio - 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 App Service Security: https://learn.microsoft.com/en-us/azure/app-service/overview-security +- Azure role-based access control documentation: https://learn.microsoft.com/en-us/azure/role-based-access-control/ +- Azure managed identities documentation: https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/ +- Microsoft Entra Privileged Identity Management: https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/ +- Azure Key Vault RBAC guide: https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide +- Workload identity federation: https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation - Terraform AzureRM Provider Documentation: https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs --- ## Changelog +- **1.0.1** -- Added managed identity, PIM, inherited scope, Key Vault authorization mode, workload identity federation, and effective role-assignment evidence gates. - **1.0.0** -- Initial release. Full coverage of CIS Microsoft Azure Foundations Benchmark v2.1.0 sections 1 through 9.