12. 보안과 권한 관리 - 접근 제어, GRANT/REVOKE, Role

 

💡 1분 핵심 요약 (TL;DR)

• ✅ DB 보안 3요소 — 물리적 환경 보안, 권한 관리 보안, 운영 관리 보안
• ✅ 접근 제어 — 로그인(계정 확인) → 권한 확인, 두 단계로 데이터베이스 접근을 통제
• ✅ GRANT / REVOKE — 객체·시스템 권한을 부여하고 취소하는 SQL 명령어, CASCADE·RESTRICT로 연쇄 취소 여부 결정
• ✅ 역할(Role) — 여러 권한을 묶어둔 바구니, 사용자 여러 명에게 한 번에 부여·취소 가능

 

데이터베이스에는 회원 정보, 매출 데이터처럼 아무나 봐서는 안 될 정보가 잔뜩 들어있습니다. 그래서 누가, 어떤 테이블에, 무슨 작업까지 할 수 있는지를 세밀하게 통제하는 권한 관리가 필요합니다. 이번 포스팅에서는 데이터베이스 보안의 목표부터, GRANT·REVOKE로 권한을 주고 뺏는 방법, 그리고 여러 권한을 묶어 편하게 관리하는 역할(Role)까지 정리했습니다.

 

 

 

01 데이터베이스 보안의 목표

허가된 사용자만 접근하도록 통제하는 3가지 축

 

📖 데이터베이스 보안이란?
조직에서 허가한 사용자만 데이터베이스에 접근할 수 있도록 통제하여 보안을 유지하는 것입니다. 보호 대상에 따라 세 가지 축으로 나뉩니다.

 

구분	무엇으로부터 보호?	설명
물리적 환경 보안	자연 재해 등	자연 재해처럼 데이터베이스에 물리적 손실을 발생시키는 위험으로부터 보호
권한 관리 보안	권한이 없는 사용자	계정이 발급된 사용자만 접근하도록 통제하고, 사용자별 사용 범위와 작업 내용을 제한
운영 관리 보안	권한이 있는 사용자	접근이 허락된 사용자가 사용하는 동안 데이터 무결성이 유지되도록 제약조건을 정의하고 위반하지 않도록 통제

※ 권한이 없는 사용자로부터 보호하는 것이 '보안'이고, 권한이 있는 사용자의 실수로부터 데이터 정확성을 지키는 것은 '무결성'입니다 — 이 둘을 헷갈리지 않는 게 중요합니다.

 

 

📖 참고 : 데이터 프라이버시(Privacy)
최근에는 여기에 더해 데이터 프라이버시 개념도 함께 강조됩니다. 이는 데이터에 접근할 권한이 있는 사람이라 할지라도, 주민번호 같은 민감한 개인정보를 함부로 노출하거나 가공하지 않도록 관리하는 좀 더 넓은 의미의 보안 개념입니다.

 

 

 

02 권한 관리의 개념 — 접근 제어

로그인 확인 후 권한까지 확인하는 2단계 통제

 

📖 접근 제어(access control)
계정이 발급된 사용자가 로그인에 성공했을 경우에만 데이터베이스 접근을 허용하는 것입니다. 사용자 계정 관리는 데이터베이스 관리자(DBA)가 담당합니다. 로그인에 성공한 사용자라도 허용된 권한 내에서만 데이터베이스를 사용할 수 있으며, 보안을 위한 데이터 단위는 데이터베이스 전체부터 특정 테이블의 특정 행·열, 심지어 특정 데이터 값까지 다양하게 지정할 수 있습니다.

 

사용자가 DB에 접근하는 과정은 ① 로그인 → ② 권한 확인 두 단계를 거칩니다.

 

사용자

→ ① 로그인 →

계정 확인

→ ② 권한 확인 →

허가된 테이블 (허가/거부)

예) 로그인에 실패하면 그 단계에서 접근이 거부되고, 로그인에 성공해도 해당 테이블에 권한이 없으면 두 번째 단계에서 접근이 거부됩니다.

 

 

 

 

03 객체 권한 부여 — GRANT

테이블 소유자가 다른 사용자에게 사용 권한을 나눠주는 법

 

GRANT 기본 문법

GRANT 권한 ON 객체 TO 사용자 [WITH GRANT OPTION];

 

📖 문법 포인트
· 객체의 소유자가 다른 사용자에게 사용 권한을 부여
· 부여 가능한 주요 권한 : INSERT, DELETE, UPDATE, SELECT, REFERENCES (REFERENCES는 외래키 제약조건을 정의할 수 있는 권한)
· UPDATE·SELECT는 테이블의 일부 속성에만 권한 부여 가능, 여러 권한을 한 번에 부여 가능
· PUBLIC : 특정 사용자 대신 이 키워드를 쓰면 모든 사용자에게 동일하게 권한 부여
· WITH GRANT OPTION : 권한을 받은 사용자가 그 권한을 다른 사용자에게도 다시 부여할 수 있게 함

 

예제로 하나씩 확인해보겠습니다.

 

예제 11-1) 고객 테이블 검색 권한을 Hong에게 부여

GRANT SELECT ON 고객 TO Hong;

 

예제 11-2) 고객 테이블 삽입·삭제 권한을 모든 사용자에게 부여

GRANT INSERT, DELETE ON 고객 TO PUBLIC;

 

예제 11-3) 고객 테이블의 등급·적립금 속성만 수정 권한을 Park에게 부여

GRANT UPDATE(등급, 적립금) ON 고객 TO Park;

 

예제 11-4) 고객 테이블 검색 권한을 WITH GRANT OPTION과 함께 Lee에게 부여

GRANT SELECT ON 고객 TO Lee WITH GRANT OPTION;

→ Lee는 이제 이 SELECT 권한을 자기 자신뿐 아니라 다른 사용자에게도 다시 부여할 수 있습니다.

 

⚠️ 보안 팁 : WITH GRANT OPTION은 신중하게
이 옵션은 편리하지만 보안 관리의 통제력을 낮추는 강력한 기능이기도 합니다. 권한을 위임할 수 있는 권한까지 함께 주는 것이므로, 위임받은 사용자가 의도치 않게 혹은 악의적으로 권한을 무한히 퍼뜨릴 수 있습니다. 실무에서는 위임이 꼭 필요한 경우가 아니라면 이 옵션의 사용을 최소화하거나 금지하는 것이 원칙입니다.

 

 

 

04 시스템 권한 부여와 권한 취소 — REVOKE

CASCADE와 RESTRICT로 연쇄 취소 여부 결정

 

📖 시스템 권한 vs 객체 권한
시스템 권한은 CREATE TABLE, CREATE VIEW처럼 데이터베이스 관리와 관련된 DDL 권한으로, 데이터베이스 관리자(DBA)가 부여하며 객체를 지정할 필요가 없습니다. 앞서 다룬 객체 권한(INSERT·SELECT 등)은 특정 테이블 등 객체를 대상으로 소유자가 부여합니다.

 

예제 11-5) 테이블 생성 시스템 권한을 Song에게 부여

GRANT CREATE TABLE TO Song;

 

부여한 권한을 되돌리고 싶다면 REVOKE문을 사용합니다.

 

REVOKE 기본 문법 (객체 권한 취소)

REVOKE 권한 ON 객체 FROM 사용자 CASCADE | RESTRICT;

 

사용자 A가 B에게, B가 다시 C에게 같은 권한을 부여한 상황에서 A가 B의 권한을 취소하면, C에게 부여됐던 권한은 어떻게 될까요? 이때 선택하는 옵션이 CASCADE와 RESTRICT입니다.

 

옵션	동작
CASCADE	A가 B의 권한을 취소하면, B가 C에게 부여한 권한도 연쇄적으로 함께 취소
RESTRICT	A가 B의 권한을 취소해도, C가 부여받은 권한은 취소하지 않음

 

 

예) Kim이 Hong에게, Hong이 다시 Park에게 고객 테이블 검색 권한을 부여한 상황을 가정해보겠습니다.

 

예제 11-7) Hong의 권한을 취소하면서 Park의 권한도 함께 취소

REVOKE SELECT ON 고객 FROM Hong CASCADE;

 

예제 11-8) Hong이 다른 사용자에게 권한을 부여한 적이 없을 때만 Hong의 권한 취소

REVOKE SELECT ON 고객 FROM Hong RESTRICT;

→ 만약 Hong이 이미 Park에게 권한을 넘겨준 상태라면, RESTRICT 옵션 때문에 이 REVOKE문 자체가 실행되지 않고 오류가 납니다.

 

예제 11-9) Hong에게 부여한 테이블 생성 시스템 권한 취소

REVOKE CREATE TABLE FROM Hong;

시스템 권한 취소는 특정 객체에 대한 취소가 아니므로 객체를 지정할 필요가 없습니다.

 

지금까지의 권한 부여 내역을 정리한 권한 목록은 아래처럼 한눈에 확인할 수 있습니다.

 

사용자	고객 테이블에 대한 권한
Kim	소유자
Hong	INSERT / DELETE / SELECT
Park	INSERT / DELETE / UPDATE(등급, 적립금)
Lee	INSERT / DELETE / SELECT (WITH GRANT OPTION)

 

 

 

05 역할(Role) — 권한을 담아두는 바구니

여러 사용자에게 여러 권한을 한 번에 부여·취소하기

 

📖 역할 기반 접근 제어 (RBAC, Role-Based Access Control)
사용자 개개인에게 권한을 직접 부여하면 관리가 매우 복잡하고 오류가 발생하기 쉽습니다. 이를 해결하기 위해 사용자의 '역할(Role)'에 권한을 부여하고, 사용자에게는 그 역할을 부여하는 모델을 RBAC(Role-Based Access Control)이라 하며, 현재 대부분의 기업용 DBMS가 채택하고 있는 보안 관리의 표준입니다.

 

📖 역할(role)이란?
여러 권한을 그룹으로 묶어놓은 것, 쉽게 말해 '권한들을 넣어둔 바구니'입니다.

 

왜 역할이 필요할까요? Kim이 자신의 고객 테이블에 대한 검색·삽입·삭제 권한을 Hong, Park, Lee 세 명에게 모두 부여하려면, 역할 없이는 아래처럼 9줄의 GRANT문을 일일이 작성해야 합니다.

 

⚠️ 역할 없이 권한을 하나하나 부여하면?
GRANT SELECT, INSERT, DELETE ON 고객 TO Hong;
GRANT SELECT, INSERT, DELETE ON 고객 TO Park;
GRANT SELECT, INSERT, DELETE ON 고객 TO Lee;
→ 사용자 수만큼, 권한 수만큼 반복해야 해서 새 권한이 추가되면 모든 사용자에게 일일이 다시 부여해야 하는 번거로움이 있습니다.

 

역할을 이용하면 여러 권한을 역할에 미리 담아두고, 역할 자체를 사용자에게 부여하는 것만으로 끝납니다. 나중에 권한이 추가되거나 취소되면, 그 역할을 부여받은 모든 사용자에게 변화가 그대로 전달되어 관리가 훨씬 쉬워집니다.

 

역할을 생성하고 활용하는 전체 흐름은 다음과 같습니다.

 

① 역할 생성

→

② 역할에 권한 추가

→

③ 사용자에게 역할 부여

→

④ 역할 취소 / 제거

 

예제 11-10) role_1 이라는 이름의 역할 생성 (담당 : DB 관리자)

CREATE ROLE role_1;

 

예제 11-11) 고객 테이블 검색·삽입·삭제 권한을 role_1에 담기 (담당 : 객체 소유자)

GRANT SELECT, INSERT, DELETE ON 고객 TO role_1;

이후 Hong·Park·Lee에게는 각각 GRANT role_1 TO Hong; 처럼 역할 하나만 부여하면 세 가지 권한이 한 번에 전달됩니다.

 

예제 11-13) Hong에게 부여한 role_1 역할 취소 (담당 : DB 관리자)

REVOKE role_1 FROM Hong;

 

예제 11-14) role_1 역할 자체를 제거 (담당 : DB 관리자)

DROP ROLE role_1;

역할을 제거하면, 그 역할을 부여받았던 모든 사용자의 관련 권한이 한꺼번에 취소됩니다.

 

 

📌 핵심 정리

· DB 보안 3요소 : 물리적 환경 보안(자연재해), 권한 관리 보안(권한 없는 사용자), 운영 관리 보안(권한 있는 사용자의 무결성 위반) + 데이터 프라이버시(권한 있는 사용자로부터도 민감정보를 보호)
· 접근 제어 : 로그인 확인 → 권한 확인, 2단계로 접근 통제
· GRANT : 객체 권한(소유자가 부여, INSERT/DELETE/UPDATE/SELECT/REFERENCES)과 시스템 권한(DBA가 부여, CREATE TABLE 등)으로 구분. WITH GRANT OPTION은 통제력을 낮추는 기능이므로 신중히 사용
· REVOKE ... CASCADE/RESTRICT : 연쇄 취소 여부를 결정 — CASCADE는 하위 권한까지 함께 취소, RESTRICT는 하위 권한이 있으면 취소 자체가 거부됨
· 역할(Role) : RBAC(역할 기반 접근 제어) 모델의 실제 구현. CREATE ROLE로 생성 → GRANT로 권한 추가 → 사용자에게 역할 부여 → REVOKE/DROP ROLE로 취소·제거, 여러 사용자·권한을 한 번에 관리 가능

 

 

태그 : 데이터베이스 보안 목표접근 제어 access controlGRANT 문법 객체권한WITH GRANT OPTIONREVOKE CASCADE RESTRICT시스템 권한 객체 권한 차이역할 Role 개념CREATE ROLE DROP ROLE권한 목록 관리보안 무결성 차이RBAC 역할기반접근제어데이터 프라이버시