Гибридные и мультиоблачные инфраструктуры в 2025 году уже стали обычным явлением. Эти решения часто являются результатом целого ряда шагов, сделанных различными командами, в разное время и под разные задачи. На первый взгляд, всё выглядит вполне стандартно: есть серверы на месте, несколько облачных провайдеров, Kubernetes, VPN, IdP и Terraform. Однако на практике настоящие проблемы начинаются тогда, когда пересекаются идентичности и сети: кто ты в каждой из этих сред, какие ресурсы тебе доступны, и каким образом ты можешь попасть к ним через разные маршруты и точки входа.
Большинство инцидентов безопасности в таких архитектурах связаны не с уязвимыми криптографическими алгоритмами или дырявыми фаерволами. Часто причина кроется в организационных и человеческих ошибках: слишком много ролей, забытые исключения, временный доступ, который неожиданно стал постоянным, и сегментация, которая выглядит прекрасно на схеме, но не работает в реальности. В этой статье я постараюсь показать, как подходить к управлению доступом в гибридных инфраструктурах так, чтобы такие системы могли эффективно адаптироваться к изменениям, справляться с инцидентами и расти вместе с бизнесом.
Для этого важно помнить о принципах Zero Trust: доверие не должно зависеть от того, где ты находишься, а безопасность должна быть ориентирована на пользователей, устройства и ресурсы, а не на периметр.
Аналогично в практиках DevSecOps, где Zero Trust применяется к CI/CD, контроль идентичности и управление привилегиями должны проходить «сквозь» все стадии жизненного цикла - от раннера до деплоя. подробнее...
Причины, по которым IAM ломается
Разные модели идентичности
В большинстве современных инфраструктур используются разные системы для управления идентичностями. В одном месте у нас стоит Active Directory или LDAP, в облаках - собственные IAM системы, Kubernetes контролирует доступ через ServiceAccount, а CI/CD работает с токенами. Когда эти системы не согласованы, начинают возникать проблемы с дублированием учетных записей и с деактивацией пользователей. Например, когда человек увольняется, его отключают в одном месте, но оставляют доступ в другом - и это может привести к серьёзным последствиям.Разные модели авторизации
Каждая система имеет свои подходы к авторизации: где-то это роли, где-то политики с условиями, где-то ACL. Попытки создать универсальную таблицу доступа часто заканчиваются неудачей, так как с течением времени команды меняются, продукты перерабатываются, а таблицы прав уже не соответствуют реальности. Когда возникают срочные задачи, проще выдать более широкие права, чем тратить время на уточнение.Исключения и роли
В мультиоблачной инфраструктуре исключения становятся нормой. Нужно срочно восстановить доступ, посмотреть логи, разрешить миграцию". Такие временные меры могут превращаться в долговечные привилегии, которые никто не отменяет, что приводит к накоплению несанкционированных прав.Долгоживущие учетные данные и секреты
Как только в системе появляются долгоживущие ключи или токены, это становится серьёзной уязвимостью. Атакующие могут дождаться, пока эти данные случайно не попадут в лог или в скомпрометированную систему. И когда эти ключи "всплывают", они оказываются легитимными.Смешение человеческого и машинного доступа
Люди должны использовать сильную аутентификацию с ясной трассировкой своих действий, а машины должны работать с минимальными правами, короткими ключами, которые автоматически обновляются. Когда эти два типа доступа пересекаются, расследовать инциденты становится крайне сложно.В статье "Облако под прицелом" рассматриваются современные практики управления доступом в облаках - от настройки MFA до применения принципа наименьших привилегий, что помогает уменьшить вероятность избыточных прав и misconfiguration в IAM‑средах.
Сегментация без иллюзий
Сетевая сегментация часто начинается с правильного подхода: разделить продакшн от тестовых систем, базы данных от приложений и админский доступ от пользовательского. Проблемы возникают, когда сегментация воспринимается как нечто статичное и не гибкое, вместо того чтобы быть механизмом для динамичного управления потоками данных.Сегментация работает только тогда, когда на вопрос "кто с кем должен общаться?" есть ясный ответ, который привязан к логике работы (сервис, данные, роль), а не к вчерашним IP-адресам.
Сегментация должна быть многоуровневой и подстраиваться под изменения, чтобы не стать барьером для быстрой адаптации инфраструктуры. Важно не забывать, что это инструмент, а не фиксированная схема, и её использование должно быть управляемым и поддающимся изменениям.
В обзоре "Безопасность облачных сред" мы показали, что управление доступом - ключевой компонент защиты данных в динамичных распределённых средах, и ошибки в правах доступа часто становятся причиной серьёзных утечек.
Реальные инциденты
Ссылка скрыта от гостей
В 2019 году Capital One столкнулась с одним из крупнейших инцидентов утечки данных, когда злоумышленник получил доступ к данным более 100 миллионов клиентов. Хакер использовал уязвимость в настройках AWS WAF, чтобы получить доступ к IAM‑токенам и метаданным EC2, а затем извлечь конфиденциальную информацию из S3‑бакетов.Ошибка заключалась в неправильной настройке доступа и отсутствии строгого контроля над метаданными, что привело к использованию несанкционированных прав.
Каждое облако должно быть настроено с максимальной точностью, чтобы исключить ошибки конфигурации. Контроль над метаданными и доступами должен быть на уровне приоритетов безопасности.
Ссылка скрыта от гостей
В 2020 году хакеры использовали украденные IAM креды для развертывания криптомайнинговых инстансов в облаке AWS. Это происшествие показало, как уязвимость в ротации ключей и недостаточный контроль за их использованием может привести к серьезным проблемам безопасности.Использование долгоживущих ключей и отсутствие регулярной ротации становятся точкой входа для атак. Ключи должны иметь ограниченный срок действия и быть защищены с использованием MFA и систем управления доступом.
Ссылка скрыта от гостей
В 2025 году группа хакеров ShinyHunters скомпрометировала сервисы Salesforce через уязвимость в OAuth‑токенах. Это дало им возможность получить доступ к личной информации пользователей через скомпрометированные токены, что привело к утечке данных.Токены OAuth/refresh должны управляться с особой осторожностью, так как они открывают доступ к множеству сервисов в облаке. Необходимо применять строгие политики на их использование и обеспечить защиту их жизненного цикла.
Рекомендации для Blue Team
- Минимизируйте IAM права и внедряйте строгие политики на основе ролей (RBAC). Права должны быть ограничены строго по необходимости.
- Внедрите многофакторную аутентификацию и управляйте ключами и токенами через надёжные хранилища.
- Используйте инструменты для автоматического обнаружения и предотвращения misconfigurations в облачных сервисах.
- Регулярно проводите ревизию и ротацию IAM-ключей, чтобы избежать долгоживущих и устаревших токенов.
- Применяйте политику «least privilege» для всех сервисов и компонентов, чтобы предотвратить возможность масштабирования атак внутри сети.
Заключение
Инциденты, такие как компрометация Capital One или утечка данных через OAuth-токены, подчеркивают, насколько важно правильно настроить системы управления доступом в гибридных и мультиоблачных средах. Ошибки в IAM-конфигурации, неправильное использование ролей и долгоживущие ключи могут привести к утечкам данных и серьезным угрозам безопасности. Чтобы предотвратить такие инциденты, необходимо использовать принципы наименьших привилегий, регулярно проводить ревизии, использовать MFA и автоматизировать ротацию ключей. Только так можно создать гибкую и безопасную инфраструктуру, которая будет устойчива к изменениям и инцидентам.
Последнее редактирование:
