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

В отличие от пользователей (как обсуждалось в главе 34) привилегии применимы к уровню базы данных и хранятся непосредственно в самой базе данных в системной

таблице RDB$USER_PRIVILEGES.

База данных и все ее объекты (таблицы, просмотры и хранимые процедуры) становятся защищенными от неавторизованного доступа в момент их создания. То есть доступ является "необязательным". Ни один пользователь не может получить доступ к любому объекту базы данных, не получив на это полномочий. За исключением пользователей с особыми привилегиями - владелец, SYSDBA и (в POSIX) Суперпользователь - пользователи должны иметь привилегии SQL к любой операции, даже к SELECT.

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

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

Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.

Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.

Хотя кажется, что PUBLIC (т. е. все) имеют доступ ALL К системным таблицам, тем не менее существует таинственный черный ход в управлении правами SQL, который может легко исправить ситуацию. Вы можете ограничить доступ к системным таблицам, так же, как и к любым другим таблицам базы данных, предоставив, а затем отменив полномочия. При этом права предоставляются только для того, чтобы быть отмененными.

Все, что нужно сделать, - это просто установить управление доступом к системным таблицам путем выполнения серии операторов GRANT ALL <системная таблица> то PUBLIC. После этого мы можем отменить любые права.

Я не знаю точного технического объяснения, каким именно образом это работает, но это мой совет. Оператор GRANT создает управляющий список доступа (Access Control List, ACL) для системной таблицы, который проверяется в коде. Какая-то ветвь в этом коде означает "предоставить всем все привилегии, если элемент ACL не найден для системной таблицы, иначе использовать ACL".

Следует помнить некоторые вещи.

• Эта установка не сохраняется после восстановления базы данных из резервной копии, следовательно, напишите скрипт, который вы будете использовать каждый раз для только что восстановленной базы данных.

• Вам нужно быть внимательным по поводу удаления прав SELECT у PUBLIC К некоторым системным таблицам, потому что функции API isc_biob_iookup_desc и isc_array_iookup_bounds зависят от этой возможности. От этого также могут зависеть некоторые инструментальные средства и библиотеки.

• Удаление прав записи в системные таблицы не ограничивает возможность их изменения обычным нормальным способом с использованием команд DDL. Предотвращается только бесполезная прямая корректировка системных таблиц.

Привилегия дает возможность пользователю иметь некий вид доступа к объекту в базе данных. Она предоставляется с помощью оператора GRANT и убирается с использованием оператора REVOKE.

Синтаксис разрешения доступа:

GRANT <привилегия> ON <объект>

ТО <пользователь>;

привилегия, предоставленная пользователю к объекту, создает разрешение. Синтаксис для удаления разрешений:

REVOKE <привилегия> ON <объект>

FROM <пользователь>;