Image courtesy of Shutterstock
Do you feel confident about the security of your database environment? Because databases may contain sensitive or regulated information, critical applications or stored functions, ensuring database security is undoubtedly a number one priority. And with a number of users viewing and accessing the data, how about all those “who-what-when-where” details that might be hidden from your radar?
The increasing pressure of compliance regulations and security policies makes the deployment of high-level database protection a must-have for any organization. However, according to David Monahan, research director of Enterprise Management Associates, Inc., in almost 90% of cases, unnoticed changes to database configurations result in outages and security breaches.
For those looking for ways to advance database security, here are 5 SQL Server best practices to maintain database security and streamline compliance.
Tip 1: Minimize SQL server exposure and do not leave any “open doors”
You can take the first step to minimize security risks for SQL Server even before your installation is complete and fully configured. Install only required components. In the first place, when configuring your installation, remember the principle of least privilege. Running SQL Server services under an account with local Windows administrative privileges is not a good idea. In case a violator gains possession of such an account with extended privileges, the probability of unwanted outcomes increases. The risk of overall exposure can be minimized if you use a domain account with minimum required privileges instead.
It stands to reason to avoid using the default settings. Rename or disable the default system account for server administration after installation. The same is applicable to naming SQL Server instances instead of using the default instances. Changing the SQL Server port number, which is 1433 by default, will also help you minimize service and data exposure, and so will hiding SQL Server instances and/or disabling the SQL Server Browser service.
Also, do not leave anything unattended. Disable and remove everything you do not use,any unnecessary services or databases from production servers, for example, and sample or test data you may have used to verify successful installation.
Tip 2: Control who can access SQL server and how
When you plan a user and service accounts authentication, be mindful of establishing user accountability and avoid misuse of privileged accounts. When you can choose between integrated (Windows) authentication and built-in SQL Server authentication, choose the first option whenever it is possible. Integrated authentication encrypts messages to validate users, while built-in authentication passes SQL Server logins and passwords across the network and keeps them unprotected. If you have to use built-in SQL Server authentication for application compatibility, make sure you have ensured a strong password policy.
Again, never use shared user accounts for administrators. Your SQL Server administrators should have dedicated accounts with no administrative privileges in other systems. Also, make sure that each admin is using a personal user account. The same recommendation works for applications. Creating separate service accounts with descriptive names for each application that works with SQL is among security best practices, too.
Note: To keep an eye on future changes and avoid account misuse that results in security incidents, consider deploying change auditing to monitor SQL Server and track unauthorized or malicious changes to system configurations.
Tip 3: Plan database ownership and data security in advance
Start by identifying the needed level of protection and encryption for each database. This is an important issue when you have to deal with securing sensitive data, such as credit card numbers or patient health information, which is also a staple requirement to meet PCI or HIPAA compliance regulations. Having ensured complete visibility into what is happening across your databases, you strengthen security and streamline compliance by reducing the risk of missing suspicious activities.
When creating a database, make sure that you get all the necessary information about data confidentiality. Do not forget to assign distinct database owners, meaning that the same login should not be applied across all databases. In order to mitigate future risks, establish the same process for new database requests and approvals as well as for database retention.
Note: Aligning security efforts with business needs and risks helps to identify and adequately protect sensitive information. Involve the business stakeholders to establish processes around database creation and tracking changes.
Protecting database files on disk from unauthorized access and copying in real-time is highly recommended and can be done by leveraging database-level encryption with the Transparent Database Encryption (TDE) feature. In case you need to keep data encrypted in memory (until it is actively decrypted), and/or if you need to give granular users specific access to certain column or cell values, it is recommended that you use cell-level encryption.
Tip 4: Regularly patch your SQL servers
The list of security best practices would not be complete without mentioning the need for proper patch management. Because attackers are actively looking for new security flaws in IT systems, and new malware and viruses appear every day, establishing proper patch management of your SQL servers should be among your mandatory security practices.
A timely deployment of current versions of SQL service packs, cumulative updates and critical security hotfixes will advance the stability of database performance. It is also necessary to pay attention to regular updating of the underlying Windows Server operating system and any supporting applications, such as antivirus applications, as well.
Tip 5: Keep track of what’s going on
Finally, establishing accountability in many respects means staying up-to-date with configuration changes and user activity. This is an ongoing process of maintaining the actual state of security policies to make sure that all changes are authorized and documented.
Note: Always keep in mind that security is not a state – it is a process. Monitoring, alerting and reporting on changes must become a part of the entire data lifecycle.
Native audit logs allow you, to some extent, to check recent activities and changes affecting security, but obtaining an older view of changes made far long ago can be a challenge. Much excessive information is saved, and as a result logs very often do not contain the required data. On the contrary, change auditing can help detect unauthorized and malicious changes at early stages or show you the historical data, all of which help prevent data breaches and system downtime.
Security Requires a Thoughtful Policy
Now, as this article has helped you have save time searching for top database maintenance tips, use this time wisely and do not forget that database security requires a thoughtful policy. Your goal is to instantly know who did what, when and where in your database environment. Try implementing continuous auditing to protect your database environment against internal and external threats by ensuring complete visibility across your databases.
About the author
Michael Fimin is CEO of Netwrix, a provider of change and configuration auditing solutions for optimizing organizational security, governance and compliance.