SQL 서버 2005 보안 가이드 1. 안전한 데이터베이스를 위한 보안 기법

2007. 1. 28. 21:57 IT 및 개발/MS-SQL & T-SQL
기업들은 몇 번의 사고를 경험한 후에야 보안의 필요성을 인식하게 된다. 보안을 위한 턴키는 없으며, 다만 자신의 계층에서 최선을 다하면 될 것 이다. 물리적인 취약점이 존재하더라도 자신의 데이터베이스를 충실히 관리하는 장인정신이 필요하다. 현실에서의 데이터베이스 보안 핵심은 장인정신을 가진 관리자를 양성하는 것이 아닐까 생각해 본다.

얼마 전에 SQL 서버 2005가 출시되었다. 많은 회사에서 SQL 서버를 2005 버전으로 업그레이드할 것이고, 이에 따라 관리자는 새로운 기능을 익혀야 하며 알아야 할 사항도 많아졌다. 새로운 기능, 보안, 가용성, 성능 등에서 5년의 세월동안 SQL 서버가 진화했기 때문이다. 개인정보보호법에 DB시스템 내의 중요 컬럼을 암호화해야 하고 기밀성 데이터를 데이터베이스에 전송할 때도 암호화해야 한다고 되어 있다. 그래서 SQL 서버 2005로 암호화하는 방법과 기능을 미리 파악해야 할 필요성이 있다. SQL 서버가 제공하는 보안 모델을 살펴보고 어떻게 적용할 건지를 고민해야 할 시기가 왔다.


서버와의 연결은 안전한가?

SQL 서버 2005에 접속하기 위한 문과 열쇠를 이해할 필요가 있다. 문을 통해 정상적인 접속이 가능하지만 문을 악용해서 비정상적인 접속을 시도할 수 있다는 것도 염두에 둬야 한다. 이 문은 열쇠가 없이는 들어올 수 없을 정도로 최신의 기술을 갖추었다. 하지만 열쇠를 문 입구의 화단 밑에 숨겨 놓았다면 약간의 짐작으로 열쇠를 획득 할 수 있을 것이다. 기본적인 액세스 컨트롤은 문과 열쇠에 대해 이해하고 서버와의 연결을 제어하는 것이다.

엔드포인트 기반 인증

엔드포인트(Endpoint)는 인스턴스에 대한 엔트리 포인트로서 HTTP, 서비스 브로코, 데이터베이스 미러링 등에 사용된다. 어떤 목적으로 사용할지 명시적으로 만들지 않는다면, 존재하지 않고 기본적으로 어떠한 퍼미션도 없다. 생소하게 느껴질 수도 있으나, 외부에서 SQL 서버로 들어오기 위한 문이라고 생각하면 쉽게 이해할 수 있을 것이다. 이 문을 구성하기 위해서는 다음과 같이 사용 목적과 사용할 프로토콜, 접속 퍼미션 등을 부여해야 한다.

◆ SOAP, SSB, 데이터베이스 미러링 등에 사용된다.
◆ TCP, HTTP 등의 프로토콜을 사용한다.
◆ 허락된 사용자에게 접속 퍼미션을 부여한다.

사용 목적과, 프로토콜, 퍼미션 등을 부여하는 문법을 이용해 상품을 조회하는 엔드포인트를 다음과 같이 만들어 보자.

CREATE ENDPOINT 상품조회_Endpoint
STATE = STARTED
AS HTTP(
    PATH = ‘/Products’,
    AUTHENTICATION = (INTEGRATED),
    PORTS = ( CLEAR ))
FOR SOAP(
    WEBMETHOD ‘상품조회_SP’ (name=’AdventureWorks.Production.상품조회_SP’,FORMAT=ROWSETS_ONLY),
    WEBMETHOD ‘가격수정_sp’ (name=’AdventureWorks.Production.가격수정_sp’),
        WSDL = DEFAULT,
        DATABASE = ‘AdventureWorks’,
        NAMESPACE = ‘http://Feelanet.com/’
   )

기본적으로 엔드포인트에 접속할 수 있는 사용자는 아무도 없다. 예를 들어 철수가 SOAP를 통해 SQL 서버 2005에 접속해 상품조회를 하고 싶다면 다음과 같은 조치를 취해야 한다.

--철수에게 상품조회_Endpoint에 접근할 수 있는 권한을 준다.
GRANT CONNECT ON ENDPOINT:: 상품조회_Endpoint TO [철수]
--철수에게 상품조회_SP를 실행할 수 있는 권한을 준다.
USE AdventureWorks
GO
GRANT EXECUTE ON Production.상품조회_SP TO [철수]

다음 예제는 영희가 SOAP를 통해 상품조회와 가격 수정을 해야 하는 경우이다.

GRANT CONNECT ON ENDPOINT:: 상품조회_Endpoint TO [영희]
USE AdventureWorks
GO
GRANT EXECUTE ON Production.상품조회_SP TO [영희]
GRANT EXECUTE ON Production.가격수정_SP TO [영희]

엔드포인트에 대한 이해는 SQL 서버 2005의 여러 가지 기능들이 사용될 때 필수적이며 관리자의 중요한 보안 포인트가 될 것이다. 엔드포인트를 통해 지구촌 여러 곳에서 SQL 서버를 사용하는 환경이 만들어지고 편리성과 필요성은 많은 부분에서 충족되겠지만 보안에 틈이 생긴다면 무용지물이 될 수도 있다.

<화면 1> 윈도우의 보안 설정


<화면 2> 정책 위반으로 계정 만들기 실패


<화면 3> 계정 만들기



강화된 암호 정책

암호 정책이 없다는 것은 열쇠를 방치하고 있다는 것과 유사하다. 2005 이전 버전에서는 회사 정책에 의해 관리자가 수동으로 암호를 바꾸거나 복잡한 암호를 사용해야 했지만 시스템이 강요할 수는 없었다. 지키지 않아도 무방했다는 뜻이다. 하지만 SQL 서버 2005에서는 다음과 같이 강화된 암호 정책을 지원한다. 지키지 않을 수 없다는 것을 의미한다.

◆ 로그인 정책 강화 : 암호 길이, 암호 만료기간, 계정 잠금
◆ 로컬 윈도우 암호 정책 계승 : 지속적인 기업 광범위 정책 지원
◆ 접근 : 새로운 API 암호 정책 점검, 윈도우 서버 2003 이상만 사용가능, 이전 버전에 대한 초보적인 복잡성 점검

SQL 서버 2005는 윈도우 서버 2003의 암호 정책을 그대로 상속받는다. 암호는 최소 6자리 이상으로 하고 단순한 암호는 사용할 수 없다는 정책을 윈도우 서버 2003에서 설정했다면, SQL 서버 2005에 그대로 상속되어 계정의 암호 정책에 반영된다.

윈도우 서버 2003의 암호 정책을 따르지 않는다면 <화면 2>와 같은 결과가 나온다. 암호의 복잡성을 만족시키지 못하기 때문에 계정이 만들어지지 않는 단순한 데모다. 그래서 <화면 3>과 같이 정책을 위반하지 않도록 암호를 복잡하게 만들었고 반드시 다음에 로그인시 암호를 바꾸도록 설정했다.

예전에 경찰 보안 담당자들에게 집에 설치된 번호키를 몇 자리의 번호로 설정하고 얼마나 자주 바꾸는 것이 좋은지 물어본 적이 있다. 그 보안 담당자의 대답은 7자리 이상의 번호와 한 달에 한 번씩은 바꿔야 한다는 것이었다. 하지만 과연 현실이 그럴까? 보통은 1년에 한 번도 바꾸지 않는 것이 현실로 알고 있다.

또한 집에 초등학생이 있다면 따를 수 있는 정책이겠는가. 필자는 최소한의 원칙을 만들고 지켜나가는 것이 보안의 시작이라 생각한다. 적어도 자신이 관리하는 서버 개체들은 안전한가와 최소한의 특권 원칙을 지키고 있는지는 생각해봐야 한다.

데이터베이스는 모두 SA(System Administrator) 계정으로 접근하는 것이 일반적이고 당연하게 생각되고 있다. 윈도우는 Administrator로, SQL 서버는 SA로 로그인하는 이상한 관습들이 많은 회사를 지배하고 있다. 누구나 실수를 할 수도 있고 접근하지 말아야 하는 곳에 접근하고 싶은 욕심이 생길 수도 있다. 기본을 지키지 않아서 발생하는 많은 문제들을 경험할 수도 있다.


데이터베이스 개체 보안

데이터베이스 개체가 어디에 존재하는지를 생각해보자. 우물에서 숭늉을 찾을 수는 없는 노릇이다. 개체에 퍼미션을 설정하는 기본 작업과 함께 개체들을 논리적으로 나눠서 저장하는 것은 중요하다. 이전 버전에서는 데이터베이스 단위로만 나눌 수 있었으나 SQL 서버 2005에서는 스키마를 지원으로 세분화하고 있다. 또 하나의 중요 특징은 실행 문맥 제어를 통해 직접적인 권한 대신 대리인의 문맥으로 실행할 수 있다는 것이다.

새로운 등장, 스키마

보안의 세부 단위가 새롭게 등장했다. 스키마는 데이터베이스를 보안 단위나 논리적 단위(응용 프로그램)로 나눌 수 있는 개념이다. 책상에 서랍이 여러 개 있는 개념이라고 할 수 있다. 윗 서랍의 관리자와 아랫 서랍 관리자 그리고 사용자를 각각 분리해서 처리할 수 있다. 그래서 이제 개체를 명명할 때는 서버, 데이터베이스, 스키마, 개체로 불러야 한다. SQL 서버 2000에서는 서버, 데이터베이스, 소유자, 개체의 이름을 가졌다. 그래서 소유자를 삭제하고 싶어도 개체의 소유주이기에 지울 수 없거나 개체의 소유자를 다 바꾸고 삭제하는 무식한(?) 행동을 해야 했다. 하지만 2005에서는 스키마로 대처되어 이런 불편함이 사라지게 되었다. 사용자 스키마를 제한하면 다른 스키마의 접근이 차단되어 향상된 보안 관리를 할 수 있다. 그리고 응용 프로그램에게 향상된 네임스페이스 관리 계획을 제공한다. <리스트 1>은 스키마 수준의 개체 보안에 관해 보여주고 있으며, <그림 1>은 데이터베이스 스키마 개체의 계층 구조를 설명하고 있다.

실행 문맥 제어

기본적인 실행 문맥은 호출한 사용자의 권한으로 실행하면 된다. 데이터를 지우는 업무를 하기 위해서는 지울 수 있는 권한이 있어야 한다는 의미이다. 업무의 단위로 권한을 부여하다 보면 최소한의 권한이 아니라 어쩔 수 없이 많은 권한의 줘야 하는 경우가 생기기도 한다. 예를 들어 특정 테이블만 truncate할 수 있는 권한은 없다. 그래서 truncate 권한을 주면 다른 테이블에 대한 권한이 생겨 문제가 야기될 수 있다는 것이다. 그래서 특정 테이블을 지울 수 있는 개체를 만들고 개체를 실행할 수 있는 권한을 줘서 그 개체에서 수행하는 업무를 다른 사용자의 문맥으로 수행해야 할 필요성이 존재한다. 최소한의 권한 부여라는 보안의 기본원칙을 실행 문맥 제어를 통해 세밀하게 정의할 수 있게 되었다.

<그림 1> 스키마의 계층 구조


<표 1> 퍼미션을 조회하는 카탈로그 뷰

카탈로그 뷰 내용
Sys.Server_permissions 서버 레벨 퍼미션
Sys.database_permissions 데이터베이스 레벨 퍼미션
Sys.securable_permissions 모든 보호된 객체 리스트
Sys.fn_builtin_permissions 모든 수여 가능한 퍼미션 목록

EXECUTE AS와 SETUSER

저장 프로시저를 만들 때 누구의 문맥으로 실행할지를 지정할 수 있다. 사용자들은 저장 프로시저를 호출한 권한만 있으면 저장 프로시저에서 어떤 일을 하는가에 따른 퍼미션을 신경 쓰지 않아도 된다. Execute As는 「{ EXEC | EXECUTE } AS { CALLER | SELF | OWNER | ‘user_name’ } 」와 같이 사용한다. 여기서 CALLER는 호출한 사용자(기본 값), SELF는 저장 프로시저나 함수를 만든 사용자를 말한다. 또 OWNER는 소유자 문맥, user_name에는 특정 사용자를 지정한다. 그리고 SETUSER는 「SETUSER [ ‘username’ [ WITH NORESET ] ] 」와 같이 사용한다. EXECUTE AS는 저장 프로시저가 동작하는 순간에만 유효하지만 SETUSER는 다른 사용자로 가장해서 다른 업무를 수행하다가 다시 자신의 계정으로 돌아온다.

SETUSER ‘원혁’
GO
GRANT SELECT ON 한글탐정 TO 원용
GO
SETUSER

퍼미션 검사

관리자가 조회해야 할 기본적인 카탈로그 뷰이다. 누가 어떤 권한을 가지고 있는지를 보고 싶다면 <표 1>과 같은 뷰들과 친숙해야 한다. 필자가 SQL 서버 2000을 강의할 때 가장 많아 듣던 질문 중 하나가 어떻게 보안이 설정되었는지 보고 싶다는 것이었다.

데이터 암호화

보안 강화를 위해 민감한 데이터는 암호화되어야 한다. 아무리 관리자라도 고객들의 민감한 데이터를 볼 권한은 없다. 고객의 비밀번호나 주민등록번호 등과 같은 데이터를 생각해보자. 요즘은 데이터베이스에서 암호화는 필수적으로 필요한 시대에 왔다. 또한 법률 규정이 강화되고 있어 회사의 정책이나 법률 규정에 따라서도 데이터를 암호화해야 한다. 2005 이전 버전에서는 암호화된 모듈을 개발하거나 전문 업체의 제품을 구입하는 것으로 암호화가 이뤄졌다. SQL 서버에서 직접 지원하지 못했기 때문에 벤더 스스로가 해결책을 찾아야만 했다. 그러나 SQL 서버 2005는 데이터 암호화가 탑재되어 있다. 이전 버전보다 진보되었고 시대의 흐름을 반영하고 있다는 증거가 될 것이다.

키 이해하기

서비스 마스터 키는 연결된 서버의 암호, 데이터베이스 마스터 키 보호 등 시스템 데이터 보호 역할을 담당한다. 서비스 마스터 키는 현관 열쇠로 비유할 수 있는 것으로 연결된 서버의 암호와 연결 문자를 암호화하는데 사용된다. 그리고 데이터베이스 마스터 키를 암호화할 때도 사용될 수 있다. 방마다 열쇠(데이터베이스 마스터 키)가 있고 이 열쇠의 목적은 방안의 귀중품을 지키는 것이다. 그럼 이 열쇠는 누가 보호하고 있는 가를 생각해보면 이해가 될 것이다. 현관 열쇠를 이용해서 현관에 들어온 이후에야 방 열쇠를 사용할 수 있다.

데이터베이스 마스터 키는 디지털 증명서와 비대칭 키를 암호화하는데 사용되며, 디지털 증명서와 비대칭 키는 대칭키를 암호화하는데 사용된다. 방안에 있는 책상 열쇠가 최종적인 데이터를 보호할 것이다. 대칭키를 책상 열쇠로 생각하면 이해가 빠를 것이다. <그림 2>는 암호화 계층 구조를 보여주고 있다. 가장 상위에는 서비스 마스터 키가 있고, 윈도우의 DPAPI에 의해 암호화되어 있다.

디지털 증명서

디지털 증명서는 크게 다음 3가지 용도로 사용된다.

◆ 서비스 브로커에서 커뮤니케이션 인증이나 메시지를 암호화하는데 사용된다.
◆ 저장 프로시저 등의 개체에 서명하여 코드 인증을 한다.
◆ 디지털 증명서를 이용해 데이터를 암호화하고 복호화한다.

디지털 증명서를 사용하기 위해서는 새로운 T-Sql문을 익혀야 한다. <리스트 2>는 디지털 증명서를 만드는 문법을 보여주고 있고, <리스트 3>에는 특정 컬럼을 암호화하는 데모이다. 데모를 따라하면 <화면 4>와 같이 암호화된 결과를 확인할 수 있다.

SQL 서버 감사

데이터베이스 관련 분야에는 많은 솔루션들이 있다. 그 중에서 최근에 많은 관심을 받고 있는 솔루션은 감사와 관계되는 솔루션들이다. 네트워크에서 들어오는 모든 쿼리문을 데이터 손실 없이 잡아내는 제품부터 Agent 방식의 제품까지 정말 다양하다. 일반적인 회사의 업무에서 사용할 목적이라면 SQL 서버 2005에서 제공하는 감사 기능으로 충분할 수 있다. 그러나 특수한 목적이 있다면 SQL 서버 2005와 함께 추가적인 솔루션 도입을 고려해야 한다. 다음은 SQL 서버 2005의 감사 기능이다.

◆ 데이터 접근 감사 : SQL 서버에는 프로필러라는 모니터링 도구가 있다. 이벤트를 선택하고 데이터를 필터링하게 구성하면 쿼리문을 실시간으로 감사할 수 있다. 그러나 클라이언트에서 이 도구를 이용해서 실시간으로 보게 되면 서버에 부하를 줄 수 있다. 그래서 가급적이면 저장 프로시저를 이용해 파일로 남겨두고 나중에 프로필러에 불러오거나 테이블로 저장해두고 서버에 어떤 일이 발생했는지 감사할 수 있다. 감사 도구라기보다는 모니터링 도구에 가깝지만 특정 시간대에 일어나는 일을 보기 위한 용도라면 충분할 것이다. 서버가 다운되었는데, 블랙박스가 없다면 정확한 원인을 알기 힘들다. SQL 서버에도 블랙박스를 만들 수 있다.

◆ 로그인 감사 : 누가 언제 접속했는지를 알 필요성이 있다. 누군가 서버로 침입하기 위한 기록을 남겼다면 그런 공격에 대한 대비를 할 수 있다. SQL 서버 2005는 기본적으로 실패한 로그인 시도에 대해 감사하도록 설정되어 있다. 관리자는 정기적으로 감사 이벤트를 확인해야 한다.

◆ 사용자 정의 감사 : 누가 데이터를 삭제했는지 테이블을 수정했는지를 알고 싶다면 트리거나 이벤트 알림을 사용해야 한다. 외부의 침입뿐만 아니라 내부 운영에 관해서도 누가 어떤 일을 했는지 알아야 한다. 트리거나 이벤트 알림 서비스를 사용해서 구현하는데 목적에 맞는 감사 테이블을 만들고 특정 행위가 일어나면 감사 테이블로 적재하는 형태로 구현된다.

<그림 2> SQL 서버 2005 암호화 계층 구조



<화면 4> 암호화된 데이터 조회 결과

서버 구성은 안전한가?

Surface Area Configuration은 새로운 설치의 기본 보안을 지원하기 위한 도구이다. 윈도우를 설치하면 기본적으로 많은 서비스가 시작된다. 사용하지 않는 서비스가 동작하면 서버 리소스(메모리 등)가 그 만큼 낭비되고 보안의 틈은 그 만큼 커지게 된다. 좀 더 쉽게 SQL 서버를 구성하자는 단순하지만 직관적인 생각으로는 새로운 도구를 만들 수 없을 것이다. 처음 이 단어를 접했을 때 당황스러웠지만 한번만 실행해 보면 모든 것이 이해될 것이다.

<화면 5>는 Surface Area Configuration의 기본 화면 구성을 보여 준다. 화면에서 몇 번 클릭해보면 이 도구를 쉽게 이해 할 수 있을 것이지만, 간단히 정리하면 다음과 같은 일을 한다.

◆ 설치 시 서비스를 선택할 수 있다(가급적 필요 없는 서비스는 멈추는 것이 좋다).
◆ 기능 레벨에서 특정 기능의 ON/OFF 스위칭이 가능하다.
◆ 특정 통신 프로토콜에 대한 ON/OFF 스위칭이 가능하다.

보안 진단 체크 리스트

보안 진단 체크 리스트는 사람에 따라 평가가 달라지면 안되기 때문에 템플릿이 필요하다. <표 2>를 간단히 보자. 11가지 중 Yes라는 대답이 6가지 이상이 안되면 서버의 보안 상태는 아주 낮은 수준일 것이다. MS에서는 운영자 가이드, 보안 가이드를 통해 많은 정보를 주고 있다. 이러한 정보를 이용해서 단순하지만 적용 가능한 체크리스트를 만들어 활용해야 한다.

이론에 대한 실천이 중요

지금까지 SQL 서버 2005가 제공하는 보안 모델에 대해 살펴봤다. SQL 서버 2005에 관한 정보는 아직 부족하지만 점점 많아질 것이다. 아무리 많은 이론을 알아도 실천하지 못하는 지식은 반쪽이라고 생각한다. 어디서부터 시작하면 좋을까? SQL 서버 2005를 테스트 장비에 설치하고 시뮬레이션을 해보는 것도 좋은 시작일 것이다. 짧은 지면이라 SQL 서버 2005의 모든 보안 기술을 나열하지는 못했지만 전체를 간단히 살펴 볼 수 있는 기회가 되었으면 좋겠다.


<화면 5> 서비스와 연결 구성


<화면 6> 응용 프로그램에서 요구하는 기능 제어 구성

<표 2> 간단한 보안 체크 리스트

다음을 수행하고 있나? Yes or No
주기적으로 MBSA 실행  
정책 점검과 널 값 암호이 삭제 또는 검색  
사용되지 않은 로그인 삭제  
Public에 대한 퍼미션 객체 검색  
로그인-사용자 맵핑 확인  
붙이기/분리하기 방법  
Sp_change_users_login  
역할에 소속된 멤버십 관리  
트러스트된 개별 맴버십 확인  
서버 시작 시 프로시저의 안정성 확인  
주기적 검색 필요 -the surface area  

출처 : 마이크로소프트웨어 2006년 1월호