Signing Modules in SQL Server 2005 with Certificates

dansellers — Wed, 06 Sep 2006 23:10:00 GMT

The one topic that I get asked to talk about frequently is Encrypting Data with SQL Server 2005. Personally, I am very impressed with the build-in encryption support provided in SQL Server 2005, but one of my favorite and what appears to be a subtle Security enhancement in SQL Server 2005 is the ability to sign Modules such as Stored Procedures, Functions or Triggers with Certificates.

The first thing you are probably wonder is why would I want to sign a Stored Procedures?

By signing a Module with a certificate, the certificate is then granted the relevant permission and goes beyond what can be achieved with the "Execute As" feature, especially from an auditing perspective.

When you perform tracing, the auditing table will record the "Execute As User" that performed the operation of the Stored Procedure (the user account in which the stored procedure is executing under) but does not show who the actual calling user was. Now, there is a additional column in the auditing table that will record the original login that caused the actions to occur, however, in the trace records it will only show that Execute As User performed all the operations and not the original caller.

Thus the moral of the story is we use the Sign Module approach in SQL Server 2005 this will allow us to capture the original caller that caused the action to occur in the Stored Procedure.

So how do I set this up?

Let say we have an End User calling a Stored Procedure called Proc1 that will perform some kind of action on Table1. The End User does not have permission on the Table 1, only the Proc1 does, however, the End User has been granted Execute permission.

Now we can sign Proc1 with a certificate called Cert1. We then create a User called CertUser which is mapped to the Cert1. Then we grant the necessary permission on Table1 to CertUser.

What is going on under the Hood of SQL Server 2005?

When a SQL Server 2005 User calls a Module the User Token--similar to a token in Windows will be passed to the Module. The Token will contain both the primary id--identifies the calling user--and the secondary's id--the SQL Server 2005 roles the user belongs to. If the Module has been signed, SQL Server 2005 will add the User Account which has been mapped to the Certificate--that was used to sign the Module--to the secondary id of the calling user.

Therefore, in our example, when EndUser calls SP1, SP1 will verify the signature of Cert1 and add CertUser--the user that was mapped to the Certificate--to the secondary id of the EndUser token. Now EndUser can have access to the Table1 via the signed Module "Proc1" and in tracing we can capture the "Calling User"--End User--and not just the "Executing As User" only.

Security for Canadian Developers : SQL Server 2005

Signing Modules in SQL Server 2005 with Certificates