8. Безопасность
Для обеспечения конфиденциальности и целостности данных в системе реализована многоуровневая модель безопасности на основе ролей [2]. Главной особенностью разработанного решения является отказ от использования стандартной схемы dbo и назначение прав доступа на уровне пользовательских схем (Schema-Level Permissions). Это значительно упрощает администрирование: новые объекты, добавляемые в схему, автоматически наследуют права доступа, установленные для этой схемы [3].
8.1. Уровни аутентификации и авторизации
Система безопасности построена по иерархическому принципу:
Уровень сервера (Logins): Созданы учетные записи User_Manager и User_Engineer. Они обеспечивают аутентификацию (проверку пароля) при подключении к экземпляру SQL Server.
Уровень базы данных (Users): Логинам сервера сопоставлены пользователи базы данных Manager и Engineer.
Уровень ролей и схем (Roles & Schemas): Права доступа назначаются не пользователям напрямую, а ролям базы данных, в которые включаются пользователи.
8.2. Ролевая модель разграничения доступа
В системе реализованы две функциональные роли с четко разграниченными полномочиями:
Роль «Менеджер» (Role_SeeReports) Предназначена для сотрудников, занимающихся аналитикой.
Права: Предоставлено право SELECT на схемы [Stock] и [Ref].
Ограничения: Полный запрет на изменение данных. Пользователь не имеет прав INSERT, UPDATE, DELETE ни на одну таблицу, а также не может запускать процедуры модификации.
Роль «Инженер» (Role_ComponentEditor)
Предназначена для технических специалистов, работающих с данными.
Права:
EXECUTE ON SCHEMA::[Stock] — разрешает выполнение всех хранимых процедур в оперативной схеме (поиск, создание, импорт).
SELECT ON SCHEMA::[Ref] — разрешает чтение справочников (необходимо для работы выпадающих списков и процедур поиска).
Принцип наименьших привилегий: Инженеру не выданы прямые права на вставку или удаление записей в таблицах (GRANT INSERT/DELETE). Все изменения осуществляются строго через хранимые процедуры, что гарантирует прохождение всех проверок бизнес-логики и транзакционную целостность.
8.3. Тестирование системы безопасности
Для подтверждения корректности настроек безопасности был проведен эксперимент, имитирующий попытку несанкционированного доступа.
Сценарий теста:
Выполнено переключение контекста безопасности на пользователя Manager (команда EXECUTE AS USER) [4].
Предпринята попытка выполнить деструктивное действие — удаление справочной таблицы [Ref].[Manufacturers].
Предпринята попытка вызвать процедуру создания компонента, доступную только инженерам.
Результат: В обоих случаях СУБД заблокировала выполнение операций, вернув ошибку об отсутствии прав доступа. Это подтверждает, что изоляция на уровне схем и ролей функционирует корректно.
Рисунок 7 – Демонстрация отказа в доступе при попытке удаления таблицы пользователем с ограниченными правами