Настройка прав доступа с GRANT и REVOKE

Представьте, что ваши данные — это крепость, и каждый житель крепости имеет свои права: кто-то может только ходить по двору, кто-то хранит ключи от сокровищницы, а кто-то сидит в тронном зале и управляет всем. В нашей базе данных с этой ролью справляются команды GRANT и REVOKE. Это как раз они отвечают за то, чтобы решать: кто, куда и зачем может ходить.

Команда GRANT, как любой нормальный грант, позволяет выдавать доступ к ресурсам (например, базам данных, таблицам, схемам) определённым ролям. Это своего рода "приглашение на вечеринку", где вы решаете, кто может читать, писать или ломать мебель.

Команда REVOKE, наоборот, забирает ранее выданные права. Это как сказать: "Эй, вечеринка для тебя закончилась, ключи оставь у выхода".

Предоставление прав с помощью GRANT

Начнём с самого верхнего уровня — базы данных. Чтобы пользователь мог подключаться к базе, ему нужно выдать права на подключение. Для этого используется команда:

GRANT CONNECT ON DATABASE database_name TO role_name;

Например, если у нас есть база данных university и роль student, мы можем разрешить студентам подключаться с помощью следующего запроса:

GRANT CONNECT ON DATABASE university TO student;

Но просто подключиться — это ещё не значит, что можно делать всё, что угодно. Чтобы пользователь мог создавать объекты в базе данных, ему нужно ещё и право на создание:

GRANT CREATE ON DATABASE university TO student;

Права на базе данных можно проверить с помощью команды:

\l+ university

Отзыв прав с помощью REVOKE

Если студент вдруг начал вести себя подозрительно (например, пытается создать больше таблиц, чем мы ожидали), мы можем отозвать его права на создание с помощью команды:

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 может запускать запросы SELECT из таблицы courses.

Права на запись

Если вы хотите, чтобы пользователь мог вставлять новые строки в таблицу, это можно настроить так:

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;

Совет: старайтесь не злоупотреблять этими правами. Если студентам дать доступ на удаление данных, они могут случайно (или специально) всё испортить.

Примеры: создание роли с ограниченными правами

Представьте, что мы создаём роль для преподавателей, которые должны иметь доступ к чтению данных о студентах и курсах, но не могут удалять записи. Вот как это сделать:

1. Создаём роль:

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, которую мы хотим ограничить. Она должна иметь доступ только к данным по курсам, но ни в коем случае не к данным студентов. Вот как это выглядит:

1. Разрешаем доступ только к таблице courses:

GRANT SELECT, INSERT ON TABLE courses TO intern;

2. Убеждаемся, что у роли intern нет прав на таблицу students:

REVOKE ALL ON TABLE students FROM intern;

Эта комбинация позволяет точно настроить права доступа.

Примеры использования на реальных проектах

Этот механизм управления доступом часто применяется на реальных проектах. Например:

1. В интернет-магазинах права на таблицы пользователей и заказы распределены между ролями "администратор", "оператор" и "гость".
2. В университетских системах администраторы могут добавлять и изменять курсы, а студенты — только просматривать их.
3. В банковских системах доступ к счетам клиентов разграничен между сотрудниками разных отделов.