27. Операторы обеспечения безопасности

27.1. Операторы управления пользователями

В данном разделе описываются операторы создания, модификации и удаления учётных записей пользователей средствами операторов SQL. Такая возможность предоставлена следующим пользователям:

SYSDBA;
Любому пользователю, имеющему права на роль RDB$ADMIN в базе данных пользователей и права на ту же роль для базы данных в активном подключении. Пользователь должен подключаться к базе данных с ролью RDB$ADMIN или получить её права, если роль назначена в качестве роли по умолчанию;
Любому пользователю с ролью, которой назначена системная привилегия USER_MANAGEMENT в базе данных безопасности (о системных привилегиях см. раздел 27.2). Пользователь должен подключаться к базе данных с этой ролью или получить её права, если роль назначена в качестве роли по умолчанию;
При включенном флаге AUTO ADMIN MAPPING в базе данных пользователей (security5.fdb или той, что установлена для вашей базы данных в файле databases.conf) — любой администратор операционной системы Windows (при условии использования сервером доверенной авторизации — trusted authentication) без указания роли. При этом не важно, включен или выключен флаг AUTO ADMIN MAPPING в самой базе данных.

Непривилегированные пользователи могут использовать только оператор ALTER USER для изменения собственной учётной записи.

CREATE USER

Оператор CREATE USER создаёт учётную запись пользователя РЕД Базы Данных. Пользователь должен отсутствовать в текущей базе данных безопасности иначе будет выдано соответствующее сообщение об ошибке.

Листинг 27.1 Синтаксис оператора CREATE USER

CREATE USER <логин> PASSWORD '<пароль>'
   [FIRSTNAME '<имя пользователя>']
   [MIDDLENAME '<отчество пользователя>']
   [LASTNAME '<фамилия пользователя>']
   [ACTIVE | INACTIVE]
   [USING PLUGIN 'имя плагина']
   [TAGS (<атрибут> [, <атрибут> ...] )]
   [GRANT ADMIN ROLE]

<атрибут> ::= <имя атрибута> = 'строковое значение'

Начиная с версии 3.0 имена пользователей подчиняются общему правилу наименования идентификаторов объектов метаданных. Таким образом, пользователь с именем "Alex" и с именем "ALEX" будут разными пользователями.

Предложение PASSWORD задаёт пароль пользователя. Максимальная длина пароля зависит от того какой менеджер пользователей задействован (параметр UserManager в файле конфигурации firebird.conf). Для менеджер пользователей SRP эффективная длина пароля ограничена 20 байтами. Для менеджер пользователей Legacy_UserManager максимальная длина пароля равна 8 байт.

Необязательные предложения FIRSTNAME, MIDDLENAME и LASTNAME задают дополнительные атрибуты пользователя, такие как имя пользователя, отчество и фамилия соответственно. Максимальная длина 32 символа.

Кроме того можно задать неограниченное количество пользовательских атрибутов с помощью необязательного предложения TAGS. Данная возможность доступна только при использовании Srp в качестве менеджера пользователей.

Если при создании учётной записи будет указан атрибут INACTIVE, то пользователь будет создан в "неактивном состоянии", т.е. подключиться с его учётной записью будет невозможно. При указании атрибута ACTIVE пользователь будет создан в активном состоянии (по умолчанию). Данная возможность доступна только при использовании Srp в качестве менеджера пользователей.

С опцией GRANT ADMIN ROLE создаётся новый пользователь с правами роли RDB$ADMIN в базе данных пользователя (security5.fdb). Это позволяет ему управлять учётными записями пользователей, но не дает ему специальных полномочий в обычных базах данных.

Необязательное предложение USING PLUGIN позволяет явно указывать какой плагин управления пользователями будет использован. По умолчанию используется тот плагин, который был указан первым в списке параметра UserManager в файле конфигурации firebird.conf. Допустимыми являются только значения, перечисленные в параметре UserManager. Следует учитывать, что одноименные пользователи, созданные с помощью разных плагинов управления пользователями — это разные пользователи.

Примечание

Если предложение USING PLUGIN не указано, то при добавлении пользователя он сам добавляется во все плагины из списка параметра DefaultUserManagers (в том числе его атрибуты).

CREATE USER jon PASSWORD '87654321'
FIRSTNAME 'Jon'
LASTNAME 'Snow'
TAGS (BIRTHYEAR = '283' , CITY = 'Winterfell');

Подробнее о работе с пользователями см. в «Руководстве администратора».

ALTER USER

Для изменения существующей учетной записи пользователя используется следующий синтаксис:

Листинг 27.2 Синтаксис оператора ALTER USER

ALTER {USER <логин> | CURRENT USER}
{
   [SET]
   [PASSWORD '<пароль>']
   [FIRSTNAME '<имя пользователя>']
   [MIDDLENAME '<отчество пользователя>']
   [LASTNAME '<фамилия пользователя>']
   [ACTIVE | INACTIVE]
   [TAGS (<атрибут>|DROP <имя атрибута> [, <атрибут>|DROP <имя атрибута>...] )]
}
[USING PLUGIN 'имя плагина']
[{GRANT | REVOKE} ADMIN ROLE];

<атрибут> ::= <имя атрибута> = 'строковое значение'

В операторе ALTER USER должно присутствовать хотя бы одно из необязательных предложений.

Это единственный оператор управления учётными записями, который может также использоваться непривилегированными пользователями для изменения их собственных учетных записей, однако это не относится к опциям GRANT/REVOKE ADMIN ROLE и атрибуту ACTIVE/INACTIVE для изменения которых, необходимы административные привилегии. Если требуется изменить свою учётную запись, то вместо указания имени текущего пользователя можно использовать предложение CURRENT USER.

Необязательное предложение PASSWORD задаёт новый пароль пользователя.

Необязательные предложения FIRSTNAME, MIDDLENAME и LASTNAME позволяют изменить дополнительные атрибуты пользователя, такие как имя пользователя (имя человека), отчество и фамилия соответственно.

Атрибут INACTIVE позволяет сделать учётную запись неактивной. Это удобно когда необходимо временно отключить учётную запись без её удаления. Атрибут ACTIVE позволяет вернуть неактивную учётную запись в активное состояние. Данная возможность доступна только при использовании Srp в качестве менеджера пользователей.

Необязательное предложение TAGS позволяет задать, изменить или удалить пользовательские атрибуты. Если в списке атрибутов, атрибута с заданным именем не было, то он будет добавлен, иначе его значение будет изменено. Атрибуты не указанные в списке не будут изменены. Для удаления пользовательского атрибута перед его именем в списке атрибутов необходимо указать ключевое слово DROP. Данная возможность доступна только при использовании Srp в качестве менеджера пользователей.

Предложение GRANT ADMIN ROLE предоставляет указанному пользователю привилегии роли RDB$ADMIN в текущей базе данных безопасности. Это позволяет указанному пользователю управлять учётными записями пользователей, но не даёт ему специальных полномочий в обычных базах данных.

Предложение REVOKE ADMIN ROLE отбирает у указанного пользователя привилегии роли RDB$ADMIN в текущей базе данных безопасности. Это запрещает указанному пользователю управлять учётными записями пользователей.

Необязательное предложение USING PLUGIN позволяет явно указывать какой плагин управления пользователями будет использован. По умолчанию используется тот плагин, который был указан первым в списке параметра UserManager в файле конфигурации firebird.conf. Допустимыми являются только значения, перечисленные в параметре UserManager.

Примечание

Если предложение USING PLUGIN не указано, то при изменении атрибутов пользователя они сами меняется у соответствующих пользователейво во всех плагинах из списка параметра DefaultUserManagers.

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

CREATE OR ALTER USER

Оператор CREATE OR ALTER USER создаёт новую или изменяет учётную запись.

Листинг 27.3 Синтаксис оператора CREATE OR ALTER USER

CREATE OR ALTER USER <логин>
{
   [SET]
   [PASSWORD '<пароль>']
   [FIRSTNAME '<имя пользователя>']
   [MIDDLENAME '<отчество пользователя>']
   [LASTNAME '<фамилия пользователя>']
   [ACTIVE | INACTIVE]
   [TAGS (<атрибут>|DROP <имя атрибута> [, <атрибут>|DROP <имя атрибута>...] )]
}
[USING PLUGIN 'имя плагина']
[{GRANT | REVOKE} ADMIN ROLE];

<атрибут> ::= <имя атрибута> = 'строковое значение'

Если пользователя не существует, то он будет создан с использованием предложения CREATE USER. Если он уже существует, то он будет изменён, при этом существующие привилегии сохраняются.

Примечание

Если предложение USING PLUGIN не указано, то при создании пользователя он сам добавляется во все плагины из списка параметра DefaultUserManagers (в том числе его атрибуты).

При изменении пароля пользователя он сам меняется во всех плагинах из списка параметра DefaultUserManagers. Если в каком-то плагине нет пользователя, то он добавляется.

Если меняется какой-либо другой атрибут, то он также меняется и в других плагинах, но если пользователь отсутствует, то он не создаётся.

Семантика операторов и предложений в этом операторе полностью соответствует оператору ALTER USER

DROP USER

Для удаления существующей учетной записи пользователя используется следующий синтаксис:

Листинг 27.4 Синтаксис оператора DROP USER

DROP USER <логин>
[USING PLUGIN 'имя плагина'];

Необязательное предложение USING PLUGIN позволяет явно указывать какой плагин управления пользователями будет использован. По умолчанию используется тот плагин, который был указан первым в списке параметра UserManager в файле конфигурации firebird.conf. Допустимыми являются только значения, перечисленные в параметре UserManager. Следует учитывать, что одноименные пользователи, созданные с помощью разных плагинов управления пользователями — это разные пользователи.

RECREATE USER

Оператор RECREATE USER создаёт нового или пересоздаёт существующего пользователя.

Листинг 27.5 Синтаксис оператора RECREATE USER

RECREATE USER <логин> PASSWORD '<пароль>'
   [FIRSTNAME '<имя пользователя>']
   [MIDDLENAME '<отчество пользователя>']
   [LASTNAME '<фамилия пользователя>']
   [ACTIVE | INACTIVE]
   [TAGS (<атрибут>|DROP <имя атрибута> [, <атрибут>|DROP <имя атрибута>...] )]
   [USING PLUGIN 'имя плагина']
   [GRANT ADMIN ROLE];

<атрибут> ::= <имя атрибута> = 'строковое значение'

Если пользователь с таким именем уже существует, то оператор RECREATE USER удалит его и создаст нового. Существующие привилегии при этом будут сохранены.

Примечание

Если предложение USING PLUGIN не указано, то при добавлении пользователя он сам добавляется во все плагины из списка параметра DefaultUserManagers (в том числе атрибуты).

Семантика операторов и предложений в этом операторе полностью соответствует оператору CREATE USER.

27.2. Операторы управления ролями

Роль (role) — объект базы данных, представляющий набор привилегий. Множество привилегий предоставляется роли, а затем роль может быть предоставлена или отозвана у одного или нескольких пользователей.

Пользователь, которому предоставлена роль, должен указать её при входе, для того чтобы получить её привилегии, или же эта роль должна быть грантована с использованием ключевого слова DEFAULT. Любые другие привилегии, предоставленные пользователю, не будут затронуты при его входе в систему с указанной ролью. Вход в систему с несколькими ролями не поддерживается, однако вы можете права нескольких ролей назначенных по умолчанию. Вы можете изменить текущую роль с помощью оператора SET ROLE.

Роли могут быть грантованы другие роли. При входе с этой ролью пользователь автоматически получит права всех ролей выданных с использованием ключевого слова DEFAULT.

CREATE ROLE

Оператор позволяет создать новую роль. Синтаксис оператора:

Листинг 27.6 Синтаксис оператора CREATE ROLE

CREATE ROLE <имя роли>
[SET SYSTEM PRIVILEGES TO <сис.привилегия> [,<сис.привилегия> ...]];

Создать новую роль может администратор и пользователь с привилегией CREATE ROLE.

Имя роли может содержать до 63 символов и должно быть уникальным среди всех имен ролей.

Предупреждение

Желательно также чтобы имя роли было уникальным не только среди имён ролей, но и среди имён пользователей. Если вы создадите роль с тем же именем существующего пользователя, то такой пользователь не сможет подключиться к базе данных.

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

Предложение SET SYSTEM PRIVILEGES TO позволяет создать роль с системными привилегиями. Системные привилегии это части привилегий администратора. Таким образом, через делегирование роли с системными привилегиями пользователю можно передавать ему часть прав администратора БД.

Примечание

Системные привилегии позволяют производить очень тонкую настройку, поэтому иногда вам нужно будет выдать более 1 системной привилегии для выполнения какой-либо задачи. Например, необходимо выдать IGNORE_DB_TRIGGERS совместно с USE_GSTAT_UTILITY, потому что gstat должен игнорировать триггера на события БД.

Таблица 27.1 Системные привилегии
Привилегия	Описание
USER_MANAGEMENT	Управление пользователями.
READ_RAW_PAGES	Чтение страниц в сыром формате используя `Attachment::getInfo()`.
CREATE_USER_TYPES	Создание, изменение и удаление не системных записей в таблице `RDB$USER_TYPES`.
USE_NBACKUP_UTILITY	Использование `nbackup` для создания резервных копий.
CHANGE_SHUTDOWN_MODE	Закрытие базы данных (`shutdown`) и возвращение её в `online`.
TRACE_ANY_ATTACHMENT	Трассировка чужих пользовательских сессий.
MONITOR_ANY_ATTACHMENT	Мониторинг (`MON$` таблицы) чужих пользовательских сессий.
CREATE_DATABASE	Создание новой базы данных (хранится в базе данных пользователей `security.db`).
DROP_DATABASE	Удаление текущей БД.
USE_GBAK_UTILITY	Использование утилиты или сервиса `gbak`.
USE_GSTAT_UTILITY	Использование утилиты или сервиса `gstat`.
USE_GFIX_UTILITY	Использование утилиты или сервиса `gfix`.
IGNORE_DB_TRIGGERS	Разрешает игнорировать триггеры на события БД.
CHANGE_HEADER_SETTINGS	Изменение параметров на заголовочной странице БД.
SELECT_ANY_OBJECT_IN_DATABASE	Выполнение оператора `SELECT` из всех селективных объектов (таблиц, представлений, хранимых процедур выбора).
ACCESS_ANY_OBJECT_IN_DATABASE	Доступ (любым способом) к любому объекту БД.
MODIFY_ANY_OBJECT_IN_DATABASE	Изменение любого объекта БД.
CHANGE_MAPPING_RULES	Изменение правил отображения при аутентификации.
USE_GRANTED_BY_CLAUSE	Использование `GRANTED BY` в операторах `GRANT` и `REVOKE`.
GRANT_REVOKE_ON_ANY_OBJECT	Выполнение операторов `GRANT` и `REVOKE` для любого объекта БД.
GRANT_REVOKE_ANY_DDL_RIGHT	Выполнение операторов `GRANT` и `REVOKE` для выдачи DDL привилегий.
CREATE_PRIVILEGED_ROLES	Создание привилегированных ролей (с использование `SET SYSTEM PRIVILEGES`).
GET_DBCRYPT_KEY_NAME	Получение имени ключа шифрования.
MODIFY_EXT_CONN_POOL	Управление пулом внешних соединений.
REPLICATE_INTO_DATABASE	Использование API репликации для загрузки наборов изменений в базу данных.

Для проверки имеет ли текущее подключение заданную системную привилегию можно воспользоваться встроенной функцией RDB$SYSTEM_PRIVILEGE.

CREATE ROLE SYS_UTILS
SET SYSTEM PRIVILEGES TO USE_GBAK_UTILITY, USE_GSTAT_UTILITY, IGNORE_DB_TRIGGERS;

ALTER ROLE

Оператор ALTER ROLE изменяет список системных привилегий роли или удаляет их.

Листинг 27.7 Синтаксис оператора ALTER ROLE

ALTER ROLE
{
     <имя роли> SET SYSTEM PRIVILEGES TO <сис.привилегия> [,<сис.привилегия>...]
   | <имя роли> DROP SYSTEM PRIVILEGES
   | RDB$ADMIN {SET | DROP} AUTO ADMIN MAPPING
}

При использовании предложения SET SYSTEM PRIVILEGES TO роли назначаются системные привилегии из списка. Для очистки списка системных привилегий установленных предыдущим оператором используйте оператор ALTER ROLE с предложением DROP SYSTEM PRIVILEGES.

Выполнить оператор могут администраторы, владелец роли или пользователи с привилегией ALTER ANY ROLE.

ALTER ROLE RDB$ADMIN

Оператор ALTER ROLE RDB$ADMIN включает или отключает возможности администраторам Windows автоматически получать привилегии роли RDB$ADMIN при входе.

Листинг 27.8 Синтаксис оператора ALTER ROLE RDB$ADMIN

ALTER ROLE RDB$ADMIN {SET | DROP} AUTO ADMIN MAPPING

Этот оператор может быть выполнен владельцем базы данных или администратором.

Администраторы операционной системы Windows автоматически не получают права SYSDBA при подключении к базе данных. Имеют ли администраторы автоматические права SYSDBA зависит от установки значения флага AUTO ADMIN MAPPING.

Оператор ALTER ROLE разрешает или запрещает автоматическое предоставление роли RDB$ADMIN администраторам Windows в текущей базе данных, если используется доверительная авторизация (Trusted Authentication). По умолчанию автоматическое предоставление роли RDB$ADMIN отключено.

В настоящее время AUTO ADMIN MAPPING является устаревшим и поддерживается для обратной совместимости, вместо него рекомендуется использовать операторы {CREATE | ALTER | DROP} MAPPING.

DROP ROLE

Оператор DROP ROLE удаляет существующую роль.

Листинг 27.9 Синтаксис оператора DROP ROLE

DROP ROLE <имя роли>

При удалении роли все привилегии, предоставленные этой роли, отменяются.

Выполнить оператор могут администраторы, владелец роли, пользователи с привилегией DROP ANY ROLE.

27.3. Операторы отображения объектов безопасности

CREATE MAPPING

Оператор CREATE MAPPING создаёт отображение объектов безопасности (пользователей, групп, ролей) одного или нескольких плагинов аутентификации на внутренние объекты безопасности – CURRENT_USER и CURRENT_ROLE.

Листинг 27.10 Синтаксис оператора CREATE MAPPING

CREATE [GLOBAL] MAPPING <имя отображения>
USING {
   PLUGIN <имя плагина> [IN <имя базы данных>]
 | ANY PLUGIN [IN <имя базы данных> | SERVERWIDE]
 | MAPPING [IN <имя базы данных>]
 | '*' [IN <имя базы данных>] }
FROM { ANY <тип отображаемого объекта> | <тип отображаемого объекта> <имя отображаемого объекта> }
TO { USER | ROLE } [<имя объекта, на которое произведено отображение>]

Имя отображения должно быть уникальным среди имён отображений.

Если присутствует опция GLOBAL, то отображение будет применено не только для текущей базы данных, но и для всех баз данных находящимся в том же кластере, в том числе и базы данных безопасности.

Предупреждение

Одноименные глобальные и локальные отображение — разные объекты.

Примечание

Глобальное отображение работает, если в качестве базы данных безопасности используется база данных РЕД База Данных 3 или более высокой версии. Если вы планируете использовать другую базу данных, например, для целей использования собственного поставщика, то вам необходимо создать таблицу в ней и назвать её RDB$MAP с той же структурой, что и RDB$MAP в базе данных РЕД База Данных 3 и дать доступ на запись только для SYSDBA.

Предложение USING описывает источник отображения. Оно имеет весьма сложный набор опций:

явное указание имени плагина (опция PLUGIN) означает, что оно будет работать только с этим плагином;
оно может использовать любой доступный плагин (опция ANY PLUGIN), даже если источник является продуктом предыдущего отображения;
оно может быть сделано так, чтобы работать только с обще серверными плагинами (опция SERVERWIDE);
оно может быть сделано так, чтобы работать только с результатами предыдущего отображения (опция MAPPING);
вы можете опустить использование любого из методов, используя звёздочку (*) в качестве аргумента;
оно может содержать имя базы данных (опция IN), из которой происходит отображение объекта FROM.

Предложение FROM описывает отображаемый объект. Оно принимает обязательный аргумент — тип объекта. Особенности:

при отображении имён из плагинов, тип определяется плагином;
при отображении продукта предыдущего отображения, типом может быть только USER и ROLE;
если имя объекта будет указано явно, то оно будет учитываться при отображении;
при использовании ключевого слова ANY будут отображены объекты с любыми именами данного типа.

В предложении TO указывается пользователь или роль, на которого будет произведено отображение. NAME является не обязательным аргументом. Если он не указан, то в качестве имени объекта будет использовано оригинальное имя из отображаемого объекта.

Воспользоваться оператором создания отображений может SYSDBA, владелец базы данных (если отображение локальное), пользователь с ролью RDB$ADMIN, пользователь root (Linux).

Пример 1.

Включение доступа определённому пользователю из другой базы данных к текущей базе данных под другим именем.

CREATE MAPPING FROM_RT
USING PLUGIN SRP IN "rt"
FROM USER U1 TO USER U2;

Пример 2.

Включение SYSDBA сервера (от основной базы данных безопасности) для доступа к текущей базе данных.

CREATE MAPPING DEF_SYSDBA
USING PLUGIN SRP IN "security.db"
FROM USER SYSDBA TO USER;

Пример 3.

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

CREATE MAPPING LEGACY_2_GUEST
USING PLUGIN legacy_auth
FROM ANY USER TO USER GUEST;

Пример 4.

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

CREATE GLOBAL MAPPING TRUSTED_AUTH
USING PLUGIN WIN_SSPI
FROM ANY USER TO USER;

Пример 5.

Включение SYSDBA подобного доступа для администраторов Windows в текущей базе данных.

CREATE MAPPING WIN_ADMINS
USING PLUGIN WIN_SSPI
FROM Predefined_Group
DOMAIN_ANY_RID_ADMINS
TO ROLE RDB$ADMIN;

Группа DOMAIN_ANY_RID_ADMINS не существует в Windows, но такое имя будет добавлено плагином win_sspi для обеспечения точной обратной совместимости.

ALTER MAPPING

Оператор ALTER MAPPING позволяет изменять любые опции существующего отображения.

Листинг 27.11 Синтаксис оператора ALTER MAPPING

ALTER [GLOBAL] MAPPING <имя отображения>
USING {
   PLUGIN <имя плагина> [IN <имя базы данных>]
 | ANY PLUGIN [IN <имя базы данных> | SERVERWIDE]
 | MAPPING [IN <имя базы данных>]
 | '*' [IN <имя базы данных>] }
FROM { ANY <тип отображаемого объекта> | <тип отображаемого объекта> <имя отображаемого объекта> }
TO { USER | ROLE } [<имя объекта, на которое произведено отображение>]

Изменить отображение может SYSDBA, владелец базы данных (если отображение локальное), пользователь с ролью RDB$ADMIN или пользователь root (Linux).

CREATE OR ALTER MAPPING

Оператор CREATE OR ALTER MAPPING создаёт новое или изменяет существующее отображение. Если отображение не существует, то оно будет создано с использованием предложения CREATE MAPPING.

Листинг 27.12 Синтаксис оператора CREATE OR ALTER MAPPING

     CREATE OR ALTER [GLOBAL] MAPPING <имя отображения>
USING {
   PLUGIN <имя плагина> [IN <имя базы данных>]
 | ANY PLUGIN [IN <имя базы данных> | SERVERWIDE]
 | MAPPING [IN <имя базы данных>]
 | '*' [IN <имя базы данных>] }
FROM { ANY <тип отображаемого объекта> | <тип отображаемого объекта> <имя отображаемого объекта> }
TO { USER | ROLE } [<имя объекта, на которое произведено отображение>]

Семантика операторов и предложений в этом операторе полностью соответствует оператору CREATE MAPPING.

DROP MAPPING

Оператор DROP MAPPING удаляет существующее отображение. Если указана опция GLOBAL, то будет удалено глобальное отображение.

Листинг 27.13 Синтаксис оператора DROP MAPPING

DROP [GLOBAL] MAPPING <имя отображения>

Удалить отображение может SYSDBA, владелец базы данных (если отображение локальное), пользователь с ролью RDB$ADMIN, пользователь root (Linux).

27.4. Операторы управления политиками

Политики безопасности (политики учетных записей) позволяют контролировать следующие параметры безопасности системы:

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

Предупреждение

Политики безопасности работают со всеми известными методами аутентификации.

Для удобного просмотра всех созданных политик существует псевдотаблица безопасности SEC$POLICIES (см. Руководство администратора Приложение Б "Псевдотаблицы безопасности").

CREATE POLICY

Для создание политики используется оператор CREATE POLICY. Синтаксис этого оператора приведен ниже:

CREATE POLICY <имя политики> [AS <параметр>=<значение> [,<параметр>=<значение>...]]

Хотя сами политики хранятся в базе данных безопасности security5.fdb, создать их можно, соединившись с любой базой данных. Однако пользователь при этом должен иметь права на запись в базу данных безопасности security5.fdb.

Возможные параметры политик следующие:

AUTH_FACTORS — факторы аутентификации:
- SRP — пароль (верификатор) SRP
- LEGACY — пароль Legacy
- WIN_SSPI
- GSS
- CERTIFICATE — сертификат пользователя
- GOSTPASSWORD — пароль по ГОСТ
PSWD_NEED_CHAR — минимальное количество букв в пароле;
PSWD_NEED_DIGIT — минимальное количество цифр в пароле;
PSWD_NEED_DIFF_CASE — требование использования различных регистров букв в пароле;
PSWD_MIN_LEN — минимальная длина пароля;
PSWD_VALID_DAYS — срок действия пароля;
PSWD_UNIQUE_COUNT — количество последних не повторяющихся паролей;
MAX_FAILED_COUNT — количество неудачных попыток входа;
MAX_SESSIONS — максимальное число одновременных подключений одного пользователя;
MAX_IDLE_TIME — время бездействия, в секундах;
MAX_UNUSED_DAYS — максимальное время неактивности учетных записей пользователя, в днях.

Следующий пример демонстрирует создание политики:

CREATE POLICY TestPolicy AS
AUTH_FACTORS = (SRP, LEGACY),
PSWD_NEED_CHAR = 5,
PSWD_NEED_DIGIT = 3,
PSWD_MIN_LEN = 8,
PSWD_NEED_DIFF_CASE = true,
PSWD_VALID_DAYS = 15,
PSWD_UNIQUE_COUNT = 5,
MAX_FAILED_COUNT = 5,
MAX_SESSIONS = 10,
MAX_IDLE_TIME = 1800,
MAX_UNUSED_DAYS = 45;

ALTER POLICY

Оператор ALTER POLICY используется для изменения политики безопасности.

ALTER POLICY <имя политики> AS <параметр>=<значение> [,<параметр>=<значение>...]

Чтобы изменить политику безопасности пользователь должен иметь права на запись в базу данных безопасности security5.fdb и успешно соединиться с любой базой данных.

Возможные параметры политик можно посмотреть в описании оператора CREATE POLICY.

DROP POLICY

Для удаления политики безопасности администратору необходимо соединиться с какой-либо базой данных. Для удаления политики используется оператор DROP POLICY. Синтаксис этого оператора приведен ниже:

DROP POLICY <имя политики>

27.5. Операторы управления привилегиями

После создания объекта, только пользователь создавший объект (его владелец) и администраторы имеют доступ к нему. Пользователю необходимы привилегии на каждый объект, к которому он должен получить доступ. Как правило, привилегии должны быть предоставлены явно пользователю владельцем объекта или администратором базы данных. Привилегии предоставляются оператором GRANT, а отзываются с помощью оператора REVOKE.

GRANT

Оператор предоставляет одну или несколько привилегий для объектов базы данных пользователям, ролям, хранимым процедурам, функциям, пакетам, триггерам и представлениям. Синтаксис оператора:

Листинг 27.14 Синтаксис оператора GRANT

GRANT <табличные привилегии> ON [TABLE] {<имя таблицы/представления>}
   TO <список получателей привилегий> [WITH GRANT OPTION]
   [{GRANTED BY|AS} [USER] <имя грантора>]

GRANT EXECUTE ON {PROCEDURE | FUNCTION | PACKAGE} <имя процедуры/функции/пакета>
   TO <список получателей привилегий> [WITH GRANT OPTION]
   [{GRANTED BY|AS} [USER] <имя грантора>]

GRANT USAGE ON {EXCEPTION <имя искл-я>|{GENERATOR | SEQUENCE} <имя генератора>}
   TO <список получателей привилегий> [WITH GRANT OPTION]
   [{GRANTED BY|AS} [USER] <имя грантора>]

GRANT {ALL [PRIVILEGES] | {CREATE|ALTER ANY|DROP ANY} [, {CREATE|ALTER ANY| DROP ANY}...] } <объект>
   TO <список получателей привилегий> [WITH GRANT OPTION]
   [{GRANTED BY|AS} [USER] <имя грантора>]

GRANT CREATE DATABASE TO {USER <имя пользователя>|ROLE <имя роли>|GROUP <имя группы в Unix>} [,{USER <имя пользователя>|ROLE <имя роли>|GROUP <имя группы в Unix>}...]

GRANT {ALL [PRIVILEGES] | {ALTER|DROP} [,{ALTER|DROP}...]} DATABASE
   TO <список получателей привилегий> [WITH GRANT OPTION]
   [{GRANTED BY|AS} [USER] <имя грантора>]

GRANT [DEFAULT] <имя роли> [, [DEFAULT] <имя роли> ...]
   TO [USER]|[ROLE] <имя польз-я/роли> [, [USER]|[ROLE] <имя польз-я/роли>...]
   [WITH ADMIN OPTION] [{GRANTED BY | AS} [USER] <имя грантора>]

GRANT POLICY <имя_политики> TO <имя_пользователя>

<табличные привилегии> ::= ALL [PRIVILEGES] | <привилегия> [, <привилегия>...]

<привилегия> ::=   SELECT
                 | DELETE
                 | INSERT
                 | UPDATE [(<имя столбца [, <имя столбца>...]>)]
                 | REFERENCES [(<имя столбца [, <имя столбца>...]>)]

 <объект> ::=  TABLE
             | TABLESPACE
             | VIEW
             | PROCEDURE
             | FUNCTION
             | PACKAGE
             | GENERATOR
             | SEQUENCE
             | DOMAIN
             | EXCEPTION
             | ROLE
             | CHARACTER SET
             | COLLATION
             | FILTER
             | JOB

 <список получателей привилегий> ::= {<объект получатель>|<пользователь получатель>}
                                  [, {<объект получатель>|<пользователь получатель>}...]

 <объект получатель> ::=  PROCEDURE <имя процедуры>
                        | FUNCTION <имя функции>
                        | PACKAGE <имя пакета>
                        | TRIGGER <имя триггера>
                        | VIEW <имя представления>
                        | SYSTEM PRIVILEGE <системная привилегия> }

 <пользователь получатель> ::=  [USER] <имя пользователя>
                              | [ROLE] <имя роли>
                              | GROUP <имя группы в Unix>

Примечание

Все привилегии по доступу к объектам базы данных хранятся в самой базе, и не могут быть применены к любой другой базе данных.

Авторизованный пользователь не имеет никаких привилегий до тех пор, пока какие либо права не будут предоставлены ему явно. SYSDBA или владелец объекта могут выдавать привилегии другим пользователям, в том числе и привилегии на право выдачи привилегий другим пользователям.

Оператор позволяет выполнить одно из следующих действий:

предоставить одну или несколько привилегий для таблиц и представлений пользователям, ролям, представлениям, хранимым процедурам, триггерам, пакетам и функциям;
выдать права на выполнение процедуры, функции или пакета пользователям, ролям, представлениям, хранимым процедурам, триггерам, пакетам и функциям;
контролирует доступ к исключениям, последовательностям и генераторам;
предоставить одну или несколько привилегий на выполнение DDL операций над основными объектами базы данных пользователям, ролям, представлениям, хранимым процедурам, триггерам, пакетам и функциям;
назначает привилегии на создание, удаление и изменение базы данных пользователям, ролям, представлениям, хранимым процедурам, триггерам, пакетам и функциям;
назначить указанные роли группе перечисленных пользователей;
назначить политику конкретному пользователю.

Предложение TO

В предложении TO указывается список пользователей, ролей и объектов базы данных (процедур, функций, пакетов, триггеров и представлений) для которых будут выданы перечисленные привилегии. Необязательные предложения USER и ROLE позволяют уточнить, кому именно выдаётся привилегия. Если ключевое слово USER или ROLE не указано, то сервер проверяет, существует ли роль с данным именем, если таковой не существует, то привилегии назначаются пользователю. Существование пользователя, которому выдаются права, не проверяются при выполнении оператора GRANT. Если привилегия выдаётся объекту базы данных, то необходимо обязательно указывать тип объекта.

WITH GRANT OPTION

При предоставлении привилегий пользователям можно указать предложение WITH GRANT OPTION, что позволяет в свою очередь предоставлять другим пользователям эти привилегии.

Предложение GRANTED BY

С помощью предложение GRANTED BY можно предоставлять права не от имени текущего пользователя, а от другого пользователя. При использовании оператора REVOKE после GRANTED BY права будут удалены только в том случае, если они были зарегистрированы от удаляющего пользователя. Предложение AS является синонимом GRANTED BY. Предложения GRANTED BY и AS могут использовать владелец базы данных; SYSDBA; любой пользователь, имеющий права на роль RDB$ADMIN и указавший её при соединении с базой данных; при использовании флага AUTO ADMIN MAPPING — любой администратор операционной системы Windows (при условии использования сервером доверенной авторизации — trusted authentication), даже без указания роли. Даже владелец объекта не может использовать их, если он не имеет административных привилегий.

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

Привилегии для таблиц и представлений

Для таблиц и представлений возможно использовании сразу нескольких привилегий.

SELECT — разрешает выборку данных из таблицы или представления. Можно указать ограничения, чтобы можно было изменять только указанные столбцы;
DELETE — разрешает удалять записи из таблицы или представления;
INSERT — разрешает добавлять записи в таблицу или представление;
UPDATE — разрешает изменять записи в таблице или представлении. Можно указать ограничения, чтобы можно было изменять только указанные столбцы;
REFERENCES — разрешает ссылаться на указанные столбцы внешним ключом. Необходимо указать для столбцов, на которых построен первичный ключ таблицы, если на неё есть ссылка внешним ключом другой таблиц;
ALL [PRIVILEGES] — объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES.

Привилегии EXECUTE

Привилегия EXECUTE применима к хранимым процедурам, хранимым функциям, пакетам и унаследованным внешним функциям (UDF).

Для хранимых процедур привилегия EXECUTE позволяет не только выполнять хранимые процедуры, но и делать выборку данных из процедур выбора (с помощью оператора SELECT).

Привилегии USAGE

Для использования объектов метаданных, отличных от таблиц, представлений, хранимых процедур и функций, триггеров и пакетов, в пользовательских запросах необходимо предоставить пользователю привилегию USAGE для этих объектов.

Привилегия USAGE проверяется только для исключений и генераторов/последовательностей (в GEN_ID или NEXT VALUE FOR).

Привилегии на выполнение DDL операций

Выдача привилегий на создание, изменение или удаление объектов конкретного типа позволяет различным пользователям производить эти DDL операции.

CREATE — разрешает создание объекта указанного типа метаданных;
ALTER ANY — разрешает изменение любого объекта указанного типа метаданных;
DROP ANY — разрешает удаление любого объекта указанного типа метаданных;
ALL [PRIVILEGES] — объединяет привилегии CREATE, ALTER и DROP на указанный тип объекта.

DDL привилегии на базу данных

Оператор назначения привилегий на создание, удаление и изменение базы данных имеет несколько отличную форму от оператора назначения DDL привилегий на другие объекты метаданных.

CREATE — разрешает создание базы данных;
ALTER — разрешает изменение текущей базы данных;
DROP — разрешает удаление текущей базы данных;
ALL [PRIVILEGES] — объединяет привилегии ALTER и DROP на указанный тип объекта.

Привилегия CREATE DATABASE является особым видом привилегий, поскольку она сохраняется в базе данных безопасности. Список пользователей имеющих привилегию CREATE DATABASE можно посмотреть в виртуальной таблице SEC$DB_CREATORS. Привилегию на создание новой базы данных могут выдавать только администраторы в базе данных безопасности.

Привилегии ALTER DATABASE и DROP DATABASE относятся только к текущей базе данных. Привилегии на изменение и удаление текущей базы данных могут выдавать только администраторы.

Назначение ролей

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

При назначении роли пользователям можно указать предложение WITH ADMIN OPTION, которое дает право соответствующим пользователям назначать эти роли другим пользователям.

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

CREATE DATABASE 'LOCALHOST:/TMP/CUMROLES.FDB';
CREATE TABLE T(I INTEGER);
CREATE ROLE TINS;
CREATE ROLE CUMR;
GRANT INSERT ON T TO TINS;
GRANT SELECT ON T TO CUMR;
GRANT DEFAULT TINS TO USER1;
GRANT CUMR TO USER1;

CONNECT 'LOCALHOST:/TMP/CUMROLES.FDB' USER 'USER1' PASSWORD 'PAS' ROLE 'CUMR';
INSERT INTO T VALUES (1);
SELECT * FROM T;

Данный сценарий не выдаст ошибки.

Назначение политик

После создания политики безопасности (см. «Руководство администратора») ее можно назначить конкретному пользователю.

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

Политики назначаются только пользователям, но не ролям. Назначить политику несуществующему пользователю нельзя. У пользователя может быть только одна политика. Таким образом, чтобы отменить предыдущую политику и назначить новую, нужно просто еще раз выполнить оператор GRANT POLICY <новая_политика>.

Вновь созданным пользователям соответствует политика безопасности по умолчанию – DEFAULT. В ней отсутствуют какие-либо требования к паролям или сессиям пользователей. То есть для того, чтобы отменить требования политики для определенного пользователя, ему необходимо назначить политику по умолчанию:

GRANT POLICY "DEFAULT" TO <имя_пользователя>;

Выдача прав системным привилегиям

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

Описание системных привилегий можно посмотреть в разделе 27.2.

Пример.

Следующий оператор назначит все привилегии на представление PLG$SRP_VIEW, используемое в плагине управления пользователями SRP, системной привилегии USER_MANAGEMENT.

GRANT ALL ON PLG$SRP_VIEW TO SYSTEM PRIVILEGE USER_MANAGEMENT;

REVOKE

Оператор позволяет отозвать привилегии у пользователей, ролей, хранимых процедур, хранимых функций, пакетов, триггеров и представлений, которые были предоставлены оператором GRANT. Синтаксис оператора REVOKE:

Листинг 27.15 Синтаксис оператора REVOKE

REVOKE [GRANT OPTION FOR] <табличные привилегии>
   ON [TABLE] {<имя таблицы> | <имя представления>}
   FROM <список обладателей привилегий>
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE [GRANT OPTION FOR] EXECUTE ON {PROCEDURE | FUNCTION | PACKAGE} <имя процедуры/функции/пакета>
   FROM <список обладателей привилегий>
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE [GRANT OPTION FOR] USAGE ON {EXCEPTION <имя искл-я>| {GENERATOR | SEQUENCE} <имя генератора>}
   FROM <список обладателей привилегий>
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE [GRANT OPTION FOR] {ALL [PRIVILEGES] | {CREATE|ALTER ANY|DROP ANY} [, {CREATE|ALTER ANY|DROP ANY}...] } <объект>
   FROM <список обладателей привилегий>
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE CREATE DATABASE FROM <пользователь обладатель> {,<пользователь обладатель>}

REVOKE [GRANT OPTION FOR] {ALL [PRIVILEGES]|{ALTER|DROP}[,{ALTER|DROP}]} DATABASE
   FROM <список обладателей привилегий>
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE [ADMIN OPTION FOR] [DEFAULT] <имя роли> [, [DEFAULT] <имя роли> ...]
   FROM [USER]|[ROLE] <имя польз-я/роли> [, [USER]|[ROLE] <имя польз-я/роли>...]
   [{GRANTED BY|AS} [USER] <имя грантора>]

REVOKE ALL ON ALL FROM <список обладателей привилегий>

<табличные привилегии> ::= ALL [PRIVILEGES] | <привилегия> [, <привилегия>...]

<привилегия> ::=  SELECT [(<имя столбца [, <имя столбца>...]>)]
                | DELETE
                | INSERT
                | UPDATE [(<имя столбца [, <имя столбца>...]>)]
                | REFERENCES [(<имя столбца [, <имя столбца>...]>)] }

<объект> ::=  TABLE
            | TABLESPACE
            | VIEW
            | PROCEDURE
            | FUNCTION
            | PACKAGE
            | GENERATOR
            | SEQUENCE
            | DOMAIN
            | EXCEPTION
            | ROLE
            | CHARACTER SET
            | COLLATION
            | FILTER
            | JOB

<список обладателей привилегий> ::={<объект обладатель>|<пользователь обладатель>}
                                [, {<объект обладатель>|<пользователь обладатель>}...]

<объект обладатель> ::=  PROCEDURE <имя процедуры>
                       | FUNCTION <имя функции>
                       | PACKAGE <имя пакета>
                       | TRIGGER <имя триггера>
                       | VIEW <имя представления>
                       | SYSTEM PRIVILEGE <системная привилегия>

<пользователь обладатель> ::=  [USER] <имя пользователя>
                             | [ROLE] <имя роли>
                             | GROUP <имя группы в Unix>

Только пользователь, который назначил привилегию, может удалить её.

Оператор позволяет выполнить одно из следующих действий:

отнять одну или несколько привилегий для таблиц и представлений у пользователей, ролей, хранимых процедур, хранимых функций, пакетов, триггеров и представлений;
отнять права на выполнение процедуры, функции или пакета у пользователей, ролей, хранимых процедур, хранимых функций, пакетов, триггеров и представлений;
отнять привилегии на контроль доступа к исключениям, последовательностям и генераторам;
отнять одну или несколько привилегий на выполнение DDL операций над основными объектами базы данных у пользователей, ролей, хранимых процедур, хранимых функций, пакетов, триггеров и представлений;
отнять привилегии на создание, удаление и изменение базы данных у пользователей, ролей, хранимых процедур, хранимых функций, пакетов, триггеров и представлений;
отменить назначенные оператором GRANT роли;
отменить все привелегии на всех объектах у пользователей.

Предложение FROM

В предложении FROM указывается список пользователей, ролей и объектов базы данных (процедур, функций, пакетов, триггеров и представлений), у которых будут отняты перечисленные привилегии. Необязательные предложения USER и ROLE позволяют уточнить, у кого именно отбирается привилегия. Если ключевое слово USER или ROLE не указано, то сервер проверяет, существует ли роль с данным именем, если таковой не существует, то привилегии отбираются у пользователя. Существование пользователя, у которого отбираются права, не проверяются при выполнении оператора REVOKE. Если привилегия отбирается у объекта базы данных, то необходимо обязательно указывать тип объекта.

GRANT OPTION FOR

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

ADMIN OPTION FOR

Предложение ADMIN OPTION FOR отменяет ранее предоставленную опцию — право на передачу предоставленной пользователю роли другим, не отменяя прав на роль.

GRANTED BY

Используя предложение GRANTED BY можно отозвать привилегии не от имени текущего пользователя, а от другого пользователя. Данное предложение доступно не всем пользователям (см. GRANT).

ALL ON ALL

Если указано предложение ALL ON ALL, то это позволяет отменить все привилегии (в том числе и роли) на всех объектах у пользователей и/или ролей. Это позволяет быстро заблокировать пользователю доступ к базе данных.

Примечание

Когда оператор REVOKE ALL ON ALL вызывается привилегированным пользователем (владельцем базы данных, SYSDBA или любым пользователем, с ролью RDB$ADMIN), удаляются все права независимо от того, кто их предоставил. В противном случае удаляются только права, предоставленные текущим пользователем.

Подробное описание различных типов привилегий см. в разделе .