How do we connect Wiz to AWS Organizations and multiple Azure subscriptions with least-privilege access (what roles/permissions are needed)?

Most teams connecting Wiz to AWS Organizations and multiple Azure subscriptions want two things at once: fast, agentless onboarding and strict least‑privilege access. You don’t need admin‑level permissions everywhere to get value from Wiz, but you do need to design the AWS roles and Azure app/role assignments carefully so the Security Graph can see enough to model real attack paths, without opening up unnecessary write access.

Below I’ll walk through a practical, least‑privilege pattern I’ve used in multi‑cloud environments, optimized for the operating model Wiz expects: agentless discovery across AWS Orgs and Azure tenants, deep internal analysis mapped to identities and data, and a path from exposure to code fix and runtime validation.

Note: Exact JSON policies and CLI commands are versioned in Wiz’s docs and onboarding wizard. Use this article as your design blueprint and cross‑check specific statements against the latest Wiz setup guide in the product UI.

---

The Quick Overview

• What It Is: A connection model and permission set that let Wiz scan AWS Organizations and multiple Azure subscriptions agentlessly, with read‑only or tightly scoped write privileges, so it can build the Wiz Security Graph without over‑permissioning your cloud.
• Who It Is For: Cloud security engineers, platform teams, and CISOs consolidating cloud visibility across many AWS accounts and Azure subscriptions—especially those standardizing on least‑privilege access and audited role assumptions.
• Core Problem Solved: You avoid the usual tradeoff between “give the tool admin everywhere” and “cripple visibility.” Instead, you give Wiz just enough access to map code, cloud resources, identities, network, and data across all your environments, and let it drive accurate prioritization and remediation.

---

How It Works

At a high level, connecting Wiz to AWS Organizations and Azure looks like this:

1. Centralize cross‑account / cross‑subscription access:

   • In AWS, create an Organization‑level role that member accounts trust, and let Wiz assume an external role from its Wiz-owned AWS account.
   • In Azure, register a multi‑tenant application for Wiz and assign it least‑privilege roles in each subscription (or via management groups).

2. Align permissions with Wiz’s job:

   • Wiz needs read access to cloud control planes (EC2, S3, IAM, Azure Resource Manager, Azure AD/Microsoft Entra ID, etc.) and optional write/grant for specific functions (e.g., auto‑tagging, ticket integration in some patterns).
   • The goal is to give Wiz visibility into external exposure, identity paths, misconfigurations, vulnerabilities, and data access chains, without broad modify/delete rights.

3. Wire it into Wiz’s onboarding:

   • You paste AWS account/role ARNs and Azure app IDs/tenant IDs into Wiz.
   • Wiz verifies trust relationships and permissions, then begins agentless discovery and deep internal analysis within minutes.

---

AWS: Least‑Privilege Access for AWS Organizations

1. Architecture Overview

You’ll typically use this pattern:

• Wiz AWS account → IAM Role in your AWS Org
  • You create an IAM role in a designated “security” or “shared services” account within your AWS Organization.
  • This role:
    • Trusts Wiz’s AWS account (via an external ID) to be assumed.
    • Has a policy with cross‑account read permissions, and optionally some limited write where needed.
  • Member accounts in the Organization either:
    • Directly trust this central role, or
    • Use a stack set / baseline to deploy a per‑account role that delegates back to the central role.

This keeps your onboarding manageable at scale while aligning with Org‑wide governance.

2. Core Permissions Needed

Think in terms of what Wiz needs to do:

1. Inventory and posture (CSPM / CNAPP base):

   • Read access to:
     • ec2:* (Describe‑only APIs)
     • rds:* (Describe)
     • eks:* (Describe/List)
     • lambda:* (List/Get)
     • s3:* (ListBuckets, GetBucketAcl, GetBucketPolicy, GetBucketLocation, GetBucketLogging, GetBucketTagging)
     • elasticloadbalancing:* (Describe)
     • cloudformation:Describe*, List*
     • config:Get*, Describe*
     • kms:List*, Describe*
     • secretsmanager:List*, Describe*
   • This lets Wiz discover resources and configuration across compute, storage, networking, and platform services.

2. Identity, network, and data context:

   • Read access to:
     • iam:List*, iam:Get*
     • organizations:Describe*, List*
     • sts:GetCallerIdentity
     • guardduty:List*, Describe* (if integrating with GuardDuty)
     • cloudtrail:DescribeTrails, LookupEvents, GetTrailStatus
     • logs:DescribeLogGroups, DescribeLogStreams
   • This is critical for the Wiz Security Graph: modeling identity paths, lateral movement, and data access chains.

3. Optional runtime and container detail:

   • If you connect EKS/ECS/Kubernetes, you’ll also allow Wiz to:
     • Discover clusters via eks:ListClusters, DescribeCluster
     • Pull metadata required for container and workload security (still read‑heavy; Wiz’s eBPF Runtime Sensor is separate and deployed where you opt‑in).

4. No blanket write privileges needed:

   • Wiz does not need power to create/delete infrastructure in your AWS accounts for core visibility and risk modeling.
   • Optional write actions are limited to specific workflows (for example, if you enable certain auto‑tagging or remediation features). You can keep those in a separate, opt‑in policy to maintain strict separation.

3. Example Role Shape (Design, not full JSON)

In your security account:

• Trust policy:

  • Principal: Wiz’s AWS account ID
  • Condition: sts:ExternalId with a Wiz-provided external ID
  • Action: sts:AssumeRole

• Permissions policy (read‑only baseline):

  • Multiple Statement blocks with:
    • Effect: Allow
    • Action: [ "ec2:Describe*", "rds:Describe*", ... ]
    • Resource: "*", because AWS Describe/List actions typically don’t support fine‑grained resource ARNs and are inherently global/scoped via account.

You then either:

• Attach an AWS Organizations Service Control Policy (SCP) to ensure no broader permissions are granted than your baseline, or
• Manage per‑account roles via CloudFormation StackSets that delegate to the central role.

---

Azure: Least‑Privilege Access Across Multiple Subscriptions

1. Architecture Overview

In Azure, Wiz connects via a service principal (app registration) with delegated rights across subscriptions:

• Wiz app registration in Azure AD/Microsoft Entra ID
  • Creates a service principal in your tenant.
  • The service principal is granted roles in each subscription or management group that you want Wiz to monitor.

This allows multi‑subscription, multi‑tenant visibility without an agent farm or per‑VM identity changes.

2. Core Roles and Permissions

Wiz’s Azure integration needs to read across the Azure Resource Manager plane, plus identity and security configuration.

The most common least‑privilege pattern is:

1. Per‑subscription role assignment:

   • Assign Wiz’s service principal the Reader role at:
     • Subscription scope, or
     • Management group scope (if you want to cover many subscriptions centrally).
   • Reader gives:
     • Read access to all resource types in that scope (compute, storage, network, databases, PaaS services).
     • No write or delete rights.

2. Directory‑level read for identity and entitlement context:

   • In Microsoft Entra ID (Azure AD), you give the Wiz app:
     • Directory read permissions (e.g., Directory.Read.All) to:
       • Enumerate users, groups, service principals, and their roles/assignments.
   • This is essential for CIEM‑level analysis: mapping excessive privileges, lateral movement, and privilege escalation paths between identities and resources.

3. Optional security‑specific APIs:

   • If you want Wiz to ingest from Azure-native security services and logs for deeper context:
     • Permissions to query Microsoft Defender for Cloud or related APIs.
     • Access to Log Analytics workspaces (read‑only) if you route logs there for runtime correlation.

3. Recommended Role Model

• Subscription/management group level:

  • Assign Reader to the Wiz service principal.
  • Optionally add Security Reader if you want it to pull security alerts and recommendations from native services.

• Azure AD / Microsoft Entra ID:

  • Grant the app Application permissions (with admin consent) for:
    • Directory.Read.All
    • Group.Read.All
    • User.Read.All
    • RoleManagement.Read.All (if you want full role assignment visibility)
  • These are read‑only, but powerful; ensure they’re approved via your normal app governance board and logged.

This gives Wiz enough to build a cross‑subscription identity and access graph without the ability to modify tenant configuration.

---

How Wiz Uses These Permissions

Once AWS and Azure are connected with the roles above, Wiz performs:

1. Attack surface scanning

   • Maps externally reachable assets in every AWS account and Azure subscription: public IPs, load balancers, exposed storage buckets, web apps, APIs.
   • Uses security group, NSG, route table, and WAF configuration to calculate effective internet exposure, not just “has a public IP.”

2. Deep internal analysis

   • Correlates:
     • Cloud resources (EC2, VMs, containers, PaaS)
     • Identities and roles (IAM, Azure AD)
     • Network paths
     • Data locations (S3, Blob, databases)
   • Builds the Wiz Security Graph: modeling initial access, lateral movement, privilege escalation, and data access chains across your entire AWS Org and Azure estate.

3. From exposure to code fix

   • With this context, Wiz can:
     • Prioritize findings based on exploitability and blast radius, not just CVSS.
     • Map issues to ownership (team, repo, service), and—if you enable it—have the Wiz Green agent open PRs with code or IaC fixes.
   • Importantly, this does not require write permissions in your cloud environments; fixes are generated as code changes back in your repos, where your normal CI/CD controls apply.

4. Detect and block (optional runtime)

   • If you enable the eBPF Runtime Sensor and runtime integrations, Wiz combines:
     • Cloud and SaaS logs
     • Runtime telemetry
     • The existing cloud configuration and identity graph
   • to detect and block real exploitation attempts. These runtime hooks are separate from the core AWS/Azure read‑only roles described above.

---

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Agentless multi‑cloud onboarding	Connects Wiz to AWS Organizations and Azure subscriptions using cross‑account roles and SPNs.	Visibility in minutes across accounts and subscriptions without deploying agents everywhere.
Least‑privilege security graph	Uses read‑only access to model resources, identities, network, and data into the Wiz Security Graph.	High‑fidelity attack path analysis without granting broad modify/delete permissions to a third‑party.
Ownership‑aware remediation	Maps findings to teams/services and generates code‑level fixes (PRs) via Wiz Green agent.	Turns cloud findings into actionable tasks for engineering, hitting remediation SLAs without friction.

---

Ideal Use Cases

• Best for multi‑account AWS Organizations: Because the cross‑account role pattern scales to hundreds or thousands of accounts, giving Wiz a consistent, least‑privilege view of your Org without one‑off role sprawl.
• Best for enterprises with many Azure subscriptions/tenants: Because a single Wiz service principal can be granted Reader and directory read access across subscriptions, letting you see identity paths and blast radius across the entire estate.

---

Limitations & Considerations

• Read‑only won’t auto‑enforce: Least‑privilege access is intentionally read‑heavy. Wiz will identify and prioritize risk, and can generate fixes as code, but it won’t directly change cloud resources unless you explicitly choose workflows that require limited write permissions and configure them.
• Identity graph requires directory consent: To get full identity and entitlement visibility in Azure, you must grant directory read permissions via admin consent. If this is blocked, Wiz’s ability to model privilege escalation and lateral movement in Azure will be reduced.

---

Pricing & Plans

Wiz pricing is tailored to your environment’s scale and use cases, typically based on covered workloads and platforms rather than per‑user licensing. Connecting AWS Organizations and multiple Azure subscriptions with least‑privilege access is fully supported in standard Wiz Cloud deployments.

• Wiz Cloud (Core CNAPP): Best for security and platform teams needing unified context across AWS, Azure, and other clouds—CSPM, container/Kubernetes security, and identity/data mapping in a single security graph.
• Wiz Cloud with Runtime & Agents: Best for organizations extending from exposure management into real‑time detection and response, combining the Security Graph with runtime sensors and AI agents (Wiz Red for automated attack path discovery, Wiz Blue for SecOps investigation).

Your Wiz account team can size the right plan once you share approximate workload counts and cloud footprint.

---

Frequently Asked Questions

Do we have to give Wiz admin rights in our AWS accounts and Azure subscriptions?

Short Answer: No. Wiz is designed to operate with read‑only or tightly scoped permissions and does not require full admin rights for core visibility and risk modeling.

Details:
In AWS, Wiz typically assumes a role with Describe/List permissions across EC2, S3, RDS, IAM, and other services, plus identity and log metadata. In Azure, a Reader role at subscription or management group scope plus directory read permissions is sufficient for most use cases. Write privileges are only needed for specific optional workflows (like some automated remediation patterns) and can be isolated into separate roles or policies if you enable them.

---

How do we audit and monitor what Wiz can access across AWS Organizations and Azure?

Short Answer: Treat Wiz like any other privileged (but read‑only) security integration: monitor role assumptions, app sign‑ins, and API calls via native cloud logs.

Details:
In AWS, CloudTrail will log every AssumeRole into the Wiz role and the resulting API calls. You can:

• Filter by Wiz’s AWS account ID or external ID.
• Alert on unexpected actions (e.g., write operations that shouldn’t be possible with the assigned policy).

In Azure, you can:

• Track the Wiz service principal’s sign‑ins and activity through Entra ID sign‑in logs and Azure Activity Logs.
• Use Azure Monitor / Log Analytics to build queries and alerts for that app’s operations.

Because Wiz uses predictable, read‑focused patterns, any deviation stands out and can be investigated quickly.

---

Summary

Connecting Wiz to AWS Organizations and multiple Azure subscriptions with least‑privilege access comes down to designing the right roles and app permissions: cross‑account read roles in AWS, Reader and directory read in Azure. With that foundation, Wiz can build its unified Security Graph—linking resources, identities, network, and data—without asking for blanket admin rights.

That graph is what lets you prioritize by exploitability, internet exposure, identity paths, and blast radius instead of drowning in CVSS‑only queues. And because the model is read‑heavy, you can safely move from exposure to code fix and runtime validation while maintaining tight control over who can change what in your cloud.

Next Step

Get Started