ПРИНЦИПЫ ЗАЩИТЫ ДАННЫХ в стандартном SQL (без редакции)

За реализацию системы безопасности отвечает СУБД. Язык SQL является фундаментом системы безопасности реляционной СУБД: требования, предъявляемые к системе защиты информации в базе данных, формулируются с помощью инструкций SQL. С защитой данных в SQL связаны три основные концепции:

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

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

- Привилегии – это права пользователя на проведение тех или иных действий над определенным объектом базы данных. Например, пользователю может быть разрешено, извлекать строки из некоторой таблицы и добавлять их в неё, но запрещено удалять или обновлять строки этой таблицы. У другого пользователя может быть другой набор привилегий.

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

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

В стандарте ANSI/ISO вместо термина “идентификатор пользователя” (user-id) употребляется термин идентификатор прав доступа (authorization-id), и он встречается иногда в документации по SQL. С технической точки зрения второй термин является более правильным, так как в действительности идентификатор определяет права или привилегии. Бывают ситуации, когда имеет смысл присвоить нескольким пользователям одинаковый идентификатор. В других ситуациях один пользователь может пользоваться двумя или тремя различными идентификаторами. В промышленной базе данных идентификатор прав доступа может относиться к программам и группам программ, а не к отдельным людям.

Аутентификация пользователей. Безопасность базы данных обеспечивается с помощью идентификаторов пользователей. Однако в стандарте ничего не говорится о механизме связи идентификатора пользователя с инструкциями SQL. Например, на сервере БД может существовать программа генерации отчетов, запланированная на выполнение каждый вечер, каков в этом случае идентификатор, если нет самого пользователя? Наконец, как обрабатываются запросы к базе данных по сети, если на локальном компьютере у пользователя может быть один идентификатор, а на удаленном компьютере – другой?

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

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

В некоторых СУБД реализована своя собственная система безопасности с идентификаторами пользователей и паролями. Например, когда в СУБД ORACLE вы работаете с интерактивной SQL-утилитой, которая называется SQL*Plus, вы вводите имя пользователя и соответствующий пароль.

Защищаемые объекты. Средства защиты в SQL применяются по отношению к отдельным объектам базы данных. В стандарте SQL1 указаны два типа защищаемых объектов – таблицы и представления. Таким образом, каждая таблица и представление могут быть защищены индивидуально. Доступ к ним может быть разрешен для одних пользователей и запрещен для других. Стандарт SQL2 расширяет круг защищаемых объектов, включая в него домены, и пользовательские наборы символов.

В большинстве коммерческих реляционных СУБД дополнительно могут быть защищены и другие объекты. Например, в ORACLE важным объектом базы данных является хранимая процедура. С помощью средств защиты SQL устанавливается, какие пользователи могут создавать и удалять хранимые процедуры и какие пользователи могут их выполнять.

Привилегии.Как уже указывалось привилегии – это права пользователя на проведение тех или иных действий над определенным объектом базы данных. В SQL предоставление тех или иных прав над различными объектами баз данных возможно посредством инструкции GRANT. Обычно инструкцией GRANT пользуется владелец таблицы или представления, чтобы разрешить другим пользователям доступ к этим данным. Особенности данной инструкции рассматриваются ниже в настоящем разделе. Здесь же следует указать, что многие коммерческие СУБД поддерживают набор системных привилегий. Системная привилегия – это мощная привилегия, которая предоставляет пользователю возможность выполнять системную операцию определенного вида.

Отметим, что вопросы создания и использования таких объектов баз данных как хранимые процедуры, функции и модули будут рассмотрены ниже в разделе, посвященном PL/SQL, процедурного языка программирования, который встроен в большинство продуктов корпорации ORACLE – ведущего производителя промышленных СУБД.

Работа с привилегиями при помощи ролей. Вполне возможно, что для использования обычного приложения баз данных придется назначать множество системных привилегий. Когда с приложением работает множество пользователей, управление привилегиями может быстро превратиться в достаточно трудную задачу, так как нужно будет предоставлять привилегии каждому пользователю. Чтобы упростить процесс обеспечения безопасности системы некоторые СУБД в частности ORACLE позволяют воспользоваться ролями. Роль – это совокупность системных привилегий, предоставляемых пользователям и другим ролям. Например, при создании нового приложения можно создать новую роль с привилегиями, необходимыми для выполнения данной программы. После того как пользователю приложения предоставляется эта роль, он может запускать приложение, соединяться с базой данных и выполнять свою работу. Если привилегии, необходимые для выполнения приложения изменяются, то нужно только быстро модифицировать набор привилегий, заданных в роли. Все пользователи, которым предоставлена эта роль, автоматически отслеживают происшедшие изменения и продолжают работу с приложением, имея на то необходимые привилегии. Надо отметить, что СУБД может предоставлять пользователям некоторое количество предварительно установленных ролей.

Роли, определяемые пользователями. Для базы данных ORACLE можно создавать любое требуемое количество ролей. После создания роли нужно построить для нее набор привилегий, предоставив ей привилегии и другие роли. Затем надо предоставить эту роль пользователям, чтобы они имели привилегии, необходимые им для работы.

Ниже приведен пример создания новой роли для типичного приложения по вводу заказов, а также предоставления роли ряду пользователей базы данных.

create role order_entry;

grant select, insert, update, delete on sales.customers to order_entry;

grant select, insert, update, delete on sales. orders to order_entry;

grant select, insert, update, delete on sales.items to order_entry;

grant select, update on sales.parts to order_entry;

grant order_entry to smith, alice, george;

В приведенном примере sales – схема базы данных; customers, orders, items, parts – таблицы этой схемы; smith, alice, george – пользователи базы данных, полномочия которых распространяются на объекты схемы sales. Как видно из примера сначала создается роль, а уже затем посредством инструкции GRANT задаются привилегии этой роли. Особенности задания инструкции GRANT рассматриваются ниже, в параграфе “предоставление привилегий”.