Безопасность OpenEdge-приложений

ФАЙЛОВАЯ СИСТЕМА

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

У обычных пользователей не должно быть доступа для записи в любой из файлов или каталогов, содержащих инсталляцию OpenEdge, а также не должно быть возможности изменения кодов программ или файлов базы данных непосредственно. Например, только у пользователя root должен быть доступ для записи в каталог $DLC с возможным исключением каталога $DLC/properties, т.е. изменять файлы настроек в этом каталоге можно позволить и другим специальным пользователям. Точно так же нужно разрешить запись кодов программ в каталоги лишь группе пользователей, внедряющих приложение.

Бит SetUID

Часто недооценивается атрибут setuid-бит (только для UNIX), который позволяет пользователю выполнить программу с уровнем безопасности владельца программы. В случае с OpenEdge клиентская исполняемая программа _progres принадлежит пользователю root, поэтому все ABL-пользователи инициализируют свои сессии от имени этого пользователя. Однако как только процесс инициализации закончен, программа _progres автоматически понизит свой уровень безопасности до уровня пользователя, который её запустил.

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

Защита базы данных

По крайней мере, все файлы базы данных и каталоги должны принадлежать одной обслуживающей учетной записи (напр.: prodba), и только этой учетной записи нужно разрешить чтение и запись в эти каталоги и файлы. Как объяснялось выше, у пользователей, которые подключаются к базе данных при запуске, не возникнет никаких проблем связанных с подключением к разделяемой памяти. Но пользователи, которые попытаются подключиться к базе данных после запуска сессии, столкнутся с ошибкой прав доступа и будут вынуждены выполнить подключение через клиент-сервер.

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

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

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

Решения

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