- Newest
- Most votes
- Most comments
When it comes to column-level encryption, or field-level for that matter, there really isn’t a perfect solution in the market today. It’s all about making tradeoffs and determining what’s important for you.
As you found out, there are built-in solutions inside relational database offered by various vendors (commonly goes under the name transparent data encryption or TDE). In some sense, these are easy to use since it’s built into the database. On table creation, you specify which key should be used and the database takes care of everything for you. As you highlighted, problem is the key management. How do you grant access user/group to keys? Each database has its own way of doing that which may not be compatible with your organization’s security standard. It’s also difficult to port the ciphertext data and search on encrypted data is very limited. Other vendors have attempted to solve this by using deterministic encryption, which itself has issue (hint: it can leak data.)
On AWS, you have couple of options. You can pursue PostgreSQL with RDS and enable pgcrypto extension (see doc). You still have to deal with key management yourself but it does offer some level of transparency and portability in a sense that PostgreSQL is open source and you can run elsewhere. You can also use vendor provided TDE in DBs on AWS. The searching on encrypted data is still limited however.
Another way is doing client-side encryption; that is, doing encryption within your application then loading the ciphertext into database directly. You have the most flexibility here since you control the data. It’s portable in a sense that as long as you use the same client library to decrypt and encrypt the data. AWS offers AWS Encryption SDK that can help you with this. If you want searchability, then you may want to explore AWS Database Encryption SDK. It uses truncated hashes (beacon) as index to your encrypted data. Both SDKs integrate nicely with AWS KMS for key management and provide you with industry standard and best practices when it comes to cryptography implementation. Unfortunately, the Database Encryption SDK only supports Amazon DynamoDB today although it seems like team is exploring other DBs. The downside of client-side encryption is that as you expected it can be a lot of work (e.g., coding) and while it may work for transactional driven use case, it may not work for analytic purposes.
I hope this helped guiding your decision.
Hello,
I understand that you would like to know if there is any other solution that implements column level encryption on RDS SQL Server that is as efficient and transparent as the default database encrytion at rest.
Please let me inform you that as of today, There is no other solution that allows you to perform column level encryption with as much ease as using DB encrytion at rest such as TDE.
Unfortunately with the use of column level encryption, There are some compromises that must be made like managing keys, possible performance impact, searching and indexing encrypted columns is difficult as well etc.
Column level encryption can have high performance penalties if search queries cannot be optimized to avoid encrypted data.
[+]Column-level encryption on Amazon RDS for SQL Server https://aws.amazon.com/blogs/database/column-level-encryption-on-amazon-rds-for-sql-server/
Relevant content
- asked 3 days ago
- asked 10 months ago
AWS OFFICIALUpdated a year ago- AWS OFFICIALUpdated 9 months ago
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 years ago
Column level encryption in general cannot be transparent(else it will defy the purpose of column level encryption versus other wider scope encryption), it has impact on performance and limits some of the operations. None of the commercial or non-commercial databases provide column level encryption without a level of compromise.
Thank you Behrang. It cannot be fully transparent, but it could require from the user as little as labeling the columns that should be encrypted differently (as opposed to explicitely managing the keys and performing the encryption/decryption with code, as the linked solution requires). As for performance, the DBMS could create an index and encrypt it in the same way as the default DB encryption at rest does, just with different keys. However, I admit that the use case is tiny and I would not be surprised if no vendor offer it. But I want to be sure.