Last October 22, 2020, the pharmaceutical company Pfizer suffered one of the worst data breaches within the Google Cloud Platform (GCP) in history. Found inside one of its unsecured Cloud Storage buckets are millions of personally identifiable information (PII), including medical records.
The cost of a security breach can have severe financial and reputation impact. Still, your organizations can avoid mistakes like these by configuring your GCP resources in a way that minimizes your security risks.
Here are some GCP cloud configurations to start looking into:
Restrict Your Data Storage
Just like what happened with Pfizer, many cloud breaches stemmed from one misconfigured bucket or database. These incidents make it paramount to secure your data storage and restrict them to entities you trust.
- Ensure all Cloud Storage buckets with sensitive data are not accessible to the world. If there’s a need to open some buckets up, make a note of all publicly accessible data locations and for what purpose it serves.
- Configure your Cloud SQL databases only to allow incoming connections from trusted sources. Making them publicly accessible can open up your database to attackers and make it easy for them to extract your sensitive information
- Restrict access to your BigQuery resources. BigQuery resources tend to run large and opening them to unauthorized users can have you rack up a hefty bill.
Once you’ve restricted your data, encrypt them while you’re at it to add another layer of protection.
While Google encrypts most data storage resources at-rest by default, you can add another security layer if you supply customer-managed encryption keys. If you choose this option, make sure to rotate your keys every 90 days to protect yourself from cryptanalysis-based attacks.
Enable and Secure Cloud Audit Logs
Another core part of any GCP security strategy is ensuring you have full visibility to all activities within your cloud infrastructure. Cloud Audit Logs provide full transparency within your cloud environment and track what activities are happening.
There are two types of Cloud Audit Logs:
- Admin Activity Logs: Logs that detail API calls and configuration changes, like creating new Compute instances and changing IAM permissions. These logs are on by default, and you cannot configure them.
- Data Access Logs: Logs that detail the creation, modification, and deletion of user data. As these types of logs can run large, you need to turn them on explicitly (except for BigQuery, whose data access logs are on by default).
Here are some best practices when configuring Cloud Audit Logs:
- Enable Data Access Logs for every service you use. Ensure there are no users exempted from log capturing.
- Configure sinks for all log entries. Sinks are objects that tell Cloud Audit Logs which logs to export and where to export it. At the minimum, export your logs to a Cloud Storage Bucket.
- Restrict Cloud Audit Logs access to those who need them. Restrict especially your Data Access Logs, since they detail every activity from everyone who accesses all your resources.
Once you have your audit logs configured, set up log metric filters and alarms to alert you for any changes and unusual activity happening within your account.
Use Service Accounts Wisely
Service Accounts in the GCP world are both a resource and an identity: As a Resource, you can control who can access your Service Accounts. As an Identity, you can also grant a role to a specific Service Account to allow access to certain resources in your project.
This concept makes service accounts extremely powerful, depending on how you configure them. Do the following to secure your service accounts.
- Have a naming convention for your Service Accounts that is easy to read and understand. It should immediately tell you what the account is for and what it can access.
- Limit identities with the Service Account User role. The Service Account User role allows users to indirectly access resources they would otherwise not have access to through a Service Account.
- Make sure your Service Accounts do not have admin roles bound to them. Create one Service Account per GCP service and only give the minimum privileges needed to function correctly.
- Do not rely on default Service Accounts. Default Service Accounts tend to have loose privileges and do not allow you as much control as creating your Service Accounts.
Adhering to these best practices ensures that your GCP infrastructure follows the least privilege principle, reduces the attack surface area, and minimizes security risks.
These are just some of the cloud configurations you can do to secure your GCP environment. Organizations that need to continuously maintain a robust cloud security posture can choose to periodically do a security review of their infrastructure. But this can be tedious and inefficient, let alone risky between checks. That’s why more and more organizations are turning to Cloud Security Posture Management (CSPM) tools to automate these checks at a fraction of the manual cost.
Learn more about CSPMs here:
