Идентичности и роли

Что это такое

Субъект (principal) — это всё, что может вызвать API провайдера: человек, сервис, рабочая нагрузка, конвейер. Роль — это набор разрешений, которые доверенный субъект может принять на ограниченное время и получить временные учётные данные. Вместо хранимого пароля рабочая нагрузка предъявляет доказательство своей идентичности и получает короткоживущий токен, который истекает сам.

Почему это важно

Долгоживущие учётные данные — крупнейший источник компромисса в облаке: они никогда не истекают, копируются между системами и в итоге оказываются в репозитории или в логе. Роль убирает то, что можно украсть: учётные данные выдаются по запросу, ограничены рабочей нагрузкой и бесполезны через час. Она же делает журнал аудита осмысленным, потому что каждое действие приписывается идентичности, принявшей роль, а не общему ключу.

Ключевые идеи

Аккаунт — внешняя граница, и он не должен быть единственной

Ресурсы живут в аккаунте, и разрешение внутри аккаунта — первый уровень контроля. Разделение продакшена и разработки на разные аккаунты означает, что ошибка в одном не дотянется до другого, а компромисс учётных данных разработки не станет компромиссом данных клиентов. Это самая дешёвая структурная граница из доступных, и её часто пропускают, потому что один аккаунт проще в начале и куда труднее разделить потом.

организация
  аккаунт продакшена  -> данные клиентов, строгие политики
  аккаунт разработки  -> эксперименты, широкие разрешения, без данных клиентов
  общие сервисы       -> логирование, хранилище артефактов

Временные учётные данные заменяют хранимые ключи

Рабочая нагрузка с прикреплённой ролью просит у платформы учётные данные и получает их со сроком истечения. Человек аутентифицируется и получает сессию. В обоих случаях нет секрета в покое, который можно украсть, — в этом весь смысл. Там, где внешняя система должна вызывать API, федерация позволяет ей предъявить собственную идентичность и получить токен вместо того, чтобы хранить ключ вечно.

Разрешение оценивается на нескольких слоях

Вызов разрешён, только если политика идентичности его допускает, а политика ресурса его принимает. Для доступа между аккаунтами «да» должны сказать обе стороны. Понимание, что действующее разрешение — это пересечение, останавливает частую ошибку: выдать широко на одном слое и полагать, что другой это компенсирует.

Политика доверия — само по себе решение о безопасности

Роль указывает, какие субъекты могут её принять. Политика доверия, принимающая целый аккаунт или произвольную федеративную идентичность, — это широкая дверь, и именно эта часть конфигурации чаще всего написана один раз и никогда не пересматривается. Сузить, кто может принять роль, так же важно, как сузить, что роль может делать.

Корневой и человеческий доступ требуют особого обращения

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

Идентичность — это журнал аудита

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

Практика

Замените хранимый ключ ролью

Найдите рабочую нагрузку, использующую долгоживущий ключ доступа, дайте ей роль, ограниченную тем, что она действительно вызывает, и удалите ключ.

Готово, когда: рабочая нагрузка работает без ключа, а её вызовы приписываются роли.

Проверьте, кто может принять роль

Возьмите политику доверия роли, перечислите каждого субъекта, который может её принять, и удалите тех, кому это больше не нужно.

Готово, когда: у каждого субъекта в политике доверия есть текущая причина там быть, а удалённый больше не получает учётных данных.

Частые ошибки

• Хранить долгоживущий ключ на сервере — он не истекает и подходит для любой утечки; исправить: прикрепите роль и получайте временные учётные данные.
• Держать продакшен и разработку в одном аккаунте — ошибка в разработке может дотянуться до данных клиентов; исправить: разделите аккаунты как структурную границу.
• Писать широкую политику доверия — любой субъект в аккаунте может принять роль; исправить: назовите конкретных субъектов, которым это нужно.
• Полагать, что один слой политики компенсирует другой — разрешение есть пересечение, а широкая сторона всё равно действует в других местах; исправить: сужайте обе стороны.
• Постоянно пользоваться корневыми учётными данными аккаунта — самая мощная идентичность в ежедневном использовании; исправить: заприте её и переведите человеческий доступ на федерацию с многофакторной аутентификацией.

Что читать дальше

• AWS (06-cloud-devops/02-aws) — модель аккаунта и разрешений, из которой взяты эти идеи, поэтому читайте её первой.
• Безопасность в облаке и IAM (06-cloud-devops/12-cloud-security-iam) — дисциплина, основой которой является этот дочерний урок.
• Наименьшие привилегии на практике (06-cloud-devops/12-cloud-security-iam/02-least-privilege-in-practice) — как эти идентичности сужаются со временем.