Database Encryption pros and cons
- When a table is queried for data in a non-encrypted column, no performance impact is seen. Since no decryption activity is taking place, no delay in readingwriting and no performance hit by system due to encryption software activity is seen
- When a query for a record with data from an encrypted field is performed, the overhead is minimal. Since the decryption activity only has to take place on the individual field or fields that are encrypted, there is much lower overhead.
- It can be used in conjunction with other controls to protect data from administrators. Separation of duties between security administrators and database administrators reduces the risk presented, by allowing a database administrator (DBA) unlimited access to the data you need to secure for a compliance.
- Requires tight integration with the database.
- It is highly invasive to the database design.To implement column-level encryption protection after the fact you will likely have to change the following:
- 1. Data type of the field being encrypted.
- 2. References to, and queries of the encrypted field(s) will have to be modified to limit access. Middleware and other applications that interact with the database will have to be comprehended and possibly reconfigured.
- Key management has to be well planned. If the encryption key is hardcoded into scripts, it defeats the security. Keys themselves must be stored in an encrypted state and access controls placed around them.
- Employing column-level encryption can lead to a false sense of security. Merchants and service providers who perform batch processing will commonly end up storing sensitive data in flat files. Additionally, sensitive data is often found in debug and transaction logs.The column-level encryption does not protect this; only file-level encryption would. It has to be remembered that the column that the sensitive data is entered into may not be the only place it is stored. [Tony Bradley, PCI Compliances]
Trackback URL for this post: