Fortifying Database Protection with Fortanix Data Security Manager, Part - II

In my previous blog, I discussed how the advent of cloud computing has added various layers of complexity to databases and DB security. In continuation to that thought I can’t help but quote a line of thinking that has emerged in recent years: “just like you cannot keep the key in the same database, you cannot keep it in the same cloud.”

When we encrypt data at rest, there is a range of key management options, most of the times we use default encryption and store keys securely and transparently – for e.g., Oracle uses TDE – this enables keys to be separated from encrypted data with many, many boundaries of many different types.

In addition, cloud introduces a new dimension to the risk of keeping the key ‘close to’ the data: where the key is stored physically versus who controls the key.

For example, is the key considered 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? This also raises a question of who is ultimately responsible if the key is compromised—complicating the matter even more.

My Two Cents

• While working on our integration points with databases, here are my key takeaways after talking to the customers:Databases are becoming a lucrative target for malicious actors seeking sensitive data.
• Legislation and audit compliance has seen organizations increase focus on classifying and protecting sensitive data.
• Cloud has given rise to a new wave of Database technologies to meet modern requirements—many of which provide no or limited native encryption capabilities.
• Public cloud PaaS offerings are reliant on proprietary key management solutions which provide custody but not ownership of cryptographic key materials.
• 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.
• Providing consistent encryption policies and governance across Multicloud environments is virtually impossible using native tooling.
• As the volume of data grows across Enterprise and systems become more integrated, the footprint of systems containing sensitive data continues to expand— increasing the difficulty of consistent encryption practices across environments.
• Remote work and access have drastically shifted the focus on Identity and Access controls to manage and protect sensitive data sources more granularly.
• One of the fundamental data security mistakes involving encryption is encrypting the data and failing to secure the encryption key. To make matters worse, common issue is leaving the key “close” to data, such as in the same database or on the same system as the encrypted files. Such practices reportedly were a contributing factor for some prominent data breaches.

When we try to encrypt the database on the cloud – one needs to consider securing the data in cloud and security of the cloud. The figure above depicts the integration points for database for SaaS, IaaS, PaaS, and on-premises. Multiple integration points bring its own challenge in terms of security, manageability, and performance.

Key Differences between data-in-rest encryption methods

How does Fortanix provides encryption to On-premises and Cloud-native databases?

On-premises:

• Oracle
  • Fortanix Provides pkcs11 library that Oracle Database can use and connect to DSM. DSM stores the master encryption key that encrypts/decrypts DEK.
  • Database Stores the encrypted version of DEK which required for encrypting and decrypting Data.
  • Database stores the connection secrets in an encrypted auto-login wallet.
  • Fortanix PKCS library provides network resiliency and auto-connect feature which allows database to be stable and able to reconnect to DSM cluster nodes in case of site failover.
• MongoDB
  • Ensure MongoDB Enterprise Edition
  • MongoDB relies on KMIP for TDE; KMIP server access via port 5696 (must be able to communicate to DSM on that port)
• DB2
  • Fortanix Provides KMIP library that IBM DB2 Database can use and connect to DSM.
  • DB2 native encryption ensures that the DEK is never exposed outside of the encrypted database, transaction log, or backup file.
• MSSQL
  • Fortanix Provides EKM provider that MSSQL Database can use and connect to DSM.
  • DSM stores the master encryption key (Asymmetric Key) that encrypts/decrypts DEK
  • Database Stores the encrypted version of DEK which required for encrypting and decrypting Data.
  • Database stores the connection secrets (API_KEY) in encrypted format.

Cloud Native:

• BYOK
  • Fortanix DSM installed in on-prem
  • Key generated on Fortanix DSM and BYOK’ed in respective cloud
  • Intercepting application / tool sends the data to be encrypted by DSM
  • CMK imported into cloud KMS
  • New service provisioned on cloud (such as S3) and KMS CMK is attached to newly provisioned service
  • DEK is generated and wrapped with CMK -> all new files / data into newly provisioned service is encrypted at the server side using DEK

  

  

  The above figure depicts BYOK use cases for cloud native databases and steps to encrypt an AWS Aurora DB. Data Encryption / Decryption via Fortanix DSM: Data is sent to local region DSM through Route 53 and Elastic Load Balancer. Data is Encrypted / Decrypted and sent back to EC2 Instance with User Defined Function and is Stored / Queried by AWS Aurora DB

• BYOE
  • Fortanix DSM installed in Azure, AWS or GCP local region
  • New VM Instance within same region has database (such as Oracle) containing sensitive information
  • Master Key Encryption / Decryption via Fortanix DSM:
  • Wrapped Data Encryption Key is sent to local region DSM through Azure DNS / Traffic Manager/ Route 53 and into Regional Load Balancer
  • Unwrapped Data Encryption Key is Encrypted / Decrypted and sent back to VM Instance hosting the database
  • PKCS#11 and KMIP both apply

  

  Data Driven Security with Fortanix DSM

  

  With Fortanix Data Security Manager we help customers in data migration between on-premises to cloud and cloud to cloud by encrypting/ tokenizing the data (structured, un-structured, IoT etc.,) even before the ingestion layer and safely storing the encrypted data in datalake or customer managed DB.

  At the consumption layer – data is decrypted using a stringent RBAC control at the application layer. We enable the following use cases:

  • Tokenize sensitive information
  • Whitelist based on customer (IP’s)
  • Cloud native-controls
  • Secure at lifecycle (microservices based applications)
  • Encrypt data-at-rest

Now that we’re on the same page with regards to the knick-knacks of cloud-based database security, stay tuned for the third part of this series. I’ll give you a thorough walkthrough of database integrations with KMS and a demo of how BYOK integration can be done with Azure Synapse.

I promise the wait is going to be worth it.

I understand you may already have plenty of queries, and we would love to take those.

Check out the next part of my blog here.

You can begin by reading the datasheet here.

Want to see us in action? Sign up for a free demo.