As an MSP, CSP, general IT Service Provider or even a regular IT department, we generate a huge number of login credentials for different systems to keep everything running. While it is best practice to maintain a single source of identity using LDAP integrations, ADFS and delegation, sometimes the systems we work with don’t support this. Things like Certificate Authority logins, root passwords to non-Windows machines, local admin passwords etc. all need to be stored securely and potentially made available to a large team when needed.

This problem is very common, with many third party solutions such as LastPass having decent offerings around credential access management. One relatively low cost tool we have at our disposal in the Microsoft Cloud is Azure Key Vault. Key Vault allows us to securely store a range of sensitive credentials like secrets/passwords, keys and certificates and allow the other technologies in Azure to help us with access management. It also allows for logging of activity, backup and versioning of credentials which goes a long way towards making the solution scalable and secure.

We can create a Key Vault in our Azure Subscription very easily and start using it to store credentials for anyone with access, this is fine but persistent access to this secure data probably isn’t required and shouldn’t be in place.

To provide access to the keys we want to publish, we create a security group in Azure which will be granted permissions in the access policy to just the Keys required. As we want to make access available as ‘just in-time’ ensure to tick the option for “Azure AD roles can be assigned to the group (Preview)”.

When our group is created we can enable it for privileged access from the group settings under “Activity”.

Once enabled, we add our users who require access as eligible to the group.

Now that our group is ready, the last step is to assign access to the group. From the Key Vault we created, create a new Access Control policy, granting appropriate access to the Key Vault for our group. For this group I am granting the “Reader” permissions to the vault but this can be tailored to the specific group needs.

If required, we can customize the settings of the eligible role to put in any approval or notification requirements.

Now that the role is assigned, we can test with our user account.

Requesting Access

When our user requires access, they can navigate to the Privileged Identity Management section of the Azure portal and under Privileged Access Groups can request the access to the group providing justification for logging purposes and subject to any approval / notification settings etc.

The request will process with any notifications or approval we have specified.

Once activated, the role will allow our user to access to Key Vault for the time specified in the request. When this time expires they will need to activate the role again.

Summary

Key Vault and PIM work together to form an extremely secure workflow for secret management. While we can’t get granular for different individual objects, it’s recommended that a tiered approach using multiple vaults is taken to ensure segregation of permissions. Key Vault is also extremely cheap to run and using this model, is highly scalable.

Some other ideas would be to integrate something like Logic Apps to remind the Key Vault owners to rotate any stale passwords and update them in the vault. For certain services this rotation can even be automated with Logic Apps and/or Azure automation.