Читать онлайн «Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ». Страница 157

Вторая цель требует большой работы по ограничению доступа к конфиденциальным или чувствительным данным. Привилегии 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 <пользователь>;

Доступны некоторые варианты "центрального" синтаксиса. Мы рассмотрим их несколько позже.

Привилегия представляет разрешение выполнять операцию DML. В табл. 35.1 описываются привилегии SQL, которые могут быть предоставлены или удалены.

Таблица 35.1. Привилегии SQL

Привилегия

Доступ

SELECT

Чтение данных

INSERT

Создание новых строк

UPDATE

Изменение существующих данных

DELETE

Удаление строк

REFERENCES

Ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи

ALL

Выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа

EXECUTE

Выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL (см. разд. "Ключевое слово ALL")

ROLE

Предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится привилегией, которая может явно назначаться пользователям. Роль никогда не предоставляется как часть привилегии ALL

SQL Firebird реализует возможности упаковки множества привилегий для назначения индивидуальным получателям, спискам или специально сгруппированным пользователям. Это пакет ALL, разделенные запятыми списки и роли SQL.

Ключевое слово ALL

Ключевое слово ALL упаковывает привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES в одном назначении. Роли и привилегия EXECUTE не включены в пакет ALL.

Привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES также могут быть предоставлены или отменены поодиночке или в списках, разделенных запятыми. При этом в операторах, где предоставляются или отменяются привилегия EXECUTE или привилегия роли, нельзя предоставлять или отменять другие привилегии.

Роль создается в базе данных и доступна только в этой базе данных. Думайте о роли, как о емкости для набора привилегий. Когда емкость "заполнена" некоторыми привилегиями, она становится доступна - как привилегия - некоторым типам пользователей.

Может быть создано множество ролей. Здесь основная мысль в том, чтобы упаковать и управлять дискретными наборами привилегий, которые могут назначаться и отменяться как одно целое, вместо того, чтобы постоянно назначать и отменять большие количества индивидуальных привилегий.

Роль никогда не может быть предоставлена как часть пакета ALL, хотя роли могут быть назначены привилегии ALL.

Роли не похожи на пользовательские группы операционной системы. Пользователю Firebird может быть назначено более одной роли, однако он может подключиться к базе данных за один раз только с одной ролью.

Firebird поддерживает группы UNIX на платформах POSIX. Если реализована идентификация на уровне системы, вы можете предоставлять привилегии группам UNIX. См. вариант то GROUP <mix-rpynna> в операторах GRANT и REVOKE.

"Другой частью" полномочий является объект, к которому применяется привилегия или для которого она отменяется. Объектом может быть таблица, просмотр, хранимая процедура или роль, хотя не все привилегии применимы ко всем типам объектов. Например, привилегия UPDATE неприменима к процедуре, а привилегия EXECUTE - к таблице или просмотру.

Не существует "пакета объектов", который включает все или группу объектов. Должен быть, по крайней мере, один оператор GRANT для каждого объекта базы данных.

Привилегии SELECT, INSERT, UPDATE и DELETE применимы только к объектам, являющимся таблицами или просмотрами, REFERENCES применяется только к таблицам - точнее к тем, на которые ссылаются внешние ключи.

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