Security in the CLR World Inside SQL Server

Is running ।NET Framework code within SQL Server 2005 exciting or a threat? Which is it? This article explores the security issues of SQLCLR code so that both developers and DBAs can make informed decisions about its use.


One of the major benefits of writing .NET code to run in the Common Language Runtime (CLR) hosted in any environment is code access security (CAS).

CAS provides a code-based rather than user-based authorization scheme to prevent various kinds of luring and other code attacks. But how does that security scheme coexist with SQL Server 2005's own, newly enhanced security features? By default your .NET code is reasonably secure, but it's all too easy for the two security schemes to butt heads and cause you grief. In this article I'll look briefly at the concept behind CAS and a few new security features in SQL Server 2005, then explore how to make the two systems work for you instead of against you as you take advantage of these advanced programming features in SQL Server.

The good news is that Microsoft did a great job bringing together the security systems of SQL Server and the Common Language Runtime, with tools to control code. But there are some interesting features—both to watch for and to take advantage of!

Don Kiely gives a complete detail about and how to secure ur SQL Server, chk it out।

Page 1: Introduction
Page 2: Securely Hosting SQLCLR Code

Page 3: SQL Server-Level Security
Page 4: SQLCLR Permission Set Levels
Page 5: Accessing External Resources
Page 6: It's Secure Enough