왜 DB 접근통제를 별도로 다루는가

09편에서 애플리케이션 계정에도 최소 권한 원칙을 적용해야 한다고 정리했습니다. 이 편은 그 원칙을 실제로 어떤 모델로, 어떤 SQL 문법으로 구현하는가까지 파고듭니다. 정보보호 시험에서 접근통제 모델(DAC·MAC·RBAC)은 14편(시스템 전반의 인증·접근통제)에서도 다루지만, 이 편에서는 그 모델들을 데이터베이스라는 구체적인 대상에 적용했을 때의 SQL 구현과 함께 봅니다. 개인정보가 저장된 테이블일수록 “누가, 어떤 조건으로, 무엇을 볼 수 있는가”를 정밀하게 통제해야 하기 때문에, DB 접근통제는 개인정보보호법(15편)과도 직결되는 실무·시험 양쪽의 핵심 주제입니다.

쉽게 말하면: 접근통제 모델은 “누가 문의 열쇠를 나눠줄 권한을 갖는가”에 대한 규칙이고, 이 편에서 다루는 SQL 문법은 그 규칙을 데이터베이스 안에서 실제로 켜고 끄는 손잡이입니다.

1. 접근통제 모델 세 가지 비교 — DAC·MAC·RBAC

접근통제(Access Control)는 주체(사용자·프로세스)가 객체(파일·테이블 등)에 접근할 수 있는지를 결정하는 메커니즘입니다. 이 메커니즘을 누가, 어떤 기준으로 설계하느냐에 따라 세 가지 모델로 나뉩니다.

2. Oracle SQL로 보는 계정·권한 관리

이제 위 모델, 특히 실무 DB에서 가장 널리 쓰이는 RBAC를 Oracle SQL 문법으로 직접 구현해 봅니다.

계정 생성과 기본 권한 부여

-- 1. 계정 생성
CREATE USER app_user IDENTIFIED BY "안전한비밀번호123!";
 
-- 2. 접속 권한 부여 (Oracle은 접속조차도 별도 권한이 필요하다)
GRANT CREATE SESSION TO app_user;
 
-- 3. 특정 테이블에 대한 최소한의 권한만 부여 (최소 권한 원칙)
GRANT SELECT, INSERT ON orders TO app_user;

GRANT 문은 특정 계정(또는 역할)에게 특정 객체에 대한 특정 동작 권한을 부여하는 명령어입니다. 이 예시에서 app_user 계정은 orders 테이블에 대해 조회(SELECT)와 삽입(INSERT)만 할 수 있고, 삭제(DELETE)나 구조 변경(ALTER)은 할 수 없습니다. 이것이 09편에서 다룬 최소 권한 원칙의 실제 SQL 구현입니다.

역할(Role) 생성과 부여 — RBAC의 실제 구현

-- 1. 역할 생성
CREATE ROLE sales_viewer;
 
-- 2. 역할에 권한 묶어서 부여
GRANT SELECT ON customers TO sales_viewer;
GRANT SELECT ON orders TO sales_viewer;
 
-- 3. 사용자에게 역할 부여 (권한 하나하나가 아니라 역할 하나로 한 번에)
GRANT sales_viewer TO app_user;

신규 계정이 100개 생겨도 GRANT sales_viewer TO 신규계정; 한 줄이면 그 계정은 고객·주문 테이블을 조회할 수 있는 권한을 즉시 갖게 됩니다. 권한이 바뀌어야 할 때도 역할 하나만 수정하면 그 역할을 가진 모든 계정에 자동 반영되므로, 계정별로 권한을 일일이 수정하는 DAC적 관리 방식보다 관리 부담이 크게 줄어듭니다.

권한 회수

-- 특정 권한만 회수
REVOKE INSERT ON orders FROM app_user;
 
-- 역할 자체를 회수
REVOKE sales_viewer FROM app_user;

REVOKE는 GRANT의 반대 동작으로, 이미 부여한 권한이나 역할을 거둬들입니다. 계정의 직무가 바뀌거나 퇴사할 경우 04편에서 다룬 계정 라이프사이클 관리의 일환으로 즉시 실행되어야 하는 명령입니다.

3. 뷰(View)를 이용한 개인정보 보호

뷰(View)는 하나 이상의 테이블에서 특정 컬럼·행만 뽑아 마치 하나의 가상 테이블처럼 보여주는 객체입니다. 뷰는 접근통제의 관점에서 매우 중요한 도구인데, 사용자에게 원본 테이블 전체가 아니라 뷰를 통해 제한된 컬럼·행만 노출시킬 수 있기 때문입니다.

-- 원본 테이블: members (id, name, ssn, phone, address, email)
-- 콜센터 상담원에게는 주민등록번호(ssn)를 제외하고 노출
CREATE VIEW members_for_agent AS
SELECT id, name, phone, email
FROM members;
 
-- 콜센터 상담원 계정에는 원본 테이블이 아니라 뷰에 대한 권한만 부여
GRANT SELECT ON members_for_agent TO call_center_agent;

이렇게 하면 콜센터 상담원 계정은 members 원본 테이블에 대한 권한이 아예 없으므로, SELECT * FROM members를 직접 시도해도 권한 오류가 발생합니다. 오직 members_for_agent 뷰를 통해서만 조회할 수 있고, 그 뷰에는 애초에 민감정보인 주민등록번호(ssn) 컬럼이 존재하지 않습니다.

마스킹과 암호화의 보완 관계

뷰가 “컬럼 자체를 아예 안 보여주는” 방식이라면, 데이터 마스킹(Data Masking)은 컬럼은 보여주되 값의 일부를 가리는 방식입니다.

-- 전화번호 뒷자리를 마스킹해서 보여주는 뷰
CREATE VIEW members_masked AS
SELECT id,
       name,
       SUBSTR(phone, 1, 7) || '****' AS phone_masked
FROM members;

위 예시는 Oracle의 문자열 함수 SUBSTR(문자열 자르기)과 문자열 연결 연산자 ||를 이용해, 전화번호의 앞 7자리만 보여주고 나머지는 ****로 가린 결과를 뷰로 제공합니다. 원본 테이블에는 전화번호 전체가 그대로 저장되어 있지만, 이 뷰를 조회하는 사용자에게는 마스킹된 값만 노출됩니다.

민감정보 보호의 마지막 층은 암호화(Encryption, 06~07편에서 다룬 암호 기술)로, 저장 자체를 암호화된 형태(예: 컬럼 암호화)로 해 두어 DB 파일에 직접 접근하는 공격(예: 백업 파일 탈취)에도 대비하는 방식입니다. 뷰·마스킹이 “권한 없는 사용자의 조회 화면”을 통제하는 층이라면, 암호화는 “저장 매체 자체가 탈취되었을 때”를 대비하는 마지막 층으로 서로 보완 관계에 있습니다.

4. 로깅·감사를 통한 추적성 확보

접근통제가 “누가 접근할 수 있는가”를 사전에 결정하는 일이라면, 감사(Audit)는 “실제로 누가 언제 무엇을 했는가”를 사후에 확인할 수 있게 기록하는 일입니다. 이 기록이 있어야만 사고 발생 시 원인을 추적(Traceability, 추적성)할 수 있습니다.

-- 특정 테이블에 대한 SELECT 작업을 감사 로그로 남기도록 설정
AUDIT SELECT ON members BY ACCESS;
 
-- 감사 로그 조회 (Oracle 표준 감사 뷰)
SELECT username, obj_name, action_name, timestamp
FROM dba_audit_trail
WHERE obj_name = 'MEMBERS';

AUDIT 문은 지정한 테이블에 대한 특정 동작(위 예시는 SELECT)이 발생할 때마다 그 사실을 감사 로그에 남기도록 설정합니다. 이렇게 쌓인 로그는 dba_audit_trail 같은 감사용 뷰를 통해 “누가(username), 어떤 객체에(obj_name), 어떤 동작을(action_name), 언제(timestamp)” 수행했는지 조회할 수 있게 해 줍니다.

핵심 정리

• DAC는 객체 소유자가, MAC는 시스템(정책)이, RBAC는 역할을 통해 권한을 결정한다는 것이 세 모델을 가르는 핵심 기준이다.
• Oracle SQL에서 GRANT/REVOKE로 권한을 주고 거두며, CREATE ROLE로 역할을 만들어 다수 계정에 한 번에 권한을 적용하는 것이 RBAC의 실제 구현이다.
• 계정 생성만으로는 로그인이 되지 않으며 CREATE SESSION 권한이 별도로 필요하다.
• 뷰(View)는 컬럼·행을 제한해 원본 테이블을 감추는 가상 테이블이며, 마스킹은 값의 일부를 가리고, 암호화는 저장 매체 탈취에 대비하는 마지막 층으로 서로 보완 관계에 있다.
• 감사(Audit)는 접근통제(사전 예방)와 달리 사후 추적성을 확보하는 통제이며, AUDIT 문과 dba_audit_trail 뷰로 구현한다.

마무리 복습

CREATE USER app_user ...;

-- app_user로 접속 시도
SELECT * FROM orders;

참고 자료

• Oracle 공식 문서 - Database Security Guide 
• 행정안전부·한국인터넷진흥원(KISA) - DB 접근통제·개인정보 DB 보호조치 가이드