Облачная идентификация: роли IAM и сервисные учётные записи
Настройте роли IAM с минимальными привилегиями и сервисные учётные записи в облачных платформах, избегая распространённых ошибок вроде разрешений с подстановочными знаками и ключей с длительным сроком действия.
«Облачная идентификация: роли IAM и сервисные учётные записи» — бесплатный урок Cloud & IT Cert Prep на CoddyKit. Это урок 3 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения Cloud & IT Cert Prep, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Основы облачных удостоверений
В облачных средах удостоверение стало новым периметром безопасности. Каждое действие — запуск VM, чтение базы данных, вызов API — авторизуется на основании удостоверения, от имени которого оно выполняется. Облачные системы IAM (управления удостоверениями и доступом) определяют, кто может выполнять какие действия над какими ресурсами. В отличие от локальных сред, где расположение в сети обеспечивало неявное доверие, IAM в облаке рассматривает каждый запрос как требующий явной авторизации независимо от места его отправки.
Пользователи, группы и роли в AWS IAM
В AWS IAM есть три основных типа удостоверений. Пользователи IAM представляют отдельных людей или приложения с долгосрочными учётными данными (ключ доступа + секретный ключ). Группы IAM объединяют пользователей и назначают им общие разрешения. Роли IAM — это удостоверения с временными учётными данными, которые могут принимать пользователи, сервисы AWS (EC2, Lambda) или другие аккаунты. Роли предпочтительнее долгосрочных ключей доступа, поскольку срок действия их учётных данных автоматически истекает, что снижает риск их раскрытия.
# IAM role trust policy — allows EC2 to assume this role
{
'Version': '2012-10-17',
'Statement': [{
'Effect': 'Allow',
'Principal': { 'Service': 'ec2.amazonaws.com' },
'Action': 'sts:AssumeRole'
}]
}
# EC2 instance with this role attached can call AWS APIs
# using temporary credentials from the instance metadata serviceМинимальные привилегии в политиках IAM
Политики IAM определяют, какие действия удостоверение может выполнять над какими ресурсами. Принцип минимальных привилегий требует, чтобы политики предоставляли только те действия, которые необходимы для выполнения задачи. Распространённые нарушения: использование подстановочного символа * для действий (предоставляет все действия в сервисе), использование * для ресурсов (предоставляет доступ ко всем ресурсам) и назначение сервисным аккаунтам чрезмерно широких управляемых политик, таких как AdministratorAccess. Каждый подстановочный символ следует обосновывать и регулярно пересматривать.
# Overly permissive policy (AVOID)
{
'Effect': 'Allow',
'Action': 's3:*', # all S3 actions
'Resource': '*' # all buckets
}
# Least-privilege policy (PREFERRED)
{
'Effect': 'Allow',
'Action': ['s3:GetObject', 's3:ListBucket'],
'Resource': [
'arn:aws:s3:::my-specific-bucket',
'arn:aws:s3:::my-specific-bucket/*'
]
}Учетные записи Service Accounts в GCP
В Google Cloud Platform (GCP) рабочие нагрузки без участия человека проходят аутентификацию с помощью service accounts — управляемых сущностей идентификации с файлами ключей JSON или Workload Identity Federation. Для каждой service account следует соблюдать принцип минимальных привилегий: назначайте ей доступ только к тем сервисам GCP, которые ей необходимо вызывать. Ключи service account (файлы JSON, загруженные из консоли) являются долгосрочными учетными данными, с которыми следует обращаться как с паролями: регулярно заменять их и никогда не добавлять в исходный код и не загружать в общедоступные репозитории.
# Check service account permissions (gcloud)
gcloud projects get-iam-policy my-project \
--flatten='bindings[].members' \
--format='table(bindings.role, bindings.members)' \
--filter='bindings.members:serviceAccount'
# Prefer Workload Identity over service account keys
# (no downloadable key files — uses workload federation tokens)Управляемые удостоверения Azure
Managed Identities Azure (ранее MSI) — аналог ролей AWS IAM для сервисов в Azure. Они позволяют ресурсам Azure (виртуальным машинам, App Services и Functions) проходить аутентификацию в API Azure без хранения учетных данных. Существует два типа: управляемые удостоверения System-assigned связаны с определенным ресурсом и удаляются вместе с ним. Управляемые удостоверения User-assigned являются самостоятельными объектами, которыми можно совместно пользоваться из нескольких ресурсов. Управляемые удостоверения устраняют необходимость хранения ключей и секретов.
# Azure CLI — assign managed identity to a VM
az vm identity assign \
--name myVM \
--resource-group myRG \
--identities /subscriptions/.../userAssignedIdentities/myIdentity
# The VM can now call Azure Key Vault without any stored credentials:
# Token is fetched automatically from the Instance Metadata ServiceРиски долгосрочных учетных данных
Долгосрочные учетные данные — статические ключи доступа, токены API и файлы ключей service account, срок действия которых не истекает, — относятся к наиболее рискованным элементам облачных сред. При утечке (через GitHub, корзину S3, журналы или скомпрометированный ноутбук разработчика) эти учетные данные предоставляют немедленный доступ, пока их не отзовут вручную. Организациям следует: проверять все долгосрочные учетные данные, регулярно заменять их, отдавать предпочтение ролевому или федеративному доступу с краткосрочными токенами и немедленно оповещать об обнаружении учетных данных в общедоступных репозиториях.
# Find IAM access keys older than 90 days (AWS)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | \
base64 -d | grep -v 'N/A' | \
awk -F',' '$10 > 90 {print $1, $10}'
# Keys older than 90 days should be rotated or deletedЦепочки ролей IAM и повышение привилегий
Повышение привилегий IAM происходит, когда сущность идентификации использует сочетание разрешений, чтобы предоставить себе дополнительные разрешения. Классические пути повышения привилегий включают: назначение более разрешающей политики собственной учетной записи, создание нового пользователя IAM с расширенными разрешениями, передачу роли (iam:PassRole) сервису и обновление роли выполнения функции Lambda. IAM Access Analyzer в AWS может обнаруживать такие шаблоны, а границы разрешений IAM позволяют жестко ограничить максимальный набор разрешений, который можно предоставить любой сущности идентификации.
# Dangerous permission combination (enables privilege escalation):
# iam:CreatePolicyVersion + iam:SetDefaultPolicyVersion
# Attacker can create a new policy version with AdministratorAccess
# Or: iam:PassRole + lambda:CreateFunction + lambda:InvokeFunction
# Attacker creates Lambda with a privileged role, invokes it
# Defense: permission boundaries limit maximum grantable permissionsПринятие роли между учетными записями
Облачные организации часто используют несколько учетных записей (dev, staging, prod, security) как границы радиуса воздействия инцидента. Принятие роли между учетными записями позволяет сущностям из одной учетной записи принимать роли в другой, благодаря чему централизованные инструменты могут работать сразу с несколькими учетными записями. Средства защиты включают: требование External ID в политике доверия для предотвращения атак типа «замешательство заместителя», ограничение списка учетных записей, которым разрешено принимать роль, с помощью ARN субъекта Principal и регистрацию всех случаев принятия ролей между учетными записями в CloudTrail для аудита.
# Trust policy with External ID (confused deputy protection)
{
'Effect': 'Allow',
'Principal': { 'AWS': 'arn:aws:iam::PARTNER-ACCOUNT-ID:root' },
'Action': 'sts:AssumeRole',
'Condition': {
'StringEquals': {
'sts:ExternalId': 'unique-shared-secret-12345'
}
}
}Безопасность IMDS и сервиса метаданных
Экземпляры AWS EC2 могут получать учетные данные роли IAM из Instance Metadata Service (IMDS) по адресу http://169.254.169.254. Здесь особенно опасен класс уязвимостей SSRF: если приложение уязвимо к SSRF, злоумышленник может похитить учетные данные роли IAM экземпляра, заставив сервер обратиться к URL IMDS. IMDSv2 (требующий токен сеанса) снижает риск кражи учетных данных через SSRF и должен быть принудительно включен для всех экземпляров EC2.
# Enforce IMDSv2 on a new EC2 instance (requires token for IMDS)
aws ec2 run-instances \
--metadata-options 'HttpTokens=required,HttpEndpoint=enabled' \
...
# IMDSv1 (insecure) just needs a GET request:
# curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
# IMDSv2 requires a PUT to get a session token firstIAM Access Analyzer и проверка политик
IAM Access Analyzer (AWS) автоматически выявляет ресурсы, к которым предоставлен доступ внешним субъектам, а также политики IAM, предоставляющие больше разрешений, чем предполагалось. Он анализирует политики корзин, политики доверия ролей и политики ключей KMS, чтобы выявить внешний доступ, который не был явно предусмотрен. Регулярная проверка политик IAM — вручную или с помощью таких инструментов, как Cloudsplaining, PMapper или Permissions Boundary Analyzer, — необходима для выявления путей повышения привилегий до того, как их обнаружат злоумышленники.
Федерация удостоверений рабочих нагрузок
Workload Identity Federation позволяет внешним рабочим нагрузкам (GitHub Actions, локальным системам и другим облачным провайдерам) проходить аутентификацию в облачном IAM с помощью краткосрочных токенов OIDC вместо долгосрочных ключей service account. Рабочий процесс GitHub Actions может принять роль AWS IAM с помощью своего токена OIDC на время выполнения задания, после чего токен истекает. Такой подход полностью устраняет риск утечки долгосрочных учетных данных из конвейеров CI/CD.
Быстрая проверка
Проверьте, насколько хорошо Вы понимаете концепции CompTIA Security+ (SY0-701), рассмотренные в этом уроке.
Итоги урока
В этом уроке Вы узнали, что роли IAM предоставляют временные учетные данные и предпочтительнее долгосрочных ключей доступа для облачных рабочих нагрузок, политики минимальных привилегий не должны использовать подстановочные знаки и должны предоставлять только определенные действия над определенными ресурсами, а IMDSv2, границы разрешений и федерация удостоверений рабочих нагрузок устраняют распространенные пути утечки учетных данных. Далее мы рассмотрим управление состоянием безопасности облака (CSPM).
Часто задаваемые вопросы
Урок «Облачная идентификация: роли IAM и сервисные учётные записи» бесплатный?
Да — полный текст урока «Облачная идентификация: роли IAM и сервисные учётные записи» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс Cloud & IT Cert Prep, подпишись на CoddyKit PRO. Курс Cloud & IT Cert Prep содержит 4 уроков всего.
Чему я научусь в уроке «Облачная идентификация: роли IAM и сервисные учётные записи»?
Настройте роли IAM с минимальными привилегиями и сервисные учётные записи в облачных платформах, избегая распространённых ошибок вроде разрешений с подстановочными знаками и ключей с длительным сроко… Ты практикуешь Cloud & IT Cert Prep с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать Cloud & IT Cert Prep?
Предыдущий опыт не требуется. Cloud & IT Cert Prep на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 3 из 4.
Сколько времени занимает урок «Облачная идентификация: роли IAM и сервисные учётные записи»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке Cloud & IT Cert Prep?
Да. Каждый урок Cloud & IT Cert Prep включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- Модель общей ответственности: IaaS, PaaS, SaaS
- Безопасность облачного хранилища и риски раскрытия данных
- Облачная идентификация: роли IAM и сервисные учётные записи
- Управление состоянием безопасности облака (CSPM)