Почему не стоит выносить NOMAD в демилитаризованную зону (DMZ)

Опубликовано:
12 марта в 09:44
  • 0

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

Описанное ниже применимо ко всем веб-сервисам DIRECTUM: веб-доступ, NOMAD, УПЭ, сервисы интеграции. Все эти продукты периодически выносят за периметр сети организации с целью обеспечить безопасность внутренней сети организации. Но обеспечивает ли данное решение должный уровень безопасности?

Что же такое демилитаризованная зона (DMZ)?

Можно воспользоваться информацией, которую предоставляет русскоязычный Wiki:

Нам важны две фразы:

Цель ДМЗ — добавить дополнительный уровень безопасности в локальной сети, позволяющий минимизировать ущерб в случае атаки на один из общедоступных сервисов: внешний злоумышленник имеет прямой доступ только к оборудованию в ДМЗ.

и

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

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

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

Что такое NOMAD?

С одной стороны, это сервис, предоставляющий веб-API для взаимодействия мобильных приложений с системой, который должен быть опубликован в Internet.

С другой, он сам является пользователем системы DIRECTUM и локальных ресурсов предприятия. А это значит, у него должен быть доступ к следующим ресурсам:

  • SQL – для получения данных системы;
  • Сервисами DIRECTUM (сервер сеансов, служба Workflow и т.д. )
  • Cлужба файловых хранилищ, SMB – для работы с документами;
  • доменным сервисам: AD, DNS, LDAP и NetBIOS.

Могут добавиться и дополнительные ресурсы, которые требуются в прикладных вычислениях.

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

Что будет, если разместим NOMAD в DMZ?

Чтобы заставить работать NOMAD в DMZ, потребуется открыть порты для взаимодействия с сервисами, описанными выше. Тем самым образуется все больше связей между DMZ и сетью предприятия.

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

Тем самым мы нарушили основной принцип DMZ - изолирование внутренней сети. Злоумышленник, попав на машину в DMZ, получает доступ к SQL, AD, smb и т.д. - а это практически вся внутренняя сеть предприятия.

В конечном счёте, безопасность такого развертывания сравнима с безопасностью публикации порта напрямую из сети предприятия. Более того, тем самым, мы резко снизили безопасность существующей DMZ в организации.

Если нельзя размещать NOMAD в DMZ, то как же тогда быть?

Об этом уже было рассказано на нашем ресурсе: Безопасность: Настройка демилитаризованной зоны

Все достаточно просто:

  • NOMAD, как локальный ресурс, размещается внутри сети предприятия;
  • Для публикации в интернет используем посредника, в виде Reverese-прокси, который и размещаем в DMZ.

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

Это особенность сервисов DIRECTUM?

Нет, аналогичным примером может служить почтовый сервис Exchange (https://blogs.technet.microsoft.com/exchange/2013/02/18/exchange-firewalls-and-support-oh-my/), либо другой сервис/веб приложение который активно взаимодействует с внутренними ресурсами предприятия.

В заключение

Вот так благая задача может стать серьёзной угрозой безопасности для организации.

Желаю вам безопасной и продуктивной работы.

 

42
Подписаться

Комментарии

Пока комментариев нет
Авторизуйтесь, чтобы написать комментарий