SQL Server CLR - 레지스트리 읽기

SQL Server 2005 버전 부터 기존 Native 확장프로시저의 개념으로 .net 환경의 CLR 코드의 통합을 제공한다

기본 네이티브 확장프로시저는의 문제점은 위험한 코드로 인해 SQL Server 자체의 보안이나 실행에 영향을 줄수 있다는것인데 2005 부터 지원되는 CLR의 경우 SQL Server와 실행의 완벽한 분리로 리스크를 최소한으로 줄였다고 한다.


이번에 SQL Server 암호화 모듈을 위해 Native 확장프로시저및 CLR 코드로 만들어 비교해 봤는데 CLR 의 압승이었다

Native의 경우 crypto++ 이라는 라이브러리로 래핑을 하였고 CLR의 경우 System.Security.Cryptography 의 라이브러리를 사용해서 만들었다.

대강의 느낌은 CLR 쪽이 3배 이상 빠른것으로 판단이되며 추측키로는 C++의 경우 확장프로시저 내의 객체 인스턴스 메모리의 할당하는 부분에서 승패를 가르지 않았는가 생각이 들지만 확인은 못해봤다.
아니면 알고리즘 구현 자체에 품질 문제 일수도 있을테고...

어찌 되었던 원래의 목적인 다중키 관리를 위해 키 저장소가 필요했고 키 저장소를 위해 xml 파일등 보다는 레지스트리에 저장을 하는것이 바이너리저장및 나름의 이점이 있지 않을까 생각이 들었고, 간단한 WinForm 을 제작하여 테스트를 해보았을때도 문제가 없었다.

그리고 CLR로 올리고 테스트 하는순간 레지스트리 접근을 못한다는것을 알았다

이유인 즉..
디폴트로 SQL Server CLR를 배포했을 경우 권한 수준이 "안전"(SAFE)수준으로 배포가 되어 SQL Server 이외의 리소스에 대해서 접근이 안됐다.

그래서 권한 수준을 "외부"나 "안전하지 않음"으로 배포를 해야 한는데 배포를 하면 다음과 같은 에러가 발생한다.

오류: 어셈블리 'IntCryptNetProc'에 PERMISSION_SET = EXTERNAL_ACCESS에 대한 권한이 없으므로 어셈블리 'IntCryptNetProc'에 대한 CREATE ASSEMBLY가 실패했습니다. 어셈블리는 DBO(데이터베이스 소유자)에게 EXTERNAL ACCESS ASSEMBLY 권한이 있고 데이터베이스에 TRUSTWORTHY 데이터베이스 속성이 있는 경우 또는 어셈블리가 현재 인증서로 서명되어 있거나 EXTERNAL ACCESS ASSEMBLY 권한이 있는 관련 로그인을 소유한 비대칭 키로 서명되어 있는 경우에 권한이 부여됩니다. 이 데이터베이스를 복원하거나 연결한 경우 데이터베이스 소유자가 이 서버의 올바른 로그인에 매핑되어 있는지 확인하십시오. 그렇지 않으면 sp_changedbowner를 사용하여 문제를 해결하십시오.

결론은 "권한이 있는 계정"으로 "TRUSTWORTHY 데이터 베이스 속성"이 되어있는 Database 에만 "외부"나 "안전하지 않음"의 권한 수준을 가지는 CLR를 배포할수 있다.

권한있는 계정은 sa나 그에 상응한는 계정으로 처리하면 되고 TRUSTWORTHY 데이터 베이스 속성은 아래와 같이 만들면 된다.

ALTER DATABASE SecureDB SET TRUSTWORTHY ON;

이번 CLR을 테스트 해보면서 거듭 느낀점은 .net 코드도 충분히 쓸만하게 성능이 나온다는것이다
경우에 따라서는 기존 native 보다 더 좋은 성능이 나오는것에 대해서 당황(?)을 하기도 하지만.. ^^


참고 :
http://technet.microsoft.com/ko-kr/library/ms345101.aspx
http://technet.microsoft.com/ko-kr/library/ms187861.aspx
http://msdn.microsoft.com/en-us/library/ms189524.aspx


ps.
위에 사항을 해결하기 위해 RegistryPermission 라는 클래스를 많이 찾아보았는다. (삽질..)
물론 직접적인 도움이 되지는 않았지만 먼가가 새로운 세계가 있는 갑다. 흐흐..