One-and-a-half decades—that’s how long I’ve been in the IT industry. During my time here, I have worked on just about every database platform that exists— creating validated designs, best practices guides, and configuring backups for databases such as Oracle, MongoDB, DB2.
More recently, in my time at Fortanix, I have been working to provide encryption services and tokenization services for databases to safeguard Personal Identifiable Information (PII) data such as Credit Cards, salary information, private medical records and more.
Generally, on-premises database integrations are not very demanding and fairly straightforward—to an extent where data-at-rest encryption and tokenization do a decent job at fulfilling most compliance and regulatory obligations.
However, this space is witnessing some tectonic changes.
Flocking To the Cloud
The advent of cloud tech is making the database space a bit complex. Most organizations in the process of migrating or have migrated applications to the public cloud that leverage cloud-based PaaS or SaaS databases, on top of which there are database deployments on IaaS platforms such as Azure VMs and AWS EC2—require encryption services.
When we encrypt data-at-rest, there is a range of key management options to choose from. In most instances, the default encryption mechanism is used to store keys securely and transparently enabling separation from encrypted data with multiple boundaries of many different types.
For example, when deploying databases on cloud, the most essential risk mitigation is with Cloud Privileged Access, Cloud Unavailability and Compliance. Contrary to popular belief, it’s the insider threat that is an important metric from risk mitigation.
However, separation becomes more difficult as these databases move to the cloud where encryption services are held inside the same walled gardens as those databases.
Just as organizations understand the risks inherent to storing keys alongside the underlying database—storing keys in a KMS inside the same cloud poses a similar level of risk.
The new challenge has become not just ensuring separation of keys but also maintaining its ownership.
Historically, for ensuring performance, organizations seek to minimize the separation between the key and data—to reduce latency.
For example, is the key close to data if it is located inside a secure hardware device (i.e., an HSM) that is located on the same network (or: in the same cloud data center) as data? Or is the key close to data if it is located inside a system in another country, but people with credentials to access the data can also access the key with them?
Leveraging cloud-native management tools to manage keys allows you to retain custody of the keys, but fundamentally you do not own the keys which protect your data. This means you cannot export those keys to another cloud and given they are stored with the CSP.
Meaning, anyone who has access to the cloud account (be that the CSP, a rogue admin or Law Enforcement) can use this custody vs ownership arrangement to their own benefit and unlock your protected data.
Now Why Should It Concern You?
Cybercrimes have pretty much quadrupled over the past few years. More so during the pandemic. Databases have become a prime target for malicious actors seeking sensitive data—since providing consistent encryption policies and governance across Multicloud environments is virtually impossible using native tools.
The adoption of Cloud (accelerated by the shift to work from home) has given rise to a new wave of Database technologies to meet modern requirements, many of which provide no or limited native encryption capabilities.
Consider the database integration points for instance. While legislative and audit compliance mandates are pushing organizations to increase focus on classifying and protecting sensitive data—most database technologies fail to meet the modern-day data security requirements and provide no or limited native encryption capabilities.
Best of breed technologies are increasingly delivered as SaaS which changes the entire paradigm of database encryption when no or limited access to the underlying platform is provided.
PaaS offerings rely on proprietary key management solutions that provide custody but not ownership of cryptographic key materials, whilst best of breed technologies are increasingly delivered as SaaS, which changes the entire paradigm of database encryption when no or limited access to the underlying platform is provided.
Related Read: Getting Started with Database Security
As the volume of data grows across Enterprise and systems, become more integrated, the footprint of sensitive data systems continues to expand, increasing the difficulty of consistent encryption practices across environments.
And with new legislation and more rigorous auditing, organizations have had to increase focus on classifying and protecting sensitive data.
These challenges grow more complex every day as new legislation is introduced, new threats are uncovered, and customer environments become more disparate.
Getting the Basics in Place
One of the fundamental data security mistakes involving encryption is encrypting the data and failing to secure the encryption key. To make matters worse, a persistent issue we have encountered is leaving the key “close” to data in the same database or on the same system as the encrypted files.
Such practices have contributed to some of the more prominent data breaches of late, as has the lack of clarity around key ownership vs custody with organisations with too much reliance placed on tools that eschew the former in favour of the simplicity of the latter.
Fundamentally, however, these challenges can all be addressed with Fortanix and seeing the variety of environments and database platforms which our customers use today, putting in place a centralised key management solution to protect and encrypt every flavour of database in any type of environment simultaneously helps to enhance your organisation’s security posture whilst also simplifying operations and enabling them to be automated.
So how does a data-driven security posture look like? What do we mean when we talk about having a multi-level security approach? Where should you begin? Watch out this space for my upcoming blog that will cover all of these questions and many more.
I understand you may already have plenty of queries, and we would love to take those.
You can begin by reading the datasheet here.
Want to see us in action? Sign up for a free demo.