[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > [Рекомендации по защите облачной инфраструктуры](index.md) > Чеклист безопасности аутентификации и авторизации

# Чеклист безопасности аутентификации и авторизации

В разделе собраны рекомендации по защите аутентификации, авторизации и доступа к ресурсам Yandex Cloud.

## Аккаунты {#accounts}

✓ **Защитите аккаунты на Яндексе**: включите [двухфакторную аутентификацию](https://yandex.ru/support/passport/authorization/twofa.html) для своего [Яндекс ID](../../iam/concepts/users/accounts.md#passport) и аккаунтов пользователей организации.

✓ **Настройте MFA для федеративных и локальных аккаунтов**: включите [многофакторную аутентификацию](../../organization/concepts/mfa.md) для [федеративных](../../iam/concepts/users/accounts.md#saml-federation) и [локальных](../../iam/concepts/users/accounts.md#local) аккаунтов и задайте требования в политиках MFA.

✓ **Используйте федерацию удостоверений**: настройте [SAML-совместимую федерацию удостоверений](../../organization/concepts/add-federation.md), чтобы сотрудники входили в Yandex Cloud с корпоративными аккаунтами из внешних систем.

✓ **Используйте пулы пользователей для локальных аккаунтов**: [пулы пользователей](../../organization/concepts/user-pools.md) помогают централизованно управлять локальными пользователями в , доменами, правами доступа и настройками аутентификации.

✓ **Настройте SSO для внешних систем**: используйте [приложения в Yandex Identity Hub](../../organization/concepts/applications/index.md), если Yandex Cloud должен выступать как поставщик удостоверений (IdP) для внешних сервисов.

## Роли и ресурсы {#resources-and-roles}

✓ **Соблюдайте принцип минимальных привилегий**: [назначайте](../../iam/operations/roles/grant.md) сервисные роли вместо примитивных и выдавайте только те права, которые нужны сейчас. Учитывайте [наследование ролей](../../iam/concepts/access-control/index.md#inheritance) и назначайте роли [администратора](../../iam/roles-reference.md#admin), [владельца](../../resource-manager/security/index.md#resource-manager-clouds-owner) и `editor` только тем, кому они действительно нужны.

✓ **Используйте политики авторизации**: с помощью [политик авторизации](../../iam/concepts/access-control/access-policies.md) управляйте разрешениями на операции в каталоге, облаке или организации для всех типов субъектов.

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

✓ **Защитите привилегированные роли**: назначайте их федеративным или локальным аккаунтам, а не аккаунтам на Яндексе. Так вы сможете применять MFA и централизованно управлять доступом.

   * **Ограничьте использование `billing.accounts.owner`**: применяйте эту роль только для первоначальной настройки и редких изменений. Для повседневного управления платежным аккаунтом назначьте сотруднику роль `admin`, `editor` или `viewer`. Для Яндекс ID с ролью `billing.accounts.owner` включите 2FA, задайте сложный пароль и не используйте его без необходимости.

   * **Защитите `organization-manager.organizations.owner`**: передайте роль федеративному или локальному аккаунту, затем удалите из организации аккаунт на Яндексе с этой ролью. Для защиты резервного Яндекс ID используйте сложный пароль и входите в него только при сбоях федерации. Порядок действий описан в статье [Удаление аккаунта на Яндексе из организации](../operations/account-deletion.md).

✓ **Регулярно проводите аудит доступов**: проверяйте права пользователей и сервисных аккаунтов с помощью [модуля CIEM](../../security-deck/concepts/ciem.md) или [Yandex Cloud CLI](../../cli/index.md), отзывайте избыточные роли и блокируйте либо удаляйте неиспользуемые учетные записи старше 30 дней.

✓ **Используйте корректную ресурсную модель**:

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

## Сервисные аккаунты {#service-accounts}

✓ **Используйте сервисные аккаунты для автоматизации**: дату и время последней аутентификации можно проверить на странице сервисного аккаунта в консоли управления.

✓ **Создавайте отдельные сервисные аккаунты для разных задач**: так проще ограничивать роли и отзывать доступ без влияния на другие процессы.

✓ **По возможности используйте имперсонацию**: [имперсонация](../../iam/operations/sa/impersonate-sa.md) позволяет временно выполнять действия от имени сервисного аккаунта без генерации статических учетных данных.

✓ **Используйте IAM-токены**: [IAM-токен](../../iam/concepts/authorization/iam-token.md) действует 12 часов, поэтому безопаснее долгоживущих ключей. Скомпрометированный или ненужный токен [отзовите](../../iam/operations/iam-token/revoke-iam-token.md). О выпуске токена читайте в [инструкции](../../iam/operations/iam-token/create-for-sa.md).

✓ **Контролируйте использование ключей**: на странице сервисного аккаунта в [консоли управления](https://kz.console.yandex.cloud) отслеживайте дату и время последнего использования ключей и удаляйте неиспользуемые.

✓ **Ограничивайте области и срок действия API-ключей**: создавайте ключи только с нужными [областями](../../iam/concepts/authorization/api-key.md#scoped-api-keys) и минимальным сроком действия.

✓ **Регулярно ротируйте ключи сервисных аккаунтов**: [авторизованные](../../iam/concepts/authorization/key.md) и [статические ключи](../../iam/concepts/authorization/access-key.md) без срока действия ротируйте самостоятельно, как минимум раз в 90 дней. Рассмотрите использование [эфемерных ключей](../../iam/concepts/authorization/ephemeral-keys.md) или [Secure Token Service](../../iam/concepts/authorization/sts.md) для доступа к Object Storage.

✓ **Используйте федерации сервисных аккаунтов**: [федерации сервисных аккаунтов](../../iam/concepts/workload-identity.md) позволяют обменивать токены внешних OIDC-совместимых систем на IAM-токены без использования долгоживущих учетных данных.

✓ **Используйте ID-токены для внешних систем**: [ID-токены](../../iam/concepts/authorization/id-token.md) подходят для аутентификации сервисных аккаунтов во внешних OIDC-совместимых системах.

✓ **Для операций изнутри ВМ привязывайте сервисный аккаунт к виртуальной машине**: тогда не придется хранить ключи на ВМ, а IAM-токен будет доступен через [сервис метаданных](../../compute/operations/vm-connect/auth-inside-vm.md#auth-inside-vm).

## Секреты {#secrets}

✓ **Отслеживайте секреты Yandex Cloud в открытых источниках**: сервис позволяет обнаруживать API-ключи, IAM Cookies, IAM-токены, статические ключи доступа и серверные ключи Yandex SmartCaptcha. [Подробнее](../operations/search-secrets.md).

✓ **Отзывайте секреты, попавшие в открытый доступ**: отзывайте и перевыпускайте их, проверяйте несанкционированные действия, удаляйте лишние ресурсы и сообщайте об инциденте в [службу технической поддержки](https://kz.center.yandex.cloud/support). [Подробнее](../../iam/operations/compromised-credentials.md).

✓ **Храните ключи и токены в Yandex Lockbox**: сохраняйте их в [секретах Yandex Lockbox](../../lockbox/tutorials/static-key-in-lockbox/index.md) и используйте полезную нагрузку секретов при обращении к ним.

✓ **Используйте OS Login для централизованного SSH-доступа**: [OS Login](../../organization/concepts/os-login.md) позволяет управлять доступом к ВМ через Yandex Identity and Access Management и хранить SSH-ключи в профилях Yandex Identity Hub. Чтобы использовать сервис, [включите доступ](../../organization/operations/os-login-access.md) на уровне организации.