Everything You Need to Know about SQL Server Security

By Gaurav Belani

By Gaurav Belani on

August 17, 2020

SQL server security has always been a pressing concern even for the most seasoned SQL DBA. Regardless of its version, the SQL database is constantly under threat as it holds sensitive data malicious hackers want access to. Source Being easy to implement and potentially dangerous, SQL injection (SQLi) attacks are the hacker’s favorite choice. The State of the Internet/ Security report reveals that SQLi alone accounts for 77 percent of all application attacks in 2019 where hackers insert arbitrary SQL into the application database query to destroy it. SQL Attack Chart

Source Security of SQL Server environments is considered to be among database administrators’ prime responsibilities. Fortunately, SQL Server is designed to be a secure database platform. It holds several features that can encrypt data, limit access and authorization, and protect data from theft, destruction, and other types of malicious behavior. Yet, innumerable organizations continue to experience SQL database vulnerabilities, SQL injection attacks, brute-forcing SQL credentials, and other attacks launched to manipulate data retrieval. The threat to SQL servers is ubiquitous nowadays. But that doesn’t mean we cannot do anything about it. To protect the organization from such attacks, DBAs and security professionals should understand the potential threats to the database management platform and take proactive steps to mitigate the security risks.

SQL Server Security Best Practices

SQL Server is one of the most popular data platforms in the world. It is used to run an organization’s critical operations and processes. As a result, it offers a variety of security tools for protection against malicious attacks and to secure SQL Server instances. However, using the default security settings can leave security gaps, leaving the network vulnerable to attacks. Here’s a SQL server security checklist to effectively sever the threats to your database platform. 1. Run Multiple SQL Server Security Audits Regular server security, login, and permission audits are a prerequisite for preventing potential attacks and to aid in any forensic analysis of a possible data breach. However, an enterprise-level SQL Server security audit isn’t merely a security investment, it has become a legal requirement following the new legislation like HIPAA and GDPR. To begin with, define what you want to audit. You may want to monitor the following in your server audits.

User logins
C2 Auditing
Common Compliance Criteria
Login Auditing
Server configuration
Schema changes
SQL Server Auditing
SQL Trace
Extended Events
Change Data Capture
DML, DDL, and Logon Triggers

A routine audit can help in improving the health of your database and network. For instance, if a query won’t run an audit can point out to the underlying reason. Does it point to a security threat? Is it due to an error with the SQL order of operations? Similarly, repeated failed logins to the server, changes and deletions to restricted database objects, and changes to configurations and permissions indicate that someone is trying to access your server. Regular security audits (including login auditing) can help you spot these signs of potential attacks on the server and arrest them before they cause significant damage. 2. Have a Strong Password Policy All database administrator accounts must have a strong password that helps combat brute-force attacks.

Include a minimum of 10 characters, including numbers, uppercase and lowercase letters, and special characters. You can also use passphrases consisting of a minimum of 15 characters with both letters and numbers.
Avoid easy-to-guess passwords like ‘password,’ ‘qwerty,’ or names and birthdates of your spouse. Also, refrain from using the same password for multiple systems.
Change the password periodically.
Use password management tools with a strong master key to store multiple passwords.

Want more tech news? Subscribe to ComputingEdge Newsletter today! 3. Keep It Lean Having unnecessary software and extra applications allows hackers to exploit your SQL database server. Further, multiple applications are tough to manage and soon get outdated. We all know how outdated or unpatched applications introduce security holes in the system, inviting attackers to run unauthorized code on a SQL server via an authorized path (SQL injection). Limit the installation of the SQL database components and features to the ones that are necessary for certain tasks. This will reduce the resource utilization by the database and simplify the administration, thus minimizing the security risk. 4. Apply the Principle of Minimal Privilege All of us are aware of the principle of least privilege, a common phrase used in the information security and IT fields. It states that an account should be given only those privileges (in this case, minimum permissions and system rights) needed for it to function properly. Determine which accounts should be permitted to run which database services based on this principle. Better still, assign a separate account to a specific service. That way, if one service gets compromised, the others will be able to tighten the security further and continue to operate normally. Here are a few accounts you can have for SQL server services.

Domain user account - This is the most commonly used account type to run SQL server services as it’s quite secure owing to the absence of administrator privileges.
Active directory managed service account - This account is safer than a domain user account as one cannot log on to the server with this account and doesn’t need to manually manage the password resets.
Local user account - This is usually a good choice for non-domain environments.
Local system account - These accounts have extensive privileges and unrestricted access to all local system resources. The local system account has permissions that a SQL server doesn’t need, hence you can avoid using them to run services.
Network service account - It has fewer privileges than a system account but has more access to network resources and objects than members of the users group. Avoid using this type of account whenever possible.
Virtual service account - This account is similar to the AD managed service account but can be used to manage services without a domain. In technical terms, it’s like a built-in network service account, having its unique identifier. This makes virtual service accounts ideal for SQL services.

5. Have a Robust Database Backup Strategy in Place Always take backups for your SQL database and save it in different locations outside your network. Count on third-party SQL recovery tools to tackle SQL database issues like corruption and inaccessibility of database files. What’s more? Remember to encrypt the SQL server database backups. Your backup has the same sensitive data as your database; hence, it needs to be equally protected. You don’t want to land up with a corrupt backup files. So, apply the same protocols to them including restricting access, using security measures, and monitoring/controlling access to the backup data. 6. Use a Suitable SQL Monitoring Tools A solid SQL monitoring tool should be able to scan the processes of a database application and monitor the changes in database server settings. It should promptly detect errors, sessions, and individual SQL statements that allow access to sensitive information. Not to miss, the monitoring tool itself may pose a security risk because of the sensitive nature of the system it monitors. Therefore, the tool should use modern security practices, allowing you to maintain the long-term health of your database and network. Deploy a suitable SQL server monitoring tool to protect your server from frequent attacks, address performance issues, and keep your network up and running. Summing Up SQL Server offers several features to support and secure database applications. Yet, it’s impossible to predict what security threats may emerge on the go. Therefore, it’s wise to know the best practices and common security considerations that go into securing your database applications. The information shared above will guide you in building a strong SQL server security strategy, enabling you to counter the common security threats. -------- About The Author: Gaurav Belani is a senior SEO and content marketing analyst at Growfusely, a content marketing agency that specializes in data-driven SEO. He has more than seven years of experience in digital marketing and loves to read and write about education technology, AI, machine learning, data science, and other emerging technologies. In his spare time, he enjoys watching movies and listening to music. Connect with him on Twitter at @belanigaurav.

Everything You Need to Know about SQL Server Security

By Gaurav Belani

By Gaurav Belani on

August 17, 2020

SQL Server Security Best Practices

User logins
C2 Auditing
Common Compliance Criteria
Login Auditing
Server configuration
Schema changes
SQL Server Auditing
SQL Trace
Extended Events
Change Data Capture
DML, DDL, and Logon Triggers

Include a minimum of 10 characters, including numbers, uppercase and lowercase letters, and special characters. You can also use passphrases consisting of a minimum of 15 characters with both letters and numbers.
Avoid easy-to-guess passwords like ‘password,’ ‘qwerty,’ or names and birthdates of your spouse. Also, refrain from using the same password for multiple systems.
Change the password periodically.
Use password management tools with a strong master key to store multiple passwords.

Domain user account - This is the most commonly used account type to run SQL server services as it’s quite secure owing to the absence of administrator privileges.
Active directory managed service account - This account is safer than a domain user account as one cannot log on to the server with this account and doesn’t need to manually manage the password resets.
Local user account - This is usually a good choice for non-domain environments.
Local system account - These accounts have extensive privileges and unrestricted access to all local system resources. The local system account has permissions that a SQL server doesn’t need, hence you can avoid using them to run services.
Network service account - It has fewer privileges than a system account but has more access to network resources and objects than members of the users group. Avoid using this type of account whenever possible.
Virtual service account - This account is similar to the AD managed service account but can be used to manage services without a domain. In technical terms, it’s like a built-in network service account, having its unique identifier. This makes virtual service accounts ideal for SQL services.