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

Группы пользователей

В больших производственных базах данных часто имеются фуппы пользователей со схожими задачами. Например, в учебной базе данных фи человека в отделе обработки заказов образуют естественную фуппу пользователей; два человека в финансовом отделе образуют другую естественную фуппу. В пределах каждой фуппы все пользователи работают с одинаковыми данными и должны иметь идентичные привилегии. Согласно стандарту ANSI/ISO, с фуппами пользователей можно поступить одним из двух способов:

Каждому члену фуппы можно присвоить один и тот же идентификатор пользователя (рис. 15.2). Это упрощает управление системой безопасности, так как позволяет установить привилегии на доступ к данным один раз (в связи с тем, что идентификатор пользователя один). Однако в этом случае людей, совместно использующих один идентификатор пользователя, нельзя будет различить ни на дисплее системного оператора, ни в отчетах СУБД.

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

Выбор варианта зависит от того, какие компромиссы в базе данных и прикладной профамме вы допускаете.

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

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

прав доступа, совпадающие с именами групп пользователей, которые используются в RACF (утилита безопасности для мэйнфреймов компании IBM). Таким образом, применяемый в DB2 подход фактически вводит идентификаторы фупп, не расширяя явно механизм идентификаторов пользователя.

Защищаемые объекты

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

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

Привилегии

Те действия, которые пользователь имеет право выполнять над объектом базы данных, называются привилегиями пользователя по отношению к данному объекту. В стандарте SQL1 для таблиц и представлений определены четыре привилегии:

Привилегия select позволяет извлекать данные из таблицы или представления. Имея эту привилегию, можно задавать имя таблицы или представления в предложении from инструкции select ИЛИ подчиненного запроса.

Привилегия insert позволяет вставлять новые записи в таблицу или представление. Имея эту привилегию, можно задавать имя таблицы или представления в предложении into инструкции insert.

Привилегия delete позволяет удалять записи из таблицы или представления. Имея эту привилегию, можно задавать имя таблицы или представления в предложении from инструкции delete.

Привилегия update позволяет модифицировать записи в таблице или представлении. Имея эту привилегию, можно задавать таблицу или представление в инструкции update как целевую таблицу. Привилегия update может быть офаничена отдельными столбцами таблицы или представления, давая тем самым возможность обновлять только эти столбцы и запрещая обновлять другие.

Эти четыре привилегии используются фактически во всех коммерческих реляционных СУБД.

Расширенные привилегии в SQL2

В стандарте SQL2 механизм управления привилегиями значительно расширен. Определенные в SQL1 привилегии insert и update дополнены новыми возможностями. Появилась новая привилегия references, офаничиваюшая право пользователя на создание внешних ключей доступной ему таблицы для ссылок на другие таблицы. Кроме того, добавлена новая привилегия usage, управляющая доступом к новым объектам баз данных в SQL2 - доменам, наборам символов, порядкам сортировки и правилам конвертирования текста.

Привилегии insert и update теперь могут относиться к конкретному столбцу или столбца.м таблицы, а не только ко всей таблице целиком, как было в стандарте SQL1. Давайте рассмофим их применение на примере нашей учебной базы данных. Предположим, вы хотите, чтобы за добавление информации о новых служащих в таблицу salesreps отвечал начальник отдела кадров. Он должен вводить идентификатор принятого на работу служащего, его имя и прочую учетную информацию. Однако за назначение новому служащему планового объема продаж, т.е. за заполнение с голбца quota, отвечает не он, а начальник отдела сбыта. Подобным же образом начальник отдела кадров не должен иметь доступа к столбцу sales существующих записей таблицы salesreps. Используя новые возможности стандарта SQL2, можно реализовать эту схему так:

назначить начальнику отдела кадров привилегию insert на столбцы от empl num до manager; остальные столбцы (sales и quota) будут при создании принимать значения null;

начальнику отдела кадров назначить привилегию update на столбцы sales и quota, чтобы он мог назначать служащим плановые объемы продаж.

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

А вот привилегию select стандарт SQL2 не позволяет связывать с отдельными столбцами. Эта привилегия может быть назначена только на всю таблицу. Теоретически, без привилегий на отдельные столбцы можно и обойтись, создав на основе таблицы представление с избранными столбцами и назначив пользователю привилегии на доступ к этому представлению. Однако привилегии на выборку конкретных столбцов были бы более логичным и естественным способом решения задачи. Они помогли бы упростить структуру базы данных (сократив количество представлений) и создать более прозрачную и ценфализованную схему защиты, сконценфировав все ее элементы в одном месте (в инсфукциях grant). Поэтому некоторые ведущие СУБД, включая Sybase и SQL Server, все-таки позволяют назначать привилегии select на отдельные столбцы, используя тот же синтаксис, что и для привилегий insert и update, в стандарте SQL2 упоминается, что эту возможность планируется включить в его будущие версии.

Введение новой привилегии references связано с более тонкой особенностью системы безопасности баз данных в SQL2, касающейся определения внешних ключей и Офаничений на значения столбцов. Проанализируем это на примере нашей учебной базы данных. Предположим, что служащий компании может создавать в базе данных новые таблицы (например, ему может понадобиться таблица с информацией о новом товаре), но у него нет доступа к информации о служащих в таблице salesrEPS. При такой схеме защиты может показаться, что он никак не сможет узнать используемые