Hybrid cloud security audit: testing the boundaries between on-premises and cloud

A hybrid cloud is not merely an on-premises estate connected to a provider account. It is a chain of trust that crosses directories, token issuers, routers, management agents, logging systems and operating teams. An audit that reviews the cloud tenant while treating the data centre as a black box can miss the very paths that make the design hybrid. The same is true in reverse: a familiar internal-network review says little about what synchronized identities, cloud roles or remote agents can do.

The useful buyer question is therefore not “is Azure, AWS or Google Cloud configured securely?” It is “which identities, commands and data can cross each boundary, which control is supposed to stop them, and can we produce evidence that the control works?” This guide turns that question into a scope, evidence plan, safe validation method and retest standard. It complements a broader multi-cloud assessment by concentrating on on-premises-to-cloud trust rather than comparing several cloud estates.

The audit object is a boundary chain

Start with business flows, not a provider checklist. A payroll export may begin in an on-premises database, traverse a private circuit, land in object storage and trigger a cloud function. An administrator may sign in with an Active Directory identity, receive a cloud token and use a cloud control plane to run a privileged extension on a server that still sits in the data centre. Each flow crosses several independent boundaries.

This changes what “secure” means. Private routing does not prove encryption. A synchronized directory object does not prove that disabling the source account ends every session. A cloud activity log does not prove that reads of sensitive data are recorded. A role described as “monitoring” does not prove that its agent cannot execute privileged code. The audit must test each claim against the exact product mode, endpoint and log category in use.

Use a boundary register as the primary scope document. Each row names a source, destination, protocol or agent, identity, data class, expected control, evidence owner and failure impact. The register is more useful than a flat asset list because it reveals hand-offs: networking may own the circuit, IAM the federation, a platform team the subscription, and an application owner the session cookie that survives an identity change.

Scope must make the hybrid system enumerable

A good scope identifies both sides of every crossing. Record tenants, organizations, accounts, subscriptions, projects, regions and relevant resource groups. Pair them with forests, domains, identity providers, federation servers, synchronization hosts, DNS zones, address spaces, gateways, carrier circuits, proxies and remote-management agents. Include SaaS applications if their sessions or provisioning depend on the hybrid identity path.

Do not accept “all production” without an inventory date and reconciliation method. Compare cloud organization exports with billing accounts, identity directories, network route inventories and the configuration-management database. Sample recently created and recently retired assets. Orphaned subscriptions, stale connectors and disconnected agents matter because they can preserve credentials or trust after the system of record says the asset is gone.

The scope should state exclusions as testable assumptions. If a carrier-managed segment is excluded, name its endpoints and the assurance supplied by the carrier. If an application cannot be tested in production, identify a representative environment and the differences that could affect identity, routing or logging. An exclusion without a compensating evidence source becomes an unknown, not a passed control.

Record an inventory collection time and owner so that exports from different dates are not mistaken for one coherent architecture snapshot. For ephemeral resources, organization-level configuration history, billing records or logs can reconstruct their existence during the test window. This reveals resources that no longer exist but once carried trust, and explains when evidence cannot be recollected live.

Identity synchronization, federation and revocation

Draw the authentication path for each important user class: employee, contractor, service account, emergency administrator and workload identity. Show the authoritative directory, synchronization or federation component, token issuer, conditional-access decision, group-to-role mapping and application session. Then add the return path for password writeback, provisioning, deprovisioning and device state when those features exist.

Revocation is a sequence rather than a single switch. In Microsoft Entra ID, blocking sign-in and revoking refresh tokens can still leave an accepted access token or an application-issued session usable until its own control takes effect; continuous access evaluation applies only where supported. The audit should therefore measure new authentication, renewal, resource acceptance and application-session termination separately.

A safe test uses dedicated accounts and a pre-agreed maximum observation window. Establish a session, record token and cookie timestamps, disable the account through the normal incident procedure, and observe each boundary without trying to evade controls. Repeat for a high-risk SaaS or internal application whose own session is material. The finding is not “revocation took N minutes” in the abstract; it states which credential remained useful, at which relying party, under which documented configuration.

Also inspect the synchronization host as critical infrastructure. Review who can administer it, how its service accounts and certificates are protected, where configuration changes are logged, and whether a compromised on-premises administrator can influence cloud roles through group membership. Conversely, examine cloud writeback or provisioning paths that can change on-premises objects. The goal is to identify both directions of authority.

Private connectivity and encryption are different controls

For every Direct Connect, ExpressRoute, partner interconnect, VPN and application tunnel, record the physical or logical endpoints and the encryption endpoints separately. AWS Direct Connect does not encrypt transit traffic by default. MACsec protects the Layer 2 link between specific devices and does not create end-to-end encryption across successive segments. The configured mode also matters: a preference that can fall back to clear traffic is a different guarantee from a mode that stops traffic when encryption cannot be established.

ExpressRoute traffic is also unencrypted by default. With ExpressRoute Direct, MACsec can protect the physical customer-to-Microsoft link. IPsec instead covers the configured on-premises-to-Azure gateway path. Map those endpoints onto the application flow: any remaining segment needs its own protection decision, such as TLS.

The audit should reconcile diagrams with live state: circuit type, peering, route advertisements, failover path, encryption mode, key ownership, rotation procedure and monitoring. Test failover in a maintenance window or review a recent controlled exercise. Confirm that a secondary path does not silently bypass inspection or encryption. Where active manipulation is too risky, validate configuration and status read-only, then agree on a narrowly scoped owner-operated test.

Remote management agents can reverse the trust direction

Hybrid agents can create a path from a cloud role to a privileged local process. On Azure Arc-enabled servers, Custom Script Extension and Run Command execute scripts as Local System on Windows or root on Linux by default. Host-side restrictions can narrow that path, but adding an allowlist does not remove extensions already installed.

Avoid simplistic conclusions such as “every cloud Contributor is root.” Determine the assigned Azure roles, permitted extension operations and effective local state. Test the result of those layers together: a cloud permission to request an operation and the host's decision to accept it are separate conditions. The audit finding should describe the combined route that actually exists.

Validate with a harmless, pre-approved action on a non-critical or designated test host: for example, request an extension operation that should be denied, or run an agreed command that writes a nonce to a temporary test location. Correlate the cloud activity event, agent log and host event. Do not deploy arbitrary payloads, disable endpoint protection or test on domain controllers without explicit, narrow authorization.

Evidence must cover control plane and data plane

Configuration screenshots are weak evidence when detached from scope, time and identity. Prefer machine-readable exports with tenant or account identifiers, collection timestamps and the commands or APIs used. Store a hash or immutable copy when the audit process permits. For every material control, collect design evidence, operating evidence and validation evidence: what should happen, what the system recorded over a relevant period, and what happened during an authorized test.

Cloud logging defaults are especially easy to misread. In AWS CloudTrail, management events describe control-plane operations and are recorded by default for trails and event data stores; data events such as object-level access require explicit selection. Google Cloud similarly writes Admin Activity logs, while Data Access logs are generally disabled by default outside stated service exceptions. An audit that finds “CloudTrail enabled” or “Audit Logs present” has not yet shown that a sensitive object read, function invocation or database data operation is visible.

Build an event matrix from the threat model. Rows are actions that matter: change a federation setting, attach an administrative policy, alter a route, install an agent extension, read a sensitive object, use a break-glass account, change a log sink and deny an access request. Columns state expected source, event category, identity field, destination, retention, alert and evidence owner. Run one harmless known event for representative rows and trace it end to end. Note redacted fields, unsupported services and sampling explicitly.

The evidence index should link every conclusion to a specific export, query, time range and test marker rather than a folder of screenshots. If a cloud event proves only that a request was submitted, the local agent log should show whether it ran. If the host shows only a process start, the cloud identity field should show who triggered it through which permission. Correlating layers distinguishes configured, operating and outcome evidence.

1. Inventoryenumerate both endpoints, trust objects, agents and owners
2. Configurationexport the effective identity, network, agent and logging state
3. Validationperform an authorized harmless action with a unique marker
4. Correlationfind the marker across cloud, agent, host and detection systems
5. Retestrepeat the same acceptance test after remediation

Safe validation needs an authorization envelope

The rules of engagement should name accounts, hosts, applications, test windows, source addresses, permitted actions, data-handling rules and stop conditions. Assign a technical owner who can halt the exercise, and define who watches production health. This is particularly important for federation changes, key rotation, route failover and management agents because a technically small action can interrupt authentication or connectivity.

Use the least invasive method that can answer the question. Begin with read-only exports and log queries. Move to owner-executed changes when the assessor does not need direct write access. Use dedicated test identities and synthetic objects. Prefer a denied-operation test where denial proves the control. If exploitation would be required to establish impact, agree on a safe proof boundary: demonstrate the reachable permission or execution primitive without accessing business data or persisting on a host.

This is where a cloud red-team assessment differs from the audit described here. Red teaming pursues an agreed adversarial objective and may chain weaknesses. A hybrid audit can stop once it has reproducible evidence that a boundary claim is false and enough context to remediate it. A secure configuration audit offers additional context when the primary need is baseline verification rather than cross-boundary attack paths.

Findings should assign the broken hand-off

A useful finding names the source state, crossing, destination effect and missing evidence. “ExpressRoute is unencrypted” is too broad; “the provider circuit is private, but the application flow between endpoint A and workload B has no verified encryption beyond the edge link” is actionable. “Revocation is slow” should become “the cloud account stopped receiving new tokens, while application C continued accepting its own session until its configured expiry.”

Assign remediation to the team that can change the control, and name dependencies. IAM may shorten token exposure, but the application owner must implement session invalidation. Networking may enable MACsec, while the application owner still owns TLS after the link endpoint. The cloud platform team may restrict an Arc role, while the server team configures local allowlists and removes existing extensions. Security operations may write a detection, while the service owner must enable the data-event source.

Prioritize by credible path and business effect rather than product labels. A route from a broadly assigned cloud role to privileged execution on an on-premises identity server deserves attention because it can cross administrative tiers. A missing low-value object read log may be less urgent, yet still material if it prevents investigation of regulated data access. State assumptions instead of inflating certainty.

Retest criteria belong in the original finding. They should specify the export or query to repeat, the harmless action to perform, the expected denial or event, and the maximum acceptable propagation time. Configuration presence alone is not closure when the finding concerned behavior.

What the buyer should receive

The final package should include an executive view of the highest-risk trust paths, the boundary register, scope and exclusions, an architecture view, evidence index, reproducible findings, remediation ownership and retest cases. A detailed sample penetration test report helps buyers judge the expected level of evidence, while the scope planner is useful for assembling accounts, identity systems, circuits, agents and applications before procurement.

Effort should not be estimated from the number of cloud accounts alone. The main drivers are the number of trust paths, identity types, circuits and encryption endpoints, agent-managed hosts, log categories to validate, permitted manual tests and retest rounds. A small but critical identity path crossing several administrative teams can require more coordination than a large, standardized single environment. A supplier should explain how these variables affect price and schedule instead of offering a fixed promise without defined boundaries.

Ask prospective assessors how they will handle temporary access, production safety, multiple administrative teams and evidence from excluded carrier or SaaS segments. Ask whether they distinguish control-plane visibility from data-plane visibility, and whether retesting repeats behavior or merely rechecks a setting. Those answers are more revealing than a long list of provider benchmarks.

The temporary-access plan should name who creates test identities, when permissions expire, how evidence is handed over and how revocation is confirmed. A multi-team environment also needs one contact and escalation path so network, identity, platform and application teams do not each assume another team owns the control.

An independent assessment is useful when ownership is fragmented, a migration has created overlapping controls, or the organization cannot demonstrate that incident actions propagate across the boundary. Pentest.red's cloud security audit can combine IAM and federation review, read-only configuration analysis, selected manual validation and attack-path reasoning within an agreed scope. The right next step may still be an internal evidence exercise if the team already understands the trust paths and only needs to close a narrow gap. The aim is a defensible answer to how the hybrid system behaves, who owns each correction and how that answer will be tested again.