실제 데이터베이스 보안사고 유형 및 대응 사례
아래 실제 회사에서 발생 한 사고들에 대해 보편적인 실례를 든 것이며 각각의 케이스를 통하여 사내에서 어떤 식의 보안 정책이 필요하고, 어떤 기능의 솔루션이 필요한 지에 대하여 기술을 한 것이다.
1. 외부 침입에 의한 사고
A. SQL Injection을 통한 공격
 정의
웹 등에서 강제로 SQL 구문을 삽입하여 권환 취득 후 내부의 데이터를 유출, 변조 하는 등의
공격을 얘기한다.
현황
이러한 공격은 방어하기가 무척 어려운데, 정상적인 사용자와 해킹을 시도하는 자를
구분하기가 실제 불가능하기 때문이다.
이러한 해킹 시도는 무척 빈번하게 발생되고 있으나 보안에 관련하여 미처 신경을 쓰지 못한
곳에서는 번번히 당하면서도 어떻게 해결해야 하는지, 혹은 자사 데이터가 누출되었는지 모르는
경우도 허다하다.
대응책
보통의 사이트는 정형화 되어 있는 쿼리를 많이 사용한다.
이를 활용하여 정형화 되지 않은 쿼리가 발생하였을 시 관리자에게 이것을 바로 통보해 주어
관리자 판단하에 침입자에 대한 차단작업을 할 수 있도록 하고 이후 해킹시도를 방지할 수 있는 보안
룰을 세팅 도록 함
iProtector에서는 이러한 보안정책을 위하여 항상 새로운 형태의 쿼리가 수집되는 것을 실시간으로
감지하는 기능을 제공하고 있다. 이를 통해서 새로운 형태가 수집될 경우 관리자가 그것을 확인하고
해킹의 시도가 있었는지에 대한 판단을 할 수 있는 가장 중요한 자료를 제공 해 준다.
매일매일 쿼리들을 뒤져가며 찾아야 할 작업의 양을 대폭적으로 줄여주기 때문에 현장 보안요원들이
가장 환영하고 있는 기능이기도 하다.
B. Back door 프로그램을 통한 정보 빼내기
정의
시스템의 보안구멍을 이야기 한다. 원래 의미로는 관리자가 시스템에 문제가 있을 경우 접근하기 위한
숨겨져 있는 접근방법을 의미한다. 요즘에는 데이터베이스에 접근이 가능한 Web Server 등에 backdoor
프로그램을 심어 사용권한을 획득하거나 데이터를 유출하는 등의 공격을 이야기 한다.
현황
Backdoor 프로그램의 경우 공격을 시도하기 자체가 무척 까다로운 반면 (네트워크 보안을 뚫기가 쉽지
않기 때문) 일단 설치되고 나면 Backdoor가 존재하는지를 파악하기가 무척이나 어렵기 때문에 흔히 발생
되지는 않지만 사고의 규모가 큰 것이 특징이다.
실제로 알려진 사례는 많이 없으나 보안에 신경 쓰지 못하는 많은 업체가 이러한 공격에 속수무책으로
당하고 있다는 것은 널리 알려진 사실이다. 더군다나 자사의 컴퓨터가 이미 감염되어 또 다른 공격의 경유
지로 사용되는 경우도 많아 각별한 주의가 필요한 실정이다.
대응책
백신 프로그램/네트워크의 보안 등의 기본적인 보안 솔루션을 통해 백도어 프로그램은 제 일차적으로
반드시 걸러져야 한다.
그러나 결국 백도어 프로그램이 데이터베이스에 접근할 수 있는 상황이 된다고 했을 때 가장 마지막인
보안은 결국 데이터베이스를 정보 자체를 보호하는 방법 뿐이다.
이를 위해 데이터베이스 보안 솔루션은 외부 접속 서버들에게서 오는 질의(query)들에 대해 다양한
이러한 상황을 처리하기 위해 다양한 보안룰을 세팅할 수 있어야 한다.
터베이스 솔루션을 사용하는 많은 회사에서는 위와 같은 문제를 피하기 위해 정상적인 사용자에 의한
정상 질의라 하더라도 그것을 감시하기 위한 다양한 룰을 적용하고 있다. 위와 같은 백도의 프로그램의
불법적인 데이터 유출을 피하기 위해서는 감시의 대상을 자세하게 특정할 수 있고 실시간으로 그것을
알려주고 저장할 수 있는 능력이 솔루션의 능력을 가리게 된다.
iProtector에서는 이러한 정상적인 쿼리를 가장한 악성 쿼리들을 감지해 내기 위해서 많은 옵션들을
제공 해 준다. 기본적인 세션정보인 IP/MAC/USER 등으로 보안 룰을 정할 수 있는 것은 물론, 쿼리에
들어있는 특정 단어 필터링, 시간대별 룰 적용, 응답의 양을 제한하는 룰 등 수많은 옵션이 존재한다.
이러한 옵션들은 수년간 현장에서 보안요원들이 원하는 내용을 최적화 하여 적용하였기 때문에 만족스럽게
사용할 수 있을 뿐 아니라, 현재도 새로운 해킹시도에 대한 필요한 요청이 생길 경우 이를 즉각적으로
반영해 주고 있는 등, 꾸준히 최상의 솔루션을 만들기 위한 노력을 계속하고 있다.
2. 내부 사용자에 의한 사고
A. 사용자의 실수에 의한 데이터 파손
정의
개발자 혹은 DBA 가 본인도 모르게 실수를 하여 데이터를 망가뜨려 운영에 심각한 문제를 초래하거나
운영 중 문제를 발견하게 되는 경우
현황
실제 많은 회사에서 이러한 문제를 겪고 있는데, 문제는 수많은 개발자나 DBA 중 누가 어떤 실수를 했는지
파악하는데도 많은 시간이 소요 될 뿐 아니라 그것을 복구하는데도 시간이 걸려 결국 서비스에 막대한
지장을 초래하게 된다.
이러한 실례는 이곳에서 다 언급할 수 없을 정도로 많다.
관리자가 운영중인 데이터베이스를 테이블 이름들이 비슷한 경우 관리자가 A1 테이블에 해야 할 작업을
AI 테이블에 하는 경우가 가장 흔한데, 테이블을 잘못 업데이트 하거나 삭제하게 될 경우 심각한 에러를
유발하게 된다.
특히 테이블이 삭제되지 않은 채 내용이 잘못 업데이트 된 경우 실제 운영중인 서비스에 문제가 있다는
것을 판단하기 까지 많은 시간이 소요될 수 있기에 항상 주의에 주의를 해야 하지만, 작업을 실행하기
전 까지 까맣게 모르고 있다가 엔터를 치고 나거 후회하는 경우가 많다.
대응책
사람의 실수는 언제 어디서나 발생할 수 있다. 관리자들도 예외가 아니다.
하지만, 이러한 케이스에서의 문제점은 DBA 나 개발자 들이 허용된 권한 내에서 작업할 때 발생하는
경우가 많으므로 사전에 작업을 차단할 수 있기에는 어렵고, 작업이 일어난 이후 이러한 잘못된 작업이
언제 누구에게서 일어났는지를 빨리 파악할 수 있는 상세하고 방대한 감사(Auditing) 자료의 기능을 제공
해 주는 것이 중요하다.
이를 위해서 보안 솔루션은 특정 작업을 할 때 마다 룰을 변경하여 실제 운영 중에 생기는 감사 자료와는
별도로 관리할 수 있도록 Auditing이나 Alerting에 대한 다양한 방식이 존재해야 한다.
관리자가 자신의 잘못을 재빠르게 파악해 처리 할수록, 문제를 빨리 파악 해 정상적인 서비스를 실행할
수 있는 여유가 생기는 것이므로 경험적인 부분에서 나오는 이러한 기능들은 보안 솔루션에서 빠져서는
안 되는 중요한 기능 들 중 하나라고 할 수 있다.
iProtector에서는 이러한 고객들의 실수를 방지하기 위해서 원하는 내용을 별도로 저장하는 기능을
제공하고 있다.
예를 들어 오전 5시부터 7시까지 업그레이드 작업이 예정되어 있다고 할 때, 이 때 DBA 들이 작업하는
내용은 별도 로그로 남기는 등의 작업이 가능하고, 이 시간대 이외의 개발자 라인에서 올라오는 DML
쿼리 (데이터 변형 쿼리) 등은 관리자에게 실시간 통보를 하는 등의 동작이 가능하다.
iProtector에서는 단순히 보안 정보를 기록하는 것에만 중점을 둔 것이 아니라 실제 사용자들이 실무에서
재활용 할 수 있는 정보를 제공하기 위해 최선을 다하기 때문이다.
실제로 현장에서는 iProtector를 이용하여 개발자들이 자신이 이전에 수행한 쿼리들의 이력을 볼 수
있도록 제공하여 좋은 호응을 받고 있다.
B. 내부 사용자의 고의적 정보 빼내기
정의
내부 사용자 혹은 데이터에 접근할 권한이 있는 관리자가 악의적인 목적으로 데이터를 파기하거나 데이터
를 유출하는 경우를 말한다.
현황
이러한 케이스도 실제 공개적으로 발표 된 케이스는 적으나 적지 않은 업체가 이로 인하여 타격을 받은
것으로 알려져 있다.
실제 관리자의 경우 보안 솔루션 등을 함께 다루는 경우가 많기에, 만약 모든 권한을 가지고 있는 관리자가
마음먹고 데이터를 유출하고자 한다면 막을 수 있는 방법이 없다.
그러나 회사에서는 인원을 많이 둘 수 없는 경우가 많기에 단일 인원이 이를 처리하는 경우 이런 문제에
대해 무척 취약할 수 밖에 없다.
이 밖에도 루트 권한을 가지고 있는 사람의 컴퓨터에 몰래 접속해서 작업을 하는 경우 등도 희박하지만
가끔 발생하는 경우에 속한다.
대응책
가장 좋은 대응책은, 데이터베이스를 관리하는 관리팀과 데이터베이스를 보안하는 보안팀이 별 개로 나뉘
어져 있는 것이 좋다. 보안 관리 룰은 데이터베이스 관리자나 개발자들이 손댈 수 없어야 하며, 만약 필요하
다면 보안팀에 허가를 득하여 작업을 하되 그 내역은 모두 기록을 하여 문제가 없는지 관리를 하는 것이
좋다.
현재 많은 회사들이 운영하기 힘든 구조이긴 하지만 점차적으로 이렇게 업무를 분할하여 처리하는 회사가
점점 늘고 있는 추세이다.
이를 위해 보안 솔루션 중 프로텍션 UI는 몇 가지 규칙이 필요하다.
보안 룰은 DB에 대해 잘 모르더라도 누구나 쉽게 작성이 가능하여야 한다.
UI를 별도로 배우지 않더라도 파악이 가능한 솔루션이어야 한다.
보안 룰은 쉽게 변경이 불가능하여야 하며 룰 변경 이력이 존재해야 한다.
실제 보안에 위배되는 행위, 혹은 그에 준하는 행위는 데이터베이스 검색 능력이 없는 일반인이라 할 지라
도 쉽게 검색이 가능하도록 하여야 한다.
iProtector의 UI는 위의 조건들을 만족하기 위하여 UI 개발에 많은 공을 들여 새로이 개발되었다.
UI는 기본적으로 Microsoft VISIO 스타일로 제작 되어져 있으며, 룰의 적용방향을 볼 수 있도록 TREE 구조
로 작성되어져 있어 누구라도 쉽게 적응이 가능하다.
또한 자신이 작성한 룰에 대하여 실제 어떠한 방식으로 적용이 되는지 시뮬레이션이 가능하여 서비스에
문제가 발생할 수 있는 점을 사전에 점검하거나, 해킹 시도를 하였을 때 이것을 제대로 방지할 수 있는지에
대한 점검이 가능하다.
이 밖에도 보안 룰 구성을 위한 UI에는 현장 요원들의 요청을 반영한 수많은 기능이 포함되어 있어 DBA 가
아닌 일반 사용자라 할 지라도, 데이터베이스 보안에 대한 기본적인 지식만 갖추고 있다면 충분히 활용이
가능하도록 제작되어져 있다.
|
