Infrastructure Security in the Cloud: Risk & Visibility

The cloud infrastructure security problem

Don’t think of cloud infrastructure security as a firewall checklist. Think of it as comprehensive, continuous understanding of reachability and segmentation across your entire cloud perimeter, forming the foundation of effective cloud security.  

The challenge: It’s an architectural problem. AWS, Azure, and GCP each define their own network policies for their cloud services (security groups, network ACLs, route tables, peering rules, service endpoints, private link options), and organizations must manage their portion of the shared responsibility model across multiple providers. That includes coordinating identity and access management (IAM), a SASE platform, private cloud, on-premises firewall infrastructure across your data centers, and internal microsegmentation policies. As a result, you end up with a heterogeneous policy fabric across cloud environments that’s difficult to manage manually and increases the risk of human error.

We cover this problem (and the complete set of risks and controls it creates) in our overview of cloud infrastructure security. For this article, we’re zooming in on the network layer: understanding reachability and segmentation.

Cyber threats don’t wait for your quarterly firewall audit to find their way in. They’re scanning for misconfigured security groups, permissive access policies, and paths to pivot between workloads right now. And manual reviews don’t scale as a defense.

Network exposure and reachability

Reachability is the question you find hardest to answer: If an attacker has gained a foothold in one workload or virtual machine, the management plane, or other critical cloud resources like cloud storage, understanding what they can reach is critical to containing cyber threats before they spread and reducing the risk of data breaches. You can’t see the answer in a firewall rule. Instead, it’s determined by the cumulative effect of policies and access controls at every point along the path, from one public cloud provider to another, across virtual routers and NAT gateways, and into on-premises segments.

When you build your cloud security architecture around reachability analysis, you can identify exposure that could be exploited by external attackers or insider threats. Rather than pull up individual rules to review, you ask the network itself: “Can this port be reached from the internet to my production database tier?” You get a simple yes or no answer. And you can audit the path that produced that answer.

Without a unified, up-to-date model of your network, answering that question can take days and multiple teams to complete. With one, you can have the answer in seconds.

Segmentation and security groups across AWS, Azure and GCP

Network segmentation is the first line of defense in containing blast radius if a workload or virtual machine becomes compromised, reducing the likelihood of data breaches. Public cloud providers implement segmentation and access controls differently: security groups, VPC boundaries, subnet level routing and firewall rules. The hard part is maintaining consistency: segmentation you enforce in AWS may not translate to Azure nor be enforced in GCP.

Rules within AWS VPC security groups are a typical attack vector for misconfiguration. Security groups tend to accumulate rules as teams rapidly provision new virtual machines and other cloud resources. Unused rules and overly permissive rules are rarely deleted. Imagine that practice applied across three cloud providers and thousands of workloads and soon your segmentation model will drift from your original intent.

With NIST SP 800-207A Zero Trust Architecture for multi-cloud environments defining segmentation as a policy enforcement challenge instead of a network topology challenge, the security control must be portable with the workload. That means a policy model that is provider-agnostic and enforced in real time, not periodically reviewed.

Network segmentation made simple for multi-cloud.  Gain visibility across providers into where boundaries are set, where they’re being violated, and what change caused the violation.

Cloud infrastructure security best practices

How do effective cloud security teams operate at scale? Here are some guiding principles that mature security teams follow. 

Map your attack surface. Actively. Your attackers will. Every security group, every route table change, and every new peering connection affecting your virtual machines and cloud resources is a potential vulnerability that can contribute to data breaches and increase the risk of insider threats if left unchecked. Continuous mapping of your network topology is required. Periodic audits are insufficient.  

Write your segmentation policy once, in vendor-neutral terms. Express your policy and access controls as intent, incorporating controls such as multi-factor authentication where appropriate: “production databases must not be reachable from the internet” or “development VPCs must not have direct routes to payment processing networks.” Then automatically enforce that intent across AWS, Azure and GCP, not manually and on a per-provider basis. 

Validate changes. Every change to your infrastructure should be validated against your segmentation policy before it reaches production and exposes cloud resources (Terraform apply, console tweaks, CloudFormation stack changes), helping maintain regulatory compliance while reducing unnecessary exposure. If it introduces exposure, it should be blocked or at least flagged. Don’t wait to learn about it during a post incident investigation. 

Don’t leave your cloud firewalls behind when you review your on-prem firewall policy. Hybrid cloud architectures create attack paths that span your on-prem and cloud environments. That on-prem perimeter firewall rule you just added? It may have opened up a path to cloud workload you thought was segregated. Govern your policy across the full path.  

Audit paths, not rules. Rules are inputs. Paths are the results of those inputs. Only by understanding every path (and the access controls governing it) can you know your true security posture.

Tufin’s approach to cloud infrastructure security

These practices describe the discipline. Here is how Tufin puts it into practice.

Central to Tufin’s platform is the Dynamic Network Connectivity Graph: a single source of truth and dynamic, up-to-date digital representation of your entire hybrid cloud and multi-vendor network. It graphs any firewall, security group, cloud router, SASE connection and microsegmentation boundary across a single data layer. Query the graph to answer reachability questions anywhere in your network, not just inside a single provider’s firewall or perimeter.

Overlaying the graph is Tufin’s control plane: a single control plane that manages your firewalls, cloud, routers and switches, SASE and microsegmentation from one platform.  You define policy once and enforce it across all your vendors.

Tufin converts your segmentation requirements into a single source of truth using the correct policy syntax for every platform: AWS security groups, Azure NSGs, GCP firewall rules, on-premises firewall rules. It maintains those definitions across infrastructure changes. 

Tufin’s agentic AI acts across your entire network, leveraging the graph as its knowledge base. It can help surface exposure, identify policy violations and suggest remediation options automatically, at scale, and in real-time. It doesn’t replace your security teams, but arms them with the ability to respond at attacker speed.

Learn how one healthcare provider with 300,000 employees and 186 hospitals reduced audit reporting from days to minutes with complete visibility into their hybrid, multi-vendor network. 

That’s what centralized security looks like in the cloud. Posture you can validate, not assume.

Conclusion

Securing your cloud infrastructure is an issue of continuous operations. Your network evolves every time a developer provisions a resource, a team updates a security group or an automation pipeline pushes a new config. Static reviews and periodic audits can’t keep up. You need a live model of your network. You need a policy layer that stretches across every vendor to support a consistent Zero Trust security model and complements identity and access management with consistent network policy enforcement. You need to know about exposure as soon as it happens, not weeks later when it gets exploited. Tufin provides all of that: the Dynamic Network Connectivity Graph as your single source of network truth, one control plane spanning cloud and on-prem, and agentic AI that works at network speed. If you’re ready to see what your network really looks like and what’s really reachable, get a demo.

Frequently asked questions

What is infrastructure security in cloud computing?

Cloud infrastructure security consists of the controls, policies and monitoring practices designed to protect the network layer of cloud environments. It complements identity controls such as multi-factor authentication by securing how systems communicate, not just who can access them. This spans VPCs, security groups, firewall rules, routing and segmentation boundaries. It answers the question of who can reach what, where exposures exist and if segmentation policy is enforced across providers. Cloud infrastructure security is different from workload or application security: it’s at the connectivity layer below your apps.

Find out more about securing cloud workloads and how it relates to infrastructure protection.

How does cloud infrastructure security work?

Cloud infrastructure security maintains a model of your network topology. It analyzes reachability across all layers of policy and enforces segmentation rules when your infrastructure changes. Cloud infrastructure security works by integrating a live model of your network (so you have visibility into what is actually reachable) with automated policy validation so you can catch changes that open up exposure before they hit production. Incidents happen in the gap between policy intent and enforcement.

See the top cloud security threats that exploit gaps in infrastructure security.

What are cloud infrastructure security best practices?

Best practices for cloud infrastructure security focus on providing continuous visibility, vendor-neutral policy definition and automated enforcement across your entire multi-cloud/hybrid environment, aligning with Zero Trust principles. Policies should be defined in business-meaningful terms and enforced through vendor-specific controls automatically. These policies should be validated against every change to your infrastructure before it reaches production. At maturity, teams focus on access path analysis as opposed to rules review as their primary audit mechanism. 

Learn how these best practices align to recommendations from the CISA advisory with Tufin’s breakdown.

How is cloud infrastructure security different from CSPM?

Cloud Security Posture Management (CSPM) tools determine if individual cloud resources are configured properly: encryption is on, public buckets are not exposed, IAM permissions are set correctly. Cloud infrastructure security determines if the network itself enforces your boundaries: what can talk to what, across all accounts, regions and providers. The two solutions are complementary.  If a properly configured resource is sitting on an open network path, it’s still exposed. 

Compare network security posture management to CSPM.