Implement Azure RBAC for ADLS – Keeping Data Safe and Secure

1. Log in to the Azure portal at https://portal.azure.com ➢ navigate to your Azure Active Directory ➢ select Groups from the navigation menu ➢ select the New Group menu item ➢ enter a name (I used BRAINJAMMER) ➢ set the Sensitivity level to General ➢ select the Member link ➢ add a user other than yourself ➢ select the identity ➢ click the Select button ➢ and then click Create. The configuration should be similar to Figure 8.46

FIGURE 8.46 Azure Active Directory created group

2. Navigate to your subscription ➢ select Access Control (IAM) from the navigation menu ➢ select + Add ➢ select Add Role Assignment ➢ and then add the group you created in step 1 to the Storage Blob Data Reader group.
3. Navigate to the ADLS container you created in Exercise 3.1 ➢ select the Access Control (IAM) navigation item ➢ select the Role Assignments tab ➢ notice that the group within the expected RBAC role exists ➢ create a directory path similar to the following ➢ and then upload the same file from Exercise 8.10, NormalizedBrainwavesSE.parquet, to the directory.
   EMEA\brainjammer\business-data\Confidential\2022\10
4. Navigate to the Azure Synapse Analytics workspace you created in Exercise 3.3 ➢ navigate to Synapse Studio ➢ open the Manage hub ➢ select Access Control, located in the Security group ➢ click the + Add button on the Add Role Assignment window ➢ select Synapse Administrator ➢ select the Group you created in step 1, and then click Apply. The configuration should resemble Figure 8.47.

FIGURE 8.47 Add role assignment access control Synapse Contributor.

5. Log in to the Azure Synapse Workspace using the credentials of a BRAINJAMMER group member and a workspace URL similar to https://web.azuresynapse.net/en/workspaces ➢ select the Azure Active Directory tenant ➢ select the subscription ➢ select the workspace name ➢ and then click Continue.
6. Open the Data hub ➢ select the Linked tab ➢ navigate to the file you uploaded in step 2 ➢ right‐click the file ➢ select New SQL script ➢ click Select Top 100 Rows ➢ and then click Run. The result should resemble Figure 8.48.

FIGURE 8.48 Add role assignment access control Synapse Contributor Parquet file.

When groups and users are created, they are stored in the Azure Active Directory tenant. The tenant ID is typically a GUID that is bound to a primary domain. The primary domain is often your organization name appended to. onmicrosoft.com. While creating the Azure Active Directory group, you set a sensitivity label on it. It is good practice to begin placing sensitivity labels on all your resources from this point forward. After creating the group, you added a user to the group. It is important that you use a user account other than the one you used to provision all the resources from this book. This is because you, as the resource creator, will already have owner and/or admin access to them. Also keep in mind that if the user you add to the BRAINJAMMER group is a member in another group with a higher level of permissions, then those permissions will be applied instead of the limited set configured in Exercise 8.12.

You then created a folder structure on the ADLS container that included a confidential folder. This is a flag that should signal that additional attention needs to be given to the content within this folder. As you know from Figure 8.16, when access permissions are applied with RBAC, access to the resource and the content within it is granted as well. The final action was to grant the Azure AD group access to the Azure Synapse Analytics workspace using Access control (IAM). Because the workspace is bound to the same Azure Active Directory tenant, the same groups and users are accessible and addable from the access controls. The Role drop‐down list box from Figure 8.47 contains all the Synapse RBAC roles you have been exposed to in some previous discussions. The BRAINJAMMER Azure AD group was added to the Synapse Administrator role because at this time it is required to perform operations on a serverless SQL pool. As you observed in Figure 8.46, the value in the Connect To drop‐down list box is Built‐in, which means the serverless SQL pool was used. Also, PolyBase is what managed to get the SQL query to run against a Parquet file and render as a table.

Implement POSIX‐like Access Control Lists

One of the undesired side effects of adding the BRAINJAMMER group to the Storage Blob Data Reader role is that all the users within it have read access to all that data. Read access is the most limited amount of access one can be given to a data resource. The only other more constrained permission is no access at all. It was neither intended nor desired to give all those in the BRAINJAMMER group access to the files located in the Confidential folder created in Exercise 8.12. One of the complexities here, however, is that once a group or user is added to the Storage Blob Data Reader role, it is not possible to provide a lower level of access than is granted by the RBAC role. That means you cannot remove read access from a specific folder or file on that storage account. The reason is obvious when reviewing the flowchart in Figure 8.18, because as soon as a validation results in yes, access to the resource is granted. Because the RBAC role check happens before the ACL check, the RBAC role permission is applied. The scenario where an ACL permission can be applied is increasing the level of access on a directory, file, or resource. In some business scenarios, it might be all right for all the users in the BRAINJAMMER group to have read access to the Confidential folder. But you do not want those group members to add or change the data in that folder. To implement this scenario using ACLs, complete Exercise 8.13.