In part three of the Azure logging guide series, we discuss the best practices for logging with Azure and why these practices are highly recommended. We also cover the security considerations for monitoring data on Azure, along with the roles and permissions in Azure Monitor.

Best Practices for Logging With Azure

By adopting the following recommended logging practices, you can maximize the full potential of the various logging capabilities provided by Microsoft Azure. As software development teams create logs for proper analysis, they’ll be better equipped to understand the behavior and health of their application.

Enable Azure Diagnostics

To gather diagnostic information from your Azure services, use Azure Diagnostics for logs, metrics and traces. With Azure Diagnostics, the data accumulates in a single location. Use this information to investigate issues, track system performance and more.

To enable Azure Diagnostics, navigate to your Azure Web Application and select App Service Logs.

Turn on Application Logging (Blob) and click on Storage Containers to create a new storage container that will connect the logs.

Fill in the properties for the storage account and storage container.

After successfully creating the storage container, it will appear as the linked storage container for App Service logs.

Log all exceptions

Receive the full context of what’s happening in your system by logging every exception, both unhandled and handled — handled exceptions are important to log too. Even if the exception has not terminated the application, it can cause other issues. Error log data is useful for resolving problems and preventing them from happening again.

Set up alerts for important errors

Important application problems can go unnoticed and may lead to significant issues in the future. As a result, it’s crucial to have a reliable monitoring and alerting system, such as Azure Monitor, that can inform the software engineering team immediately after these errors occur.

Use log data and other application information to create real-time alerts in Azure Monitor. By setting up alerts, you can receive notifications immediately after an error occurs, giving you plenty of time to act.

Use Microsoft OMS features in the Log Analytics workspace

Microsoft Operations Management Suite (OMS) has fully transitioned into the Azure portal. The major selling point is its ability to gather and analyze data from various Azure resources all in one place.

Additionally, the feature offers integrated dashboards and reports that give you visibility on the information about your Azure environment. That way, you can easily analyze problems, resolve issues, and improve performance.

Create a Log Analytics workspace on the Azure portal to get started.

Don’t collect personal data

Compliance and security are the two reasons you should not log personal data. Privacy laws in different regions enable users to request data exports and deletions. Meeting these requirements becomes difficult when user data exists in multiple systems beyond the application’s data store, such as in the logs.

Over time, logs have become targets for hacks and data breaches. Accidental data leaks also occur through application logs. An easy way to avoid this problem is to ensure personal data is not collected. In the event of a cyberattack, your users’ data will not be compromised.

Security in Azure Monitoring

Security is vital, as it protects all data against misuse, theft, and loss. With the right security policies, software development teams can control access to their log data, reducing the risk of data leaks. Additionally, considering security when monitoring data ensures compliance for applications containing large amounts of user data. This improves the application’s quality and protects the organization’s reputation.

Azure resources for storing or streaming log data include storage accounts and event hubs. These resources are general purpose, so only administrators should manage them. To prevent misuse, follow the recommended procedures below for monitoring relevant resources.

Limiting access to monitoring-related storage accounts

When an identity needs access to a storage account, create a shared access signature (SAS) on that storage account. This storage account should only have service-level, read-only access to Blob storage.

The following code snippet shows an example of how to create an SAS token for a user or application identity using PowerShell.

$storageContext = New-AzStorageContext -ConnectionString “<Monitoring Storage Account Connection String>”

$token = New-AzStorageAccountSASToken -ResourceType Service -Service Blob -Permission "rl" -Context $storageContext

After successfully creating the token, only the identity that needs access to the storage account Blobs can use that token to gain access.

Alternatively, if you want to manage all access with Azure role-based access control (RBAC), then you can grant the Contributor role to that identity. To do this, go to the monitoring storage account on the Azure Portal and click Access Control (IAM).

From here, click on Add role assignment and choose the Contributor role.

As a third alternative, you can also create a custom role to grant identities the Microsoft.Storage/storageAccounts/listkeys/actionpermission in PowerShell.

$role = Get-AzRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Custom Storage Account Reader"
$role.Description = "Can list the storage account keys for a storage account."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.Storage/storageAccounts/listkeys/action")
$role.Actions.Add("Microsoft.Storage/storageAccounts/Read")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/<subscription-id>/resourceGroups/<resource-group-id>/providers/Microsoft.Storage/storageAccounts/<storage-account-id>")
New-AzRoleDefinition -Role $role

Identities require this permission if they want to set a diagnostic setting or log profile to archive into a storage account.

Limiting access to monitoring-related event hubs

You can achieve access control for event hubs similar to storage accounts, but make a specific authorization rule for listening to events related to monitoring. Follow these next steps to give an identity the permission to listen.

Navigate to the Azure Portal and create a shared access policy for the event hubs that stream monitoring data with only listening claims.

Go to Shared access policies in the Event Hub resource, then click on + Add to create a shared access policy.

The ListKeys action for that event hub should be available to the identity that needs to obtain the key on demand. Identities that need to configure a diagnostic option or a log profile to stream to event hubs must also complete this step. For instance, here’s how you create a custom Azure RBAC role:

$role = Get-AzRoleDefinition "Reader"
$role.Id = $null
$role.Name = "Custom Event Hub Listener"
$role.Description = "Can get the key to listen to an event hub streaming monitoring data."
$role.Actions.Clear()
$role.Actions.Add("Microsoft.EventHub/namespaces/authorizationrules/listkeys/action")
$role.Actions.Add("Microsoft.EventHub/namespaces/Read")
$role.AssignableScopes.Clear()
$role.AssignableScopes.Add("/subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.ServiceBus/namespaces/<servicebus-namespace>")
New-AzRoleDefinition -Role $role

Roles and Permissions in Azure Monitoring

The use of roles and permissions in Azure Monitor helps you to restrict access to authorized identities. While there are built-in roles, you can also create custom roles.

Built-in monitoring roles

Azure Monitor has two built-in roles: Monitoring Reader and Monitoring Contributor. These roles allow software development teams to restrict access to resources while only allowing people monitoring the infrastructure to receive and configure the data they need.

Identities with Monitoring Reader permissions can view all monitoring data in an Azure subscription. However, they cannot update monitoring resource properties.

Unlike the Monitoring Reader, identities with Monitoring Contributor permissions can read monitoring data and update resource properties.

Monitoring permissions and Azure custom roles

If you want more granular permissions on your team because the built-in roles don’t fit your requirements, you can create an Azure custom role from the Azure portal.

To create a custom role, go to Access control (IAM) on the resource group and select Add custom role.

You can also enforce security without creating custom roles by using Azure Monitor’s regular RBAC permissions:

Permission	Description
Microsoft.Insights/ActionGroups/[Read, Write, Delete]	Manage action groups
Microsoft.Insights/ActivityLogAlerts/[Read, Write, Delete]	Manage activity log alerts
Microsoft.Insights/DiagnosticSettings/[Read, Write, Delete]	Manage log diagnostic settings
Microsoft.Insights/eventtypes/values/Read	Lists activity log events belonging to a subscription
Microsoft.Insights/LogDefinitions/Read	Access activity logs through the portal
Microsoft.Insights/LogProfiles/[Read, Write, Delete]	Manage log profiles
Microsoft.Insights/Register/Action	Register the resource provider for Azure Monitor

Check out part four of this series, where we will explore different log ingestion solutions for Azure

Log your data with CrowdStrike Falcon Next-Gen SIEM

Elevate your cybersecurity with the CrowdStrike Falcon^® platform, the premier AI-native platform for SIEM and log management. Experience security logging at a petabyte scale, choosing between cloud-native or self-hosted deployment options. Log your data with a powerful, index-free architecture, without bottlenecks, allowing threat hunting with over 1 PB of data ingestion per day. Ensure real-time search capabilities to outpace adversaries, achieving sub-second latency for complex queries. Benefit from 360-degree visibility, consolidating data to break down silos and enabling security, IT, and DevOps teams to hunt threats, monitor performance, and ensure compliance seamlessly across 3 billion events in less than 1 second.

Schedule Falcon Next-Gen SIEM Demo