Specialized Engineering: Enterprise Hybrid Cloud

Table of Contents

• Introduction
• Module 1: Working with Hybrid Identities
  • Course Scenario: Globomantics
  • Authentication and Authorization Challenges in Hybrid Cloud
  • Federating Identity with a Single Authoritative Identity Provider
  • Role-Based Access Control Across Cloud Providers
  • Auditing Authentication and Authorization Activity
  • Demo: Synchronizing and Authenticating Identities Between Active Directory and Azure AD
  • Demo: Establishing SAML Federation Trust Between Azure AD and AWS IAM
  • Demo: Authorizing Access with Azure RBAC and AWS IAM Roles
• Module 2: Working with Hybrid Network Connectivity
  • Site-to-Site VPN Connectivity Options
  • Dedicated Connections and Encryption Considerations
  • Choosing a Connectivity Model: Applying Globomantics’ Requirements
  • Extending the Cloud to On-Premises Infrastructure
  • Demo: Building the Cloud Components of a Managed Site-to-Site VPN in AWS
  • Demo: Comparing Site-to-Site VPN Components in Azure
  • Demo: Hardening IPsec Tunnel Security Settings
• Module 3: Understanding Cloud Compliance
  • Identifying Applicable Compliance and Regulatory Frameworks
  • Evaluating Cloud Provider Compliance Documentation
  • Case Study: Globomantics’ Healthcare Compliance Requirements
  • Demo: Investigating Compliance Centers in AWS and Azure
  • Demo: Monitoring Compliance Posture with AWS Security Hub and Microsoft Defender for Cloud
• Module 4: Understanding Security for Multi-Cloud Implementations
  • Why Organizations Adopt Multi-Cloud Architectures
  • Centralizing Authentication, Authorization, and Auditing Across Clouds
  • Securely Connecting Multi-Cloud Environments
  • Application Mobility: Containers, Managed Compute, and Serverless
• Summary

Introduction

Most enterprise organizations today are adopting some aspect of cloud computing, and almost every cloud project shares two common concerns: hybrid connectivity (linking on-premises infrastructure to the cloud) and managing security between an organization and its cloud providers. This reference covers the key engineering considerations for building and securing an enterprise hybrid cloud, including:

• Managing hybrid identities (authentication and authorization across on-premises and cloud boundaries)
• Managing hybrid network connectivity (VPNs, dedicated circuits, and on-premises cloud extensions)
• Working with compliance requirements in the cloud
• Working in multi-cloud environments

Throughout this material, a running scenario is used to ground the concepts: Globomantics, a global healthcare organization, is migrating workloads to the cloud and needs security engineering guidance at each stage of that journey.

A working knowledge of cloud concepts — cloud networking and identity and access management fundamentals — is assumed.

Module 1: Working with Hybrid Identities

Course Scenario: Globomantics

Globomantics is a mature, global healthcare organization. Like most established enterprises, it already has an on-premises directory service that authenticates and authorizes on-premises entities — users, computers, and applications. In this scenario, Globomantics uses Microsoft Active Directory Domain Services (AD DS) as that directory service, and it operates across multiple cloud providers, including Azure, AWS, and GCP.

As Globomantics moves workloads to the cloud, a security engineer must answer three central questions:

1. How do users authenticate to the cloud without repeatedly supplying credentials to each provider?
2. How is access scoped so that teams get only the permissions they need to do their jobs — no more, no less?
3. How are authentication attempts audited so the organization can track who is logging in to which cloud services?

mindmap
  root((Hybrid Identity Challenges))
    Authentication
      Single sign-on across clouds
      Avoid re-entering credentials
      Trust between on-prem directory and cloud IdPs
    Authorization
      Least-privilege access
      Role-based access control
      Per-provider RBAC implementation differences
    Auditing
      Track login attempts
      Track administrative actions
      Retention and searchability of logs

Authentication and Authorization Challenges in Hybrid Cloud

The foundational principle for solving the authentication challenge is to designate a single authoritative identity provider that performs authentication, and to have every other service trust that identity provider rather than maintaining its own separate set of credentials.

Because Globomantics already runs AD DS on-premises, containing every user account for the organization, the sensible approach is not to reinvent identity management in each cloud, but to configure each cloud service to trust the existing AD forest.

Option 1 — Active Directory Federation Services (AD FS) as the broker

Whether connecting to AWS, GCP, Azure, or another cloud provider, an organization can use Microsoft Active Directory Federation Services (AD FS) to broker trust between the on-premises directory and each cloud provider. AD FS provides single sign-on (SSO):

1. A user (for example, “Bob”) authenticates against the on-premises AD domain.
2. When Bob accesses a cloud management console, his on-premises authentication token is exchanged for a SAML 2.0 token.
3. That SAML token is presented to the cloud provider’s authentication service.
4. The cloud provider trusts the SAML token — and therefore trusts that Bob is an authenticated user — without asking him for credentials again.

sequenceDiagram
    participant Bob as Bob (User)
    participant AD as On-prem Active Directory
    participant ADFS as AD FS (Federation Broker)
    participant Cloud as Cloud Provider Console (AWS/Azure/GCP)

    Bob->>AD: Authenticate with on-prem credentials
    AD-->>Bob: On-prem authentication token
    Bob->>ADFS: Request access to cloud console
    ADFS->>AD: Validate trust / user identity
    ADFS-->>Bob: SAML 2.0 token
    Bob->>Cloud: Present SAML 2.0 token
    Cloud->>Cloud: Validate token against configured trust
    Cloud-->>Bob: Authenticated session (no credential re-entry)

The more cloud providers an organization uses, the more valuable a centralized identity provider becomes. AD FS is one common broker, but it is not a strict requirement — it is entirely possible to use one of the cloud providers’ own identity and access management (IAM) services as the central broker instead.

Option 2 — A cloud IAM service as the central broker

In the Globomantics scenario, the on-premises AD is synchronized with Azure AD using Azure AD Connect, and Azure AD then becomes the hub that federates trust out to the other cloud providers (AWS and GCP). There is no need for AD FS in this model — a Globomantics employee with an AD account can authenticate once and be trusted by every integrated cloud provider.

flowchart LR
    AD[On-prem Active Directory Domain Services] -->|Azure AD Connect sync| AAD[Azure AD Tenant]
    AAD -->|SAML federation trust| AWS[AWS IAM]
    AAD -->|Federation / IAM integration| GCP[GCP IAM]
    AAD -->|Native SSO| AzureConsole[Azure Portal]

Although Microsoft AD is used as the example directory service, other directory services — including Red Hat Directory Services — can fill the same role.

Federating Identity with a Single Authoritative Identity Provider

Once directory services are integrated with the cloud providers, the remaining two problems — assigning appropriate access and tracking user actions — can be solved using each cloud provider’s native services.

Role-Based Access Control Across Cloud Providers

All major cloud providers offer a version of role-based access control (RBAC), so the underlying principles are consistent regardless of provider:

• A role has a set of permissions linked to it.
• The role is scoped so its permissions apply at a particular level (subscription, resource group, project, account, etc.).
• Trusted users are assigned to the role.

The implementation details differ significantly between providers:

flowchart TD
    subgraph Azure_GCP["Azure / GCP RBAC Model"]
        A1[Preconfigured Role] --> A2[Permissions Bundled In]
        A2 --> A3[Assign User/Group to Role at Scope]
    end
    subgraph AWS["AWS RBAC Model"]
        B1[Create Role] --> B2[Attach JSON Policy Document]
        B2 --> B3[Grant User Right to Assume Role]
        B3 --> B4[User Assumes Role to Gain Permissions]
    end

Because AWS requires roles to be built from scratch, an example AWS IAM policy document (of the kind attached to a role) looks like this:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

This particular policy — AdministratorAccess — allows all actions on all resources, granting full administrative control to any role it is attached to. In production, policies should be scoped far more narrowly, following least-privilege principles, but full-access policies are sometimes used deliberately for break-glass or federated-admin roles, as shown in the demo below.

Auditing Authentication and Authorization Activity

All major cloud providers implement auditing by default: every action carried out in a chosen cloud service is recorded automatically. Administrators can typically configure:

• How long audit logs are retained
• Where logs are stored
• How logs are searched, queried, and alerted on

Demo: Synchronizing and Authenticating Identities Between Active Directory and Azure AD

This walkthrough demonstrates identity integration for authentication, showing how users are synchronized with a cloud IAM system and how trust is established between cloud IAM solutions.

Step-by-step:

1. Open the Azure Active Directory dashboard in the Azure portal and select Users.
2. Observe the user list. Two example accounts are compared:
   • Abby Brown — created directly in the cloud (On-premises sync enabled = No).
   • ADBob — synchronized from the on-premises AD DS instance via Azure AD Connect (On-premises sync enabled = Yes).
3. Select Abby Brown → Edit properties. All fields (Display name, First name, Last name, etc.) are editable directly in Azure AD, since Azure AD is the source of truth for that identity.
4. Select ADBob → Edit properties. Most fields are grayed out, because the single source of truth for Bob’s identity is the on-premises AD DS instance — that is where ADBob must be created and modified.
5. Despite being externally sourced, ADBob can still authenticate against Azure AD because the account has been synchronized. Sign in to the Azure portal as ADBob using his synchronized credentials; the sign-in succeeds, confirming Azure AD can authenticate a synced on-premises identity.
6. Navigate to the My Apps portal while signed in as ADBob. The list of applications assigned to Bob includes Amazon Web Services — a different cloud provider entirely.
7. Select Amazon Web Services from My Apps. ADBob is signed in to the AWS console automatically, without being prompted for AWS credentials — demonstrating cross-cloud SSO.

sequenceDiagram
    participant Bob as ADBob
    participant OnPremAD as On-prem AD DS
    participant AzureAD as Azure AD Tenant
    participant MyApps as Microsoft My Apps Portal
    participant AWS as AWS Console

    OnPremAD->>AzureAD: Azure AD Connect sync (user + group objects)
    Bob->>AzureAD: Sign in with on-prem-sourced credentials
    AzureAD-->>Bob: Authenticated session
    Bob->>MyApps: Open assigned application tile (AWS)
    MyApps->>AzureAD: Request SAML assertion for AWS
    AzureAD-->>AWS: SAML assertion (federated trust)
    AWS-->>Bob: Signed in to AWS console (no separate AWS credentials)

Demo: Establishing SAML Federation Trust Between Azure AD and AWS IAM

Continuing from the previous demo, this section shows how the underlying SAML trust between Azure AD and AWS is configured:

1. In the AWS IAM dashboard, note that ADBob does not appear in the AWS user list — AWS has no local account for him.
2. Under Identity providers, a trust relationship with Azure AD is listed. This trust was created by:
   • Selecting Add provider.
   • Choosing SAML as the provider type, named AzureAD.
   • Uploading the federation metadata document obtained from Azure AD.
3. Back in the Azure AD dashboard, under Enterprise applications, an integrated application named Amazon Web Services exists. It was configured by:
   • Selecting New application and choosing Amazon Web Services from the gallery.
   • Completing the Getting Started steps to configure the Azure side of the SAML trust.
   • Under Users and groups, adding ADBob so he is entitled to use the integration.

flowchart LR
    subgraph Azure["Azure AD"]
        EA[Enterprise Application: Amazon Web Services]
        FedMeta[Federation Metadata Document]
    end
    subgraph AWS["AWS IAM"]
        IdP[Identity Provider: AzureAD - SAML]
        Roles[AD-prefixed IAM Roles]
    end
    FedMeta -->|Uploaded to| IdP
    IdP -->|Federated trust| EA
    EA -->|Assigns user to role during sign-in| Roles

Demo: Authorizing Access with Azure RBAC and AWS IAM Roles

This walkthrough shows how authentication (proving who you are) is distinct from authorization (what you are allowed to do), and how each cloud provider implements RBAC.

Azure RBAC:

1. As an Azure administrator, open Resource groups and select RG3, which contains a set of deployed resources (VMs, networks, databases).
2. Signed in as ADBob, opening Resource groups shows an empty list — Bob is authenticated against Azure AD but not yet authorized to see any resources.
3. Back as the administrator, open RG3’s Access control (IAM) blade, select Add → Role assignment, choose the Owner role, and assign it to ADBob.
4. Refreshing the portal as ADBob now shows RG3 and all its contained resources — Bob can fully administer them because Owner grants full control at that scope.

AWS IAM Roles:

1. In AWS IAM, under Roles, note the existing roles prefixed AD — each was created to support the Azure AD federation trust.
2. To create a new federated role:
   • Select Create role → SAML 2.0 federation, choosing AzureAD as the SAML provider.
   • Choose whether holders get programmatic access, Management Console access, or both.
   • Under Add permissions, attach the AdministratorAccess policy (shown above as a JSON document) to grant full control.
   • Name and create the role.
3. Back in Azure AD’s Enterprise application for AWS, under Users and groups, note ADBob already holds one federated role (ADFullAWSAdmin). Adding a second role assignment (e.g., a newly created role) grants Bob a choice of roles to assume the next time he signs in through the SAML trust.
4. When ADBob signs in to AWS via the My Apps portal with two eligible roles assigned, AWS now prompts him to choose which role to assume, rather than silently signing him in with a single implicit role — demonstrating how SAML-based federation can support multiple, differently-scoped roles for the same federated identity.

Module 2: Working with Hybrid Network Connectivity

Site-to-Site VPN Connectivity Options

Globomantics has a virtual network in the cloud with deployed virtual servers, along with headquarters (HQ) networks containing on-premises clients and servers. The requirement: connect the two environments so traffic can be routed between them, with encryption in transit and a minimum bandwidth of 10 Gbps.

All major cloud providers offer very similar hybrid networking options:

• Site-to-site VPNs across the public internet
• Dedicated connections offering always-on, dedicated bandwidth (similar to a traditional leased line)

Nothing prevents an organization from deploying its own virtual servers in the cloud and building custom site-to-site VPNs, but every major provider also offers a managed site-to-site VPN service.

How a managed site-to-site VPN is typically built:

1. An on-premises device (e.g., a router) is already connected to the internet.
2. A virtual gateway is deployed in the cloud, configured with the IP address and other details of the on-premises device.
3. The cloud provider supplies one or more connection endpoints for the on-premises device to connect to.

IPsec is the security suite of choice for these connections:

• Tunnel endpoints authenticate with each other, usually via pre-shared keys.
• All data is encrypted, and integrity checks are performed.
• Cloud providers expose configuration options for Diffie-Hellman groupings, hashing algorithms, and encryption algorithms.

Because traffic travels across the public internet, these connections experience variable contention (shared with other internet traffic) and are bandwidth-limited:

Dedicated Connections and Encryption Considerations

For higher, guaranteed bandwidth without internet contention, all major providers offer dedicated connections:

These connections are dedicated to the customer — no contention, and bandwidth is guaranteed. They typically involve a third-party co-location facility (colo):

1. The cloud provider partners with colo facilities and places its own networking equipment there.
2. The customer chooses a colo near them and arranges a connection to that facility via a local provider.
3. The customer rents rack space in the colo and places (or rents) equipment there.
4. Once connected to the same facility as the cloud provider’s equipment, the customer requests a dedicated connection at the desired bandwidth.

flowchart LR
    OnPrem[Organization HQ Network] -->|Local provider circuit| Colo[Co-location Facility]
    Colo -->|Cloud provider's on-site equipment| CloudEdge[Cloud Provider Edge]
    CloudEdge -->|Dedicated Interconnect / Direct Connect / ExpressRoute| CloudVNet[Cloud Virtual Network]

The encryption gap in dedicated connections: until recently, encryption was not offered as a native part of a dedicated connection, which caused problems for security-conscious organizations. Two ways to address this:

1. Overlay a site-to-site VPN on top of the dedicated connection. This combines the guaranteed bandwidth of the dedicated link with IPsec encryption — but it increases architectural complexity and can be difficult to implement.
2. Use MACsec encryption, now offered by some cloud providers for their dedicated connections. MACsec requires a device at the customer site that supports the MACsec standard, and it is typically only available on high-speed connections (usually above 10 Gbps), with restrictions on supported regions and eligible colo providers.

flowchart TD
    Start["Need >10Gbps AND encryption?"] -->|No| VPN[Use a managed site-to-site VPN with IPsec]
    Start -->|Yes| Dedicated[Provision a dedicated connection]
    Dedicated --> MACsecCheck{"Does region/colo/device support MACsec?"}
    MACsecCheck -->|Yes| MACsec[Enable native MACsec encryption]
    MACsecCheck -->|No| Overlay[Overlay a site-to-site VPN on the dedicated connection]

Choosing a Connectivity Model: Applying Globomantics’ Requirements

Globomantics needs a 10 Gbps connection with encryption. Because a managed site-to-site VPN alone cannot reach 10 Gbps, the correct recommendation is a dedicated connection, secured with either:

• Native MACsec encryption (if the region, device, and colo support it), or
• A site-to-site VPN overlay on top of the dedicated connection.

Extending the Cloud to On-Premises Infrastructure

Some Globomantics workloads — database and application servers that are highly latency-sensitive — must remain on-premises, while still integrating with cloud-deployed applications and following cloud principles.

Common reasons to keep workloads on-premises:

• Latency requirements that the cloud cannot meet
• Cost considerations
• Compatibility or licensing constraints

At the same time, organizations building modern API-driven, event-driven microservices applications increasingly want the benefits of cloud principles — automation, Infrastructure as Code, and DevSecOps — even for on-premises workloads. Two broad approaches make this possible:

1. Self-managed infrastructure — deploy your own virtualization platform with a management suite (e.g., Microsoft System Center).
2. Vendor-supplied hybrid hardware/software — deploy hardware and software provided by a cloud provider so the on-premises environment is managed with the same tools as the cloud.

flowchart TB
    subgraph DataCenter["Customer Data Center"]
        Outposts[AWS Outposts]
        AzStack[Azure Stack]
        GDC[Google Distributed Cloud]
    end
    Outposts <-->|Same management tools/APIs| AWSRegion[AWS Region]
    AzStack <-->|Same management tools/APIs| AzureRegion[Azure Region]
    GDC <-->|Same management tools/APIs| GCPRegion[GCP Region]

Using vendor-supplied hybrid hardware brings the benefit of the vendor’s management, monitoring, and security tooling, along with hardware engineered and optimized specifically to run that provider’s cloud services.

Demo: Building the Cloud Components of a Managed Site-to-Site VPN in AWS

This walkthrough builds the AWS-side components required for a managed site-to-site VPN, using the AWS VPC dashboard’s Virtual private network section.

Steps:

1. Create a customer gateway (Customer gateways → Create customer gateway):
   • Provide a name.
   • Optionally provide the BGP autonomous system number (ASN) used on the on-premises network.
   • Provide the public IP address of the on-premises networking device that will terminate the VPN.
   • Optionally attach a digital certificate for device authentication, plus tags.
2. Create a virtual private gateway (Virtual private gateways → Create virtual private gateway):
   • Provide a name.
   • Optionally set the AWS-side ASN (only relevant when using BGP for dynamic routing).
   • The new gateway starts detached — it must be attached to a VPC via Actions → Attach to VPC before it can be used. Only that VPC can route traffic through the gateway.
3. Create the site-to-site VPN connection (Site-to-Site VPN connections → Create VPN connection):
   • Name the connection and select the previously created virtual private gateway.
   • Select the previously created customer gateway. The VPN connection links the virtual private gateway (cloud side) to the customer gateway (on-premises side).
   • Choose the routing type:
     • Dynamic routing (BGP configured on both ends) — required for dedicated connections.
     • Static routing — an option for standard site-to-site VPNs; requires manually entering the on-premises network’s IPv4 CIDR prefixes.
   • Configure IPsec tunnel options (or accept the defaults) and create the connection.
4. Review tunnel status. Selecting the VPN connection’s Tunnel details shows two tunnel endpoints, each with its outside (public) IP address and an inside IPv4 CIDR range used to address traffic inside the tunnel. The status will show Down until the on-premises device is configured to match.
5. Download vendor-specific configuration. AWS can generate a ready-to-use configuration file tailored to the on-premises device vendor and platform (e.g., Cisco Systems → ISR Series Routers), which is applied to the on-premises router to bring the tunnels Up.

flowchart TD
    CGW[Create Customer Gateway] --> VGW[Create Virtual Private Gateway]
    VGW --> Attach[Attach Virtual Private Gateway to VPC]
    Attach --> VPNConn[Create Site-to-Site VPN Connection]
    VPNConn --> Routing{Dynamic BGP or Static routing?}
    Routing -->|Static| CIDR[Enter on-prem IPv4 CIDR prefixes]
    Routing -->|Dynamic| BGPConfig[Configure BGP on both ends]
    CIDR --> Download[Download vendor-specific config]
    BGPConfig --> Download
    Download --> OnPremConfig[Apply configuration to on-prem device]
    OnPremConfig --> TunnelUp[Tunnels transition from Down to Up]

Demo: Comparing Site-to-Site VPN Components in Azure

Azure implements the same conceptual components using different names:

The principles — an on-premises-representing object, a cloud-side gateway attached to a virtual network, and a connection resource linking the two — are consistent even though naming differs.

Demo: Hardening IPsec Tunnel Security Settings

This walkthrough configures the IPsec cryptographic settings for an existing managed site-to-site VPN, comparing AWS and Azure.

AWS (Actions → Modify VPN tunnel options):

1. Select a specific tunnel by its outside IP address.
2. Review the pre-shared key (must match on both ends to authenticate the tunnel) and the inside CIDR block.
3. Under IPsec settings, customize the allowed encryption algorithms and integrity (hashing) algorithms for both Phase 1 and Phase 2 of the IPsec negotiation — for example, removing SHA1 as an allowed integrity algorithm in both phases.
4. Configure the Diffie-Hellman groupings and the Internet Key Exchange (IKE) protocol version used to negotiate session keys.
5. Save changes.

Azure (Configuration → IPsec / IKE policy → Custom):

1. Switching from Default to Custom exposes the same categories of settings: Encryption, Integrity, and Diffie-Hellman group.
2. Choose algorithms from provider-supported lists for each category.

GCP exposes equivalent configuration for its own managed site-to-site VPN service. Regardless of provider, the on-premises device’s IPsec configuration must match the cloud-side configuration exactly, or the tunnels will fail to establish.

sequenceDiagram
    participant OnPrem as On-prem Device
    participant CloudGW as Cloud VPN Gateway

    Note over OnPrem,CloudGW: IKE Phase 1 - negotiate secure control channel
    OnPrem->>CloudGW: Propose encryption/integrity/DH group
    CloudGW->>OnPrem: Accept matching proposal
    OnPrem->>CloudGW: Authenticate via pre-shared key
    Note over OnPrem,CloudGW: IKE Phase 2 - negotiate IPsec SAs
    OnPrem->>CloudGW: Propose Phase 2 encryption/integrity
    CloudGW->>OnPrem: Accept matching proposal
    Note over OnPrem,CloudGW: Tunnel Up - encrypted, integrity-checked traffic flows

Module 3: Understanding Cloud Compliance

Identifying Applicable Compliance and Regulatory Frameworks

Before selecting cloud providers and services, an organization must identify which compliance and regulatory frameworks apply to it. Relevant questions include:

• Is the organization in financial services?
• Is it involved in healthcare or life sciences?
• Does it hold customers’ personal data?
• Does it work on government projects?
• Where geographically does it operate? (Europe, North America, and Asia often carry different security and data-compliance requirements.)

Examples of sector-specific frameworks:

Evaluating Cloud Provider Compliance Documentation

When working in the cloud, it is essential to select providers and services that help maintain adherence to the organization’s applicable compliance standards. All major cloud providers publish compliance documentation, usually through a dedicated compliance center, which typically comes in two forms:

1. Standards supported — a list of compliance standards the provider supports, including which of its services are in scope (i.e., can be certified against that standard).
2. Certifications held — details of the standards the provider’s own physical infrastructure has been certified against, along with independently audited reports proving the requirements were met.

If a cloud provider does not offer this documentation, proceed with caution.

Not every service from a supported provider is automatically in scope. For example, Microsoft Azure supports HIPAA overall, but within Azure, App Service Web Apps are in scope and support HIPAA, while App Service Static Web Apps are not. The choice of specific service, not just provider, must account for compliance scope.

flowchart TD
    Identify[Identify sector + region compliance requirements] --> Review[Review each candidate provider's compliance center]
    Review --> StandardCheck{Does the provider support all required standards?}
    StandardCheck -->|No| Discard[Discard this provider]
    StandardCheck -->|Yes| ScopeCheck{Are the specific services you need in scope?}
    ScopeCheck -->|No| ChooseAlt[Choose an in-scope alternative service or provider]
    ScopeCheck -->|Yes| Proceed[Proceed with deployment + certification monitoring]

Case Study: Globomantics’ Healthcare Compliance Requirements

Globomantics is a healthcare organization operating in both the US and Europe, and it routinely retains customer data for years. Before selecting cloud services, it must identify the full set of applicable frameworks:

This is not an exhaustive list — other frameworks may apply to Globomantics and similar healthcare organizations depending on jurisdiction and data type.

Recommended research process for Globomantics:

1. Build the complete list of frameworks the organization must adhere to (by sector, region, and data type).
2. Review each candidate cloud provider’s compliance center to confirm every required standard is supported; eliminate providers that fall short.
3. Confirm that the specific services Globomantics intends to use are in scope for each required standard (not just the provider as a whole).

Demo: Investigating Compliance Centers in AWS and Azure

AWS Compliance Center:

1. Use the country filter (e.g., search “UK”) to surface region-specific legal and regulatory requirements.
2. Browse by standard (e.g., General → PCI DSS) to find detailed information about a specific compliance standard.

Azure Compliance Documentation:

1. Documentation is organized by region and by business sector (e.g., Financial services; Healthcare and life sciences; Automotive, education, energy, media, and telecommunications).
2. Selecting a sector (e.g., Financial services → PCI DSS) surfaces standard-specific detail, including a list of in-scope services.

Demo: Monitoring Compliance Posture with AWS Security Hub and Microsoft Defender for Cloud

Once a provider is chosen, its native tools can continuously monitor compliance posture against a selected standard.

AWS Security Hub:

1. Select the PCI DSS standard being monitored.
2. Security Hub reports the number of controls being evaluated (e.g., 45 controls) and the current pass rate (e.g., 58%, 26 of 45 controls passing).
3. Drilling into a failed control (e.g., “the IAM root user access key should not exist”) surfaces specific remediation guidance.
4. The workflow is to work through each failed control, following its guidance, until the account is fully in line with the standard, then proceed to formal certification.

Microsoft Defender for Cloud:

1. Under regulatory compliance monitoring, select Improve your compliance to see the subscription’s status against a chosen standard (e.g., PCI DSS).
2. Each control shows pass/fail status. For example, “Identify and authenticate access to system components” may fail because MFA is not enabled on all accounts with Owner permissions on the subscription.
3. Applying the recommended fix (enabling MFA on the flagged accounts) moves the control from Failed to Passed.
4. This process is repeated for all controls in the standard before submitting for certification.

sequenceDiagram
    participant Eng as Security Engineer
    participant Tool as Compliance Monitoring Tool (Security Hub / Defender for Cloud)
    participant Cloud as Cloud Environment

    Eng->>Tool: Select compliance standard (e.g., PCI DSS)
    Tool->>Cloud: Evaluate environment against each control
    Tool-->>Eng: Report pass/fail per control + overall score
    loop For each failed control
        Eng->>Tool: Review remediation guidance
        Eng->>Cloud: Apply fix (e.g., enable MFA on Owner-role accounts)
        Tool->>Cloud: Re-evaluate control
        Tool-->>Eng: Control now Passed
    end
    Eng->>Tool: All controls passed; proceed to formal certification

Module 4: Understanding Security for Multi-Cloud Implementations

Why Organizations Adopt Multi-Cloud Architectures

Organizations like Globomantics may choose to use services from multiple cloud providers rather than standardizing on a single one, for reasons including:

• Service availability — not every service is offered by every provider; a needed capability may only exist on one platform.
• Cost — pricing for equivalent services can differ meaningfully between providers.
• Compliance — a preferred provider may not support a required compliance standard, forcing the use of another provider for certain workloads.

Multi-cloud deployments are increasingly common, but they introduce new challenges:

• Authentication and authorization become more difficult, since single sign-on must be coordinated across multiple cloud environments and on-premises.
• Auditing becomes harder if audit and security logs are scattered across multiple clouds rather than centralized, making it more difficult to track team activity or detect unauthorized access.
• Connectivity becomes more complex when different services from different providers must be connected to form one complete, secure architecture.

mindmap
  root((Multi-Cloud Drivers & Challenges))
    Drivers
      Provider-exclusive services
      Cost optimization across providers
      Meeting compliance where one provider falls short
    Challenges
      Authentication/authorization coordination
      Centralizing audit and security logs
      Cross-cloud network connectivity complexity

Centralizing Authentication, Authorization, and Auditing Across Clouds

Authentication and authorization follow the same single-source-of-truth principle already established in Module 1:

• Continue using the existing on-premises directory service as the one place identities are created.
• Either:
  1. Create a direct trust from the on-premises directory service to each cloud provider and enable SSO for each, or
  2. Replicate identities from the directory service into one cloud provider, then create trust from that provider out to the others, enabling SSO for each.
• Authorization is then performed using each cloud provider’s own RBAC implementation.

Centralizing audit and security logging requires more deliberate architecture. Using a scenario where Globomantics works across GCP, AWS, and Azure (each enabling audit logging locally by default):

1. Choose one provider (e.g., GCP) as the central log repository.
2. Create a dedicated GCP project for this purpose, locked down to only the appropriate security teams.
3. Configure each other provider’s audit tooling to replicate logs from its native storage into the centralizing provider’s operations/logging service (e.g., GCP Operations).
4. From the central service, query all logs, generate alerts on specific log patterns, and archive logs to cloud storage for long-term retention and analysis.
5. On-premises logs can also be imported into this same central pipeline.

The specific terminology differs by provider, but the underlying principle — a single, centralized place for querying, alerting, and archiving logs from every environment — is provider-agnostic.

flowchart TD
    AWSLogs[AWS Audit Logs] -->|Replication| Central[Centralized Logging Project - e.g. GCP Operations]
    AzureLogs[Azure Audit Logs] -->|Replication| Central
    GCPLogs[GCP Audit Logs] -->|Native| Central
    OnPremLogs[On-prem Logs] -->|Import| Central
    Central --> Query[Query / Search]
    Central --> Alert[Alerting on Log Patterns]
    Central --> Archive[Long-term Archival Storage]

Securely Connecting Multi-Cloud Environments

Connectivity between different cloud environments, providers, and on-premises networks can be achieved in a couple of complementary ways:

1. Site-to-site VPNs between cloud virtual networks. In the same way a site-to-site VPN connects on-premises infrastructure to a cloud virtual network (Module 2), a site-to-site VPN can also connect virtual networks that exist in different clouds, allowing traffic to route between them (and to on-premises).
2. Public endpoints exposed by cloud services. Many cloud services expose secure public URLs/endpoints (encrypted in transit) that other services can consume directly, without requiring a full virtual-network connection.

Illustrative example: Globomantics has a database on-premises, a web front end in Azure, and uses AWS S3 object storage for large customer-accessible objects.

• A site-to-site VPN connects on-premises and Azure so the web front end can reach the on-premises database.
• The web front end accesses S3 objects directly via S3’s public, encrypted endpoint URLs — no dedicated virtual-network connection to AWS is required for this piece.

flowchart LR
    OnPremDB[(On-prem Database)] ---|Site-to-site VPN| AzureWeb[Azure Web Front End]
    AzureWeb -->|HTTPS to public endpoint| S3[(AWS S3 Object Storage)]

Application Mobility: Containers, Managed Compute, and Serverless

Migrations — from on-premises into the cloud, and between different cloud environments — are a near-certain part of a cloud career. The more an organization leans into multi-cloud, the more valuable it becomes to choose application-hosting models that are easy to migrate between environments.

Containerization is supported by every major cloud provider and can also be deployed on-premises, making containerized applications highly portable. Security for containerized workloads centers on two areas:

1. The container images used to deploy containers.
2. The orchestration platform used to manage deployments at scale — most commonly Kubernetes, which is available as a managed service from every major cloud provider and can also run on-premises.

Because the same container images, management tools, and deployment concepts apply whether deploying to AWS, Azure, GCP, or on-premises, security processes stay consistent across environments — reducing the number of distinct processes that must be implemented and maintained.

By contrast, choosing different, provider-specific hosting models across clouds (e.g., virtual machines in AWS, Web Apps in Azure, App Engine in GCP) introduces more moving parts — and more moving parts means more that can go wrong.

Not every application can be containerized. Some must run on virtual machines, which are familiar to most operations teams (useful when an organization is just starting its cloud journey), but every VM brings an operating system that must be secured, and each provider implements VMs slightly differently — making cross-cloud migration harder, though not impossible.

Reducing what must be secured — the mobility/security spectrum:

flowchart TD
    Q1{Can the application be containerized?}
    Q1 -->|Yes| Containers[Use managed Kubernetes: consistent tools + security across clouds]
    Q1 -->|No| Q2{Can a managed/serverless service replace a self-managed VM?}
    Q2 -->|Yes, event-driven/stateless| Serverless[Use serverless: Lambda / Functions - no OS to secure, but hardest to migrate]
    Q2 -->|Yes, general web app| ManagedCompute[Use managed compute: Web Apps / Elastic Beanstalk / App Engine - provider owns the OS]
    Q2 -->|No| VM[Deploy virtual machines - full OS security responsibility]

From a pure security-management standpoint, the general preference ordering is:

1. Containers — easiest to secure, thanks to unified tools/techniques and the ability to leverage existing container engineering skill sets.
2. Serverless — no OS to secure, though portability between providers is limited.
3. Managed compute services — OS responsibility shifts to the provider.
4. Virtual machines — full OS security responsibility remains with the customer.

Summary

Enterprise hybrid cloud security engineering rests on a small number of durable principles that apply regardless of which specific cloud providers are involved:

• Hybrid identity: Choose a single authoritative source of identity — typically an existing on-premises directory service — so there is one place users and groups are created and managed, one password policy to maintain, and one place to disable or delete an identity when needed. Synchronize or federate that identity source with each cloud provider’s IAM/access-management solution, and use trust relationships (SAML, AD FS, or the cloud provider’s own IdP integration) rather than duplicating identities per provider.
• Hybrid networking: Use site-to-site VPNs with IPsec for encrypted, cost-effective connectivity, or dedicated connections (Direct Connect / ExpressRoute / Dedicated Interconnect) for guaranteed bandwidth, paired with either an IPsec VPN overlay or native MACsec encryption when high bandwidth and encryption are both required.
• Cloud compliance: Identify every regulatory and compliance framework applicable to your sector and operating regions, confirm that a candidate cloud provider both supports the relevant standards and offers the specific services you need in scope, and use built-in tools (such as AWS Security Hub or Microsoft Defender for Cloud) to continuously track and remediate compliance posture.
• Multi-cloud security: Centralize authentication, authorization, and audit logging across every cloud and on-premises environment in use; connect multi-cloud virtual networks with VPNs where needed, and take advantage of secure public endpoints for lighter-weight cross-cloud integration; and favor container-based or serverless application architectures where possible to reduce the amount of infrastructure that must be independently secured in each environment.

Quick-Reference: Connectivity Options by Requirement

Hybrid Cloud Security Engineering Checklist

• A single authoritative identity provider is designated and trusted by every cloud environment in use.
• Federation (AD FS, SAML, or native cloud IdP integration) is configured so users authenticate once and are trusted everywhere.
• RBAC roles and policies follow least-privilege principles in every cloud provider.
• Audit logging is enabled everywhere and retention/search requirements are defined.
• Network connectivity between on-premises and cloud meets both bandwidth and encryption requirements.
• IPsec (or MACsec) cryptographic settings are hardened and matched exactly between the cloud and on-premises endpoints.
• On-premises workloads that must stay in place are integrated using either self-managed infrastructure or vendor-supplied hybrid hardware.
• All applicable compliance and regulatory frameworks (by sector and region) have been identified.
• Each chosen cloud provider and specific service has been confirmed in scope for every required compliance standard.
• Compliance posture is continuously monitored with native tooling and failed controls are remediated on an ongoing basis.
• Audit and security logs from every cloud and on-premises environment are centralized into a single queryable, alertable location.
• Multi-cloud network connectivity (VPNs and/or secure public endpoints) is documented and secured.
• Application hosting models favor containers or serverless where feasible, to minimize per-environment OS security burden and maximize migration flexibility.

Search Terms

specialized · engineering · enterprise · hybrid · cloud · governance · risk · compliance · networking · systems · security · aws · azure · connectivity · authentication · authorization · globomantics · multi-cloud · site-to-site · vpn · access · across · auditing · between