ORA-01031 해결: 권한 부족 원인별 점검과 최소 권한 복구

ORA-01031 해결: 권한 부족 원인별 점검과 최소 권한 복구

ORA-01031: insufficient privileges(권한이 불충분합니다) 오류는 “권한이 없다”라는 한 문장으로 끝나지 않는 경우가 많습니다. 같은 메시지지만 원인은 시스템 권한, 객체 권한, 롤(ROLE) 적용 방식, 프로시저 권한 모델(definer/invoker), PDB/컨테이너 권한 범위까지 다양하게 갈립니다.

실무 기준으로 보면
ORA-01031은 “GRANT 한 번 더 주면 된다”로 끝내면 재발합니다.
어떤 작업(DDL/DML/패키지 호출)을 누가(스키마/프로시저/잡)가 실행했는지부터 확정하고,
그 경로에 맞는 최소 권한을 정확히 주는 게 운영 안전성과 감사 대응에 유리합니다.

개요

Oracle 권한은 크게 시스템 권한(예: CREATE TABLE, ALTER SYSTEM) 과 객체 권한(예: 특정 테이블에 대한 SELECT, EXECUTE)으로 나뉩니다. 여기에 ROLE은 세션에서는 적용되지만, 일반적으로 Definer Rights(기본 AUTHID DEFINER)로 실행되는 PL/SQL 내부에서는 자동 적용되지 않는 등 “실행 컨텍스트”에 따라 체감 동작이 달라집니다.

환경

• DB: Oracle Database (11g~19c/21c, CDB/PDB 포함)
• 발생 지점: DDL 수행, 타 스키마 객체 접근, 패키지/프로시저 실행, DB 링크 사용, 잡(SCHEDULER) 실행
• 점검 뷰: DBA_SYS_PRIVS, DBA_TAB_PRIVS, DBA_ROLE_PRIVS, ROLE_SYS_PRIVS, SESSION_ROLES

증상

ORA-01031은 아래 패턴에서 자주 보입니다.

• DDL 실행: CREATE, ALTER, DROP, GRANT 등
• 타 스키마 객체 접근: SELECT other_schema.table, EXEC other_schema.pkg
• 프로시저 내부에서 외부 객체 호출 시 실패(직접 실행은 되는데 프로시저에서만 실패)
• PDB에서 권한을 줬는데 CDB/다른 PDB에서는 적용이 안 됨
• DBMS_* 패키지 호출이 특정 계정에서만 막힘

ORA-01031: insufficient privileges

1차 점검

가장 먼저 아래 4가지를 확정해야 합니다. 이 단계가 애매하면 권한을 “과다 부여”하게 됩니다.

점검 항목	확인 포인트
실행 주체	실패한 계정(스키마), 프록시/앱 계정 여부, 잡(Job) 실행 계정
실패 작업	정확한 SQL/패키지 호출, DDL인지 DML인지, 대상 객체(스키마.객체명)
실행 컨텍스트	직접 실행인지, 프로시저/트리거 내부 실행인지(Definer/Invoker)
컨테이너	CDB/PDB 중 어디에서 실행했는지(권한은 컨테이너 범위를 타는 경우가 많음)

현재 세션 권한/롤 확인

-- 세션에 활성화된 롤
SELECT * FROM session_roles;

-- (권한 점검용) 내가 가진 시스템 권한
SELECT * FROM user_sys_privs;

-- (권한 점검용) 내가 가진 객체 권한
SELECT owner, table_name, privilege
FROM   user_tab_privs;

실무 팁
“직접 실행은 되는데 프로시저에서만 ORA-01031”이면 10번 중 7~8번은 ROLE 문제입니다.
PL/SQL(Definer Rights)은 ROLE을 기본적으로 사용하지 않으니, 필요한 권한은 롤이 아니라 직접 GRANT로 줘야 합니다.

심화 분석

원인 1) 객체 권한이 없음(타 스키마 테이블/뷰/시퀀스/프로시저)

-- 대상 객체에 대한 권한이 있는지(관리자 관점)
SELECT grantee, owner, table_name, privilege
FROM   dba_tab_privs
WHERE  grantee = 'APPUSER'
AND    owner   = 'OTHER_SCHEMA'
AND    table_name IN ('T1','V1','SEQ1','PKG1')
ORDER  BY owner, table_name, privilege;

원인 2) 시스템 권한이 없음(DDL/관리 기능)

SELECT grantee, privilege
FROM   dba_sys_privs
WHERE  grantee = 'APPUSER'
ORDER  BY privilege;

원인 3) ROLE로만 권한이 부여되어 PL/SQL에서 실패

예: ROLE_A에 SELECT 권한이 있고 APPUSER가 ROLE_A를 받았지만, APPUSER 소유 프로시저가 OTHER_SCHEMA.T1을 조회하면 ORA-01031이 날 수 있습니다.

-- APPUSER가 받은 롤 확인
SELECT granted_role
FROM   dba_role_privs
WHERE  grantee = 'APPUSER';

-- 롤이 가진 권한 확인(객체 권한은 DBA_TAB_PRIVS에서 GRANTEE=롤명으로 조회)
SELECT grantee, owner, table_name, privilege
FROM   dba_tab_privs
WHERE  grantee = 'ROLE_A'
ORDER  BY owner, table_name, privilege;

원인 4) Definer/Invoker 권한 모델 불일치

패키지/프로시저가 AUTHID CURRENT_USER(Invoker Rights)인지, 기본값(Definer Rights)인지에 따라 필요한 권한이 달라집니다.

-- 객체 소유자/상태 확인
SELECT owner, object_name, object_type, status
FROM   dba_objects
WHERE  owner = 'APPUSER'
AND    object_name = 'P_TEST';

-- 소스에서 AUTHID 확인(프로시저/패키지)
SELECT text
FROM   dba_source
WHERE  owner = 'APPUSER'
AND    name  = 'P_TEST'
AND    type  IN ('PROCEDURE','PACKAGE','PACKAGE BODY')
ORDER  BY line;

원인 5) CDB/PDB 권한 범위 문제

CDB 환경에서는 같은 사용자/롤이라도 컨테이너마다 권한 부여 상태가 달라질 수 있습니다. “PDB에서만 발생”하거나 “특정 PDB에서만 해결됐다”면 컨테이너를 확정하고 권한을 다시 점검해야 합니다.

관리자 입장에서
ORA-01031은 “권한이 없다”라기보다 “권한이 그 컨텍스트에서 유효하지 않다”인 경우가 많습니다.
특히 ROLE과 PL/SQL 실행 모델, 그리고 CDB/PDB 범위가 같이 얽히면 원인 파악이 늦어집니다.

복구

복구 원칙은 간단합니다. 필요한 권한을 직접(Direct Grant)로 최소 범위로 부여하고, “전체 권한” 역할(DBA 등) 부여는 가능한 피합니다.

1) 타 스키마 테이블 조회 권한 부여(객체 권한)

-- OTHER_SCHEMA 소유 테이블 T1을 APPUSER가 조회해야 하는 경우
GRANT SELECT ON OTHER_SCHEMA.T1 TO APPUSER;

-- DML이 필요하면 필요한 것만 추가
GRANT INSERT, UPDATE, DELETE ON OTHER_SCHEMA.T1 TO APPUSER;

2) 타 스키마 패키지 실행 권한 부여(객체 권한)

GRANT EXECUTE ON OTHER_SCHEMA.PKG_API TO APPUSER;

3) 프로시저에서만 실패한다면(ROLE 의존 제거)

-- 롤에만 있던 권한을 APPUSER에 직접 부여(Definer Rights 대응)
GRANT SELECT ON OTHER_SCHEMA.T1 TO APPUSER;

4) DDL이 필요하다면(시스템 권한)

-- 예: APPUSER가 테이블을 생성해야 하는 경우
GRANT CREATE TABLE TO APPUSER;

-- 시퀀스/뷰 등도 필요한 것만
GRANT CREATE SEQUENCE TO APPUSER;
GRANT CREATE VIEW TO APPUSER;

주의
GRANT ANY PRIVILEGE, SELECT ANY TABLE, EXECUTE ANY PROCEDURE 같은 ANY 권한은 영향 범위가 매우 큽니다.
급한 장애 조치로 남발하면, 나중에 회수하기도 어렵고 감사 이슈로 이어질 수 있습니다.

5) 적용 확인

-- 권한 부여 후 즉시 재현 SQL로 확인
SELECT COUNT(*) FROM OTHER_SCHEMA.T1;

BEGIN
  OTHER_SCHEMA.PKG_API.PING;
END;
/

재발 방지

• 최소 권한 설계: 업무별로 필요한 객체/권한 목록을 정의하고 직접 GRANT로 관리
• ROLE 사용 원칙: 세션 편의용(개발자 도구 등)과 애플리케이션 실행 권한을 분리
• PL/SQL 권한 모델 표준화: Definer/Invoker 사용 기준을 문서화하고 코드 리뷰에 포함
• 컨테이너 범위 점검: CDB/PDB 환경에서 권한 부여 위치(어느 컨테이너에서 GRANT했는지) 기록
• 권한 변경 이력: GRANT/REVOKE 변경은 티켓/승인 기반으로 남기고 주기적으로 회수 점검

실제 사용 시
ORA-01031은 한번 해결해도, 배포/계정 변경/권한 회수 작업에서 쉽게 재발합니다.
“누가 무엇을 실행할 수 있어야 하는지”를 표준 권한 정책으로 고정해두면 장애가 급격히 줄어듭니다.