Security is a vast landscape of things: things to remember to do, things to find time for, and then things to get right. As such, it comes with a lot of cognitive overhead for security teams and developers hardening their code, system administrators patching their servers, and database administrators protecting their databases. Security is also constantly changing, in part because technology is constantly changing, which only adds to the cognitive load.
Advancements that can reduce cognitive load around security have tremendous potential because they get adopted. Benefits around risk reduction are inherited largely from the use of these advancements. Many modern programming languages for the most part don’t require that developers think about buffer overflows. Consumers of Software-as-a-Service (SaaS) products don’t think about patching.
A recent advancement in cloud-native database technologies referred to as autonomous databases seeks to have a similar impact on those responsible for setting up, managing, and overseeing databases, and includes many automated security features. It’s worth noting that while this term is being used for an Oracle Cloud product, similar concepts exist in other cloud infrastructure providers such as AWS Aurora or GCP Cloud SQL, though the features differ. While these new solutions can definitely reduce the cognitive load for database teams, they must still be vetted in terms of what they can and cannot do on the security front . This article is going to discuss some of the benefits and potential risks of autonomous databases as they apply to security.
The Security Benefits of Autonomous Databases
Some of the biggest security benefits of autonomous databases over traditional, cloud-based database technologies include:
- Automatic patching, which alleviates the constant negotiation around downtime, migrations, prioritization, and security impact.
- Encryption, which ensures that data is protected at rest using the optimal encryption settings — without needing to negotiate trade-offs with the development teams.
- Built-in auditing, which produces, from day one, a viable, consumable audit log of the service rollout. This is a huge boon for compliance and security operations teams.
- Configuration management, which gives scalable security benefits no matter where it’s applied. This is big. Operating by default on secure configuration settings is also important as configuration options change, ensuring little or no time is spent between a new feature release and its subsequent implementation.
Each of the above areas typically creates discussion points and trade-offs with development and system administration teams. Those trade-off discussions lead to gaps in coverage which, depending on how bad things might be, create opportunities for exploitation.
The Potential Risks of Autonomous Databases
One interesting aspect of the cloud technology explosion has been the misunderstanding of various shared responsibility models. This misunderstanding often comes in the form of assumptions not aligning with reality. For example, the consumer believes that their cloud provider is addressing auto-scaling or patching when, in reality, the particular services they are consuming do not handle this by default. This assumption leads to a gap, that gap leads to risk, and that risk can be exploited.
One of the biggest risk areas that I see with the development of autonomous databases lies in the unintended creation of these assumptions through marketing. Even if the reality of what autonomous databases (or equivalent solutions) do is only and exactly what their marketing campaigns are supporting, potential or actual consumers may still draw unintended conclusions.
Looking at the autonomous database documentation, it would be reasonable to conclude that an application owner doesn’t have to think at all about least privilege, configuration, hardening, encryption, or compliance issues when it comes to the database. Are these all the security concerns one might have when it comes to data? What about the service points of interaction with the database? What about processes security-related processes that intersect with or are built on top of the database?
The point is, “set it and forget it” assumptions can be dangerous when it comes to security. It’s important for users to understand everything their cloud tools can’t do as much as they understand what they can do.
Want more cybersecurity insights? Visit the Cybersecurity channel:
