호출자 권한 이용하기 - 8i부터 가능
① 톰아저씨가 이야기하는 호출자권한 이용하기
- 기본적으로, 스토어드 프로시저(또는 팩키지, 함수, 트리고 이하 그냥 프로시져로 표현함)는 definer의 권한을 통해 실행된다.
- (invoker와 definer가 다른 경우에도 마찬가지이다)
- 호출자가 테이블 접근 권한은 없고 프로시저 실행 권한만을 갖는 경우에도 프로시저의 모든 테이블 액세스는 definer의 권한을 가지게 됨.
정의자(Definer) 권한
정의
- 프로시져 소유자의 기본 권한을 이용하여 SQL을 실행함을 의미한다
특징
- 컴파일 시 정의자(작성자?)가 오라클객체에 대한 액세스 권한이 있는지 체크한다.
- 정적인 컴파일 시간 바인딩은 엑세스하는 객체에 대한 직접부여된 권한으로만 한정된다.
사용 예
CREATE PROCEDURE create_dept (
my_deptno NUMBER,
my_dname VARCHAR2,
my_loc VARCHAR2) -- 디폴트값 AUTHID DEFINER (정의자권한)
AS
BEGIN
INSERT INTO dept VALUES (my_deptno, my_dname, my_loc);
END;
/
호출자(Invoker) 권한이용
정의
- 프로시져 호출자의 기본 권한을 이용하여 SQL을 실행함을 의미한다
특징
- 정의자 권한의 규칙을 따르지 않는 프로시져, 팩키지, 함수를 생성할 수 있다.
- 액세스하기 위한 객체에 대한 권한 확인을 컴파일시간이 아닌 실행시간에 정의할 수 있다.
- 즉, 프로시져를 실행하는 사용자의 권한에 따라 작동(오류)여부를 정할 수 있다
사용예
CREATE PROCEDURE create_dept1 (
my_deptno NUMBER,
my_dname VARCHAR2,
my_loc VARCHAR2) AUTHID CURRENT_USER --호출자권한
AS
BEGIN
INSERT INTO dept VALUES (my_deptno, my_dname, my_loc);
END;
/
호출자권한과 정의자권한의 동작 테스트
호출자 권한과 다중 스키마
- 호출자 권한의 목표는 프로시져의 수정없이 USER1이 USER1.TABLE을 이용하고 USER2가 USER2.TABLE을 이용하게 하는것이다.
- 하지만 저자는 오라클에서 이야기하는 것과는 다르게 모든 데이터를 유지하기 위한 하나의 스키마만이 존재해야한다고 말하며,
- 사용의 편의성과 보안을 위하여 데이터를 분리해야 한다면 FGAC(Fine-Grained Access Control)을 이용할 것을 권고하고 있다.
톰아저씨의 호출자권한에 대한 생각
스키마를 유지할 필요가 있다
- 예를 들어 특정 테이블의 컬럼을 추가하는 요구가 발생하면 관련된 모든 스키마의 해당 테이블 속성을 추가해주어야 한다
종속성 메커니즘을 잃게 된다
- 실행시간에 어떤 객체를 사용할지 모르기 때문에 어떻게 종속이 되는지 검증하기 힘들다
저장코드의 신뢰성을 상실하게 된다
- 위와 같은 이유로 검증되지 않기 때문에 신뢰성을 상실하게 된다.
오라클 공유 풀이 넘친다
- 액세스하는 객체가 다르기 때문에SYNTAX는 같아도 HASH값은 다를 것이기 때문이다.
PL/SQL의 주요 이점이 소멸된다
- 공유 풀과 종속성과 관련한 문제를 이미 이야기했다
개발과 디버깅이 어려워진다
Q/A
- 톰아저씨 말대로라면 단점이 많은 호출자 권한 루틴은 쓸모가 없을것 같다?
- 하지만 일반적인 유틸리티를 개발할때는 대단히 유용하다. (예 DUMP_CSV와 PRINT_TABLE)
호출자 권한 루틴의 조건
호출자처럼 실행될 필요가 있다
- 정의자로서 실행되려면 엄청난 보안사항이 고려되어야 할 것이다 (경우에 따라 많은 권한을 주어야되는데 그런 고려사항이 되겠다.)
사용빈도가 낮다
- ('낮아야 한다' 로 이해하는게 맞겠다)
- 많이 사용되어서 공유 풀을 넘치게 하지 않는다
모두 동적 SQL을 이용한다
- 일단의 테이블에 얽메이지 않는다.
- 동적SQL을 이용하여 누구라도 자신의 테이블을 사용할 수 있도록 해준다. (톰아저씨의 방법론이다.)
오라클 메뉴얼에서의 호출자 권한 이용하기
오라클에서 말하는 호출자권한의 특징
- 호출자권한 서브프로그램을 재사용하고 어플리케이션 로직을 중심에 모은다.
- 그들은 매우 자주 사용하며 각각 다른 스키마에 저장하는 어플리케이션이다.
- 그런 경우, 다중 유저들은 하나의 코드기반으로 각각 소유자의 데이터를 관리할 수 있다.
사용예
시나리오_step1
한 회사는 판매분석을 위한 정의자권한 프로시져의 사용을 고려한다. 지역 판매통계를 제공하기 위해, 판매분석 프로시져는 반드시 각 지역사이트에 속한 판매테이블에 엑세스한다.
그래서 figure 8-4를 보면, 해당 프로시져는 반드시 지역 사이트에 속한다 이것은 관리상의 문제점을 야기한다.
그림 figure 8-4
시나리오_step2
이 문제를 해결하기 위해, 해당 회사는 본사에 호줄자권한 버전의 프로시져를 분석하여 설치한다.
지금은 Figure 8-5 에 보이듯, 모든 지역 사이트는 그들 소유의 sale테이블을 조회하기 위해서 같은 프로시져를 사용할 수 있다
그림 figure 8-5
시나리오_step3
민감한 데이터에 제한적으로 엑세스하기 위하여, 당신은 호출자권한 서브프로그램에서 정의자권한 서브프로그램을 호출할 수 있다. 만약 본사에서 판매커미션을 계산하고 중앙 급여대장을 업데이트하는 프로시져를 분석한다면, 현재 사용자(호줄자)는 급여대장 테이블에 직접 접근할 권한을 가지고 있지 않기 때문에 현재 문제가 야기되며 Figure 8-6를 보면 calc_comm 정의자권한 프로시져를 가짐으로서 해결하고 있다.
그림 figure 8-6