Database security and protection is receiving more attention and budget from organizations with the steady increase in data breaches and the resultant regulations designed to keep them at bay. However, a better understanding of database security is still required.
Enforcing database authorization requires technical expertise and elevated privileges. Many aspects of database security require different utilities, system procedures, and commands to implement. When users require access to multiple databases on multiple servers distributed across different physical locations, database security administration can become quite complicated. The commands must be repeated for each database, and there is no central repository for easily modifying and deleting user security settings on multiple databases simultaneously.
At a high level, database security boils down to answering four questions:
- Who is it? (Authentication)
- Who can do it? (Authorization)
- Who can see it? (Encryption)
- Who did it? (Audit)
Strong authentication is the cornerstone of any security implementation plan. It is impossible to control authorization and track usage without it. Before authorization to use database resources can be granted, a login needs to be established for each user of the database management system (DBMS). The login will have a password associated with it such that only those who know the password can use the login ID. Some DBMSs use the operating system login ID and password as the DBMS login ID and password; others require an additional login ID and password to be created specifically for database access and security.
Regardless of the type of ID, passwords should be changed regularly to make it difficult for hackers to gain access to the DBMS surreptitiously. When a DBMS user no longer requires access to the DBMS or leaves the company, his login should be dropped from the system as soon as possible; however this can be a complicated task. Some systems forbid a login to be dropped if the user owns any database objects. Therefore, it is wise to limit the database users who can create database objects to DBAs only, especially in a production environment.
Authorization to the database system is managed using GRANT and REVOKE statements to control which users have access to which objects and commands. Privileges are granted and revoked from logins enabling access to data, database objects, system commands, programs, etc. As an alternative to granting access to a database user, authorization can be granted to PUBLIC, thereby allowing anyone who can log in to the DBMS that particular authority. It is generally considered to be a poor practice to grant privileges to PUBLIC.
Another important issue is the avoidance of SQL injection attacks. SQL injection is a form of web hacking whereby SQL statements are specified in a web form to expose data to the attacker. Appropriately using well-
designed query language interpreters and coding applications can help to prevent SQL injection attacks. Additional techniques for halting SQL injection attacks include using static SQL instead of dynamic SQL, proper validation and testing of user input, enforcing appropriate limits to prevent buffer overruns, and avoiding the concatenation of user input to SQL.
Of course, we have only scraped the surface in talking about database security practices. There are many other techniques and methods available for improving the protection of the vital corporate data stored in your databases. Additional techniques include the use of the following:
- Label-based access control to provide a more granular security scheme, specifying who can read and modify data in individual rows and/or columns
- Roles and groups to assign privileges to groups of users instead of one-by-one
- Views that omit sensitive columns or rows of data
- Stored procedures that are coded to access only row- and/or column-level subsets of data
- Encryption (at rest or in transit) to transform data, rendering it unreadable to anyone without the decryption key
Finally, be sure to plan your database auditing requirements. Auditing enables authorized users to track the use of database resources and privileges. When auditing is enabled, the DBMS will produce an audit trail of database operations, including what database object was impacted, who performed the operation, and when it occurred. Depending on the level of auditing supported by the DBMS, an actual record of what data actually changed may also be recorded.
The bottom line is that more attention and resources need to be expended on database security and protection in this day and age of digital transformation.