Нет ничего плохого в создании механизмов доступа для узлов в DMZ для доступа к узлам в защищенной сети, когда это необходимо для достижения желаемого результата. Это, возможно, не является предпочтительным, но иногда это единственный способ выполнить работу.
Ключевые вещи для рассмотрения:
Ограничьте доступ к наиболее конкретному правилу брандмауэра, которое вы можете. Если возможно, назовите конкретные хосты, включенные в правило, а также конкретные протоколы (порты TCP и / или UDP), которые будут использоваться. В основном, открывайте только маленькое отверстие, как вам нужно.
Убедитесь, что вы регистрируете доступ от хоста DMZ к хосту в защищенной сети и, если возможно, анализируйте эти журналы в автоматическом режиме на наличие аномалий. Вы хотите знать, когда происходит что-то необычное.
Признайте, что вы открываете внутренний хост, даже если он косвенным образом, для Интернета. Будьте в курсе патчей и обновлений для выставляемого вами программного обеспечения и самого программного обеспечения операционной системы хоста.
Рассмотрите возможность взаимной аутентификации между узлом DMZ и внутренним узлом, если это возможно с вашей архитектурой приложения. Было бы неплохо знать, что запросы, поступающие на внутренний хост, на самом деле поступают с хоста DMZ. Можете ли вы сделать это или нет, будет сильно зависеть от архитектуры вашего приложения. Кроме того, имейте в виду, что тот, кто «владеет» узлом DMZ, сможет отправлять запросы внутреннему узлу, даже если происходит аутентификация (поскольку он, по сути, будет узлом DMZ).
Если есть опасения по поводу DoS-атак, рассмотрите возможность использования ограничения скорости для предотвращения исчерпания ресурсов внутреннего хоста DMZ-ресурсами.
Возможно, вы захотите использовать подход «межсетевого экрана» уровня 7, где запросы от узла DMZ сначала передаются внутреннему узлу специального назначения, который может «очистить» запросы, проверить их работоспособность, а затем передать их «реальный» внутренний хост. Поскольку вы говорите о взаимодействии с вашими приложениями для бэк-офиса на вашем IBM iSeries, я предполагаю, что у вас ограниченные возможности для проверки работоспособности по входящим запросам на самом iSeries.
Если вы подходите к этому методично и придерживаетесь здравого смысла, нет никаких причин, по которым вы не можете делать то, что описываете, в то же время сохраняя минимизированный риск.
Честно говоря, если у вас есть демилитаризованная зона, которая не имеет беспрепятственного доступа к защищенной сети, вы прыгаете за пределы многих сетей, которые я видел. Похоже, что для некоторых людей DMZ просто означает «еще один интерфейс на брандмауэре, возможно, с некоторыми другими адресами RFC 1918, и в основном беспрепятственный доступ к Интернету и защищенной сети». Старайтесь держать свою DMZ как можно более закрытой, но при этом достигать бизнес-целей, и у вас все будет хорошо.