Роли и пользователи: управление доступом в БД

🔐 Введение: Почему управление доступом — это важно?

База данных без контроля доступа — как дом с открытыми дверями. Любой может зайти, взять что угодно или даже сломать систему. В SQL управление доступом строится на двух ключевых понятиях:

• Пользователи — это аккаунты для входа (как логины в системе)
• Роли — группы прав, которые можно назначать пользователям (как должности в компании)

Пример: бухгалтеру нужен доступ к финансовым таблицам, а менеджеру — только к данным клиентов. Давайте разберёмся, как это реализовать!

👥 Создание пользователей: ваша первая линия обороны

Создадим пользователя analyst с паролем:

CREATE USER analyst WITH PASSWORD 'SecurePass123!';

🔑 Важно: - Пароли должны быть сложными (используйте буквы, цифры, спецсимволы) - Никогда не храните пароли в открытом виде в скриптах

Проверим созданного пользователя:

SELECT usename FROM pg_user;  -- PostgreSQL
SELECT user FROM mysql.user;  -- MySQL

🎭 Роли: как раздавать права оптом

Роли — это «шаблоны» прав. Создадим роль для чтения данных:

CREATE ROLE read_only;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO read_only;

Теперь назначим эту роль пользователю:

GRANT read_only TO analyst;

💡 Лайфхак: В PostgreSQL есть встроенные роли типа pg_read_all_data — используйте их для стандартных задач!

🛡️ Гранулярные права: тонкая настройка доступа

Дадим конкретные права на конкретную таблицу:

GRANT SELECT, INSERT ON customers TO analyst;
REVOKE DELETE ON orders FROM analyst;  -- Запрещаем удаление

Проверим текущие права:

-- PostgreSQL
SELECT * FROM information_schema.table_privileges 
WHERE grantee = 'analyst';

-- MySQL
SHOW GRANTS FOR analyst;

🔄 Наследование ролей: как строить иерархии

Роли могут включать другие роли! Создадим иерархию:

CREATE ROLE manager;
GRANT read_only TO manager;  -- Менеджер наследует права read_only
GRANT INSERT, UPDATE ON invoices TO manager;

Теперь если дать пользователю роль manager, он автоматически получит и права read_only.

🚫 Запреты: когда нужно сказать «нет»

Иногда нужно явно запретить доступ, даже если роль его разрешает:

REVOKE SELECT ON salary_data FROM PUBLIC;  -- Отзываем у всех
DENY SELECT ON salary_data TO analyst;     -- Явный запрет (в SQL Server)

⚠️ Важно: В некоторых СУБД (например, PostgreSQL) явных запретов нет — работает принцип «что не разрешено, то запрещено».

🏁 Практический пример: настройка доступа для интернет-магазина

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

CREATE ROLE customer_service;
GRANT SELECT ON orders, customers TO customer_service;
GRANT UPDATE (status) ON orders TO customer_service;

2. Назначаем пользователя:

CREATE USER support_team WITH PASSWORD 'SupPass#2023';
GRANT customer_service TO support_team;

3. Запрещаем опасные операции:

REVOKE DELETE ON ALL TABLES IN SCHEMA public FROM PUBLIC;

🔍 Проверка и аудит: кто что может?

Часто нужно проверить эффективность настроек:

-- Показать все роли и их членов (PostgreSQL)
SELECT rolname, memberof FROM pg_roles;

-- Показать права конкретного пользователя (MySQL)
SHOW GRANTS FOR support_team;

📊 Совет: Регулярно проверяйте права — со временем в них накапливается «мусор»!

💡 Продвинутые техники

1. Групповые роли: Создавайте роли по отделам (finance, hr, dev)
2. Временные права: sql GRANT SELECT ON customers TO analyst WITH GRANT OPTION FOR 1 DAY;
3. Динамическая маскировка данных (в Enterprise-версиях СУБД)

🧩 Итоговая схема управления доступом

1. Создавайте роли по бизнес-функциям (не по людям!)
2. Назначайте роли пользователям
3. Минимизируйте права (принцип наименьших привилегий)
4. Регулярно пересматривайте настройки

Теперь вы вооружены знаниями для грамотного управления доступом!