Article
How to Build Network Security Architecture in Google Cloud (GCP)? Ultimate Guide
Have Questions? Want to see Valtix in action?
The Ultimate Guide to Building Network Security Architecture in GCP
Protecting your applications and workloads in public clouds continues to face new challenges. Log4Shell has been a wakeup call for customers who realized that there will always be windows of vulnerability since (a) finding vulnerable systems across their entire deployment is quite challenging, (b) patching vulnerable systems at scale is a lot harder than expected, and (c) having to deal with similar emerging/new threats will impose significant additional burden for security teams. This is changing how enterprises are viewing security in the cloud.
A recent report from the Google Cybersecurity Action Team (GCAT) also reveals additional cloud-specific challenges that build on the initial Log4J attack: new attack tools like Sliver for command-and-control (C2) and attack vectors using reverse SSH connections using GCP Cloud Shell.
Security Tools Provided By GCP
Let’s step back and review the network security tools provided by Google Cloud Platform (GCP):
- Cloud Armor – DDoS protection at layer 3 and 4 (similar to AWS Shield), and web application firewall (WAF). This protects Internet-facing web applications against attacks, providing ingress security.
- GCP Firewall – stateful firewall and ACLs (similar to AWS Security Groups) that allow traffic on customer-opened ports and approved GCP resources. This serves as a basic segmentation mechanism for ingress, east-west, and egress. It does not actually inspect the content of the traffic to determine good versus malicious traffic or sensitive data. GCP network endpoint groups (NEG) provide the same IP and port-based protections for container and backend services.
- GCP Cloud IDS – content inspection of mirrored traffic with no built-in ability to decrypt traffic. This is not sitting inline with traffic and cannot prevent or block malicious actions.
Here’s how the existing network security controls of GCP address security threats.
What’s missing is:
- A comprehensive, advanced GCP security approach that secures all flows, ingress, egress, and east-west.
- Segmentation combined with content inspection to prevent lateral movement of attacks
- Preventing connections to malicious sites and command-and-control (C2), and stopping exfiltration of sensitive information (DLP).
- Consistent multi-cloud security architecture that works across GCP and your other clouds (AWS, Azure, OCI).
GCP Cloud Security Done Right
Valtix provides a complete solution that solves the above issues and enables:
- Security informed by continuous and real-time discovery of cloud assets and security gaps that enable a proactive security model
- Dynamic multi-cloud network security policies based on workload identity
- Centralized hub-n-spoke or distributed scale-out architecture that works across all public clouds
- Baking security into the DevOps process using the Valtix Terraform provider that enables security teams to move in lockstep with the application teams and enables business agility
Network Security Architecture for GCP
Valtix provides flexibility in securing your workloads running in Google Cloud. You can choose between a distributed model that bakes security into each VPC, centralized hub-n-spoke that protects multiple VPCs, or a hybrid that protects Internet-facing applications in public VPCs while security east-west and egress flows in the centralized security hub. You choose, and the Valtix controller deploys.
Diving in a bit deeper using the GCP constructs for the centralized hub-n-spoke model, you can see that the application VPCs (aka the spokes) are connected via VPC peering to the security hub VPC. The security hub runs two Valtix Gateways, one for ingress to protect Internet-facing applications and the other for east-west (between VPCs) and egress traffic.
Customers configure security policies based on the workload identity of their applications based on deployment stage (dev, test, prod), application tiers (web/frontend, middle-tier, service1 etc), or security requirements (general, compliance, etc). These workload identities are based on the continuous discovery of your GCP cloud assets and leverage the tags and labels assigned to the workloads. As your applications are deployed or auto-scale, Valtix automatically applies your security policies.
A crucial new aspect of visibility in public clouds is to get visibility and control of your IaaS and PaaS provided by GCP and other public clouds. This ensures that you don’t treat the shared security model as a blind spot and ensure the protection of the 100s of cloud services from AWS, Azure, and GCP.
The entire deployment and security policy management can be performed in minutes from the Valtix service console or using Terraform. This enables you to make security operate at the speed of cloud, i.e., as application and DevOps teams deploy and update applications, they are automatically protected.
Outline Steps for Security in Your GCP Environment
- Sign up to get an account using the Valtix Free Tier
- Onboard your GCP accounts in minutes and enable traffic visibility
- View on-demand Hands-On workshop automating GCP security with Terraform to get started
- Discover your cloud assets and find the security gaps, including egress traffic to malicious sites
- Deploy Valtix Gateways
- Defend with security policies using discovered workload identities