When many of us moved our server and application needs to the cloud, we rejoiced that we no longer had to worry about the drudgery of patching. We didn\u2019t have to monitor servers and their Patch Tuesday deployments; it was all in Microsoft\u2019s hands. But as often occurs with cloud deployments, a solution that means you no longer have to worry about one area can create security issues in others. \u00a0Time and again in the handling of any cloud deployment, how we manage identity and authentication needs to be reviewed on a scheduled basis to ensure that the security of cloud assets is being handled according to the latest recommended guidance. In the worst-case scenario, the attackers find out first and don\u2019t inform us to take action. In the best case, researchers find a flaw and work with the vendors to help us all make better security decisions \u2014 Orca Security recently pointed out just such a flaw.Orca, which constantly reviews for cloud misconfigurations and vulnerabilities, found that it could abuse Azure Storage account keys and use the vulnerability to gain full access to storage accounts and even move laterally within the cloud. As Orca notes in its blog, it can be all too easy to set up a storage account and business critical assets with this Shared Key authorization while inadvertently handing administrators privileges that they don\u2019t need.Shared Key is enabled by defaultWhile Microsoft states in its documentation that the use of Shared Key authorization is not ideal and recommends using Azure Active Directory, which provides superior security, Shared Key authorization is still enabled by default when creating storage accounts. Administrators should have only rights over those assets to which they explicitly need access. In this case, the vulnerability can surface if DevOps have the ability to gain Azure listKeys permission.The user who has permission to access \u201cMicrosoft.Storage\/storageAccounts\/listkeys\/action\u201d is not granted access to data. However, the action grants access to the keys, and one can then access the data with the keys \u2014 hence the exposure to risk when using Shared Key authorization and not authorization via OAuth\/Azure AD.Too often in cloud deployments, you get your project working and take the potentially easier way to get something set up. You don\u2019t go back and read the guidance that states:\u201cAuthorization with Shared Key is not recommended as it may be less secure. For optimal security, disable authorization via Shared Key for your storage account, as described in Prevent Shared Key authorization for an Azure Storage account.Use of access keys and connection strings should be limited to initial proof of concept apps or development prototypes that don't access production or sensitive data. Otherwise, the token-based authentication classes available in the Azure SDK should always be preferred when authenticating to Azure resources.Microsoft recommends that clients use either Azure AD or a shared access signature (SAS) to authorize access to data in Azure Storage. For more information, see Authorize operations for data access.\u201dAs the documentation further states:\u201cWhen you attempt to access blob data, the Azure portal first checks whether you've been assigned an Azure role with Microsoft.Storage\/storageAccounts\/listkeys\/action. If you've been assigned a role with this action, then the Azure portal uses the account key for accessing blob data via Shared Key authorization. If you haven't been assigned a role with this action, then the Azure portal attempts to access data using your Azure AD account.\u201dAttackers have already shown that they will target administrators and DevOps to gain access to key resources. Targeting a remotely working developer who is using his home computer to connect to company assets is a key means of gaining corporate secrets and credentials.Shared Key access can leave the door open for intrudersTargeting the users who have Listkeys rights, the attacker can then identify these shared keys and move to accessing those resources. Think in terms of an attacker not having the key to the door of your house but knowing where you\u2019ve stashed the secret key under the doormat. The end result is that the attacker can walk right in, access your data and either use it for corporate infiltration or notify you of access and demand a ransom not to destroy the data. As Orca points out, pivoting from merely reading the shared keys to performing a subscription privilege escalation can be trivial for the attacker.If you are like many Azure customers, you may have set up your organization years ago and are not really sure what the impact will be of moving all of your authentication over to the more secure Azure Active Directory implementation. It could take time and testing that you may not have. Thus, you may have to implement a security review of your Azure assets that not only reviews for this Shared Key authorization risk but other potential configurations that may cause additional problems in the future.Review Microsoft\u2019s guidance\u00a0Review the guidance for granting access to Azure storage and consider additional solutions that will monitor for misuse of access. Orca specifically has a service to monitor for unusual activity in the Microsoft.Storage\/storageAccounts\/listKeys\/action permission so that you can be alerted should someone start abusing the rights.Review those users\/administrators that have Azure blob rights. Do they still need that right? Have they moved to other roles and duties? Should they have rights over that storage location? What is the bare minimum of rights that every DevOps needs to get their job done, but not place undue risk to the organization? Assign someone to perform regular reviews of best-practice guidance and determine whether your organization is still abiding by it.Zero trust and least privilege are key concepts increasingly being stressed as a solution not only in traditional on-premise installations but in cloud assets as well. From users to resources, the assignment of roles should be explicitly granted and understood \u2014 attackers should not know more about your organization and how to access your data than you do.