The postings on this site are my own and do not represent my Employer's positions, advice or strategies.

LifeAsBob - Blog

 

Home

No Ads ever, except search!
Wednesday, April 24, 2024 Login
Public

SQL Server Security, not where it needs to be ? 12/1/2009 1:08:40 PM

SQL Server security, logins, auditing and reporting still not where it needs to be ?  Maybe someone can help me with ideas, if so email, me or leave me some comments.

I've been through a lot of requirements and implementing everything the information security group wants is like Macgyver with duct tape.  Currently this is for SQL 2005, but I'd like to know how to implement it for SQL 2008 as well.

Currently I'm meeting the following Information Security requirements:

  • Limit Logins by specific IP or IP Ranges in combination with Time of Day [login trigger]
  • Limit Logins by Time of Day [login trigger]
  • Disconnect logins that are connected past there authorized time. [job running every 5 minutes]
  • Keep Record of All Logins (success or Failures) [daily job to scrape error log]
  • Keep Counts of Login Failures [daily job to scrape error log]
  • Keep track of Date and Time Password was changed (sql authenticated only) [Tracing]
  • Provide reporting and alerting that shows counts of failure, by month, by id etc. [Reporting Services and SQL Agent]
  • Limit number of concurrent connections by ID and by Global Count [login trigger], so the max number of connections for an instance may be 1000, and the max for a user maybe 5, and the max for the application id may be 300.

Now they want me to selectively enforce password length and expiration based on the following requirements for SQL Server Authenticated:

  • Service accounts  28 characters, expire yearly  (accounts that are not, or should not be used for general sign on’s and limited by what machine(s) they can login from)
  • Admin accounts 15 characters, expire yearly (accounts that are used by DBA’s)
  • User accounts 8 characters, expire every 90 days (normal user accounts) [this is easy as our Active Directory can enforce this]

It just seems that meeting all these requirements in SQL becomes very difficult to administer; we're running a combination of:

  • Dedicated database for reporting, configuration and capture of statistics
  • Login Trigger (difficult to administer and one little issue everyone is locked out)
  • Tracing (to capture when a user changes their password)
  • SQL Agent jobs (to clean up, scrape and roll over reporting tables)
  • Reporting Services (for reporting)
  • Enabling the DAC
  • Enabling Login Auditing
  • Enabling CCC (Common Criteria Compliance)

My counter-parts in Oracle seem to have an easier time meeting all these requirements, with less overhead, easier to administer and keep running, and less danger of locking everyone out.

SQL Server continues to frustrate me with this, anyone have suggestions or an easier time with SQL Server 2005 or 2008?

All these things should be available out of the box, duct taping all that stuff together in sql server is absolutely brutal, documenting and training someone on it is even worse.

It does provide good job security, as let the suits out source the DBA Staff after implementing all of these requirements and they'd sure have a tough time finding someone to run this stuff easily!

The "Suits" and "Information Security"!


Blog Home