Microsoft SQL Server 2008 R2 Unleashed- P43 ppsx

ptg
364
CHAPTER 13 Security and Compliance
The Open Web Application Security Project (OWASP; www.owasp.org) lists its recent top
10 application vulnerabilities as follows:
. SQL Injection
. Cross-Site Scripting
. Broken Authentication and Session Management
. Insecure Direct Object References
. Cross-Site Request Forgery
. Security Misconfiguration
. Failure to Restrict URLs
. Unvalidated Redirects and Forwards
. Insecure Cryptographic Storage
. Insufficient Transport Layer Protection
Identity Access Management Components
One of the key areas identified in the security big picture (as you can see looking back at
Figure 13.3) is identity management. It is key in the sense that well-managed identities are
essential to well-managed security. There is a quite a bit to consider when talking about
identities. Figure 13.4 shows a common “identity universe” for a company that has both
internal- and external-facing applications. In other words, identities are both customers
that interact with the business and internal identities such as employees and other work-
force identities (contractors, temps, partners, and so on). Both sets of identities must be
managed well, and often there are overlapping identities that require accesses (and iden-
tity management) in both areas (internal and external).
Often, companies use one internal-facing LDAP directory such as Microsoft’s Active
Directory for managing their internal identities and then another LDAP directory such as
Sun One LDAP for managing all external-facing identities (for forums, eStore, and so on).
Then they create triggers or synchronization jobs that do a “search before create” type of
processing when new identities are created within either LDAP directory. Because overlap
is rare, not much extra “create” overhead occurs, but when they do overlap, only one

identity (such as a partner identity that might be in that company’s internal and external
LDAP directories) gets created. This is effectively “mastering” the user identities. It is
recommended that you consider both sources of identities at all times. You should also
establish strict access roles for all identities with the least rights going to anonymous
identities.
More and more companies are also now moving to concepts such as Open ID, where a
company can utilize the authentication and identification established by third-party Open
ID providers and grant trust to these identities with very high confidence. The industry is
moving this way fast. Figure 13.5 shows the logical components of identity access
management.
Download from www.wowebook.com
ptg
365
Identity Access Management Components
13
Company Identities
Internally-Facing
Identities
Externally-Facing
Identities
Employees
Temps
Others
Partners
(and their Contacts)
Forums
Customers
(Registered/Subscription/Anonymous)
Prospects
Leads

Opportunities
Touch/Use
Internal
Applications/Data
Sell/Service/Buy/Use
Products, Services, Data
Mergers and
Acquisitions
Social
Networking
App
Store…
Identity Universe
Mergers and
Acquisitions
Mergers and
Acquisitions
FIGURE 13.4 Identity universes (internal and external-facing applications).
Logical Components of
Identity Access Management
Applications/Access Points
Access ManagementIdentity Life-Cycle Management
Directory Services
- User Management
- Credential Management
- Entitlement Management
- Identity Integration
- Provisioning/De-provisioning
- Authentication & SSO
- Trust & Federation

- Entitlements & Authorization
- Security Auditing/Compliance
- Identity Propagation
- Impersonation & Delegation
- Users - Attributes
- Groups - Roles
- Credentials - Policies
Applications/Access Points
FIGURE 13.5 Logical components of identity access management.
Download from www.wowebook.com
ptg
366
CHAPTER 13 Security and Compliance
This figure shows that you must carefully address full identity life-cycle management,
which includes user ID management, credential management, entitlement management,
identity integration (between multiple LDAPs), and provisioning and deprovisioning iden-
tities. Access management is all about authentication, single sign-on, authorization, and
impersonation and delegation rules. And, the directory services themselves define the
users, groups, all attributes (or elements) of a user or group, roles, policies to enforce, and
credentials to be used. All applications and access points must be plugged in to this iden-
tity access management framework. All risk is minimized by a sound identity access
management foundation.
Compliance and SQL Server
On the global level, hundreds of compliance laws are in place that affect almost every
aspect of data access, data protection, data movement, and even data storage. Countries
such as Germany now have some of the most severe data compliance rules on the planet,
such as strict control of how certain personal data is stored and what personal data can be
stored; these rules even prohibit personal data from being transmitted (or moved) across
German borders. If you are planning to create applications and databases that will span
countries or contain sensitive or private data, you must “design in” the rules and enforce-

ments from the beginning (as we have been stressing throughout this chapter).
Let’s address the most common “sensitive” data: Personal Identifiable Information (or PII
for short). PII data is at the center of most global data privacy laws and regulations. As
you can see from a subset of the PII data model in Figure 13.6, PII data is any personal
information that identifies an individual, such as name; address; driver’s license number;
other government-issued identification (such as passport number); and even gender,
ethnicity, and age.
If you have any databases or applications that have this type of data in it, you are bound
by local and/or regional laws and regulations whether you like it or not. It is the law. You
must then protect this data in accordance with those regulations and laws; otherwise, you
become liable for fines, lawsuits, or worse (risk exposure of that data could put you out of
business). As you can also see in Figure 13.6, there are different sensitivity levels around
PII data. Something like a person’s name is considered low sensitivity, whereas an
employee ID is considered medium sensitivity. And marital status, gender, Social Security
number, bank account number, driver’s license number, and passport number are consid-
ered high sensitivity and often must be treated with special care and feeding with capabili-
ties such as encryption in transit and at rest (while stored in a table).
Following is a list of some of the many laws and regulations that have been put into effect
and that you will likely have to address in your application:
. The Health Insurance Portability and Accountability Act (also known as HIPAA) was
introduced in 1996 to protect critical health and patient information. HIPAA forces
companies to strictly control data identified under its jurisdiction.
Download from www.wowebook.com
ptg
367
Compliance and SQL Server
13
Billing Profile
No n - K
"Card Number"

"Card Type"
PIN
"Security Code"
Bank
"Bank Account Number"
"Bank Routing Number"
Customer Physical Address
No n - K
"Street Address"
City
State
"Postal Code"
Personnel Demographic
No n - K
BirthDate
Gender
"Marital Status"
Children
Government Identification
No n - Ke
"Social Security Number"
"Passport Number"
"Drivers License Number"
"Other Government ID"
Purchases
No n - K
Product
"Purchase Date"
"Purchase Amount"
"Renewal Date"

Personnel Name
No n - K
"First Name"
"Middle Name"
"Last Name"
Internal Contact Information
No n - K
"Office Phone Number"
"Job Title"
"Site Location"
Consumer Customer Name
No n - Ke
"First Name"
"Last Name"
Customer Contact
Points
Personnel
No n - K
"Employee ID"
Sales Entity
Enterprise/SMB Customer
Consumer Customer
Customer Electronic
Address
Low Sensitivity
Medium Sensitivity
High Sensitivity
characterized by
Referenced by
Provided

Known by
Made
Made
Made
Specifies
Installed
provided
Installed
Identified via
has provided
Known by
Specifies
FIGURE 13.6 Personally Identifiable Information (PII).
. The Sarbanes-Oxley Act (known as SOX), put into place in 2002, requires auditors to
assess and report on the effectiveness of a company’s internal controls on informa-
tion and extend into the authorization of access and updates to data.
. The Gramm-Leach-Bliley Act (GLBA) of 1999 further defines steps that must be taken
by financial institutions to protect, secure, and prevent access of core financial data.
. California’s Information Practices Act of 2005 details strict controls around PII data,
what needs to be encrypted, and laws surrounding breaches of controlled data.
. The Children’s Online Privacy Protection Act, passed in 1998, focuses on the proce-
dures to protect the confidentiality, security, and integrity of personal information
collected from children.
Other industry-oriented laws and regulations have emerged, such as the Payment Card
Industry data security standard (PCI standard). It is focused on what must be done to
ensure credit card information is secure from the moment a customer makes a purchase
until the merchant disposes of the credit card transactions.
Two great books on security and compliance are Cryptography in the Database by Kevin
Kenan (2006, Addison-Wesley) and The Executive Guide to Information Security by Mark
Egan (2005, Addison-Wesley). These books will make great focused additions to your tech-

nology library.
Download from www.wowebook.com
ptg
368
CHAPTER 13 Security and Compliance
SQL Server Auditing
Introduced with SQL Server 2008 is the SQL Server Audit feature. This long-overdue feature
now adds a great native auditing functionality into the SQL Server Database Engine.
NOTE
The SQL Server Audit feature is available only in the SQL Server 2008 Enterprise and
Developer Editions.
An audit is the combination of several elements into a single package for a specific group
of server actions or database actions. The components of SQL Server Audit combine to
produce an output that is called an audit.
The SQL Server Audit feature in SQL Server 2008 is intended to replace SQL Trace as the
preferred auditing solution. SQL Server Audit is meant to provide full auditing capabilities,
and only auditing capabilities, unlike SQL Trace, which also serves for performance debug-
ging. The SQL Server Audit feature is built on top of Extended Events, a new high-perfor-
mance eventing infrastructure introduced in SQL Server 2008. SQL Server Audit leverages
the performance benefits of Extended Events, which provides both asynchronous and
synchronous write capabilities (by default, SQL Server Audit uses the asynchronous event-
ing model).
NOTE
By default, the audit events are written to the audit target in an asynchronous fashion for
performance reasons. When tighter guarantees of audit records being written to the
audit log are required, you can select synchronous write, with the understanding that
some amount of performance degradation should be expected. The choice of asynchro-
nous or synchronous is controlled by the QUEUE_DELAY option of the CREATE AUDIT DDL.
SQL Server Audit is also tightly integrated with the Windows operating systems and can
push (write) its audits to the Windows Application or Security Event Log. With SQL Server

Auditing, you can set up auditing of just about any event or execution within SQL Server,
and it can be as granular as you need (right down to a table and operation level). This
capability is important because not only can you track all these events, but you can use
this auditing capability to fulfill application and database audit compliance and look for
patterns of misuse, or even specific “hot” objects that contain the most sensitive data in
your database.
As you can see in Figure 13.7, a branch under each database called
Security contains
several of the common security-related nodes that you’ve seen before (Users, Roles,
Schemas, and so on). But now, there is a Database Audit Specifications branch from
which you can set up and view the database audit specifications you have defined. You
Download from www.wowebook.com
ptg
369
SQL Server Auditing
13
FIGURE 13.7 The new Database Audit Specifications item in the SQL Server
Management Studio (SSMS) Object Explorer.
can have as many specifications as you want, and again, they can be at varying levels of
granularity.
Before you can set up a Database Audit Specification, however, you must first set up a SQL
Server Audit object. To do this, you must use a couple of new entries in the Object
Explorer under the Security folder at the SQL Server instance level: Audits and Server
Audit Specifications.
Essentially, three main objects describe audits in SQL Server 2008:
. The Server Audit object—Used to describe the target for audit data, plus some top-
level configuration settings. This destination can be a file, the Windows Application
log, or the Windows Security log. The Server Audit object contains no information
about what is being audited—just where the audit data is going. Multiple Server
Audit objects can be defined with each object independent from one another (that

is, they can each specify a different destination).
. The Server Audit Specification object—Used to describe what to audit at a server
instance-wide level. A server audit specification must be associated with a Server
Audit object to define where the audit data is written. There is a one-to-one relation-
ship between the Server Audit Specification object and the Server Audit object.
. The Database Audit Specification—Used to describe what to audit at a specific
database level. Where the audit data is written is determined by the Server Audit
object it is associated with. Each database audit specification can be associated with
Download from www.wowebook.com
ptg
370
CHAPTER 13 Security and Compliance
FIGURE 13.8 Creating a new Server Audit object in Object Explorer at the Server instance
level.
only one server audit. A server audit can be associated with audit specifications for
multiple databases, but only one database audit specification per database.
To create a new Server Audit object, right-click on the Audits item in Object Explorer and
select New Audit (see Figure 13.8).
When you set up a Server Audit object, you specify where the audit information will be
written to. In Figure 13.9, you can see that we are creating a server audit named
NEW_SQL_Server_Audit and are defining it to use the Application log at the Windows oper-
ating system level as the audit destination. You can also choose to write to the Windows
Security log or to a text file. Events written to the Application or Security Event log can be
accessed with Event Viewer or with specialized Event log management software, such as
Microsoft Systems Center Operations Manager.
NOTE
Depending on the volume of audit targets being monitored, better performance may be
achieved by using a file as the audit target rather than the Windows Event log. Also,
when written to a file, the audit data is accessible through a built-in table-valued func-
tion (fn_get_audit_file), which allows the use of regular SELECT syntax to query the

audit trail.
NOTE
You can also configu re the Audit object to shut do wn the SQL Ser ver insta nce if, for
whatever reason, SQL Server Audit is unable to write its audit events to the audit tar-
get. Although shutting down the server instance may seem drastic, doing so may be
necessary for certain scenarios, to ensure that the server cannot operate without its
activity being audited.
Download from www.wowebook.com
ptg
371
SQL Server Auditing
13
FIGURE 13.9 The Create Audit dialog.
FIGURE 13.10 The Create Database Audit Specification dialog.
After you set up the Server Audit object, the next step is to go to the Database Audit
Specifications folder, as shown in Figure 13.7, in the database for which you want to set
up auditing. Right-click this folder and select New Database Audit Specification to bring
up the dialog shown in Figure 13.10. This is where you define your database-level audits.
In the Create Database Audit Specification dialog, you specify the name of the Database
Audit object and the Server Audit object it will be running under. In this example, the
Database Audit name is NEW_Database_Audit_Specification, and it will be running under
Download from www.wowebook.com
ptg
372
CHAPTER 13 Security and Compliance
the NEW_SQL_Server_Audit Audit object defined in Figure 13.9. In this example, the data-
base audit is being set up to audit any SELECT statements (reads) run against the Employee
table (which, of course, contains company-sensitive employee data) by any user (public).
At this point you have created a Server Audit object and database audit specification asso-
ciated with the server audit. However, neither of these audits is enabled. You can enable

them by right-clicking on each and selecting Enable. As soon as the Server Audit object is
enabled, it begins auditing and writing audit records to the specified destination (in this
example, the Windows Application log).
NOTE
If your SQL Server login is configured for a default database other than master,
enabling the SQL Server Audit object via SSMS fails with the following message:
Cannot alter a server audit from a user database. This operation must be
performed in the master database.
If you receive this error, you need to enable/disable the server audit via T-SQL, as
shown in Listing 13.1.
You can review the details by right-clicking on the Ser ver Audit and selecting View Audit
Logs or, if you are auditing to the Windows Application or Security Event Log, by opening
the Windows Event Viewer directly. One of the advantages of opening the Audit log from
within SSMS is that it automatically filters the log to show only SQL Server Audit events.
In Figure 13.11, you can see that we’ve opened the Log File Viewer and selected to view
the Application log (where we directed our SQL Server Audit to go). A few SELECT state-
ments were run against the Employee table and, sure enough, the audit information of the
SELECT statements shows up in the Application log.
Within the Log File Viewer, you can filter your audit results or search them to look for
patterns, specific violations, and so on. From the Log File Viewer, you also have the option
of exporting the audit logs to a text file or to a comma-separated values (CSV) file. With a
CSV file, you could import the audit logs into a database for further analysis and correla-
tion. It’s up to your security and audit team to decide how these audits are to be used.
In addition to database-level auditing of actions at the database level, you can also set up
auditing of server-level events, such as management changes and logon and logoff opera-
tions. These are set up in the SSMS Object Explorer through the Server Audit Specifications
item in the Security folder for the SQL Server instance (refer to Figure 13.8).
Setting Up Auditing via T-SQL
Alternatively, you can set up auditing with T-SQL statements and also switch the audit
off and on using the ALTER SERVER AUDIT command by using WITH (STATE=ON) or WITH

(STATE=OFF), as shown in Listing 13.1.
Download from www.wowebook.com
ptg
373
Setting Up Auditing via T-SQL
13
FIGURE 13.11 Log File Viewer showing the audit events of a SQL Server Audit object.
LISTING 13.1 Setting Up Auditing with T-SQL
/* Create the SQL Server Audit object, and send the results to the
Windows Application event log. */
USE master;
go
CREATE SERVER AUDIT NEW_SQL_Server_Audit
TO APPLICATION_LOG
WITH ( QUEUE_DELAY = 1000, ON_FAILURE = CONTINUE);
GO
/* Create the Database Audit Specification object using an Audit event */
USE AdventureWorks2008R2;
GO
CREATE DATABASE AUDIT SPECIFICATION NEW_Database_Audit_Specification
FOR SERVER AUDIT NEW_SQL_Server_Audit
ADD (SELECT
ON OBJECT::[HumanResources].[Employee]
BY [public])
WITH (STATE = ON);
GO
Download from www.wowebook.com