SQL Server 2005 개발자 가이드[13/13]

SQL Server 2005의 향상된 보안기능

2003년 1월 23일 슬래머웜(Slammer Worm)이 전 세계 SQL서버를 강타했습니다. 그후 2년 동안 마이크로소프트는 SQL서버에 있어서 보안에 대한 부분에 많은 시간과 비용을 투자했습니다. 2005에서는 보안에 있어서 새로운 특징을 탑재해서 개발자와 관리자에게 좀더 강하고 편리한 보안 체계를 소개하게 되었습니다. 2005에서는 개체에 대한 계층적인 구조를 사용하여 보안을 향상시켰습니다. 다음의 표에서 향상된 대표적인 보안특징을 정리했습니다. 향상된 점 설명 1. SQL 로그인 계정에 대한 암호정책 가능 이전 버전에서는 윈도우서버에 정의된 암호화 정책이 SQL Server 로그인계정에 영향을 주지 못했습니다. 2005에서는 윈도우 보안 정책이 SQL Server 로그인계정에 그대로 영향을 주게 되었습니다. 2. 계층적 보안 SQL Server 2005에서 보안주체, 보안개체, permission에 대한 계층적 배열을 사용해서 서로 다른 영역의 개체를 보호하는 일관된 모델을 제공합니다. 이전 버전에 비해서 2005의 보안의 접근 방법을 통해 서 사용자는 보안에 대해서 좀더 수월하게 할 수 있게 되었습니다. 3. 사용자와 스키마의 분리 2005이전 버전에서 개체의 네임스페이스는 개체의 소유자를 가리켰습니다. 2005에서는 개체의 네임스페이스는 개체의 소유자와는 독립적으로 스키마를 이용해서 지정이 됩니다. 소유자와 개체 네임스페이스의 분리를 통해서 좀더 유연하고 관리가 용이한 프레임워크를 제공합니다. 4. 제한적인 메타데이터 접근 SQL Server 2005는 메타데이터에 대한 허가가 부여된 개체에 대해서만 살펴 볼 수 있는 권한을 주어줍니다. 5. 모듈의 컨텍스트 실행 저장프로시저나 함수와 같은 프로그램적인 모듈에 대해서 수행 문맥을 CREATE 문장을 이용하여 명시적으로 선언할 수 있습니다. 6. 데이터암호화 SQL Server 자체에서 데이터암호화를 지원하는 함수를 제공합니다. 7. 기타 서버구성 값 2005 데이터베이스 엔진의 특징에서 보안에 관련된 구성옵션을 추가 했습니다.

SQL 로그인 계정에 대한 암호정책 가능

■ 로그인 계정 생성 방법    ㆍ CREATE LOGIN 명령어        로그인계정을 생성하기 위해 2000에서 사용해 왔던 sp_addlogin 과 sp_grantlogin 저장프로시저        는 CREATE LOGIN 명령어로 대치 됩니다. CREATE LOGIN [ComputerName\user1] FROM windows -- 윈도우계정 이용시 With default_database = adventureWorks    ㆍ sp_addlogin 과 sp_grantlogin은 과거버전의 호환성을 위해 제공됩니다.    ㆍ SQL 계정을 추가할 때도 마찬가지 원리로 생성합니다. CREATE LOGIN [sqluser] With password=’abc_1234’, default_database = adventureWorks ■ SQL Server 로그인 암호 정책    ㆍ 윈도우 사용자계정은 윈도우 정책에 의해서 암호화 정책이 정의됩니다.    ㆍ 윈도우 로컬보안계정에서‘암호는 복잡성을 만족해야 함’을 사용으로 설정하면 다음과 같은 로그        인은 생성되지 않습니다.         CREATE LOGIN [simple_user] With password=’1111’, Default_database = adventureWorks    ㆍ 보안정책을 무시하고 생성을 하기 위해서는 다음과 같이 합니다. CREATE LOGIN [simple_user] With password=’1111’ ,default_database = adventureWorks ,CHECK_EXPIRATION = OFF ,CHECK_POLICY = OFF    ㆍ 옵션    ㆍ CREATE LOGIN 명령어서 사용할 수 있는 옵션의 일부분입니다. 옵션 설명 HASHED SQL Server 로그인에만 적용됩니다. PASSWORD 인수 다음에 입력한 암호가 이미 해시되었음을 지정합니다. 이 옵션을 선택하지 않으면 암호로 입력한 문자열이 데이터베이스에 저장되기 전에 해시됩니다. MUST_CHANGE SQL Server 로그인에만 적용됩니다. 이 옵션을 지정한 경우 새 로그인을 처음 사용할 때 SQL Server 에서는 새 암호를 묻는 메시지를 표시합니다. 이 옵션이 사용되면 CHECK_EXPIRATION 옵션과 CHECK_POLICY이 같이 설정됩니다. CHECK_EXPIRATION SQL Server 로그인에만 적용됩니다. 이 로그인에 암호 만료 정책을 적용할지 여부를 지정합니다. 기본값은 OFF입니다 CHECK_POLICY SQL Server 로그인에만 적용됩니다. SQL Server 가 실행 중인 컴퓨터의 Windows 암호 정책을 이 로그인에 적용하도록 지정합니다. 기본값은 ON입니다. 사용권한 서버에 대한 ALTER ANY LOGIN 권한이 필요합니다. CREDENTIAL 옵션을 사용하는 경우에는 서버에 대한 ALTER ANY CREDENTIAL 권한도 필요합니다. [따라하기]내장함수를 이용해서 계정의 정보 알아내기 2005에서 지원하는 함수를 이용해서 계정의 정보를 알아낼 수 있습니다. CREATE LOGIN Mic WITH PASSWORD =’111’ SELECT LOGINPROPERTY‘( Mic’,‘ IsLocked’) SELECT LOGINPROPERTY‘( Mic’,‘ IsExpired’) SELECT LOGINPROPERTY‘( Mic’,‘ LastSetTime’) SELECT LOGINPROPERTY‘( Mic’,‘ IsMustChange’)

인가 (계층적인 인가 방식)

위의 인증절차를 통해서 들어온 사용자는 SQL Server 자원에 접근할 수 있는 인가를 받아야 합니다. 2005에서 이 인가부분 절차에 새로운 부분이 등장했습니다. 명칭 설명 보안주체 (Principal) 개별적인 윈도우 로그인, SQL서버 로그인, 데이터베이스 사용자, application 역할, 데이터베이스 역할과 같은 SQL Server 내에서 인증과 인가에 사용되는 모든 단위의 일반적인 의미를 가리킵니다. 보안개체 (Securable) Endpoints, 데이터베이스, 전체 텍스트 카탈로그, 서비스 브로커, 테이블, 뷰 등과 같이 서버, 데이터베이스, 스키마 수준에서 지켜지는 개체들을 말합니다. Grantor 허가를 허용하는 보안주체를 의미합니다. Grantee 허가를 받은 보안주체를 의미합니다. 2000에서 어느 사용자에게 프로필러를 이용하기 위해서 sysadmin 권한을 주었다 생각해봅니다. 이 사용자는 프로필러뿐만 아니라 시스템 전체에 대해서 권한을 부여 받게 됩니다. 이런 문제는 웹호스팅 업체에서 충분히 일어날 수 있는 일입니다. A, B, C라는 웹호스팅 서비스를 받는 고객이 있을 때, A라는 고객은 자기 웹사이트에서 주로 사용되는 쿼리를 프로필러로 받고 싶습니다. 그래서, 그 사용자에게 sysadmin권한을 주면 다른 업체의 데이터베이스에 이런 저런 일을 할 수 있게 됩니다. 그럼 프로필러만 돌릴 수 있는 권한을 줄 수 있을까요? 2000까지는 방법이 없습니다. 2005에서는 서버 수준, 데이터베이스 수준, 스키마 수준, 개체 수준, 보안주체 수준에 대해서 보안 개체를 제공합니다. 예를 들면 스키마 수준에서 일정한 허가를 부여하면 특정 스키마내에 존재하는 개체에 대한 허가를 가지게 됩니다. 예를 들어 보기로 합시다. 서버영역에서의 허가는 추적을 돌리고 끝점(EndPoint)을 생성할 수 있습니다. 데이터베이스 영역에서의 허가권은 테이블, 뷰, 저장프로시저, 함수, 서비스브로커,큐 등등과 같은 보안개체를 포함합니다. 개체영역 허가는 테이블, 뷰, 프로시저 등등에 대한 변경을 포함합니다. 여기서 새로 등장하는 개념 impersonate이 등장합니다. 이것은 login X와 login Y가 있을 때 로그인 X에게 로그인 Y에 대한 IMPERSONATE 권한을 부여할 수 있습니다. 이렇게 되면 로그인 Y는 로그인 X의 역할로 명령어를 수행 할 수 있습니다. USE AdventureWorks Go CREATE LOGIN Tom WITH Password =’1234’ GO CREATE USER Tom GO CREATE LOGIN Jelly WITH Password =’5678’ GO CREATE USER Jelly GO GRANT EXECUTE ON DATABASE::ADVENTUREWORKS TO Jelly GRANT CONTROL ON OBJECT::PERSON.ADDRESS TO Jelly GRANT SELECT ON SCHEMA::PERSON TO Jelly -- CONTROL 허가를 이용하면 허가를 부여받은 보안주체는 개체를 소유한 것 만큼의 허가를 받게됩니다. -- 아래의 명령을 수행하기 전에 프로필러에 Jelly로 로그인을 해봅니다. <그림. 서비스 지향 기술구조> USE master Go -- Jelly에게 추적권한을 허가합니다. GRANT ALTER TRACE TO Jelly -- 프로필러에 다시 한번 로그인합니다. <그림 로그인 성공> --> 로그인이 잘 되었습니다. USE AdventureWorks; GRANT IMPERSONATE ON USER::Jelly TO Tom --Tom으로 로그인 했을 때 어떻게 보안이 수행해 오는지 살펴보자. -- Tom으로 로그인 USE AdventureWorks GO SELECT * FROM person.address GO --메시지229, 수준14, 상태5, 줄1 --개체’Address’, 데이터베이스’adventureworks’, 스키마’Person’에대한SELECT 사용권한이 거부되었습니다. ALTER TABLE person.address ADD col1 INT null GO --메시지1088, 수준16, 상태13, 줄1 --개체”address”이(가) 없거나 권한이 없으므로 이를 찾을 수 없습니다. ALTER TABLE person.address DROP column col1 GO --메시지1088, 수준16, 상태13, 줄1 --개체”address”이(가) 없거나 권한이 없으므로 이를 찾을 수 없습니다. EXEC dbo.uspGetEmployeeManagers 1; GO --메시지229, 수준14, 상태5, 프로시저uspGetEmployeeManagers, 줄1 --개체’uspGetEmployeeManagers’, 데이터베이스’adventureworks’, 스키마’dbo’ 에대한EXECUTE 사용권한이 거부되었습니다. --Jelly로 은폐변경을해보자. EXECUTE AS USER =‘ Jelly’ GO SELECT User_name( ) --------------------------------- Jelly -- 앞에서 수행한 쿼리를 재수행해봅시다. SELECT * FROM person.address GO ALTER TABLE person.address ADD col1 INT null GO ALTER TABLE person.address DROP column col1 GO EXEC dbo.uspGetEmployeeManagers 1; GO -- 모든쿼리가 잘 수행됩니다.

사용자와 스키마의 분리

2000에서는 사용자는 개체를 생성하면 그 소유권은 생성한 사용자에게 속했습니다. 예를 들어서 Ann이라는 사용자가 TableA를 생성하면 소유권은 Ann이 되었습니다. 이렇게 사용자는 개체를 만들어 내고 소유권도 가지게 됩니다. 만약 사용자 Ann을 지워야 한다면 어떻게 사용자를 지울 수 있을까요? 사용자를 지운다? 바로 지울 수 없습니다. 이유는 사용자를 지우려면 사용자가 가지고 있는 소유물의 소유권을 먼저 변경을 해야 하기 때문입니다. 스키마의 개념은 다음과 같습니다. 사용자가 개체를 만들지만 생성된 개체의 소유권은 스키마가 지니게 됩니다. 즉, Ann.TableA이 됩니다. 모양은 2000과 같지만 앞에 나온 Ann은 소유자가 아닌 스키마를 의미합니다. 이렇듯 스키마는 데이터베이스 개체를 네임스페이스로 구성하게 됩니다.    한편 2005에서는 기본적으로 dbo라는 스키마를 가지고 있어서 2000에서 사용하던 dbo사용자의 개체를 dbo 스키마로 변경하게 됩니다. 사용자를 생성할 때 다음과 같이 생성하며 기본 스키마를 지정합니다. 스키마는 생성되지 않은 스키마를 우선적으로 지정할 수 있습니다. ■ 스키마 관리하기 스키마 관리는 SQL Server Management Studio에 있는 Object Explorer나 CREATE, ALTER, DROP SCHEMA를 사용해서 수행합니다. ■ 스키마 생성하기 CREATE SCHEMA 문을 이용해서 새로운 스키마를 생성합니다. 간단히 한 줄로 스키마를 작성할 수 있습니다. CREATE SCHEMA Schema_A CREATE SCHEMA 문의 문법은 아래와 같습니다. CREATE SCHEMA schema_name_clause [ < schema_element > [ , ...n ] ] <schema_name_clause > ::= { <schema_name> | AUTHORIZATION < owner_name > | < schema_name > AUTHORIZATION < owner_name > } <schema_element > ::= { table_definition | view_definition | grant_statement| revoke_statement | deny statement } 예) CREATE SCHEMA sales CREATE TABLE orders (OrderID INT, SalesPersonID INT, OrderDate DATETIME) GRANT SELECT ON orders TO John GO [따라하기] 스키마 생성 및 스키마에 개체 생성하기 USE AdventureWorks GO CREATE SCHEMA Sample GO CREATE TABLE Sample.tblReport ( id_no INT PRIMARY key NOT null identity(1,1) , employee_name varchar(10) ) GO INSERT INTO Sample.tblReport DEFAULT values; SELECT * FROM Sample.tblReport GO SELECT NAME AS schemaowner FROM sys.database_principals WHERE principal_id = (SELECT principal_id FROM sys.schemas WHERE NAME =‘ Sample’) GO --결과: dbo SELECT * FROM sys.all_objects WHERE schema_id = ( SELECT schema_id FROM sys.schemas WHERE NAME =’Sample’) GO <그림. 스키마 개체> DROP TABLE Sample.tblReport GO DROP SCHEMA Sample GO ■ 기본 스키마 지정하기 개체를 생성하거나 개체를 수정할 때 기본 스키마를 지정할 수 있습니다. 특별히 스키마를 지정하지 않으면 기본 스키마는 dbo가 됩니다. [따라하기] 기본스키마 지정하기 및 스키마 이해하기. USE adventureWorks GO -- 로그인을 생성합니다. CREATE login loginTemp WITH password =’1234’ -- 사용자를 생성하고 그 사용자의 기본 스키마를 sales로 합니다. CREATE USER loginTemp WITH default_schema = sales; -- sales.store 개체의 SELECT명령어 권한을 loginTemp에게 허가합니다. GRANT SELECT ON object::sales.store TO loginTemp GO -- 사용자를 loginTemp로 전환합니다. EXECUTE AS USER =’loginTemp’ GO SELECT * FROM store GO SELECT * FROM sales.store GO -- 위의 두 개의 쿼리가 성공적으로 수행됩니다. -- 사용자를 원위치(dbo)로 합니다. REVERT GO -- 사용자 loginTemp의 기본 스키마를 production으로 합니다. ALTER USER loginTemp WITH default_schema=production GO -- 사용자를 loginTemp로 전환합니다. EXECUTE AS USER =’loginTemp’ GO -- 아래의 쿼리를 수행하면 실패합니다. -- 실패 이유는 loginTemp 사용자가 production 스키마에서 store를 찾습니다. -- 하지만 production 스키마에는 존재하지 않습니다. SELECT * FROM store GO 메시지208, 수준16, 상태1, 줄2 개체이름’store’이(가) 잘못되었습니다. -- 아래의 쿼리는 성공합니다. -- 성공이유는 loginTemp 사용자가 sales스키마에서 Store 개체를 찾았기 때문입니다. SELECT * FROM sales.store GO -- 사용자를 환원합니다. REVERT Go ■ 스키마 변경하기 스키마의 소유권을 변경하게 되면 스키마에게 부여되었던 모든 개체와 허가는 제거됩니다. ALTER SCHEMA schema_name TRANSFER object_name 예) ALTER SCHEMA HumanResources TRANSFER Person.Address 설명: Person스키마에 있는 address 테이블을 HumanResources 스키마로 수정합니다. ■ 스키마 제거하기 DROP SCHEMA 명령어를 이용해서 스키마를 제거합니다. 스키마를 제거하기 전에 스키마가 가지고 있는 모든 개체를 우선적으로 제거해야 합니다. DROP SCHEMA schema_name [따라하기] 스키마 제거하기 --스키마 sales를 제거합니다 DROP SCHEMA sales 알림 sp_addlogin 과 sp_adduser 명령어는 앞으로 스크립트에서 사용하지 않을 것을 권장합니다. 위의 프로시저는 CREATE LOGIN 과 CREATE USER로 대치되어 사용됩니다. 2005에서 sp_addlogin과 sp_adduser는 사용할 수 있으나 기본 스키마를 지정할 수 없습니다. sp_adduser를 이용하여 사용자를 추가하면 기본 스키마는 사용자 이름과 같은 스키마를 가지게 됩니다. [따라하기] 로그인 생성 -- 로그인 생성 sp_addlogin‘ clark’,‘ adventureWorks’ USE AdventureWorks -- 사용자 계정생성 sp_adduser‘ clark’ -- 스키마 테이블에서 확인 select * from sys.schemas -- 사용자와 같은 스키마로 생성이 되어 있는 것을 볼 수 있음 <그림 스키마와 로그인>

메타데이터에 대한 제한적인 접근

2000에서는 모든 사용자는 메타데이터(시스템테이블)에 접근이 가능했습니다. 그리고, 사용자의 권한에 관계 없이 모든 행을 반환했습니다. 2005에서는 메타데이터(시스템테이블)에 대해서 직접적으로 접근을 금지 하며 하나의 뷰 형식으로 그 값을 반환합니다. 사용자(User)에게 owner가 아니거나 메타데이터에 대한 열람 할 수 있는 권한이 없다면 행을 반환하지 않습니다. 2005에서는 새로운 허가 VIEW DEFINITION을 제공합니다. 이것은 사용자에게 메타데이터를 볼 수 있도록 권한을 부여합니다. [따라하기] USE AdventureWorks GO CREATE LOGIN Ally WITH password=’12345’ GO CREATE USER allyU FOR LOGIN Ally GO EXECUTE AS USER =’allyU’ go EXEC sp_helptext‘ dbo.uspLogError’ go 메시지15009, 수준16, 상태1, 프로시저sp_helptext, 줄54 데이터베이스’adventureworks’에개체’dbo.uspLogError’이(가) 없거나 이 작업에 적합하지 않습니다. SELECT object_definition(object_id‘( dbo.uspLogError’)) go NULL SELECT * FROM sys.objects WHERE type =’U’ SELECT * FROM information_schema.tables; go --실행컨텍스트를마지막EXECUTE AS 문의호출자로다시전환합니다. REVERT; go --사용자allyU에게각각의권한을부여합니다. GRANT VIEW definition ON OBJECT::dbo.uspLogError TO allyU GRANT VIEW definition ON SCHEMA::HumanResources TO allyU --위의작업을다시수행합니다. -- 이전과는달리결과값이잘반환되는것을볼수있습니다. EXECUTE AS USER =’allyU’ go EXEC sp_helptext‘ dbo.uspLogError’ go SELECT object_definition(object_id‘( dbo.uspLogError’)) go SELECT * FROM sys.objects WHERE type =’U’ SELECT * FROM information_schema.tables; go REVERT; go

모듈 실행 컨텍스트

SQL Server 2005 에서는 모듈 실행 컨텍스트라는 개념을 도입했습니다. 이것은 저장프로시저, 함수 트리거와 같은 모듈에 대한 실행을 규정합니다. EXECUTE AS는 함수, 프로시저, 큐 및 트리거와 같은 사용자 정의 모듈의 실행 컨텍스트를 정의하는 데 사용될 수 있습니다. 예를 들어 실행 컨텍스트는 모듈 호출자에서 모듈 소유자로 또는 지정된 사용자로 전환될 수 있습니다. 이전 버전의 SQL Server?에서 이러한 모듈은 항상 모듈 호출자의 컨텍스트에서 실행되었습니다. 모듈이 실행되는 컨텍스트를 지정해서 SQL Server 2005 데이터베이스 엔진 사용자 계정을 제어하면 모듈에서 참조하는 개체에 대한 사용 권한을 검사할 수 있습니다. 이렇게 하면 사용자 정의 모듈 및 해당 모듈에서 참조하는 개체 사이에 있는 개체 체인에서 좀 더 유연하게 사용 권한 관리를 제어할 수 있습니다. 모듈 사용자는 해당 모듈의 실행 권한만 필요하며, 참조되는 개체에 대한 명시적 사용 권한은 필요하지 않습니다. 모듈이 실행 중인 사용자만이 모듈에서 액세스한 개체에 대한 사용 권한을 가져야 합니다. [따라하기] CREATE PROC GetOrders With EXECUTE AS {CALLER |SELF | OWNER ‘| user_name’} AS {수행 문장} 위의 인수가 의미하는 것은 다음과 같습니다. 인수 설명 CALLER 모듈 내부의 문이 모듈 호출자의 컨텍스트에서 실행되도록 지정합니다. 모듈을 실행하는 사용자는 모듈 자체에 대한 알맞은 사용 권한뿐만 아니라 모듈에서 참조하는 모든 데이터베이스 개체에 대한 사용 권한도 갖고 있어야 합니다. CALLER는 큐를 제외한 모든 모듈의 기본값이며 이것은 SQL Server 2000 동작과 동일합니다. CREATE QUEUE 또는 ALTER QUEUE 문에서는 CALLER를 지정할 수 없습니다. SELF EXECUTE AS SELF는 EXECUTE AS user_name과 동일합니다. 여기에 서 지정된 사용자는 모듈을 만들거나 변경하는 사용자입니다. 모듈을 만들거나 수정하는 사용자의 실제 ID는sys.sql_modules 또는 sys.service_queues 카탈로그 뷰의 execute_as_principal_id 열에 저장됩니다. SELF는 큐의 기본값입니다. sys.service_queues 카탈로그 뷰에서 execute_as_principal_id의 사용자 ID를 변경하려면 ALTER QUEUE 문에서 명시적으로 EXECUTE AS를 설정해야 합니다 OWNER 모듈 내부의 문이 현재 모듈 소유자의 컨텍스트에서 실행되도록 지정합니다. 모듈에 지정된 소유자가 없으면 이 모듈의 스키마 소유자를 사용합니다. DDL 트리거에 대해서는 OWNER를 지정할 수 없습니다. [따라하기] 사용자 Alice에게 실행권한이 있는 프로시저 생성하기 CREATE PROC Getorders WITH EXECUTE AS‘ Alice’ AS SELECT * FROM sales.orders 위의 [따라하기]는 저장 프로시저 Getorders는 Alice가 수행하는 것과 같은 사용권을 가집니다. [따라하기] AdventureWorks 데이터베이스에서 소유자 Bob이 sales.orders 라는 테이블을 생성했고 Alice 에게 이 테이블에 대한 SELECT 권한을 부여했습니다. 반면 Bob은 Eve 에게 어떤 권한도 주지 않았습니다. Eve는 다음과 같이 저장 프로시저 sales.getorders을 만들었습니다. CREATE PROC sales.getorders WITH EXECUTE AS SELF AS SELECT * FROM sales.orders Eve 가 위의 저장프로시저를 수행 할 수 있을까요? 아니면 없을까요? EXECUTE AS SELF라는 구절은 이 프로시저를 수행하는 사용자에게 권한을 부여한다는 의미입니다. 즉, Eve는 저장프로시저에 테이블에 접근할 수 있는 권한이나 소유권 깨짐 현상이 없어도 수행을 할 수 있게 되었습니다.

암호화 지원

이전 버전에서는 데이터를 암호화하고 암호를 해독하는데 있어서 자체 개발이나 써드파티 벤더의 솔루션을 이용해야 했습니다. 이런 문제점을 해결하기 위해서 2005에서는 SQL Server 자체적으로 지원하기로 했습니다. EncryptByKey, EncryptByAsmKey, EncryptByCert, EncryptByPassPhase 등의 함수를 이용하여 데이터를 암호화 하고 암호를 풀어냅니다. [따라하기] 암호화와 암호화된 데이터 읽기 USE AdventureWorks go CREATE TABLE dbo.tAccount ( id_no int identity(1,1) NOT NULL PRIMARY key , Acc_no varbinary(100) NOT NULL , Company_name varbinary(512) NOT null , money Money NOT null ) go INSERT INTO dbo.tAccount values ( EncryptByPassPhrase‘( asdfg_1’,‘ 001’) , EncryptByPassPhrase‘( asdfg_2’,‘ Feelanet DB Division’) , 1000 ) -- 암호화하여데이터삽입하기 INSERT INTO dbo.tAccount values ( EncryptByPassPhrase‘( asdfg_1’,‘ 002’) , EncryptByPassPhrase‘( asdfg_2’,‘ Microsoft MSSQL Server 2005’) , 5000 ) -- 데이터삽입한결과 SELECT * FROM dbo.tAccount GO <그림. 암호화된 데이터> -- 데이터를읽어오기결과 SELECT id_no , CONVERT(varchar(15), DecryptByPassPhrase‘( asdfg_1’, Acc_no)) AS Acc_no , CONVERT(varchar(255), DecryptByPassPhrase‘( asdfg_2’, Company_name)) AS Company_name , money FROM dbo.tAccount GO <그림. 암호화된 데이터> DROP TABLE dbo.tAccount GO

SQL Server 2005 데이터베이스 엔진의 보안 값 설정

2005서버에서 보안에 관련된 서버구성 값이 추가되었습니다. Sp_configure의 옵션 설명 기본값 CLR enabled CLR enabled 옵션을 사용하여 Microsoft SQL Server 에서 사용자 어셈블리를 실행할 수 있는지 여부를 지정합니다. Off Xp_cmdshell 시스템 관리자가 시스템에서 xp_cmdshell 확장 저장 프로시저를 실행할 수 있는지 여부를 제어할 수 있도록 하는 서버 구성 옵션입니다. Off Web Assistant Stored Procedures 서버에서 웹 길잡이 프로시저를 설정할 수 있습니다. Off Ad hoc Distributed Queries 이 옵션을 0이 아닌 값으로 설정하면 SQL Server 에서 OLE DB 공급자에 대해 OPENROWSET 및 OPENDATASOURCE 함수를 통한 임의 액세스가 허용되지 않습니다. Off Database Mail XPs 서버에서 데이터베이스 메일을 활성화할 수 있습니다 Off SQL Mail XPs enabled 서버에서 SQL 메일을 활성화할 수 있습니다. Off OLE automation procedures OLE 자동화 개체가 Transact-SQL 일괄 처리 내에서 인스턴스화될 수 있는지 여부를 지정할 수 있습니다. Off SMO and DMO XPs 서버에서 SQL 메일을 활성화할 수 있습니다. On Remote admin connections 관리자 전용연결(DAC)을 허용합니다. Off Agent XPs 서버에서 SQL Server 에이전트 확장 저장 프로시저를 설정할 수 있습니다. 이 옵션을 해제하면 SQL Server Management Studio 개체 탐색기에서 SQL Server 에이전트 노드를 사용할 수 없습니다. SQL Server 에이전트 서비스를 시작할 때 이 확장 저장 프로시저가 자동으로 설정됩니다. On

[출처] DBGuide.net