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 권한을 가진 계정의 인가여부를 확인한다.
다음

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 시스템의 버전을 확인하는 스크립트이다.