All Days 무한도전

### SK DB 보안 점검

select * from dba_sys_privs where GRANTEE ='APEX_030200' AND ADMIN_OPTION='YES' order by 2

SQL> desc user_role_privs;

 Name                  Type              Description

 USERNAME                    VARCHAR2(30) --Name of the user to whom the role has been granted.

 GRANTED_ROLE                VARCHAR2(30) --Name of the role granted to the user.

 ADMIN_OPTION                VARCHAR2(3)  --Whether the user is able to grant the role to another user or role. Equal to YES or NO.

 DEFAULT_ROLE                VARCHAR2(3)  --Whether the role is enabled by default when the user connects to the database. Equal to YES or NO.

 OS_GRANTED                  VARCHAR2(3)  --Whether the role was granted by the operating system.

SELECT * FROM user_role_privs;

Privilege(권한)

이처럼 권한은
1) DBA가 사용자에게 직접 부여 할 수도 있고
2) ROLE을 생성하여 롤에 권한을 부여한 뒤 그 롤을 사용자에게 부여하는 것처럼 간접적으로 부여 하는 방법도 있다.

권한 또는 롤을 부여 받은 사용자는 데이터베이스에서 데이터 조작이 가능하게 된다.

즉, 사용자는 권한을 받아야만 DB에 access(접근), create(생성), select(검색), insert(삽입)등의 작업을 할 수 있다.

권한은 system privilege와 object privilege로 구분되며, 사용자는 DB에 접근하기 위해 시스템 권한이 필요하고, 데이터베이스의 객체를 조작하기 위해 객체 권한이 필요하게 된다.

즉, 시스템 권한은 데이터베이스 안의 모든 테이블을 검색할 수 있는 권한이며,
객체 권한은 사용자에게 하나의 특정 테이블만을 검색할 수 있게 하는 권한이다.

권한의 종류

권한의 종류
설명

시스템 권한(SYSTEM privilege)
데이터베이스 객체를 생성, 수정, 삭제 권한

객체 권한(OBJECT privilege)
object 내용을 조작(추가, 변경, 삭제, 검색)할 수 있는 권한

시스템(system) 권한

• 시스템 권한은 특정 DB 연산 또는 작업을 수행하기 위하여 필요한 권한이다.
• 이러한 작업에는 테이블, 뷰, undo segment, 프로시져의 생성, 삭제, 수정등이 있다.
• 시스템 권한은 주로 DBA가 부여한다.
• system_privilege_map 뷰를 통해 전체 시스템 권한을 확인할 수 있다.

SQL> desc system_privilege_map;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 PRIVILEGE                                 NOT NULL NUMBER
 NAME                                      NOT NULL VARCHAR2(40)
 PROPERTY                                  NOT NULL NUMBER
 
SQL> select count(*) from system_privilege_map;
 
  COUNT(*)
----------
       206
 
SQL>

• 다음은 시스템 권한 중에서 몇개에 대해서 설명한다.

시스템 권한
설명

CREATE SESSION
DB에 연결할수 있는 권한

RESTRICTED SESSION
DB를 startup restricted로 시작할 수 있는 권한

CREATE TABLE
user소유 schema 안에서 table 또는 index를 생성할 수 있는 권한

SELECT ANY TABLE
어떤 schema에서나 모든 table, view 또는
snap shot에 대한 검색을 실행할 수 있는 권한

ALTER SYSTEM
alter system 명령을 사용하여 system 정의를 변경할 수 있는 권한

CREATE ROLE
오라클 DATABASE ROLE을 생성할 수 있는 권한

INSERT ANY TABLE
어떤 schema에서나 모든 table, view에 데이터를 입력할 수 있는 권한

DROP USER
생성한 user를 삭제시킬 수 있는 권한

CREATE USER
create user를 이용하여 user를 생성할 수 있는 권한

ALTER USER
alter user를 이용하여 생성한 user의 정의를 변경할 수 있는 권한

【형식】 
     GRANT 시스템권한명 또는 롤명 TO 사용자명 또는 롤명 또는 PUBLIC
        [WITH ADMIN OPTION];

【예제】
SQL> connect / as sysdba

SQL> create user kim  ☜ 새로운 user인 kim을 만듬
  2  identified by kun114$;
 
User created.
 
SQL> GRANT CREATE table, CREATE view TO jijoe;  ☜ jijoe에게 권한을 부여함
 
Grant succeeded.
 
SQL> connect jijoe/password
Connected.
SQL> select * from USER_sys_privs; ☜ ADMIN 권한을 받았는지 확인하는 뷰
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
JIJOE                          CREATE VIEW                              NO
JIJOE                          CREATE TABLE                             NO
JIJOE                          CREATE SESSION                           NO
JIJOE                          UNLIMITED TABLESPACE                     NO
 ☜  ADM 필드가 NO이면 ADMIN 권항이 부여 되지 않았음을 나타냄 

SQL> GRANT CREATE table, CREATE view TO kim;  ☜ ADMIN 권한이 없는 상태에서 kim에게 권한을 주려고 함
GRANT CREATE table, CREATE view TO kim
*
ERROR at line 1:
ORA-01031: insufficient privileges   ☜ 권한이 없다고 알려 줌
 
 
SQL> conn system/password as sysdba
Connected.
SQL> grant create table, create view TO jijoe  
  2  WITH ADMIN OPTION;    ☜  ADMIN 옵션으로 table,view를 만들 수 있는 권한을 jijoe에게 줌
 
Grant succeeded.
 
SQL> conn jijoe/password
Connected.
SQL> select * from user_sys_privs; ☜ ADMIN 권한을 받았는지 확인하는 뷰
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
JIJOE                          CREATE VIEW                              YES
JIJOE                          CREATE TABLE                             YES
JIJOE                          CREATE SESSION                           NO
JIJOE                          UNLIMITED TABLESPACE                     NO
 ☜  ADM 필드가 YES이면 ADMIN 권한이 부여 되었음을 나타냄 

SQL> GRANT CREATE table, CREATE view TO kim; 
    ☜ ADMIN 권한을 부여 받은 jijoe가 사용자 kim에게 권한을 부여할 수 있음
 
Grant succeeded.
 
SQL> 

다음 예제는 DBA가 모든 user에게 새로운 user 생성 권한을 예이다.(절대 권장하지 않음)

【예제】
SQL> connect system/password as sysdba
Connected.
SQL> CREATE USER kim2 identified by kim2##;
 
User created.
 
SQL> GRANT create session TO kim2;
 
Grant succeeded.
 
SQL> GRANT create USER TO PUBLIC;
 
Grant succeeded.
 
SQL> connect kim2/kim2##;
Connected.
SQL> SELECT * FROM USER_SYS_PRIVS;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
KIM2                           CREATE SESSION                           NO
PUBLIC                         CREATE USER                              NO
 
SQL> create user kim3 IDENTIFIED BY kim3###;
 
User created.
 
SQL> conn kim3/kim3###;
ERROR:
ORA-01045: user KIM3 lacks CREATE SESSION privilege; logon denied
 
 
Warning: You are no longer connected to ORACLE.

SQL> conn system/password as sysdba

SQL> GRANT connect TO kim3;
 
Grant succeeded.
 
SQL> conn kim3/kim3###;
Connected.
SQL> select * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
PUBLIC                         CREATE USER                              NO
 
SQL>

DBA_sys_PRIVS
롤이나 사용자에게 부여된 모든 시스템 권한을 조회

session_PRIVS
Session Level의 시스템 권한을 확인

SYSTEM_PRIVILEGE_MAP
전체 시스템 권한을 확인

【형식】
	REVOKE 시스템권한명, 롤명 FROM 사용자명, 롤명, PUBLIC

【예제】
SQL> connect kim3/kim3###
Connected.
SQL> select * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
PUBLIC                         CREATE USER                              NO
 
SQL> connect kim2/kim2##
Connected.
SQL> select  * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
KIM2                           CREATE SESSION                           NO
PUBLIC                         CREATE USER                              NO
 
SQL> conn system/password as sysdba
Connected.
SQL> REVOKE CREATE user FROM PUBLIC;
 
Revoke succeeded.
 
SQL> conn  kim2/kim2##
Connected.
SQL> select  * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
KIM2                           CREATE SESSION                           NO
 
SQL> conn kim3/kim3###
Connected.
SQL> select  * from user_sys_privs;
 
no rows selected
 
SQL> 

SQL> conn jijoe/password
Connected.
SQL> select * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
JIJOE                          CREATE VIEW                              YES
JIJOE                          CREATE TABLE                             YES
JIJOE                          CREATE SESSION                           NO
JIJOE                          UNLIMITED TABLESPACE                     NO
 
SQL> conn system/password as sysdba
Connected.
SQL> REVOKE CREATE TABLE,CREATE VIEW FROM jijoe;
 
Revoke succeeded.
 
SQL> conn jijoe/password
Connected.
SQL> select * from user_sys_privs;
 
USERNAME                       PRIVILEGE                                ADM
------------------------------ ---------------------------------------- ---
JIJOE                          CREATE SESSION                           NO
JIJOE                          UNLIMITED TABLESPACE                     NO
 
SQL> 

객체(object) 권한

• Object privilege란 특정한 table view, sequence, procedure, function, package등에 대한 특정한 작업을 수행하는 권한이다. 예를 들어, 사용자 kim의 PERSONNEL table을 SELECT 할 수 있도록 하거나 SYSTEM user의 TEST procedure를 실행할 수 있는 권한처럼 특정 object에 대한 권한을 뜻한다.
• 객체에 대해 권한 부여 및 회수 방법은 SYSTEM 권한과 유사하며, 다만 대상 객체를 명시한다는 점이 다르다.
• 객체에 대한 소유자는 객체에 대한 모든 권한을 가진다.
• 객체 권한을 부여하기 위해서는 객체의 소유자이거나, WITH ADMIN OPTION으로 권한을 부여 받아야 한다.
• 객체 소유자는 객체에 대한 특정한 권한을 제공할 수 있다.

객체 권한의 종류와 범위

TABLE 권한
VIEW 권한
SEQUENCE 권한
PROCEDURE 권한
SNAPSHOT 권한

INSERT
0
0

UPDATE
0
0

DELETE
0
0

ALTER
0
0
0
0

INDEX
0
0

SELECT
0
0
0
0

EXECUTE
0

REFERENCES
0

다음은 각각의 권한이 행할 수 있는 기능이다.

alter
권한을 받은 사용자가 변경할 수 있도록 허용

audit
권한을 받은 사용자가 감사를 할 수 있도록 허용

comment
권한을 받은 사용자가 주석을 달 수 있도록 허용

delete
권한을 받은 사용자가 삭제할 수 있도록 허용

grant
권한을 받은 사용자가 부여할 수 있도록 허용

index
권한을 받은 사용자가 table에 대해 인덱스를 생성할 수 있도록 허용

insert
권한을 받은 사용자가 삽입할 수 있도록 허용

lock
권한을 받은 사용자가 locking할 수 있도록 허용

rename
권한을 받은 사용자가 이름을 변경할 수 있도록 허용

select
권한을 받은 사용자가 조회할 수 있도록 허용

update
권한을 받은 사용자가 갱신할 수 있도록 허용

references
권한을 받은 사용자가 자료를 참조할 수 있도록 허용

execute
권한을 받은 사용자가 procedure,function,package에 대해 실행할 수 있도록 허용

【형식】
	GRANT 객체권한, ALL[컬럼명,...]
	ON 대상객체
	TO 사용자명, 롤명, PUBLIC
	WITH GRANT OPTION;

【예제】
SQL> connect system/password as sysdba
SQL> create user kim identified by gun;
SQL> grant connect,resource to kim;
SQL> create user kim2 identified by gun2;
SQL> grant connect,resource to kim2;
SQL> conn kim/gun
SQL> create table aa(pno number(3),pname varchar2(10));
SQL> insert into aa values(111,'COREA');
SQL> insert into aa values(222,'CHINA');
SQL> select * from aa;
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA
 
SQL> select * from user_tab_privs;
 
no rows selected
 
SQL> select * from user_tab_privs_recd;
 
no rows selected
 
SQL> grant select ON aa TO kim2; ☜ aa 객체에 대한 권한을 kim2에게 부여함
 
Grant succeeded.
 
SQL> conn kim2/gun2;
SQL> select * from user_tab_privs; ☜ 사용자에게 주어진 객체권한 조회
 
GRANTEE OWNER   TABLE_NAME  GRANTOR  PRIVILEGE   GRA HIE
------- ------- ----------- -------- ----------- --- ---
KIM2    KIM     AA          KIM      SELECT      NO  NO
 
SQL> select * from user_tab_privs_recd; ☜ 부여받은 객체 권한 정보를 조회
 
OWNER      TABLE_NAME   GRANTOR   PRIVILEGE   GRA HIE
---------- ------------ --------- ----------- --- ---
KIM        AA           KIM       SELECT      NO  NO
 
SQL> select * from kim.aa; ☜ kim.aa 객체를 kim2가 조회할 수 있음
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA

SQL> conn kim/gun
Connected.
SQL>
SQL> grant insert(pno,pname),select ON aa
  2  TO kim2; ☜ kim.aa객체에 kim2사용자에게 insert와 select 권한을 부여함
 
Grant succeeded.
 
SQL> conn kim2/gun2
Connected.
SQL> select * from kim.aa;
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA
 
SQL> insert into kim.aa values(333,'JAPAN'); ☜ kim2가 kim.aa 객체에 insert를 실행함
 
1 row created.
 
SQL> select * from kim.aa;
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA
       333 JAPAN
 
SQL> conn kim/gun
Connected.
SQL> select * from aa;
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA
       333 JAPAN
 
SQL> conn kim2/gun2;
Connected.
SQL> select * from user_tab_privs;
 
GRANTEE  OWNER TABLE GRANT PRIVILEGE  GRA HIE
-------- ----- ----- ----- ---------- --- ---
KIM2     KIM   AA    KIM   SELECT     NO  NO
 
SQL> select * from user_tab_privs_recd;
 
OWNER TABLE GRANT PRIVILEGE  GRA HIE
----- ----- ----- ---------- --- ---
KIM   AA    KIM   SELECT     NO  NO
 
SQL>

【형식】
	REVOKE 객체권한명
	ON 객체명
	FROM 사용자명, 롤명, PUBLIC
	[CASCADE CONSTRAINTS;

【예제】
SQL>  conn kim/gun
Connected.
SQL> select * from user_tab_privs;  ☜ kim사용자가 부여한 객체 내용을 확인함
 
GRANTEE  OWNER TABLE GRANT PRIVILEGE  GRA HIE
-------- ----- ----- ----- ---------- --- ---
KIM2     KIM   AA    KIM   SELECT     NO  NO
 
SQL> select * from user_tab_privs_recd;  ☜ kim이 받은 객체를 확인함
 
no rows selected
 
SQL> REVOKE select ON aa
  2  FROM kim2;   ☜ kim2에게 부여된 aa객체의 select 권한을 회수함
 
Revoke succeeded.
 
SQL> select * from user_tab_privs;  ☜ kim이 어떤 객체도 권한부여한 것이 없음(아직도 insert(pno,pname) 객체 권한은 남아 있음)
 
no rows selected
 
SQL> conn kim2/gun2
Connected.
SQL> insert into kim.aa values(444,'Honkong');  ☜ kim이 kim2에게 aa객체에 insert권한은 부여되어 있음
 
1 row created.
 
SQL> select * from kim.aa;    ☜ kim이 kim2로부터 aa객체의 select 권한이 회수된 상태임
select * from kim.aa
                  *
ERROR at line 1:
ORA-01031: insufficient privileges
 
 
SQL> conn kim/gun
Connected.
SQL> select * from aa;  ☜ kim2가 kim의 aa객체에 insert 객체 권한이 부여된 상태임을 알 수 있음
 
       PNO PNAME
---------- ----------
       111 COREA
       222 CHINA
       333 JAPAN
       444 Honkong
 
SQL> select * from user_col_privs;  ☜ 객체의 컬럼 권한을 확인함 
 
GRANTEE  OWNER TABLE COLUMN_NAME                    GRANT PRIVILEGE  GRA
-------- ----- ----- ------------------------------ ----- ---------- ---
KIM2     KIM   AA    PNAME                          KIM   INSERT     NO
KIM2     KIM   AA    PNO                            KIM   INSERT     NO
 
SQL> conn kim2/gun2 
Connected.
SQL> select * from user_col_privs;
 
GRANTEE  OWNER TABLE COLUMN_NAME                    GRANT PRIVILEGE  GRA
-------- ----- ----- ------------------------------ ----- ---------- ---
KIM2     KIM   AA    PNAME                          KIM   INSERT     NO
KIM2     KIM   AA    PNO                            KIM   INSERT     NO
 
SQL> 

데이터베이스 내의 모든 개체 권한을 보여주는 DBA_TAB_PRIVS와 컬럼에 지정된 모든 개체 권한은 DBA_COL_PRIVS에 표시된다.

모든 사용자를 위한 객체 권한 뷰

data dictionary view
설명

ALL_TAB_PRIVS
사용자 또는 public으로 부여된 객체 권한 뷰

ALL_TAB_PRIVS_MADE
각 사용자 권한과 사용자 소유의 객체 권한 뷰

ALL_TAB_PRIVS_RECD
사용자 또는 public으로 주어진 객체에 대한 객체 권한 뷰

TABLE_PRIVILEGES
객체 권한 소유자, 부여자, 피부여자이거나 public으로 부여된 객체 권한 뷰

ALL_COL_PRIVS
사용자 또는 public으로 부여된 컬럼 객체 권한 뷰

ALL_COL_PRIVS_MADE
각 사용자 권한과 사용자 소유의 컬럼 객체 권한 뷰

ALL_COL_PRIVS_RECD
사용자 또는 public으로 주어진 객체에 대한 컬럼 객체 권한 뷰

COLUMN_PRIVILEGES
객체 권한 소유자, 부여자, 피부여자이거나 public으로 부여된 컬럼 객체 권한 뷰


일반 사용자 객체 권한 뷰

data dictionary view
설명

USER_TAB_PRIVS
객체 권한 소유자, 부여자, 피부여자의 객체 권한 뷰

USER_TAB_PRIVS_MADE
사용자가 소유자인 객체 권한 뷰

USER_TAB_PRIVS_RECD
객체 권한 피부여자를 위한 뷰

USER_COL_PRIVS
객체 권한 소유자, 부여자,피부여자의 컬럼에 권한 뷰

USER_COL_PRIVS_MADE
사용자가 소유한 컬럼에 권한 뷰

USER_COL_PRIVS_RECD
객체 권한 피부여자를 위한 컬럼의 뷰

최근 전자신문 미래기술연구센터와 한국정보화진흥원이 공동으로 학계 업계 등의 전문가 52명을 대상으로 조사한 `2013 개인정보보호 트렌드 전망` 연구 결과에 따르면 DB 암호화를 비롯한 개인정보 암호화가 개인정보보호 분야 이슈로 선정됐을 만큼 개인정보보호법 시행과 일련의 정보 유출 사고를 계기로 많은 조직에서 DB 암호화에 대한 관심이 뜨겁다.

실제로 기존 공공 기관 및 은행권을 중심으로 이뤄 지던 암호화가 올해에는 물류 업체, 백화점, 대형 할인 마트 등 전 산업군으로 확산되면서 지난해 500억∼600억원 규모로 전년 대비 2배 이상 성장한 DB 암호화 시장이 올해는 전년 대비 30∼40% 성장할 것으로 전망되고 있다.

이처럼 법 제정 이후로 성능 및 비용 문제로 DB암호화 적용을 보류해 온 업체들까지도 도입을 고려하고 있어 암호화 시장이 크게 성장한 것은 사실이지만, 그에 따른 우려의 목소리 또한 높다. 암호화의 효용성 논란과, 시스템 성능 저하 문제 때문이다. 그 중 성능 이슈는 DB 암호화 적용 시 가장 우려가 되는 부분으로, 특히 대용량 데이터 처리를 수행하는 배치에서 더욱 심하게 나타난다.

그러나 최근 대용량 데이터를 암호가 걸린 상태로도 자유롭게 연산해 데이터 처리 속도는 높이면서도 외부 유출 가능성은 줄일 수 있는 기술이 개발되었다. 기존에는 암호화된 정보를 검색하거나 통계 처리를 하려면 이를 다시 해제해 원래 정보를 복구한 후에 연산하고, 또다시 암호화해서 저장해야 하므로 데이터 처리 속도가 느려 지고 이 과정에서 데이터가 노출되는 위험이 있었다. 그런데 이번에 국내 연구진이 개발한 '완전 동형 암호화(fully homomorphic encryption)' 방식은 암호화된 정보의 해제 과정을 생략하고 암호화된 상태 그대로 연산이 가능해 이목을 집중 시킨다.

일반적으로 DB를 암호화하면 컬럼 길이가 증가하고 저장 공간과 I/O의 증가, 넓은 범위 액세스나 Full Table Scan에 영향을 미친다. 또한 암호화 할 대상이 많아 지면 저장 공간 및 I/O 문제가 심화되고, 메모리 사용량이 증가하며 High Resource Query의 증가로 시스템 전체의 성능이 저하된다. 사소한 코딩 실수도 심각한 성능 문제로 비화될 수 있으며, API 방식이나 Plug-In 방식 모두 대량의 데이터 처리 시 암복호화 부하가 발생하기도 한다. 또한 암호화된 값은 암호화 전의 대소 관계를 유지할 수 없으므로 Range Scan 문제가 발생하는 등 여러 가지 성능 이슈가 대두된다.

<="" v:imagedata="" src="http://www.dator.co.kr/file:///C:\Users\jiho\AppData\Local\Temp\msohtmlclip1\01\clip_image001.jpg">

이러한 DB 암호화를 통한 성능 이슈들을 방지하기 위해서는 먼저 전사적인 통합 설계가 선행되어야 한다. 암호화 대상 항목의 중복이 많을수록 SQL만으로 개선이 불가능한 성능 문제가 자주 나타나므로 적절한 통합 설계로 암복호화의 불필요한 수행 여지를 최소화 한 후 SQL의 최적화가 필요하다. 데이터 품질이 높고 튜닝이 잘 된 DB라면 암호화로 인한 시스템 성능 저하를 크게 줄일 수 있다.

그 이후에 현 운영 시스템의 다양한 환경적인 요소를 분석하여 적절한 DB 암호화 설계 방식을 선택해야 한다. DB 암호화 설계 방식으로는 컬럼 유지 후 암호화를 하는 ▲암호화 후 View 적용 방식과 데이터를 통합한 후에 암호화를 하는 ▲데이터 집중 후 암호화 방식 2가지가 있다.

<="" v:imagedata="" src="http://www.dator.co.kr/file:///C:\Users\jiho\AppData\Local\Temp\msohtmlclip1\01\clip_image003.jpg">

현 시스템에 최적화된 DB 암호화를 위해서는 먼저 현재 사용하고 있는 DB와 서버 등의 환경이나 버전 등을 파악하고 있어야 한다 또한 DB 내부에 어떠한 데이터들이 저장되어 있는지, 데이터들 중에서 암호화를 적용해야 하는 개인 정보들은 어떤 것들이 있는지, 또한 개인 정보들은 어떠한 포맷으로 저장되어 있는지 등을 알아야 한다.

.

이처럼 DB 암호화를 효율적으로 실행하기 위해서는 여러 가지 고려해야 할 사항들이 수반된다. 그러나 아직도 일선 실무자들과 이야기를 나누다 보면 DB 암호화에 대해 정확히 모르고 있거나, 무턱대고 솔루션을 구입하는 것으로 개인정보보호를 위한 노력을 다했다고 생각하는 사람들이 더러 있는데 이는 위험한 발상이다.

솔루션 도입을 고려하기 전에 먼저 DB 암호화에 대한 올바른 이해가 선행되어야 하며, 암호화 작업에만 급급해 모든 정보를 일괄적으로 암호화하는 것은 자칫 조직 효율성을 떨어뜨릴 수 있으므로 각 산업의 특성에 맞게 선별적으로 암호화 정책을 수립하고 그에 적합한 암호화 방식을 선택해야 한다. 이 때 현 시스템 현황을 상세히 파악하고 있는 관리자가 중심이 되어 자사 환경에 맞는 DB 암호화 방식을 택하고 그에 따른 솔루션 구입을 고려해야 불필요한 비용을 최소화할 수 있다.

더불어 수년간 발생한 주요 개인 정보 유출 사건을 분석한 결과 70%의 공격이 방화벽 내부에서 이루어졌고, 이중 90%의 공격이 정당한 권한을 가진 내부 직원에 의해서 발생했다는 것을 고려한다면, DBA는 물론, 개발자 및 과도한 권한이 설정된 내부 직원으로부터 주요 정보에 대한 무분별한 접근을 효과적으로 통제할 수 있는 대안을 추가로 마련해야 할 것이다.

0005. 보안 체크리스트

5. DB 취약점 체크리스트(Oracle 기반)

모든 DBA는 오라클이 안정적으로 운영되고 문제발생 시에 해당 원인을 찾아 신속히 대처 해야 할 임무를 갖는다. 이를 위해서 사전에 발생할 수 있는 문제들이 어떠한 것이 있는지 파악하고 있어야 하며, 일단 문제가 발생하였을 경우 오라클 운영 환경을 점검하여 빠른 시간 내에 문제를 해결할 수 있어야 한다.

본 가이드라인은 오라클 운영 중에 고려해야 할 다양한 항목들을 제시하고 있다. 오라클 운영 중 고려해야 할 항목은 크게 DB 전체와 DB를 구성하는 FILE 및 TABLESPACE 종 류 별로 백업, 설정, 모니터링 등의 측면을 구분하여 각각 점검할 사항들을 제시한다. 각 구성요소별 백업, 설정, 모니터링 등의 측면에서 살펴보고, 이것을 업무에 적용함으로 써 오라클 운영과 문제상황에 대해 효과적으로 대처할 수 있다.

가. Database

1) 백업
■백업(Backup)에 사용될 테이프와 같은 장비상태가 불안정하다고 판단될 때는 절대로 사용하지 말아야 한다. 또한, 백업된 정보는 즉시 확인할 수 있어야 한다. 즉, 어느 파 일이 어느 백업 위치에 있는지 바로 알 수 있어야 것이다.
■시스템 가동 시점에서 백업 절차 전체에 대한 테스트를 수행한 후, 해당 결과를 확인하 여 변경할 사항들이 있는지 확인하여야 한다.
■백업 되는 파일 이름은 날짜, 업무 등의 정보를 포함시켜서 나중에 보더라도 알기 쉽도 록 지정한다.
■3개월 단위마다 정기적으로 백업을 이용한 복구 테스트(Recovery Test)를 실시한다.

2) 설정
■가장 최신의 오라클 패치를 적용하여 시스템이 안정적으로 운영될 수 있도록 해야 한다.
■DB_FILES 값의 설정에 주의해야 한다. 이 값을 초과하여 추가 하려고 할 때는 에러가 발생하게 되고, 이러한 상황에서 DB_FILES를 변경하게 되면 DB는 종료(shutdown) 후에 다시 시작(start)되어야 한다.
■ENQUEUE_RESOURCES는 OS의 Lock Resource를 조절하는 역할을 한다. 이 값 이 너무 낮게 설정되어 있게 되면 특정 애플리케이션에서 Time Out이 발생하게 된다.
■DML_LOCKS값은 Object에 대한 작업을 하는 모든 사용자를 고려하여 최대한 크게 설 정한다. 이 값이 부족하게 되면 애플리케이션에서 에러가 발생하게 된다.
■DB를 재생성할 경우에 대비해서 그 절차를 숙지하고 있어야 한다. 그렇지 않으면 소요 작업시간이 길어지게 된다.

3) 모니터링
■Alert.log와 Trace 파일의 내용을 점검하여 에러가 없는지, Archive나 Checkpoint 에 대한 Waiting이 발생하지 않았는지 등을 점검한다. 이 파일들을 이용하여 오라클 Internal Error나 다른 Error 정보를 얻을 수 있다.
■*_dump_dest의 Free Space여부를 확인한다. InitSID.ora나 configSID.ora에 *_dump_dest가 설정되어 있다. 특히, Alert Log 는 계속 늘어나게 되므로 일정한 크 기가 되었을 때 백업을 받고, Background_dump_dest의 Free Space를 수시로 점검 하여 Space 문제가 발생하지 않도록 주의한다.
■Tablespace별로 성장속도를 확인한다. 이렇게 하면 Space 부족으로 발생할 수 있는 DB Hang 문제를 미리 대비할 수 있게 된다.
■Utlbstat.sql / utlestat.sql으로 DB 상태를 정기적으로 점검하여 시스템에 대한 통계 정보를 기록해 둔다. 이 자료는 튜닝을 위한 기초자료가 된다.
■각 Tablespace에 대해 Fragmentation을 점검한다. Fragmentation이 많이 발생하 여 Free Space가 부족하다면 Coalesce를 수행하거나 Data File을 추가하도록 한다. Disk Space가 거의 존재하지 않는다면 Export를 받은 후 다시 Import를 실시한다.
■InitSID.ora 파일에 변경이 있을 때 마다 그 이력(History)를 기록해 둔다. 이렇게 하 면 Parameter의 변경으로 발생하는 문제를 대처할 수 있고, 성능(Performance)의 변 화도 알 수 있다.

나. Database 구성 File

오라클 DB를 구성하는 파일들은 Control 파일, Online Redo Log 파일, Archive Log 파일, Data 파일 등으로 나누어진다. 각각의 파일들은 DB 운영을 위해 중요한 정보들을 포함하고 있으므로 수시로 상태를 점검하여야 한다.

1) CONTROL 파일
■ 백업
？정기적으로 백업을 받도록 한다. Cold Backup일 경우에는 Control 파일자체를 복 사하여 백업을 받고 DB가 운영중일 경우는 다음 명령어를 이용하여 파일을 백업받 도록 한다.

.Data 파일과 Redo Log 파일의 추가나 삭제 등의 원인으로 DB에 변경사항이 있을 때마다 백업 받도록 한다.

.Hot Backup시 End Backup이 발생할 때마다 백업을 받도록 한다.
.백업받은 파일 이름에 날짜와 업무정보 등을 포함시켜 쉽게 알아볼 수 있도록 한다.

■ 설정
.MAXDATAFILES 값은 예상치보다 크게 설정하여야 한다. 디폴트 값은 플랫폼 (Platform)별로 다르게 지정된다. InitSID.ora에서 DB_FILES가 크게 설정되어 있더라도 MAXDATAFILES 값이 너무 작으면, DB에서 동시에 Open할 수 있는 Datafile의 개수는 MAXDATAFILES 값을 넘을 수가 없게 된다. 이 값을 변경하기 위해서는 Control 파일을 재생성해야 한다.
？별도의 디스크와 콘트롤러가 사용되도록 물리적 위치를 지정한다.
？*.ctl과 같이 알기 쉬운 이름을 사용하도록 한다.
？최소 3개가 사용되도록 해야 한다.
？MAXLOGFILES 값을 확인하여 예상치보다 크게 설정하도록 한다.
？MAXLOGMEMBERS 값이 3이상이 되도록 설정한다.
？OPS의 경우 MAXINSTANCES값을 예상치보다 크게 설정하도록 한다.
？MAXLOGHISTORY는 저장될 Log History정보의 양을 지정하므로, Log File이 생성되는 추이를 파악하여 적절한 값을 지정하여야 한다.
？OS 레벨에서 모니터링이 되어 있는지 확인하고 Striping은 하지 않도록 한다.

2) ONLINE REDO LOG 파일
■ 백업
？Hot Backup시에는 End Backup 이후에 'archive log list' 명령어를 수행하여 현재 Log Sequence Number를 먼저 확인해야 한다. 그리고 나서 다음 명령어를 수행하여 Archive를 추가로 생성한 후, 앞서 확인한 Sequence Number까지 Archive Log를 백업 받으면 된다.

？Hot Backup시에는 Archive Log 파일이 Backup되었으면 Online Redo Log는 백업받을 필요가 없다.
？Cold Backup시에는 Restore 할 때의 실수를 방지하기 위하여 주요 DB 파일, 특히 Archive Log 파일과는 다른 위치에 백업을 받는다.
■ 설정
？OPS일 경우 Instance Recovery를 위해서 Log의 모든 Member는 동시에 Access 가 가능하여야 한다.
？각 그룹의 Member들은 Disk와 Controller를 별도로 사용하도록 지정한다.
？Redo의 Thread는 Instance당 1개를 설정하여야 한다.
？Redo Log Group은 최소 3개 이상이 되도록 하고, 각 그룹들은 최소 2개 이상의 Member를 가지도록 한다. 이렇게 Log Mirroring을 하게 되면 돌발적인 파일 삭 제 상황에 대비할 수 있게 된다.
？Redo Log Member의 Size는 Checkpoint에 대한 Waiting이 발생하지 않도록 충 분한 크기를 지정하여야 한다. 사이즈(Size)가 너무 작을 경우에는 잦은 Log Switch 로 인하여 복구 시간이 지나치게 많이 소요될 수 있다.
？Redo Log Member의 사이즈는 모두 같게 한다.
？DB 파일과 다른 물리적인 위치를 지정하도록 한다.
■ 모니터링
？Checkpoint 주기를 점검하도록 한다. 권장할 만한 Checkpoint의 주기는10-15분 정도이다. LOG_CHECKPOINT_INTERVAL을 가장 큰 Redo Log File Size보다 크게 설정하고 LOG_CHECKPOINT_TIMIEOUT을 0으로 설정하게 되면, Log Switch가 일어날 때마다 Checkpoint가 발생하게 되므로 Log File Size 변경을 통 해 Checkpoint 주기를 조정할 수 있게 된다.
잦은 Checkpoint는 Crash 복구 시간은 줄여주지만, Dirty Buffers를 자주 사용하 고 File Headers를 자주 업데이트하게 되어 Overhead를 일으키게 된다. ？Log Switch가 너무 자주 발생하지 않는지 점검한다. Log Switch는 15분 정도 주 기가 적당하다. Log Switch가 너무 자주 발생하면 v$backup을 통해 Hot Backup 상태인 파일이 있는지도 확인한다.
？V$logfile을 통해 Status를 수시로 점검한다. Status가 Invalid나 Stale이 없는지 확인해야 한다.
3) ARCHIVE LOG 파일
■ 백업
？모든 Archive Log가 빠짐없이 백업에 포함되었는지 점검한다. 또한, V$LOG에서 Archived, Status 칼럼을 참조하여 Archive가 완전이 끝난 Log 파일을 백업해야 한다.
？OPS일 경우에는 모든 Thread에서 생성되는 Archive를 전부 백업해야 한다.
？백업된 Archive Log 파일의 Sequence Number가 연속되어 있는지 확인해야 한다.
？Archive Log 파일이 특정 Threshold에 도달할 때마다 백업해야 한다. 가능하다면 매일 백업을 받는 것이 좋다.
？백업된 Archive 파일들은 삭제하도록 한다. 그러나 Disk의 공간을 충분히 하여 최 소한 하루의 Archive Log들은 백업을 받았더라도 삭제하지 않도록 한다. 이것은 장애 시에 복구 시간을 줄이는 역할을 할 수 있다.
？Archived Log File의 개수는 Log 파일의 크기와 Redo의 양에 달려있다. 그리고 Redo 의 양은 Transaction의 양과 연관되어 있다. 이러한 환경을 고려하여 백업의 빈도를 결정하도록 한다.
？백업 위치별로 그 속에 포함된 Log가 어느 기간동안 생성된 것인지에 대한 정보를 기록해 두어야 한다.
？Archive Log 생성속도와 파일의 백업 속도에 대해 알고 있어야 한다.
？Main이 되는 백업 장비에 문제가 있을 것에 대비하여 즉시 사용 가능한 대체장비를 확보하고 있어야 하며, 이 대체장비는 Backup Script에 반영되어 있어야 한다.
■ 설정
？DB가 ARCHIVELOG Mode로 운영 중인지 확인한다. 이것을 위해서는 다음 명령어 를 사용할 수 있다.

？생성되는 Archive 파일의 위치와 파일 이름 형식을 알아보기 쉽도록 지정한다. 이 것은 initSID.ora에서 LOG_ARCHIVE_DEST와 LOG_ARCHIVE_FORMAT을 통해 지정할 수 있다. LOG_ARCHIVE_FORMAT= "LOG%s_%t.ARC"으로 설정 할 경우 %s는 Log Sequence Number, %t는 Thread Number를 의미한다. 특히 OPS인 경우 %t를 설정하여 Thread별로 생성되는 Archive를 구별하여 관리하도 록 한다.
？Archive되는 위치가 Disk인지 확인한다. Tape에서 Disk로 옮기는 시간을 줄여서 복구 시간을 단축할 수 있다. 그러나 Tape에도 Archive를 복사해 두도록 한다. ？Online Redo Log와는 다른 Disk와 Controller를 사용해야 한다.
？DB 파일과는 다른 Disk와 Controller를 사용해야 한다.
？OS 레벨에서 Mirror가 되도록 하고, Striping은 하지 않도록 한다.
■ 모니터링
？Archive 파일이 생성되는 위치에 여유 공간이 있는지 확인해야 한다. Disk에 여유 공간이 없어서 Archive Log를 생성하지 못하는 경우에는 DB Hang이 발생하게 된 다. Archive 위치에 여유공간이 얼마 남지 않았을 경우 경고 메시지를 발생시키도 록 하는 내용을 Backup Script에 포함시킨다.
？Archive와 관련된 에러가 발생하지 않았는지 Alert Log를 점검한다.
？Archived Log 파일의 Sequence Number가 순차적인지 확인한다. Log Switch 가 일어날 때마다 Sequence Number는 하나씩 증가된다.
？DB가 ARCHIVELOG Mode로 작동중인지 확인해 본다. 만약 Archive Log Mode 가 아니라면 다음과 같은 과정을 통해 Mode를 변경할 수 있다.

？ARCH Process가 움직이는지를 자주 확인한다. 이렇게 하면ARCH Process가 움 직이지 않아서 DB가 Hang이 걸리는 문제를 막을 수 있다.

다. TABLESPACE

오라클 DB를 구성하는 Tablespace에는 System Tablespace, Rollback Segment Tablespace, Data Tablespace, Temporary Tablespace 등이 있다. 각 Tablespace 는 Data를 저장하는 논리적인 공간이며, 앞에서 다룬 OS 상의 DB 관련 파일들과 긴밀하 게 연관되어 있다.

1) SYSTEM TABLESPACE
■ 모니터링
？Free Space를 수시로 점검한다.
？Extents의 개수가 MAXEXTENTS/2 지점에 이르지 않았는지 확인한다.
？Tablespace의 size가 적정수준인지 확인한다. 일반적인 System Tablespace의 Size는 30~50M이다.
？일반사용자의 Object나 Temporary Segment가 포함되지 않았는지 점검한다.
？일반사용자에게 사용권한을 부여하지 않도록 한다.
？System Tablespace 이외의 Tablespace에서 발생하는 Extent는 Data Dictionary 의 정보를 사용하게 되므로 작은 Extent가 지나치게 많을 경우 System Tablespace 의 Space도 영향을 받게 된다.
？특별한 경우가 아니면 SYS Object의 Storage절을 변경하지 않도록 한다.
？Disk를 모니터링하고 Striping은 설정하지 않는다.
2) ROLLBACK SEGMENT TABLESPACE
■ 백업
？Hot Backup은 DB Activity가 낮은 시점에서 실시한다.
■ 설정
？알기 쉬운 이름을 사용해야 한다.
？일반적인 용도의 RBS의 크기는 모두 같게 한다.
？INITIAL과 NEXT는 같게 설정한다.
？PCTINCREASE는 0으로 설정한다.
？InitSID.ora에서 UNLIMITED_ROLLBACK_SEGMENTS=FALSE를 지정하여 RBS가 Unlimited Extent Format을 사용하는 것을 방지하도록 한다.
？OS 레벨에서 모니터링을 하고 Striping은 하지 않는다.
■ 모니터링
？InitSID.ora에 RBS들이 등록되어 있는지 확인한다.
？RBS가 Online 상태인지 주기적으로 점검한다. 이 때 dba_rollback_segs를 이용 할 수 있다.
？RBS Tablespace에 다른 Object가 생성되지 않았는지 점검한다.
？RBS의 크기변동률을 점검한다. V$rollstat을 이용하면 RBS가 커지거나 줄어드는 비율과 Wait 정보를 확인할 수 있다.
？Free Space와 Fragmentation 정도를 점검한다.
？ORA-1555에러가 발생하는지 점검한다. 이 경우에 DB는 여전히 사용가능하며 Application Error가 발생할 수 있다. Data 파일을 추가하여 공간을 늘여야 한다.
？RBS당 Transaction의 개수는 4개~5개가 적절하다.
？Batch Job에만 사용되는 큰 크기의 RBS를 별도로 설정하고, OLTP용 RBS와 동시 에 Online되지 않도록 한다. 다음 명령어로 특정 RBS 사용을 지정할 수 있다.

3) DATA TABLESPACE
■ 백업
？READ-ONLY Tablespace일 경우 쓰기, 읽기 권한 관리에 주의하여야 한다. 이러 한 변화는 Control 파일이나 Data 파일의 백업에도 영향을 미치게 된다.
？MTTR을 만족시킬 수 있는 주기 단위로 백업을 실시한다.
？Export를 이용하여 Object 레벨에서 Logical 백업을 받아두어야 한다.
？Hot Backup 시에는 해당 Data 파일의 Transaction 발생을 줄여서 Redo가 적게 발생되도록 해야 한다.
■ 설정
？알아보기 쉬운 이름을 사용하도록 한다.
？서로 다른 Tablespace는 다른 Disk에 위치하도록 하는 것이 좋다. OS 파일이 분실 되는 것은 곧 Tablespace의 분실을 의미하므로 사전에 주의하여야 한다.
？Index Tablespace는 Data와 분리하여 사용하도록 한다.
？Fragmentation을 줄이기 위해서는 Tablespace내에 비슷한 크기의 Object들이 위치하게 하는 것이 좋다.
？OPS의 경우에는 Application별로 Tablespace를 분리하여 운영하는 것이 좋다.
？Autoextend는 비활성화로 설정하여 사용한다.
？7.3 이전 Version에서는 Block Size 별로 Tablespace의 MAX EXTENTS의 값이 제한되어 있었다. 예를 들어, Block Size가 2K일 경우는 121, 8K일 경우는 505 였다. 그러나 7.3이후 Version에서는 MAX EXTENTS값보다 더 많은 값을 직접 지정하는 것이 가능해 졌다. MAX EXTENTS 보다 더 큰 값을 사용하게 되면 새로 운 Block Format이 사용된다.
？Default Storage 절이나 생성되는 Object에 MAXEXTENTS UNLIMTED를 사 용하지 않도록 한다.
？MAXEXTENTS UNLIMITED를 설정할 수도 있으나 권장되는 설정이 아니다. UNLIMITED Extent Format을 사용하려면 COMPATIBLE의 값이 7.3.0이상으 로 설정되어 있어야 한다.
？MAXEXTENTS UNLIMITED를 설정하는 것은 해당 Tablespace의 Free Space 전체를 사용하게 될 위험이 있다. 또, MAXEXTENTS UNLIMITED가 사용될 경우 작은 Extent의 개수가 과도하게 증가하여 DROP TABLE, TRUNCATE TABLE 작업 등을 수행할 때 Space와 관련된 심각한 성능 문제를 유발할 수 있다.
.OS 레벨에서 Mirror되게 한다.
■ 모니터링
.주요 Object에 대해서는 정기적으로 분석을 실시한다.
.문제를 조기에 발견하기 위해서 Object가 MAXEXTENTS/2에 도달했는지를 점검 한다.
.Type이 다른 Object가 동일한 Tablespace에서 혼용되지 않도록 한다.
.DBVERIFY를 사용하여 정기적으로 점검해 본다.
.Null Device에 Export하여 Logical Object의 상태를 점검해 본다.
4) TEMPORARY TABLESPACE
■ 설정
.임시 Tablespace의 개수는 DB 사용자별로 1개, OPS일 경우는 Instance의 개수 만큼으로 생성하도록 한다.
.7.3이상 Version에서는 TEMPORARY Status를 설정하도록 한다.
.PCTINCREASE 는 0으로 설정하도록 한다.
.INITIAL과 NEXT의 값은 sort_area_size의 배수로 설정한다.
.7.3 Version부터 TEMPORARY Tablespace 에 생성되는 Sort Segment는 INITIAL값으로 Tablespace의 NEXT 값을 그대로 사용하게 되고, PCTINCREASE는 0, MAXEXTENTS는 UNLIMITED로 지정된다. 따라서, 임시 Tablespace에 생성되 는 Sort Segments의 EXTENT 전체 크기는 조절할 수 없으므로 Default Storage 절에서 NEXT값 설정에 주의해야 한다.
.Index 생성을 위해 사용되는 임시 tablespace의 크기는 Index Data의 2배 정도가 되어야 한다.
.OS 레벨에서 모니터링을 하고 Striping은 하지 않도록 한다.
■ 모니터링
.일반 사용자가 올바른 임시 Tablespace를 사용하고 있는지 확인한다.
.Tablespace 내에 일반 사용자의 Object가 생성되지 않았는지 점검한다.
.Tablespace가 TEMPORARY 상태인지 확인한다.
.MAXEXTENTS UNLIMTED로 설정된 Tablesapce가 TEMPORARY Segments 를 위해 사용된다면, SMON이 해당 Segments를 Clean-up하는데?? 된다. 또한, Shutdown 작업이 지나치게 길어질 수도 있다.

라. OS 및 기타

오라클 DB는 OS 상에서 동작하기 때문에 안정적인 운영을 위해서 OS의 상태를 점검하는 것은 필수적이다. 또한, 리스너와 같은 오라클 Process들의 작동상태를 수시로 점검하여 애플리케이션 운영에 차질이 없도록 해야 한다.

1) OS
DB에 설정되어 있는 DB_FILES나 MAXDATAFILES 값이 크더라도, DB 사용자가 동시 에 접근하여 사용할 수 있는 파일의 개수는 OS에서 동시에 접근할 수 있는 파일의 개수를 넘을 수 없다.
따라서 사용 중인 Control 파일, Redo Log 파일, Data 파일, Alert.Log, Trace 파일 들의 개수를 모두 고려하여 OS에서 동시에 Open할 수 있는 파일 개수를 지정하여야 한 다. 이 값을 변경하기 위해서는 DB도 Down되어야 하기 때문에 운영 중인 시스템에서는 치명적일 수 있다.
그러므로 Disk나 Controller에 문제가 없는지 자주 확인하고, OS 모니터링이 제대로 동 작하고 있는지도 확인한다.

2) 기타
SQL*NET의 상태를 확인한다. Listener의 Process가 Running상태인지 확인하려면 다 음의 명령어를 사용할 수 있다.

마. 권한 관리

1) Unauthorized Object Owner

단지 SYS, SYSTEM, DB Administrators, 애플리케이션 소유자 계정들만이 운용 DB 시스템상의 Oracle Objects를 소유해야 한다. 개발자 계정은 또한 개발 DB 시스템상의 Object를 소유해야 한다. Object 소유권은 소유 Object에 대한 전체 권한을 의미한다. Database Object 소유자 계정이 인가된 Application 소유자 계정인지에 대해 확인한다. 다음은 새로운 Default Object 소유자 계정을 확인하는 스크립트이다.

2) Active Schema Owner Account

Application Schema Owner 계정은 업데이트와 유지보수 업무를 제외하고는 사용에 제 한을 두어야 한다. Application Schema Owner 계정은 모든 Application Objects에 모든 접근이 가능하다. Application Schema Owner 계정의 사용에 제한을 두는 것은 Application Objects에 추가적인 보안을 제공한다. Application Objects를 소유하고 있는 DB 관리자 계정은 만약 관리자 계정이 애플리케이션에 의해 사용되지 않는다면 사용 을 제한할 필요는 없다.
또한, DB 관리자 계정은 매일 반복되는 특별한 작업에 대해 할당해서는 안된다. 인가된 DBA 계정 리스트나 ISSO에서 제공하는 인가된 DBA 리스트를 얻기 위해서 D03440을 살펴 봐야 한다. DB 관리자간의 상호연동을 위해 각 DBA에 할당된 임의의 DBA 계정은 무관하지만 임의의 다른 계정들의 리스트가 있는지를 확인한다. 다음은 이를 위한 스크립트이다.

3) Oracle Predefined Roles Oracle Predefined Role은 Application Role, Application 사용자 또는 애플리케이션 관리자에게 부여되지 않는다. Application 사용자는 자신의 업무를 수행하기 위한 최소 한의 권한만을 받아야 한다. Oracle Predefined Role은 오라클 업무 기능을 위한 오라클 에 의해 정의된다. Customer Defined Role은 RDBMS에 의해서 생성되고 사용된다. 다음은 이를 위한 스크립트이다.

4) Developer Account Privileges on Production Databases

운용 DB 시스템 또는 공유된 운용·개발 DB 시스템에서 개발자에게 Create, Alter, Drop 와 같은 DBA 권한을 할당해서는 안된다. 운용 환경에서 테스트되지 않은 Objects를 통제 되지 않은 Introduction은 DB 시스템의 알려지지 않은 취약점을 알려줄 수 있고 시스템 자원의 경쟁이 생길 수 있다.
다음 스크립트의 실행 결과로 리스트된 모든 계정들이 인가된 DBA 계정인지와 애플리케 이션 개발자 계정이 아닌지를 확인하기 위해서 운용 DB 시스템상에서 Create, Alter, 또 는 Drop Privilege가 부여된 계정 및 Role의 리스트를 확인한다.

5) Access to System Tables/DBA Views System Tables과 DBA View는 사용자 정보, 시스템 정보, 그리고 데이터 정보와 같은 비인가된 접근을 불러 올 수 있는 정보를 포함하고 있다. SYS 소유의 오브젝트에 직접 접 근할 수 있거나 DBA view (DBA_%)로 접근이 가능한 일반 계정에 부여된 권한을 전부 해 지해야 한다.
다음 스크립트의 실행 결과로 리스트 된 계정에 대해 인가가 되었는지를 확인해야 한다.

6) Roles Assigned to PUBLIC Application Role은 PUBLIC에 부여되며, PUBLIC에 부여된 권한은 DB의 모든 사용자 에게 부여된다. Custom Role은 Application 권한을 특정 애플리케이션 사용자 그룹에 할당하기 위해 사용된다.
다음 스크립트의 결과값을 통해 Public으로 부여된 Role을 확인할 수있다.

7) SYSDBA Privilege Assignments

DBA의 권한을 가지는 SYSDBA의 권한의 사용을 제한해야 한다. SYSDBA 권한은 사용 자에게 DB를 구동하고, 종료시키고, DB를 재설정할 수 있다. 'as sysdba'로 DB에 접속 하게 되면 SYS 스키마안에서 SYS 사용자 권한으로 DB에 연결된다. Oracle의 감사기능 은 SYS 사용자에 의한 실행을 감사하지 못한다. 따라서, SYSDBA 권한을 가진 계정을 엄 격히 관리해야 한다.
인가된 DBA 계정 이외에 SYSDBA 권한을 가진 계정의 인가여부를 확인한다.
다음img src="/publishing/img/knowledge/111221_dqc218.jpg">

8) System Privilege Assignments

시스템 권한은 DB와 DB 오브젝트에 대한 광범위한 변경을 허용한다. 변경 작업에는 테이 블, 뷰, 롤백 세그먼트, 그리고 프로시저의 생성, 삭제, 수정이 해당된다. 이러한 시스템 권한은 DBA나 인가된 사용자 계정에게 제한해서 부여해야 한다.
이를 위해 시스템 권한이 부여된 DBA가 아닌 계정과 Role의 리스트를 검토해야 한다. 또 한, 운용 DB상에서 Create User, Alter User, Drop User가 리스트되는 임의의 계정이 인가된 애플리케이션 관리 롤에 포함되어 있는지를 확인해야 한다. 개발 시스템에서는 개 발자에게 할당된 시스템 권한이 ISSO에 의해 공정하고 인가되었는지를 확인해야 한다. 다음 스크립트의 실행 결과를 통해 비인가된 사용자 계정이나 애플리케이션 사용자 롤이 있는지 확인한다.

9) DBA Includes Non-default Account

DBA Role은 매우 강력하다. 그래서 DBA로의 접근은 제한되어야 한다. DBA Role이 부 여된 임의의 Database 계정이 ISSO에 의해 명백하게 인가되었는지를 검증해야 한다. 비 인가된 계정이 DBA Role에 대한 접근 및 Database Objects에 대한 접근할 수 있다는 것 은 서버 시스템에 대한 모든 접근을 제공할 수도 있다는 것이다. 따라서, DBA 계정들이 DBA 각각에 의해 만들어졌는지와 DBA 계정들이 단지 DBA 기능을 수행하기 위해 사용 되고 있는지를 검증해야 한다.
다음은 인가된 DBA 계정을 확인하는 스크립트이다.

10) With Grant Option

GRANT OPTION을 가진 Object 권한이 있는 사용자는 다른 사용자에게 그가 소유한 오 브젝트의 권한을 부여할 수 있다. 모든 권한을 반드시 롤을 통해서만 부여되어야 한다. 다음은 이를 확인하기 위한 스크립트이다.

11) Role Permissions

기능적인 롤(Role)은 할당된 기능을 수행하는 사용자 계정에 대하여 요청되어지는 최소한 의 오브젝트(Object) 권한을 정의하고 할당하여야 한다. 최소한의 권한에 제한적인 접근 을 하기 위해서는 실행되는 프로시져에 권한을 부여해야 한다. SELECT, EDLETE, 그리고 UPDATE 오브젝트의 권한은 제한적일 필요는 없다. 그러 나 ALTER, INDEX, 그리고 REFERENCE 오프젝트의 권한은 시스템 사용자에게만 권 한을 부여해야 하며 애플리케이션 유저에게는 권한을 부여해서는 안된다. 다음은 ALTER, INDEX, REFERENCE 권한을 할당받은 계정의 인가 여부를 확인하는 스크립트이다.

12) Restricted PL/SQL Packages

UTL_FILE, UTL_SMTP, UTL_TCP, UTL_HTTP, and DBMS_RANDOM PL/SQL 패키지는 다양한 보안상의 취약점들이 소개되고 있다. 그러므로 이러한 패키지에 대한 접 근은 제한적이어야 한다.
다음은 UTL_FILE, UTL_SMTP, UTL_TCP, UTL_HTTP, and DBMS_RANDOM PL/SQL 패키지가 PUBLIC에게 EXECUTE 권한이 부여되었는지 확인하기 위한 스크립 트이다.

13) Privileges Granted With Admin

오라클 시스템의 권한은 직접적으로 부여되는 것이 아니라 롤(Role)을 통해서 부여된다. 롤을 통한 권한의 부여는 DB에 대한 관리적 제어와 효율성을 향상시킨다. 다음은 인가된 DBA 계정 이외에 admin_options='YES' 인 계정의 인가 여부를 확인하는 스크립트이다.

14) PUBLIC System Privileges

시스템 권한은 사용자 그리고 롤에 부여될 수 있으며 사용자 그룹 PUBLIC에 부여될 수 있 다. PUBLIC으로 부여된 모든 권한은 DB안에 있는 모든 사용자들에게 접근을 허용한다. 일반적으로 이러한 권한은 롤에 부여되며 따라서 적당한 롤을 사용자들에게 부여해야 한 다. 시스템 권한은 결코 PUBLIC 계정에 부여해서는 안된다. 왜냐하면 일반 사용자들이 DB에 침투하는 것을 허용할 수 있기 때문이다.
다음은 PUBLIC 계정에 시스템 권한을 부여되었는지를 확인하는 스크립트이다.

15) Roles Granted With Admin

Database 롤에 부여된 권한은 인가된 DBA와 Application Administrators로 제한되어 야 한다. 다음은 인가된 DBA 계정들인지 또는 Application Administrator 롤인지를 확인한는 스크립트이다.

16) Replication Account Use

■Replication을 지원하기 위해 사용된 계정은 인가된 DBA의 접근만 가능하도록 제한해 야 한다.

■Replication을 위해 Replication Administrator, Replication Propagator, Replication Receiver 3가지 롤 형태가 있다. 일반적으로 모든 롤은 단일 사용자 계정 에 의해 수행된다. ■Replication 계정(Default는 REPADMIN, 변경가능)이 단지 ISSO에서 리스트된 인 가된 사용자로 제한되어 있는지 DBA와 인터뷰한다. 그렇지 않다면 Finding이다. 그리 고 하나 이상의 계정이 있는 경우에는 해당 계정들이 공정한지를 확인한다.

17) Database Demonstration Objects

데모 계정과 Object는 DB 시스템에서 제거해야 한다. DB 데모 계정과 애플리케이션은 취약점을 가지고 있어서 운용 DB 시스템상에서는 필요하지 않다. 다음 스크립트 결과에 의해 리스트된 계정들은 제거되어야ledge/111221_dqc229.jpg">

18) Account Permissions

계정에 권한을 부여하는 것은 실수를 유발할 수 있고 이러한 실수를 반복될 수 있다. 기능 별로 할당된 권한을 그룹으로 관리하는 롤을 사용해야 한다. 이를 통해 잘못된 권한을 할 당할 가능성이 줄어든다. 롤에 권한을 할당하고 롤을 계정에 부여해야 한다. 이를 위해 다음 스크립트의 실행 결과값이 있는지 확인한다. 결과값에 대해서는 DBA와 인터뷰를 한다.

19) Default Accounts and Passwords

■오라클 DB 시스템은 몇 가지 잘 알려져 있는 기본 계정과 디폴트 패스워드가 있다. 이 러한 기본 계정 및 패스워드는 서버 시스템에 비인가된 접근을 허용할 수 있게 된다. 따 라서, 이러한 기본 계정을 사용하지 않을 경우에는 계정을 잠그고 기간을 만료 시켜야 한다.
■기본 계정 중에 연결이 되는 계정이 있는지 확인해야 하며 발견된 기본 계정에 대해 DBA와 인터뷰해야 한다.

바. 패스워드 관리

1) Password Life Time

PASSWORD_LIFE_TIME 값은 패스워드가 파기되는 시점을 의미한다. PASSWORD_ LIFE_TIME 값의 설정으로 사용자들이 패스워드를 변경하고 있는지 확인할 수 있다. PASSWORD_LIFE_TIME은 사용기간으로 설정할 수 있다. 또한, UNLIMITED로 설정 하면 영구히 사용할 수 있으며 디폴트 프로필에 지정된 값을 사용할 수도 있다. PASSWORD _LIFE_TIME 값을 UNLIMITED 로 두는 것은 사용자가 현재 설정된 패스워드를 영원히 사용하는 것을 허용하게 된다. 이러한 설정은 프로필에 설정되며 계정과 연관된다. 다음 스크립트를 실행하여 패스워드의 사용기간을 확인한 결과에 대해 DBA와 인터뷰해 야 한다.

2) Password Reuse PASSWORD_REUSE_MAX값은 패스워드를 다시 사용하기 전에 패스워드를 바꿔야 하 는 횟수를 나타낸다.
PASSWORD_REUSE_MAX 값은 DEFAULT로 설정할 수 있고 UNLIMITED로 설정할 수도 있으며 특별한 숫자로 설정할 수 있다. 이러한 설정은 DEFAULT 프로필 안에 나타 난다. 이러한 DEFAULT 프로필은 각 계정에 대해 설정해야 한다. PASSWORD_REUSE_MAX는 PASSWORD_REUSE_TIME와 배타적이다. 만약 PASSWORD_ REUSE_MAX를 설정하였다면, PASSWORD_REUSE_TIME는 같은 프로필 안 에 UNLIMITED로 설정해야 한다.
PASSWORD_REUSE_MAX의 최대 허용치는 '10'이며, PASSWORD_REUSE_TIME 값의 최대 허용치는 365일이다.
PASSWORD_REUSE_MAX 값과 PASSWORD_REUSE_MAX 값이 설정되어 있는지를 확인한 후 각 값이 허용치를 넘지 않았는지를 확인한다. 다음은 이를 위한 스크립트들이다.

3) Password Verify Function

PASSWORD_VERITY_FUNCTION의 값은 프로필에 할당되어 있는 사용자가 DB에 로 그인할 때 패스워드를 확인하는데 사용되는 PL/SQL의 함수값이다. 이 기능은 PL/SQL 을 통과하기 위해 필요한 패스워드를 검증하기 위해 사용될 수 있다. 이러한 기능은 반드 시 프로필이 적용되는 DB가 지역적으로 실행될 때 가능하다. 오라클은 이를 위해 디폴틀 스크립트(utlpwdmg.sql)을 제공한다. 그러나 오너는 오너의 함수를 생성할 수 있다. 패스워드 검증 함수의 소유권은 반드시 SYS여야 한다. PASSWORD_VERIFY_FUNTION 파라미터 기본값은 NULL이다. 이는 패스워드 검증 없이 수행됨을 의미한다. 다음 스크립트를 통해 PASSWORD_VERITY_FUNCTION의 값이 UNLIMITED나 NULL인지 확인할 수 있다.

4) REMOTE_LOGIN_PASSWORDFILE

EXCLUSIVE로 설정된 REMOTE_LOGIN_PASSWORDFILE은 SYS계정으로 로그인 하는 DBA에 대해 감사를 실시한다. 만약, EXCLUSIVE로 설정되어 있지 않다면 'internal' 이나 'SYSDBA'의 연결에 대해 로그를 남기지 않는다.
다음 스크립트를 통해 REMOTE_LOGIN_PASSWORDFILE의 값이 EXCLUSIVE로 설 정되었는지를 확인한다.

5) Database Link Password Encryption

오라클의 설정 파라메터인 DBLINK_ENCRYPT_LOGIN은 암호화된 패스워드를 사용하 여 원격지의 오라클 DB에 접속하는 파라미터이다.
오라클 7.2 버전 전에는 네트워크를 통해 패스워드가 전달될 때 암호화되지 않았다. 오래 된 서버에 연결하는 수단으로 오라클은 연결이 실패된 서버에 대해 암호화되지 않은 패스 워드를 사용하여 재연결을 시도할 때 이 파라미터를 사용한다. 만약, DBLINK_ENCRYPT_LOGIN 파라미터가 TRUE이면 커넥션은 실패할 것이고 다 시 연결을 시도하지 않는다. 만약 이 파라미터가 FALSE이면 처음 연결은 실패할 것이지 만, 오라클은 계속해서 암호화되지 않은 패스워드를 사용하여 연결을 시도할 것이다. DBLIKE_ENCRYPT_LOGIN 파라미터가 FALSE로 설정된 서버는 링크된 서버 사이에 암호화된 패스워드를 주고 받는다. 오라클 9i이후의 버전에서 이 파라미터는 TRUE로 기 본 설정되어 있다. 이 파라미터를 오라클 9i의 init.ora 파일에 추가하면, 에러 메시지들 을 볼 수 있다.
다음은 DBLINK_ENCRYPT_LOGIN의 파라미터 값이 'TRUE'인지를 확인하는 스크립트이다.

사. 환경설정

1) Audit Table Ownership

Audit Table은 SYS, SYSTEM 또는 이와 유사하게 보호받고 제한되고 접근이 문서화되 어 있는 DB 계정의 소유이어야 한다. Audit Table Ownership은 Audit Table에 비인가 된 접근을 막는데 도움을 준다.
Audit Table 소유자 계정이 단지 ISSO에서 리스트된 인가된 사용자로 제한되고 있는지 DBA에게 알아본다. 아울러, Audit Table 소유자 계정이 Audit Data의 검토 및 유지보 수 이외의 접근을 차단하고 있는지도 확인한다.

앞의 스크립트를 수행한 결과값이 'DB' 가 아니면 Audit Table을 사용하지 않는 것이다. 만약, 결과값이 'DB'이면 다음 스크립트를 실행한다.

앞의 스크립트를 수행한 결과, 리스트 된 소유자 계정이 'SYS' 또는 'SYSTEM' 이 아니라 면 해당 계정에 대해 검증한다.

2) Oracle Instance Names

DB 인스턴스 이름에 버전 숫자를 사용하는 것은 차후의 업그레이드에 있어 인스턴스 이름 의 사용을 제한하게 된다. 운용 DB의 DB 인스턴스 이름의 변경은 불필요한 관리적 부하 를 야기할 수 있고 보안 네트워크 설정에 침해가 발생할 수 있다. 다음은 결과값의 첫 부분이 숫자이거나 혹은 오라클의 릴리즈 번호인지를 확인하는 스크 립트이다.

3) Oracle Control Files

Control Files는 DB의 물리적 상태를 정의하는 바이너리 형식의 파일로 다음과 같은 정 보가 저장되어 있다.
■DB 명(SID : System ID)
■DB 파일과 REDO 로그파일명
■현 로그 순서 번호(Log Sequence number)
■체크 포인트 정보
Control Files가 손상되면 DB의 기동이 불가능하다. 여러 개의 컨트롤 파일(물론 각각의 내용은 동일하다.)을 지정하여 손상에 대비하는 것이 일반적이다. 하나의 물리적 디스크 나 RAID 디스크상에는 하나의 오라클 Control 파일이 존재한다. 따라서, 물리적으로 분 리된 여러 개의 디스크에 오라클 Control 파일을 준비하는 것이 필요하다. 다음을 통해 물리적으로 분리된 두개 이상의 디스크에 오라클 Control 파일이 있는지 확 인할 수 있다.

4) Oracle Redo Log Files

두 개 이상의 Redo Log 파일이 있는 Oracle Redo Log 그룹을 둘 이상 생성하는 것은 바 람직하지 않다. 다음을 통해 오라클 Redo Log 그룹이 둘 이상 나오는지 확인할 수 있다.

5) SQL*Plus HOST Command

SQL*PLUS에서는 OS의 명령어를 사용할 수 있다. 따라서, HOST 명령어는 권한이 있 는 사용자로 제한해야 한다. 다음은 SQL*PLUS에서 OS 명령어의 실행이 인가된 사용자로 제한되어 있는지 확인하는 스크립트이다.

6) Audit Trail Location

오라클의 감사는 DB 또는 OS 파일의 감사 자료를 기록하도록 설정할 수 있다. DB에 대해 서 기록된 이벤트들은 뷰를 통해 OS 사용자에게 제공된다. Audit를 사용하는 경우에 audit_trail의 값은 TRUE, DB, OS로 설정되어야 하며 NONE 으로 설정하면 audit_trail을 사용하지 않게 된다. 다음을 통해 audit_trail의 값이 NONE인지를 확인한다. 만약, 파라미터값을 변경하면 DB를 재실행해야 한다.

7) Audit Table Permissions

Audit Table에 대한 권한은 Audit Table에 접근하는 계정들을 제한한다. 과도한 권한의 부여는 Audit Trail Data를 함부로 수정할 수 있게 된다. 계정들에게 단지 Audit Data 가 저장된 테이블(SYS.AUD$)에서 select, insert, delete 또는 update 기능을 수행할 수 있는 권한이 부여되었는지 점검해야 한다.
다음 스크립트를 통해 리스트된 계정들이 인가된 DBA 계정들인지 또는 제 3의 Audit 모 니터링 계정 문서에 등록되었는지를 확인할 수 있다.

8) Idle Time Resource Usage Limit

Idle Time Resource 사용 설정은 하나의 세션에서 허용될 수 있는 최대 Idle Time을 제 한해야 한다. Idle Time은 하나의 세션에서 비활성 시간(분으로 표시)의 간격이다. 실행 시간이 긴 쿼리나 다른 작업들은 이러한 제한이 필요하지 않다. Idle Time Resource Usage 제한 설정은 사용자가 그들의 자리에서 이탈할 때 애플리케이션을 열어두는 것을 막는다.
다음의 스크립트를 통해 리스트 된 Idle time이 60분 이상으로 나오면 애플리케이션 사용 자에게 어떤 프로필이 할당되었는지 확인할 수 있다.

9) Failed Login Attempts

FAILED_LOGIN_ATTEMPTS 값은 로긴 시도의 횟수를 제한하는 값으로 제한된 로긴 시도횟수 이후에는 계정이 잠기게 된다. 이 값을 설정함으로써 비인가된 사용자가 패스워 드를 추측하게 하는 것을 방지할 수 있다.
다음 스크립트를 통해 FAILED_LOGIN_ATTEMPTS의 값이 UNLIMITED나 NULL로 설정되어 있는지 확인할 수 있다.

10) Trusting Remote OS Authentication Setting

REMOTE_OS_AUTHENT 값이 TRUE로 설정되어 있으면 안전하지 않는 커넥션을 통한 원격지의 OS의 인증을 허용한다. 원격지 OS를 신뢰하는 것은 원격지 OS의 사용자인 것 처럼 속이는 사용자를 허용?용한다. 따 라서, 설정 값은 FALSE로 설정해야 한다. 만약, 설정 값을 변경하게 되면 DB를 재시동 해야 한다.
다음 스크립트를 통해 REMOTE_OS_AUTHENT 값이 FALSE인지 확인할 수 있다.

11) Trusting Remote OS for Roles Setting

REMOTE_OS_ROLES가 TRUE이면 OS의 그룹들이 오라클의 롤을 조절할 수 있다. 만 약, FALSE 값이면 롤은 DB 시스템에 의해 관리되고 인식된다. REMOTE_ OS_ROLE이 TRUE로 설정된다면 원격 사용자는 네트워크가 연결된 상태에서 다른 OS 사용자 역할을 할 수 있다. 따라서, REMOTE_OS_ROLES의 값은 FALSE로 설정되어야 한다. 다음 스크립트를 통해 REMOTE_OS_ROLES의 값이 FALSE인지 확인할 수 있다.

12) Oracle SQL92_SECURITY

SQL92_SECURITY 파라미터의 설정은 해당 참조 테이블 열값의 갱신 또는 삭제를 실행 하는 데 테이블 수준 SELECT 권한이 필요한지 여부를 지정한다. 만약, 이 옵션이 TRUE 로 설정되어 있으면 갱신 권한이 실행될 때 SELECT 권한을 사용할 수 있다. 다음 스크립트를 통해 SQL92_SECURITY가 TRUE로 설정되어 있는지 확인할 수 있다.

13) UTL_FILE_DIR Setting

UTL_FILE 패키지는 오라클 DB 프로세스나 서비스가 호스트 파일에 접근하는 것을 허용 한다. 이 패키지가 사용할 수 있는 모든 파일들은 데이터 베이스의 UTL_FILE 실행 권한 이 있는 어떠한 DB 사용자도 사용할 수 있기 때문에 주의해서 사용해야 한다. UTL_FILE_DIR 값이 '*'로 설정되어 있으면 오라클 DB 프로세스는 UTL_FILE 패키지 를 통해 모든 디렉토리에 접근할 수 있다. UTL_FILE_DIR 리스트는 보호해야 할 디렉토 리와 권한을 부여해야 할 디렉토리를 명확히 기술해야하며 경로명을 전부 포함해서는 안 된다.
UTL_FILE PACKAGE를 통해 모든 디렉토리에 대해 읽고 쓰기가 가능하도록 설정되어 있는지 확인한다. 만약, 결과값으로 '*'가 나오면 모든 디렉토리가 접근 가능한 것이므로 설정을 변경해야 한다.

14) Data Dictionary Accessibility

SELECT ANY TABLE 권한을 갖는 계정이 암호화된 패스워드와 같은 Data Dictionary Table에 있는 중요한 데이터에 접근을 제한하고 있는지를 확인한다. 이 기능은 오라클 8에서 07_DICTIONARY_ACCESSIBILITY 파라미터를 통해 제공된 다. 만약, 이 파라미터 값이 FALSE이면 Data Dictionary 내에 있는 민감한 정보에 접근 하는 것을 제한한다.
다음 스크립트를 통해 07_DICTIONARY_ACCESSIBILITY 값이 FALSE인지를 확인할수 있다.

15) Database Link Permissions

Database Link 패스워드는 SYS.LINK$ 테이블에 암호화되지 않은 상태로 저장이 되는 데, 이 테이블에 대한 접근은 제한되어야 한다.
이를 위해 다음 스크립트의 수행 결과값이 있는지를 확인한다.

16) Resource Limits Not Enabled

RESOURCE_LIMIT 파라미터는 DB 프로파일에 리소스 제한의 강제 수행 여부를 결정한 다. FALSE값으로 설정하면 리소스 제한의 강제 적용을 비활성화하고, TRUE값으로 설 정하면 리소스 제한의 강제 적용을 활성화한다. RESOURCE_LIMIT 파라미터의 기본값 은 FALSE이다. 이 값은 패스워드 리소스에는 적용되지 않는다.
다음 스크립트를 통해 RESOURCE_LIMIT 의 설정이 'TRUE'로 설정되어 있는지를 확인 할 수 있다.

17) Current Oracle Version

다음은 현재 DB 시스템의 버전을 확인하는 스크립트이다.

5. DB 취약점 체크리스트(Oracle 기반)

모든 DBA는 오라클이 안정적으로 운영되고 문제발생 시에 해당 원인을 찾아 신속히 대처 해야 할 임무를 갖는다. 이를 위해서 사전에 발생할 수 있는 문제들이 어떠한 것이 있는지 파악하고 있어야 하며, 일단 문제가 발생하였을 경우 오라클 운영 환경을 점검하여 빠른 시간 내에 문제를 해결할 수 있어야 한다.

본 가이드라인은 오라클 운영 중에 고려해야 할 다양한 항목들을 제시하고 있다. 오라클 운영 중 고려해야 할 항목은 크게 DB 전체와 DB를 구성하는 FILE 및 TABLESPACE 종 류 별로 백업, 설정, 모니터링 등의 측면을 구분하여 각각 점검할 사항들을 제시한다. 각 구성요소별 백업, 설정, 모니터링 등의 측면에서 살펴보고, 이것을 업무에 적용함으로 써 오라클 운영과 문제상황에 대해 효과적으로 대처할 수 있다.

가. Database

1) 백업
■백업(Backup)에 사용될 테이프와 같은 장비상태가 불안정하다고 판단될 때는 절대로 사용하지 말아야 한다. 또한, 백업된 정보는 즉시 확인할 수 있어야 한다. 즉, 어느 파 일이 어느 백업 위치에 있는지 바로 알 수 있어야 것이다.
■시스템 가동 시점에서 백업 절차 전체에 대한 테스트를 수행한 후, 해당 결과를 확인하 여 변경할 사항들이 있는지 확인하여야 한다.
■백업 되는 파일 이름은 날짜, 업무 등의 정보를 포함시켜서 나중에 보더라도 알기 쉽도 록 지정한다.
■3개월 단위마다 정기적으로 백업을 이용한 복구 테스트(Recovery Test)를 실시한다.

2) 설정
■가장 최신의 오라클 패치를 적용하여 시스템이 안정적으로 운영될 수 있도록 해야 한다.
■DB_FILES 값의 설정에 주의해야 한다. 이 값을 초과하여 추가 하려고 할 때는 에러가 발생하게 되고, 이러한 상황에서 DB_FILES를 변경하게 되면 DB는 종료(shutdown) 후에 다시 시작(start)되어야 한다.
■ENQUEUE_RESOURCES는 OS의 Lock Resource를 조절하는 역할을 한다. 이 값 이 너무 낮게 설정되어 있게 되면 특정 애플리케이션에서 Time Out이 발생하게 된다.
■DML_LOCKS값은 Object에 대한 작업을 하는 모든 사용자를 고려하여 최대한 크게 설 정한다. 이 값이 부족하게 되면 애플리케이션에서 에러가 발생하게 된다.
■DB를 재생성할 경우에 대비해서 그 절차를 숙지하고 있어야 한다. 그렇지 않으면 소요 작업시간이 길어지게 된다.

3) 모니터링
■Alert.log와 Trace 파일의 내용을 점검하여 에러가 없는지, Archive나 Checkpoint 에 대한 Waiting이 발생하지 않았는지 등을 점검한다. 이 파일들을 이용하여 오라클 Internal Error나 다른 Error 정보를 얻을 수 있다.
■*_dump_dest의 Free Space여부를 확인한다. InitSID.ora나 configSID.ora에 *_dump_dest가 설정되어 있다. 특히, Alert Log 는 계속 늘어나게 되므로 일정한 크 기가 되었을 때 백업을 받고, Background_dump_dest의 Free Space를 수시로 점검 하여 Space 문제가 발생하지 않도록 주의한다.
■Tablespace별로 성장속도를 확인한다. 이렇게 하면 Space 부족으로 발생할 수 있는 DB Hang 문제를 미리 대비할 수 있게 된다.
■Utlbstat.sql / utlestat.sql으로 DB 상태를 정기적으로 점검하여 시스템에 대한 통계 정보를 기록해 둔다. 이 자료는 튜닝을 위한 기초자료가 된다.
■각 Tablespace에 대해 Fragmentation을 점검한다. Fragmentation이 많이 발생하 여 Free Space가 부족하다면 Coalesce를 수행하거나 Data File을 추가하도록 한다. Disk Space가 거의 존재하지 않는다면 Export를 받은 후 다시 Import를 실시한다.
■InitSID.ora 파일에 변경이 있을 때 마다 그 이력(History)를 기록해 둔다. 이렇게 하 면 Parameter의 변경으로 발생하는 문제를 대처할 수 있고, 성능(Performance)의 변 화도 알 수 있다.

나. Database 구성 File

오라클 DB를 구성하는 파일들은 Control 파일, Online Redo Log 파일, Archive Log 파일, Data 파일 등으로 나누어진다. 각각의 파일들은 DB 운영을 위해 중요한 정보들을 포함하고 있으므로 수시로 상태를 점검하여야 한다.

1) CONTROL 파일
■ 백업
？정기적으로 백업을 받도록 한다. Cold Backup일 경우에는 Control 파일자체를 복 사하여 백업을 받고 DB가 운영중일 경우는 다음 명령어를 이용하여 파일을 백업받 도록 한다.

.Data 파일과 Redo Log 파일의 추가나 삭제 등의 원인으로 DB에 변경사항이 있을 때마다 백업 받도록 한다.

.Hot Backup시 End Backup이 발생할 때마다 백업을 받도록 한다.
.백업받은 파일 이름에 날짜와 업무정보 등을 포함시켜 쉽게 알아볼 수 있도록 한다.

■ 설정
.MAXDATAFILES 값은 예상치보다 크게 설정하여야 한다. 디폴트 값은 플랫폼 (Platform)별로 다르게 지정된다. InitSID.ora에서 DB_FILES가 크게 설정되어 있더라도 MAXDATAFILES 값이 너무 작으면, DB에서 동시에 Open할 수 있는 Datafile의 개수는 MAXDATAFILES 값을 넘을 수가 없게 된다. 이 값을 변경하기 위해서는 Control 파일을 재생성해야 한다.
？별도의 디스크와 콘트롤러가 사용되도록 물리적 위치를 지정한다.
？*.ctl과 같이 알기 쉬운 이름을 사용하도록 한다.
？최소 3개가 사용되도록 해야 한다.
？MAXLOGFILES 값을 확인하여 예상치보다 크게 설정하도록 한다.
？MAXLOGMEMBERS 값이 3이상이 되도록 설정한다.
？OPS의 경우 MAXINSTANCES값을 예상치보다 크게 설정하도록 한다.
？MAXLOGHISTORY는 저장될 Log History정보의 양을 지정하므로, Log File이 생성되는 추이를 파악하여 적절한 값을 지정하여야 한다.
？OS 레벨에서 모니터링이 되어 있는지 확인하고 Striping은 하지 않도록 한다.

2) ONLINE REDO LOG 파일
■ 백업
？Hot Backup시에는 End Backup 이후에 'archive log list' 명령어를 수행하여 현재 Log Sequence Number를 먼저 확인해야 한다. 그리고 나서 다음 명령어를 수행하여 Archive를 추가로 생성한 후, 앞서 확인한 Sequence Number까지 Archive Log를 백업 받으면 된다.

？Hot Backup시에는 Archive Log 파일이 Backup되었으면 Online Redo Log는 백업받을 필요가 없다.
？Cold Backup시에는 Restore 할 때의 실수를 방지하기 위하여 주요 DB 파일, 특히 Archive Log 파일과는 다른 위치에 백업을 받는다.
■ 설정
？OPS일 경우 Instance Recovery를 위해서 Log의 모든 Member는 동시에 Access 가 가능하여야 한다.
？각 그룹의 Member들은 Disk와 Controller를 별도로 사용하도록 지정한다.
？Redo의 Thread는 Instance당 1개를 설정하여야 한다.
？Redo Log Group은 최소 3개 이상이 되도록 하고, 각 그룹들은 최소 2개 이상의 Member를 가지도록 한다. 이렇게 Log Mirroring을 하게 되면 돌발적인 파일 삭 제 상황에 대비할 수 있게 된다.
？Redo Log Member의 Size는 Checkpoint에 대한 Waiting이 발생하지 않도록 충 분한 크기를 지정하여야 한다. 사이즈(Size)가 너무 작을 경우에는 잦은 Log Switch 로 인하여 복구 시간이 지나치게 많이 소요될 수 있다.
？Redo Log Member의 사이즈는 모두 같게 한다.
？DB 파일과 다른 물리적인 위치를 지정하도록 한다.
■ 모니터링
？Checkpoint 주기를 점검하도록 한다. 권장할 만한 Checkpoint의 주기는10-15분 정도이다. LOG_CHECKPOINT_INTERVAL을 가장 큰 Redo Log File Size보다 크게 설정하고 LOG_CHECKPOINT_TIMIEOUT을 0으로 설정하게 되면, Log Switch가 일어날 때마다 Checkpoint가 발생하게 되므로 Log File Size 변경을 통 해 Checkpoint 주기를 조정할 수 있게 된다.
잦은 Checkpoint는 Crash 복구 시간은 줄여주지만, Dirty Buffers를 자주 사용하 고 File Headers를 자주 업데이트하게 되어 Overhead를 일으키게 된다. ？Log Switch가 너무 자주 발생하지 않는지 점검한다. Log Switch는 15분 정도 주 기가 적당하다. Log Switch가 너무 자주 발생하면 v$backup을 통해 Hot Backup 상태인 파일이 있는지도 확인한다.
？V$logfile을 통해 Status를 수시로 점검한다. Status가 Invalid나 Stale이 없는지 확인해야 한다.
3) ARCHIVE LOG 파일
■ 백업
？모든 Archive Log가 빠짐없이 백업에 포함되었는지 점검한다. 또한, V$LOG에서 Archived, Status 칼럼을 참조하여 Archive가 완전이 끝난 Log 파일을 백업해야 한다.
？OPS일 경우에는 모든 Thread에서 생성되는 Archive를 전부 백업해야 한다.
？백업된 Archive Log 파일의 Sequence Number가 연속되어 있는지 확인해야 한다.
？Archive Log 파일이 특정 Threshold에 도달할 때마다 백업해야 한다. 가능하다면 매일 백업을 받는 것이 좋다.
？백업된 Archive 파일들은 삭제하도록 한다. 그러나 Disk의 공간을 충분히 하여 최 소한 하루의 Archive Log들은 백업을 받았더라도 삭제하지 않도록 한다. 이것은 장애 시에 복구 시간을 줄이는 역할을 할 수 있다.
？Archived Log File의 개수는 Log 파일의 크기와 Redo의 양에 달려있다. 그리고 Redo 의 양은 Transaction의 양과 연관되어 있다. 이러한 환경을 고려하여 백업의 빈도를 결정하도록 한다.
？백업 위치별로 그 속에 포함된 Log가 어느 기간동안 생성된 것인지에 대한 정보를 기록해 두어야 한다.
？Archive Log 생성속도와 파일의 백업 속도에 대해 알고 있어야 한다.
？Main이 되는 백업 장비에 문제가 있을 것에 대비하여 즉시 사용 가능한 대체장비를 확보하고 있어야 하며, 이 대체장비는 Backup Script에 반영되어 있어야 한다.
■ 설정
？DB가 ARCHIVELOG Mode로 운영 중인지 확인한다. 이것을 위해서는 다음 명령어 를 사용할 수 있다.

？생성되는 Archive 파일의 위치와 파일 이름 형식을 알아보기 쉽도록 지정한다. 이 것은 initSID.ora에서 LOG_ARCHIVE_DEST와 LOG_ARCHIVE_FORMAT을 통해 지정할 수 있다. LOG_ARCHIVE_FORMAT= "LOG%s_%t.ARC"으로 설정 할 경우 %s는 Log Sequence Number, %t는 Thread Number를 의미한다. 특히 OPS인 경우 %t를 설정하여 Thread별로 생성되는 Archive를 구별하여 관리하도 록 한다.
？Archive되는 위치가 Disk인지 확인한다. Tape에서 Disk로 옮기는 시간을 줄여서 복구 시간을 단축할 수 있다. 그러나 Tape에도 Archive를 복사해 두도록 한다. ？Online Redo Log와는 다른 Disk와 Controller를 사용해야 한다.
？DB 파일과는 다른 Disk와 Controller를 사용해야 한다.
？OS 레벨에서 Mirror가 되도록 하고, Striping은 하지 않도록 한다.
■ 모니터링
？Archive 파일이 생성되는 위치에 여유 공간이 있는지 확인해야 한다. Disk에 여유 공간이 없어서 Archive Log를 생성하지 못하는 경우에는 DB Hang이 발생하게 된 다. Archive 위치에 여유공간이 얼마 남지 않았을 경우 경고 메시지를 발생시키도 록 하는 내용을 Backup Script에 포함시킨다.
？Archive와 관련된 에러가 발생하지 않았는지 Alert Log를 점검한다.
？Archived Log 파일의 Sequence Number가 순차적인지 확인한다. Log Switch 가 일어날 때마다 Sequence Number는 하나씩 증가된다.
？DB가 ARCHIVELOG Mode로 작동중인지 확인해 본다. 만약 Archive Log Mode 가 아니라면 다음과 같은 과정을 통해 Mode를 변경할 수 있다.

？ARCH Process가 움직이는지를 자주 확인한다. 이렇게 하면ARCH Process가 움 직이지 않아서 DB가 Hang이 걸리는 문제를 막을 수 있다.

다. TABLESPACE

오라클 DB를 구성하는 Tablespace에는 System Tablespace, Rollback Segment Tablespace, Data Tablespace, Temporary Tablespace 등이 있다. 각 Tablespace 는 Data를 저장하는 논리적인 공간이며, 앞에서 다룬 OS 상의 DB 관련 파일들과 긴밀하 게 연관되어 있다.

1) SYSTEM TABLESPACE
■ 모니터링
？Free Space를 수시로 점검한다.
？Extents의 개수가 MAXEXTENTS/2 지점에 이르지 않았는지 확인한다.
？Tablespace의 size가 적정수준인지 확인한다. 일반적인 System Tablespace의 Size는 30~50M이다.
？일반사용자의 Object나 Temporary Segment가 포함되지 않았는지 점검한다.
？일반사용자에게 사용권한을 부여하지 않도록 한다.
？System Tablespace 이외의 Tablespace에서 발생하는 Extent는 Data Dictionary 의 정보를 사용하게 되므로 작은 Extent가 지나치게 많을 경우 System Tablespace 의 Space도 영향을 받게 된다.
？특별한 경우가 아니면 SYS Object의 Storage절을 변경하지 않도록 한다.
？Disk를 모니터링하고 Striping은 설정하지 않는다.
2) ROLLBACK SEGMENT TABLESPACE
■ 백업
？Hot Backup은 DB Activity가 낮은 시점에서 실시한다.
■ 설정
？알기 쉬운 이름을 사용해야 한다.
？일반적인 용도의 RBS의 크기는 모두 같게 한다.
？INITIAL과 NEXT는 같게 설정한다.
？PCTINCREASE는 0으로 설정한다.
？InitSID.ora에서 UNLIMITED_ROLLBACK_SEGMENTS=FALSE를 지정하여 RBS가 Unlimited Extent Format을 사용하는 것을 방지하도록 한다.
？OS 레벨에서 모니터링을 하고 Striping은 하지 않는다.
■ 모니터링
？InitSID.ora에 RBS들이 등록되어 있는지 확인한다.
？RBS가 Online 상태인지 주기적으로 점검한다. 이 때 dba_rollback_segs를 이용 할 수 있다.
？RBS Tablespace에 다른 Object가 생성되지 않았는지 점검한다.
？RBS의 크기변동률을 점검한다. V$rollstat을 이용하면 RBS가 커지거나 줄어드는 비율과 Wait 정보를 확인할 수 있다.
？Free Space와 Fragmentation 정도를 점검한다.
？ORA-1555에러가 발생하는지 점검한다. 이 경우에 DB는 여전히 사용가능하며 Application Error가 발생할 수 있다. Data 파일을 추가하여 공간을 늘여야 한다.
？RBS당 Transaction의 개수는 4개~5개가 적절하다.
？Batch Job에만 사용되는 큰 크기의 RBS를 별도로 설정하고, OLTP용 RBS와 동시 에 Online되지 않도록 한다. 다음 명령어로 특정 RBS 사용을 지정할 수 있다.

3) DATA TABLESPACE
■ 백업
？READ-ONLY Tablespace일 경우 쓰기, 읽기 권한 관리에 주의하여야 한다. 이러 한 변화는 Control 파일이나 Data 파일의 백업에도 영향을 미치게 된다.
？MTTR을 만족시킬 수 있는 주기 단위로 백업을 실시한다.
？Export를 이용하여 Object 레벨에서 Logical 백업을 받아두어야 한다.
？Hot Backup 시에는 해당 Data 파일의 Transaction 발생을 줄여서 Redo가 적게 발생되도록 해야 한다.
■ 설정
？알아보기 쉬운 이름을 사용하도록 한다.
？서로 다른 Tablespace는 다른 Disk에 위치하도록 하는 것이 좋다. OS 파일이 분실 되는 것은 곧 Tablespace의 분실을 의미하므로 사전에 주의하여야 한다.
？Index Tablespace는 Data와 분리하여 사용하도록 한다.
？Fragmentation을 줄이기 위해서는 Tablespace내에 비슷한 크기의 Object들이 위치하게 하는 것이 좋다.
？OPS의 경우에는 Application별로 Tablespace를 분리하여 운영하는 것이 좋다.
？Autoextend는 비활성화로 설정하여 사용한다.
？7.3 이전 Version에서는 Block Size 별로 Tablespace의 MAX EXTENTS의 값이 제한되어 있었다. 예를 들어, Block Size가 2K일 경우는 121, 8K일 경우는 505 였다. 그러나 7.3이후 Version에서는 MAX EXTENTS값보다 더 많은 값을 직접 지정하는 것이 가능해 졌다. MAX EXTENTS 보다 더 큰 값을 사용하게 되면 새로 운 Block Format이 사용된다.
？Default Storage 절이나 생성되는 Object에 MAXEXTENTS UNLIMTED를 사 용하지 않도록 한다.
？MAXEXTENTS UNLIMITED를 설정할 수도 있으나 권장되는 설정이 아니다. UNLIMITED Extent Format을 사용하려면 COMPATIBLE의 값이 7.3.0이상으 로 설정되어 있어야 한다.
？MAXEXTENTS UNLIMITED를 설정하는 것은 해당 Tablespace의 Free Space 전체를 사용하게 될 위험이 있다. 또, MAXEXTENTS UNLIMITED가 사용될 경우 작은 Extent의 개수가 과도하게 증가하여 DROP TABLE, TRUNCATE TABLE 작업 등을 수행할 때 Space와 관련된 심각한 성능 문제를 유발할 수 있다.
.OS 레벨에서 Mirror되게 한다.
■ 모니터링
.주요 Object에 대해서는 정기적으로 분석을 실시한다.
.문제를 조기에 발견하기 위해서 Object가 MAXEXTENTS/2에 도달했는지를 점검 한다.
.Type이 다른 Object가 동일한 Tablespace에서 혼용되지 않도록 한다.
.DBVERIFY를 사용하여 정기적으로 점검해 본다.
.Null Device에 Export하여 Logical Object의 상태를 점검해 본다.
4) TEMPORARY TABLESPACE
■ 설정
.임시 Tablespace의 개수는 DB 사용자별로 1개, OPS일 경우는 Instance의 개수 만큼으로 생성하도록 한다.
.7.3이상 Version에서는 TEMPORARY Status를 설정하도록 한다.
.PCTINCREASE 는 0으로 설정하도록 한다.
.INITIAL과 NEXT의 값은 sort_area_size의 배수로 설정한다.
.7.3 Version부터 TEMPORARY Tablespace 에 생성되는 Sort Segment는 INITIAL값으로 Tablespace의 NEXT 값을 그대로 사용하게 되고, PCTINCREASE는 0, MAXEXTENTS는 UNLIMITED로 지정된다. 따라서, 임시 Tablespace에 생성되 는 Sort Segments의 EXTENT 전체 크기는 조절할 수 없으므로 Default Storage 절에서 NEXT값 설정에 주의해야 한다.
.Index 생성을 위해 사용되는 임시 tablespace의 크기는 Index Data의 2배 정도가 되어야 한다.
.OS 레벨에서 모니터링을 하고 Striping은 하지 않도록 한다.
■ 모니터링
.일반 사용자가 올바른 임시 Tablespace를 사용하고 있는지 확인한다.
.Tablespace 내에 일반 사용자의 Object가 생성되지 않았는지 점검한다.
.Tablespace가 TEMPORARY 상태인지 확인한다.
.MAXEXTENTS UNLIMTED로 설정된 Tablesapce가 TEMPORARY Segments 를 위해 사용된다면, SMON이 해당 Segments를 Clean-up하는데 시간이 오래 걸 리게 되어 많은 자원을 소모하게 된다. 또한, Shutdown 작업이 지나치게 길어질 수도 있다.

라. OS 및 기타

오라클 DB는 OS 상에서 동작하기 때문에 안정적인 운영을 위해서 OS의 상태를 점검하는 것은 필수적이다. 또한, 리스너와 같은 오라클 Process들의 작동상태를 수시로 점검하여 애플리케이션 운영에 차질이 없도록 해야 한다.

1) OS
DB에 설정되어 있는 DB_FILES나 MAXDATAFILES 값이 크더라도, DB 사용자가 동시 에 접근하여 사용할 수 있는 파일의 개수는 OS에서 동시에 접근할 수 있는 파일의 개수를 넘을 수 없다.
따라서 사용 중인 Control 파일, Redo Log 파일, Data 파일, Alert.Log, Trace 파일 들의 개수를 모두 고려하여 OS에서 동시에 Open할 수 있는 파일 개수를 지정하여야 한 다. 이 값을 변경하기 위해서는 DB도 Down되어야 하기 때문에 운영 중인 시스템에서는 치명적일 수 있다.
그러므로 Disk나 Controller에 문제가 없는지 자주 확인하고, OS 모니터링이 제대로 동 작하고 있는지도 확인한다.

2) 기타
SQL*NET의 상태를 확인한다. Listener의 Process가 Running상태인지 확인하려면 다 음의 명령어를 사용할 수 있다.

마. 권한 관리

1) Unauthorized Object Owner

단지 SYS, SYSTEM, DB Administrators, 애플리케이션 소유자 계정들만이 운용 DB 시스템상의 Oracle Objects를 소유해야 한다. 개발자 계정은 또한 개발 DB 시스템상의 Object를 소유해야 한다. Object 소유권은 소유 Object에 대한 전체 권한을 의미한다. Database Object 소유자 계정이 인가된 Application 소유자 계정인지에 대해 확?? 확인하는 스크립트이다.

2) Active Schema Owner Account

Application Schema Owner 계정은 업데이트와 유지보수 업무를 제외하고는 사용에 제 한을 두어야 한다. Application Schema Owner 계정은 모든 Application Objects에 모든 접근이 가능하다. Application Schema Owner 계정의 사용에 제한을 두는 것은 Application Objects에 추가적인 보안을 제공한다. Application Objects를 소유하고 있는 DB 관리자 계정은 만약 관리자 계정이 애플리케이션에 의해 사용되지 않는다면 사용 을 제한할 필요는 없다.
또한, DB 관리자 계정은 매일 반복되는 특별한 작업에 대해 할당해서는 안된다. 인가된 DBA 계정 리스트나 ISSO에서 제공하는 인가된 DBA 리스트를 얻기 위해서 D03440을 살펴 봐야 한다. DB 관리자간의 상호연동을 위해 각 DBA에 할당된 임의의 DBA 계정은 무관하지만 임의의 다른 계정들의 리스트가 있는지를 확인한다. 다음은 이를 위한 스크립트이다.

3) Oracle Predefined Roles Oracle Predefined Role은 Application Role, Application 사용자 또는 애플리케이션 관리자에게 부여되지 않는다. Application 사용자는 자신의 업무를 수행하기 위한 최소 한의 권한만을 받아야 한다. Oracle Predefined Role은 오라클 업무 기능을 위한 오라클 에 의해 정의된다. Customer Defined Role은 RDBMS에 의해서 생성되고 사용된다. 다음은 이를 위한 스크립트이다.

4) Developer Account Privileges on Production Databases

운용 DB 시스템 또는 공유된 운용·개발 DB 시스템에서 개발자에게 Create, Alter, Drop 와 같은 DBA 권한을 할당해서는 안된다. 운용 환경에서 테스트되지 않은 Objects를 통제 되지 않은 Introduction은 DB 시스템의 알려지지 않은 취약점을 알려줄 수 있고 시스템 자원의 경쟁이 생길 수 있다.
다음 스크립트의 실행 결과로 리스트된 모든 계정들이 인가된 DBA 계정인지와 애플리케 이션 개발자 계정이 아닌지를 확인하기 위해서 운용 DB 시스템상에서 Create, Alter, 또 는 Drop Privilege가 부여된 계정 및 Role의 리스트를 확인한다.

5) Access to System Tables/DBA Views System Tables과 DBA View는 사용자 정보, 시스템 정보, 그리고 데이터 정보와 같은 비인가된 접근을 불러 올 수 있는 정보를 포함하고 있다. SYS 소유의 오브젝트에 직접 접 근할 수 있거나 DBA view (DBA_%)로 접근이 가능한 일반 계정에 부여된 권한을 전부 해 지해야 한다.
다음 스크립트의 실행 결과로 리스트 된 계정에 대해 인가가 되었는지를 확인해야 한다.

6) Roles Assigned to PUBLIC Application Role은 PUBLIC에 부여되며, PUBLIC에 부여된 권한은 DB의 모든 사용자 에게 부여된다. Custom Role은 Application 권한을 특정 애플리케이션 사용자 그룹에 할당하기 위해 사용된다.
다음 스크립트의 결과값을 통해 Public으로 부여된 Role을 확인할 수있다.

7) SYSDBA Privilege Assignments

DBA의 권한을 가지는 SYSDBA의 권한의 사용을 제한해야 한다. SYSDBA 권한은 사용 자에게 DB를 구동하고, 종료시키고, DB를 재설정할 수 있다. 'as sysdba'로 DB에 접속 하게 되면 SYS 스키마안에서 SYS 사용자 권한으로 DB에 연결된다. Oracle의 감사기능 은 SYS 사용자에 의한 실행을 감사하지 못한다. 따라서, SYSDBA 권한을 가진 계정을 엄 격히 관리해야 한다.
인가된 DBA 계정 이외에 SYSDBA 권한을 가진 계정의 인가여부를 확인한다.
다음은 이를 위한 스크립트이다.

8) System Privilege Assignments

시스템 권한은 DB와 DB 오브젝트에 대한 광범위한 변경을 허용한다. 변경 작업에는 테이 블, 뷰, 롤백 세그먼트, 그리고 프로시저의 생성, 삭제, 수정이 해당된다. 이러한 시스템 권한은 DBA나 인가된 사용자 계정에게 제한해서 부여해야 한다.
이를 위해 시스템 권한이 부여된 DBA가 아닌 계정과 Role의 리스트를 검토해야 한다. 또 한, 운용 DB상에서 Create User, Alter User, Drop User가 리스트되는 임의의 계정이 인가된 애플리케이션 관리 롤에 포함되어 있는지를 확인해야 한다. 개발 시스템에서는 개 발자에게 할당된 시스템 권한이 ISSO에 의해 공정하고 인가되었는지를 확인해야 한다. 다음 스크립트의 실행 결과를 통해 비인가된 사용자 계정이나 애플리케이션 사용자 롤이 있는지 확인한다.

9) DBA Includes Non-default Account

DBA Role은 매우 강력하다. 그래서 DBA로의 접근은 제한되어야 한다. DBA Role이 부 여된 임의의 Database 계정이 ISSO에 의해 명백하게 인가되었는지를 검증해야 한다. 비 인가된 계정이 DBA Role에 대한 접근 및 Database Objects에 대한 접근할 수 있다는 것 은 서버 시스템에 대한 모든 접근을 제공할 수도 있다는 것이다. 따라서, DBA 계정들이 DBA 각각에 의해 만들어졌는지와 DBA 계정들이 단지 DBA 기능을 수행하기 위해 사용 되고 있는지를 검증해야 한다.
다음은 인가된 DBA 계정을 확인하는 스크립트이다.

10) With Grant Option

GRANT OPTION을 가진 Object 권한이 있는 사용자는 다른 사용자에게 그가 소유한 오 브젝트의 권한을 부여할 수 있다. 모든 권한을 반드시 롤을 통해서만 부여되어야 한다. 다음은 이를 확인하기 위한 스크립트이다.

11) Role Permissions

기능적인 롤(Role)은 할당된 기능을 수행하는 사용자 계정에 대하여 요청되어지는 최소한 의 오브젝트(Object) 권한을 정의하고 할당하여야 한다. 최소한의 권한에 제한적인 접근 을 하기 위해서는 실행되는 프로시져에 권한을 부여해야 한다. SELECT, EDLETE, 그리고 UPDATE 오브젝트의 권한은 제한적일 필요는 없다. 그러 나 ALTER, INDEX, 그리고 REFERENCE 오프젝트의 권한은 시스템 사용자에게만 권 한을 부여해야 하며 애플리케이션 유저에게는 권한을 부여해서는 안된다. 다음은 ALTER, INDEX, REFERENCE 권한을 할당받은 계정의 인가 여부를 확인하는 스크립트이다.

12) Restricted PL/SQL Packages

UTL_FILE, UTL_SMTP, UTL_TCP, UTL_HTTP, and DBMS_RANDOM PL/SQL 패키지는 다양한 보안상의 취약점들이 소개되고 있다. 그러므로 이러한 패키지에 대한 접 근은 제한적이어야 한다.
다음은 UTL_FILE, UTL_SMTP, UTL_TCP, UTL_HTTP, and DBMS_RANDOM PL/SQL 패키지가 PUBLIC에게 EXECUTE 권한이 부여되었는지 확인하기 위한 스크립 트이다.

13) Privileges Granted With Admin

오라클 시스템의 권한은 직접적으로 부여되는 것이 아니라 롤(Role)을 통해서 부여된다. 롤을 통한 권한의 부여는 DB에 대한 관리적 제어와 효율성을 향상시킨다. 다음은 인가된 DBA 계정 이외에 admin_options='YES' 인 계정의 인가 여부를 확인하는 스크립트이다.

14) PUBLIC System Privileges

시스템 권한은 사용자 그리고 롤에 부여될 수 있으며 사용자 그룹 PUBLIC에 부여될 수 있 다. PUBLIC으로 부여된 모든 권한은 DB안에 있는 모든 사용자들에게 접근을 허용한다. 일반적으로 이러한 권한은 롤에 부여되며 따라서 적당한 롤을 사용자들에게 부여해야 한 다. 시스템 권한은 결코 PUBLIC 계정에 부여해서는 안된다. 왜냐하면 일반 사용자들이 DB에 침투하는 것을 허용할 수 있기 때문이다.
다음은 PUBLIC 계정에 시스템 권한을 부여되었는지를 확인하는 스크립트이다.

15) Roles Granted With Admin

Database 롤에 부여된 권한은 인가된 DBA와 Application Administrators로 제한되어 야 한다. 다음은 인가된 DBA 계정들인지 또는 Application Administrator 롤인지를 확인한는 스크립트이다.

16) Replication Account Use

■Replication을 지원하기 위해 사용된 계정은 인가된 DBA의 접근만 가능하도록 제한해 야 한다.

■Replication을 위해 Replication Administrator, Replication Propagator, Replication Receiver 3가지 롤 형태가 있다. 일반적으로 모든 롤은 단일 사용자 계정 에 의해 수행된다. ■Replication 계정(Default는 REPADMIN, 변경가능)이 단지 ISSO에서 리스트된 인 가된 사용자로 제한되어 있는지 DBA와 인터뷰한다. 그렇지 않다면 Finding이다. 그리 고 하나 이상의 계정이 있는 경우에는 해당 계정들이 공정한지를 확인한다.

17) Database Demonstration Objects

데모 계정과 Object는 DB 시스템에서 제거해야 한다. DB 데모 계정과 애플리케이션은 취약점을 가지고 있어서 운용 DB 시스템상에서는 필요하지 않다. 다음 스크립트 결과에 의해 리스트된 계정들은 제거되어야 한다.

18) Account Permissions

계정에 권한을 부여하는 것은 실수를 유발할 수 있고 이러한 실수를 반복될 수 있다. 기능 별로 할당된 권한을 그룹으로 관리하는 롤을 사용해야 한다. 이를 통해 잘못된 권한을 할 당할 가능성이 줄어든다. 롤에 권한을 할당하고 롤을 계정에 부여해야 한다. 이를 위해 다음 스크립트의 실행 결과값이 있는지 확인한다. 결과값에 대해서는 DBA와 인터뷰를 한다.

19) Default Accounts and Passwords

■오라클 DB 시스템은 몇 가지 잘 알려져 있는 기본 계정과 디폴트 패스워드가 있다. 이 러한 기본 계정 및 패스워드는 서버 시스템에 비인가된 접근을 허용할 수 있게 된다. 따 라서, 이러한 기본 계정을 사용하지 않을 경우에는 계정을 잠그고 기간을 만료 시켜야 한다.
■기본 계정 중에 연결이 되는 계정이 있는지 확인해야 하며 발견된 기본 계정에 대해 DBA와 인터뷰해야 한다.

바. 패스워드 관리

1) Password Life Time

PASSWORD_LIFE_TIME 값은 패스워드가 파기되는 시점을 의미한다. PASSWORD_ LIFE_TIME 값의 설정으로 사용자들이 패스워드를 변경하고 있는지 확인할 수 있다. PASSWORD_LIFE_TIME은 사용기간으로 설정할 수 있다. 또한, UNLIMITED로 설정 하면 영구히 사용할 수 있으며 디폴트 프로필에 지정된 값을 사용할 수도 있다. PASSWORD _LIFE_TIME 값을 UNLIMITED 로 두는 것은 사용자가 현재 설정된 패스워드를 영원히 사용하는 것을 허용하게 된다. 이러한 설정은 프로필에 설정되며 계정과 연관된다. 다음 스크립트를 실행하여 패스워드의 사용기간을 확인한 결과에 대해 DBA와 인터뷰해 야 한다.

2) Password Reuse PASSWORD_REUSE_MAX값은 패스워드를 다시 사용하기 전에 패스워드를 바꿔야 하 는 횟수를 나타낸다.
PASSWORD_REUSE_MAX 값은 DEFAULT로 설정할 수 있고 UNLIMITED로 설정할 수도 있으며 특별한 숫자로 설정할 수 있다. 이러한 설정은 DEFAULT 프로필 안에 나타 난다. 이러한 DEFAULT 프로필은 각 계정에 대해 설정해야 한다. PASSWORD_REUSE_MAX는 PASSWORD_REUSE_TIME와 배타적이다. 만약 PASSWORD_ REUSE_MAX를 설정하였다면, PASSWORD_REUSE_TIME는 같은 프로필 안 에 UNLIMITED로 설정해야 한다.
PASSWORD_REUSE_MAX의 최대 허용치는 '10'이며, PASSWORD_REUSE_TIME 값의 최대 허용치는 365일이다.
PASSWORD_REUSE_MAX 값과 PASSWORD_REUSE_MAX 값이 설정되어 있는지를 확인한 후 각 값이 허용치를 넘지 않았는지를 확인한다. 다음은 이를 위한 스크립트들이다.

3) Password Verify Function

PASSWORD_VERITY_FUNCTION의 값은 프로필에 할당되어 있는 사용자가 DB에 로 그인할 때 패스워드를 확인하는데 사용되는 PL/SQL의 함수값이다. 이 기능은 PL/SQL 을 통과하기 위해 필요한 패스워드를 검증하기 위해 사용될 수 있다. 이러한 기능은 반드 시 프로필이 적용되는 DB가 지역적으로 실행될 때 가능하다. 오라클은 이를 위해 디폴틀 스크립트(utlpwdmg.sql)을 제공한다. 그러나 오너는 오너의 함수를 생성할 수 있다. 패스워드 검증 함수의 소유권은 반드시 SYS여야 한다. PASSWORD_VERIFY_FUNTION 파라미터 기본값은 NULL이다. 이는 패스워드 검증 없이 수행됨을 의미한다. 다음 스크립트를 통해 PASSWORD_VERITY_FUNCTION의 값이 UNLIMITED나 NULL인지 확인할 수 있다.

4) REMOTE_LOGIN_PASSWORDFILE

EXCLUSIVE로 설정된 REMOTE_LOGIN_PASSWORDFILE은 SYS계정으로 로그인 하는 DBA에 대해 감사를 실시한다. 만약, EXCLUSIVE로 설정되어 있지 않다면 'internal' 이나 'SYSDBA'의 연결에 대해 로그를 남기지 않는다.
다음 스크립트를 통해 REMOTE_LOGIN_PASSWORDFILE의 값이 EXCLUSIVE로 설 정되었는지를 확인한다.

5) Database Link Password Encryption

오라클의 설정 파라메터인 DBLINK_ENCRYPT_LOGIN은 암호화된 패스워드를 사용하 여 원격지의 오라클 DB에 접속하는 파라미터이다.
오라클 7.2 버전 전에는 네트워크를 통해 패스워드가 전달될 때 암호화되지 않았다. 오래 된 서버에 연결하는 수단으로 오라클은 연결이 실패된 서버에 대해 암호화되지 않은 패스 워드를 사용하여 재연결을 시도할 때 이 파라미터를 사용한다. 만약, DBLINK_ENCRYPT_LOGIN 파라미터가 TRUE이면 커넥션은 실패할 것이고 다 시 연결을 시도하지 않는다. 만약 이 파라미터가 FALSE이면 처음 연결은 실패할 것이지 만, 오라클은 계속해서 암호화되지 않은 패스워드를 사용하여 연결을 시도할 것이다. DBLIKE_ENCRYPT_LOGIN 파라미터가 FALSE로 설정된 서버는 링크된 서버 사이에 암호화된 패스워드를 주고 받는다. 오라클 9i이후의 버전에서 이 파라미터는 TRUE로 기 본 설정되어 있다. 이 파라미터를 오라클 9i의 init.ora 파일에 추가하면, 에러 메시지들 을 볼 수 있다.
다음은 DBLINK_ENCRYPT_LOGIN의 파라미터 값이 'TRUE'인지를 확인하는 스크립트이다.

사. 환경설정

1) Audit Table Ownership

Audit Table은 SYS, SYSTEM 또는 이와 유사하게 보호받고 제한되고 접근이 문서화되 어 있는 DB 계정의 소유이어야 한다. Audit Table Ownership은 Audit Table에 비인가 된 접근을 막는데 도움을 준다.
Audit Table 소유자 계정이 단지 ISSO에서 리스트된 인가된 사용자로 제한되고 있는지 DBA에게 알아본다. 아울러, Audit Table 소유자 계정이 Audit Data의 검토 및 유지보 수 이외의 접근을 차단하고 있는지도 확인한다.

앞의 스크립트를 수행한 결과값이 'DB' 가 아니면 Audit Table을 사용하지 않는 것이다. 만약, 결과값이 'DB'이면 다음 스크립트를 실행한다.

앞의 스크립트를 수행한 결과, 리스트 된 소유자 계정이 'SYS' 또는 'SYSTEM' 이 아니라 면 해당 계정에 대해 검증한다.

2) Oracle Instance Names

DB 인스턴스 이름에 버전 숫자를 사용하는 것은 차후의 업그레이드에 있어 인스턴스 이름 의 사용을 제한하게 된다. 운용 DB의 DB 인스턴스 이름의 변경은 불필요한 관리적 부하 를 야기할 수 있고 보안 네트워크 설정에 침해가 발생할 수 있다. 다음은 결과값의 첫 부분이 숫자이거나 혹은 오라클의 릴리즈 번호인지를 확인하는 스크 립트이다.

3) Oracle Control Files

Control Files는 DB의 물리적 상태를 정의하는 바이너리 형식의 파일로 다음과 같은 정 보가 저장되어 있다.
■DB 명(SID : System ID)
■DB 파일과 REDO 로그파일명
■현 로그 순서 번호(Log Sequence number)
■체크 포인트 정보
Control Files가 손상되면 DB의 기동이 불가능하다. 여러 개의 컨트롤 파일(물론 각각의 내용은 동일하다.)을 지정하여 손상에 대비하는 것이 일반적이다. 하나의 물리적 디스크 나 RAID 디스크상에는 하나의 오라클 Control 파일이 존재한다. 따라서, 물리적으로 분 리된 여러 개의 디스크에 오라클 Control 파일을 준비하는 것이 필요하다. 다음을 통해 물리적으로 분리된 두개 이상의 디스크에 오라클 Control 파일이 있는지 확 인할 수 있다.

4) Oracle Redo Log Files

두 개 이상의 Redo Log 파일이 있는 Oracle Redo Log 그룹을 둘 이상 생성하는 것은 바 람직하지 않다. 다음을 통해 오라클 Redo Log 그룹이 둘 이상 나오는지 확인할 수 있다.

5) SQL*Plus HOST Command

SQL*PLUS에서는 OS의 명령어를 사용할 수 있다. 따라서, HOST 명령어는 권한이 있 는 사용자로 제한해야 한다. 다음은 SQL*PLUS에서 OS 명령어의 실행이 인가된 사용자로 제한되어 있는지 확인하는 스크립트이다.

6) Audit Trail Location

오라클의 감사는 DB 또는 OS 파일의 감사 자료를 기록하도록 설정할 수 있다. DB에 대해 서 기록된 이벤트들은 뷰를 통해 OS 사용자에게 제공된다. Audit를 사용하는 경우에 audit_trail의 값은 TRUE, DB, OS로 설정되어야 하며 NONE 으로 설정하면 audit_trail을 사용하지 않게 된다. 다음을 통해 audit_trail의 값이 NONE인지를 확인한다. 만약, 파라미터값을 변경하면 DB를 재실행해야 한다.

7) Audit Table Permissions

Audit Table에 대한 권한은 Audit Table에 접근하는 계정들을 제한한다. 과도한 권한의 부여는 Audit Trail Data를 함부로 수정할 수 있게 된다. 계정들에게 단지 Audit Data 가 저장된 테이블(SYS.AUD$)에서 select, insert, delete 또는 update 기능을 수행할 수 있는 권한이 부여되었는지 점검해야 한다.
다음 스크립트를 통해 리스트된 계정들이 인가된 DBA 계정들인지 또는 제 3의 Audit 모 니터링 계정 문서에 등록되었는지를 확인할 수 있다.

8) Idle Time Resource Usage Limit

Idle Time Resource 사용 설정은 하나의 세션에서 허용될 수 있는 최대 Idle Time을 제 한해야 한다. Idle Time은 하나의 세션에서 비활성 시간(분으로 표시)의 간격이다. 실행 시간이 긴 쿼리나 다른 작업들은 이러한 제한이 필요하지 않다. Idle Time Resource Usage 제한 설정은 사용자가 그들의 자리에서 이탈할 때 애플리케이션을 열어두는 것을 막는다.
다음의 스크립트를 통해 리스트 된 Idle time이 60분 이상으로 나오면 애플리케이션 사용 자에게 어떤 프로필이 할당되었는지 확인할 수 있다.

9) Failed Login Attempts

FAILED_LOGIN_ATTEMPTS 값은 로긴 시도의 횟수를 제한하는 값으로 제한된 로긴 시도횟수 이후에는 계정이 잠기게 된다. 이 값을 설정함으로써 비인가된 사용자가 패스워 드를 추측하게 하는 것을 방지할 수 있다.
다음 스크립트를 통해 FAILED_LOGIN_ATTEMPTS의 값이 UNLIMITED나 NULL로 설정되어 있는지 확인할 수 있다.

10) Trusting Remote OS Authentication Setting

REMOTE_OS_AUTHENT 값이 TRUE로 설정되어 있으면 안전하지 않는 커넥션을 통한 원격지의 OS의 인증을 허용한다. 원격지 OS를 신뢰하는 것은 원격지 OS의 사용자인 것 처럼 속이는 사용자를 허용할 수 있으며 또한, 패스워드 없이 DB에 접근을 허용한다. 따 라서, 설정 값은 FALSE로 설정해야 한다. 만약, 설정 값을 변경하게 되면 DB를 재시동 해야 한다.
다음 스크립트를 통해 REMOTE_OS_AUTHENT 값이 FALSE인지 확인할 수 있다.

11) Trusting Remote OS for Roles Setting

REMOTE_OS_ROLES가 TRUE이면 OS의 그룹들이 오라클의 롤을 조절할 수 있다. 만 약, FALSE 값이면 롤은 DB 시스템에 의해 관리되고 인식된다. REMOTE_ OS_ROLE이 TRUE로 설정된다면 원격 사용자는 네트워크가 연결된 상태에서 다른 OS 사용자 역할을 할 수 있다. 따라서, REMOTE_OS_ROLES의 값은 FALSE로 설정되어야 한다. 다음 스크립트를 통해 REMOTE_OS_ROLES의 값이 FALSE인지 확인할 수 있다.

12) Oracle SQL92_SECURITY

SQL92_SECURITY 파라미터의 설정은 해당 참조 테이블 열값의 갱신 또는 삭제를 실행 하는 데 테이블 수준 SELECT 권한이 필요한지 여부를 지정한다. 만약, 이 옵션이 TRUE 로 설정되어 있으면 갱신 권한이 실행될 때 SELECT 권한을 사용할 수 있다. 다음 스크립트를 통해 SQL92_SECURITY가 TRUE로 설정되어 있는지 확인할 수 있다.

13) UTL_FILE_DIR Setting

UTL_FILE 패키지는 오라클 DB 프? 허용 한다. 이 패키지가 사용할 수 있는 모든 파일들은 데이터 베이스의 UTL_FILE 실행 권한 이 있는 어떠한 DB 사용자도 사용할 수 있기 때문에 주의해서 사용해야 한다. UTL_FILE_DIR 값이 '*'로 설정되어 있으면 오라클 DB 프로세스는 UTL_FILE 패키지 를 통해 모든 디렉토리에 접근할 수 있다. UTL_FILE_DIR 리스트는 보호해야 할 디렉토 리와 권한을 부여해야 할 디렉토리를 명확히 기술해야하며 경로명을 전부 포함해서는 안 된다.
UTL_FILE PACKAGE를 통해 모든 디렉토리에 대해 읽고 쓰기가 가능하도록 설정되어 있는지 확인한다. 만약, 결과값으로 '*'가 나오면 모든 디렉토리가 접근 가능한 것이므로 설정을 변경해야 한다.

14) Data Dictionary Accessibility

SELECT ANY TABLE 권한을 갖는 계정이 암호화된 패스워드와 같은 Data Dictionary Table에 있는 중요한 데이터에 접근을 제한하고 있는지를 확인한다. 이 기능은 오라클 8에서 07_DICTIONARY_ACCESSIBILITY 파라미터를 통해 제공된 다. 만약, 이 파라미터 값이 FALSE이면 Data Dictionary 내에 있는 민감한 정보에 접근 하는 것을 제한한다.
다음 스크립트를 통해 07_DICTIONARY_ACCESSIBILITY 값이 FALSE인지를 확인할수 있다.

15) Database Link Permissions

Database Link 패스워드는 SYS.LINK$ 테이블에 암호화되지 않은 상태로 저장이 되는 데, 이 테이블에 대한 접근은 제한되어야 한다.
이를 위해 다음 스크립트의 수행 결과값이 있는지를 확인한다.

16) Resource Limits Not Enabled

RESOURCE_LIMIT 파라미터는 DB 프로파일에 리소스 제한의 강제 수행 여부를 결정한 다. FALSE값으로 설정하면 리소스 제한의 강제 적용을 비활성화하고, TRUE값으로 설 정하면 리소스 제한의 강제 적용을 활성화한다. RESOURCE_LIMIT 파라미터의 기본값 은 FALSE이다. 이 값은 패스워드 리소스에는 적용되지 않는다.
다음 스크립트를 통해 RESOURCE_LIMIT 의 설정이 'TRUE'로 설정되어 있는지를 확인 할 수 있다.

17) Current Oracle Version

다음은 현재 DB 시스템의 버전을 확인하는 스크립트이다.

0004. 취약점 분석 운영

4. DB 취약점 분석 운영

가. 취약점 수집

기존 네트워크나 애플리케이션 취약점 분석 솔루션은 네트워크와 OS 보안에 있어 효과적 일 수 있지만 DB 취약점에 대한 정보를 제공하고 있지 않는다. 따라서, DB 취약점 분석에 서는 DB 취약점을 수집하여 DB 계층에 존재하는 서비스 거부 공격, Misconfigurations, 알려진 취약성 경고, 패스워드 공격 취약성 등과 같은 보안 사항을 다루어야만 한다. DB 취약점은 DBMS 벤더사나 컴퓨터 침해 사고 대응단(CERT, Computer Emergency Response Team)에 의해 공개되거나 혹은 악의적 의사를 가진 해커들에 의해 공유되고 있다. 이렇게 발표되는 취약점은 사실상 공개적으로 노출된 것이기 때문에 발표된 취약점 만을 대응하는 DB가 대응시점이 늦었다면 즉시 공격 위험에 노출 될 수 있다.
대표적인 DB 취약점인 버퍼 오버플로(Buffer Overflow) 공격은 그 종류가 매우 다양하 며 애플리케이션과 DB 레벨 내에 발생된다. 이러한 버퍼 오버플로의 가능성은 취약점으 로 분류하여 관리해야 한다.
취약점이란 실행되지 않도록 의도된 애플리케이션이 비인가 유저에 의해 실행되도록 하는 모든 시도 및 그 공격들로 정의된다. 애플리케이션 내 취약점들은 대개 프로그래밍 에러를 발생시키며, 특히 개발자들은 종종 gets(), printf() 등과 같은 함수를 사용함에 있어 그 보안상의 의미를 잘 모르고 있는데 많은 개발코드들이 애플리케이션 보안 취약점들이 잘 알려지기 이전에 만들어졌기 때문이다. 가장 위험한 취약점은 비인증 유저의 Aribitray 명령의 수행을 허용하는 것이다. 아무리 패스워드 및 인증 관리가 강화된다고 하더라도 이 러한 취약점을 이용하여 우회적으로 공격할 수 있다.

나. 취약점 제거

DB 취약점은 단순한 네트워크나 애플리케이션 취약점에 의해 서비스가 중지되는 수준이 아니라 개인정보보호 차원과 기업 기밀보호 차원에서 매우 중요한 관리 요소가 된다. 하지 만 여기서 고려해야 할 사항은 DB는 특성상 IT 인프라 내의 상시 운영시스템으로서 DB 취약점 제거를 위해 DB의 가동을 중지하기란 쉽지 않다는 것이다. 취약점의 성격과 위험 등급에 따라 단순한 Fix Script로서 취약점을 제거할 수 있는 가벼운 것도 있지만, DB의 패치(Patch)를 통해 취약점을 제거해야 하는 경우도 생기게 된다. 때때로, 이러한 패치작 업은 여러가지 오류로 인해 DB 재가동이 어렵게 되는 경우도 발생하게 되므로, DB 취약 점 제거를 위해 패치를 적용하는 경우에는 해당 벤더사 엔지니어의 조언이 필요하게 된다.

다. 취약점 개선 분석 비교

새로운 DB 취약점은 발표시기에 대한 예정이 없기 때문에 취약점 분석은 자주 하는 것이 바람직하다. 예를 들어, 지난 달에 DB 취약점 분석과 제거 작업을 수행하였지만 그사이 새로운 취약점 발표와 함께 공격 위험에 노출 될 수 있다. 사실상 DB 취약점 분석은 빠른 시간 안에 수행할 수 있지만 취약점 제거에 소요되는 노력과 시간은 만만치가 않다. 하지 만, 가능하다면 잦은 주기마다 취약점을 분석하여 새로운 취약점 발견과 기존 취약점의 제 거의 확인에 노력을 기울어야 한다.

0003. 취약점 분석 구축

3. DB 취약점 분석 구축

가. 모의 해킹 (Penetration Test)

DB 모의해킹(Database Penetration Test)란 DB 계정을 소유하지 않은 외부 사용자에 의한 DB 침해공격을 시뮬레이션(Simulation)하는 행위를 의미한다. 통해 취약점을 검출 하거나 수집된 취약점 지식 DB를 통해 외부공격자의 침투가능 경로를 검출할 수 있다.
모의해킹(Penetration Test)의 주요 점검 항목은 다음과 같다.
■DB 서비스 프로세스의 여부 점검
■DB의 패스워드를 Brute Forcing, Dictionary Attack, Password Cracking 기법을 통해 안전하지 못한 DB 패스워드 추출 여부 점검
■버퍼 오버플로 공격에 대한 DB 서비스 오동작 여부 점검
■Dos(Denial of Service) 공격에 대한 DB 다운이나 서비스 불가 요부 점검
■DB의 비정상 설정으로 인한 비정상 침투 경로 존재 여부 점검

나. 내부 보안감사(Security Auditing)

DB 내부 보안감사(Database Security Auditing)는 알려진 취약점과 더불어 DB가 보안상 안전하게 설치되고 운영되는가를 점검하고, 더불어 DB를 구성하는 File, Table Space, OS, Role, Grant 등의 다각적 보안 검토를 의미한다. 내부 보안감사 (Security Auditing) 에서의 주요 점검 항목은 다음과 같다.
■패스워드를 포함하는 Database User Account 정보
■모든 Profile과 각 Profile의 Resource 정보
■DB User의 다른 Role에 부여된 Role 정보
■Database 내의 모든 Role에 대한 상세 정보
■Database User의 다른 Role에 부여된 System Role 정보
■Database User에게 부여된 System 권한 정보
■Database 프로세스와 세션 정보

다. Oracle DB 취약점 점검 리스트

라. IBM DB2 Database 취약점 점검 리스트

마. Microsoft SQL Server Database 취약점 점검 리스트

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

0001. 취약점 분석 개요

1.DB 취약점 분석 개요

DB 보안은 외부 혹은 내부자로부터 개인 또는 조직의 주요기밀 정보 유출에 대한 방어를 목적으로 한다. DB 보안의 위협들은 사용자의 실수, 오용, 내부자의 권한 남용, DB에 대 한 알려진 취약점 등으로부터 기인하게 된다. 오늘날 정보자산은 무형의 자산에 그치지 않 고 실질적인 재화이다. 이러한 정보자산 가치의 증대로 인하여 주요 정보가 집중되어 있는 DB에 대한 위협은 날로 증가하고 있다.

DB 침해사고는 외부의 해커, 인가된 내부 사용자, 인가되지 않은 내부 사용자 등 모든 범 위에서 발생할 수 있다. DB는 정보시스템의 가장 깊은 곳에서 운영되지만 웹 애플리케이 션(Web Application), 내부망(Internal Network), 파트너 연계 네트워크 등 수 많은 접 근점의 존재로 인해 데이터 유출 위험이나 서비스 중지의 위험이 상시적으로 존재한다.
DB 취약점의 유형은 다음과 같다.
■Admin 권한이 아닌 일반 권한을 가진 DB 계정이 단 하나의 SQL 명령으로 Admin 권 한을 획득 한다면?
■DB 계정이 없는 사용자의 DoS공격에 의해 고객 및 금융 업무를 운영하는 DB가 갑자기 중지된다면?
■DBMS 내부에 DBA도 모르는 내부 함수(Internal Function)로 인해 DB가 손상된다면?
■다른 소유주의 테이블(Table)이 남모르게 접근 가능하다면?
앞의 취약점들은 다음의 대표적인 DB 취약점을 통해 공격받을 수 있다.
■디폴트(Default) 패스워드 및 보안상 안전하지 못한 약한 패스워드
■권한의 남용(모든 권한은 꼭 필요한 최소한의 권한으로 운영되어야 한다.)
■버퍼 오버플로(Buffer overflow)나 형식문자열(Format String)과 같은 알려진 취약 점들
■네트워크를 통한 취약점들
■DB 및 시스템 파일에 대한 불법 열람 및 변조
■SQL 주입공격(Injection )
■DB 서비스를 중단시킬 수 있는 서비스 거부(Denial of Service)와 같은 위협들 문제는 이러한 DB 취약점들이 DBMS 제조사나 해커들에 의해 항상 공개가 된다는 것이 다. 이렇게 공개된 DB 취약점들을 통해 DB는 쉽게 공격 대상으로 주목된다. DB 취약점 분석은 DB에 내재된 취약점들과 DB 운영에 있어서 고려되어야 할 항목들을 다각도에서 구체적으로 점검함으로써 보안 관리자 및 DBA에게 시스템에 내재된 안전 취 약점(Security Hole)을 제거하게 하여 DB의 보안 수준을 향상시키게 한다.
DB 취약점 분석 솔루션은 점검대상 네트워크 범위에 존재하는 정보자산을 파악하는 정보 수집(Information Gathering), DB 보안을 검증할 수 있는 모의해킹(Penetration Test), 내부 보안감사(Security Auditing) 등의 과정을 통해 다양한 DB 취약점들을 도출 하여 DB의 전체 보안 수준의 향상을 도모한다.
DB 취약점 분석은 정보 자산의 파악과 보안성의 검토, 검출된 취약점 제거를 위한 Fix Scripts 및 개선안 제시, 레포팅 등을 주요 항목으로 한다.

결국 DB 취약점(Database Vulnerabilities)은 DB 보안을 위해 반드시 점검해야 할 항목 이라고 할 수 있다.