Для определения конкретных назначений или установления правил и ограничений доступа при проектировании банков данных АИС, а также в целях управления системой разграничения доступа и в более широком смысле системой коллективной обработки данных администратору системы необходим специальный инструментарий. Такой инструментарий должен основываться на определенном языке, позволяющем описывать и устанавливать те или иные назначения доступа и другие необходимые установки политики безопасности в конкретной АИС.
В реляционных СУБД такой язык должен являться соответственно составной частью языка SQL. Исторически впервые подобные вопросы были поставлены и реализованы в упоминавшихся языках SEQUEL (созданного в рамках проекта System R фирмы IBM) и языка QUEL (созданного в рамках проекта INGRES) и послуживших в дальнейшем основой для языка SQL.
Как уже отмечалось нами, в перечне базовых инструкций языка SQL представлены инструкции GRANT и REVOKE, предоставляющие или отменяющие привилегии пользователям. Структура инструкции GRANT выглядит следующим образом:
GRANTсписок_привилегий_через_запятую ON ИмяОбъекта
TOИменаПользователей_через_запятую
[WITHGRANTOPTION];
где:
— список привилегий составляют разрешенные инструкции (операции) над объектом (таблицей) — SELECT, INSERT, UPDATE, DELETE;
— список пользователей представляется их именами-идентификаторами или может быть заменен ключевым словом PUBLIC, которое идентифицирует всех пользователей, зарегистрированных в системе;
— директива WITH GRANT OPTION наделяет перечисленных пользователей дополнительными особыми полномочиями по предоставлению (перепредоставлению) указанных в списке привилегий-полномочий другим пользователям.
В большинстве случаев право подачи команд GRAND и REVOKE по конкретному объекту автоматически имеют пользователи, создавшие данный объект, т. е. их владельцы. В других подходах этим правом наделяются доверенные субъекты, т. е. администраторы.
Хотя в явном виде такой подход не предусматривает создание матрицы доступа,* тем не менее, реализуется классический принцип дискреционного разграничения доступа с сочетанием как добровольного, так и принудительного управления доступом.
* На самом деле в большинстве СУБД привилегии и установки доступа, как и структура базы данных, «прописываются» в системных таблицах БД, т.е. в системном каталоге БД. который можно рассматривать, в том числе и в качестве матрицы доступа.
Как уже отмечалось, дискреционный принцип обладает большой гибкостью по настройке системы разграничения доступа на особенности предметной области базы данных и потребности пользователей, но не обеспечивает эффективной управляемости и затрудняет проведение какой-либо целенаправленной политики безопасности в системе. Преодоление этого недостатка достигается двумя путями — использованием техники «представлений» и специальными расширениями языка SQL.
Использование техники представлений является распространенным технологическим приемом формирования для конкретного пользователя своего «видения» базы данных (виртуальной БД) и осуществления на этой основе разграничения доступа к данным в реляционных СУБД. Напомним, что «представлением» называется глобальный авторизованный запрос на выборку данных, формирующий для пользователя «свое» представление определенного объекта (объектов), совокупность которых формирует некую виртуальную базу данных, со своей схемой (объектами) и данными (отобранными или специально преобразованными — razgovorodele.ru). При входе пользователя в систему в процессе его идентификации и аутентификации ядро безопасности отыскивает для пользователя соответствующие представления-запросы и передает запрос основному ядру СУБД для выполнения. В результате выполнения запроса пользователь «видит» и имеет доступ только к тем объектам, которые соответствуют его полномочиям и функциям.
В целом создание системы разграничения доступа через технику представлений является более простым способом, чем непосредственное использование инструкций GRANT, и осуществляется в два этапа:
1. Для всех зарегистрированных пользователей в системе с помощью конструкций CREAТЕ VIEW создаются свои представления объектов базы данных.
2. С помощью инструкций «GRANT SELECT ONИмяПредставления ТО ИмяПользователя» созданные представления авторизуются со своими пользователями.
Вместе с тем такой подход является более грубым по сравнению с применением инструкции GRANT непосредственно к объектам базы данных, т. к. не обеспечивает расщепления установок доступа к объектам на уровне отдельных операций (SELECT, INSERT, UPDATE, DELETE).
Поэтому другим подходом являются специальные расширения языка SQL, основанные на событийно-процедурной идеологии с введением специальных правил (RULE) безопасности:
CREATESECURITYRULEИмяПравила
GRANTсписок_привилегий_через_запятую ON ИмяОбъекта
WHERE условия
TOИменаПользователей_через_запятую
Реакция_на_нарушение_правила;
Введение правил безопасности обеспечивает более широкие и гибкие возможности реализации различных политик безопасности с большей степенью контроля и управляемости, но, как, впрочем, и техника представлений и непосредственное использование инструкций GRANT, не позволяет строить системы с мандатным принципом разграничения доступа, который считается более жестким и надежным — razgovorodele.ru. Для решения этой задачи могут предлагаться более кардинальные расширения языка SQL с введением возможностей создания объектов базы данных с метками конфиденциальности. Следует, однако, заметить, что подобные примеры в коммерческих и сертифицированных по требованиям безопасности СУБД чрезвычайно редки.
В заключение по языкам безопасности баз отметим, что в современных СУБД для реализации установок, правил и ограничений доступа разрабатывается и используется специальный диалогово-наглядный интерфейс, автоматически формирующий соответствующие конструкции языка SQL и позволяющий в большинстве случаев обходиться без непосредственного программирования.