InterBase обеспечивает два уровня безопасности. Первый - это проверка пользователя, которая осуществляется во время подключения к БД. Пользователь проверяется по БД безопасности сервера InterBase. Второй уровень безопасности обеспечивается на уровне БД. Все привилегии данного уровня сохраняются в самой БД. Авторизованный пользователь не имеет привилегий на данные сохраненные в БД, пока для этого пользователя явно не будут установлены привилегии. Авторизованным пользователям позволяется подключение к БД, но пока они не имеют привилегий, они не могут получить доступ к какому-либо объекту или данным в БД.
SQL-привилегии контролируются на уровне таблиц. Каждый пользователь имеет список операций, которые он или она может выполнять с данной таблицей или представлением. Этот список операций устанавливает привилегии доступа этого пользователя.
Дополнительно, InterBase устанавливает ограничения на использование хранимых процедур. Пользователь не может выполнить хранимую процедуру, пока он не получит привилегию на данную операцию.
Когда создан объект БД, только пользователь SYSDBA и владелец объекта имеет привилегии на доступ к этому объекту. Пользователь, создавший объект БД, - владелец этого объекта. SYSDBA или владелец объекта может явно устанавливать привилегии для других пользователей. Дополнительно, привилегия на установку привилегий для других пользователей может быть установлена пользователю отличному от SYSDBA или владельца объекта.
Как сказано ранее, только SYSDBA и владелец объекта изначально имеет привилегии на доступ к объекту. Если SQL-привилегии так и оставить, то они будут бесполезны. Необходим способ позволить доступ к объекту другим пользователям. Для SQL-привилегий это возможно при помощи операторов GRANT и REVOKE. Оператор GRANT используется для установки привилегий на таблицы или представления для авторизованных пользователей. Оператор REVOKE, наоборот, используется для того, чтобы убрать привилегии, которые были предварительно установлены для пользователя оператором GRANT.
Типичная ошибка: Разработчики создают объект БД и не устанавливают привилегии не одному пользователю. Пока разработчик владелец объекта - нет проблем с привилегиями. Если разработчик является владельцем, он может производить любые действия с объектом БД. Когда приходит время для выпуска приложения, другие пользователи не имеют доступа, т.к. для них не установлены привилегии на объект БД.
Для всех операций безопасности SYSDBA всегда имеет право устанавливать или убирать привилегии пользователей. Пользователь SYSDBA всегда имеет полный контроль над БД. Нет возможности запретить доступ пользователю SYSDBA. Операторы GRANT и REVOKE не действуют на SYSDBA.
Оператор GRANT устанавливает новые привилегии на объект БД для пользователя. Типы привилегий, которые могут быть установлены, перечислены в следующей таблице.
| Привилегия | Описание привилегии |
| Insert | Позволяет вставку новых записей в таблицу |
| Update | Позволяет изменение существующих записей |
| Delete | Позволяет удаление существующих записей |
| Select | Позволяет просмотр/выборку записей в таблице |
| Execute | Позволяет выполнение процедуры |
| References | Позволяет серверу подстановку в строках по ссылке первичного/вторичного ключа |
| All | Установка всех привилегий на таблицу (insert, update, delete, select, references) |
SQL определяет специального пользователя PUBLIC для представления всех пользователей. Если операция установлена для PUBLIC, то любой зарегистрированный пользователь может выполнять операцию на данном объекте БД. Следует быть осторожным при установке привилегий для PUBLIC. Все текущие и будущие пользователи смогут выполнять операции установленные для PUBLIC.
Для использования хранимой процедуры пользователь должен иметь привилегию на ее
выполнение. Формат оператора GRANT для установки привилегии на выполнение хранимой
процедуры:
GRANT EXECUTE ON PROCEDURE procname TO user;
Дополнительно, хранимая процедура должна иметь привилегии на все, имеющие к ней
отношение, таблицы для всех выполняемых операций. Например, установка привилегии
на выборку для хранимой процедуры имеет следующий формат:
GRANT SELECT ON tablename TO PROCEDURE procname;
В основном, привилегии на представления устанавливаются также как на таблицы. Есть
несколько важных различий, на которые следует обратить внимание.
Во-первых, представление - это виртуальная таблица, и является выборкой из базовой
таблицы. Данные, полученные из таблицы, не сохраняются, сохраняется только определение
запроса. Данные выбираются из базовой таблицы каждый раз, когда происходит запрос
представления. Таким образом, для любого оператора INSERT, UPDATE или DELETE операция
производится над базовых таблицах. Устанавливать привилегии INSERT, UPDATE или DELETE
на представление, необходимо только если оно с возможностью обновления. Представление
с возможностью обновления не должно содержать операций соединения или агрегатных функций.
Более полное описание представлений можно найти в InterBase Data Definition Guide
в разделе Working with Views.
Несмотря на то что возможно устанавливать привилегии INSERT, UPDATE, DELETE на представления
только для чтения без возникновения ошибки, любая попытка записи через представление не
достигнет успеха, т.к. оно только для чтения. Однако, SELECT-привилегии могут быть
установлены на такие представления для того, чтобы контролировать, какие пользователи
имеют доступ на чтение представления.
Представление также может быть использовано для контроля доступа к данным базовой таблицы. Если пользователю нужен доступ только к подмножеству записей таблицы представление может быть определено на выборку данного подмножества. Для пользователя могут быть установлены привилегии только на представление, а не на базовую таблицу. Таким образом, пользователь получает привилегии только на необходимое подмножество записей, а на остальные записи в таблице доступ отсутствует.
Например, представим таблицу, которая называется TEST_SCORES и содержит поля LASTNAME,
FIRSTNAME, TESTNAME, SCORE. Таблица содержит информацию, которую могут просмотреть
все: LASTNAME, FIRSTNAME и TESTNAME. Данная информация доступна для каждого. Также
есть информация, которая не должна быть доступна для всех пользователей: SCORE.
Необходимо позволить доступ к полю SCORE только некоторым пользователям. Это можно
осуществить, создав представление, которое осуществляет выборку общедоступных полей,
и предоставить всем привилегии только на представление, но не на базовую таблицу:
CREATE VIEW TESTTAKERS AS SELECT LASTNAME, FIRSTNAME, TESTNAME FROM TEST_SCORES;
GRANT SELECT ON TESTTAKERS TO PUBLIC;
GRANT ALL ON TEST_SCORES TO INSTRUCTOR;
В данном примере предоставляются все (ALL) привилегии на таблицу TEST_SCORES пользователю
JJOHNSON. Привилегия ALL дает пользователю JJOHNSON право на вставку, изменение, выборку,
удаление из данной таблицы:
GRANT ALL ON TEST_SCORES TO JJOHNSON;
Этот пример устанавливает привилегию ALL специальному пользователю PUBLIC. Пользователь
PUBLIC предоставляет всем текущим и будущим пользователям все привилегии на таблицу
TEST_SCORES:
GRANT ALL ON TEST_SCORES TO PUBLIC;
Следующий пример устанавливает все привилегии для хранимой процедуры. Это дает процедуре
права на доступ к таблице TEST_SCORES. Для пользователей использующих хранимую процедуру
должна быть установлена привилегия EXECUTE на выполнение процедуры (см. пример позже).
GRANT ALL ON TEST_SCORES TO PROCEDURE GET_PASSING_SCORES;
В данном примере предоставляются привилегии EXECUTE для пользователя PUBLIC, что позволяет
всем пользователям выполнять эту процедуру. Процедура должна иметь привилегии на доступ ко
всем таблицам, которые ей необходимы.
GRANT EXECUTE ON PROCEDURE GET_PASSING_SCORES TO PUBLIC;
Этот пример устанавливает привилегии INSERT на таблицу TEST_SCORES пользователю JJOHNSON.
Пользователь сможет добавлять новые записи в таблицу, но не сможет осуществлять выборку.
GRANT INSERT ON TEST_SCORES TO JJOHNSON;
Этот пример устанавливает привилегии UPDATE на подмножество полей пользователю JJOHNSON.
Пользователь сможет изменять только поля, указанные в операторе GRANT.
GRANT UPDATE (FIRST_NAME, LAST_NAME) ON TEST_SCORES TO JJOHNSON;
Первоначально, только SYSDBA и владелец может предоставлять привилегии другим пользователям. Оператор GRANT дает возможность SYSDBA или владельцу предоставить пользователю право на установку привилегий другим пользователям, для чего используется WITH GRANT OPTION. Поскольку оператор GRANT работает на отдельных таблицах, WITH GRANT OPTION может быть использована только для одной таблицы единовременно. Оператор GRANT с применением WITH GRANT OPTION должен быть использован для каждой таблицы, на которую SYSDBA или владелец хочет предоставить другим возможность установки привилегий.
Пользователи, имеющие возможность установки привилегий, могут устанавливать только те привилегии, которые имеют сами. Например, пользователь имеющий привилегию на выборку, не может устанавливать привилегию на изменение для других пользователей, а только на выборку.
В данном примере предоставляется привилегия на выборку для таблицы EMPLOYEE
пользователю BJONES, а также разрешение ему устанавливать привилегию на выборку
для данной таблицы другим пользователям:
GRANT SELECT ON employee TO bjones WITH GRANT OPTION;
Если оператор GRANT предоставляет привилегии данному пользователю, то REVOKE
позволяет отменять привилегии. Только предварительно установленные привилегии
могут быть аннулированы. Основной синтаксис оператора REVOKE следующий:
REVOKE <список операций> ON <имя таблицы> FROM
<пользователь>
Только пользователь, который предоставлял привилегию может ее отменить. Например, если userA предоставил привилегию userB, то userC не имеет права отменить привилегию userB. Только userA может аннулировать ее. Пользователь SYSDBA, как сказано выше, всегда имеет право на предоставление/аннулирование любой привилегии любого пользователя.
Привилегия ALL сочетает в себе SELECT, INSERT, UPDATE и DELETE. Она может использоваться как быстрый способ отмены нескольких привилегий пользователя. Когда отменяется привилегия ALL она аннулирует все входящие в нее. Например, пользователь имеет привилегии на вставку и выборку из таблицы. Если SYSDBA выполнит оператор REVOKE ALL, то пользователь больше не будет иметь не одной привилегии для данной таблицы.
Как сказано ранее, WITH GRANT OPTION предоставляет право на установку привилегий другим пользователям. Также пользователь получивший данное право может предоставить его другим. Это может привести к дыре в безопасности БД. Право предоставления привилегий изначально может быть только у нескольких пользователей, но быстро вырасти до огромного количества. Команда REVOKE может использоваться для того, чтобы остановить эту цепочку. Удаление привилегии у пользователя, которому она устанавливалась с WITH GRANT OPTION, также удаляет привилегии всех дополнительных пользователей, которым они были переданы. Здесь приведена последовательность событий демонстрирующая этот сценарий:
Подключение к БД как SYSDBA: GRANT ALL ON TEST_SOURCE TO USERA WITH GRANT OPTION; Подключение к БД как USERA: GRANT ALL ON TEST_SOURCE TO USERB; Подключение к БД как SYSDBA: REVOKE ALL ON TEST_SOURCE FROM USERA; Подключение к БД как USERA: SELECT * FROM TEST_SOURCE; Statement failed, SQLCODE = -551 no permission for read/select access to table TEST_SOURCE Подключение к БД как USERB: SELECT * FROM TEST_SOURCE; Statement failed, SQLCODE = -551 no permission for read/select access to table TEST_SOURCE
Если привилегии установлены для PUBLIC, они не могут быть аннулированы для отдельного пользователя и отменяться должны для пользователя PUBLIC. Специальный пользователь PUBLIC используется для предоставления доступа к таблице всем пользователям. Однако, его нельзя представить как группу пользователей. Например, PUBLIC имеет привилегию ALL на таблицу TEST_SOURCE. SYSDBA не может отменить эту привилегию только для BJONES. Если надо, чтобы только несколько пользователей имели привилегии, не следует устанавливать права на таблицу для пользователя PUBLIC.
В данном примере аннулируется привилегия ALL пользователя PUBLIC. Эта команда
подействует только на привилегии, которые установлены именно для PUBLIC. Все
привилегии предоставленные отдельным пользователям остаются действительными.
REVOKE ALL ON TEST_SOURCE FROM PUBLIC;
Следующий пример отменяет привилегию INSERT пользователя BJONES. Остальные
привилегии, которые он имеет для данной таблицы остаются действительными.
REVOKE INSERT ON TEST_SOURCE FROM BJONES;
Этот пример отменяет привилегию EXECUTE пользователя BJONES. BJONES больше не
имеет права на выполнение данной процедуры.
REVOKE EXECUTE ON PROCEDURE GET_PASSING_SCORES FROM BJONES;
Оператор REVOKE позволяет также аннулировать полномочия пользователя на предоставление
привилегий. Следующий пример отменяет полномочия пользователя BJONES на предоставление
привилегий другим пользователям. Привилегии BJONES для данной таблицы остаются.
REVOKE GRANT OPTION FOR ALL ON TEST_SOURCE FROM BJONES;
Можно также отменить полномочия на предоставление привилегий для выбранных операций.
Например, если BJONES имел полномочия для всех привилегий, команда REVOKE может быть
использована для отмены полномочий предоставления привилегий для операции INSERT:
REVOKE GRANT OPTION FOR INSERT ON TEST_SOURCE FROM BJONES;
Привилегии BJONES на вставку в таблицу TEST_SOURCE остаются, отменяется только право
предоставления привилегии INSERT другим пользователям.
Механизм безопасности SQL выполняет свою работу. Однако, он неэффективен для администраторов БД при управлении. Механизм безопасности SQL работает для индивидуальных пользователей. Кроме пользователя PUBLIC нет другой возможности предоставления привилегий на групповом уровне. К тому же, безопасность SQL работает на основе таблиц. Привилегии надо устанавливать для каждой таблицы в БД.
Например, администратор БД пытается установить SQL-безопасность для 100 пользователей на БД из 100 таблиц. В данном случае администратор должен выполнить 10000 операторов GRANT для установки безопасности на данной БД. Для каждого пользователя один оператор на каждую таблицу. Можно на каждую таблицу устанавливать привилегии для списка пользователей, но это может привести к множеству ошибок. Администратору БД надо разделить пользователей между командами и гарантировать предоставление привилегий для каждого пользователя на каждую таблицу. В большинстве случаев администраторы БД используют одного пользователя на одну команду.
Механизм безопасности SQL не облегчает задачу для DBA (DataBase Administrator) и на существующей БД. Нет условий для облегчения добавления нового пользователя на существующей БД, также как и при изменении уже установленных привилегий для группы пользователей. Для каждого нового пользователя, добавляемого в систему, DBA должен повторно использовать те же команды, что и для остальных пользователей, причем для каждой таблицы в БД. Данная администраторская операция весьма скучна. Безопасность SQL не предусматривает возможности для упрощения операции.
Недостаток групповой защиты приводит к тому, что при любом небольшом изменении в безопасности, необходимо изменять привилегии для каждого отдельного пользователя. Для чего необходимо аннулировать привилегии, которые больше не действительны, и устанавливать новые для тех же пользователей.
Безопасность SQL не обеспечивает гибкости в привилегиях пользователей. Это механизм - все или ничего. Или ты имеешь привилегии или нет. Безопасность SQL не обеспечивает гибкости изменения пользовательских привилегий без непосредственного управления каждым пользователем посредством GRANT или REVOKE. А также невозможно присвоить набор привилегий пользователю больше чем для одной таблицы одновременно.
| Пользователь InterBase | Содержание | Роли SQL |