Architecting for Data Security: Page 4 of 8

Beyond logging are third-party log-analysis tools that attempt to interpret some of the results to give you a picture of what co-related queries are being posed. There are also rogue-database-detection tools that provide a picture of all the databases using standard communications mechanisms within an organization. Finally come database-extrusion-detection tools, the king of this class of products, which let administrators set policies on who can do what and alert admins when abnormal behavior occurs with a given account.

Some products in this last group can even be configured to stop a query from returning data sets. These are not policies, such as "user X has rights to column Y." Rather, they let you drill down to the level of "user X has rights to column Y for all rows where column Z has value AA"--thereby restricting access to only the data a user should be seeing to do his job. Of course, you could set restrictions too high and keep him from getting his work done (maybe he has a new assignment and needs more information). If this concern is larger than the litigation risk of a data leak, you can always set the product to notify you of the breach instead having it stop the transaction.

The Power Of The Network

Security functionality is increasingly being built into network devices. And it makes sense that the products seeing your traffic can control some transmissions.

You can put your databases on a subnet or virtual LAN, allowing connections only from those on the same VLAN. You'll need to do some careful architecting to make your Web servers visible to the outside world on one side and on the VLAN on the other. Of course, taking these steps will lock things down tightly--so tight that you'll have to maintain constant vigilance to ensure continued access for all the users that must be able to modify the database or its environment.