Skip to content

Add Azure managed identity evidence gates #1195

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
yZangEren wants to merge 1 commit into
base: main
Choose a base branch
from
+149 −1
Open

Add Azure managed identity evidence gates #1195

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
42 changes: 41 additions & 1 deletion skills/cloud/azure-review/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand Down Expand Up @@ -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

---

Expand All @@ -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.
Expand All @@ -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.

---
Expand Down Expand Up @@ -119,6 +143,7 @@ Produce the final report using the structure defined in the Output Format sectio
- Date: <assessment date>
- Framework: CIS Microsoft Azure Foundations Benchmark v2.1.0
- Files reviewed: <list of IaC files>
- Effective identity sources reviewed: <role assignment export, PIM export, Entra ID policy export, activity logs>

### Executive Summary
- Total CIS recommendations evaluated: <N>
Expand Down Expand Up @@ -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:** <path to relevant config>
- **Line(s):** <line numbers if applicable>
- **Description:** <what was found>
- **Evidence:** <specific configuration or code snippet>
- **Remediation:** <specific fix with code example>

### 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 -- <action item>
Expand Down Expand Up @@ -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.

---

Expand All @@ -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

---
Expand Down
108 changes: 108 additions & 0 deletions skills/cloud/azure-review/benchmark-checklist.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down Expand Up @@ -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:
Expand Down