Подключиться
Безопасность в Yandex Cloud

Аутентификация и управление доступом

Статья создана

В Yandex Cloud управление идентификацией, аутентификацией и контролем доступа выполняется сервисами Yandex Identity and Access Management (IAM) и Yandex Cloud Organization.

Платформа работает с тремя категориями пользователей:

Аккаунты на Яндексе и федеративные аккаунты аутентифицируются в собственных системах. Yandex Cloud не имеет доступа к паролям этих пользователей и аутентифицирует только сервисные аккаунты с помощью сервиса IAM.

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

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

В данном разделе документации приводятся рекомендации по организации безопасной работы с сервисами Yandex Cloud:

С целью упрощения и автоматизации управления ролевым доступом был подготовлен IAM module (на базе Terraform). Он позволяет организовать группы доступов для пользователей облака и имеет ряд других удобных функций. С IAM модулем и примерами его использования можно ознакомиться в решении.

Централизованное управление и федерации удостоверений

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

Для централизованного управления учетными данными используйте SAML-совместимые федерации удостоверений. С помощью федераций удостоверений компания может настроить Single Sign-On аутентификацию в Yandex Cloud через свой сервер IdP. При таком подходе сотрудники имеют возможность использовать свои корпоративные аккаунты, на которые распространяются политики безопасности компании, такие как:

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

Инструкция по настройке SAML федерации удостоверений.
Инструкция по настройке SAML федерации с KeyCloak.

Совет

Используйте федеративные аккаунты вместо аккаунтов Яндекс ID, где это возможно.

Принцип минимальных привилегий и разграничение полномочий

Принцип минимальных привилегий требует назначать минимально необходимые для работы роли.
Не рекомендуется использовать примитивные роли admin, editor, member, viewer, действующие во всех сервисах. Для более избирательного управления доступом и реализации принципа минимальных привилегий используйте сервисные роли, которые содержат разрешения только для определенного типа ресурсов в указанном сервисе.

Примечание

При добавлении в облако нового пользователя ему автоматически назначается роль участника облака — resource-manager.clouds.member. Роль необходима для работы с облаком и не дает никаких привилегий.

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

Сервисный аккаунт — аккаунт, от имени которого программы могут управлять ресурсами в Yandex Cloud.
Сервисный аккаунт служит для выполнения запросов от имени приложения. Не используйте вместо сервисных аккаунтов аккаунты сотрудников. Если, например, сотрудник уволится или сменит подразделение, то его аккаунт потеряет права, что может привести к сбою приложения.

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

  • Применяйте механизм назначения сервисного аккаунта виртуальной машине и получения токена через сервис метаданных.

  • Настройте локальный файрвол на виртуальной машине так, чтобы только необходимые процессы и пользователи системы имели доступ к сервису метаданных (IP-адрес: 169.254.169.254).
    Пример блокирования доступа от всех пользователей, кроме указанного (в данном случае root):

    sudo iptables --append OUTPUT --proto tcp \
--destination 169.254.169.254 --match owner ! --uid-owner root \
--jump REJECT

  • Храните ключи сервисного аккаунта и управляйте ими с соблюдением требований стандартов.

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

    Примечание

    Существует возможность назначать права на использование сервисного аккаунта от имени другого пользователя или сервисного аккаунта.

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

Двухфакторная аутентификация

Стандарты безопасности требуют использовать двухфакторную аутентификацию (2FA) для доступа к инфраструктуре. Поэтому доступ в консоль Yandex Cloud организован с помощью 2FA.

Чтобы подключить двухфакторную аутентификацию, обратитесь к поставщику удостоверений (identity provider) с поддержкой 2FA и настройте SAML-совместимую федерацию удостоверений.

Для аккаунта Яндекс ID настройте 2FA согласно инструкции.

Управление привилегированными пользователями

К привилегированным пользователям Yandex Cloud относятся аккаунты со следующими ролями:

  • billing.accounts.owner;
  • admin, назначенный на платежный аккаунт;
  • resource-manager.clouds.owner;
  • admin, назначенный на облако;
  • admin, назначенный на каталог.

Роль billing.accounts.owner автоматически выдается при создании платежного аккаунта и не может быть переназначена другому пользователю. Роль позволяет выполнять любые действия с платежным аккаунтом. Роль billing.accounts.owner может быть назначена только аккаунту Яндекс ID. Аккаунт с ролью billing.accounts.owner используется при настройке способов оплаты и подключении облаков.

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

  • Используйте его только при первоначальной настройке и внесении изменений.
  • На время активного использования данного аккаунта включите двухфакторную аутентификацию (2FA) в Яндекс ID.
  • Затем, если вы не используете способ оплаты банковской картой (доступный только для данной роли), назначьте данному аккаунту сложный пароль (сгенерированный с помощью специализированного ПО), отключите 2FA и не используйте этот аккаунт без необходимости.
  • После каждого использования меняйте пароль на сгенерированный заново.

Отключить 2FA рекомендуется только для этого аккаунта и в случае, если аккаунт не "закреплен" за конкретным сотрудником. Эта мера рекомендуется для того, чтобы избежать привязки этого критически важного аккаунта к личному устройству.

Для управления платежным аккаунтом назначьте роль admin или editor на платежный аккаунт выделенному сотруднику организации с федеративным аккаунтом. Для просмотра данных биллинга назначьте роль viewer на платежный аккаунт выделенному сотруднику организации с федеративным аккаунтом.

Роль resource-manager.clouds.owner автоматически выдается при создании облака. Пользователь с этой ролью может выполнять любые операции с облаком и ресурсами в нем, а также выдавать доступ к облаку другим пользователям: назначать роли и отзывать их.

Используйте роль resource-manager.clouds.owner с осторожностью:

  • Назначьте ее одному или нескольким федеративным пользователям в организации.
  • Задайте сложный пароль аккаунту Яндекс ID, от имени которого создано облако. Используйте аккаунт Яндекс ID только в случае крайней необходимости, например, если федерация недоступна.

Федеративный аккаунт с ролью resource-manager.clouds.owner необходимо всесторонне защитить:

  • Включите двухфакторную аутентификацию.
  • Запретите аутентификацию с устройств, не управляемых организацией.
  • Настройте мониторинг попыток входа и задайте пороги предупреждений.

Для просмотра списка идентификаторов текущих аккаунтов с ролью resource-manager.clouds.owner выполните следующий скрипт:

yc resource-manager cloud list-access-bindings \
 --id <идентификатор_облака> \
 --format json | jq -r '.[] | select(.role_id=="resource-manager.clouds.owner") | .subject.id'

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

Особенности аутентификации в сервисе управляемых БД

Для работы с БД на прикладном уровне помимо сервисных IAM ролей создается отдельный пользователь — владелец БД. В отношении него действует следующая парольная политика:

  • пароль должен содержать цифры, буквы в верхнем регистре, буквы в нижнем регистре, специальные символы;
  • длина пароля — не менее 8 символов.

Предоставление доступа к Yandex Cloud подрядным организациям

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

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

Ресурсная модель

При разработке модели доступа для инфраструктуры рекомендуется использовать следующий подход:

  • Все критичные ресурсы поместите в отдельные облака. К критичным относятся в том числе ресурсы, которые связаны с обработкой платежных данных, персональных данных, данных коммерческой тайны.
  • Группы ресурсов, которые требуют различного административного доступа, поместите в различные каталоги (DMZ, CDE, security, backoffice и т. д.).
  • Общие ресурсы (например, сеть и группы безопасности) поместите в отдельный каталог для разделяемых ресурсов.
В этой статье: