Как мы делаем разграничение доступа в одной платформе Сбера

Наша команда создаёт сервис управления доступом (коротко — СУД) в одной из самых больших в Сбере платформ — Платформе Кибербезопасности, или просто ПКБ. На ней обрабатываются все данные Банка, связанные с кибербезопасностью, а также работает множество продуктов и сервисов, предназначенных для противодействия внутреннему и внешнему мошенничеству, защиты инфраструктуры, а также для мониторинга и анализа различных угроз. Подробнее о том, что собой представляет ПКБ, можно посмотреть в Кибрарии Сбера в статье «Аналитическая платформа кибербезопасности. Опыт Сбера». Там же можно узнать, как наш сервис вписан в платформу.

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

Наш сервис используется в большой гетерогенной среде, которая содержит не только разрабатываемое в банке программное обеспечение, но и open source-продукты, предоставляющие различную функциональность (Apache Flink и MLFlow), а также управляющие данными (Apache Hadoop, Ozone и Clickhouse).

СУД должен:

• вписаться в общебанковский ландшафт и не нарушать банковские требования различного уровня;

• обеспечить удобное управление доступом на платформе и предложить новшества, которые станут востребованы всеми потребителями, в том числе в используемых open source-продуктах;

• централизовать аутентификацию и авторизацию, назначение доступов и контроль за ними на платформе;

• быть пригоден к переиспользованию другими платформами (автоматизированными системами).

Работу СУД можно разделить на специфические для сферы «Управление доступом и идентификация» направления:

1. модель доступа;

2. управление моделью доступа к ресурсам;

3. назначение доступов пользователям;

4. идентификация и аутентификация;

5. авторизация;

6. контроль, аудит и отчётность.

Я вынес «Модель доступа» отдельным пунктом, потому что она является основой, поверх которой выполняют все доработки и создают процессы управления доступом.

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

На схеме цветами и номерами выделены направления, в которых первоначально работал сервис управления доступов ПКБ.

1. Команда каждого сервиса ПКБ самостоятельно формирует свою ролевую модель доступа, защищает её на приёмо-сдаточных испытаниях очередного релиза и передаёт роли в СУД (1a). Все роли от всех сервисов агрегируют, а затем по запросу передают в общебанковский сервис управления пользовательскими учётными записями, который назовём userIDM (1b), с использованием протокола SCIM.

2. В userIDM по согласованной заявке пользователю может быть назначена роль (2a). Информация об этом синхронизируется с общебанковским сервисом аутентификации и передаётся по протоколу SCIM в СУД (2b), который сохраняет связку пользователь-роль в своей базе данных.

3. С сервисом ПКБ пользователь работает через шлюз аутентификации на основе Platform V IAM Proxy. Для этого пользователь должен авторизоваться на нём с использованием протокола OpenID Connect при помощи общебанковского сервиса аутентификации (3a—3d). После аутентификации сессия пользователя обогащается ID-токеном в формате JWT, затем его получает сервис ПКБ, вызванный пользователем.

4. Далее сервис обращается к СУД по REST API, запрашивая роли пользователя, идентификатор которого он получил в ID-токене. В соответствии с полученными ролями сервис уже разграничивает доступ пользователя — возможен или нет доступ к тому или иному разделу сервиса.

Модель доступа

Поскольку в банке используется ролевая модель, мы вынуждены использовать роли, но при этом можем значительно расширить их. Одним из самых известных стандартов, описывающих использование ролевой модели для разграничения доступа, является ANSI INCITS 359-2012 «Role Based Access Control». Мы взяли компонент референсной модели «Ядро RBAC» (Core RBAC) и расширили роли для использования привилегий внутри них (в наименованиях мы немного разошлись со стандартом, но суть осталась той же). В одной роли может быть несколько привилегий, а привилегия является именованным доступом к ресурсу и описывается связкой наименования ресурса с набором прав доступа к нему. Эта декомпозиция ролей позволяет хранить, по сути, уже политики разграничения доступа в СУД, видеть более полную картину доступов пользователей к ресурсам сервисов платформы.

Остальные определения стандарта, например, иерархию ролей (Hierarchical RBAC), мы пока не используем или полагаемся на общебанковские процессы, которые контролируют, в том числе, статическое разделение обязанностей (Static Separation of Duties).

У каждого сервиса ПКБ в СУД хранится своя собственная ролевая модель. Пространства сервисов полностью изолированы друг от друга. Однако сервисы на платформе работают всё-таки в конгломерате друг с другом, поэтому для упрощения получения доступов в рамках платформы мы расширили нашу ролевую модель на так называемые «опубликованные привилегии». Созданные в рамках одного сервиса ПКБ, их можно использовать в ролях другого сервиса.

Любые ролевые модели существуют отдельно от реальных ресурсов, потому что СУД, например, не знает, к каким же реальным ресурсам в сервисе даёт доступ привилегия с ресурсом «*», которая обычно интерпретируется как доступ ко всем ресурсам. Поэтому мы ввели в СУД ещё такое понятие, как «физический ресурс». Физические ресурсы — это информация о существующих в сервисе ПКБ реальных ресурсах. Например, это может быть база данных, таблица или даже столбец таблицы. Эту информацию ещё часто называют физической моделью.

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

Но эта модель доступа остаётся статической, то есть в большинстве случаев при появлении нового физического ресурса пользователь не получает автоматически доступ к нему. Приходится бегать и запрашивать, получая новую роль. Проблема скорости выдачи доступов особенно ярко проявляется с массовым использованием искусственного обучения и ИИ-агентов. Для её смягчения мы сейчас прорабатываем концепции управления доступом на основе связей (Relationship-based Access Control — ReBAC) и на основе атрибутов (Attribute-based Access Control — ABAC).

Управление моделью доступа к ресурсам

Концептуально управлять всеми моделями доступа на платформе должен Сервис управления доступом. Для этого у нас есть два канала изменения моделей:

• REST API управления СУД;

• заявки в графическом интерфейсе СУД.

В API управления есть отдельные методы для создания или изменения прав доступа, ресурсов, привилегий и ролей, а также опубликования привилегий. Для различного использования предусматриваются как методы полного обновления сущностей, так и частичного или даже только инкрементального (добавление без изменения или удаления). Сервис использует API СУД в случае ввода новой версии модели доступа в производственный процесс разработки с доработкой самого сервиса. Новую модель доступа тестируют на различных стендах и согласовывают с заинтересованными подразделениями, после чего уже вводят в эксплуатацию. Однако некоторым сервисам ПКБ необходимо изменять модель доступа без новых релизов, например, при изменении доступов пользователей к данным. В этом случае можно воспользоваться заявками на изменение модели доступа, в которой определённые сотрудники могут редактировать модель в том же интерфейсе СУД, и после получения всех необходимых согласований автоматически заливать в промышленную среду. Так может выглядеть подобная заявка в СУД:

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

В настоящий момент в СУД есть несколько возможностей получить информацию о физических ресурсах:

• Через API, через который любой сервис ПКБ может передать в СУД свою физическую модель с атрибутами или связями, например, идентификаторами владельцев ресурсов.

• С помощью импорта информации о физических ресурсах из других сервисов ПКБ, например, сервиса управления метаданными.

• С помощью импорта информации о физических ресурсах из самих сервисов, например, о базах данных и таблицах Hive из Metastore, о директориях HDFS и прочем.

• И, наконец, планируем вводить информацию о физических ресурсах через графический интерфейс СУД.

Основным атрибутом физических ресурсов сейчас является информация о владельце, но мы уже вычисляем и другие атрибуты, например, категорию конфиденциальности информации в Hadoop. Для этого СУД обращается к службе Hive, считывает небольшие образцы данных из таблиц и определяет степень их конфиденциальности с помощью внутреннего сервиса ПКБ на основе алгоритмов и искусственного интеллекта. Такие атрибуты могут в дальнейшем использоваться при применении принципов ReBAC и ABAC в моделях доступа.

СУД умеет управлять моделями доступа не только разрабатываемых в ПКБ сервисов, но и open source-продуктов, используемых в ПКБ. Например, он интегрирован с Apache Ranger и freeIPA. Модель доступа к сервисам Apache Hadoop ведется в СУД, после выполнения заявки по изменению модели автоматически или вручную преобразуется в политику доступа Apache Ranger и передается в него, после чего уже раскатывается на все необходимые узлы служб Hadoop. Другой вариант — использование LDAP-интерфейса в СУД для передачи прав доступа в такие продукты как Grafana или Platform V Search.

Назначение доступов пользователям

Роли пользователей в СУД разделены на два класса: базовый и прикладной. Базовые роли назначают при помощи общебанковского сервиса управления пользовательскими учётными данными IDM и передают в СУД с использованием протокола SCIM. Прикладные же роли не дают какого-либо доступа без базовых ролей, пользователь может заказать их в своём личном кабинете («Мой профиль») в СУД. Только после согласования владельцем сервиса и, при необходимости, владельцами ресурсов, к которым роль предоставляет доступ, пользователь получит запрошенную прикладную роль.

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

При этом мы стремимся максимально автоматизировать предоставление доступа пользователям с помощью использования связей (например, связи владелец ресурса) и атрибутов.

Идентификация и аутентификация

Мы прошли этапы формирования и назначения доступов и переходим к процессу входа пользователя в сервисы ПКБ с использованием Сервиса управления доступом. Сначала необходимо идентифицировать и авторизовать входящие запросы на шлюзе аутентификации, являющемся частью Сервиса управления доступом. Как я писал выше, шлюз создан на основе Platform V IAM Proxy. Для каждого сервиса ПКБ на IAM Proxy создаётся отдельное ответвление, под которым работает его графический интерфейс. Пользователь может быть аутентифицирован различными способами, в том числе в зависимости от уровня конфиденциальности обрабатываемых в сервисе ПКБ данных. Например, для многих сервисов используем двухфакторную аутентификацию при помощи мобильного приложения с подтверждением входа одноразовым паролем или ответом на push-уведомление.

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

Авторизация

Авторизация (или санкционирование доступа) — это предоставление субъекту доступа прав доступа, а также предоставление доступа в соответствии с установленными правилами управления доступом (ГОСТ Р 58833-2020 Защита информации. Идентификация и аутентификация. Общие положения. Пункт 3.50).

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

Вызовы API-авторизации спроектированы таким образом, что сервис может к нему прийти с разными запросами. Например, «Этот пользователь имеет такое-то право к такому-то ресурсу?». В этом случае СУД будет выступать PDP, то есть предоставлять ответ о возможности доступа.

Запрос:

GET /user/access/resource/is?system_id=mms&user_id=1102787&resource_name=resource1&permission_id=READ

Ответ: 

{
	"has_permission": true
}

Или другой вопрос: «Какие у этого пользователя роли?». Тогда СУД, скорее, выступит в качестве PIP, который формирует политику доступа, применимую к этому пользователю, а в качестве PDP выступит сам сервис: вычислит, есть ли у пользователя доступ к ресурсу.

Запрос:

GET /user/role?system_id=mms&user_id=1102787

Ответ:

{
  "user_id": "1102787",
  "roles": [ {
    "system_id": "mms",
    "role_id": "mms_role_1",
    "role_name": "mms_role_first",
    "description": "Первая роль MMS",
    "privileges": [ {
      "published": false,
      "privilege_id": "mms_privilege_res1_for_read&write"
    } ]
  } ]
}

Вне зависимости от того, где вычисляется доступ (PDP), решение по нему применяет сам сервис ПКБ, выступая в качестве PEP.

В случае продуктового open source-сервиса, такого как Grafana или Platform V Search, для авторизации мы используем LDAP API СУД. С его помощью определяем привилегии пользователей — в нотации LDAP они называются группами, в которые входит пользователь (в данном случае СУД выступает в качестве PIP). Далее на основе этих групп локальная политика сервиса определяет возможности доступа пользователя к той или иной функциональности (продукт выполняет функции PDP и PEP).

В платформе есть такие open source-сервисы, которые сами не умеют разграничивать доступ пользователей, например, Apache Flink или MLFlow. Авторизация доступа пользователей к этим сервисам происходит на шлюзе авторизации, который создан на основе Apache KNOX. Он получает привилегии пользователя, соответствующие его группам в LDAP СУД, и проверяет возможность доступа пользователя к сервисам за шлюзом при помощи Ranger plugin, который хранит и обновляет политику доступа, получаемую с Apache Ranger. При этом ядро СУД выполняет функции PIP, а шлюз авторизации на основе KNOX — функции PDP и PEP.

Сейчас Сервис управления доступом архитектурно выглядит так:

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

Итак, за несколько лет развития СУД прошёл путь от сервиса, агрегирующего роли пользователей, до полноценной платформы управления доступом, которая объединяет модели доступа других сервисов, предоставляет различные возможности по их изменению, обеспечивает централизованную авторизацию, интегрируется с корпоративными и open source-решениями, адаптируется под новые вызовы, становясь подсистемой доступа для ИИ-агентов, и постепенно превращается в единую точку управления доступом в ПКБ.