Самая большая поверхность атаки сегодня — это ваше облако.
Разбор конфигурации, доступов и сегментации в AWS, Azure и GCP. Большинство облачных инцидентов начинается не со сбоя у провайдера, а со слишком широкого права, случайно открытого ресурса или забытого секрета.
В облаке ошибка редко бывает на стороне провайдера
Модель разделённой ответственности делит работу: провайдер отвечает за инфраструктуру, конфигурация — ваша. Инциденты происходят на вашей половине: корзина, открытая ради удобства теста; роль, которой второпях выдали административные права; сеть, оставшаяся без сегментации из-за сроков. Ничего из этого не появится в сканировании как уязвимость — это появится как решение о настройке, к которому никто не вернулся.
- Право, выданное как временная мера, почти никогда не отзывается потом.
- Ресурс, созданный в обход стандартного процесса, не наследует защиту, которую этот процесс даёт.
- Секреты в переменных окружения и репозиториях остаются самым коротким путём внутрь.
- Без сегментации одна точка опоры достаёт до аккаунтов и сред, которые должны быть разделены.
Что входит
Ниже — стандартный объём для типового проекта. Всё можно скорректировать на этапе согласования границ, без доплаты.
- Широкие политики и подстановочные символы в действиях и ресурсах
- Принимаемые роли и цепочки повышения привилегий
- Долгоживущие ключи доступа и их ротация
- Федерация, поставщик учётных данных и сессии
- Служебные учётные записи и права рабочих нагрузок
- Разделение администрирования и эксплуатации
- Публичная доступность объектов и контейнеров
- Шифрование при хранении и управление ключами
- Политика доступа и обмен между аккаунтами
- Версионирование, срок хранения и защита от удаления
- Резервные копии и проверка восстановления
- Чувствительные данные вне предназначенного хранилища
- Входящие правила, открытые всему интернету
- Сегментация между средами и между аккаунтами
- Балансировщики, шлюзы и терминация трафика
- Управляющие сервисы, достижимые снаружи
- Частные каналы связи и сетевой пиринг
- Поверхность контейнеров и оркестрации
- Журнал аудита включён во всех регионах
- Хранение и защита самих журналов
- Охват событий управляющего слоя
- Оповещения при изменении чувствительных прав
- Централизация в отдельном аккаунте
- Интеграция с существующим мониторингом
- IAM, роли, политики и федерация учётных данных
- VPC, группы безопасности, NACL, пиринг и публичный доступ
- S3, RDS, DynamoDB, Blob Storage и Cloud Storage
- EC2, Lambda, ECS, EKS, AKS и GKE
- CloudTrail, AWS Config, Microsoft Sentinel и Security Command Center
- Поставщики учётных данных и федеративный SSO
Форматы
подстраиваются под объёмРазбор конфигурации
Систематический просмотр среды из роли аудитора с правами только на чтение: учётные записи, сеть, хранилища, журналирование и защита данных — в сопоставлении с документацией самого провайдера и публичными бенчмарками.
Проверка маршрутов
Вместо перечисления настроек мы начинаем с правдоподобной позиции — учётные данные приложения, скомпрометированный контейнер, обычный пользователь — и определяем, как далеко она достаёт внутри среды.
Постоянный контроль и инфраструктура как код
Анализ шаблонов и модулей, из которых собирается среда, плюс регулярный цикл перепроверки. Исправление в исходнике не даёт одному и тому же отклонению возвращаться с каждым новым аккаунтом, проектом или развёртыванием.
Когда стоит проверить облачную среду
Конфигурация облака меняется ежедневно и многими руками. Есть моменты, когда риск концентрируется сильнее обычного.
Среда, перенесённая в спешке, обычно тащит за собой широкие права, выданные ради того, чтобы переключение состоялось, — с обещанием сузить их потом. Это «потом» наступает редко.
Каждая команда завела свой, каждый проект открыл ещё один. Без единого стандарта защита расходится, и никто не видит картину целиком.
Аномальные траты — иногда просто расточительство, а иногда ресурс, созданный тем, у кого не должно было быть прав его создавать. Полезно знать, что именно.
Доказательства облачных мер защиты сегодня стандартный пункт большинства анкет. Лучше найти пробел раньше, чем это сделает проверяющий.
Как мы это делаем
[этапы]Обзор среды
Начинаем с того, что вообще есть: аккаунты, подписки, проекты, активные регионы и используемые ресурсы. Облачное хозяйство почти всегда больше, чем следует из документации, а ресурс, которого нет в реестре, обычно и оказывается незащищённым.
Анализ учётных записей и прав
Мы описываем, кто и что может, включая возможности через наследование и принятие ролей. Важна не записанная политика, а действующее право — и оно, как правило, заметно шире, чем представляет себе тот, кто его выдал.
Разбор настроек
Хранилища, сеть, шифрование, журналы, резервное копирование и управляемые сервисы сверяются с документацией провайдера и публичными бенчмарками безопасной конфигурации; каждое отклонение фиксируется вместе с тем, почему оно важно именно в этой среде.
Проверка дальности
Мы воспроизводим реалистичные стартовые позиции и измеряем, куда достаёт каждая: что может прочитать учётная запись приложения, до чего дотягивается скомпрометированный контейнер, возможен ли переход из одной среды в другую. Именно это отличает список отклонений от доказанного риска.
Оценка журналов и оповещений
Проверяем, оставили ли след выполненные нами действия, защищён ли этот след от удаления и вызывает ли изменение чувствительных прав оповещение. Среду без надёжного следа невозможно расследовать после инцидента.
Отчёт и план устранения
Отклонения сгруппированы по причине, а не по ресурсам: десять пунктов из одной политики — это одно исправление, а не десять. К каждой группе прилагается применимое руководство и предложение, как исключить повторение в исходнике.
Публичные стандарты, на которых строится работа
Разбор опирается на документацию самих провайдеров и на открытые бенчмарки конфигурации, поэтому каждый пункт можно проверить независимо.
- CIS Benchmarks
- Базовые конфигурации для AWS, Azure и GCP дают объективный ориентир по пунктам, с которым сверяется состояние среды.
- Well-Architected (раздел безопасности)
- Архитектурные руководства провайдеров излагают их же рекомендованную практику, что снимает спор о том, откуда взялась та или иная рекомендация.
- Модель разделённой ответственности
- Она точно определяет, где заканчивается ответственность провайдера и начинается ваша, — ровно ту границу, на которой происходит большинство инцидентов.
- MITRE ATT&CK for Cloud
- Облачная матрица даёт названия техникам злоупотребления доступом, закрепления и сбора данных и служит для оценки покрытия обнаружения.
- NIST SP 800-53
- Каталог мер защиты — мост между технической находкой и языком, которым уже пользуются управление рисками и аудит.
- Минимально необходимые права
- Не стандарт, а критерий, направляющий анализ прав: каждая учётная запись должна доставать только до нужного, и любое отступление требует явного обоснования.
- Azure Security Benchmark
- Собственная базовая конфигурация Microsoft для Azure — применяется, когда ландшафт преимущественно на Azure и аудит ждёт именно этой ссылки.
- CSA Cloud Controls Matrix
- Матрица Cloud Security Alliance описывает области облачной безопасности и связывает их с другими стандартами, что выручает, когда анкета заказчика оказывается длинной.
- ISO/IEC 27017 и 27018
- Стандарты, посвящённые именно облачной безопасности и персональным данным в облаке; часто упоминаются в корпоративных договорах.
- Соотнесение с законами о защите данных и PCI-DSS
- Если среда обрабатывает персональные данные или данные карт, каждая находка дополнительно привязывается к соответствующему требованию, чтобы служить доказательством напрямую.
Результаты
два уровня · NDAОпись того, что есть
Реальный перечень аккаунтов, проектов, регионов и работающих ресурсов. Для многих команд это первый полезный результат, потому что всплывают среды, о принадлежности которых никто не помнил.
Карта действующих прав
Кто до чего достаёт на практике, включая непрямые маршруты через наследование и принятие ролей. Удивляет обычно сильнее, чем список настроек.
Отклонения, сгруппированные по причине
Находки упорядочены по общему источнику, к каждой приложена публичная ссылка. Исправление причины закрывает сразу несколько пунктов и предотвращает повторение.
Показанные маршруты
Для наиболее значимых рисков — конкретный путь: откуда начинается, до чего достаёт и почему это важно. Так отклонение в настройках превращается в риск, который может взвесить и неспециалист.
Оценка следа и обнаружения
Что было записано из выполненных нами действий, что было отключено и какие чувствительные изменения сегодня прошли бы незамеченными.
План устранения по приоритетам
Порядок работ, взвешивающий риск и трудозатраты, с разделением на то, что чинится в конфигурации, и то, что нужно менять в инфраструктуре как коде, чтобы оно не вернулось.
Частые вопросы
Нет. Разбор выполняется из роли аудитора с правами только на чтение — такая роль есть у всех трёх провайдеров. Для проверки маршрутов отдельно согласуются конкретные ограниченные учётные данные, с письменно зафиксированным объёмом и сроком.
Дополняет, а не заменяет. Такие инструменты берут на себя объём и непрерывно отслеживают отклонения — это ценно. Чего они не делают, так это не связывают права в цепочку, чтобы показать: учётные данные приложения достают до данных, которые должны быть изолированы. И меняет приоритеты именно такая демонстрация.
Да. Смешанные ландшафты — обычное дело, и сравнение провайдеров как раз обнажает неравномерность защиты: один и тот же тип ресурса закрыт у одного и открыт у другого, потому что делали разные команды.
Оркестрация входит в объём: роли и привязки, контексты безопасности контейнеров, сетевые политики между сервисами, доступность управляющего слоя, работа с секретами и связка между учётной записью кластера и облачной учётной записью — частый маршрут повышения привилегий.
Как минимум ту, что обслуживает продуктив. Аккаунты разработки и тестирования стоит включать, если у них есть сетевой или доверительный путь в продуктив, а это встречается чаще, чем принято думать — и защита там обычно самая слабая.
Исправлять их в исходнике. Если среда собирается из инфраструктуры как кода, правка вносится в модуль и действует для всех будущих развёртываний. По каждой группе отклонений отчёт указывает, лечить ли её на ресурсе или в шаблоне, который его создаёт.
Да. К каждому пункту приложены публичная ссылка и свидетельство наблюдавшейся конфигурации — в виде, который аудитор может проверить самостоятельно, не повторяя анализ.
Готовы увидеть свои слабые места?
Первое согласование границ — бесплатно и под NDA. В течение 48 часов вы получите техническое предложение, объём работ и график. Без бюрократических форм.