프로시저 및 함수에 대한 Invoker’s 및 Definer’s 권한 사용

Oracle 데이터베이스에서 PL/SQL 프로시저와 함수를 사용하여 코드를 모듈화하고 재사용성을 높일 수 있습니다. PL/SQL 코드를 작성할 때 중요한 고려 사항 중 하나는 어떤 권한 모델을 사용할지 결정하는 것입니다. Oracle은 크게 Invoker’s Rights(호출자 권한)와 Definer’s Rights(정의자 권한) 두 가지 권한 모델을 제공합니다. 각 모델은 서로 다른 보안 및 액세스 제어 메커니즘을 제공하며, 특정 시나리오에 더 적합할 수 있습니다.

Invoker’s Rights (호출자 권한)

Invoker’s Rights는 PL/SQL 유닛이 실행될 때 해당 유닛을 호출하는 사용자의 권한을 사용하여 데이터베이스 객체에 액세스하는 권한 모델입니다. 즉, 프로시저나 함수 내부에서 사용되는 SQL 문은 해당 코드를 실행하는 사용자의 권한으로 실행됩니다. 이는 코드를 소유한 사용자(정의자)가 아닌, 코드를 실행하는 사용자(호출자)에게 데이터 액세스 권한을 부여합니다.

Invoker’s Rights의 장점

  • 유연한 액세스 제어: 애플리케이션 로직을 변경하지 않고도 사용자별로 다른 데이터에 액세스할 수 있도록 제어할 수 있습니다.
  • 애플리케이션 보안 강화: 정의자의 권한이 아닌 호출자의 권한을 사용하므로, 악의적인 사용자가 정의자의 권한을 악용하여 데이터베이스를 손상시키는 것을 방지할 수 있습니다.

Invoker’s Rights의 단점

  • 복잡한 권한 관리: 각 호출자에게 필요한 권한을 명시적으로 부여해야 하므로 권한 관리가 복잡해질 수 있습니다.
  • 성능 저하 가능성: 런타임에 권한을 확인해야 하므로 Definer’s Rights에 비해 성능이 다소 저하될 수 있습니다.

Invoker’s Rights 예제

다음 예제는 `EMP_TABLE` 테이블에서 데이터를 조회하는 프로시저를 보여줍니다. 이 프로시저는 Invoker’s Rights로 정의되어 있으므로, 프로시저를 호출하는 사용자는 `EMP_TABLE`에 대한 `SELECT` 권한을 가지고 있어야 합니다. 


 CREATE OR REPLACE PROCEDURE get_employee_data
 AUTHID CURRENT_USER
 AS
 emp_name VARCHAR2(100);
BEGIN
 SELECT ename INTO emp_name FROM emp_table WHERE empno = 100;
 DBMS_OUTPUT.PUT_LINE('Employee Name: ' || emp_name);
END;
/

위 코드에서 `AUTHID CURRENT_USER`는 해당 PL/SQL 유닛이 Invoker’s Rights로 실행됨을 명시합니다.

Definer’s Rights (정의자 권한)

Definer’s Rights는 PL/SQL 유닛이 해당 유닛을 소유한 사용자의 권한을 사용하여 데이터베이스 객체에 액세스하는 권한 모델입니다. 즉, 프로시저나 함수 내부에서 사용되는 SQL 문은 해당 코드를 소유한 사용자의 권한으로 실행됩니다. 이는 코드의 실행자가 아닌, 코드 소유자에게 데이터 액세스 권한을 부여합니다.

Definer’s Rights의 장점

  • 간단한 권한 관리: 모든 사용자가 동일한 권한으로 데이터에 액세스하므로 권한 관리가 간단합니다.
  • 향상된 성능: 런타임에 권한을 확인할 필요가 없으므로 Invoker’s Rights에 비해 성능이 좋습니다.

Definer’s Rights의 단점

  • 보안 위험 증가: 악의적인 사용자가 Definer’s Rights 유닛에 코드를 삽입하여 데이터베이스를 손상시킬 위험이 있습니다.
  • 제한적인 액세스 제어: 사용자별로 다른 데이터에 액세스하도록 제어하기 어렵습니다.

Definer’s Rights 예제

다음 예제는 `EMP_TABLE` 테이블에 새로운 직원을 추가하는 프로시저를 보여줍니다. 이 프로시저는 Definer’s Rights로 정의되어 있으므로, 프로시저를 호출하는 사용자는 `EMP_TABLE`에 대한 `INSERT` 권한을 가지고 있지 않아도 됩니다. 프로시저 소유자(정의자)에게만 `INSERT` 권한이 있으면 됩니다. 


 CREATE OR REPLACE PROCEDURE add_employee(
 p_empno NUMBER,
 p_ename VARCHAR2,
 p_deptno NUMBER
 )
 AUTHID DEFINER
 AS
BEGIN
 INSERT INTO emp_table (empno, ename, deptno) VALUES (p_empno, p_ename, p_deptno);
 COMMIT;
END;
/

위 코드에서 `AUTHID DEFINER`는 해당 PL/SQL 유닛이 Definer’s Rights로 실행됨을 명시합니다.

Invoker’s Rights와 Definer’s Rights 선택 가이드라인

어떤 권한 모델을 사용할지 결정할 때는 다음과 같은 요소를 고려해야 합니다.

  • 보안 요구 사항: 사용자별로 다른 데이터에 대한 액세스 제어가 필요한 경우 Invoker’s Rights를 사용하는 것이 좋습니다. 반면, 모든 사용자가 동일한 권한으로 데이터에 액세스해야 하는 경우 Definer’s Rights를 사용하는 것이 더 간단합니다.
  • 애플리케이션 복잡성: Invoker’s Rights는 권한 관리를 복잡하게 만들 수 있으므로, 애플리케이션이 간단한 경우 Definer’s Rights를 사용하는 것이 좋습니다.
  • 성능 요구 사항: Definer’s Rights는 런타임 권한 확인이 없으므로 Invoker’s Rights보다 성능이 좋습니다.

추가 고려 사항

  • 뷰(View): 뷰를 생성할 때도 `AUTHID` 절을 사용하여 뷰의 권한 모델을 지정할 수 있습니다. Invoker’s Rights 뷰는 뷰를 사용하는 사용자의 권한으로 기본 테이블에 액세스하므로, 뷰를 통해 데이터에 액세스하는 사용자에게 필요한 권한을 부여해야 합니다. 반면, Definer’s Rights 뷰는 뷰 소유자의 권한으로 기본 테이블에 액세스합니다.
  • 데이터베이스 링크(Database Link): 데이터베이스 링크를 사용하여 원격 데이터베이스에 액세스하는 경우, 데이터베이스 링크를 생성할 때 지정한 사용자 계정의 권한이 사용됩니다. 따라서 데이터베이스 링크를 통해 데이터에 액세스하는 PL/SQL 유닛은 데이터베이스 링크에 지정된 사용자의 권한을 사용합니다.

결론

PL/SQL 프로시저 및 함수에서 Invoker’s Rights와 Definer’s Rights는 서로 다른 보안 및 액세스 제어 메커니즘을 제공합니다. 어떤 권한 모델을 사용할지 결정할 때는 애플리케이션의 보안, 복잡성, 성능 요구 사항을 신중하게 고려해야 합니다. 각 모델의 장단점을 이해하고 애플리케이션의 요구 사항에 가장 적합한 모델을 선택하는 것이 중요합니다.

위로 스크롤