Microsoft SQL Server Security & Auditing March 23, 2011 ISACA Chapter Meeting
Agenda Introduction SQL Server Product Description SQL Security Basics Security System Views Evolution of Tool Set for Auditing a SQL Server Things to look for when auditing a SQL Server Q & A
Who is this guy? Currently acting as a Business Intelligence (BI) Developer / DBA for Brooks Rehabilitation Former Roles: Duval County Clerk of the Courts (DBA) Citigroup (DBA / Database Developer) 9 years of real world experience with all components of the SQL Server Stack
What is the SQL Server Stack? This a term used to refer to the four different components that make up the SQL Server Product. SQL Server Database Engine SQL Server Integration Services (SSIS) SQL Server Analysis Services (SSAS) SQL Server Reporting Services (SSRS)
Logical Illustration of the SQL Server Components Provided by Microsoft
How does SQL Server Security Work? Virtual Office Building Analogy
SQL Server Logins A SQL Server Login in this analogy gets you in the building or SQL Server instance. It does not necessarily get you into any particular office or database. When a login is setup it is assigned to one of 9 static server roles that afford it differing levels of permission. Server logins can be in the form of an explicit SQL login, an individual windows login, or an Active Directory group
SQL Server Roles There are nine server roles that ship with SQL Server. They cannot be modified and you cannot create new roles: Public: This is the default role given to a new login unless otherwise specified. SecurityAdmin: Logins belonging to this role can create or modify logins on a SQL Server. SysAdmin: This is the highest level role given to a login & it automatically affords absolute privileges on a SQL Server.
SQL Server Database Users SQL Server logins are mapped to users within a particular database. Permissions assigned to a user dictate what actions they can perform within a database. Database roles can be used to organize users into groups based on the level of access they need within the database. There are database roles that exist by default but unlike server roles new ones can be added.
SQL Server Database Roles Database roles can be thought of as dynamic permission groupings or buckets. db_reader: Rights to directly select data from any tables or views within a database. db_writer: Rights to directly insert, update, or delete data within a database. db_owner: Rights to take any action within a database.
What are System Views? System Views are internal data structures provided by Microsoft to allow users to view the state of a SQL Server. There are easily 100+ system views reporting information back about every aspect of the SQL Server Engine.
Important Security System Views SQL Server 2005 & 2008 sys.server_principals: Lists all server logins. sys.server_role_members: Maps logins to their roles. sys.server_permissions: Lists server permissions along with ID of who granted them. sys.database_principals: List all database users with a link through SID column back to logins.
More Security Views sys.database_roles: List the members of database roles. sys.database_permissions: List explicit permissions within a database. In SQL Server 2000 the comparable views would have been syslogins for logins & sysusers for users. These are only included for backwards compatibility and will probably get deprecated in the upcoming version of SQL.
Want to Make it Easier? Microsoft also provides system stored procedures to get this information back without having to directly query the views. sp_helplogins: This proc will list all server logins & the user accounts that are mapped to them. sp_helpusers: This proc will list all users within the current database along with the role they are in. sp_helpsrvrolemember: Returns server role members.
More System Procedures sp_helprole: Returns information about database roles within current database. sp_helprolemember: Returns information about role members within a current database. Example: exec sp_helplogins (If the above was executed against a SQL Server you would get two sets of information listing logins & users mapped to those logins. **You must have elevated permissions to run these procs**)
Evolution of Auditing SQL Server SQL Server 2000: C2 Auditing: Expensive, heavy footprint logs every action to a file. DML Triggers: Can be difficult to maintain. Home grown background traces: Very effective and efficient if coded correctly. Need pretty high level DBA skills to implement and maintain. Vendor Products: Depending on vendor ties you to a particular version of SQL. Often hobbling ability to cleanly migrate when business needs require it.
Next Round SQL Server 2005 DDL Triggers: These allow an action to occur when someone tries to create, alter, or drop an object such as a table, view, or stored procedure. Same difficulties of trying to maintain all this background code. They do have their place but triggers alone are not a great auditing solution. *Example: CREATE TRIGGER safety ON DATABASE FOR DROP_TABLE, ALTER_TABLE AS PRINT 'You must disable Trigger "safety" to drop or alter tables!' ROLLBACK ; *Example provided by MSDN Books Online
Where We are at Today SQL Server 2008 & R2: SQL Server Audit Feature: This has laid a user interface over the background trace functionality to allow for easier setup and maintenance of these activities. Only available on SQL Server 2008 Enterprise. Still need to account for archiving of target files the audits write to. *With any background traces it is important to baseline server to make sure audit is not reducing performance.
Still Today Policy Based Management: One of the coolest new features released in SQL Server 2008. Allows an administrator to setup a server policy or check a policy against an existing server. Proactive Auditing. Requires a fair amount of knowledge to configure. Certain functionality only works with SQL Server 2008 instances.
Things to Look for in a SQL Audit What privileges and what type of network access do the Windows accounts running the SQL services have on the network? Privileges outside the server they are on should be limited. Is xp_cmdshell enabled? If so, is it restricted to sys.admin role? Remember if a login asks SQL to perform an action outside of SQL that action will be executed under the service account.
More Things to Look For What is the authentication mode on the server? Are failed login attempts being written to the Windows Event Log? Is the BUILTIN/ADMINISTRATORS group disabled? If not someone can gain access to a SQL Server by adding themselves into this server group.
(SA) Account Built in SQL Administration account. Has unlimited rights on the server by default. Been the source of many SQL Server attacks over the years. Requires a password in the latest versions of SQL Server. Many businesses choose to disable this account. (**Otherwise, password should be locked away only accessed when needed & modified**)
A Few Other Important Ones Where are SQL Backups being written to? If written to a network share is it secure? Are there any linked servers setup? If so what security context are they making their connections under? (sp_helpremotelogin)
Also Important Are all users in sysadmin role Windows accounts? Do these people have ability to modify Active Directory? Are logins that are not in special role explicitly mapped to only databases required to do their job?
In Closing Know what SQL assets you have. Know who can access them. Use principle of least privileges. Enforce separation of duties between (Network / System Engineers) & Database Administrators. Keep up with latest security threats to SQL Server.
Questions?