SQL Server Security Database and OS Level Audit

SQL Server Security Database and OS Level
Wipro Technologies | Confidential

SQL Server Security Database and OS Level Audit

Author Vamshi Krishna Vaddepally
MSIT SQL Operations
Date of Creation 20-Jan-2010
Email id vaddepalli.krishna@wipro.com&
v-vamsk@microsoft.com


SQL Server Security Audit - Database Level Audit
Once the Server Level audits are complete, databases should be considered next. A number of steps can
be taken to audit database level security.
Database owners
A database owner can perform any action in the database. This includes granting access rights to the
database to other users. Every database has a built-in user account called the dbo. This is the database
owner. By default, this user account is mapped to the login that created the database. There is also a
fixed database role called db_owner whose members have database ownership privilege.
Just like finding out who has system administrator privilege in your SQL Server, you may want to find out
who has ownership rights in each database.
Executing the following script against each database will give you a list of user accounts that are
members of the db_owner role:
USE <<database_Name>> -- Run against each database
GO
SELECT c.name AS DB_Owner_Role_Member
FROM sys.database_principals a
INNER JOIN sys.database_role_members b
ON a.principal_id = b.role_principal_id AND a.is_fixed_role = 1 AND a.name ='db_owner'
INNER JOIN sys.database_principals c
ON b.member_principal_id = c.principal_id
If you want to find out the login that is mapped to the built-in dbo user, you can use the following
query:
USE <<database_name>> -- Execute for each database
GO
SELECT b.name AS Login_Mapped_to_DBO


INNER JOIN sys.server_principals b
ON a.sid = b.sid
WHERE a.name = 'dbo'
Guest user account
Just like dbo, the guest account is also a special built-in database user. This user is disabled by default,
but you can enable it or create it manually. The guest account does not correspond to any SQL Server
login. In fact its purpose is to serve as an ad-hoc user for any login. What this means is that any login
that does not have a corresponding database user account can still get into the database provided the
database has the guest user enabled. Guest user exists in the system databases and they are there for
a reason. But if you have a guest account enabled in your production database, you need to know why it
is there and what access it has got.
A code snippet like the following can help you identify the rights of the guest user.
GO
SELECT c.name AS ObjectName,
c.type_desc AS Object_Type,
b.permission_name AS Permission_Type,
b.state_desc AS Permission_Status
INNER JOIN sys.database_permissions b
ON a.principal_id = b.grantee_principal_id
INNER JOIN sys.objects c
ON b.major_id = c.object_id

WHERE a.name = 'guest'
ORDER BY c.name


Orphan users
Strictly speaking, this is not a security hole, but one that needs to be looked at nevertheless. Sometimes
SQL Server logins are deleted without dropping the associated database users first. Often databases are
restored from another system and the user accounts in them do not correspond to any local logins. Your
database is said to have orphan users in such cases. The security audit should pick up these orphan
users in each database. The following query can be run in each database for this purpose.
GO
SELECT a.name AS OrphanUserName, a.type_desc AS UserType
LEFT OUTER JOIN sys.server_principals b
ON a.sid = b.sid
WHERE b.sid IS NULL
AND a.type In ('S', 'U', 'G')
AND a.name NOT in ('sys', 'INFORMATION_SCHEMA', 'guest')
Database object permissions
We could go down to more granular level and find out the access rights explicitly granted to each
database user for each database object. This can be a quite large report, with probably not much value.
But if you are still interested, you can execute a query like the following:
GO
SELECT a.name AS Database_Principal_Name,
a.type_desc AS Database_Principal_Type,
c.name AS ObjectName,
c.type_desc AS Object_Type,
b.permission_name AS Permission_Type,


b.state_desc AS Permission_Status
INNER JOIN sys.database_permissions b
ON a.principal_id = b.grantee_principal_id
INNER JOIN sys.objects c
ON b.major_id = c.object_id
WHERE a.name NOT IN ('sys', 'INFORMATION_SCHEMA', 'public', 'guest')
ORDER BY a.name
Instead, you will probably be interested to find out the non-default schemas that exist in your database
and the owners of those schemas:
GO
-- List of non-standard schemas and their owners
SELECT a.name AS Database_Schema_Name, b.name AS Schema_Owner
FROM sys.schemas a
INNER JOIN sys.database_principals b
ON a.principal_id = b.principal_id
WHERE a.schema_id <> a.principal_id
AND b.type <> 'R'
-- List of users and their default schemas
SELECT name AS Database_User, Default_Schema_Name
FROM sys.database_principals
WHERE type <> 'R'


Certificates, symmetric and asymmetric keys
From version 2005, a new feature of data security has been added to SQL Server. Individual table
columns can now be encrypted using asymmetric keys, symmetric keys or certificates. Data traffic
between SQL Servers can be encrypted using certificates and login accounts can be mapped to
certificates or asymmetric keys.

When it comes to encryption, there is a hierarchical relationship between these three entities. A data
field can be encrypted using a symmetric key, which in turn can be encrypted by an asymmetric key or a
certificate. Certificates can also encrypt asymmetric keys. At the root of all encryption mechanism is the
service master key.
When using certificates, SQL Server does not necessarily need a certificate issued by a third party like
VeriSign. In fact it can issue a self signed certificate itself.
If you want to see if there are asymmetric keys, symmetric keys of certificates installed in your database,
you can either use the Management Studio or use a query like the following:
USE <<ddatabase_name>> -- Change for each database


GO
SELECT * FROM sys.certificates
SELECT * FROM sys.symmetric_keys
SELECT * FROM sys.asymmetric_keys
Operating system level audits
Typically, most DBAs have remote access privilege to the Windows machine hosting the database server.
If you have administrator privilege in the Windows box (or VM), you can take some time to try the
following:
Windows security log
This should be actually a part of the DBAs daily checks. However, as part of your initial audit, check the
Windows security log. The security log in the Event Viewer can show you the unsuccessful login
attempts to your SQL Server.

You can filter the security log with various options. For example, you may be only interested in failed
login attempts.


If there are a large number of unsuccessful login attempts either from same or multiple sources pay
attention, note it down; this needs to be looked at. However, this does not necessarily mean somebody
is trying to hack into your server: it may be due to a service accounts being locked out.
Local administrator group
Members of the Local Administrators group are also by default members of the sysadmin fixed server
role. Even if the role privilege has been explicitly revoked, local administrators still have full access to the
Windows environment.
If you have administrator privilege in the Windows machine hosting the SQL Server, you may be
interested to know who else has that privilege. To find out, start the Computer Management applet
from the Administrative Tools program group and then browse to the Local Users and Groups node.


If you double click on the Administrators group, it will show you a list of local administrators of the
machine.



By default, only the built-in administrator account and the Domain Admins group should be listed
here. You may also find your account (as the DBA) or a Windows group for DBAs listed here. However, if
you see accounts or groups that you know should not have this privilege note it down.
Shared folders
Database applications often import and export data contained in text files. This can happen from within
stored procedure codes, SSIS packages or hard coded scripts within SQL Server jobs. Often these data
files are located in shared folders in the database servers file system. If you see such shared folders in
your SQL Server machine, take a minute to check its permission level. It is common to see the
Everyone group having full access to shared folders.



You may also want to explicitly check the folder permissions for directories holding data, backup or
replication files.
Security Configuration and Analysis Tool
The Security Configuration and Analysis tool is an MMC snap-in that can make use of customised
security templates (created as .INF files) to check the status of your servers security. There are some
standard security template files that ship with Windows by default (see figure below).


These templates are configured for domain controllers, member servers etc. There is no specific
template that applies to SQL Server database servers. However as a standard practice, most companies
have domain level policies that automatically overwrite any server specific changes on a regular interval.
If your organisation has any such customised template that is used for member servers and the server is
not automatically refreshed with the security policies, you can use that template to verify the current
status of security.
You can invoke the Security Configuration and Analysis tool by starting the MMC application from the
command prompt, then adding the relevant snap-in (see below).


Once you have the snap-in into place you can create a security database (not in the traditional sense of
SQL Server database). This database will have all the details of the current Windows server security
configurations. The database creation is a fairly straightforward process: all you have to do is right click
on the snap-in under the MMC console root and choose Open Database and provide a name for it.
Security databases have an extension of .sdb. Once you provide the name, you need to select the
appropriate template file.


Next, you need to choose Analyze Computer Now... from the pop-up menu by right clicking on the
snap-in again.

The application will take some time to analyse the security status of your server against the template.
Once the analysis is complete, it will show you with visual flags where the current security status is not
consistent with the template settings. In the example below, we had used the tool with the
hisecws.inf template file.


Working with the Security Configuration and Analysis tool is primarily a server administrator or
infrastructure engineers work not a DBAs. This is where you need to be a bit careful as not to give the
impression that you are treading into the responsibility area of another person or department. If
needed, work closely with your server administrators for this audit.
Microsoft Baseline Security Analyzer
Microsoft Baseline Security Analyzer (MBSA) is a freely downloadable tool from the Microsoft web site.
You can run it against your target SQL Server machine to get a detailed report on security vulnerabilities.
MBSA can be configured to check for security updates for Windows Server 2003 or 2008. The updates
can be checked either from the Microsoft web site or from a WSUS server. It can also check IIS or SQL
Server for vulnerabilities. The automated audits are saved as reports that you can refer back to later.
The tool also lets you check a range of machines in one single session.
Provided you have administrator privileges in the machine, it may be worthwhile to run the MBSA tool
against the SQL Servers installed.




You may get a report like the following:


Probably many of your findings in the security audit so far will also be picked up the MBSA. Nevertheless
it is a good idea to run the application to see if you have missed anything.
Virus Protection
Check with your system administrators to see if the SQL Server machine has the latest anti-virus
software installed and enabled and if the virus definitions are automatically updated. This may sound
obvious since most organisations will have anti-virus software running on their servers, but this is for
completeness sake.
Conclusion
You would not probably want to include your development and test servers in the security audit
described here since there will be little value in doing so. Ideally, at the very beginning, the audit should
include one or few critical SQL Servers in the enterprise. Depending on time, budget and scope, you may
not want to include everything in your audit and everything discussed here may not apply to your
environment either. But once you have the process ready through scripts, manual checks and
documentation it can easily be repeated.
Another point to remember is that you will probably perform the audit for management presentation. In
such cases you would want to keep it as free of technicalities as possible. This often means you will have
to prepare a second birds eye-view report based on your initial findings. You should be ready to back
this high level audit report with all the screenshots and query outputs wherever necessary.
Also, once you have the initial audit ready with all the Excel spreadsheets, Word documents,
screenshots and reports you need to start working with developers, system administrators, team
leaders and business stakeholders to find out the reasons behind any anomalies that you identified.


So for example, if your audit shows the accounting team user Joe Blogg has sysadmin privilege in your
SQL Server and after talking with the stakeholders you establish that he should not have this access,
present the fact in an understandable format. Instead of showing the account MYCOMAPNY\JBlogg
listed under a column titled sysadmins, make sure your final report only highlights the fact that some
of the accounting department personnel have system administrator privilege in the database server and
this is against the business rules.

Please send your feedback to vaddepalli.krishna@wipro.com or v-vamsk@microsoft.com

SQL Server Security Database and OS Level Audit

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

SQL Server Security Database and OS Level Audit

Загружено:

Авторское право:

Доступные форматы

SQL Server Security Database and OS Level

Wipro Technologies | Confidential

Вам также может понравиться