Обеспечение безопасности базы данных
При использовании доменов возникают вопросы, связанные с безопасностью. Если кто-то другой вдруг захочет использовать созданные вами домены, то может ли такое использование привести к осложнениям? Может. Что если кто-то создаст таблицу со столбцом, в котором используется домен PriceTypeDomain? Пользователь может в этом столбце постепенно увеличивать значения и делать это до тех пор, пока столбец не перестанет их принимать. Таким образом можно будет определить верхнюю границу значений PriceType (тип цены), которую вы указали в предложении CHECK (проверка) оператора CREATE DOMAIN. И если значение этой верхней границы является закрытой информацией, необходимо запретить использовать домен PriceType неуполномоченным пользователям. Чтобы защитить вас в подобных ситуациях, SQL позволяет использовать чужие домены только тем, кому владельцы доменов явно предоставят соответствующее разрешение. Такое разрешение может предоставлять только владелец домена (и, конечно же, администратор). А само предоставление разрешения выглядит так:
GRANT USAGE ON DOMAIN PRICE_TYPE TO SALES_MGR;
Внимание:
Если к доменам применять оператор DROP, то могут возникнуть проблемы, связанные с безопасностью. И когда вы попытаетесь с помощью DROP отправить домен "в небытие", а в каких-либо таблицах есть столбцы, определенные с помощью этого домена, то такие таблицы станут источником неприятностей. Не исключено, что перед тем как применить оператор DROP к самому домену, этот оператор вначале придется применить к каждой из использующих его таблиц. Возможно, вы обнаружите, что к доменам этот оператор вообще не применим. Действие оператора DROP зависит от конкретной реализации. SQL Server может сильно отличаться в этом смысле от Oracle. Но, видимо, в любом случае придется ограничить круг лиц с разрешением применять оператор DROP к доменам. То же самое относится к наборам символов, сопоставлениям и трансляциям.
Инициирование выполнения операторов SQL
В некоторых случаях выполнение одного оператора SQL может вызвать запуск другого оператора или даже целого их блока. Поддержка такой функции (триггерной схемы) и была осуществлена в версии SQL:2003.
Триггер – это механизм, который задает триггер-событие (событие для запуска), время активизации триггера и одно или несколько запускаемых действий. Триггер-событие инициирует запуск, выражаясь простым языком, дает команду "огонь". Время активизации триггера указывает, в какой момент должно произойти действие: непосредственно перед триггер-событием или после него. Запускаемое действие – это выполнение одного или нескольких операторов SQL. При запуске более одного оператора SQL все операторы должны содержаться в пределах структуры BEGIN ATOMIC… END. Само триггер-событие может использовать оператор INSERT, UPDATE или DELETE.
К примеру, вы можете использовать триггер для выполнения оператора, который контролирует истинность новых значений, перед применением обновления данных. Если новые значения будут неверными, обновление данных будет прервано.
Как показано в следующем примере, пользователь или роль должны иметь привилегию на создание триггера:
CREATE TRIGGER CustomerDelete BEFORE DELETE
ON CUSTOMER FOR EACH ROW
WHEN State = NY
INSERT INTO CUSTLOG VALUES ('deleted a NY customer'):
Теперь при каждом удалении нью-йоркского клиента из таблицы CUSTOMER в регистрационной таблице CUSTLOG будет сделана запись об удалении.
Предоставление полномочий
Администратор базы данных может предоставить любому пользователю любые полномочия. Владелец объекта также может предоставить любому пользователю любые полномочия, связанные с этим объектом. Однако те, кто получил таким образом свои полномочия, не могут их, в свою очередь, предоставить третьим лицам. Это ограничение позволяет администратору или владельцу объекта в достаточной степени сохранять контроль над ситуацией. Доступ к объекту могут получить только пользователи, уполномоченные на это администратором или владельцем объекта.
Если смотреть с точки зрения безопасности, то представляется разумным ограничить возможность раздавать полномочия доступа. Тем не менее часто пользователям нужны именно права на предоставление полномочий. Конвейер не может остановиться только из-за того, что кто-то заболел, находится в отпуске или ушел на обед. Вы можете дать некоторым пользователям право предоставлять их права доступа надежным сменщикам. Для передачи пользователю такого права в операторе GRANT используется предложение WITH GRANT OPTION (предоставляющий полномочия). Следующий оператор показывает пример того, как можно использовать это предложение:
GRANT UPDATE (BonusPct) ON BONUSRATE TO SalesMgr WITH GRANT OPTION;
Теперь менеджер по продажам может предоставить права на обновление данных при помощи следующего оператора:
GRANT UPDATE (BonusPct) ON BONUSRATE TO AsstSalesMgr;
После того как этот оператор выполнится, заместитель менеджера по продажам сможет обновлять данные таблицы BONUSRATE, т.е. получит полномочия, которых у него до этого не было.
Внимание:
Приходится искать компромисс между безопасностью и удобством. Владелец таблицы BONUSRATE, предоставляя менеджеру по продажам полномочия UPDATE вместе с атрибутом WITH GRANT OPTION, делится с ним значительной частью своей власти. Ему остается надеяться, что менеджер по продажам серьезно отнесется к этой ответственности и будет осторожен с передачей полномочий другим лицам.