Cloud IAM (Identity and Access Management) — это система Yandex Cloud, которая отвечает на один вопрос: «кто и что может делать». Хотите прочитать файл из хранилища, запустить машину, отправить сообщение в очередь — каждый раз облако сверяется с IAM: а разрешено ли вам это.

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

Пользователи против сервисных аккаунтов

Первое различие, в котором путаются новички, — кому вообще выдают доступ. В Cloud IAM «кто-то» бывает двух видов.

Пользователь — это человек: аккаунт в вашей организации (личный Яндекс ID или корпоративная учётка через federation). Люди заходят в консоль, что-то настраивают, смотрят.

Сервисный аккаунт (service account) — это учётная запись для программ и виртуальных машин, а не для человека. У неё нет пароля для входа в консоль; её задача — дать доступ вашему коду. Аналог в AWS — роль, которую «надевает» сервис.

Ключевое правило, которое стоит запомнить сразу: для программ, серверов и автоматизации используют сервисные аккаунты, а не личные ключи человека. Личные учётки — для людей, сервисные аккаунты — для кода.

Роли и привязки

В отличие от AWS с его JSON-политиками, в Yandex Cloud права выдаются проще: роль + привязка.

Роль (role) — именованный набор разрешений. Есть примитивные роли на широкий доступ:

  • viewer — только смотреть;
  • editor — создавать и менять ресурсы;
  • admin — плюс раздавать доступ другим.

И множество узких сервисных ролей вида storage.editor (управлять объектным хранилищем), compute.viewer (смотреть виртуальные машины), ydb.editor (работать с базой YDB). Узкие роли — то, что нужно на практике: они дают доступ только к одному сервису.

Привязка (role binding) — это назначение «кому — какую роль — на каком ресурсе». Роль выдают на облако, на каталог или на отдельный ресурс, и права наследуются вниз: роль, выданная на каталог, действует на все ресурсы внутри него. Обычно доступ выдают на уровне каталога — это удобная граница.

yc iam service-account create --name orders-app
yc resource-manager folder add-access-binding my-folder \
  --role storage.editor \
  --service-account-name orders-app

Здесь мы завели сервисный аккаунт orders-app и дали ему право управлять объектным хранилищем в пределах каталога my-folder. Никаких JSON-документов — только «субъект, роль, ресурс».

Least privilege — минимум прав

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

Самый частый дефект новичка — выдать сервисному аккаунту editor или admin на весь каталог, «чтобы просто заработало». Так делают, чтобы не возиться, — и именно это потом превращается в инцидент: одна утёкшая такая учётка открывает злоумышленнику весь каталог.

На практике least privilege — это итеративный процесс:

  1. Начните узко — дайте минимум сервисных ролей, который точно нужен (например, только storage.editor и ydb.editor).
  2. Запустите, посмотрите, чего не хватает (отказы видны в логах доступа).
  3. Добавьте недостающую роль. Повторяйте.

Дольше, чем выдать всё сразу, — но именно «узко и по факту» отделяет нормальную работу от заголовка про очередную утечку.

IAM-токен: как код получает доступ

За доступом всегда стоит короткоживущий IAM-токен. Он живёт около 12 часов, после чего протухает — этим и хорош: даже если токен утечёт, назавтра он бесполезен.

Самое важное для новичка — понять, откуда токен берётся в приложении, чтобы не хранить в коде ни одного секрета:

  • На виртуальной машине к ней привязывают сервисный аккаунт, и приложение получает IAM-токен прямо из сервиса метаданных машины (специальный внутренний адрес 169.254.169.254). SDK и CLI забирают и обновляют токен автоматически — вам не надо ничего писать. Это тот же принцип, что instance role в AWS.
  • В Managed Kubernetes узлам и рабочим нагрузкам доступ выдают через привязанный сервисный аккаунт по той же модели.
  • Извне облака (например, из CI, который живёт не в Yandex Cloud) используют авторизованный ключ сервисного аккаунта — JSON-файл, которым обмениваются на IAM-токен. Такой ключ — долгоживущий секрет, поэтому его держат в защищённом хранилище CI, а не в git, и регулярно ротируют.

Правило простое: код внутри облака — через привязанный сервисный аккаунт и метаданные; ключ-файл — только там, где иначе никак.

Организация, каталоги и федерация

Доступ живёт в иерархии организация → облако → каталог. Роли, выданные выше, наследуются ниже, поэтому «где выдать привязку» — это выбор границы: на каталог staging — значит на все его ресурсы, но не на production.

Для компаний людей обычно подключают не по личным Яндекс ID, а через federation (SSO): настраивается доверие к корпоративному провайдеру входа (по протоколу SAML), и сотрудники заходят под рабочими учётками. Права таким пользователям удобно выдавать не по одному, а через группы: группе — роль на каталог, а состав группы меняется отдельно.

Где это применяется

Cloud IAM — это слой «кто что может делать» поверх сетевого слоя «кто до кого вообще может достучаться». Вместе они дают полноценную защиту: минимальная сеть плюс минимальные права. Осваивать их стоит в паре.

Где вы столкнётесь с IAM сразу:

  • Любой ваш сервис (виртуальные машины, бессерверные функции, контейнеры) получает доступ к другим сервисам через привязанный сервисный аккаунт.
  • Конвейеры доставки кода (CI/CD) работают через сервисный аккаунт и авторизованный ключ, а не через зашитые пароли.
  • Секреты и шифрование — соседняя тема: где хранить пароли, разбирается в безопасности и наблюдаемости.

Типичные ошибки новичков:

  • Класть авторизованный ключ сервисного аккаунта в код или git вместо привязки аккаунта к машине.
  • Выдавать editor/admin на весь каталог «чтобы заработало», а потом забыть сузить до сервисных ролей.
  • Удивляться, что доступа нет: часто привязку выдали не на том уровне иерархии или не тому субъекту.

Что учить дальше: как хранят секреты и шифруют данные — в безопасности и наблюдаемости; как роли описываются в инфраструктуре-как-коде вместо кликов в консоли — в Terraform. Модель близка к IAM в AWS — роли и временные токены вместо вечных ключей устроены там аналогично.