What the Google SQL Flaw Tells Us About Data Access in the Cloud

Last month, we saw yet another high-profile case of cloud administrators being able to access confidential data. This time, it was a security flaw in the Google Cloud Platform (GCP) SQL service that made the headlines. The flaw was notable because it could have been exploited to obtain access to confidential data and even take full control of database servers.

According to Dig, the Israeli data security firm that first identified it: “The vulnerability could have enabled a malicious actor to escalate from a basic Cloud SQL user to a full-fledged sysadmin on a container, gaining access to internal GCP data like secrets, sensitive files, passwords, in addition to customer data.”

Although the vulnerability was ultimately resolved without a data breach or other consequences, it’s only one of many cloud misconfigurations that are granting users too much access to data in the cloud. With that in mind, we’re taking a closer look at the situation — and what it says about the problem of cloud data access as a whole.

What’s the background on Google Cloud SQL?

Google Cloud SQL is a fully managed relational database solution that supports three distinct database engines: MySQL, PostgreSQL, and SQL Server. The service allows clients to build various databases for cloud-based applications and integrate them easily with those apps.

Cloud SQL offers many features, including automated failover, database provisioning, and storage capacity management. One of its chief selling points, though, is its ability to keep data secure and compliant. In this context, the new SQL vulnerability presented a major risk for reputational damage.

What was the Google Cloud SQL security flaw?

This is far from the first Google Cloud SQL vulnerability. As the data security company Dig noted, integrating database engines into cloud service providers is a challenge that often exposes new risks. It’s unsurprising, then, that previous vulnerabilities have been disclosed in MySQL and PostgreSQL databases hosted in GCP, AWS, and Microsoft Azure.

The new SQL vulnerability leveraged a gap in GCP’s security layer, allowing the security team to escalate their initial user privilege to a GCP administrator role. From there, the team was able to find a second critical misconfiguration in the SQL role-permissions architecture. That misconfiguration allowed them to further escalate their privilege to sysadmin on the SQL Server, from which they could have extracted passwords, accessed any file they wanted, and taken full control of the database server.

Google has since addressed the issue, which Dig originally discovered in February 2023, with a fix to its server and database permissions architecture.

What’s the bigger problem with data access in the cloud?

It’s clear that the SQL misconfiguration could have been very serious if it had been discovered by malicious actors rather than a security team working with Google’s bug bounty program. Dig noted that the misconfiguration allowed them to access the operating system hosting the database, which in turn allowed them to see sensitive files in the host OS and underlying service agents.

But the SQL flaw is also part of a much larger problem we’re seeing with cloud providers today: Too much data, available in too complex an environment, makes it nearly impossible to safeguard everything. Especially in hyperscale settings where speed is being prioritized over security, it’s easy for systems to have critical vulnerabilities that go undetected until it’s too late. The result is a much higher risk of data exposure, leaks, and breaches.

Minimizing data access in the cloud

To solve this problem, organizations should limit data access as much as possible.

The least-privilege approach is a good start, as are standard measures like multi-factor and biometric authentication, stringent data retention policies, rapid incident response, and isolating infrastructures that store sensitive data.

However, as a study from the MIT Computer Science and AI Lab notes, access controls alone are insufficient for data protection. They must be supplemented with measures like file-level encryption, which traditionally brings its own downsides.

An alternate solution is ShardSecure’s data control platform. With an innovative, agentless approach to file-level protection, the platform provides strong protection against unauthorized access. Even in an event like the Google SQL misconfiguration, cloud and system administrators remain unable to read sensitive data.

To learn more about how ShardSecure can help mitigate data security risks in the cloud, browse our resources or check out our solutions today.