СУБД, не поддерживающих этот механизм.

Системы управления бданных, в особенности реляционные СУБД, стали доминирующим инструментом хранения больших массивов информации. Сколько-нибудь развитые информационные приложения полагаются не на файловые структуры операционных систем, а на многопользовательские СУБД, выполненные в технологии клиент/сервер. В этой связи обеспечение информационной безопасности СУБД, и в первую очередь их серверных компонентов, приобретает решающее значение для безопасности организации в целом.

Обычно в СУБД для идентификации и проверки подлинности пользователей применяются либо соответствующие механизмы операционной системы, либо SQL-оператор CONNECT. Так или иначе, в момент начала сеанса работы с сервером баз данных, пользователь идентифицируется своим именем, а средством аутентификации служит пароль. Обычно в СУБД применяется произвольное управление доступом, когда владелец объекта передает права доступа к нему (чаще говорят - привилегии) по своему усмотрению. Привилегии могут передаваться субъектам (отдельным пользователям), группам, ролям или всем пользователям.

Группа - это именованная совокупность пользователей. Объединение субъектов в группы облегчает администрирование баз данных и, как правило, строится на основе формальной или фактической структуры организации. Каждый пользователь может входить в несколько групп. Когда пользователь тем или иным способом инициирует сеанс работы с базой данных, он может указать, от имени какой из своих групп он выступает. Кроме того, для пользователя обычно определяют подразумеваемую группу.

Роль - это еще один возможный именованный носитель привилегий. С ролью не ассоциируют перечень допустимых пользователей - вместо этого роли защищают паролями. В момент начала сеанса с базой данных можно специфицировать используемую роль (обычно с помощью флагов или эквивалентного механизма) и ее пароль, если таковой имеется.Привилегии роли имеют приоритет над привилегиями пользователей и групп. Иными словами, пользователю как субъекту не обязательно иметь права доступа к объектам, обрабатываемым приложениям с определенной ролью. Совокупность всех пользователей именуется как PUBLIC. Придание привилегий PUBLIC - удобный способ задать подразумеваемые права доступа.

Пользователей СУБД можно разбить на три категории:администратор сервера баз данных. Он ведает установкой, конфигурированием сервера, регистрацией пользователей, групп, ролей и т.п. Администратор сервера имеет имя ingres. Прямо или косвенно он обладает всеми привилегиями, которые имеют или могут иметь другие пользователи. администраторы базы данных. К этой категории относится любой пользователь, создавший базу данных, и, следовательно, являющийся ее владельцем. Он может предоставлять другим пользователям доступ к базе и к содержащимся в ней объектам. Администратор базы отвечает за ее сохранение и восстановление. В принципе в организации может быть много администраторов баз данных. Чтобы пользователь мог создать базу и стать ее администратором, он должен получить (вероятно, от администратора сервера) привилегию creatdb. прочие (конечные) пользователи. Они оперируют данными, хранящимися в базах, в рамках выделенных им привилегий.

Привилегии доступа выделяются пользователям, группам, ролям или всем посредством оператора GRANT и изымаются с помощью оператора REVOKE. Эти привилегии, как правило, присваивает владелец соответствующих объектов (он же - администратор базы данных ) или обладатель привилегии security (обычно администратор сервера баз данных ).Прежде чем присваивать привилегии группам и ролям, их (группы и роли) необходимо создать с помощью операторов CREATE GROUP и CREATE ROLE.Для изменения состава группы служит оператор ALTER GROUP.

Оператор DROP GROUP позволяет удалять группы, правда, только после того, как опустошен список членов группы.Оператор ALTER ROLE служит для изменения паролей ролей, а DROP ROLE - для удаления ролей.Привилегии доступа можно подразделить в соответствии с видами объектов, к которым они относятся. Присваивание привилегий доступа производится с помощью оператора GRANT. В самом общем виде оператор GRANT имеет следующий формат: GRANT привилегии ON объекты TO кому;

Применительно к таблицам и представлениям можно управлять следующими правами доступа : SELECT - право на выборку данных INSERT - право на добавление данных DELETE- право на удаление данных UPDATE - право на обновление данных (можно указать определенные столбцы, разрешенные для обновления) REFERENCES- право на использование внешних ключей, ссылающихся на данную таблицу (можно указать определенные столбцы)

По умолчанию пользователь не имеет никаких прав доступа к таблицам и представлениям - их необходимо передать с помощью операторов GRANT. По отношению к процедуре можно предоставить право на выполнение. При этом не нужно заботиться о выделении прав доступа к объектам, обрабатываемым процедурой - их наличие не обязательно. Таким образом, процедуры баз данных являются удобным средством предоставления контролируемого доступа для выполнения строго определенных действий над данными. Права доступа к базе данных как к единому целому может предоставлять ее администратор или пользователь с привилегией security. Эти " права " на самом деле устанавливают ряд ограничений на использование базы данных, то есть по сути являются запретительными. Имеется в виду ограничение на число операций ввода/вывода или число строк, возвращаемых одним запросом, ограничение права создания таблиц и процедур и т.п. По умолчанию пользователь не стесняется количественными лимитами и получает право на создание объектов в базе.Отметим, что при создании базы данных указывается ее статус - общая или личная. Это влияет на подразумеваемые права доступа к базе. По умолчанию право на подключение к общей базе предоставляется всем. Право на подключение к личной базе нужно передавать явным образом. Право на подключение необходимо для выполнения всех прочих операций с базой и содержащимися в ней объектами. Оператор GRANT может содержать необязательную часть, принципиально важную для защиты СУБД. Имеется в виду конструкция GRANT......WITH GRANT OPTION; Подобный оператор GRANT передает не только указанные в нем привилегии, но и права на их дальнейшую передачу. Очевидно, что использование конструкции WITH GRANT OPTION ведет к децентрализации контроля над привилегиями и содержит потенциальную угрозу безопасности данных.

Для отмены привилегий, выданных ранее (как разрешительных, так и запретительных), служит оператор REVOKE. Проверка доступа производится на основании сравнения меток (Labels) объекта системы, к которому запрашивается доступ, и субъекта, который запрашивает доступ. Если метка субъекта, запрашивающего доступ имеет значение не меньшее, чем значение метки объекта, к которому доступ запрашивается, доступ предоставляется. Уточняя данное положение, требуется сказать, что субъект (например, пользователь системы) получает доступ не к самому объекту, а к соответствующему уровню конфиденциальности. Уровни конфиденциальности при этом реализованы как отдельные зоны, которым присвоены соответствующие метки.

Пользователь может получить доступ к данным, если степень его благонадежности удовлетв требованиям соответствующей метки безопасности. Более точно: уровень секретности пользователя должен быть не ниже уровня секретности данных; набор категорий, заданных в метке безопасности данных, должен целиком содержаться в метке безопасности пользователя; набор областей, заданных в метке безопасности пользователя, должен целиком содержаться в метке безопасности данных.

Механизм меток безопасности не отменяет, а дополняет произвольное управление доступом. Пользователи по-прежнему могут оперировать с таблицами только в рамках своих привилегий, но даже при наличии привилегии SELECT им доступна, только часть данных. При добавлении или изменении строк они, как правило, наследуют метки безопасности пользователя, инициировавшего операцию. Таким образом, даже если авторизованный пользователь перепишет секретную информацию в общедоступную таблицу, менее благонадежные пользователи не смогут ее прочитать.

Специальная привилегия, DOWNGRADE, позволяет изменять метки безопасности, ассоциированные с данными. Подобная возможность необходима, например, для коррекции меток, по тем или иным причинам оказавшихся неправильными.

 

Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 13 - Предложение SELECT языка SQL. Сортировка (ORDER BY). Группирование данных (GROUP BY, GROUP BY … HAVING).
Часть 14 - СУБД, основанные на инвертированных списках (dBase, Clipper, FoxPro, Paradox). Иерархические СУБД. Сетевые
Часть 15 - Права доступа к базам данных и таблицам. Предложения GRANT и REVOKE. Метки доступа. Способ организации меток доступа для
Часть 16 - Гипертекст. Навигация, как способ доступа к данным. Web-интерфейсы к базам данных. XML и Web-службы (Web-Services).
Часть 17 - 2)Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и NOT EXIST.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и