DB보안
DA, SQL, DB보안 등 실무자를 위한 위한 DB기술 바이블!
모든 DBA는 오라클이 안정적으로 운영되고 문제발생 시에 해당 원인을 찾아 신속히 대처 해야 할 임무를 갖는다. 이를 위해서 사전에 발생할 수 있는 문제들이 어떠한 것이 있는지 파악하고 있어야 하며, 일단 문제가 발생하였을 경우 오라클 운영 환경을 점검하여 빠른 시간 내에 문제를 해결할 수 있어야 한다. 1) 백업 오라클 DB를 구성하는 파일들은 Control 파일, Online Redo Log 파일, Archive Log 파일, Data 파일 등으로 나누어진다. 각각의 파일들은 DB 운영을 위해 중요한 정보들을 포함하고 있으므로 수시로 상태를 점검하여야 한다. .Data 파일과 Redo Log 파일의 추가나 삭제 등의 원인으로 DB에 변경사항이 있을 때마다 백업 받도록 한다. Hot Backup시에는 Archive Log 파일이 Backup되었으면 Online Redo Log는 백업받을 필요가 없다. 생성되는 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를 구별하여 관리하도 록 한다. ARCH Process가 움직이는지를 자주 확인한다. 이렇게 하면ARCH Process가 움 직이지 않아서 DB가 Hang이 걸리는 문제를 막을 수 있다. 오라클 DB를 구성하는 Tablespace에는 System Tablespace, Rollback Segment Tablespace, Data Tablespace, Temporary Tablespace 등이 있다. 각 Tablespace 는 Data를 저장하는 논리적인 공간이며, 앞에서 다룬 OS 상의 DB 관련 파일들과 긴밀하 게 연관되어 있다. 3) DATA TABLESPACE 오라클 DB는 OS 상에서 동작하기 때문에 안정적인 운영을 위해서 OS의 상태를 점검하는 것은 필수적이다. 또한, 리스너와 같은 오라클 Process들의 작동상태를 수시로 점검하여 애플리케이션 운영에 차질이 없도록 해야 한다. 1) Unauthorized Object Owner 2) Active Schema Owner Account 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 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 권한을 특정 애플리케이션 사용자 그룹에 할당하기 위해 사용된다. 7) SYSDBA Privilege Assignments 8) System Privilege Assignments 9) DBA Includes Non-default Account 10) With Grant Option 11) Role Permissions 12) Restricted PL/SQL Packages 13) Privileges Granted With Admin 14) PUBLIC System Privileges 15) Roles Granted With Admin 16) Replication Account Use ■Replication을 위해 Replication Administrator, Replication Propagator, Replication Receiver 3가지 롤 형태가 있다. 일반적으로 모든 롤은 단일 사용자 계정 에 의해 수행된다. ■Replication 계정(Default는 REPADMIN, 변경가능)이 단지 ISSO에서 리스트된 인 가된 사용자로 제한되어 있는지 DBA와 인터뷰한다. 그렇지 않다면 Finding이다. 그리 고 하나 이상의 계정이 있는 경우에는 해당 계정들이 공정한지를 확인한다. 17) Database Demonstration Objects 18) Account Permissions 19) Default Accounts and Passwords 1) Password Life Time 2) Password Reuse PASSWORD_REUSE_MAX값은 패스워드를 다시 사용하기 전에 패스워드를 바꿔야 하는 횟수를 나타낸다. 3) Password Verify Function 4) REMOTE_LOGIN_PASSWORDFILE 5) Database Link Password Encryption 사. 환경설정 1) Audit Table Ownership 앞의 스크립트를 수행한 결과값이 'DB' 가 아니면 Audit Table을 사용하지 않는 것이다. 만약, 결과값이 'DB'이면 다음 스크립트를 실행한다. 앞의 스크립트를 수행한 결과, 리스트 된 소유자 계정이 'SYS' 또는 'SYSTEM' 이 아니라 면 해당 계정에 대해 검증한다. 3) Oracle Control Files 4) Oracle Redo Log Files 5) SQL*Plus HOST Command 6) Audit Trail Location 7) Audit Table Permissions 8) Idle Time Resource Usage Limit 9) Failed Login Attempts 10) Trusting Remote OS Authentication Setting 11) Trusting Remote OS for Roles Setting 12) Oracle SQL92_SECURITY 13) UTL_FILE_DIR Setting 14) Data Dictionary Accessibility 15) Database Link Permissions 16) Resource Limits Not Enabled 17) Current Oracle VersionDB 취약점 체크리스트(Oracle 기반)
5. DB 취약점 체크리스트(Oracle 기반)
가. Database
■백업(Backup)에 사용될 테이프와 같은 장비상태가 불안정하다고 판단될 때는 절대로 사용하지 말아야 한다. 또한, 백업된 정보는 즉시 확인할 수 있어야 한다. 즉, 어느 파 일이 어느 백업 위치에 있는지 바로 알 수 있어야 것이다.
■시스템 가동 시점에서 백업 절차 전체에 대한 테스트를 수행한 후, 해당 결과를 확인하 여 변경할 사항들이 있는지 확인하여야 한다.
■백업 되는 파일 이름은 날짜, 업무 등의 정보를 포함시켜서 나중에 보더라도 알기 쉽도 록 지정한다.
■3개월 단위마다 정기적으로 백업을 이용한 복구 테스트(Recovery Test)를 실시한다.
■가장 최신의 오라클 패치를 적용하여 시스템이 안정적으로 운영될 수 있도록 해야 한다.
■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
■ 백업
정기적으로 백업을 받도록 한다. Cold Backup일 경우에는 Control 파일자체를 복 사하여 백업을 받고 DB가 운영중일 경우는 다음 명령어를 이용하여 파일을 백업받 도록 한다.
.백업받은 파일 이름에 날짜와 업무정보 등을 포함시켜 쉽게 알아볼 수 있도록 한다.
■ 설정
.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를 백업 받으면 된다.
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되는 위치가 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를 변경할 수 있다.
다. 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 사용을 지정할 수 있다.
■ 백업
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에 설정되어 있는 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상태인지 확인하려면 다 음의 명령어를 사용할 수 있다.
마. 권한 관리
또한, DB 관리자 계정은 매일 반복되는 특별한 작업에 대해 할당해서는 안된다. 인가된 DBA 계정 리스트나 ISSO에서 제공하는 인가된 DBA 리스트를 얻기 위해서 D03440을 살펴 봐야 한다. DB 관리자간의 상호연동을 위해 각 DBA에 할당된 임의의 DBA 계정은 무관하지만 임의의 다른 계정들의 리스트가 있는지를 확인한다. 다음은 이를 위한 스크립트이다.
다음 스크립트의 실행 결과로 리스트된 모든 계정들이 인가된 DBA 계정인지와 애플리케 이션 개발자 계정이 아닌지를 확인하기 위해서 운용 DB 시스템상에서 Create, Alter, 또 는 Drop Privilege가 부여된 계정 및 Role의 리스트를 확인한다.
다음 스크립트의 실행 결과로 리스트 된 계정에 대해 인가가 되었는지를 확인해야 한다.
다음 스크립트의 결과값을 통해 Public으로 부여된 Role을 확인할 수있다.
인가된 DBA 계정 이외에 SYSDBA 권한을 가진 계정의 인가여부를 확인한다.
다음
시스템 권한은 DB와 DB 오브젝트에 대한 광범위한 변경을 허용한다. 변경 작업에는 테이 블, 뷰, 롤백 세그먼트, 그리고 프로시저의 생성, 삭제, 수정이 해당된다. 이러한 시스템 권한은 DBA나 인가된 사용자 계정에게 제한해서 부여해야 한다.
이를 위해 시스템 권한이 부여된 DBA가 아닌 계정과 Role의 리스트를 검토해야 한다. 또 한, 운용 DB상에서 Create User, Alter User, Drop User가 리스트되는 임의의 계정이 인가된 애플리케이션 관리 롤에 포함되어 있는지를 확인해야 한다. 개발 시스템에서는 개 발자에게 할당된 시스템 권한이 ISSO에 의해 공정하고 인가되었는지를 확인해야 한다. 다음 스크립트의 실행 결과를 통해 비인가된 사용자 계정이나 애플리케이션 사용자 롤이 있는지 확인한다.
다음은 인가된 DBA 계정을 확인하는 스크립트이다.
다음은 UTL_FILE, UTL_SMTP, UTL_TCP, UTL_HTTP, and DBMS_RANDOM PL/SQL 패키지가 PUBLIC에게 EXECUTE 권한이 부여되었는지 확인하기 위한 스크립 트이다.
다음은 PUBLIC 계정에 시스템 권한을 부여되었는지를 확인하는 스크립트이다.
■기본 계정 중에 연결이 되는 계정이 있는지 확인해야 하며 발견된 기본 계정에 대해 DBA와 인터뷰해야 한다.
바. 패스워드 관리
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 값이 설정되어 있는지를 확인한 후 각 값이 허용치를 넘지 않았는지를 확인한다. 다음은 이를 위한 스크립트들이다.
다음 스크립트를 통해 REMOTE_LOGIN_PASSWORDFILE의 값이 EXCLUSIVE로 설 정되었는지를 확인한다.
오라클 7.2 버전 전에는 네트워크를 통해 패스워드가 전달될 때 암호화되지 않았다. 오래 된 서버에 연결하는 수단으로 오라클은 연결이 실패된 서버에 대해 암호화되지 않은 패스 워드를 사용하여 재연결을 시도할 때 이 파라미터를 사용한다. 만약, DBLINK_ENCRYPT_LOGIN 파라미터가 TRUE이면 커넥션은 실패할 것이고 다 시 연결을 시도하지 않는다. 만약 이 파라미터가 FALSE이면 처음 연결은 실패할 것이지 만, 오라클은 계속해서 암호화되지 않은 패스워드를 사용하여 연결을 시도할 것이다. DBLIKE_ENCRYPT_LOGIN 파라미터가 FALSE로 설정된 서버는 링크된 서버 사이에 암호화된 패스워드를 주고 받는다. 오라클 9i이후의 버전에서 이 파라미터는 TRUE로 기 본 설정되어 있다. 이 파라미터를 오라클 9i의 init.ora 파일에 추가하면, 에러 메시지들 을 볼 수 있다.
다음은 DBLINK_ENCRYPT_LOGIN의 파라미터 값이 'TRUE'인지를 확인하는 스크립트이다.
Audit Table 소유자 계정이 단지 ISSO에서 리스트된 인가된 사용자로 제한되고 있는지 DBA에게 알아본다. 아울러, Audit Table 소유자 계정이 Audit Data의 검토 및 유지보 수 이외의 접근을 차단하고 있는지도 확인한다.
DB 인스턴스 이름에 버전 숫자를 사용하는 것은 차후의 업그레이드에 있어 인스턴스 이름 의 사용을 제한하게 된다. 운용 DB의 DB 인스턴스 이름의 변경은 불필요한 관리적 부하 를 야기할 수 있고 보안 네트워크 설정에 침해가 발생할 수 있다. 다음은 결과값의 첫 부분이 숫자이거나 혹은 오라클의 릴리즈 번호인지를 확인하는 스크 립트이다.
■DB 명(SID : System ID)
■DB 파일과 REDO 로그파일명
■현 로그 순서 번호(Log Sequence number)
■체크 포인트 정보
Control Files가 손상되면 DB의 기동이 불가능하다. 여러 개의 컨트롤 파일(물론 각각의 내용은 동일하다.)을 지정하여 손상에 대비하는 것이 일반적이다. 하나의 물리적 디스크 나 RAID 디스크상에는 하나의 오라클 Control 파일이 존재한다. 따라서, 물리적으로 분 리된 여러 개의 디스크에 오라클 Control 파일을 준비하는 것이 필요하다. 다음을 통해 물리적으로 분리된 두개 이상의 디스크에 오라클 Control 파일이 있는지 확 인할 수 있다.
다음 스크립트를 통해 리스트된 계정들이 인가된 DBA 계정들인지 또는 제 3의 Audit 모 니터링 계정 문서에 등록되었는지를 확인할 수 있다.
다음의 스크립트를 통해 리스트 된 Idle time이 60분 이상으로 나오면 애플리케이션 사용 자에게 어떤 프로필이 할당되었는지 확인할 수 있다.
다음 스크립트를 통해 FAILED_LOGIN_ATTEMPTS의 값이 UNLIMITED나 NULL로 설정되어 있는지 확인할 수 있다.
다음 스크립트를 통해 REMOTE_OS_AUTHENT 값이 FALSE인지 확인할 수 있다.
UTL_FILE PACKAGE를 통해 모든 디렉토리에 대해 읽고 쓰기가 가능하도록 설정되어 있는지 확인한다. 만약, 결과값으로 '*'가 나오면 모든 디렉토리가 접근 가능한 것이므로 설정을 변경해야 한다.
다음 스크립트를 통해 07_DICTIONARY_ACCESSIBILITY 값이 FALSE인지를 확인할수 있다.
이를 위해 다음 스크립트의 수행 결과값이 있는지를 확인한다.
다음 스크립트를 통해 RESOURCE_LIMIT 의 설정이 'TRUE'로 설정되어 있는지를 확인 할 수 있다.