Далее следует пространная предыстория, предваряющая следующий вопрос: каковы лучшие отраслевые практики (или какие рекомендации вы бы дали) для защиты исходящего трафика в корпоративной среде?
У нас довольно типичная корпоративная среда: хосты Linux и Windows на немаршрутизируемых IPv4-адресах за брандмауэром / маршрутизатором / прокси. Среди прочего, эти хосты запускают наши серверы приложений и баз данных для основной службы нашей компании, которую мы разрабатываем собственными силами. Серверы баз данных были довольно сильно заблокированы. Их адреса не маршрутизируются (даже с NAT / PAT) из внутренней сети.
С другой стороны, серверы приложений и серверы, которые создают и готовят приложения, требуют некоторого подключения к внешнему миру. Этим хостам необходим доступ к Интернет-ресурсам по разным причинам:
Часто эти Интернет-ресурсы можно идентифицировать по имени хоста или имени домена, но не часто на них можно ссылаться просто по IP-адресу назначения. Ресурс может быть определенным подмножеством ресурса, например приложением в домене (graph.facebook.com) или путем на хосте (google.com/a/company). Мы хотели бы иметь возможность идентифицировать ресурс как можно более конкретно, чтобы избежать чрезмерной снисходительности.
Наша цель - поддерживать безопасную сеть. В частности, мы хотим:
Наше внимание уделяется трафику, исходящему из сети и завершающемуся за пределами нашей безопасной среды. Кроме того, мы стремимся максимально ограничить права доступа, указывая источник на основе класса хоста, а место назначения - на основе ресурсов, которые требуются классу хоста.
Что бы мы ни использовали в конечном итоге, мы хотели бы механизировать процесс предоставления доступа как часть процесса инициализации хоста. Еще одно требование - минимальное влияние на разработку приложений; решение должно быть максимально похоже на простую сеть TCP / IP для авторизованной связи.
С этой целью у нас есть несколько предложений, некоторые из которых мы попробовали, а некоторые мы можем оценить:
Брандмауэр находится в демилитаризованной зоне и направляет трафик (сетевой уровень) на основе белого списка допустимых конечных узлов. Он определяет белый список IP-адресов. Брандмауэр просто отбрасывает трафик, не соответствующий соответствующему правилу.
Преимущества
Ограничения
Прокси-сервер, как и брандмауэр, находится в DMZ с возможностью подключения как к внутренней, так и к внешней сети. Весь исходящий трафик должен проходить через прокси-сервер, который содержит белый список авторизованных ресурсов по URL-адресу или частичному URL-адресу. Он разрешает только трафик, который соответствует указанному ресурсу в белом списке. Прокси-сервер работает на уровне протокола HTTP / HTTPS.
Преимущества
Ограничения (некоторые относятся конкретно к нашему прибору Stingray)
В настоящее время мы рассматриваем такое устройство, как Palo Alto Enterprise Perimiter. Это устройство, как и другие, будет фильтровать трафик. Это устройство будет проводить глубокую проверку передачи на уровне приложений. Он может проверять заголовки HTTP и соответствующим образом управлять трафиком. Он даже может перехватывать и расшифровывать защищенные пакеты (SSL).
Преимущества
Ограничения
Каковы лучшие отраслевые практики (или какие рекомендации вы бы дали) для защиты исходящего трафика в корпоративной среде? Исходя из приведенных выше деталей, является ли наша позиция слишком агрессивной (или слишком снисходительной)? Мы собираемся инвестировать в одно из этих решений (или, может быть, в другое), разрабатывая инструменты для механизации наших процессов, поэтому мы будем очень благодарны за любые продуманные советы по выбору наилучшего подхода.
Хороший пост. Что является агрессивным, а что нет, вообще сложно сказать - решать вам. Все три хороши, но имеют разные подходы, проблемы с удобством использования, цену и т. Д.
Я работаю в компании, которая ежегодно проходит сертификацию безопасности VISA / Mastercard (PCI), и все зависит от того, чем вы занимаетесь и какие риски у вас могут возникнуть. Нет компании без риска, он может быть минимальным / несущественным для вас, но риски есть всегда. Возможно, вам достаточно иметь http-прокси, и вы не боитесь парней, которые могут использовать http-туннель или использовать удаленные приложения на основе http и т.д. (например, Skype, Teamviewer), и у вас нет контроля над управлением приложениями, не у меня нет сертификата 802.1x на основе аутентификации на уровне Ethernet с машиной, которая имеет двухдисковое шифрование, которому требуется специальный ключ USB для каждой загрузки, несмотря на то, что этот ключ USB взят из одного из 20 стальных сейфов толщиной 10 дюймов, открытых двумя разделенными паролями изменен 6 часов назад, известен двумя парнями, доставленными двумя специалистами по безопасности с двумя охранниками и четырьмя дистанционно управляемыми камерами и всем, что находится под землей, глубиной 300 метров. Что применимо / достаточно для вас - опять же, решать вам.
Если ваши сотрудники являются экспертами по безопасности и плохими парнями, умеющими использовать несколько инструментов и прятаться от камер - нет возможности контролировать их, наблюдая за их трафиком и пакетами - они все равно могут прятаться и проложить туннель где угодно, вам следует рассмотреть другие вещи тоже (я полагаю, Palo Alto Enterprise Perimiter может это сделать, если он вам так нужен и вы заплатите за этот 1 миллион долларов США).
Все ваши предложения в порядке - нет ничего плохого в том, чтобы использовать их на предприятии.
Рекомендую взглянуть и на продукты оповещения SIEM (Solarwinds SIEM, Trustwave SIEM, IBM Q1 Labs Qradar). Может быть, вы хотите понаблюдать за ситуацией, а не ограничивать ее в деталях и т. Д.