Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

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.

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

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

таблице RDB$USER_PRIVILEGES.

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

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

С возможностью при инсталляции Firebird 1.5 ограничивать местоположение внешних объектов, к которым может обращаться сервер, ситуация несколько улучшается. При этом риски не устраняются полностью- вы должны выполнить конкретные шаги по реализации этой возможности и созданию ограничений файловой системы операционной системы. Доступ по умолчанию к внешним файлам в инсталляторе установлен в NONE, и каталоги внешних функций ограничены деревом UDF. Ваша задача - позаботиться о системных ограничениях.

Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.

Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.

Хотя кажется, что PUBLIC (т. е. все) имеют доступ ALL К системным таблицам, тем не менее существует таинственный черный ход в управлении правами SQL, который может легко исправить ситуацию. Вы можете ограничить доступ к системным таблицам, так же, как и к любым другим таблицам базы данных, предоставив, а затем отменив полномочия. При этом права предоставляются только для того, чтобы быть отмененными.