database.sarang.net
UserID
Passwd
Database
ㆍDBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
DBMS Tutorials 450 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 450
Fine-Grained Access Control
작성자
정재익(advance)
작성일
2002-07-13 11:36
조회수
6,048

기업이 직면하고 있는 비즈니스 환경의 급격한 변화는 기업으로 하여금 주변환경 변화에 민감하게 반응하고, 대응하기 위한 내.외부 데이터를 통합 관리하는 시스템을 필요로 하게 되었다. 이런 기업의 통합 시스템은 기업 구성원으로 하여금 보다 빠르고 일관성 있는 데이터를 제공받을 수 있게 하였다. 그러나 통합 시스템은 기존 OLTP 환경에서와 다른, 통합 데이터에 대한 "보안"이라는 새로운 문제를 야기하게 되었다. 즉, 사용자에게 "통합된 테이블의 전체 데이터를 보여 줄 것인가?" 아니면 "일부분만을 보여줄 것인가?"라는 문제에 봉착한 것이다. 결국 이런 문제를 해결하기 위한 방안으로, 좀더 세밀한 데이터 제어기술의 필요성이 대두되게 되었고 그 연구 결과들이 모습을 드러내고 있다.

 

본 연재에서는 통합시스템의 여러 보안요소 중에서 데이터베이스 관리시스템(DBMS)에서 제공하는 보안 기술에 대해서 살펴보고, 그 중에서 Row Level 단위의 액세스를 가능하게 하는 Fine-Grained Access Control에 대해 중점적으로 알아보자.

 

DBMS에서 제공하는 접근제어 기능은 구현 방식의 차이에 따라서 다음과 같이 분류할 수 있다. 첫번째, 사용자의 데이터베이스 시스템에 대한 접근 자체를 제어하는 방식(Secure Application Role), 두번째, 데이터베이스 시스템 내부의 오브젝트(테이블, 뷰, …)에 대한 접근을 제어하는 방식(Application Security), 세번째, 데이터베이스 시스템 접속 세션(Session)별로 접속한 사람의 정보를 가지고 접근을 제어 하는 방식(Application Context), 마지막으로 오브젝트(테이블, View, …)내의 Row 단위 접근을 제어하는 방식(Fine-Grained Access Control)으로 구분할 수 있다.

 

 

그림1. 데이터베이스 보안

 

 

Secure Application Role

이 방식은 데이터베이스 시스템에 대해 접근 자체를 제어하는 방식으로 구현 방법에 따라서 다시 두 가지로 분류될 수 있다. 하나는 사용자의 접근제어를 어플리케이션에서 처리하는 방법이고, 다른 하나는 사용자의 접근 제어를 데이터베이스 시스템에서 처리하는 방법이다. 예전에는 데이터베이스 시스템에서 접근을 제어할 수 있는 방식이 아이디, 패스워드 인증방식 뿐이었으나 최근에는 사용자의 IP 주소 정보로 접근을 제어할 수 있는 방식을 제공하고 있다. 그러나 이 방식의 최대 단점은 유연성 있는 보안 정책을 구현하기 어렵다는 것이다. 영업사원이 여러 장소에서 주문을 내고자 하는 경우를 생각해보자. 주문을 내는 장소에 따라 IP가 다르기 때문에 이런 경우 보안 정책을 수립하기 어려울 것이다.

 

Application Security

전통적으로 많이 사용되는 방식으로 데이터베이스 시스템 사용자에게 역할과 권한에 따라 접근할 수 있는 데이터베이스 오브젝트(테이블, 뷰, …) 혹은 작업 권한을 제한하는 방식이다. 이 방식의 특징은 오브젝트 단위 접근제어가 가능하며, 중앙 집중적인 보안 정책을 수립, 적용할 수 있다. 예를 들면, 고객 테이블에 홍길동은 입사 초기에는 읽기 권한만 주어졌으나, 담당 업무의 변화로 인하여 추가적인 변경, 쓰기 권한이 필요하게 되었다고 한다면 데이터베이스에서는 간단한 명령으로 권한을 변경할 수 있으나, 이를 어플리케이션에서 처리한다면 상당히 복잡한 과정을 거쳐야 할 것이다.

 

그러나 이 방식은 구현은 간단하지만 다양한 사용자 요구를 만족시키기에는 부족한 부분이 있다.

 

Application Context

이 방식은 데이터베이스 연결 세션 단위로 보안 정책을 적용하는 방식이다. 이 방식은 동일 어플리케이션에, 동일 사용자라 하더라도 접속시의 정보를 사용하여 서로 다른 보안 정책을 적용할 수 있는 장점을 지니고 있다. 예를 들어 근무시간과 근무 외 시간에 대한 보안정책을 펼친다고 했을 때 홍길동이라는 사용자가 근무시간에 접속하면 고객 테이블의 정보를 수정가능하나 근무시간외에 접속하면 수정 불가능하게 할 수도 있다. 이 글을 읽는 독자들 중에는 "이런 기능이 뭐가 새롭냐"고 반문하시는 분들도 계시겠지만, 이전에 이런 기능을 구현하려면 어느 Tier 단에서 구현했는지 생각해보라. 대부분의 경우 Client 프로그램이나 Middle Tier 단에서 구현했을 것이다. 하지만 이젠 이런 기능을 데이터베이스시스템 단에서 구현 및 제어할 수 있게 되었다. 즉, 그만큼 중앙 집중적이고, 유연성 있는 보안관리가 가능해졌다는 뜻이다.

 

Fine-Grained Access Control

앞서 언급한 방식들은 사용자 또는 어플리케이션 단위로 보안 정책을 수립할 수 있었는데 반해, 이 방식은 데이터베이스 오브젝트(테이블, 뷰)에 적용할 수 있는 보안 정책을 수립할 수 있다. 즉 임의의 테이블에 존재하는 특정 레코드에 대해 보안 정책을 적용할 수 있다.

 

특성

Table-based or View-based security policies

테이블 또는 뷰를 기반으로 하는 유연한 보안정책을 구현할 수 있다. 예를 들어 사원테이블의 데이터는, 사용자 본인 데이터만 조회 가능하도록 보안정책을 변경하고자 할 경우 기존 어플리케이션의 수정 없이 Fine-Grained Access Control을 적용하면 쉽게 구현가능 하다. 또한, 테이블의 레코드 단위로 select, insert, update, delete 정책을 다르게 설정할 수 있어 기존 어플리케이션의 수정 없이 다양한 보안 정책을 적용할 수 있다.

 

Multiple policies per Object (테이블 또는 뷰)

하나의 오브젝트에 다수의 보안정책을 설정할 수 있으며 이들은 각각 logically 'AND'의 조건이 된다. 즉 다양한 보안 정책을 적용하기 위해서 수많은 보안 정책을 각각 구현하지 않고 몇 가지 보안정책을 결합하여 적용 함으로써 사용자의 요구를 충족할 수 있을 것이다.

 

Highly performance

Application Context와 결합하여 사용함으로써, 실행시 결정되는 attributes values에 대하여 parsed 문장의 bind variable을 제공한다. 따라서 parsed 문장의 재사용과 optimization의 이점을 동시에 취할 수 있는 것이다.

 

장단점

장점

어플리케이션 마다 필요에 의해 각각 구현해 왔던 보안정책을 데이터베이스 서버에서 한번만 만들어주면 가능하게 할 수 있으므로 비용을 줄일 수 있다. 예를 들면 어플리케이션 마다 접속 사용자에 따른 데이터 접근제어기능을 데이터베이스 서버에 만든 하나의 Fine-Grained Access Control로 대체할 수 있다. (Row Level Security도 가능)

 

어플리케이션 레벨에서 제어하는 보안정책으로는 충족할 수 없는, 즉, user가 다른 방법으로 보안정책을 피해갈 수 있는 상태에서 반드시 구현해야 하는 보안정책을 만들 수 있다 예를 들어서 보안정책이 적용된 어플리케이션을 사용하던 사용자가 보안정책이 적용되지 않은 어플리케이션을 사용하여 데이터에 접근하려고 할 때 동일한 보안정책을 적용할 수 있도록 할 수 있어, 데이터에 대한 보안을 한층 강화할 수 있다.

 

단점

Fine-Grained Access Control이 내부적으로 작동하게 되므로 관리자가 보안정책 오류에 대한 검증을 수행하기 어렵다. 또한, Fine-Grained Access Control을 적용하게 되면 사용자가 사용하는 SQL문과 데이터베이스에서 처리하는 SQL문이 상이하므로 인하여 SQL 튜닝작업이 어려워 진다. 즉, SQL문과 플랜이 일치하지 않는 경우가 발생하여 Fine-Grained Access Control에 대한 이해 없이 인덱스 전략을 수립하기 어렵다.

위에서 각 보안 기능을 단독적으로 적용하기 보다는 각각의 장단점을 이해하고 각 기능을 유기적으로 결합하여 적용한다면 보다 효과적이고 유연하게 데이터에 대한 보안 정책을 수립, 적용할 수 있을 것이다.

 

본 연재에서는 데이터베이스 시스템에서 제공하는 보안 기능에 대해서 살펴 보았으며, Fine-Grained Access Control의 특성 및 장단점에 대해서 살펴 보았다. 다음 연재에서는 Fine-Grained Access Control에 대해 예제를 통하여 어떻게 작동하는지, 어떻게 활용할 것인지에 대해서 자세히 살펴 보고자 한다.

 

지난 "Fine-Grained Access Control"연재에서 Database 환경에서의 Security 중요성 및 Fine-Grained Access Control에 대해 간단히 알아보았다. 이번 연재에서는 Fine-Grained Access Control가 어떻게 동작하는지 살펴보고 실제로 간단한 보안정책을 구현해 볼 것이다. 그리고 Fine-Grained Access Control 을 적용시 주의할 점에 대해 서도 몇 가지 언급하고자 한다.

 

그럼 먼저, Fine-Grained Access Control의 구성하고 동작시키는 과정을 알아보자.

 

Fine-Grained Access Control을 구성하고 동작시키기 위해서는 아래와 같은 보안정책을 구현하고 셋팅하는 절차가 필요하며, 여기서 셋팅한 보안정책은 SQL 실행과정에서 Oracle server에 의해 동적으로 적용된다.

 

* Fine-Grained Access Control 의 구현방법 및 동작

 

1) Fine-Grained Access Control 을 위한 패키지 및 권한 셋팅

 

2) 보안정책을 펼칠 Object를 선정한다. (Table 이나 View)

 

3) 각각의 Object에 맞는 보안정책 Rule을 작성한다. (이때 만들어진 Rule이 Policy가 됨)

 

4) DBMS_RLS 패키지를 사용하여 Policy를 Policy Group에 등록한다.

 

(만일 Policy Group을 따로 설정하지 않았다면 default group인 'SYS_DEFAULT' group에 저장됨)

 

5) 사용자가 쿼리를 실행시킨다.

 

6) Oracle Server는 사용자가 실행시킨 쿼리를 파싱하며, 이 과정에서 보안정책이 구현된 Object가 인지되면 사용자의 쿼리에 보안정책을 동적으로 적용한다.

 

7) 보안정책이 적용된 사용자의 쿼리가 실행된 후, 결과집합을 사용자에게 보여준다.

 

 

위에서 설명한 내용을 이해하기 위해 실제로 간단한 보안정책을 구현해보자.

 

1) Fine-Grained Access Control 을 사용하기 위해 필요한 패키지 및 권한 셋팅하기

 

- DBMS_RLS Package 생성 : 보안정책을 등록하기 위해 필요한 패키지

 

$ORACLE_HOME/rdbms/admin/dbmsrlsa.sql

conn sys/change_on_install
@C:\Oracle\Ora81\RDBMS\ADMIN\catrls.sql
@C:\Oracle\Ora81\RDBMS\ADMIN\dbmsrlsa.sql
@C:\Oracle\Ora81\RDBMS\ADMIN\prvtrlsa.plb

- Test를 위한 사용자 생성 및 권한부여

CONN internal;
DROP USER king cascade;
GRANT CONNECT,RESOURCE,UNLIMITED TABLESPACE TO king IDENTIFIED BY 
king;
GRANT EXECUTE ON DBMS_RLS TO king;

DROP USER clark cascade;
GRANT CONNECT,RESOURCE,UNLIMITED TABLESPACE TO clark IDENTIFIED BY 
clark;
GRANT EXECUTE ON DBMS_RLS TO clark;
GRANT CREATE ANY CONTEXT TO clark;
GRANT EXECUTE_CATALOG_ROLE, CREATE ANY CONTEXT TO scott;

- 보안정책이 적용되기 전의 쿼리결과집합 보기

conn scott/tiger;
select * from emp; -- Emp 테이블의 모든 Row를 볼 수 있다.
grant all on emp to public;

 

2) 보안정책을 펼칠 Object를 선정.

 

=> Oracle의 디폴트 테이블인 EMP 테이블에 대해 보안정책을 펼쳐보자.

 

 

3) 각각의 Object에 맞는 보안정책 Rule을 작성.

 

=> Login한 User의 이름과 emp table의 ename이 같은 Row만 접근할 수 있도록 보안정책 수립.

 

CREATE OR REPLACE FUNCTION test_security_function( p_schema in varchar2,
                                                      p_object in varchar2 ) 
RETURN varchar2
AS
BEGIN
    if ( user = 'KING' ) then        -- King 유저는 ‘관리자’로서 모든 Row를 볼 수 있다.
        return '';
    else
        return 'ename = USER';       -- King 이외의 사람들은 자신의 Row만 볼 수 있다.
    end if;
END;
/

4) DBMS_RLS 패키지를 사용하여 Policy를 Policy Group에 등록. 

BEGIN
   SYS.DBMS_RLS.ADD_POLICY   ( object_schema   => 'scott',
                                   object_name     => 'emp',
                                   policy_name     => 'TEST_POLICY',
                                   function_schema => 'scott',
                                   policy_function  => 'test_security_function',
                                   statement_types => 'SELECT, INSERT, UPDATE, DELETE',
                                   update_check    => TRUE,
                                   enable           => TRUE);
   );
END;
/

 

5) 각 유저별로 세션을 열어서 쿼리를 실행해보면 보안정책이 적용된 결과집합을 볼 수 있다.

 

conn scott/tiger;
select * from scott.emp;
select * from emp, dept;
 
conn king/king;
select * from scott.emp;
 
conn clark/clark;
select * from scott.emp;

6) 보안정책 삭제

BEGIN
 SYS.DBMS_RLS.DROP_POLICY
   ( object_schema   => 'scott',
     object_name     => 'emp',
     policy_name     => 'TEST_POLICY'
   );
END;
/

 

이렇게 Fine-Grained Access Control 을 이용한다면 간단하게 보안정책을 구현할 수 있으며, 좀더 복잡하고 다양한 보안정책을 구현하고 싶어하는 독자들은 An application context 를 이용한 방법을 공부해보는 것도 좋을 것이다.

 

이제 마지막으로 Fine-Grained Access Control을 적용할 때 주의해야 할 점에 대해 살펴보자.

 

첫째, Fine-Grained Access Control 은 Transaction 이 많은 OLTP 업무환경에서는 적당하지 않다. 쿼리문 실행시마다 발생하는 Oracle Server의 보안정책 Call에 따른 부하로 성능이 저하될 수 있기 때문이다. 따라서 모든 업무환경에 Fine-Grained Access Control을 적용하려 하지말고, DSS 또는 통합 시스템 또는 보안이 중시되는 OLTP 환경에서 Row Level Security가 반드시 요구되는 업무환경에 선별적으로 구현하는 것이 좋을 것이다.

 

둘째, Fine-Grained Access Control 은 Column Level의 보안을 지원하지 않는다. 따라서 Column Level의 보안과 Row Level의 보안이 요구되는 업무환경에서는 View 와의 적절한 역할분담을 통해 구현하는 것이 좋을 것이다.

 

셋째, 단일 Transaction 내에서 Policy 정책의 일관성 유지가 반드시 보장되어야 한다.

 

단일 트랜잭션 내에서 Policy 정책이 변화게 되면 올바른 결과를 보장하지 못하므로, PL/SQL 이나 Pro*C 등으로 복잡한 Business Logic을 구현하는 경우 Policy 정책이 변화되지 않도록 주의해야 한다.

 

이 부분에 대해서는 Oracle Bug가 아닐까 판단되며, Oracle 9i 에서도 똑같은 문제점을 지니고 있지만 향후 버전에서는 이 문제가 해결될 것이다.

 

넷째, UPDATE_CHECK option 에 따른 DML 수행결과의 차이점을 이해하고 있어야 한다.

 

위에서 구현했던 보안정책으로 그 차이점을 이해해보자. Scott 유저로 Login하여 EMP 테이블을 select 하게되면 ename이 scott인 하나의 row만 보게될 것이다. 여기서 만일 다음과 같은 update 문이나 Insert 문을 실행한다면 어떻게 될까?

 

UPDATE emp
SET ename = ’SCOTT2’
WHERE ename = ‘SCOTT’
또는
INSERT INTO emp(ename) VALUES (‘SCOTT3’);

 

위와 같은 쿼리문이 실행되었을 경우, 보안정책으로 따져본다면 모두 에러가 발생해야 될 것이다. 그러나 UPDATE_CHECK option 이 'FALSE'로 셋팅되어 있었다면 두 문장 모두 에러없이 수행된다. 물론 select 했을 경우, 보안정책에 위배되기 때문에 볼수는 없다. 하지만 결과야 어찌되었던 중요한 것은 'FALSE'로 했을 경우 잘못하면 보안정책에 구멍이 생길 수도 있으므로, 되도록이면 UPDATE_CHECK option 은 'TRUE'로 셋팅해 주는 것이 좋을 것이다. 참고로, 디폴트는 'FALSE'이다.

 

다섯째, 보안정책을 고려한 인덱스 전략을 수립해야 한다.

 

앞에서 살펴보았듯이 Fine-Grained Access Control 의 동작원리는 실행시 WHERE 조건절에 보안정책을 적용하는 Dynamic Modify 기법이다. 따라서 실제로 오라클이 수행하는 쿼리문은 우리가 던진 쿼리문에 보안정책이 적용된 쿼리문인 것이다. 만일 이런 원리를 이해하지 못하고, 단순히 사용자가 작성한 쿼리문만으로 튜닝작업을 한다면 엉뚱한 Access Path로 인해 튜닝한 효과를 보지못하는 경우를 만나게 될 것이다. 그러므로 인덱스 전략 수립시, 반드시 보안정책을 숙지한 후 인덱스 전략 수립에 들어가야 할 것이다.

 

[유저 쿼리문]
   SELECT * FROM emp;
 
[실행계획]
   Excution Plan 
   -------------------------------------------------- 
   SELECT STATEMENT                   Hint=HINT: RULE   
   +--TABLE ACCESS BY INDEX ROWID     EMP 
      +-- INDEX UNIQUE SCAN           IND_ENAME_EMP

 

보안정책에 의해 Predicate 될 조건절을 생각치 못한다면 이 현상을 어떻게 설명

할 것인가?

 

 
[실제 실행된 쿼리문]
   SELECT * FROM emp
   WHERE ename=USER; -- emp 테이블의 ename 컬럼에 ind_ename_emp 인덱스존재

 

여섯째, AFTER logon Trigger 를 이용하면 좀더 유연한 보안정책을 구현할 수 있다.

 

이번 항목은 주의사항이라기 보다는 팁에 해당한다. 효율적인 보안정책의 구현은 우선 개발자의 능력에 따라 좌우되겠지만, 그 능력과 더불어 DBMS가 제공해주는 다양한 기능들을 활용하게 된다면 좀더 다양하고 강력한 보안정책을 펼칠 수 있을 것이다.

 

CREATE OR REPLACE TRIGGER app_logon_trigger
AFTER logon 
ON database
-- ON scott.schema
BEGIN
   scott.set_secure_emp ;
END;
/         

 

지금까지 2회에 걸쳐 Fine-Grained Access Control 에 대해 알아보았다.

 

지난 글에서 말씀드린바와 같이 Security가 중시되는 환경에서 Fine-Grained Access Control 은 사용자로 하여금 손쉽게 보안정책을 펼칠 수 있도록 도와준다. 비록 아직까진 많은 부분에서 미숙하지만, 그런 부분들은 여러분들의 능력을 십분 발휘함으로써 충분히 해결할 수 있을 것이다. 그러므로 많은 독자들이 이 기능의 잠재력을 인지하고 현업에 활용하기 위해 노력하기를 바란다. 지면관계상 Application context 를 이용한 보안구현방법이나 import/export 시의 보안정책, Predicate를 확인하기 위한 V$VPD_POLICY과 이벤트 트레이스 방법(set events '10730') 등 많은 부분을 설명드리지 못하여 아쉽지만 이 부분에 대해서는 향후 다른 루트를 통해 자료를 제공할 것을 약속드리며 이것으로 Fine-Grained Access Control 에 대한 연재를 마치고자 한다.

 

 

다음 연재부터는 VLDB에서 위용을 떨치고 있는 Partitioning에 대해 설명될 것이다.

[Top]
No.
제목
작성자
작성일
조회
454Partitioned Table의 Index
정재익
2002-07-16
8897
453파티션키(Partition Key)의 선정
정재익
2002-07-16
7717
452파티션의 개념 및 소개
정재익
2002-07-16
6270
450Fine-Grained Access Control
정재익
2002-07-13
6048
449Data Warehouse 환경에서의 Star Transformation 기술 활용
정재익
2002-07-13
6610
448Bitmap Index에 대한 이해 및 소개
정재익
2002-07-13
8460
437데이터 모델링 강좌(11)
정재익
2002-07-12
5995
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2023 DSN, All rights reserved.
작업시간: 0.048초, 이곳 서비스는
	PostgreSQL v16.1로 자료를 관리합니다