CREATE PROCEDURE log_proc

(un VARCHAR(31)) RETURNS

(x CHAR(1) )

AS

BEGIN

IF (USER = '') THEN

INSERT INTO log_table (TSTAMP, UNAME) VALUES ( CURRENT_HMESTAMP, :un);

/* и не забудьте изменить записанные поля, если вы изменили таблицу log_table, чтобы сделать ее текстовым файлом! */ IF (USER = '' OR USER = 'SYSDBA' OR USER = :un) THEN SUSPEND;

END

Мы проверяем (USER = ''), потому что, когда Firebird проверяет пароль, переменная USER пустая. Это помогает отличить, когда сервер проверяет пароль, а когда пользователь напрямую соединяется с базой данных безопасности.

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

CREATE VIEW USERS (USER_NAME) AS SELECT * FROM users2

WHERE EXISTS (SELECT * FROM logjproc(users2.user_name));

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

GRANT SELECT ON USERS TO PUBLIC;

*/

GRANT UPDATE (PASSWD, GROUP_NAME, UID, GID, FIRST_NAME, MIDDLE_NAME, LAST_NAME) ON USERS TO PUBLIC;

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

GRANT INSERT ON log_table TO PROCEDURE log_proc; GRANT EXECUTE

ON PROCEDURE log_proc TO PUBLIC;

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

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

Например, можно подсчитать количество попыток подключений конкретного пользователя в течение последней минуты и, если это количество достигает некоторого

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

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

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

. . .

DECLARE VARIABLE Cnt INTEGER;

SELECT COUNT(*)

FROM log_table

WHERE uname = :un

AND tstamp > CURRENT_TIMESTAMP - 0.0007

INTO :cnt;

IF (cnt >= 3) THEN EXIT;

Вы можете изменять константы, а именно 3 (допустимое количество ошибок) и 0.0007 (интервал, приблизительно равный одной минуте). Эта процедура действует для всех пользователей.

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

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

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

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