DBAs understand how critical and important security is but due to other administration priorities, it can often take a back seat. When working inside an enterprise, the CIO’s are constantly worried about data theft and how to secure their environments. Most of the security vulnerabilities are caused by people working inside the organization and it is critical for a DBA to secure the environments. In this post, I will talk through 3 of the most critical security concepts that every DBA must know when working with SQL Server. In fact these are so generic that these apply to any environment, any database and any application.
Securing Data, Log and Backups
Malicious users who obtain access to database files can attach these files to other instances of the Database Engine. In addition malicious users who can access the SQL Server binary files can cause damage and denial of service. Hence it is critical to limit the access (by using file system permissions) to the Database Engine files (.mdf, .ndf, .ldf files), and also access to the Database Engine binary files (sqlservr.exe in the binn folder) must be limited by file system permissions.
Protecting SQL Server backups is a security measure to prevent the access to these backup files to any malicious user. Access to the backup folder needs to be limited only to service account, database administrators and backup operators, so that these backups cannot be copied locally and taken offline. SQL Server also supports password protection for backup media and backup sets.
Try to explore the option of using database backup encryption techniques introduced with SQL Server 2014. This allows us to encrypt the backups using a certificate or a key which can be secure within our environment.
Object Access
Know how different applications are residing inside your production instance. How are applications talking to each other? What is the access pattern for each of these applications? How can users access data from a different application? How is the deployment strategy for each app? How does a potential upgrade of applications happen? All these are critical questions a DBA must know. The secure practices in SQL Server Object Access can be classified into the following practices:
- Public server and database roles granted few (if any) permissions.
- Grouping similar database objects together into the same schema.
- Managing database object security by setting ownership and permissions at the schema level, when possible.
- Granting users/roles needed access to only required objects.
- Distinct owners for schemas instead of having all schemas owned by dbo.
- Granting access to users through SQL Server roles.
Auditing
SQL Server provides several features that can be used for auditing activities and changes on a SQL Server system. These features enable functionality to implement a defense-in-depth strategy that can be tailored to meet the specific security requirements of production environments.
SQL Server Properties: Server properties are used to audit login failures on all instances. These audit records are stored in windows application log. However these application logs are seldom reviewed proactively or periodically.
Audit Events in SQL Server Profiler: You can use SQL Server profiler to audit DML events/activity on the SQL Servers/instances. Even better, with appropriate filters we can also use Extended Events for lightweight logging.
Tips: Continue to practice auditing login failures on all SQL server instances. In addition to that we suggest the following practices.
- Audit successful logins in addition to unsuccessful logins for critical applications.
- Periodically review the windows application logs and check for any login failure patterns to see if there is an attack.
- Use SQL Server Audit to monitor DML activity instead of using SQL Server profiler on production servers. The advantages of SQL Server Audit over SQL Server trace include the ability to provide centralized storage of audit logs and integration with System Center, as well as noticeably better performance. Perhaps most significantly, SQL Server Audit permits fine-grained auditing whereby an audit can be targeted to specific actions by a principal against a particular object.
By integrating Audit logs with reporting services and SSIS, a centralized audit reporting system can be easily built for a quick overview on overall audit activity.
These were some of the top best practices that I thought were worth sharing. As a DBA, try to internalize them and in future we will try to explore other aspects of security. Do let us know your thoughts and if you have done any of the above in your production environments.
Next Steps
Learn more about Embarcadero DBArtisan in this short video, and try DBArtisan for free.