|
|
|
|
|
Database Scanner 3.0.1 1 2 3 4 5 6 7 8 9 10 The SQL Server System Integrity tab is the one that I have the biggest problem with. If you change nothing else, I can guarantee that you will make several changes to these settings. Allowing replication will depend upon your environment as will web tasks. I've never put web tasks into a system simply because almost no one seems to know that capability even exists and there are much better solutions out there. The other 2 features I completely disagree with are tasks and alerts. I have to run backups. I have to run DBCCs. I have to do other administrative processes. If I don't allow tasks, then that means I am forced to move this out into an external application which then has to log into the SQL Server instead of simply running the processes internally. Alerting is a vital part of any environment. I fail to see how the alerting mechanism or tasks can possibly cause a security breach. I change both of these settings to allow tasks/jobs and alerts. While requiring encryption of objects is nice, I think it has been proven that the encryption algorithm is so weak it is trivial to decrypt those objects. This means encryption is a moot point. If really want to protect the source code, don't allow users access to the system tables. Auditing of logins is a very good idea. I don't audit successful logins. It would be a full time job for someone to wade through the several thousand succeeded logins on a daily basis. All I care about is multiple failed logins which could indicate an attempted hack of a login. Not allowing trace flags makes doing some things incredibly difficult and with 6.5 servers there are trace flags that are required to be run so I turn this option on. The backups have ZERO place within a security profile. They are used to recover from a security breach. Not performing backups every x number of hours is in no way a security breach and should not be treated as one. I set both the backup and the tran log options to the maximum value that the field will accept so I don't have to deal with extraneous security breaches that have nothing to do with security.I do understand why it is there, because you would use a backup to recover from a serious security breach. Backups aren't the province of security audits, IMO, and are best left to normal operational practices. Additionally I run many servers that would never get a backup, but still need to be secured. These are consolidation, staging, and reporting servers. The server needs to be secured just as any other server, but I won't perform backups on these servers. I'll leave it up to you. Maybe I'm being a little too hard on this one. Afterall, it does say system integrity and not security. Any opportunity that I can use to hit someone over the head about doing backups, I'll take. I guess if they are truly going to look at problem settings and configuration options, including security settings, then I'd probably add a couple dozen options to this section to scan for.
The network protocols will probably need adjusting in just about every environment. I've only been in 2 clients that ran multi-protocol and neither of them were any of the financial or government clients that I've had that required extremely high security. The basics here are that the less routable a protocol is, the more secure it is. Additionally, anything that allows you to encrypt the data between the server and client provides an extra security level.
|
All content on this site, except where noted, represents an original work of Michael R. Hotek and is protected by applicable copyright laws. The SQL Server FAQ is the sole work of Neil Pike. No page, portion of a page, or download may be used for commercial purposes in whole or in part without the express, written permission of the applicable author.
