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

DB 보안 점검 · 접근관리/옵션관리

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

아래는 KISA 점검표 중 16~20번(D-16~D-20)을 대상으로, 확인 SQL(점검)과 조치 방법(권고)을 정리한 내용이다. 옵션관리 항목은 설정 한 줄이 우회 경로가 될 수 있으므로, 변경 시 영향 분석을 우선한다.

범위: D-16 ~ D-20 · 대상: 인증 모드/감사/권한 공개 범위/OS 인증/스키마 소유

공통 전제

실무 기준으로 보면
D-16~D-20은 “정책이 엄격할수록 안전”하긴 하지만, 인증/권한 구조와 강하게 얽혀 있다.
변경 전에는 반드시 테스트 적용 → 운영 반영 순으로 진행하고, 롤백 절차를 문서화한다.

• 주요 뷰: V$PARAMETER, DBA_USERS, DBA_ROLE_PRIVS, DBA_TAB_PRIVS, DBA_OBJECTS
• 감사 정책은 Unified Auditing/Traditional Auditing 구성에 따라 확인 경로가 달라질 수 있음

D-16 Windows 인증 모드 사용(하/1)

Windows 인증(외부 인증/OS 인증 연계)은 운영 편의가 있지만, 구성 오류 시 우회 위험이 생길 수 있다. 기관 정책에 맞게 “사용 여부”와 “통제 조건(접속 구간·권한 매핑·감사)”을 명확히 해야 한다.

확인 방법(SQL)

-- OS 인증/외부 인증 관련 파라미터 확인(환경에 따라 적용 범위 상이)
SELECT name, value
FROM v$parameter
WHERE name IN ('os_authent_prefix','remote_os_authent','remote_os_roles','os_roles');

-- 사용자 인증 방식(외부 인증 계정 여부)
SELECT username, account_status, authentication_type
FROM dba_users
WHERE oracle_maintained = 'N'
ORDER BY authentication_type, username;

* AUTHENTICATION_TYPE 컬럼은 버전에 따라 다를 수 있다. 조회 실패 시 데이터딕셔너리 확인 후 컬럼을 조정한다.

조치 방법(권고)

-- 원칙: 외부/OS 인증을 사용하지 않는다면 관련 우회 경로를 최소화(D-19와 함께 적용)
-- 사용해야 한다면:
-- 1) 외부 인증 대상 계정 범위를 최소화
-- 2) 권한 매핑은 최소 권한으로 설계
-- 3) 접속 구간은 관리망/VPN 등으로 제한
-- 4) 로그인/권한 사용 감사 로그를 필수로 남김

D-17 Audit Table은 DBA 계정에만 접근하도록 제한(하/1)

감사(Audit) 데이터는 침해 분석의 핵심 증빙이다. 조회/변경/삭제 권한이 넓게 퍼져 있으면 은폐가 쉬워진다. 최소 원칙은 “감사 데이터 접근은 DBA(또는 감사 전담 계정)로만 제한”이다.

확인 방법(SQL)

-- 1) Traditional Auditing 사용 시(표준 테이블/뷰 접근 권한 점검)
-- SYS.AUD$ (기본 감사 테이블) 접근 권한 확인
SELECT grantee, owner, table_name, privilege
FROM dba_tab_privs
WHERE owner = 'SYS'
  AND table_name IN ('AUD$')
ORDER BY grantee, privilege;

-- 2) Unified Auditing 사용 시(뷰 접근 권한 점검)
-- UNIFIED_AUDIT_TRAIL 접근 권한(직접/롤 통한 권한은 별도 확인 필요)
SELECT grantee, owner, table_name, privilege
FROM dba_tab_privs
WHERE owner = 'SYS'
  AND table_name IN ('UNIFIED_AUDIT_TRAIL')
ORDER BY grantee, privilege;

* 감사 구성에 따라 실제 조회 경로가 다를 수 있다. 운영 환경에서 “감사 조회 표준 뷰/계정”을 먼저 확정하는 것이 좋다.

조치 방법(SQL 예시)

-- 불필요 권한 회수(정확한 대상/권한 확인 후)
REVOKE SELECT ON SYS.AUD$ FROM SOME_USER;
REVOKE SELECT ON SYS.UNIFIED_AUDIT_TRAIL FROM SOME_USER;

-- 전담 감사 계정에만 최소 권한 부여(예시: 조회만)
-- GRANT SELECT ON SYS.UNIFIED_AUDIT_TRAIL TO AUDIT_READONLY;

D-18 응용/DBA 계정 Role이 PUBLIC으로 설정되지 않도록 조정(상/3)

PUBLIC은 사실상 “전체 사용자”에 가깝다. 앱/DBA 성격의 권한이 PUBLIC에 열리면 권한 경계가 무너진다.

확인 방법(SQL)

-- 1) PUBLIC에 부여된 롤 확인
SELECT grantee, granted_role, admin_option
FROM dba_role_privs
WHERE grantee = 'PUBLIC'
ORDER BY granted_role;

-- 2) PUBLIC에 부여된 오브젝트 권한 확인(민감 owner 우선)
SELECT owner, table_name, privilege
FROM dba_tab_privs
WHERE grantee = 'PUBLIC'
ORDER BY owner, table_name, privilege;

-- 3) PUBLIC 경유로 노출된 권한이 실제 사용자에 어떤 영향인지 참고(간접 확인)
SELECT username, profile, account_status
FROM dba_users
WHERE oracle_maintained = 'N'
ORDER BY username;

조치 방법(SQL 예시)

-- 1) PUBLIC에 부여된 불필요 롤/권한 회수(업무 영향도 검토 필수)
REVOKE SOME_ROLE FROM PUBLIC;

REVOKE SELECT ON APP_SCHEMA.SENSITIVE_TABLE FROM PUBLIC;

-- 2) 필요한 경우 특정 롤/계정에만 최소 권한으로 재부여
-- GRANT SOME_ROLE TO APP_USER;

* PUBLIC 권한 회수는 영향이 클 수 있다. 실제 사용 서비스(배치/툴)에서 사용하는지 사전 확인 후 단계적으로 진행한다.

D-19 OS_ROLES/REMOTE_OS_AUTHENTICATION/REMOTE_OS_ROLES = FALSE(상/3)

OS 기반 원격 인증/권한 연계는 구성 오류 시 우회 경로가 될 수 있다. 기관 정책상 특별한 사유가 없다면 관련 파라미터는 FALSE로 두는 것이 일반적이다.

확인 방법(SQL)

SELECT name, value
FROM v$parameter
WHERE name IN ('os_roles','remote_os_authent','remote_os_roles')
ORDER BY name;

조치 방법(SQL 예시)

-- 변경 전 영향 분석(외부 인증 사용 여부/연동 구조 확인) 필수
ALTER SYSTEM SET os_roles = FALSE SCOPE = BOTH;
ALTER SYSTEM SET remote_os_authent = FALSE SCOPE = BOTH;
ALTER SYSTEM SET remote_os_roles = FALSE SCOPE = BOTH;

-- 일부 파라미터는 SCOPE=SPFILE + 재기동이 필요할 수 있음(환경에 따라)
-- ALTER SYSTEM SET remote_os_authent = FALSE SCOPE=SPFILE;
-- 이후 계획된 점검 창구에서 재기동

D-20 인가되지 않은 Object Owner 제한(하/1)

스키마(Owner)는 데이터 경계의 핵심이다. 불명확한 Owner, 개인 계정 Owner, 임시 Owner가 늘어나면 권한/감사/운영 표준이 흐려진다. “업무용 스키마/계정 표준”을 정해 통제하는 것이 목적이다.

확인 방법(SQL)

-- 1) 오브젝트 소유자 분포(시스템 스키마 제외)
SELECT owner, COUNT(*) AS obj_cnt
FROM dba_objects
WHERE owner NOT IN ('SYS','SYSTEM')
GROUP BY owner
ORDER BY obj_cnt DESC;

-- 2) 개인 사용자로 추정되는 스키마(예: USER_*, 개인명 패턴 등) 오브젝트 보유 여부
-- 환경의 네이밍 규칙에 맞춰 LIKE 조건 조정
SELECT owner, object_type, COUNT(*) AS cnt
FROM dba_objects
WHERE owner LIKE 'USER\_%' ESCAPE '\'
GROUP BY owner, object_type
ORDER BY owner, object_type;

-- 3) 스키마 계정의 상태/프로파일 확인(비활성인데 오브젝트가 많은 경우 등)
SELECT u.username, u.account_status, u.profile, COUNT(o.object_name) AS obj_cnt
FROM dba_users u
LEFT JOIN dba_objects o ON u.username = o.owner
WHERE u.oracle_maintained = 'N'
GROUP BY u.username, u.account_status, u.profile
ORDER BY obj_cnt DESC;

조치 방법(권고)

-- 1) 스키마 표준 확정(업무용/연동용/개인용 분리)
-- 2) 개인 계정이 오브젝트를 소유하고 있다면, 표준 스키마로 이관 계획 수립
--    (예: DBMS_REDEFINITION, EXPORT/IMPORT, 스키마 리빌드 등 환경에 맞는 방식 선택)
-- 3) 미승인 스키마 생성 통제:
--    CREATE USER 권한을 최소화(D-04와 연계), 승인 절차 없이 스키마 생성 불가하도록 운영