The use of cloud databases is commonplace in many companies, and the advantages are compelling: the performance of the database systems is easily scalable, storage space problems do not exist, and access from different geographical regions is unproblematic. But despite all the simplicity, database security remains a key issue.
Cloud databases come in two different presentations that have divergent security requirements. With infrastructure providers, the database runs on a virtual server for which the using company is fully responsible. The provider only guarantees the trouble-free operation of the physical infrastructure.
For platform services, also called Database as a Service (DBaaS), shared responsibility applies to the database. In simple terms, the provider takes care of a database system that is up-to-date at all times and equipped with the necessary security updates and provides basic security functions.
Users are responsible for taking care of all other aspects of database security on their own. To do this, they can choose from numerous security options, although some of these are initially inactive.
Enable two-factor authentication
Despite all the security concerns, “factory” enabled user authentication is often limited to the classic credentials: Username or email address and password. But this is not enough. For example, passwords that are reasonably secure are difficult to remember. Many users then write them down on a piece of paper that they leave somewhere, for example on their office desk. This is basically a gateway for cybercriminals.
Two-factor authentication, therefore, makes sense. This means that users log on to an application for the database with at least two identification features. This is, for example, a specific password (1st factor) and a confirmation code (2nd factor).
The user finds it in an authentication app such as Google or Microsoft Authenticator on the smartphone. This procedure prevents, for example, a captured password or a stolen smartphone from becoming a security trap, since both factors are always needed to gain access.
Assign user rights and protect admin access
Each access to a cloud database requires its own user account, which must be created by a master admin. He or she gives individual users their rights. Pure users should be so strictly limited that they cannot change the configuration or the structure of the database.
The simplest way to do this is the so-called role-based security, where there are several user roles, for example, guest (read data), the user (read and write data), and admin (all rights).
There should be only a few admin user accounts, and these must also be specially protected. For example, it makes sense to create special accounts for them that are not connected to Single Sign-On (SSO). This allows admins to log in even if the SSO is affected by a malfunction or cyberattack. This includes automatically logging admins out if there has been no activity for a while.
Encrypt data and connections
Cloud databases offer several options to encrypt data. As a rule, they are not yet activated during the initial configuration, since a key must first be generated. This can be done with integrated routines of the database system, but also via an external application. This option is often referred to as “Bring Your Own Key”: The key is not generated and managed at the DBaaS provider but in an external application.
The most important thing is the encryption of the data and the connections. Data encryption applies to data stored in tables, so they are worthless without the right key. However, they must be decrypted for transport between the database system and a front-end system. Therefore, it makes sense to use transport encryption.
This is a protocol such as HTTPS that establishes an encrypted tunnel between two endpoints, in this case, the database and a using application. What is important here is whether the cloud database is in the same or a different infrastructure or cloud. If the organization runs its IT infrastructure and database platform with the same cloud provider, the intra-cloud connection is easy to protect.
Enable and encrypt backups
By now, most providers have the backup function active by default. Normally, it makes a backup of the entire database instance with all active tables once a day. This copy is then stored in a separate storage area.
There are built-in functions for encrypting the backups, but they are not active for the same reason as for general data and transport encryption: A key must be generated first. Since the database backups are stored in storage areas of the provider, companies should encrypt them in any case.
Backup and evaluate logs
During initial configuration, it makes sense to activate the log functions immediately. This provides information about the activities of all users of the database system. It also records any anomalies in database operation, such as frequently repeated logon attempts with changing password entries.
In general, detailed logs are a useful tool for measuring performance and determining the causes of malfunctions, configuration problems, and hacker attacks. However, similar to backups, logs are only kept for a certain period of time. So if you want to analyze events that occurred long ago, you have to back them up regularly.
Conclusion: Database security is the responsibility of the user
For technical reasons alone, many security functions are the responsibility of the user. Preliminary work is often necessary, such as generating a key or integrating an authentication system. If you do your homework here, you can achieve a high level of security even during the initial configuration of the database. DBaaS offerings are also a secure alternative: Here, the provider takes over more security aspects; admins are thus relieved.