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

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

CREATE TABLE XYZ (TRYIT MONEY, CHECK ((SELECT QUOTA

FROM SALESREPS WHERE NAME = Bill Adams) BETWEEN 400000 AND 500000))

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

Вот эту-то лазейку для доступа к данным и закрывает введенная в стандарт SQL2 новая привилегия references. Подобно привилегиям insert и update, она назначается на отдельные столбцы таблицы. Если у пользователя есть привилегия references для некоторого столбца, он может создавать новые таблицы, связанные с этим столбцом тем или иным способом (например, через внещний ключ или ограничения на значения столбцов, как в предыдущих примерах). Если же СУБД не поддерживает привилегию references, но поддерживает внещние ключи и ограничения на значения столбцов, то иногда эту же задачу может выполнить привилегия select.

Наконец, стандарт SQL2 определяет новую привилегию usage, управляющую доступом к доменам (наборам допустимьвс значений столбцов), пользовательским наборам символов, порядкам сортировки и правилам конвертирования текста. В назначающей ее инсфукции grant указывается имя объекта и идентификатор пользователя Например, имея привилепгю usage на некоторый домен, можно определить новую таблицу и указать этот домен в качестве типа даршых какого-нибудь из ее столбцов. Без такой привилегии использовать этот домен для определения столбцов нельзя. Привилегия usage Служит главным образом для упрощения админисфирования больших корпоративных баз данных, которые используются и модифицируются несколькими различными командами разработчиков. Ее введение не связано с теми проблемами безопасности, с которыми связаны привилегии на доступ к таблицам и столбцам.

Привилегии владельца

Когда вы создаете таблицу посредством инструкции create table, вы становитесь ее владельцем и получаете все привилегии для этой таблицы (select, insert. Delete, update и другие привилегии, имеющиеся в СУБД) Другие пользователи первоначально не имеют никаких привилегий на вновь созданную таблицу. Чтобы

они получили доступ к таблице, вы должны явно предоставить им соответствующие

привилегии с помощью инструкции grant

Когда вы с помощью инструкции create view создаете представление, вы становитесь владельцем этого представления, но не обязательно получаете по отношению к нему все привилегии. Для успешного создания представления необходимо иметь привилегию select на каждую исходную таблицу представления, поэтому привилегию select на созданное представление вы получаете автоматически. Что касается остальных привилегий (insert, delete и update), to вы получаете их только в том случае, если имели их для каждой исходной таблицы представления.

Другие привилегии

Во многих коммерческих СУБД помимо привилегий select, insert, delete и update, установленных стандартом SQLl, по отношению к таблицам и представлениям могут быть выданы дополнительные привилегии. Например, в Oracle и базах данных для мэйнфреймов компании IBM предусмотрены привилегии alter и index Имея привилегию alter для какой-либо таблицы, пользователь может с помощью инструкции alter table модифицировать определение данной таблицы; имея привилегию index, пользователь может посредством инструкции create index создать индекс для таблицы. В тех СУБД, где отсутствуют привилегии alter и index, только владелец таблицы может пользоваться инструкциями alter table и create index.

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

Представления и защита данных в SQL

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

Предположим, например, что вы решили установить в учебной базе данных следующее правило защиты данных:

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

Это правило можно реализовать, создав представление

create view repinfo as

select empl num, name, rep office from salesreps

и назначив привилегаю select для этого представления пользователю с идентификатором aruser (рис. ] 5.3). в данном примере для офаничения доступа к отдельным столбцам используется вертикальное представление.

ARUSER

Представление REPINFO

SELECT

Нет доступа

Таблица SAIESREPS

Рис. 15.3. Ограничение доступа кстлбцам таблицы с помощью вертикального представления

С помощью горизонтальных представлений также можно эффективно реализо-вывать правила защиты данных. Возьмем, к примеру, такое правило:

Менеджеры по продажам каждого региона должны иметь доступ ко всем данным, касающимся служащих только их региона .

Как видно из рис. 15.4, можно создать два представления, eastreps и westreps, в которых содержатся данные таблицы salesreps отдельно по каждому региону, а затем каждому менеджеру по продажам дать разрещение на доступ к соответствующему представлению.