9. Администрирование функций безопасности

9.1. Основные термины и определения

Сервер баз данных (далее сервер) — установленная СУБД РЕД База Данных. Для соединения с сервером по сети по умолчанию используется порт 3050 (настраивается через параметр RemoteServicePort в конфигурационном файле РЕД Базы Данных).

Конфигурационный файл сервера — текстовый файл firebird.conf, расположенный в корневой директории каталога установки сервера. Файл содержит параметры настройки сервера.

База данных безопасности — база данных, в которой хранится информация о пользователях, зарегистрированных для конкретного сервера РЕД Базы Данных - security5.fdb (расположена в корневой директории каталога установки сервера). Для каждой базы данных база данных безопасности может переопределена в файле databases.conf (параметр SecurityDatabase). Любая база данных может быть базой данных безопасности для самой себя. В этой базе хранятся параметры пользователей системы и политики доступа (см. 19).

Пользователь — субъект доступа к базам данных сервера.

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

Идентификация — предъявление пользователем имени (логина) для входа в систему.

Аутентификация — процедура подтверждения пользователем того, что он тот, чье имя он предъявил в ходе идентификации.

Фактор аутентификации — метод аутентификации из любого плагина.

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

Администратор сервера БД — пользователь с именем SYSDBA. Создается при установке сервера. Обладает всеми правами по управлению работой сервера и полным доступом ко всем базам данных сервера. Пароль для SYSDBA по умолчанию – masterkey.

Системный администратор — пользователь, которому назначена роль RDB$ADMIN. Предназначен для распределения прав пользователей, а также для операций обслуживания баз данных (резервное копирование, восстановление и т.д.).

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

9.2. Общая модель защиты

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

Объектами защиты в РЕД Базе Данных являются:

хранящиеся в РЕД Базе Данных пользовательские данные (записи, поля);
данные системного каталога (метаданные);
операции над данными и метаданными.

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

Система защиты состоит из следующих механизмов безопасности:

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

9.3. Специальные учетные записи

SYSDBA

Изначально в системе существует только один пользователь – администратор сервера SYSDBA. Этот пользователь обладает полными правами на выполнение всех функций по управлению работой сервера и работе с базами данных.

Пользователи POSIX

В POSIX системах, включая MacOSX, имя пользователя POSIX будет интерпретировано как имя пользователя РЕД Базы Данных Embedded, если имя пользователя не указано явно.

В POSIX системах пользователь root может выступать в роли SYSDBA. РЕД База Данных Embedded в этом случае будет трактовать имя пользователя root как SYSDBA, и он будет иметь доступ ко всем базам данных сервера.

Пользователи Windows

В операционных системах семейства Windows NT вы также можете пользоваться учётными записями ОС. Для этого необходимо, чтобы в файле конфигурации firebird.conf (параметр AuthServer) в списке плагинов присутствовал провайдер Win_Sspi. Кроме того, этот плагин должен присутствовать и в списке плагинов клиентской стороны (параметр AuthClient).

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

Примечание

До версии 3 при включенной доверительной аутентификации, пользователи прошедшие проверку по умолчанию автоматически отображались в CURRENT_USER. В версии 3 и выше отображение должно быть сделано явно для систем с несколькими базами данных безопасности и включенной доверительной аутентификацией.

Владельцы базы данных

Владелец базы данных — это либо текущий пользователь (CURRENT_USER), который был в момент создания, либо пользователь который был указан в параметрах USER и PASSWORD в операторе CREATE DATABASE.

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

Администраторы

Администратор — это пользователь, которые имеет достаточные права для чтения и записи, создания, изменения и удаления любого объекта в базе данных. В таблице показано, как привилегии «Суперпользователя» включены в различных контекстах безопасности.

Таблица 9.1 Администраторы
Пользователь	Роль RDB$ADMIN	Замечание
`SYSDBA`	Автоматически	Существует автоматически на уровне сервера. Имеет полные привилегии ко всем объектам во всех базах данных. Может создавать, изменять и удалять пользователей.
Пользователь `root` или суперпользователь в POSIX	Автоматически	Также как `SYSDBA`. Только в РЕД Базе Данных Embedded.
Владелец базы данных	Автоматически	Также как `SYSDBA`, но только в этой базе данных.
Администраторы Windows	Устанавливается в `CURRENT_ROLE`, если вход успешен	Также как `SYSDBA`, если соблюдены следующие условия: В файле конфигурации `firebird.conf` (параметр `AuthServer`) в списке плагинов присутствовал провайдер `Win_Sspi`. Кроме того, этот плагин должен присутствовать и в списке плагинов клиентской стороны (параметр `AuthClient`). Во всех базах данных, где требуется полномочия суперпользователя должен быть включен `AUTO ADMIN MAPPING` или создано отображение предопределенной группы `DOMAIN_ANY_RID_ADMINS` на роль `RDB$ADMIN`. При входе не указана роль.
Обычный пользователь	Должна быть предварительно выдана и должна быть указана при входе	Также как `SYSDBA`, но только в тех базах данных, где эта роль предоставлена.
Пользователь POSIX	Должна быть предварительно выдана и должна быть указана при входе	Также как `SYSDBA`, но только в тех базах данных, где эта роль предоставлена. Только в РЕД Базе Данных Embedded.
Пользователь Windows	Должна быть предварительно выдана и должна быть указана при входе	Также как `SYSDBA`, но только в тех базах данных, где эта роль предоставлена. Доступно только если в файле конфигурации `firebird.conf` (параметр `AuthServer`) в списке плагинов присутствовал провайдер `Win_Sspi`. Кроме того, этот плагин должен присутствовать и в списке плагинов клиентской стороны (параметр `AuthClient`).

9.4. Идентификация и аутентификация

В СУБД РЕД База Данных идентификация и аутентификация основана на имени пользователя, его пароле, а также других факторах аутентификации.

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

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

Весь функционал, который относится к аутентификации, реализован в виде сторонних плагинов: Legacy_Auth, Gss, Srp, Win_Sspi, GostPassword, Certificate и VerifyServer. Они реализуют следующие методы аутентификации:

Безопасная парольная аутентификация использующая алгоритм хэширования SHA для передачи данных: Srp, Srp224, Srp256, Srp384, Srp512. По умолчанию используется Srp256;
Традиционная (Legacy_Auth) аутентификация, унаследованная от предыдущих версий;
Доверительная (Win_Sspi) аутентификация для ОС Windows;
Метод GostPassword обеспечивает аутентификацию с использованием алгоритмов шифрования из криптографического плагина (Crypto_API) [1];
Плагин Certificate позволяет аутентифицировать пользователей по сертификатам X509;
Плагин VerifyServer позволяет клиенту проверить сертификат сервера;
Доверенная аутентификация через механизм GSSAPI (Gss);
Доверенная аутентификации для выполнения Execute Statement On External без указания пароля (ExtAuth).

Плагины аутентификации состоят из трех частей и все три части должны быть настроены отдельно в firebird.conf:

Клиентская часть (параметр AuthClient) - подготавливает данные на клиенте для отправки на сервер;
Серверная часть (параметр AuthServer) - проверяет пароль на правильность;
Менеджер пользователей (параметр UserManager) - добавляет, изменяет и удаляет пользователей на сервере. Это не требуется, если используется какой-либо внешний метод аутентификации, такой как доверенная аутентификация Windows.

Параметр AuthClient настраивается на клиентской машине и содержит список методов, поддерживаемых клиентом. Параметр AuthServer настраивается на сервере и содержит список доступных методов аутентификации, разрешенных сервером. Методы перечисляются в виде строковых символов (слов), разделенных запятыми, точками с запятой или пробелами.

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

СУБД РЕД База Данных также обеспечивает возможность аутентификации пользователя на сервере с использованием протокола LDAP. При аутентификации из службы каталогов запрашивается дополнительная информация о пользователе (телефон, адрес, email и т.д.), и на основе этих данных заполняются контекстные переменные на сервере БД.

Управление пользователями

Создать пользователя можно с помощью одного из плагинов управления пользователями, указанных в параметре UserManager (файла конфигурации firebird.conf): Srp, GostPassword_Manager, Legacy_UserManager. По умолчанию используется тот плагин, который был указан первым в списке.

Информация о пользователях, зарегистрированных для конкретного сервера Ред Базы Данных, хранится в особой базе данных безопасности — security5.fdb. Для каждой базы данных база данных безопасности может быть переопределена в файле databases.conf (параметр SecurityDatabase). Любая база данных может быть базой данных безопасности для самой себя.

Примечание

Следует учитывать, что одноименные пользователи, созданные с помощью разных плагинов управления пользователями — это разные пользователи.

Это связано с тем, что методы парольной аутентификации используют разные таблицы в базе данных безопасности для хранения данных пользователей. Поэтому для системы аутентификации пользователь, созданный менеджером Legacy_UserManager, никак не связан с пользователем, созданным Srp. У них разные пароли и другая пользовательская информация. Но с точки зрения движка эти пользователи одинаковые, так как движок идентифицирует пользователей по именам.

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

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

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

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

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

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

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

Имя пользователя может состоять максимум из 63 символов. Начиная с РЕД Базы Данных 3 имена пользователей подчиняются общему правилу наименования идентификаторов объектов метаданных. Таким образом, пользователь с именем "Alex" и с именем "ALEX" будут разными пользователями.

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

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

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

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

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

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

Примечание

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

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

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 для изменения которых, необходимы административные привилегии.

Примечание

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

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

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

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

Примечание

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

Блокирование сеанса пользователя

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

Начиная с версии РЕД Базы Данных 5.0.3 оператор недоступен.

Оператор SUSPEND позволяет заблокировать сеансы пользователей и ролей:

SUSPEND { [USER <список пользователей>] | [ROLE <список ролей>] }
[DISCONNECT] | [PERMANENT];

<список пользователей> ::= "<имя пользователя 1>" [, "<имя пользователя 2>" ...]
<список ролей> ::= "<имя роли 1>" [, "<имя роли 2>" ...]

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

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

SUSPEND USER TEST_USER

Параметр конфигурации ConnectionSuspendTimeout позволяет установить для всего сервера или отдельно для базы данных количество секунд, по истечении которых сессия бездействующего пользователя будет заблокирована. Изменить значение параметра для текущего подключения можно с помощью isc_dbp_suspend_timeout. Установить таймаут больше определенного конфигурацией может только SYSDBA, владелец базы данных, пользователь с ролью RDB$ADMIN.

Для возобновления доступа необходимо использовать API интерфейса IAttachment функцию reconnect() или isc_reconnect(), передавая все необходимые для повторной авторизации данные. В случае использования доверенной аутентификации, указывать авторизационные данные не требуется.

Пример использования функции при возобновлении доступа в утилите ISQL:

RECONNECT [ [PASSWORD '<пароль>']
          | [CERTIFICATE '<алиас_сертификата>' [PIN <пароль_закрытого_ключа>] ]
        ];

Для возобновления выполнения транзакций/запросов заблокированный пользователь должен повторно ввести свои авторизационные данные. Это можно сделать с помощью оператора RECONNECT. В случае успешного ввода пароля, все незавершенные до момента блокировки транзакции будут продолженны.

Если пользовательское подключение закрыто вместо блокировки или после неё, то все незавершенные транзакции отменятся. Для возобновления работы, пользователю необходимо выполнить подключение к базе данных со всеми своими авторизационными данными. Это можно сделать с помощью оператора CONNECT.

Безопасная парольная аутентификация (SRP)

РЕД База Данных 5.0 поддерживает метод аутентификации пользователей, реализованный в качестве плагина по умолчанию - Secure Remote Password (SRP) Protocol.

В результате работы данного протокола обе стороны получают длинный секретный ключ, проверяемый на соответствие между сторонами после получения. В случаях, когда помимо аутентификации необходимо шифрование данных, SRP предоставляет более надёжные, чем SSH, и более быстрые, чем протокол Диффи-Хеллмана, средства для достижения этой цели. Он также не зависит от третьих лиц, в отличие от Kerberos.

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

Кроме того, SRP устойчив к атаке посредника (man-in-the-middle).

Для того, чтобы пользователь РЕД Базы Данных смог пройти парольную аутентификацию, он должен быть предварительно создан с помощью плагина управления пользователями Srp:

CREATE USER test PASSWORD 'pass'
USING PLUGIN Srp;

Для этого в файле конфигурации firebird.conf параметр UserManager должен содержать значение Srp в списке:

UserManager = Srp, Legacy_UserManager

Данные о пользователях, созданных с помощью Srp плагина, хранятся в базе данных безопасности (security5.fdb) в таблице PLG$SRP (см. %s).

Менеджер пользователей Srp хэширует пароль алгоритмом SHA-1, при этом эффективная длина пароля ограничена 20 байтами. На длину пароля нет ограничения в 20 байт и он может быть использован. хэши различных паролей, длина которых более 20 байт, тоже различны. Предел эффективности наступает из-за ограниченной длины хэша в SHA1 равном 20 байт или 160 бит. Рано или поздно найдётся более короткий пароль с тем же хэшем с помощью атаки Brute Force. Именно поэтому часто говорят, что эффективная длина пароля для алгоритма SHA1 составляет 20 байт.

Для работы данного метода необходимо, чтобы в файле конфигурации firebird.conf параметр AuthServer в списке значений содержал метод аутентификации Srp. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient.

AuthServer = Srp
AuthClient = Srp

Для аутентификации в режиме Srp необходимо предъявить имя пользователя и пароль:

isql localhost:d:\test.fdb –user test –password pass

Традиционная (Legacy_Auth) аутентификация

Традиционная аутентификация подразумевает использование пароля в качестве единственного фактора аутентификации. Пароль может передаваться серверу в виде хэша или в открытом виде. Шифрование пароля происходит по алгоритму LEGACY.

Если вы собираетесь использовать данный метод аутентификации, в файле конфигурации firebird.conf выставите значения следующих параметров:

UserManager = Legacy_UserManager
WireCrypt = Enabled
AuthServer = Legacy_Auth, Srp, Win_Sspi
AuthClient = Legacy_Auth, Srp, Win_Sspi

Плагин, отвечающий за Legacy_Auth аутентификацию, не предоставляет ключа шифрования трафика. Поэтому следует отключить обязательное (Required) шифрование сессий через параметр WireCrypt в конфигурации сервера, т.е. выставить значение Enabled или Disabled.

Для аутентификации в традиционном режиме необходимо предъявить имя пользователя и пароль, например:

isql localhost:d:\test.fdb –user testuser –password testpass

В этом методе аутентификации учитывается только первые 8 символов любого пароля.

Для того, чтобы пользователь РЕД Базы Данных смог пройти традиционную аутентификацию, он должен быть предварительно создан с помощью плагина управления пользователями Legacy_UserManager:

CREATE USER test PASSWORD 'test'
USING PLUGIN Legacy_UserManager;

Данные о пользователях, созданных в традиционном режиме, хранятся в базе данных безопасности (security5.fdb) в таблице PLG$USERS (см. %s).

Доверительная (Win_Sspi) аутентификация

В доверительном режиме аутентификации используется система безопасности операционной системы. В операционных системах семейства Windows NT можно пользоваться учётными записями ОС. Для этого необходимо, чтобы в файле конфигурации firebird.conf параметр AuthServer в списке значений содержал метод аутентификации Win_Sspi. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient. Также для использования доверительной аутентификации следует отключить обязательное (Required) шифрование соединений (параметр WireCrypt), поскольку плагин, реализующий Win_Sspi, не предоставляет ключ шифрования. Для этого достаточно выставить значение Enabled или Disabled.

AuthServer = Win_Sspi, Srp
AuthClient = Win_Sspi, Srp
WireCrypt = Enabled

До РЕД Базы Данных 3 при включенной доверительной аутентификации, пользователи прошедшие проверку по умолчанию автоматически отображались в CURRENT_USER. В версии 5.0 отображение должно быть сделано явно для систем с несколькими базами данных безопасности и включенной доверительной аутентификацией.

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

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

В этом режиме при подключении к серверу РЕД Базы Данных не требуется предъявлять имя пользователя и пароль. Если пользователь локального компьютера подключается к серверу, работающему на том же компьютере, то он получает роль PUBLIC.

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

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

select CURRENT_USER from rdb$database;
--------------------------------------
domain\administrator

То есть подключился пользователь с именем administrator, который является членом домена domain.

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

Администраторы операционной системы Windows автоматически не получают права SYSDBA при подключении к базе данных. Имеют ли администраторы автоматические права SYSDBA зависит от установки значения флага AUTO ADMIN MAPPING. После успешного "auto admin" подключения текущей ролью будет являться RDB$ADMIN.

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

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

Оператор ALTER ROLE является упрощённым видом оператора создания отображения предопределённой группы DOMAIN_ANY_RID_ADMINS на роль RDB$ADMIN.

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

В обычных базах данных статус AUTO ADMIN MAPPING проверяется только во время подключения. Если Администратор имеет роль RDB$ADMIN потому, что произошло автоматическое отображение во время входа, то он будет удерживать эту роль на протяжении всей сессии, даже если он или кто-то другой в это же время выключает автоматическое отображение. Точно также, включение AUTO ADMIN MAPPING не изменит текущую роль в RDB$ADMIN для администраторов, которые уже подключились.

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

Рекомендуется явно указывать на то, что ожидается доверительная аутентификация, используя для этого ключ – tr. Например, если в системе установлены соответствующие значения переменных окружения ISC_USER и ISC_PASSWORD, и не будет указан ключ – tr при аутентификации, то вместо контекста безопасности пользователя на сервер будут переданы имя пользователя и пароль, соответствующие переменным окружения, как при традиционной аутентификации, что приведет к ошибке, так как на сервере ожидается доверительная аутентификация.

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

При доверительной аутентификации возможен следующий вариант соединение с БД:

isql localhost:d:\test.fdb

GostPassword метод аутентификации

Метод GostPassword обеспечивает аутентификацию с использованием алгоритмов шифрования из криптографического плагина. При аутентификации все данные пользователя, кроме имени, передаются только в зашифрованном виде. Для работы данного метода необходимо наличие криптопровайдера и криптоплагина. Криптоплагин входит в поставку СУБД и называется Crypto_API.

Для использования этого режима аутентификации следует в файле конфигурации firebird.conf добавить в список значений параметра AuthServer метод аутентификации GostPassword. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient. Также в конфигурационном файле сервера и клиента необходимо указать используемый криптоплагин CryptoPlugin = Crypto_API (по умолчанию).

AuthServer = GostPassword, Srp
AuthClient = GostPassword, Srp
UserManager = GostPassword_Manager
CryptoPlugin = Crypto_API

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

CREATE USER test PASSWORD 'pass'
USING PLUGIN GostPassword_Manager;

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

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

Данные о пользователях, созданных этим плагином, хранятся в базе данных безопасности (security5.fdb) в таблице PLG$MF (см. %s). Там хранится не только хэш пароля, но и название алгоритма, с помощью которого этот хэш получен.

Для GostPassword-аутентификации необходимо предъявить имя пользователя и пароль, например:

isql localhost:d:\test.fdb –user test –password pass;

Аутентификация по сертификату (Certificate)

РЕД База Данных 5.0 поддерживает метод аутентификации по сертификату с использованием алгоритмов шифрования из криптографического плагина. Для работы данного метода необходимо наличие криптопровайдера и криптоплагина. Криптоплагин входит в поставку СУБД и называется Crypto_API.

Для того, чтобы пользователь РЕД Базы Данных смог пройти аутентификацию по сертификату, в файле конфигурации firebird.conf параметр AuthServer должен содержать значение Certificate в списке. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient. Также в конфигурационном файле сервера и клиента необходимо указать используемый криптоплагин CryptoPlugin = Crypto_API (по умолчанию).

AuthServer = Certificate, Srp
AuthClient = Certificate, Srp
WireCrypt = Disabled
CryptoPlugin = Crypto_API

Следует отключить обязательное (Required) шифрование соединений, поскольку плагин, реализующий Certificate, не предоставляет ключ шифрования. Для этого достаточно выставить значение параметра WireCrypt равным Enabled или Disabled.

Данные о таком пользователе не хранятся в базе данных безопасности (security5.fdb).

При подключении необходимо предъявить алиас сертификата и пароль закрытого ключа - PIN (если установлен). Контейнер с набором ключей и сертификат создаются заранее. Например:

isql localhost:d:\test.fdb –certificate "TESTUSER,Федеральная служба судебных приставов,120025bec5106c2a6b1143bac900000025bec5" -pin 123456

Алиас сертификата представляет собой строку следующего вида:

<алиас сертификата> ::= "SubjectCN,IssuerCN,SerialNumber"

где SubjectCN – имя владельца сертификата, IssuerCN – название издателя сертификата, SerialNumber – серийный номер сертификата в шестнадцатеричном виде.

Таблица 9.2 Параметры конфигурационного файла, имеющие отношение к аутентификации по сертификату
Параметр	Возможное значение	Комментарий
AuthServer, AuthClient	Srp, Win_Sspi, Legacy_Auth, Gss, GostPassword, Certificate	Параметр `AuthServer` - набор методов аутентификации, разрешенных на сервере. Параметр `AuthClient` - набор методов аутентификации, поддерживаемых клиентом.
CryptoPlugin	Crypto_API	Имя библиотеки криптопровайдера (расположена в каталоге `plugins` сервера)
ServerCertificate	<алиас сертификата>	Задаёт алиас сертификата, которым сервер будет удостоверять свою подлинность клиенту.
CertUsernameDN	<атрибут>	Атрибут сертификата, из которого будет извлекаться имя его владельца. По умолчанию `CN`.
CertUsernamePattern	<регулярное выражение>	Регулярное выражение, применяемое к атрибуту сертификата с именем пользователя для извлечения самого этого имени. Использует синтаксис SQL, по умолчанию не задано.
VerifyCertificateChain	0 \| 1	Задаёт / отключает проверку цепочки сертификации пользовательского сертификата.
TrustedCertificate	<алиас сертификата>	Задаёт алиас сертификата, которому сервер будет доверять. Если пользователь предъявляет этот сертификат, он будет аутентифицирован с указанным именем без пароля и без проверки его сертификата.

Проверка сертификата сервера (VerifyServer)

РЕД База Данных 5.0 поддерживает плагин проверки сертификата сервера с использованием алгоритмов шифрования из криптографического плагина. Для работы данного плагина необходимо наличие криптопровайдера и криптоплагина. Криптоплагин входит в поставку СУБД и называется Crypto_API.

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

Для того, чтобы пользователь РЕД Базы Данных смог проверить сертификат сервера, в файле конфигурации firebird.conf должны быть указаны параметры ServerCertificate и ServerPrivatePin, а параметр AuthServer должен содержать значение VerifyServer в списке. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient. Также в конфигурационном файле сервера и клиента необходимо указать используемый криптоплагин CryptoPlugin = Crypto_API (по умолчанию).

AuthServer = Srp, VerifyServer
AuthClient = Srp, VerifyServer
WireCrypt = Disabled
CryptoPlugin = Crypto_API

Данные плагина не хранятся в базе данных безопасности (security5.fdb).

При подключении необходимо указывать параметр для проверки сертификата сервера. Например:

isql localhost:d:\test.fdb –verify <алиас сертификата>

Аутентификация доверенным пользователем

В firebird.conf добавлен параметр конфигурации TrustedUser для аутентификации по паролю с именем другого пользователя. По умолчанию пустой.

При соединении с базой данных кроме имени пользователя (isc_dpb_user_name) можно указать эффективный логин (isc_dpb_effective_login). В isql для этого добавлен ключ -l.

Если задан эффективный логин, то после успешной аутентификации любого плагина проверяется задан ли параметр TrustedUser:

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

Для ядра СУБД это подключение будет выглядеть как обычное, информация о подмене логина до него не доходит.

Примечание

Работает для всех плагинов аутентификации.

Доверенная аутентификация через механизм GSSAPI (Gss)

Примечание

Доверенная аутентификация через механизм GSSAPI доступна только в промышленной редакции СУБД РЕД База Данных. Подробнее различия функционала редакций описаны в разделе Редакции СУБД РЕД База Данных 5.0.

РЕД База Данных 5.0 поддерживает Kerberos аутентификацию через GSSAPI (Generic Security Services Application Programming Interface). GSSAPI - это абстрактный уровень над Kerberos 5, предназначенный для решения проблемы несовместимости схожих сервисов безопасности. GSSAPI обеспечивает автоматическую аутентификацию (single sign-on), для систем, которые её поддерживают.

Принцип работы:

Для аутентификации клиента используется контекст безопасности, полученный при входе в систему или из других источников типа kinit.
Из контекста безопасности клиент извлекает токен, который отправляется на сервер СУБД.
Сервер СУБД проверяет токен через GSSAPI (по умолчанию для проверки используется механизм Kerberos).
Если токен проходит проверку, сервер извлекает из него имя пользователя, которое будет использовано для подключения к базе.

К достоинствам данной аутентификации можно отнести преимущества технологии единого входа (SSO):

ввод пользователем своих учётных данных только один раз;
отсутствие ввода пароля;
безопасность;
централизованное хранение учётных данных пользователей.

При работе с Kerberos GSSAPI использует стандартные учётные записи в формате servicename/hostname@realm.

Имя пользователя при такой аутентификации формируется из имени учетной записи в базе данных KDC.

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

Такой вид аутентификации работает только при передаче данных через сетевой протокол.

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

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

Для работы данного метода аутентификации необходимо, чтобы в файле конфигурации firebird.conf параметр AuthServer в списке значений содержал метод аутентификации Gss. Кроме того, этот метод должен присутствовать и в списке методов клиентской стороны - в параметре AuthClient. Так как плагин, отвечающий за GSSAPI аутентификацию, не предоставляет ключа шифрования трафика, следует отключить обязательное (Required) шифрование сессий через параметр WireCrypt в конфигурации сервера, т.е. выставить значение Enabled или Disabled.

Если вы собираетесь использовать данный метод аутентификации, в файле конфигурации firebird.conf выставите значения следующих параметров:

AuthServer = Gss, Srp
AuthClient = Gss, Srp
WireCrypt = Disabled
GssServerKeyfile =
GssServiceName =
GssHostName =
GSSLibrary =

где

GssServerKeyfile - путь до файла, содержащий долговременный ключ сервиса, который будет использовать СУБД для аутентификации в Kerberos. Этот ключевой файл создаётся в центре распределения ключей (KDC), например командой утилитой в Active Directory;
GssServiceName - имя сервиса (по умолчанию «rdb_server»), созданное на сервере Kerberos для аутентификации СУБД;
GssHostName - DNS-адрес сервера СУБД (например «rdb.example.com»);
GSSLibrary - динамическая библиотека GSSAPI (libgssapi_krb5.so). Поддерживается также библиотека libvas-gssapi.so от One Identity Authentication Services. При её использовании СУБД после аутентификации определяет группы, назначенные пользователю в домене, и назначает ему одноимённые роли, существующие в базе данных.

В РЕД Базе Данных 3 при включенной доверенной аутентификации пользователи, прошедшие проверку, по умолчанию автоматически отображались в CURRENT_USER. В РЕД Базе Данных 5 отображение должно быть создано явно для систем с несколькими базами данных безопасности и включенной доверенной аутентификацией.

Отображение для использования доверительной аутентификации во всех базах данных, которые используют текущую базу данных безопасности:

CREATE GLOBAL MAPPING GSS_AUTH
USING PLUGIN GSS
FROM ANY USER
TO USER;

В этом режиме при подключении к серверу РЕД Базы Данных не требуется предъявлять имя пользователя и пароль. Если пользователь локального компьютера подключается к серверу, работающему на том же компьютере, то он получает роль PUBLIC.

При доверенной аутентификации возможен следующий вариант соединение с БД:

isql localhost:d:\test.fdb

Доверенная аутентификации для выполнения Execute Statement On External без указания логина и пароля (ExtAuth)

Примечание

Доверенная аутентификации для выполнения Execute Statement On External без указания логина и пароля доступна только в промышленной редакции СУБД РЕД База Данных. Подробнее различия функционала редакций описаны в разделе Редакции СУБД РЕД База Данных 5.0.

Для выполнения оператора EXECUTE STATEMENT ON EXTERNAL, если внешний источник данных находится на другом сервере, предложения AS USER <имя пользователя> и PASSWORD <пароль> являются обязательными.

EXECUTE STATEMENT 'SELECT * FROM RDB$DATABASE'
ON EXTERNAL 'server:db1' AS USER 'MYUSER' PASSWORD 'mypassword'

Значения имени пользователя и пароля передаются в открытой форме, что небезопасно. Например, если ESOE (сокр. от EXECUTE STATEMENT ON EXTERNAL) вызывается из кода хранимой процедуры, подключенные пользователи могут видеть пароль.

Для безопасного подключения в РЕД Базе Данных был разработан плагин аутентификации ExtAuth специально для ESOE, который устанавливает доверительную связь между серверами РЕД Базы Данных и выполняет аутентификацию ESOE без логина и пароля:

EXECUTE STATEMENT 'SELECT * FROM RDB$DATABASE'
ON EXTERNAL 'server:db1';

Для использования данной возможности следует в файле конфигурации firebird.conf добавить в список значений параметров AuthServer и AuthClient метод аутентификации ExtAuth на всех серверах, которые будут "доверять" друг другу.

AuthServer = Srp, ExtAuth
AuthClient = Srp, ExtAuth

Затем необходимо сгенерировать ключевой файл для плагина. Этот ключ должен быть размещен на всех серверах РЕД Базы Данных, которые должны доверять друг другу.

Чтобы сгенерировать ключевой файл ExtAuth.conf, запустите исполняемый файл extauth_keygen. Ключевой файл содержит три параметра:

Key - сам ключ;
IgnoreLogin - игнорировать явное указание логина в операторе ESOE (по умолчанию логин не игнорируется). Если значение параметра No и указан логин, то плагин ExtAuth перестает действовать.
IgnorePassword - игнорировать явное указание пароля в операторе ESOE (по умолчанию пароль не игнорируется). Если значение параметра No и указан пароль, то плагин ExtAuth перестает действовать.

_images/extauthkey.png — Рис. 9.1 Содержимое файла `ExtAuth.conf`

Потом скопируйте файл ключа на все доверенные сервера РЕД Базы Данных в папку plugins. Ключ, созданный на Windows, можно использовать в Linux, и наоборот.

Примечание

Другое имя ключевого файла и его расположение не допускается.

Чтобы использовать плагин аутентификации внутри конкретной базы данных, необходимо создать отображение между пользователями плагина ExtAuth и обычными пользователями РЕД Базы Данных.

Например, чтобы запустить ESOE от имени пользователя MYUSER:

EXECUTE STATEMENT 'SELECT * FROM RDB$DATABASE'
ON EXTERNAL 'server:db1';

Нужно сопоставить пользователя MYUSER с фактическим пользователем в целевой базе данных db1. Давайте предположим, что есть пользователь MYUSER2 в целевой базе данных, в этом случае нужно создать следующее отображение в целевой базе данных db1:

CREATE MAPPING cluster_auth USING PLUGIN extauth
FROM USER MYUSER TO user MYUSER2;

Оба пользователя должны существовать.

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

Аутентификация по протоколу LDAP

Примечание

Аутентификация по протоколу LDAP доступна в стандартной редакции СУБД РЕД База Данных. Подробнее различия функционала редакций описаны в разделе Редакции СУБД РЕД База Данных 5.0.

РЕД База Данных поддерживает возможность аутентификации пользователей сервера баз данных с использованием службы каталогов через протокол LDAP. Как известно, учётные данные пользователей хранятся в БД безопасности – security5.fdb. Также существует возможность добавить дополнительный источник учётной информации – службу каталогов на основе сервера OpenLDAP и Active Directory. При этом LDAP используется именно как дополнение к традиционной схеме безопасности сервера. При проверке пользовательских учётных данных, если заданы параметры подключения к LDAP, сервер для всех пользователей, кроме SYSDBA, сначала пытается проверить наличие учетной записи пользователя в каталоге LDAP и если он там не найден, то выполняется также поиск в БД безопасности security5.fdb. Для SYSDBA поиск выполняется только в БД безопасности.

Если пользователь не найден в LDAP-сервере(не задан адрес LDAP-сервера) и проверка в базе данных безопасности прошла неуспешно, выдается сообщение об ошибке аутентификации.

С точки зрения конечного пользователя всё это работает совершенно прозрачно и ему не нужно выполнять никаких дополнительных действий.

Параметры конфигурации LDAP

Для аутентификации по протоколу LDAP в firebird.conf должны быть заданы настройки подключения к серверу каталогов.

Таблица 9.3 Параметры конфигурационного файла, имеющие отношение к LDAP
Параметр	Возможное значение	Комментарий
LDAPServer		Адрес сервера `LDAP` (IP-адрес или символьное имя)
LDAPEncryption	None\|SSL\|TLS	Тип шифрования, используемый при подключении к `LDAP`. Он может принимать три значения: `None` – шифрование отсутствует, подключение к серверу по порту 389 (по умолчанию); `SSL` – подключение по протоколу `LDAPS` по порту 636; `TLS` – подключение с командой `START_TLS` к порту 389. Сервер `LDAP`, к которому выполняется подключение, должен быть настроен соответствующим образом. Сертификат сервера `LDAP` будет проверяться, если параметр `VerifyLdapServer` не отключен.
VerifyLdapServer	true\|false	Если параметр включен, то при `SSL/TLS`-соединениях будет выполняться проверка сертификата `LDAP`-сервера со стороны сервера РЕД Базы Данных. Если сертификат не проходит проверку, соединение разрывается. Верификация сертификата выполняется аналогично проверке пользовательского сертификата. Если параметр отключен, проверка сертификата `LDAP`-сервера не выполняется.
LDAPUserDN	uid=rdb, ou=people, dc=example, dc=com	`DN` пользователя, от имени которого сервер будет подключаться к `LDAP` для аутентификации других пользователей. Этот пользователь должен иметь права на чтение атрибутов `LDAP`, используемых сервером РЕД Базы Данных. Если параметр не задан, сервер будет делать `bind` к `LDAP` с именем и паролем пользователя, указанным клиентом, чтобы пройти аутентификацию.
LDAPPassword		Пароль пользователя, определенного в атрибуте `LDAPUserDN`, от имени которого сервер будет подключаться к `LDAP` для аутентификации других пользователей.
LDAPUserBase	ou=people, dc=example, dc=com	Ветка в `LDAP` каталоге в виде `DN`, которая будет использована как стартовая для поиска пользователей. При аутентификации имена пользователей будут искаться в этой ветке и рекурсивно во всех ветках, находящихся в ней до первого совпадения.
LDAPUserPrefix	uid	Название атрибута, в котором хранится имя пользователя в его `DN` в `LDAP`. Для OpenLDAP обычно `uid`, для AD - `cn`. В основном используется, когда не задан `LDAPUserDN`. Если параметр `LDAPUserPrefix` не задан, клиентская библиотека `fbclient` будет шифровать пароль пользователя и для аутентификации будут использоваться пароли из атрибутов: `rdbPassword; rdbSrpVerifier; rdbSrpSalt; rdbSecurePassword; rdbPasswordAlgorithm`. Если параметр `LDAPUserPrefix` задан, то пароль не шифруется и отправляется на сервер открытым, сервер "биндится" к `LDAP` с этим именем пользователя и этим паролем.
LDAPUserFilter	uid=%u	Фильтр для поиска учетных записей пользователей. В значении этого параметра используется шаблон `%u`, который при поиске будет заменен на имя пользователя, предъявленное при аутентификации. По умолчанию параметр имеет значение `uid=%u`, что типично для схем каталога на базе OpenLDAP. В схеме, поддерживаемой Active Directory, обычно используется фильтр `-(objectClass=user)(cn=%u)`.
LDAPGroupBase	ou=group, dc=example, dc=com	Ветка в `LDAP`, которая будет использована как стартовая для поиска групп пользователей. Поиск групп будет выполняться рекурсивно. Группы пользователя будут преобразованы в его роли на сервере. Указывается в виде `DN`.
LDAPMembershipFilter	member=%d	Фильтр, который будет использован при поиске в `LDAP` групп, к которым принадлежит пользователь. Существует три основные схемы, используемые в `LDAP` для указания членства в группах. В соответствии с используемой схемой нужно формировать фильтр. В нём в качестве имени предполагаемого пользователя указывается шаблон `%u`, а в качестве `DN` пользователя указывается `%d`. Если указано пустое значение, принадлежность пользователя к группам не определяется.
LDAPUserCertificate		Атрибут `LDAP`, в котором будет храниться сертификат пользователя. Если данный параметр задан, то сертификат, предъявленный пользователем, должен соответствовать его сертификату в `LDAP` (если настроены параметры подключения к `LDAP`-серверу). Если этот параметр не задан, сертификат пользователя не будет проверяться на соответствие его сертификату из `LDAP`. Сертификат должен храниться в двоичном формате (DER) в атрибуте `«userCertificate»`.
LDAPPasswordSync	rdbSrpVerifier; userPassword	Данный параметр задаёт синхронизацию пароля пользователя в БД безопасности и в `LDAP`. Здесь перечисляются атрибуты, которые должны меняться в `LDAP` при смене пароля пользователя в БД безопасности. Допускается указание через «;» следующих атрибутов: `rdbPassword` — традиционный пароль пользователя в СУБД РЕД База Данных; `rdbSrpVerifier` — пароль (верификатор) SRP; `rdbSecurePassword` — пароль по ГОСТ; `userPassword` — пароль пользователя, используемый обычно в UNIX-системах; `sambaLMPassword` — пароль пользователя, используемый SAMBA-протоколом; `sambaNTPassword` — пароль пользователя, используемый SAMBA-протоколом. По умолчанию выполняется синхронизация всех паролей.
LDAPReadOnly	0\|1	Заданный параметр может перевести LDAP-сервер в режим только для чтения (значение 1). Тогда параметр `LDAPPasswordSync` будет игнорироваться. По умолчанию используется значение 0.

Процесс аутентификации при передаче пароля в открытом виде

Пользователь при подключении к БД передаёт пароль в открытом виде в тэге isc_dpb_password. В файле конфигурации задан параметр LDAPServer.

Cервер для всех пользователей, кроме SYSDBA, сначала пытается проверить наличие учетной записи пользователя в каталоге LDAP. Пользователь будет аутентифицироваться в LDAP по его реальному логину методом bind одним из следующих способов:

Если задан параметр LDAPUserDN, то сначала сервер подключается к LDAP от этого общего пользователя. Затем он ищет DN реального пользователя и отключается от LDAP. Далее сервер делает bind с полным именем (DN) и паролем реального пользователя. Это позволяет распределять учетные записи пользователей по разным веткам LDAP.
Если LDAPUserDN не задан, то сервер сразу делает bind с именем и паролем реального пользователя.
Если задан параметр LDAPUserBase, то DN пользователя формируется, как LDAPUserPrefix + <имя пользователя> + LDAPUserBase. В этом случае пользователи должны находиться в одной ветке LDAP, указанной в LDAPUserBase;
Если параметр LDAPUserBase не задан, то сервер сначала попытается сделать bind с именем пользователя в том виде, в котором его передал клиент.
Если аутентифицироваться не получилось и задан параметр LDAPDomain, то будет выполнена попытка сделать bind используя UPN (UserPrincipalName) в виде <имя пользователя>@<значение LDAPDomain>. Такой способ работает для входа в ActiveDirectory.

Пример настройки для ActiveDirectory:

#Адрес сервера LDAP
LDAPServer=10.81.1.1

#Шифрование по SSL
LDAPEncryption=SSL

#Атрибут LDAP, по которому будет выполняться поиск пользователя, имя которого передает клиент
LDAPUserPrefix=sAMAccountName

#Фильтр для поиска пользователя в каталоге LDAP
LDAPUserFilter=&(objectClass=user)(sAMAccountName=%u)

#Стартовая ветка для поиска групп пользователя (поиск выполняется рекурсивно по всем вложенным веткам)
LDAPGroupBase=ou=groups,dc=example,dc=com

#Фильтр для поиска групп пользователя
LDAPMembershipFilter=member=%d

#Имя домена
LDAPDomain = example.com

#Отключение проверки сертификата сервера LDAP
VerifyLdapServer=0

Если пользователь не найден в LDAP, сервер пытается проверить пользователя через security5.fdb. Если он там найден, аутентификация выполняется по считанным из неё данным. Если не найден или найден, но его пароль не совпадает, то сообщается об ошибке аутентификации.

Примечание

Если в firebird.conf заданы параметры LDAPServer и LDAPUserPrefix, клиентская библиотека fbclient шифровать пароль не будет.

Для SYSDBA поиск выполняется только в БД безопасности.

Процесс аутентификации при передаче пароля в зашифрованном виде

Пользователь при подключении к БД передаёт пароль в зашифрованном виде в тэге isc_dpb_password_enc. В файле конфигурации задан параметр LDAPServer.

Cервер для всех пользователей, кроме SYSDBA, сначала пытается проверить наличие учетной записи пользователя в каталоге LDAP. Сначала выполняется подключение к LDAP-серверу от имени общего пользователя LDAPUserDN (указывается обязательно). Затем на сервере происходит поиск нужного пользователя относительно указанной ветви LDAPUserBase. Если пользователь найден, то сверяются хэш его пароля в LDAP с хэшем предоставленного им пароля.

Пароль пользователя для Legasy/Srp/GostPassword-аутентификации хранится в LDAP в атрибуте rdbPassword/rdbSrpVerifier/rdbSecurePassword в том же виде, в котором он сохраняется в security5.fdb.

Если пользователь не найден в LDAP, сервер пытается проверить пользователя через security5.fdb. Если он там найден, аутентификация выполняется по считанным из неё данным.

Если пользователь не найден в LDAP и не найден в security5.fdb, проверка пароля считается неуспешной.

Процесс аутентификации по сертификату

При аутентификации по сертификату сначала проверяется является ли пользовательский сертификат доверенным. Для этого он сравнивается с сертификатом, заданным в параметре конфигурации TrustedCertificate. Если сертификат не доверенный, то он верифицируется и после этого проверяется, задан ли параметр конфигурации LDAPUserCertificate. Если он не задан, проверка сертификата считается успешной. Если параметр задан, то выполняется подключение к LDAP-серверу и скачивание оттуда сертификата пользователя. Затем полученный сертификат сравнивается с сертификатом, предоставленным пользователем. Если они одинаковы, проверка сертификата считается успешной. Если не удалось подключиться к LDAP, получить оттуда сертификат пользователя или сертификаты не совпадают, проверка сертификата считается неуспешной.

Если проверка сертификата через LDAP прошла успешно, имя пользователя, извлечённое из сертификата, может отличаться от имён пользователей, которые заданы другими факторами аутентификации.

Имя пользователя из сертификата (из секции Subject) извлекается с помощью двух параметров конфигурации.

CertUsernameDN – содержит DN атрибута пользователя внутри сертификата. По умолчанию используется атрибут CN.
CertUsernamePattern – задаёт регулярное выражение в синтаксисе SQL, которое извлекает подстроку из содержимого найденного атрибута. По умолчанию используется пустой шаблон, что означает использование содержимого атрибута целиком.

Если указанный атрибут не найден в сертификате или результатом применения к нему регулярного выражения оказалась пустая строка, возвращается ошибка.

Верификация сертификата пользователя выполняется в два этапа. На первом этапе проверяется наличие у пользователя доступа к закрытому ключу, соответствующему предъявленному сертификату. Это выполняется генерацией сессионного ключа по алгоритму Диффи-Хеллмана, в которой участвуют пары открытых и закрытых ключей клиента и сервера. На втором этапе выполняется проверка самого сертификата и его цепочки сертификации. Верификация может быть отключена параметром конфигурации VerifyLdapServer. Верификация считается неуспешной в следующих случаях:

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

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

Информация о пользователях, получаемая из LDAP

После аутентификации через LDAP можно запросить информацию о пользователе с помощью функций LDAP_ATTR:

LDAP_ATTR(<имя атрибута> [, <имя пользователя> ])

Важно учитывать, что получить атрибуты пользователя, указанного в необязательном аргументе функции LDAP_ATTR, может только SYSDBA, владелец базы данных, пользователь с ролью RDB$ADMIN или пользователь, принадлежащий группе LDAP_ADMIN каталога LDAP.

Можно узнать где пользователь прошел проверку подлинности - через базу данных безопасности или в LDAP:

select RDB$GET_CONTEXT('AUTHDATA', 'AUTH_TYPE') from rdb$database;

и с помощью какого плагина аутентификации:

select RDB$GET_CONTEXT('AUTHDATA', 'AUTH_PLUGIN') from rdb$database;

Также можно узнать ФИО пользователя. При аутентификации через LDAP эта информация считывается из атрибута пользователя "CN":

select RDB$GET_CONTEXT('AUTHDATA', 'USER_FIRST_NAME') from rdb$database;
select RDB$GET_CONTEXT('AUTHDATA', 'USER_MIDDLE_NAME') from rdb$database;
select RDB$GET_CONTEXT('AUTHDATA', 'USER_LAST_NAME') from rdb$database;

Если заданы параметры LDAPGroupBase и LDAPMembershipFilter, то осуществляется поиск групп, к которым принадлежит пользователь в LDAP. После этого ему назначаются роли, соответствующие найденным группам пользователя из LDAP. Заполняются переменные LDAP_ROLES и LDAP_ROLES_DN - список ролей пользователя и DN ролей пользователя, полученных из каталога LDAP.

Список всех групп, которым принадлежит пользователь, можно получить с помощью функции LDAP_USER_GROUPS:

LDAP_USER_GROUPS(<имя пользователя> [, <фильтр списка групп> ])

Для получения полного списка групп пользователей каталога LDAP можно использовать функцию LDAP_GROUPS:

LDAP_GROUPS([ <фильтр списка групп> ])

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

Результирующие списки групп можно отфильтровать во время запроса с помощью необязательных аргументов функций LDAP_GROUPS и LDAP_USER_GROUPS:

select LDAP_GROUPS('objectClass=posixGroup') from rdb$database;
select LDAP_USER_GROUPS('TEST-USER', 'objectClass=posixGroup') from rdb$database;

Изменение пароля в LDAP

Чтобы сменить или задать пароль пользователя в LDAP используется параметр конфигурации LDAPPasswordSync. В нём через «;» указываются пароли, которые необходимо сменить (по умолчанию – все возможные). При изменении пароля указанный пользователь сначала ищется в базе данных безопасности и, если он там найден, его пароль меняется. Затем пользователь ищется в LDAP (если задан адрес LDAP-сервера). В LDAP меняются следующие атрибуты:

userPassword – пароль пользователя в Linux (записывается хэш SHA1 в кодировке BASE64).
sambaLMPassword – LMHash для Samba.
sambaNTPassword – MD4 хэш для Samba.
rdbPassword – пароль пользователя на сервере БД, зашифрованный алгоритмом LEGACY, используемым при традиционной аутентификации.
rdbLegacyHistory - история изменения паролей Legacy.
rdbLegacyPasswordTime - время последнего изменения пароля Legacy
rdbSecurePassword – пароль по ГОСТ пользователя на сервере БД, зашифрованный каким-либо алгоритмом из криптоплагина.
rdbPasswordAlgorithm – алгоритм шифрования пароля по ГОСТ на сервере БД (в кодировке UTF-8).
rdbPasswordHistory – история смены ГОСТ паролей.
rdbPasswordTime – время последнего изменения пароля ГОСТ.
rdbSrpVerifier - пароль (верификатор) SRP.
rdbSrpSalt - соль SRP.
rdbSrpHistory - история изменения паролей SRP.
rdbSrpPasswordTime - время последнего изменения пароля SRP.

Если сменить какой-либо пароль не получилось, в firebird.log записывается сообщение об ошибке с указанием имени пользователя, атрибута и описания ошибки. Два связанных с паролем атрибута тоже не меняются. Например, пароль не получится сменить, если в схеме LDAP нет соответствующего ему атрибута. При ошибке смены одного из паролей выполняется попытка сменить остальные пароли.

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

Если пользователь найден, но хотя бы один из паролей не получилось задать, пользователю возвращается ошибка «error changing ldap password».

Если пользователь не найден ни в security5.fdb, ни в LDAP, возвращается ошибка «record not found for user».

Схемы LDAP

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

Чтобы сервер мог использовать эти атрибуты, администратор LDAP должен назначить пользователю класс rdbAuth. У пользователя, от имени которого сервер выполняет подключение к LDAP (LDAPUserDN) должны быть права на чтение всех этих атрибутов и на запись в атрибуты rdbPassword, rdbSrpVerifier, rdbSrpSalt, rdbSecurePassword, rdbPasswordAlgorithm, rdbLegacyHistory, rdbSrpHistory, rdbPasswordHistory, rdbLegacyPasswordTime, rdbSrpPasswordTime, rdbPasswordTime, rdbActive, rdbPolicy, rdbFailedCount, rdbAccessTime. При этом сервер сможет создавать нужные атрибуты запросами к LDAP.

Таблица 9.4 Атрибуты пользователя LDAP
Атрибут	Описание
userPassword	Пароль пользователя, используемый обычно в `UNIX-системах`.
sambaLMPassword	Пароль пользователя, используемый `SAMBA-протоколом`.
sambaNTPassword	Пароль пользователя, используемый `SAMBA-протоколом`.
sambaPwdLastSet	Время последнего изменения атрибутов `sambaLMPassword` и `sambaNTPassword` в формате `UNIX`.
rdbPassword	Пароль для пользователя метода `Legacy_Auth`.
rdbSrpVerifier	Верификатор пользователя для протокола `SRP`.
rdbLegacyHistory	История изменения паролей `Legacy`.
rdbSrpHistory	История изменения паролей `SRP`.
rdbLegacyPasswordTime	Время последнего изменения пароля `Legacy`.
rdbSrpPasswordTime	Время последнего изменения пароля `SRP`.
rdbSrpSalt	Cоль для аутентификации по протоколу `SRP`.
rdbSecurePassword	Пароль для пользователя метода `Multifactor`.
rdbPasswordAlgorithm	Алгоритм шифрования многофакторного пароля на сервере БД (в одировке `UTF-8`).
rdbPasswordHistory	История смены многофакторных паролей.
rdbActive	Атрибут показывает активен пользователь или заблокирован. Значение `true`, если пользователь активен и `false`, если пользователь заблокирован.
rdbPolicy	Название политики безопасности. Если у пользователя этот атрибут не найден, для него применяется политика безопасности по умолчанию (`DEFAULT`).
rdbPasswordTime	Время последней смены ГОСТ-пароля пользователем.
rdbFailedCount	Число неудачных попыток аутентификации с момента последнего успешного входа.
rdbAccessTime	Время, до которого вход пользователя на сервер запрещён.

Аутентификация по протоколу OpenIDConnect

Для аутентификации по протоколу OpenIDConnect в firebird.conf необходимо указать следующие настройки:

AuthServer = OpenIDConnect, Srp -- на стороне сервера
AuthClient = OpenIDConnect, Srp -- на стороне клиента

Для дальнейшей настройки необходимо получить публичные данные ключа провайдера (JSON Web Key - JWK). Это можно сделать по ссылке https://<провайдер>/.well-known/openid-configuration. Публичные ключи провайдера хранятся в jwks_uri.

В файле plugins.conf нужно указать использование OpenIDConnect и публичные данные ключа провайдера (или в plugins/OpenIDConnect.conf).

Plugin = OpenIDConnect {
  Module = $(dir_plugins)/OpenIDConnect
  Config = OpenIDConnect_config
}

Config = OpenIDConnect_config {
  jwks
  {
    jwk = <имя провайдера>
    {
      kid = "<идентификатор ключа>"
      alg = "<алгоритм шифрования>"
      kty = "<тип ключа>"
      use = "<использование открытого ключа>"
      e = "<экспонента RSA ключа>"
      n = "<модуль RSA ключа>"
      x5c = "<сертификат формата X.509>"
    }
  }
}

Описание параметров:

jwk - имя провайдера, выдающего токен;
kid - идентификатор ключа;
alg - криптографический алгоритм;
kty - тип ключа;
use - использование открытого ключа;
e - экспонента RSA ключа (обычно AQAB (0x10001 = 65537)); указывается в формате base64url;
n - модуль RSA ключа; указывается в формате base64url;
x5c - сертификат формата X.509, который можно указать вместо параметров e и n; указывается в формате base64, а не base64url.

Создайте отображение пользователей для аутентификация по протоколу OpenIDConnect во всех базах данных, которые используют текущую базу данных безопасности:

CREATE GLOBAL MAPPING OIDC_AUTH
USING PLUGIN OPENIDCONNECT
FROM ANY USER
TO USER;

Для аутентификация по протоколу OpenIDConnect необходимо предъявить токен. Токен представляет собой строку base64url в формате: <header>.<payload>.<sign>. Header содержит алгоритм токена. На данный момент поддерживается только RS256. Payload содержит следующие ключи: exp - срок действия токена в UTC; sub - пользователь, которому выдан токен; iss - провайдер, выдавший токен.

Передать токен можно через переменную окружения RDB_OID_TOKEN или с помощью утилиты isql, используя опцию -token:

isql <спецификация сервера> -user "<имя пользователя>" -token "<токен>";

Имя пользователя должно совпадать с пользователем, указанным в sub полезной части токена.

Политики безопасности

Общие сведения

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

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

Политики учетных записей создаются и хранятся в базе данных безопасности (security5.fdb или любой другой заданной) в таблице PLG$POLICIES (см. %s) или в LDAP. Информация о назначенных пользователям политиках хранится в базе данных безопасности в таблице PLG$USER_POLICY. Для контроля уникальности паролей хэши старых паролей хранятся в PLG$PASSWD_HISTORY. Дата и время создания пароля сохраняется в поле PLG$PASSWD_TIME в таблице соответствующего метода (PLG$SRP, PLG$USERS, PLG$MF).

Для удобного просмотра всех созданных политик существует псевдотаблица безопасности SEC$POLICIES (см. 17), аналогичная PLG$POLICIES.

Примечание

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

Политики реализуется в виде плагина Policy.

Примечание

Для включения политик плагин Policy должен быть указан в PolicyPlugin.

Если PolicyPlugin = Policy, то попытка пройти аутентификацию будет осуществляться для каждого плагина, указанного в AuthServer, а информация об успешном прохождении будет добавляться в AuthBlock. Затем плагин Policy, указанный в PolicyPlugin, проверяет AuthBlock и решает дать ли доступ пользователю.

Если PolicyPlugin не указан, то аутентификация завершается при первом успешном прохождении по методу, указанному в AuthServer.

Создание политик безопасности

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

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

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

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

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

<параметр> ::= AUTH_FACTORS
             | PSWD_NEED_CHAR
             | PSWD_NEED_DIGIT
             | PSWD_NEED_DIFF_CASE
             | PSWD_MIN_LEN
             | PSWD_VALID_DAYS
             | PSWD_UNIQUE_COUNT
             | PSWD_NEED_SPECIAL
             | MAX_FAILED_COUNT
             | MAX_UNUSED_DAYS

Описание политик приведено в следующей таблице:

Таблица 9.5 Параметры политик
Параметр	Тип	Описание
AUTH_FACTORS	VARCHAR(64)	Факторы аутентификации (задаются в круглых скобках через запятую): `SRP` - пароль (верификатор) SRP `LEGACY` - пароль Legacy `WIN_SSPI` `GSS` `CERTIFICATE` - сертификат пользователя `VERIFYSERVER` - проверка сервера `GOSTPASSWORD` - пароль по ГОСТ
PSWD_NEED_CHAR	INTEGER	Минимальное количество букв в пароле
PSWD_NEED_DIGIT	INTEGER	Минимальное количество цифр в пароле
PSWD_NEED_DIFF_CASE	BOOLEAN	Требование использования различных регистров букв в пароле
PSWD_MIN_LEN	INTEGER	Минимальная длина пароля
PSWD_VALID_DAYS	INTEGER	Срок действия пароля
PSWD_UNIQUE_COUNT	INTEGER	Количество последних не повторяющихся паролей
PSWD_NEED_SPECIAL	INTEGER	Количество специальных символов, требуемых в пароле. Специальным считается любой печатный символ, за исключением букв, цифр и пробела.
MAX_FAILED_COUNT	INTEGER	Количество неудачных попыток входа
MAX_UNUSED_DAYS	INTEGER	Максимальное время неактивности учетных записей пользователя, в днях

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

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_UNUSED_DAYS = 45;

Назначение политики пользователям

Назначение политики пользователю выполняется оператором GRANT POLICY:

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

Пользователь может иметь только одну политику. По умолчанию при создании пользователя ему назначается политика DEFAULT. В ней отсутствуют какие-либо требования к паролям или сессиям пользователей. Чтобы отменить предыдущую политику и назначить новую, нужно просто еще раз выполнить оператор GRANT POLICY <новая_политика>. То есть для того, чтобы отменить требования политики для определенного пользователя, ему необходимо назначить политику по умолчанию:

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

Политики назначаются только пользователям, но не ролям. Назначить политику несуществующему пользователю нельзя.

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

Если при смене пароля пользователь введет пароль, который не удовлетворяет установленной для пользователя политике безопасности, то будет выдано сообщение:

Statement failed, SQLSTATE = HY000

modify record error

При неудачной попытке входа у пользователя увеличивается счётчик неудачных попыток и время доступа к БД устанавливается на текущее + 1 секунда. Когда достигается значение MAX_FAILED_COUNT при неудачных попытках соединиться с базой данных, пользователь блокируется. Для его разблокировки следует подключиться к базе безопасности security5.fdb и установить значение столбца PLG$FAILED_COUNT (см. таблицу PLG$MF), выполнив запрос:

UPDATE PLG$MF SET PLG$FAILED_COUNT=<значение> WHERE PLG$USER_NAME = '<имя_пользователя>'

При установке значения параметра в $0$ пользователь блокироваться не будет.

Есть и другой способ снятие блокировки пользователя. Сброс количества неудачных попыток и времени доступа к БД выполняется оператором RESET USER:

RESET USER <имя пользователя>;

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

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

Использование политик позволяет повысить общую безопасность системы, а именно:

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

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

Работа с политиками безопасности через LDAP

Чтобы для LDAP-пользователей действовали политики безопасности, в LDAP для пользователя предусмотрены следующие атрибуты:

rdbPolicy – название политики безопасности. Если у пользователя этот атрибут не найден, для него применяется политика безопасности по умолчанию (DEFAULT);
rdbLegacyPasswordTime – время последней смены Legacy-пароля пользователем;
rdbSrpPasswordTime – время последней смены SRP-пароля пользователем;
rdbPasswordTime – время последней смены ГОСТ-пароля пользователем;
rdbFailedCount – число проваленных попыток аутентификации с момента последнего успешного входа;
rdbAccessTime – время, до которого вход пользователя на сервер запрещён.

Политика пользователя (rdbPolicy) задаётся при выполнении в базе оператора GRANT <policy> TO <user>, если в конфигурации задано использование LDAP. Это происходит после попытки назначить эту политику пользователю в security5.fdb (независимо от результата этой попытки). Если назначить политику не получилось ни в security5.fdb, ни в LDAP, выдаётся ошибка.

Время последней смены пароля (rdbPasswordTime) задаётся в LDAP после успешной синхронизации пароля.

Атрибуты rdbFailedCount и rdbAccessTime изменяются при попытке аутентификации пользователя на сервере. При успешной попытке они сбрасываются, т.е. устанавливаются в 0. При неудачном входе rdbFailedCount увеличивается на 1, rdbAccessTime устанавливается на секунду большим текущего времени.

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

С введением поддержки множества баз данных безопасности в РЕД Базе Данных появились новые проблемы, которые не могли произойти с единой глобальной базой данных безопасности. Кластеры баз данных, использующие одну и ту же базу данных безопасности, были эффективно разделены. Отображения предоставляют средства для достижения той же эффективности, когда множество баз данных используют каждая свою базу данных безопасности. В некоторых случаях требуется управление для ограничения взаимодействия между такими кластерами. Например:

когда EXECUTE STATEMENT ON EXTERNAL DATA SOURCE требует обмена данными между кластерами;
когда SYSDBA доступ к базам данных необходим от других кластеров, использующих службы;
аналогичные проблемы существовали в РЕД Базе Данных 2.5 и 2.6 под Windows, из-за поддержки доверительной аутентификации: два отдельных списка пользователей — один в базе данных безопасности, а другой в Windows, и необходимо связать их.

Единое решение для всех этих случаев является отображение информации о пользователе, входящего в систему, на внутренние объекты безопасности — CURRENT_USER и CURRENT_ROLE.

Создание отображения объекта безопасности выглядит следующим образом:

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

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

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

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

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

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

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

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

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

Синтаксис позволяет изменять любые опции существующего отображения (ALTER MAPPING) и удалять отображение (DROP MAPPING).

Примеры

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;

9.5. Ролевое разграничение доступа

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

Роль можно создать с помощью следующего оператора [2]:

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

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

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

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

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

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

Для того, чтобы отнять роль у пользователя, используется оператор:

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

Для удаления роли используется оператор:

DROP ROLE <имя роли>;

Существует ряд предопределённых ролей, предназначенных для выполнения функций поддержки и администрирования СУБД. Роли и их назначение приведены в следующей таблице:

Таблица 9.6 Предопределенные роли
Имя роли	Назначение роли
RDB$ADMIN	Дает полные права, но только в текущей базе данных.
PUBLIC	Роль по умолчанию для вновь создаваемых пользователей. Не имеет никаких прав. Не существует в базе данных в явном виде.
RDB$SYSADMIN	Даёт права управления пользователями, создания/изменения/удаления базы данных, а также возможность назначать права пользователя. Роль `RDB$SYSADMIN` должна назначаться в базе данных безопасности.
RDB$DBADMIN	Даёт права управления пользователями, выполнения резервного копирования и восстановления базы из бэкапа, управление настройками базы данных, а также возможность назначать права пользователя.
RDB$USER	Даёт права создавать объекты базы данных и манипулировать ими, выполнять хранимые процедуры.

Кумулятивное действие ролей

Роли могут быть грантованы другие роли. В СУБД РЕД База Данных действует принцип кумулятивного действия ролей. Это значит, что, привилегии конкретной роли - это объединение привилегий, выданных этой роли, и привилегий ролей, назначенных этой роли.

Правила кумулятивного действия ролей:

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

Назначение и отбор у ролей прав других ролей происходит аналогично назначению и отбору прав у пользователей или у ролей:

GRANT Role1 TO Role2;
REVOKE Role2 FROM Role1;

Попытка выполнить повторный GRАNT одной роли на другую не даст ошибки – права обеих ролей не могут от этого измениться.

Попытка выполнить циклическое наследование прав между ролями:

GRANT Role1 TO Role2;
GRANT Role2 TO Role1;

Вернет ошибку при выполнении второго оператора:

Statement failed, SQLCODE = -607

unsuccessful metadata update

-role ROLE2 can not be granted to role ROLE1

При попытке повторного отбора прав одной роли у другой роли:

GRANT Role1 TO Role2;
REVOKE Role1 FROM Role2;
REVOKE Role1 FROM Role2;

будет выдано предупреждение:

Warning: privileges on ROLE1 is not granted to ROLE2.

Аналогичное предупреждение будет выдано и при попытке отнять у роли права той роли, которые не были ей назначены.

Роль RDB$ADMIN

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

Привилегии вступают в силу сразу после входа в обычную базу данных с указанием роли RDB$ADMIN, после чего пользователь получает полный контроль над всеми объектами базы данных.

Роль RDB$ADMIN может быть предоставлена с использованием ключевого слова DEFAULT. В этом случае пользователь автоматически будет получать административные привилегии даже если он не указал роль RDB$ADMIN при входе.

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

В обоих случаях пользователь с правами RDB$ADMIN роли может всегда передавать эту роль другим. Другими словами, WITH ADMIN OPTION уже встроен в эту роль и эту опцию можно не указывать.

Предоставление роли RDB$ADMIN в обычной базе данных

Для предоставления и удаления роли RDB$ADMIN в обычной базе данных используются операторы GRANT и REVOKE, как и для назначения и отмены остальных ролей.

GRANT [DEFAULT]  RDB$ADMIN TO <имя пользователя>
REVOKE [DEFAULT]  RDB$ADMIN FROM <имя пользователя>

Привилегии на роль RDB$ADMIN могут давать только пользователи с правами RDB$ADMIN.

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

Предоставление роли RDB$ADMIN в базе данных безопасности

Предоставление роли RDB$ADMIN в базе данных безопасности даёт возможность создавать, изменять и удалять учётные записи пользователей. Для этого могут использоваться не только операторы GRANT и REVOKE, но и SQL команды управления пользователями: CREATE USER и ALTER USER, в которых указываются специальные опции GRANT ADMIN ROLE и REVOKE ADMIN ROLE.

CREATE USER <имя пользователя> PASSWORD '<пароль>'
GRANT ADMIN ROLE

ALTER USER <имя пользователя> REVOKE ADMIN ROLE

Привилегии на роль RDB$ADMIN могут давать только администраторы.

Для управления учётными записями пользователей пользователь, имеющий права на роль RDB$ADMIN, должен подключиться к базе данных безопасности с этой ролью. Чтобы управлять пользователями из обычной базы данных, у этого пользователя должны быть права на роль RDB$ADMIN в это базе данных. Он определяет роль при соединении и может в ней выполнить любой SQL запрос. Иначе управление учётными записями посредством SQL запросов недоступно.

То же самое можно сделать используя утилиту gsec указав параметр -admin для сохранения атрибута RDB$ADMIN учётной записи пользователя:

gsec -add <имя пользователя> -pw <пароль> -admin yes
gsec -mo <имя пользователя> -admin no

Для управления пользователями через утилиту gsec роль RDB$ADMIN должна быть указана в переключателе -role.

AUTO ADMIN MAPPING

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

подключается с помощью доверенной аутентификации
не определяет никакой роли при подключении

После успешного подключения текущей ролью будет являться RDB$ADMIN.

Включение и выключение флага AUTO ADMIN MAPPING в обычной базе данных осуществляется следующим образом:

ALTER ROLE RDB$ADMIN SET AUTO ADMIN MAPPING
ALTER ROLE RDB$ADMIN DROP AUTO ADMIN MAPPING

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

Альтернативой включения такого флага служит создание отображения предопределённой группы DOMAIN_ANY_RID_ADMINS на роль RDB$ADMIN:

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

В обычных базах данных статус AUTO ADMIN MAPPING проверяется только во время подключения. Если администратор имеет роль RDB$ADMIN потому, что произошло автоматическое отображение во время входа, то он будет удерживать эту роль на протяжении всей сессии, даже если он или кто-то другой в это же время выключает автоматическое отображение. Точно также, включение AUTO ADMIN MAPPING не изменит текущую роль в RDB$ADMIN для администраторов, которые уже подключились.

Для включения AUTO ADMIN MAPPING в базе данных пользователей можно создать глобальное отображение предопределённой группы DOMAIN_ANY_RID_ADMINS на роль RDB$ADMIN следующим образом:

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

Также можно использовать утилиту командной строки gsec:

gsec -mapping set
gsec -mapping drop

Только SYSDBA может включить AUTO ADMIN MAPPING, если он выключен, но любой администратор может выключить его.

При выключении AUTO ADMIN MAPPING пользователь отключает сам механизм, который предоставлял ему доступ и, таким образом, он не сможет обратно включить AUTO ADMIN MAPPING. Даже в интерактивном gsec сеансе новая установка флага сразу вступает в силу.

9.6. Распределение системных привилегий

Пользователю можно назначить часть прав администратора БД, делегировав ему роль с системными привилегиями.

Для этого сначала нужно создать роль с системными привилегиями:

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

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

Таблица 9.7 Системные привилегии
Привилегия	Описание
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 репликации для загрузки наборов изменений в базу данных
PROFILE_ANY_ATTACHMENT	Профилирование подключений других пользователей.
EXECUTE_ANY_OBJECT_IN_DATABASE	Выполнение любого объекта в базе данных.
UPDATE_ANY_OBJECT_IN_DATABASE	Обновление любого объекта в базе данных.

Примечание

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

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

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

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

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

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

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

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

9.7. Разграничение доступа к объектам базы данных

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

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

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

Субъектами доступа в СУБД РЕД База Данных являются пользователи, роли, а также представления, процедуры, функции, пакеты и триггеры, запущенные от имени пользователей.

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

Для каждой пары (субъект – объект) задается явное и недвусмысленное перечисление допустимых типов доступа (читать, писать и т.д.).

Для назначения прав субъектам доступа используется оператор GRANT. Для снятия этих прав используется оператор REVOKE. Полный синтаксис этих операторов представлен в Руководстве по SQL.

Объекты базы можно разделить на две группы:

метаданные («данные о данных», структура базы);
данные (собственно информация, содержащаяся в базе).

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

Доступные для каждого объекта операции сведены в таблицу 9.8:

Таблица 9.8 Объекты и операции над ними
Объект	Операция
База данных	Создание, изменение, удаление
Таблица	Создание, изменение, удаление, добавление строк, изменение строк, удаление строк, выборка строк, ссылка на указанные столбцы внешним ключом
Представление	Создание, изменение, удаление
Процедура/функция/пакет	Создание, изменение, удаление, запуск (вызов)
Триггер	Создание, изменение, удаление
Генератор	Создание, изменение, удаление, использование
Домен	Создание, изменение, удаление
Исключение	Создание, изменение, удаление, использование
Роль	Создание, удаление, назначение пользователю/другой роли, изменение системных привилегий
`BLOB` фильтр	Объявление и удаление объявления `BLOB` фильтра
Сортировка	Добавление сортировки и удаление существующей сортировки
Набор символов	Установка сортировки по умолчанию для набора символов
Записи	Добавление, изменение, удаление, выборка, ссылка на указанные столбцы внешним ключом

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

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

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

Распределение прав на DDL-операции

В СУБД РЕД База Данных пользователь или роль могут получить права на выполнение операций изменения структуры базы данных (DDL-операции) и делегировать свои права другим пользователям или ролям (предложение WITH GRANT OPTION в операторе GRANT).

Права на создание, изменение и удаление объектов назначаются и отменяются следующими выражениями:

Таблица 9.9 Назначение прав на DDL операции
Операция	Объект	Назначение прав
CREATE, ALTER ANY, DROP ANY, ALL [PRIVILEGES]	PROCEDURE, FUNCTION, PACKAGE, ROLE, TABLE, VIEW, EXCEPTION, GENERATOR, DOMAIN, SEQUENCE, CHARACTER SET, COLLATION, FILTER, JOB	GRANT <операция> <объект> TO <список получателей привилегий> [WITH GRANT OPTION] [{GRANTED BY\|AS} [USER] <имя грантора>] REVOKE [GRANT OPTION FOR] <операция> <объект> FROM <список обладателей привилегий> [{GRANTED BY\|AS} [USER] <имя грантора>]
CREATE	DATABASE	GRANT CREATE DATABASE TO <список пользователей и ролей> REVOKE CREATE DATABASE FROM <список пользователей и ролей>
ALTER, DROP, ALL [PRIVILEGES]	DATABASE	GRANT <операция> DATABASE TO <список получателей привилегий> [WITH GRANT OPTION] [{GRANTED BY\|AS} [USER] <имя грантора>] REVOKE [GRANT OPTION FOR] <операция> DATABASE FROM <список обладателей привилегий> [{GRANTED BY\|AS} [USER] <имя грантора>]

Предложение ALL [PRIVILEGES] объединяет привилегии CREATE, ALTER и DROP на указанный тип объекта.

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

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

С помощью предложение GRANTED BY можно предоставлять или отозвать права не от имени текущего пользователя, а от другого пользователя. При использовании оператора REVOKE после GRANTED BY права будут удалены только в том случае, если они были зарегистрированы от удаляющего пользователя. Предложение AS является синонимом GRANTED BY. Предложения GRANTED BY и AS могут использовать только владелец базы данных и администраторы. Даже владелец объекта не может использовать их, если он не имеет административных привилегий.

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

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

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

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

Пример

Для того, чтобы дать пользователю TestUser возможность создавать таблицы, необходимо выполнить следующую команду:

GRANT CREATE TABLE TO TestUser;

Теперь пользователь сможет создавать таблицы, например:

CREATE TABLE TEST_TABLE (ID integer, Name: VARCAHR(50));

При попытке создать какой-либо другой объект базы данных пользователь получит сообщение об ошибке:

Statement failed, SQLCODE = -901

There is no privilege for this operation.

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

Для того, чтобы лишить пользователя права на изменение структуры базы данных, необходимо выполнить команду REVOKE, например:

REVOKE CRATE TABLE FROM TestUser;

Теперь при попытке выполнить операцию

CREATE TABLE TEST_TABLE_2 (ID integer, Name: VARCAHR(50))

пользователь получит сообщение об ошибке следующего вида:

Statement failed, SQLCODE = -901

There is no privilege for this operation.

Распределение прав на DML-операции

По аналогии с распределением прав на DDL-операции, администратор и владелец объекта могут распределять права и на операции доступа к данным (добавление, изменение, выборка, удаление). Пользователь или роль могут делегировать свои права другим пользователям или ролям (предложение WITH GRANT OPTION в операторе GRANT). Синтаксис запросов по доступу к DML-операциям сведен в таблицу 9.10:

Таблица 9.10 Назначение прав на DML операции
Операция	Объект	Назначение прав
SELECT, DELETE, INSERT, UPDATE [(<имя столбца>[, <имя столбца>])], REFERENCES (<имя столбца>[, <имя столбца>...]), ALL [PRIVILEGES]	TABLE, VIEW	GRANT <операция> ON [TABLE] {<имя таблицы>\|<имя view>} TO <список получателей привилегий> [WITH GRANT OPTION] [{GRANTED BY\|AS} [USER] <имя грантора>] REVOKE [GRANT OPTION FOR] <операция> ON [TABLE] {<имя таблицы> \| <имя представления>} FROM <список обладателей привилегий> [{GRANTED BY\|AS} [USER] <имя грантора>]
USAGE [3]	EXCEPTION, GENERATOR, SEQUENCE	GRANT USAGE ON {EXCEPTION\|GENERATOR\|SEQUENCE} <имя> TO <список получателей привилегий> [WITH GRANT OPTION] [{GRANTED BY\|AS} [USER] <имя грантора>] REVOKE [GRANT OPTION FOR] USAGE ON {EXCEPTION\|GENERATOR\|SEQUENCE} <имя> FROM <список обладателей привилегий> [{GRANTED BY\|AS} [USER] <имя грантора>]
EXECUTE	PROCEDURE, FUNCTION, PACKAGE	GRANT EXECUTE ON {PROCEDURE\|FUNCTION\|PACKAGE} <имя> TO <список получателей привилегий> [WITH GRANT OPTION] [{GRANTED BY\|AS} [USER] <имя грантора>] REVOKE [GRANT OPTION FOR] EXECUTE ON {PROCEDURE \| FUNCTION \| PACKAGE} <имя> FROM <список обладателей привилегий> [{GRANTED BY\|AS} [USER] <имя грантора>]

Предложение WITH GRANT OPTION означает, что пользователь (или роль), кроме права на ту или иную операцию, получит также возможность передать право на эту операцию другому пользователю или роли. Лишить пользователя возможности делегировать свои права можно с помощью оператора REVOKE GRANT OPTION.

С помощью предложение GRANTED BY можно предоставлять или отозвать права не от имени текущего пользователя, а от другого пользователя. При использовании оператора REVOKE после GRANTED BY права будут удалены только в том случае, если они были зарегистрированы от удаляющего пользователя. Предложение AS является синонимом GRANTED BY. Предложения GRANTED BY и AS могут использовать только владелец базы данных и администраторы. Даже владелец объекта не может использовать их, если он не имеет административных привилегий.

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

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

Распределение прав ролям происходит аналогично назначению прав пользователям, только в предложениях GRANT... TO... и REVOKE... FROM... указываются не имена пользователей, а имена ролей.

Примеры

Для того, чтобы дать пользователю, право на вставку данных в таблицу Test_Table необходимо выполнить команду:

GRANT INSERT ON TABLE Test_Table To TESTUSER;

Теперь пользователь TestUser сможет добавлять записи в таблицу Test_Table:

INSERT INTO Test_Table (ID, Name) VALUES (1, 'Alex');

Попытка же выполнить другие операции манипулирования данными вернет ошибку. Например:

SELECT * FROM Test_Table;

вернет ошибку:

Statement failed, SQLCODE = -551

no permission for read/select access to TABLE TEST_TABLE

Для того, чтобы лишить пользователя права добавлять записи в таблицу, необходимо выполнить команду:

REVOKE INSERT ON TABLE Test_Table FROM TESTUSER;

Теперь при попытке вставить запись в таблицу Test_Table пользователь получит сообщение об ошибке:

Statement failed, SQLCODE = -551

no permission for insert/write access to TABLE Test_Table

При попытке доступа к неразрешенным столбцам таблиц пользователь получит сообщение об ошибке, например:

GRANT UPDATE (Name) ON Test_Table TO TestUser;
COMMIT;
CONNECT 'TestDB.fdb' USER TESTUSER PASSWORD TestPass123;
UPDATE Test_Table SET ID=2, Name='Tom';

вернет ошибку:

Statement failed, SQLCODE = -551

no permission for update/write access to COLUMN ID

так как пользователю TESTUSER разрешено изменять значение только столбца Name. А оператор

UPDATE Test_Table Name='Tom';

выполнится без ошибок.

Привилегии выполнения SQL кода

Все объекты метаданных содержащие DML или PSQL код могут выполнятся в одном из следующих режимов:

с привилегиями вызывающего пользователя (привилегии CURRENT_USER);
с привилегиями определяющего пользователя (владельца объекта метаданных).

В РЕД Базе Данных есть возможность указывать объектам метаданных с какими привилегиями они будут выполняться: вызывающего или определяющего пользователя. Для этого используется предложение SQL SECURITY, которое можно указать для таблицы, триггера, процедуры, функции или пакета. Если выбрана опция INVOKER, то объект метаданных будет выполняться с привилегиями вызывающего пользователя. Если выбрана опция DEFINER, то объект метаданных будет выполняться с привилегиями определяющего пользователя (владельца). Эти привилегии будут дополнены привилегиями выданные самому PSQL модулю с помощью оператора GRANT.

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

ALTER DATABASE SET DEFAULT SQL SECURITY {DEFINER | INVOKER}

Для сохранения обратной совместимости по умолчанию используется опция INVOKER.

Примечание

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

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

select RDB$GET_CONTEXT('SYSTEM', 'EFFECTIVE_USER') from RDB$DATABASE

Примечание

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

хранимая процедура INV с SECURITY INVOKER, которая вставляет записи в таблицу T;

хранимая процедура DEF с SQL SECURITY DEFINER, которая определена пользователем SYSDBA.

Если пользователь U вызывает процедуру INV, то для доступа к таблице T потребуется привилегия INSERT выданная пользователю U (и конечно привилегия EXECUTE для INV). В этом случае U является эффективным пользователем (EFFECTIVE_USER) во время выполнения INV.

Если пользователь U вызывает процедуру DEF, то для доступа к таблице T потребуется привилегия INSERT выданная пользователю SYSDBA (и EXECUTE на DEF для пользователя U). В этом случае SYSDBA является эффективным пользователем (EFFECTIVE_USER) во время выполнения DEF.

Если внутри DEF вызывается процедура INV, то эффективным пользователем по время выполнения INV будет так же SYSDBA.

9.8. Аудит

Аудит событий реализован на основе утилиты FBTrace. РЕД База Данных отличает пользовательскую трассировку и системный аудит, которые с помощью Services API позволяют отслеживать и анализировать все, что происходит в базе данных в режиме реального времени. Средства трассировки и аудита позволяют серверу отслеживать и записывать в лог-файлы такие события: соединения и отсоединения от БД (создания и удаления БД), операции DML и DDL, выполнение хранимых процедур и т.д. По умолчанию лог-файлы размещаются в том же каталоге, что и отслеживаемая (логируемая) БД, и имеют имя вида: <имя_базы.fbtrace_text> или <имя_базы.fbtrace_bin> для текстового и бинарного формата лога соответственно. Запись в лог для каждой конкретной БД начинает вестись с момента ее создания или присоединения к ней и до момента отсоединения от нее или ее удаления. Регистрируются события, завершившиеся как удачно, так и неудачно (с ошибкой).

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

Параметр AuditTraceConfigFile в файле конфигурации firebird.conf задает имя и расположение файла с настройками системного аудита. Этот параметр по умолчанию имеет значение fbtrace.conf. Но по умолчанию он не включен (enabled false), что означает отсутствие сессий системного аудита. Можно указать несколько конфигурационных файлов, тогда для каждого будет запущена отдельная сессия аудита. Файл с шаблоном настроек fbtrace.conf находится в корневом каталоге и содержит список отслеживаемых событий и указывает размещение логов трассировки для каждого события. Это позволяет достаточно гибко настроить параметры аудита различных событий для любой базы данных, при этом логирование будет осуществляться в отдельные файлы.

Что касается пользовательской трассировки, она нуждается в запуске пользователем явно. При запуске сессии пользовательской трассировки из приложения задаются ее конфигурация и имя (необязательный параметр). Конфигурация сессии представляет собой текстовый файл, составленный в соответствии с правилами и синтаксисом, приведенными в файле fbtrace.conf. Любой пользователь может инициировать и управлять сессией трассировки. Обычный пользователь может управлять сессиями только в своих соединениях и не может управлять сессиями, начатыми другими пользователями. Администраторы могут управлять любыми сессиями.

Вывод сессии пользовательской трассировки сохраняется во временные файлы, каждый размером в 1 МБ. После прочтения файла приложением он автоматически удаляется. По умолчанию максимальный размер файла вывода ограничен 10 МБ. Он может быть изменен в большую или меньшую сторону с помощью параметра MaxUserTraceLogSize в файле firebird.conf.

После запуска сессии пользовательской трассировки чтение ее вывода осуществляется вызовом из приложения функции isc_service_query(). Сервис может генерировать вывод быстрее, чем приложение может прочитать его. Если общий размер вывода достигает значения ограничения MaxUserTraceLogSize, то сервер автоматически приостанавливает сессию слежения. После того, как приложение завершит чтение файла (размером 1 МБ), он удаляется, работоспособность восстанавливается и сервер автоматически запускает приостановленную ранее сессию.

Когда приложению нужно остановить сессию, достаточно просто послать запрос на отсоединение от сервиса. В качестве альтернативы приложение может использовать функции isc_action_svc_trace_stop, isc_action_svc_trace_suspend, isc_action_svc_trace_resume для остановки, паузы или возобновления сессии трассировки.

Типы событий аудита

В логе аудита могут быть зарегистрированы следующие события:

начало и окончание ведения аудита для БД;
присоединение к БД и отсоединение от нее;
присоединение к сервису и отсоединение от него;
старт сервиса, запрос к сервису;
подготовка, выполнение и освобождение запроса к БД, а также выборка записей;
компиляция и выполнение BLR- и DYN-запросов;
начало и окончание выполнения хранимой процедуры;
начало и окончание выполнения хранимой функции;
начало и окончание выполнения триггера;
установка значения контекстной переменной;
начало и завершение транзакции;
возникновение ошибок и предупреждений;
сборка мусора.

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

По умолчанию система аудита выключена.

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

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

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

Сообщения о вызове сервисов и предъявлении факторов аутентификации записываются в лог-файл базы security5.fdb. В unix-системах у суперсервера недостаточно прав для записи в данный файл. Для решения этой проблемы сервер должен быть запущен от имени root (нужно выполнить скрипт restoreRootRunUser.sh из каталога bin), либо лог-файл может быть создан вручную и пользователь firebird должен иметь право на запись в него.

Возможно использование системы ротации логов, которая активизируется по достижении файлом журнала аудита заданного пользователем максимального размера. При этом рабочий лог-файл переименовывается в файл с именем <log_filename>.<текущая дата и время>.<log_ext>, где дата и время записываются в виде <YYYY-MM-DDThh-mm-ss>, <log_ext> – расширение лог-файла. Этот файл упаковывается в архив ZIP в Windows-системах, GZIP - в Linux-системах. После завершения сжатия исходный архивируемый файл удаляется, а его содержимое очищается если включена очистка памяти (MemoryWipePasses > 0). Директория, в которой будет создан архив, задаётся параметром archive_directory. После переименования рабочего лога, создается новый файл с именем переименованного. Этот новый файл используется в дальнейшем в качестве рабочего лога. Удаление старых лог-файлов не предусмотрено и может осуществляться средствами ОС и планировщиками задач.

Настройка аудита. Параметры конфигурационного файла

Настройка регистрации событий происходит с помощью изменения параметров в файле fbtrace.conf, расположенном в каталоге установки РЕД База Данных.

Файл конфигурации может состоять из двух секций:

database [= /путь/к/бд]
{

...

}
services
{

...

}

Различные database ... секции состоят из параметров, отвечающие за логирование событий на уровне запросов. services секция может быть только в единственном экземпляре, позволяет делать трейс для широкого круга вызовов Services API (таких как резервирование, восстановление данных и т.д.)

Настроить регистрацию событий можно для конкретной базы данных отдельно. Для этого нужно указать путь к нужной базе данных. При этом в качестве имени базы данных можно указать регулярное выражение на основе SIMILAR TO. Синтаксис SIMILAR TO см. в Руководстве по SQL.

Строка, следующая за символом #, считается комментарием. В параметрах, значения которых допускают использование регулярных выражений, используется синтаксис регулярных выражений SQL (аналогично оператору SIMILAR TO). Значение параметра true означает что параметр включен, false – что он выключен.

В текстовом режиме по умолчанию включено логирование единственного типа событий — завершения выполнения SQL-запросов (если включен сам аудит).

В бинарном режиме автоматически регистрируются события всех типов. Игнорируются все параметры, за исключением enabled, format, log_filename, max_log_size, rotate_log и archive_directory.

В конфигурационном файле настраиваются следующие параметры.

Общие параметры

enabled = true/false

Вести аудит или нет. По умолчанию аудит выключен.

format = 0/1/2/3/text/binary/syslog/aggtrace

Формат лог-файла.

0/text – текстовый (по умолчанию);
1/binary – бинарный;
2/syslog - запись в системный лог;
3/aggtrace - агрегатный.

В Linux запись в системный лог осуществляется вызовом функции syslog, обычно события регистрируются в системный лог-файл (например, /var/log/messages). При этом используются следующие категории событий:

LOG_AUTH - для событий аутентификации;
LOG_AUTHPRIV - для событий безопасности;
LOG_DAEMON - для остальных событий.

Приоритет событий:

LOG_ERR - для событий, завершившихся с ошибкой;
LOG_NOTICE - для событий безопасности;
LOG_INFO - для всех остальных событий.

В Windows события регистрируюся в системный журнал событий. Для успешных событий используется тип сообщения EVENTLOG_INFORMATION_TYPE, для неуспешных - EVENTLOG_ERROR_TYPE. В качестве источника будет указан Red Database SQL Server.

Параметр игнорируется при запуске трассировки через rdbtracemgr.

log_filename = <строка>

Имя файла лога. Если этот параметр не задан, лог-файл создаётся в той же папке, где находиться БД и имеет имя вида <имя_базы.fbtrace_text> или <имя_базы.fbtrace_bin>. Возможно использование регулярных выражений в этом параметре. Например, с их помощью можно разбить путь к БД на группы и обращаться к этим группам конструкциями вида \1, \2 и т.д. (см. примеры ниже). При явном указании имени файла, все события от всех логируемых БД будут сохранятся в данном файле. В этом параметре разделитель каталогов Windows - символ обратной косой черты \ - должен дублироваться. Применяется для текстового и бинарного формата лог-файла. Параметр игнорируется при запуске трассировки через rdbtracemgr.

max_log_size = <число>

Задает максимальный размер log-файлов в мегабайтах. Если значение параметра равно 0, то размер файла журнала не ограничен, ротация логов не используется. Значение по умолчанию для текстового формата лог-файла – 50. Значение по умолчанию для бинарного формата – 500. Значение по умолчанию для агрегатного аудита - 2048. Не применяется при записи в системный лог. Параметр игнорируется при запуске трассировки через rdbtracemgr.

rotate_log = true/false

Определяет, использовать ли систему ротации логов. Если значение равно true, то при достижении логом размера max_log_size будет выполняться его ротация. Если значение равно false, то при достижении логом размера max_log_size запись в лог будет остановлена, сессия трассировки будет отключена. Значение по умолчанию для текстового формата лог-файла – true. Значение по умолчанию для бинарного формата - false. Применяется для текстового и бинарного формата лог-файла. Параметр игнорируется при запуске трассировки через rdbtracemgr.

archive_directory = <строка>

Путь к директории, в которую будут записываться логи после ротации. Значение по умолчанию – пусто, то есть архив будет создан в той же директории, где лог. Если операция записи в журнал завершилась с ошибкой исчерпания места, то будет произведена принудительная ротация логов. Применяется для текстового и бинарного формата лог-файла. Параметр игнорируется при запуске трассировки через rdbtracemgr.

time_format = <h/n/u/m/s>

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

h - человекочитаемый формат;
n - наносекунды;
u - микросекунды;
m - миллисекунды (значение по умолчанию);
s - секунды.

Применяется для текстового формата лог-файла и для записи в системный лог.

cancel_on_error = true/false

Если включен, отменяет текущую записываемую операцию, если при записи в лог-файл произошла ошибка. По умолчанию выключено (значение false).

print_hostname = true/false

Включает/отключает печать имени хоста. По умолчанию значение false.

log_services = true/false

Включает или отключает аудит событий присоединения/отсоединения и старта сервиса. Агрегатный аудит не логирует события сервисов. По умолчанию выключено.

log_service_query = true/false

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

log_message = true/false

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

connection_id = <число>

Задаёт номер (идентификатор) подключения на сервере, которое будет отслеживаться. По умолчанию равно 0, т.е. отслеживаются все подключения. Не применяется для агрегатного формата.

include_gds_codes = <GDS-коды>

Это список GDS-кодов ошибок или предупреждений. Если список пустой, то в конечный лог будут включены все ошибки. Иначе в лог будут записываться только ошибки из этого списка. Не применяется для агрегатного формата.

exclude_gds_codes = <GDS-коды>

Это список GDS-кодов ошибок или предупреждений. Если список пустой, то в конечный лог будут включены все ошибки. Иначе в лог будут записываться ошибки, не входящие в этот список. Не применяется для агрегатного формата.

include_user_filter = <регулярное выражение>

Регулярное выражение, которому должно соответствовать имя пользователя, от которого выполняется соединение с базой данных. Аудит будет работать только для тех подключений, которые прошли эту проверку. Значение по умолчанию – пусто, то есть в лог будут включены все подключения. Не применяется для агрегатного формата.

exclude_user_filter = <регулярное выражение>

Регулярное выражение, противоположное include_user_filter. Подключения от пользователей, совпавших с этим выражением не будут регистрироваться. Значение по умолчанию – пусто, то есть в лог будут включены все подключения. Не применяется для агрегатного формата.

include_process_filter = <регулярное выражение>

Регулярное выражение, которому должно соответствовать название пользовательского процесса, выполняющего соединение с базой данных. Аудит будет работать только для тех подключений, которые прошли эту проверку. Значение по умолчанию – пусто, то есть в лог будут включены все подключения. Не применяется для агрегатного формата.

exclude_process_filter = <регулярное выражение>

Регулярное выражение, противоположное include_process_filter. Подключения от процессов, совпавших с этим выражением не будут регистрироваться. Значение по умолчанию – пусто, то есть в лог будут включены все подключения. Не применяется для агрегатного формата.

Параметры текстового аудита

include_filter = <регулярное выражение>

Этот параметр задаёт регулярное выражение в синтаксисе SQL (SIMILAR TO), которому должен удовлетворять текст SQL-запроса. Если текст запроса не удовлетворяет заданному здесь шаблону, этот запрос не записывается в лог. Значение по умолчанию – пусто, то есть в конечный лог будут включены все запросы. Применяется только для текстового формата лог-файла.

exclude_filter = <регулярное выражение>

Задаёт регулярное выражение в синтаксисе SQL (SIMILAR TO), которому не должен удовлетворять текст SQL-запроса. Аналогично include_filter. Значение по умолчанию – пусто. Применяется только для текстового формата лог-файла.

log_connections = true/false

Определяет, записывать ли события присоединения/отсоединения к БД в лог-файл. Применяется только для текстового формата лог-файла.

log_transactions = true/false

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

log_statement_prepare = true/false

Определяет, записывать ли события подготовки запросов к БД в лог-файл. Применяется только для текстового формата лог-файла.

log_statement_free = true/false

Определяет, записывать ли события освобождения запросов к БД в лог-файл. Применяется только для текстового формата лог-файла.

log_statement_start = true/false

Определяет, записывать ли события начала выполнения запросов к БД в лог-файл. Применяется только для текстового формата лог-файла.

log_statement_finish = true/false

Определяет, записывать ли события окончания выполнения запросов к БД в лог-файл. Применяется только для текстового формата лог-файла.

log_procedure_compile = true/false

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

log_procedure_start = true/false

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

log_procedure_finish = true/false

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

log_function_compile = true/false

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

log_function_start = true/false

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

log_function_finish = true/false

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

log_trigger_compile = true/false

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

log_trigger_start = true/false

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

log_trigger_finish = true/false

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

log_context = true/false

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

log_errors = true/false

Включает/отключает запись об ошибках. Применяется только для текстового формата лог-файла.

log_warnings = true/false

Включает/отключает запись о предупреждениях. Применяется только для текстового формата лог-файла.

log_initfini = true/false

Определяет, записывать ли события начала/окончания ведения аудита БД в лог-файл. Применяется только для текстового формата лог-файла.

log_sweep = true/false

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

log_blr_requests = true/false

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

log_dyn_requests = true/false

Определяет, записывать ли события прямого выполнения откомпилированных запросов на изменение метаданных (DDL) во внутреннем представлении сервера - DYN. Применяется только для текстового формата лог-файла.

log_privilege_changes = true/false

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

log_changes_only = true/false

Включает/отключает запись только тех событий, которые изменяли данные в базе. Применяется только для текстового формата лог-файла.

time_threshold = <число>

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

max_sql_length = <число>

Максимальная длина одной записи SQL-запроса в лог-файле, в байтах. Значение по умолчанию – 0 (неограниченно), максимальное значение – 64К. Если длина запроса больше указанного здесь значения, запрос будет обрезан. Применяется только для текстового формата лог-файла [5].

max_blr_length = <число>

Максимальная длина BLR-запроса, сохраняемого в лог, в байтах. Значение по умолчанию – 500 байт. Максимальное значение – 64К. Если длина запроса больше указанного здесь значения, запрос будет обрезан. Применяется только для текстового формата лог-файла.

max_dyn_length = <число>

Максимальная длина DYN-запроса, сохраняемого в лог, в байтах. Значение по умолчанию – 500 байт. Максимальное значение – 64К. Если длина запроса больше указанного здесь значения, запрос будет обрезан. Применяется только для текстового формата лог-файла.

max_arg_length = <число>

Максимальная длина одного параметра запроса / процедуры в лог-файле. Значение по умолчанию – 0 (неограниченно). Максимальное значение – 64К. Если длина параметра больше указанного здесь значения, параметр будет обрезан. Применяется только для текстового формата лог-файла.

max_arg_count = <число>

Максимальное количество параметров запроса / процедуры, которое заносится в лог-файл. Значение по умолчанию – 0 (неограниченно). Параметры, номера которых больше указанного здесь значения, отображаться не будут. Применяется только для текстового формата лог-файла.

print_plan = true/false

Включает/отключает печать планов запросов. По умолчанию значение false. Применяется только для текстового формата лог-файла.

explain_plan = true/false

Включает/отключает печать расширенных планов запросов. По умолчанию значение false. Применяется только для текстового формата лог-файла.

print_perf = true/false

Включает/отключает печать статистики выполнения запросов. По умолчанию значение false. Применяется только для текстового формата лог-файла.

print_blr = true/false

Если параметр установлен в true, то содержимое BLR-запросов будет преобразовываться в текстовое представление. Если параметр установлен в false, то BLR-запрос будет сохранен в двоичном виде (последовательность байт). Этот параметр будет работать только для текстового формата лога. В бинарном формате содержимое BLR всегда будет сохраняться в двоичном виде.

print_dyn = true/false

Если параметр установлен в true, то содержимое DYN-запросов будет преобразовываться в текстовое представление. Если параметр установлен в false, то DYN-запрос будет сохранен в двоичном виде (последовательность байт). Этот параметр будет работать только для текстового формата лога. В бинарном формате содержимое DYN всегда будет сохраняться в двоичном виде. По умолчанию значение false. Применяется только для текстового формата лог-файла.

log_security_incidents = true/false

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

print_security_level = true/false

Включает/отключает печать уровня важности события. Уровни важности:

EMERG - аварийный;
FATAL - фатальный;
CRITICAL - критический;
HIGH - высокий;
MEDIUM - средний;
LOW - низкий;
DEBUG - отладочный.

По умолчанию отключено. Применяется только для текстового формата лог-файла.

print_security_type = true/false

Включает/отключает печать типа события. Типы событий:

AUTHENTICATION - аутентификация;
IDENTIFICATION - идентификация;
USER MANAGEMENT - управление пользователями и ролями;
ACCESS MANAGEMENT - управление доступом;
START/STOP COMPONENT - запуск/остановка сервера;
RESTORE - восстановление из резервной копии;
ACCESS TO PROTECTED INFO - изменение правил разграничения доступа;
VALIDATION OF THE SOFTWARE COMPONENTS - проверка целостности объектов контроля;
OTHER - другое.

По умолчанию отключено. Применяется только для текстового формата лог-файла.

Параметры агрегатного аудита

reset_counters = true/false: Опция reset_counters определяет, сбрасывать ли значения счётчиков для события. При reset_counters = true значения perf, count, succeed и failed у события будут обнуляться при вызове агрегатного аудита через сервисы с любыми опциями, кроме -atrc_clear. По умолчанию выключено.
max_sql_length = <число>: Определяет максимальную допустимую длину SQL-запроса. По умолчанию значение 0, то есть длина не ограничена.
max_plan_length = <число>: Определяет максимальную допустимую длину плана SQL-запроса. По умолчанию значение 0, то есть длина не ограничена.

Примеры настройки

При помощи регулярных выражений можно задавать конкретные БД для логирования. Примеры конфигурационных файлов аудита:

Пример 1:

#Лог ведется для баз с именами test.fdb, azk2.fdb, rules.fdb
database = %[\\/](test|azk2|rules).fdb
{
    enabled = true
    # Логи сохраняются в файлы  test.log, azk2.log, rules.log соответственно
    log_filename = \1.log
}

Пример 2:

#Для всех БД на диске С с расширением fdb — формат лога текстовый
database = C:%.fdb
{
    enabled = true
    format = 0
}

#Для всех БД с расширением fdb на диске D — формат лога бинарный
database = D:%.fdb
{
    enabled = true
    format = 1
}

Пример 3:

В регулярных выражениях можно использовать группировку - ().

#Первая группа (%[\\/]) - любой путь к файлам БД
#Вторая группа (test|azk) — имя файла БД test или azk

database = (%[\\/])(test|azk).fdb
{
    enabled = true
    #\1 — Первая группа - путь.
    #\2 — Вторая группа - имя файла
    log_filename = \1\\logs\\\2.log
}

То есть будут создаваться лог-файлы с именами <имя_базы.log> в каталоге logs расположенном на одном уровне с каталогом, содержащим базы.

Текстовый файл аудита

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

Результат UNAUTHORIZED записывается, если возникла ошибка, связанная с недостаточными правами доступа или неверными данными при аутентификации. В случае возникновения других ошибок результатом будет FAILED.

Начало/окончание ведения аудита

Включить ведение записей об этом событии позволяет параметр log_initfini. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>)
    SESSION_<ID сессии> <имя сессии>
    <путь к базе данных>

Где <тип события>:= {TRACE_INIT | TRACE_FINI}.

Присоединение/отсоединение от БД

Включить ведение записей об этом событии позволяет параметр log_connections. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) <событие>, <важность события>, <тип события>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>

<тип события>:= {CREATE_DATABASE| ATTACH_DATABASE| DROP_DATABASE| DETACH_DATABASE}

<сведения о соединении> ::=
    <путь к БД> (ATT_<ID соединения>, <имя пользователя>:<роль>, <кодировка>,
    <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>)

В случае неуспешной или несанкционированной попытки выполнения присоединения или отсоединения от БД в типе события фиксируется результат FAILED или UNAUTHORIZED.

Начало/завершение транзакции

Включить ведение записей об этом событии позволяет параметр log_transactions. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) <событие>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
    [<глобальные счетчики>]
    [<табличные счетчики>]

<тип события> := {START_TRANSACTION | COMMIT_RETAINING | COMMIT_TRANSACTION |
                  ROLLBACK_RETAINING | ROLLBACK_TRANSACTION}

<сведения о соединении> ::=
    <путь к БД> (ATT_<ID соединения>, <имя пользователя>:<роль>, <кодировка>,
    <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>)

<уровень изоляции> ::= {CONSISTENCY | CONCURRENCY | {READ_COMMITTED|REC_VERSION} |
                       {READ_COMMITTED|NO_REC_VERSION} |
                       {READ_COMMITTED|READ_CONSISTENCY}}

<режим разрешения блокировок> ::= {WAIT [N] | NOWAIT};

<режим доступа к данным> := {READ_ONLY | READ_WRITE};

<глобальные счетчики> ::= m1 ms, m2 read(s), m3 write(s), m4 fetch(es), m5 mark(s)

<табл. счетчики> ::=  Table Natural Index Update Insert Delete Backout Purge Expunge
                      **************************************************************

В случае неуспешной или несанкционированной попытки выполнения старти или завершения транзакции в типе события фиксируется результат FAILED или UNAUTHORIZED.

Записи содержат табличные и глобальные счетчики, только если в настройках включен параметр print_perf.

Таблица 9.11 Табличные счетчики
Table	Имя таблицы
Natural	Количество записей, считанных последовательно (без индекса)
Index	Количество записей, считанных по индексу
Update	Количество обновленных записей
Insert	Количество вставленных записей
Delete	Количество удаленных записей
Backout	Количество записей, для которых были восстановлены предыдущие версии из-за отката транзакции или точки сохранения
Purge	Количество записей, для которых были удалены устаревшие версии, не нужные ни одной активной транзакции
Expunge	Количество вычищенных средствами сборки мусора записей (`expunged records`). Это происходит, когда запись, которая не видна какой-либо активной транзакции, удаляется и удаляющая транзакция подтверждается (`commit`). Удалённая запись и все ранее подтверждённые версии этой записи удаляются, чтобы занятое ими дисковое пространство можно было повторно использовать. Если запись всё ещё видна для более старых snapshot транзакций, конечно, удаление может произойти только после завершения этих транзакций
Lock	Количество записей прочитанных с использованием предложения `WITH LOCK`
Wait	Количество попыток обновления/модификации/блокировки записей принадлежащих нескольким активным транзакциям. Транзакция находится в режиме `WAIT`
Conflict	Количество неудачных попыток обновления/модификации/блокировки записей принадлежащих нескольким активным транзакциям. В таких ситуациях сообщается о конфликте обновления (`UPDATE CONFLICT`)
BVersion	Количество прочитанных версий при поиске видимых версий записей
Fragment	Количество прочитанных фрагментов записей
Refetch	Количество повторно прочитанных записей

Таблица 9.12 Глобальные счетчики
ms	время выполнения
read(s)	количество страниц, считанных с диска
write(s)	количество страниц, записанных на диск
fetch(es)	количество страниц, считанных из страничного кэша
mark(s)	количество страниц, изменённых в страничном кэше

Подготовка запросов к БД

Включить ведение записей об этом событии позволяет параметр log_statement_prepare. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) PREPARE_STATEMENT <важность события>, <тип события>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
Statement <идентификатор запроса>:
------------------------------------------------------------------------------------
<содержимое запроса>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[<план запроса>]
<время выполнения> ms

<сведения о соединении> ::=
    <путь к БД> (ATT_<ID соединения>, <имя пользователя>:<роль>, <кодировка>,
                 <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>)

<уровень изоляции> ::= {CONSISTENCY | CONCURRENCY | {READ_COMMITTED|REC_VERSION} |
                       {READ_COMMITTED|NO_REC_VERSION}}

<режим разрешения блокировок> ::= {WAIT [N] | NOWAIT};

<режим доступа к данным> := {READ_ONLY | READ_WRITE};

В случае неуспешной или несанкционированной попытки подготовки запроса в типе события фиксируется результат FAILED или UNAUTHORIZED.

План выполнения запроса выводится, если включен параметр print_plan.

Освобождение запросов к БД

Включить ведение записей об этом событии позволяет параметр log_statement_free. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) {FREE_STATEMENT | CLOSE_CURSOR} <важность события>, <тип события>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
Statement <идентификатор запроса>:
------------------------------------------------------------------------------------
<содержимое запроса>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<план запроса>

План выполнения запроса выводится, если включен параметр print_plan.

Начало/окончание выполнения запросов к БД

Включить ведение записей об этом событии позволяют параметры log_statement_start и log_statement_finish. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) <событие>, <важность события>, <тип события>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
Statement <идентификатор запроса>:
------------------------------------------------------------------------------------
<содержимое запроса>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[<план запроса>]
<параметры выполнения запроса>
[<количество выбранных записей> records fetched]
    [sorting memory usage: total: <суммарный размер кэша>,
     cached: <размер RAM кэша>, on disk: <размер дискового кэша>]
    [<глобальные счетчики>]
    [<табличные счетчики>]

<тип события>:= {EXECUTE_STATEMENT_START | EXECUTE_STATEMENT_FINISH}

В случае неуспешной или несанкционированной попытки выполнения запроса в типе события фиксируется результат FAILED или UNAUTHORIZED.

В типе события {EXECUTE_STATEMENT_FINISH}, при использовании сортировки, будет добавлена запись sorting memory usage со счетчиками выделенного кэша. В противном случае, если сортировка не использовалась, к records fetched будет добавлено without sorting.

План выполнения запроса выводится, если включен параметр print_plan.

Записи содержат табличные и глобальные счетчики (см. таблицу 9.11 и таблицу 9.12), только если в настройках включен параметр print_perf.

Изменение значений контекстных переменных

Включить ведение записей об этом событии позволяет параметр log_context. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) SET_CONTEXT
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
[<пространство_имен>] <имя_переменной> =  <значение_переменной>

Изменение правил разграничения доступа

Включить ведение записей об этом событии позволяет параметр log_privilege_changes. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) PRIVILEGES_CHANGE
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
    Executed by <executor> as <grantor>,operation:{ADD|DELETE} PRIVILEGE <прив-ия>
    <объект> for <имя пользователя>
    Attachment: <ID_соединения>, Transaction: <ID_транзакции>

<привилегия> ::= {ALL | INSERT | UPDATE | DELETE | SELECT | EXECUTE | REFERENCE | CREATE | ALTER | ALTER ANY | DROP | DROP ANY | ROLE | ENCRYPTION KEY}

Начало/завершение выполнения хранимых процедур (функций)

Включить ведение записей об этом событии позволяют параметры log_procedure_start и log_procedure_finish (log_function_start, log_function_finish). Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) <событие>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
     (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
Procedure (Function) <имя процедуры (функции)>:
    <входные параметры хранимой процедуры (функции)>
    [returns: <выходное значение функции>]
<количество выбранных записей> records fetched
    [sorting memory usage: total: <суммарный размер кэша>,
     cached: <размер RAM кэша>, on disk: <размер дискового кэша>]
    [<глобальные счетчики>]
    [<табличные счетчики>]

<тип события>:= {EXECUTE_PROCEDURE_START | EXECUTE_FUNCTION_START |
                EXECUTE_PROCEDURE_FINISH | EXECUTE_FUNCTION_FINISH}

В случае неуспешной или несанкционированной попытки выполнения хранимой процедуры или функции в типе события фиксируется результат FAILED или UNAUTHORIZED.

В типе события {EXECUTE_PROCEDURE_FINISH}/{EXECUTE_FUNCTION_FINISH}, при использовании сортировки, будет добавлена запись sorting memory usage с счетчиками выделенного кэша. В противном случае, если сортировка не использовалась, к records fetched будет добавлено without sorting.

Записи содержат табличные и глобальные счетчики (см. таблицу 9.11 и таблицу 9.12), только если в настройках включен параметр print_perf.

Начало/завершение выполнения триггеров

Включить ведение записей об этом событии позволяют параметры log_trigger_start и log_trigger_finish. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>)
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
    <имя_триггера> [FOR <имя_таблицы (представления)>] ({ON <событие БД>} |
    {BEFORE | AFTER}  <событие таблицы (представления) или DDL-событие>)
    [<глобальные счетчики>]
    [<табличные счетчики>]

<тип события>:= {EXECUTE_TRIGGER_START | EXECUTE_TRIGGER_FINISH}

В случае неуспешной или несанкционированной попытки выполнения триггера в типе события фиксируется результат FAILED или UNAUTHORIZED.

Записи содержат табличные и глобальные счетчики (см. таблицу 9.11 и таблицу 9.12), только если в настройках включен параметр print_perf.

Компиляция BLR-запросов перед исполнением

Включить ведение записей об этом событии позволяет параметр log_blr_requests. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) COMPILE_BLR
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
Statement <идентификатор запроса>:
------------------------------------------------------------------------------------
<содержимое запроса>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
<время выполнения> ms

В случае неуспешной или несанкционированной попытки компиляции BLR-запроса в типе события фиксируется результат FAILED или UNAUTHORIZED.

Выполнение BLR-запросов

Включить ведение записей об этом событии позволяет параметр log_blr_requests. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) EXECUTE_BLR
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
Statement <идентификатор запроса>:
------------------------------------------------------------------------------------
<содержимое запроса>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    [<глобальные счетчики>]
    [<табличные счетчики>]

В случае неуспешной или несанкционированной попытки выполнения BLR-запроса в типе события фиксируется результат FAILED или UNAUTHORIZED.

Записи содержат табличные и глобальные счетчики (см. таблицу 9.11 и таблицу 9.12), только если в настройках включен параметр print_perf.

Выполнение DYN-запросов

Включить ведение записей об этом событии позволяет параметр log_dyn_requests. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) EXECUTE_DYN
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
        (TRA_<ID транзакции>,<уровень изоляции>|<режим разр. бл-к>|<режим доступа>)
------------------------------------------------------------------------------------
<содержимое запроса>
<время выполнения> ms

В случае неуспешной или несанкционированной попытки выполнения DYN-запроса в типе события фиксируется результат FAILED или UNAUTHORIZED.

Присоединение/отсоединение к сервисам

Включить ведение записей об этом событии позволяет параметр log_services. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>)
{ATTACH_SERVICE|DETACH_SERVICE} <важность события>, <тип события>
    service_mgr, ( Service  <ID сервиса> , <имя пользователя>,
                  <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>,
                  <клиентский процесс>:<ID клиентского процесса> )

В случае неуспешной или несанкционированной попытки присоединения (отсоединения) к сервису в типе события фиксируется результат FAILED или UNAUTHORIZED.

Старт сервиса

Включить ведение записей об этом событии позволяет параметр log_services. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) START_SERVICE
    service_mgr, ( Service  <ID сервиса> , <имя пользователя>,
                  <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>,
                  <клиентский процесс>:<ID клиентского процесса>)
    <тип запроса к сервису>
    <опции, переданные сервис-менеджеру от клиента при запуске>

В случае неуспешной или несанкционированной попытки старта сервиса в типе события фиксируется результат FAILED или UNAUTHORIZED.

Запросы к сервису

Включить ведение записей об этом событии позволяют параметры log_services и log_service_query. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) QUERY_SERVICE
    service_mgr, ( Service  <ID сервиса> , <имя пользователя>,
                <протокол соединения>:<IP адрес или имя компьютера>:<MAC-адрес>,
                <клиентский процесс>:<ID клиентского процесса>)
    <тип запроса к сервису>
    [Send portion of the query: <данные, переданные сервис-менеджеру> ]
    [Receive portion of the query: <данные, полученные сервис-менеджером>]

В случае неуспешной или несанкционированной попытки выполнения запроса к сервису в типе события фиксируется результат FAILED или UNAUTHORIZED.

Событие с ошибкой или предупреждением

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

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) {ERROR AT|WARNING AT} <...>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
<ошибки>

Чистка базы данных

Включить ведение записей о чистке базы данных позволяет параметр log_sweep. Структура записи в журнале аудита будет выглядеть так:

<дата события>T<время> (<ID процесса>:<ID потока>#<номер записи>) <тип события>
    <сведения о соединении>
    <клиентский процесс>:<ID клиентского процесса>
Transaction counters:
    Oldest interesting     <OIT>
    Oldest active     <OAT>
    Oldest snapshot  <OST>
    Next transaction  <Next>
[<глобальные счетчики>]
[<табличные счетчики>]

<тип события> ::= {SWEEP_START | SWEEP_FINISH | SWEEP_FAILED | SWEEP_PROGRESS}

Записи содержат табличные и глобальные счетчики (см. таблицу 9.11 и таблицу 9.12), только если в настройках включен параметр print_perf.

Адаптер для подключения бинарного файла аудита

Это инструмент анализа журнала аудита в бинарном формате, который позволяет подключать двоичные журналы в виде внешних таблиц и использовать SQL-запросы для поиска и фильтрации данных в них. Удаление и редактирование записей запрещено. Используется понятие версии формата бинарного лог-файла. Она проверяется при инициализации аудита (событие начала ведения аудита), если лог-файл уже существует и имеет бинарный формат. Если версия формата лога, используемая в РЕД Базе Данных, отличается от версии формата существующего файла, то производится ротация (переименование существующего лога, создание рабочего лог-файла с таким же именем).

Подключение журнала производится с помощью SQL-запроса вида:

CREATE TABLE <table_name>EXTERNAL [FILE]
<filespec> ADAPTER 'fbtrace'
[(<col_defs>)]

table_name – имя таблицы, которая будет хранить данные аудита;
filespec – имя лог-файла, который должен быть подключен;
ADAPTER – ключевое слово, необходимое для подключения в качестве внешней таблицы файла с нестандартным форматом данных;
fbtrace – название адаптера, предназначенного для обработки бинарного лога системы аудита;
col_defs – описание полей таблицы аудита (см. таблицу 9.13).

Примечание

При подключение бинарного лога необходимо в firebird.conf настроить параметр ExternalFileAccess, по умолчание он выключен и подключение внешних файлов невозможно.

Таблица 9.13 Поля создаваемой таблицы аудита по типам событий
Общие поля таблицы аудита
Имя поля	Тип	Комментарий
EVENT_TIME	TIMESTAMP	Время регистрации события
EVENT_PROCESS_ID	INTEGER	Идентификатор процесса, вызвавшего событие
EVENT_OBJECT_ID	VARCHAR(16)	Идентификатор объекта, вызвавшего событие (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
EVENT_NUMBER	INTEGER	Номер события, записанного процессом сервера
SECURITY_LEVEL	VARCHAR(16)	Уровень важности события
SECURITY_TYPE	VARCHAR(50)	Тип события

Начало ведения аудита
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`TRACE INIT`

Окончание ведения аудита
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`TRACE FINI`

Присоединение к базе данных
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`CREATE DATABASE` или `ATTACH DATABASE`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполнено присоединение к БД
EVENT_PROTOCOL	BLOB TEXT	Протокол, по которому произошло подключение к БД
EVENT_HOSTNAME	BLOB TEXT	Имя хоста, с которого произошло подключение к БД
EVENT_HW_ADDRESS	BLOB TEXT	Физический адрес клиента (MAC-адрес адаптера)
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором произошло подключение к БД
EVENT_RESULT	VARCHAR(14)	Результат подключения (успешно, неуспешно, несанкционированно)

Отсоединение от базы данных
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`DROP DATABASE` или `DETACH DATABASE`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполнено отключение от БД
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором произошло отключение от БД

Начало транзакции
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`START TRANSACTION`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого стартовала транзакция
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором стартовала транзакция
TRANS_ID	BIGINT	Идентификатор транзакции
TRANS_OPT	BLOB TEXT	Параметры транзакции
EVENT_RESULT	VARCHAR(14)	Результат старта транзакции (успешно, неуспешно, несанкционированно)

Завершение транзакции
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`COMMIT RETAINING`, `COMMIT TRANSACTION`, `ROLLBACK RETAINING` или `ROLLBACK TRANSACTION`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого завершилась транзакция
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором завершилась транзакция
TRANS_ID	BIGINT	Идентификатор транзакции
PERF_INFO	BLOB TEXT	Статистика производительности запроса
PERF_TIME	BIGINT	Время выполнения запроса
EVENT_RESULT	VARCHAR(14)	Результат завершения транзакции (успешно, неуспешно, несанкционированно)

Изменение значения контекстной переменной
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`SET CONTEXT`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого произвели изменения
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполнили изменения контекстной переменной
TRANS_ID	BIGINT	Идентификатор транзакции, в которой произвели изменения
VAR_NS	BLOB TEXT	Пространство имен, для которого устанавливается контекстная переменная
VAR_NAME	BLOB TEXT	Имя контекстной переменной
VAR_VALUE	BLOB TEXT	Значение контекстной переменной

Начало выполнения хранимой процедуры
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`START FUNCTION` или `START PROCEDURE`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется процедура
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется хранимая процедура
TRANS_ID	BIGINT	Идентификатор транзакции
PROC_NAME	BLOB TEXT	Имя хранимой процедуры или функции
PROC_PARAMS	BLOB TEXT	Параметры хранимой процедуры или функции
EVENT_RESULT	VARCHAR(14)	Результат начала выполнения процедуры (успешно, неуспешно, несанкционированно)

Завершение выполнения хранимой процедур
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`FINISH FUNCTION` или `FINISH PROCEDURE`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого завершилось выполнение процедуры
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором завершилось выполнение процедуры
TRANS_ID	BIGINT	Идентификатор транзакции
PROC_NAME	BLOB TEXT	Имя хранимой процедуры или функции
PROC_PARAMS	BLOB TEXT	Параметры хранимой процедуры или функции
FUNC_RESULT	BLOB TEXT	Возвращаемый результат хранимой функции
PERF_INFO	BLOB TEXT	Статистика производительности хранимой процедуры или функции
PERF_TIME	BIGINT	Время выполнения хранимой процедуры или функции
ROW_FETCHED	BIGINT	Число выбранных записей
TOTAL_SORTING_MEMORY_USAGE	BIGINT	Суммарный размер кэша (в байтах), выделенного в процессе сортировки
SORTING_CHACHE_USAGE	BIGINT	Размер RAM кэша (в байтах), выделенного в процессе сортировки
SORTING_FILE_CHACHE_USAGE	BIGINT	Размер временных файлов (в байтах), созданных в процессе сортировки
EVENT_RESULT	VARCHAR(14)	Результат завершения выполнения процедуры (успешно, неуспешно, несанкционированно)

Подготовка запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`PREPARE STATEMENT`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого шла подготовка запроса
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором шла подготовка запроса
TRANS_ID	BIGINT	Идентификатор транзакции
STMT_ID	BIGINT	Идентификатор запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
STMT_SQL	BLOB TEXT	Содержимое SQL-запроса
PERF_TIME	BIGINT	Время подготовки запроса
STMT_ACCESS_PATH	BLOB TEXT	План запроса
EVENT_RESULT	VARCHAR(14)	Результат подготовки запроса (успешно, неуспешно, несанкционированно)

Начало выполнения запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`START EXECUTE STATEMENT`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется запрос
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется запрос
TRANS_ID	BIGINT	Идентификатор транзакции
STMT_ID	BIGINT	Идентификатор запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
STMT_PARAMS	BLOB TEXT	Параметры выполнения запроса
EVENT_RESULT	VARCHAR(14)	Результат начала выполнения запроса (успешно, неуспешно, несанкционированно)

Окончание выполнения запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`FINISH EXECUTE STATEMENT`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется запрос
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется запрос
TRANS_ID	BIGINT	Идентификатор транзакции
STMT_ID	BIGINT	Идентификатор запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
STMT_PARAMS	BLOB TEXT	Параметры выполнения запроса
PERF_INFO	BLOB TEXT	Статистика производительности запроса
PERF_TIME	BIGINT	Время выполнения запроса
ROW_FETCHED	BIGINT	Число выбранных записей
TOTAL_SORTING_MEMORY_USAGE	BIGINT	Суммарный размер кэша (в байтах), выделенного в процессе сортировки
SORTING_CHACHE_USAGE	BIGINT	Размер RAM кэша (в байтах), выделенного в процессе сортировки
SORTING_FILE_CHACHE_USAGE	BIGINT	Размер временных файлов (в байтах), созданных в процессе сортировки
EVENT_RESULT	VARCHAR(14)	Результат завершения выполнения запроса (успешно, неуспешно, несанкционированно)

Освобождение запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`FREE STATEMENT` или `CLOSE CURSOR`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого происходит освобождение запроса
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором освобождается запрос
STMT_ID	BIGINT	Идентификатор запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)

Компилирование BLR-запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`COMPILE BLR`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого компилируется запрос
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором компилируется запрос
TRANS_ID	BIGINT	Идентификатор транзакции
STMT_ID	BIGINT	Идентификатор BLR-запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
BLR_DATA	BLOB BLR	Содержимое BLR-запроса
PERF_TIME	BIGINT	Время компилирования BLR-запроса
EVENT_RESULT	VARCHAR(14)	Результат компилирования BLR-запроса (успешно, неуспешно, несанкционированно)

Выполнение BLR-запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`EXECUTE BLR`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется BLR-запрос
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется BLR-запрос
TRANS_ID	BIGINT	Идентификатор транзакции
STMT_ID	BIGINT	Идентификатор BLR-запроса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
PERF_INFO	BLOB TEXT	Статистика производительности BLR-запроса
PERF_TIME	BIGINT	Время выполнения BLR-запроса
EVENT_RESULT	VARCHAR(14)	Результат выполнения BLR-запроса (успешно, неуспешно, несанкционированно)

Выполнение DYN-запроса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`EXECUTE DYN`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется DYN-запрос
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется DYN-запрос
TRANS_ID	BIGINT	Идентификатор транзакции
DYN_DATA	BLOB DYN	Содержимое DYN-запроса
PERF_TIME	BIGINT	Время выполнения DYN-запроса
EVENT_RESULT	VARCHAR(14)	Результат выполнения DYN-запроса (успешно, неуспешно, несанкционированно)

Присоединение к сервису
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`ATTACH SERVICE`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется присоединение к сервису
SVC_ID	VARCHAR(16)	Идентификатор сервиса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
EVENT_PROTOCOL	BLOB TEXT	Протокол, по которому произошло подключение к сервису
EVENT_HOSTNAME	BLOB TEXT	Имя хоста, с которого произошло подключение к сервису
EVENT_HW_ADDRESS	BLOB TEXT	Физический адрес клиента (MAC-адрес адаптера)
EVENT_DATABASE	BLOB TEXT	База данных, для которой присоединились к сервису
EVENT_RESULT	VARCHAR(14)	Результат присоединения к сервису (успешно, неуспешно, несанкционированно)

Старт сервиса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`START SERVICE`
SVC_ID	VARCHAR(16)	Идентификатор сервиса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
SVC_NAME	BLOB TEXT	Имя вызываемого сервиса
SVC_SWITCHES	BLOB TEXT	Параметры запуска сервиса
EVENT_RESULT	VARCHAR(14)	Результат старта сервиса (успешно, неуспешно, несанкционированно)

Запрос к сервису
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`QUERY SERVICE`
SVC_ID	VARCHAR(16)	Идентификатор сервиса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
SVC_QUERY	BLOB TEXT	Тип запроса к сервису
EVENT_RESULT	VARCHAR(14)	Результат запроса к сервису (успешно, неуспешно, несанкционированно)

Отсоединение от сервиса
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`DETACH SERVICE`
SVC_ID	VARCHAR(16)	Идентификатор сервиса (размер идентификатора заранее неизвестен, зависит от размера указателей в системе)
EVENT_RESULT	VARCHAR(14)	Результат отсоединения от сервиса (успешно, неуспешно, несанкционированно)

Проверка предъявленного фактора аутентификации
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`VERIFY AUTH FACTOR`
EVENT_USER	BLOB TEXT	Пользователь, проходящий аутентификацию
AUTH_FACTOR_TYPE	BLOB TEXT	Тип фактора, предъявленного при аутентификации
EVENT_RESULT	VARCHAR(14)	Результат проверки предъявленных факторов аутентификации (успешно, неуспешно, несанкционированно)

Начало выполнения триггера
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`START TRIGGER`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется триггер
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется триггер
TRANS_ID	BIGINT	Идентификатор транзакции
TRIG_NAME	BLOB TEXT	Название триггера
TRIG_ACTION	BLOB TEXT	Событие, на которое срабатывает триггер
EVENT_RESULT	VARCHAR(14)	Результат начала выполнения триггера (успешно, неуспешно, несанкционированно)

Завершение выполнения триггера
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`FINISH TRIGGER`
EVENT_USER	BLOB TEXT	Пользователь, от имени которого выполняется триггер
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором выполняется триггер
TRANS_ID	BIGINT	Идентификатор транзакции
TRIG_NAME	BLOB TEXT	Название триггера
TRIG_ACTION	BLOB TEXT	Событие, на которое срабатывает триггер
PERF_INFO	BLOB TEXT	Статистика производительности триггера
PERF_TIME	BIGINT	Время выполнения триггера
EVENT_RESULT	VARCHAR(14)	Результат завершения выполнения триггера (успешно, неуспешно, несанкционированно)

Изменение правила разграничения доступа
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`ADD PRIVILEGE` или `DELETE PRIVILEGE`
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором происходит изменение правил разграничения доступа
TRANS_ID	BIGINT	Идентификатор транзакции
EVENT_USER	BLOB TEXT	Пользователь, от имени которого происходит изменение правил разграничения доступа
PRIVILEGE_GRANTOR	BLOB TEXT	Пользователь, выдавший привилегию
PRIVILEGE_OBJECT	BLOB TEXT	Объект, на который выдали привилегию
PRIVILEGE_GRANTEE	BLOB TEXT	Кому выдана привилегия
PRIVILEGE	BLOB TEXT	Выданная привилегия
PRIVILEGE_OPTION	INTEGER	Наличие `GRANT OPTION` при выдаче привилегии
EVENT_RESULT	VARCHAR(14)	Результат изменения правил разграничения доступа (успешно, неуспешно, несанкционированно)

Ошибка
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`WARNING` или `ERROR`
PROC_NAME	BLOB TEXT	Название функции, в которой произошла ошибка
ERROR_MESSAGE	BLOB TEXT	Сообщение об ошибке

Сборка мусора
Имя поля	Тип	Комментарий
EVENT_TYPE	CHAR(24)	`SWEEP`
EVENT_ATT_ID	BIGINT	Идентификатор соединения, в котором произошло отключение от БД
SWEEP_OIT	BIGINT	Oldest Interesting Transaction
SWEEP_OAT	BIGINT	Oldest Active Transaction
SWEEP_OST	BIGINT	Oldest Snapshot Transaction
SWEEP_NEXT	BIGINT	Next Transaction
PERF_TIME	BIGINT	Время выполнения сборки мусора
PERF_INFO	BLOB TEXT	Статистика производительности запроса
EVENT_RESULT	VARCHAR(14)	Состояние сборки мусора (`SWEEP_START \| SWEEP_FINISH \| SWEEP_FAILED \| SWEEP_PROGRESS \| UNKNOWN`)

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

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

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

Если одно из полей задано неверно (ему не соответствует ни одно поле в таблице адаптера), в файл firebird.log записывается соответствующая ошибка и выполнение запроса прерывается.

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

При открытии бинарного лог-файла определяется версия его формата. Если она отличается от номера версии, которая является рабочей для данной версии РЕД Базы Данных, в файл firebird.log записывается соответствующая ошибка

Если производится попытка использования адаптера в БД, ODS которой не поддерживает этого, в файл firebird.log записывается соответствующая ошибка.

Пример подключения журнала с набором конкретных полей:

CREATE TABLE log EXTERNAL FILE '/home/tester/employee.fdb.fbtrace_bin'
ADAPTER 'fbtrace' (
        EVENT_TYPE CHAR(20),
        EVENT_DATABASE BLOB SUB_TYPE 1,
        EVENT_USER BLOB SUB_TYPE 1,
        EVENT_RESULT VARCHAR(14)
);

Утилита трассировки в интерактивном режиме (rdbtracemgr)

Утилита rdbtracemgr позволяет выполнять трассировку в интерактивном режиме. Утилита включает следующий функционал:

Запуск пользовательской трассировки и отображение событий сервера (START)
Завершение сеанса трассировки (STOP)
Приостановление и возобновление сеанса трассировки (SUSPEND и RESUME)
Вывод списка всех существующих сеансов трассировки (LIST)

Синтаксис вызова утилиты:

rdbtracemgr -SE <сервис> -U <имя пользователя> {-P <пароль> | -FE <путь к файлу>} [<параметры подключения>] <действие>

<действие>::=
  <запуск сессии трассировки>
| <завершение сессии трассировки>
| <приостановление сессии трассировки>
| <возобновление сессии трассировки>
| -L[IST]

<запуск сессии трассировки>::= -STA[RT] -C[ONFIG] <конфигурационный файл> [-N <имя сессии>] [-F[ORMAT] <число>] [-O[UTPUT] <путь к файлу> [-REP[LACE]]]

<завершение сессии трассировки>::= -STO[P] -I[D] <ID сессии>

<приостановление сессии трассировки>::= -SU[SPEND] -I[D] <ID сессии>

<возобновление сессии трассировки>::= -R[ESUME] -I[D] <ID сессии>

Таблица 9.14 Параметры подключения rdbtracemgr
Параметр	Описание
-SE[RVICE] <сервис>	Имя сервиса. Обязательный параметр.
-U[SER] <имя пользователя>	Имя пользователя. Обязательный параметр.
-P[ASSWORD] <пароль>	Пароль.
-FE[TCH] <путь к файлу>	Считать пароль из файла. Параметр принимает строку без кавычек и апострофов, содержащую абсолютный или относительный путь к файлу с паролем. Файл должен быть доступен текущему пользователю операционной системы для чтения.
-T[RUSTED]	Использовать доверенную аутентификацию.

Таблица 9.15 Опции rdbtracemgr
Опция	Описание
-C[ONFIG] <конфигурационный файл>	Путь к конфигурационному файлу аудита. Обязательный параметр. Параметры format, log_filename, max_log_size, rotate_log и archive_directory игнорируются.
-I[D] <ID сессии>	ID сессии для завершения, приостановки или возобновления конкретной сессии. Используется совместно с опцией `STOP`, `RESUME` или `SUSPEND`.
-STA[RT]	Запуск сессии трассировки.
-F[ORMAT] <число>	Формат лог-файла: 0 - текстовый формат, 1 - бинарный формат, -1 - legacy формат вывода. Если указано значение 1, то необходимо использовать -O[UTPUT]. По умолчанию значени -1.
-O[UTPUT] <путь к файлу>	Перенаправить вывод в файл.
-REP[LACE]	Перезаписать файл вывода, если он уже существует. Используется совместно с опцией `-OUTPUT`.
-STO[P]	Завершение сессии трассировки. Используется совместно с -ID.
-SU[SPEND]	Приостановить сессию трассировки. Используется совместно с -ID.
-R[ESUME]	Возобновляет сессию трассировки. Используется совместно с -ID.
-N[AME] <имя сессии>	Имя сессии для отображения в списке сессий.
-L[IST]	Вывести список существующих сессий трассировки.
-Z	Вывести версию сервера.

Пример запуска аудита:

rdbtracemgr -SE remote_host:service_mgr -USER SYSDBA -PASS masterkey -START -NAME my_trace -CONFIG my_cfg.txt

9.9. Агрегатный аудит

Агрегатный аудит собирает метрики, которые агрегируются по событиям и транзакциям. Метриками являются следующие значения запросов: read, write, fetch, mark и время выполнения. Аудит хранит значения метрик во время работы сервера. При выключении/перезагрузке сервера сохранённая статистика будет очищена.

Настройка агрегатного аудита

Для настройки агрегатного аудита нужно создать конфигурационный файл, например, aggtrace.conf, и указать в нём следующие параметры:

database
{
  format = 3
  reset_counters = false
  max_log_size = 2048
}

database [= /путь/к/бд]
{
  enabled = true
  format = 3
  max_sql_length = 0
  max_plan_length = 0
}
Файл конфигурации состоит из двух секций. В глобальной секции (database) указываются настройки для плагина aggtrace. Указанные параметры распространяющиеся на все базы данных. В ней должны быть указаны параметры log_max_size и reset_counters.

В секции database [= /путь/к/бд] указываются параметры, распространяющиеся на заданную базу данных.

Опция enabled = true включает ведение аудита.

Опция format = aggtrace указывает, что нужно использовать агрегатный аудит.

Опция reset_counters определяет, сбрасывать ли значения счётчиков для события. При reset_counters = true значения perf, count, succeed и failed у события будут обнуляться при вызове агрегатного аудита через сервисы с любыми опциями, кроме -atrc_clear. Параметр должен быть определён в глобальной секции.

Опция max_sql_length определяет максимальную допустимую длину SQL-запроса, которая может храниться. Запросы, длина которых больше, будут обрезаны до указанного значения. Значение 0 указывает, что длина не ограничена.

Опция max_plan_length определяет максимальную допустимую длину плана SQL-запроса, которая может храниться. Планы, длина которых больше, будут обрезаны до указанного значения. Значение 0 указывает, что длина не ограничена.

Опция max_log_size задает максимальный размер log-файлов в мегабайтах. Допускается значение от 5 до 4096. Если значение параметра равно 0 (по умолчанию), то размер файла журнала не ограничен. Параметр должен быть определён в глобальной секции.

Настройки агрегатного аудита перечитываются для каждого соединения.

В firebird.conf в параметре AuditTraceConfigFiles укажите конфигурационный файл агрегатного аудита:

AuditTraceConfigFiles = aggtrace.conf;

В firebird.conf для параметра TracePlugin укажите значение aggtrace.

TracePlugin = aggtrace
Можно использовать несколько плагинов. Для этого нужно указать их через запятую.

Запуск агрегатного аудита

Запросить значения, собранные агрегатным аудитом, можно следующей командой:

./rdbsvcmgr -service_mgr -user <имя пользователя> -password <пароль> -action_aggtrace [опции]

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

Таблица 9.16 Опции агрегатного трейса

Опция

Описание

-atrc_statement

Запросить метрики событий. Если указана какая-либо "get" опция (atrc_get_new, atrc_get_old, atrc_get_all, atrc_with_query, atrc_get или atrc_get_updated), то atrc_statement будет применена автоматически.

-atrc_get

Запросить метрики новых и обновлённых запросов.

-atrc_get_updated

Запросить метрики только обновлённых запросов т.е тех, у которых изменились значения метрик.

-atrc_get_new

Запросить метрики только новых запросов.

-atrc_get_old

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

-atrc_get_all

Запросить метрики по всем статусам.

-atrc_with_query

Добавлять текст запроса в вывод.

-atrc_with_plan

Добавлять план запроса в вывод.

-atrc_text {<хэш запроса>|<хэш плана>}

Вывести запрос или план запроса по указанному хэшу.

-atrc_transaction

Запросить метрики событий транзакций.

-atrc_get_version

Вывести версию плагина агрегатного аудита.

-atrc_clear

Очистить сохранённую статистику.

Вывод собранных метрик

Схема вывода результата работы aggtrace.schema.json расположена в каталоге doc установки сервера.

Метрики событий

Аудит агрегирует значения событий по следующим параметрам:

dbname - полный путь к базе данных;
event - событие;
query - текст запроса.

Формат вывода метрик событий:

[
  {
    "event": "<событие>",
    "hash": "<хэш>",
    "status": "<статус>",
    "perf": [
      [
        <среднее количество страниц, считанных из страничного кэша (fetch)>,
        <минимальное количество страниц, считанных из страничного кэша (fetch)>,
        <максимальное количество страниц, считанных из страничного кэша (fetch)>,
        <общее количество страниц, считанных из страничного кэша (fetch)>
      ],
      [
        <среднее количество прочитанных (read) страниц базы данных>,
        <минимальное количество прочитанных (read) страниц базы данных>,
        <максимальное количество прочитанных (read) страниц базы данных>,
        <общее количество прочитанных (read) страниц базы данных>
      ],
      [
        <среднее количество страниц, изменённых в страничном кэше (mark)>,
        <минимальное количество страниц, изменённых в страничном кэше (mark)>,
        <максимальное количество страниц, изменённых в страничном кэше (mark)>,
        <общее количество страниц, изменённых в страничном кэше (mark)>
      ],
      [
        <среднее количество страниц, записанных на диск (write)>,
        <минимальное количество страниц, записанных на диск (write)>,
        <максимальное количество страниц, записанных на диск (write)>,
        <общее количество страниц, записанных на диск (write)>
      ],
      [
       <средний объём памяти, выделенный под сортировки>,
       <минимальный объём памяти, выделенный под сортировки>,
       <максимальный объём памяти, выделенный под сортировки>,
       <общий объём памяти, выделенный под сортировки>
      ],
      [
       <средний объём памяти, выделенный под сортировки на диске>,
       <минимальный объём памяти, выделенный под сортировки на диске>,
       <максимальный объём памяти, выделенный под сортировки на диске>,
       <общий объём памяти, выделенный под сортировки на диске>
      ],
      [
       <средний объём памяти, кэшированной в процессе сортировки>,
       <минимальный объём памяти, кэшированной в процессе сортировки>,
       <максимальный объём памяти, кэшированной в процессе сортировки>,
       <общий объём памяти, кэшированной в процессе сортировки>
      ],
      [
        <среднее время выполнения (ns)>,
        <минимальное время выполнения (ns)>,
        <максимальное время выполнения (ns)>
        <общее время выполнения (ns)>,
      ]
    ],
    "count": <общее количество событий>,
    "succeed": <количество успешно выполненных событий>,
    "failed": <количество событий, завершённых с ошибкой>,
    "dbname": "<полный путь к базе данных>",
    "query_hash": "<хэш запроса>",
    "query": "<текст запроса>",
    "plan_hash": "<хэш плана запроса>",
    "plan": "<план запроса>"
  },
  ...
]

Описание значений в выводе:

event – Название события. Отслеживаются следующие события:
- Завершение выполнения хранимой процедуры (FINISH PROCEDURE);
- Завершение выполнения триггера (FINISH TRIGGER);
- Подготовка запроса (PREPARE STATEMENT);
- Начало выполнения запроса (START STATEMENT);
- Завершение выполнения запроса (FINISH EXECUTE STATEMENT);
- Освобождение запроса или закрытие курсора (FREE STATEMENT);
- Завершение выполнения хранимой функции (FINISH FUNCTION).
hash – Хэш агрегированного значения;
status – Статус запроса:
- new – Запрос, метрики которого ранее не запрашивались из агрегатного трейса;
- old – Старый запрос, у которого сохранённые значения мметрик не изменились;
- updated – Обновлённый запрос, у которого обновились сохранённые значения метрик.
perf – Собранные значения метрик;
count – Количество выполнений запроса;
succeed – Количество успешных выполнений;
failed – Количество выполнений, завершённых с ошибкой;
dbname – Полный путь к базе данных или алиас;
query_hash - Хэш запроса;
query – Текст запроса;
plan_hash - Хэш плана запроса;
plan – План запроса.

Метрики транзакций

Формат вывода метрик транзакций:

[
  {
    "dbname": "<база данных>",
    "hash": "<хэш>",
    "<тип транзакции>":{
      "perf": [
        [
          <среднее количество страниц, считанных из страничного кэша (fetch)>,
          <минимальное количество страниц, считанных из страничного кэша (fetch)>,
          <максимальное количество страниц, считанных из страничного кэша (fetch)>,
          <общее количество страниц, считанных из страничного кэша (fetch)>
        ],
        [
          <среднее количество прочитанных (read) страниц базы данных>,
          <минимальное количество прочитанных (read) страниц базы данных>,
          <максимальное количество прочитанных (read) страниц базы данных>,
          <общее количество прочитанных (read) страниц базы данных>
        ],
        [
          <среднее количество страниц, изменённых в страничном кэше (mark)>,
          <минимальное количество страниц, изменённых в страничном кэше (mark)>,
          <максимальное количество страниц, изменённых в страничном кэше (mark)>,
          <общее количество страниц, изменённых в страничном кэше (mark)>
        ],
        [
          <среднее количество страниц, записанных на диск (write)>,
          <минимальное количество страниц, записанных на диск (write)>,
          <максимальное количество страниц, записанных на диск (write)>,
          <общее количество страниц, записанных на диск (write)>
        ],
        [
          <средний объём памяти, выделенный под сортировки>,
          <минимальный объём памяти, выделенный под сортировки>,
          <максимальный объём памяти, выделенный под сортировки>,
          <общий объём памяти, выделенный под сортировки>
        ],
        [
          <средний объём памяти, выделенный под сортировки на диске>,
          <минимальный объём памяти, выделенный под сортировки на диске>,
          <максимальный объём памяти, выделенный под сортировки на диске>,
          <общий объём памяти, выделенный под сортировки на диске>
        ],
        [
          <средний объём памяти, кэшированной в процессе сортировки>,
          <минимальный объём памяти, кэшированной в процессе сортировки>,
          <максимальный объём памяти, кэшированной в процессе сортировки>,
          <общий объём памяти, кэшированной в процессе сортировки>
        ],
        [
          <среднее время выполнения (ns)>,
          <минимальное время выполнения (ns)>,
          <максимальное время выполнения (ns)>
          <общее время выполнения (ns)>,
        ]
      ],
      "count": <общее количество событий>,
      "succeed": <количество успешно выполненных событий>,
      "failed": <количество событий, завершённых с ошибкой>
    },
    "ROLLBACK_TRANSACTION":{
      "perf": [...],
      "count": <общее количество событий>
    },
    "ROLLBACK_RETAINING:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "COMMIT_TRANSACTION:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "COMMIT_RETAINING:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "FAILED ROLLBACK_TRANSACTION:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "FAILED ROLLBACK_RETAINING:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "FAILED COMMIT_TRANSACTION:{
      "perf": [...],
      "count": <общее количество событий>
    },
    "FAILED COMMIT_RETAINING:{
      "perf": [...],
      "count": <общее количество событий>
    }
  }
]

Описание значений в выводе:

dbname – Путь к базе данных или алиас;
hash – Хэш агрегированного значения;
тип транзакции - Выполненная транзакция;
perf – Собранные значения метрик для транзакции;
count – Количество запусков транзакции;
succeed – Количество успешных выполнений;
failed – Количество выполнений, завершённых с ошибкой;

Вывод версии

Формат вывода версии:

{
  "version": "<версия агрегатного аудита>"
}

9.10. Очистка освобождаемых ресурсов

Важная особенность СУБД РЕД База Данных — версионная архитектура. Это означает, что при изменении записи создается новая версия записи. Предыдущая версия остается существовать. Каждая транзакция, стартовавшая на сервере, имеет свой номер. Запись также имеет номер создавшей ее транзакции. Таким образом, каждая транзакция может видеть свою версию записи и именно к ней иметь интерес.

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

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

Функция очистки (обезличивания) освобождаемых ресурсов памяти встроена в РЕД Базу Данных и может настраиваться путём задания различных значений параметра MemoryWipePasses = <integer> в конфигурационном файле сервера. Целочисленное значение, настраивающее необходимость и метод обезличивания освобождаемой памяти, задаёт следующие действия:

0 - не производить обезличивание;
1 - обезличивать освобождаемый ресурс за один проход;
N - производить заданное количество чередующихся заполнений освобождаемого ресурса нулями и единицами. При этом последний проход в любом случае заполняет освобождаемый блок нулями.