Monday, June 27, 2011
To CLR or Not To CLR
After looking at the below STIG entries, my recommendation is that CLR should be disabled on an instance that hosts legacy databases and a separate instance should be maintained for newer databases that use CLR.
While stored procedures remain a preferred way of doing things, in some cases you may need to do something very complex that might be better developed and maintained in managed code.
In this case, CLR would be the preferred solution instead of making calls from within the DBMS out to code that is external to the DBMS environment.
If CLR is required, then this needs to be documented in the System Security Plan that "access to CLR applications is required."
http://iase.disa.mil/stigs/content_pages/database_security.html
U_INS_sqlserver9_v8r1.7_Checklist_20100827.pdf
STIG ID: DM6123
Use of Command Language Runtime objects should be disabled if not required.
STIG ID: DG0099-SQLServer9
Vulnerability: DBMS’s may spawn additional external processes to execute procedures that are defined in the DBMS, but stored in external host files (external procedures) or to executables that reside on the external host.
Fix: Redesign applications to use CLR integration.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment