Cloud database security: Best practices, challenges and threats

Why is effective cloud database security important?

As more database implementations move to the cloud, keeping security configuration and access controls in mind is critical for a number of reasons. These include the following:

• Data privacy. Given that cloud databases can reside in a wide variety of geographic locations, it's likely that any personal or sensitive data might fall under the purview of local or country-specific data privacy laws. Depending on the types of data involved, security and privacy teams should take deployment location into account, as well as monitoring and oversight capabilities in the provider environment that accommodate privacy reporting.
• Data classification and protection. Many data types might require encryption or other security controls to meet compliance or internal requirements. While encryption is generally standard in most leading cloud databases, it's important to ensure that encryption standards are met, as well as key rotation and other accompanying controls.
• APIs and integration. As with many other cloud services, cloud databases of all types are often interconnected to a wide range of other services in use within the provider ecosystem -- monitoring, application components and workloads, for example. They also offer a number of APIs that can be used to import and export data, synchronize data sets and make configuration changes. All of these connectivity areas can be potentially abused or exposed, so they need to be carefully configured.
• Role-based access. Along with the APIs and integration just mentioned, cloud databases often have a number of identity policies assigned, allowing access from both human and cloud accounts. It's very easy to assign excessive privileges to cloud resources quickly, and cloud databases are no exception.
• Cloud velocity. Cloud databases aren't exempt from the rapid pace of updates that occur in cloud deployments. Both development and infrastructure operations tend to experience more dynamic, fast-paced updates than traditional environments, which can often lead to mistakes or misconfiguration.

While these certainly aren't the only drivers to develop a sound, maintainable cloud database configuration and security standard, they're some of the most prevalent and broad in scope.

Common threats to cloud databases

Cloud databases are targets for attackers if they aren't properly secured. For example, in May 2021, security analytics software vendor Cognyte exposed 5 billion data records -- ironically, containing information on previous data breaches at other organizations -- due to a cloud database with weak authentication controls discovered by a security researcher. In late 2023, Microsoft AI researchers accidentally exposed 38 TB of personal data and other sensitive information in a database due to improperly configured permissions. Cloud service hosting provider Zenlayer exposed more than 380 million records in early 2024, primarily customer contact details and some technical attributes related to customer accounts.

There are numerous threats to cloud databases, with the most common types including the following:

• Data exposure. If cloud databases are poorly secured, it's likely the data in them could be exposed to the internet or other cloud resources. Attackers actively looking for exposed databases can take advantage of this and exfiltrate data for financial gain or other purposes.
• Exposed APIs. Many cloud databases offer a wide variety of APIs for administration, integration and synchronization with other data stores. If these APIs are exposed publicly, or poorly secured and left unmonitored, attackers could access and manipulate database content and configurations.
• Cloud workload hijacking. Cloud database workloads can run in containers or virtual servers. As a result, databases that aren't properly secured could be exploited by attackers who then compromise the underlying container or OS runtime. This could lead to lateral movement by the attackers and other cloud services also being disrupted, exposed or compromised.
• Application exploits. Cloud databases are potentially susceptible to common attacks, such as SQL injection, which can lead to application compromises, escalation of access privileges for user and service accounts and exposure of database details. In that way, attackers might be able to expand compromises of cloud environments through traditional application-centric attacks.

Challenges for organizations on cloud database security

Organizations planning to implement cloud databases, as well as those with cloud databases already deployed, will commonly face a number of challenges in configuring and monitoring them. Some of the most common include the following:

• Configuring and maintaining access controls. Unless explicitly set up to be public-facing, no cloud database should be visible directly to the internet. Security teams need to maintain vigilance to ensure no existing or new database services or instances are configured to allow public access, and threat modeling should be performed regularly to ensure all data and network access to all databases is as restricted as possible. In large environments, this can be a constant challenge.
• Managing encryption. While database encryption is usually set automatically, cloud tenants should enable customer-managed encryption keys wherever possible to enact better control over how and where encryption is applied, as well as key rotation and oversight. Encryption might need to be managed for connectivity, particularly for certain databases in Microsoft Azure where TLS requirements need to be set and maintained.
• Managing logging and database events. Cloud databases should have logging enabled, but this comes at a cost -- most generate staggering numbers of events that need to be managed. Security operations teams often find the volume of cloud database logs to be somewhat overwhelming, so they'll need to spend time familiarizing themselves with the types of events that are important and building detection and response workflows from these.
• Classifying and tracking data. Particularly as it relates to privacy requirements, classifying data in cloud databases and tracking it across different cloud regions and availability zones can be a major headache, and this is only compounded with multiple cloud services in use.
• Enforcing privileges and permissions. Fortunately, many leading cloud databases start with a minimal set of privileges associated with them, but this quickly changes as application architectures are deployed and connect to them.

Admittedly, many of the most common challenges related to cloud database security align with the top overall challenges in cloud security, such as security visibility for logging and monitoring, controlling user access and permissions, and protecting data anywhere in the cloud environment.

Cloud database security best practices

Regardless of which cloud database service is employed, be sure to follow these best practices:

• Change any default logins or credentials to the cloud databases. This prevents common brute-force attacks that use these default credentials to expose databases. Such attacks are simple to execute, even by unskilled adversaries.
• Employ customer-managed keys versus cloud provider keys where possible. Generating your own keys lets you have more control over the cryptographic strength of the keys, as well as permissions and the key management lifecycle. Removing cloud providers from involvement in key management and use is a good way to reduce risk related to third-party access to cloud database resources.
• Use cloud identity and access management to the utmost for privilege minimization. Cloud IAM is highly capable today, and granular least-privilege policies can be created and applied in all areas of cloud deployments. By prioritizing strong IAM, the threat surface of cloud databases can be significantly reduced.
• Enable full logging capabilities for all databases. Logs can be sent to a central security event management system for monitoring and incident response related to suspicious or malicious access attempts.
• Enable encrypted database access wherever possible. Encryption can help protect sensitive data and other cloud data assets from accidental exposure and illicit access by attackers who don't have the needed decryption keys.

Now let's take a look at some of the cloud database services from the top three cloud platform providers and their built-in security controls.

Amazon DynamoDB

DynamoDB is a managed NoSQL database service within the AWS cloud. It offers a number of security features, including the following:

• Automatic backups. These are possible using a specific template in AWS Data Pipeline, another data management service for moving data between different AWS cloud services. Full and incremental backups can then be used for disaster recovery and continuity.
• Automated 256-bit AES encryption. DynamoDB is the first AWS service to automatically encrypt data.
• AWS IAM permissions. Such permissions control who can use the DynamoDB services and API. These can be permissions to items (rows) and attributes (columns), which enables fine-grained access control.
• Cryptographically signed requests. Requests in the DynamoDB service must include a valid Hash-based Message Authentication Code SHA-256 signature to access stored data; otherwise, the request is rejected.
• SSL/TLS-encrypted endpoints. DynamoDB is accessible via SSL/TLS-encrypted endpoints.

Amazon RDS

Amazon Relational Database Service (RDS) is a more traditional service that offers a choice of different relational database engines. It includes MySQL, Oracle, SQL Server, Amazon Aurora, MariaDB or PostgreSQL as options. Its security features include the following:

• DB security groups. Similar to AWS security groups, DB security groups are network ingress controls that can be enabled by authorizing IP ranges or existing security groups. They only allow access to necessary database port(s) and don't require a restart of running database instances.
• IAM permissions. These are used to control which RDS operations users can call.
• Encryption. RDS supports Transparent Data Encryption for SQL Server and Oracle. MySQL encryption must be enabled by cloud clients within their applications.
• SSL/TLS connections. SSL/TLS can be enabled between RDS instances and applications running elsewhere in AWS.
• Automated backups and patching. Amazon RDS automatically backs up data and patches vulnerabilities by default.

Other options from AWS, Azure and Google Cloud

Amazon Redshift, a petabyte-scale SQL cloud data warehouse, offers logging, automatic patching, encryption with strong multi-tiered key management and encrypted network connectivity.

Microsoft's Azure cloud also has a variety of database services, including Azure Table storage. This is essentially a NoSQL data store that is now part of the Azure Cosmos DB database service via a Table API. They both support automated Storage Service Encryption by default and strong role-based access.

Microsoft also offers SQL Server PaaS capabilities as part of its Azure SQL Database service, which offers numerous data protection options. Column and cell encryption can be enabled with Transact-SQL, which supports built-in functions to encrypt data with symmetric or asymmetric keys, or the public key of a certificate. Azure SQL Database also offers Always Encrypted mode, in which entire columns of data can be automatically encrypted in applications before they are stored in the databases.

Google Cloud offers several databases, including Cloud SQL, which is a managed SQL database service for PostgreSQL, MySQL and SQL Server that has automated encryption and secure connectivity. Google's Spanner is a fully managed SQL database offering customer-managed encryption keys, logging, identity permissions and data-layer encryption. Bigtable is a NoSQL database that has customer-managed encryption, logging and strong access controls.

Editor's note: This article was updated to include information on cloud database security challenges.

Dave Shackleford is founder and principal consultant with Voodoo Security; SANS analyst, instructor and course author; and GIAC technical director.