Шесть главных вопросов при выборе решения для защиты SSL
This post is also available in:
Английский 
Французский 
Немецкий 
Итальянский 
Португальский, Бразилия 
Испанский
В настоящее время показатель зашифрованного трафика достигает 99% от общего интернет-трафика. Государственные и корпоративные стандарты безопасности (GDPR) обязывают компании использовать протокол HTTPS, что подразумевает шифрование данных. Хотя использование зашифрованного трафика важно для обеспечения безопасности и конфиденциальности данных пользователей, это открывает двери для нового поколения агрессивных DDoS-атак, которые могут потребовать в 15 раз больше ресурсов сервера, чем запрашивающий хост.
Проблематичной частью становится обнаружение угроз внутри зашифрованного трафика — как искать иголку в стоге сена. Это выигрышный метод атак, так как для идентификации вредоносного трафика требуются большие вычислительные мощности, в результате существенно повышается нагрузка на сеть и инфраструктуру приложений.
Безусловно, не существует универсального решения для защиты SSL. У каждой компании есть свои приоритеты, потребности бизнеса, категории конфиденциальности и требования к защите персональных данных. Тем не менее есть несколько наводящих вопросов, которые помогут выбрать оптимальное решение для защиты SSL для вашей организации.
1. Есть ли у вас доступ к сертификату SSL?
У некоторых компаний такого доступа нет. Причины могут быть разными: нормативные ограничения, требования конфиденциальности, архитектура сети и системы безопасности, делегирование защиты (модель Security as-a-Service, SaaS). Может не быть доступа к сертификату конечного пользователя у компаний, которые пользуются услугами управления ИБ или проверки трафика.
Другие компании, у которых есть доступ к сертификату SSL, имеют возможность расшифровывать и получать видимость трафика SSL.
2. Если есть доступ к сертификату, где следует расшифровывать трафик?
Простого доступа к сертификату недостаточно. Нужно учитывать топологию сети и уровень безопасности.
В одних топологиях сети расшифровка SSL трафика выполняется ближе к серверам, а в других системах предпочтительно расшифровывать трафик и исключать угрозы на более ранних этапах. В первом варианте обеспечение безопасности основывается на решениях для защиты приложений. В этом случае следует учитывать дополнительные риски, такие как DDoS-атаки, которые лучше не пускать далеко по сети.
3. Если есть доступ к сертификату, когда следует расшифровывать трафик?
Постоянная расшифровка всего SSL трафика обеспечивает полную видимость, но требует много ресурсов и приводит к задержкам. В некоторых случаях дополнительная задержка недопустима, что исключает вариант постоянной расшифровки всех соединений. Хорошее решение должно позволять расшифровывать лишь некоторые соединения в определенных условиях, а в иных случаях не трогать их вообще. Важно правильно выбирать, какой трафик расшифровывать, сохраняя баланс между безопасностью SSL, временем задержки и качеством работы пользователей.
[Возможно, вам будет интересно: Обнаружение и предотвращение HTTP-флуда… без ключей расшифровки]
4. Если есть доступ к сертификату, какие части SSL-соединений следует расшифровывать?
Нужно выбрать не только момент расшифровки, но и ее уровень. Расшифровка не всего SSL-соединения, а лишь его части имеет большое значение при защите от определенных атак. Как и в предыдущем пункте, правильный выбор глубины расшифровки помогает найти баланс между уровнем безопасности и оптимальным качеством работы пользователей.
5. Насколько ваши сервисы чувствительны к задержкам?
Расшифровка всего SSL-трафика обеспечивает полную видимость, но чрезмерно потребляет ресурсы и увеличивает задержки. Для некоторых компаний и сервисов дополнительное увеличение задержки из-за расшифровки SSL недопустимо. Им нужно решение, которое позволит обойтись без расшифровки или будет расшифровывать только часть соединений при определенных условиях.
6. Используются ли сети доставки контента (CDN)?
Сеть доставки контента (CDN) передает трафик от имени компании. В этом случае настоящий IP-адрес можно найти только в зашифрованных заголовках HTTP, то есть невозможно определить реальных клиентов, не расшифровывая весь трафик SSL. При использовании сервисов CDN решение безопасности должно расшифровывать соединения SSL полностью, определять реальных клиентов в заголовках HTTP и применять направленные меры безопасности.
Основные выводы
Согласно отчету Radware о DDoS-атаках за второй квартал 2021 года объем зашифрованных веб-атак составил 20% всех инцидентов кибербезопасности за период. Совершенно ясно, что традиционные решения не могут обеспечить требуемую защиту. Сетевые решения, например Netflow, не видят SSL-трафик, оставляя сеть незащищенной перед зашифрованными атаками.
Сеть доставки контента (CDN) передает трафик от имени компании. Настоящий IP-адрес можно найти только в зашифрованных заголовках HTTP, то есть невозможно определить реальных клиентов, не расшифровывая весь трафик SSL.
Другим решениям требуется полная расшифровка пакетов HTTPS, что нарушает конфиденциальность пользователей, приводит к задержкам и усложняет процесс управления ключами.
