4.3 Connecting Hybrid and Multi-Cloud Environments

Connecting Hybrid and Multi-Cloud Environments

Introduction

Most organisations do not run exclusively in Azure. They have on-premises servers in data centres, workloads in AWS or GCP (either intentionally or through shadow IT), and hybrid configurations where some services run on-premises and others in the cloud. Defender for Cloud’s value proposition depends on covering all of these environments — a security posture assessment that only covers Azure while ignoring the 200 EC2 instances in AWS is incomplete.

This subsection teaches you to connect three non-Azure environments to Defender for Cloud: on-premises servers (via Azure Arc), AWS accounts (via the native cloud connector), and GCP projects (via the native cloud connector). Each uses a different integration mechanism, provides different levels of protection, and has different limitations compared to Azure-native resources.

Azure Arc: bringing on-premises servers into Defender for Cloud

Azure Arc extends Azure management to resources outside Azure. When you Arc-enable an on-premises server, it appears in the Azure portal alongside Azure VMs — with the same management capabilities, including Defender for Cloud protection.

The Arc onboarding process installs a lightweight agent (the Azure Connected Machine agent) on the on-premises server. The agent establishes an outbound HTTPS connection to Azure (the server does not need to be directly accessible from the internet — it initiates the connection outbound). Once connected, the server appears in the Azure portal as an Arc-enabled server resource. Defender for Cloud’s auto-provisioning then deploys the MDE sensor and monitoring agent, just as it does for Azure VMs.

Arc onboarding at scale uses a service principal and a deployment script that can be distributed via GPO, SCCM, or any configuration management tool. For a data centre with 200 servers, you do not install the Arc agent manually on each — you deploy the script through your existing automation. The script registers each server with Azure Arc, and auto-provisioning handles the rest.

What Arc-enabled servers get from Defender for Cloud:

Full CSPM assessment — security recommendations evaluate the server’s configuration (OS patches, endpoint protection, firewall rules, encryption settings) against the same benchmarks used for Azure VMs. The Secure Score includes Arc-enabled servers alongside Azure VMs.

Full CWP protection with Defender for Servers — the MDE sensor provides threat detection (malware, suspicious processes, brute-force attacks, lateral movement). Security alerts for Arc-enabled servers appear in the same alert queue as Azure VM alerts.

Vulnerability assessment — the integrated vulnerability scanner (powered by Qualys or Microsoft MDVM) evaluates installed software for known CVEs, providing the same TVM capability as for Azure VMs.

What Arc-enabled servers do NOT get: Just-in-time (JIT) VM access (this requires Azure network security groups, which do not exist for on-premises servers). Adaptive application controls (requires Azure-specific integration). Network-level protections (Azure Firewall, NSGs) — network security for on-premises servers remains the responsibility of the on-premises infrastructure team.

AWS multi-cloud connector

Connecting an AWS account to Defender for Cloud uses a native cloud-to-cloud connector — not Azure Arc (though Arc is used for server-level CWP on EC2 instances). The connector is configured in Defender for Cloud → Environment settings → Add environment → AWS.

The connection process creates a CloudFormation stack in the AWS account that provisions an IAM role with read-only permissions. Defender for Cloud assumes this role to read the AWS resource inventory, evaluate configurations, and assess security posture. The connection is API-based — no agents are deployed for CSPM assessment. The entire AWS account inventory (EC2, S3, RDS, EKS, IAM, VPC, Lambda) becomes visible in Defender for Cloud within minutes.

CSPM for AWS evaluates AWS resources against the AWS CIS Foundations Benchmark (not the Azure Security Benchmark — the benchmark is cloud-specific). Security recommendations are AWS-specific: “S3 bucket allows public access,” “EC2 instance has unrestricted SSH access,” “RDS instance is not encrypted at rest.” These recommendations appear in the same Defender for Cloud recommendations view alongside Azure recommendations, with clear labeling showing which cloud each recommendation applies to.

CWP for AWS requires Azure Arc. EC2 instances that need runtime threat detection are Arc-enabled (the Arc agent is installed on each EC2 instance), and Defender for Servers provides MDE-based protection. This is the same protection available for Azure VMs and on-premises servers — the detection capabilities are identical regardless of where the server runs.

CSPM without CWP is the common starting point for AWS integration. Connecting the AWS account for CSPM provides immediate visibility into the AWS security posture without installing any agents on EC2 instances. This is useful for organisations that want to assess their AWS security posture before committing to full CWP deployment. CSPM alone finds misconfigurations. CWP (added later by Arc-enabling EC2 instances) adds runtime threat detection.

GCP multi-cloud connector

The GCP connector follows the same pattern as AWS: a cloud-to-cloud API connection that reads the GCP resource inventory and evaluates configurations against GCP-specific benchmarks (GCP CIS Foundations Benchmark). The connector is configured in Defender for Cloud → Environment settings → Add environment → GCP.

The connection process creates a Google Cloud service account with read-only IAM permissions. Defender for Cloud uses this service account to enumerate GCP resources (Compute Engine VMs, Cloud Storage buckets, Cloud SQL instances, GKE clusters) and assess their configuration.

CWP for GCP Compute Engine VMs uses Azure Arc, identical to the AWS approach — install the Arc agent on GCE VMs, and Defender for Servers provides MDE-based runtime protection.

GCP-specific considerations: GKE (Google Kubernetes Engine) cluster protection is available through Defender for Containers, which deploys a Defender sensor to GKE clusters. Cloud Storage and Cloud SQL do not have the same depth of protection as Azure Storage and Azure SQL — Defender for Cloud provides CSPM assessment (configuration evaluation) but not the same runtime CWP detection available for Azure-native services.

The unified multi-cloud dashboard

After connecting Azure subscriptions, AWS accounts, GCP projects, and on-premises servers via Arc, all resources appear in a single Defender for Cloud dashboard. The Overview page shows a unified Secure Score that incorporates all environments. The Recommendations page shows findings across all clouds, filterable by environment. The Inventory page shows every resource across every connected platform.

This unified view is the operational reality: your SOC team uses one tool to assess security posture across all clouds and on-premises. A security recommendation for an AWS S3 bucket and a security recommendation for an Azure Storage account appear in the same list, assessed against equivalent benchmarks, with the same remediation workflow.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Multi-cloud resource inventory in Sentinel
SecurityRecommendation
| where TimeGenerated > ago(1d)
| extend CloudEnvironment = tostring(Properties.resourceDetails.Source)
| extend ResourceType = tostring(Properties.resourceDetails.ResourceType)
| extend Severity = tostring(Properties.severity)
| summarize RecommendationCount = count(),
    HighSeverity = countif(Severity == "High")
    by CloudEnvironment
| order by HighSeverity desc

Arc onboarding at scale: deployment strategies

Onboarding 5 servers to Arc manually is straightforward. Onboarding 500 requires automation. Three deployment strategies are commonly used.

Script-based deployment via GPO or SCCM: Generate the Arc onboarding script from the Azure portal (Azure Arc → Servers → Add → Generate script). The script installs the Connected Machine agent and registers the server with a specified Azure subscription, resource group, and region. Distribute this script through Group Policy, SCCM task sequences, or Ansible/Puppet/Chef for Linux servers. The script runs silently and completes in 2-5 minutes per server.

Service principal authentication: For automated deployments, create a service principal with the “Azure Connected Machine Onboarding” role. The deployment script authenticates using the service principal credentials instead of requiring an interactive login. This enables fully unattended onboarding suitable for CI/CD pipelines and configuration management tools.

VMware vCenter integration: For VMware-based data centres, Azure Arc supports direct integration with vCenter Server. This enables bulk onboarding of all VMware VMs through the Azure portal without installing the agent manually on each VM — the integration deploys the agent through vCenter’s guest operations.

After onboarding, verify all servers appear in the Azure Arc inventory: Azure portal → Azure Arc → Servers. Each server shows its connection status (Connected, Disconnected, Error), the installed extensions (MDE, AMA), and the Defender for Cloud protection status.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

// Verify Arc-enabled server inventory and agent status
Heartbeat
| where TimeGenerated > ago(1h)
| where ResourceType == "microsoft.hybridcompute/machines"
| summarize LastHeartbeat = max(TimeGenerated),
    AgentVersion = any(Version),
    OS = any(OSType)
    by Computer, ResourceGroup
| extend Status = iff(LastHeartbeat > ago(10m), "Connected", "Stale")
| order by Status desc, Computer asc

Multi-cloud alert investigation: AWS and GCP specifics

When a Defender for Cloud alert fires for an AWS or GCP resource, the investigation requires understanding the cloud-specific resource model.

AWS EC2 alerts (via Arc + MDE): These appear as standard server alerts because Arc + MDE provides the same detection regardless of cloud. The alert entity references the Arc server name (which matches the EC2 instance hostname). To trace the investigation to the AWS console: note the instance ID from the Arc resource metadata, then look up the instance in AWS EC2 console for AWS-specific context (VPC, security groups, IAM role).

AWS CSPM findings: These reference AWS resource types (S3 bucket, RDS instance, IAM policy). The recommendation includes the AWS ARN (Amazon Resource Name), which uniquely identifies the resource. Remediation must be performed in the AWS console or via AWS CLI/CloudFormation — Defender for Cloud cannot remediate AWS resources directly (it assesses them but cannot modify them).

GCP Compute Engine alerts: Same as AWS — Arc + MDE provides detection, and the investigation uses standard server techniques. GCP-specific context (project, zone, network) is available in the Arc resource metadata.

Cross-cloud correlation: An attacker who compromises an Azure identity may pivot to AWS resources if your organisation uses federated access (Azure AD as the IdP for AWS SSO). When investigating a compromised identity, check not just Azure Activity Log but also AWS CloudTrail (via the Sentinel AWS connector if configured) for activity from the same identity or IP across both clouds.

Multi-cloud security governance model

Connecting multiple clouds to Defender for Cloud is the technical step. The operational challenge is governance: ensuring consistent security standards apply regardless of which cloud hosts the workload.

The governance principle: Define security requirements once (in Defender for Cloud’s compliance standards and Azure Policy), and apply them everywhere. A VM must have endpoint protection whether it runs in Azure, AWS, or on-premises. A database must have auditing enabled whether it is Azure SQL, AWS RDS, or on-premises SQL Server. A storage service must not allow public access whether it is Azure Blob Storage or AWS S3.

The implementation model: Use Defender for Cloud as the single pane of glass for posture assessment across all clouds. Use the same compliance standards (CIS benchmarks are available for Azure, AWS, and GCP). Use governance rules to auto-assign remediation across all connected environments. Generate a single compliance report that covers all clouds — presenting management with a unified posture view rather than separate per-cloud assessments.

The gap: Remediation in non-Azure clouds must be performed in the native console (AWS Management Console, GCP Console) or through IaC tools (Terraform, CloudFormation). Defender for Cloud cannot remediate AWS or GCP resources directly — it assesses them and provides recommendations, but the “Fix” button only works for Azure resources. This means multi-cloud remediation requires cross-team coordination: the SOC identifies the finding in Defender for Cloud, the cloud engineering team implements the fix in the appropriate console.

DevSecOps connectors: GitHub and Azure DevOps

Defender for Cloud also connects to code repositories through DevSecOps connectors for GitHub and Azure DevOps. These connectors scan code repositories for exposed secrets (hardcoded API keys, connection strings, passwords), infrastructure-as-code misconfigurations (Terraform templates that deploy resources without encryption or with overly permissive access), and vulnerable dependencies (open-source libraries with known CVEs).

DevSecOps findings appear as security recommendations in Defender for Cloud alongside infrastructure findings. For SOC analysts, the most relevant finding type is exposed secrets — a hardcoded storage account key in a public GitHub repository is the root cause of many Defender for Storage alerts. When you investigate a storage access alert and determine the storage key was compromised, check the DevSecOps recommendations to see if the key was found in a code repository.

Knowledge check