SQL Security Practices for 2021

Whether you’re running an instance of open-source MySQL or Microsoft SQL Server, you need to be certain you have robust, high-quality security measures in place. This is extremely important for preventing malicious access to your database, particularly if sensitive or personal data is stored on your servers.

Essential SQL Server security best practices starts with a SQL Security Checklist. Like a pilot who goes through a checklist every time before takeoff don’t try to remember all you need to do, have a checklist. Like for example; tailor the Database Installation to your company’s business, keep it updated, Restrict Processes, Restrict SQL Traffic, use least privileges in assigning permissions, use strong passwords, audit the logs, secure the backups, protect against SQL injection attacks.

Data breaches from vulnerable SQL servers can lead to huge amounts of lost revenue, lost trust, penalties and fines for not keeping customer data safe. Encrypt all the data if you’re moving it to the cloud, as well as limit access and authorization. Trust your ISP, but verify your data is safe because new hacking techniques come out on the web daily. Ramson ware is only the latest problem that Database Administrators have to deal with and a good backup maybe the only thing that saves you.

1. Isolate your server. By keeping your server isolated, you help ensure it’s protected from other applications and services that might get compromised. Consider putting your SQL Server in a restricted DMZ network and allow access only to authorized traffic. The application server or web server should be the only thing communicating directly with the database, and malicious or unexpected connections can be prevented through isolation and restrictive access. Check and double check you firewall setting and log files.
2. Keep it lean and mean. All your systems should be kept lean. This means you should only install the necessary software and services and avoid turning on additional features or installing extra applications. By staying away from software or features you don’t need, you reduce the opportunities for attackers to exploit your server. In addition, check with your programmers about using third party off the shelf software. If you’re testing a features, test these 3^rd party apps and do so in a test or development environment, not in the production server. Also, make sure you turn off the SQL Server Browser, and any programmer back-doors when running a default instance of SQL Server. The Server Browser allows admins and authorized users to discover database instances over the network, and a back-doors created by a programmer could be left open for his/her convenience – turn it off, if you don't think an attackers will find it, think again.
3. Regularly update. Make sure all your SQL Server tools and applications are updated regularly. All security patches and updates should be tested in a development environment first then applied immediately. Sticking to a regular patching schedule and testing all patches for bugs and functionality before installation. It will save you from having to rollback or crashing your systems. In addition, have a change management process in place - PLEASE! Pick one, ISO, ITIL, Six-Sigma, NIST, or make up your own, but have something you can measure against.
4. Apply restrictions. The user who runs the database service can also access the filesystem, execute programs, and undertake other important tasks. MySQL runs under a dedicated user account with minimal permissions for accessing or dealing with the rest of the server. But on Windows installations, SQL Server is often run as an administrator account, which can allow full access when this isn’t necessary or ideal.

Instead, SQL Server should always be run as a local account—not an administrator—without administrator privileges. Restricting access for user accounts helps make sure a compromised data server or user account doesn’t compromise the rest of the network. Also restrict access to the server itself, by allowing only another server to connect to it and blocking all other database ports. Restrict SQL connections to specific IP addresses requiring access. Use antivirus and anti-malware software to prevent SQL attacks. In addition to firewall configurations which should be part of the monitoring process.

Follow the principle of least privilege when assigning accounts. Allow access to what users need to do their job and nothing more, also audit permissions in a timely manner. Steer clear of “ALL” grants in MySQL, and don’t allow SysAdmin roles when using SQL Server unless strictly necessary. Always think about how implementing application accounts will affect the resiliency of your server, and run tasks and procedures as a dedicated user with restricted permissions, rather than as a full-access admin. If a user needs escalated access temporarily to perform a task, remove the additional access once the task is completed.  

5. Manage logins. Set a strong password for the system administrator account or root user, especially if you have mixed-mode authorization enabled. You should also perform a regular SQL Server security audit, including login auditing, because people change jobs within a company and can end up having more access required. Repeated failed logins can indicate someone trying to access your server, and you can lock down those accounts before they make their way in. In addition, login auditing creates a record you can use later, to show you did all you could to ensure security. Be diligent about deleting or disabling logins after they no longer need to be used. If a login won’t be used for an extended time, such as a couple of months, you should delete or disable it, and then set it up again later when it’s needed.
6. Secure backups. Your backups have all the same data as your production databases, and thus need to be protected in the exact same way. This means applying the same protocols to your backups, including restricting access, using security measures, and reviewing and controlling who has access to your backup data. If your backing up to a cloud environment you might want to encrypt the data before you send it. You don’t want your ISP provider looking at your data. Moreover, most ISP use virtual server setups how days and NIST as recognized at least 41 major flaws depending on the Virtual setup depending on if it’s Type 1, or Type 2.

While controlling access to your backups is important, ensuring the security of your backup storage is also vital. That’s why it’s worth looking for an encryption/backup tools that best fits your needs.  There are many types of tools on the market that can help you streamline the backup process so do your homework on which one best works for you. Additionally, you might want to pick an encryption protocol that is strong enough to stand up to Quantum Computers. These systems are here now and will be able to break many encryption standards we now have in place. The only two types of encryption I have heard of that can with stand breakage in a Quantum world is the Elliptical Curve Cipher and the Vernam Cipher, but this is the future and its coming on fast. IS YOUR DATA THAT IMPORTANT?

7. Protect against injection. Make sure your database applications are set up to prevent SQL injection, and you have security tools in place to scan event logs and systems. One of the primary approaches to setting up your SQL Server to protect it from SQL injection is to use stored procedures. These have specific parameters and only accept certain types of code, so when someone tries to send malicious SQL queries, the queries aren’t accepted by the procedure and don’t return any useful information to the attacker. Moreover, test any interface you use or build for validation problems, because there are many other ways to wreak havoc on a system if one just wants to create mayhem and chaos.
8. Continuously monitor. Even if you take all the other steps above, your SQL Server could still be at risk. Your best hope is to find it before it happens and that means continuous monitoring. Discover and resolve the issue before it goes too far.