엑시엄이 보는 DB 세상

PL/SQL 내 권한에 대한 오해

IT를 업으로 삼고 있다면 데이터베이스(이하 DB) 권한을 한번쯤은 고민해 봤을 것이다. 데이터 보호의 최전선에 있는 방화벽과 같은 물리적 보안이 뚫렸을 때 최후의 보루인 DB 권한은 체계적이고 철저한 관리가 요구된다. 그럼에도 편의를 위해 또는 무지의 산물로 DBA라는 막강한 권한을 사용자에게 부여하는 홈페이지가 적지 않다. 보안보다 편의성을 중시하는 사람을 계도하기 위해 이 글을 쓰는 것은 아니다. 다만 PL/SQL 내의 권한 오류에 대처하는 방법을 몰라 최상위 권한으로 해결하려는 분들에게 PL/SQL 내에서 권한이 어떻게 부여되고 동작하는지 알려주려는 것 뿐이다.

PL/SQL 내의 권한 오류를 위해 ‘DBA’라는 최상위 권한 묶음을 부여해 해결을 시도했다고 가정하자. 과연 문제를 올바르게 해결한 것일까 답은 ‘아니다’다. 정확하게 말하면 성공할 수도 있고, 아닐 수도 있다. PL/SQL 내에서 권한이 동작하는 방식에 따라 달라지기 때문이다. 그렇다보니 최상위 권한인 DBA를 부여하고도 문제가 해결되지 않으면 대부분은 다른 권한을 하나씩 무작위로 추가한다. 그야말로 불필요한 권한이 선물세트처럼 사용자 계정에 부여하는 것이다. 이런 방식으로 구성된 DB 보안이 튼튼하지 않을 것은 불을 보듯 자명하다.

문제제기 및 가설

먼저 DBA 권한을 부여해도 원하는 권한을 부여받지 못하고 ‘ORA-01031 권한이 불충분합니다’ 또는 ‘ORA-00942 테이블 또는 뷰를 찾을 수 없습니다’라는 문구를 보게 되는 것일까 PL/SQL 내에서는 일반적인 권한 방식과 다르게 동작하는 것일까 PL/SQL 오브젝트는 소유자와 수행자가 다를 수 있는데 누구에게 권한을 줘야 할까 이러한 물음에 대한 답을 지금부터 함께 생각해 보자. A라는 소유자의 특정 프로시저를 다른 스키마 B도 실행 권한만 부여받으면 이 프로시저를 수행할 수 있다. 이 경우 해당 프로시저 내부에서 접근하는 테이블에 대한 권한은 소유자 A에게 부여해야 할까 아니면 수행자 B에게 부여해야 할까 모든 케이스를 하나씩 확인해 보면 그 답을 찾을 수 있을 것이다.

테스트

테스트에 앞서 프로시서 생성 옵션 중 권한과 관련된 옵션을 살펴보고 넘어가자.



<그림 1>의 프로시서 생성 옵션에서 확인할 수 있듯 권한 관련 옵션으로는 두 가지가 있다. AUTHID DEFINER 옵션은 프로시저 수행 시 프로시저를 생성한 소유자의 권한 체계를, 두 번째 옵션인 AUTHID CURRENT_USER는 프로시서를 수행하는 수행자의 권한 체계를 따른다는 의미다. 프로시서 생성 DDL은 <리스트 1>과 같이 선언해야 사용할 수 있다.

<리스트 1> 프로시저 생성 DDL
/* PROCEDURE 생성 DDL 예제 */
CREATE OR REPLACE PROCEDURE 유저명.프로시저명
[AUTHID DEFINER | AUTHID CURRENT_USER]
IS
BEGIN
/* 프로시저 내용 부분 */
END;

참고로 디폴트 옵션은 AUTHID DEFINER이다. 두 옵션을 선택치 않으면 모두 디폴트 옵션으로 생성된다. 즉 별도의 옵션 지정 없이 생성된 프로시저는 소유자 스키마의 권한 체계를 따르게 된다. 어떤 이들은 나는 수행자, 소유자 모두에게 DBA 권한을 부여했지만 권한 에러가 발생했다고 의문을 제기할 수도 있다. 결론만 말하면 그런 상황도 충분히 발생할 수 있다. 이 또한 앞서 얘기했듯 모든 변수를 일일이 테스트해 보면 알 수 있을 것이다. <표 1>은 생성자와 소유자, 권한 유형 등의 모든 변수들에 따른 케이스를 나열한 표다.

총 12가지 상황에 대한 예제 스크립트는 <리스트 2>와 같다. 케이스별로 변수에 해당하는 부분을 변경하며 테스트를 수행하면 된다.

<리스트 2> <표 1>의 모든 케이스에 대한 예제 스크립트
#################### PROCEDURE 생성 DDL 예제 #####################
CREATE OR REPLACE PROCEDURE ownuser.plsql_auth_test_proc
[AUTHID DEFINER | AUTHID CURRENT_USER]
IS
v_empno VARCHAR2(20);
BEGIN
SELECT EMPLOYEE_ID INTO v_empno
FROM HR.EMP
WHERE ROWNUM< =1;
END;
#################### 케이스별 권한 부여 명령어 #####################
/* 소유자에게 DBA 롤 권한을 부여 */
GRANT DBA TO ownuser;
/* 소유자에게 시스템 권한을 부여 */
GRANT SELECT ANY TABLE TO ownuser;
/* 소유자에게 오브젝트 권한을 부여 */
GRANT SELECT ON HR.EMP TO ownuser;
/* 수행자에게 DBA 롤 권한을 부여 */
GRANT DBA TO execuser;
/* 수행자에게 시스템 권한을 부여 */
GRANT SELECT ANY TABLE TO execuser;
/* 수행자에게 시스템 권한을 부여 */
GRANT SELECT ON HR.EMP TO execuser;
######################## 프로시저 수행 ###########################
GRANT EXECUTE ON ownuser.plsql_auth_test_proc TO execuser;
EXEC ownuser.plsql_auth_test_proc;

12가지 케이스를 모두 테스트한 결과는 <표 2>와 같다. 특이한 점은 AUTHID DEFINER 옵션의 경우 DBA ROLE 권한을 소유자에게 부여해도 프로시저 내에서는 유효하지 않았다. 반면 AUTHID CURRENT_USER 옵션의 경우에는 모든 권한 유형에 대해 유효했다.

이번 테스트는 프로시저에 한해 수행했지만 PL/SQL 오브젝트인 PACKAGE, FUNCTION도 AUTHID DEFINER 및 AUTHID CURRENT_USER 생성 옵션이 있으며 그 결과는 이와 같다.

사용법 가이드

혹자는 AUTHID CURRENT_USER를 모든 PL/SQL에 적용하면 수행자의 권한만 관리하면 되기 때문에 권한 관리가 더 쉽고 간편하지 않냐고 물을 수 있다. 그러나 단순하게 무엇이 더 좋으니 이것만 써라는 식으로 이를 단순화시킬 수는 없다. 왜냐하면 각각 장단점이 있기 때문이다. 예컨대 특정 테이블을 TURNCATE하는 프로시저가 있다고 가정해 보자. AUTHID CURRENT_USER 방식으로 생성하면 해당 프로시저를 수행하는 모든 사용자가 TRUN CATE 권한을 가지고 있어야 한다. 그러나 TRUNCATE는 데이터 복구가 힘들어 이를 프로시저를 원하는 모든 사용자에게 부여하는 것은 굉장히 위험하다. 그러므로 다음과 같이 상황에 따라 PL/SQL 권한 옵션을 적절하게 사용해야 한다.

* AUTHID DEFINER 사용은 언제
: 특정 오브젝트에 대한 접근을 제한하고 싶을 때

* AUTHID CURRENT_USER 사용은 언제
: 수행자별로 권한을 관리를 하고 싶을 때

이처럼 여건에 따라 PL/SQL의 권한 옵션을 알맞게 사용하면 불필요한 권한 부여로 보안이 취약해지는 경우를 최소화할 수 있다. 더 이상 PL/SQL의 권한 체계를 몰라 DBA라는 막강한 권한을 고민없이 부여하는 일이 없었으면 하는 바람이다.