Are you currently experiencing an attack?

Are you currently experiencing an attack?

GCP and Cloud Security, Part 3

This third article in our Cloud Security and Google Cloud Platform (GCP) series focuses solely on networking.

There were two previous articles in this series. Part 1 explored the building blocks of cloud security and GCP, and Part 2 examined resource management and IAM on GCP. This third and final article will discuss the connections between all the pieces.

Virtual Private Cloud

Networking in a cloud environment isn’t much different from networking in a traditional data center, since all of the same concepts, rules, and best practices apply. One key difference between the processes is that in the cloud, everything is software-defined. You no longer have to worry about the physical limitations imposed by networking hardware.

When using GCP, you get a private, fully managed network in the form of a Virtual Private Cloud (VPC). This VPC is isolated from every other network in Google Cloud.

GCP’s VPC network is unique in that it is global. Some other cloud providers offer VPC networks that exist in a single region and require peering connections between VPCs in different regions. GCP’s network not only makes managing a globally-distributed network much more straightforward (i.e., there is no need for peering connections or VPNs), it also keeps traffic between regions off of the public internet.

VPC Concepts

For a network to be usable, there must be at least one subnet, which is a subset of the total IP address space of the network. While the network itself is global, the subnet is regional. Resources that involve networking, such as compute instances, are always attached to a subnet.

Routes determine what happens to traffic that leaves a subnet, commonly referred to as egress traffic. After you create a new subnet, a subnet route is automatically established by the system, making it possible to communicate between subnets. The system also automatically creates a default route that enables internet access. It is possible to delete this default route in order to isolate the network from the public internet. You can also replace the route completely and customize the egress traffic’s path to the internet.

Firewall rules control ingress and egress traffic. These rules not only control the traffic within the network, they also control traffic coming into and leaving the network. A firewall rule includes the direction of traffic (ingress or egress), the priority of the rule represented by a number from 0 (highest) to 65535 (lowest), the action to take (allow or deny), a target, and a source or destination (depending on the direction of traffic).

Best Practices

Simpler network topologies are much easier to understand, and a better understanding of the overall network results in a lower chance of hidden security holes. To make the network easier to manage and understand, you should group VMs with similar network security requirements in the same subnet and apply firewall rules to the entire subnet.

For production, always create a well-planned custom network. By default, new GCP projects contain an automatically-created network with a subnet for each region. All default networks have the same IP address range, which creates an overlap when connecting to other default networks. For existing projects, the default network can be deleted at any time, provided it’s not in use. It’s also possible to disable the creation of default networks for new projects by using an organization policy with a constraint.

Limiting external access is one of the simplest forms of security, and it is still a highly effective one. When external IP addresses on VMs are disabled, it is impossible to initiate connections to them from the internet. If you still want to allow these instances to be able to connect to the internet (for external API access or updates), you can use a NAT instance.

Just as you should keep different environments in different projects, you should also keep different environments in different networks.

Gotchas

One important limitation to be aware of with VPC is that only IPv4 is supported. While public internet traffic from and to a GCP load balancer can use IPv6, it is converted into IPv4 traffic before entering the VPC.

There are two implied firewall rules that don’t show up in the Google Cloud Console. Although you cannot delete them, they exist at the lowest possible priority, making them easy to override. One rule denies all ingress traffic with a source 0.0.0.0/0 (i.e., from anywhere)—a good default. The other allows most egress traffic with a destination of 0.0.0.0/0, which may or may not be what you want. It’s imperative to be aware of these implied rules and override them to suit your security requirements.

Network Monitoring

Monitoring is crucial not only for troubleshooting but also for security. Fortunately, monitoring one or more VPCs is quite straightforward.

VPC traffic can be logged as it enters and leaves compute instances. These logs are called VPC Flow Logs. They record information about the TCP and UDP traffic and enable you to monitor the performance and throughput of your network, helping you to better plan your capacity. They can also be used to detect unwanted/hostile traffic or assist in debugging efforts.

You can adjust the logs’ sampling levels from 0% to 100% of traffic. The aggregation time interval, which defaults to 5 seconds, can also be adjusted to give you near real-time log processing capabilities.

Enabling flow logs per subnet is also possible. Because flow logs use Stackdriver Logging, you can add filters to them and even forward them to other services supported by Stackdriver, such as Cloud Pub/Sub for real-time processing and BigQuery for long-term storage.

It is worth understanding how the VPC Flow Logs are generated. Each log entry is made up of aggregated ingress and egress packets on VMs. However, only about 1 in 10 packets are sampled. While this may not be a problem, it needs to be taken into account when planning your security and compliance requirements.

You can also monitor and audit firewall rules using Firewall Rules Logging. This feature can be incredibly helpful in determining whether or not a firewall rule is acting as expected. It can also monitor the amount of traffic that is allowed and denied. For each firewall rule, the logs can quickly be enabled or disabled. As with flow logs, firewall rules logs are sent to Stackdriver Logging, allowing you to take advantage of all the same advanced search, filtering, and exporting capabilities.

Best Practices

It is worth the effort to use these capabilities and monitor traffic as part of your daily workflows, whether via the native GCP products or by connecting them into your SIEM/SOC. Even better is to integrate them with your web security solution(s).

A common security mistake is to only pay attention to traffic that has been blocked; indeed, many security solutions only report the requests that were identified as hostile. However, when diagnosing a traffic issue, it is frequently valuable to examine all incoming requests (passed and blocked), and their disposition. Comparing blocked requests to those that are passed allows you to understand exactly how traffic is being processed, and can help diagnose traffic issues that otherwise could be difficult to understand.

A few security solutions provide this capability out of the box. Reblaze displays all incoming requests and their disposition in real time, and also streams its data into Google Cloud Security Command Center. It stores all traffic data in BigQuery, thus providing comprehensive historical logs.

Network Address Translation (NAT) in GCP

As previously mentioned, it’s often necessary to prevent virtual machines from accessing the internet directly—either for security or compliance reasons, or to have a static list of public IPs that your partners and clients can use to whitelist your traffic.

Instead of having to manage additional virtual machines to perform network address translation, GCP provides Cloud NAT, a managed, scalable, high-performance service that addresses this exact need. And, by using a managed service, your share of responsibility decreases. You don’t have to harden and secure VMs running at the edge of your network or shoulder a maintenance and operational burden.

Please note that a single Cloud NAT can have multiple public IP addresses and subnets, but it belongs to a single region. For networks with multiple regions requiring NAT, at least one Cloud NAT must be created per region.

Connecting Networks

Eventually, you’ll need to connect two or more networks. Whether the networks are all in GCP or include external networks, such as an on-premises network or another cloud provider, Google Cloud provides a plethora of possibilities for linking them.

Peering and Sharing

Connecting networks inside Google Cloud is a straightforward process known as VPC peering. It is possible to create a peering connection between any two GCP networks, even if they reside in different organizations. Compared to VPN solutions, peering is much simpler, and it is available at no extra cost.

However, for organizations that have multiple projects with shared networking, peering is not the only solution. It is possible to create a separate GCP project (a host project) with a shared VPC network. Other projects (service projects) are then associated with the shared network so that they can launch resources either in the entire shared network, which is the default, or just in one or more subnets, which is achieved by creating an organization policy constraint.

If you’re starting to plan your network from scratch, check to see if a shared network can suit your needs since VPC peering comes with limitations (such as the number of maximum peering connections) that are not present in a shared VPC network.

Virtual Private Network (VPN)

When connecting to networks outside of Google Cloud is necessary, you can use Cloud VPN, a fully managed, low-cost VPN solution. In it, each single Cloud VPN tunnel supports up to 3Gbps of network bandwidth. Cloud VPN supports high availability (HA) setups with multiple VPN tunnels, in which case an SLA of 99.99% takes effect. IPSec as well as both IKEv1 and IKEv2 are supported by it, as is dynamic (BGP) routing.

Dedicated Connection

If a physical connection to Google Cloud is required, GCP offers Cloud Interconnect. Because Cloud Interconnect is a physical connection outside of the public internet, it can be more cost-effective for large volumes of transferred data. There are two types of interconnect options. The first is a dedicated pipe from your network to one of Google’s point-of-presence (POP) locations. This pipe provides 10Gbps and 100Gbps circuits, up to a maximum of 200Gbps per connection. The second interconnect option is necessary when connecting directly to a Google POP is not feasible, or when less network throughput is required. In the latter case, there is a long list of partners that provide between 50Mbps to 50Gbps of connectivity. The partners maintain most of the required hardware.

Unlike VPN connections, direct connections to Google Cloud provide no encryption of the traffic whatsoever. This means that encryption has to be handled at the application level.

Best Practices

When designing network topologies, any network that is accessible from the public web must have robust protection against Internet threats: hacking and breach attempts, DDoS attacks, hostile bots, and so on.

GCP includes Google Cloud Armor, which defends against some threats. As a native GCP product, it is straightforward to deploy and use with the rest of your GCP platform. It is effective at blocking certain kinds of threats. However, it does not provide comprehensive, automated protection against all forms of attack.

The best practice is to use Cloud Armor as an enforcement mechanism. For example, Reblaze is fully integrated with GCP, and can act as Cloud Armor’s “GCP security engine.” Reblaze identifies hostile traffic, and Cloud Armor blocks it at the edges. More information is here: How to convert Cloud Armor into a full web security solution.

Summary

This series of articles has presented the basics of cloud security, the scope of Google Cloud Platform’s security-related offerings, and some cloud security best practices. While this series focused mostly on internal security, it’s equally important—if not more important—to protect yourself from external threats.

Robust web security today requires a next-generation WAF, DDoS protection, bot management, and more. For web application and API security, Reblaze offers a comprehensive, all-in-one solution for protecting sites, web applications, services, and APIs. (For a demo, contact us.)

A final note: on the web today, security must always be an important part of your thinking. When using a platform such as GCP, security is a shared responsibility! Neglecting it will eventually end in disaster. But diligently maintaining security best practices will provide peace of mind, as you leverage Google Cloud Platform to its fullest potential.

Get your price quote

Fill out your email below, and we will send you a price quote tailored to your needs

This website uses cookies to ensure you get the best experience on our website.