Меня зовут Саша Черток, руковожу отделом безопасности контейнерных и облачных технологий в Альфа-Банке. Расскажу, как вывести организацию в облако, даже если она максимально зарегулирована.
Статья будет интересна как организациям схожим по масштабу, так и компаниям с большей свободой действий, но тем не менее, имеющим уже выстроенные процессы, в частности, процессы ИБ.
Изначально был только сервер
В котором мы жили по уже сложившимся канонам внутри известного и подконтрольного периметра и исповедовали Zero Trust — подход к безопасности, при котором никто никому не доверяет по умолчанию. И однажды у нас появилась задача «выехать» в облако. Но не в ещё один собственный ЦОД, а во внешнее облако.
Пример выезжающих в облако в рамках пилотов команд говорил, что всё будет быстро и легко. Но быстро и легко пришло только осознание, что нельзя просто так взять и перенести on-prem в облако.
Почему?
Потому что традиционные средства и подходы не работают. Само по себе облако имеет специфику безопасности, а риски отличаются от традиционной инфраструктуры. Возможно, по этой причине за 2024 год больше 60% компаний столкнулись с инцидентами безопасности, связанными с облаком, а в 2025 — уже 65%?
Если, как упоминал ранее, мы жили за неким сетевым периметром, где можно было отгородиться блокирующими или разрешающими правилами или «белыми списками», то облако — это API-first инфраструктура, где используемые сервисы (особенно managed services) не стоят за какими-то фаерволами, а имеют в первую очередь публичные API, доступ к которым регулируется иными правилами: RBAC, политики, ACL.
Возникает новая модель ответственности, где часть задач берет на себя платформа и её сотрудники. Это так называемый Cloud Trust — модель безопасности, которая предполагает разделение обязанностей между провайдером и клиентом.
Но даже если ответственность поделена, отпускать контроль мы не можем. Но и тормозить команды оправданиями «уникальной специфики облака» тоже не будем. Так что мы решили не изобретать велосипед, а просто учесть специфику облака в виде вариантов технической реализации наших текущих процессов. Ниже я пройду по базовому набору действий: сеть, доступы, конфигурации и SOC.
№1. Сетевой доступ
Мы сделали практически полный маппинг ресурсной организации on-premises с ресурсной организацией Yandex Cloud (ЯО далее).
Как и говорил ранее, у нас появляется новый периметр — IAM. Но и старый никуда не исчезает. Сетевая изоляция и микросегментация остаются чуть ли не самыми важными вопросами ИБ до сих пор. Потому первый же вопрос, который мы задали себе при выезде, был таков: «А как нам с ним общаться?» То есть как строить интеграции, как пускать управляющий трафик и трафик этих интеграций и так далее.
Ответом на вопрос стал интерконнект. Это оптика с тёмным волокном между Банком и Платформой, поверх которой накладывается ГОСТ-шифрование. В интерконнект мы заворачиваем весь свой трафик, ходим из сети Банка в консоль, строим внутри интеграции и т.д.
Чтобы текущие процессы продолжали работать в облаке, должна появиться схожая структура и организация управляемых объектов, то есть сетей, подсетей и правил фаерволинга. Напомню, что мы тут про ИБ, поэтому опустим некоторые детали сетевой архитектуры.
В банке у каждой условной системы есть свой набор сред (упрощенно: dev, test, prod). Каждая из них имеет собственный набор подсетей, строго изолированных друг от друга. В рамках одной среды подсети этой системы также изолированы фаерволами.
Такую же структуру мы организовали в облаке: система — это облако, а фолдеры – среды, каждая из которых имеет свои сети/подсети и набор правил фаерволинга, реализованных через Security Groups (как механизм сетевой изоляции).
Также и трафик в самом интерконнекте поделен между средами и не пересекается. Мы сохранили текущую архитектуру, научились работать с сетями облака, как с собственными, реализовав текущий процесс управления сетевыми доступами в новом окружении.
Команда, как и раньше, согласовывает проект, заказывает подсети и сетевые доступа, как в on-prem, но в облаке. И даже если система поделена между on-prem и облаком, то её связность никак не нарушается. Все проекты, выезжающие в облако, получают пул IP-адресов с банковской сетью. Эти сети анонсируются в интерконнект и выглядят так, будто просто находятся в другом ЦОДе, и в нашей системе учета сетей пул заводится как обычная подсеть.
Мы выбрали контроль через сохранение текущей модели управления доступом, но делегировали реализацию этого процесса облачным сервисам — тем же Security Groups, которыми мы управляем через Terraform.
Единственное, что внешний трафик («интернет-интернет») в облако и из облака пока не пускаем — только через внутреннюю инфраструктуру. Но когда-нибудь сможем.
№2. Пользовательский доступ
Осознавая критичность пользовательских доступов в новой парадигме, мы решили, что и процесс управления последними также должен быть универсальным и повторять свою реализацию в новом окружении. Внутри все пользовательские доступы, доступы систем, технических учетных записей, управляются централизованно через Active Directory (AD) и KeyCloak, которые также поделены по средам. Облако позволяет их интегрировать со своим IAM и построить на их базе федерации для каждой из сред со своими наборами политик.
Фактически процесс аутентификации происходит в банке и транслируется в ЯО — то есть мы продолжаем использовать именно банковские корпоративные УЗ через банковскую же инфраструктуру для доступа к ресурсам и консоли облака.
А что с авторизацией и правами?
Сама по себе авторизация очень важна, и в какие бы разные и мелкие группы пользователей AD мы ни распределяли сотрудников, она всё равно работает уже на самом сервисе. Без сервисных ролей здесь никуда.
Мы начали переход в облако давно, и на первых этапах роли были примитивнее, чем сервисные. Со временем у ЯО появилась отличная грануляция сервисных прав, которая очень удобно позволяет собирать роли, соблюдая принципы наименьших привилегий. И также позволяет сопоставлять упомянутые ранее группы A D и группы пользователей IAM в ЯО. Фактически мы и здесь реализовали текущий процесс управления доступом в новом облачном окружении, сохранив командам привычный флоу работы и скорость без потери контроля.
Получился отличный баланс – аутентификация как в on-prem, но логичное делегирование авторизации в облако.
№3. Контроль конфигурации
Ну а что насчет самого разворачивания в облаке? Как вообще выезжать и контролировать то, что едет?
Чуть ранее я говорил, что мы используем ту же модель объектов в облаке, что и в банке, т.е. условно созданный Compute Cloud в облаке фиксируется в нашей системе инвентаризации как обычная WM. То же самое с сетями, то же и с другими сервисами.
Но что изменилось?
Например, мы стали вести реестр и критерии применимости Managed Services – каждый из них имеет свои возможности и нюансы, и мы начали с того, что провели анализ и составляем некую карту применимости того или иного managed services в том или ином проекте, с помощью которой можем решить, что один сервис разрешен одной команде, а другой запрещен.
Каждый проект должен создать свою проектную документацию – фактически отрисовать архитектуру с применяемыми в том числе облачными ресурсами. По итогу он получит согласование (сам процесс согласования сейчас не важен). И далее команда идет не в ЯО, а в нашу внутреннюю платформу, интегрируемую с облаком и через неё заказывает все необходимые ресурсы —> всё будет поднято для них в облаке. А мы на своей стороне сможем проверить ту же конфигурацию этих ресурсов.
Стоит отметить, что облако помимо предоставления своих образов ОС, за безопасностью и свежестью которых они следят самостоятельно, также позволяют приносить и свои образы, чем мы активно и пользуемся. И здесь, как я ранее писал, мы также разрешаем использовать и облачные managed services.
Далее на развернутую инфраструктуру надо деплоить приклад — мы выбираем платформу CI/CD. Но здесь всё просто – у нас есть требования к платформам CI/CD и фактически такую систему можно сделать полностью облачной, что мы пробовали. Но использовать внутреннюю, уже построенную и готовую, куда удобнее: все сканеры настроены, все гейты построены.
И, самый интересный пункт, по моему мнению — контроль развернутого. Так уж получилось, что у нас есть своя команду ответственных за безопасность облаков, которой удается время от времени заниматься исследование новых облачных сервисов, актуализировать модель угроз и требования.
А так как в облаке у нас довольно внушительная инфраструктура, много новых тяжелых подпроцессов, новых требований и моделей угроз, а команда маленькая, то без автоматизации никак. Потому с самого начала мы перекладывали все требования в код. Сейчас наши требования выглядят как набор проверок в коде — фактически это сканер облаков, являющийся клиентом над API облака, со всеми необходимыми нам функциями. Так, фактически, у нас появился собственный CSP (Cloud Security Posture Management — управление состоянием безопасности облака).
Этот подход позволяет писать любые требуемые нам проверки. Но порой нам может не хватать экспертизы в каких-то вопросах, и без экспертизы ЯО не обойтись, поэтому мы также можем использовать сервис Yandex Security Deck с его модулями.
На данном этапе мы всё ещё сохраняем преимущественно Zero Trust подход, но частично отдаём ответственность ЯО.
№4. SOC
Мы всё развернули, задеплоили, прошли проверки ИБ. А значит пора мониторить, детектить и реагировать. В on-prem мы знаем всё: у нас свои правила и полный контроль логов — на это отдельно выделена функция SOC.
Но в облаках у нас нет полного контроля над логами, так как:
мы можем использовать только те сервисы сбора логов, что нам предоставляет площадка: Control Plane и Data Plane (= Audit Trail/Cloud Logging), а также логи действия самого провайдера;
в ЯО постоянно появляются сервисы (которые, конечно же, сразу нужны командам), а фичи (в плане логирования) за ними не поспевают.
Но одно дело получить, другое — обработать (нужен детект). На это нужно нанимать команду, чтобы собирать, обрабатывать, а это дорого (да и свою экспертизу надо наращивать).
Поэтому мы всё ещё пользуемся сервисом YCDR от платформы, который позволяет нам закрывать эту функцию в облаке.
Примечание. С логами у нас ситуация строгая, и не все сервисы выдают необходимые объём и формат, но команда ЯО всегда старается реализовать необходимый FR или же всегда можно воспользоваться их экспертизой и сервисом SOC.
Итого
На данный момент в облаке у нас довольно большая инфраструктура: разные среды, разные системы, 1500 виртуальных машин, 100 managed services, 1000 пользователей — сотрудники и члены команд и сервисных аккаунтов.
Если собрать всё, о чём мы говорили, в одну картину, то кажется, что сети, доступы, конфигурации, мониторинг — это разные процессы. Но на самом деле в каждом из них мы принимаем одно и то же решение — где оставить контроль, а где довериться облаку.
Безопасность в гибридной инфраструктуре — это не набор инструментов, сумма решений. Если пытаться всё контролировать — не успеем за скоростью облака. Если доверять всему — потеряем безопасность. Поэтому единственный рабочий подход — это баланс между Zero Trust и Cloud Trust.
Читайте также: