What Cloud Security Actually Controls

Cloud security is often focused on protecting networks and endpoints, but some of the most consequential actions happen somewhere else: the cloud control plane. This is the API layer used to create, change, and delete cloud resources. If an attacker compromises an identity with legitimate permissions, they can use those same APIs to change security settings, modify access policies, or create new administrative accounts. The potential damage is determined by what that identity is authorized to do—not just by the security controls protecting the underlying infrastructure.

Cloud Security versus Infrastructure Protection

Traditional security governs what is physically present: servers you can touch, network segments you can cable, endpoints you can image. Cloud security governs what can be acted upon through APIs. The distinction matters because the controls are fundamentally different.

In an on-premises environment, an attacker who compromises a server gains access to that server's local resources and whatever network segments it can reach. In a cloud environment, an attacker who compromises an identity gains access to every resource that identity's permissions allow — across regions, across accounts, across service boundaries. The attack surface is not the compute instance; it is the IAM policy attached to the role that instance assumed.

Misconfiguration, improper separation of privileges, and insufficient logging are among the most common security weaknesses NSA and CISA observe across large organizations. In cloud environments these weaknesses concentrate at the control plane — the API layer where identities configure and authorize resources — which is why visibility into control-plane activity is a foundational requirement for cloud security.

Cloud control exists in four places: the API authorization layer, identity permissions, configuration state, and the telemetry which records what happened. If these four control surfaces are not governed, the cloud environment is not governed — regardless of how well the underlying infrastructure is protected.

Cloud Control Planes

The control plane is the API layer through which identities create, modify, delete, and configure cloud resources. Every action a human user, role, service principal, or automated process takes generates a control-plane API call. CloudTrail in AWS, Activity Logs in Azure, and Cloud Audit Logs in GCP capture these calls: which identity made the request, what API action was requested, which resource it affected, when, from where, and whether it succeeded.

This is the authoritative record of what cloud environments do. Security programs that do not govern the control plane are governing a shadow of the actual system.

Control-plane logs contain several categories of high-signal events for security practitioners:

Role assumption and credential events show when identities change context or gain new permissions. AWS AssumeRole, Azure service principal authentication, and GCP service account impersonation all generate control-plane events that establish who can act with what authority.

IAM policy modifications change what identities can do. These events — AttachUserPolicy in AWS, role assignments in Azure, IAM bindings in GCP — directly modify the authorization surface. An attacker who can modify IAM policies can grant themselves additional permissions without needing to compromise additional credentials.

Logging configuration changes modify what gets recorded. Disabling CloudTrail, modifying log retention policies, or changing log destinations can eliminate the evidence of subsequent actions. These events often appear before other malicious activity.

Resource creation events establish new attack surface. Creating new IAM identities, launching instances with privileged roles, or establishing cross-account trust relationships all expand what an attacker can reach.

The control plane is distributed: actions can be taken from any location with valid credentials, across multiple management interfaces, through CLI tools, SDKs, or third-party integrations. This distribution means that control-plane authority cannot be centralized to a single administrative interface.

Control Plane versus Data Plane

The control plane governs how resources are configured and who can access them. The data plane governs what flows through those resources — data reads and writes, network traffic, application transactions.

Most cloud security programs have partial visibility into the control plane and limited visibility into the data plane. The combination creates gaps: an attacker who exfiltrates data from a misconfigured S3 bucket may not appear in control-plane logs, which show access configuration, but would appear in data-plane logs like S3 access logs showing GET requests.

Control-plane logs answer different questions than data-plane logs. Control-plane telemetry shows who changed what configuration when. Data-plane telemetry shows what data moved where. An incident that involves both configuration changes and data movement requires both log sources to reconstruct.

Data-plane logging varies significantly between cloud services and often requires explicit configuration. S3 access logging, VPC Flow Logs, and application-level access logs each capture different aspects of data movement. Control-plane logging is typically enabled by default but may not cover all service actions depending on configuration.

Governing cloud security requires visibility into both planes, with different monitoring requirements for each. Control-plane monitoring focuses on identity activity and configuration drift. Data-plane monitoring focuses on data movement and access patterns.

Identity as a Control Surface

Every control-plane action is taken by an identity — a human user, a role, a service account, a federated principal, or an automated process. Identity is not just an authentication mechanism; it is the control surface through which all cloud actions are authorized.

The permissions attached to an identity determine what that identity can do to the cloud environment, which resources it can reach, and what blast radius it carries if compromised. Cloud security without identity governance is control without a control surface.

Identity operates at multiple layers in cloud environments:

Human identities authenticate through identity providers and assume roles or receive direct permissions. The blast radius depends on what roles they can assume and what direct permissions they hold.

Service identities operate with permissions needed for their function. EC2 instance profiles, Azure managed identities, and GCP service accounts all represent non-human identities that can make control-plane API calls.

Cross-account identities enable resource sharing and service integration across cloud account boundaries. These relationships — AWS cross-account roles, Azure service principals, GCP service account impersonation — create paths between otherwise isolated environments.

Federated identities map external authentication systems to cloud permissions. When external identity providers are compromised, the mapped cloud permissions become available to attackers.

When any of these identity layers is compromised, the damage tracks the permissions the identity carries rather than the infrastructure beneath it — which is why identity and configuration governance, not host hardening alone, does most of the work in bounding the blast radius of a cloud breach.

Each identity type requires different governance approaches, but all share the same characteristic: they can act through the control plane with whatever authority their permissions allow.

Logging and Telemetry Foundations

Cloud telemetry serves as security evidence when it meets four requirements: comprehensive coverage, sufficient retention, tamper resistance, and identity context.

Comprehensive coverage means control-plane logging is enabled across all accounts, subscriptions, and projects. Gaps in coverage create blind spots where malicious activity can occur without detection.

Sufficient retention means logs are kept long enough to cover the investigation window when incidents are detected. Many cloud compromises are not detected immediately; logs that have been deleted cannot be analyzed.

Tamper resistance means logs are centralized to a location the compromised environment cannot modify. If an attacker can delete or modify the logs that would expose their activity, those logs cannot serve as evidence.

Identity context means individual API calls can be attributed to specific principals and sessions. Logs that show API activity without clear identity attribution cannot establish who took what action.

When these conditions are not met, telemetry exists but cannot function as evidence. A cloud environment with control-plane logging that gets deleted weekly, stored in the same account it monitors, or missing identity details cannot support incident investigation.

Each cloud provider implements control-plane logging differently. AWS CloudTrail can be configured per region or organization-wide. Azure Activity Logs operate at the subscription level but can be aggregated. GCP Cloud Audit Logs function at the project level with organization-wide aggregation options.

The default configuration often provides incomplete coverage. Enabling comprehensive logging typically requires explicit configuration and centralized log management.

Service Relationships and Control Boundaries

Cloud accounts, subscriptions, and projects function as administrative, billing, and security boundaries. IAM policies, service control policies, and network controls can be scoped to these boundaries. Understanding where control boundaries exist determines where security governance must be applied.

Administrative boundaries determine who can manage what resources. Account-level permissions in AWS, subscription-level access in Azure, and project-level IAM in GCP all establish different scopes of administrative control.

Service-to-service relationships cross these boundaries with permissions governed by service identities. A Lambda function calling S3, an EC2 instance assuming a role, or a workload querying Secrets Manager all represent service relationships that can span accounts or projects.

Regional boundaries affect where data resides and which regulatory requirements apply. Some compliance frameworks require data to remain within specific geographic regions, making regional architecture a security control.

Cross-boundary relationships create paths between otherwise isolated environments. Cross-account trust relationships, shared VPCs, and federated access all represent boundary crossings that require additional scrutiny.

Where control boundaries exist determines where security governance must be applied. A multi-account AWS environment requires governance at the organization level, account level, and individual resource level. An Azure environment with multiple subscriptions requires governance at the tenant level, subscription level, and resource group level.

Boundary crossings require additional scrutiny because they represent potential escalation paths. An identity with cross-account access can potentially extend a compromise beyond the initially affected environment.

What This Means for Security

Cloud security programs that monitor network perimeters and endpoint behavior without governing the control plane miss the primary attack surface. Most cloud attacks operate through the control plane: compromising an identity, using that identity's API authority, modifying configurations to extend access or reduce detection, and creating persistence through new identities or policy modifications.

The evidence of these actions exists in control-plane logs. The authority to perform them exists in identity permissions. The exposure surface exists in configuration state. Governing cloud security means governing all three.

Traditional security controls that worked in physical environments often do not apply directly to cloud control planes. Network segmentation cannot prevent an identity with broad IAM permissions from accessing resources across multiple network segments. Endpoint protection cannot prevent legitimate API calls made with compromised credentials.

What changes the security outcome in cloud environments:

Identity governance that limits what each identity can do and monitors what it actually does.

Configuration management that prevents security-relevant configuration changes without approval.

Control-plane logging that provides complete visibility into who changed what when.

Boundary enforcement that limits blast radius when individual identities are compromised.

Organizations that apply traditional security models to cloud environments without adapting to the control-plane reality often discover their security controls during incident response — when the attack has already succeeded through ungoverned API access.

Sources