오라클 KISA 접근관리 11~15번: 확인 SQL과 조치 방법 정리

DB 보안 점검 · 접근관리

오라클 KISA 접근관리 11~15번: 확인 방법과 조치 방법(SQL/설정)

아래는 KISA 점검표 중 11~15번(D-11~D-15)을 대상으로, 확인 SQL(점검)과 조치 방법(권고)을 운영 적용 관점에서 정리한 내용이다. 접근관리 항목 특성상 DB 내부 SQL뿐 아니라 리스너/OS 파일 권한 점검이 함께 필요하다.

범위: D-11 ~ D-15 · 대상: Oracle 접근 통제/리스너/파일 권한

공통 전제

운영 환경에서는
“권한 회수/리스너 정책 변경/파일 권한 변경”이 서비스 영향으로 이어질 수 있다.
적용 전 반드시 테스트 환경 선적용 → 운영 반영 순으로 진행하고, 변경 이력(누가/언제/무엇을)을 남긴다.

• 주요 뷰: DBA_TAB_PRIVS, DBA_ROLE_PRIVS, DBA_SYS_PRIVS, V$SESSION
• 리스너/네트워크 설정: listener.ora, sqlnet.ora, tnsnames.ora (경로는 환경별 상이)

D-11 DBA 이외 인가되지 않은 사용자의 시스템 테이블 접근 차단(상/3)

시스템 테이블/데이터사전(예: SYS 스키마, 딕셔너리 뷰)은 민감도가 높다. 불필요한 권한(특히 PUBLIC 또는 과다 롤 부여)이 존재하면 정보 노출 및 권한 상승의 발판이 될 수 있다.

확인 방법(SQL)

-- 1) SYS 스키마 오브젝트에 대한 직접 권한 부여 현황(대표 점검)
SELECT grantee, owner, table_name, privilege
FROM dba_tab_privs
WHERE owner = 'SYS'
  AND grantee NOT IN ('SYS','SYSTEM')
ORDER BY grantee, table_name, privilege;

-- 2) PUBLIC에 과도한 권한이 부여되어 있는지 점검
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
  AND owner IN ('SYS','SYSTEM')
ORDER BY owner, table_name, privilege;

-- 3) 딕셔너리 접근 관련 강한 권한 점검(환경별로 필요 권한만 허용)
SELECT grantee, privilege, admin_option
FROM dba_sys_privs
WHERE privilege IN ('SELECT ANY DICTIONARY','SELECT ANY TABLE','EXECUTE ANY PROCEDURE')
ORDER BY grantee, privilege;

조치 방법(SQL 예시)

-- 1) 불필요한 권한 회수(정확한 대상 오브젝트/권한 확인 후 진행)
REVOKE SELECT ON SYS.SOME_TABLE FROM SOME_USER;

-- 2) PUBLIC 권한 회수(업무 영향도 검토 필수)
REVOKE SELECT ON SYS.SOME_TABLE FROM PUBLIC;

-- 3) 과다한 시스템 권한 회수(필요 최소만 남기기)
REVOKE SELECT ANY DICTIONARY FROM SOME_USER;

* “무조건 회수”가 아니라, 실제 사용 여부(배치/모니터링/백업/진단툴)를 확인한 뒤 대체 권한(최소 권한)으로 재설계하는 것이 안전하다.

D-12 안전한 리스너 비밀번호 설정 및 사용(상/3)

리스너 관리 인터페이스가 노출되거나 약하게 보호되면, 서비스 교란/정보 노출 위험이 커진다. 리스너 보안은 SQL만으로 끝나지 않으며, 리스너 설정과 관리 접근 통제가 핵심이다.

확인 방법(운영 점검)

# 리스너 상태/설정 확인(서버에서 실행)
lsnrctl status

# 리스너 관리 접근 경로가 외부에 열려있는지 점검(방화벽/보안그룹)
# - DB 포트(예: 1521) 노출 여부
# - 관리망/VPN/Bastion 경유 여부

-- (보조) 현재 접속 프로그램 분포로 원격 노출 징후 확인(정확한 판별은 네트워크 점검 필요)
SELECT machine, program, COUNT(*) AS session_cnt
FROM v$session
WHERE username IS NOT NULL
GROUP BY machine, program
ORDER BY session_cnt DESC;

조치 방법(권고)

# 1) 네트워크 통제가 1순위
# - 리스너 포트(1521 등) 인터넷 직접 노출 금지
# - 허용 IP/대역만 관리망에서 접근
# - Bastion/VPN 경유, MFA 적용(가능 시)

# 2) 리스너/네트워크 설정 보강(환경 정책에 맞게)
# - listener.ora / sqlnet.ora에서 허용 노드/보안 옵션 적용 여부 검토
# - 관리 명령 접근을 최소화(관리자만 수행)

# 3) 설정 변경 후 리스너 재기동/검증 절차 수립
# lsnrctl reload
# lsnrctl stop / start

D-13 불필요한 ODBC/OLE-DB 데이터 소스·드라이브 제거(중/2)

불필요한 드라이버/데이터 소스는 공격면을 넓힌다. DB 자체보다는 서버 OS의 구성요소 정리 성격이 강하다.

확인 방법(운영 점검)

# Windows(예시)
# - ODBC 데이터 소스 관리자(시스템 DSN/사용자 DSN)
# - 설치된 OLE DB Provider 목록(프로그램/기능)

# Linux(예시)
# - unixODBC, freetds 등 설치 패키지 목록 확인
#   rpm -qa | egrep "odbc|oledb|freetds|unixODBC"
#   dpkg -l | egrep "odbc|oledb|freetds|unixodbc"

-- (보조) DB 링크/외부 연결 사용 여부를 간접 확인(환경에 따라 존재)
SELECT owner, db_link, username, host
FROM dba_db_links
ORDER BY owner, db_link;

조치 방법(권고)

# 1) 미사용 드라이버/DSN 제거(표준 소프트웨어 목록 기준)
# 2) 꼭 필요한 경우에도 사용 범위(계정/호스트/접속 구간)를 제한
# 3) 변경 후 연동 서비스(배치/리포트/ETL) 정상 동작 확인

D-14 주요 설정파일·패스워드 파일 등 접근 권한 적정화(중/2)

spfile, init.ora, 패스워드 파일(예: orapw<SID>), 네트워크 설정 파일은 유출/변조 시 침해로 직결될 수 있다. 핵심은 “소유자/그룹/기타 권한”을 최소화하고, 백업본까지 동일 정책을 적용하는 것이다.

확인 방법(SQL + OS)

-- DB에서 파라미터 파일 위치를 간접 확인(환경에 따라 경로는 다름)
-- spfile 사용 여부/위치 힌트
SHOW PARAMETER spfile;

-- (가능 시) 진단/트레이스 경로 확인(리스너 로그/trace와 연계)
SHOW PARAMETER diagnostic_dest;

# (Linux 예시) 주요 파일 권한 점검
# 실제 경로는 환경별로 상이하므로 ORACLE_HOME/ORACLE_BASE 기준으로 확인
ls -l $ORACLE_HOME/dbs
ls -l $ORACLE_HOME/network/admin

# 권장 방향(예시): oracle:oinstall 소유, others 권한 제거 등
# -rw------- 또는 -rw-r----- 수준으로 최소화(정책에 맞게)

조치 방법(권고)

# 1) 소유권/권한 최소화(예시)
# chown oracle:oinstall $ORACLE_HOME/dbs/orapw
# chmod 600 $ORACLE_HOME/dbs/orapw

# 2) 네트워크 설정 파일도 동일하게 최소 권한 적용
# chmod 640 $ORACLE_HOME/network/admin/sqlnet.ora

# 3) 백업본/공유폴더/배포 경로에 동일 정책 적용(자주 놓치는 구간)

D-15 리스너 로그·trace 파일 변경 제한(하/1)

로그/trace는 침해 흔적의 핵심 증빙이다. 변경/삭제가 가능하면 은폐가 쉬워진다. 관리자를 제외한 사용자가 로그/trace를 수정하지 못하도록 OS 권한과 경로 접근을 통제한다.

확인 방법(운영 점검 + 보조 SQL)

# 리스너 로그/trace 위치 확인
lsnrctl status

# (Linux 예시) 로그/trace 디렉터리 권한 점검
# 경로 예시: $ORACLE_BASE/diag/tnslsnr///trace
ls -ld $ORACLE_BASE/diag/tnslsnr
find $ORACLE_BASE/diag/tnslsnr -maxdepth 4 -type d -name trace -exec ls -ld {} \;

-- (보조) DB 쪽 진단 경로(서버 진단 체계와 함께 맞추기)
SHOW PARAMETER diagnostic_dest;

조치 방법(권고)

# 1) 로그/trace 디렉터리 권한 최소화
# - 소유자/그룹: oracle 전용
# - others 쓰기 권한 제거
# 예시)
# chown -R oracle:oinstall $ORACLE_BASE/diag/tnslsnr
# chmod -R go-w $ORACLE_BASE/diag/tnslsnr

# 2) 로그 보관/로테이션 정책 수립(삭제/변조 방지)
# 3) 백업/원격 전송(SIEM 등)으로 이중 보관(가능 시)