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

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

Цель данной статьи – показать, что вопрос безопасности требует комплексного взгляда на инфраструктуру организации в целом. Написана на основе реального опыта поддержки веб-решений 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
Подписаться

Комментарии

Спасибо за отличный пост, Михаил!

Мне кажется, стоит добавить в виде примечания, что находящийся в DMZ обратный прокси желательно оснастить средствами защиты, анализирующими трафик, такими, как web application firewall или даже системы анализа вторжений. Иначе, на мой взгляд, описанная конфигурация (с использованием обратного прокси) не лишена изъянов.

1) Сам по себе сервер reverse proxy, предположительно, не помешает злоумышленнику пытаться использовать некоторую часть уязвимостей IIS и NOMAD, ведь он (прокси) как бы "прозрачен" для таких атак.

2) Если злоумышленник скомпрометировал сервер reverse proxy, то задача последующей компрометации сервера NOMAD превращается почти в ту же самую задачу, которая стояла бы перед ним в случае, когда никакого обратного прокси нет (с некоторыми оговорками).

3) Если злоумышленнику все-таки удастся взломать NOMAD, то взломанный сервер NOMAD, находящийся внутри intranet-сети, потенциально будет более полезен в качестве плацдарма для атак на другие серверы компании, чем взломанный NOMAD, стоящий в DMZ. Этот минус можно компенсировать, если сделать еще один барьер, т.е. поместить NOMAD в еще одну DMZ, отделенную от интрасети.

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