Читать интересную книгу Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ - Хелен Борри

К счастью, почти для всех из нас фрагменты кодов для реализации событий в клиентских приложениях инкапсулированы в классах и компонентах в большинстве инструментов разработки приложений, которые поддерживают Firebird. Такие компоненты, включающие в себя AST, инкапсулирующие вызовы функций API isc_event* вместе с блоками параметров событий и управление буферами событий на клиентской стороне, обычно называются обработчиками сообщений (event alerter). Иногда этот термин в форумах и литературе вызывает путаницу, потому что триггеры и хранимые процедуры, вызывающие POST_EVENT, также часто называют обработчиками сообщений.

Использование POST_EVENT

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

POST_EVENT <имя-события>;

Параметр <имя-события> может быть или литералом в кавычках, или строковой переменной. Он является чувствительным к регистру и может начинаться с цифры. Имена событий ограничиваются 64 символами.

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

POST_EVENT ' new_order' ;

В альтернативном варианте, при использовании переменной для имени события можно одним оператором посылать различные события в соответствии с текущим значением строковой переменной (например, event_name).

POST EVENT event name;

! ! !

ПРИМЕЧАНИЕ. Хотя POST_EVENT и является оператором SQL, его аргумент имя события не должен иметь префикс двоеточия.

. ! .

Триггер или хранимая процедура, которые посылают сообщение, иногда называются обработчиками сообщений[129]. Следующий скрипт создает триггер, который посылает событие менеджеру событий, когда любое приложение добавляет в таблицу данные:

SET TERM А;

CREATE TRIGGER POST_NEW_ORDER FOR SALES ACTIVE AFTER INSERT POSITION 0

AS

BEGIN

POST_EVENT 'new_order'; END ^

SET TERM ; ^

Триггер или процедура?

Оператор POST EVENT доступен и в триггерах, и в хранимых процедурах. Как же решить, где лучше его поместить для посылки событий?

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

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

Пора дальше

Теперь мы обратимся к безопасности вашего сетевого окружения СУБД. В этой части мы рассмотрим риски и меры безопасности, связанные с выполнением ваших серверов баз данных Firebird. Для начала в следующей главе обсуждаются некоторые слабые места в системе защиты операционного окружения и меры, которые вы можете принять по их устранению.

ЧАСТЬ VIII. Безопасность.

ГЛАВА 33. Безопасность в операционной среде.

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

В этой главе на первый план выдвигаются некоторые вопросы, по поводу которых вы должны предпринять меры предосторожности в вашем окружении сервера и клиентов Firebird. Не имеет никакого смысла выполнять проектирование для решения всех относящихся к безопасности окружения вопросов, которые могут воздействовать на ваш сервер и вашу сеть. Короче говоря, если безопасность имеет серьезное значение для установки вашей системы, то и отнеситесь к ней серьезно. Исследуйте ее, определите потенциальные зоны рисков и будьте готовы консультироваться со специалистами.

В главах 34 и 35 рассматриваются средства Firebird по управлению доступом на уровнях сервера Firebird и баз данных, соответственно. Глава 36 содержит подробности конфигурирования серверов Firebird для уменьшения незащищенности данных при некоторых рисках для безопасности, связанных с окружающей средой.

Физическая безопасность

Содержите серверы и чувствительные или критичные клиентские машины в помещениях с хорошо закрываемыми дверями. Если у вас на серверах или рабочих станциях установлена система FAT32, любой пользователь, локально подключившийся к одной такой машине, может получить доступ и ко всем другим. Если возможно, заблокируйте такие ресурсы, как CD-ROM, накопители на гибких магнитных дисках и драйверы Zip, отключите порты, через которые можно получить доступ к устройствам первоначальной загрузки или установите такие режимы в BIOS, которые предотвратят загрузку со съемных устройств. Установите в BIOS защиту по паролю, чтобы предотвратить неавторизованные изменения режимов первоначальной загрузки. Установите защиту по паролю на все серверы и рабочие станции.

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

Использование защищенных файловых систем

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

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

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

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

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

Защита оперативных копий

Регулярно выполняйте резервное копирование, упаковывайте копии, копируйте на переносимые носители и сохраняйте в защищенном месте.

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

Некоторые ложные предположения

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

* Файл копии разрушен, следовательно, он не может быть использован злоумышленником. Не думайте, что файл копии выполняющейся базы данных будет разрушен и недоступен для использования. Незаконная копия прекрасно может быть использована, особенно если деятельность по изменению данных базы данных выполняется относительно редко, или если атакующий попытается выполнить повторные копирования[130].