Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1212 Part VII Security @LocationCode = ‘RDBMS’, @SecurityLevel = 3; Result: Server: Msg 50000, Level 15, State 1, Procedure pSecurity_Assign, Line 30 Location: ‘RDBMS’ not found Handling security-level updates The pSecurity_Assign procedure used in the previous examples handles new security assignments but fails to accept adjustments to an existing security setting. The following alteration to the procedure checks whether the security combination of contact and loca- tion is already in the Security table, and then performs the appropriate INSERT or UPDATE. Security permissions may be created or adjusted with the new version of the procedure and the same parameters. Here’s the improved procedure: ALTER PROCEDURE pSecurity_Assign( @ContactCode VARCHAR(15), @LocationCode VARCHAR(15), @SecurityLevel INT ) AS SET NOCOUNT ON; DECLARE @ContactID UNIQUEIDENTIFIER, @LocationID UNIQUEIDENTIFIER; Get ContactID SELECT @ContactID = ContactID FROM dbo.Contact WHERE ContactCode = @ContactCode; IF @ContactID IS NULL BEGIN; RAISERROR (‘Contact: "%s" not found’, 15,1,@ContactCode); RETURN -100; END; Get LocationID SELECT @LocationID = LocationID FROM dbo.Location WHERE LocationCode = @LocationCode; IF @LocationID IS NULL BEGIN; RAISERROR (‘Location: "%s" not found’, 15,1,@LocationCode); RETURN -100; END; 1212 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1213 Row-Level Security 52 IS Update or Insert? IF EXISTS(SELECT * FROM dbo.Security WHERE ContactID = @ContactID AND LocationID = @LocationID) Update BEGIN; UPDATE dbo.Security SET SecurityLevel = @SecurityLevel WHERE ContactID = @ContactID AND LocationID = @LocationID; IF @@ERROR <> 0 RETURN -100; END; Insert ELSE BEGIN; INSERT dbo.Security (ContactID,LocationID, SecurityLevel) VALUES (@ContactID, @LocationID, @SecurityLevel); IF @@ERROR <> 0 RETURN -100; END; RETURN; The following script tests the new procedure’s ability to modify a security permission for a contact/location combination. The first command modifies contact 120’s security for location W: EXEC pSecurity_Assign @ContactCode = ‘120’, @LocationCode = ‘W’, @SecurityLevel = 2; EXEC pSecurity_Fetch @ContactCode = ‘120’; Result: ContactCode LocationCode SecurityLevel 120 W 2 The following two commands issue a new security permission and edit an existing security permission. The third command fetches the security permissions for contact code 120: EXEC pSecurity_Assign @ContactCode = ‘120’, @LocationCode = ‘CH’, @SecurityLevel = 1; 1213 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1214 Part VII Security EXEC pSecurity_Assign @ContactCode = ‘120’, @LocationCode = ‘W’, @SecurityLevel = 3; EXEC pSecurity_Fetch @ContactCode = ‘120’; Result: ContactCode LocationCode SecurityLevel 120 W 3 120 CH 1 Checking Permissions The value of row-level security is in actually allowing or blocking reads and writes. The following procedures, functions, and triggers are examples demonstrating how to build row-level read/write validation. The security-check stored procedure The security-check stored procedure, p_SecurityCheck, is central to the row-based security system. It’sdesignedtoreturnatrueorfalsevalueforasecurity request for a user, a location, and a requested security level. The procedure selects the security level of the user for the given location and then compares that value with the value of the requested security level. If the user’s permission level is sufficient, then a 1 (indicating true) is returned; otherwise, a 0 (for false) is returned: CREATE PROCEDURE p_SecurityCheck @ContactCode VARCHAR(15), @LocationCode VARCHAR(15), @SecurityLevel INT, @Approved BIT OUTPUT AS SET NOCOUNT ON; DECLARE @ActualLevel INT = 0; SELECT @ActualLevel = s.SecurityLevel FROM dbo.Security AS s INNER JOIN dbo.Contact AS c ON s.ContactID = c.ContactID INNER JOIN dbo.Location AS l ON s.LocationID = l.LocationID WHERE c.ContactCode = @ContactCode AND l.LocationCode = @LocationCode; 1214 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1215 Row-Level Security 52 IF @ActualLevel < @SecurityLevel SET @Approved = CAST(0 AS bit); ELSE SET @Approved = CAST(1 AS bit); RETURN 0; The following batch calls the p_SecurityCheck procedure and uses the @OK local variable to capture the output parameter. When testing this from the script on the web, try several different values. Use the pSecurity_Fetch procedure to determine possible parameters. The following code checks whether contact code 118 has administrative privileges at the Charlotte warehouse: DECLARE @OK BIT; EXEC p_SecurityCheck @ContactCode = ‘118’, @LocationCode = ‘Clt’, @SecurityLevel = 3, @Approved = @OK OUTPUT; SELECT @OK; Result: 0 The security-check function The security-check function, fSecurityCheck, includes the same logic as the pSecurity_Check stored procedure. The advantage of a function is that it can be used directly within an IF com- mand without a local variable being used to store the output parameter. The function uses the same three input parameters as the stored-procedure version and the same internal logic, but it returns the approved bit as the return of the function, rather than as an output parameter. Here’s the function’s code: CREATE FUNCTION dbo.fSecurityCheck ( @ContactCode VACHAR(15), @LocationCode VARCHAR(15), @SecurityLevel INT) RETURNS BIT AS BEGIN; DECLARE @Approved BIT = CAST(0 AS bit); IF (SELECT s.SecurityLevel FROM dbo.Security AS s INNER JOIN dbo.Contact AS c ON s.ContactID = c.ContactID INNER JOIN dbo.Location AS l ON s.LocationID = l.LocationID WHERE c.ContactCode = @ContactCode 1215 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1216 Part VII Security AND l.LocationCode = @LocationCode) >= @SecurityLevel BEGIN; SET @Approved = CAST(1 AS bit); END; RETURN @Approved; END; The next code fragment demonstrates how to call the function to test security within a stored proce- dure. If the function returns a 0, then the user does not have sufficient security, and the procedure terminates: Check within a Procedure IF dbo.fSecurityCheck( ‘118’, ‘Clt’, 3) = CAST(0 AS bit) BEGIN; RAISERROR(‘Security Violation’, 16,1); ROLLBACK TRANSACTION; RETURN -100; END; Using the NT login Some applications are designed so that the user logs in with the application, and, so far, the row-based security code has assumed that the username is supplied to the procedures. However, if the SQL Server instance is using NT authentication, then the security routines can use that identification. Rather than request the contact code as a parameter, the security procedure or function can automat- ically use suser_sname(), the NT login, to identify the current user. The login name (domain and username) must be added to the Contact table. Alternately, a secondary table could be created to hold multiple logins per user. Some wide-area networks require users to log in with different domain names according to location, so a ContactLogin table is a good idea. The following function is modified to check the user’s security based on his or her NT login and a ContactLogin table. The first query demonstrates retrieving the login within T-SQL code: SELECT SUSER_SNAME(); Result: NOLI\Paul The following code creates the secondary table to store the logins: CREATE TABLE dbo.ContactLogin( ContactLogin UNIQUEIDENTIFIER PRIMARY KEY NONCLUSTERED DEFAULT NEWID(), ContactID UNIQUEIDENTIFIER NOT NULL REFERENCES dbo.Contact(ContactID) ON DELETE CASCADE, NTLogin NVARCHAR(128) UNIQUE CLUSTERED); 1216 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1217 Row-Level Security 52 With the table in place, a simple INSERT will populate a single row using my login so the code can be tested: INSERT dbo.ContactLogin (ContactID, NTLogin) SELECT ContactID, ‘NOLI\Paul’ FROM dbo.Contact WHERE ContactCode = 118; Check the data: SELECT c.ContactCode, cl.NTLogin FROM dbo.Contact AS c INNER JOIN ContactLogin AS cl ON c.ContactID = cl.ContactID; Result: ContactCode NTLogin 118 Paul/NOLI The security-check function is modified to join the ContactLogin table and to restrict the rows returned to those that match the NT login name. Because the contact code is no longer required, this SELECT can skip the contact table and join the Security table directly with the ContactLogin table: CREATE FUNCTION dbo.fSecurityCheckNT ( @LocationCode VARCHAR(15), @SecurityLevel INT) RETURNS BIT AS BEGIN; DECLARE @Approved BIT = CAST(0 AS bit); IF (SELECT s.SecurityLevel FROM dbo.Security AS s INNER JOIN dbo.Location AS l ON s.LocationID = l.LocationID INNER JOIN dbo.ContactLogin AS cl ON s.ContactID = cl.ContactID WHERE cl.NTLogin = suser_sname() AND l.LocationCode = @LocationCode) >= @SecurityLevel BEGIN; SET @Approved = CAST(1 AS bit); END; RETURN @Approved; END; 1217 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1218 Part VII Security To test the new function, the following code fragment repeats the security check performed in the last section, but this time the user will be captured from the NT login instead of being passed to the function: IF dbo.fSecurityCheckNT(‘Clt’, 3)=0 BEGIN; RAISERROR(‘Security Violation’, 16,1); ROLLBACK TRANSACTION; RETURN; END; The function did not return an error, so I’m allowed to complete the procedure. The security-check trigger The security-check stored procedure and function both work well when included within a stored pro- cedure, such as the FETCH, ADDNEW, UPDATE,orDELETE procedures mentioned in the beginning of this chapter; but to implement row-based security in a database that allows access from views, ad-hoc queries, or direct table DML statements, you must handle the row-based security with a trigger. The trig- ger can prevent updates, but it will not be able to check data reads. If row-based security is a require- ment for reads, then all reads must go through a stored procedure. The following trigger is similar to the security-check function. It differs in that the trigger must allow for multiple orders with potentially multiple locations. The joins must match up [Order] rows and their locations with the user’s security level for each location. The join can go directly from the ContactLogin table to the Security table. Because this is an INSERT and UPDATE trigger, any security level below 2 for any order being written will be rejected and a security-violation error will be raised. The ROLLBACK TRANSACTION command will undo the original DML command that fired the trigger and all other modifications made as part of the same transaction: CREATE TRIGGER OrderSecurity ON dbo.[Order] AFTER INSERT, UPDATE AS IF @@ROWCOUNT = 0 RETURN; IF EXISTS ( SELECT * FROM dbo.Security AS s INNER JOIN dbo.ContactLogin AS cl ON s.ContactID = cl.ContactID INNER JOIN Inserted AS i ON i.LocationID = s.LocationID WHERE cl.NTLogin = suser_sname() AND s.SecurityLevel < 2 ) BEGIN; RAISERROR(‘Security Violation’, 16,1); ROLLBACK TRANSACTION; END; 1218 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1219 Row-Level Security 52 Summary SQL Server has a solid reputation for security, but it lacks row-based security. If the database is well architected with a carefully implemented abstraction layer, then adding a custom row-based security schema is not difficult. This concludes Part VII, ‘‘Security,’’ which is so critical for production databases. SQL Server security is based on matching privileges between principals and securables, and a chapter was devoted to each side of the equation. The third security chapter covered data cryptography — introduced in SQL Server 2005 and extended with SQL Server 2008. From here, the book moves into Part VIII, ‘‘Monitoring and Auditing.’’ The sheer number of technolo- gies and options available for monitoring and auditing has grown such that what was a single chapter in SQL Server 2005 Bible grew into a 10-chapter part in this edition. 1219 www.getcoolebook.com Nielsen c52.tex V4 - 07/21/2009 3:43pm Page 1220 www.getcoolebook.com Nielsen p08.tex V4 - 07/10/2009 5:15pm Page 1221 Monitoring and Auditing IN THIS PART Chapter 53 Data Audit Triggers Chapter 54 Schema Audit Triggers Chapter 55 Performance Monitor Chapter 56 Tracing and Profiling Chapter 57 Wait States Chapter 58 Extended Events Chapter 59 Change Tracking Chapter 60 Change Data Capture Chapter 61 SQL Audit Chapter 62 Management Data Warehouse W ow! SQL Server has seen an explosion of monitoring and auditing technologies. SQL Server 2000 and before offered these traditional monitoring technologies: ■ Trace and Profiler ■ System Monitor and Performance Monitor ■ DML triggers and custom audit trails ■ Wait states SQL Server 2005 added: ■ Dynamic management views ■ DDL triggers (Logon triggers with SP2) ■ Event notification ■ SSMS reports ■ Performance Dashboard (downloadable add-on) SQL Server 2008 doubles the core monitoring technologies with the following: ■ Extended events ■ SQL Server auditing ■ Change tracking ■ Change Data Capture ■ Management Data Warehouse ■ Policy-Based Management (covered in Chapter 43) If SQL Server is the box, then this part is about the many ways to be a SQL whisperer and listen to the box. The table on the following page clearly delineates the monitoring and auditing functions available in SQL Server. www.getcoolebook.com . security chapter covered data cryptography — introduced in SQL Server 2005 and extended with SQL Server 2008. From here, the book moves into Part VIII, ‘‘Monitoring and Auditing.’’ The sheer number. 60 Change Data Capture Chapter 61 SQL Audit Chapter 62 Management Data Warehouse W ow! SQL Server has seen an explosion of monitoring and auditing technologies. SQL Server 2000 and before offered. states SQL Server 2005 added: ■ Dynamic management views ■ DDL triggers (Logon triggers with SP2) ■ Event notification ■ SSMS reports ■ Performance Dashboard (downloadable add-on) SQL Server 2008