Привет, Хабр! Меня зовут Михаил Кажемский, я ведущий DevOps‑инженер в системном ИТ‑интеграторе Hilbert Team. В этой статье мы с моим коллегой Алексеем Колосковым объясним, как разобраться с тонкостями управления доступом в облаке. Материал будет полезен специалистам по ИБ, техническим руководителям и DevOps‑инженерам, которые только начинают свою работу с Yandex Cloud и хотят быстро разобраться с особенностями этого облака.
Предположим, что у вас появилась задача развернуть сервис на виртуальной машине в Yandex Cloud. Казалось бы, всё просто: создал виртуальную машину, развернул приложение, и всё готово. В общем случае это работает именно так, но лишь при условии, что кто‑то уже настроил для вас все доступы и выдал вам все необходимые права.
Но что делать, если тот самый человек, которому нужно всё настроить — это вы сами? Для этого предстоит разобраться с базовыми особенностями ресурсной модели и управления доступами в Yandex Cloud. Обо всём этом мы расскажем в статье.
Какие шаги предстоит пройти
Если нужно впервые запустить своё приложение в Yandex Cloud, например, для оценки применимости облака для бизнеса, то желательно продумать все шаги перед миграцией. В этом случае пригодится краткий гид для быстрой настройки доступов, как с точки зрения бизнес‑логики, так и с точки зрения безопасности. В нашей статье в качестве примера мы рассмотрим особенности организации доступа для приложения, которое помимо стандартных виртуальных машин использует объектное хранилище для размещения файлов.
Кратко план действий в этом случае будет выглядеть так.
Создать в Yandex Cloud организацию‑владельца нашего приложения.
Создать в ней платёжный аккаунт, чтобы иметь возможность создавать и оплачивать виртуальные машины, хранилище и другие ресурсы облака.
Создать в консоли управления облако и каталог, где далее будет создана виртуальная машина.
Настроить права доступа для своей команды.
Создать виртуальную машину.
Создать сервисные аккаунты для этой виртуальной машины.
Поднять приложение, которое с помощью этих сервисных аккаунтов будет «стучаться» в объектное хранилище.
Настроить доступ приложения к объектному хранилищу.
Настроить мониторинг безопасности в облаке.
Давайте пройдёмся по шагам настройки доступа для каждого пункта. В статье воспользуемся материалами из нашего бесплатного курса «Аутентификация и управление доступами», который мы разработали совместно с Yandex Cloud.
Что такое ресурсная модель облака
Ресурсная модель — это иерархическая модель сущностей, которая позволяет упорядочивать облачные ресурсы и обеспечивать необходимый уровень изоляции между ними. В Yandex Cloud управлять ресурсами помогает сервис Yandex Resource Manager.
На схеме ресурсной модели Yandex Cloud видим её основные элементы. Рассмотрим их от меньшего к большему, справа налево.
Ресурс — виртуальный объект, который создаётся и обслуживается конкретным сервисом облачного провайдера. Для нашего примера: приложение работает на виртуальной машине. Её данные хранятся на диске, а файлы, с которыми работает приложение — в объектном хранилище. Сеть обеспечивает доступ пользователей к приложению и доступ приложения к объектному хранилищу. Обратиться к нему можно по фиксированному DNS‑имени и соответствующему ему IP‑адресу.
Все перечисленные сущности: виртуальная машина, её диск, хранилище, сеть, IP‑адрес — это ресурсы облака.
Пользоваться ими можно через различные сервисы. Например, виртуальная машина и её диски — это часть сервиса Compute Cloud. Сеть и подсети являются частью сервиса Virtual Private Cloud. Объектное хранилище — частью Object Storage.
Каталог — это пространство, в котором создаются и группируются ресурсы. Можно группировать их по типу, проекту, отделу или по любому другому признаку.
При создании ресурса необходимо указать каталог, в котором он будет храниться. Каталоги имеют плоскую структуру — нельзя создать новый каталог внутри уже существующего.
Более сложную иерархию создают облака — изолированные пространства, в которых создаются каталоги. Каталог может принадлежать только одному облаку.
В одном облаке обычно достаточно простой иерархии: на один проект можно выделить один каталог внутри общего облака. В крупной компании со множеством направлений и проектов лучше разделить ресурсы по разным облакам.
Yandex Cloud Organization — это структурная единица, которая позволяет управлять списком сотрудников и их уровнем доступа к облачным сервисам Yandex Cloud. Даже если ресурсы в облаке арендует не юридическое лицо, а разработчик, ему нужно создать свою «организацию» как логическую сущность.
Все облака принадлежат организациям, внутри одной организации может быть создано несколько облаков. Разные организации и их ресурсы изолированы друг от друга.
А теперь, когда мы разобрались в устройстве ресурсной модели, расскажем о принципах аутентификации и авторизации в Yandex Cloud.
Управление доступом в Yandex Cloud
За управление доступом в Yandex Cloud отвечает Yandex Identity and Access Management (IAM) — это сервис идентификации и контроля доступа (авторизации).
Вы определяете, кто и какие права имеет на ресурс, а IAM предоставляет доступ в соответствии с ними.
Допустим, пользователь хочет создать диск в каталоге. Схема показывает, как IAM в этой ситуации следит, чтобы операции над ресурсами дисков выполнялись только пользователями с необходимыми правами.
Посмотрим, какие аккаунты мы можем создавать для разных пользователей.
Идентификация и аутентификация пользователей в Yandex Cloud
В Yandex Cloud для идентификации и аутентификации пользователей, выполняющих операции с ресурсами, есть несколько видов аккаунтов:
пользовательские аккаунты Yandex Cloud, их существует два типа: Яндекс ID и Яндекс 360);
федеративные аккаунты;
сервисные аккаунты;
платёжные аккаунты.
Пользовательский аккаунт Yandex Cloud — это личный аккаунт на Яндексе (Яндекс ID) или аккаунт в Яндекс 360 для Бизнеса. Обычно такой аккаунт используется при начальной настройке облака и для доступа к биллингу и консоли облака.
Давайте разберёмся, чем они отличаются. Если вы входили в почту или регистрировались в других сервисах Яндекса, у вас уже есть единый аккаунт Яндекс ID. Он также используется для мобильных приложений и сайтов, которые поддерживают его авторизацию. Аккаунт Яндекс 360 предназначен для пользователей бизнес‑сервисов, в нём используется свой домен, зарегистрированный на вас или вашу организацию. Для регистрации организации в Яндекс 360 необходим аккаунт Яндекс ID.
Для оплаты ресурсов также необходимо создать отдельный аккаунт, его называют платёжным или биллинг‑аккаунтом. Важно отметить, что платёжный аккаунт не используется для управления ресурсами Yandex Cloud и не относится к сервису IAM. Такой аккаунт нужен для идентификации плательщика и хранения информации о нём. С одного платёжного аккаунта можно оплачивать ресурсы нескольких облаков, а облако может быть привязано только к одному платёжному аккаунту.
Биллинг‑аккаунт может быть не связан напрямую с конкретным человеком. Для платежей есть два типа аккаунтов: личный и бизнес‑аккаунт. Отличие в том, что для бизнес‑аккаунтов предусмотрено два варианта оплаты используемых ресурсов: автоматическое списание с банковской карты или банковский перевод на основании договора и выставленного Yandex Cloud счёта. Для личных аккаунтов доступен только первый вариант.
Федеративный аккаунт — это аккаунт во внешних по отношению к Яндексу системах, которые поддерживают технологии аутентификации. Например, аккаунт в службе каталогов Active Directory.
С помощью федерации удостоверений компания может настроить аутентификацию в Yandex Cloud через свой сервер. Это позволит сотрудникам компании использовать свои корпоративные аккаунты для работы в Yandex Cloud.
Сервисные аккаунты — это специальные аккаунты, с помощью которых приложения могут выполнять операции в Yandex Cloud.
Сервисные аккаунты не привязаны к конкретному сотруднику. От имени сервисного аккаунта вы можете выполнять операции через API, CLI и другие инструменты, которые поддерживают аутентификацию с ним. Но войти в консоль управления с помощью сервисного аккаунта нельзя. Для нашего приложения из примера такой аккаунт пригодится для настройки доступа к данным хранилища, о чём мы поговорим в конце статьи.
Как мы помним, аутентификация — это процедура проверки подлинности. Она происходит по‑разному в зависимости от типа аккаунта и используемого интерфейса. Для пользовательских аккаунтов аутентификация происходит автоматически, когда вы входите в Яндекс ID или Яндекс 360. Для федеративных аккаунтов потребуется предварительная настройка федерации удостоверений с помощью внешних систем (Identity Provider), а для сервисных — настройка использования одного из типов ключей для аутентификации.
Для чего это нужно: после аутентификации, как через пользовательский, так и через сервисный или федеративный аккаунт, сервис IAM выдаёт пользователю IAM‑токен — уникальную последовательность символов. Процесс получения и использования токена незаметен для пользователя, работающего через консоль управления или интерфейс командной строки (CLI), но именно с его помощью пользователь авторизуется для работы с API Yandex Cloud и выполнения операции с ресурсами. IAM‑токен действует не больше 12 часов.
Авторизация
Теперь разберёмся с авторизацией. Напомним, что авторизация — это предоставление лицу или группе лиц прав на выполнение определённых действий.
Любой процесс авторизации можно разбить на компоненты:
субъект доступа — пользователь или группа пользователей, которые хотят получить доступ;
объект доступа — объект, к которому субъект пытается получить доступ;
авторизатор — компонент, который принимает решение, разрешить или запретить доступ субъекта к объекту.
Схематично процесс авторизации изображен на рисунке:
Получается, что с точки зрения авторизации субъект в Yandex Cloud — это какой‑то из аккаунтов, кроме платежного, объект — это сервис или ресурс в облаке, а авторизатором выступает сервис IAM.
Теперь переходим к ролевой модели управления доступом.
Ролевая модель доступа в Yandex Cloud
В Yandex Cloud используется модель управления доступом на основе ролей (Role-Based Access Control, RBAC).
RBAC представляет собой механизм управления доступом, при котором отдельные права доступа к объектам группируются в роли, а те, в свою очередь, назначаются субъектам. Обычно роли соответствуют простым бизнес-задачам.
Роль — это набор разрешений, который определяет допустимые операции с ресурсами в Yandex Cloud. Можно назначать роли аккаунтам, облаку, каталогу и другим ресурсам.
Назначать роли могут только администраторы или владельцы облака, при этом уровень назначаемых прав не должен быть выше, чем у пользователя, который их выдаёт. Например, чтобы назначить роль владельца облака, пользователь должен сам обладать этой ролью — роли администратора недостаточно.
Роли на ресурс назначаются в виде списка связей ролей и субъектов. Такие связи называют привязками прав доступа или access bindings. Вы можете добавлять и удалять эти связи, таким образом контролируя права доступа к ресурсу. Одна привязка — одно назначение роли субъекту. Каждому субъекту можно создавать несколько привязок.
Типы субъектов:
userAccount— аккаунт на Яндексе, добавленный в Yandex Cloud.serviceAccount— сервисный аккаунт, созданный в Yandex Cloud. Ему можно назначить роли на ресурсы и сервисы в разных облаках и каталогах организации.federatedUser— аккаунт пользователя федерации удостоверений, например из Active Directory или Keycloak.group— группа пользователей, созданная в Yandex Cloud Organization.system— системная группа.
Часто пользователи могут иметь одинаковый набор ролей, поэтому для упрощения управления доступом можно объединить таких пользователей в группы. Скажем, трёх внешних разработчиков с одинаковыми правами можно просто объединить в группу «Внешние разработчики».
В Yandex Cloud также есть специальные системные группы allAuthenticatedUsers и allUsers. С ними можно назначать доступы для всех пользователей сервиса — как аутентифицированных, так и неаутентифицированных. Например, это может понадобиться для доступа в объектное хранилище всех пользователей.
Далее разберём, какие роли можно назначать. Начнём с примитивных и сервисных ролей.
Примитивные и сервисные роли
Примитивные роли содержат разрешения, действующие для всех типов ресурсов Yandex Cloud. Это роли admin, editor и viewer.
viewerдаёт разрешения на просмотр ресурсов.editorдаёт разрешения на все операции для управления ресурсом, кроме назначения ролей другим пользователям.adminдаёт все разрешения для управления ресурсом, включая назначение ролей другим пользователям.
Разрешения ролей наследуются. Это значит, что все разрешения роли viewer содержатся в роли editor, а разрешения роли editor содержатся в роли admin.
Сервисные роли содержат разрешения только для определённого типа ресурсов в сервисе. Идентификатор сервисной роли указывается в формате service.resources.role. Например, роль compute.images.user позволяет использовать образы в сервисе Yandex Compute Cloud.
На примере иерархии ролей сервиса Yandex Compute Cloud можно увидеть, какие роли бывают у сервиса и как они наследуют разрешения друг друга.
Например, роль viewer включает все полномочия compute.viewer, а editor включает все полномочия viewer.
Количество ролей и порядок их наследования в сервисах может изменяться с развитием Yandex Cloud.
Если у объекта, например, облака или каталога, есть дочерние ресурсы, то они унаследуют все разрешения родителя. Например, если вы назначите пользователю роль на каталог, в котором лежит виртуальная машина, то все разрешения этой роли будут действовать и для виртуальной машины.
Матрица ролей
Часто возникает вопрос, зачем создавать большое количество ролей и почему нельзя просто использовать примитивные роли (admin, editor и viewer). Возьмём ситуацию, когда вам нужно дать права доступа внешним разработчикам. Если назначить им роль viewer, то они смогут просматривать вообще все ресурсы в облаке, что нежелательно. А если дать внешним разработчикам роль editor, они смогут управлять всеми ресурсами, и это уже слишком рискованно. Большое количество ролей даёт возможность гранулярной настройки доступа любому сотруднику. Для этого существует матрица ролей.
Наделить правами группу пользователей гораздо проще, чем каждого по отдельности. Если объединить сотрудников по их функциям, это поможет определить, какие именно сервисные роли должны быть выданы группам.
Пример матрицы ролей для нашего гипотетического случая:
Пользователи | Группы | Названия групп | Полномочия сотрудников |
egor | Администратор облака | devops | Может управлять всеми ресурсами облака. |
vladimir, mumshad, anastasia | Сотрудники внешней команды разработки | external-developers | Имеют доступ к сервисам Compute. Могут пользоваться ресурсами сети и сервисными аккаунтами. |
mikhail | Billing Admin | admin | Управляет доступом в облака и выдачей квот. |
ivan | Специалист по ИБ | security | Может видеть все ресурсы облака и операции с ними. |
dmitry | Сетевой администратор | network-admin | Имеет административный доступ ко всем ресурсам сети. |
В вашем случае матрица ролей может выглядеть иначе.
Привилегированные аккаунты
Привилегированные аккаунты требуют дополнительной защиты. К ним в Yandex Cloud относятся аккаунты со следующими ролями:
billing.accounts.owner;resource-manager.clouds.owner;admin, назначенная на платежный аккаунт;admin, назначенная на облако;admin, назначенная на каталог.
billing.accounts.owner — это роль, которая автоматически выдаётся пользователю при создании платежного аккаунта и не может переназначаться другому пользователю. Роль позволяет выполнять любые действия с платежным аккаунтом и назначается только аккаунту Яндекс ID. Аккаунт с ролью billing.accounts.owner используется при настройке способов оплаты и подключении облаков. При попытке создать платёжный аккаунт от лица федеративного пользователя вы получите ошибку.
Роль resource-manager.clouds.owner автоматически выдаётся при создании облака. Пользователь с этой ролью может выполнять любые операции с облаком и ресурсами в нём. Он также может выдавать доступ к облаку другим пользователям, назначать роли и отзывать их.
organization-manager.organizations.owner — это роль владельца организации.
Она даёт возможность назначать владельцев организации и пользоваться всеми полномочиями администратора. Пользователь с этой ролью может назначать администраторов организации и всех нижележащих сущностей, например, облаков и каталогов. По умолчанию владелец организации — это её создатель.
Примитивную роль admin стоит использовать в исключительных случаях, так как она даёт пользователю полный доступ ко всем ресурсам облака или каталога. admin может назначать роли другим пользователям, что позволяет выполнять любые, в том числе деструктивные действия со всеми ресурсами облака или каталога. Например, он может удалить виртуальную машину со всеми дисками и данными.
Подробнее о защите таких аккаунтов рекомендуем прочитать в документации.
Управление доступом в Yandex Object Storage
Итак, мы рассмотрели основные понятия и принципы, которые помогут настроить доступ для виртуальной машины, где можно будет запустить наше приложение. Но поскольку приложению также понадобится доступ в объектное хранилище, рассмотрим особенности организации доступа для него на примере Yandex Object Storage.
Сервис Yandex Object Storage — это масштабируемое объектное хранилище, которое обеспечивает быстрый доступ к данным произвольного формата. Он поддерживает взаимодействие с объектами хранилища посредством API. API Object Storage, за некоторым исключением, совместим с API AWS S3, это позволяет управлять объектами через сторонние инструменты, предназначенные для работы с S3.
В терминах Yandex Object Storage файлы и папки — это объекты. Все объекты размещаются в контейнерах — бакетах, и содержат пользовательские данные в том виде, в котором они были загружены. Бакет — это логическая сущность, которая помогает организовать хранение объектов.
Проверка доступа происходит на трёх уровнях. Сначала процедуру проводит сервис IAM, а затем действуют отдельные механизмы объектного хранилища: политика доступа (bucket policy) и в самом конце наступает черёд списка управления доступом (ACL).
Если запрос прошёл проверку IAM, к нему применяется проверка политики доступа.
Проверка правил политики доступа происходит так:
Если запрос подошёл хотя бы под одно из правил
Deny, доступ будет запрещён. Последующая проверка не выполняется.Если запрос подошёл хотя бы под одно из правил
Allow, доступ будет разрешён.Если запрос не подошёл ни под одно из правил, доступ будет запрещён.
Если запрос не прошёл проверку IAM или политики доступа, то применяется проверка доступа через ACL конкретного объекта.
Если запрос подошёл хотя бы под одно из правил Deny, доступ будет запрещён. Последующая проверка не выполняется.
Если запрос подошёл хотя бы под одно из правил Allow, доступ будет разрешён.
Если запрос не подошёл ни под одно из правил, доступ будет запрещён.
Увидеть, как работает алгоритм проверки доступа, можно на схеме:
Сервисные аккаунты и особенности работы с ними в Yandex Cloud
Уделим отдельное внимание сервисным аккаунтам, от имени которых приложения могут управлять ресурсами в Yandex Cloud.
Наше приложение из примера получает данные из S3-совместимого объектного хранилища Yandex Object Storage. Ему достаточно иметь права на просмотр, то есть роль viewer. Но программа работает от вашего имени, а вы — editor с правами на изменение и удаление объектов. Чтобы защититься от случайного удаления объекта программой, нужно создать сервисный аккаунт с доступом только на просмотр.
В этом контексте важно отметить отличия сервисных аккаунтов от других типов аккаунтов:
Подразумевается, что операции от имени сервисного аккаунта будут выполнять приложения, а не люди.
Соответственно, сервисные аккаунты нельзя использовать для входа в консоль управления.
С точки зрения управления доступом сервисный аккаунт ведёт себя как ресурс. Это значит, что можно назначать и отзывать роли на него у других пользователей.
Для сервисного аккаунта можно создать ключи, используемые для аутентификации в Yandex Cloud через API, CLI и другие инструменты. При удалении сервисного аккаунта эти ключи тоже будут удалены.
Сервисный аккаунт можно привязывать к виртуальным машинам, в которых запускается ваша программа. Это упрощает масштабирование приложений, работающих с Yandex Cloud.
Для аутентификации сервисного аккаунта в Yandex Cloud можно использовать различные инструменты:
авторизованные ключи для получения IAM‑токена;
API‑ключи — в некоторых сервисах они используются для упрощенной аутентификации вместо IAM‑токена;
статические ключи доступа — в сервисах с AWS‑совместимым API.
Мониторинг безопасности с помощью Audit Trails
Когда вы уже настроили права доступа, то осталось последнее — обезопасить облачную инфраструктуру приложения через логирование событий аудита.
Yandex Audit Trails — инструмент, который позволяет собирать журналы событий в режиме реального времени для последующего анализа. С ним можно быстро выявлять потенциальные угрозы безопасности — попытки входа в систему или получения доступа к конфиденциальной информации неавторизованными пользователями.
Аудитные логи в Yandex Audit Trails — это записи в формате JSON, которые содержат информацию о действиях пользователей в системе, например, о входах в систему, изменении настроек и получении доступа к файлам. Сбор и анализ аудитных логов позволяет отслеживать действия пользователей и обеспечивает безопасность системы.
Если в облачной инфраструктуре происходят какие-то необычные или подозрительные действия, администраторы смогут быстро их обнаружить и принять меры для защиты системы.
Yandex Audit Trails поддерживает три механизма выгрузки аудитных логов:
выгрузку аудитных логов в бакет Object Storage;
отправку аудитных логов в Cloud Logging;
отправку аудитных логов в поток данных Yandex Data Streams.
Используя эти механизмы, можно обрабатывать и анализировать аудитные логи различными способами, например:
искать события по аудитным логам в бакете или лог‑группе с помощью Yandex Query;
загружать аудитные логи в различные SIEM;
настраивать алерты в Yandex Monitoring.
Инструменты и способы работы с аудитными логами можно условно разделить на три группы:
Выгрузка аудитных логов в какое‑либо хранилище для дальнейшего ручного анализа. К таким хранилищам можно отнести бакет в Yandex Object Storage или лог‑группу в Yandex Cloud Logging.
Настройка реагирования по событиям аудитного лога. Это можно реализовать, например, настроив алерты или реагирования на события.
Выгрузка событий аудитного лога во внешнюю SIEM-систему, например:
Итого
В заключение ещё раз кратко перечислим все шаги, которые необходимо пройти, чтобы безопасно поднять приложение в облаке:
Создать в Yandex Cloud организацию-владельца приложения.
Создать в ней платёжный аккаунт, чтобы иметь возможность создавать и оплачивать виртуальные машины, хранилище и другие ресурсы облака.
Создать в консоли управления облако и каталог, где далее будет создана виртуальная машина.
Настроить права доступа для своей команды.
Создать виртуальную машину.
Создать сервисные аккаунты для этой виртуальной машины.
Поднять приложение, которое с помощью этих сервисных аккаунтов будет «стучаться» в объектное хранилище.
Настроить доступ приложения к объектному хранилищу.
Настроить мониторинг безопасности в облаке.
Полезные ссылки:
Попрактиковаться в создании защищённой облачной структуры на бесплатном курсе Hilbert Team и Yandex Cloud «Аутентификация и управление доступами»;
Посмотреть вебинар Yandex Cloud «Управление доступами в облаке»;
Подписаться на канал Hilbert Team в Telegram, чтобы не пропустить выход новых материалов о безопасности, DevOps, FinOps и Data Tech.