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

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

АккаунтыАккаунты

✓ Защита аккаунтов на Яндексе:

• Включите для своего аккаунта Яндекс ID и аккаунтов пользователей вашей организации двухфакторную аутентификацию.
• Держите в секрете ваш OAuth-токен. Если кто-то мог узнать ваш OAuth-токен, отзовите его и выпустите новый. Старайтесь не использовать OAuth-токен для аутентификации, если можно использовать IAM-токен. OAuth-токен действует 1 год, а IAM-токен — 12 часов.

✓ Федерация удостоверений (Single Sign-On, SSO): для централизованного управления учетными данными используйте SAML-совместимые федерации удостоверений. С помощью федераций удостоверений компания может настроить Single Sign-On аутентификацию в Yandex Cloud через свой сервер-поставщик удостоверений — так ваши сотрудники смогут получить доступ к сервисам Yandex Cloud с помощью своих корпоративных аккаунтов и вы сможете управлять пользователями в консоли управления Yandex Cloud. Настройте двухфакторную авторизацию на стороне поставщика удостоверений.

Роли и ресурсыРоли и ресурсы

✓ Принцип минимальных привилегий: назначайте сервисные роли (например, compute.images.user) вместо примитивных (auditor, viewer, editor, admin), см. список всех ролей.

• Назначайте только роли, которые необходимы сейчас. Не назначайте роли, которые могут потребоваться только в будущем.
• Помните, что когда вы назначаете роль на каталог, облако или организацию, разрешения этой роли унаследуют все вложенные ресурсы.
• Назначайте роль администратора только тем пользователям, которые должны управлять доступом к ресурсам.
• Назначайте роль владельца облака или организации только тем, кто должен совершать любые действия с ресурсами. Администратор может лишить прав доступа другого администратора, а владелец — отозвать у другого владельца его роль.
• Назначайте пользователям сервисные и примитивные роли уровня editor, чтобы создавать и удалять ресурсы.
• Применяйте имперсонацию — пользователи могут выполнять необходимые действия с ресурсами облака от имени сервисного аккаунта. Используйте сервисные аккаунты с нужными ролями вместо назначения ролей отдельным пользователям. Такой подход применяется, чтобы временно расширить права пользователя, не прибегая к генерации статических учетных данных.

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

✓ Защита billing.accounts.owner: после выполнения первоначальных операций не используйте учетную запись с этой ролью. Для управления платежным аккаунтом назначьте роль admin, editor или viewer на платежный аккаунт выделенному сотруднику организации с федеративным аккаунтом.

✓ Защита organization-manager.organizations.owner: передайте роль organization-manager.organizations.owner федеративному аккаунту, затем удалите из организации паспортный аккаунт с этой ролью. Чтобы минимизировать риски возможных сбоев в работе федерации, выполните шаги, описанные в статье Удаление паспортного аккаунта из организации.

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

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

Сервисные аккаунтыСервисные аккаунты

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

✓ Использование сервисного аккаунта для операций изнутри виртуальной машины: привяжите к ВМ сервисный аккаунт. Тогда для аутентификации не нужно будет хранить ключи сервисного аккаунта на виртуальной машине — IAM-токен будет доступен по ссылке на сервис метаданных.

✓ Использование IAM-токена для аутентификации: если вам нужно использовать статические учетные данные, рассмотрите использование IAM-токена. Срок жизни ключей неограничен, а IAM-токен действует 12 часов. Если IAM-токен оказался скомпрометирован или вы не планируете больше его использовать, отзовите его.

✓ Использование сервисных аккаунтов: используйте сервисные аккаунты для автоматизации работы с Yandex Cloud. Вы можете проверить дату и время последней аутентификации на странице с информацией о сервисном аккаунте в консоли управления — эта информация позволяет отслеживать случаи несанкционированного использования сервисных аккаунтов.

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

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

✓ Хранение ключей сервисного аккаунта в секрете: в случае использования статических ключей, храните их в секретах Yandex Lockbox.

✓ Периодическая ротация ключей сервисных аккаунтов: ключи без срока действия (авторизованные ключи и статические ключи) нужно ротировать самостоятельно. Дату создания можно проверить в свойствах ключа. Рекомендуется ротировать ключи как минимум раз в 90 дней.

СекретыСекреты

✓ Поиск секретов Yandex Cloud в открытых источниках: Yandex Cloud может искать несколько типов секретов в открытых источниках: API-ключи, IAM Cookies, IAM-токены, статические ключи доступа, OAuth-токены и серверные ключи SmartCaptcha. Подробнее о поиске различных типов секретов.

✓ Обработка секретов, попавших в открытый доступ: если секреты были скомпрометированы, отзовите и перевыпустите секреты, проверьте наличие несанкционированных действий и удалите несанкционированные ресурсы. Сообщите об инциденте в службу технической поддержки и защитите секреты от уязвимостей. Подробнее о плане действий по обработке секретов.

✓ Использование секрета Yandex Lockbox для хранения ключей доступа и токенов: сохраняйте ключи и токены в секретах Yandex Lockbox и используйте полезную нагрузку этих секретов, когда нужно применить ключ или токен.

✓ Использование API-ключей с ограниченным доступом: создавайте API-ключи с ограниченной областью и сроком действия для работы с перечнем необходимых сервисов, чтобы снизить риск несанкционированного использования ключей.