Унификация защиты на стороне клиента в платформе Akamai Application Protection Platform

• Настраивайте правила для браузера там же, где и все остальное
• Контролируйте доступ скриптов
• Расследуйте нарушения там же, где и расследуете угрозы
• Видимость клиентских скриптов и современные ИИ-приложения
• Единая модель политик для всей поверхности атаки приложения

Основные выводы

Сторонний JavaScript выполняется вне средств контроля серверного WAF, что делает приложения уязвимыми к сбору клиентских данных и внедрению скриптов.

Платформа Akamai Application Protection Platform теперь объединяет правила для браузера и серверные политики защиты веб-приложений и API (WAAP) в единой консоли управления.

Телеметрия клиентских угроз поступает напрямую в Web Security Analytics (WSA) для упрощенного расследования инцидентов на разных уровнях.

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

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

Мы это изменили.

Настраивайте правила для браузера там же, где и все остальное

Платформа Akamai Application Protection Platform теперь включает в себя встроенную клиентскую защиту. Команды безопасности могут создавать правила для клиентской стороны прямо внутри политик безопасности защиты приложений: там же, где они настраивают правила WAF, средства защиты от ботов и защиты API.

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

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

Контролируйте доступ скриптов

Браузер предоставляет JavaScript доступ к важным элементам: полям конфиденциальных форм, сетевым адресам назначения, файлам cookie, локальному хранилищу и хранилищу сеансов. Неправильно настроенный или скомпрометированный скрипт может получить доступ к любому из них.

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

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

Расследуйте нарушения там же, где и расследуете угрозы

При срабатывании правила клиентской стороны нарушение отображается в Web Security Analytics (WSA). В дополнение к серверным данным, уже имеющимся в WSA, вы видите:

• Сработавшее правило

Сработавшее правило

• Задействованный скрипт

Задействованный скрипт

• Тип активности

Тип активности

• Метод JavaScript

Метод JavaScript

• Соответствующий селектор

Соответствующий селектор

• Релевантные контекстные данные

Релевантные контекстные данные

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

Видимость клиентских скриптов и современные ИИ-приложения

Поскольку предприятия внедряют клиентских ИИ-ассистентов, сторонние чат-виджеты на базе LLM и встроенные в браузер скрипты инференса в свои веб-приложения, подверженность клиентским рискам значительно возрастает. Вредоносные скрипты могут перехватывать локальный ввод промптов или полезные данные ответов ИИ прямо в браузере. Расширяя платформу Akamai Application Protection Platform на клиентскую сторону, команды AppSec получают унифицированный обзор как традиционных зависимостей JavaScript, так и новых путей передачи ИИ-данных на стороне клиента.

Единая модель политик для всей поверхности атаки приложения

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

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

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