Notes

DB 10. 보안과 권한 관리

DBMS 보안의 기본 관점, GRANT/REVOKE 기반 권한 관리, role, Oracle의 시스템 권한과 객체 권한을 정리한 학습 노트

Published: May 31, 2026
Updated: May 31, 2026
Area: Databases
Type: concept
Series: Database Systems
Category: Notes

database-securityaccess-controlgrantrevokeroleoracleprivilege-management

데이터베이스 보안과 권한 관리

데이터베이스 보안은 단순히 계정과 비밀번호를 설정하는 문제가 아니다. 데이터베이스가 손실되거나, 권한 없는 사용자가 접근하거나, 정상 사용자의 실수로 데이터 무결성이 깨지는 상황을 모두 고려해야 한다.

이 글은 데이터베이스 보안을 다음 흐름으로 정리한다.

데이터베이스 보안의 기본 유형
DBMS가 제공해야 하는 보안 기능
GRANT / REVOKE 기반 권한 관리
role을 이용한 권한 관리 단순화
Oracle의 시스템 권한과 객체 권한
Oracle에서 권한을 확인하고 사용하는 방식

1. 데이터베이스 보안의 기본 관점

데이터베이스는 조직의 핵심 데이터를 저장한다. 따라서 데이터베이스가 손실되면 조직 운영에 큰 문제가 생길 수 있다. DBMS는 권한이 없는 사용자로부터 데이터베이스를 보호하고, 권한이 있는 사용자도 허가된 범위 안에서만 작업하도록 통제해야 한다.

기본적으로 어떤 사용자가 릴레이션을 생성하면 그 릴레이션의 생성자, 즉 소유자만 접근할 수 있다. 다른 사용자가 접근하려면 생성자나 관리자로부터 권한을 받아야 한다.

객체 생성자(owner) → 권한 허가 → 다른 사용자 접근 가능

공유 데이터베이스에서는 여러 사용자가 같은 릴레이션에 접근해야 하는 경우가 많다. 이때 모든 사용자에게 동일한 권한을 주는 것이 아니라, 사용자별 또는 역할별로 필요한 권한만 허가해야 한다.

2. 세 가지 유형의 보안

데이터베이스 보안은 크게 물리적 보호, 권한 보호, 운영 보호로 나눌 수 있다.

구분	보호 대상	핵심 의미	예
물리적 보호	서버, 저장장치, 물리적 환경	자연 재해, 도난, 장비 손상으로부터 데이터베이스 보호	화재, 홍수, 지진, 서버실 출입 통제, 백업
권한 보호	사용자 접근 권한	권한을 가진 사용자만 특정 접근 모드로 데이터베이스 접근	`SELECT`, `INSERT`, `UPDATE`, `DELETE` 권한
운영 보호	데이터 무결성	사용자 실수로 인한 데이터 무결성 훼손 최소화	트랜잭션, 제약조건, 로그, 복구

2.1 물리적 보호

물리적 보호는 화재, 홍수, 지진 같은 자연 재해나 도난, 컴퓨터 시스템 손상으로부터 데이터베이스를 보호하는 것이다.

이 관점에서는 SQL 권한보다 서버실, 저장장치, 백업 정책, 장애 대비 구조가 중요하다.

2.2 권한 보호

권한 보호는 권한을 가진 사용자만 특정한 접근 모드로 데이터베이스에 접근하도록 하는 것이다.

예를 들어 어떤 사용자는 조회만 가능하고, 어떤 사용자는 삽입과 수정까지 가능하며, 관리자는 삭제까지 가능할 수 있다.

조회 가능 ≠ 삽입 가능 ≠ 수정 가능 ≠ 삭제 가능

각 작업은 별도의 권한으로 관리된다.

2.3 운영 보호

운영 보호는 정상 사용자의 실수로 데이터베이스 무결성이 훼손되는 것을 막는 조치다.

예를 들어 존재하지 않는 부서 번호를 직원 테이블에 입력하거나, 급여를 음수로 입력하거나, 기본 키가 중복되는 상황을 막아야 한다. 이를 위해 DBMS는 제약조건, 트랜잭션, 로그, 복구 기능 등을 제공한다.

3. DBMS가 제공해야 하는 보안 기능

DBMS가 제공해야 하는 보안 기능은 크게 access control과 security / privilege management로 나눌 수 있다.

기능	질문	설명
`access control`	누가 DBMS에 접속할 수 있는가?	계정과 암호를 관리하고 로그인 과정을 통제
`security / privilege management`	접속한 사용자가 무엇을 할 수 있는가?	특정 사용자 또는 사용자 그룹이 지정된 데이터베이스 영역만 접근하도록 통제

3.1 Access Control

access control은 데이터베이스 시스템에 대한 접근 자체를 통제하는 기능이다.

사용자가 데이터베이스에 접속하려면 계정과 암호가 필요하다. DBMS는 로그인 과정에서 사용자가 정당한 사용자인지 확인한다.

계정 없음 → 접속 불가
계정 있음 + 로그인 권한 있음 → DBMS 접속 가능

3.2 Security and Privilege Management

접속에 성공했다고 해서 모든 데이터를 볼 수 있는 것은 아니다. 로그인 이후에는 사용자가 어떤 객체에 대해 어떤 연산을 수행할 수 있는지 권한을 검사해야 한다.

예를 들어 LEE라는 사용자가 Oracle에 접속할 수 있더라도, KIM.EMPLOYEE 테이블에 대한 SELECT 권한이 없으면 해당 테이블을 조회할 수 없다.

4. 두 가지 보안 기법

데이터베이스 보안 기법은 discretionary security mechanism과 mandatory security mechanism으로 구분할 수 있다.

구분	기준	특징
`discretionary security mechanism`	객체 소유자와 권한 허가	`GRANT`, `REVOKE`로 권한을 부여하고 취소
`mandatory security mechanism`	조직의 보안 등급 정책	사용자와 데이터를 보안 등급으로 분류하여 다단계 보안 적용

4.1 Discretionary Security Mechanism

discretionary security mechanism은 사용자에게 특정 릴레이션, 투플, 애트리뷰트에 대해 지정된 모드로 접근할 권한을 허가하거나 취소하는 방식이다.

대표 명령은 다음과 같다.

GRANT ...
REVOKE ...

대부분의 상용 관계 DBMS에서 사용되는 방식이다. DBMS는 시스템 카탈로그에 누가 어떤 권한을 허가받았고, 어떤 권한이 취소되었는지를 유지한다.

4.2 Mandatory Security Mechanism

mandatory security mechanism은 데이터와 사용자를 보안 등급으로 분류하고, 조직 정책에 따라 접근을 강제하는 방식이다.

예를 들어 다음과 같은 등급을 둘 수 있다.

1급 비밀
2급 비밀
3급 비밀
일반 정보

이 방식은 군사, 공공기관, 고보안 환경처럼 다단계 보안이 중요한 환경에서 의미가 크다. 일반적인 상용 관계 DBMS에서는 discretionary security mechanism이 더 흔하게 사용된다.

5. GRANT: 권한 허가

객체의 생성자 또는 권한을 가진 사용자는 GRANT문을 사용하여 다른 사용자나 역할에게 권한을 허가할 수 있다.

기본 형식은 다음과 같다.

GRANT 권한 [(애트리뷰트들의 리스트)]
ON 객체
TO {사용자 | 역할 | PUBLIC}
[WITH GRANT OPTION];

절	의미
`GRANT 권한`	허가할 권한 지정
`ON 객체`	권한을 부여할 대상 객체 지정
`TO 사용자 \| 역할 \| PUBLIC`	권한을 받을 대상 지정
`WITH GRANT OPTION`	권한을 받은 사용자가 다시 다른 사용자에게 권한을 줄 수 있도록 허용

6. 주요 객체 권한

GRANT절에는 대표적으로 SELECT, INSERT, DELETE, UPDATE, REFERENCES를 포함할 수 있다.

권한	의미	주의할 점
`SELECT`	데이터 조회	Oracle에서는 일반적으로 애트리뷰트 단위로 `SELECT` 권한을 허가할 수 없음
`INSERT`	투플 삽입	삽입 가능하다고 수정 가능하다는 뜻은 아님
`DELETE`	투플 삭제	조건 없이 실행하면 대량 삭제 위험
`UPDATE`	기존 값 수정	특정 애트리뷰트 단위로 권한 부여 가능
`REFERENCES`	외래 키 참조 허용	참조 무결성 제약조건 생성에 필요

6.1 SELECT

SELECT는 데이터를 조회할 수 있는 권한이다.

GRANT SELECT
ON EMPLOYEE
TO LEE;

이 경우 LEE는 EMPLOYEE 테이블을 조회할 수 있다. 단, 삽입, 수정, 삭제는 별도의 권한이 필요하다.

6.2 INSERT

INSERT는 새로운 투플을 삽입할 수 있는 권한이다.

GRANT INSERT
ON EMPLOYEE
TO LEE;

INSERT 권한은 새로운 행을 넣을 수 있게 하지만, 기존 데이터를 수정할 수 있게 하지는 않는다.

6.3 UPDATE

UPDATE는 기존 데이터를 수정할 수 있는 권한이다. 특정 애트리뷰트만 수정할 수 있도록 제한할 수도 있다.

GRANT UPDATE (TITLE, MANAGER)
ON EMPLOYEE
TO LEE;

이 경우 LEE는 TITLE, MANAGER만 수정할 수 있고, SALARY 같은 다른 애트리뷰트는 수정할 수 없다.

6.4 REFERENCES

REFERENCES는 외래 키 제약조건을 만들 수 있는 권한이다.

GRANT REFERENCES (EMPNO)
ON EMPLOYEE
TO CHOI;

이 권한을 받은 CHOI는 자신이 만든 테이블에서 EMPLOYEE(EMPNO)를 외래 키로 참조할 수 있다.

7. WITH GRANT OPTION

WITH GRANT OPTION은 객체 권한을 받은 사용자가 그 권한을 다시 다른 사용자에게 허가할 수 있게 하는 옵션이다.

GRANT SELECT
ON EMPLOYEE
TO LEE
WITH GRANT OPTION;

권한 전달 구조는 다음처럼 표현할 수 있다.

KIM → LEE → CHOI

KIM이 LEE에게 WITH GRANT OPTION과 함께 권한을 주면, LEE는 해당 권한을 CHOI에게 다시 줄 수 있다.

반대로 WITH GRANT OPTION 없이 권한을 받은 사용자는 권한을 사용할 수는 있지만 다른 사용자에게 전달할 수 없다.

GRANT SELECT
ON EMPLOYEE
TO LEE;

KIM → LEE 가능
LEE → CHOI 불가능

주의할 점: 권한 전달은 WITH GRANT OPTION과 관련된다. 뷰 갱신 제약에서 사용되는 WITH CHECK OPTION과 구분해야 한다.

8. PUBLIC

PUBLIC은 모든 사용자를 의미하는 특수 키워드다.

GRANT SELECT
ON EMPLOYEE
TO PUBLIC;

이 명령은 모든 사용자에게 EMPLOYEE 테이블 조회 권한을 부여한다.

PUBLIC은 편리하지만 위험할 수 있다. 모든 사용자에게 공개해도 되는 객체인지 확인한 뒤 사용해야 한다.

사용해도 비교적 적절한 경우	주의해야 하는 경우
공지사항, 공개 코드 테이블, 공용 참조 테이블	직원 정보, 급여 정보, 환자 정보, 개인정보 포함 테이블

9. REVOKE: 권한 취소

다른 사용자에게 허가한 권한을 취소할 때는 REVOKE문을 사용한다.

기본 형식은 다음과 같다.

REVOKE [권한들의 리스트 | ALL]
ON 객체
FROM {사용자 | 역할 | PUBLIC};

예를 들어 LEE에게 허가한 DEPARTMENT 테이블의 SELECT, INSERT 권한을 취소하려면 다음처럼 작성한다.

REVOKE SELECT, INSERT
ON DEPARTMENT
FROM LEE;

특정 권한만 취소할 수도 있다.

REVOKE INSERT
ON EMPLOYEE
FROM LEE;

특정 객체에 대한 모든 권한을 취소할 수도 있다.

REVOKE ALL
ON EMPLOYEE
FROM LEE;

10. 연쇄적 취소

객체 권한에서 WITH GRANT OPTION을 통해 권한 전달 사슬이 만들어진 경우, 원래 권한이 취소되면 그 권한을 바탕으로 다시 부여된 권한도 연쇄적으로 취소될 수 있다.

KIM → LEE → CHOI

KIM이 LEE에게 WITH GRANT OPTION과 함께 권한을 주고, LEE가 CHOI에게 다시 권한을 주었다고 하자.

이때 KIM이 LEE의 권한을 취소하면 LEE가 CHOI에게 부여한 권한도 함께 취소될 수 있다.

KIM → LEE 권한 취소
LEE → CHOI 권한도 연쇄적으로 취소

이것을 cascading revoke로 이해할 수 있다.

권한 취소에서 중요한 기준은 다음과 같다.

취소하려는 권한을 허가했던 사람만 그 권한을 취소할 수 있다.
권한을 허가했던 사람은 자신이 권한을 허가했던 사용자로부터만 권한을 취소할 수 있다.
권한 전달 사슬이 있는 경우 연쇄적 취소가 발생할 수 있다.

11. Role: 권한 관리 단순화

role은 사용자에게 허가할 수 있는 관련 권한들의 그룹이다. 여러 사용자에게 동일한 권한 집합을 직접 부여하는 대신, 권한을 role에 부여하고 사용자는 그 role을 받도록 구성한다.

11.1 Role 없이 권한을 직접 부여하는 경우

사용자1 ← SELECT, INSERT, UPDATE
사용자2 ← SELECT, INSERT, UPDATE
사용자3 ← SELECT, INSERT, UPDATE

사용자가 많아질수록 권한 관리가 복잡해진다. 권한 집합을 바꾸려면 여러 사용자에게 반복적으로 수정해야 한다.

11.2 Role을 사용하는 경우

Programmer role ← SELECT, INSERT, UPDATE
사용자1 ← Programmer role
사용자2 ← Programmer role
사용자3 ← Programmer role

role과 연결된 권한이 바뀌면 그 role을 허가받은 사용자들의 권한도 자동으로 바뀐다.

11.3 Role 예시

GRANT CREATE TABLE
TO programmer;

GRANT programmer
TO CHOI;

이 구조에서는 CREATE TABLE 권한이 programmer role에 부여되고, 사용자 CHOI는 programmer role을 통해 해당 권한을 사용할 수 있다.

CREATE TABLE 권한 → programmer role → CHOI

12. Oracle의 보안 및 권한 관리

Oracle에서는 권한을 크게 system privilege와 object privilege로 구분한다.

구분	의미	예
`system privilege`	데이터베이스 전체 수준에서 특정 작업을 수행할 수 있는 권한	`CREATE SESSION`, `CREATE TABLE`, `CREATE VIEW`
`object privilege`	특정 객체에 대해 특정 연산을 수행할 수 있는 권한	`SELECT ON EMPLOYEE`, `INSERT ON EMPLOYEE`

계정이 있다고 해서 자동으로 작업을 수행할 수 있는 것은 아니다. 별도로 권한을 허가받아야 한다.

Oracle 계정 있음 ≠ 모든 작업 가능
Oracle 계정 있음 + 필요한 권한 있음 = 해당 작업 가능

13. System Privilege

system privilege는 사용자가 데이터베이스에서 특정 작업을 수행할 수 있도록 하는 권한이다.

예를 들어 테이블을 생성하려면 CREATE TABLE 시스템 권한이 필요하다.

대표적인 시스템 권한은 다음과 같다.

유형	예
TABLE	`CREATE TABLE`, `CREATE ANY TABLE`, `ALTER ANY TABLE`, `DROP ANY TABLE`, `SELECT ANY TABLE`
INDEX	`CREATE ANY INDEX`, `ALTER ANY INDEX`, `DROP ANY INDEX`
TABLESPACE	`CREATE TABLESPACE`, `ALTER TABLESPACE`, `DROP TABLESPACE`
SESSION	`CREATE SESSION`, `ALTER SESSION`

ANY가 포함된 권한은 다른 사용자의 객체까지 포함할 수 있으므로 매우 강력하다. 운영 환경에서는 최소 권한 원칙에 따라 신중하게 부여해야 한다.

14. WITH ADMIN OPTION

시스템 권한을 다른 사용자에게 다시 허가할 수 있게 하려면 WITH ADMIN OPTION을 사용한다.

GRANT CREATE SESSION
TO KIM
WITH ADMIN OPTION;

WITH ADMIN OPTION을 받은 사용자는 해당 시스템 권한을 다른 사용자에게 다시 허가할 수 있다.

중요한 구분은 다음과 같다.

구분	객체 권한	시스템 권한
권한 전달 옵션	`WITH GRANT OPTION`	`WITH ADMIN OPTION`
권한 취소 시 연쇄 취소	발생할 수 있음	발생하지 않음
예	`GRANT SELECT ON EMPLOYEE TO LEE WITH GRANT OPTION`	`GRANT CREATE SESSION TO KIM WITH ADMIN OPTION`

시스템 권한은 취소할 때 객체 권한처럼 연쇄적인 취소가 일어나지 않는다.

15. Object Privilege

object privilege는 특정 객체에 대해 특정 연산을 수행할 수 있는 권한이다.

객체의 소유자는 해당 객체에 대한 모든 권한을 보유한다. 또한 자신의 객체에 대한 특정 권한을 다른 사용자나 role에게 허가할 수 있다.

GRANT SELECT, INSERT
ON EMPLOYEE
TO LEE;

이 명령은 LEE에게 EMPLOYEE 테이블에 대한 SELECT, INSERT 권한을 부여한다.

이 경우 LEE는 조회와 삽입은 할 수 있지만, UPDATE나 DELETE는 할 수 없다. 각 연산은 별도의 권한으로 관리된다.

16. Oracle의 미리 정의된 Role

강의 자료 기준으로 Oracle에는 사용 패턴에 따라 미리 정의된 role이 여러 개 있으며, 대표적으로 connect, resource, dba가 설명된다.

Role	설명
`connect`	데이터베이스 로그인에 필요한 기본 성격의 role
`resource`	테이블과 인덱스를 생성하고 자신의 객체에 대해 권한을 허가하거나 취소할 수 있는 성격의 role
`dba`	`WITH ADMIN OPTION`과 함께 모든 시스템 권한을 가지는 강력한 관리자 role

확인 필요: Oracle 버전에 따라 predefined role의 세부 권한 구성은 달라질 수 있다. 실제 운영 환경에서는 해당 버전의 공식 문서와 현재 DBA_ROLE_PRIVS, ROLE_SYS_PRIVS 등을 확인해야 한다.

17. SYSOPER와 SYSDBA

Oracle에는 일반 role 외에 데이터베이스 관리자 권한으로 SYSOPER, SYSDBA가 있다.

권한	주요 작업
`SYSOPER`	`STARTUP`, `SHUTDOWN`, `ALTER DATABASE OPEN`, `ALTER DATABASE BACKUP`
`SYSDBA`	`SYSOPER` 권한을 포함하고 `CREATE DATABASE` 등 더 강력한 관리자 작업 가능

관리자 권한은 데이터베이스 전체에 영향을 줄 수 있으므로 일반 사용자에게 부여하면 안 된다.

18. Oracle에서 권한 부여와 취소 예제

18.1 LEE에게 SELECT와 INSERT 권한 부여

사용자 KIM이 소유한 EMPLOYEE 테이블에 대해 LEE에게 조회와 삽입 권한을 부여한다.

GRANT SELECT, INSERT
ON EMPLOYEE
TO LEE;

이후 LEE는 KIM.EMPLOYEE 테이블을 조회하거나 투플을 삽입할 수 있다.

18.2 객체에 대한 모든 권한 취소

REVOKE ALL
ON EMPLOYEE
FROM LEE;

이 명령은 EMPLOYEE 객체에 대해 LEE에게 허가된 모든 객체 권한을 취소한다.

18.3 특정 권한만 취소

REVOKE INSERT
ON EMPLOYEE
FROM LEE;

이 명령은 LEE에게서 INSERT 권한만 취소한다. SELECT 권한이 별도로 남아 있다면 조회는 계속 가능하다.

18.4 사용자 전체 권한 취소

강의 자료에서는 데이터베이스 관리자로 로그인하여 다음 명령으로 LEE에게 허가된 전체 권한을 취소하는 예를 다룬다.

REVOKE ALL PRIVILEGES
FROM LEE;

객체 단위 권한 취소와 사용자 전체 권한 취소는 구분해야 한다.

명령	의미
`REVOKE ALL ON EMPLOYEE FROM LEE;`	`EMPLOYEE` 객체에 대한 권한 취소
`REVOKE ALL PRIVILEGES FROM LEE;`	`LEE`에게 허가된 전체 권한 취소로 설명됨

19. 데이터 사전 뷰로 권한 확인

Oracle에서는 데이터 사전 뷰를 통해 권한 정보를 확인할 수 있다.

19.1 객체 권한 확인

SELECT *
FROM USER_TAB_PRIVS;

또는 DBA 관점에서는 다음 뷰를 사용할 수 있다.

SELECT *
FROM DBA_TAB_PRIVS;

대표 컬럼은 다음과 같다.

컬럼	의미
`GRANTEE`	권한을 허가받은 사용자
`OWNER`	객체의 소유자
`TABLE_NAME`	테이블 이름
`GRANTOR`	권한을 허가한 사용자
`PRIVILEGE`	객체에 대한 권한
`GRANTABLE`	받은 권한을 다시 다른 사용자에게 허가할 수 있는지 여부

GRANTABLE은 객체 권한의 WITH GRANT OPTION과 연결된다.

19.2 시스템 권한 확인

SELECT *
FROM USER_SYS_PRIVS;

대표 컬럼은 다음과 같다.

컬럼	의미
`USERNAME`	시스템 권한을 허가받은 사용자
`PRIVILEGE`	허가받은 시스템 권한
`ADMIN_OPTION`	받은 시스템 권한을 다시 허가할 수 있는지 여부

ADMIN_OPTION은 시스템 권한의 WITH ADMIN OPTION과 연결된다.

20. 다른 사용자의 테이블 접근

Oracle에서 다른 사용자의 테이블에 접근할 때는 테이블 이름 앞에 소유자 계정을 붙여야 한다.

INSERT INTO KIM.EMPLOYEE
VALUES(3428, '김지민', '사원', 2106, 1500000, 2);

여기서 KIM.EMPLOYEE라고 쓰는 이유는 EMPLOYEE 테이블의 소유자가 LEE가 아니라 KIM이기 때문이다.

권한이 없다면 다음과 같은 작업은 실패한다.

UPDATE KIM.EMPLOYEE
SET DNO = 3
WHERE EMPNAME = '조민희';

LEE에게 SELECT, INSERT 권한만 있고 UPDATE 권한이 없다면 UPDATE는 수행할 수 없다. 이후 KIM이 LEE에게 UPDATE 권한을 부여해야 수정이 가능하다.

GRANT UPDATE
ON EMPLOYEE
TO LEE;

21. Synonym

다른 사용자의 객체를 매번 KIM.EMPLOYEE처럼 쓰는 것은 번거롭다. Oracle에서는 synonym을 이용해 객체 이름에 별칭을 만들 수 있다.

기본 형식은 다음과 같다.

CREATE SYNONYM 동의어 FOR 객체;

예를 들어 KIM.EMPLOYEE를 EMP라는 이름으로 참조하려면 다음처럼 작성한다.

CREATE SYNONYM EMP
FOR KIM.EMPLOYEE;

이후에는 다음처럼 사용할 수 있다.

SELECT *
FROM EMP;

주의할 점은 synonym은 이름을 편하게 만드는 기능이지 권한을 부여하는 기능이 아니라는 것이다.

권한 부여 = 접근 가능하게 만드는 것
synonym = 접근 이름을 편하게 만드는 것

따라서 EMP synonym이 있어도 실제 KIM.EMPLOYEE에 대한 권한이 없으면 접근할 수 없다.

22. View를 이용한 보안

기본 릴레이션에 직접 접근시키고 싶지 않을 때는 view를 사용할 수 있다.

예를 들어 EMPLOYEE 테이블에 다음 애트리뷰트가 있다고 하자.

EMPNO, EMPNAME, TITLE, MANAGER, SALARY, DNO

LEE에게 직원 정보는 보여주고 싶지만 SALARY는 숨기고 싶다면 원본 테이블에 SELECT 권한을 주면 안 된다. 대신 SALARY를 제외한 view를 만든다.

CREATE VIEW EMPLOYEE_PUBLIC AS
SELECT EMPNO, EMPNAME, TITLE, MANAGER, DNO
FROM EMPLOYEE;

그리고 view에 대해 SELECT 권한을 부여한다.

GRANT SELECT
ON EMPLOYEE_PUBLIC
TO LEE;

Oracle에서는 일반적으로 애트리뷰트 단위로 SELECT 권한을 허가할 수 없으므로, 특정 컬럼을 숨기고 조회 권한을 주려면 view를 사용하는 방식이 중요하다.

목적	방법
테이블 전체 조회 허용	원본 테이블에 `SELECT` 권한 부여
일부 컬럼만 조회 허용	필요한 컬럼만 포함한 view 생성 후 view에 `SELECT` 권한 부여
일부 컬럼만 수정 허용	`GRANT UPDATE (컬럼명)` 사용
일부 컬럼만 외래 키 참조 허용	`GRANT REFERENCES (컬럼명)` 사용

23. 자칫 실수하기 쉬운 부분

23.1 계정과 권한은 다르다

Oracle 계정이 있다는 것은 로그인할 수 있는 신분이 있다는 뜻이다. 하지만 특정 작업을 수행하려면 별도의 권한이 필요하다.

계정 있음 ≠ 테이블 생성 가능
계정 있음 ≠ 다른 사용자 테이블 조회 가능

23.2 SELECT, INSERT, UPDATE, DELETE는 독립적이다

INSERT 권한이 있다고 해서 UPDATE 권한이 있는 것은 아니다. 각 연산은 별도 권한으로 관리된다.

23.3 WITH GRANT OPTION과 WITH ADMIN OPTION을 구분해야 한다

옵션	적용 대상	의미
`WITH GRANT OPTION`	객체 권한	받은 객체 권한을 다른 사용자에게 다시 허가 가능
`WITH ADMIN OPTION`	시스템 권한	받은 시스템 권한을 다른 사용자에게 다시 허가 가능

23.4 객체 권한 취소와 시스템 권한 취소의 연쇄 여부가 다르다

객체 권한은 WITH GRANT OPTION을 통해 전달된 권한이 연쇄 취소될 수 있다. 반면 시스템 권한은 취소할 때 연쇄 취소가 일어나지 않는다.

23.5 PUBLIC은 편하지만 위험하다

PUBLIC은 모든 사용자에게 권한을 주는 것이다. 개인정보, 급여, 환자 정보, 내부 업무 데이터에는 신중하게 사용해야 한다.

23.6 Synonym은 권한이 아니다

synonym은 객체 이름을 짧게 쓰기 위한 별칭이다. 접근 권한을 자동으로 부여하지 않는다.

23.7 Oracle에서 SELECT 컬럼 제한은 view로 처리한다

Oracle에서는 일반적으로 애트리뷰트 단위로 SELECT 권한을 허가할 수 없다. 일부 컬럼만 보여주려면 view를 만들고 view에 권한을 부여한다.

24. 구분 기준 요약

구분할 개념	기준
물리적 보호 vs 권한 보호	서버와 저장장치 보호인지, 사용자 접근 통제인지
권한 보호 vs 운영 보호	누가 접근할 수 있는지의 문제인지, 데이터 무결성 유지 문제인지
Access control vs privilege management	로그인 가능 여부인지, 로그인 후 작업 가능 여부인지
Discretionary vs mandatory security	소유자 기반 권한 부여인지, 보안 등급 기반 강제 통제인지
System privilege vs object privilege	DB 전체 수준 작업인지, 특정 객체에 대한 작업인지
WITH GRANT OPTION vs WITH ADMIN OPTION	객체 권한 전달인지, 시스템 권한 전달인지
GRANT vs REVOKE	권한 허가인지, 권한 취소인지
Role vs direct grant	사용자에게 직접 권한을 주는지, role을 거쳐 권한을 주는지
View vs synonym	데이터 노출 범위를 제한하는지, 객체 이름을 간단히 만드는지

25. 핵심 요약

데이터베이스 보안은 물리적 보호, 권한 보호, 운영 보호로 나눌 수 있다. DBMS는 사용자의 접속을 통제하는 access control과, 접속 후 어떤 데이터베이스 영역에 어떤 연산을 수행할 수 있는지 통제하는 권한 관리 기능을 제공한다.

권한 관리는 주로 GRANT와 REVOKE를 통해 이루어진다. GRANT는 SELECT, INSERT, DELETE, UPDATE, REFERENCES 같은 권한을 사용자나 role에게 허가하고, REVOKE는 허가된 권한을 취소한다. WITH GRANT OPTION이 있으면 객체 권한을 받은 사용자가 다시 다른 사용자에게 권한을 줄 수 있으며, 이 경우 권한 취소 시 연쇄적 취소가 발생할 수 있다.

role은 여러 권한을 묶어 놓은 이름 있는 권한 집합이다. 여러 사용자에게 동일한 권한을 반복해서 부여하는 대신 role에 권한을 부여하고 사용자에게 role을 부여하면 관리가 단순해진다.

Oracle에서는 권한을 system privilege와 object privilege로 구분한다. 시스템 권한은 CREATE SESSION, CREATE TABLE처럼 데이터베이스 전체 수준의 작업 권한이고, 객체 권한은 특정 테이블이나 view에 대해 SELECT, INSERT, UPDATE 같은 연산을 수행할 수 있는 권한이다. 시스템 권한 전달에는 WITH ADMIN OPTION, 객체 권한 전달에는 WITH GRANT OPTION을 사용한다.

다른 사용자의 테이블을 접근할 때는 KIM.EMPLOYEE처럼 소유자.객체명 형식을 사용한다. 이 이름을 간단히 쓰고 싶으면 synonym을 만들 수 있지만, synonym은 권한을 대신하지 않는다. 일부 컬럼만 보여주고 싶다면 원본 테이블이 아니라 필요한 컬럼만 포함한 view를 만들고 그 view에 SELECT 권한을 부여해야 한다.