[오라클]002.취약점 분석 설계

0002. 취약점 분석 설계

2. DB 취약점 분석 설계

DB의 취약점을 보안 관리자 또는 DBA가 일일이 찾아낼 수도 있지만 이는 엄청난 시간과 노력이 필요하다. 이러한 단점을 보안하고 업무의 효율성을 높이기 위해 일반적으로 DB 취약점 분석 솔루션을 사용한다.
DB 취약점 분석 솔루션은 빠른 시간안에 방대한 DB를 분석하여 DB의 취약점을 도출하여 해당 DB의 보안 대책을 마련하는 기초 자료를 제공한다. 또한, 보안 관리자 및 DBA에게 현재 운영 중이거나 향후 구축될 DB의 취약점을 미연에 방지하도록 사전 가이드성 정보를 제공한다.
다음은 DB 취약점 분석 솔루션의 도입시 고려할 사항이다.

■ 사용자 편의성과 점검시간 단축(Easy operating and time saving)
？시스템 내에 에이전트(Agent)나 별도의 컴포넌트(Component) 설치를 요구하지 않음
？점검대상 DB의 IP 대역과 포트 정보만으로 점검 수행 가능
？단 한번의 정보수집으로 대상 네트워크 정보자산의 파악 가능
■다각적 분석(Fine granularity diagnosis on database security)
？단편적인 보안도구(In-house ware)를 조합한 보안점검은 일부 항목이 누락될 위 험 상존
？국제 보안 기준(STIG, SANS, CIS)에 입각한 다각도의 점검과 분석 가능
■모의해킹과 내부 보안감사 병행(Double-faced security check)
？보안관리자 및 감사자 측면을 고려한 다각도의 보안점검 수행 가능
？외부로부터의 침입을 가상한 모의해킹 수행
？DB가 보안상 안전하게 설치·운영되는 가를 점검하는 내부 보안 감사 수행
■사용자 정의 진단 (Adaptable user-defined operating)
？간편하고 직관적인 유저 인터페이스(User Interface)
？점검자의 필요에 의한 점검항목 정의 후 점검 수행 가능
？비밀번호 체크(Password Checking)와 같은 개별 점검항목에 대한 신속한 점검 수 행 가능
다음 그림은 DB 취약점 분석을 위한 절차를 나타낸 것이다.

다음은 본 절에서 자주 사용되는 키용어에 대한 설명이다.

가. DB 환경 제안

DB 설치 항목 중 무엇이 필요한 요소인지가 확실하지 않다면 일반적인 구성으로 설치하게 되는데 대체로 DB의 대표적인 취약점은 사용하지 않는 모듈의 취약점을 통해 공격하는 사 례가 많기 때문에 DB는 처음 설치할 때 반드시 필요한 요소만 설치하여야 한다.
예를 들어, 오라클 DB의 데이터 딕셔너리(Data Dictionary)에 대한 공격을 살펴보면, 오 직 적절한 권한을 가진 사용자(DBA 권한으로 접속을 생성한 사용자)만이 데이터 딕셔너 리 상의 ANY 시스템 권한(ANY System Privilege)를 사용할 수 있게하여야 한다. 만약 ANY 시스템 전환을 앞에서와 같이 설정하지 않는다면, DROP ANY TABLE 시스템 권 한을 가진 사용자는 누구라도 데이터 딕셔너리 내용을 악의적으로 이용할 수 있을 것이다.
따라서, 데이터 딕셔너리를 조회해야만 하는 사용자에게는 SELECT ANY DRCTIONARY 시스템 권한을 주어 데이터 딕셔너리 뷰(Data Direction View)로의 접근만을 허용하도 록 해야 한다.
오라클에서 데이터 딕셔너리를 보호하기 위해서는 파라미터 파일(Parameter File)인 init.ora의 내용을 OS가 제공하는 에디터를 이용하여 다음과 같이 수정하여 주면 된다.

예를 들어, 오라클 9i에서는 디폴트로 O7_DIRCTIONARY_ACCESSIBILITY=FALSE 가지지만 오라클 8i에서는 디폴트로 O7_DIRCTIONARY_ACCESSIBILITY=TRUE 로 설정되어 있으므로 반드시 수정하여야 한다.

나. 계정 관리

오라클 DB를 설치하면 다수의 디폴트 사용자 아이디가 생긴다. 만약, 수동으로 DBCA를 사용하지 않고 오라클을 설치하는 경우라면 디폴트 사용자 아이디는 모두 열린다. 즉, 잠 기지 않는 상태가 되므로 보다 세심한 주의가 필요하다.
이러한 이유로 수동으로 설치한 DB는 SQL문을 통하여 디폴트 사용자 아이디를 잠그고 기간을 만료시켜야 한다. 물론 상기의 SYS, SYSTEM, SCOTT, OUTLN, 그리고 3개의 JSERV 사용자 아이디들은 제외해야 한다.
다음과 같은 SQL문을 통하여 DB 사용자 아이디 목록과 아이디별 상태를 알 수 있다.

특정 사용자 아이디를 잠그고 기간을 만료시키는 SQL문장은 다음과 같다.

다. 패스워드 관리

앞서 언급한 디폴트 사용자 아이디인 SYS, SYSTEM, SCOTT, DBSNMP, 그리고 3개 의 JSERV 사용자 아이디들은 패스워드를 변경해 주어야 한다. 오라클 DB를 공격하는 가 장 손쉬운 방법은 설치 당시의 디폴트 패스워드를 사용하는 사용자 아이디를 사용하는 것 이므로 패스워드의 변경은 설치 직후에 지체 없이 이루어져야 한다.

앞의 접속 상황은 디폴트 사용자 아이디인 SYSTEM의 디폴트 패스워드인 MANAGER로 접 속이 이루어짐을 알 수 있다. 이렇게 디폴트 패스워드로 접속이 가능하다면 해당 DB는 디폴트 사용자 아이디를 알고 있는 누구든지 DB에 접근하여 자료를 파괴할 수 있다는 것을 의미한다. 디폴트 사용자 아이디의 디폴트 패스워드는 다음 표와 같다.

JSERV의 사용자 아이디는 임의로 생성된 패스워드를 사용한다. 또한, DB는 영문자의 대 소문자를 구별하지 않음을 기억해야 한다. 다음은 USER2의 사용자 아이디의 패스워드를 'new_passwd'로 변경하는 SQL문장이다. 다른 디폴트 사용자 아이디도 동일한 방법으로 변경할 수 있다.

또한, 오라클 엔터프라이즈 에디션을 사용한다면 Kerberos, 토큰 카드(Token Card), 스마트 카드, X.509 등과 같은 강화된 인증 기능을 이용할 수도 있다.

라. 권한 관리

사용자에게는 반드시 필요한 최소권한(Least Privilege)만을 부여해야 한다. 예를 들어, PUBLIC 사용자 그룹에서 불필요한 권한을 회수하여야 한다. PUBLIC은 오라클 DB의 모든 사용자에게 디폴트로 적용된다. 따라서, 모든 사용자는 PUBLIC에 권한 부여(Privilege Grant)된 것은 어떤 일이든 할 수 있다. 이런 경우 사용자가 교묘하게 선택된 PL/ SQL 패키지를 실행시켜 보낼 자신에게 권한 부여된 권한 범위를 넘어서는 작업을 할 수도 있을 것이다.
부적절한 권한 관리로 PL/SQL 보다 강력한 다음과 같은 패키지들도 오용될 소지가 있으 므로 주의해야 한다.

앞의 표와 같은 패키지들은 특정한 응용프로그램에 아주 유용하게 이용될 수 있다. 바꾸어 말하면, 모든 경우에 이러한 패키지들을 필요로 하는 것이 아니라는 것이다. 따라서, 필요 하지 않는 패키지들의 사용권한을 PUBLIC에서 제거해야 한다. 즉, 'Run-time Facilities' 에 제약된 퍼미션을 주어야 한다.
오라클 자바 버추얼 머신(OJVM, Oracle Java Virtual Machine)이 DB 서버의 Runtime Facility의 예가 될 수 있다. 어떠한 경우라도 이러한 Run-time Facility에 모든 권한을 주어서는 안된다. 또한, DB 서버 외부에서 파일이나 패키지를 실행할 수 있는 Facility에 어떤 퍼미션을 줄 때는 반드시 정확한 경로를 명시하여야 한다. 다음은 이에 대한 예시들이다.

마. 인증 관리

클라이언트에 대한 철저한 인증이 필요하다. 예를 들러, 오라클 9i는 원격 인증 기능을 제 공한다. 만일 해당 기능이 활성화(True)되면 원격의 클라이언트들이 오라클 DB에 접속할 수 있다. 즉, DB는 적절하게 인증된 모든 클라이언트를 신뢰한다. 그러나 일반적으로 PC 의 경우에는 적절한 인증 여부를 보장할 수 없다. 따라서, 원격인증 기능을 사용하면 보안 이 대단히 취약해진다.
원격 인증기능을 비활성화(False)한다면 오라클 DB에 접속하려는 클라이언트들은 Server-base 인증을 해야 하므로 보안이 강화될 것이다.
원격 인증을 제한하여 클라이언트의 인증을 DB 서버가 행하도록 하려면 오라클 파라미터 파일(Parameter File) 인 init.ora의 내용을 다음과 같이 수정하면 된다.

또한, DB 서버가 있는 시스템의 사용자 수를 제한하여야 한다. 즉, 오라클 DB가 운영되 고 있는 시스템의 사용자 수를 OS차원에서 제한하여야 한다. 제한이란 꼭 필요한 사용자 아이디만 생성하라는 의미로서 관리자 권한을 가진 사용자를 특히 주의해야 한다.

바. 원격 접속관리

■ 방화벽 구축
다른 중요한 서비스와 마찬가지로 DB 서버는 방화벽 뒤에 설치하여야 한다. 오라클 네 트워킹 인프라스트럭쳐인 오라클 Net Service(Net8 and SQL*Net으로 많이 알려져 있음)는 다양한 종류의 방화벽을 지원한다.

■ 기본 서비스 포트 사용 자제
오라클 DB를 외부 네트워크에서 접근할 수 있도록 방화벽의 1521 포트를 열어두면 이 는 치명적인 허점이 될 수 있다. 더 나아가 패스워드 설정 없이 오라클 리스너를 운영한 다면 DB에 대한 중요한 정보들이 노출될 수 있다. 이러한 노출정보가 많으면 많을수록 DB가 공격 당할 가능성이 높아진다. 또한, 원격에서 오라클 리스너의 설정을 변경할 수 없도록 하여야 한다.
다음과 같은 형식으로 오라클의 리스너 설정 파일인 listener.ora 내의 파라미터를 설정 하면 원격에서 오라클 리스너 설정을 바꿀 수 없다.

접속을 허용할 네트워크 IP 주소 대역을 지정하는 것이 좋다. DB 서버가 특정한 IP 주소 대역으로부터의 클라이언트 접속을 제어하려면 'Oracle Net valid node checking' 기능 을 이용하면 된다. 이 기능을 사용하려면 protocol.ora 내의 파라미터를 다음과 같이 설 정해야 한다.

앞의 설정은 직관적으로 알 수 있듯이 첫번째 파라미터가 나머지 두 개 파라미터 기능의 활성화를 결정하며, invited_nodes에 포함된 IP 주소 대역의 접속 요구만이 받아들여진 다. 이러한 기능은 DoS 공격의 잠재적인 위협도 경감시켜준다.

■ 네트워크 트래픽(Network Traffic) 암호화
오라클 DB 서버와 클라이언트의 통신은 암호화되지 않은 형태로 이루어진다. 이는 네 트워크상의 악의적인 공격자에 의해 데이터의 읽기, 변경, 삭제가 가능하다는 보안상 의 위협이 존재한다. 따라서, 가능하다면 Oracle Advanced Security를 사용하여 네 트워크 트래픽을 암호화해야 한다.
그러나 오라클 Advanced Security가 Oracle Database Enterprise Edition에서만 제공된다는 점이며 암호화하고 복호화하는 알고리즘으로 인해 속도가 떨어질 수 밖에 없다. (암호화 복호화 알고리즘은 DES, Three-DES, RC4 중에서 선택할 수 있음)

■ DB 서버가 있는 시스템의 OS 강화
불필요한 서비스를 제거하면 DB 서버 시스템이 보다 안전해진다. UNIX와 Windows 를 막론하고 ftp, tftp, telnet 등의 불필요한 많은 서비스들을 디폴트로 제공하는데 제거된 서비스가 사용하는 TCP/UDP 포트는 막아야 한다. 이때, TCP/UDP 포트는 모두 막아야 한다.

■ 보안 패치의 적용
오라클 DB가 운영되고 있는 OS와 DB 자신에 대한 모든 중요한 패치를 정기적으로 실시 하여야 한다. 조직 차원에서 패치와 관련된 업무 프로세스를 만드는 것이 바람직하다. 오라클의 경우 다음의 사이트에서 보안과 관련된 정보를 얻을 수 있다.

■ http://otn.oracle.com
■ http://technet.oracle.com