Ответ.

SQL-сервер поддерживает многоуровневую систему прав доступа через роли, пользовательские права (GRANT/REVOKE) и схемы (schemas). Ключевые принципы:

Назначайте роль= набор разрешений, которые потом получит пользователь.
Давайте права минимальные, только необходимые (принцип минимальных привилегий).
Разделяйте права на уровне базы, таблицы, представления, процедуры отдельно.
Для особо важных операций — использовать только через хранимые процедуры или представления, а не прямой доступ к таблицам.

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

-- Создаём роль для аналитиков
CREATE ROLE Analyst;
-- Даем только SELECT к нужным таблицам
GRANT SELECT ON Sales TO Analyst;
-- Запрещаем модификацию данных
REVOKE INSERT, UPDATE, DELETE ON Sales FROM Analyst;
-- Назначаем роль пользователю
GRANT Analyst TO user_ivan;

Часто выделяют роли для чтения (read-only), модификации, администрирования и отдельных операций.

Вопрос с подвохом.

Подвох: "Может ли пользователь, имеющий доступ только к представлению (VIEW), изменить базовую таблицу через него? Приведите пример."

Ответ: Да, если VIEW не содержит агрегирования/группировки и не яв-ся только для чтения (WITH CHECK OPTION) – можно выполнять INSERT/UPDATE/DELETE на VIEW, и изменения попадут в базовую таблицу, если разрешения позволяют.

-- Представление, отсекающее лишние столбцы
CREATE VIEW SalesAsView AS SELECT id, total, manager_id FROM Sales;
-- Если разрешено, пользователь внесёт изменения так:
UPDATE SalesAsView SET total=1000 WHERE id=42;
-- Это затронет Sales.total для id=42

Решение: использовать только readonly VIEW или запрещать права на изменения данных через представления.

Примеры реальных ошибок из-за незнания тонкостей темы.

История

Проект: HR-портал, персональные данные сотрудников.

Ошибка: Операторы имели доступ к базовой таблице через VIEW без ограничения по UPDATE — модифицировали зарплаты друг друга случайно, хотя изначально VIEW задумывался "только для отчетов".

История

Проект: Бухгалтерский учёт, внешние интеграции.

Ошибка: Дали внешней системе права INSERT и SELECT на всю DB вместо только INSERT в нужные таблицы. Итог: уязвимость к чтению всей БД и возможное нарушение законодательства по GDPR.

История

Проект: SaaS-платформа, многопользовательские отчеты.

Ошибка: Все клиенты работали в одной схеме с общими правами: случайно видели и могли редактировать чужие данные. Решение — разбивка на схемы, отдельные роли и собственные ограничения на уровне Row Level Security (RLS).