Microsoft’s SQL Server product, like so many software products, can be vulnerable to unwanted actions that cause harm to organizations. The responsibility for making a SQL Server secure does not rest with a security team, nor a DBA, nor a network administrator. It requires people in all of these roles to take the appropriate steps. It also requires software developers to write applications that mitigate the risk of SQL Injection. Finally, it requires ongoing surveillance to ensure security remains strong.
—more—
Even if your SQL Server databases contain no sensitive data, you still must make sure that some security is implemented to prevent hackers from using SQL Server as a path to get into your operating system and other computers on your network.
The most common attacks you need to defend against are:
- Attempts to log on to the SQL Server directly, often using the account named ‘sa’.
- Attempts to use SQL Injection to run malicious queries in your database that might allow the entire server to be infected with malware.
- Attempts to exploit a known vulnerability in an unpatched SQL Server.
- Attempts to obtain an unencrypted backup to read sensitive data.
- Attempts to find credentials in code repositories such as github or on computers and servers in configuration files. These credentials are then used to access the SQL Server.
Other blog posts:
https://csharpdeveloper.wordpress.com/2020/05/05/sql-to-find-who-is-trying-to-hack-the-sql-server-you-exposed-to-the-internet/