К числу типов доступа пользователей к объектам БД относятся:
- добавление, удаление, модификация и выборка строк из таблицы, представления;
- запуск хранимой процедуры:
- создание, модификация и удаление объектов БД:
- выполнение некоторого набора команд SQL.
Данный перечень является приблизительным, поскольку, повторимся, наборы типов доступа различны для разных СУБД.
Из сказанного можно заключить, что фактически управление доступом осуществляется в СУБД на двух уровнях.
1. На уровне СУБД:
а) выполняется идентификация и аутентификация по имени учетной записи и паролю, соответственно:
б) учетные записи наделяются основными и дополнительными разрешениями на использование сервисов СУБД.
2. На уровне БД:
а) выполняется идентификация пользователя — проверяется, есть ли в БД пользователь, соответствующий данной учетной записи;
б) пользователи наделяются правами доступа к объектам БД.
Что касается назначения прав доступа, традиционным способом здесь является назначение их субъекту «напрямую»: субъект S наделяется правами R к объекту О. Однако возможны ситуации, когда целая группа субъектов должна получить множество одинаковых прав. Чтобы избежать непосредственного назначения одинаковых прав каждому субъекту, целесообразно использовать механизм ролей.
В отличие от пользователя или учетной записи, роль — это административная единица доступа, соответствующая не одному, а целой группе субъектов. В роль можно включить один и более субъектов, при этом все права доступа, предоставленные данной роли, будут распространяться на субъекты, являющиеся ее членами.
Различают серверные роли, используемые для группирования учетных записей, и роли БД, — для группирования пользователей БД.
Типичными для СУБД являются такие серверные роли, как системный администратор и администратор безопасности. Системный администратор наделяется абсолютными привилегиями по администрированию сервера, администратор безопасности — правами создания, обновления и удаления учетных записей, включения учетных записей в серверные роли, назначения прав доступа на уровне СУБД. На уровне БД также имеется администратор безопасности. Он управляет пользователями БД, ролями БД. правами доступа пользователей к объектам БД. Абсолютными правами доступа на уровне БД обладает владелец БД.
Управление правами доступа включает разрешение, запрещение и неявное отклонение доступа.
Учетная запись получает возможность выполнять разрешенные ей операции над указанным объектом, если только они не запрещены ей через членство в роли БД, т. к. запрещение имеет более высокий приоритет, чем разрешение.
Запрещение доступа пользователя (роли) к объекту гарантирует, что пользователь (роль) никакими средствами не получит возможность выполнять запрещенные операции над данным объектом. Если некоторому пользователю User1 запретить выборку данных из таблицы Таblе1, то он не сможет ее производить, даже если он включен в роль, которой эта выборка разрешается. Запрещение прав доступа может каскадироваться. Допустим, имеется пользователь User1, которому было дано некоторое разрешение доступа, и который передавал это разрешение пользователям User1,…, UserN, При замене этого разрешения на данный запрет с применением каскадирования запрещение будет распространено как на User1, так и на User2,…, UserN. Каскадирование не является обязательным, но в некоторых случаях может оказаться полезным.
Неявное отклонение доступа является своего рода «средним состоянием», когда отсутствует явное разрешение или явное запрещение. Пользователь, которому явно не запрещен и не разрешен доступ к объекту, может получить (или потерять) его через членство в роли. В этом заключается принципиальная разница между неявным отклонением и запрещением: запрещение не может быть преодолено через участие в роли. Неявное отклонение, как и запрещение, может каскадироваться.
Ролевое разделение прав и иерархия пользователей
В ролевой модели классическое понятие субъекта разделяется на 2 части:
Пользователь – человек, работающий с системой и выполняющий определенные служебные обязанности.
Роль – активно действующая в системе абстрактная сущность, с которой связан ограниченный, логически связанный набор привилегий, необходимый для осуществления определенной деятельности.
Ролевая модель включает 3 компонента, модель отображения:
- Пользователь-роль
- Привилегия-роль
- Роль-роль
Так же вводится понятие иерархии ролей. Роль, входящая в иерархию, может включать другие роли, наследую все привилегии включаемых ролей.
Использование ролей в СУБД способствует избавлению администратора базы данных от большого объема рутинной работы в случаях, когда многим пользователям назначается одинаковый набор привилегий. В рамках СУБД Oracle под ролью понимается поименованный набор привилегий, который может быть предоставлен пользователю или другой роли.
Роль не является объектом какой-либо схемы. Описание привилегий, характерных для той или иной роли, готовится заранее; при регистрации нового пользователя администратор выполняет только предоставление пользователю привилегий конкретной роли.
При необходимости изменить привилегии конкретному приложению достаточно изменить привилегии соответствующей роли. Пользователь, отображенный на эту роль, автоматически получит измененную привилегию.
Для работы с ролями в Oracle предусмотрены следующие системные привилегии:
- Create role
- Grant any role – позволяет назначать любую роль любому пользователю
- Drop any role – позволяет уничтожать любую роль
- Alter any role – позволяет менять любую роль
Управлять ролями могут только владелец или же обладатель вышеперечисленных привилегий
Существует 3 предопределенные роли:
- CONNECT — гость
- RESOURCE — пользователь
- DBA – all inclusive
Иерархия прав доступа.
Правильное определение прав доступа позволяет защититься не только от угрозы вторжения злонамеренных или просто любопытных посторонних лиц, но и предотвратить нарушения в работе, обусловленные действиями ваших сотрудников и вас самих. Широко известно, что серьезные проблемы могут быть вызваны действиями служащих самой компании, обусловленными раздражительностью, невнимательностью, кратковременной потерей способности к безошибочной работе или сочетанием отрицательных мотивов. Вряд ли кому-то захочется испытать последствия прощального хлопка дверью уволенного служащего или попытки нового работника проверить действие команды DROP на производственной базе данных, лишь для того чтобы узнать, что при этом получится.
Типичная иерархия прав доступа к базе данных может выглядеть примерно так, как показано ниже.
- Посетитель Web-узла: только SELECT.
- Участник разработки: SELECT, INSERT и, возможно, UPDATE.
- Редактор содержимого узла: SELECT, INSERT, UPDATE, возможно, DELETE и, возможно, GRANT.
- Пользователь root: SELECT, INSERT, UPDATE, DELETE, GRANT И DROP.
SQL аутентификация в MS SQL Server
