Мультирегиональные облака: как мы решили изоляцию регионов и бесшовный переход

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

Я Антон Дедов, архитектор функций безопасности Yandex Identity and Access Management (Yandex IAM) в Yandex Cloud. Вместе с Евгением Сидоровым, Аркадием Вязниковым и Владиславом Архиповым мы запатентовали собственную систему управления доступом в облаке. В нашей платформе мы выбрали не классический подход с глобальным IAM, как у многих зарубежных компаний, а развили противоположный — с изолированными регионами, которые мы бесшовно склеили на уровне UX. И в итоге получили возможность переходить к мультирегиональной модели с учётом требований ИБ.

Как устроены облачные регионы и при чём тут Казахстан

В позапрошлом году Yandex Cloud открыл новый регион в Казахстане, и нам потребовался свежий взгляд на архитектуру с точки зрения безопасности. Исторически в Yandex Cloud был один регион, но платформа сразу проектировалась с учётом региональности. Российский регион был обозначен как ru-central1. Мы ожидали, что со временем появятся новые, и было несколько вариантов, как развивать архитектуру с их появлением.

Новый регион — это новая локация для размещения дата-центров провайдера. Как правило, регион состоит из одной или нескольких зон доступности — изолированных дата-центров с собственной инфраструктурой (питание, охлаждение и т. д.). А Yandex Cloud как облачный провайдер предоставляет клиентам возможность использовать ресурсы в регионах.

Региональность решает в первую очередь задачу размещения нагрузок ближе к конечному пользователю. Это позволяет снижать задержки: например, крупный интернет-магазин может обслуживать клиентов из Азии или Европы из соответствующих регионов. Внутри зоны задержки минимальны, между зонами — выше, а между регионами — максимальны.

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

При этом система Yandex Identity and Access Management — важная составляющая любого публичного облака, через которую проходят все действия с облачными сущностями. IAM определяет модель безопасности, авторизации и управления ресурсами. И когда мы оперируем разными ресурсами, в IAM учитывается, что они могут быть зональными, региональными и глобальными.

Почему глобальный IAM нам не подошёл

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

Когда мы проектировали мультирегиональность, с точки зрения IAM возникло несколько вопросов. Нам нужно было решить:

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

Без ответов на эти вопросы нельзя стартовать проект мультирегиональной архитектуры.

Реализацией мультирегиональности в Yandex Cloud мы занимались в несколько этапов.

1. В 2021 году мы рассматривали вариант с глобальным IAM, обслуживающим все регионы. Но этот вариант развития событий был дороже, и в том числе означал повышение стоимости услуг для конечных пользователей. Одновременно с этим к началу 2022 года стало понятно, что модель изолированных регионов может стать преимуществом. Когда международные облака (Microsoft, Google, AWS) подчиняются американскому законодательству, мы могли гарантировать пользователям из других регионов: «ваши данные остаются вашими» — ведь данные хранились на территории их стран.

2. В 2023 году, когда мы вернулись к проекту создания региона в Казахстане, мы в первую очередь взяли за основу архитектурные принципы, определяющие дизайн системы:

   • отсутствие общих точек отказа между регионами — если один регион испытывает трудности, другие регионы не должны страдать,
   • объём ущерба инцидентов должен быть ограничен пределами одного региона,
   • важно соответствовать требованиям комплаенса и локального законодательства,
   • необходимо создать условия, при которых клиент чувствует, что пользуется единым сервисом, а не набором разнородных изолированных облаков.

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

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

Что даёт изоляция регионов в мультирегиональной модели

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

Ресурсы и доступы

Модель авторизации в Yandex Cloud построена как иерархическое дерево ресурсов. Корневой элемент — организация, внутри которой находятся пользователи, группы и облака с ресурсами.

Организация выступает административным доменом: доступ к ресурсам могут получать только пользователи, входящие в эту организацию. Доступы наследуются по иерархии.

Например, роль, выданная на уровне облака 2.2, распространяется только на ресурсы внутри него, а роль, выданная на уровне организации, действует на все ресурсы организации.

Команда Security Operation Center внимательно следит, чтобы доступы были очень-очень гранулярные и выдавались только для разбора конкретного кейса. Все субъекты в облаке равны — и сервисные аккаунты, и сотрудники облака, и внешние пользователи. Даже для поставки событий необходимо делегировать доступ — предоставить аналитикам разрешения на чтение логов соответствующего уровня. Если же возникает необходимость расследовать инцидент, то инженеры получают урезанный временный доступ на выполнение конкретных операций.

В мультирегиональной модели пользователь при создании организации выбирает регион, который становится домашним. В этом регионе администратор выполняет все основные операции администрирования организацией: создаёт пользователей, группы, ресурсы и настраивает доступы уровня организации.

При необходимости использовать другой регион (например, Казахстан) создаётся теневая копия организации — shadow organization. В неё реплицируются пользователи, группы и доступы на уровне всей организации.

Для shadow organization вводятся ограничения: источником административной правды остаётся домашний регион, а синхронизация выполняется в одном направлении — из основного региона в дополнительный. При этом в теневом регионе можно создавать и использовать ресурсы, запускать нагрузки и т. д.

Сейчас этот сервис находится в техническом превью: для тестирования нужно запросить доступ. Покажу, как это выглядит в UX:

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

Под капотом межрегиональное взаимодействие построено на сервисных аккаунтах. В каждом регионе существуют системные сервисные аккаунты, представляющие сам регион, а также аккаунты-представители других регионов. На схеме показаны три региона: регион 1, 2, 3. Это для простоты и наглядности.

Сервисные аккаунты — по сути роботные учётки. В данном случае это системные сервисные аккаунты, и тёмным цветом выделены сервисные аккаунты, которые представляют сам регион. В регионе 1 синий — это сервисный аккаунт региона 1, в регионе 2 — чёрный и т. д.

Также в каждом регионе есть сервисные аккаунты представителей соседних регионов. Доверие между регионами реализовано через механизм Workload Identity Federation: сервисный аккаунт одного региона может имперсонироваться в аккаунт-представитель в другом регионе. При этом права таких аккаунтов строго ограничены — фактически они могут только создавать shadow organization.

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

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

Если скомпрометирован регион, в котором организация не представлена, инцидент не оказывает на неё влияния: у сервисных аккаунтов этого региона отсутствует доступ к её ресурсам.

Если компрометация происходит в регионе с shadow organization, под угрозой оказываются только ресурсы, размещённые в этом регионе. Административные изменения не распространяются обратно, так как синхронизация выполняется односторонне — из домашнего региона.

Компрометация домашнего региона приводит к полной потере контроля над организацией. Game over, друзья. Но, собственно, эта ситуация ничем не отличается от ситуации, где у нас просто один регион.

Пользователи и аутентификация

Аутентификация пользователей в Yandex Cloud реализована двумя способами: через Яндекс ID или через федерацию удостоверений. Мы поддерживаем протокол SAML. Также у нас появился Yandex Identity Hub, где можно создавать пользователей прямо в облачной платформе.

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

Независимо от способа входа в облако все сервисы Yandex Cloud, включая UI, интегрированы с центральным OpenID или OAuth-провайдером. Это обеспечивает единый механизм аутентификации и сессионности (в том числе через внутренний API для шеринга сессий).

Независимо от того, как идентифицируется конечный пользователь, все наши собственные UI коммуницируют с нашим центральным сервером по OpenID Connect. У нас также есть Session API — приватный API, который позволяет держать единую сессию между всеми.

Чем же тогда отличаются регионы? В мультирегиональной модели регионы могут выступать в разных ролях. Регион, в котором находится пользователь и его организация, становится identity-провайдером (IdP), а регион, где размещаются ресурсы (например, в рамках shadow organization), — сервис-провайдером (SP).

Мы можем использовать нашу текущую технологию OpenID Connect и соединить произвольное количество регионов по стандартному протоколу.

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

На уровне реализации для регионов используется схема с префиксами. Например, kz.auth.yandex.cloud, kz.console.yandex.cloud, kz.center.yandex.cloud для Казахстана, тогда как исторически первый российский регион остаётся без префикса.

Процесс логина выглядит следующим образом. Пользователь обращается к консоли того региона, где он планирует работать с ресурсами. Например, он приходит в консоль R1 по протоколу OpenID Connect, который является внутренним регионом, и мы пользователя проверяем, идентифицируем. Если пользовательской сессии нет, ему предлагается выбрать способ аутентификации: через Яндекс ID или через федерацию.

В случае Яндекс ID аутентификация выполняется напрямую через Яндекс Паспорт в рамках текущего региона. В случае федерации возможен сценарий, при котором пользователь принадлежит организации с домашним регионом в другом регионе R2. Тогда текущий регион инициирует аутентификацию через этот регион по протоколу OpenID Connect: домашний регион выступает как IdP, а целевой — как SP. После успешной аутентификации пользователь получает доступ к ресурсам.

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

Поскольку пользователи хранятся в отдельных IAM каждого региона, возникает задача их глобальной идентификации при синхронизации. Для этого придумали специальный идентификатор этих пользователей: identity reference, состоящий из двух частей: issuer и subject ID.

Для пользователей Яндекс ID в issuer мы пишем просто волшебное слово Yandex, а в subject ID — идентификатор пользователя в системе Яндекса, что позволяет однозначно распознавать его в любом регионе.

Для федеративных пользователей в issuer указывается регион, а subject ID остаётся локальным идентификатором. Это позволяет иметь разные локальные идентификаторы в регионах, сохраняя возможность их сопоставления.

Единый UX, бесшовный переход между облаками и регионами

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

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

Бесшовное переключение между регионами реализовано поверх OpenID Connect с дополнительной логикой. Все UI-компоненты выступают как OAuth/OpenID Connect-клиенты, но консоли разных регионов — это разные клиенты, подключённые к разным авторизационным серверам. Прямого доверия между ними нет, поэтому стандартный флоу OpenID Connect не подходит для перехода между регионами.

В спецификации OpenID Connect предусмотрен механизм initiate_login_uri, позволяющий инициировать аутентификацию из внешней системы. Он использует параметр issuer и дополнительные параметры для передачи контекста логина.

В Yandex Cloud этот механизм усовершенствован в целях безопасности: мы добавили собственный параметр Authentication Intent — подписанный JWT, который хранит и сообщает данные:

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

Процесс выглядит так:

1. Пользователь в консоли одного региона выбирает ресурс в другом регионе.
2. Фронтенд генерирует Authentication Intent.
3. Запрос с этим объектом отправляется в целевой регион.
4. Целевой регион валидирует подпись и проверяет, что Intent адресован ему.
5. Выполняется аутентификация пользователя через локальный авторизационный сервер с передачей login_hint.

В результате при корректной валидации пользователь получает сессию в другом регионе без повторного ввода кредов.

Итоги перехода к мультирегиональности

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

Такой подход — осознанный компромисс. Альтернативой могла бы быть модель с глобальным IAM и глобальными пользователями (как у крупных облачных провайдеров), но она значительно дороже в реализации. Вместо этого мы выбрали архитектуру, у которой есть преимущества с точки зрения безопасности и изоляции.

За рамками остаются дальнейшие задачи: развитие control plane между регионами, объединение в единую консоль и проработка дополнительных деталей архитектуры. На наши решения мы получили патент. Если вам интересно, вот описание изобретения к патенту.