СРЕДА

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

Среда разработки

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

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

Лицензии Разработки

На основании лицензионных ключей из файла конфигурации progress.cfg, который размещен в инсталляционном каталоге, Progress обеспечивает три уровня доступа к базе данных:

1. Runtime: могут выполняться только предварительно откомпилированные программы (r-код).
2. Query: в данном случае могут выполняться запросы, которые не изменяют базу данных, могут быть откомпилированы на лету, но только предварительно откомпилированные программы (r-код) могут изменять данные.
3. Full Dev: пользователь может выполнять запросы, которые могут читать, изменять, создавать или удалять данные.

Относительно этих лицензий существует одно простое правило:

«Пользователи, обладающие лицензиям разработки, не должны иметь возможность обращения к промышленным данным с этими лицензиями».

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

DBAUTHKEY

Как упоминалось ранее, функция DBAUTHKEY устанавливает ограничение, которое определяет, какие программы (r-код) могут быть выполнены на тех или иных базах данных. При использовании функции DBAUTHKEY программы, откомпилированные на незащищенной тестовой базе данных, не могут быть выполнены на промышленной базе данных.

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

PROPATH

Незащищенный PROPATH является одной из самых простейших, и в то же время, самой недооцененной «брешью» в безопасности, которую я когда-либо встречал. Переменная окружения PROPATH закладывает основу, в пределах которой команды RUN находят ABL-программы, которые они пытаются выполнить. Если возможность изменения PROPATH не заблокирована, или если он содержит символ точки «.», то это позволяет хакерам вместо исходного кода программы подставлять свой собственный код, используя то же самое имя и структуру каталогов как в оригинале.

Ограничение возможностей PROPATH также препятствует другой распространенной практике – выполнению тестирования разработчиками в промышленной среде. Разработчик должен осуществить исправление, но у него нет прямой возможности воспроизвести проблему на промышленной базе. Чтобы выйти из этой ситуации, он изменяет свой личный PROPATH в промышленной среде и выполняет тестовую версию программы вместо оригинала. Типичный результат: вместо того, чтобы исправить исходную проблему, тестовая программа привела к ещё большему нарушению целостности данных.

Дополнительно. Ограничьте возможности использования каталогов и файлов, найденных в PROPATH. Эти каталоги содержат все необходимые приложению программы, которым должны быть выставлены права только на чтение для обычных пользователей, т.е. чтобы они могли их только выполнять. Если вы блокируете изменение PROPATH, но позволяете пользователю записать в один из каталогов PROPATH инородную программу, то базе данных может быть причинен наибольший ущерб, т.к. её будут использовать все пользователи.

AppServer

AppServer – это фактически ABL-клиент, который может выполнить программу от имени удаленного пользователя. Буквально можно сказать, что пользователь, подключаясь к AppServer`у, говорит: «Пожалуйста, выполни эту программу». Потенциальный хакер может положить свою программу где-нибудь на сервере, на котором работает AppServer и запросить, чтобы AppServer её выполнил. Теперь, если окажется, что у AppServer`а есть более высокий доступ безопасности, чем у пользователя (например: если AppServer запущен пользователем root), то он благополучно выполнит программу хакера от имени пользователя!

Чтобы избежать этого, необходимо ограничить возможность хакера выкладывать программы туда, где AppServer может их обнаружить. Однако мы также можем ограничить сам AppServer, используя функцию SESSION:EXPORT. Эта функция позволяет ограничить список выполняемых программ на AppServer`е.

$DLC

Для установки продуктов OpenEdge требуется учетная запись root (или administrator), но по умолчанию доступ открыт для всех ко всему содержимому инсталляционного каталога. Нет ничего проще этого для того, чтобы облегчить жизнь похитителя данных.

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

Во-вторых, во всех каталогах $DLC ограничьте возможность чтения библиотек программ, к которым нормальный пользователь во время работы не должен обращаться. Например, библиотеки программ, содержащие программы Progress Editor и Data Dictionary, не требуются обычным пользователям. Ограничьте возможность доступ к этим файлам.

Также ограничьте права доступа на выполнение инструментальных средств Progress в каталоге $DLC/bin, таких как _mprosrv (запуск базы данных), _mprshut (останов базы данных), _proutil (общая утилита базы данных) и _rfutil (утилита для работы с After-Imaging).

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

Запуск процессов сервера

Считается, что после установки Progress с использованием учетной записи root процессы сервера должны по умолчанию запускаться с помощью этой же учетной записи. Так не должно быть. Учетная запись root должна быть ограничена только выполнением процессов операционной системы. Для сервера базы данных – AdminServer`а и AppServer`ов – должны  быть созданы отдельные сервисные учетные записи. Причем это должны быть учетные записи без возможности подключения к серверу (no-login accounts.). Мы ведь не хотим создавать универсальные учетные записи, к которым у нескольких пользователей есть пароль. Вместо того чтобы запускать процессы, используя параметры доступа сервисной учетной записи, можно использовать такие инструментальные средства как «su» или «sudo».

Это особенно важно для AdminServer`а, поскольку по умолчанию он запускает дочерние элементы (AppServer, WebSpeed Transaction Server, NameServer, и т.д) с использованием той же самой учетной записи. Если установлен OpenEdge Management, то он работает в той же самой JVM^[8] что и AdminServer, тем самым предоставляя администратору OpenEdge Management полный «рутовый» доступ к серверу. То же верно для WebSpeed. Любой обратившийся к странице WebSpeed Workshop может потенциально иметь доступ к командной строке UNIX с «рутовыми» полномочиями.

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

Shell-доступ

Хотя об этом можно было и не говорить, я чувствую, что обязан заявить, что ни у одного пользователя не должно быть shell-доступа в UNIX. Пользовательский скрипт доступа должен немедленно направлять пользователя в его приложение. Для запуска приложения должна использоваться UNIX-команда «exec». Без этого нетерпеливый пользователь может нажать комбинацию клавиш во время выполнения скрипта и оказаться в командной строке.

Также рассмотрите возможность использования одной из доступных ограниченных оболочек UNIX. В большинстве случаев использование ограниченной оболочки не должно затронуть ваше приложение, но если случится, что пользователь сможет выйти в UNIX, то его возможности будут строго ограничены.

Решения

Повторюсь еще раз: область Вашей ответственности заключается в том, чтобы сделать задачу хакера наиболее трудной – установить на его пути большое количество барьеров. Кроме того, Вы не должны помогать ему, «разбрасывая вокруг» различные инструментальные средства.

• Не обновляйте базы разработчиков промышленными данными.
• Не предоставляйте пользователям полные лицензии разработки для доступа к промышленным данным.
• Используйте функцию DBAUTHKEY.
• Удалите точку («.») из PROPATH.
• Ограничьте возможность доступа к файлам и утилитам в инсталляционном каталоге OpenEdge.
• Не используйте учетную запись «root» для запуска сервера базы данных и различных фоновых процессов.
• Не предоставляйте пользователям доступ к Shell.

[8] JVM – Java Virtual Machine

1 2 3 4 5 6 7 8