Reporting and Monitoring – Gaining the Azure Data Engineer Associate Certification
Since Azure AD is the place where most of your authentication and authorization activities will happen, it is very important to have some tools to make sure all is working. If you see in the audit logs that many of your employees are failing to be authenticated because of IP location, you might want to perform some analysis to find that IP range and consider changing the Conditional Access rule. Reporting and monitoring is also important to check if there have been any malicious attempts to exploit your directory. There are two reports that might come in handy here, which are available with an Azure AD Premium P2 license:
- The first is “user flagged for risk,” which highlights an account that may have been compromised. It is possible for a person to lose a device that isn’t protected by a PIN, and someone who finds the device can use a cached user ID and password to access the application without having to enter those credentials. The Azure platform captures telemetry and can flag and alert security anomalies that might not be obvious to individuals. This report can help surface such events.
- The other report is called “risky sign‐ins” or “risky users,” which is similar to the first but instead targets compromised credentials versus a lost device. Either way, knowing what is going on in your Azure AD is extremely important.
Role‐Based Access Control
RBAC is a feature that is used to control access to Azure resources in the Azure portal, Azure PowerShell, or Azure CLI. For example, you can grant someone the authority to provision and configure Azure VMs and at the same time deny them the authority to provision networking and data services. You can also grant some the authority to provision an Azure Synapse Analytics workspace and deny them authority to provision an Azure Cognitive service. It is very flexible, so you can come up with your scenarios, and they are likely supported using RBAC. There are two fundamental concepts you need to know about RBAC:
- Role definitions
- Scope
Role Definitions
Consider, for example, a role named Synapse User. When you think about that role, imagine what kind of permissions such a role would require. Does a person assigned that role need access to Azure Arc or the Azure Active Directory? Probably not. Would that role need access to Azure Synapse Analytics? That is very likely. This is what RBAC provides—it lets you define roles that have specific permissions to perform specific tasks on specific Azure resources. There are two important things to keep in mind:
- First, no permissions are granted by default, which is a good thing. It is best practice to grant a role the absolute minimum permissions required to perform their tasks.
- Second, assign a role to a group and not an individual. If you have a large organization, it is much more feasible to assign permissions to a group versus an individual. Then, if you need to change permissions, then you change it on a single group instead of potentially thousands of individual user accounts.
The following snippet illustrates an example Synapse User role in JSON format:
{“Name”: “Synapse User”, “Id”: null, “IsCustom”: true,”Description”: “Read Synapse Analytics resources and create support cases”,”Actions”: [“Microsoft.Synapse/workspaces/read”,”Microsoft.Synapse/workspaces/bigDataPools/read”,”Microsoft.Synapse/workspaces/sqlPools/read”,”Microsoft.Synapse/workspaces/integrationruntimes/read”,”Microsoft.Support/*”],”NotActions”: [ ],”DataActions”: [ ], “NotDataActions”: [ ], “AssignableScopes”: [ “/subscriptions/#######-####-####-####-#########”]}
The first entry seen in the Actions property of the previous snippet is Microsoft.Synapse/workspaces/read, which gives the person the ability to read Azure Synapse Analytics workspaces. Notice that there is no ability to create or delete. Adding something like Microsoft.Synapse/workspaces/* would grant all permissions to the workspaces. The next three actions grant read access to Spark pools, SQL pools, and integration runtimes. The final entry is not part of the built‐in Synapse User role but is added to allow the individual to create support cases with Microsoft, if required. This additional permission calls out the fact that if a built‐in RBAC role doesn’t match your needs, it is possible to create custom roles. Notice that the IsCustom attribute is true. To see a list of all built‐in Azure Synapse Analytics roles, visit https://docs.microsoft.com/en-us/azure/synapse-analytics/security/synapse-workspace-synapse-rbac-roles.
Since Azure AD is the place where most of your authentication and authorization activities will happen, it is very important to have some tools to make sure all is working. If you see in the audit logs that many of your employees are failing to be authenticated because of IP location, you might want to…
