Язык запросов SQL

Ограничения ссылочной целостности угрожают вашим данным



Ограничения ссылочной целостности угрожают вашим данным

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

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

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

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

CREATE TABLE HOT_STOCKS (

         STOCK CHARACTER (30) REFERENCES FOUR_STAR

         );

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

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

REFERENCES (STOCK)

         ON FOUR_STAR

         TO IMASECRET_HACKER;

Совет 3
Совет 3

He предоставляйте полномочия тем, кто может ими злоупотребить. Конечно, гарантии у людей на лбу не написаны. Но если вы кому-либо не собираетесь давать свой новый автомобиль для дальней поездки, то, скорее всего, не должны также предоставлять этому человеку и полномочия REFERENCES на ценную таблицу.

Этот пример показывает первую уважительную причину, чтобы осторожно обращаться с полномочиями REFERENCES. А ниже указаны еще две причины, чтобы быть осторожными с этим видом полномочий.

  • Если кто-то другой установил в таблице HOT_STOCKS ограничение с помощью ключевого слова RESTRICT (ограничить), а вы пытаетесь из своей таблицы удалить строку, то СУБД сообщит, что вам этого делать нельзя, так как будет нарушена ссылочная целостность.
  • Вы решаете, что для уничтожения вашей таблицы нужна команда DROP (прекратить), и обнаруживаете, что уничтожить свое ограничение (или свою таблицу) вначале должен кто-то другой.

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



Содержание раздела