Компоненты SQL
Теперь хакер может вставить в свою таблицу HOT_STOCKS названия всех ценных бумаг с Нью-йоркской фондовой биржи. Те названия, которые будут успешно вставлены, подскажут ему, что именно находится в вашей конфиденциальной таблице. Благодаря быстродействию компьютеров хакеру не потребуется много времени, чтобы вытащить весь ваш список ценных бумаг.
Вы сможете защитить себя от проделок, аналогичных показанной в предыдущем примере, если будете остерегаться вводить операторы такого рода:
REFERENCES (STOCK) ON FOUR_STAR TO IMASECRET_HACKER;
Совет:
He предоставляйте полномочия тем, кто может ими злоупотребить. Конечно, гарантии у людей на лбу не написаны. Но если вы кому-либо не собираетесь давать свой новый автомобиль для дальней поездки, то, скорее всего, не должны также предоставлять этому человеку и полномочия REFERENCES на ценную таблицу.
Этот пример показывает первую уважительную причину, чтобы осторожно обращаться с полномочиями REFERENCES. А ниже указаны еще две причины, чтобы быть осторожными с этим видом полномочий.
- Если кто-то другой установил в таблице HOT_STOCKS ограничение с помощью ключевого слова RESTRICT (ограничить), а вы пытаетесь из своей таблицы удалить строку, то СУБД сообщит, что вам этого делать нельзя, так как будет нарушена ссылочная целостность.
- Вы решаете, что для уничтожения вашей таблицы нужна команда DROP (прекратить), и обнаруживаете, что уничтожить свое ограничение (или свою таблицу) вначале должен кто-то другой.
Следовательно, предоставление другим лицам возможности устанавливать ограничения целостности на вашу таблицу не только создает потенциальную угрозу безопасности, но иногда и усложняет вашу работу.
Делегирование ответственности за безопасность
Если вы хотите сохранять свою систему в безопасности, то должны строго ограничить полномочия доступа, которые вы предоставляете, и круг тех людей, кому вы предоставляете эти полномочия. Однако те, кто не может работать из-за отсутствия доступа, скорее всего, будут постоянно вам надоедать. Чтобы иметь возможность сосредоточиться, вам придется кому-то делегировать часть своей ответственности за безопасность базы данных. В SQL такое Делегирование выполняется с помощью предложения WITH GRANT OPTION (с возможностью предоставления). Проанализируйте следующий пример:
GRANT UPDATE ON RETAIL_PRICE_LIST TO SALES_MANAGER WITH GRANT OPTION
Этот оператор похож на приведенный в предыдущем примере с GRANT UPDATE в том смысле, что дает возможность менеджеру по продажам обновлять розничный прайс – лист. Но, кроме того, новый оператор еще дает ему право предоставлять полномочия на обновление любому, кому он захочет. И если вы используете такую форму оператора GRANT, то обязаны не только быть уверены, что менеджер по продажам разумно использует предоставленные полномочия, но также должны быть уверены, что он будет осторожно предоставлять подобные полномочия другим пользователям.
Внимание:
Крайняя доверчивость означает и крайнюю уязвимость. Будьте чрезвычайно осторожны, используя подобные операторы:
GRANT ALL PRIVILEGES ON FOUR_STAR TO BENEDICT_ARNOLD WITH GRANT OPTION
Здесь пользователь ВENEDICT_ ARNOLD получает все полномочия FOUR_STAR с возможностью передачи этих полномочий другим лицам.