feat(scanner): add rule AZ-KV-006 — Key Vault using legacy access policies instead of Azure RBAC

[dipeshrayg]

Problem

Existing Key Vault rules (AZ-KV-001 through AZ-KV-005) cover soft delete, public network access, diagnostic logging, purge protection, and certificate expiry — none check the vault's authorization model. Key Vaults still using legacy vault access policies instead of Azure RBAC lack scoped, auditable, least-privilege access control: access policies are all-or-nothing per permission type, cannot be scoped to individual secrets/keys/certificates, and aren't tracked through Azure RBAC's centralized role-assignment audit trail.

Proposed rule

Rule ID	Check	Severity
AZ-KV-006	Key Vault has enable_rbac_authorization set to false or unset (still on legacy access policies)	MEDIUM

Implementation scope

• Reuse AzureClient.get_key_vaults() — no new client method needed, the property is already on the returned vault objects.
• Flag when properties.enable_rbac_authorization is False or missing (access policies are the legacy default; a vault must opt into RBAC).
• Playbook: az keyvault update --enable-rbac-authorization true, with a note that existing access policies stop being enforced once RBAC is on (so role assignments should be prepared first).
• Compliant / non-compliant / missing-property test cases, following the existing tests/test_rules_keyvault.py pattern.
• Update all four compliance framework JSON files (CIS, NIST CSF, ISO27001, SOC2).

A mapping issue found while drafting this

Cross-checked against the real CIS Azure Foundations Benchmark: the official control for "Enable Role Based Access Control for Azure Key Vault" is 8.6. In this repo's compliance/frameworks/cis_azure_benchmark.json, control 8.6 is already assigned to AZ-KV-004 (purge protection) — an unrelated check. That looks like a pre-existing mapping error, not something this PR should silently resolve by reassigning another rule's control ID. I've mapped AZ-KV-006 to TBD-KV-006 for now, following the same TBD-* placeholder convention already used elsewhere in that file (e.g. TBD-IDN-010), pending a maintainer decision on how to resolve the 8.6 collision.

Out of scope

• Auditing individual access-policy permission grants for over-broad access (a bigger surface — enumerating principals/permissions — better suited to its own follow-up issue).
• Key Vault firewall / network ACL default-action checks (overlaps with AZ-KV-002's public-access check).

Acceptance criteria

• Maintainers confirm rule ID, severity, and how to resolve the CIS 8.6 collision noted above.
• Rule correctly flags vaults with enable_rbac_authorization false/unset and skips RBAC-enabled vaults.
• Compliant, non-compliant, and missing-property test cases pass.
• All four compliance framework JSON files updated and tests/test_cis_benchmark_mapping.py passes (no duplicate CIS control IDs).
• Remediation playbook validates inputs and warns about the access-policy-to-RBAC transition impact.
• Full repository CI and security checks pass.

References

• https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide
• https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-access-policy

[dipeshrayg]

I would like to work on this.

[dipeshrayg]

@core-team could a maintainer confirm the CIS mapping for AZ-KV-006?

The official CIS Azure Foundations Benchmark control for "Enable Role Based Access Control for Azure Key Vault" is 8.6, but 8.6 is already assigned to AZ-KV-004 (purge protection) in compliance/frameworks/cis_azure_benchmark.json, which looks like a pre-existing mismatch unrelated to this PR. I left AZ-KV-006 mapped to TBD-KV-006 rather than reassign AZ-KV-004's control ID myself. Should AZ-KV-006 stay as TBD, or should AZ-KV-004 be corrected to a different control and 8.6 freed up for this rule? Whichever you prefer, I'll update the PR accordingly.

[TFT444]

@core-team could a maintainer confirm the CIS mapping for AZ-KV-006?

The official CIS Azure Foundations Benchmark control for "Enable Role Based Access Control for Azure Key Vault" is 8.6, but 8.6 is already assigned to AZ-KV-004 (purge protection) in compliance/frameworks/cis_azure_benchmark.json, which looks like a pre-existing mismatch unrelated to this PR. I left AZ-KV-006 mapped to TBD-KV-006 rather than reassign AZ-KV-004's control ID myself. Should AZ-KV-006 stay as TBD, or should AZ-KV-004 be corrected to a different control and 8.6 freed up for this rule? Whichever you prefer, I'll update the PR accordingly.

Go with option 2, correct AZ-KV-004's mapping and free up 8.6 for AZ-KV-006. 8.6 is the right control for this rule; AZ-KV-004 needs its own accurate ID instead.
Please update both and confirm tests/test_cis_benchmark_mapping.py still passes.