GRANT랑 REVOKE로 권한 설정하기

데이터가 마치 성이라고 생각해봐. 성 안에 사는 사람마다 권한이 다르지: 어떤 애는 마당만 돌아다닐 수 있고, 어떤 애는 보물창고 열쇠를 갖고 있고, 또 어떤 애는 왕좌에 앉아서 다 관리하지. 우리 데이터베이스에서는 GRANT랑 REVOKE 명령어가 이런 역할을 해. 누가 어디까지, 뭘 할 수 있는지 정하는 거지.

GRANT 명령어는 말 그대로 grant(허락)처럼, 특정 role한테 리소스(예: 데이터베이스, 테이블, 스키마)에 접근 권한을 주는 거야. 일종의 "파티 초대장" 같은 거지. 누가 읽고, 쓰고, 심지어 가구 부술 수 있는지 네가 정하는 거야.

REVOKE 명령어는 반대로, 이미 줬던 권한을 뺏는 거야. "야, 파티 끝났으니까 열쇠 두고 가!" 이런 느낌이지.

GRANT로 권한 주기

가장 상위 레벨인 데이터베이스부터 시작해보자. 유저가 데이터베이스에 접속하려면, 접속 권한을 줘야 해. 이럴 때 쓰는 명령어가:

GRANT CONNECT ON DATABASE database_name TO role_name;

예를 들어, university라는 데이터베이스랑 student라는 role이 있으면, 학생들이 접속할 수 있게 이렇게 할 수 있어:

GRANT CONNECT ON DATABASE university TO student;

근데 접속만 된다고 해서 다 할 수 있는 건 아니야. 유저가 데이터베이스에 오브젝트를 만들 수 있으려면, CREATE 권한도 줘야 해:

GRANT CREATE ON DATABASE university TO student;

데이터베이스 권한은 아래 명령어로 확인할 수 있어:

\l+ university

REVOKE로 권한 뺏기

만약 학생이 갑자기 수상하게 행동한다면(예를 들어, 우리가 예상한 것보다 테이블을 더 많이 만들려고 한다면), CREATE 권한을 이렇게 뺏을 수 있어:

REVOKE CREATE ON DATABASE university FROM student;

이제 학생은 접속만 할 수 있고, 더 이상 "창의적인 자유"는 없어.

스키마 레벨에서 권한 설정하기

스키마는 데이터베이스 안에 있는 "방" 같은 거야. 테이블, 뷰, 기타 오브젝트들이 여기 들어있지. 유저가 스키마 안 오브젝트를 다루려면, 읽기, 쓰기, 생성 권한을 따로 줄 수 있어.

스키마 권한 주기

예를 들어, public 스키마가 있다고 해(이건 모든 데이터베이스에 기본으로 있어). 유저가 스키마 내용을 볼 수 있게 하려면:

GRANT USAGE ON SCHEMA public TO student;

근데 USAGE만으로는 테이블 작업이 부족해. 오브젝트를 만들 수 있게 하려면:

GRANT CREATE ON SCHEMA public TO student;

이렇게 하면 학생이 public 스키마에서 테이블을 읽고 만들 수 있어.

스키마 권한 뺏기

만약 학생이 bad_idea_01 같은 이상한 테이블을 막 만든다면, 권한을 제한할 수 있어:

REVOKE CREATE ON SCHEMA public FROM student;

이제 학생은 새로운 테이블을 못 만들어. 질서 회복!

테이블 레벨에서 권한 설정하기

테이블은 아마 데이터베이스에서 제일 많이 쓰는 오브젝트일 거야. 테이블 접근 권한은 크게 세 가지로 나뉘어: 읽기, 쓰기, 수정.

읽기 권한

유저가 테이블 내용을 읽을 수 있게 하려면:

GRANT SELECT ON TABLE table_name TO role_name;

예를 들어, 학생들이 courses 테이블을 읽을 수 있게 하려면:

GRANT SELECT ON TABLE courses TO student;

이제 student 유저는 courses 테이블에서 SELECT 쿼리를 날릴 수 있어.

쓰기 권한

유저가 테이블에 새 행을 추가할 수 있게 하려면 이렇게 해:

GRANT INSERT ON TABLE table_name TO role_name;

예시:

GRANT INSERT ON TABLE courses TO student;

이제 학생들이 테이블에 새로운 강좌를 추가할 수 있어. 근데... 이게 진짜 좋은 생각일까?

수정 및 삭제 권한

유저가 기존 행을 업데이트하거나 삭제할 수 있게 하려면, 각각 UPDATE랑 DELETE 권한을 줘야 해.

GRANT UPDATE ON TABLE courses TO student;
GRANT DELETE ON TABLE courses TO student;

팁: 이 권한들은 너무 남발하지 마. 학생들한테 삭제 권한을 주면 실수로(아니면 일부러) 다 날릴 수도 있어.

예시: 제한된 권한의 role 만들기

예를 들어, 강사 role을 만들어서 학생/강좌 데이터는 읽을 수 있지만, 삭제는 못 하게 하고 싶어. 이렇게 하면 돼:

1. role 만들기:

CREATE ROLE teacher;

2. students랑 courses 테이블 읽기 권한 주기:

GRANT SELECT ON TABLE students, courses TO teacher;

3. 삭제 권한 제한하기:

REVOKE DELETE ON TABLE students, courses FROM teacher;

이제 강사들은 필요한 권한만 있고, 쓸데없는 건 못 해.

GRANT랑 REVOKE 조합해서 유연하게 세팅하기

예를 들어, intern이라는 role이 있는데, 얘는 강좌 데이터만 접근할 수 있고, 학생 데이터는 절대 못 보게 하고 싶어. 이렇게 하면 돼:

1. courses 테이블만 접근 허용:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. intern role이 students 테이블에 권한이 없는지 확인:

REVOKE ALL ON TABLE students FROM intern;

이렇게 조합하면 권한을 딱 맞게 세팅할 수 있어.

실전 프로젝트에서의 활용 예시

이런 권한 관리 방식은 실제 프로젝트에서 자주 써. 예를 들면:

1. 온라인 쇼핑몰에서는 유저랑 주문 테이블 권한을 "관리자", "오퍼레이터", "게스트" role별로 나눠서 관리해.
2. 대학교 시스템에서는 관리자가 강좌를 추가/수정할 수 있고, 학생은 보기만 할 수 있어.
3. 은행 시스템에서는 고객 계좌 접근 권한을 부서별 직원마다 다르게 줘.