Cloud Infrastructure Security: Risks and Best Practices

Key Takeaways - Cloud infrastructure security protects the compute, network, identity, storage, and control-plane layer beneath your applications and data. Where your responsibility starts depends on the service model. - The provider secures the infrastructure of the cloud. You secure the configuration, identity, and exposure of everything running in it, and that line moves between infrastructure as a service and managed services. - Four controls carry the layer: workload identity, network exposure, image and patch state, and control-plane logging. Every major provider offers all four under a different name and a different default. - Provider defaults are a security decision you inherit without making it. A new AWS security group allows all outbound traffic, Azure network security groups allow everything inside a virtual network, and Google Cloud’s default Compute Engine service account holds the Editor role on the project. - Orca maps assets, configurations, identities, and network paths across every provider into one Unified Data Model, so a control question asked once returns one answer instead of three. Cloud infrastructure security is the practice of protecting the compute, network, identity, storage, and control-plane layer your applications run on. It covers the resources you configure rather than the hardware the provider operates. Where that boundary sits depends on the shared responsibility model and the cloud service you use. Cloud security spans everything from application code to compliance. Infrastructure security focuses on the cloud infrastructure you provision and operate beneath those applications. This guide explains the core infrastructure components, the risks that affect them, the practices that reduce exposure, and how the same controls map across AWS, Azure, and Google Cloud. What is cloud infrastructure security? Infrastructure security in cloud computing is the set of controls protecting the resources underneath an application, including compute, networking, identities, storage, and the provider APIs that create and manage them. Because you configure these resources, you are responsible for securing them. Where the provider’s responsibility ends and yours begins depends on the shared responsibility model and the service you use. With infrastructure as a service, you manage the guest operating system, patching, network rules, and workload identities. With managed services, the provider manages the underlying platform while you still control access policies, encryption decisions, and network exposure. The provider secures the cloud computing platform. You secure how you use it. That split determines which failures are yours. A hypervisor flaw belongs to the provider. A security group open to the internet belongs to you, regardless of provider or service model. Application logic and data sensitivity sit above this layer and belong to application and data security. Why cloud infrastructure security matters Infrastructure failures scale differently from application failures. A bug in one service affects that service. An over-permissive role attached to a compute instance affects everything that role can reach, and a network rule opened for a migration outlives the migration by years. The blast radius is set by the layer, not by the severity of the individual finding. Speed is the second reason. Cloud infrastructure gets created by pipelines, by consoles, and by teams who do not report to security, so the cloud security infrastructure you operate has to cover resources it was never told about. A provider’s compliance certification confirms that the provider’s facilities and hypervisors were audited. It says nothing about the account someone opened last quarter, or the default that account inherited. Key components of cloud infrastructure security Infrastructure security in cloud estates breaks into five components. Separating them matters because they fail independently and different people own them. What follows describes what already exists in your environment. Designing the target state is the job of cloud security architecture, which is a different exercise. Compute and Workloads Virtual machines, containers, and serverless functions. At this layer you own the image, the packages inside it, and the configuration it launches with. Workload protection and container security each cover a slice of this in depth. The component includes instances that are stopped, paused, or orphaned, which still hold data and still hold credentials. Network Cloud infrastructure security network controls answer two questions: what can reach this resource, and what can this resource reach. The primitives are virtual networks, subnets, route tables, instance-level firewall rules, load balancers, peering connections, and private endpoints. The second question is the one the defaults answer for you, and they answer it permissively. Internal network segmentation is what keeps one compromised subnet from becoming the whole environment. Identity and Access Every compute resource runs as something. AWS attaches an IAM role through an instance profile, Azure attaches a managed identity, and Google Cloud attaches a service account. These machine identities outnumber the human ones in a typical cloud estate, and a pipeline creates them, so no joiner process ever reviews them. Cloud infrastructure entitlement management and least privilege enforcement exist because this component grows without anyone deciding that it should. Storage and Data Services Object storage, block volumes, snapshots, and managed databases. The infrastructure-layer questions are narrow: what the access configuration allows, who owns the encryption key, and which network paths reach the endpoint. Snapshots deserve a separate look, because a snapshot carries its own permissions, separate from the volume it was taken from, and it outlives the instance that created it. What the data actually is, and how sensitive it is, belongs to data security rather than to this layer. Logging and the Control Plane The provider API is where the other four components come from. Every resource above was created by a call to it, and that call is the only durable record of who did what. AWS records it in CloudTrail, Azure in the Activity log, and Google Cloud in Cloud Audit Logs. Coverage is uneven by default, which turns security visibility into a configuration problem before it is a tooling problem. Common threats and vulnerabilities in cloud environments Five failure modes belong specifically to this layer. Each one is a property of how cloud infrastructure works, not a generic security risk restated with the word cloud in front of it. - Exposure created by a default, not by a mistake. A newly created AWS security group has no inbound rules and one outbound rule allowing all traffic, per AWS documentation. Azure network security groups ship with default rules that allow all traffic inside the virtual network and all outbound traffic to the internet. Google Cloud’s implied rules deny all ingress and allow all egress. Nobody misconfigured anything, and outbound is wide open on all three. Many of the common cloud misconfigurations teams find are defaults that were never revisited. - Machine identities holding permissions nobody reviewed. Google Cloud grants its default Compute Engine service account the Editor role on your project. An AWS instance profile widened during a debugging session tends to stay wide. Compromise the workload and you inherit the identity, which turns a single foothold into lateral movement across the account. - Metadata service abuse from a compromised workload. A server-side request forgery flaw or a compromised container can reach the metadata endpoint at 169.254.169.254 and ask it for the workload’s credentials. The providers harden this differently. Azure requires a Metadata: true header and Google Cloud requires a Metadata-Flavor: Google header, while AWS states that by default an instance accepts either IMDSv1 or IMDSv2 unless the AMI sets ImdsSupport to v2.0. IMDSv2 uses session tokens and a default response hop limit of 1, and that hop limit is what keeps a container off the endpoint. It is a short attack path from an application flaw to the control plane. - Compute images that stopped being maintained. A golden image gets built once, hardened once, and then keeps launching instances long after the hardening was current. Patch state is a property of the image, so every instance launched from a stale image starts life behind. Stopped and paused instances make it worse, because they hold the same packages and no agent-based scanner reaches them while they are off. - Resources created outside infrastructure as code. A virtual machine stood up in the console for a test never passes through a pipeline check, carries no owner tag, and inherits every default described above. It is the combination that matters. Unowned plus undefended plus unreviewed is the shape of the asset that shows up in an incident. Cloud infrastructure security best practices These cloud infrastructure security best practices are ordered by how much exposure each one removes. The first three cost configuration changes. The last four cost a decision about how your organization works. - Make workload identity the first thing you inventory. List what every compute resource runs as before you look at what those identities can do. Replace long-lived access keys with the provider’s workload identity mechanism wherever a workload can use one. - Close egress, not only ingress. All three major providers allow outbound traffic by default. Attackers use that path for credential exfiltration and command and control, so start with the accounts holding your most sensitive data and work outward. - Require the hardened metadata path. Set instance metadata options to require IMDSv2, keep the response hop limit at 1, and block the metadata address at the container network layer for workloads that have no reason to call it. - Treat the image as the unit of patching. Rebuild and redeploy instead of patching in place, and set a maximum age for any image still in service. Cloud patch management and continuous vulnerability scanning tell you which images have fallen behind. - Enforce at the organization boundary. AWS service control policies attach to the organization root, an organizational unit, or an account, and they cap the maximum permissions available instead of granting any. Google Cloud’s Organization Policy Service works at the organization, folder, or project level, and Azure Policy covers the equivalent scopes. A guardrail applied account by account gets skipped by the next account someone creates. - Make infrastructure as code the only path to production. Anything created by hand is invisible to every check in your pipeline. Infrastructure as code scanning only pays off once console changes are the exception. - Turn on the logs the provider leaves off. AWS retains 90 days of management events in CloudTrail Event history and does not log data events by default. Google Cloud always writes Admin Activity audit logs but leaves Data Access audit logs disabled outside BigQuery. Cloud security posture management is what keeps these settings from drifting back. Cloud infrastructure security for multi-cloud and hybrid environments Running two clouds is not the problem. The problem is that the same control has a different name, a different scope, and a different default in each. A rule your team knows in one provider gets re-learned in another. That is the operational reality behind multi-cloud security, and it differs from the architectural question of multicloud versus hybrid cloud. The table below maps five common infrastructure controls to their provider-specific implementations and highlights the defaults that most often create risk. | Control | AWS | Azure | Google Cloud | | Instance-level network filtering | Security groups. A new group has no inbound rules and one outbound rule allowing all traffic. | Network security groups. Default rules allow all traffic within the virtual network and all outbound traffic to the internet. | VPC firewall rules. Implied rules deny all ingress and allow all egress. | | Identity attached to a workload | IAM role assumed through an instance profile | Managed identity | Service account. The default Compute Engine service account may receive the Editor role depending on organization policy; newer organizations disable that automatic grant by default. | | Instance metadata endpoint | Instance Metadata Service. IMDSv2 uses session tokens; the response hop limit is configurable and defaults depend on the AMI and account settings. | Azure Instance Metadata Service. Requests must carry a Metadata: true header. | Metadata server. Requests must carry a Metadata-Flavor: Google header. | | Control-plane audit record | CloudTrail. Event history holds 90 days of management events, and data events are off by default. | Activity log in Azure Monitor. Retained 90 days by default, so anything longer needs an export. | Cloud Audit Logs. Admin Activity logs are always written and Data Access logs are off by default outside BigQuery. | | Organization-wide guardrail | Service control policies | Azure Policy | Organization Policy Service | Applying Controls Across Providers Provider names are easy to learn. Defaults are what get deployed by accident. The first row illustrates the problem: the same network filtering control starts from three different defaults. Provider-specific guidance covers the details for AWS security, Azure security, and Google Cloud security. The AWS Well-Architected Security Pillar and its equivalents describe each provider’s recommended design patterns. Hybrid environments add another layer. On-premises, you own the physical network, hypervisor, and hardware lifecycle, so the responsibility boundary moves again. Treat each control as a single security objective with provider-specific implementations, and review those implementations continuously as providers change defaults and services evolve. The role of zero trust in securing cloud infrastructure NIST SP 800-207 defines zero trust as assuming “there is no implicit trust granted to assets or user accounts based solely on their physical or network location.” Read that against the Azure default rule allowing all traffic inside a virtual network and the point stops being abstract. Implicit trust based on network location is not a habit teams fell into. It is written into the defaults, and that is where zero trust security has to be applied first. For infrastructure specifically, the model changes three things. Authentication and authorization become, in the publication’s words, “discrete functions performed before a session to an enterprise resource is established,” so a workload proves its identity per call instead of inheriting access from its subnet. Long-lived credentials give way to short-lived, workload-bound ones. The third change is the unit you protect. Zero trust protects the resource, so a private endpoint plus an identity check does work that a flat network never did. The trusted internal network stops being a control and becomes an assumption you have to test. Cloud infrastructure security posture assessment A cloud infrastructure security assessment answers one question at this layer: what exists, and what can reach it. How to scope the exercise, which type to run, which framework supplies the baseline, and what to do with the findings are all covered in the guide to running a cloud security assessment. What follows is scope rather than method. A cloud infrastructure security posture assessment covers six things. Any security posture assessment that skips the last one has produced a result about part of the estate. - Network paths and exposure. Every resource with a public IP address or a public load balancer in front of it, every allow rule that reaches it, and the egress rules that let it call out. - Identity boundaries. Every role, managed identity, and service account attached to a compute resource, and the resources each one can reach if the workload is compromised. - Compute images and patch state. Which images are in service, when each was built, and how many instances are stopped or paused, since those launch from the same images. - Storage configuration and encryption. Public access settings, key ownership, and whether a network path exists from a workload to the storage endpoint. - Control-plane logging coverage. Which accounts, subscriptions, and projects emit audit logs, at what level of detail, and where those logs are retained. - The account boundary itself. Accounts, subscriptions, and projects with no named owner. Nothing above applies to a resource nobody has claimed. How Orca Secures Cloud Infrastructure Across Every Provider Every cloud provider offers infrastructure security tooling, but each exposes assets, identities, configurations, and network paths differently. In multi-cloud environments, answering the same security question often means querying multiple consoles and reconciling the results manually. Orca’s Unified Data Model continuously maps assets, configurations, identities, network paths, and data stores across AWS, Azure, GCP, Alibaba, Oracle, Tencent, and more into a single model. Agentless SideScanning™ keeps running, stopped, and orphaned workloads in scope, while context-aware prioritization considers severity, exposure, blast radius, and data sensitivity. Get a Demo to see your infrastructure layer through a single, unified view. Frequently Asked Questions about Cloud Infrastructure Security Do You Still Need Infrastructure Security if You Only Run Serverless and Managed Services? Yes, though the surface shrinks. You no longer own a guest operating system or a patch cycle, so image maintenance and host hardening leave your scope. What stays is everything above the host: the execution role attached to the function, the network path to the managed endpoint, the encryption key decision, and the control-plane logging. Serverless moves the boundary, and it does not remove it. How Is Cloud Infrastructure Security Different From Cloud Infrastructure Entitlement Management? Cloud infrastructure security is the whole layer. Cloud infrastructure entitlement management is one component of it, focused specifically on who and what holds permissions and whether those permissions are used. CIEM answers the identity question in depth. It does not tell you which images are stale, which subnets are reachable, or which project stopped writing audit logs. Does Infrastructure as Code Make Your Cloud Infrastructure Secure? It makes it reviewable, which is not the same thing. A Terraform module can encode a permissive security group as reliably as a console click can, and it will then reproduce that group in every environment it deploys to. What infrastructure as code buys you is a single place to apply a check and a record of what changed. The check still has to exist, and console changes still have to be the exception. Which Team Should Own Cloud Infrastructure Security? Ownership usually splits, and pretending otherwise is where programs stall. Platform and cloud engineering teams own the primitives, because they create the accounts, the networks, and the pipelines. Security owns the standard those primitives have to meet and the evidence that they meet it. The arrangement works when the standard is written as something a platform team can enforce in code, and it fails when it arrives as a report. Do a Provider’s Compliance Certifications Cover Your Infrastructure? They cover the provider’s side of the boundary. A SOC 2 report or an ISO certificate held by a cloud provider attests to the controls that provider operates on its own facilities, hardware, and services. Your accounts, network rules, identities, and images are not in that scope. The certification is a reason to trust the platform, not evidence that your use of it is sound.