RLS(Row Level Security), 행 수준 보안

접근 제어

RDBMS를 다루며, 보안과 접근 제어는 떼어놓을 수 없다.
가장 크게는 MAC, DAC, RBAC으로 구분되는데

1. MAC

• 정책과 규칙에 의한, 시스템 중앙 통제식 접근 제어

2. DAC

• 사용자가 객체(자원)에 대한 접근 권한 결정

3. RBAC

• 사용자의 역할을 기반으로 하는 접근 제어

로 이해할 수 있다.

그럼 오늘 알아보고자 하는 RLS는 무엇일까?

---

RLS

RLS : Row Level Security이란,
사용자별로 테이블의 특정 행에 대한 접근을 제어하는 것이다.

쉽게 말해, RBAC이라는 문을 통과한 사용자에게 방 안의 특정 물건(정보)를 필터링해서 보여주는 역할을 한다.

동일한 테이블(EMPLOYEE)에서 접속한 사람의 권한에 따라 누구는 SALARY컬럼이 보이고, 누구는 보이지 않는 기술이다.

Oracle에선 이를 VPD : Virtual Private Database라고도 한다.

---

RLS 동작 원리

1. DML 쿼리에 따라, Oracle은 해당 테이블에 연결된 보안 정책을 파악하고 자동으로 실행한다.
2. 이때, Policy Function이라는 정책 함수를 호출해 Predicate(술어), 즉 WHERE절의 조건문을 동적으로 생성한다.
3. 생성된 동적 조건문을 기존 DML문에 덧붙여 결과 데이터를 필터링한다.

한 마디로 요약하자면,
DML 실행에 동적 WHERE절을 추가하는 것과 같다.

---

RLS 구성 요소

1. 정책 함수 : Policy Function
   동적으로 WHERE 조건을 생성하는 PL/SQL 함수.
   사용자 세션 정보를 활용해 필터링 조건 결정

2. 정책 : Policy
   DBMS_RLS 패키지를 사용해 생성하며, 특정 테이블(뷰)에 정책 함수를 연결하는 역할.
   어떤 DML에 정책을 적용할지, 어떤 정책 함수를 사용할지 등을 정의

3. 애플리케이션 컨텍스트 : Application Context
   RLS정책이 참조할 수 있는 사용자별 세션 정보
   (저장하는 메모리 공간)

사용 예시)

SCOTT.EMP에 접근 시, deptno에 따라 정보 조회 제어

-- 1. 애플리케이션 컨텍스트 생성
CREATE OR REPLACE CONTEXT emp_ctx USING emp_pkg;

-- 2. 컨텍스트 값을 설정하는 패키지 생성
CREATE OR REPLACE PACKAGE emp_pkg IS
  PROCEDURE set_dept;
END;
/
CREATE OR REPLACE PACKAGE BODY emp_pkg IS
  PROCEDURE set_dept AS
    v_deptno NUMBER;
  BEGIN
    SELECT deptno INTO v_deptno FROM emp
    WHERE empno = SYS_CONTEXT('USERENV', 'SESSION_USERID');
    DBMS_SESSION.SET_CONTEXT('emp_ctx', 'deptno', v_deptno);
  EXCEPTION
    WHEN NO_DATA_FOUND THEN NULL;
  END set_dept;
END;
/

-- 3. 로그온 트리거를 사용하여 로그인 시 컨텍스트 값 설정
CREATE OR REPLACE TRIGGER set_dept_ctx_trig
  AFTER LOGON ON DATABASE
BEGIN
  emp_pkg.set_dept;
END;
/

-- 4. 정책 함수 생성
CREATE OR REPLACE FUNCTION emp_policy_func (
  p_schema IN VARCHAR2,
  p_object IN VARCHAR2
) RETURN VARCHAR2 AS
  v_deptno VARCHAR2(20);
BEGIN
  v_deptno := SYS_CONTEXT('emp_ctx', 'deptno');
  RETURN 'deptno = ' || v_deptno;
END;
/

-- 5. 정책 적용
BEGIN
  DBMS_RLS.ADD_POLICY (
    object_schema    => 'SCOTT',
    object_name      => 'EMP',
    policy_name      => 'emp_dept_policy',
    function_schema  => 'SYS',
    policy_function  => 'emp_policy_func'
  );
END;
/

---

장점

1. 애플리케이션 단순화
   : 애플리케이션 로직의 수정 없이, 데이터베이스 수준에서 정교한 데이터 접근 통제가 가능해진다.

2. 보안성 강화
   : DB수준에서의 접근 제어

3. 투명성
   : 사용자는 RLS의 존재를 인지하지 못하며, 애플리케이션 변경 없이 보안 적용 가능

4. 중앙 관리
   : 보안 정책이 DB에 중앙 집중화 -> 일관성 있는 관리 가능

---

고려 사항

1. 성능 영향 파악
   : 모든 쿼리에 정책 함수가 실행되므로, 로직이 복잡해질 수록 성능 저하를 유발한다.

2. 설계 복잡성 증가
   : 정교한 접근 제어를 위해 완성도 높은 정책 설계가 필수적이다.

3. 디버깅
   : RLS로 인해 발생하는 문제는 원인 파악이 어렵다.

---

마치며...

오늘은 이렇게 Oracle에서 접근 제어의 일종인 RLS에 대해 알아보았다.

현재 회사 실무에서 RLS를 적용할 일은 사실상 없다.
다만, 데이터가 훨씬 많고 IT 팀이 훨씬 큰 규모로 운영되는 기업이거나,
SI 기업처럼 각 팀에서 사용하는 데이터가 전부 다르지만, 공통 데이터(인사, 재무 등)을 통합 관리하는 경우에서는
DBA 혹은 보안 책임자의 역할에서 충분히 고려해야 될 사항이라고 생각된다.

DB는 알면 알수록 더 어렵지만, 알아가는 재미가 있다.