В настоящее время наш веб-сервер находится в демилитаризованной зоне. Веб-сервер не может ничего видеть во внутренней сети, но внутренняя сеть может видеть веб-сервер. Насколько безопасно было бы пробить брешь в брандмауэре между DMZ и внутренней сетью только на одном веб-сервере во внутренней сети? Мы работаем над чем-то, что будет взаимодействовать с несколькими из наших приложений бэк-офиса (которые все находятся на одном сервере), и было бы намного проще выполнить этот проект, если бы мы могли напрямую связываться с сервером IBM i, содержащим эти данные ( через веб-службы).
Насколько я понимаю (и я не знаю брендов), у нас есть один межсетевой экран для DMZ с внешним IP-адресом, отличным от нашего основного IP-адреса с другим межсетевым экраном. Другой межсетевой экран находится между веб-сервером и внутренней сетью.
Так что-то вроде:
Web Server <==== Firewall ===== Intranet
| |
| |
Firewall Firewall
| |
| |
Internet IP1 Internet IP2
Нет ничего плохого в создании механизмов доступа для хостов в DMZ для доступа к хостам в защищенной сети, когда это необходимо для достижения желаемого результата. Это, возможно, не желательно, но иногда это единственный способ выполнить работу.
Ключевые моменты, которые следует учитывать:
Ограничьте доступ к самому конкретному правилу брандмауэра, которое вы можете. Если возможно, назовите определенные хосты, участвующие в правиле, вместе с конкретными протоколами (TCP и / или UDP-портами), которые будут использоваться. Как правило, открывайте только то маленькое отверстие, которое вам нужно.
Убедитесь, что вы регистрируете доступ с хоста DMZ к хосту в защищенной сети и, если возможно, анализируете эти журналы в автоматическом режиме на предмет аномалий. Вы хотите знать, когда происходит что-то необычное.
Осознайте, что вы открываете доступ к Интернету внутреннего хоста, даже если это косвенно. Будьте в курсе исправлений и обновлений для программного обеспечения, которое вы раскрываете, и самого программного обеспечения операционной системы хоста.
Рассмотрите возможность взаимной аутентификации между хостом DMZ и внутренним хостом, если это возможно с архитектурой вашего приложения. Было бы неплохо знать, что запросы, поступающие на внутренний хост, на самом деле исходят от хоста DMZ. Сможете вы это сделать или нет, будет во многом зависеть от архитектуры вашего приложения. Кроме того, имейте в виду, что тот, кто «владеет» хостом DMZ, сможет делать запросы к внутреннему хосту, даже если происходит аутентификация (поскольку они, по сути, будут хостом DMZ).
Если есть опасения по поводу DoS-атак, рассмотрите возможность использования ограничения скорости, чтобы предотвратить исчерпание хостом DMZ ресурсов внутреннего хоста.
Вы можете рассмотреть возможность использования подхода «брандмауэра» уровня 7, когда запросы от хоста DMZ передаются сначала на специальный внутренний хост, который может «дезинфицировать» запросы, проверять их работоспособность, а затем передавать их на «настоящий» серверный хост. Поскольку вы говорите о взаимодействии с вашими бэк-офисными приложениями на вашем IBM iSeries, я предполагаю, что у вас есть ограниченные возможности для выполнения проверок работоспособности для входящих запросов на самом iSeries.
Если вы подходите к этому методично и придерживаетесь здравого смысла, нет причин, по которым вы не можете делать то, что описываете, при этом сводя риск к минимуму.
Откровенно говоря, то, что у вас есть демилитаризованная зона, в которой нет неограниченного доступа к защищенной сети, значительно превосходит многие сети, которые я видел. Для некоторых людей DMZ означает просто «другой интерфейс на брандмауэре, возможно, с некоторыми другими адресами RFC 1918, и в основном неограниченный доступ к Интернету. и защищенная сеть ". Постарайтесь сохранить свою DMZ как можно более заблокированной, продолжая выполнять бизнес-цели, и у вас все получится.
Конечно, есть некоторые опасности, но вы можете это сделать. По сути, вы открываете отверстие, через которое кто-то может попасть, поэтому сделайте его крошечным. Ограничьте его только серверами на обоих концах и разрешите данные только на выбранных портах. Неплохая идея использовать трансляцию адресов портов, чтобы просто использовать причудливые порты. Тем не менее, безопасность через неизвестность - это вовсе не безопасность. Убедитесь, что у сервера на другой стороне есть какой-то способ проверить, что информация, проходящая через это соединение, действительно то, чем кажется ... или, по крайней мере, есть какой-то контекстно-зависимый брандмауэр. Кроме того, существуют определенные межсетевые экраны, предназначенные для такого рода вещей ... Я знаю, что Microsoft ISA делает то же самое для серверов OWA и Exchange.