Как защитить и проверить исходящий трафик в корпоративной среде?

Далее следует скучный фон для предисловия к следующему вопросу: какова наилучшая отраслевая практика (или какие рекомендации вы бы дали) для защиты исходящего трафика в корпоративной среде?

Фон

У нас довольно типичная корпоративная среда: Linux и Windows размещаются на не маршрутизируемых IPv4-адресах за брандмауэром / маршрутизатором / прокси. Помимо прочего, эти хосты запускают наши серверы приложений и баз данных для основного сервиса нашей компании, который мы разрабатываем собственными силами. Серверы баз данных были заблокированы довольно широко. Их адреса не маршрутизируются (даже с NAT/PAT) из внутренней сети.

С другой стороны, серверам приложений и серверам, которые создают и подготавливают приложения, требуется некоторая связь с внешним миром. Эти хосты должны получить доступ к интернет-ресурсам по разным причинам:

• интегрировать с государственными или частными службами,
• вытащить библиотеки из репозиториев с открытым исходным кодом,
• загрузить обновления платформы,
• получить ресурсы для специального устранения неисправностей,
• передавать статистику в партнерские системы мониторинга,
• возможно, другое использование еще не определено.

Часто эти интернет-ресурсы могут быть идентифицированы по имени хоста или имени домена, но не часто на них можно ссылаться просто по IP-адресу назначения. Ресурсом может быть определенное подмножество ресурса, например приложение в домене (graph.facebook.com) или путь на хосте (google.com/a/company). Мы хотели бы иметь возможность идентифицировать ресурс настолько конкретно, насколько это возможно, чтобы избежать чрезмерной разрешительности.

Наша цель - поддерживать безопасную сеть. В частности, мы хотим:

• предотвратить или ограничить удаление данных умным злоумышленником, получившим несанкционированный доступ к системе,
• мониторинг и учет активности, исходящей из сети.

Наше внимание сосредоточено на трафике, исходящем изнутри сети и заканчивающемся вне нашей безопасной среды. Кроме того, мы стремимся максимально ограничить разрешения, указав источник на основе класса хоста и адресата на основе ресурсов, которые требуются классу хоста.

Что бы мы в конечном итоге не использовали, мы хотели бы механизировать процесс предоставления доступа как часть процесса подготовки хоста. Другое требование состоит в том, что разработка приложений должна быть минимально затронута; решение должно выглядеть как простая сеть TCP/IP для авторизованной связи.

Для этого у нас есть несколько предложений, некоторые из которых мы попробовали, а некоторые из них мы можем оценить:

DMZ Firewall

Брандмауэр располагается в демилитаризованной зоне и направляет трафик (сетевой уровень) на основе белого списка допустимых хостов назначения. Он определяет белый список IP-адресов. Брандмауэр просто отбрасывает трафик, который не соответствует соответствующему правилу.

преимущества

• Приложения могут быть написаны естественно, без учета сети.
• Поддерживает транспорты, отличные от HTTP/HTTPS.

Ограничения

• Низкая степень детализации - IP-имя или адрес могут обслуживать многие приложения и почти всегда обслуживать несколько путей на этом хосте.
• Иногда можно разрешить имя хоста в список IP-адресов с использованием DNS и механически обновить этот список, но обновления не происходят в режиме реального времени.
• Отклоненный трафик неотличим от неисправной сети. Сбои могут занимать много времени, занимая 15-60 секунд (или дольше), чтобы устранить их как неудачные.
• Механизация брандмауэра нежелательна из-за возможного злоупотребления / сбоя.

HTTP прокси-сервер

Прокси-сервер, как и брандмауэр, находится в демилитаризованной зоне с возможностью подключения к внутренней и внешней сети. Весь исходящий трафик должен проходить через прокси-сервер, который содержит белый список авторизованных ресурсов по URL или частичному URL. Это позволяет только трафик, который соответствует указанному ресурсу в белом списке. Прокси-сервер работает на уровне протокола HTTP/HTTPS.

преимущества

• Надежное определение разрешенных направлений.
• С небольшой конфигурацией хоста, естественно работает для многих приложений.
• Отклоненный трафик обычно можно быстро идентифицировать.

Ограничения (некоторые относятся конкретно к нашему устройству Stingray)

• Приложения должны знать о прокси-сервере и направлять трафик на него.
• Некоторым библиотекам для правильной работы в этой среде требуется специальное хранение (или даже исправление ошибок). Зачастую сложно заранее определить, какие библиотеки будут затронуты.
• Правила не могут легко различаться в зависимости от исходного класса хоста.
• Сложно механизировать.
• Работает только для HTTP/HTTPS.
• Сетевая среда прокси-сервера может отличаться от сетевой среды хоста, что приводит к трудным для диагностики ситуациям. Например, хост приложения может разрешить имя хоста, но прокси не может, поэтому прокси-сервер возвращает ответ 404, который трудно отличить от ответа 404 от намеченного ресурса.
• Прокси-сервер не может проверять зашифрованный трафик и, следовательно, не может фильтровать зашифрованный трафик лучше, чем брандмауэр.

Усовершенствованное устройство защиты периметра

В настоящее время мы рассматриваем такое устройство, как Palo Alto Enterprise Perimiter. Это устройство, как и другие, будет фильтровать трафик. Это устройство будет проводить глубокий контроль передачи на уровне приложения. Он может проверять заголовки HTTP и соответственно управлять трафиком. Он может даже перехватывать и расшифровывать защищенные пакеты (SSL).

преимущества

• Это коммерчески поддерживаемый, многофункциональный подход.
• Глубокая проверка пакетов предоставляет множество деталей для применения детальных разрешений.
• Приложения, общающиеся в виде простого текста, не должны знать об устройстве.

Ограничения

• Для нас это новая инвестиция и еще одно устройство для изучения / настройки / управления.
• Если проверка SSL включена, это нарушает цепочку доверия. Приложения, правильно настроенные на высокий уровень безопасности, будут блокироваться или давать сбой, поэтому должны учитывать специализированную среду.
• Это неизвестное количество. Неясно, будут ли у него интерфейсы, которые позволили бы механизации, которую мы желаем.
• Новые капитальные затраты.

Вопрос

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