Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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

ГЛАВА 35. Безопасность на уровне базы данных.

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

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

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

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

таблице RDB$USER_PRIVILEGES.

Безопасность и доступ по умолчанию

База данных и все ее объекты (таблицы, просмотры и хранимые процедуры) становятся защищенными от неавторизованного доступа в момент их создания. То есть доступ является "необязательным". Ни один пользователь не может получить доступ к любому объекту базы данных, не получив на это полномочий. За исключением пользователей с особыми привилегиями - владелец, SYSDBA и (в POSIX) Суперпользователь - пользователи должны иметь привилегии SQL к любой операции, даже к SELECT.

А теперь плохие новости

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