Ограничения ссылочной целостности угрожают вашим данным
Ограничения ссылочной целостности угрожают вашим данным
Возможно, вы думаете, что если можете контролировать функции просмотра, создания, изменения и удаления в таблице, то вы надежно защищены. В большинстве случаев это правда. Однако с помощью непрямого метода опытный хакер все равно имеет возможность сделать подкоп под вашу базу.
Правильно спроектированная реляционная база данных имеет ссылочную целостность, т.е. данные в одной таблице из базы данных согласуются с данными во всех других таблицах. Чтобы обеспечить ссылочную целостность, проектировщики баз данных применяют к таблицам такие ограничения, которые относятся к вводимым в таблицу данным. И если ваша база данных имеет ограничения ссылочной целостности, то какой-либо пользователь может создать новую таблицу, где в качестве внешнего ключа используется столбец из засекреченной таблицы вашей базы. Вполне возможно, что в таком случае этот столбец можно использовать в качестве канала кражи конфиденциальной информации.
Скажем, вы, например, являетесь знаменитым аналитиком с Уолл-Стрит. Многие верят в точность вашего биржевого анализа, и если вы рекомендуете подписчикам своего бюллетеня какие-либо ценные бумаги, то многие люди их покупают, и стоимость этих бумаг растет. Ваш анализ хранится в базе данных, в которой находится таблица 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 (прекратить), и обнаруживаете, что уничтожить свое ограничение (или свою таблицу) вначале должен кто-то другой.
Следовательно, предоставление другим лицам возможности устанавливать ограничения целостности на вашу таблицу не только создает потенциальную угрозу безопасности, но иногда и усложняет вашу работу.
