Я пытаюсь настроить как обычно, с DMZ, содержащей серверы, к которым можно получить доступ из Интернета, и LAN, которая должна быть как можно более безопасной.
У меня также есть полная свобода в архитектуре. Учитывая, что я хочу сделать свою зону LAN как можно более безопасной, я подумал: «Что может быть лучше, чем отсутствие доступа к LAN из DMZ». Для этого я бы настроил брандмауэр так, чтобы он блокировал любое входящее соединение в направлении DMZ-> LAN.
Конечно, мне все еще нужно, чтобы мои интерфейсные приложения находились в DMZ для связи с доверенными серверами LAN. Чтобы сделать это возможным, я думал о том, чтобы разрешить устанавливать соединения только в направлении LAN-> DMZ.
Это означает, что в отличие от обычной ситуации, именно мои доверенные службы локальной сети будут подключаться к ненадежным интерфейсным серверам DMZ. После установления TCP-соединения все запросы и ответы между двумя конечными точками будут мультиплексированы в этом соединении.
Это хорошая идея с точки зрения безопасности? Могу ли я сделать что-нибудь еще, чтобы сделать доступ к моим серверам локальной сети еще сложнее? Вы слышали о том, чтобы кто-то еще таким образом защищал свою локальную сеть? Что-то ускользает от меня, что делает эту идею глупой?
Как и на все вопросы, связанные с безопасностью, ответ - «в зависимости от обстоятельств». Это зависит от типа вашей компании, типа предоставляемых вами услуг, степени защиты ваших интернет-сервисов, данных, которые вы храните, какого законодательства вы должны соблюдать и т. Д. И т. Д.
Краткий ответ - минимизируйте «поверхность атаки», ограничив адреса / порты между вашей DMZ и доверенной сетью. Если возможно, разверните технологии, использующие тип обратного прокси, чтобы инициирование диалога из DMZ-> Trust было невозможно. Конечно, это не всегда возможно. Подумайте о наличии промежуточной зоны с брандмауэром, содержащей базы данных «только для Интернета». Наконец, убедитесь, что вы также ограничили порты / адреса из Trust-> DMZ. Многие вредоносные программы используют соединения в стиле обратного прокси (но в противоположном направлении), то есть они полагаются на входящее соединение для выхода в исходную сеть.
Проблема с такого рода вопросами в том, что вы получите разные ответы практически от всех, и ваша задача - выбрать то, что лучше для вас. Дополнительная безопасность неизбежно делает повседневные операции более неудобными, а чрезмерно сложные конфигурации безопасности нередко приводят к ошибкам конфигурации, оставляя дыры, которые остаются незамеченными.
Безопасность - это все уровни защиты, и ни одно решение, что бы вам ни говорили, не защищено на 100%. Что бы вы ни решили сделать, подумайте о том, чтобы проверить его на ручку перед запуском, и убедитесь, что службы DMZ исправлены. Наконец, проверяйте свою конфигурацию не реже одного раза в год.
Хорошо, сведение к минимуму соединений между DMZ и LAN - хорошее практическое правило, хотя я бы не стал подчиняться этой идее (если у вас есть локальные почтовые серверы, ваша почтовая служба будет интересна, мягко говоря, если вы заставите это следовать вашей идее).
Кроме того, не думайте, что это волшебная защита от взлома. Если кто-то взломает сервер в DMZ, то он все еще может проникнуть в вашу сеть в зависимости от того, как настроены серверы в DMZ (например, наличие открытых соединений на стороне LAN между базой данных SQL на стороне LAN и DMZ- Сторонний веб-сервер мало что может вам помочь, если веб-сервер был рутирован, а учетные данные для доступа к серверу SQL хранятся на сервере DMZ.
Кроме того, если информация то, что вы используете / храните, ценно само по себе, и его все еще может украсть кто-то, кто внедрил сервер в DMZ, и то, что вы предлагаете, не сильно поможет.
Что ж, вы уже в значительной степени перечислили одну из проблем с этой настройкой, это только TCP. Не только это, но и сеанс можно относительно легко подделать из демилитаризованной зоны. Идеальное идеальное решение для меня звучит так: относиться к доверенной локальной сети как к обычному пользователю, отправлять их из вашей сети и обратно.