Inaccurate/inconsistent "Supported" state for IM-8 in AKV Security Baseline

[lindbeck]

"IM-8: Restrict the exposure of credential and secrets" states that storing keys utilized by the service is supported, which is inaccurate. Key Vault stores keys, yes, but that is not what this benchmark refers to.

The description of this benchmark is: "Description: Data plane supports native use of Azure Key Vault for credential and secrets store.

This refers to the service (Key Vault) using stored secrets in a Key Vault, this is not applicable as Key Vault itself won't use secrets that are stored in another Key Vault, therefor this should be stated as unsupported.

---

Document Details

⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

• ID: 9ccbaaaf-2267-bbf4-c6c4-9e7cb63f3465
• Version Independent ID: 8e0ae980-eace-6fde-59ec-61ea040196e0
• Content: Azure security baseline for Key Vault
• Content Source: benchmark/azure/baselines/key-vault-security-baseline.md
• Service: key-vault
• GitHub Login: @msmbaldwin
• Microsoft Alias: mbaldwin

[TPavanBalaji]

@lindbeck Thanks for your feedback! We will investigate and update as appropriate.

[jlichwa]

@lindbeck I'm not sure I understand the ask. Key Vault does restrict exposure to any secrets regardless of use, example could be MSAK when Key Vault identity is used to access Storage Account to rotate keys, or any other calls which are made with Key Vault, like Event Grid.

[lindbeck]

@jlichwa Let me clarify. The benchmark is written from the perspective of an Azure service utilizing Key Vault to store credentials and secrets that it then accesses, not from the perspective of Key Vault storing secrets within itself.

An example is how the benchmark is described for Azure Virtual Machines.

The feature note says: "Within the data plane or operating system, services may call Azure Key Vault for credentials or secrets."

And the configuration guidance says: "Ensure that secrets and credentials are stored in secure locations such as Azure Key Vault, instead of embedding them into code or configuration files."

I do not think the benchmark is applicable to Key Vault as it does not utilize credentials and secrets that are stored in another vault for data plane operations within itself. The definition of this benchmark is interpreted completely different for Key Vault than it is for any other service.

[jlichwa]

The IM-8 guidance has multiple options, but the key is that credentials are not exposed: "Avoid embedding the credentials and secrets into the code and configuration files", could be hidden or stored in Key Vault: https://learn.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-identity-management#im-8-restrict-the-exposure-of-credential-and-secrets

If you believe that Key Vault exposes secrets to integrate with any service, that it will be false. Otherwise service comply, you may possibly argue that is not applicable.

[lindbeck]

As I stated above that refers to the service itself utilizing a Key Vault to store its secrets and credentials. Key Vault does not apply here as Key Vault does not store and utilize secrets itself for its own data plane use, it stores them for other applications.

A comparison would be if I wrote in the Virtual Network security baseline that NS-1 "Virtual Network Integration" is supported, which it isn't as virtual networks are the networks being integrated into by services, not the service integrating into a virtual network.

The benchmarks are written from the service utilizing Key Vaults perspective, not from Key Vault having the capability to store secrets.

I'm not saying that Key Vault exposes secrets, I'm saying that the definition of the benchmark you linked is inconsistent with how it is described in the Key Vault Security Baseline.

[jlichwa]

IM-8 is about restricting secrets and credentials exposure as description says is broad requirement not limited to storing secrets in Key Vault, it is just an example. It is part of PCI DSS and Key Vault is PCI DSS certified (all Key Vault secrets are protected and stored in internal secrets manager):

Description in here is not covering entire IM-8 requirement which it seems you are stuck on, here you have entire description of IM-8, if you think Key VAult violates it, we can report Security Standard team (since we don't have control here): https://learn.microsoft.com/en-us/security/benchmark/azure/security-controls-v3-identity-management#im-8-restrict-the-exposure-of-credential-and-secrets.

The only thing we can consider, since Key Vault does not have any credentials besides identities (unlike Storage Account with access keys), it could possibly be not applicable.

[lindbeck]

I think we are interpreting the control differently. But I would agree that IM-8 is not applicable to Key Vault security baseline, I would recommend removing the benchmark from the documentation.

Key Vault is the tool used for a service to comply with IM-8. The security principle explicitly refers to application developers handling credentials and secrets in their code and configuration files, this isn't applicable to Key Vault as Key Vault itself does not use any credentials or secrets that must be stored securely, which again, is what the security principle explicitly describes.