11 September,2012 by Jack Vamvas
SQL Server Security Risk Analysis is adds good value to managing SQL Servers and the DBA role. Managing database security, most DBAs create a security policy , monitor log files, and possibly run a regular audit to check if the security policy is implemented. Taking it one step further and commiting to a regular risk review , can yield some good results – without a major impact on DBA resources.
When discussing SQL Server security, IT managers often ask for any known risks on the database servers. Some risks are bigger than others and it’s important to focus on the biggest risk first. The following is a checklist of items to review. Not all of them may be relevant to your environment. I implement this type of Risk Analysis , on a quarterly basis
1) Identify Risk
2) Mitigate Risks – create policies , audits, reviews
3) Verify that Risks have been mitigated
Perimeter – firewall, ipsec
Are Windows Administrators and SQL Server Administrators separated?
SQL server 2008 doesn’t automatically create BUILTIN\Administrators, but there are still plenty of SQL Server 2005 installations with a BUILTIN\Administrators logon
Are regular sql server security audits occurring?
When a user moves dept are they removed from the AD groups?
Microsoft Baseline Security Analyzer. Download MBSA
According to BOL “ a system should allow for only the required level of access to a securable object.”
Is access given to only users who need it?
If temporary elevated rights are required , is the specified time managed?
Are applications reviewed to check for coding based on elevated privileges.?
Are developers using db_ddladmin rather than db_owner?
A great way to standardize policies across multiple SQL Server Instances.
Select * from sys.endpoints - to view endpoints
Why check SQL Server endpoints? It is the point of entry for SQL Server – and offers a “map” of every interaction between SQL Server and the network. It’s not a firewall – but is similar in regards to controlling the traffic type allowed.