How Microsoft Azure Works with Red Canary

Red Canary cannot assign IAM permissions to anything inside the Management Groups/Subscriptions/Resources of your Azure environment. Red Canary does require write permissions to configure log streaming on individual Azure resources inside the subscriptions. As a specific example, Red Canary configures every Key Vault to stream access logs to our Event Hub. Without write permissions, Red Canary cannot complete the setup required to ingest Azure logs or maintain coverage as you add new cloud infrastructure to your environment.

Owner is the least privileged Managed Identity Role that Red Canary has found that can run the required policy remediation actions. Red Canary does not use the service principals, all deployments running as the policy service principal are started from within Azure.

No new policies are deployed, only the policies in the bicep file and these policies are not modified, viewed, edited or accessed by Red Canary. After onboarding, we do list resources and create exports into Red Canary’s Event Hubs; however, this is done via custom automation within our systems, and not via Azure policies.

Red Canary does not define, create, deploy, or apply new policies inside your Azure environment. The two policies provided in the bicep file will mark any new subscriptions as Out Of Compliance and remediate them to create a Resource Group and Lighthouse connection to enable monitoring. Red Canary has the ability to create new policies with the permissions above, but cannot attach service principals for remediation. If new or updated policies are required, Red Canary will contact customers to deploy any new changes.

The location is only used to execute the Bicep file, which grants access to Red Canary. The actual data export will operate in the same regions as your infrastructure.

During onboarding, the bicep file creates two policies: one that grants Red Canary access to each subscription and one that creates a resource group in each subscription for placing Defender for Cloud streaming configurations. The AZ account list commands create a policy evaluation and remediation task for each account (subscription) and policy so that the process to grant access starts as soon as possible.

A security configuration is not required for onboarding. As mentioned earlier, the region specified is only used to set up global access. Actual communication and data exports stay inside the region.

No, you do not need to change regions.

1. From your Microsoft Azure homepage, in the search bar, type and then select Management groups.

   

2. If there are no management groups listed, click Start using Management Groups to enable management groups in your Azure directory.

   

3. Refresh the page and verify the listing includes the default Tenant Root Group Management Group created for your directory.

   

Yes. Follow the steps below to limit Red Canary’s access to your Azure subscriptions and resources.

Scoping diagnostic settings to select Azure subscriptions

By default, Red Canary requests access permissions to be granted on the Tenant Root Group management group. This enables Red Canary to monitor control plane activity for all resources within all subscriptions.

Red Canary users can limit the scope of Red Canary’s monitoring by utilizing management groups that contain only the subscriptions they wish to have monitored.

If your organization still needs to enable Management groups, you must do so. For more information on this process, see how do I enable Management groups in my Azure directory. If you can navigate to management groups in the Azure portal and see a root management group, they are already enabled.

Step 1.4 requires you to build a command that will be executed in the Azure Cloud Shell. Within this command, we ask you to paste your “<Tenant ID>” into the Red Canary provided code. This command should be replaced with the ID of the management group containing the subscriptions to be monitored.
Example:

az deployment mg create --name 'RCLogIngestPolicy' \

--location eastus \

--template-file RedCanary.bicep \

--management-group-id <TenantId>

becomes

az deployment mg create --name 'RCLogIngestPolicy' \

--location eastus \

--template-file RedCanary.bicep \

--management-group-id <Management Group ID>

You then run the two commands from Step 1.12. These commands will apply the bicep file from earlier to all of the subscriptions utilizing an Azure Policy. For more information, see Microsoft’s Azure Policy overview.

During the remediation of the Azure Policy, multiple errors will occur where the policy cannot apply to subscriptions not in the management group. These errors are expected behavior when only onboarding a portion of subscriptions. The errors warn that the bicep file did not apply to all the tenant subscriptions. To check for successful onboarding, look at the Azure policy’s compliance page to ensure that the subscriptions in the management group meet the policy.

Log Analytics Workspace & Entra ID Logs (Tenant Level Logs)

Entra ID creates logs at the Tenant Level. These logs focus on Audit and Login actions. Red Canary ingests these logs to provide identity-based protection. For more information, see the Azure Audit Logs overview and the Entra Sign-in Logs overview.

Step 2 asks you to configure an Azure Log Analytics workspace to collect Entra ID logs.

To ingest these logs, Red Canary must have access to the Log Analytics Workspace subscription. Therefore, the Log Analytics Workspace must be in one of the subscriptions belonging to the management group to which Red Canary has been granted access.

If your organization already pushes Microsoft Entra ID Logs to a Log Analytics workspace in a subscription not contained in the Management Group, create a second Log Analytics workspace to which Red Canary does have access. This second Log Analytics workspace may incur additional costs. For more information, see Azure Monitor Pricing.

Each customer’s Azure Tenant is mapped to its own Event Hub within a shared namespace in Red Canary’s Azure tenant. While multiple customers may share an Event Hub namespace, each integration has its own Event Hub, and data is not accessible between customers. Red Canary’s authorization rules ensure that customers have no read or management access to other tenants’ data.