The final part of our Data Protection FAQ series touches on commonly asked questions about database column and field encryption. As data breaches are becoming the new normal, encryption is your last line of defense when everything else fails. The rest of the FAQ series is available here:
Part 2: Key Management FAQ
1. What is database column or field encryption?
A method that allows user to select specific information or attributes to be encrypted instead of encrypting the entire database file.
2. What kind of data can be protected?
Any structured data within the database that is considered sensitive such as Primary Account Number (PAN), NRIC, mobile number, patient info etc.
3. We already use file and folder encryption. Why do we need this?
While file encryption protect the database file (eg. MDF, LDF, DBF etc), database privilege accounts can still bypass the application to access sensitive tables and data directly.
4. Can I use the native database encryption tool?
Yes, but you will need to manage each encryption tool in silos since it is proprietary to its own database. It will be challenging to execute an enterprise data protection policy for all sensitive data. Many database products require license upgrade to higher product editions and separate modules to enable encryption which may prove costly.
5. How types of data privacy options are available for database?
Encryption, Tokenization, Masking and Anonymization.
6. What is Tokenization?
Tokenization is the process of replacing sensitive data, either fully or partially, with a randomly generated “dummy” or fake value.
7. When should I use Encryption and Tokenization?
Encryption is suitable for free text fields such as Name, Address etc while Tokenization can be use for formatted data such as PAN, NRIC, Mobile number etc.
8. Which is more secure?
Unlike encryption, tokenization is more secure as it does not require a crypto key. Hence, it cannot be reverse engineered if stolen.
9. Do I need to alter the database structure and data types?
No. Both encryption and tokenization preserves the format and size of the original data with no changes required to the database structure.
10. Can we restrict different type of users from viewing data?
Yes. You can set masking rules that will determine how user can view the data; in encrypted form, partially tokenize or displayed in the clear.
11. Will DBAs be able to access specific sensitive data in the clear after it is encrypted?
No, unless permission is granted. This can be executed in real-time without disruption.
12. What database can it support?
MSSQL, Oracle, MySQL, IBM Db2, Teradata, Exadata and Netezza.
13. Do I need to make changes to my application?
No. If the data is a primary index key, you may use API integration or an inline reverse proxy technology to avoid changes to application.
14. What is the performance overhead?
Minimal. The latency can be reduce to as low as possible with stateless technology and optimized processor resources.
15. Do we need deploy encryption in every system?
No. Only for data which is classified sensitive and on databases where it resides.