I was once a database administrator in charge of several SQL Servers hosting the databases of vendor apps. Right after taking the job, I began looking at things like backups and security. I was quite shocked to find that one of the most important SQL Servers in the firm had a blank sa password. I also found that the application was configured to use the sa account to connect to the database! It turned out that the software vendor had recommended this setup in their documentation, and the person originally setting it up at the firm had just followed this recommendation without question. After contacting the vendor, they confessed that they didn’t know what permissions their software needed, and this configuration cut down on support calls. Eventually, the company did change their recommendation.

The more secure a system is, the harder it is for legitimate users to access it. No one disputes that, but it’s critical to follow best practices like separation of duties and proper use of service accounts. Even if a company does everything right, nothing is guaranteed to be 100% secure.

One way that SQL Monitor reduces risk is by using the Base Monitor to collect and process the data. Nothing gets installed on the monitored servers which minimizes the exposed surface area. Of course, you must also provide an account with access to the instance for collecting data, but the documentation spells out exactly what permissions are needed so you can avoid using a privileged account. It’s also a good idea to use a separate, dedicated account for monitoring each server as well.

Security is hard work, and software vendors must do everything they can to ensure their software is secure.