For data to enable a business or a process, it needs to be instantly accessible. It is therefore unsurprising that vendors, analysts, and engineers spend a significant amount of time optimizing database performance. So much so that the notion of performance has often overshadowed the equally, if not more important, issue of data security.
In the early years of database technologies, the main bottleneck was hardware, which made accessibility and security at odds with each other, since they were essentially fighting for the same limited computing resources.
Now, with computing resources being virtually limitless, it is the speed at which organizations operate that has become the much bigger issue. An operation like creating a new database — which could easily take months on the on-premises hardware world — now only requires minutes. In the modern DevOps world with hundreds and thousands of product releases pushed out monthly, engineering teams create new infrastructure before security teams can even react.
And this is why it’s become apparent that the architecture optimized purely for performance is equally optimized for threat actors. It’s been decades since this revelation, and yet not factoring security into database design and resourcing continues to be a pervasive issue.
Added to the constant tug of war between performance and security is another equally important notion of cost. Too often, it’s the silent judge that decides where the balance is struck. Equally often, that balance is not struck in favor of security.
Database Security Capabilities
In the world of traditional on-premises databases, the problem of security has conceptually boiled down to proper resource engineering. Database security capabilities like monitoring and auditing required system resources, and the more resources one allowed, the better performance they could expect.
Database servers themselves were operated within the perimeter of an organization, allowing for much tighter access control and visibility around usage — only trusted users could gain access to the infrastructure the database ran on. Besides, production applications were very tightly coupled to the databases, often with no one except for a handful of administrators allowed direct access to those databases.
That’s not to say that data breaches did not happen. They certainly did, but they were nowhere near the proportions of the problem we have today.
One can rightfully wonder then, shouldn’t the cloud, with all its agile resource engineering capabilities and infrastructure as code (IaC), make securing databases easier? To one extent, it did: Managing and securing data in the cloud has never been cheaper. But it has never been harder either.
Data Security in the Cloud Era
Imagine the exponential growth in complexity of securing the modern data layer. Instead of a few types of carefully provisioned on-premises databases, a typical organization today uses a multitude of databases, data warehouses, and pipelines distributed across multiple clouds.
Add to the equation the DevOps model of dynamically provisioning any type of database on demand, often for each microservice, with very few agile controls available for properly regulating access to them.
It’s not all doom and gloom, however. Take one of the best examples of where the cloud and IaC clearly help database security: the notion of automated patch management. The practice, which has become common, is saving organizations thousands of hours in labor and, undoubtedly, millions more in potential breach costs. This could be one of the reasons why many IT professionals believe that the public cloud excels their own data centers when it comes to security — it can help easily avoid basic human errors like failing to install latest patches.
And yet, the fundamental dilemma of data security in the cloud still remains: Implementing any controls to monitor database accesses still means that you’re in the performance-sensitive path.
A simple read request requires that a database perform tasks like syntax analysis, query optimization, plan execution, and fetching results from physical media. Put a control point in front of that path, and you inevitably slow down the rest of the processes in the chain.
Some of the less successful attempts at strengthening security included introducing agents that would sit directly in the infrastructure, running background analysis on all activity with the hope of catching unauthorized accesses or any suspicious activity.
However, every single microsecond involved in these inspections means slowing applications down, which in turn impacts the user experience and, ultimately, the overall business performance. It doesn’t take a banker, for example, to realize that, when it comes to issuing a loan, there’s a big difference between getting the critical customer information in seconds compared to hours.
Sidestepping Performance Concerns While Increasing Security
There are other approaches in securing data that have fortunately proven to be more efficient. Take, for instance, asynchronous analysis, which postulates that it’s OK for an unauthorized read request to reach the data layer, as long as the results can be blocked. With this approach, read requests to the data layer are passed without any delay, while the data layer is processing them in parallel to determine if the corresponding results should be allowed or blocked.
Of course, in order to deliver this technology, you need to also employ some form of a stateless proxy that defers all session state management to the data layer connections. Such a stateless proxy would intercept any type of data requests, and, through asynchronous analysis, deliver results with next to no impact on performance.
Aside from the technical innovations, some new approaches to securing the data cloud focus on the how — the specific processes and practices involved in delivering security to data. It’s no secret that security of data has evolved from being a prerogative of a security team into a shared responsibility. Engineering, for instance, carries a much heavier burden, given the fact that data infrastructure is scaled and enabled instantly through the code that they write.
These days, many engineering teams that embrace DevOps, for example, release new code at the frequency of thousands of releases every year. At such a high pace, ensuring high data security standards necessitates practices like Security as Code, which implement security testing and scanning and access policies directly into the continuous integration and deployment (CI/CD) pipeline. Each of these checks enables engineering teams to understand and fix security issues much earlier on in development. As a result, security concerns are resolved immediately, avoiding potential costly delays and rework at the end of the development process.
These new approaches, while still early in their adoption, give reason to feel optimistic. In fact, the more optimistic among us may even say that, at last, the never-ending tug-of-war between database performance and security may be the issue of the past.
