There are numerous methods for controlling access to an ADLS container. Connection strings, SAS tokens, RBAC, and ACLs are the most approaches. From a security layer perspective, as illustrated in Figure 8.1, this kind of security is applied at the access management layer. Although connection strings and SAS tokens are valid access control techniques, each requires an access key, which has a vulnerability due to credential leakage. The approach for solving that is to store those values in an Azure key vault and use managed identities to access and retrieve them when needed. When you are focused on controlling access at the level both a connection string and SAS token target, which is the storage account, the most secure and recommended approach is to use RBAC. As you may recall from Table 8.2, Azure RBAC has the scope of either the storage account or container, which is the same for a connection string and SAS token. If you require a more granular level of access control, all the way down to the data layer, down to the file level, then the optimal mechanism is to place ACLs on those files. In the case of both RBAC and ACLs, you apply either users, groups, or service principals to the control list.
Before moving onto the implementation of Azure RBAC and ACLs, you should know something about Microsoft Defender for Cloud (MDC). One of the components of MDC is Microsoft Defender for Storage, which can alert when a storage account is potentially being exploited or harmed. This feature targets the threat protection layer of the layered security model. As shown in Figure 8.45, to enable it, you must only set the Status toggle button to On for the storage plan.
FIGURE 8.45 Enabling Microsoft Defender for Storage
The Microsoft Defender for Storage threat protection feature applies to Azure Data Lake Storage Gen2, Azure Files, and Azure Blob Storage. There are also guidelines for investigating and mitigating activities like privilege abuse, compromised credentials, unauthenticated access, and social engineering attacks. The point is that in addition to setting these access controls, it is recommended to have a layer of protection that monitors and alerts when those access controls exhibit breached and unwanted behavioral patterns.
Implement Azure Role‐Based Access Control
RBAC permissions are primarily used to restrict access to Azure resources. Some Azure products have expanded so that the security feature can be applied to the data that exists on the data source. The point here is to call out the difference between granting permission to an Azure resource and granting access to the data or services that reside within or on it. This section will be restricted to the understanding that an RBAC permission applies to the Azure resource. Figure 8.16 illustrated a flow chart that clarifies the operation flow when permissions are applied using RBAC. Figure 8.17 shows how this looks in the Azure portal. In Exercise 8.12 you will create a group named BRAINJAMMER in Azure Active Directory and add a separate account to the group. As you know, granting permissions to individuals is not efficient, especially when a large number of people need permissions. Therefore, the separate user account that is added to the Storage Blob Data Reader RBAC role on the ADLS container, which is shown in Figure 8.17, will be removed and added to the group. Adding individuals to groups and then applying permissions to that group is a more efficient way to manage access permissions for resources. A note of caution here: do not completely remove your account from the RBAC groups on a product or feature, and especially not a subscription. If you do that, then you will lock yourself out of it and not be able to regain access.
