SQL Server 2005의 최신보안 기능을 이용한 해커 저지하기
이 기사는 SQL Server 2005의 프리릴리즈 버전에 근거합니다. 여기에 실린 모든 정보는 변경될 수 있습니다.
This article discusses:
지금은 여러분의 데이터베이스와 클라이언트 응용프로그램에 대해 더욱 더 적대적인 세상입니다. 공격자들은 매일 여러분의 귀중한 데이터를 손상시키기 위해 새롭고 영리한 공격을 개발합니다. 다행스럽게 SQL Server 2005은 철저한 방어와 최소 권한 같은 원칙을 전적으로 다루는 강력한 새로운 보안 기능들을 제공합니다. SQL Server 온라인 설명서에서 설명된 것처럼 Microsoft는 변화하는 보안 상황에 높을 보안을 유지하는 것에 관한 보다 나은 보안 도구와 문서를 제공하면서, 공격 표면적을 줄이고 SQL Server와 데이터베이스를 안전하게 배포하는 것을 쉽게 하는 많은 보안 전략을 구현했습니다.
이 문서에서는 개발자 관점에서 SQL Server2005내에서 가장 흥미로운 보안 기능 향상에 대해서 알아볼 것입니다. 저자는 TechNet Magazine (영문)의 2005년 봄호에서 관리자 보안 기능들에 대해서 다루었습니다. 그러나 종단점 인증과 서버에서 실행하는 관리 코드의 보안 컨텍스트에 대한 지원 같은 수많은 개발자 기능 향상이 있습니다. 저자는 핵심 관계형 데이터베이스 엔진에만 집중할 것입니다. Reporting Service나 Analysis Service 같은 지원 시스템은 전체기사를 할애할만한 가치가 있는 자체 보안 기반구조를 가지고 있습니다.
사용 권한
SQL Server 2000과 그 이전 버전은 사용자, 로그인 및 다른 대리 사용자(principal) 에게 권한을 할당하는 합리적인 스키마를 가지고 있습니다. 그러나 이런 버전의 SQL Server에 대한 락 다운(lock down)을 시도할 때 여러분은 강력한 보안을 구현하기 위해 날카로운 해부용 메스라기 보다는 상당히 뭉툭한 도구를 가지고 작업을 하고 있습니다. 여러분은 종종 사용자에게 사용자가 필요로 하는 권한 뿐만 아니라 사용자가 필요로 하지 않은 다른 많은 권한을 가지는 고정 역할을 사용자에게 할당해야만 합니다. 이것은 개개의 사용자나 다른 대리 사용자가 더도 말고 덜도 말고 딱 필요한 권한만 가진다는 최소 권한 원칙의 심각한 위반입니다.
SQL Server 2005에서는 부여할 수 있는 권한이 이전 버전보다 훨씬 한정되었습니다. 사실상 어떤 개체든 실질적인 대리 사용자에 수여할 수 있는 다양한 권한을 가지고 있습니다. SQL Server는 여전히 서버와 데이터베이스 수준에서 역할을 많이 사용합니다만 사용자 요구가 특정한 자원에 대한 제한된 액세스일 때 더 이상 사용자를 역할에 추가할 필요가 없습니다.
SQL Server 2005의 보안 용어에서, 대리 사용자(principal)는 보호되는 자원에 액세스하는 요청을 할 수 있고 이것에 액세스 하기 위해서 권한이 부여 되는 어떤 개인, 그룹(역할), 또는 프로세스입니다. 이전 버전의 SQL Server에서처럼 대리 사용자는 Windows내에 정의 할 수 있고 하거나 일치하는 Windows 대리 사용자 없이도 SQL Server 로그인을 기반으로 할 수 있습니다. 그림 1 에서는 고정 서버 역할과 고정 데이터베이스 역할을 제외한 SQL Server 2005 대리 사용자 계층구조를 보여주며 어떻게 로그인과 데이터베이스 사용자 보안 개체에 매핑될 수 있는지를 보여줍니다. 이전 버전에서처럼 SQL Server 2005에서 대리 사용자의 영향이 미치는 범위는 이것의 정의 범위 에 달려 있습니다. 따라서 Windows 수준 대리 사용자는 SQL 서버 수준 대리 사용자를 포함하고 SQL 서버 수준 대리 사용자는 데이터베이스 수준 대리 사용자를 포함합니다. 모든 데이터베이스 사용자는 자동적으로 고정 공용(Public) 역할에 속합니다.
또한 주목할만한 것은 개체는 사용 권한을 부여하고 거부함으로서 보호될 수 있다는 것입니다. 그림 2은 SQL Server 2005의 보호할 수 있는 개체 목록입니다. 서버 수준에서 서버로부터 와 서버로의 통신 채널을 제어하기 위한 네트워크 종단점뿐만 아니라 데이터베이스, 바인딩, 역할, 및 로그인을 보호할 수 있습니다. 데이터베이스와 스키마수준에서는 생성할 수 있는 모든 개체는, 특히 데이터베이스 개체들을 포함하기 위해 사용되는 스키마 개체, 사실상 보호할 수 있습니다.
그림 2 SQL Server 2005에 보호할 수 있는 개체들
고정 서버 역할들과 고정 데이터베이스 역할들은 SQL Server 2000와 비교해서 변경되지 않았습니다. 그래서 사용자나 응용프로그램이 전부 또는 대부분의 정의된 사용 권한을 요구할 때 이런 미리 정의된 사용 권한 묶음을 여전히 이용할 수 있습니다. 그러나 최소 권한 원칙하에서는 여러분은 대리 사용자에게 초과 권한을 부여하는 역할을 사용하기를 원하지 않을 것입니다. 비록 대리 사용자에 필요한 권한을 알아내고 사용 권한을 할당하는 것은 약간의 일을 더하게 되지만 이것은 좀 더 안전한 데이터베이스 환경일 수 있습니다.
SQL Server에서 사용 가능한 사용 권한의 숫자에 대해 알기 위해서, builtin_permissions 카타로그 뷰를 볼 수 있습니다:
SELECT * FROM sys.fn_builtin_permissions(default)
4월의 CTP에서는 모든 사용 권한을 나타내는 180행 이상의 행을 반환합니다; 여기서는 좀 더 중요한 몇 가지에 대해서 설명할 것입니다.
CONTROL사용 권한은 권한을 허가 받든 사용자(grantee)에게, 보호할 수 있는 개체에 사용 권한을 수여하는 능력을 포함하여, 소유권을 수여합니다. 계층구조내의 한 레벨에 있는 보호할 수 있는 개체가 CONTROL 권한을 가지고 있다는 것은 포함된 모든 개체에 같은 권한이 있다는 것을 뜻합니다.
ALTER ANY 엔터티 사용 권한은 엔터티 형태의 어떤 개체에 생성(create), 대체(alter), 및 삭제(drop)하는 권한을 수여합니다. 예를 들어 서버 수준의 ALTER ANY DATABASE 사용권한은 권한을 허가 받은 사용자가 어떤 데이터베이스든 대체할 수 있게 합니다. 특정한 데이터베이스 범위내의 ALTER ANY ASSEMBLY 사용 권한은 권한을 허가 받은 사용자가 어떤 어셈블리든 변경할 수 있도록 합니다.
IMPERSONATE ON 로그인 또는 IMPERSONATE ON 사용자는 권한을 허가 받은 사용자에게 특정한 로그인이나 데이터베이스 사용자를 가장할 수 있게 해서 가장된 보안 자격 증명을 사용하여 어떤 연산이든 수행됩니다. 이 사용 권한은 EXECUTE AS 기능(이 기사의 뒤에서 설명하는)에서는 중요합니다.
SQL Server 2005는 보호할만한 개체에 권한을 할당하고 거부하기 위해서 잘 알려진 GRANT, DENY,및 REVOKE 스키마를 여전히 사용합니다. GRANT 구문은 권한 부여 영역과 대리 사용자가 다른 대리 사용자에게 권한를 부여할 수 있는지 와 같은 새로운 권한 옵션을 포함하도록 확장되었습니다. 데이터베이스 간의 사용자 권한은 허용되지 않습니다. 데이터베이스 간의 사용자 권한 부여를 위해서, 각각의 데이터베이스에 복제 사용자를 만들고 각각의 데이터베이스 사용자에게 권한을 할당해야 합니다. 이전 버전의 SQL Server와 같이 응용프로그램 역할 활성화는 역할이 활성화되는 기간동안 다른 권한을 보류됩니다.
특정한 권한 부여는 함축을 통해서 다른 사용 권한을 옮길 수 있습니다. SQL Server 온라인 설명서에는 sys.fn_builtin_permissions 카테고리 뷰로부터 계층구조 목록을 모으고 각각 사용 권한의 깊이를 식별하는 ImplyingPermissions 사용자 정의 함수를 위한 T-SQL이 있습니다. 개체와 사용 권한 형태를 전달해서 사용 권한의 계층 구조 목록을 생성하기 위해 아래 구문을 실행 합니다:
SELECT * FROM master.dbo.ImplyingPermissions('schema', 'alter')
SQL Server 2005내에서 단지 얼마나 세밀한 사용 권한이 가능한지를 평가하는 것은 처음에는 어려울 것입니다. 서버와 대표적인 데이터베이스내의 사용 가능한 대리 사용자의 숫자와 형태 그리고 보호할 수 있는 개체의 숫자를 고려하십시오(검토하십시오). 또한 사용 가능한 사용 권한과 포함되고 내포한 사용 권한의 숫자를 고려하십시오. 응용프로그램 생성은 좀더 자세한 분석 보안 요구사항에 대한 상세한 분석과 모든 개체의 사용권한을 주의 깊은 제어를 필요로 합니다. 그럼에도 불구하고 여전히 부여할 수 있는 권한을 가지지 않는 동작들이 있습니다. 예를 들면 TRUNCATE TABLE은 테이블에 단지 테이블의 행을 삭제하는 것 이상의 능력을 수여하는 ALTER 사용 권한을 필요로 한다.
카탈로그 뷰와 메타데이터 가시성
SQL Server 2005의 고도로 세밀한 권한 스키마의 장점은 현대 데이터베이스 엔진이 필요로 하는 메타데이터에 대한 보다 나은 보호를 할 수 있다는 것입니다. SQL Server는 SQL-92 명세에 정의 되어 있는 INFORMATION_SCHEMA 뷰, 서버와 데이터베이스 수준의 시스템 테이블, 그리고 시스템에 내장된 막대한 숫자의 저장 프로시저를 통해서 강력히 지원되는 리치(rich) 메타데이터를 가지고 있습니다. 시스템 안정성에 커다란 위험이 있지만 시스템 테이블을 수정해서 서버와 서버의 데이터베이스의 내재하는 상태 조차도 변경할 수 있습니다. Microsoft는 언제든지 내재하는 시스템 테이블을 변경할 수 있어서 이것을 사용한 것은 본인의 책임임을 끊임없이 상기시킵니다.
SQL Server 2005에서 Microsoft는 시스템 전체의 모든 메타데이터를 표시하는 새로운 카탈로그 뷰 집합을 만들었습니다. 새로운 sys 스키마는 메타데이터 뷰를 캡슐화 합니다. 카타로그 뷰들은 읽기 전용이며 이것은 이전 버전의 SQL Server에서 가능했던 해킹을 제거합니다. 많은 뷰들이 원하는 정보를 쉽게 찾기 위해서 예전 시스템 테이블의 이름과 같은 이름을 사용합니다. 예를 들어 sysobjects 메타데이터 sys.objects 뷰를 통해서 표시됩니다. 뷰 정의는 물리적으로 이 정의에 직접적으로 액세스하는 방법이 없는 알려지지 않은 (undocumented) 위치에 숨겨져 있습니다. (서버에 해킹을 해서 이것을 찾지 않으면) 그럼에도 불구하고 메시지는 명백합니다: 서버와 데이터베이스의 모든 데이터를 얻기 위해 카타로그 뷰를 이용하십시오. 그리고 이전 해킹에 대해서는 잊어버리십시오. 저장 프로시저, T-SQL, 및 그 밖의 SQL Server를 구성하고 조정(tweaking)하는 공식적인 방법을 준수하십시오. 이것은 모두 보안과 안정성을 위해서 입니다.
보안 관점에서 메타데이터를 표시하기 위해서 뷰를 사용하는 것의 장점은 카탈로그 뷰로부터 반환되는 데이터가 데이터를 요청하는 사용자 컨텍스트의 보안에 따라 필터된다는 것입니다. 예를 들어, 과거에는 데이터베이스내의 sysobject 테이블에 액세스하는 권한을 가지고 있는 사용자(대부분의 사용자는 많은 응용프로그램 내에서 합니다.)가 테이블에 대한 쿼리를 실행할 수 있고 데이터베이스에 있는 모든 사용가능한 개체를, 이 사용자가 각각의 개체에 대한 액세스가 있던 없던 상관없이, 볼 수 있었습니다. SQL Server 2005에서는 테이블을 보기 위해서는 테이블에 대한 SELECT 권한 같은 최소한의 액세스를 가지고 있어만 합니다. 만약 사용자가 데이터베이스에 대한 액세스를 가지고 있지만 이 데이터베이스 개체에 대해서는 액세스 없으면, sys.objects에 대한 쿼리는 아무런 결과 행을 반환하지 않습니다.
이것이 어떤 식으로 동작하는지 보기 위해서 다음의 코드를 관리자로 실행하십시오:
USE master
CREATE LOGIN User1 WITH password = 'myPassword'
-- 여러분이 선택한 데이터베이스를 사용하십시오
USE AdventureWorks
CREATE USER User1
EXECUTE AS LOGIN = 'User1'
SELECT * FROM sys.objects
-- 사용자 db내에 사용권한이 없기 때문에 아무런 행이 반환되지 안습니다.
REVERT
코드는 서버에 대한 User1 로그인을 생성하는 것으로 시작해서 로그인한 사용자와 매핑 되는 사용자를 예제 AdventureWorks 데이터베이스에 추가합니다. 그리고는 실행 컨텍스트를 User1으로 바꾸고 sys.objects로부터 데이터를 검색합니다. User1은 데이터베이스에 대한 액세스는 가지고 있지만 어떤 개체에 대한 권한도 없기 때문에 카타로그 뷰로부터 아무것도 반환되지 않습니다. REVERT 구문은 관리자로 실행 컨텍스트를 복귀시킵니다.
데이터가 반환되기 위해서는 두개의 권한을 사용자에게 부여해야만 합니다. 다음 코드는 Contact 테이블에 대한 SELECT 권한과 dbo.uspGetBillOfMaterials 저장 프로시저에 대한 EXECUTE 권한을 부여합니다.
-- 테이블과 저장 프로시저에 대한 권한을 부여 하십시오
GRANT SELECT ON Person.Contact TO User1
GRANT EXECUTE ON dbo.uspGetBillOfMaterials TO User1
-- User1으로 다시 실행하십시오
EXECUTE AS LOGIN = 'User1'
SELECT * FROM sys.objects
REVERT
User1으로 카타로그 뷰를 실행했을 때, sys.objects 카타로그 뷰로부터 Contact 테이블와 uspGetBillOfMaterials 저장 프로시저의 메타데이터뿐만 아니라 테이블 제약 조건과 트리거 같은 연관된 개체를 포함하는 아홉개의 행을 얻게 됩니다. 이것은 개체 계층구조의 한 수준에 권한을 부여하면 연관된 권한이 자식 개체에 부여되는 방법을 보여줍니다.
예상한 것처럼, sysadmins와 sa는 시스템 카타로그 뷰에서 서버에 있는 모든 것을 볼 수 있으며 데이터베이스 소유자는 데이터베이스의 모든 것을 볼 수 있습니다. 사용 권한 기반 필터링은 sp_help와 sp_helpdb 같은 별개의 개체에 대한 정보를 보여주는 시스템 저장 프로시저에도 적용합니다. 이런 시스템 저장 프로시저는 시스템 카타로그 뷰를 읽기 때문에, 프로시저를 실행하는 대리 사용자의 권한에 따라 필터링됩니다. 그렇지만 메타데이터 가시성의 한계가 아직까지는 모든 메타데이터 함수에 적용되지 않았기 때문에(OBJECTPROPERTY같은) 주의해야만 합니다.
대부분의 예전 시스템 테이블, 저장 프로시저, 및 뷰들은(모두 읽기 전용 뷰로 표시되는 것을 제외하고) 여전히 사용하는 가능합니다. 이것들은 이전 버전 호환을 위한 것이며 어떤 SQL Server 2005의 새로운 기능도 나타내지 않습니다.
사용자/스키마 분리
ANSI SQL-99 명세는 데이터베이스 스키마를 개체의 단일 네임스페이스로 구성하는 단일 대리 사용자가 소유한 데이터베이스 개체의 집합으로 정의 합니다. 스키마는 테이블, 뷰, 저장 프로시저, 함수, 타입, 트리거 같은 데이터베이스 개체를 포함하며 이것은 개체를 그룹화하는 간편한 방법이며 그래서 데이터베이스가 서로 다른 소유자 밑에서 개체 이름과 그룹 개체를 재사용할 수 있습니다.
SQL Server 2000에서는 그림 3의 제일 윗 부분에서 보는 것 같이 소요자와 스키마를 구별할 수 없었습니다. 만약 관리자가 데이터베이스 내에 Fred라는 이름의 사용자를 생성하면 Fred라는 이름의 스키마를 자동으로 생성하고 Fred 사용자 밑에 숨깁니다. Fred 사용자가 SQL Server에 로그인하고 Table1 테이블을 생성하면 테이블 이름은 Fred.Table1이 됩니다. Fred가 만드는 Fred.StoredProcedure와 Fred.View1같은 다른 개체에 대해서도 마찬가지 입니다. Fred가 데이터베이스의 소유자이면 Fred1 개체가 대신 생성되고 dbo 스키마의 일부가 됩니다.
그림 3 SQL Server내의 사용자와 스키마
Fred가 퇴사하고 George가 Fred의 일을 맡은 때 같은 개체의 소유권 변경이 필요할 때 문제가 발생합니다. 시스템 관리자는 Fred가 가지고 있는 모든 개체의 소유권을 변경해야만 합니다. Fred.Table1를 참조하는 T-SQL이나 클라이언트 응용프로그램 코드는 George가 테이블의 소유권을 획득한 후에 George.Table1로 변경되어야 합니다. Fred가 소유하고 있는 개체의 수와 얼마나 많은 응용프로그램이 내부에 이 이름을 포함하고 있는가에 따라서 이것은 복잡해질 수 있습니다.
SQL Server 2005는 이 문제를 해결하며 그림 3의 아래 부분에서 보는 것과 같이 사용자와 스키마를 분리함으로써 SQL-99스키마를 좀 더 엄격하게 구현합니다. 새로운 DDL 구문을 이용해서 Fred라는 이름의 사용자를 만들 때 SQL Server는 더 이상 자동으로 같은 이름의 스키마를 생성하지 않습니다. 대신에 명시적으로 스키마를 생성하고 소유권을 할당해야만 합니다. 모든 데이터베이스 개체가 MySchema 스키마 (처음에 Fred가 소유하는)에 포함되어 있기 때문에 스키마의 소유권을 George로 바꿈으로써 스키마의 모든 개체의 소유권을 바꾸는 것은 간단해 집니다. 각각의 사용자는 이 사용자에 할당되는 기본 스키마를 가지고 있어서 스키마 참조 없이 이름으로 참조되는 어떤 개체든 기본 스키마 내에 있다고 여겨집니다. 그래서 그림 3의 아래 부분에서 사용자 Fred가 기본 스키마로 MySchema를 가지고 있으면 테이블을 MySchema.Table1나 또는 간단히 Table1로 참조할 수 있습니다. George는 아마도 이름에 연관된 기본 스키마가 없어서 테이블을 참조 할 때 MySchema.Table1로 참조해야만 할 겁니다. 지정된 기본 스키마가 없는 사용자는 기본적으로 dbo를 갖습니다.
그림 4 는 이것이 어떻게 작동하는지를 보여줍니다. 코드는 Carol이라는 이름의 로그인을 만드는 것으로 시작하고 CREATE TABLE 권한을 가지는 Pub 데이터베이스의 Carol이라는 이름의 사용자를 생성합니다. 코드를 실행하는 보안 컨텍스트는 Carol로 바꿔고 Carol 테이블 생성을 시도 합니다. 이 시도는 “지정된 스키마 이름 ’dbo’가 존재하지 않거나 이것을 이용할 권한이 없습니다.”라는 에러와 함께 실패합니다. 이 경우의 문제점은 Carol이 dbo 스키마에 개체를 생성할 권한이 없다는 것입니다. 기본 스키마 지정이 되지 않았기 때문에 CREATE TABLE 구문은 dbo.table1생성을 시도합니다.
이 코드는 이 코드를 실행하고 CarolSchema을 생성하고 Carol에게 스키마의 소유권을 수여한 signed in 한 admin 사용자로 복귀합니다. 그리고 Carol의 보안 컨텍스트 내에서 다시 실행되고 다시 테이블 생성을 시도합니다. 이 시도는 같은 에러 메시지를 가지고 실패합니다. Carol이 그녀의 재량권에 스키마를 가지고 있기 때문인데 이것은 SQL Server가 기본적으로 이것을 사용할 것이라는 것을 의미하지 않습니다. 결과적으로 이용할 사용 권한을 가지고 있는 개체 이름과 스키마를 명시적으로 사용할 때 CarolSchema.table1을 성공적으로 생성할 수 있습니다. 두 번째 테이블 생성 시도의 실패는 CarolSchema 이 존재한 이후에, 아래 보는 바와 같이 사용자 Carol를 생성할 때나 사용자에 기본 설정을 추가함으로, Carol 기본 스키마를 설정해서 성공할 수 있습니다.
CREATE USER Carol FOR LOGIN Carol WITH DEFAULT_SCHEMA = CarolSchema
-- or
ALTER USER Carol WITH DEFAULT_SCHEMA = CarolSchema
실행 컨텍스트
SQL Server는 데이터에 접근하는 코드를 실행하는 사용자가 적절한 권한을 가지고 있다는 것을 보증하는 강력히 지원되는 소유권 연결(chaining)을 가지고 있습니다. 코드를 호출하는 사용자가 실행 권한을 가지고 있고 그리고, 예를 들어, 코드의 소유자가 액세스한 두 개의 테이블과 뷰의 소유자이기만 하면, 더 이상의 권한이 검사되지 않고 호출자는 요청된 데이터를 받습니다. 만약 소유권 체인이 손상(예를 들면 코드의 소유자가 참조되는 뷰를 소유하고 있지 않은경우)되면 호출자의 보안 컨텍스트를 검사합니다.
만약 호출자가 뷰에 액세스하는 권한이 있다면, 데이터는 반환됩니다. 만약 호출자가 뷰에 액세스 하는 권한을 가지고 있지 않다면, 데이터는 반환되지 않을 것입니다. 이것이 SQL Server 200와 이전 버전이 작동하는 방법이었습니다. 데이터에 대한 액세스를 프로시저나 함수를 통해서 사용자에게 수여할 때 이런 방법은 좋습니다. 소유권 연결은 약간의 제한이 있습니다. 한가지는 데이터 조작 작업에만 적용되고 동적 SQL에는 아닙니다.
그러나 호출자의 권한을 데이터 액세스의 유효성 검사에 사용하는 것을 원하지는 않을 것입니다. 데이터를 보호하기 위해 주의 깊게 디자인된 프레임워크의 일부분으로써, 권한을 검사하기 위해서 다른 사용자의 보안 컨텍스트를 사용하는 저장 프로시저를 생성하고 싶다면 어떻게 할 것인가? 실행 컨텍스트의 개념을 소개하는 SQL Server 2005이전에는 어떤 쉬운 선택 사항들이 없었습니다. 이제 저장 프로서저, 데이터 조작 트리거, 및 사용자 정의 함수(인라인 테이블 값을 제외하고)를 정의 할 때, EXECUTE AS 절을 이용하여 SQL Server가 개체와 프로시저에 의해 참조되는 개체와 데이터에 대한 액세스의 유효성 검사를 위해 어떤 사용자의 권한을 사용할 것인가를 지정할 수 있습니다. 예를 들어 코드 생성자와 관련된 권한을 데이터에 액세스하는데 항상 사용하도록 지정할 수 있습니다. 다음은 지정된 사용자 권한을 가지고 코드를 실행하는 예제입니다. 이 경우에 실행 컨텍스트가 ec의 컨텍스트이기 때문에 사용자 ec는 반듯이 titles 테이블에 대한 SELECT 권한을 가지고 있어야 합니다:
USE pubs
CREATE LOGIN ec WITH PASSWORD = 'ecpassword'
CREATE USER ec FOR LOGIN ec
CREATE PROCEDURE GetTitlesEC(@Table varchar(40))
WITH EXECUTE AS 'ec'
AS
EXECUTE('SELECT * FROM ' + quotename(@Table))
GO
SQL Server 2005는 네 가지의 실행 컨텍스트 옵션을 제공합니다. EXECUTE AS CALLER는 코드 모듈의 호출자 컨텍스트내에서 실행되도록 지정합니다. 따라서 호출자는 모듈의 실행 권한뿐만 아니라 모든 내제하는 개체의 액세스 권한을 가지고 있어야 합니다. SQL Server는 끊어진 소유권 체인에 대해서만 권한을 검사합니다. 그래서 만약 코드의 소유자가 내제하는 개체도 소유하면, 모듈의 실행 권한만 검사됩니다. 이것은 이전 버전 호환성을 보장하기 위한 기본 실행 컨텍스트입니다.
EXECUTE AS 'user_name'는 지정된 사용자의 보안 컨텍스트내에서 코드가 실행되는 것을 지정합니다. 이것은 소유권 체인화에 의지하고 싶지 않고 대신에 코드를 실행할 필요한 권한을 가진 사용자를 생성하기를 원한다면 주목할 만한 옵션입니다.
EXECUTE AS SELF는 모듈이 모듈을 생성하고 대체하는 사용자의 보안 컨텍스트 아래 실행되는 것을 지정하기 위한 간단한 표기법입니다. SQL Server는 SELF가 아니라 모듈과 연관된 실제 사용자 이름을 저장합니다.
EXECUTE AS OWNER는 보안 컨텍스트가 모듈의 현재 소유자의 컨텍스트라는 것을 지정합니다. 만약 소유자가 지정되지 않으면 포함하는 스키마의 소유자의 컨텍스트가 사용됩니다. 소유자는 지정된 사용자(역할이 아닌)의 싱글턴(singleton) 계정이어야 합니다. 모듈 자제를 변경하지 않고 모듈의 소유자를 변경할 수 있기를 원할 때 주목할 만한 옵션입니다.
코드의 실행 컨텍스트를 변경하는 데는 약간의 제한이 있습니다. 모듈의 생성자는 반드시 특정한 사용자를 위한 IMPERSONATE 권한이 있어야 합니다. 여러분 자신을 가장하기 위해 이 권한을 가질 필요는 없습니다. 또한 특정 사용자를 더 이상 사용하지 않기 위해서 모든 모듈의 실행 컨텍스트를 변경하기 전까지 데이터베이스에서 이 사용자를 삭제할 수 없습니다. 소유권 연결은 모듈 내에서 동적 SQL 실행에는 적용하지 않습니다. SQL Server 2000고 마찬가지로 실행 컨텍스트는 동적 SQL에 의해 액세스된 내제하는 개체의 권한을 가지고 있어야 합니다.
암호화
귀중한 자원에 대한 최선의 보호는 보안을 겹겹이 하는 것 입니다 ? 철저한 방어로 알려진 원칙. 공격자는 상품에 도달하기 전에 계층을 연달아 통과해야 합니다. 해커는 빈번하게 네트워크 보안을 손상시켜왔고 그 다음엔 컴퓨터 보안을 그 다음엔 데이터베이스를 손상시켜서 귀중한 데이터에 자유로운 액세스를 획득해 왔습니다.
SQL Server에 암호화된 데이터는 방어의 마지막 선입니다. 비록 공격자가 데이터베이스 액세스를 성공적으로 획득했다 하더라고 데이터를 해독 해야만 합니다. 요즘의 강력한 암호화 알고리즘이라면 해독 키 없이는 공격자는 거의 넘을 수 없는 도전에 직면하게 됩니다. 물론 암호화는 결코 공짜가 아닙니다. 여러분은 아마도 상품 카탈로그 같은 공개적으로 접근가능한 데이터를 포함해서 SQL Server내에 저장되어 있는 모든 데이터를 암호화 하고 싶은 유혹에 빠져들 수도 있을 겁니다. 그러나 암호화는 프로세서 집중적이기 때문 성능상의 막대한 타격을 초래할 수 있습니다. 암호화나 해독에 요구되는 처리 주기 테이블의 하나의 짧은 문자열을 1000만행으로 증대시켜서 쉽게 서버를 굴복시킬 수 있습니다. 보호가 필요한 수준을 고려해서 필드를 보호하는 것이 비용을 지출을 초래할 만한 가치가 있는 때만 암호화를 사용하십시오.
SQL Server 2005는 다양한 키 형태과 암호화 알고리즘을 제공합니다. 대층 키에는 RC4, RC2, DES군, 그리고 AES군 알고리즘를 사용할 수 있습니다. 비대층 키로 RSA를 제공하고 증명서로는 인터넷 엔지니어링 테스크 포스팀의 X.509 V1 표준을 사용합니다.
암호화의 가장 어려운 부분은 키 관리(기밀사항을 비밀에 붙이는것)입니다. 만약 공격자가 데이터를 암호화하는데 사용한 대칭키를 획득하면 데이터에 액세스 할수 있고 거리낌없이 데이터를 변경할 수 있습니다. SQL Server 2005는 서버내의 별개의 범위에 다양한 형태의 키를 보호하기 위해 암호화 개체의 계층구조를 사용해서(그림 5에 서 보듯이) 여러분이 직접 키를 관리하거나 SQL Server가 여러분의 위해 키를 관리하도록 할 수 있습니다.
그림 5 SQL Server 2005의 암호화 계층구조
그림 5 의 제일 위는 SQL Server의 모든 키와 인증서의 부모인 서비스 마스터 키입니다. 서비스 마스터 키(서버의 모든 키를 직간접적으로 암호화 하는 대칭키)는 SQL Server를 설치할 때 자동으로 생성됩니다. 만약 이것이 손상되면, 공격자는 결과적으로 모든 데이터베이스내의 모든 키를 해독(crack)해 낼 수 있습니다. 이런 이유 때문에 이것은 윈도우 내의 Data Protection API(DPAPI)에 의해 보호됩니다. SQL Server가 운영중인 서비스 계정 이름을 이용해서 이것이 액세스할 수 있습니다.
비록 그림 6 에서 보이는 T-SQL문을 이용하여 키를 파일에 덤프하고, 키를 재생성, 파일에서 키를 복원하는 다소간의 관리 작업을 수행 할 수는 있지만 SQL Server가 여러분을 위해 서비스 마스터 키 관리를 책임집니다.
대부분의 경우 키에 어떤 변화도 원하지 않거나 필요하지 않지만, ALTER SERVICE MASTER KEY구문은 복구 옵션과 DPAI에서 키를 암호화하는데 사용하 서비스 계정을 변경하는 옵션을 가지고 있고 있습니다.
데이터베이스의 범위 내에서 데이터베이스 마스터 키는 모든 키와 인증서와 데이터베이스 데이터의 루트 암호화 개체입니다. 각각의 데이터베이스는 단일 마스터 키를 가질 수 있습니다: 만약 보조 키를 만들려고 시도한다면 에러가 발생할 것 입니다.
사용자가 제공하는 패스워드를 가지고 CREATE MASTER KEY T-SQL 사용하기 전에 CREATE MASTER KEY T-SQL를 통해 데이터베이스 마스터 키를 생성해야만 합니다:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'WeZ#6hv*XHq#akAEaqcr7%CUP3aQ'
결과적으로 생성되는 키는 triple DES로 암호화되고 두 번 저장됩니다. 첫 번째로 저장되는 장소는 sys.symmetric_keys 데이터베이스 테이블에 저장되며 제공되는 패스워드에 의해 암호화되고, 두 번째로는 master 데이터베이스의 sys.databases 테이블에 저장되며 서비스 마스터 키를 이용하여 암호화됩니다. 이 복제 저장소는 마스터 키가 자동으로 열릴 수 있게합니다.
데이터베이스에서 현재의 마스터 키를 분리해 내서 다른 서버로 이동하는 것는 문제를 발생시킵니다. 왜냐하면 새로운 서버의 서비스 마스터 키가 서로 다르기 때문입니다. ALTER MASTER KEY는 이전 서버의 서비스 마스터 키에 의한 암호화를 해제하는 옵션을 가지고 있으며 이렇게 한 뒤에 새로운 서버에 추가합니다. 이렇게 하지 않으면 마스터 키를 사용하기 전에 항상 명시적으로 열어야만 합니다.
데이터베이스 마스터 키가 존재하면 필요한 암호화에 따라 세가지 형태의 키를 만드는데 사용할 수 있습니다.
- 비대칭 키는 공개키 공개키와 개인키의 쌍을 가지는 공개키 암호화에 사용됩니다.
- 대칭 키는 데이터를 암호화하고 해독할 때 같은 키를 사용하는 공유되는 비밀에 사용됩니다.
- 인증서는 기본적으로 공개키에 대한 래퍼입니다.
그림 5는 이 키들과 인증서 다른 키나 데이터를 암호화 하는데 사용되는 방법을 보여줍니다. 비대칭 키는 대칭 키와 데이터를 암호화 할 수 있으며, 대칭 키는 다른 대칭 키와 데이터를 암호화 할 수 있으며, 인증서는 대칭 키와 데이터를 암호호 할 수 있습니다. 만약 여러분이 직접 키 관리를 다루고 싶다면 대칭 키는 사용자 지정 패스워드를 이용해서 생성될 수 있습니다. 물론 결국에는 이 모든 키는 데이터베이스 마스터 키를 이용해서 암호화 됩니다.
인증서는 문서, 이메일, 파일 서명에 관해 얘기할 때 전자 서명의 컨텍스트에서 사용되는 같은 종류의 개체입니다. 인증서 개체는 비대칭 암호화에 사용되는 공개키를 이것이 생성하는 방법에 대한 풍부한 옵션을 가지고 감쌉니다. 그러나 SQL Server모든 자세한 사항을 책임지기 때문에 다른 환경에서 인증서를 생성하기 위해 요구되는 단계를 숨깁니다.
SQL Server가 자체적인 사용을 위해서 인증서를 만들게 할 수 있으며 Microsoft 인증 서버나 VeriSign과 같은 다른 신뢰된 인증 기관이 발행한 인증서를 가져올게 할 수 있습니다. 옵션은 개인 키를 암호화하는데 사용하기 위한 패스워드 설정이나 SQL Server 데이터베이스 마스터 키를 사용하도록 하는 설정뿐만 아니라 생성일과 만료일을 설정을 포함합니다. 인증서를 파일부터 가져오거나 서명된 실행 파일이나 탑재된 .NET 어셈블리로부터 인증서를 읽을 수 있습니다. 다음의 코드는 두개의 인증서를 만드는데 User1과 연관된 만료되지 는 하나와 User2을 위한 2005년에 만료되는 다른 하나입니다:
-- User1과 관련된 데이터베이스 마스터 키로 암호화된 인증서를 생성하십오
-- database master key. 데이터베이스 마스터 키는 이미 존재해야 합니다.
CREATE CERTIFICATE User1Certificate
AUTHORIZATION User1 WITH subject = 'Certificate For User1'
GO
-- 제한된 User2를 위한 인증서를 생성하십시오
CREATE CERTIFICATE User2Certificate
AUTHORIZATION User2 WITH subject = 'Certificate For User2',
EXPIRY_DATE = '12/31/2005',
ENCRYPTION_PASSWORD = 'q%dsabciJ&#QZk#wM5G!WB36z5m7'
인증서가 존재하면 암호화를 지원하는 새로운 T-SQL 함수 EncryptByCert를 이용하여 데이터를 암호화할 수 있습니다. 다음과 같은 Customer라는 이름의 테이블이 있다고 생각해 봅시다
CREATE TABLE Customer (
CustId int,
name nvarchar(30),
City varchar(20),
CreditCardType varbinary(300),
CreditCardNumber varbinary(300),
Notes varbinary(4000))
GO
암호화된 데이터는 바이너리라서 테이블은 이것을 담기 위해 varbinary 필드를 사용합니다. 암호화된 데이터는 디지털 인증을 포함하기 때문에 필드 길이는 간단한 문자열 “Visa”와 크레디트 카드 번호를 담지만 다소간 커야 합니다. 여기서는 이 테이블에 데이터 행을 삽입하는 방법을 보여줍니다. INSERT INTO Customer VALUES (1, 'Don Kiely', 'Fairbanks',
EncryptByCert(Cert_ID('User1Certificate'), 'Visa'),
EncryptByCert(Cert_ID('User1Certificate'), '1234-5678-8765-4321'),
EncryptByCert(Cert_ID('User1Certificate'),
'This customer is a real flake. Don''t trust him!'))
EncryptByCert는 Cert_ID 함수(여러분이 인증서에 명명함 이름을 이용하는)를 가지고 얻을 수 있는 인증서 ID와 암호화되는 데이터의 두개의 인수를 가집니다.
테이블에서 데이터를 select할 때 암호화한 데이터의 장점을 볼 수 있습니다. SQL Server Management Studio 에서 SELECT * FROM Customer를 실행하면 그림 7에 보이는 결과를 반환합니다. INSERT문은 Encrypt함수에 대해 다중 호출를 사용하기 때문에 각각의 필드가 다른 메소드를 이용하여 암호화될 수 있습니다. SELECT 문의 일부분으로 데이터를 해도하기 위해서는 아래에 보이는 DecryptByCert를 이용하십시오:
To decrypt the data as part of a SELECT statement, use DecryptByCert as shown here:
SELECT CustID, Name, City,
CONVERT(VARCHAR,
DecryptByCert(Cert_ID('User1Certificate'),
CreditCardType)) AS CardType,
CONVERT(VARCHAR,
DecryptByCert(Cert_ID('User1Certificate'),
CreditCardNumber)) AS CardNumber,
CONVERT(VARCHAR,
DecryptByCert(Cert_ID('User1Certificate'),Notes)) AS Notes
FROM Customer
DecryptByCert는 varbinary 데이터를 반환하기 때문에 일반적으로 다른 데이터 타입(여기서는 varchar)으로 변화해야 합니다. 이것은 그림 8에서 보는 바와 같이 일반 텍스트로 반환합니다.그림 8 DecryptByCert을 이용한 SELECT
비대칭 키를 가지고 수행하는 암호화의 매우 일반적인 형식은 공개 키 암호화라 불립니다. SQL Server 2005내의 비대칭 키는 512, 1,024,또는 2,048 bit 크기의 키를 가지는 RSA 알고리즘을 사용합니다. 지정된 패스워드나 데이터베이스 마스터 키를 가지고 생성된 개인 키를 암호화할 수 있습니다. 또한 디스크 파일, 실행 파일, 메모리에 로드된 .NET 어셈블리에서 키를 가져올 수 있습니다. 다음 코드는 키를 생성하는 서로 다른 두 가지 방법을 보여줍니다. 첫 번째는 사용자에 의해 관리되는 시크릿(secret)를 이용하고 두 번째는 SQL Server에 의해 관리되는 데이터베이스 마스터 키를 이용합니다:
-- 사용자 제공 패스워드에 의해 보호되는
-- 개인 키를 가지고 비대칭 키를 만드십시오.
CREATE ASYMMETRIC KEY User1AsymmetricKey
AUTHORIZATION User1
WITH ALGORITHM = RSA_2048
ENCRYPTION BY PASSWORD = 'AVeryVerySecretPassword'
-- 데이터베이스 마스터키에 의해서 보호되는 다른 하나를 만드십시오
CREATE ASYMMETRIC KEY User2AsymmetricKey
AUTHORIZATION User1
WITH ALGORITHM = RSA_2048
데이터베이스에서 키가 사용하는 하면 데이터를 암호화 하기 위해서 EncryptByAsymKey 함수를 사용할 수 있습니다. EncryptByCert 함수와 비슷하게 첫 번째 인수는 AsymKey_ID 함수를 사용해서 얻을 수 있는 여러분이 사용하고자 하는 키의 ID입니다. 비록 그림 9 에서는 이런 접근 방법이 사용하지만 레코드의 모든 암호화되는 필드에 같은 키를 사용할 필요는 없습니다.
각각의 열의 데이터를 해독하기 위해서 데이터 암호화에 사용된 비대칭 키의 이름을 가지고 AsymKey_ID 함수를 한번 더 이용하여 DecryptByAsymKey 함수를 사용하십시오. 그림 10 에서는 User1AsymmetricKey가 패스워드를 가지고 생성됩니다. 따라서 DecryptByAsymKey 함수 호출의 세 번째 필드에 패스워드를 전달해야 합니다. varbinary 데이터를 사람이 읽을 수 있는 형태로 변환하기 위해서 CONVERT함수를 사용해야 합니다.( 그림 10참조)
데이터베이스 마스터 키를 가지고 생성되는 User2AsymmetricKey(그림 11참고)를 가지고 데이터를 암호화 하기 위해서는, SQL Server가 키를 관리하기 때문에 어떤 자격 증명도 전달할 필요가 없습니다. 바라건대 SQL Server가 여러분을 위해 키를 관리하도록 하는 것이 매운 쉽다는 것을 보기 바랍니다.
만약 SQL Server이 비대칭 키 쌍을 생성하면 다른 사람에게 전송하기 위한 공개키를 sys.asymmetric_keys 카타로그 뷰의 public_key 필드에서 구할 수 있습니다. 다음 코드는 생성하는 각각의 비대칭 키 쌍과 연관된 공개 키를 반환합니다:
SELECT Name, Public_Key FROM sys.asymmetric_keys
인증서와 비대칭 키는 SQL Server데이터를 위한 고성능의 암호화를 제공합니다. 특히 데이터베이스 외부로 데이터를 옮기고 그 도중에 데이터를 보호해야 할 때 고성능의 암호화를 제공합니다. 그러나 서버에 있는 데이터를 보호해야하고 다른 위치에서도 걱정 없으려면 대칭 키는 좋은 선택입니다. 데이터는 안전하게 저장되어 있고 서버에서 해독되고, 클라이언트에 보내고 인증된 사용자에게 보여지는 것은 상당히 일반적인 데이터베이스 시나리오입니다. 대칭 키는 다른 형태의 암호화보다 프로세싱 싸이클이 덜 필요합니다. 이것은 데이터베이스 응용프로그램에 아주 적절하기 때문에 SQL Server내의 대층키 암호화는 아주 유연합니다.
대칭 키 생성은 인증서와 비대칭 키를 생성하는 것과 유사합니다. CREATE SYMMETRIC KEY 구문은 여러 옵션을 가지고 있습니다. 한 옵션은 데이터베이스에 저장될 때 키 자체가 암호화되는 방법입니다. 그 림 5을 참조하여 인증서, 비대칭 키, 사용자 지정 패스워드, 또는 다른 대칭 키를 사용하는 대칭 키를 보호할 수 있습니다. 그 외의 옵션은 사용된 압축 알고리즘, 키를 생성하기 위해 사용자가 제공한 패스워드를 이용할 것인가, 및 선택적인 ID 문구 을 포함한다. 이 구문은 암호화된 데이터에 임시 키를 태그(tag)로 다는데 사용되는 GUID를 생성합니다. SQL Server는 DES, triple DES, 및 AES을 비롯해서 가장 널리 사용되는 대부분의 대칭 키 알고리즘을 지원합니다.
대칭 키를 생성하고 이 키를 직접 관리할 것인지SQL Server가 관리할 것인가를 고려할 때 선택적인 패스워드를 어떻게 보호할 것인가에 대한 고려가 중요합니다. 키를 암호화 하기 위해 패스워드를 지정하면, 생성된 대칭 키를 가지고 데이트를 암호화하는데 사용하려고 선택한 알고리즘이 뭐던지 상관없이, triple DES가 패스워드로부터 키를 이끌어 내는데 사용됩니다. 키를 보호하는 패스워드를 보호하는데 사용된 것보다 더 강력한 암호화를 데이터를 위해 사용하는 것은 가능합니다.
그림 12 은 대칭 키를 생성하는 많은 옵션중 몇 가지를 보여 줍니다. 첫 번째 예제는 현재 있는 인증서에 의해 triple DES를 가지고 암호화한 키를 생성하고 User1 소유권을 결과 키에 부여합니다. 대칭 키와 다르게 인증서를 사용하기 위해서는 명시적으로 인증서를 열지 않아도 된다는 것에 주의하십시오. 두 번째 예제는 비슷한 대칭 키를 만듭니다. 그러나 인증서 대신, 사용자는 제공되는 패스워드를 사용하여 키를 관리하도록 선택했습니다. 세 번째 예제에서는 AUTHORIZATION 절을 생략해서 dbo가 키를 소유하고 RC4 알고리즘을 사용합니다. 이 예제는 새로운 대칭 키를 보호하기 위해서 현재 있는 비대칭 키를 사용합니다. 마지막 예제는 dbo가 키를 소유하는 또 다른 대칭 키를 생성합니다. 그러나 이것 자체는 다른 대칭 키에 의해서 보호됩니다. 새로운 키를 암호화 하기 위해서 현재 있는 대칭 키를 이용하기 전에 현재 있는 키를 명시적으로 열어야 합니다.
대칭 키를 가지고 암호화된 데이터를 삽입하고 select하는 것은 인증서와 비대칭 키를 이용하는 것과 이용하는 메소드와 비슷합니다만 예제 코드 다운로드(MSDN Magazine 웹 싸이트에서 다운 가능)좀더 복잡합니다. 코드는 특정한 키를 검색하기 위한 Key_GUID 함수와 함께 데이터를 전환하기 위해서 EncryptByKey 와 DecryptByKey 함수를 이용합니다. 데이터베이스 마스터 키에 의해 암호화된 키 같은 키를 생성할 수 없기 때문에 대칭 키를 사용하기 전에 반드시 명시적으로 이 대칭 키를 열어야 합니다. 예제에서는 GenericSymmetricKeySym 키를 생성하고 사용합니다. 이 키는 대칭 키User1SymmetricKeyCert에 의해 보호되기 때문에 사용하고자 하는 키를 보호하는 대칭 키를 먼저 열어야 합니다. 이것은 어느 때든지 데이터베이스에서 대칭 키를 다중으로 열 수 있다는 것을 설명합니다. SQL Server는 어떤 키가 데이터를 암호화하는데 사용되었는지를 알고 있습니다: DecryptByKey 함수 내에서 키를 지정하지 않아도 됩니다.
SQL Server 2005 암호화 구현의 흥미 있는 장점 한가지는 사용자가 그들의 데이터만 보도록 하는 방법을 제공한다는 것입니다. 이 기사의 여러 예제에서 보인 것처럼 AUTHORIZATION 절을 사용해서 키나 인증서의 소유권을 다른 사용자에게 데이터를 보기 위해서 권한을 수여할 수 있는 사용자에게 줄 수 있습니다.
결론
SQL Server 2005는 데이터베이스 엔진내의 보안을 위한 전례가 없는 수준의 지원을 했습니다. 이것은 안전한 서버에 있는 데이터를 액세스 할 수 있는 안전한 응용프로그램을 만드는데 사용할 풍부한 기능 집합을 개발자에게 제공합니다. 높은 입자성 권한은 최소 권한의 보안 원칙을 실천하도록 하고 사용자에게 일을 수행하는데 필요한 권한만을 부여 하고 자만하는 권한의 이점을 이용하는 공격을 막습니다. SQL Server 2005의 이런 보안 기능 향상은 여러분의 데이터에 대한 오늘날의 세련된 공격을 극복해 내는데 필요한 모든 도구를 제공합니다.
Don Kiely, MVP, MCSD, 는 책임 기술 컨설턴트이며 보안, 특히 분산 Windows Forms과 ASP.NET 응용프로그램의 개발 내에서의 보안에, 에 중점을 두고 있는 개발자입니다. 그는 또한 기술에 관한 저술, 컨퍼런스 발표, 강연을 합니다. Don에게 연락하려면 donkiely@computer.org.
댓글 없음:
댓글 쓰기