Финтех уходит в облако: что делать ИБ

От «защищённой сети» к «проверке каждого запроса»

Финтех переходит в облака ради скорости — это позволяет быстрее масштабировать ИТ-системы, запускать новые сервисы и управлять вычислительными ресурсами. Но вместе с возможностями растёт и поверхность атаки.

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

В облаке эта логика перестаёт работать. Единый периметр фактически распадается на множество точек контроля — ими становятся отдельные устройства, сервисы, API, рабочие нагрузки и наборы данных. Каждый из этих элементов может стать точкой входа. Причём атака не всегда начинается со взлома межсетевого экрана или VPN. Скомпрометированная учётная запись, токен с избыточными правами или легитимный на первый взгляд API-запрос позволяют злоумышленнику действовать от имени пользователя или сервиса. Поэтому само нахождение внутри корпоративной сети больше не может считаться достаточным основанием для доверия.

В основе защиты лежат принципы Zero Trust и Identity First Security: решение о доступе принимается не на основании местоположения пользователя или сервиса в сети, а с учётом его цифровой идентичности, полномочий и контекста обращения. Идентичность — только один из уровней контроля. Микросегментация ограничивает взаимодействие между отдельными системами и рабочими нагрузками. Принцип наименьших привилегий предполагает предоставление только тех прав, которые необходимы для выполнения конкретной задачи. Дополняют эту модель постоянный контроль конфигураций, централизованный мониторинг и анализ событий, а также защита приложений и API на уровне запросов и доступа к ресурсам. Таким образом, мы выясняем не «находится ли объект внутри защищённой сети?», а «кто обращается, к какому ресурсу, зачем, с какого устройства, с какими полномочиями и соответствует ли это ожидаемому поведению?».

Какие угрозы усилились в облаке

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

Большинство угроз не являются принципиально новыми — облачная среда лишь их ускорила и масштабировала. Среди наиболее характерных сценариев: компрометация учётных записей администраторов, захват Kubernetes-кластера или контейнера с последующим перемещением между рабочими нагрузками, SSRF-атаки с обращением к внутренним сервисам и метаданным облака.

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

Идентичность — новая точка контроля

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

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

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

Zero Trust на практике

Внедрение Zero Trust начинается не с выбора конкретных инструментов, а с инвентаризации инфраструктуры. Необходимо определить пользователей, устройства, сервисы, точки взаимодействия, маршруты передачи данных и действующие права доступа. Здесь важно понять, где сохраняются избыточные зоны доверия и какие компоненты требуют первоочередной защиты. В качестве базовых мер можно последовательно внедрять централизованную аутентификацию и MFA, разделять роли, сокращать ненужный публичный доступ, унифицировать журналирование и ограничивать межсервисные соединения.

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

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

Безопасность до выхода продукта

Security by Design предполагает, что безопасность закладывается в продукт с самого начала, а не становится финальной проверкой перед релизом. Контроль должен проводиться на протяжении всего жизненного цикла продукта. При этом задача ИБ — не согласовывать вручную каждое изменение, а автоматизировать типовые проверки через политики, шаблоны и CI/CD. Ручная экспертиза при таком подходе сосредотачивается на новых архитектурных решениях и изменениях с повышенным риском.

В разработке важны статический и динамический анализ, проверка зависимостей и управление секретами. Критичные уязвимости должны выявляться как можно раньше и блокировать сборку, а не просто фиксироваться в отчёте.

Адаптация ИБ-архитектуры

Переход в облако меняет саму архитектуру информационной безопасности. Уходит представление о том, что достаточно защитить вход в инфраструктуру, а внутренний трафик можно считать доверенным. Поэтому начинать переход стоит не с выбора отдельных продуктов, а с проектирования базовой платформы: определить критичные активы, права доступа, требования к сегментации, журналированию и резервированию. Эти правила важно сразу автоматизировать через Infrastructure as Code и CI/CD, чтобы безопасная конфигурация становилась настройкой по умолчанию.

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

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