IAM-инвентаризация не отвечает на правильный вопрос
В одном аккаунте спросить, кто что может делать, уже сложно. В AWS Organizations вопрос меняет форму: кто к чему может добраться, через какие роли, из какого аккаунта, с каким практическим результатом.
Документированные политики, прикреплённые права и trust policy существуют. Часто отсутствует граф эффективных путей между ними. Добросовестный sts:AssumeRole в member-аккаунте может стать следующим прыжком от identity, которую никто не рассматривал целиком.
Риск не всегда выглядит как одна раздутая JSON-политика. Он выглядит как цепочка.
Почему multi-account организации скрывают пути
AWS Organizations вводит структурное доверие: cross-account роли, management-аккаунты, SCP, делегированные администраторы, Identity Center, Access Analyzer в масштабе org. Каждая часть осмысленна сама по себе. Вместе они задают периметр, который редко рисуют целиком.
Типичные паттерны в обзорах:
- широкие trust policy или слабые условия между аккаунтами
- jump-роли пайплайнов или vendor, накапливающие охват
- привилегии management-аккаунта, не подчиняющиеся тем же SCP, что и member
- пути, которые появляются только когда IAM-инвентаризация сочетается со связями организации
Без этой карты команды безопасности отвечают локальными контролями. Атакующий или аудитор думает маршрутами.
Что даёт STRAP
STRAP. внутренний tooling TechRebel для анализа путей атаки в масштабе организации AWS. Мы используем его в cloud security engagement и предоставляем клиентам, когда задача. понять эффективный доступ за пределами одного аккаунта.
Он не заменяет IAM Access Analyzer и инвентаризацию политик. Дополняет эти источники path-ориентированным чтением: от identity к identity, от аккаунта к аккаунту, до привилегий, важных для бизнеса.
Полезный результат. не бесконечный список findings. Это приоритизированный набор маршрутов, объясняющих, как кто-то с опорой в одном месте может добраться до другого.
Как это вписывается в engagement
В работе AWS & Cloud Security мы обычно начинаем с трёх слоёв:
- постура и покрытие (аккаунты, регионы, логинг, базовые контроли)
- эффективный доступ (роли, trusts, cross-account пути)
- приоритизация (какие маршруты важны и какие remediation реалистичны)
STRAP в основном питает второй. Помогает перейти от «у нас много политик» к «вот маршруты, которые резать первыми».
Что мы не обещаем
Никакой инструмент не снимает сложность крупной организации AWS. STRAP сам по себе не изобретает безопасную постуру. Зависит от согласованного объёма чтения и credentials, качества инвентаризации и человеческих решений о том, что исправлять.
Его ценность. делать видимыми пути, которые дизайн аккаунт за аккаунтом склонен оставлять вне радара.
Чтобы проверить эффективный доступ в вашей организации AWS, запишитесь на встречу или см. больше контекста в Research.