Five things to do to secure your Google Cloud Infrastructure

If you’re using Google Cloud Platform at your company, here are five things you can check to make sure your application’s infrastructure is as secure as possible. Infrastructure security, especially with big clouds like GCP, can be difficult to get right. It’s near impossible to have perfect infrastructure & application security, but these are a few big-ticket items that will get your organization moving in the right direction.

1 – Use Secure Boot & Shielded VMs

If you’re using a virtual machine based architecture, make sure you turn on Secure Boot if the image supports it. Secure Boot is a feature offered by Google Cloud Compute that verifies signatures for all boot components, stopping the boot process if any signatures are deemed invalid – inhibiting lower level attacks like rootkits.

Shielded VMs are an offering through Google Cloud Compute that allows users to spin up virtual machines with enhanced protection. In addition to using secure boot, these VMs also have enhanced integrity monitoring.

2 – Enable Versioning, Retention, and Bucket Lock, for Cloud Storage

When creating a Google Cloud Storage bucket, enable versioning, a minimum object retention, and bucket lock on the bucket to increase your company’s protection against ransomware attacks. Hopefully access to the bucket won’t be granted in the first place, but in case of a ransomware attack where all files in the bucket are encrypted, your organization still has access to the previous versions of all files in the protected bucket.

3 – Use Ephemeral Architectures

It’s often said to think of machines running your application as “cattle, not pets”. When you design these machines to be replacable, you spend less time trying to solve individual problems as you’re more likely to terminate the machine and create a new one.

By using ephemeral architectures, where machines are designed to be easily replaceable and ultimately temporary, advantages come when a machine is possibly compromised. If that machine is preemptible for instance, it’s maximum lifespan is 24 hours. While this doesn’t fix the underlying mechanism that allowed the machine to be compromised in the first place, it does buy your organization time to identify and solve the problem, whereas a traditional architecture might keep a machine compromised for a much longer period of time.

4 – Enable VPC Flow Logs

If you’re defining subnetworks for your VPC with a declarative tool like terraform, it can be easy to miss a simple block like log_config.

Here’s a resource without it:

resource "google_compute_network" "example" {
  name                    = "example-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "example" {
  name          = "example-subnetwork"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.example.id
  secondary_ip_range {
    range_name    = "tf-test-secondary-range-update1"
    ip_cidr_range = "192.168.10.0/24"
  }
}

and one with it:

resource "google_compute_network" "example" {
  name                    = "example-network"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "example" {
  name          = "example-subnetwork"
  ip_cidr_range = "10.2.0.0/16"
  region        = "us-central1"
  network       = google_compute_network.example.id
  secondary_ip_range {
    range_name    = "tf-test-secondary-range-update1"
    ip_cidr_range = "192.168.10.0/24"
  }
  log_config {
    aggregation_interval = "INTERVAL_10_MIN"
    flow_sampling        = 0.5
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

Enabling VPC flow logs allows detection (and a historical record) of anomalous traffic. This data is immensely valuable during a forensic investigation of network anomalies and should be always saved where possible.

5 – Use Managed Services Where Possible

If your company is running data pipelines, instead of rolling your own Apache Spark on Compute instances, consider using Google Cloud Dataproc, which allows a more managed and secure-by-default way of running data pipelines.

Smaller organizations often don’t have enough resources to dedicate to infrastructure or application security, especially machines running self-installed open source solutions. While running your own services is ultimately less expensive, it can come at the cost of infrastructure security. If you’re stretched for person-resources – use managed services where possible.

Looking to build secure infrastructure?

Get started with Cloudrail