This article explains how Azure organizes environments, manages access, and grants permissions and how those concepts map to the Drata Azure integration. It provides the background needed to understand how Drata uses Azure identity, role, and resource structures to monitor configuration, collect evidence, and support access reviews.

Before diving into specific Azure components, it helps to understand how Azure is structured at a high level.

Azure organizes environments in a top-down hierarchy. Everything starts with a single Microsoft Entra tenant, which defines identity and access for the entire environment. Subscriptions, applications, users, and resources all connect back to this tenant and inherit its boundaries.

As you read this section, start at the tenant level and move downward. Each concept builds on the one before it, and understanding this hierarchy will make it easier to see how permissions, roles, and the Drata Azure integration fit together.

Everything in Azure starts with a Microsoft Entra tenant. A tenant represents your organization's Azure environment. It tracks identities and governs which applications can request access.

At this level, Azure defines:

Every Azure environment has exactly one tenant. All other Azure components connect back to it.

Azure subscriptions are connected to your Microsoft Entra tenant. The tenant determines who can access Azure, while subscriptions determine what they can access.

Azure subscriptions are containers that group and manage resources and provide a boundary for billing and access control. Each subscription contains:

An organization can have one or many subscriptions, all linked to the same tenant.

Organizations often use multiple subscriptions to separate:

Connecting all relevant subscriptions to Drata enables monitoring and evidence collection across all in-scope environments. If you manage many subscriptions, you can use Azure Management Groups to apply access and policies across them.

Azure assigns roles to identities to control access.

Azure roles apply within subscriptions and define allowed actions on resources. Roles can be assigned to:

Roles can be scoped at:

Drata relies on roles to read configuration and infrastructure data without making changes.

The Global Administrator role is the highest-privilege role at the tenant level.

It allows users to:

This role is required to set up the Drata Azure integration but does not provide direct access to subscription resources.

Registering an app creates an application identity in your Microsoft Entra tenant.

This identity can:

This lets Drata securely access resources without relying on a personal user account.

Once an application is registered, Azure needs a way to apply permissions to it inside subscriptions. That is the purpose of a service principal.

The service principal is the identity Azure uses to enforce permissions. It represents the app within your subscriptions and receives any Azure role assignments (such as Reader or Key Vault Reader).

For the Drata integration, the service principal is what allows Drata to:

You don’t need to manually create the service principal—Azure handles it automatically during app registration. But it's essential to understand that this is the identity Drata uses when interacting with your Azure resources.

Directory data in Azure lives at the tenant level and includes:

This data describes who exists in the organization and how access is structured. Azure manages this data separately from subscription resources like virtual machines or storage.

Microsoft Graph is the API used to read tenant-level directory data. These permissions:

When you grant Microsoft Graph API application permissions during setup, you are allowing the registered app to read specific types of directory data from the tenant.

Azure RBAC controls access to subscription-level resources. It evaluates:

RBAC applies only to Azure resources, such as virtual machines, storage accounts, and networking components. It does not apply to directory data.

A Drata Azure integration is a secure connection between Drata and your Azure environment that enables automated monitoring, evidence collection, and access review support.

Instead of relying on manual uploads or personal user accounts, the integration uses an application identity with scoped permissions to securely access the data Drata needs.

Common use cases include:

As part of the integration, Drata can import user and group data from Microsoft Entra. This process, called user syncing, allows Drata to:

You control user syncing by specifying which Microsoft Entra groups Drata should import:

You can also use dynamic groups, which automatically update based on attributes like department or role. This helps ensure that user scope stays accurate without manual updates.

Drata relies on permissions applied across multiple Azure layers to function effectively. Here’s how each piece fits together:

These layers work together to give Drata the access it needs to:

All without modifying resources.

Drata recommends a default permission model that balances security and functionality. By default, the integration uses:

This model provides the access needed for most use cases while limiting unnecessary exposure.

If additional access is needed to support specific services or tests, you can expand permissions incrementally—without assigning broad administrative roles.

To stay secure and audit-ready, always follow the principle of least privilege.

This approach helps reduce risk, contain misconfigurations, and ensure your Azure integration stays secure and compliant over time.