오라클 KISA 21~26번: 확인 SQL과 조치 방법 정리

DB 보안 점검 · 옵션관리/패치관리

오라클 KISA 21~26번: 확인 방법과 조치 방법(SQL/설정)

아래는 KISA 점검표 중 21~26번(D-21~D-26)을 대상으로, 확인 SQL(점검)과 조치 방법(권고)을 정리한 내용이다. 이 구간은 “권한 재위임 통제”와 “패치/감사 체계”가 핵심이라, 설정값과 함께 운영 프로세스(정기 점검, 변경 승인, 증빙)를 같이 구축하는 것이 중요하다.

범위: D-21 ~ D-26 · 대상: 권한 재위임/리소스 제한/위험 기능/패치/감사

공통 전제

운영 환경에서는
D-21~D-26은 “기술 설정”만으로 끝나지 않는다.
권한은 승인/회수 흐름이, 패치는 테스트→운영 흐름이, 감사는 보관/조회/위변조 방지 흐름이 있어야 점검이 통과된다.

• 주요 뷰: DBA_TAB_PRIVS, DBA_SYS_PRIVS, DBA_ROLE_PRIVS, V$PARAMETER, (가능 시) UNIFIED_AUDIT_TRAIL
• D-23, D-24는 오라클 단독 환경에서 “동명 기능”이 없을 수 있어, 운영 환경의 구성(DB + 외부 컴포넌트/확장 기능)을 기준으로 매핑 점검이 필요

D-21 인가되지 않은 GRANT OPTION 사용 제한(중/2)

GRANT OPTION은 “권한을 다시 줄 수 있는 권한”이다. 관리되지 않으면 권한이 눈덩이처럼 확산되며, 최소권한 원칙이 쉽게 붕괴한다. 핵심은 GRANT OPTION 보유 현황을 가시화하고, 필요한 주체만 남기는 것이다.

확인 방법(SQL)

-- 1) 오브젝트 권한 중 GRANTABLE(=GRANT OPTION) 부여 현황
SELECT grantee, owner, table_name, privilege, grantable
FROM dba_tab_privs
WHERE grantable = 'YES'
ORDER BY owner, table_name, privilege, grantee;

-- 2) 강한 시스템 권한의 ADMIN OPTION(권한/롤 재위임) 보유 현황
SELECT grantee, privilege, admin_option
FROM dba_sys_privs
WHERE admin_option = 'YES'
ORDER BY privilege, grantee;

-- 3) 롤 부여의 ADMIN OPTION 현황
SELECT grantee, granted_role, admin_option
FROM dba_role_privs
WHERE admin_option = 'YES'
ORDER BY granted_role, grantee;

조치 방법(SQL 예시)

-- 1) 불필요한 GRANT OPTION 회수(권한 확산 구조 영향 분석 후 진행)
REVOKE SELECT ON APP_SCHEMA.SOME_TABLE FROM SOME_USER;

-- 필요 권한은 GRANT OPTION 없이 최소 권한으로 재부여
GRANT SELECT ON APP_SCHEMA.SOME_TABLE TO SOME_USER;

-- 2) 시스템 권한/롤의 ADMIN OPTION을 최소화(업무 구조 재설계 후)
REVOKE GRANT ANY PRIVILEGE FROM SOME_USER;
-- 또는 필요한 최소 롤로 대체 후 불필요 권한 회수

* “회수” 자체보다 “누가 권한을 재위임할 수 있는가”를 운영 문서/승인 프로세스에 묶는 것이 지속성에 도움이 된다.

D-22 데이터베이스 자원 제한 기능 TRUE 설정(하/1)

자원 제한은 과도한 세션/CPU/IO 사용이나 비정상 쿼리로 인한 장애를 줄이는 안전장치다. resource_limit 활성화와 함께 프로파일의 자원 제한 항목이 실제로 적용되는지 확인한다.

확인 방법(SQL)

-- resource_limit 파라미터 값 확인
SELECT name, value
FROM v$parameter
WHERE name = 'resource_limit';

-- 프로파일 자원 제한 관련 항목 확인(대표)
SELECT profile, resource_name, limit
FROM dba_profiles
WHERE resource_name IN (
  'SESSIONS_PER_USER',
  'CPU_PER_SESSION',
  'CPU_PER_CALL',
  'CONNECT_TIME',
  'IDLE_TIME'
)
ORDER BY profile, resource_name;

조치 방법(SQL 예시)

-- 1) resource_limit 활성화
ALTER SYSTEM SET resource_limit = TRUE SCOPE = BOTH;

-- 2) 표준 프로파일에 자원 제한 설정(예시 값은 운영 정책에 맞게)
ALTER PROFILE SECURE_PROFILE LIMIT
  SESSIONS_PER_USER  5
  IDLE_TIME          30
  CONNECT_TIME       600;

-- 3) 적용
ALTER USER APP_USER PROFILE SECURE_PROFILE;

D-23 xp_cmdshell 사용 제한(상/3)

xp_cmdshell은 일반적으로 MS-SQL 계열에서 OS 명령 실행을 의미하는 대표 기능이다. 오라클 환경에서는 동일 명칭이 없을 수 있으므로, 점검의 핵심은 “DB에서 OS 명령 실행/외부 호출이 가능한 경로”를 찾아 통제하는 것이다.

확인 방법(SQL)

-- 오라클에서 OS 명령 실행 경로로 악용될 수 있는 대표 구성요소 예시 점검
-- 1) Java 권한/관련 사용자 여부(사용 환경에 따라)
SELECT username
FROM dba_users
WHERE username IN ('OJVM','JAVA$USER$')
ORDER BY username;

-- 2) Scheduler Job/Program을 통한 외부 실행 사용 여부(환경에 따라)
SELECT owner, job_name, enabled
FROM dba_scheduler_jobs
ORDER BY owner, job_name;

SELECT owner, program_name, program_type, enabled
FROM dba_scheduler_programs
ORDER BY owner, program_name;

-- 3) UTL_FILE 사용 경로(Directory 객체) 점검
SELECT owner, directory_name, directory_path
FROM dba_directories
ORDER BY owner, directory_name;

* 실제 운영에서 “외부 실행”을 쓰는 경우가 많아, 무조건 비활성보다는 “사용 주체/용도/권한/접근구간”을 제한하는 방식이 현실적이다.

조치 방법(권고)

-- 1) Scheduler 외부 실행을 사용하는 경우
-- - 실행 주체(스키마/계정)를 최소화
-- - 프로그램/잡의 생성 권한(CREATE JOB 등)을 제한(D-04, D-21과 연계)
-- - 승인된 프로그램만 실행되도록 운영 기준 수립

-- 2) UTL_FILE/Directory 객체는 경로를 최소화하고 권한을 엄격히 제한
-- 예시: 불필요 directory 제거 또는 권한 회수
-- DROP DIRECTORY SOME_DIR;
-- REVOKE READ, WRITE ON DIRECTORY SOME_DIR FROM SOME_USER;

D-24 Registry Procedure 권한 제한(상/3)

“Registry Procedure” 역시 환경에 따라 의미가 달라질 수 있다. 오라클 단독 기준에서는 OS/시스템 영역에 접근 가능한 패키지/프로시저 권한을 과다하게 부여하지 않는 것이 목적이다. 핵심은 PUBLIC 또는 광범위 롤에 “위험 패키지 실행 권한”이 열려 있지 않은지 점검하는 것이다.

확인 방법(SQL)

-- PUBLIC에 EXECUTE 권한이 열린 패키지/프로시저 점검(대표)
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
  AND privilege = 'EXECUTE'
ORDER BY owner, table_name;

-- 특정 민감 패키지(환경에 따라) 권한 점검 예시
-- 실제 운영 정책에 맞춰 목록을 확정해서 상시 점검하는 방식 권장
SELECT grantee, owner, table_name, privilege
FROM dba_tab_privs
WHERE privilege = 'EXECUTE'
  AND owner IN ('SYS')
  AND table_name IN ('UTL_FILE','UTL_HTTP','UTL_TCP','DBMS_SCHEDULER')
ORDER BY grantee, table_name;

* 패키지 사용 여부는 업무 의존성이 크다. “차단”보다는 “승인된 계정만 사용” 구조로 재설계하는 것이 안전하다.

조치 방법(SQL 예시)

-- 1) PUBLIC에 열린 EXECUTE 권한은 우선 회수 검토(영향 분석 필수)
REVOKE EXECUTE ON SYS.UTL_FILE FROM PUBLIC;

-- 2) 필요한 계정에만 최소 권한으로 재부여
GRANT EXECUTE ON SYS.UTL_FILE TO APP_FILE_SVC;

-- 3) 위험 패키지 사용 계정은 전용 롤로 묶고, 승인/회수 프로세스 운영

D-25 주기적 보안 패치 및 벤더 권고 사항 적용(상/3)

패치는 가장 현실적인 방어선이다. 정기 CPU/PSU 적용 주기와 긴급 권고 반영 기준, 테스트/검증 절차, 예외 승인 절차가 문서화되어야 점검에서 일관성이 생긴다.

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

-- DB 버전/패치 레벨은 환경별 확인 방식이 다를 수 있음
-- 일반적으로는 DB 버전 확인
SELECT * FROM v$version;

-- (가능 시) 설치된 패치 목록은 OPatch로 확인(서버에서 실행)
# $ORACLE_HOME/OPatch/opatch lsinventory

# 운영 점검 체크
# - 최근 CPU/PSU 적용일, 적용 버전, 영향/검증 결과
# - 예외(패치 미적용) 승인 문서 및 만료일
# - 패치 적용 후 기능 테스트 체크리스트 보관

조치 방법(권고)

# 1) 정기 패치 주기 수립(예: 분기)
# 2) 테스트 환경 선적용 → 운영 적용(유지보수 창구 확보)
# 3) 패치 적용 증빙(인벤토리 결과, 변경 요청서, 테스트 결과) 보관
# 4) 예외는 승인+만료일+대체 통제(네트워크 차단, 접근 제한 등)로 관리

D-26 접근/변경/삭제 감사기록을 기관 정책에 적합하도록 설정(상/3)

감사는 “켜기만”이 아니라, 기관의 감사 정책(대상 행위, 보관 기간, 열람 권한, 위변조 방지)에 맞게 설계되어야 한다. 특히 관리자 권한 사용, 권한 부여/회수, 로그인 실패/성공, 중요 테이블 접근은 최소 범위로라도 수집이 권장된다.

확인 방법(SQL)

-- 1) Unified Auditing 사용 시: 최근 감사 이벤트 확인(환경에 따라 컬럼/옵션 차이 가능)
SELECT dbusername, userhost, action_name, event_timestamp
FROM unified_audit_trail
WHERE event_timestamp > SYSTIMESTAMP - INTERVAL '7' DAY
ORDER BY event_timestamp DESC;

-- 2) Traditional Auditing 사용 시: audit_trail 파라미터 확인(환경에 따라)
SELECT name, value
FROM v$parameter
WHERE name = 'audit_trail';

-- 3) 감사 보관/삭제 권한 통제 점검은 D-17과 함께 수행 권장

* unified_audit_trail 뷰가 없거나 권한이 없으면 조회가 실패할 수 있다. 이 경우 운영 표준 감사 경로를 먼저 확정해야 한다.

조치 방법(권고)

-- 1) 감사 대상 정의(정책 문서화)
-- - 로그인(성공/실패), 권한 부여/회수, 사용자 생성/변경, 중요 테이블 접근 등

-- 2) 감사 로그 접근 통제(전담 계정만 조회) + 위변조 방지
-- - 감사 데이터 조회/삭제 권한 최소화(D-17 연계)
-- - 외부 전송(SIEM/로그서버) 또는 이중 저장으로 증빙 강화(가능 시)

-- 3) 보관 기간/로테이션/검색 절차 수립
-- - “보관만”이 아니라 사고 시 조회 가능한 형태(인덱싱/검색)까지 고려