- Чего ЕЦБ ожидает от банков
- Почему теневые и «зомби»-API повышают уровень риска
- Обнаружение API в банковской среде
- Приоритизация рисков API и тестирование перед развертыванием
- Связь обнаружения в среде выполнения с встроенной защитой
- Создание доказательств снижения рисков API
- Включение безопасности API в план действий
Основные выводы
Европейский центральный банк (ЕЦБ) требует, чтобы значимые организации, находящиеся под его прямым надзором, представили планы действий по борьбе с киберугрозами, использующими ИИ, до 31 октября 2026 года.
Теневые и «зомби»-API могут раскрыть банковские данные и бизнес-функции. Более быстрые и автоматизированные атаки делают поиск и защиту этих конечных точек еще более актуальными.
Akamai API Security помогает банкам обнаруживать API, оценивать риски, тестировать на наличие уязвимостей, выявлять злоупотребления в среде выполнения и поддерживать процессы устранения проблем.
Прямая интеграция с Akamai App & API Protector связывает внеканальный анализ API Security с распределенной встроенной защитой для фильтрации трафика.
Недокументированная партнерская конечная точка или устаревший API мобильного банкинга могут раскрыть информацию о клиентах даже после того, как новые сервисы получили более надежную защиту. Поскольку ИИ ускоряет обнаружение и эксплуатацию уязвимостей, банкам необходимо более четкое представление об этих пробелах и практический способ их устранения.
Для банков, готовящих ответ на призыв ЕЦБ усилить киберзащиту, безопасность API должна стать четко определенной частью плана действий. Это означает идентификацию открытых сервисов, назначение ответственных лиц, устранение слабых мест и измерение прогресса как для обычных банковских API, так и для тех, что поддерживают приложения с ИИ. Банку не обязательно внедрять ИИ самостоятельно, чтобы столкнуться с атаками, использующими ИИ.
Чего ЕЦБ ожидает от банков
В своем письме ЕЦБ предписывает значимым финансовым организациям взять на себя прямую ответственность за этот риск, представив подробные планы действий своим Совместным надзорным группам (JST) до 31 октября 2026 года. Планы должны определять меры, ресурсы, обязанности и сроки реализации. Обратите внимание, что это крайний срок подачи, а не требование завершить все улучшения к этой дате.
Письмо опирается на Закон о цифровой операционной устойчивости (DORA) и существующие стратегии киберрисков. В Приложении 1 API включены в число сущностей, которые могут поддерживать принципы «нулевого доверия» (Zero Trust) и глубокоэшелонированной защиты посредством непрерывной проверки. В нем также подчеркивается важность управления уязвимостями, мониторинга, рисков третьих сторон, а также реагирования и восстановления.
Наша рекомендация — превратить эту актуальность API в конкретную работу: определить, какие интерфейсы открыты, приоритизировать риски и проверить средства контроля, защищающие их.
Почему теневые и «зомби»-API повышают уровень риска
API соединяют банковские приложения с информацией о счетах, платежными сервисами, партнерскими системами и внутренними рабочими процессами. Их структурированные запросы и ответы дают злоумышленникам повторяемый способ поиска слабых мест. Инструменты с поддержкой ИИ могут ускорить эту работу, усиливая давление на команды в вопросах устранения нарушений авторизации, утечек данных, неправильной конфигурации и злоупотреблений бизнес-логикой.
Теневые API находятся вне утвержденного реестра и вне поля зрения службы безопасности. «Зомби»-API остаются доступными после того, как они устарели или были выведены из эксплуатации. И те, и другие могут не проходить тестирование, обновление политик и мониторинг, применяемые к текущим сервисам. ЕЦБ определяет неполные реестры и устаревшие версии API как риски безопасности. Удаление конечной точки из документации не делает ее недоступной.
Например, старый API выписки по счету может принимать правильный логин, но не проверять, действительно ли запрашиваемая выписка принадлежит этому пользователю. Просто изменив идентификатор записи, злоумышленник может раскрыть информацию другого клиента — это уязвимость, известная как нарушение авторизации на уровне объекта (BOLA). Запрос может быть правильно отформатирован и оставаться в пределах лимитов скорости, нарушая при этом правила доступа, поэтому средства контроля, ориентированные только на формат запроса, аутентификацию или объем трафика, могут пропустить такое злоупотребление.
Обнаружение API в банковской среде
Akamai API Security объединяет данные обнаружения из трафика в среде выполнения, репозиториев исходного кода, спецификаций и поддерживаемых интеграций инфраструктуры (Рисунок). Это помогает банкам выявлять API, которые могут быть пропущены при инвентаризации только через шлюз или проверке документации, включая внутренние API для взаимодействия между сервисами. Покрытие зависит от источников данных и сред, подключенных к платформе.
Функция «APIs from Code» добавляет видимость поддерживаемых репозиториев перед развертыванием. Обнаружение также включает интерфейсы, связанные с ИИ, такие как подключения к большим языковым моделям (LLM), сервисам генеративного ИИ (GenAI) и серверам протокола контекста модели (MCP). Непрерывное обнаружение дополняет периодические аудиты по мере изменения приложений и интеграций.
Команды должны подтвердить владельца, назначение, ожидаемых потребителей и риски раскрытия конфиденциальных данных для каждой конечной точки. Эти детали помогают определить, нуждается ли API в более строгом контроле, дополнительном тестировании, ограничении доступа или выводе из эксплуатации.
Приоритизация рисков API и тестирование перед развертыванием
Akamai API Security оценивает состояние безопасности и определяет, какие API обрабатывают конфиденциальные данные, помогая командам приоритизировать слабые места, такие как пробелы в аутентификации или неправильные конфигурации. Реакция должна основываться на уровне риска и влиянии на бизнес.
API, выходящий в интернет и обслуживающий финансовые записи, может потребовать более быстрого исправления, чем изолированная тестовая конечная точка без производственных данных. Для устаревшего API правильным действием может быть контролируемый вывод из эксплуатации после подтверждения того, что легитимные потребители мигрировали.
С помощью Active Testing организации могут тестировать существующие API для выявления нарушений авторизации и злоупотреблений бизнес-логикой. Команды могут запускать тесты до выхода в продакшн, по запросу или в рамках рабочих процессов непрерывной интеграции и доставки (CI/CD), а затем проверять исправления перед выпуском. Обнаружение исходного кода идентифицирует интерфейсы, а динамическое тестирование предоставляет доказательства того, как эти интерфейсы ведут себя при атаке.
По возможности Akamai связывает результаты с репозиторием, путем к файлу и контекстом разработчика. Это дает командам приложений более четкую отправную точку для исправления и сокращает время, затрачиваемое на поиск кода, стоящего за затронутым API, гарантируя, что скорость разработки не пострадает из-за узких мест в безопасности.
Связь обнаружения в среде выполнения с встроенной защитой
Сами по себе обнаружение и тестирование недостаточны. Производственные API нуждаются в мониторинге даже после прохождения тестов безопасности. Akamai API Security анализирует поведение API для выявления аномального использования, раскрытия конфиденциальных данных и злоупотреблений бизнес-логикой, включая активность с использованием действительных учетных данных и легитимных вызовов. Команды могут исследовать такое поведение, не доказывая предварительно, использовал ли злоумышленник ИИ.
Внеполосный анализ API Security дополняет App & API Protector. Благодаря их прямой интеграции API Security может инициировать принудительное применение политик через App & API Protector для трафика на защищенном пути в соответствии с настроенным ответом. Отдельные интеграции с инструментами управления информацией о безопасности и событиями (SIEM) и управления ИТ-услугами (ITSM) поддерживают расследование, оповещение и управление инцидентами.
Вынос анализа, требующего больших затрат ресурсов на сессии и контекст, за пределы пути запроса позволяет избежать добавления этой обработки к каждому запросу, в то время как App & API Protector обеспечивает распределенное встроенное принудительное применение политик. Такая архитектура поддерживает высокопроизводительную и отказоустойчивую стратегию защиты. Командам следует проверять настроенный ответ, включая время от обнаружения до применения мер и охват трафика.
Там, где это применимо, правила межсетевого экрана веб-приложений (WAF) могут обеспечить виртуальное исправление уязвимостей (virtual patching) для защиты от шаблонов эксплойтов, пока разработчики устраняют основной дефект. Блокировка злонамеренного источника не исправляет нарушенную проверку авторизации. Элементы управления доступом на стороне приложения, постоянные исправления и валидация остаются необходимыми.
Создание доказательств снижения рисков API
Инвентаризация API дает командам базовый уровень для улучшений. Возможности Akamai по оценке состояния и отчетности помогают отслеживать результаты и оценивать соответствие политик с течением времени. Результаты тестирования, записи об инцидентах и доказательства устранения уязвимостей могут показать, какие риски были устранены, а где еще предстоит работа.
Для раздела плана действий, касающегося API, мы рекомендуем документировать:
- Охват инвентаризации, подключенные источники обнаружения и известные пробелы в видимости
Охват инвентаризации, подключенные источники обнаружения и известные пробелы в видимости
- Теневые и устаревшие конечные точки, назначенные владельцы и решения по их защите, ограничению или выводу из эксплуатации
Теневые и устаревшие конечные точки, назначенные владельцы и решения по их защите, ограничению или выводу из эксплуатации
- Приоритизированные результаты, раскрытие конфиденциальных данных, сроки устранения и принятые исключения
Приоритизированные результаты, раскрытие конфиденциальных данных, сроки устранения и принятые исключения
- Охват предпроизводственного тестирования, неудачные проверки и результаты повторного тестирования, подтверждающие исправления
Охват предпроизводственного тестирования, неудачные проверки и результаты повторного тестирования, подтверждающие исправления
- Инциденты во время выполнения, ответные действия и измеренное время от обнаружения до применения мер
Инциденты во время выполнения, ответные действия и измеренное время от обнаружения до применения мер
Это практические примеры доказательств безопасности API для более широкой программы устойчивости банка. Банкам следует связывать их с критичностью услуг и допустимым уровнем риска, наряду с реагированием на инциденты, упражнениями по восстановлению, сторонним аудитом и подотчетностью руководства.
Сделайте безопасность API частью плана действий
Устранение воздействия теневых и «зомби»-API требует постоянных решений о том, какие службы должны существовать, к чему они могут получать доступ и как они ведут себя в рабочей среде. Akamai API Security объединяет обнаружение, оценку состояния, тестирование и анализ во время выполнения, в то время как App & API Protector предоставляет дополнительные встроенные средства контроля. Вместе они помогают банкам снизить риски API и документировать прогресс. Соблюдение нормативных требований остается обязанностью банка и зависит от его общих средств контроля и управления.
Прочитайте Руководство Akamai по соблюдению требований ЕЦБ для получения более широкого ответа или изучите Akamai API Security, чтобы увидеть, как обнаружение, тестирование, обнаружение во время выполнения и интегрированная защита могут поддержать программу безопасности API вашего банка.
Об авторе(ах)
Стас Нейман
Стас Нейман — директор по маркетингу продуктов в Akamai, курирующий портфель решений Application Protection.
Теги
Агент может справиться с разногласиями, если система поиска показывает, что они существуют.
Искусственный интеллект
Векторный поиск не может отличить «да» от «нет»
Узнайте, почему векторный поиск может ранжировать противоречивые утверждения как похожие и как гибридный поиск может помочь системам RAG выявлять противоречивую информацию.
Akamai и UNIQLO нанесли код на футболку, что помогло мне задуматься о том, что AI-native поиск может означать для моды. Akamai и UNIQLO нанесли код на футболку, что помогло мне задуматься о том, что AI-native поиск может означать для моды.
Как выглядел бы RAG, если бы пользователем была Миранда Пристли?
Узнайте о создании «Миранды» — мультимодальной поисковой системы, индексирующей более 280 тысяч изображений моды с использованием OpenCLIP, PyTorch GEMM и локальных LLM без векторной базы данных.
Чего ИИ-агенты не могут делать лучше людей, так это выносить моральные суждения о том, что правильно, а что нет. По этой причине ИИ всегда должен находиться под контролем человека.
Что ИИ может, чего не может и чего не должен делать
Генеральный директор Akamai Том Лейтон высказывается о необходимости сдержек, противовесов и безопасности, чтобы держать использование ИИ под контролем человека.
