Jump to Content
Networking

Google Cloud networking in depth: three defense-in-depth principles for securing your environment

June 20, 2019
Ines Envid

Group Product Manager

Emil Kiner

Senior Product Manager, Cloud Armor

If you operate in the cloud, one of the biggest considerations is trust—trust in your provider, of course, but also confidence that you’ve configured your systems correctly. Google Cloud Platform (GCP) offers a robust set of network security controls that allow you to adopt a defense-in-depth security strategy to minimize risk and ensure safe and efficient operations while satisfying compliance requirements. In fact, Google Cloud was recently named a leader in the Forrester Wave™: Data Security Portfolio Vendors, Q2 2019 report

In addition to tools, there are three principles for defense-in-depth network security that you should follow to reduce risk and protect your resources and environment: 

  1. Secure your internet-facing services
  2. Secure your VPC for private deployments
  3. Micro-segment access to your applications and services
https://storage.googleapis.com/gweb-cloudblog-publish/images/Overview_of_network_security_controls_GCP.max-1400x1400.png
Overview of network security controls GCP

Most GCP deployments consist of a mix of your own managed applications deployed in VMs or in containers, as well as some managed Google or third-party services consumed as software-as-a-service, for example Google Cloud Storage, or BigQuery for data analytics. GCP enables a defense-in-depth security strategy with a comprehensive portfolio of security controls, across all of these deployment models. 

It’s important to remember that the attack surface for your cloud deployment exponentially increases when it is exposed to and reachable from the internet. Therefore, the most basic network security principle is to close off access to your cloud resources from the internet, unless absolutely necessary. On GCP, you can use Cloud IAM and Organization policies to restrict access to GCP resources and services to authorized users and projects. However, in the event that a workload must be exposed to the internet, you should employ a defense-in-depth strategy to protect your environment. Let's take a closer look at three network security controls to minimize risk and secure your resources.

1. Secure your Internet-facing services 

If a service must be exposed to the internet, you can still limit access where possible and defend against DDoS and targeted attacks against your applications.

Defend against DDoS attacks 
The prevalence, magnitude, and duration of DDoS attacks is increasing as malicious tools and tactics proliferate and get commoditized by a wider range of bad actors. You can mitigate the threat of DDoS by placing your services behind a Google Cloud HTTP(S) Load Balancer and deploying Google Cloud Armor. Together, they protect publicly exposed services against Layer 3 and Layer 4 volumetric DDoS attacks.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Google_Cloud_Armor_protects_your_application.max-700x700.png
Google Cloud Armor protects your applications at the edge of Google’s network

Control access to your applications and VMs 
Cloud Identity-Aware Proxy (IAP) is a first step towards implementing BeyondCorp, the security strategy we developed to control access to applications and VMs in a zero-trust environment. With Cloud IAP, you can permit access for authorized users to applications over the internet based on their identity and other contexts without requiring them to connect to a VPN.

Enforce web application firewall (WAF) policies at the edge 
By deploying Google Cloud Armor security policies, you can block malicious or otherwise unwanted traffic at the edge of Google’s network, far upstream from your infrastructure. Use preconfigured WAF rules to protect against the most common application vulnerabilities like Cross-site Scripting (XSS) and SQL injection (SQLi). Configure custom rules to provide custom filtering of internet traffic across Layer 3 through Layer 7 attributes like IP (IPv4 & IPv6), geography (alpha), request headers (alpha), and cookies (alpha). 

Apply granular security policies 
Although Google Cloud Armor evaluates and enforces security policies at the edge of the network, you can configure those policies at varying levels of granularity based on the complexity of your deployment. You can configure uniform L7 filtering for all applications in a project, or deploy customized access controls on a per-application (backend service) basis. Policy and rule updates are possible through a REST API or CLI as well as the UI, and are propagated globally in near real time to respond to threats as they happen.

https://storage.googleapis.com/gweb-cloudblog-publish/images/Cloud_Armor_security_policies.max-1000x1000.png
Cloud Armor security policies can be applied at various levels of granularity

Turn on real-time monitoring, logging, and alerting 
With Stackdriver Monitoring you can leverage pre-configured or custom dashboards to monitor network security policies in real time including allowed and denied traffic as well as the impact of rules in preview mode (passive logging). Logs of all decisions made and relevant data about the requests can be sent to Stackdriver Logging to be stored in Cloud Storage or BigQuery, or forwarded on to a downstream SIEM or log management solution to plug into existing security operations processes and help satisfy compliance needs.  

2. Secure your VPC for private deployments 

As described in the previous section, you should keep your deployments as private as possible, to reduce their exposure to internet threat vectors. Google Cloud offers a set of solutions that let you deploy your workloads privately, while fulfilling critical user workflows: 

  • Deploy your VMs with only private IPs. You can reduce or eliminate your exposure to the internet by disabling the use of external IPs in VMs in specific projects, or even in your entire organization with an Org policy
  • Deploy GKE private clusters. If you use Google Kubernetes Engine (GKE), consider creating private clusters. Google Cloud still fully manages private clusters through a private connection to our managed cluster master.
  • Serve your applications privately whenever possible. Use our Internal Load Balancer service to scale and serve your applications privately, for clients accessing applications and services within your Google Cloud VPC, or from an on-prem private connection like Cloud VPN or Cloud Interconnect
  • Access Google managed services privately. Google Cloud offers a variety of private access options for Google services, so that both clients hosted in GCP or in your on-prem data centers can access and privately consume services like Cloud Storage, BigQuery or Cloud SQL. 
  • Provide secure outbound internet connections with Cloud NAT. Your private VMs or your private GKE clusters may need to initiate egress connections to the internet, for example, to contact an external software repository for software upgrades. Cloud NAT allows you to configure such access in a controlled manner, reducing the access paths and the number of public IPs to only those configured in Cloud NAT. 
  • Mitigate exfiltration risks by preventing your data from moving outside the boundaries of a trusted perimeter. VPC Service Controls allows you to build a trusted private perimeter and ensure that data access is not allowed outside the boundaries of that perimeter. Similarly, the data can't move outside of the perimeter boundaries, mitigating exfiltration risks.

The figure below illustrates a service perimeter applied to a production project, which prevents the data in Cloud Storage buckets or BigQuery datasets from being accessed or exfiltrated outside of the project’s boundaries.

https://storage.googleapis.com/gweb-cloudblog-publish/images/service_perimeter_applied_to_a_production_.max-1000x1000.png

3. Micro-segment access to your applications and services 

Even within a private boundary, you often need to granularly regulate communication between applications. Google Cloud provides a comprehensive set of tools to micro-segment those applications. 

  • Micro-segmentation for your VM-based applications. Within a given VPC, you can control the communication of your VM-based applications by setting up firewall rules. You can group your applications with tags or service accounts and then construct your firewall rules referencing tags or service accounts. While tags are metadata and very flexible, service accounts provide additional access controls, requiring a user to have permission to apply the service account to a VM. 
  • Micro-segmentation for your GKE based applications. Within a given GKE cluster, you can control communication between your container-based applications by setting up network policies. You can group your applications based on namespaces or labels.

Defense-in-depth, the networking way

To summarize, you can reduce your attack surface by making your deployments as private as possible. If you must expose your applications to the internet, enforce strict access controls and traffic filtering at the edge of the network while monitoring for anomalous behavior. Finally, enforce granular micro-segmentation even within the VPC perimeter using GCP’s distributed VPC firewalls and GKE network policies. 

By following these defense-in-depth strategies, you can reduce risk, meet compliance requirements, and help ensure the availability of your mission-critical applications and services. To get started, watch this NEXT ‘19 talk on Cloud Armor. You can learn more about GCP’s cloud network security portfolio online. Let us know how you plan to use these network security features, and what capabilities you’d like to have in the future by reaching out to us at gcp-networking@google.com.

Posted in