Connect an Azure subscription

Connect an Azure subscription step by step. Register the subscription, delegate it to WASViking with the Reader role through Azure Lighthouse using the generated ARM template, Terraform module, Azure CLI script or portal steps, validate, optionally grant the read-only directory consent, and read the first results in Azure words with changes judged from the Activity Log.

This guide connects an Azure subscription to WASViking^® Cloud Security next to your AWS accounts and Google Cloud projects, in the same screens. By the end the subscription is read through a delegation you own, every resource is in the inventory and evaluated, administrative changes are judged minutes after Azure records them, and the first contextual risks and attack paths are on screen in Azure words. Nothing here creates a credential in your tenant: you delegate the subscription to the WASViking tenant with the built-in Reader role through Azure Lighthouse, and you remove that delegation whenever you choose.

Before you start

Cloud Security is an add-on module, available from the Pro plan, enabled per organization by your WASViking contact or partner. The package includes one connected account; an AWS account, a Google Cloud project and an Azure subscription each count as one. Registering and validating connectors needs the Manage permission on the module.

On the Azure side you need someone who holds Owner on the subscription you are connecting and who is a member of the subscription's tenant: Azure Lighthouse refuses a delegation deployed by a guest account. That person deploys the ARM template, applies the Terraform module, runs the Azure CLI script in Cloud Shell, or follows the portal steps.

Have at hand the subscription id (the GUID the Subscriptions page shows, not the display name) and the e-mail of the team that owns the subscription.

The delegation needs the Microsoft.ManagedServices resource provider registered in the subscription. The script registers it; with the template or the module, register it once under Subscriptions, Resource providers, if the deployment asks for it. The providers of the services you use stay as they are: a service whose provider is not registered reads not enabled in the validation and its resources are simply not read.

Optional, for the directory: to read Microsoft Entra ID next to the subscription (users, groups, service principals, applications, MFA registration, directory roles, Conditional Access and security defaults), a Global Administrator of the tenant grants a consent in Step 3. Everything else works without it.

Step 1: register the subscription

Open Cloud Security → Accounts & Connectors and click Connect account. Choose the Azure card and fill in:

• Account name, as your team calls the subscription ("Customer apps", "Payments production").
• The Azure subscription id: the GUID, as the Subscriptions page shows it.
• Environment: Production, Staging, Development, Shared, Security, Sandbox or Audit. The environment weighs the risk score of every resource in the subscription.
• Owner: the e-mail that receives the subscription's health notices.

The Delegated role reads Reader (built-in) and cannot be changed: an Azure Lighthouse delegation carries built-in roles only, and Reader is every control-plane read and no write. The right panel shows what the delegation you are about to create will trust: the WASViking tenant, the delegated principal WASViking Cloud Security, an External ID generated for this connector only, the role and Write access: No. Click Register and get the deployment artifacts. The subscription now appears in the accounts table and the wizard can be resumed from there at any time.

Step 2: delegate the subscription

The deploy page offers four ways to create the same delegation. All four create two objects in your subscription: a registration definition that names the WASViking tenant and the WASViking Cloud Security principal with the Reader role, and the registration assignment that applies it. The definition's description carries this connector's External ID. None creates a credential and none grants a write.

• ARM template (recommended): Download template and deploy it at the subscription, either with az deployment sub create --location eastus --template-file <file> from the directory holding the file, or from the portal's Deploy a custom template page with Build your own template in the editor. The location only stores the deployment's metadata; the delegation has no region.
• Terraform: Download module and apply it with an identity that holds Owner on the subscription: upload the file to an empty directory, then run terraform init and terraform apply there. The ids of the definition and the assignment are stable, so a later apply updates the delegation in place.
• Azure CLI: Download script and run it with bash in Cloud Shell or in a terminal signed in to the subscription's tenant. It registers the resource provider, creates the definition and the assignment with two az managedservices commands, and lists the delegation at the end.
• Manual: See the steps: paste the template in the portal's custom deployment, deploy it at the subscription, then check that Service providers, Delegations lists WASViking Cloud Security with the Reader role and the External ID in its description.

The External ID is shown on this page to members with the Manage permission, with a copy button; it never appears in lists, notifications or exports. If it ever leaks, Rotate External ID issues a new one and keeps the previous one valid for 24 hours. While the window is open the deploy page shows a Rotation pending block with the Azure CLI line that updates the description of the existing delegation in place; deploying the template again, or applying the module again in the directory of the first apply, does the same.

Step 3: validate, and grant the directory consent (optional)

There is nothing to paste. Click Validate connection: WASViking reads the subscription through the delegation, finds the delegation that carries this connector's External ID, measures the role it grants against every read the inventory needs, lists the registered resource providers and discovers the locations. The result shows:

• the delegation found and its role,
• the subscription matched, with its tenant,
• the directory consent, granted or not,
• the identity reads, granted or not (optional, see below),
• the locations that will be read,
• the services whose resource provider is not registered, if any (their resources are not read; nothing to fix unless you use them),
• Permission coverage: the share of reads the delegation allows,
• the missing reads, if any, with a Fix access block: the template to deploy again when the delegation names another role, or the consent to grant when a directory permission is missing,
• the estimated duration of the first sync.

A validation that fails stays on this step with the reason and what to change (see Troubleshooting). A validation that succeeds marks the subscription Healthy, or Permission gap when some reads are denied, and queues the first full sync at once.

The Directory reads (optional) block offers Grant the directory consent. A Global Administrator of the tenant clicks it, signs in on the Microsoft consent page and accepts five application permissions, all read-only: AuditLog.Read.All, Directory.Read.All, Policy.Read.All, RoleManagement.Read.Directory and UserAuthenticationMethod.Read.All. The page returns to the wizard and the next validation reads Directory consent: Granted. Without the consent the records of the directory (MFA for administrators and for all users, legacy authentication, the number of Global Administrators, user consent, guest invitations, inactive accounts, application credentials) read Not evaluated with the reason, never Passed, and every other record evaluates normally.

Identity reads (optional)

An Azure Lighthouse delegation never shows the role assignments of your own tenant: who holds which role on the subscription, including the managed identities of your workloads. To let WASViking evaluate them (the identities of your workloads, who can read each data store, and the attack paths that go through an identity), the Identity reads (optional) block of Step 3 asks for one more read-only grant, after the directory consent:

1. Grant the directory consent first: it registers the WASViking Cloud Security application in your tenant.
2. Give that application the built-in Reader role at the subscription (at the management group when the connector reads a management group). Either run the Azure CLI line the block shows, from Cloud Shell signed in to your tenant with an identity that can assign roles (Owner or User Access Administrator), or open the subscription in the Azure portal, Access control (IAM), Add role assignment, pick Reader, then select WASViking Cloud Security as the member.
3. Click Validate again: the result reads Identity reads: Granted and the next sync reads the role assignments of your tenant.

The role is read-only and appears on your Access control page like any other assignment. The block also shows the line that removes it; without it everything else works and the identity records read the delegation's view only.

Step 4: real-time changes

Nothing to deploy. WASViking reads the Activity Log of the subscription every minute through the same delegation, so an administrative change becomes a judged change row minutes after Azure records it, instead of waiting for the next full sync. Azure writes an event three to twenty minutes after the operation; the change row keeps the time of the operation, the caller (a person by their sign-in name, an application by its name when the inventory holds it, a managed identity by its workload), the client address and where the change was made (the Azure portal, the command line, a pipeline). Only the administrative category is read, and the request and response bodies of an event are never stored.

The step shows a state rather than a switch: Waiting for events until the first change arrives, Receiving events with the time of the last one afterwards, or Paused when the organization turned real-time evaluation off in Settings. The accounts table reads Periodic, Receiving or Paused for each connector. The changes the full sync finds between two reads name their actor through the same log.

Assisted remediation (Step 5 on AWS and Google Cloud) is not offered on an Azure connector: every finding carries its guided plan in four forms (portal steps, Azure CLI, Terraform and the Azure Policy definition that prevents the state, with its built-in id where one exists) and you apply it yourself.

The first sync

The accounts table shows the sync progressing by collector (the subscription and its resource groups, role assignments and custom roles, managed identities, the Entra directory and its principals when consented, virtual networks, network security groups, interfaces and public addresses, load balancers and application gateways, firewalls, Bastion, gateways, private endpoints, route tables and NAT gateways, Network Watcher and flow logs, DNS zones, virtual machines and scale sets, AKS, Container Registry, App Service, managed disks and snapshots, storage accounts, key vaults, Azure SQL, the PostgreSQL and MySQL flexible servers, Cosmos DB, Azure Cache for Redis, Event Hubs, Service Bus, the Activity Log export and alerts, Log Analytics, Microsoft Defender for Cloud, Azure Policy, Azure AI services and Azure Machine Learning). The Overview stays in its "first sync running" state until the evaluation completes, then shows the Cloud Risk ring with every point named, the posture by domain and the first findings. The controls of an Azure subscription are referenced to the CIS Microsoft Azure Foundations Benchmark v3.0.0, PCI DSS 4.0.1 and NIST SP 800-53; the Compliance page shows the CIS Microsoft Azure card for the subscription.

What to look at next:

1. Overview: the coverage confidence banner (if below 100 percent, open the gaps and apply the Fix access block), the top toxic combination and the highest priority risks.
2. Posture Findings: start with the Contextual risks tab; each one names the components of the combination and how to break it. The Control failures tab filtered by the subscription lists every failing control with its CIS Microsoft Azure reference.
3. Attack Paths: the featured chain and its recommended break option, written in Azure words (anonymous blob access, the firewall rules of a SQL server, the managed identity a public app runs as, the role assignment to narrow).
4. Cloud Inventory: open any resource to read its configuration, the graph around it and its exposure path (the public address, the network interface and the network security groups of the subnet and the interface that admit the internet to it).
5. Architecture Map: the subscription drawn with its virtual networks, their subnets and the machines placed in the subnet of their interface.

Reading every subscription of a management group

One connector can read every subscription under a management group. In Step 1, fill Management group scope with the management group id (the identifier, not the display name; for example mg-platform) and register a subscription under it as the central one. Azure Lighthouse delegates subscriptions, never a management group, so the artifacts of Step 2 assign at the management group the Azure Policy Microsoft documents for this: it deploys this connector's delegation (the same Reader role, the same External ID) into every subscription under the management group, the existing ones through a remediation task and the new ones as they arrive.

• Register the Microsoft.ManagedServices resource provider in the subscriptions first; the script does it for every enabled subscription of the tenant you can see.
• Deploy the template at the management group (az deployment mg create, or the portal's custom deployment at the management group scope) with an identity that holds Owner there. It creates the policy definition, its assignment with a system-assigned managed identity and Owner for that identity at the management group: the policy needs it to create the delegations. That identity is yours, in your tenant; WASViking never sees it.
• Azure Policy evaluates a new assignment within about thirty minutes. Then delegate the existing subscriptions: run the script again with REMEDIATE=1, or open Policy, Remediation and remediate the assignment. The Terraform module creates the remediation task itself.

After the first sync of the central subscription, every subscription delegated with this External ID appears in the accounts table as a connector of its own, marked Discovered subscription. It needs nothing deployed: it validates itself as soon as it is discovered and runs its first sync right after. A rotation of the central connector's External ID moves every discovered subscription with it; the Rotation pending block carries the line that updates the delegations already made. A subscription already delegated to WASViking by another connector keeps that connector.

Day two

• Settings: the tag data-classification on a storage account, a database or a key vault declares its classification (pii, pci, phi, secrets, internal), the tag public-by-design on a machine or an App Service site declares that it answers the internet on purpose, and the owner, environment and criticality tag keys are the ones you set there, as on AWS.
• Identity: every principal that holds a role assignment in the subscription is profiled (people, groups, applications and managed identities), named after its directory entry when the consent is granted, with the escalation paths its roles open (Owner, User Access Administrator, Managed Identity Operator, a custom role that writes role assignments, a directory administrator).
• Native signals: the Microsoft Defender for Cloud plans, the secure score, the unhealthy assessments and the security contacts, and the Azure Policy assignments (the Microsoft cloud security benchmark initiative, an allowed locations policy), count toward the detection and guardrail controls. All are read by Reader.
• Policies & Controls: the policy packs apply to every provider; the control library lists the Azure controls with their CIS references; exceptions are time bound and need an approver.
• Reports & Evidence: the executive PDF, the posture and inventory exports and the evidence pack include the Azure subscription next to the AWS accounts and the Google Cloud projects.
• Permission baseline: Reader carries every control-plane read, so a new check rarely asks anything of you; when WASViking adds a directory permission, the validation lists it and the consent is granted again from Step 3.
• More subscriptions: one connector is one subscription; repeat the steps per subscription, or scope one connector to a management group (above). The template and the module take the subscription id and the External ID, so a second subscription is a second deployment.

Troubleshooting

Removing a subscription

Remove on the accounts table stops the reads at once. The inventory and the evidence are kept for the deleted-resource retention window set in Settings so reports stay reproducible, then purged. On your side, delete the delegation from Service providers, Delegations (or destroy the Terraform module), remove the Reader role of the WASViking Cloud Security application if you granted the identity reads, and, if you granted the directory consent, delete the WASViking Cloud Security application under Enterprise applications; nothing on the WASViking side can keep them.