Налаштування прав доступу з 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. У банківських системах доступ до рахунків клієнтів розмежований між співробітниками різних відділів.