Lesson 8 — Multicloud Protection

Learning objectives

After completing this lesson, you should be able to explain how Multicloud Protection-enabled servers connect hybrid machines to multicloud security and Defender for Cloud.

What is Multicloud Protection?

Multicloud Protection extends multicloud security, governance and selected Azure services to resources running outside Azure.

Multicloud Protection-enabled servers

Supported physical and virtual Windows or Linux machines can be represented as Azure resources while remaining in their existing location.

What Multicloud Protection does not do

Multicloud Protection does not automatically migrate the server, applications or data into Azure. It creates a management relationship.

Azure Resource Manager representation

Each connected machine receives an Azure resource identity inside a selected subscription, resource group and region.

AWS and Google Cloud connectors

The agent establishes the connection to Azure and manages identity, metadata, extension operations and service communication.

Machine identity

An connector-enabled server receives a managed identity that supported Azure services and extensions can use without embedded credentials.

Subscription selection

The subscription determines governance scope, access control, policy inheritance and Defender plan configuration.

Resource group placement

Consistent placement by environment, business unit, location or owner simplifies security operations and reporting.

Azure region

The connector resource metadata is associated with an Azure region; the external server itself does not move there.

Tags and metadata

Tags can record owner, application, environment, criticality, support group, location and data classification.

Supported machines

Multicloud Protection can connect supported physical servers, private-cloud VMs, hosted servers, branch systems and machines in other clouds.

Operating system support

Support varies by version, architecture and feature. Unsupported systems require upgrade or compensating controls.

Single-server onboarding

An interactive portal-generated script is useful for testing and small environments.

At-scale onboarding

Large environments should use controlled automation, configuration management or software distribution tools.

Service principal onboarding

A least-privilege service principal supports unattended deployment at scale; credentials must be protected and rotated.

Interactive onboarding

Interactive sign-in is convenient for limited deployments but should not become the enterprise default.

Least privilege

Onboarding identities need only the permissions required to create and connect connector resources at the intended scope.

Network requirements

Outbound access, DNS, proxies, firewalls and TLS inspection must support the AWS and Google Cloud connectors and required extensions.

Outbound connectivity

connector generally uses outbound connections rather than requiring unsolicited inbound management ports.

Proxy configuration

Proxy settings must be supported, consistent and tested; a IAM trust relationship change can disconnect many servers simultaneously.

TLS inspection

Certificate inspection can interfere with Azure service communication and should be validated end to end.

Private connectivity

Private Link designs can reduce public service exposure but require careful DNS, routing and dependency planning.

Connected status

The portal reports connected, disconnected or expired states. This status must be monitored continuously.

Heartbeat freshness

A current heartbeat proves recent communication. Stale heartbeats require operational investigation.

Azure Policy integration

Azure Policy can assess connector-enabled servers and deploy approved configurations or extensions.

Guest Configuration

Machine configuration can assess selected operating-system settings inside supported servers.

Policy inheritance

Assignments can flow from management groups, subscriptions and resource groups.

Remediation tasks

DeployIfNotExists policies may require remediation tasks for existing machines.

Extension management

Extensions add monitoring, security and management functions and must be versioned and monitored.

Azure Monitor Agent

The Azure Monitor Agent can collect selected logs and metrics through Data Collection Rules.

Defender for Endpoint extension

Supported Defender for Servers deployments can use extension-based Microsoft Defender for Endpoint onboarding.

Extension provisioning state

Failed, updating or transitioning extensions should be investigated for permissions, network access and compatibility.

Defender for Cloud discovery

connector-enabled servers can appear in Defender for Cloud inventory and posture assessment when scope and plans are correct.

Defender for Servers plan

connector onboarding alone does not guarantee full workload protection; the appropriate Defender plan must be enabled.

Endpoint protection integration

Defender for Endpoint provides behavioural endpoint detection and response for supported, healthy machines.

Vulnerability assessment

Supported machines can contribute software inventory and vulnerability data; coverage and freshness must be monitored.

Security recommendations

Defender for Cloud can identify missing protection, insecure configuration, outdated systems and exposed services.

Secure score impact

connector server recommendations can affect security posture and Secure Score depending on active assessments.

Inventory visibility

Hybrid servers can be viewed alongside Azure resources and filtered using tags, location, owner and environment.

Hybrid governance

Multicloud Protection supports a common governance model without removing local operational responsibilities.

Role-based access control

Azure RBAC controls who can view, modify, tag and manage connector resources.

Resource locks

Locks reduce accidental deletion of Azure resource objects but do not prevent local removal of the agent.

Local administrator risk

A local administrator can stop services or remove the agent, so endpoint privilege and hardening remain essential.

Agent updates

The AWS and Google Cloud connectors should remain on a supported version through a tested maintenance process.

Server decommissioning

Decommissioning should remove the connector connection, extensions and stale Azure resource records.

Duplicate resources

Rebuilds or repeated onboarding can create duplicate resources that distort inventory and coverage reporting.

Resource moves

Moving connector resources can change policy, permissions, Defender plans and automation.

Disconnected machines

Disconnected status can indicate shutdown, decommissioning, network failure, IAM trust relationship change or agent removal.

Expired machines

Long-disconnected resources should be investigated and cleaned up rather than ignored.

Azure Activity Log

The Activity Log records control-plane operations such as resource creation, deletion, extension changes and policy assignments.

Local agent logs

Local logs provide evidence for registration, authentication, IAM trust relationship and connectivity troubleshooting.

Monitoring connector health

Dashboards should track connection state, last heartbeat, agent version, extension health, policy compliance and Defender coverage.

Validation after onboarding

Do not stop when the resource appears in Azure; validate policy, extensions, recommendations and security telemetry.

Pilot deployment

Use representative operating systems, networks, locations and workloads to document prerequisites and failure patterns.

Production rollout

Scale using approved automation, naming standards, tags, least-privilege identities, monitoring and rollback procedures.

Change management

Proxy, firewall, certificate, operating-system and identity changes should include connector impact assessment.

Security operations integration

Defender for Cloud alerts involving connector servers can feed Defender XDR or Microsoft Sentinel workflows where configured.

Operational lesson

Hybrid protection depends on the server, agent, network, identity, connector resource, policy, extensions and Defender services all remaining healthy.

Common onboarding failures

• Unsupported operating system
• Incorrect service-principal permissions
• Expired credentials
• Proxy authentication failure
• Blocked service endpoints
• DNS resolution failure
• TLS inspection interference
• Duplicate machine identity
• Local security software blocking installation

Common extension failures

• Package download blocked
• Unsupported operating system version
• Insufficient local permissions
• Conflicting security product
• Reboot pending
• Corrupt previous installation
• Extension handler out of date

connector coverage checklist

• Server owner recorded
• Criticality classified
• Supported operating system
• Correct subscription and resource group
• Connected status healthy
• Heartbeat current
• Agent version supported
• Required extensions successful
• Policy assignments compliant
• Defender plan enabled
• Endpoint telemetry current
• Vulnerability data current

What Agent Foskett checked

• connector resource connection status
• Last heartbeat
• AWS and Google Cloud connectors services
• Proxy and DNS configuration
• Required service endpoints
• Agent version
• Extension provisioning state
• Defender plan assignment
• Endpoint sensor health
• Recommendation freshness
• Other machines behind the same IAM trust relationship

Best practices

• Use automated onboarding at scale.
• Apply consistent naming and tags.
• Use least-privilege service principals.
• Monitor stale heartbeats.
• Track disconnected and expired machines.
• Keep agents and extensions supported.
• Use policy for standard deployment.
• Validate Defender telemetry after onboarding.
• Document IAM trust relationship and endpoint dependencies.
• Remove stale resources during decommissioning.