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 решает две задачи: во-первых, не разрешить доступ пользователей, идентифицированных на сервере, к данным в вашей базе данных, и, во-вторых, предоставить доступ пользователям, которые работают с вашей базой данных. Средствами реализации такой безопасности на уровне
Первая цель, блокирование ненужных пользователей, авторизованных на сервере, используется в средах, где базы данных, которыми владеют многие объекты, запущены на одном сервере - обычно, на сайте, где выполняются сервисы для множества заказчиков. В подобных ситуациях заказчики провайдера обычно не имеют доступа SYSDBA.
Вторая цель требует большой работы по ограничению доступа к конфиденциальным или чувствительным данным. Привилегии SQL могут поддерживать любой уровень детализации доступа к любому элементу данных вплоть до уровня столбца.
В отличие от пользователей (как обсуждалось в главе 34) привилегии применимы к уровню базы данных и хранятся непосредственно в самой базе данных в системной
таблице RDB$USER_PRIVILEGES.
Безопасность и доступ по умолчанию
База данных и все ее объекты (таблицы, просмотры и хранимые процедуры) становятся защищенными от неавторизованного доступа в момент их создания. То есть доступ является "необязательным". Ни один пользователь не может получить доступ к любому объекту базы данных, не получив на это полномочий. За исключением пользователей с особыми привилегиями - владелец, SYSDBA и (в POSIX) Суперпользователь - пользователи должны иметь привилегии SQL к любой операции, даже к SELECT.
А теперь плохие новости
Существует большая загвоздка, так что не будьте так легко внушаемы ложным чувством безопасности. Несуществующие объекты не являются защищенными. Любой пользователь, имеющий доступ к базе данных, может создать любой допустимый объект базы данных - включая объявления внешних функций и таблиц, связанных с внешними таблицами - которые потенциально могут быть использованы в комбинации с установкой и выполнением хакерского кода на сервере.
С возможностью при инсталляции Firebird 1.5 ограничивать местоположение внешних объектов, к которым может обращаться сервер, ситуация несколько улучшается. При этом риски не устраняются полностью- вы должны выполнить конкретные шаги по реализации этой возможности и созданию ограничений файловой системы операционной системы. Доступ по умолчанию к внешним файлам в инсталляторе установлен в NONE, и каталоги внешних функций ограничены деревом UDF. Ваша задача - позаботиться о системных ограничениях.
Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.
Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.