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

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

Я ищу возможности (и их плюсы и минусы) для защиты сетевого трафика компонентов критичного ко времени приложения в центре обработки данных. Целью является минимизация ущерба, который может нанести злоумышленник, если ему удастся скомпрометировать VM. Должно быть невозможно прочитать трафик между другими (не скомпрометированными) VM. Этого можно достичь с помощью шифрования или ограничения доступа к сети.

У нас есть среда VMware, несколько хостов ESXi и брандмауэр Fortigate. Часть внутреннего трафика пока не зашифрована, поскольку приложение открывает несколько соединений, одно за другим. И есть ограничение по задержке для всего процесса.

Из-за ограничения задержки (тривиальное) использование TLS для каждого соединения не является вариантом. Возможно, это можно сделать с помощью прокси-серверов во всех системах, которые поддерживают соединения TLS открытыми независимо от того, что делает приложение.

Я думаю, что использование VPN между всеми задействованными системами (около 50) было бы кошмаром для управления. Мы используем keepalived, что, вероятно, делает решение VPN еще хуже.

Я также думаю об использовании постоянных записей ARP в качестве защиты от подмены ARP. VMware предотвращает подмену MAC-адресов. Это не добавит задержек и должно исключить необходимость шифрования. Но это не работает хорошо с Fortigate и также не работает с виртуальными IP-адресами.

Мне интересны мнения об упомянутых подходах, а также о других подходах, о которых я пока не знаю.

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

решение1

Похоже, вы ищете то, что сейчас называется «микросегментацией» как часть архитектуры с нулевым доверием.

По сути, при традиционной сегментации (брандмауэр и vLAN) вы ограничиваете коммуникации между подсетями — вы не позволяете кому-либо общаться с кем-либо, если он не соответствует заданным критериям. При микросегментации вы ограничиваете трафик и/или проверяете его между приложениями/службами, которые находятся в одной подсети. Это проще всего сделать на уровне гипервизора, поскольку гипервизор может изначально видеть весь трафик, проходящий к/от его гостей.

А нулевое доверие относится к старой поговорке о безопасности «не доверяй никому», даже своим собственным системам. Вы расширяете минимальный уровень доверия, по сути, операционный эквивалент «необходимо знать» для информации. Серверы приложений могут общаться с внешним миром только в ответ на запросы TLS, ничего другого не разрешено — и т. д. Вы ограничиваете доверие явными требованиями к операциям, не допуская ничего большего.

В качестве примера можно использовать микросегментацию, чтобы сказать, что Front-End-App-Server-A может общаться с Mid-Tier-Logic-Server-A, который, в свою очередь, может общаться с Database-Server-A. Но Front-End-Server не может напрямую общаться с сервером БД. А Front-End-A не может общаться с Front-End-B, даже если они находятся в одной подсети.

VMware в последнее время делает довольно много шума по поводу использования микросегментации на своей платформе. Похоже, вам стоит это проверить:https://www.vmware.com/solutions/micro-segmentation.html

Это обходит ограничения времени создания сеанса для шифрования. Плюс это делает то, что шифрование не может. (VPN или SSL/TLS защищают данные при передаче, но фактически не ограничивают вред, который злоумышленник может нанести, оказавшись в «защищенной» сети. Сегментация с ограниченным доверием ограничивает возможные следующие шаги злоумышленников — по сути, им приходится обходить новый брандмауэр каждый раз, когда они пытаются перейти на новый вектор.) И все это делается на уровне гипервизора/сети; это означает, что вам не нужно переписывать свои приложения, чтобы использовать его. Настройте его на уровне инфраструктуры и позвольте своим приложениям продолжать делать то, что они делают.

решение2

В принципе VPN будет иметь такое же влияние на производительность, как и TLS. Поэтому вам нужно более дешевое решение с точки зрения задержки.

  1. Вы можете использовать брандмауэр ESXi. (По сути, технология VMware близка к Linux, и возможна фильтрация L2 и L3 на мостах и ​​других компонентах виртуальной сети).

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

  3. Вы можете использовать настройку VLAN, но, по моему скромному мнению, это немного переоцененная стратегия.

Связанный контент