Мне интересно, сколько из вас, кто работает в КРУПНЫХ компаниях, имеют сетевую архитектуру, которая требует использования трех отдельных брандмауэров для доступа к данным. Другими словами: * Разделение внешних (Интернет) сторон и уровня представления брандмауэром * Разделение уровня представления и уровня приложений брандмауэром * Разделение уровня приложений и данных брандмауэром
Вкратце: Public-> Presentation-> Application-> Data (где каждая стрелка - это брандмауэр)
Вот моя проблема: я работаю в очень большой американской компании (более 75 тысяч сотрудников), где каждая среда, похоже, имеет разное количество межсетевых экранов сегментации. Мы хотели стандартизировать нашу архитектуру брандмауэра, но: 1) Мы не можем найти никаких реальных материалов, чтобы оправдать потребность в трех межсетевых экранах (в отличие, скажем, от брандмауэра с одним периметром) 2) Мы не можем определить ценность - добавить три уровня межсетевых экранов. 3) Мы не можем разобраться, должна ли это быть архитектура только для приложений с выходом в Интернет или для ВСЕХ приложений / устройств / оборудования.
Любой совет?
То, что вы ищете, оправдание архитектуры с тремя брандмауэрами, звучит как часть фантастического мира, который не будет хорошо отображаться в реальности. Если вы не контролируете все приложения, суровая реальность такова, что большинство поставщиков приложений предполагают нефильтрованный и неограниченный доступ между программными компонентами от каждого уровня к смежному уровню (и, возможно, к несмежному уровню тоже).
Я проделал некоторую работу в средах, где использовалась "безопасность", предписываемая администрацией, посредством брандмауэра серверных компьютеров вдали от локальной сети и сведения к минимуму количества открытых служб. Это было проблемой каждый раз, когда появлялось новое программное обеспечение, оборудование или поставщик, потому что все «традиционные» предположения о беспрепятственном сквозном соединении в локальной сети оказывались на слух. Реализация что-нибудь в итоге в такой среде стоил дороже.
Моя стратегия и рекомендации по ограничению общения и воздействия в локальной сети заключаются в следующем:
Используйте списки контроля доступа / правила брандмауэра на внутренних маршрутизаторах / брандмауэрах, чтобы «рисовать широкой кистью» и исключать типы трафика, которые явно нежелательны (доступ к подсети / VLAN, к которой подключены IP-камеры безопасности из любого места, кроме VLAN, в которой установлены серверы агрегирования видео, доступ в Интернет из подсети, где установлены только внутренние серверные компьютеры и т. Д.).
Применяйте более конкретные правила контроля доступа с помощью программного обеспечения брандмауэра, запущенного на самих различных серверных компьютерах (брандмауэр Windows, iptables). Убедитесь, что на серверах установлено и запущено только необходимое программное обеспечение, и что только нужные службы / демоны прослушивают сетевой трафик только на требуемых интерфейсах. Здесь главенствуют здравые подходы к управлению изменениями, безопасности паролей / единого входа и обновлению операционных систем и приложений.
Брандмауэры позволяют количественно оценивать и определять потоки трафика. Так называемые межсетевые экраны «уровня 7» суют свой нос в трафик прикладного уровня (и даже тогда, на некотором произвольном уровне глубины этого трафика) и могут применять даже более специализированные правила арбитража, чем «традиционные» межсетевые экраны. Брандмауэры, однако, не «обеспечивают безопасность», а эффективны лишь настолько, насколько эффективны люди, разрабатывающие наборы правил или контролирующие журналы. Неизменно, чем более жестко ограничены правила изначально, тем больше компромиссов в конечном итоге делается для обеспечения работы приложений.
Лично я сомневаюсь в усилиях по добавлению брандмауэров для «повышения безопасности». Я вижу увеличение затрат на обслуживание для всех приложений в сети без какой-либо гарантии количественного улучшения устойчивости среды к атакам или снижения профиля риска.
Речь идет об ограничении ущерба, который могут нанести вещи. Правила вашего брандмауэра редко предотвращают атаку сразу, но если что-то действительно скомпрометировано, они должны предотвратить слишком большой ущерб (поскольку любой конкретный ящик должен иметь доступ только к списку служб, которые вы его проверили. потребности доступ к). Кроме того, они дают вам возможность всегда знать, какой трафик находится в вашей сети.
Однако стандартизация настроек брандмауэра может быть глупой. Вам не нужно одинаковое количество брандмауэров на всех сайтах, и архитектура брандмауэра на каждом сайте должна быть компромиссом между простотой развертывания новых услуг и безопасностью. Если ваша среда постоянно меняется или вас не волнует, что разрешено делать сотрудникам, обширная защита брандмауэра будет слишком сложной задачей и принесет очень мало пользы. Если вы хотите ограничить свободу своих сотрудников, то это стоит сделать, установив брандмауэры между Интернетом, службами, доступными из Интернета, и вашей локальной сетью (возможно, LAN). Если одна локальная сеть имеет дело с конфиденциальными данными, вы, вероятно, захотите, чтобы она находилась в отдельном брандмауэре. подсеть, если возможно.).
По сути, цель брандмауэра должна заключаться в том, чтобы разрешать только тот трафик, который, как вы знаете, вам нужен, между серверами, которые, как вы знаете, должны общаться друг с другом. Это не означает, что у вас обязательно должно быть несколько брандмауэров, хотя они могут быть полезны (в конечном итоге у вас заканчиваются порты на одном брандмауэре). Это означает, что у вас должны быть вещи, требующие доступа к аналогичным уровням доверия и к аналогичным системам. Если вы собираетесь использовать несколько уровней брандмауэра, стоит обратить внимание на использование гетерогенных систем (например, контрольных точек для ваших веб-серверов, с ASA между веб-серверами и серверами баз данных).
Мы запускаем 1 даже за пределами DMZ, просто потому, что, черт возьми, почему бы и нет? DMZ должна быть открыта, но глупо допускать неограниченное воздействие.
Затем мы запускаем один между DMZ и серверами, которым мы разрешаем связываться с DMZ. Все, что мы разрешаем для подключения к Интернету, подключается через прокси в DMZ; это быстрое отключение в случае атаки и машина, которая может быть взломана без ущерба для самого сервера.
Затем, наконец, мы запускаем брандмауэр между всем, что подключается к нашей внутренней сети, поэтому, если что-то скомпрометировано в DMZ, это не может распространиться внутри.
Есть исключение: корпоративная глобальная сеть находится на том же уровне, что и внутренние серверы, поэтому эксплойт в глобальной сети находится всего в 1 брандмауэре от внутренних систем, хотя у них такая же структура брандмауэра, что и у нас, поэтому есть еще 2 брандмауэры между внешним миром на этом векторе.
В том смысле, о котором вы говорите (по отношению к конкретному приложению, которому разрешен внешний доступ), у нас будет внешний брандмауэр, прокси, брандмауэр, сервер приложений и затем сервер базы данных, находящийся на том же уровне. Точку брандмауэра (кроме обычных внутренних брандмауэров) между сервером базы данных и сервером приложений сложно понять: требуется доступ между ними, и существует достаточный доступ для взлома независимо от вашего брандмауэра.
Я думаю, что стандартизация САЙТОВ - это глупо, но вы должны быть стандартизированы в отношении открытых приложений / серверов. Вы не хотите оставлять это на усмотрение местных жителей: кто-то БУДЕТ принимать плохое решение. Например, в наших вспомогательных офисах есть только 1 брандмауэр, а затем VPN для обычной сети, но им нечего защищать, тогда как наши финансовые системы доступны только локально.