Key Takeaways from Protecting Relational Databases

In this, our final post on relational database security, let’s review some key topics from the series, which we trust has helped you understand—if not implement—best practices for securing your relational data.

Key Takeaways from Protecting Relational Databases.pngHere are the top takeaways, or a quick summary of each post in the series:

  • Form does matter, especially in relational database design. By enforcing a minimum of third normal form (3NF), we get sensitive data out of primary and foreign key columns. This is absolutely necessary to avoid encryption key rotation on these columns, which would otherwise destroy relational integrity.
  • We have multiple choices for database protection technology. The best choice for us depends on a number of factors. In general, the more databases we use, the better protection at the data item level works for us.
  • Eliminating the need to re-identify data items is the key (pardon the pun) to maintaining lightning fast performance in query execution. By partially protecting data, for example leaving the last four digits of an account number in plain text in an otherwise encrypted field, we can perform customer verification directly on desensitized data.
  • Sometimes adding alternative column encodings can go a long way towards increasing the usability of an encrypted database. We looked at loss-full encodings, such as Soundex coding for names and storing birthdates as quarter and year only, as a method of increasing analytical ease of use while still maintaining security.
  • Searching on discrete sets—as opposed to inequalities—allows us to make more use of data protected at the field level. Not to mention the performance benefit of avoiding column decryption to find a “needle in the haystack” when direct data queries are much faster.
  • Expressing these techniques in practical use case examples makes it easier to understand more efficient ways of using encrypted data. Which still provides us business value while simultaneously eliminating any benefit to hackers who might steal our data.

We started off this series by calling attention to some headline-gathering data breaches that could have been non-events had the source databases been protected, as well as noting that hacks are still lucrative. So there is incentive for us as data custodians to implement relational database security as soon as possible.

That’s it for this blog series. Meanwhile what are your thoughts on relational database security? Have any articles in this series helped you secure your organization’s data? If you have a thought on these matters, please leave a note in the comments section below. And thanks for contributing your thoughts on this series!


Data security and encryption