0

I am looking into ways to build a data warehouse that would house confidential data for 1+ clients. The requirement is that our organization can never obtain access to the decrypted data. There would be a web application clients utilize to write data and query data (basic select statements including ranges).

I've been learning about SQL Server Always Encrypted w/ Secure Enclaves (and Azure SQL Always Encrypted w/ Secure Enclaves) and am wondering about key management strategies.

Based on what I've read here: https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/always-encrypted-enclaves?view=sql-server-ver16 and even here https://aws.amazon.com/blogs/modernizing-with-aws/sql-server-always-encrypted-with-secure-enclaves/ , it seems like at the end of the day, someone in an organization utilizing this, is going to maintain access of the actual keys that could be used to decrypt the data.

Microsoft suggests role separation such that a DBA may have access to the database, but not access to the keys used for encryption and a Security Admin has access to the keys but not the actual database.

But, hypothetically, if the DBA and Security Admin wanted to be malicious together, they could technically obtain access to the data together. Are there strategies that can be employed to help mitigate this potential risk?

I'm wondering if the key management could be placed onto the client(s) instead of one of our own Security Admins - that way, technically, it would be completely impossible for our organization to ever have access to the data in a decrypted form. This would mean that for each client, there would be a column master key that they would store/manage and pass to us (encrypted). We'd use this to programmatically retrieve the column encryption key(s) relevant to their querying.

I've never worked around architectures involving confidential computing and am curious if the direction I am headed seems reasonable and/or if folks have any thoughts, advice, or could point me to any documentation involving key management strategies where clients house their own keys to access their data hosted by some other service.

tl;dr Does anyone know how to use SQL Server Always Encrypted (w/ Enclaves) with Customer Managed Keys? Is this possible? It seems possible with Cosmos DB, why not this? Does anyone have suggested for an alternative?

Improve this question
7
  • welcome - to clarify, "the requirement is that our organization can never obtain access to the decrypted data" excludes the infrastructure provider? ie. you're asking your clients to trust that, by configuring the 3rd-party infrastructure using the service provider's tools, that anyone in your org. will have no possible way to access any plaintext in the application? will you cede control of the browser-based ui code deployment also?
    – brynk
    Commented Dec 18, 2022 at 23:27
  • also, you've added the homomorphic- and e2e-enc tags to this q, however, as far as i'm aware the tech you're considering uses neither - does this imply that you're considering other options also?
    – brynk
    Commented Dec 18, 2022 at 23:40
  • @brynk We're asking clients to trust the cloud provider / services we utilize, but not us. The key seems to be that we'd also have a middle service in an enclave that would handle api requests from the client, therefore we'd never be able to intercept the data from an application standpoint (attestation etc). I looked into FHE but nothing seems viable outside of research yet, and e2ee seemed applicable but my missing piece is processing while remaining encrypted - hope this helps clarify
    – jackie
    Commented Dec 21, 2022 at 22:00
  • as far as i'm aware a browser-client cannot be cloud-hosted and interact securely with the hosted data store, without your org being able to intercept plaintext data; if the client app were on the desktop there's at least one option (in its simplest form) whereby data are encrypted client-side with the public key and then sent to the enclave, and only the enclave holds the private key- if both client and enclave exchange public keys, you can establish a shared secret using public-key cryptography
    – brynk
    Commented Dec 22, 2022 at 0:49
  • @brynk I think the problem you’re suggesting could be solved with an application running in a trusted execution environment. The problem is that if the data is encrypted in the database and is NOT on an enclave as well, then the TEE service would need to retrieve data, and then extract the subset of data that it needs. If the data could be secured and in an enclave (like sql server always encrypted in an enclave) then the TEE app could simply run w.e. sql query it needed and then process the data and return it to the client. I think this could be done, but don’t know how to deal w/ the db yet
    – jackie
    Commented Dec 22, 2022 at 4:02

1 Answer 1

Reset to default
1

There is a section describing options for extending the key management options. There might be some custom development but there seems to be a way to do it. https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/extensible-key-management-ekm?view=sql-server-ver16

Improve this answer
2
  • welcome - your answer would be improved by discussing how ekm could help the op with their particular use-case
    – brynk
    Commented Dec 20, 2022 at 18:23
  • Thanks I’m gonna check it out
    – jackie
    Commented Dec 22, 2022 at 13:14

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .