보안 관리

개요

이장에서는 데이터 베이스 관리자 또는 SQL 서버 2000 관리자들이 부딪히게 될 사용자 계정 관리 문제, 암호 만드는 규칙, 권한과 역할의 사용법, 연결된 서버(Linked Server)와 DTS(Data Transformation Services)같은 중요 보안 문제, 운영상 발생되는 문제, 그리고 다양한 환경 설정 작업 중 발생되는 문제 등에 대해 폭넓게 다루고 있다. 또한 레지스터리 보안과 물리적 보안에 관련된 일반적 문제를 간단하게 논의할 것이다. 이 장을 완전히 이해하고 나면 SQL 서버 2000의 가장 이상적인 보안 방법을 검토하고 확인할 수 있으며, DBA는 이러한 작업을 충실히 이행함으로써 보안상 안전한 시스템 환경을 구축할 수 있을 것이다.

소개

기업에서 데이터베이스 서버를 유지하는 궁극적인 목적은 구조화되고 중앙 집중적인 자료 저장소 역할을 수행할 수 있는 일종의 데이터 창고를 소유하기 위한 것이다. 그리고 데이터베이스 시스템 관리를 위한 담당자로서 데이터베이스 관리자(DBA: Database Administrator)를 두며, 이들을 통해 데이터를 안전하게 구성하고 관리할 수 있게 한다. 응용 프로그램 설계자 및 개발자는 마이크로소프트 SQL 서버의 장점을 충분히 살려 보안상 안전한 기반구조 및 프로그램 개발에 전력을 다해야 한다.

보안 취약성을 가지고 있는 서버는 반드시 데이터 손실, 데이터 침해, 시스템 가용성 상실, 데이터 변조 등과 같은 보안 침해 사고를 받게 될 것이다. 정보 시스템에 따라 보안 침해의 경중은 다르게 나타나며, 그 결과는 기능 장애부터 수입 감소 혹은 인명 사상으로 이어질 수도 있다.

보안의 기본적인 목표는 다음과 같다.

SQL 서버 시스템의 구조를 설계할 때는 강력한 보안 기능을 제공할 수 있도록 보안 구조에 초점을 두고, 강력한 보안구조 하에서 응용 프로그램을 도입하며, 적절하게 응용 프로그램을 구현하고, 보안 기능을 적당히 지원할 수 있도록 운영환경을 준비하는 것이 필수적이다. 만일 보안 기능을 너무 강력하게 지원한다면 결국은 시스템 가용성 및 접근성 문제를 일으킬 것이다.

모든 조직에 있어서 성공을 위한 필수 구성 요소 중 하나가 보안이다. 아직까지도 많은 조직들이 네트워크 환경에 필요한 보안 기능을 구현할 보안정책을 가지고 있지 못한 상태이다. SQL 서버 보안은? 어느 정도 확신하는가?라는 질문에 명쾌한 답변을 할 수 있는 조직과 DBA가 그리 많지는 않을 것이다. 이 장에서는 적용할 수 있는 이상적인 보안 방법, DBA의 경험이 많고 적음과 무관하게 일반적으로 간과되는 보안 허점에 대하여 논하고 있다. 그리고 이 장의 끝에는 상세한 보안 기술자료에 대한 정보를 제공하고 있다.

가정

이 장은 마이크로소프트 윈도우 2000 어드벤스트 서버 환경에서 SQL 서버 2000을 운영하는 DBA 또는 이와 동등한 수준의 사람을 대상으로 기술하였다.

이 장에서 다루는 내용

이장은 다음과 같은 내용을 다루고 있다.

기본적 보안

SQL 서버에서 제기되는 기본적인 보안문제로는 보안정책과 인증이라는 두 가지 측면으로 분류하여 살펴볼 수 있다.

보안정책

보안정책은 정보 시스템에 적용할 보안 규약과 절차의 집합을 의미한다. 보안은 모든 IT 기반구조를 구성하기 위한 기본 구성요소로서, 프로젝트 수행 바로 앞 단계인 설계 단계부터 충분히 논의하여 일관된 구조를 유지해야 한다. DBA, 네트워크 관리자, 개발자 및 IT 기반구조에 관여하는 모든 사람들은 회사의 보안 솔루션을 보증할 수 있도록 상호 밀접한 관련을 가지고 작업에 임해야 한다. 데이터베이스, 백업, 파일과 같은 형태의 데이터와 쿼리, DTS, 복제 메커니즘과 같이 움직이는 데이터의 보호가 가장 중요하다. 저장 데이터와 이동 중인 데이터에 관한 국제법, 법규, 기타 가능한 법적 제한과 규칙에 대하여 언급할 것이다. 보안정책은 업무 요구에 영향을 받으며, 작업 진행과정을 문서화한다. 위험 평가 작업과 위험 분석 작업은 보안상 허점이나 보안정책 위반 사항을 확인할 목적으로 사용한다.

가능한 모든 보안 허점과 공격 유형을 철저히 테스트하고 문서화하여 분석한다. 모든 기본적인 연결 방법은 불가능하게 하고 필요에 따라서 Service Level Agreement)는 구현된 보안정책에 대한 보안 수준과 서비스 수준을 지키도록 강제한다. 보안 관리는 말 그대로 보호하고, 찾아내고, 무방비로 열린 문은 폐쇄시키는 일이다. 권고방법은 다음과 같이 두 가지 버전의 보안정책을 수립하는 것이다. 하나는 기술적 개념을 가지고 있는 IT 직원을 위한 것이고 다른 하나는 기업에 남아있을 인력을 위한 것이다. 두 가지 방법으로 모두 문서화 해야 한다. 즉, 구현된 보안 기반구조를 IT와 무관한 사람이 볼 수 있는 형태와 IT 전문가가 이해할 수 있는(전문용어를 사용하는 방법으로) 문서로 모두 기록한다. 이렇게 하면 IT 관련 직원과 IT와 무관한 직원이 모두 보안정책을 확실히 이해하며, 필요성을 느끼고, 중요성을 인식할 수 있다. 보안정책은 반드시 활성화 시키고, 주기적으로 검토하고, 정확하게 만들고, 필요에 따라 수정될 수 있다.

보안정책에는 다음과 같은 내용이 포함된다.

보안문제는 발생할 때마다 기록되어 로그로 남기고, 즉각적인 해결을 위해 경고 및 통지 시스템을 통합 구축한다. 보안문제는 철저히 조사하고, 문서화하고, 그리고 가능한 한 가장 완전한 해결책을 제시해야 한다. 즉각적인 복원이 필수적이지만 문제해결 자체가 전체 시스템에 악영향을 주지는 말아야 한다. DBA는 일어났던 보안문제를 해결하기 위하여 필요한 권한과 통제 기능을 가져야 한다.

인증

SQL 서버 2000은 기본 인증 모드인 윈도우 인증 모드와 윈도우 인증과 SQL 서버 인증을 모두 사용할 수 있는 혼합 인증 모드와 같은 두 가지 방법을 제공한다. 인증모드의 선택에 따라 클라이언트에서 SQL 서버에 접속하는 방법이 달라진다. 트러스트된 연결을 이용하여 모든 클라이언트들이 연결되도록 하려면 윈도우 인증 모드를 사용해야 하고, 일부 클라이언트만이 트러스트된 연결을 사용하려면 혼합 인증 모드를 사용한다.

윈도우 인증은 SQL 서버 인증보다 강화된 보안 기능을 제공한다. 이러한 특징은 암호 만료, 암호 속성, 감사, 계정 잠금, 그리고 상호 인증 방법으로 사용할 수 있는 커버러스(Kerberos)와 같은 윈도우 2000의 강화된 보안정책 때문에 가능하게 된 것이다. DBA 및 네트워크 관리자가 보안상 보다 안전한 시스템 환경을 구현하려면 특정 기간이 경과된 사용자 암호는 만료시키고, 암호 생성 시 최소한 문자와 숫자 및 특수 기호의 조합을 사용하도록 하고, 이전에 사용했던 암호를 원하는 개수까지 재사용하지 못하게 하고(예를 들면 이전에 사용한 암호가 최소 12개까지는 동일하지 않도록), 그리고 연속적인 로그온 시도 실패 횟수가 특정 횟수를 초과하는 경우 계정이 잠기도록 하는 등의 시스템 설정이 필요하다.

윈도우 인증의 또 다른 이점은 SQL 서버 인스턴스에 연결할 때, 사용자 암호를 재입력할 필요가 없다는 점이다. 윈도우 2000 도메인에 사용자가 로그인할 때, 사용자 토큰이 생성되며, 이 토큰에는 사용자 SID(security ID)와 관련된 그룹 SID가 포함된다. 사용자 SID는 네트워크를 사용하는 사용자를 확인하기 위한 유일한 증명이다. 그룹 SID는 네트워크 사용자가 속한 윈도우 그룹을 나타낸다. 사용자가 윈도우 인증 모드를 사용하는 환경에서 SQL 서버 2000에 로그인하면 토큰을 요청하고, SSPI(Security Support Provider Interface)를 이용 SQL 서버로 보내진다. 반환된 모든 SID는 Master 데이터베이스의 sysxlogins 테이블에 존재하는지 확인되며, 최초 확인작업은 거부(DENY)를 위한 것이다. 윈도우 사용자 또는 윈도우 사용자 그룹이 SQL 서버 접속이 거부되도록 설정된 사용자 그룹에 속하면 접속이 거부될 것이다. 거부(DENY)로 설정된 사용자가 아니면 곧바로 해당 프로세스는 매칭되는 사용자의 윈도우 계정SID가 존재하는지 아닌지 확인하는 과정을 진행한다. 동일한 SID가 존재하면 접속이 허용되고 그렇지 않으면, 사용자가 속한 다른 윈도우 그룹에 동일한 SID가 존재하는지 확인하기 위하여?sysxlogins?테이블을 검색한다.?sysxlogins?테이블에 해당 SID가 존재하면 사용자의 접속을 허용하고 그렇지 않으면 거부된다.

그렇지만 윈도우 인증은 단점도 여러 가지 가지고 있다. 부득이한 이유로 도메인 컨트롤러를 사용할 수 없는 경우, 사용자는 도메인에 로그온도 못하고 SQL 서버에 연결도 불가능하다. 윈도우 2000과 SQL 서버에 성공적으로 로그온한 다음 사용자의 그룹 멤버십이 변경되었다면, 네트워크에 로그오프 했다가 다시 로그온해야만 변경된 내용을 실제로 사용할 수 있게 된다. 그룹이 변경되거나 또는 도메인 그룹의 권한이 변경될 때, DBA는 해당 변경작업을 수행하기 위하여 필요한 관리자 권한을 할당 받거나, 누군가에게 해당 변경 작업을 대신 수행하도록 요청해야 한다.

DBA가 SQL 서버 서비스 도메인 사용자 계정의 자체 문제 혹은 유효성 문제로 인해 SQL 서버에 연결할 수 없으면, DBA는 엔터프라이즈 관리자를 통해 서버를 중지시키고, 시작 계정을 로컬 시스템 계정으로 변경하고 서비스를 다시 시작시키면 SQL 서버에 존재하는 모든 데이터에 접근할 수 있다. 그렇지만 가동환경과 복제 목적으로 사용하는 다른 서버와 연결된 경우 또는 전자메일 등과 같이 공유 네트워크를 통해 접속이 필요한 내용은 해당 계정이 원래된다.

이러한 단점에도 불구하고 윈도우 인증 모드는 SQL 서버 2000의 기본 인증 모드로 강력한 권장 사항이다. SQL 서버 로그인 계정으로 데이터베이스 접속이 불가능하다면 현재 작동중인 응용 프로그램도 데이터베이스 접속이 불가능하므로 인증 모드 변경은 신중히 고려해야 한다. 개발 및 테스트 환경은 실제 환경과 유사하게 구성하여 응용 프로그램한다.

역할, 권한, 암호 문제

SQL 서버의 중요한 보안 사항으로는 역할, 권한, 암호에 관련된 부분을 간과해 버린다는 점이다.

역할

역할은 사용 권한을 적용할 수 있는 단일 단위로 사용자들을 수집할 수 있게 하는 강력한 도구이다. 또한 역할에 부여되거나 거부되거나 취소된 사용 권한은 모든 역할의 구성원에게 적용된다. SQL 서버 2000은 고정 서버 역할, 고정 데이터베이스 역할, 사용자 정의 역할, 응용 프로그램 역할과 같이 4가지 유형으로 나누어진다.

조직의 작업자 클래스에서 수행하는 작업을 나타내는 역할을 설정할 수 있으며 그 역할에 적절한 사용 권한을 부여할 수 있다. 작업자들이 작업에 참여할 때 간단하게 작업자들을 역할 구성원으로 추가할 수 있다. 또한 작업에서 이탈되면 작업자들을 역할에서 제거할 수 있다. 사람들이 작업을 수용하거나 작업을 그만 두고 빠져 나갈 때 반복적으로 각 사용자에 대해 사용 권한 부여, 사용 권한 거부 및 취소를 수행할 필요가 없다. 사용자가 역할의 구성원이 될 때 사용 권한이 자동으로 적용된다.

작업 기능에 기반하여 역할의 집합을 정의하고 해당 작업에 적용되는 사용 권한에 각 역할을 할당하는 경우 데이터베이스에서 사용 권한을 쉽게 관리할 수 있다. 그런 다음 각 개별 사용자에 대한 사용 권한을 관리하는 것이 아니라 역할 간에 사용자들을 간단하게 이동할 수 있다. 작업기능이 변경되는 경우 간단하게 역할에 대한 사용 권한을 한 번 변경하면 변경 내용이 그 역할의 모든 구성원에 자동으로 적용된다.

각 유형의 역할에 따라 DBA는 매우 융통성 있게 보안관리를 제공할 수 있는 특수한 기능을 가지고 있다.

고정 서버 역할

DBA는 개발 완료된 데이터베이스를 그대로 구현하고 롤백할 수 있는 스크립트를 만들고 유지관리하며, 또한 소스 관리 도구인 DDL(Data Definition Language) /DML(Data Manipulation Language)로 표시된 모든 정보를 유지 관리 한다. DBA는 가동을 목표로 개발되는 데이터베이스 환경에 존재하는 모든 물리적 개체를 생성할 수 있어야 하고, 사용하게 될 DML 내용을 검토한다. 단 개체를 생성하는 스크립트를 관리하고 변경하게 된다.

고정 서버 역할을 통해 DBA는 데이터베이스의 특정 그룹에게 관리상의 권한을 할당할 수 있다. DBA는 사용자에게 모든 시스템 관리 기능을 부여하는 대신 고정 서버 역할을 통해 각 사용자가 필요로 하는 서버 권한만을 할당한다. sp_helpsrvrole 저장 프로시저를 사용하면 고정 서버 역할의 목록을 얻을 수 있고, sp_srvrolepermission 저장 프로시저를 사용하면 각 고정 서버 역할의 특정 사용 권한을 얻는다.

예를 들어, DBA가 특정 사용자를?sysadmin?고정 서버 역할로 추가하지 않고 연결된 서버를 생성할 수 있도록 하려면, DBA는 단지 사용자 로그인 계정을?setupadmin고정 서버 역할에만 추가하면 된다.

이러한 환경의 DBA를 위해서 DBA 그룹을 윈도우 2000에 만든 다음 DBA 그룹으로 사용할 로그인 계정을 sysadmin 고정 서버 역할로 등록한다. 이러한 방법으로 DBA는 보안 수준을 높이면서 구성원의 작업 내용을 훨씬 용이하게 추적하고 확인할 수 있다.

표 3.1은 다양한 SQL 서버 2000 고정 서버 역할을 설명하고 있다.

표 3.1 SQL 서버의 고정 서버 역할

고정 서버 역할	설명
sysadmin	SQL Server에서 모든 작업을 수행합니다. 이 역할의 권한은 모든 다른 고정 서버 역할에 걸쳐 배치한다.
sysadmin	서버 구성 옵션으로 서버를 셧다운시켜야 적용된다.
sysadmin	SQL Server에서 모든 작업을 수행합니다. 이 역할의 권한은 모든 다른 고정 서버 역할에 걸쳐 배치한다.
setupadmin	연결된 서버를 추가/제거하고 sp_serveroption 등의 일부 시스템 저장 프로시저를 실행한다.
securityadmin	로그인 계정과 CREATE DATABASE 권한을 관리하고, 또한 오류 로그를 읽고 암호를 변경할 수 있다.
processadmin	SQL 서버인스턴스에서 실행 중인 프로세스를 관리한다.
dbcreator	데이터베이스를 생성, 변경, 삭제할 수 있다.
diskadmin	디스크 파일을 관리한다.
bulkadmin	BULK INSERT 문을 실행한다.

고정 데이터베이스 역할

고정 데이터베이스 역할을 통해 DBA 또는 데이터베이스 소유자가 데이터베이스의 특정 그룹에게 관리상의 권한을 할당할 수 있게 한다. DBA는 사용자에게 모든 데이터베이스 소유자 기능을 부여하는 대신 고정 데이터베이스 역할을 통해 사용자에게 부여된 데이터베이스 권한만을 할당한다. sp_helpdbfixedrole 저장 프로시저를 사용하면 고정 데이터베이스 역할의 목록을 얻을 수 있으며 sp_dbfixedrolepermission 저장 프로시저를 사용하면 고정 데이터 베이스 역할에 대한 특정 사용 권한을 얻는다. 데이터베이스의 모든 사용자는 public 데이터베이스 역할에 속하며, 데이터베이스의 모든 사람이 특정 사용 권한을 갖게 하려면 public 역할에 사용 권한을 할당하시오. 사용자에게 개체에 대한 사용 권한이 특수하게 부여되지 않은 경우 public에 할당된 사용 권한을 사용한다.

예를 들어, DBA가 특정 사용자를?db_owner?고정 데이터베이스 역할로 추가하지 않려면, DBA는 단지 사용자 계정을?db_ddladmin?고정 데이터베이스 역할에만베이스 역할

Fixed Database Role	Description
db_owner	데이터베이스에 대한 모든 권한을 소유하고 있다.
accessadmin	Windows NT 4.0 또는 Windows 2000 그룹과 사용자 및 SQL 서버사용자를 데이터베이스에 추가하거나 삭제할 수 있다.
db_securityadmin	SQL 서버2000 데이터베이스 역할과 그 구성원을 관리하고 데이터베이스에서 명령문과 개체 사용 권한을 관리한다.
db_ddladmin	데이터베이스에서 개체를 추가, 수정 또는 삭제하고 모든 DDL을 실행시킨다.
db_backupoperator	DBCC, CHECKPOINT, BACKUP 문을 실행시킬 수 있다. 즉, 데이터베이스의 백업권한을 가지고 있다.
db_datareader	데이터베이스에 있는 모든 사용자 테이블에서 모든 데이터를 볼 수 있다.
db_datawriter	데이터베이스의 모든 사용자 테이블에서 데이터를 추가, 변경 또는 삭제할 구 있다.
db_denydatareader	데이터베이스에서 데이터를 선택하는 어떠한 권한도 거부한다.
db_denydatawriter	데이터베이스에서 데이터를 변경하는 어떠한 권한도 거부한다.

사용자 정의 데이터베이스 역할

사용자 정의 데이터베이스 역할은 DBA나 데이터베이스 소유자가 보다 쉽게 그룹 권한 기능을 사용할 수 있도록 해준다.

예를 들어, 만일 DBA가 여러 명의 사용자에게 동일한 개체에 대한 권한을 부여하려고 한다면,?DBA는 개별 사용자를 대상으로 권한을 부여할 수도 있고 또는 데이터베이스 내의 사용자 정의 역할을 사용하여 사용자를 추가할 수도 있다.

사용자 정의 역할을 포함시킬 수도 있지만 보안 분쟁을 방지하고 조치할 문제를 없애려면 가능한 한 최소화하는 것이 바람직하다.

응용 프로그램 역할

응용 프로그램 역할이 표준 역할과 다른 점은 다음과 같다.첫째, 응용 프로그램 역할은 윈도우 NT 4.0이나 윈도우 2000 그룹, 사용자 및 역할과 같은 구성원을 포함할 수 없다. 특정 응용 프로그램을 통해 응용 프로그램 역할이 사용자의 연결에 대해 활성화되는 경우에 한해 응용 프로그램 역할의 사용 권한을 획득할 수 있다. 사용자가 응용 프로그램 역할과 연결되는 경우, 역할 구성원이 되는 경우라기보다 역할을 활성화하는 응용 프로그램을 실행할 수 있는 경우이다.둘째, 응용 프로그램 역할은 기본적으로 활성화되지 않으며 활성화되려면 암호가 필요하다.셋째, 응용 프로그램 역할은 표준 사용 권한을 무시한다. 응용 프로그램에 의해 연결에 대한 응용 프로그램 역할이 활성화되는 경우, 해당 연결은 연결 기간 동안 모든 데이터베이스 내의 로그인, 사용자 계정, 다른 그룹 또는 데이터베이스 역할에 적용되는 모든 사용 권한을 영구적으로 상실한다. 연결은 응용 프로그램 역할이 있는 데이터베이스에 대해 응용 프로그램과 연결된 사용 권한을 얻는다. 응용 프로그램 역할은 현재 소속된 데이터베이스에 대해서만 적용되므로 다른 데이터베이스의 guest 사용자 계정에 대해 부여된 사용 권한을 통해서만 또 다른 데이터베이스에 대한 액세스를 획득할 수 있다. 따라서, guest 사용자 계정이 데이터베이스에 없는 경우에는 연결을 통해 해당 데이터베이스를 액세스할 수 없다. guest 사용자 계정이 데이터베이스에 있는 경우에도 개체를 액세스할 수 있는 사용 권한이 guest에 명시??었는지에 상관 없이, 연결을 통해 해당 개체를 액세스할 수 없다. 사용자가 응용 프로그램 역할에서 확보한 사용 권한은 SQL 서버 인스턴스를 로그아웃할 때까지 지속된다.

응용 프로그램 역할은 데이터베이스 마다 별도로 활성화되고, 사용자는 다른 데이터베이스에 있는 개체에 접근할 수 없다. 다른 데이터베이스에 guest 계정을 만들었을 때를 제외하고,?guest?계정이나?public?역할로 개체에 접근하려면 권한을 획득하고, 데이터베이스.소유자.개체 구문으로 확인할 수 있다. 이 경우 USE DATABASE 문을 사용할 수 없다.

권한

권한을 획득하고 작업할 때, 권한 유형, 권한 부여/파기/거부, 권한 효과와 같이 3가지 사항을 고려해야 한다.

권한 유형

SQL 서버 2000은 개체 권한, 스테이트먼트 권한, 미리 정의된 권한 그리고 암묵적 또는 유도 권한과 같이 여러 권한 유형이 있다. 시스템 저장 프로시저를 사용하지 않으면 여러 데이터베이스간에 권한을 부여할 수 없다. 사용자 계정은 접속할 모든 데이터베이스에 로그인 계정을 만들어야 한다.

개체 권한은 테이블, 뷰, 저장 프로시저, 함수 같은 기존 데이터베이스 개체의 사용자에게 부여되는 것이며, 여기에는 SELECT, INSERT, UPDATE, DELETE, REFERENCES, 및 EXECUTE가 포함된다.

스테이트먼트 권한은 사용자가 데이터베이스에 개체를 생성할 수 있도록 부여하는 권한이다. 여기에는 CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE RULE, CREATE SCHEMA, CREATE TABLE, CREATE TRIGGER, CREATE VIEW, BACKUP DATABASE, BACKUP LOG 등이 포함된다.

미리 정의한 권한은 고정 서버 역할 또는 고정 데이터베이스 역할 구성원이 사용할 수 있다. 이 권한은 역할 정의를 위한 부분이며, 변경할 수 없다.

암시적 또는 유도 권한은 사용자가 개체 소유자일 때 일어난다. 예를 들면, 테이블 소유자가 트리거를 생성하고, 권한을 부여하고, 테이블을 변경할 수 있다.

T-SQL 스크립트로 권한을 부여하고, 감사작업을 수행하여 부여 받은 권한을 확인할 수 있다. 예를 들어, DBA가 신입 사원으로부터 자기부서의 특정 응용 프로그램에서 사용하는 데이터베이스에 접속할 수 있도록 해달라는 요청을 받았다고 하자. 로그인 계정 생성부터 권한 부여까지의 모든 작업을 감사 테이블에 기록할 수 있다. 감사 테이블에는 누가 어떤 로그인 계정 혹은 사용자 계정을 생성하였는가 뿐 아니라 언제, 어디서, 그리고 각 로그인 계정을 만든 이유까지 기록할 수 있다. 모든 T-SQL 작업 스크립트는 보호 영역에 유지 관리해야 한다. 모든 관리 작업의 표준화는 중요하다. 웹 기반 프런트-앤드 응용 프로그램 구축 시 이러한 변경 작업과 기타 다른 변경작업을 고려해야 한다. 상세 작업 내역을 기록하려면 트리거와 감사 테이블을 이용한다.

권한 허가/취소/거부(Granting/Revoking/Denying)

권한 허가/취소/거부 작업은 SQL엔터프라이즈 관리자나 Grant/Revoke/Deny T-SQL 명령에 의해 가능하다. 앞에서 언급했듯이 개별 데이터베이스에서 사용자 계정으로 직접 수행하지 않고 언제든지 스크립트를 사용하여 특정 역할을 수행하도록 권한을 부여할 수 있다.

권한 정보는 각 데이터베이스의?syspermissions?테이블에 저장된다. DBA는 동적으로 생성되는?sysprotects?가상 테이블에 쿼리하여 추가적인 권한 정보를 쉽게 추적할 수 있다. GRANT 권한은?sysprotects?가상 테이블의?protecttype?컬럼에 grant_w_grant (권한을 부여 받은 사용자들이 받은 권한을 행사하기 위하여 T-SQL 명령을 사용할 수 있는 권한) 값으로 사용하는 204 또는 표준 권한 부여 상태를 의미하는 205와 같은 실제 값으로 존재한다. DENY 권한은 부정적 입력 값인 206으로 표시된다.?REVOKE?권한은 사용 권한과 거부 권한을 모두 제거한 것으로?sysprotects?임시 테이블에 아무런 등록정보도 표시되지 않는다. 즉 사용자 또는 사용자 그룹 권한이 폐쇄되어 더 이상 접근할 수 없게 된다. 다른 역할 멤버십을 통해서 권한을 또 다시 부여할 수 있다.

권한은 누적되므로 사용하는 데이터베이스의 사용 계정 또는 데이터베이스 역할 구성원에게 부여된 가장 높은 권한을 적용 받는다. 응용 프로그램 역할은 사용자 및 역할을 포함하고 있지 않으므로 응용 프로그램 역할은 데이터베이스 역할과 동일하게 동작하지 않는다.

사용자 및 그룹 수준의 권한 취소는 기타 부여된 모든 권한이 일시에 취소되는 결과를 가져온다. 예를 들어, Sales 데이터베이스의 Sales_Role 그룹의 구성원인 현수가 tblTeleSales 테이블에 있는 데이터를 SELECT 할 수 있는 권한을 부여 받았다고 가정하자. 또한 Sales_Role에는 동일 테이블에 대한 SELECT 권한이 이미 부여된 상태이다. 그런데 tblTeleSales 테이블에 SELECT 할 수 있는 현수의 권한을 폐쇄시키더라도 현수는 역할 멤버십 이기 때문에 여전히 tblTeleSales 테이블에 SELECT 할 수 있다. Sales_Role이 가지고 있던 권한만 폐쇄되더라도 여전히 현수는 자신의 SELECT 권한을 이용 tblTeleSales 테이블에 접근할 수 있다. Sales_Role을 통해 권한을 부여 받은 모든 사용자들은 권한을 잃게 된다. 사용자 들이 암시적으로 권한을 부여 받았거나 다른 그룹에 소속되어 해당 권한을 가지고 있는 경우 및 어떤 수준에서든지 접근에 대하여 DENY되지 않았으면 여전히 tbl_TeleSales 테이블에서 값을 SELECT 할 수 있다.

현수의 권한이 거부되면, 소속된 그룹이 어떠한 권한을 가지고 있는지 고려할 필요도 없이 현수는 테이블에 접근할 수 없을 것이다. Sales_Role 그룹 구성원은 여전히 해당 테이블을 접근할 수 있다. Sales_Role의 권한을 거부시키면, tbl_TeleSales 테이블에 다른 역할 권한을 가지고 부여 받은 SELECT 권한을 고려할 필요도 없이 현수와 모든 Sales_Role 역할 구성원은 데이터에 접근할 수 없게 된다.

유효한 권한

DENY 문을 사용하여 사용자의 권한을 거부하면 사용자가 나중에 해당 권한이 부여된 그룹이나 역할에 추가되어도 해당 권한을 액세스할 수 없다.

사용자 계정에서 거부된 권한을 제거하려면 REVOKE 문을 사용한다. 사용자가 속해 있는 그룹이나 역할에 권한이 부여되지 않으면 보안 계정은 권한을 액세스할 수 없다. 거부된 권한을 제거하면서 보안 계정에 명시적으로 권한을 적용하려면 GRANT 문을 사용한다.

사용자 및 역할에 부여된 권한은 데이터베이스 단위로 유효하다. DENY 권한을 제외한 모든 권한은 누적 적용된다. 사용자 및 역할 단위로 거부된 권한은 동일한 권한을?sysadmin?고정 서버 역할을 제외한 다른 역할 멤버십을 통해 부여하더라도 무시된다(DENY 권한이 적용된 역할 조차도?sysadmin에 모든 권한을 유지한다). 특정 역할을 DENY로 지정하면 해당 역할에 포함된 모든 사용자는 접속이 거부된다. 일반적으로 REVOKE 권한 부여는 DENY로 권한을 제한하는 대안으로 사용한다. REVOKE를 통해 GRANT 및 DENY 권한을 모두 제거할 수 있다. DENY는 추적이 매우 어려운 권한 문제의 원인이 될 수 있다. 단일 사용자 환경 시스템에 DENY 권한을 적용할 때는 특히 많은 주의가 필요하다. REVOKE와 역할을 사용함으로써 권한 관리 및 문서화 작업을 단순화 시킬 수 있다.

암호

암호에는 응용 프로그램 역할 암호와 암호 다시 지정과 같이 두 가지 사항에 주의해야 한다.

응용 프로그램 역할 암호

SQL서버 관리자가 특정 응용 프로그램의 데이터베이스에 접근을 제한하기 위하여 응용 프로그램 역할을 사용한다. 응용 프로그램 역할을 활성화 시킨 사용자는 현재 세션에서 소유하고 있는 권한을 잃고 응용 프로그램 역할에서 부여한 권한을 얻게 된다. sp_setapprole 저장 프로시저를 이용 응용 프로그램 역할을 활성화시킨다. 응용 프로그램 역할을 활성화 시킬 때, 여러 방법으로 암호를 안전하게 보호할 수 있다. 암호는 해당 응용 프로그램에서만 읽을 수 있도록 레지스토리에 안전하게 위치한다. 암호는 응용 프로그램 역할이 OLE-DB(Object Linking and Embedding-DataBase)나 또는 ODBC(Open DataBase Connectivity) 암호화 함수를 이용 활성화되는 시간에 따라 선택적으로 암호화된다. 암호는 또한 SSL/TLS(Secure Sockets Layer/ Transport Layer Security) 또는 프로토콜 암호화를 이용 서버와 클라이언트 간의 통신수행 과정 중에 암호화된다.

암호 다시 지정

암호는 로그인 계정의 유형에 따라 두 가지 방법 중 하나에 의해 변경할 수 있다. 윈도우 사용자 계정을 사용하는 경우, 암호는 암호를 다시 설정할 수 있는 권한을 가지고 있는 어떤 관리자 혹은 네트워크 사용자에 의해서도 변경할 수 있다. 사용자 계정은 윈도우 2000 서버에서 확인할 수 있으므로 이러한 계정 변경 작업을 SQL 서버에 반영할 필요는 없다. SQL 서버 로그인 계정을 사용하는 경우, 사용자 암호는?sysadmin과?securityadmin의 고정 서버 역할 구성원에 의해 변경 되거나, 또는 sp_password 저장 프로시저를 수행시켜 개별적으로 변경할 수 있다. sysadmin, db_owner, 그리고 db_securityadmin 역할 구성원들은 해당 데이터베 이스 sysusers 시스템 테이블에 저장되어 있는 응용 프로그램 역할 암호를 변경할 수 있다.

SQL 서버 서비스 도메인 사용자 암호는 만료되지 않도록 설정한다. SQL 서비스 계정으로 사용하던 도메인 사용자 계정이 변경되면 해당 계정을 서비스 스냅인에서 변경하고, 그 후 적절한 권한이 해당 계정에 적용되었는지 확인하고, 풀텍스트 검색 서비스와 계정을 통기화시키기 위하여 엔터프라이즈 관리자에서 또 한번 변경한다.

로깅 변경

로깅과 추적 변경에 관한 자료는 6장 변경 및 구성 관리를 참고하시오.

표준 보안 설계

표준 보안 설계의 대상은 모든 서버이며, 특정 보안 속성을 사용한다. 여기서는 기본 보안을 위한 몇 가지 권고사항에 대하여 논하겠다.

Sa 계정

가동 환경에서?sa?계정의 암호는 대문자, 소문자, 특수 기호, 스페이스 및 숫자 등을 포함시켜 복잡하게 만든다. 비록 윈도우 인증 모드로 SQL 서버가 수행되더라도?sa?계정은 복잡한 암호를 가지고 있어야 한다. 복잡한 암호는 누군가가 관리자 권한을 쉽게 획득하여 SQL 서버에 접근하는 것을 방지한다. 이것은 또한 서버 관리자가 보안 인증 모드를 혼합모드로 변경할 때 서버를 보호한다.

가동 환경에서는?sa?로그인 계정을 사용하지 않는 대신 윈도우 그룹에 각 DBA의 네트워크 사용자 계정을 등록하고, DBA 그룹이 사용할 수 있는 단일 SQL 서버 로그인 계정을 만들고?sysadmin?고정 서버 역할에 사용자 계정을 추가하시오. 이 방법으로 DBA가 수행하는 관리작업을 보다 쉽게 감사할 수 있고 문서화 할 수 있다.

암호

혼합 모드 인증 환경에서 SQL 서버 로그인 계정의 암호를 NULL 값으로 사용하면 절대 안 된다. 로그인 계정에 할당된 암호가 로그인 이름과 동일해서도 안되고, "password"와 같이 사전에 등재된 표준 단어를 사용해도 안 된다. DBA는 이러한 규칙을 준수하고, 최종 사용자에게도 전파해야 한다. 대신 각 로그인 계정과 사용자에게 유일한 암호를 제공할 수 있도록 관련 정보를 암호화된 전자메일이나 이름이 분명하게 확인된 사용자만이 접근할 수 있는 보이스 메일 계정으로 전달한다.

월 단위로 모든 암호를 변경하도록 정책을 설정했다면, 이 정책을 계획대로 진행하기 전에 비용을 고려해 보아야 한다. 예를 들어 클러스터 환경에서는 두 노드의 서비스 암호를 변경하면 장애조치(failover) 동작이 자동으로 일어난다. 그러므로 이러한 정책이 적용된 곳에서 99.999 퍼센트의 시스템 가용성을 달성한다는 것은 실질적으로 불가능하다. 이러한 환경에서 월 단위로 암호를 변경한다면 자주 암호를 잃어버리고 암호 재설정 작업을 하게 된다. 그러므로 보안 수준을 선택하고 가용한 지원 비용이 얼마인지 확인한다.

개체 생성

어떤 가동 서버든지 자질을 갖춘 DBA 만이 물리적 데이터베이스를 생성할 수 있는 권한을 가지고 있어야 한다. 개발자는 저장 프로시저, 사용자 정의 함수, 그리고 뷰 정도의 개체를 생성할 수 있는 권한만 있으면 될 것이다. 모든 다른 개체에 대한 책임은 DBA가 가져야 한다.

데이터베이스 소유자(dbo)는 모든 사용자 정의 데이터베이스 개체를 소유한다. 개체를 다음과 같이 만들었을 때?dbo가 개체 소유자로서 볼 수 있는 여러 방법이다:

소유권 체인이 끊어지지 않도록 dbo가 소유권을 갖는 것이 바람직하다. 하나의 개체로 생성시 끊긴 소유권 체인은 다른 사용자가 소유하는 다른 개체에 종속된다. 예를 들면, 영수가 테이블을 만들고, 상아가 영수의 테이블에 뷰를 만들었고, 상아는 다시 자기가 만든 뷰를 현수가 Select할 수 있도록 권한을 부여했다고 가정해 보자. SQL 서버는 모든 소유권을 무시하고 권한을 체크한다. 즉, 상아가 만든 뷰와 영수가 만든 테이블에서 모두 현수의 권한을 체크하게 되는 것이다. 만일 현수가 영수의 테이블에 Select 할 수 있는 권한을 가지고 있지 않는 다면, 현수는 상아가 만든 뷰도 사용할 수 없을 것이다. 이렇게 동작하므로 사용자들이 다른 사용자의 개체에 명백한 권한 없이 접근하는 것을 막을 수 있는 것이다. 현수가 영수의 테이블에 권한을 부여 받은 역할 구성원이라면 예외 상황이 일어날 수도 있다.

권한

테이블에 존재하는 컬럼의 일부를 선택하여 권한을 부여할 수도 있다. 뷰, 저장 프로시저, 또는 함수를 사용한다면 로우 레벨 보안을 구현할 수 있다. 컬럼 수준 권한 관리작업이 매우 복잡하기 때문에 뷰, 저장 프로시저, 함수 등을 생성하여 컬럼 및 로우 레벨 보안 관리를 수행할 것을 권고한다. 이러한 개체들은 특정 컬럼 및 열을 접근할 수 있게 지정할 수 있다. 권한은 테이블 단위로 적용되는 것이 아니라 개체 별로 권한을 부여할 수 있다.

기업에서 주문형 소프트웨어를 개발 중이라면 사용자들이 테이블에 직접 접근하는 것을 막아야 한다. 대신 모든 테이블에 대한 뷰를 생성하여 응용 프로그램 역할을 통해 뷰에만 권한을 부여한다.

문서

각 SQL 서버에 수행한 개별적인 보안 평가 작업문서에는 문서가 만들어진 시간을 표기한다. 문서는 다음과 같다.

서버 수준의 변경부터 SQL 개체에 대한 변경 뿐 아니라 발생되는 스테이트먼트 권한에 이르기까지 변경되는 모든 내용을 DBA는 철저히 문서화 해야 한다.

기타

윈도우 2000 서버와 SQL 서버 2000 서비스 팩, 패치, 그리고 핫 픽스는 정상적으로 연구하고 적용한다.

윈도우 인증은 모든 클라이언트가 신뢰되는 연결을 지원하도록 선택하는 방법이다. 신뢰된 연결을 지원하지 않는 계정은 DBA가 생성한 SQL 서버 로그인 계정과 암호이다.

DBA는 IIS(Internet Information Server)에서 지원하는 SQL XML 환경구성에 대단한 주의가 필요하다. 윈도우 인증은 생성된 가상 디렉터리에 사용한다. SQL 서버 계정을 사용한다면 sa계정은 절대로 사용하지 말아야 한다.

SQL 서버 2000 또는 SQL에 존재하는 데이터에 접근하는 모든 수단은 주의 깊은 연구 및 조사가 필요하다. 엔터프라이즈 관리자, 마이크로소프트 액세스, 쿼리 분석기,?osql, 3rd 파티 도구, 고객 응용 프로그램들이 기타 수단에 포함된다.

응용 프로그램은 클라이언트에 민감한 정보를 반환하지는 않는다. 메시지 및 오류 정보는 서버 이름, IP 주소, 코드, 그리고 보안 사항을 클라이언트에서 보지 못하도록 매우 일반적인 응답으로 변환된다. 0

비록?master?데이터베이스가 관리용 저장 프로시저를 생성하기 쉬운 장소지만, 이상적인 계획은 각 서버에 표준 SQLAdmin 데이터베이스를 생성하여 개체들을 거기에 저장하는 것이다.

확장 저장 프로시저

master?데이터베이스에 포함된 많은 확정 저장 프로시저를 통해 SQL 서버 2000의 기능을 강화시킬 수 있다. 확장 저장 프로시저는 실제로 T-SQL 문으로 쉽게 데이터베이스에 접속할 수 있는 기능을 가지는 DLL(dynamic link libraries)로 저장된다. 예를 들어, 레지스토리 등록정보는?xp_regwrite/xp_regread를 이용 생성 및 읽혀지고, 신규 OLE 자동화 개체는?sp_OACreate를 이용 생성되고, 전자메일은?sp_sendmail를 통해 보내진다.?public?역할에 포함된 사용자 중 유효하지 않은 실행 권한을 가진 사용자는 없는지 확인하기 위하여?master?데이터베이스에 존재하는 확장 저장 프로시저 목록을 확인한다. 가동 서버에 새로운 확장 저장 프로시저를 도입하기 전에 세심한 주의가 필요하다. 가동 서버에서 일어날 수 있는 메모리 누수 현상과 서버 연결 문제 등의 가능성을 막기 위한 철저한 테스트는 테스트/개발 환경에서 시작한다.

xp_cmdshell?확장 저장 프로시저는 사용자가 T-SQL을 이용하여 운영체제에서 실행되는 명령을 수행할 수 있게 해준다.?sysadmin?고정 서버 역할 사용자에만 기본 권한이 부여되므로 오직 DBA만이?sysadmin?접근 권한을 부여함으로써?xp_cmdshell?확장 저장 프로시저를 아무나 사용하지 못하게 한다.?xp_cmdshell?확장 저장 프로시저와 관련된 보안사항을 이해하는 것이 DBA에게는 매우 중요한 일이다. DBA는?MSSQLSERVER?서비스 계정인 도메인 사용자 계정 보안 컨텍스트로?xp_cmdshell?확장 저장 프로시저를 실행시킬 수 있다. 관리자 권한을 가지고 있는 동일한 도메인 사용자 계정이 여러 개의 SQL 서버 서비스 계정으로 사용된다면, DBA는 여러 개의 SQL 서버에서 관리자 권한으로?xp_cmdshell?확장 저장 프로시저를 수행할 수 있다. 이러한 위험을 완화시키려면 여러 대의 SQL 서버에서 사용하는 도메인 사용자 계정(동시에 SQL 서버 서비스 계정)을 다르게 사용하는 방법을 고려해야 한다. 응용 프로그램으로 인해 야기된 SQL 서버 권한 문제를 응용 프로그램 을 지원하는 엔지니어에게 에스컬레이션 하지 않고, DBA가 충분히 응용 프로그램에 대한 지원을 할 수 있도록, 특정 SQL 서버 응용 프로그램이 사용하는 동일한 서비스 계정끼리 그룹화하는 것이 필요하다.

저장 프로시저, 뷰, 그리고 함수 정의는 민감한 것으로 인식하고 소유자가 암호화할 수 있다. 기밀성은 CREATE 스테이트먼트에 ENCRYPTION 변수를 사용하여 유지할 수 있다. 다른 사람들은 그래픽 툴 또는?sp_helptext를 사용하여?syscomments에 존재하는 암호화된 개체의 내용을 볼 수 없을 것이다.

항상 SQL 서버 2000에 포함된 명령행 유틸리티를 신뢰 연결로 사용하려면?bcp에서는?-T?옵션을,?osql에서는?-E?옵션 코드를 추가하여 사용한다.

스크립트 보안

DBA 그룹 이외의 사람이 보거나 변경 할 수 없도록 조치한 드라이브 및 디렉터리에 관리용 스크립트를 보관한다. 가장 좋은 방법은 마이크로소프트 비쥬얼 소스세이프(Microsoft Visual SourceSafe)와 같은 버전 관리 소프트웨어를 도입 사용하는 것이다. 이러한 툴을 사용하면 권한 없는 사용자가 변경하는 것을 방지할 수 있도록 NTFS 파일 포맷으로 연계되어 데이터를 보호한다. 그리고 혼합 인증 모드를 사용하거나, FTP 사이트에 접속할 경우 절대로 프로그램 소스 코드에 암호를 하드 코딩하는 일이 없어야 한다. sa 계정을 사용한다면, 특정 스크립트, 기타 작업, DTS 패키지 연결 개체 등에서 참조되는 암호를 알려주어서는 안 된다. 보안상 위험요인일 뿐 아니라 SQL 서버의 전반적인 변경 작업을 하지 않고는 암호도 변경할 수 없게 된다.

기타 문제

DBA는 기본 데이터베이스를 master가 아닌 다른 데이터베이스로 변경할 수 있다. master와 msdb 시스템 데이터베이스에 사용자들이 개체를 생성하지 못하게 해야 한다. 왜냐하면 두 시스템 데이터베이스에는 변경 시 치명적인 문제를 일으킬 수 있는 정보와 SQL 서버가 작업을 진행하기 위해 사용하는 저장 프로시저가 포함되어 있기 때문이다.

가동 서버에서?pubs?및?northwind?같은 샘플 데이터베이스를 삭제하는 것을 고려하시오.

각 데이터베이스에서?public?역할은 데이터베이스에 대한 모든 사용자와 역할에 대한 기본 권한을 표시한다.?public?역할은 보든 데이터베이스에 존재하며, 제거할 수 없고, 사용자 및 역을 추가하지도, 그리고 이러한 역할에서 제거할 수도 없다. 그러므로 데이터베이스의 모든 사용자와 역할은 권한을 상속 받기 때문에?public?역할에 직접 권한을 부여하는 것이 어렵다. 또한?public에 부여된 어떤 권한은 역할이 활성화 되었을 때 모든 응용 프로그램에 적용될 수도 있다.?public?역할에 거부(Deny) 권한을 할당하지 마시오.

guest 계정은 각 데이터베이스에 기본적으로 존재하는 로그인 계정으로 상응하는 데이터베이스 사용자 계정이 없이도 로그인하여 데이터베이스를 사용할 수 있고, 해당 데이터베이스에 대하여 권한을 직접 부여한 guest 계정과 public 역할을 이용 개체를 사용한다. 그러므로 보안을 강화하려면 모든 데이터베이스에서 guest 계정을 삭제하고, model 데이터베이스에 추가되지 않도록 해야 한다.

2-계층 보안

2 계층 응용 프로그램 모델은 클라이언트 접속과 논리적 업무처리를 위한 계층과 데이터 계층으로 구분된다. 종종 클라이언트 접속 계층은 IIS 호스팅을 한다. 호스팅하는 IIS와 데이터베이스 서버인 SQL서버가 직접 연결하면 보안 문제가 제기될 수 있다는 점을 인식해야 한다. 첫 번째 문제는 로그인 계정과 암호 데이터를 보호해야 하는 문제이다. 웹 페이지를 연결하기 위한 커낵션 스트링이 스크립트 내에 완전한 형태로 존재하면, 웹 페이지 소스 코드에 접속할 수 있는 사람은 누구나 로그인 계정과 암호를 모두 알 수 있게 된다. 비용이 아무리 많이 투입되더라도 이 것은 막아야 한다. 이러한 방법으로부터 로그인 계정과 암호를 보호하려면 다음과 같은 방법을 수행해야 한다.

3-계층 보안

3-계층 응용 프로그램은 성공한 e-커머스 솔루션으로 표현 계층, 업무 로직 계층, 데이터 계층과 같이 3 개의 논리적 계층으로 나누어 진다. 업무 서비스 계층은 미들 티어라고 불리기도 한다. 윈도우 인증은 추가로 업무 계층의 보안을 위해 구성요소 서비스(COM+)에 구현된다. 구성요소 서비스의 역할은 윈도우 2000 업무 사용자와 그룹을 수집하여 표시한다. 가장 좋은 방법은 개별 윈도우 2000 사용자를 사용하는 것보다 구성요소 서비스 역할로 윈도우 2000 사용자 그룹을 이용하는 것이 보안을 강화할 수 있는 방법이다. 보안을 설정하자 마자 곧바로 구성요소 서비스 패키지에 할당되고, 구성요소 서비스 역할의 인터페이스가 된다.

구성요소 서비스 패키지와 응용 프로그램은 업무 및 데이터 구성요소를 모두 포함하도록 만들 수 있다. 업무 구성요소는 기업의 업무 로직을 포함하고 있다. 데이터 구성요소는 SQL 서버 2000 데이터베이스에 존재하는 데이터 접근을 통제한다. 클라이언트는 ASP 페이지를 이용 업무 구성요소에 접근한 다음 ASP 페이지를 가지고 업무 개체를 구체화시킨다. 업무 구성요소에 접근하는 것은 권한과 구성요소 서비스 역할 기반의 보안을 이용하는 멤버십에 의하여 통제된다. SQL 서버 응용 프로그램 역할과 저장 프로시저가 구현되는 시점에 안전한 e-커머스 업무 솔루션 개발을 발전시켜 데이터 구성요소와 공동으로 작업할 수 있다.

물리적 보안

가동 서버, 허브, 라우터, 그리고 스위치 등의 장비는 모두 잠긴 문이나 잠글 수 있는 캐비닛을 통해서 보호할 수 있는 물리적인 보안 장치를 가지고 있어야 한다. 정당한 권한이 없는 사람이 기계실을 출입할 수 있고 이러한 환경에서 일어날 수 있는 최악의 상황을 고려해 본다면 관리자 계정으로 컴퓨터에 로그온 한 후, 컴퓨터를 잠그지 않고 자리를 비울 수는 없을 것이다.

가동 서버에 설치된 소프트웨어는 물리적으로 보호되어야 한다. SQL 서버2000 데이터 파일, 실행 가능 파일, 그리고 DLL 등은 NTFS 권한을 통해 모두 보호할 수 있다. 단지 SQL 서버 서비스 도메인 사용자 계정과 로컬 시스템 계정, 그리고 모든?sysadmin?도메인 사용자에 속하는 로컬 관리자 그룹만이 이러한 파일에 권한을 가지고 있다. 이러한 권한은 풀 컨트롤이 가능하다. C:\Program Files\Microsoft SQL Server\MSSQL 폴더와 SQL 서버2000 하위 폴더에 설치된 단독 서버와 구성원 서버가 기본적으로 이렇게 동작한다. SQL 서버2000을 업그레이드 방법으로 설치했거나 또는 도메인 컨트롤러로 설치 했다면 권한이 다를 것이다. DBA는 위의 권고사항을 따르고 있는지 확인하기 위하여 권한을 체크할 수 있다.

가장 좋은 결과와 융통성을 발휘하려면 개발, 테스트, 스테이징 환경이 개별 도메인으로 분리되어 있어야 한다. 스테이징 환경은 가동 도메인과 데이터 백업과 스크립트를 전달할 수 있는 최소한의 연결만 가능하도록 완전히 격리된 실험실을 구성한다. 기업의 가동 서버 환경과 실험실에 완전히 격리된 시스템 환경을 구축함으로써 가동환경을 이중화한다. 그러나 가동시스템 환경에 존재하는 모든 도메인 사용자 계정을 스테이징 환경까지 동일하게 이중화하지 않고, 스테이징 환경에 있는 서비스 계정의 암호를 동일한 것으로 설정할 필요는 없다. (또는 sa 로그인 계정의 암호를 동일하게 할 필요도 없다.) 가동 환경과 스테이징 환경의 서비스 계정 암호를 동일하게 사용하면 테스트 환경에 접속할 수 있는 사람들이 가동 환경에 접근하므로 보안상 허점이 생기게 된다.

보안상 가장 안전한 가동 환경은 SQL 서버 인스턴스 당 기껏해야 하나의 도메인 로그인 계정을 갖도록 하는 것이다. 이러한 계정에는 또한 시스템 관리를 위해 경고용으로 사용할 전자메일 계정이 필요하다. 보안과 관리의 용이성은 다중 SQL 서버 도메인 사용자 계정 사용을 고려했을 때 평가할 수 있다.

네트워크 보안

네트워크 보안은 다양한 네트워크와 네트워킹 구성요소를 보안환경으로 구성하여 보안 침투를 제한하는 것이다. 비록 엄밀하게 말하면 DBA의 역할은 아니지만 네트워크 관리자에 의해 구현된 지식과 DBA가 제공하는 정보를 조합한다면 보안상 가장 안전한 환경으로 인도할 수 있을 것이다.

DMZ(Demilitarized Zone)이나 스크린드 서브넷(screened subnet)으로 알려진 돌출 네트워크는 외부 공격으로부터 SQL 서버와 같은 백엔드 서버를 보호하기 위하여 사용한다. 돌출 네트워크는 두 개의 방화벽으로 구성할 수 있다. 각 방화벽은 들어오고 나가는 네트워크 트래픽을 모니터한다. 방화벽은 일반적으로 IP 패킷 필터링과 IP 포트 룰, 프로토콜, 그리고 주소 등을 포함한다. 보안을 한층 강화하기 위하여 추가로 응용 프로그램 수준의 프락시, 견고한 필터, 그리고 호스트 기반 보호를 구현할 수 있다. 돌출 네트워크의 한 쪽은 외부 네트워크로 연결되거나 인터넷으로 연결 되고, 다른 쪽은 기업의 내부 네트워크와 연결된다. 보안 수준의 차이와 다양한 보안 통제는 사용하는 보안정책에 따라 돌출 네트워크의 내외부에 걸쳐 구현할 수 있다. 많은 장비들을 웹 클러스터로 설치하고 돌출 네트워크 내부에 별도의 네트워크를 구성하여 SQL 서버와 같은 백-앤드 서버들을 설치하면 보안상 보다 안전하게 보호되어야 하는 서버들은 기업의 내부 네트워크 내에 위치할 것이다.

네트워크 보안은 SAN(Storage Area Networks), 분할된 네트워크, 방화벽, 프락시, 스위치 같이 다양한 하드웨어와 그룹/계정/로컬 보안정책, 커버로스(Kerberos: 상호 인증, 도용/위임을 포함하는), SSL(Secure Sockets Layer) 채널을 통한 디지털 서명으로 사용하는 PKI(Public Key Infrastructure), IPSec(Internet Protocol Security), 프로토콜 보안과 VPN(Virtual Private Networks)과 같이 다양한 소프트웨어로 구성된다. 너무 지나친 보안은 가용성, 편의성, 성능 문제를 야기하므로 중복적인 보안 설정을 하지 않도록 주의해야 한다.

예를 들면, SSL을 사용한 모든 서버 네트워크 라이브러리 프로토콜 암호화는 슈퍼 소켓 넷-라이브러리로 설정될 수 있다. 이러한 기능을 이용하려면 CA(Certification Authority)로부터 확인된 인증서가 필요하다. 프로토콜 암호화는?SQL Server 네트워크 유틸리티의 일반 탭에서 프로토콜 암호화 강제 사용을 선택하여 활성화시킬 수 있다.

그리고 그림 3.1을 보시오.

네트워크 보안은 DoS(Denial of Service: 네트워크 포화 상태를 만들어 정상적인 서비스가 불가능하도록 하는 공격) 공격, 해킹(불법적인 접속 및 도용), 사용자 도용(User Impersonation)과 전송 도중 데이터를 가로채는 행위와 같은 외부로부터 시도되는 시스템 파괴를 방지하는 것이다. SQL 서버 2000에서 네트워크 보안의 또 다른 의미는 회사에 불만을 가지고 있는 사원에 의한 악의적 데이터 변조와 데이터 파괴를 방지하는 것이다.

레지스토리 보안

다음 레지스토리 키들은 NTFS 권한을 사용하여 보호된다.

사용자, 계정 관리 문제

SQL 서버를 운영할 때 다음과 같은 사용자와 계정 관리 문제를 이해하는 것이 중요하다.

장애조치 클러스터링

SQL 서버2000 장애조치 클러스터링 관리를 위한 로그인 계정은 반드시 윈도우 인증을 이용해야 한다. SQL 서버 장애조치 클러스터에서 SQL 서버 서비스 계정으로 로컬 서비스 계정을 사용할 수 없다. 비록 해당 계정이 설치과정에서 자동으로 적절한 권한을 할당 받았더라도, 해당 계정이 변경되었다면 다음과 같은 조건을 만족시키던지 또는 관리자 그룹에 포함되어야 한다.

SQL 서버의 가상 서버를 실행하고 있는 노드의 계정 변경이 필요하면, SQL 서버 엔터프라이즈 관리자를 통해서 수행한다. 이 것은 모든 노드에서 선택한 사용자 계정이 요청하는 권한을 부여할 수 있는 서비스 계정의 암호 변경이다. SQL 서버 엔터프라이즈 관리자에서 암호를 변경할 수 없다면 풀 텍스트 검색 기능도 정상적으로 동작하지 않고, SQL 서버를 시작시킬 수도 없을 것이다.

로그 전달

로그 전달은 윈도우 인증 모드에서 사용할 수 있다. 혼합 모드를 반드시 사용해야 하는 경우라면 로그 전달 설치작업을 통해 사용자?log_shipping_monitor_probe?를 생성한다. 원본 서버와 대상 서버는 이 계정을 사용하여 트랜잭션 로그 백업, 복사, 복원 작업이 발생할 때,?log_shipping_primaries와?log_shipping_secondaries를 업데이트 할 수 있다.

대상 서버를 원본 서버 역할로 변경하면 원래의 원본 서버에 존재하던 로그인 계정은 대상 서버가 원본 서버의 역할을 수행할 수 있도록 동일한 위치에 존재해야 한다. 로그 전달 프로세스는 자동으로 로그인 계정을 전달하지는 않는다(그렇지만 데이터베이스에 사용자를 기록한다). 새 원본 서버에 전근하려는 클라이언트는 로그인 계정을 복사하여 SID에 속하는 데이터베이스 사용자 UID에 전달해주어야 접속할 수 있다.

로컬 관리자, 도메인 관리자, 그리고 빌트인 관리자 SQL 서버2000 빌트인/관리자 로그인 계정은 SQL 서버 2000 서버가 설치된 로컬 컴퓨터의 로컬 관리자 그룹과 매핑된다. 로컬 관리자 그룹에는 도메인 관리자 그룹이 포함된다. 빌트인/관리자 그룹은 기본적으로?sysadmin?고정 서버 역할 구성원이 되며, sa 로그인 계정은 SQL 서버 2000에 매핑된다. 즉, 도메인 관리자, 로컬 관리자는 SQL 설치 시점에 모두 자동으로?sysadmin?고정 서버 역할 구성원이 된다. DBA는 빌트인/관리자 계정을?sysadmin?고정 서버 역할로부터 제거하는 것을 권고한다.

DBA가 윈도우 그룹의 구성원 계정을 확인하려면?xp_logininfo?확장저장 프로시저를 사용한다.

DBA가 SQL 서버 역할을 수행하는 구성원의 계정을 확인하려면 엔터프라이즈 관리자나 sp_helprolemember를 사용한다.

로그인 계정

다음 로그인 계정과 권한 구조는 그림 3.2와 같이 마이크로소프트가 그룹화하고 권한을 할당한 권고사항을 준수한다. 권고사항은 다음과 같다.

이런 접근 방법을 통한 사용자와 그룹의 표준 보안은 관리 작업과 데터베이스 문제 해결과 스테이트먼트 접근을 대단히 단순화 시킨다. 앞에서 언급한바 대로 개체 권한은 테이블에 대한 것이라기 보다는 뷰나 저장 프로시저에 대한 것이다. (권한의 핵심은 데이터베이스 단위로 부여되며, 각 데이터베이스 마다 별로시저, 함수 등에 권한을 부여함으로써 DBA는 사용자와 하부 기반 개체간에 추상 계층을 추가할 수 있다. DBA가 윈도우 그룹 계정으로 작업 중인 사용자의 네트워크 이름을 확인하려면, DBA는 SYSTEM_USER 함수 또는 SUSER_SNAME 함수를 사용한다. 몇 시에 무슨 함수로 누가 어떤 작업을 수행했는지 감사할 때 매우 중요하게 사용할 수 있다. 위에 있는 함수 중 하나를 사용하는 감사 테이블의 사용자 컬럼에 디폴트 제약을 사용하는 운영 레코드에 대해, 트리거를 설정하고 베이스 테이블에서 변경되는 모든 내용을 기록하는 고객 감사 테이블이 이러한 종류 일 것이다.

SQL 서버 로그인 계정 생성은?sysadmin과?securityadmin?고정 서버 역할 구성원에 한해 가능하다. 로그인 계정은 스크립트를 이용하여?master..sysxlogins?테이블에 추가할 수 있으며, 윈도우 2000 그룹과 사용자는?sp_grantlogin?저장 프로시저로 그리고 SQL 서버 로그인 계정은?sp_addlogin?저장 프로시저를 이용한다. 일어나는 모든 일에 대하여 DBA는 누가, 무엇을, 언제, 왜, 어떻게 하였는지 문서화 하고 변경 내용을 원복시킬 수 있는 롤백 코드를 포함하는 문서를 작성한다. 이러한 문서는 시스템 자원을 보관하는 위치에 저장 관리한다.

윈도우 2000 로그인 계정이 SQL 서버에 접근하는 것을 막으려면 DBA는?sp_revokelogin을 이용 로그인 계정을 폐기하거나,?sp_denylogin을 이용 로그인 계정으로 연결하지 못하도록 설정한다. 로그인 계정이 폐기되면 해당 사용자는 폐기된 로그인 계정으로 SQL 서버에 연결할 수 없다. 윈도우 2000 사용자가 또 다른 SQL 서버 로그인 계정을 가지고 있는 윈도우 2000 그룹의 구성원이면, 그 사용자는 해당 그룹의 사용자 계정으로 여전히 SQL 서버에 접근할 수 있다. 모든 윈도우 2000 사용자의 접근을 차단하려면 DBA는?sp_denylogin?저장 프로시저로 사용자 계정을 거부시킨다. SQL 서버 로그인 계정을 제거하려면?sp_droplogin?저장 프로시저로 로그인 계정을 제거한다.

SQL 서버에서 DBA가 로그인 계정을 추가하거나 제거할 때, 알아야 사항이 몇 가지 있다. 다른 데이터베이스와 관련을 맺고 있는 로그인 계정을 제거할 때는 데이터베이스 개체를 제거할 수 없다. 모든 연관된 데이터베이스 사용자 계정 삭제 또한 가능하다. 이러한 일이 일어나면 데이터베이스 소유자와 무관한 고아 개체들이 데이터베이스에 남아있을 가능성이 있다. 관련 데이터베이스 사용자가 소유하고 있는 로그인 계정을 제거하려면, 다음 방법 중 하나를 이용한다.

연관된 사용자 계정과 로그인 계정을 SQL 서버에서 삭제하려면 윈도우 2000 그룹과 사용자가 액티브 디렉터리에서 삭제되어야 한다. 이렇게 함으로써 고아 개체가 만들어지는 것을 막을 수 있는 것이다. 해당 계정과 그룹이 생성될 때 SID가 만들어지므로 동일한 이름으로 윈도우 2000 계정을 새로 만들어도 SQL 서버에 접속할 수 없는 것이다. 비록 이름은 동일하지만 새 그룹 또는 사용자의 SID는 다른 값을 가지며, 사용자 및 관리자는 사용자 이름을 사용하는 반면, 컴퓨터는 ACL(Access Control Lists)을 사용하고, ACL은 SID를 사용한다.

감사

누가 SQL 서버 2000에 접근할 수 있는 권한을 가지고?적은 무엇인가? 이러한 내용은 알고 있어야 하고 문서화 해야 한다. 필요하다면 감사 기능을 수행할 수 있다. 감사 기능은 여러 가지 방법으로 구현할 수 있다. 다음 그림에서 보는 바와 같이 로그인 성공 실패에 관한 로그인 감사를 수행하려면 DBA는 SQL Server 속성(구성) 다이얼로그 박스의 보안 탭에서 감사 수준의 적절한 옵션 사항을 선택한다.

이렇게 로그인 감사 기능이 실행되도록 하면 윈도우 2000 응용 프로그램의 이벤트 로그와 SQL 서버 이벤트 로그에 감사 결과가 기록된다. 감사 설정 내용을 적용하려면 SQL 서버 서비스를 중지했다가 다시 시작해야 한다. 현재의 감사 수준을 확인하려면 엔터프라이즈 관리자를 사용하거나?master..xp_loginconfig를 실행 시킨다. 권고 사항은 실패한 모든 로그인 시도를 모니터링하는 것이다.

SQL 서버에 관한 정보를 수집하기 위하여 DBA가 사용할 수 있는 또 다른 툴은 SQL 프로필러이다. SQL 서버 스토리지와 관계형 데이터베이스 엔진의 돌발 사고는 SQL 프로필러와 같은 서버 사이드 툴에 의해서 알아낼 수 있다. 이러한 돌발 사고는 파일 혹은 분석을 용이하게 하기 위해 테이블로 가공한다. 파일 형태로 수집된 정보는 SQL 서버 프로필러를 이용 그래픽 형태로 볼 수 있다. 수집한 돌발 사고 자료를 테이블로 변환하면 SQL 서버 테이블을 쿼리할 수 있는 모든 도구로 내용을 분석할 수 있다. 수집된 데이터는 분석을 쉽게 하기 위하여 정렬과 그룹핑 방법을 사용할 수도 있다. 추적 파일을 만들기 위한 사용자는?sysadmin?고정 서버 역할 구성원 이어야 한다.

가장 중요한 감사 클래스는 SQL 프로필러의?보안 감사?이벤트 클래스이다. 이 클래스를 사용하여 DBA는 상대적으로 쉽게 많은 보안 이벤트를 모니터할 수 있다.

보안 감사 이벤트 범주를 사용하여 감사 동작을 모니터링한다. 다음 그림은 이벤트 클래스와 데이터 열의 관계를 도식화한 것이다.

표 3.x 이벤트 클래스와 데이터 열 설명

이벤트 클래스	데이터 열	설명
Audit Add DB User Event	Event Class	데이터베이스(윈도우 NT 4.0, 윈도우 2000, 또는 SQL 서버) 사용자 추가 및 제거 기록 기록된 이벤트 유형 = 109.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = sp_adduser 2 = sp_dropuser 3 = grantdbaccess 4 = revokedbaccess
	Database Name	사용자를 추가할 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Target Login SID	대상 윈도우 로그인의 SID
	Target Login Name	대상 윈도우 로그인 이름
	Target User Name	데이터베이스에 추가되는 데이터베이스 사용자 이름
	Role Name	새 데이터베이스 사용자를 추가할 역할 이름
Audit Add Login to Server Role	Event Class	sp_addsrvrolemember 및 sp_dropsrvrolemember에 대해 고정 서버 역할에서 로그인의 추가 및 제거 기록
Event		기록된 이벤트 유형 = 108.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 추가 2 = 삭제
	Target Login SID	대상 윈도우 로그인의 보안 ID(SID)
	Target Login Name	대상 윈도우 로그인 이름
	Role Name	로그인이 추가되는 역할 이름
Audit Add Member to DB Role Event	Event Class	sp_addrolemember, sp_droprolemember 및 sp_changegroup에 대해 데이터베이스 역할(고정 또는 사용자 정의)에서 구성원의 추가 및 제거 기록 기록된 이벤트 유형 = 110.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 추가 2 = 삭제
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Target Login SID	대상 로그인의 SID
	Target Login Name	수정되는 역할 구성원을 갖는 로그인 이름
	Target User Name	수정되는 역할 구성원을 갖는 사용자 이름
Audit Add Role Event	Event Class	sp_addrole 및 sp_droprole에 대해 데이터베이스 역할에서 동작의 추가 및 삭제 기록 기록된 이벤트 유형 = 111.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 추가 2 = 삭제
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Role Name	데이터베이스에 만드는 역할 이름
Audit Addlogin Event	Event Class	sp_addlogin 및 sp_droplogin에 대해 SQL 서버 로그인에서 동작의 추가 및 삭제 기록 기록되는 이벤트 유형 = 104.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 추가 2 = 삭제
	Target Login SID	추가되는 로그인에 할당된 보안 ID(SID)
	Target Login Name	추가되는 로그인 이름
AAudit App Role Change Password Event	Event Class	응용 프로그램 암호 변경 기록 기록된 이벤트 유형 = 112
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 Always = 1
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Role Name	암호가 변경되는 데이터베이스 응용 프로그램 역할 이름
Audit Backup/Restore Event	Event Class	BACKUP 및 RESTORE 이벤트 기록 기록된 이벤트 유형 = 115
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값1 = 백업2 = 복원
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Text Data	백업/복원 명령문의 SQL 텍스트
Audit Change Audit Event	Event Class	AUDIT 수정 기록 기록된 이벤트 유형 = 117.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 새 감사 시작 2 = 감사 중지
Audit DBCC Event	Event Class	발급된 DBCC 명령 기록 기록된 이벤트 유형 = 116.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 Always = 1
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Text Data	DBCC 명령	Event Class	클라이언트가 SQL 서버 인스턴스를 실행하는 서버로의 연결을 요청하는 등 추적이 시작된 이후의 새 연결 이벤트를 모두 수집 기록되는 이벤트 유형 = 14.
	Text Data	모든 집합 옵션의 구분된 목록
	Binary Data	ANSI null, ANSI 채움 문자, 커밋될 때의 커서 닫기. null 연결, 따옴표가 붙은 식별자를 포함한 세션 수준 설정
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
Audit Login Change Password Event	Event Class	SQL 서버 로그인 암호 변경 기록. 암호는 기록되지 않는다. 사용자가 sysadmin 또는 securityadmin 고정 서버 역할의 구성원이고 'old_password','new_password', 'login'의 세 인수를 모두 지정한 sp_password를 사용하여 사용자 고유의 암호를 재설정하면 감사 기록에는 사용자가 다른 사용자의 암호를 변경하는 것으로 기록 기록된 이벤트 유형 = 107.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 사용자가 자신의 암호 변경 2 = 사용자가 다른 사용자의 암호 변경
	Target Login SID	대상 Windows 로그인의 보안 ID(SID)
	Target Login Name	대상 Windows 로그인 이름
Audit Login Change Property Event	Event Class	sp_defaultdb 및 sp_defaultlanguage에 대한 암호를 제외한 로그인 속성의 수정 기록 기록되는 이벤트 유형 = 106.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 기본 데이터베이스 2 = 기본 언어
	Target Login SID	대상 Windows 로그인의 보안 ID(SID)
	Target Login Name	대상 Windows 로그인 이름
Audit Login Failed Event	Event Class	클라이언트에서 SQL Server 인스턴스로의 로그인 시도가 실패 기록되는 이벤트 유형 = 20
	Success	감사의 성공 또는 실패 표시 항상 동일한 값 존재 0 = 실패
Audit Login GDR Event	Event Class	sp_grantlogin, sp_revokelogin, 및 sp_denylogin에 대해 윈도우 NT 4.0 또는 윈도우 2000 계정 로그인 권한에서의 허용, 취소 및 거부 동작 기록 기록되는 이벤트 유형 = 105.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 허용 2 = 취소 3 = 거부
	Target Login SID	대상 Windows 로그인의 보안 ID(SID)
	Target Login Name	대상 Windows 로그인 이름
Audit Logout Event	Event Class	추적이 시작된 이후 클라이언트가 연결 끊기 명령을 보내는 등의 새 연결 끊기 이벤트 수집 기록되는 이벤트 유형 = 15.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	End Time	로그 아웃 종료 시간
	Duration	사용자가 로그인한 이후의 경과 시간
	Reads	연결되어 있는 동안 이 사용자가 발급한 논리적 읽기 I/O 양
	Writes	연결되어 있는 동안 이 사용자가 발급한 논리적 쓰기 I/O 양
	CPU	연결되어 있는 동안 이 사용자가 사용한 CPU 양
Audit Object Derived Permission Event	Event Class	지정한 개체에 대해 CREATE, ALTER 또는 DROP 명령이 발급될 시기 기록 기록되는 이벤트 유형 = 118
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 개체 만들기 2 = 개체 대체 3 = 개체 삭제
	Database Name	개체를 만들고 대체하거나 삭제할 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Object Type	만들고 대체하거나 삭제할 개체 유형 값 1 = Index 2 = Database 3 = User object 4 = CHECK constraint 5 = Default or DEFAULT constraint 6 = FOREIGN KEY constraint 7 = PRIMARY KEY constraint 8 = Stored procedure 9 = User-defined function (UDF) 10 = Rule 11 = Replication filter stored procedure 12 = System table 13 = Trigger 14 = Inline function 15 = Table valued UDF 16 = UNIQUE constraint 17 = User table 18 = View 19 = Extended stored procedure 20 = Ad-hoc query 21 = Prepared query 22 = Statistics
	Object Name	만들고 대체하거나 삭제할 개체 이름
	Owner Name	만들고 대체하거나 삭제할 개체 소유자의 데이터베이스 사용자 이름
	Text Data	명령문의 SQL 텍스트
Audit Object GDR Event	Event Class	GRANT, DENY, REVOKE 개체에 대한 사용 권한 이벤트 기록 기록되는 이벤트 유형 = 103.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = 허용 2 = 취소 3 = 거부
	Database Name	개체 사용 권한 GRANT/DENY/REVOKE를 실행하는 데이터베이스 이름
	ODBUserName	데이터베이스 내의 발급자 이름
	Owner Name	개체 사용 권한 GRANT/DENY/REVOKE를 실행하는 개체를 소유하는 사용자 이름
	Permissions	발급된 명령문 유형 값1 = SELECT ALL2 = UPDATE ALL4 = REFERENCES ALL8 = INSERT16 = DELETE32 = EXECUTE (프로시저만)
	Column Permissions	열 사용 권한이 설정되어 있는지 나타내는 값 0 = 아니오 1 = 예
	OText Data	명령문의 SQL 텍스트
Audit Object Permission Event	Event Class	개체 권한의 사용 성공 또는 사용 실패 기록기록된 이벤트 유형 = 114.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값 Always = 1
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Owner Name	사용 권한을 확인할 개체의 소유자 이름
	Object Name	사용 권한을 확인할 개체 이름
	Permissions	발급된 명령문 유형 값 1 = SELECT ALL 2 = UPDATE ALL 4 = REFERENCES ALL 8 = INSERT 16 = DELETE 32 = EXECUTE (프로시저만)
	Column Permissions	열 사용 권한 사용여부 표시. 명령문 텍스트를 구문 분석하여 어떤 명령이 어떤 열에 적용되었는지 알 수 있다.
	Text Data	캡처한 이벤트 클래스에 의존하는 텍스트 값
Audit Server Starts and Stops Event	Event Class	서비스의 종료, 시작 및 일시 중지 동작 기록기록된 이벤트 유형 = 118.
	Event Sub Class	이벤트 내의 이벤트 클래스 값 1 = Instance Shutdown 2 = Instance Started 3 = Instance Pause 4 = Instance Continued
	Login SID	Windows 로그인에 대해 GRANT/DENY/REVOKE 문을 실행하는 로그인의 보안 ID(SID)
	Login Name	Windows 로그인에 대해 GRANT/DENY/REVOKE 문을 실행하는 로그인의 이름
Audit Statement GDR Event	Event Class	GRANT, DENY, REVOKE 문에 대한 사용 권한 이벤트 기록 기록되는 이벤트 유형 = 102.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값1 = 허용2 = 취소3 = 거부
	Database Name	GRANT/DENY/REVOKE 문 사용 권한을 적용할 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Permissions	발급된 명령문 유형 값 1 = CREATE DATABASE (master 데이터베이스만) 2 = CREATE TABLE 4 = CREATE PROCEDURE 8 = CREATE VIEW 16 = CREATE RULE 32 = CREATE DEFAULT 64 = BACKUP DATABASE 128 = BACKUP LOG 512 = CREATE FUNCTION
	Text Data	GRANT/DENY/REVOKE 문의 SQL 텍스트
Audit Statement Permission Event	Event Class	문 사용 권한의 사용 기록기록된 이벤트 유형 = 113.
	Success	감사의 성공 또는 실패 표시 값 0 = 실패 1 = 성공
	Event Sub Class	이벤트 내의 이벤트 클래스 값Always = 1
	Database Name	명령이 실행될 데이터베이스 이름
	DBUserName	데이터베이스 내의 발급자 이름
	Permissions	발급된 명령문 유형 값 1 = CREATE DATABASE (master 데이터베이스만) 2 = CREATE TABLE 4 = CREATE PROCEDURE 8 = CREATE VIEW 16 = CREATE RULE 32 = CREATE DEFAULT 64 = BACKUP DATABASE 128 = BACKUP LOG 512 = CREATE FUNCTION
	Text Data	캡처된 이벤트 클래스에 의존하는 텍스트 값

정부 기관과 같이 고도의 보안 기능을 필요로 하는 조직에서 사용할 수 있는 보안 감사 유형은 C2 audit mode(C2 감사 모드)를 사용하는 것이다. C2 감사 모드 를 사용하여 명령문 및 개체 액세스에 성공하거나 성공하지 못한 시도를 모두 확인할 수 있다. 이 정보로 시스템 작업을 기록하고 보안 정책 위반 내용을 찾아볼 수 있다.C2 감사 모드는 보안 감사 이벤트 클래스의 모든 데이터 컬럼에 존재하는 모든 이벤트를 수집하는 것이다. 감사 정보를 추적하여 \mssql\data(SQL 서버 2000의 기본 인스턴스에 대해) 또는 \mssql$instancename\data(SQL 서버 2000의 명명된 인스턴스에 대해) 디렉터리에 있는 파일에 기록한다. sp_configure 저장 프로시저를 이용하여 쉽게 감사 모드를 설정할 수 있다. 감사 모드를 C2 레벨로 설정하는 방법은 다음과 같다.

파일 크기가 200MB에 이르면, C2 감사는 새 파일을 시작하고 이전 파일을 닫은 다음 새 감사 레코드를 새 파일에 기록한다. 이 과정은 SQL Server가 종료되거나 감사가 해제될 때까지 계속된다.

C2 감사를 설정하거나 해제하려면 다음과 같은 내용을 고려한다.

C2 감사를 설정하려면 c2 audit mode 옵션을 1로 설정한다. 이 설정은 C2 감사 추적을 시작하고 옵션을 설정하여 어떤 이유로 감사 파일에 쓸 수 없게 된 서버는 작동을 멈추도록 한다. 이 옵션을 1로 설정하고 나면 서버를 다시 시작하여 C2 감사 추적을 시작한다. C2 감사 추적을 중지하려면 c2 audit mode를 0으로 설정한다.

보안을 위해 시스템 감사 작업을 수행할 때, 추적 파일로 기록되는 클래스와 데이터 컬럼 수를 제한하고?다. 그랙픽 프로필러 툴을 사용하여 발생되는 오버헤드를 줄일 수 있도록 sp_trace_status 저장 프로시저를 실행시켜 백엔드 서비스로 작업한다. 추적 파일을 SQL 서버 서비스가 시작될 때 자동으로 시작되도록 설정하려면, 추적 파일의 내용을 요약한 사용자 정의 저장 프로시저가 자동으로 시작되도록?sp_procoption을 이용한다.

프락시 계정

프락시 계정은 시스템 관리자에 의해서?sysadmin?고정 서버 역할 구성원이 아닌 사용자로 정의된 일종의 도메인 사용자 계정이다. 프락시 계정을 사용하는 사용자는?CmdExec?또는 도메인 계정 보안 컨텍스트를 가지고 있는 마이크로소프트 ActiveX 스크립팅으로 xp_cmdshell를 실행시키고 SQL 서버 에이전트 작업을 수행할 수 있다. 파일이나 폴더에 NTFS 권한을 부여함으로써 네트워크 권한을 컨트롤할 수 있다. 기본적으로?sysadmin?고정 서버 역할 구성원 만이 이러한 작업을 수행할 수 있다.

로그인 계정과 다른 SQL서버로부터 복원한 사용자

로그인 계정을 다른 SQL 서버로 옮길 때는 다양한 상황이 존재한다. 데이터베이스를 특정 서버에서 다른 서버로 옮겨보자. 데이터베이스를 옮기거나 복사하는 방법으로는 백업/복원, 데이터베이스 분리/ 데이터베이스 연결 또는 데이터베이스 복사 마법사 등을 이용할 수 있다. 백업/복원 작업은 재난 복구 작업의 일환으로 대기 서버를 유지 관리하는 방법으로 사용할 수 있다. 데이터베이스를 서버간에 이동할 때 주의가 필요하다. 로그인 계정과 데이터베이스 사용자 계정간에 매핑 정보가 서로 다를 수 있다.

데이터베이스 분리/ 데이터베이스 연결은 서버간에 데이터베이스를 이동하기 위한 쉬운 방법이다. 이 과정에는?sp_detach_db나 엔터프라이즈 관리자를 사용하여 원본 서버에 존재하는 시스템 카탈로그로부터 해당 데이터베이스의 모든 정보를 삭제하고, 데이터 및 로그 파일을 새로운 서버의 지정 디렉터리에 복사하고, 그리고?sp_attach_db?나 엔터프라이즈 관리자를 사용하여 새로운 서버의 시스템 카탈로그에 해당 데이터베이스의 모든 정보를 등록하는 과정이 포함되어 있다.

데이터베이스 복사 마법사는 GUI(Graphical User Interface)를 이용 서버간에 선택적으로 데이터베이스와 로그인 계정을 옮길 수 있는 도구이다. 패키지 실행 시점에 감지된 모든 로그인 계정은 옮겨지며, 복사하기 위해 선택한 데이터베이스를 사용하는 로그인 계정만 복사된다. DTS 패키지는 데이터베이스 전송 작업에 의해 수행되는 로그인 전송 작업을 대상 서버에 만든다.

사용자 데이터베이스에 백업/복원, 데이터베이스 분리/ 데이터베이스 연결 시스템 저장 프로시저를 사용할 때, 로그인 계정은 목적지 서버로 전달되지 않는다. 즉, 다양한 보안 및 시스템 접근 문제가 발생된다. 이러한 상황을 방지하려면 원본 서버에서 로그인 계정에 대한 스크립트를 생성시켜 대상 서버에서 복원 작업 전에 해당 스크립트를 실행시키거나, 또는 DTS 로그인 전송 작업을 사용하거나, 로그인 계정과 데이터베이스 옮기기 작업이 모두 가능한 데이터베이스 복사 마법사 를 사용한다.?sp_change_users_login과?sp_resolve_logins?는 SQL 서버 권한 로그인 계정과 데이터베이스 사용자 계정을 다시 매핑시킨다.

보안 환경 관리

보안 환경을 관리할 때, 연결된 서버의 보안과 DTS 패키지의 보안을 보증하는 것이 중요하다.

연결된 서버 보안

기업 내에 연결된 서버를 가지고 있으면 이것에 대한 보안 설정을 원할 것이다. 연결된 서버의 보안은 엔터프라이즈 관리자 또는?sp_addlinkedsrvlogin를 통해서 설정할 수 있다. 연결된 서버의 보안을 가장 강화할 수 있는 방법은 윈도우 2000 액티브 디렉터리 서비스의 커버러스(Kerberos) 보안 기능인 보안 계정 위임(Security Account Delegation)을 사용하는 것이다. 이 기능으로 클라이언트는 서버간에 이동되는 분산 데이터의 요청 시 윈도우 자격 증명을 유지할 수 있다.

보안 계정 위임은 여러 서버에 연결하는 기능이며 각 서버가 변경되어도 원래 클라이언트의 인증 신임장은 유지된다. 예를 들어, 사용자 (LONDON\joetuck)가 ServerA에 연결한 다음 ServerB에 연결하면 ServerB가 연결 보안 ID가 LONDON\joetuck이라고 인식한다.

위임을 사용하려면 연결하려는 모든 서버가 커버러스 지원이 가능한 마이크로소프트 윈도우 2000을 실행 중이어야 하고 사용자는 윈도우 2000 용 디렉터리 서비스인 마이크로소프트 액티브 디렉터리를 사용해야 한다. 그리고 액티브 디렉터리에 다음과 같은 옵션이 지정되어 있어야 작업을 위임할 수 있다.

보안 계정 위임을 사용하려면 SQL Server에 다음 항목이 있어야 한다.

해당 컴퓨터에 있는 SQL 서버 서비스의 서비스 계정에 대해 SPN을 할당한다. 위임하면 상호 인증이 적용된다. 윈도우 2000 계정 도메인 관리자에 의해 SQL Server가 특정 서버에서, 특정 소켓 주소에서 검증되었는지를 입증하는 데 SPN이 필요하다. 도메인 관리자가 윈도우 2000 리소스 킷을 통해 setspn 유틸리티로 SQL 서버에 대한 SPN을 작성하도록 할 수 있다.

SQL 서버에 대한 SPN을 작성하려면 명령 프롬프트에서 다음 코드를 입력한다.

위임을 사용하려면 먼저 다음을 고려해야 한다.

SQL Server에 SPN 추가

MYDOMAIN\sqlsvc을 사용하여 포트 1433에서 수신 대기하는 SQL Server 이름이 "myserver.microsoft.com"인 인스턴스에 SPN을 추가하려면, 명령 프롬프트에서 다음을 실행한다.

Netbios 이름은 사용할 수 없으며 반드시 정식 DNS 이름을 사용한다. 서비스 계정에 대해 도메인 한정자를 지정할 수 없고, 계정 이름만 사용한다.

LocalSystem 계정을 변경하여 사용하려면 명령 프롬프트에서 다음을 입력하여 이전에 등록한 SPN을 삭제한다.

DTS 패키지 보안

SQL 서버 혹은 COM 구조 저장 파일에 저장되는 DTS 패키지는 소유자 암호 또는 사용자 암호를 가질 수 있다. 소유자 암호를 이용하는 사용자는 DTS 디자이너에 있는 패키지를 보고 변경할 수 있다. 사용자 암호를 이용하는 사용자는 해당 패키지를 실행할 수 있다. 보안 목적 때문에 소유자 암호는 모든 패키지에 할당한다. 이렇게 함으로써 다른 사용자가 사용하는 패키지의 내용을 보고 변경하는 것을 방지할 수 있다.

작업 스케쥴링으로 실행되는 패키지 소유자는 SQL 서버 엔터프라이즈 관리자에 기록된 보안 계정으로 확인된다. 윈도우 인증 모드를 사용하는 서버는 도메인 사용자 계정이 스케쥴링 작업의 소유자가 된다. SQL 서버 로그인 계정을 사용하는 서버는 SQL 서버 로그인 계정이 스케쥴링 작업의 소유자가 된다.

워크스테이션에 만든 패키지는 현재 윈도우 2000 사용자로 로그인한 보안 컨텍스트로 워크스테이션에서 실행된다. 작업의 일부분으로서 스케쥴된 패키지는 서버에서 실행된다. 실행되는 보안 컨텍스트는 작업 소유자가?sysadmin?고정 서버 역할의 구성원에 따라 의존적으로 동작한다.

sysadmin?고정 서버 역할 구성원의 로그인 계정이 소유하고 있는 작업은 SQL 서버 에이전트 계정의 보안 컨텍스트로 실행될 수 있다. 그렇지 않은 작업은 SQL 서버 에이전트 프락시 계정의 도메인 사용자 계정으로 실행될 것이다. 이러한 계정이 파일에 대한 적절한 파일 권한을 포함하고 있는지 확인한다. 패키지 내부에서 참조하는 네트워크 파일은 항상 UNC(Universal Naming Convention) 이름을 사용하므로 모든 사용자가 동일한 경로를 제공 받게 된다. 성능향상을 위해서는 해당 패키지를 수행할 수 있는 서버로 외부 파일을 복사한다.

dtsrun과 같이 명령행 유틸리티를 이용하여 실행되는 패키지는 현재 로그인한 윈도우 2000 사용자 계정 보안 컨텍스트로 실행된다.?dtsrun을 실행시키기 위해?xp_cmdshell를 사용하면 사용자가?sysadmin?고정 서버 역할 구성원인지 아닌지에 따라 의존적으로 보안 컨텍스트를 사용한다. 사용자가?sysadmin?고정 서버 역할 구성원이면 패키지는 SQL 서버 서비스 계정으로 실행되는 도메인 사용자 계정의 보안 컨텍스트로 실행된다. 사용자가?sysadmin 고정 서버 역할 구성이 아니면 패키지는 프락시 도메인 사용자 계정의 도메인 컨텍스트로 실행한다.

패키지에 연결할 때, 보안을 강화하려면 마이크로소프트 데이터 링크(.udl) 파일과 윈도우 인증을 사용한다. 또한 패키지에 ActiveX 스크립트에서 호출되는 COM 개체를 포함하고 있으면 그러한 COM 개체들이 패키지를 수행하는 서버에 저장되어 있는지 확인해야 한다.

요약

이장에서는 SQL 서버 2000 환경에서 아주 중요한 보안 하부구조와 가장 이상적인 SQL 보안 방법에 대한 내용에 대하여 논의하였다. 견고하고, 역동적이고, 효과적인 보안정책 개발에 초점을 두었다. 보안정책은 데이터 관리 환경하의 보안 구조를 효과적이고 일관성 있게 유지하는 바탕이다. 하드웨어 보안은 네트워크 시스템부터 개별 서버까지 검토하였고, 소프트웨어 보안은 클라이언트부터 미들 티어(middle tier)와 백엔드 서버까지 설명하였다. 관리적 보안 요소로는 서버, 로그인 계정, 사용자, 역할, 그리고 권한에 이르기까지 다루었다. 이러한 내용은 SQL 서버 2000 DBA로 하여금 기업의 보안 모델을 보다 잘 구축하고, 강화하고, 유지하고, 개선할 수 있게 할 것이다.

?