[ad_1]
One of the benefits of access management in Azure is the clear distinction between control plane actions (“actionsâ€) and data plane actions (“dataActionsâ€) in roles. One condition, though: you may end up granting more permissions to an entity than you expect – and probably because the proposed caveats are less noticeable than they should be.
The distinction between “actions†and “dataActions†is very important – and useful – for setting up and selecting roles for different business functions and tasks. “Actions†are management operations (or control plane operations) performed on the resources themselves. “Data actions” are operations, such as reading, writing, and deleting, performed on the data of a resource. These fundamentally distinct types of operations generally correspond to functions within an organization, namely: the entities that manage resources (such as system administrators) and the entities that consume and / or manipulate them.
The usefulness of this distinction relies heavily on “actions†granting permissions only to management operations, and “dataActions†granting permissions only to data-related operations. Turns out that’s not always the case. As we’ll see in this article: Sometimes you might think you’re granting management actions but actually granting data access – and even the ability to change it!
This is the unintentional reality of the backdoor to action: Microsoft.Storage/storageAccounts/listkeys/action.
List of access keys – a control plane action that allows data manipulation
According to Azure Documentation: “When you create a storage account, Azure generates two 512-bit storage account access keys. These keys can be used to authorize data access and even modification (including deletion!) Of your storage account via shared key authorization. “
Due to the very sensitive nature of these access keys, when using them, store them with care. Even though you won’t use them and never extract them from the console, be aware of this:
While accessing data in a storage account is very clearly a data action, the action that allows a function to access access keys, Microsoft.Storage/storageAccounts/listkeys/action, is an action of the control plan, as shown in Figure 1.
Figure 1 – The List Storage Account Keys action, found in the Actions section of role creation (which is designated for control plane actions), is a control plane action
This fact is important to understand because you will often want to allow users to manage a storage account without being able to access its data. To do this, you might be tempted to provide them with the Contributor role, which does not contain any data actions.
However, the Contributor role has access to the action: Microsoft.Storage/storageAccounts/listkeys/action. Therefore, a user or service principal assigned to this role can actually access data in the storage account – unless otherwise prohibited.
Microsoft published an article about this question. Nonetheless, based on our experience with DevOps and security practitioners, we believe the issue may not be very well known. And that’s not all.
Not at all “hard to get” – this is the default
To make matters worse: not only does the Storage Account List Keys action allow unintentional access; in the Azure portal, for users who can list access keys, access keys are the default out-of-the-box authentication method to access the storage account. In other words, when using the Azure portal, a user who can list the access keys can, without any special effort, access the data in the storage account.
According to Microsoft’s post above: “When you try to access blob data in the Azure portal, the portal first checks to see if you have been assigned a role with Microsoft.Storage/storageAccounts/listkeys/action. If you were assigned a role with this action, the portal uses the account key to access blob data. If you have not been assigned a role with this action, the portal attempts to access the data using your Azure AD account.
In short, even if he does not know that he obtained this excessive authorization, it is very likely that a user will fall on it.
Let’s see this in action. Suppose a user has the Contributor role on a storage account:
Figure 2 – A user assigned the role of contributor on a storage account
Once in the Azure portal, the user can actually – again, since the console uses the default access key to authenticate user access to a storage account – perform the plan action. data that displays the contents of the storage account and its containers.
Figure 3 – A user with access keys for a storage account can actually see the data in the storage account – because in this case, access keys are the default authentication method for browsing containers in the portal
If the user switches to the Azure AD user account authentication method, Azure denies access to the storage account content because the user does not have access to data actions.
Figure 4 – A user without access to data actions (although they have access to the keylist action) is denied access when they try to use their Azure AD account as an authentication method
It should be noted that even though the Azure portal did not use the access keys for authentication, a user who can list the access keys can still simply take advantage of an interface like the Azure CLI. to obtain the access keys and use them to access the data itself. It goes without saying that unintentional access to the contents of storage accounts can be a compliance issue, not to mention the potential cause of much more damaging fallout for an organization in the event of a security breach.
Conclusion
Issues like this highlight how important it is, when granting permissions to resources, to become familiar with the content and implications of Azure resource roles assigned to users and service principals. You want information and control to be able to choose the most appropriate integrated role. Ideally, you will want to create custom roles with the least privileged access permissions for the business functions that an entity assigned to a role must perform.
The post office Access keys: an unintentional backdoor to Azure storage account data appeared first on Ermetic.
*** This is a Syndicated Security Bloggers Network blog by Ermetic written by Lior Zatlavi. Read the original post on: https://ermetic.com/whats-new/blog/azure/access-keys-an-unintended-backdoor-by-design-to-azure-storage-accounts-data/
[ad_2]
