Securing Cloud SQL on GCP: Best Practices and Tips
--
You have decided to migrate your database to the cloud, and you have chosen Google Cloud Platform (GCP) Cloud SQL as your managed database solution because of its scalability, reliability, and ease of use. However, you are concerned about the security of your database in the cloud and want to ensure that your data is protected against potential security threats.
This blog post will explore the security features and best practices for GCP Cloud SQL and how they can help organizations like yours protect their databases and comply with regulatory requirements. We will cover critical topics such as network security, access controls, encryption, auditing, and threat detection. By the end of this post, you will have a comprehensive understanding of how to secure your Cloud SQL instances on GCP and ensure the protection of your data.
Secure Connectivity
One of the first steps in connecting to Cloud SQL is to determine whether you want to use a public or private IP to connect to your instance. A public IP address is accessible through the public internet, while a private IP address is accessible within a Virtual Private Cloud (VPC).
Public IP
If you choose to use a public IP, you’ll need to authorize any connections to your instance using either the Cloud SQL Auth proxy or authorized networks. However, it’s important to note many companies have strict policies that limit the use of external IP addresses, which can impact the use of public IP addresses with Cloud SQL.
Private IP
If you choose to use a private IP, you’ll need to ensure that your resource has access to the VPC. Once you have access, you can use the private IP address to connect to your instance from that resource. This method is preferred, as it typically provides lower latency and a smaller attack surface. For private IP paths, you can connect directly to your instance through Serverless VPC Access from services and applications such as App Engine standard environment, App Engine flexible environment, Cloud Functions, and Cloud Run.
Suppose you’re considering using private IP connectivity for your Cloud SQL instance. In that case, it’s important to note that there are various considerations based on different use cases, such as connectivity from Compute Engine vs. Serverless services vs. Local environment. For more information, I highly recommend checking out Guillaume Blaquiere’s blog “Cloud SQL with private IP only: the Good, the Bad and the Ugly,” where he goes over these considerations in detail.
Access Control
In order to effectively manage your Cloud SQL instance, it is essential to configure access control for both instance-level and database-level access. Instance-level access is all about authorizing access to your Cloud SQL instance from an application or client, whether running on an App Engine standard environment or externally, or from other Google Cloud services like Compute Engine. This ensures that only authorized users or services are able to connect to your instance. On the other hand, database access is about controlling access to the data in your instance using database access control system. While both levels of access control are important, this blog will specifically focus on instance-level access.
Cloud SQL uses service accounts for authentication between Cloud SQL and other Google Cloud products. When you use an account to connect to a Cloud SQL instance, the account must have the Cloud SQL > Client role (roles/cloudsql.client), which includes the permissions required for connecting. You can add roles to an account in the Console on the IAM & Admin > IAM page, and see which permissions belong to which roles on the IAM & Admin > Roles page.
Cloud SQL roles and permissions with Cloud SQL Auth proxy
If you are connecting to a Cloud SQL instance from a Compute Engine instance using Cloud SQL Auth proxy, you can use the default Compute Engine service account associated with the Compute Engine instance. As with all accounts connecting to a Cloud SQL instance, the service account must have the Cloud SQL > Client role.
Cloud SQL roles and permissions with serverless options
Use a service account to authorize access from these options. The service account authorizes access to all Cloud SQL in a specific project. When you create an application or a Cloud Functions, this service creates this account for you. As with all accounts connecting to a Cloud SQL instance, the service account must have the Cloud SQL > Client role.
Permission to access private Cloud SQL instances
To allow other Google Cloud services like BigQuery to access your Cloud SQL instance and query data over a private connection, Cloud SQL uses an internal path instead of private IP addresses. However, VPC-level configurations, firewall rules, and route policies cannot control or restrict this traffic. To enable or disable this internal path for other Google Cloud services accessing your database, you can use a configuration flag available on your Cloud SQL instance.
Data Security
One of the key elements of data security is protecting sensitive information through encryption, secrets management, and secure networking. In the context of Google Cloud SQL, there are a number of options available to ensure your data is secure, including client-side encryption, customer-managed encryption keys, and using Virtual Private Cloud Service Controls. This section will explore these options and provide guidance on how to use them to keep your Cloud SQL data safe and secure.
Encryption
Cloud SQL provides automatic encryption of your data at rest using Google-managed encryption keys. This encryption is done at the storage layer and provides a strong level of security without any additional configuration or management required on your part.
For added security, Cloud SQL also provides the option of using customer-managed encryption keys (CMEK). With CMEK, you can create and manage your own encryption keys using the Google Cloud Key Management Service (KMS). By using CMEK, you have greater control over the encryption keys used to protect your data, and you can be confident that only authorized personnel can access the data.
Another option for data encryption is client-side encryption. With client-side encryption, data is encrypted before it is sent to Cloud SQL. For instance, imagine you have a table with sensitive information such as names and credit card numbers. You want to grant a user access to this table, but you don’t want them to view the credit card numbers. In such cases, you can encrypt the credit card numbers using client-side encryption. As long as the user is not granted access to the encryption key in Cloud KMS, they cannot read the credit card information. This provides an additional layer of security and control to help prevent data breaches and unauthorized access.
Secrets Management
Managing your sensitive information correctly is an essential part of creating a secure development workflow. For Cloud SQL, we recommend that you store your pieces of sensitive information as secrets that you create in Secret Manager. Secrets include API keys, passwords, sensitive information, or credentials that you might use to access a confidential system. Secret Manager provides convenience and improves security. You can also apply versioning to your secrets and share them across your team. To learn more, see Use Secret Manager to handle secrets in Cloud SQL
VPC Service Control
VPC Service Controls (VPC-SC) can help protect your Cloud SQL instances by creating a secure perimeter around them. This perimeter acts as a barrier to prevent data exfiltration from your Cloud SQL instances to the internet, which could occur through unauthorized access, data leaks, or other security breaches. With VPC-SC, you can use Access Levels to define granular access control policies for specific resources, allowing you to restrict access to your Cloud SQL instances based on your specific needs. Additionally, VPC-SC also provides real-time monitoring and logging to help detect and mitigate potential threats to your Cloud SQL instances. By utilizing VPC-SC, you can enhance the security of your Cloud SQL instances and ensure that your sensitive data is protected from unauthorized access.
Logging, Monitoring and Threat detection
Audit Logs for Cloud SQL Google Cloud services write audit logs to help you answer the questions, “Who did what, where, and when?” within your Google Cloud resources. Your Google Cloud projects contain only the audit logs for resources that are directly within the Cloud project. Other Google Cloud resources, such as folders, organizations, and billing accounts, contain the audit logs for the entity itself.
There are three types of audit logs available for Cloud SQL:
- Admin Activity audit logs: These include “admin write” operations that write metadata or configuration information. Admin Activity audit logs cannot be disabled.
- Data Access audit logs: These include “admin read” operations that read metadata or configuration information. They also include “data read” and “data write” operations that read or write user-provided data. To receive Data Access audit logs, you must explicitly enable them.
- System Event audit logs: These identify automated Google Cloud actions that modify the configuration of resources. System Event audit logs cannot be disabled.
Understanding the types of audit logs available for Cloud SQL is an important step towards securing your data. By analyzing the logs, you can gain insights into the usage and performance of your resources, as well as detect any suspicious activity.
Identify and prevent Cloud SQL vulnerability and misconfiguration
Using Security Command Center Premium, you can detect potential misconfigurations and vulnerabilities in your Cloud SQL instance. To learn about all the detectors available for Cloud SQL, visit this link.
Furthermore, you can use organizational policies to create guardrails for Cloud SQL, helping you enforce best practices and security requirements. Organization policies enable administrators to control how users configure instances under that organization by placing rules, or constraints, on a project, folder, or organization. The policies are enforced across all instances and help ensure compliance with access restrictions and security measures. For more information visit this link.
The Event Threat Detection (ETD) feature in Security Command Center Premium can help detect potential threats and unusual activity for Cloud SQL by analyzing Admin Activity and Data Access audit logs, but requires that those logs be enabled in order to provide the most accurate and comprehensive results. Some of the findings include:
Exfiltration: Cloud SQL Data Exfiltration
Exfiltration: Cloud SQL Restore Backup to External Organization
Exfiltration: Cloud SQL Over-Privileged Grant
Initial Access: Database Superuser Writes to User Tables
For more information on these findings visit this link.
Conclusion
In this blog, we discussed some of the key features and tools available for securing Cloud SQL, such as encryption, VPC Service Controls, and IAM policies. We also discussed the importance of logging and how tools like Security Command Center can help detect misconfigurations and potential threats. By following the best practices and utilizing these tools, customers can strengthen the security posture of their Cloud SQL instances and keep their data safe.
