Cloud-to-Cloud Connection

How cloud-to-cloud connections work

A cloud-to-cloud connection is a direct trust relationship between two cloud services, not a user-facing integration that always passes through a local application tier. In practice, the connection is usually established with an API, delegated token, service principal, or federated trust, so the security boundary is defined by what each provider will accept and what each tenant has granted.

That makes the connection more than a simple data pipe. It is a live authorization path that can allow reads, writes, workflow triggers, and administrative actions across services. Because the request is often machine-to-machine, the organisation must treat the connection as a governed access relationship, not just an integration detail.

What makes cloud-to-cloud connections security-relevant

The main security question is whether the two services are exchanging only the minimum data and actions needed. The risk grows when permissions are broader than the business case, when tokens are long-lived, or when trust is extended across multiple tenants or vendors. OWASP API Security Top 10 is a useful lens here because many cloud-to-cloud failures are really API authorisation failures, exposed endpoints, or overly permissive service-to-service access.

Cloud-to-cloud links also inherit the security posture of the connected services. If one side is misconfigured, compromised, or over-permissioned, the other side can become a pivot point for data exposure or workflow abuse. For that reason, the connection should be reviewed as part of both service ownership and vendor dependency management.

Common failure modes and exposure paths

The most common failures are excessive scope, secret leakage, weak token handling, and unclear ownership. A forgotten OAuth grant or shared service account can keep working long after the original business need has changed. If the connection is tied to a broad cloud role, a compromise of the calling service can turn into access to storage, messaging, or control-plane functions that were never intended to be exposed.

Attackers often prefer these connections because they blend into normal service traffic and can survive longer than interactive sessions. T1021 Remote Services is relevant where the connection is used as a lateral movement path, especially when cloud consoles, remote administration channels, or direct service access are available through valid credentials.

How organisations govern and harden them

Good governance starts with inventory: know which cloud-to-cloud links exist, which identities or tokens they use, what data they touch, and who owns them. The connection should be tied to a documented business purpose, a narrow permission set, and a review cycle so that stale integrations do not persist by accident.

NIST SP 800-53 Rev 5 Security and Privacy Controls is useful for structuring this governance because the subject spans access control, credential lifecycle, logging, and configuration management. NIST Privacy Framework also matters when the connection moves personal or sensitive data across providers, because data minimisation and trust boundary mapping become part of the control design. NIST Cybersecurity Framework 2.0 provides the broader governance structure for identifying, protecting, detecting, responding to, and recovering from integration risk.

Operational monitoring and review

Cloud-to-cloud connections should be monitored like privileged infrastructure, not treated as static plumbing. That means watching for unusual token use, unexpected source IPs or regions, new scopes, admin-level actions, and changes in request volume or timing. If the service-to-service path is abused, the indicator is often abnormal legitimate traffic rather than obviously malicious payloads.

Where the connection supports remote administration or direct cloud access, MITRE ATT&CK Enterprise Matrix helps analysts map the activity to lateral movement and credential abuse patterns, while NIST SP 800-207 Zero Trust Architecture reinforces the principle that each request should be verified and limited even when the caller is another cloud service.

Risk and Threat Considerations

Cloud-to-cloud connections create a privileged trust path, so a mis-scoped grant, leaked token, or compromised service can expose data and automation across provider boundaries. The danger is not just data theft, but persistence, because a valid machine-to-machine grant can remain usable long after an initial intrusion is detected.

Failure mechanism: Excessive permissions, long-lived credentials, weak revocation, or unclear tenant trust let an attacker reuse a legitimate integration path to read data, trigger workflows, or move laterally between cloud services.

Impact: The result can be cross-service data exposure, unauthorized actions, service disruption, and hidden persistence that is harder to spot than interactive account compromise.

Practitioner Guidance

Why practitioners should care: Treat each cloud-to-cloud connection as an owned security control, not a convenience integration. The practical decision is whether the business value justifies the trust, scope, and monitoring burden that the link creates.

What to watch for: Review changes in scopes, service ownership, authentication method, and data flow whenever the upstream or downstream service changes. A connection that was safe at creation can become overprivileged or stale after routine platform changes.

Practitioner takeaway: The safest cloud-to-cloud links are the ones that are narrow, inventoried, monitored, and easy to revoke.

Related resources from NHI Mgmt Group

• What breaks when audit logging depends on a live cloud connection?
• What is the difference between a direct Active Directory connection and a resource forest with one-way trust for cloud Linux access?
• What is the difference between manual Mac connection to Active Directory and a cloud identity bridge?
• How should teams handle cloud database services that do not log connection attempts?