Обзор публичного облака NGENIX: единого решения для защиты и ускорения сайтов и приложений

1. 1. Введение
2. 2. Функциональные возможности «Публичного облака NGENIX»
   1. 2.1. Роли и права пользователей
   2. 2.2. Уровни настроек
      1. 2.2.1. Настройки уровня аккаунта
      2. 2.2.2. Настройки уровня сервисной конфигурации
   3. 2.3. Возможности аналитики
   4. 2.4. Защита от киберугроз
      1. 2.4.1. Защита от DDoS-атак
      2. 2.4.2. Защита от ботов
      3. 2.4.3. Облачный WAF
   5. 2.5. Авторитативный DNS
      1. 2.5.1. Управление доменными зонами в клиентском портале
   6. 2.6. Другие возможности
      1. 2.6.1. Поддержка SSL / TLS
      2. 2.6.2. Оптимизация изображений
      3. 2.6.3. CDN
      4. 2.6.4. Мониторинг доступности
      5. 2.6.5. Работа с лог-файлами
3. 3. Подключение, лицензирование и техподдержка «Публичного облака NGENIX»
4. 4. Выводы

Введение

Публичные веб-ресурсы в последние несколько лет регулярно становятся целью кибератак, интенсивность которых растёт. Среди наблюдаемых сценариев выделяются DDoS-атаки, характеризующиеся высокой мощностью и влияющие на доступность сервисов. При использовании публичных облачных инфраструктур это накладывает дополнительное требование: одновременно обеспечивать защиту от перегрузок и сохранять стабильно высокую скорость работы веб-сайтов и приложений.

«Публичное облако NGENIX» закрывает описанные риски. В его основе — распределённая облачная платформа с 50+ фильтрующими узлами в 23 точках присутствия в России и ближнем зарубежье и более 1000 провайдеров в прямом доступе. Облако обеспечивает комплексную защиту, ускорение и доступность сайтов, приложений и API в режиме «единого окна» через единый пользовательский интерфейс. Платформа митигирует атаки до 7 Тбит/с и 5 млн RPS.

«Публичное облако NGENIX» включено в Единый реестр российского ПО (№ 20947 от 29.12.2023), имеет сертификат ГОСТ Р ИСО/МЭК 27001-2021. Вендору выдана лицензия на оказание услуг связи (Л030-00114-77/00670812 от 17.08.2023).

Функциональные возможности «Публичного облака NGENIX»

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

• защита от DDoS (Distributed Denial of Service);
• защита от ботов;
• облачный WAF (Web Application Firewall);
• авторитативный DNS (Domain Name System);
• CDN (Content Delivery Network);
• управление SSL / TLS (Secure Sockets Layer / Transport Layer Security);
• управление доступом;
• распределённый мониторинг доступности;
• оптимизация изображений;
• стриминг видео.

Управление ими доступно через единый веб-интерфейс клиентского портала NGENIX Multidesk. Учётная запись (УЗ) для первого входа формируется силами технической поддержки вендора во время бесплатного тестирования. При входе в клиентский портал необходимо пройти двухфакторную аутентификацию.

Роли и права пользователей

В клиентском портале реализована гибкая система разграничения прав доступа с 2 ролями: «Администратор» и «Оператор».

У администратора — полный и неизменяемый набор прав доступа. Он может управлять УЗ других пользователей, за исключением УЗ с признаком «Владелец аккаунта» (обычно это представитель заказчика, указанный в договоре).

Администратор определяет и настраивает права доступа для операторов в соответствии с их рабочими обязанностями.

Рисунок 1. Страница профиля пользователя в NGENIX Multidesk

Права доступа могут быть предоставлены в режиме «Просмотр» и «Редактирование».

Рисунок 2. Редактор изменения прав доступа для пользователя

Гранулярное разделение прав необходимо, чтобы возможности платформы были доступны пользователям с различными компетенциями и зонами ответственности. Например, администратор может предоставить право на управление DNS-записями сотрудникам, отвечающим за доступность ресурса. При этом другие специалисты (например, системные администраторы) не будут иметь доступа к критически важному компоненту, но смогут пользоваться другими функциями.

Также в NGENIX Multidesk реализованы технические УЗ (роботы), которые используются для настройки интеграций со сторонними системами. Их технические API-токены позволяют более гибко разграничивать доступ к объектам и сервисам платформы.

Рисунок 3. Список технических учётных записей (роботов)

Рисунок 4. Страница управления профилем робота

Уровни настроек

Логика клиентского портала устроена так, что пользователь может переключаться между настройками 2 уровней: аккаунта и сервисной конфигурации.

Настройки уровня аккаунта

Находясь в меню «Аккаунт», пользователь может управлять следующими настройками:

• Аналитика. Данные и отчёты о потреблении ресурсов платформы всеми сервисными конфигурациями.
• DNS. Настройки DNS-зоны и управление DNS-записями.
• Источники данных. Настройка источников, данные из которых будут проксироваться через платформу. В качестве источников могут выступать группа серверов оригинации, объектное хранилище на платформе и облачный WAF.
• Обработка запросов. Редактор для создания правил обработки запросов (до 40 правил в наборе правил). С помощью этой настройки можно управлять логикой обработки запросов: блокировать, пропускать и перенаправлять запросы по определённым признакам, а также добавлять и удалять заголовки в зависимости от критериев запроса.
• Облачный WAF. Управление настройками WAF, развёрнутого на платформе (через личный кабинет вендора).
• Проверка доступности. Настройка правил проверки доступности веб-ресурса на стороне пользователя из различных операторских сетей.
• Списки. Управление списками (IP-адресов, стран и т. п.) на платформе.
• Шаблоны ответов. Создание, кастомизация и управление страницами-заглушками, выдаваемыми в ответ на запрос (например, «Ваш запрос был заблокирован»).
• Лог-файлы. Настройка работы с лог-файлами (хранение, удаление, выбор полей).
• Уведомления. Настройка email-уведомлений о DDoS-атаках и истечении срока действия SSL-сертификата.
• Прямые подключения. Список актуальных прямых подключений между серверами оригинации и серверами платформы.

Рисунок 5. Меню уровня аккаунта в NGENIX Multidesk

Настройки уровня сервисной конфигурации

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

Виды сервисных конфигураций:

• Проксирование / кэширование содержимого веб-ресурса (для сайтов).
• Рестриминг сегментированных потоков (HLS, DASH и т. п.) (для видеосервисов).
• HTTP-стриминг потоков, опубликованных по RTMP/RTSP (для видеосервисов).
• HTTP-стриминг MP4-файлов (для видеосервисов).

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

Для управления объектами уровня отдельной сервисной конфигурации предусмотрено одноимённое меню. Вид бокового меню может отличаться в зависимости от типа архитектуры сервисной конфигурации, в нашем случае — это «Проксирование / кэширование содержимого веб-ресурса».

Рисунок 6. Меню уровня сервисной конфигурации в NGENIX Multidesk

Аналитика. Отчёты и графики о трафике на сервисной конфигурации.

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

Кэширование. Настройки кэширования (на стороне платформы и пользователя).

SSL/TLS. Возможность выписать или загрузить SSL-сертификат.

Оптимизация изображений. Настройка политик преобразования изображений (при наличии соответствующего сервиса в составе услуги).

Защита. Настройка сервисов киберзащиты.

Стриминг логов. Настройка передачи логов в сторонние системы в режиме реального времени.

Возможности аналитики

Пользователю доступно более 30 типов отчётов об общей работе платформы и её отдельных функциях. Многие из них представляют картину в реальном времени с отставанием всего в 1 минуту, что важно для своевременного распознавания DDoS-атаки или резкого возрастания легитимной нагрузки. Некоторые отчёты доступны только при условии подключения отдельного сервиса.

Каждый вид статистики и аналитики имеет свою страницу (в меню уровня аккаунта и уровня конфигурации).

Отчёты. Табличные отчёты за прошедшие периоды с основными статистическими показателями (сводный, биллинговый, по конфигурациям, по портам и т. п.).

Рисунок 7. Страница статистических отчётов

Мониторинг. Статистика в режиме реального времени на уровне аккаунта и уровне конфигурации для оперативного отслеживания состояния используемых сервисов и веб-ресурсов.

Рисунок 8. График мониторинга нагрузки на сервисную конфигурацию

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

Рисунок 9. Тепловая карта распределения веб-запросов по странам

Рисунок 10. Диаграмма распределения веб-запросов по семействам браузеров

Профиль IP-адреса. Сервис для поиска информации об обработанных запросах, отправленных с определённого IP-адреса.

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

Бот-аналитика. Статистика распределения запросов по бот-категориям, которая может быть использована для настройки правил управления бот-трафиком.

Защита от киберугроз

NGENIX предоставляет возможность построить эшелонированную защиту от кибератак. Это комплексный подход к обеспечению веб-безопасности, при котором система защиты разделена на несколько уровней (эшелонов). На каждом эшелоне работают разные средства защиты. Чем больше эшелонов, тем выше уровень защищённости веб-ресурса.

Рисунок 11. Схема эшелонированной защиты NGENIX

Защита от DDoS-атак

NGENIX защищает от DDoS-атак на уровне сети (L3 / L4) и приложений (L7). Вендор предоставляет облачные сервисы на базе мощной геораспределённой инфраструктуры, которая способна демпфировать крупные атаки на границе сети. Трафик фильтруется на каждом узле и не перенаправляется в центры очистки. Это позволяет сохранить высокую скорость загрузки веб-страниц даже во время мощных атак и обеспечить пользователям стабильный доступ к сайту без задержек и сбоев.

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

Защита от DDoS в «Публичном облаке NGENIX» устроена следующим образом:

1. Система защиты от DDoS уровня сети анализирует трафик и блокирует масштабные DDoS-атаки на инфраструктуру NGENIX и всех пользователей платформы.
2. Система анализа трафика выявляет источники DDoS-атак на уровне L7 на основе анализа параметров запросов, репутации источников и других характеристик.
3. Система обработки запросов проверяет все запросы по 30+ метрикам: пропускает легитимные, блокирует или отправляет на проверку подозрительные.
4. Списки подозрительных и заблокированных IP-адресов можно просматривать в NGENIX Multidesk или через API.
5. Для более гибкой защиты можно настроить дополнительные правила блокировки на основе бизнес-логики веб-ресурса.
6. Чтобы избежать атак в обход платформы, можно организовать прямое подключение между серверами обработки запросов и веб-сервером.

Рисунок 12. Схема защиты от DDoS

Базовая настройка защиты от DDoS-атак. Защита на уровне L3 автоматически активируется при подключении к платформе NGENIX. Защита на уровне L7 подключается дополнительно и настраивается в клиентском портале NGENIX Multidesk. Есть 3 режима работы защиты от DDoS на уровне L7: «Обучение», «Мониторинг», «Блокировка».

Режим «Обучение» нужен для первичного анализа трафика и формирования эталонных метрик поведения пользователей. Его включают инженеры NGENIX на время обучения системы (до 7 дней). После обучения они переводят систему защиты в режим «Блокировка», во время которого митигируются атаки.

Рисунок 13. Как переключить режим работы системы защиты от DDoS NGENIX

Пользователь может перевести защиту в режим «Мониторинг», который нужен для отслеживания аномалий трафика и проверки настроек в период нестабильной нагрузки. Например, во время технических работ на веб-инфраструктуре, когда изменяется профиль трафика веб-ресурса. В этом режиме DDoS-атаки не блокируются.

Пока система находится в режиме «Обучение», пользователю необходимо создать и наполнить «белый список» IP-адресов. IP-адреса из «белого списка» никогда не блокируются при отражении DDoS-атак. Например, туда можно добавить IP-адреса технических специалистов. После этого следует выбрать нужный «белый список» на странице «Защита от DDoS-атак на L7».

Рисунок 14. Использование белых списков в настройке системы защиты от DDoS

Теперь, когда система зафиксирует DDoS-атаку на уровне L7, она сначала проверит, есть ли источники подозрительных запросов (IP-адреса) в «белом списке». Если они там есть, система пропустит их, если нет — отправит наиболее агрессивные источники в «чёрный список» и заблокирует атаку на уровне L7. Менее агрессивные источники отправляются на дополнительную проверку в «список валидации». Если проверка не пройдена, источники блокируются. Эти блокировки — автоматические, а списки — нередактируемые.

Рисунок 15. Настройка блокировки по чёрным спискам

Однако пользователь может быстро очистить «Чёрный список» и «Список валидации». Например, если нужно оперативно снять действующие блокировки.

Рисунок 16. Очистка чёрных списков и списка валидации

Имеется возможность кастомизации «шаблона ответа» — страницы, которая появляется при блокировке запроса. На неё можно добавить фирменные цвета и логотип компании, указать email и телефон поддержки, а также расписать понятный план действий для легитимных пользователей, которых заблокировали по ошибке.

Рисунок 17. Кастомизация шаблона ответа при блокировке запроса в NGENIX Multidesk

Рисунок 18. Базовая кастомизация шаблона ответа при блокировке

Базовые возможности защиты также включают уведомление о начале атаки. Достаточно включить отправку уведомлений и добавить нужные email-адреса в разделе «Уведомления». При обнаружении DDoS-атаки система начнёт отражать атаку и отправит на указанные email-адреса уведомление.

Рисунок 19. Страница настройки уведомлений о DDoS-атаках в NGENIX Multidesk

Продвинутая защита от DDoS-атак. Для более эффективной защиты пользователь может настроить дополнительные правила митигации DDoS-атак на основе бизнес-логики веб-ресурса.

Например, пользователь может настроить блокировку запросов по геолокации, методам запросов и другим параметрам (их более 25).

Рисунок 20. Настройка набора правил обработки запросов

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

Рисунок 21. Редактор правил обработки запросов в NGENIX Multidesk

Для правил митигации (при блокировке запроса с действием deny) можно настроить «шаблон ответа» в форматах HTML или JSON.

Настроенный «шаблон ответа» доступен в настройке выбранного заранее правила.

Рисунок 22. Выбор шаблона при создании правила обработки запроса

Статистика и аналитика защиты от DDoS-атак. В разделе «Мониторинг» на странице «Блокировка» можно просматривать детальную статистику по атакам и блокировкам за конкретный период времени.

Рисунок 23. График заблокированных запросов в NGENIX Multidesk

Доступен просмотр подробной статистики о DDoS-атаках на L7 за определённый период: время начала и окончания атаки, длительность атаки в минутах, мощность атаки в RPS.

Рисунок 24. Отчёт о зафиксированных DDoS-атаках

Узнать больше о заблокированных запросах за последние 24 часа и самостоятельно выявить причины блокировки позволяет «Анализатор запросов».

Рисунок 25. «Анализатор запросов»

Защита от ботов

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

Доля ложноположительных срабатываний — низкая: жёсткие меры валидации применяются только к запросам, которые с высокой вероятностью принадлежат ботам. Возможно блокировать ботов без ухудшения пользовательского опыта, если кастомизировать «шаблоны ответов» платформы на запросы, о чём мы писали выше.

Защита от ботов происходит следующим образом:

1. Система анализирует и классифицирует весь трафик. Запросы, классифицированные как DDoS-атака, митигируются в сервисе защиты от DDoS-атак. Оставшийся трафик классифицируется по бот-категориям.
2. Пользователь может посмотреть распределение трафика по категориям и настроить правила обработки запросов для управления автоматизированным трафиком.
3. В правилах обработки запросов можно разрешить пропуск запросов от публичных ботов, заблокировать запросы от вредоносных, а подозрительные — отправить на активную проверку.
4. Проверка подозрительного запроса может включать интерактивные задания (CAPTCHA), анализ параметров браузера, сверку отпечатков и другие механизмы. Запрос, не прошедший проверку, блокируется.
5. Данные об источнике запроса, полученные в ходе активной проверки, сохраняются и в дальнейшем учитываются системой при классификации трафика, в том числе у других заказчиков.
6. Для улучшения качества классификации трафика сбор первичных данных об источнике запроса может быть выполнен с помощью JS-скрипта, размещённого заказчиком на веб-странице.

Рисунок 26. Схема защиты от ботов в NGENIX

Настройка защиты. В клиентском портале в разделе «Бот-аналитика» пользователь может посмотреть, сколько ботов в трафике и какие они. Есть 4 категории ботов: «Публичный бот», «Точно бот», «Вероятно бот» и «Вероятно человек». Они объединены в стекированный график, на котором отображается весь трафик, за исключением запросов, заблокированных системой защиты от DDoS-атак на уровне L7. Пользователь может выбрать нужный период и оценить процентное соотношение бот-категорий.

Рисунок 27. График распределения запросов по бот-категориям в NGENIX Multidesk

Основываясь на этих данных, можно настроить оптимальный способ митигации для каждой бот-категории в разделе «Обработка запросов».

Рисунок 28. Список наборов правил обработки запросов для отражения бот-атак

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

Рисунок 29. Создание правила обработки запросов для различных бот-категорий

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

Рисунок 30. Настройка правила для пропуска легитимных ботов

В категорию «Точно бот» попадают очевидно вредоносные запросы. Для таких запросов нужно включить автоматическую блокировку.

Рисунок 31. Блокировка ботов в NGENIX Multidesk

Категория «Вероятно бот» состоит из нежелательных ботов. Однако иногда в неё могут попадать и легитимные пользователи, чьи действия похожи на действия ботов. Такие подозрительные запросы нужно отправлять на проверку. Есть 3 типа проверки: Compute, CSS и CAPTCHA.

Рисунок 32. Направление подозрительных запросов на дополнительную проверку

Для проверок можно кастомизировать страницу самой проверки и «Шаблона ответа» (страницу блокировки), если проверка не была пройдена.

Рисунок 33. Страница проверки запроса

Рисунок 34. Страница проверки запроса — CAPTCHA

После настройки правил нужно определить порядок их применения. Сначала — пропускать полезных ботов, а затем проверять, блокировать или пропускать остальные запросы.

Пользователь может настраивать защиту от ботов самостоятельно или делегировать настройку клиентскому сервису NGENIX в рамках пакета обслуживания и поддержки «Управляемый антибот».

Облачный WAF

NGENIX позволяет защищать веб-ресурсы от взломов и эксплуатации уязвимостей с помощью облачного WAF, который интегрирован в эшелонированную систему защиты. DDoS-атаки и боты блокируются до серверов WAF.

Производительность кластера WAF увеличивается автоматически при пиковых нагрузках или росте аудитории.

Предоставляются 2 вендора ПО WAF на выбор.

WAF работает следующим образом:

1. Система защиты от DDoS-атак уровня сети анализирует весь трафик и блокирует масштабные DDoS-атаки на инфраструктуру NGENIX, обеспечивая защиту на уровне L3 / L4 для всех пользователей платформы на любом тарифном плане.
2. Система анализа трафика выявляет и блокирует DDoS-атаки на уровне L7 на основе анализа параметров запросов, репутации источников, характеристик трафика и TLS-соединений.
3. Пользователь услуги в NGENIX Multidesk или через API может настроить дополнительные правила обработки запросов для блокировки запросов по их параметрам и управления бот-трафиком.
4. Кэширование позволяет обрабатывать заметную часть запросов до того, как они достигнут ПО WAF. Это позволяет более эффективно использовать вычислительные ресурсы ПО WAF.
5. ПО WAF функционирует на опорных узлах платформы и обрабатывает отфильтрованный от DDoS-атак и вредоносных ботов трафик к некешируемым данным. ПО WAF регулярно синхронизируется с облаком вендора WAF для применения актуальных настроек и обновления сигнатур.
6. Управление защитой от DDoS-атак, кэшированием, правилами обработки запросов и настройками интеграции ПО WAF осуществляется через NGENIX Multidesk или API. Управление политиками ПО WAF выполняется в веб-интерфейсе ПО WAF.

Рисунок 35. Схема устройства облачного WAF от NGENIX

Пользователь может работать с ПО WAF самостоятельно или делегировать это клиентскому сервису NGENIX в рамках пакета обслуживания и поддержки «Управляемый WAF».

Авторитативный DNS

NGENIX предоставляет отказоустойчивый DNS, защищённый от DDoS-атак. Распределённая сеть DNS-серверов обрабатывает до 100+ млн QPS. Отказ отдельных серверов или узлов сети не влияет на производительность DNS.

DNSSEC позволяет проверять подлинность ответов от DNS-серверов и предотвращает такие атаки, как подмена DNS-записей или кэширование вредоносной информации.

Управлять доменной зоной можно через API, веб-редактор или Terraform: добавлять, изменять, удалять DNS-записи, а также восстанавливать доменные зоны из архивных версий — в клиентском портале NGENIX Multidesk.

Работа DNS реализована следующим образом:

1. Пользователь услуги делегирует доменную зону DNS-серверам NGENIX и управляет её содержимым через удобный веб-редактор DNS в NGENIX Multidesk, NGENIX API или Terraform.
2. Платформа анализирует весь входящий трафик на предмет наличия признаков DDoS-атак и блокирует вредоносные запросы.
3. Распределённая сеть высокопроизводительных DNS-серверов обрабатывает запросы на ближайших к источникам узлах платформы, что снижает задержку при доступе к данным и обеспечивает большой запас производительности во время DDoS-атак.
4. Если для запрашиваемого веб-пользователем доменного имени определены статические ресурсные записи, то веб-пользователь получит в ответ их значения с round-robin-балансировкой (простейший алгоритм распределения нагрузки, при котором запросы от пользователей по очереди направляются на разные серверы). Если для доменного имени определена динамическая ресурсная запись платформы, веб-пользователь будет направлен на оптимальный с точки зрения сетевой топологии, состояния и загруженности сервер обработки запросов.

Рисунок 36. Схема устройства авторитативного DNS NGENIX

Управление доменными зонами в клиентском портале

Список всех доменных зон, которыми можно управлять, находится на странице «DNS».

Рисунок 37. Список доменных зон в NGENIX Multidesk

В клиентском портале NGENIX Multidesk можно настроить права доступа для каждого пользователя в зависимости от его задач. Пользователь может только просматривать доменные зоны или полноценно управлять ими.

Пользователи с правом «Редактирование» могут создавать и редактировать доменные зоны.

Рисунок 38. Редактор доменной зоны в NGENIX Multidesk

Помимо этого можно отслеживать историю изменения доменных зон.

Рисунок 39. Страница с историей изменений доменной зоны с комментариями

Также в клиентском портале есть архивирование доменных зон: при необходимости можно вернуться к любой версии в архиве.

Другие возможности

Через клиентский портал NGENIX Multidesk можно управлять другими полезными функциями, которые важны для работы сайта или приложения.

Поддержка SSL / TLS

SSL/TLS-сертификат нужен для организации безопасного зашифрованного подключения между пользователем и веб-сервером. Для этого можно либо подключить wildcard-сертификат платформы, либо загрузить SSL/TLS-сертификат на платформу. Во втором случае возможны следующие сценарии:

1. Загрузка собственного сертификата. Этот вариант подойдёт, если пользователь хочет использовать собственное доменное имя в ссылках к данным.
2. Выпуск сертификата Let’s Encrypt. В этом случае на платформе настраивается автоматический выпуск сертификата Let’s Encrypt, он будет обновляться каждые 2 месяца. Этот вариант подходит пользователям, которым не хочется самостоятельно заниматься регулярным обновлением сертификата.
3. Загрузка самоподписанного сертификата. Пользователь может выпустить сертификат самостоятельно, что требуется крайне редко. Например, если необходимо реализовать безопасный канал для обмена информацией между сервером и клиентами и при этом не требуется обеспечивать проверку подлинности владельца.

Рисунок 40. Загрузка / выпуск собственного SSL-сертификата на платформу NGENIX

Поддерживаются различные алгоритмы шифрования и криптографические стандарты: RSA, ECDSA, ГОСТ 34.10.

Оптимизация изображений

Функция оптимизации изображений позволяет на лету изменять параметры изображений на веб-странице. Например, конвертировать их в формат WebP, задавать необходимые размеры (длину, ширину), применять размытие. Это улучшает пользовательский опыт и ускоряет доставку изображений на устройства.

Применение политик преобразования изображений для сервисной конфигурации настраивается на странице «Оптимизация изображений».

Управлять политиками преобразования можно на странице «Обработка запросов» в разделе «Политики преобразования изображений».

Рисунок 41. Список политик преобразования изображений

CDN

NGENIX предоставляет CDN для доставки статического и динамического контента.

Для сервисных конфигураций с типом архитектуры «Проксирование / кэширование содержимого веб-ресурса» пользователь может управлять настройками кэширования. Например, отслеживать на графике эффективность кэширования, контролировать срок кэширования данных через HTTP-заголовки или настройки в UI портала, быстро очищать кэш и т. д.

Рисунок 42. Настройки кэширования данных

Рисунок 43. Очистка кеша сервисной конфигурации

Для доставки видео потребуется создание конфигураций с архитектурой «Рестриминг сегментированных потоков», «HTTP-стриминг потоков, опубликованных по RTMP/RTSP», «HTTP-стриминг MP4-файлов».

Мониторинг доступности

В клиентском портале NGENIX также реализована возможность проводить активные проверки доступности веб-ресурсов через сервис распределённого мониторинга. Пользователь настраивает правила мониторинга на странице «Проверка доступности» и устанавливает длительность окна наблюдения.

После активации правила проверки доступности каждый из более чем 30 серверов распределённого мониторинга раз в минуту отправляет запросы к заданному веб-ресурсу. Если доля успешных проверок (когда на запрос возвращается установленный в правиле код ответа) превышает 70 % случаев, веб-ресурс считается доступным. Это более объективный способ оценки доступности, чем синтетические пробники, так как он основан на «живых» пользовательских данных. Данные о доступности веб-ресурса можно выгружать в формате метрик Prometheus.

Рисунок 44. Редактор правила проверки доступности

Работа с лог-файлами

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

Поддерживаются форматы лог-файлов: *.log (по умолчанию), *.json и *.tsv. Набор данных в логах варьируется: есть «стандартный» с минимальным набором полей, а есть «настраиваемый», где можно выбрать более 20 полей.

Рисунок 45. Расширенный набор полей в лог-файле

Чтобы получить доступ к логам, можно включить выгрузку лог-файлов на серверы хранения по протоколу S3 и задать срок их хранения. Раз в час они будут выгружаться на серверы хранения. Другой способ — получать сырые логи серверов доставки в режиме реального времени по протоколу Syslog. Максимальный срок хранения составляет 1 год.

Подключение, лицензирование и техподдержка «Публичного облака NGENIX»

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

NGENIX заявляет SLA от 99,4 до 99,95 % — в зависимости от базового пакета обслуживания и поддержки.

Поддержка NGENIX доступна в режиме 24/7 по различным каналам коммуникации: через веб-интерфейс тикет-системы, мессенджеры, email, телефон, бота. Это зависит от того, какой базовый пакет обслуживания и поддержки подключён у конкретного пользователя. Предусмотрена возможность самостоятельного обращения к публичной пользовательской документации и публичной странице состояния инфраструктуры. Всё это можно найти в Центре поддержки.

Выводы

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

Решение подходит как для небольших веб-ресурсов, так и для крупных высоконагруженных приложений.

Достоинства:

• обширный набор функций по принципу «всё в одном»;
• управление описанными возможностями в режиме единого окна;
• широкий набор отчётов и статистики (более 30);
• гибкая эшелонированная защита от кибератак, доступная в том числе и на младших тарифах;
• длительный срок хранения логов;
• гибкая система управления правами доступа к функциям платформы;
• крупная геораспределённая инфраструктура;
• нативно встроенный CDN.

Недостатки:

• отсутствие freemium-модели (от англ. free — «бесплатный», и premium — «премиум»; бизнес-модель монетизации, при которой компания предоставляет базовую версию продукта или услуги бесплатно, а за расширенную функциональность, дополнительные возможности или улучшенные условия использования взимает плату);
• доступность только для юридических лиц;
• отсутствие возможности самостоятельно создать учётную запись — требуется вовлечение технической поддержки.