As most DBAs know, security of data is one of the most difficult yet important tasks of maintaining a large estate of databases. It has kept more than one administrator up at night worrying about potential threats and pitfalls. With the growth of the information economy, not only is most information stored in databases, the value of that information has grown. As with anything with
value, the threats to security increases at a direct correlation to its worth.
If you are handling a great deal of sensitive data, you already know and must deal with this on a daily basis, not only due to the necessity of maintaining business integrity, but also due to potential legal pitfalls if sensitive information were to leak. It doesn't take much browsing of technology or business news to hear or read about some large company that leaked tremendous amounts of user data, and have been subjected to millions, if not billions of dollars of losses.
Even if the data you store is not particularly sensitive in nature, this does not leave you invulnerable. Perhaps this data is integral to running your business? What if you lost access to this data? Even if you have backups of everything, the sheer amount of time that gets lost repairing data, can become astronomical in a short amount of time. And on top of this, nefarious users may not even care; they may break in just for the “fun” of it. No matter what type of system you run, security is a serious concern.
Confidence in the security of your database operations is fundamental to your business.
Some of the major vulnerabilities to databases include (but are certainly not limited to) default/weak passwords, SQL injection, improper user security, DBMS packages with too many features enabled, and more.
Before you start to panic, while there is no failsafe solution to protecting the integrity of your databases, there are quite a few steps that you can take to reduce the likelihood this sort of disaster.
Keep Sensitive Databases Separate
As any black-hat hacker knows, all it takes is one weak spot in a system to get in. Due to this, never assume that all of your security should exist externally. If someone malicious (or even accidentally gets in, they should run into more walls.
If a particular database contains very sensitive information, it should be quarantined from all other systems. If it's not possible to keep this data completely offline, make sure nothing else can reach it with any ease.
Regularly Monitor
Keep a record of your database inventories, and regularly monitor behaviour on each of them to determine if there are any anomalies in their behaviour. Having a good system for keeping track of statistics and to be able to flag unusual activity will go a long way to spotting any potential breaches.
Role-Based Access Control
There's a fundamental truism associated, not just with databases, but all systems: the most vulnerable part of any system is the human component. For a multitude of reasons, including inattention, forgetfulness, laziness, or even outright malicious intent, people are just not as reliable as we'd like them to be.
For this reason, do not give admin rights to all DBAs as default, but create roles and assign roles to DBAs. It is easier to revoke role access than changing admin passwords all around. Also, start off with the assumption that your DBAs only need minimal access. It's a lot easier to deal with frustrated users than it is to deal with putting out a fire after the barn has been burnt down.
Don't let your developers have administrative power over users. The temptation to simply “test” a piece of code has a way of accidentally opening security holes, and the creation of “temporary solutions” that never get patched.
You should also consider giving your developers access only to views instead of tables. If for some reason a hole gets left open, this will reduce the likelihood of actual data destruction.
Centralise Access Control
If you are running on a Windows network, you have the ability to use Active Directory to handle access rights and roles. Use a central login point. Let command console connect through the firewall to the management server, and then connect from there to the instances.
Try to place management servers in subnets behind the firewalls, so you do not have to open all firewalls to allow connections directly to all instances.
Encryption
Don't forget that even secure connections like SSH have vulnerabilities at their endpoints. Encrypt all connections where possible. If for someone is sniffing at your database connections (the larger you are, the more likely this is occurring, and for extremely sensitive data, this should be a given), make sure that any packets that are intercepted are encrypted, preferably using 256-bit which should
be enough to prevent most brute-force attacks.
Software Security
While, as mentioned before, you shouldn't depend on software to handle the security aspects of your databases, it's generally a good idea to enforce software security. It never hurts to have extra layers, so if you have developers accessing, or you are developing for your databases, consider using stored procedures and transactions with fallbacks wherever possible, and if software must access the
database from a public interface, make sure your data packets are being stores as objects. In other words never allow inputs to directly access your database itself. Again, as mentioned before, use views and not direct access to tables.
Stay Up To Date
Keep abreast of all security news, particularly as it relates to your databases. It's a good idea to regularly check to see if there are any updates of any sort, not only as it applies to your database platforms themselves, but also with any software or connections you use for managing your systems. When an update does come through, do it immediately lest you be vulnerable to zero-day exploits.
Conclusion
This is really only a cursory overview of approaches to take when maintaining the
security of your databases. As any security professional will tell you, there is no such thing as a completely secure system. However if you can take a few steps to make the effort getting in much more difficult than the payoff, you will have thwarted most types of vulnerability.
