SQL 서버 2005 보안 가이드 2. 현실에서의 데이터베이스 보안
텔레비전을 보면 가끔 나오는 개인정보 유출이나 내부 직원의 기업 정보 유출은 드라마만의 내용이 아니라 이미 현실로 다가오고 있다. 도덕적으로 깨끗한 사람만을 채용하기에는 세상이 너무 복잡해지고 다양해졌다. 사고 사실을 알고 충격을 받아 당황하는 것은 이제 더 이상 남의 일이 아니다.
보안 전략 선택
필자는 얼마 전 A 고객사의 팀장으로부터 연락을 받았다. 그 내용은 보안에 관한 컨설팅이 필요하다는 것으로 약속을 정하고 방문을 하니 고객사 팀장은 개인정보보호법이라는 제목의 인쇄물을 필자에게 보여줬다. 개인정보보호법이 시행되면 어떻게 해야 할지에 관한 고민을 하고 있었다. 고객사 팀장은 이 문서에서 요구하는 사항을 만족할 수 있는 솔루션이나 관리 기법을 알고자 했다. 그래서 <그림 1>의 과정 중 3 요구 사항에 대한 솔루션 단계까지를 설명하기로 했다.
기능 요구 사항
필자를 비롯해 많은 사람들이 텔레마케터의 전화를 가끔 받는다. 나의 이름과 전화번호를 어떻게 알았냐고 물어보면 텔레마케터는 정확한 답변을 회피한다. 나의 정보가 어디서 유출되었을까? 인터넷에서 나는 누구일까? 인터넷에서의 나는 나를 대신한 ‘나의 정보’이다. 그런데 누군가가 나의 정보를 알고 있다면 나를 대신해 나쁜 짓을 할 수도 있을 것이다. 전자정부를 표방하고 있는 정부에서 이러한 개인정보를 보호하기 위해 법을 제정하는 것은 당연한 흐름일 것이다.
데이터베이스 관리자의 필요성
개인정보보호법 중 데이터베이스 관리 부분에는 인증, 계정 생성과 폐기, 계정 운영, 패스워드 관리에 대한 기본적인 요구 조건을 정의한다. 그밖에 추가적으로 잘못된 로그인 횟수에 대한 제한 설정, 일정시간 작업을 하지 않았을 때 자동 로그아웃되도록 한다는 내용 등이 있다. 접근 수준과 권한부여에 관한 항목도 눈에 띈다. 이와 같은 사항들은 데이터베이스 관리자가 처음 배우는 보안의 기본적인 내용이다. 단지 정책이 없기 때문에 전사적으로 적용한 적은 없더라도 교육을 통해 흔히 배우던 부분이다. SQL 서버 관리자에 의해 쉽게 정의될 수 있다. 예를 들어 <표 1>과 같이 사용자와 작업들을 정의하고 DB 서버에 적용하면 된다.
개인정보보호법을 위한 정책과 SQL DBA가 알아야 할 사항을 모두 이 지면에서 설명할 수는 없을 것이다. 다음과 같은 한 가지 예를 들어 설명해 보겠다. 다음 과정을 통해 정책과 솔루션 파악하고 적용하는 과정을 살펴보자.
⑴ 정책정의 : 정책 프로그램, 유틸리티, 명령어 등의 데이터에 대한 접근을 통제해야 한다.
⑵ 해결책 찾기 : 특정 프로그램을 어떻게 막을 수 있을까? SQL 서버에 이러한 기능이 내장되어 있느냐는 것인데, 당연히 포함되어 있다. 애플리케이션 역할을 이용하면 된다.
⑶ 관리자가 알아야 할 개념 : 애플리케이션 역할도 데이터베이스 역할의 일부분이다. 애플리케이션 역할은 그룹의 의미는 없고 오직 ‘권한의 집합이라는 의미만을 갖는다. 즉 애플리케이션 역할 안에는 데이터베이스 사용자가 포함되지 않는다. 애플리케이션 역할은 특정 업무가 있는데 다른 클라이언트(액세스, 엑셀 등)에서는 해당 데이터 접근을 금지하고, 오직 해당 업무를 위해 개발된 애플리케이션을 통해서만 데이터에 접근하도록 통제하기 위해서 사용된다.
⑷ 정책적용 : 다음에 살펴볼 ‘roleApp’라는 사용자정의 응용 프로그램 역할을 만드는 예제처럼 정책을 적용한다.
여기서 주의할 것이 있는데, 응용 프로그램 역할은 애플리케이션에서 사용하는 세션이 끝날 때까지만 유효하게 설정된다는 것이다. 세션이 종료되면 해당 애플리케이션을 사용하고 있던 사용자가 가지고 있는 모든 권한이나 역할도 모두 무효화된다.
사용자정의 응용 프로그램 역할을 만드는 방법은 엔터프라이즈 관리자를 사용하는 방법과 쿼리 분석기를 사용하는 방법이 있다. 먼저 엔터프라이즈 관리자를 사용하는 방법에 대해 알아보겠다. 엔터프라이즈 관리자를 사용하는 방법은 사용자정의 데이터베이스 역할을 만들 대상 데이터베이스의 ‘역할’을 선택하고, 오른쪽 클릭한 다음, ‘새 데이터베이스 역할’ 메뉴를 선택한다. 새 데이터베이스 역할 이름을 지정한 후 데이터베이스 역할 유형을 ‘응용 프로그램 역할’로 선택하면 된다. 마지막으로 응용 프로그램 역할에서 사용할 암호를 지정한 다음 ‘확인’ 버튼을 클릭하면 된다.
퀴리 분석기를 사용해서 사용자정의 응용 프로그램 역할을 추가하는 방법은 다음과 같다.
EXEC sp_addapprole N‘roleApp’, N‘password’
GO
-- 사용자정의 응용 프로그램 역할을 제거
EXEC sp_dropapprole N‘roleApp’
GO
-- developer1 데이터베이스 사용자가 열고 있는 세션에 roleApp 응용 프로그램 역할 부여
EXEC sp_setapprole roleApp, ‘a’
GO
참고로 응용 프로그램 역할에 대한 암호를 암호화하여 네트워크상에서 보안을 강화하고자 할 때는 다음과 같이 ODBC Encrypt 기능을 활용해서 암호화할 수 있다.
GO
<화면 1> 응용 프로그램 역할 만들기
<그림 1> 보안 전략 선택의 절차
<표 1> 사용자와 작업에 대한 정의 예
| 사용자 계정 | 작업 |
| feelanet | 모든 데이터베이스 액세스 |
| F_backup | 백업 작업 수행 |
| F_personnel | 인사 DB에 대한 액세스 |
| F_security | 기밀 데이터에 대한 액세스 |
| F_product | 제품 정보 읽기 전용 |
정책 프로그램, 유틸리티, 명령어 등의 데이터에 대한 접근을 통제해야 한다는 정책을 이해하고 애플리케이션 역할을 적용하는 관리자가 있는가? 정보보호법에 대비를 하고 회사의 보안 수준을 한 단계 높이고 싶은가? 이 모든 것은 물론 사람이 직접 해야 할 일이다. 좋은 관리자가 있다면 쉬운 일이겠지만, 반대로 얘기하면 좋은 관리자가 없기 때문에 문제가 발생한다는 것이다.
현실에서 반영하기 어려운 문제
기능 요구 사항에 맞게끔 SQL 서버의 보안을 설명하던 중 A사 팀장은 필자에게 바로 적용하기 힘들 것 같다는 의견을 주었다. 개발자들이 운영중인 데이터베이스에 개체를 만들지 못하고 테스트 서버에서 만들면 DBA가 직접 적용하는 형태로 진행하기에는 현실적으로 어렵다는 것이다. 수많은 개발자들이 db_owner가 될 수밖에 없는 형편이라 적용하려는 정책 중 지금 적용할 수 없는 일들이 발생한다는 설명이었다. 필자는 항상 고객사에게 컨설팅할 때 만약 개발자 중 악의를 품고 데이터를 삭제한다거나 고객 정보를 나쁜 의도로 사용하는 것에 대한 대책은 있냐고 물어보면 대부분 고객사들에게서 현재는 별다른 방법이 없다는 답변을 듣는다. 개인정보보호법이나 회사의 정책을 적용하기 위해서는 통제된 환경에서 오는 불편함을 기꺼이 받아들여야 하고 새로운 투자가 필요하다는 딜레마에 빠진다. 현실에서의 데이터베이스 보안은 개발의 편리성과 그와 상충되는 운영 환경에서 통제되고 문서화된 관리 절차를 어떻게 접목하느냐의 선택일 것이다.
요구 사항에 대한 솔루션 검토
기능 요구 조건이 정의가 되면 어떻게 조건을 만족시켜야 하는지 선택해야 한다. 사람이 모든 일을 하기에는 많은 시간이 들고 반복적으로 일을 해야 하며 능력에 따라 다른 결과를 가져오기도 한다. 많은 솔루션 업체들이 이런 문제를 해결하기 위해 고민을 했고 그 결과 훌륭한 제품을 만들게 되었다. 관리자가 해야 할 일은 이 제품들 중 어느 것이 가장 적은 비용으로 가장 많은 이익을 얻을지 선택하면 된다.
뜨거운 감자가 된 암호화
중요 정보에 대한 침해 사고와 악용 사례가 증가하고 있다. 고객정보 유출로 인해 심각한 피해가 발생하고 기업의 이미지가 실추된다. 사람들의 악용으로부터 개인정보를 막기 위해 기밀성이 요구되는 DB 시스템 내의 중요 필드에 대해 암호화되어 있어야 한다. 개인정보(주민번호, 계좌번호, 의료보험증번호 등)를 DB에 저장할 때 암호화해서 저장해야 할 것을 의무화하고 있다. 주민번호를 대체하는 방식이 논의되고 있는 등 아직 완전한 스펙이 정의된 것은 아니다.
암호화를 위한 솔루션으로는 소프트웨어 방식과 하드웨어 방식이 있는데, 항상 그렇듯이 소프트웨어 방식은 하드웨어 방식에 성능이 떨어진다는 단점을 지적받고 있다. SQL 서버 2005 또한 자체적으로 데이터 암호화가 탑재되어 있어 개발자나 관리자가 공부해야 할 영역이 늘어났다. 그리고 많은 소스코드가 공개되어 있어 개발자들이 특정 컬럼을 암호화하는 것은 어려운 일이 아니다. www.codeproject. com/database/xp_md5.asp에서는 SQL 서버 2000에서도 확장 프로시저를 사용하여 암호화하는 방법을 보여준다.
손쉬운 암호화 기술로 아무 문제도 없다는 결론이면 행복한 사람(관리자), 불행한 사람(솔루션 제공자)들이 생기겠지만 현실은 그 반대의 결론으로 흘러가고 있다. 암호화 자체가 기술적으로 문제되는 것은 아니지만 데이터베이스의 특정 컬럼을 암호화하면 인덱스를 사용할 수 없어 성능에 큰 문제를 야기한다. 그리고 법의 내용과 시행이 어떻게 진행될지에 대한 정확한 정보가 없는 상태다. 데이터베이스 디자인이 변경되거나 추가 장비로 인해 비용, 데이터베이스와 통합된 기술 등이 문제될 것이다. 법으로 강요해도 중소기업들의 인프라 구축과 기술 부족으로 인해 지킬 수 없는 법이 될지도 모른다.
감사 시스템
최근 실시된 CSI/FBI(Computer Security Institute/Federal Bureau of Investigation) 컴퓨터 범죄와 보안 관련 설문 조사 결과를 보면 정보 도난과 DoS(Denial-of-Service, 서비스 거부) 공격으로 인한 손실이 가장 크다는 것을 알 수 있다. 여기서 주목해야 할 내용은 내부 사용자의 정보 도난이다. 인가된 내부 사용자들은 권한이 있음으로 데이터에 접속할 수 있는 것은 당연한 일이다. 인가된 내부 사용자에 의한 사고에 대비한 데이터베이스 감사 솔루션 필요성이 제기된다.
SQL 서버의 감사 기능
SQL 서버 2005는 C2 audit 설정을 통해 SQL 서버에서 일어난 모든 명령문과 개체 액세스에 성공하거나 성공하지 않은 시도를 검토할 수 있다. 이런 모든 내용은 추적 파일에 기록되며 이것은 프로필러를 사용하여 살펴볼 수 있다. 뜻하지 않은 데이터의 삭제, 테이블 삭제 등의 원인들도 찾을 수 있다. 이를 위해서는 다음과 같은 설정이 필요하다. 단 주의할 점은 서버에 약간의 부하가 걸리며, 추적 파일을 쓸 수 없으면 서버는 자동으로 중지된다는 것이다. 참고로 서버를 재시작해야만 C2 보안 감사가 시작된다.
go
RECONFIGURE
go
sp_configure ‘c2 audit mode’, 1
go
RECONFIGURE
go
감사 파일은 SQL 서버 데이터 폴더(보통 C:\Program Files\Microsoft SQL Server\MSSQL\Data)에 ‘audit trace_yyyymmddhhmmss.trc’로 저장되며 200MB 분량이 다 차거나 서비스가 중지되어야 파일로 남게 된다. 그리고 나서 새로운 파일을 또 기록하게 된다. 해당 폴더에 공간이 없으면 SQL 서버 서비스가 시작되지 않는다. 감사를 중지할 때는 앞의 스크립트에서 다음과 같이 바꾸어 실행하고 SQL 서버 서비스를 재시작하면 된다.
참고로 써드파티에서는 보안을 위한 제품을 만들어 판매하고 있다. SQL 서버가 기본적으로 제공하는 이상의 보안 감사를 원한다면 이런 제품들을 고려해 볼 수도 있다. 써드파티 보안감사 제품을 보고 싶다면 www. microsoft.com/sql/partners/technologysolutions/ security.asp를 참고하면 된다. 국산 제품은 아직 이곳에서 소개되지 않고 있다.
써드파티 솔루션 소개
여러 제품이 있겠지만 필자가 사용해 본 경험이 있는 IAuditor라는 제품을 잠깐 살펴보면 서버에 전혀 부하를 주지 않고도 SQL 서버에 들어오는 모든 패킷을 손실 없이 잡아낸다. 작은 규모의 사이트라면 약간의 부하가 문제가 되지 않겠지만 대용량 트랜잭션이 빈번한 사이트라면 이야기가 달라진다. SQL 서버의 감사 기능으로 충분한가? 그렇지 않다면 감사 솔루션의 구입이 필연적일 수 있다. 항상 기억해야 할 것은 소프트웨어 방식은 시스템에 많은 부하를 주고 하드웨어 방식은 시스템에 부하를 주지 않는 장점이 있다는 것이다.
<그림 2>는 IAudit에서 제공하는 기능을 설명하고 있으며, <그림 3>은 스위치 장비에 들어오는 패킷을 TAP나 포트 미러를 통해 감사 서버로 전달함으로서 프로덕션 서버에 영향을 주지 않는 구조하는 IAudit 아키텍처를 설명하고 있다. 대부분의 감사 솔루션들이 이와 비슷한 구조를 가지고 있다.
보안이 취약한 이유
사고 관리는 가능한 빨리 사용자에게 서비스를 복원하는 것이고 문제 관리는 문제에 대한 영구 해결책을 제시하는 것이다. 많은 중소기업에서 문제가 발생하면 전문 업체로부터 컨설팅을 받거나 자체적으로 해결하는 것으로 사고 관리가 부분적으로 이뤄지고 있지만 문제에 대한 근본적인 해결책이 이뤄지지 않고 있다. 근본적인 이유는 돈과 관계가 있는 것으로 보안에 따로 투자할 여력이 없다는 것이다. 그러나 반드시 알아야 할 사항은 보안 시스템을 구현하는 데에도 상당한 비용이 들지만 이 비용은 보안 사고에 따른 손상을 줄이기 위한 비용에 비하면 극히 미미하다는 것이다.
<그림 2> IAuditor 기능 소개
<그림 3> IAuditor 아키텍처
출처 : 마이크로소프트웨어 2006년 2월호
