EXECUTE AS를 사용하여 데이터베이스 가장 확장
SQL Server에서는 독립 실행형 EXECUTE AS 문을 사용하여 명시적으로 또는 모듈에서 EXECUTE AS 절을 사용하여 암시적으로 다른 보안 주체를 가장할 수 있습니다. 독립 실행형 EXECUTE AS 문의 경우 EXECUTEAS LOGIN 문을 사용하여 서버 수준의 보안 주체 또는 로그인을 가장할 수 있습니다. 또한 EXECUTE AS USER 문을 사용하여 데이터베이스 수준의 보안 주체 또는 사용자를 가장할 수도 있습니다.
모듈의 EXECUTE AS 절을 통해 수행되는 암시적 가장은 데이터베이스 수준 또는 서버 수준에서 지정한 사용자 또는 로그인을 가장합니다. 이러한 가장은 모듈이 저장 프로시저 또는 함수와 같은 데이터베이스 수준 모듈인지 아니면 서버 수준 트리거와 같은 서버 수준 모듈인지에 따라 달라집니다.
가장 범위 이해
EXECUTE AS LOGIN 문을 사용하여 보안 주체를 가장하거나 EXECUTE AS 절을 사용하여 서버 범위의 모듈 내에서 보안 주체를 가장하는 경우 가장 범위는 서버 전체입니다. 즉, 컨텍스트 전환 이후에 가장된 로그인이 그 사용 권한을 갖는 서버 내 모든 리소스에는 액세스가 가능합니다.
그러나 EXECUTE AS USER 문을 사용하여 보안 주체를 가장하거나 EXECUTE AS 절을 사용하여 데이터베이스 범위 모듈 내에서 보안 주체를 가장하는 경우 가장 범위는 기본적으로 데이터베이스로 제한됩니다. 그러므로 데이터베이스 범위를 벗어난 개체를 참조하면 오류가 반환됩니다. 이와 같이 기본 동작이 수행되는 이유를 이해하려면 다음 시나리오를 살펴보십시오.
데이터베이스 내에서는 모든 사용 권한을 갖는 데이터베이스 소유자도 해당 데이터베이스 범위 밖에서는 아무런 사용 권한이 없을 수 있습니다. 따라서 SQL Server에서는 데이터베이스 소유자가 자신의 현재 사용 권한 범위를 벗어나는 리소스에 액세스하기 위해 다른 사용자를 가장할 수 없으며 다른 사람이 가장하도록 권한을 부여할 수도 없습니다.
예를 들어 호스팅 환경에서 소유자가 서로 다른 두 개의 데이터베이스가 있다고 가정합니다. Database1의 소유자는 Bob이고 Database2의 소유자는 Fred입니다. Bob과 Fred는 다른 사람이 자신의 데이터베이스 내에 있는 리소스에 액세스하는 것을 원하지 않습니다. Bob은 Database1의 소유자로서 자신의 데이터베이스에 Fred를 위한 사용자 계정을 만들 수 있습니다. Bob은 Database 1의 모든 사용 권한을 가지고 있기 때문에 Fred를 가장할 수도 있습니다. 그러나 SQL Server의 보안 제한 사항으로 인해 Bob은 가장된 컨텍스트에서는 Fred의 데이터베이스에 액세스할 수 없습니다. 이러한 기본 제한 사항이 없다면 Bob은 Fred가 모르게 Fred의 데이터에 액세스할 수 있을 것입니다. 이러한 이유로 데이터베이스 수준 가장은 기본적으로 데이터베이스로 제한됩니다.
그러나 경우에 따라서는 가장 범위를 데이터베이스 외부로 선택적으로 확장하는 것이 유용할 수도 있습니다. 예를 들어 두 개의 데이터베이스를 사용하는 응용 프로그램의 경우 한 데이터베이스에서 다른 한 데이터베이스에 액세스해야 할 때가 있습니다.
Marketing 데이터베이스에서 GetSalesProjections라고 하는 저장 프로시저를 호출하는 마케팅 응용 프로그램이 있다고 가정합니다. 이 저장 프로시저에는 실행 컨텍스트 전환이 정의되어 있습니다. 이 저장 프로시저는 Sales 데이터베이스를 호출하여 SalesStats 테이블에서 판매 정보를 검색합니다. 기본적으로 한 데이터베이스 내에서 설정한 실행 컨텍스트는 해당 데이터베이스 밖에서는 유효하지 않기 때문에 이 시나리오는 실행되지 않습니다. 그러나 마케팅 응용 프로그램 개발자는 사용자가 Sales 데이터베이스에 직접 액세스하거나 데이터베이스 내 개체에 대해 사용 권한을 얻는 것을 원하지 않습니다. 가장 좋은 방법은 저장 프로시저에서 EXECUTE AS 절을 사용하여 Sales 데이터베이스에서 필요한 사용 권한이 있는 사용자를 가장하는 것입니다. 그러나 현재 적용되어 있는 기본 제한 사항으로 인해 이 작업은 수행할 수 없습니다. 따라서 문제는 개발자가 이것을 어떻게 해결할 수 있는지에 있습니다.
SQL Server에서는 두 데이터베이스 간에 트러스트 모델을 설정하여 한 데이터베이스 내에서 설정한 데이터베이스 가장 범위를 선택적으로 확장할 수 있습니다. 그러나 이 트러스트 모델 및 선택적인 가장 범위 확장 방법을 알아보기 전에 SQL Server에서의 인증 및 인증자 역할에 대해 이해해야 합니다.
인증자 이해
인증이란 특정 보안 주체가 자신의 ID를 설정하고 시스템에 증명하는 프로세스를 말합니다. 인증자는 특정 보안 주체의 신뢰성을 인증하거나 보증하는 엔터티입니다. 예를 들어 SQL Server에 연결할 때는 SQL Server 인스턴스에서 이 연결에 대해 설정된 로그인이 인증됩니다.
EXECUTE AS LOGIN 문을 사용하여 서버 수준에서 컨텍스트 전환을 명시적으로 수행하는 사용자가 있다고 가정합니다. 이 경우 서버 수준의 가장 권한이 필요합니다. 이러한 가장 권한을 통해 권한의 피부여자인 EXECUTE AS LOGIN 문의 호출자는 SQL Server 인스턴스 내 어디서나 지정된 로그인을 가장할 수 있게 됩니다. 호출자는 실제로 이 문을 통해 로그인 동작을 가장된 로그인으로 시뮬레이션할 수 있습니다. 서버 수준의 사용 권한 범위 소유자는 SQL Server 인스턴스를 소유하고 있는 sysadmin입니다. 서버 수준 가장의 경우 인증자는 sysadmin 또는 SQL Server 인스턴스 자체입니다.
그러나 EXECUTE AS USER 문 또는 데이터베이스 범위 모듈에서의 EXECUTE AS 절에 따라 컨텍스트가 설정된 경우를 가정해 봅니다. 이 경우 데이터베이스 범위 내에서 가장 권한이 확인됩니다. 사용자에 대한 IMPERSONATE 권한의 기본 범위는 데이터베이스 자체이며 이 데이터베이스의 소유자는 dbo입니다. 또한 이 가장의 인증자는 데이터베이스 소유자입니다. 실제로, 가장된 사용자의 ID를 설정하고 그 신뢰성을 보증하는 주체는 데이터베이스 소유자입니다. 데이터베이스 소유자는 전체 데이터베이스를 소유하기 때문에 가장된 컨텍스트는 해당 데이터베이스 내의 모든 곳에서 인증된 것으로 간주됩니다. 그러나 이 데이터베이스 외부에서는 가장된 컨텍스트가 유효하지 않습니다.
인증자 사용 방법
인증자는 특정 범위 내에서 설정된 컨텍스트가 유효한지 확인하는 데 사용됩니다. 인증자는 주로 SA(시스템 관리자) 또는 SQL Server 인스턴스이며 데이터베이스의 경우에는 dbo입니다. 인증자는 실제로 특정 사용자 또는 로그인에 대한 컨텍스트가 설정되어 있는 범위의 소유자입니다. 이 인증자 정보는 로그인 및 사용자에 대해 유지 관리되는 토큰 정보에 캡처되며 sys.user_token 및 sys.login_token 뷰를 통해 볼 수 있습니다. 자세한 내용은 실행 컨텍스트 이해를 참조하십시오.
[!참고]
인증자 정보가 토큰 뷰에 반환되지 않은 경우 인증자는 SQL Server 인스턴스입니다. 이것은 컨텍스트 전환이 수행되지 않았거나 가장이 서버 수준에서 수행되는 경우에 해당합니다.
범위 소유자가 인증자로 포함되어 있는 실행 컨텍스트는 해당 범위에서 유효합니다. 그 이유는 데이터베이스와 같은 범위 소유자가 이 범위 내의 모든 엔터티에 의해 암시적으로 트러스트되기 때문입니다. 이 컨텍스트는 인증자가 트러스트되는 다른 데이터베이스 또는 SQL Server 인스턴스 자체와 같이 다른 범위에서도 유효합니다. 따라서 데이터베이스 범위 밖에서 가장된 사용자 컨텍스트의 유효성은 이 컨텍스트의 인증자가 대상 범위에서 트러스트되는지 여부에 따라 결정됩니다. 이 트러스트는 대상 범위가 다른 데이터베이스인 경우 인증자에게 AUTHENTICATE 권한을 부여하고 대상 범위가 SQL Server 인스턴스인 경우 AUTHENTICATE SERVER 권한을 부여함으로써 설정됩니다.
가장 범위 확장
데이터베이스 내 가장 범위를 다른 데이터베이스 또는 SQL Server 인스턴스와 같은 대상 범위로 확장하기 위해서는 다음 조건이 충족되어야 합니다.
인증자가 대상 범위에서 트러스트되어야 합니다.
원본 데이터베이스가 신뢰할 수 있음으로 표시되어야 합니다.
인증자 트러스트
위의 Sales 및 Marketing 데이터베이스 예를 사용할 경우 다음 그림에서는 Marketing 데이터베이스에서 저장 프로시저 GetSalesProjections를 통해 Sales 데이터베이스의 SalesStats 테이블에 있는 데이터에 액세스하는 것을 보여 줍니다. 이 저장 프로시저에는 EXECUTE AS USER MarketingExec 절이 포함되어 있습니다. Sales 데이터베이스의 소유자는 SalesDBO이며 Marketing 데이터베이스의 소유자는 MarketingDBO입니다.
.gif "모듈의 실행 컨텍스트를 전환하는 EXECUTE AS")
사용자가 GetSalesProjections 저장 프로시저를 호출하면 EXECUTE AS 절은 호출자에서 MarketingExec 사용자로 암시적으로 저장 프로시저에 대한 실행 컨텍스트 전환을 수행합니다. 이 컨텍스트의 인증자는 Marketing 데이터베이스의 소유자인 MarketingDBO입니다. 기본적으로 이 프로시저는 MarketingExec 사용자가 액세스할 수 있는 Marketing 데이터베이스 내의 모든 리소스에 액세스할 수 있습니다. 그러나 Sales 데이터베이스의 테이블에 액세스하려면 Sales 데이터베이스에서 인증자 MarketingDBO를 트러스트해야 합니다.
이렇게 하려면 MarketingDBO 로그인에 매핑되는 MarketingDBO라는 사용자를 Sales 데이터베이스에 만들고 이 사용자에게 Sales 데이터베이스에 대한 AUTHENTICATE 권한을 부여합니다. 결과적으로 이 권한의 피부여자가 인증자로 포함된 실행 컨텍스트는 해당 데이터베이스 내에서 유효합니다. 인증자 MarketingDBO에게 Sales 데이터베이스에 대한 AUTHENTICATE 권한이 부여되었으므로 Marketing 데이터베이스에서 GetSalesProjections 저장 프로시저의 EXECUTE AS 절로 설정된 사용자 MarketingExec의 컨텍스트는 Sales 데이터베이스에서 트러스트됩니다.
이 예에서는 외부 데이터베이스의 객체에 액세스할 수 있도록 가장 범위를 확장하는 방법을 보여 주지만 가장 범위를 SQL Server 인스턴스로 확장하는 것도 가능합니다. 예를 들어 이 프로시저가 서버 차원의 권한을 요구하는 서버 수준 동작의 로그인을 만드는 경우 AUTHENTICATE SERVER 권한을 해당 컨텍스트의 인증자에게 부여해야 합니다. 그러면 AUTHENTICATE SERVER 권한의 피부여자가 인증자로 포함된 컨텍스트가 마치 SQL Server 인스턴스에 직접 로그인한 것처럼 SQL Server의 전체 인스턴스에서 트러스트됩니다.
데이터베이스 트러스트
SQL Server에서 트러스트 모델은 데이터베이스 수준의 가장 범위를 확장하는 동작에 추가적인 보안 및 세분성을 제공하기 위해 한 단계 더 진행됩니다. 대상 범위에서 컨텍스트 인증자를 트러스트하는 방법으로 AUTHENTICATE 권한을 사용할 수 있을 뿐 아니라 SQL Server 인스턴스에서 원본 데이터베이스 및 그 내용을 트러스트하는지 확인할 수도 있습니다.
이를 설명하기 위해 MarketingDBO 보안 주체가 Conference라는 이름의 다른 데이터베이스를 소유한다고 가정합니다. 또한 MarketingDBO는 Marketing 데이터베이스 내에서 지정된 실행 컨텍스트에 Sales 데이터베이스의 리소스에 대한 액세스 권한이 부여되기를 원한다고 가정합니다. 반면 이 보안 주체는 Conference 데이터베이스에서 설정된 컨텍스트에는 Sales 데이터베이스에 대한 액세스 권한이 부여되지 않기를 원합니다.
이와 같은 요구 사항을 충족하려면 가장 컨텍스트를 데이터베이스 외부의 리소스에 액세스하는 데 사용하는 모듈이 포함된 데이터베이스가 신뢰할 수 있음으로 표시되어야 합니다. TRUSTWORTHY 속성은 SQL Server 인스턴스가 데이터베이스 및 그 내용을 트러스트하는지 여부를 나타냅니다. TRUSTWORTHY 속성은 두 가지 목적으로 사용됩니다.
SQL Server 인스턴스에 연결되어 있으며 높은 수준의 권한을 가진 사용자의 컨텍스트에서 실행되도록 정의된 악의적인 모듈을 포함할 가능성이 있는 데이터베이스에서 기인하는 위협을 줄입니다.
연결된 데이터베이스는 기본적으로 신뢰할 수 있음으로 표시되지 않습니다. 또한 악의적일 가능성이 있는 모듈을 통해 데이터베이스 외부의 리소스에 액세스하기 위해서는 해당 데이터베이스가 신뢰할 수 있음으로 표시되어야 합니다. 데이터베이스의 TRUSTWORTHY 속성은 sysadmin 고정 서버 역할의 멤버만 설정할 수 있습니다.
데이터베이스 소유자가 동일하고 이 소유자가 특정 범위에서 인증자로 트러스트되는 경우 SQL Server 인스턴스 관리자가 외부 리소스에 액세스할 수 있도록 허용해야 하는 데이터베이스와 허용해서는 안 되는 데이터베이스를 구별할 수 있게 해 줍니다.
이 동작은 TRUSTWORTHY 속성을 사용하여 제어할 수 있습니다. 예를 들어 Database 1의 가장된 컨텍스트는 트러스트해야 하는 반면에 Database 2의 컨텍스트는 트러스트해서는 안 되는 상황을 가정합니다. 이때 두 데이터베이스의 소유자는 동일하고 이 소유자는 대상 범위에서 인증자로 트러스트됩니다. TRUSTWORTHY 속성을 database1에 대해서는 ON으로 설정하고 database2에 대해서는 OFF로 설정하여 Database 2의 모듈에서는 이 데이터베이스 외부의 리소스에 액세스할 수 없도록 지정할 수 있습니다.
다음 그림에서는 TRUSTWORTHY 데이터베이스 속성을 사용하여 원본 데이터베이스 범위 외부의 리소스에 대한 액세스를 제어하는 방법을 보여 줍니다. MarketingDBO는 Sales 데이터베이스에서 AUTHENTICATE 권한을 가지며 Marketing 및 Conference 데이터베이스의 소유자입니다. Marketing 데이터베이스의 GetSalesProjections 저장 프로시저는 두 가지 보안 요구 사항을 만족하기 때문에 Sales 데이터베이스에 액세스할 수 있습니다. 즉, 인증자 MarketingDBO가 대상 범위에서 트러스트되고 원본 데이터베이스인 Marketing은 신뢰할 수 있습니다. Conference 데이터베이스에서 Sales 데이터베이스에 액세스하려고 시도하는 경우에는 인증자 MarketingDBO가 대상 범위에서 트러스트되어야 한다는 한 가지 요구 사항만 충족되기 때문에 거부됩니다.
.gif "외부 리소스에 대한 데이터베이스 액세스 제어")
가장된 컨텍스트를 사용하여 데이터베이스 범위 외부의 리소스에 액세스하려고 시도할 때마다 SQL Server 인스턴스에서는 이 요청을 보낸 데이터베이스가 신뢰할 수 있는 것인지, 그리고 해당 인증자가 트러스트되었는지를 확인합니다.
인증자로서 인증서 및 비대칭 키
데이터베이스 소유자를 인증자로 사용함으로써 데이터베이스 내에 설정된 가장 컨텍스트를 확장하여 데이터베이스 범위 외부의 리소스에 액세스할 수 있습니다. 이 작업을 수행하려면 데이터베이스 소유자가 외부 리소스에서 트러스트되어야 하며 데이터베이스 자체도 신뢰할 수 있는 것이어야 합니다. 그러나 이 방법을 사용하기 위해서는 트러스트된 데이터베이스 소유자에게 대상 범위에서의 AUTHENTICATE 또는 AUTHENTICATE SERVER 권한이 부여되고 호출하는 데이터베이스를 신뢰할 수 있는 경우 데이터베이스에 설정된 가장 컨텍스트가 데이터베이스 소유자를 트러스트하는 대상 범위에서 유효해야 합니다.
더욱 세부적인 트러스트 수준이 필요할 수 있습니다. 원본 데이터베이스 전체를 트러스트하지 않고 EXECUTE AS 절을 사용하여 원본 데이터베이스에 포함된 모듈 몇 개만 트러스트하여 대상 리소스에 액세스해야 하는 비즈니스 요구 사항이 있다고 가정합니다. 예를 들어 GetSalesProjections 저장 프로시저만 MarketingExec 사용자로서 SalesStats 테이블에 액세스할 수 있도록 허용하고 Marketing 데이터베이스에서 MarketingExec에 대한 가장 권한이 있는 모든 사용자는 Sales 데이터베이스의 리소스에 액세스할 수 없도록 설정하려는 SalesDBO가 있다고 가정합니다. MarketingDBO를 트러스트하고 Marketing 데이터베이스를 신뢰할 수 있음으로 설정하더라도 이 태스크를 수행할 수는 없습니다. 트러스트 모델에서는 이러한 요구 사항에 부합하는 추가적인 세분성 수준을 제공하기 위해 인증서 또는 대칭 키를 인증자로 사용할 수 있습니다. 이를 위해 서명이라는 기술이 사용됩니다. 서명에 대한 자세한 내용은 ADD SIGNATURE(Transact-SQL)를 참조하십시오.
서명 사용
모듈에 대한 서명은 모듈을 서명하는 데 사용되는 개인 키에 대한 액세스 권한이 있는 사람만 모듈 내의 코드를 수정할 수 있음을 증명합니다. 서명 프로세스가 보증하는 내용을 확인함으로써 서명에 지정된 인증서 또는 비대칭 키를 트러스트할 수 있습니다. 더욱 정확하게 보면 데이터베이스 소유자 대신 인증서 또는 비대칭 키의 소유자를 트러스트할 수 있는 것입니다.
대상 범위에서 인증서 또는 비대칭 키에 매핑된 사용자에게 AUTHENTICATE 또는 AUTHENTICATE SERVER 권한을 부여함으로써 서명된 모듈을 트러스트할 수 있습니다.
이 방법을 사용하면 트러스트된 인증서를 통해 서명된 모듈 내에서 설정된 실행 컨텍스트는 해당 인증서가 트러스트되는 대상 범위에서 유효합니다.
예를 들어 C1이라는 인증서를 사용하여 GetSalesProjections 프로시저에 서명했다고 가정합니다. 인증서 C1은 Sales 데이터베이스에 있어야 하며 CertUser1과 같은 사용자는 인증서 C1에 매핑되어야 합니다. 그런 다음 CertUser1에는 Sales 데이터베이스에 대한 AUTHENTICATE 권한이 부여됩니다.
이 프로시저가 호출되면 서명된 후 손상되지 않았는지 확인하기 위해 해당 서명이 검사됩니다. 서명이 확인되면 모듈에서 EXECUTE AS 절로 설정된 컨텍스트는 인증자로서 인증서 C1을 갖게 됩니다. 서명이 확인되지 않은 경우 인증자는 토큰에 추가되지 않으며 외부 리소스에 액세스할 수 없습니다.
다음 그림에서는 서명된 모듈을 사용하여 원본 데이터베이스 범위 외부의 리소스에 대한 액세스를 제어하는 방법을 보여 줍니다. Marketing 데이터베이스에서 GetSalesProjections 프로시저는 C1이라는 인증서를 통해 서명됩니다. 인증서 C1은 Sales 데이터베이스에 있으며 사용자 CertUser는 이 인증서에 매핑됩니다. CertUser1에는 Sales 데이터베이스에 대한 AUTHENTICATE 권한이 부여됩니다.
.gif "데이터베이스 액세스를 제한하는 데 사용되는 인증서")
데이터베이스 소유자가 인증자인 경우 트러스트가 확인되는 것과 동일한 방법으로 이 인증자에 대한 트러스트가 확인됩니다. 즉, AUTHENTICATE SERVER 또는 AUTHENTICATE 권한을 확인하여 트러스트가 확인됩니다. 그러나 트러스트가 세부적인 수준에서 설정되고 서명을 수정하지 않고는 모듈을 변경할 수 없기 때문에 데이터베이스에서 TRUSTWORTHY 속성을 확인할 필요는 없습니다.
이를 통해 악의적인 코드를 포함하고 있는 연결된 데이터베이스에서 기인하는 위협을 줄일 수 있습니다. 공격자가 침입하기 위해서는 이미 트러스트된 인증서에 해당하는 개인 키를 사용하여 모듈에 서명해야 합니다. 그러나 공격자는 이 키에 액세스할 수 없습니다. 또한 트러스트된 기존 모듈이 수정되거나 새 모듈이 생성되는 경우 이 모듈은 유효한 트러스트 서명을 갖지 못하게 됩니다.
자세한 내용은 모듈 서명(데이터베이스 엔진)을 참조하십시오.
데이터베이스 가장 범위 확장 규칙
요약하자면 다음 조건을 만족하는 경우에만 데이터베이스 내에서 설정된 컨텍스트의 가장 범위를 다른 범위로 확장할 수 있습니다.
데이터베이스 소유자 또는 모듈에 서명할 때 사용하는 인증서나 비대칭 키와 같은 인증자는 대상 범위에서 트러스트되어야 합니다. 이렇게 하려면 데이터베이스 소유자, 인증서 또는 비대칭 키에 매핑되는 보안 주체에 AUTHENTICATE 또는 AUTHENTICATE SERVER 권한을 부여합니다.
인증자가 데이터베이스 소유자인 경우 원본 데이터베이스는 신뢰할 수 있음으로 표시되어야 합니다. 이렇게 하려면 데이터베이스에 대해 TRUSTWORTHY 속성을 ON으로 설정합니다.
필요에 맞는 트러스트 메커니즘 선택
데이터베이스 소유자 방식과 서명 방식에는 각각 장단점이 있습니다. 필요에 맞는 가장 적합한 메커니즘은 비즈니스 요구 사항과 환경에 따라 다릅니다.
데이터베이스 소유자 방식
데이터베이스 소유자를 사용하여 트러스트를 설정하는 방식에는 다음과 같은 장점과 단점이 있습니다.
인증서나 서명과 같은 암호화 개념을 이해할 필요가 없습니다.
서명 방식과 같은 세분성 수준을 제공하지 않습니다.
데이터베이스를 SQL Server 인스턴스에 연결하면 데이터베이스의 TRUSTWORTHY 속성이 OFF로 설정됩니다. 데이터베이스 소유자가 트러스트한 모듈은 시스템 관리자가 명시적으로 TRUSTWORTHY 속성을 ON으로 설정해야만 유효합니다. 따라서 연결된 데이터베이스가 원하는 대로 작동하고 다른 데이터베이스에 액세스할 수 있으려면 시스템 관리자가 개입해야 합니다.
서명 방식
서명을 사용하여 트러스트를 설정하는 방식에는 다음과 같은 장점과 단점이 있습니다.
서명된 모듈 내에서 수행되는 컨텍스트 전환에만 세부적인 트러스트 수준을 제공할 수 있습니다.
독립 실행형 EXECUTE AS USER 및 EXECUTE AS LOGIN 문을 통해 설정된 컨텍스트 전환에는 서명을 적용할 수 없습니다. 이 문을 사용하려면 데이터베이스 소유자 방식으로 트러스트 범위를 확장해야 합니다.
응용 프로그램 공급업체나 개발자는 개인 키를 사용하여 모듈에 서명할 수 있지만 모듈이나 데이터베이스를 출시하기 전에 이 개인 키를 제거해야 합니다. 이 방식에서 개인 키는 모듈에 서명하는 데만 사용되기 때문입니다. 서명을 확인하기 위해서는 모듈에 연결된 공개 키만 있으면 됩니다.
서명을 사용하기 때문에 데이터베이스를 연결하더라도 트러스트된 모듈은 영향을 받지 않습니다. 추가적인 요구 사항 없이도 제대로 작동합니다.