Manage Learn to apply best practices and optimize your operations.

Database security: Who should have access?

The only users who should be allowed full access to any data store should be your system administrators. What about everybody else?

As options have increased for midmarket companies to house their data, so, too, have options for securing their...

databases and data stores. Once the preserve of only large companies, a range of data storage options are now available and within reach of companies of all sizes.

Databases are rarely seen by users and are usually hidden behind the scenes as part of inaccessible back-end systems. Yet they're the unsung heroes of applications, particularly Web applications, where they're at the heart of what makes most websites dynamic. Without them, modern e-commerce wouldn't be possible.

Protection of data in databases and other stores is also part of compliance with regulations such as the Sarbanes-Oxley, Gramm-Leach Bliley and Health Insurance Portability and Accountability acts, and industry guidelines like the Payment Card Industry (PCI) Data Security Standard.

Access control is key

The pillars of database and data storage security are access control, encryption, monitoring and configuration or architecture. For midmarket companies, this boils down to two things: a combination of best practices and security tools. Most database and data storage products have some sort of built-in security tools, but other tools can be added, as needed, to enhance security.

Access control is fundamental. In general, the only system administrators should be allowed full access to any data store. They need full access to add user accounts and maintain systems.

Other users should be granted access based on the principle of least privilege, meaning allowed access to only the data they need for their job functions and nothing more. They shouldn't have full run of the database, and write access -- the ability to add, change or delete data -- should be restricted on the same principle. For most users, read access may be sufficient.

Although user accounts can be added to databases for access, ideally access should be controlled through your existing identity and access management platform. That means tying user access to profiles in Active Directory , Lightweight Directory Access Protocol (LDAP) or whatever directory service you use.

Highly selective access

Access to mass data storage used for backups and disaster recovery should be even more restricted, since these stores aren't used for routine day-to-day work. Access should be through only a single interface that transmits data automatically from your systems and not from individual users.

Customer-facing websites should never have direct access to any company database. Access should be through only the middle tier of the Web application, and then only through a guest account with limited access. Don't use the default "sa" account built into most databases, which has powerful administrative privileges. Create a special limited account and put its user ID and password in server-side property files that are inaccessible from the website. Such user IDs and passwords should never be hard coded into the application where they can be found by hackers' prying eyes.

An inside job

Another concern with database access is malicious use by your own employees, the so-called insider threat. This is where monitoring comes in. All access to databases and other data storage should be logged to determine who accessed the stores and what they accessed. One such tool is StrongBox DBProtector from Crossroads Systems Inc. DBProtector is a network appliance that checks every SQL request to the database and provides alerts of malicious activity.

Another product that provides both access control and logging facilities is DataFort from Decru. DataFort meshes with Active Directory and LDAP to restrict access and can use smart cards to provide even further protection for back-end data storage.

SecureSphere Database Security Gateway from Imperva Inc. is another leading product for monitoring access to databases. SecureSphere is part of a suite from Imperva that also includes its well-known Web application firewall, a natural fit since websites and applications are frequently sources of malicious access to databases. SecureSphere works through user profiling and vulnerability assessments of databases.

Guardium Inc. offers a software suite for protecting databases and back-end data stores. It also integrates access controls, auditing, logging and monitoring. The product works with other appliances, like DataFort, to provide encryption.

Of course, besides these specialized tools, traditional firewall logging and intrusion detection systems can also be used for monitoring database access. Though crude and not as thorough as other tools, they may do the trick for cash-strapped midmarket companies.

Compliance escalates risk

The next big issue is encryption, which, like access controls, is a compliance issue. Under PCI, for example, credit card information must be stored encrypted. The standard is clear on this point.

Here, again, there are a number of tools available for the midmarket. But before embarking on a costly encryption program, make sure to do a thorough risk analysis of the data being stored. Is it sensitive customer data that, if exposed, could open the company to regulatory violations, legal liability or the theft of customer identities? Or is it marketing data used for sales modeling that can't be traced back to individual customers? The first will require encryption. The second just standard security procedures like database hardening and access controls.

The pillars of database and data storage security are access control, encryption, monitoring and configuration or architecture.

Ideally, as part of your security program, higher-risk data should be segregated so it can be given a correspondingly higher level of protection. A tiered storage approach can avoid putting costly controls on systems with mixed high- and low-risk data, just to protect the high-risk data.

For back-end data storage in particular, the key is to encrypt data in transit to the data store. This could be done through an encrypted channel, such as a virtual private network. In this area, DataFort again offers a product geared toward the midmarket.

Another product from CipherMax Inc. uses a high-speed encryption engine at 256 bits for both storage area network management and encryption in one appliance. The Sentio HD 8000 series from Revinetix Inc. also has encryption capabilities with built-in network-attached storage capabilities.

Besides tools, midmarket companies can also follow basic rules for architecting their systems to protect data storage assets.

First, make sure all databases and stores are behind a firewall. That sounds obvious, but that means behind the inner firewall of your demilitarized zone (DMZ). Databases should never be inside a DMZ, where they're more exposed to malicious attacks from the Internet.

Second, where possible, don't double up your databases on servers. If it's in the budget, each database should be on its own server, where it can be protected based on the risk level of its data.

Third, in Web applications make sure developers add code to filter and sanitize all user input. This is meant to prevent SQL injection attacks, which can allow malicious access to a database. In addition to secure Web coding practices, like those in the Open Web Application Security Project, a Web application firewall that blocks SQL and other injection attacks might be in order.

With these range of options, a midmarket company should have no problem securing its databases and back-end data stores. It just has to determine what data it has, where it resides and its risk level.

About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP specializing in Web and application security, and is the author of The Little Black Book of Computer Security, Second Edition, available from Amazon.com. He hosts a radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at www.theitsecurityguy.com.

This was last published in August 2008

Dig Deeper on Small-business IT strategy

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

2 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Well, that's only true if your system admins are willing and able to provide database services to the development teams. That is not the case at my organization - developers and others have their hands in databases daily. We don't have much of a choice, because there is no one else to perform tasks for us.
Cancel
The danger here is that you're putting a system in place without safeguards and redundancy. What happens if one sysadmin goes on maternity leave or gets in a car accident or has an anvil land on them? You need some provisioning in place so more than just your top tier folks can access everything. Something like dual security that banks use might be better. One set of people has keys, one has passwords, the other has different keys. A coordinated effort would be necessary to breach the system, but in case of emergency, teams could come together to access data.
Cancel

-ADS BY GOOGLE

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close