«Защита без раскрытия»: с какими рисками и ограничениями может столкнуться бизнес

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

Для того, чтобы эффективно работать с облачным провайдером, компании рекомендуется передать закрытую часть ключа своего SSL-сертификата на облачную платформу. Это распространенная практика во всем мире: ведущие игроки глобального рынка облачных решений — Akamai и Cloudflare — используют именно такой подход. А они в свое время сформировали отраслевые стандарты для публичных облаков.

Но существуют организации, которые по ряду причин не могут дать провайдеру возможность расшифровать свой HTTPS-трафик. В таком случае компания может попросить провайдера предоставить доступ к ресурсам без раскрытия SSL-сертификата. Однако важно понимать, что у этой практики есть свои недостатки, которые снижают эффективность защитных механизмов на стороне провайдера, а это может повлечь за собой дополнительные риски для организации.

В этой статье поговорим:

➡️ что такое «защита без раскрытия» и почему компания не может передать свой SSL-сертификат;
➡️ какие ограничения и риски существуют, если не раскрывать HTTPS-трафик;
➡️ какие подходы могут быть неэффективны;
➡️ что может предложить провайдер тем, кто не хочет передавать закрытую часть ключа SSL-сертификата;
➡️ почему стоит доверить свой сертификат провайдеру.

Почему компания не может передать SSL-сертификат провайдеру

Для установки безопасного канала связи в протоколе SSL/TLS используютcя алгоритмы шифрования. Чаще всего — асимметричное шифрование, которое считается более надежным из-за применения двух отдельных ключей: открытого (public key) для шифрования сообщения и закрытого (private key) для расшифровки сообщения.

Обычно, когда компания начинает сотрудничать с облачным провайдером, она передает закрытую часть ключа своего SSL-сертификата, чтобы провайдер мог «видеть» и анализировать HTTPS-трафик. Это нужно для обеспечения эффективной защиты веб-приложения.

«Защита без раскрытия» — это подход к защите ресурса, при котором закрытая часть ключа SSL-сертификата не передается облачному провайдеру, и он не расшифровывает трафик внутри своей платформы.

Часто такой подход приходится выбирать организации, в которой:

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

Так работают многие организации из государственного, финансового и медицинского сектора.

Бывает и так, что у компании нет жестких требований со стороны регулятора, однако она не стремится передавать SSL-сертификат провайдеру. У этого может быть несколько причин. Кто-то желает минимизировать организационные сложности, риски и согласования, кто-то — хочет соответствовать правилам «бумажной безопасности», другие верят, что эффективно защищать веб-приложение можно и без передачи SSL-сертификатов.

Ограничения и риски

Выбирая модель защиты без раскрытия, компания должна понимать возможные последствия. Например:

Перегрузка инфраструктуры клиента
Когда модуль защиты установлен на стороне клиента (для сбора логов и телеметрии), он сам становится «бутылочным горлышком». Массовая атака на сервер может перегрузить его до такой степени, что он не сможет отправить логи в центр очистки. Это создаёт замкнутый круг: сервер не обрабатывает запросы, а провайдер не обеспечивает защиту.

Сложность интеграции
Модули требуют строгой настройки и соответствия формату логов. Если формат логов будет изменяться со временем или данные будут передаваться с задержками, это усложнит работу центра очистки.

Отсутствие эшелонированной защиты
Часть механизмов защиты становится недоступна для отражения ИБ-сервисами провайдера. Например, если WAF развернут в облаке провайдера, он не сможет функционировать без раскрытия сертификата: вся его суть в глубоком анализе каждого запроса. То есть, нелегитимные запросы, которые можно было заблокировать, используя инфраструктуру и сервисы провайдера, будут обработаны на стороне заказчика и могут значительно повысить нагрузку на его оригинальную инфраструктуру. Таким образом, построить эшелонированную защиту серверов оригинации заказчика не получится.

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

Практики, которые не всегда эффективны

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

Вариант 1. Установка агента в защищённом контуре.
Агент собирает телеметрию (метрики и данные о запросах) и передаёт её в центр очистки провайдера.

Минус подхода:
➡️ Если агент установлен на сервере заказчика, он может не справиться с огромным количеством метрик при массовой DDoS-атаке. Это приведёт к потере защиты: агент перестанет отправлять данные, а центр очистки не сможет эффективно отреагировать.

Вариант 2. Использование фингерпринтов трафика.
Провайдеры составляют реестр отпечатков стандартных атак (например, ботнетов или вредоносных инструментов). Этот реестр используется для анализа зашифрованного трафика без его расшифровки.

Минусы подхода:
➡️ Несвоевременное обновление фингерпринтов.
➡️ Ограниченное количество типов отпечатков, которые можно использовать без раскрытия

Что может предложить провайдер, если нельзя расшифровывать HTTPS-трафик

Использовать аттестованные облачные платформы
Распространенная практика за рубежом, где просто не существует такого подхода, как «защита без раскрытия». Облака получают сертификацию и предоставляют заказчикам необходимые документы, где подтверждено, что провайдер соответствует всем требованиям регуляторов о безопасности информации. Например, Cloudflare соответствует требованиям PCI DSS 4.0, GDPR, DORA и NIS2, а Akamai поддерживает соответствие нормативным требованиям PCI DSS, DORA и таким стандартам, как SWIFT и ISO 20022.

Пересмотреть имеющиеся практики
И все же, если к компании не применяются регуляторные требования (PCI DSS, ГОСТ Р 57580, ФСТЭК 21 (152 ФЗ), то лучшим решением будет не сомневаться и передать сертификат SSL провайдеру.

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

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

Почему стоит доверить свой сертификат провайдеру:

➡️ Полная видимость трафика и точное выявление атак. Когда провайдер получает расшифрованные данные, он может анализировать реальные угрозы, а не их косвенные признаки. Это особенно важно в эпоху сложных атак, которые не всегда можно обнаружить по метрикам.

➡️ Эффективная защита от DDoS- и бот-атак. Раскрытие сертификатов позволяет провайдеру быстрее и точнее блокировать вредоносные нелегитимные запросы, не перегружая инфраструктуру клиента.

➡️ Своевременность. Новые виды и типы атак митигируются сразу, а не после атаки, как происходит в случае с фингерпринтами.

➡️ Соответствие международным практикам. Крупнейшие мировые компании работают по этой модели, потому что доверяют своим провайдерам и понимают, что только полный доступ к трафику дает надежную защиту.

🧑‍💻 Узнать больше о защите можно в других наших статьях:

«Бот-атака ≠ DDoS-атака: что такое паразитный бот-трафик и почему умные боты опасны», где мы рассказали, что такое бот-атака и умные боты; чем бот-атаки отличаются от DDoS-атак; почему умные боты опасны для сайта; кто в зоне риска и как именно паразитный бот-трафик вредит сайту.

«Сайт упал: почему DDoS-атаки опасны для вашего бизнеса», где мы рассказали, что такое DDoS-атаки и при чем тут боты; какие последствия DDoS-атак могут быть; какие известные компании сталкивались с масштабными DDoS-атаками.

«Защита от взлома: как WAF помогает защитить сайт», где мы рассказали, откуда появляются уязвимости; чем опасны атаки на веб-приложения; что такое WAF и зачем он нужен; как устроен WAF и какие угрозы предотвращает.