Статья Cloud Security Posture Management (CSPM): Сравнение Open Source и коммерческих решений

Добро пожаловать в мир CSPM (Cloud Security Posture Management) - инструментов, которые должны были сделать нашу жизнь проще. Но вместо этого мы получили вендорский маркетинг, обещающий «полную видимость за 5 минут», и опенсорс-проекты, которые требуют от тебя умения писать политики в YAML и не бояться Python.

Я протащил через боевые облака (AWS, GCP, Yandex Cloud, Azure) и коммерческие решения типа Wiz и Orca, и опенсорсную связку Cloud Custodian + Prowler. В этой статье я не буду продавать тебе очередной «единый стек». Я просто честно расскажу, что работает, где подводные камни, и какой инструмент реально спасает задницу, когда у тебя 500+ аккаунтов, compliance-аудитор дышит в спину, а бюджет на безопасность - «ну вы же умные, что-нибудь придумайте».

1. Зачем CSPM: Почему облака текут, а ручной аудит - это мазохизм​

Прежде чем кидаться в установку инструментов, давай разберемся с фундаментом. Почему вообще возникла необходимость в CSPM? Ведь облачные провайдеры обещают нам «built-in security», AWS Trusted Advisor дает какие-то советы, а в консоли даже есть «Security Hub». Почему же каждую неделю мы читаем новости про очередной утечке данных из открытого S3-бакета или RDS-инстанса, который торчал в интернет?

1.1. Cloud misconfiguration incidents: S3 public buckets, open Security Groups​

Начнем с простого: человеческий фактор. Да, звучит банально, но в облаке цена одной опечатки может стоить миллиардов долларов (вспомним Capital One, где дыра была в misconfigured WAF). Но давай без фатализма. Основные грабли, которые я видел на каждом втором проекте:

• S3 бакеты с публичным доступом. Это классика. Разработчик создает бакет, ставит флажок «public-read» для быстрой отладки, забывает его снять. Или же IAM-политики, которые разрешают s3:GetObject для *. В итоге бакет с логами, бэкапами или даже исходниками спокойно индексируется поисковиками. С 2025 годом ситуация не изменилась - S3 остается главным источником утечек. AWS, кстати, пытается бороться: с апреля 2023 года по умолчанию запрещает публичный доступ, но кто мешает вручную его разрешить?
• Открытые Security Groups. Правило 0.0.0.0/0 на порту 22 (SSH) или 3389 (RDP) - это как оставить ключи от квартиры под ковриком. Да, иногда это нужно для «временного» доступа. Но «временное» в облаке становится вечным. И ладно бы только SSH - я видел открытые порты MongoDB (27017), Redis (6379), PostgreSQL (5432) прямо в интернет. Без пароля. Думаю, ты и сам такое встречал.
• Незашифрованные диски и бакеты. Compliance-требования требуют шифрования на стороне сервера (SSE-S3 или KMS). Но при создании ресурса легко забыть поставить галочку. А если у тебя нет централизованной политики, то через полгода выясняется, что 30% EBS-томов и 40% S3-бакетов лежат в открытом виде.
• Роли и политики с избыточными правами. IAM - это темная магия. Легко дать s3:* вместо s3:РutObject на конкретный бакет. Или назначить роль EC2 с правами администратора. Атака через SSRF на метадату EC2 с такой ролью - это мгновенный компромисс всего аккаунта.
• Логи не включены. CloudTrail, VPC Flow Logs, S3 Access Logs - отключены. Потому что «дорого» или «не до этого». А когда случается инцидент, ты сидишь и гадаешь: кто, когда и откуда заходил.

Это лишь вершина айсберга. Проблема в том, что вручную проверить сотни или тысячи ресурсов в десятках аккаунтов невозможно. Даже если у тебя команда из пяти сеньоров, они будут тыкать в консоль, выгружать JSON и плакать. Масштабирование ручного аудита - это миф. Здесь нужна автоматизация. И вот тут на сцену выходит CSPM.

1.2. Compliance drivers: CIS Benchmarks, SOC 2, ISO 27001, ФЗ-152​

Но misconfiguration - это не только риск утечки данных, но и compliance. Если ваша компания проходит аудит SOC 2, ISO 27001, PCI DSS или работает с персональными данными (ФЗ-152 в РФ), то требования к конфигурации облака прописаны жестко.

• CIS Benchmarks - это де-факто стандарт для безопасной настройки облачных провайдеров. Центр интернет-безопасности выпускает рекомендации для AWS, Azure, GCP. Например: включить CloudTrail во всех регионах, запретить публичный доступ к S3, использовать MFA для root-аккаунта и так далее. Всего в CIS AWS Benchmark v3.0 около 300+ проверок.
• SOC 2 требует контроля над изменениями и доступом. CSPM помогает доказать, что у вас нет открытых портов, что шифрование включено, а логи собираются.
• ISO 27001 - аналогично, с фокусом на управление активами, контроль доступа, операционную безопасность.
• ФЗ-152 (о персональных данных) в российском контексте требует, чтобы обработка персональных данных была защищена. Если вы используете Yandex Cloud или любой другой облачный провайдер для хранения ПДн, то misconfiguration может привести к серьезным штрафам. И тут важно не просто иметь инструмент, а уметь показывать аудитору, что вы контролируете конфигурацию.

Compliance-отчеты (например, для SOC 2 Type II) требуют доказательств за период. Без CSPM собирать эти доказательства - это ад: ты скриншотишь консоль, потом доказываешь, что скриншот не подделан, и так по каждому пункту. С CSPM ты просто выгружаешь отчет и говоришь: «вот, наши политики проверяли конфигурацию каждые 6 часов, вот отчеты о несоответствиях, вот доказательства ремедиации».

1.3. CSPM vs CWPP vs CNAPP: разграничение терминов​

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

• CSPM (Cloud Security Posture Management) - фокусируется на конфигурации облачных ресурсов. Он проверяет, соответствуют ли ваши S3-бакеты, EC2-инстансы, IAM-роли и другие ресурсы лучшим практикам. CSPM не лезет внутрь контейнеров или виртуальных машин. Он смотрит на control plane (плоскость управления) облака.
• CWPP (Cloud Workload Protection Platform) - защищает рабочие нагрузки: виртуальные машины, контейнеры, бессерверные функции. Это агенты, которые ставятся внутрь ОС, сканируют уязвимости, следят за поведенческими аномалиями (например, майнер криптовалюты запустился), блокируют файловые угрозы.
• CNAPP (Cloud-Native Application Protection Platform) - это объединение CSPM + CWPP + CIEM (Cloud Infrastructure Entitlements Management) + возможно еще и KSPM (Kubernetes Security Posture Management). Идея: один инструмент, который видит всё: и конфигурацию облака, и уязвимости в образах, и права доступа, и риски в Kubernetes. Именно в эту сторону эволюционируют коммерческие решения (Wiz, Orca, Prisma Cloud). Они пытаются стать единым стеком.

Зачем это разграничение? Потому что, когда ты выбираешь инструмент, тебе нужно понимать, какую задачу ты решаешь:

• Если тебе нужно просто контролировать, что S3 не публичный, а Security Groups закрыты - можно взять опенсорсный CSPM (Custodian, Prowler).
• Если тебе нужен еще и антивирус на EC2, и сканирование контейнеров - смотри в сторону CNAPP (коммерческие).
• Если у тебя Kubernetes-кластеры - возможно, тебе понадобится отдельный KSPM-инструмент (например, Aqua или часть CNAPP).

Я не буду утверждать, что CNAPP - это всегда маркетинговый оверкилл. В больших масштабах интеграция действительно удобна. Но за нее придется платить (и не только деньгами, но и производительностью, сложностью внедрения).

Теперь, когда мы разобрались с основами, переходим к самому интересному: какие инструменты реально помогают навести порядок в облаке.

---

2. Open Source решения: когда денег нет, а головы - есть​

Открытый исходный код в облачной безопасности - это не про «бедных студентов». Это про контроль, гибкость и отсутствие vendor lock-in. Если ты готов писать политики, разворачивать пайплайны и поддерживать инфраструктуру сам, опенсорс может дать тебе уровень безопасности, не уступающий коммерческим решениям, но за копейки (только стоимость хостинга и твоего времени).

Я выделяю три проекта, которые стали индустриальными стандартами: Cloud Custodian, Prowler и ScoutSuite. У каждого своя философия, сильные стороны и, конечно, косяки.

2.1. Cloud Custodian: policy-as-code (YAML), real-time remediation, 300+ AWS rules​

Cloud Custodian (c7n) - это, наверное, самый мощный опенсорсный инструмент для управления облачными ресурсами и автоматической ремедиации. Проект родился в недрах Capital One (да, того самого, у которого была утечка, но это не из-за Custodian, а наоборот - Custodian призван предотвращать подобное). Сейчас он поддерживается сообществом и имеет статус CNCF (Cloud Native Computing Foundation) sandbox project.

Архитектура и философия​

Custodian построен на идее policy-as-code. Ты описываешь политики в YAML-файлах, которые определяют:

• Что ты проверяешь (ресурсы: EC2, S3, IAM, RDS, Lambda и т.д.).
• Какие условия должны выполняться (фильтры: публичный бакет, отсутствие тега, открытый порт и т.д.).
• Что делать с несоответствующими ресурсами (действия: уведомить в Slack, исправить, удалить, остановить).

Custodian умеет работать в двух режимах:

1. Pull mode (периодический) - запускается по расписанию (например, каждые 6 часов), собирает все ресурсы из облака, применяет фильтры и выполняет действия. Это классический режим аудита и ремедиации.
2. Real-time mode (событийный) - использует облачные сервисы (AWS CloudWatch Events, EventBridge, AWS Config Rules) для реагирования на изменения в реальном времени. Как только создается ресурс, Custodian проверяет его и при необходимости сразу же исправляет или помечает. Это уже shift-left на уровне control plane.

Покрытие облаков​

Cloud Custodian изначально заточен под AWS. И в AWS он работает как швейцарские часы: покрывает почти все сервисы, имеет встроенные правила для CIS Benchmark, HIPAA, PCI. Поддержка GCP есть, но она менее зрелая: некоторые сервисы отсутствуют, не все фильтры работают. Azure тоже поддерживается, но я лично с ним работал меньше - там свои грабли. А вот Yandex Cloud официально не поддерживается. Но это не значит, что нельзя прикрутить - я расскажу в разделе 5, как мы адаптировали Custodian под YC с помощью custom-скриптов.

Количество правил: в официальном репозитории custodian есть предопределенные политики для AWS CIS, но они покрывают около 60-70% требований. Остальное нужно дописывать самому. Зато ты сам решаешь, что именно проверять, и как реагировать.

Автоматическая ремедиация​

Это сильная сторона Custodian. Допустим, ты нашел открытый Security Group. Ты можешь:

• Отправить уведомление в Slack с описанием нарушения.
• Создать тикет в Jira.
• Выполнить Python-скрипт (например, вызвать AWS Lambda), который удалит правило 0.0.0.0/0.
• Просто удалить ресурс (но осторожно - прод!).

Пример политики, которая находит незашифрованные S3-бакеты и применяет шифрование по умолчанию (авто-ремедиация):

policies:
  - name: s3-encrypt-unencrypted-buckets
    resource: s3
    description: |
      Применяет шифрование SSE-S3 к бакетам, у которых оно не включено
    filters:
      - type: bucket-encryption
        state: false
    actions:
      - type: set-bucket-encryption
crypto: AES256

Просто, понятно, работает. Другой пример: политика, которая останавливает EC2-инстансы без тега "Environment" после 18:00:

policies:
  - name: ec2-stop-untagged-instances
    resource: ec2
    filters:
      - "tag:Environment": absent
    actions:
      - type: stop
        # дополнительно можно добавить условие на время

Минусы​

• Сложность поддержки в масштабе. Если у тебя десятки аккаунтов, нужно настраивать роли, cross-account доступы. Custodian не предоставляет коробочного multi-account управления - придется либо запускать его в каждом аккаунте отдельно, либо использовать что-то вроде StackSets.
• Pull mode - это pull mode. Если запускать раз в сутки, между сканами может образоваться окно уязвимости. Real-time mode требует дополнительной настройки (CloudTrail, EventBridge) и может быть дорогим при большом количестве событий.
• Отсутствие GUI. Ты будешь смотреть на логи, CloudWatch метрики, может, развернешь Grafana. Но красивого дашборда "как в Wiz" не будет.
• YAML-политики могут стать монстром. Когда у тебя 200+ политик, поддерживать их версионность, тестировать, деплоить - это отдельный вызов.

Но если у тебя есть хотя бы один DevOps или SRE, который дружит с Python и AWS, Custodian станет незаменимым помощником. Мы его используем для:

• Автоматического тегирования новых ресурсов (если нет тега Owner - добавляем из какой-то логики).
• Удаления незакрепленных Elastic IP.
• Контроля за тем, чтобы инстансы не использовали устаревшие AMI (с критическими уязвимостями).
• Регулярной ротации ключей IAM.

2.2. Prowler: CIS Benchmarks для AWS/GCP/Azure, CLI-first, SARIF output​

Prowler - это проект, который начинался как скрипт для проверки AWS на соответствие CIS Benchmark. Со временем он дорос до многофункционального инструмента, поддерживающего AWS, GCP, Azure, и даже частично Kubernetes. Его философия: аудит, а не управление. Prowler не умеет автоматически исправлять нарушения, он лишь сообщает о них в удобном формате.

Особенности​

Prowler написан на Python, распространяется как CLI-инструмент. Запускается одной командой, после чего собирает данные через API облака, прогоняет сотни проверок и выдает отчет в JSON, CSV, HTML, SARIF (для интеграции с GitHub Advanced Security). Это идеальный инструмент для compliance-отчетов, периодических аудитов и для интеграции в CI/CD.

Покрытие облаков:

• AWS - наиболее полное: более 400 проверок, включая CIS 1.4, 1.5, 2.0, а также дополнительные проверки на основе лучших практик (например, AWS Well-Architected Framework).
• GCP - более 100 проверок по CIS GCP Benchmark.
• Azure - активно развивается, около 80 проверок.
• Yandex Cloud - официально нет, но можно использовать расширяемость через кастомные модули.

Multi-account support: Prowler умеет работать с несколькими аккаунтами через AWS Organizations или через переключение ролей. Ты запускаешь одну команду, и он прогоняет проверки по всем аккаунтам, куда у тебя есть доступ. Результаты агрегируются.

Output formats: Очень удобно для автоматизации. SARIF - это стандарт для результатов статического анализа, его понимают GitHub, GitLab, некоторые SIEM. Можно загружать отчеты в Security Hub или Splunk.

Использование​

Установка простая: pip install prowler. Но я рекомендую использовать Docker-образ, чтобы не возиться с зависимостями. Запуск для AWS:

prowler aws --profile my-profile --output-mode html

Через несколько минут получаешь HTML-отчет, где по каждому пункту CIS указано: пройдено, не пройдено, с каким риском, и ссылка на документацию.

Где Prowler выигрывает?​

1. Compliance-аудиты. Когда приходит аудитор и просит доказательства, вы просто выгружаете отчет Prowler. В нем есть все, что нужно: описание проверки, результат, timestamp.
2. Быстрый старт. Если вы никогда не занимались CSPM, запустите Prowler - он покажет все слабые места. Это как прожектор в темной комнате.
3. CI/CD интеграция. Можно добавить Prowler в pipeline развертывания, чтобы проверять, что новая инфраструктура соответствует политикам до того, как она попадет в прод.
4. Расширяемость. Можно писать собственные проверки на Python, используя фреймворк Prowler. Это полезно для специфических требований (например, проверка наличия определенных тегов, специфических политик IAM, характерных для вашей организации).

Минусы​

• Нет автоматической ремедиации. Prowler только сообщает, но не исправляет. Вам нужно либо вручную править, либо использовать другой инструмент (Custodian) для автофикса.
• Pull-only. Prowler не работает в реальном времени. Он запускается по запросу или по расписанию.
• Медленный на больших аккаунтах. Если у вас тысячи ресурсов, сбор данных может занять часы. Нужно оптимизировать через параллелизацию и кэширование.

Тем не менее, Prowler - это must-have для любого, кто работает с облаками. Мы используем его в паре с Custodian: Prowler для compliance-отчетности и еженедельных аудитов, Custodian для автоисправления типовых нарушений.

2.3. ScoutSuite: multi-cloud, HTML report, exceptions handling​

ScoutSuite - еще один опенсорсный проект, который раньше был известен как Scout2 (только для AWS). Сейчас это мультиоблачный инструмент, который выполняет аудит конфигурации и выдает интерактивный HTML-отчет с возможностью навигации по ресурсам. Его философия: предоставить максимально наглядную картину состояния облака.

Как работает​

ScoutSuite - это Python-скрипт, который собирает данные через API облачных провайдеров (AWS, GCP, Azure, Alibaba Cloud, и даже частично Oracle Cloud). После сбора он строит веб-отчет, который можно открыть в браузере. В отчете:

• Дашборд с общим количеством ресурсов, нарушениями по уровням критичности.
• Детальный обзор по каждому сервису: EC2, S3, IAM, VPC, и т.д.
• Возможность применять исключения (exceptions): если какой-то ресурс помечен как "исключение" (например, тестовая среда), он не будет считаться нарушением.

Exceptions handling​

Это важная фича для production. В реальной жизни всегда есть ресурсы, которые нарушают политику, но по уважительной причине. Например, публичный S3-бакет, который используется для статического хостинга сайта, - это нормально. ScoutSuite позволяет определить исключения по тегам, именам, региону. В отчете такие ресурсы помечаются как "excluded" и не портят общую статистику.

Покрытие облаков​

• AWS - отлично, практически все сервисы.
• GCP - хорошо, но не все сервисы покрыты.
• Azure - базовое покрытие.
• Yandex Cloud - не поддерживается официально.

Минусы​

• Нет автоматической ремедиации. Только отчет.
• Нет CI/CD интеграции в реальном времени. В основном используется как standalone-инструмент.
• Проект развивается медленно. После того как Scout2 стал ScoutSuite, активность снизилась. Последние коммиты не такие частые. Но для базовых проверок его все еще используют.

Когда ScoutSuite?​

Если вам нужен красивый отчет для руководства или аудиторов, и вы не хотите возиться с настройкой дашбордов, ScoutSuite - отличный вариант. Мы его применяем для презентаций результатов аудита: садимся, открываем HTML, показываем "вот наши открытые S3, вот уязвимые IAM-политики, вот инстансы без мониторинга". Наглядно и не требует технической глубокой подготовки от зрителя.

---

3. Коммерческие решения: когда нужно "всё и сразу", и бюджет позволяет​

Коммерческие CSPM/CNAPP-платформы - это совершенно другой уровень. Они решают проблему не просто аудита, а видимости, приоритизации и управления рисками в масштабе. Они обещают «agentless», «полный стек», «zero-touch deployment». Звучит красиво, но давайте посмотрим на три главных игрока: Wiz, Orca и Prisma Cloud. Я расскажу о них без восторгов, как инженер, который их внедрял и сопровождал.

3.1. Wiz: agentless scanning, attack path analysis, prioritization​

Wiz - это израильский стартап, который взорвал рынок облачной безопасности. За несколько лет они стали единорогом, и многие компании переходят на Wiz, потому что он реально работает и дает то, что называется «aha! moment».

Технология: agentless scanning​

Wiz не требует установки агентов на виртуальные машины или контейнеры. Вместо этого он через API подключается к облачным провайдерам (AWS, GCP, Azure, и даже Alibaba Cloud) и сканирует всю инфраструктуру. Для сканирования виртуальных машин он использует либо snapshot дисков (в AWS - через EBS snapshots, которые потом анализирует), либо безагентное сканирование через SSM. Для контейнеров - сканирует образы в реестрах и running pods через API Kubernetes.

Такой подход дает:

• Мгновенное развертывание - не нужно возиться с агентами.
• Полная видимость - даже тех ресурсов, где нельзя установить агент (например, serverless).
• Минимальное влияние на производительность.

Но есть и обратная сторона: стоимость API-вызовов может вырасти, особенно если вы сканируете snapshot'ы дисков в AWS (вы платите за каждый snapshot, который Wiz создает). Также есть небольшая задержка между созданием ресурса и его появлением в Wiz (минуты, но не real-time).

Attack path analysis​

Главная "фишка" Wiz - это графовый анализ путей атак. Он не просто выдает список нарушений (S3 публичный, IAM перепривилегирован), а строит граф зависимостей между ресурсами и показывает, как злоумышленник может использовать цепочку уязвимостей для достижения критического актива. Например: "Пользователь с правами на EC2 может получить доступ к метадате, из которой извлечь ключи от S3, в котором лежат пароли от production RDS". Wiz визуализирует этот путь и говорит, что это критический риск, хотя отдельно каждое нарушение может быть средней тяжести.

Prioritization​

Wiz использует машинное обучение и контекст для приоритизации. Он понимает, что открытый Security Group на тестовом инстансе без данных - это не страшно, а та же проблема на production с чувствительными данными - это P1. В отчетах Wiz вы получаете не просто список из 5000 проблем, а несколько десятков реально важных рисков, которые надо закрыть в первую очередь.

Цена и масштаб​

Wiz - дорогой. Ценообразование обычно зависит от количества ресурсов (EC2, контейнеры, serverless). Для среднего enterprise (1000+ аккаунтов) речь идет о миллионе долларов в год и выше. Но для многих компаний это окупается за счет сокращения времени на расследование инцидентов и снижения operational overhead.

Что мне нравится в Wiz:​

• Простота внедрения: дал роль в AWS, через час уже видишь дашборд с рисками.
• Графовый анализ - реально помогает понять, где самые опасные комбинации.
• Интеграция с CI/CD: можно блокировать деплой, если новая конфигурация создает критический риск.
• Удобный интерфейс для не-технических пользователей (CISO, аудиторы).

Что не нравится:​

• Цена, особенно если у вас много ресурсов.
• Vendor lock-in: данные и аналитика внутри Wiz, экспортировать сложно.
• Не все фичи работают одинаково хорошо во всех облаках: в GCP поддержка может отставать от AWS.
• Для Yandex Cloud официально нет поддержки - придется изобретать.

3.2. Orca: SideScanning technology, full stack visibility​

Orca Security - это конкурент Wiz, который делает упор на технологию SideScanning. Вместо того чтобы создавать snapshot'ы дисков, Orca сканирует storage layer облака (например, AWS EBS и RDS snapshot'ы) и извлекает оттуда информацию о workload'ах, включая файлы, конфиги, логи. Это тоже agentless, но подход другой.

SideScanning в деталях​

Orca подключается к вашим облачным аккаунтам и через API получает доступ к хранилищам (S3, EBS, EFS, RDS). Затем он анализирует эти данные и строит картину: какие приложения работают, какие уязвимости в ПО, какие секреты лежат в конфигах, есть ли малварь. Все это без необходимости ставить агент внутрь ВМ.

Преимущества:

• Не нужно даже создавать snapshot'ы (как Wiz), что снижает затраты на API.
• Глубокая видимость внутрь workload'ов: можно обнаружить hardcoded credentials, наличие вредоносных файлов.
• Охватывает также serverless и контейнеры.

Full stack visibility​

Orca строит единую карту активов: от IAM-ролей до запущенных процессов внутри контейнеров. Интегрируется с Kubernetes, показывает риски на уровне кластера (например, pod с привилегированным доступом).

Сравнение с Wiz​

Orca часто дешевле Wiz, особенно для компаний с большим количеством VM, так как не требует snapshot'ов. Интерфейс у Orca чуть менее навороченный, чем у Wiz, но тоже интуитивный. В плане графового анализа Orca тоже имеет "attack path", но он менее зрелый, чем в Wiz.

Для российской специфики Orca также не поддерживает Yandex Cloud, но может работать через интеграцию с AWS, если у вас гибридная инфраструктура.

3.3. Prisma Cloud: CSPM + CWPP + CIEM - comprehensive platform​

Prisma Cloud от Palo Alto Networks - это "старая школа". Они купили несколько стартапов (RedLock для CSPM, Twistlock для CWPP) и объединили в единую платформу. Это монолитное решение, которое покрывает практически все: CSPM, CWPP, CIEM, KSPM, Serverless Security, Network Security (ранее Aporeto). Если вы уже используете Palo Alto в сети, то Prisma Cloud может вписаться в экосистему.

Особенности​

• CSPM: проверка конфигурации облаков (AWS, GCP, Azure, Alibaba, и даже частично Yandex Cloud через open-source интеграции? Нет, официально нет). Поддержка compliance frameworks: CIS, NIST, PCI, HIPAA.
• CWPP: агентная защита для VM и контейнеров. Можно ставить агент в ОС, который обеспечивает runtime-защиту, сканирование уязвимостей, контроль целостности.
• CIEM: управление правами доступа в облаке. Анализирует IAM-политики, находит избыточные права, рекомендует least privilege.
• KSPM: проверка конфигурации Kubernetes (RBAC, pod security policies, network policies).
• Network Security: микросервисная сегментация (вплоть до L7).

Prisma Cloud - это тяжелый комбайн. Он требует времени на внедрение (недели-месяцы), настройки агентов, обучения. Зато он может быть единственным инструментом безопасности для облака, если у вас есть бюджет и команда.

Плюсы:​

• Интеграция с другими продуктами Palo Alto (например, через Cortex XSOAR для SOAR).
• Глубокая защита на уровне runtime (не просто конфигурация, а обнаружение аномалий).
• Хороший отчетный модуль для compliance.

Минусы:​

• Сложность настройки и поддержки.
• Агенты - это overhead, особенно в контейнерах.
• Цена - обычно не дешевле Wiz, а иногда выше, особенно если добавлять все модули.
• Интерфейс и UX уступают Wiz и Orca - чувствуется, что это продукт, собранный из нескольких разных.

---

4. Сравнительная таблица: open-source vs коммерческие​

Теперь давай сведем всё в одну таблицу. Я не буду давать оценки типа "хорошо/плохо", а приведу факты. Решение выбирать тебе.

4.1. Coverage: поддержка облачных провайдеров​

Инструмент	AWS	GCP	Azure	Yandex Cloud	Другие
Cloud Custodian	+++ (полная поддержка)	+ (ограниченная)	+ (ограниченная)	- (только кастом)	-
Prowler	+++ (400+ checks)	++ (100+ checks)	+ (базовые)	-	-
ScoutSuite	+++	++	+	-	Alibaba, Oracle
Wiz	+++	++	++	-	Alibaba
Orca	+++	++	++	-	-
Prisma Cloud	+++	+++	+++	-	Alibaba, OCI

Вывод: ни один из перечисленных инструментов официально не поддерживает Yandex Cloud. Это проблема для российских команд. Но есть пути: использовать Cloud Custodian с кастомными скриптами, писать свои проверки на основе yc CLI или использовать встроенный Cloud Advisor от YC (об этом позже).

4.2. Checks: количество и глубина проверок по CIS Benchmark​

Инструмент	Количество checks	Глубина	Настраиваемость
Cloud Custodian	~300+ (предопределенные) + любые свои	Высокая (можно проверять любые атрибуты)	Полная (YAML/ Python)
Prowler	400+ (AWS), 100+ (GCP)	Средняя (следует CIS строго)	Можно добавлять свои модули
ScoutSuite	200+ (AWS)	Средняя	Можно добавлять правила в конфиге
Wiz	1000+ (включая свои)	Очень высокая (учитывает контекст)	Ограниченная (только через GUI)
Orca	800+	Высокая	Ограниченная
Prisma Cloud	1000+	Высокая	Широкие возможности через политики

Вывод: коммерческие инструменты дают больше предопределенных checks и учитывают контекст (например, чувствительность данных). Но опенсорс позволяет дописать любую проверку, если у вас есть специфические требования.

4.3. Remediation: auto-fix capability, notification integration​

​

Инструмент	Auto-remediation	Notifications	Integration with ticketing
Cloud Custodian	+++ (actions: stop, delete, modify, run lambda)	Slack, Email, SNS, Jira, ServiceNow	Через actions
Prowler	- (только report)	- (только output)	- (нужен внешний пайплайн)
ScoutSuite	- (только report)	-	-
Wiz	+ (через webhooks + external automation, но не встроенная auto-fix)	Slack, Jira, Teams, ServiceNow	Да, через интеграции
Orca	+ (аналогично)	Slack, Jira, etc.	Да
Prisma Cloud	++ (есть playbooks, но требуют настройки)	Slack, Jira, ServiceNow	Да

Вывод: Cloud Custodian - единственный инструмент, который из коробки предлагает мощные возможности автоисправления. Коммерческие инструменты обычно делают акцент на обнаружении и приоритизации, а remediation отдают на откуп внешним системам (Terraform, Ansible, lambda-функции). Это вопрос архитектуры: они считают, что автоматическое исправление конфигураций может быть опасным, и хотят, чтобы человек подтвердил действие.

4.4. Стоимость (ориентировочно)​

• Cloud Custodian, Prowler, ScoutSuite: 0$ лицензионных, только затраты на инфраструктуру (EC2, Lambda, CloudWatch). Для масштаба 10-20 аккаунтов - пара сотен долларов в месяц.
• Wiz, Orca: от $50 до $100 за ресурс (VM, container) в год. Для 1000 ресурсов - $50k-100k в год. Enterprise - $500k+.
• Prisma Cloud: сложная модель, часто от $100 за workload в год, плюс модули. Минимальный контракт - от $100k.

---

5. Практика: как поднять CSPM своими руками​

Теория теорией, а давай перейдем к делу. Я покажу реальные примеры настройки инструментов, с которыми работал. Основной фокус - Cloud Custodian, так как он дает максимальную гибкость. Также покажу, как работать с Yandex Cloud, где нет готовых решений, и как интегрировать CSPM в CI/CD.

5.1. Cloud Custodian: установка, первая политика, scheduled execution​

Установка​

Лучший способ - через pip в виртуальном окружении:

python3 -m venv custodian-env
source custodian-env/bin/activate
pip install c7n

Также можно использовать Docker:

docker pull cloudcustodian/c7n

Настройка доступа​

Custodian использует стандартные AWS SDK credentials. Убедись, что у тебя настроены профили AWS CLI (~/.aws/credentials), либо заданы переменные окружения AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION.

Если ты планируешь запускать Custodian в CI/CD, используй роли IAM с минимальными правами. Пример минимальной политики для Custodian: нужно разрешить ec2:DescribeInstances, s3:ListAllMyBuckets и т.д., а также права на выполнение действий (например, ec2:StopInstances).

Первая политика: проверка наличия тега "Owner"​

Создадим файл policy.yml:

policies:
  - name: ec2-check-owner-tag
    resource: aws.ec2
    description: |
      Находит EC2-инстансы без тега Owner и отправляет уведомление в SNS.
    filters:
      - "tag:Owner": absent
    actions:
      - type: notify
        template: default
        priority_header: "2"
        subject: "EC2 instance missing Owner tag"
        to:
          - arn:aws:sns:us-east-1:123456789012:security-topic
        transport:
          type: sns
          topic: arn:aws:sns:us-east-1:123456789012:security-topic

Запустим политику:

custodian run -s ./output policy.yml

После выполнения в папке output появится файл ec2-check-owner-tag.json с результатами. Если есть нарушения, уйдет уведомление в SNS.

Scheduled execution (cron)​

Чтобы запускать политики регулярно, используй AWS Lambda с CloudWatch Events. Custodian предоставляет готовый шаблон для деплоя политик как Lambda-функций. Это делается через команду:

custodian deploy --name my-policy --region us-east-1 policy.yml

Эта команда создаст Lambda-функцию, IAM-роль и CloudWatch Events правило, которое будет вызывать функцию по расписанию (если в политике указан mode). Пример политики с периодическим запуском:

policies:
  - name: ec2-check-owner-tag-scheduled
    resource: aws.ec2
    mode:
      type: cloudtrail
      role: arn:aws:iam::123456789012:role/custodian-role
      schedule: "rate(6 hours)"
    filters:
      - "tag:Owner": absent
    actions:
      - type: notify
        # ...

После деплоя политика будет выполняться каждые 6 часов и отправлять отчеты.

Реальная политика с авторемедиацией: удаление незакрепленных Elastic IP​

policies:
  - name: ec2-release-unattached-eip
    resource: eip
    filters:
      - "InstanceId": absent
      - "NetworkInterfaceId": absent
    actions:
      - type: release

Это высвобождает Elastic IP, которые не привязаны ни к какому ресурсу, тем самым экономя деньги и закрывая потенциальный риск (забытые EIP могут быть перехвачены злоумышленником? Не совсем, но они стоят денег). Кстати, о рисках: если EIP не привязан, он просто простаивает, но если его кто-то привяжет к своему ресурсу? Нет, он все еще в вашем аккаунте, но с ним ничего не сделать без прав. Так что это больше финансовая экономия.

5.2. Yandex Cloud: custom checks с yc CLI + Python​

Как я уже сказал, ни один из популярных CSPM-инструментов не поддерживает Yandex Cloud официально. Но Yandex Cloud предоставляет свой Cloud Advisor - встроенный инструмент, который проверяет конфигурацию по best practices и выдает рекомендации. Это аналог AWS Trusted Advisor. Однако функционал Cloud Advisor ограничен, и он не предоставляет возможности автоматической ремедиации или расширенных проверок.

Что делать, если вам нужен полноценный CSPM для YC? Наш путь: написать свой скрипт на Python, который через yc CLI и API Yandex Cloud собирает данные, прогоняет проверки и отправляет результаты в SIEM или в систему управления инцидентами.

Пример: проверка публичных бакетов Object Storage​

Yandex Cloud Object Storage аналогичен S3. Проверим, есть ли бакеты с публичным доступом на чтение.

Для начала установим yc CLI и настроим профиль.

Скрипт yc_cspm_check.py:

import subprocess
import json
import boto3  # для S3-совместимого API YC (используем S3 API)

# Получаем список бакетов через yc CLI
def get_buckets():
    cmd = ['yc', 'storage', 'bucket', 'list', '--format', 'json']
    output = subprocess.check_output(cmd)
    buckets = json.loads(output)
    return [b['name'] for b in buckets]

# Проверяем ACL каждого бакета через S3 API
def check_public_buckets(bucket_names, access_key, secret_key, endpoint='https://storage.yandexcloud.net'):
    s3_client = boto3.client('s3',
                              aws_access_key_id=access_key,
                              aws_secret_access_key=secret_key,
                              endpoint_url=endpoint)
    public_buckets = []
    for bucket in bucket_names:
        try:
            acl = s3_client.get_bucket_acl(Bucket=bucket)
            for grant in acl['Grants']:
                if 'URI' in grant['Grantee'] and 'http://acs.amazonaws.com/groups/global/AllUsers' in grant['Grantee']['URI']:
                    if grant['Permission'] in ['READ', 'FULL_CONTROL']:
                        public_buckets.append(bucket)
                        break
        except Exception as e:
            print(f"Error checking bucket {bucket}: {e}")
    return public_buckets

if __name__ == "__main__":
    buckets = get_buckets()
    # Здесь нужно подставить ключи от сервисного аккаунта с правами на чтение бакетов
    public = check_public_buckets(buckets, access_key='YOUR_ACCESS_KEY', secret_key='YOUR_SECRET_KEY')
    if public:
        print(f"Public buckets found: {public}")
        # Тут отправить в SIEM или в телеграм
    else:
        print("No public buckets.")

Это примитивный пример, но он показывает принцип. Для полноценного CSPM нужно:

• Покрыть все типы ресурсов: compute instances, managed databases, kubernetes clusters, IAM, VPC, security groups.
• Для каждого ресурса написать набор проверок (CIS-inspired).
• Организовать периодический запуск (cron в ВМ или функция Yandex Cloud Functions).
• Настроить вывод и интеграцию с уведомлениями.

Можно также использовать Cloud Custodian с кастомным провайдером. Custodian имеет архитектуру, позволяющую добавлять новые облака. Но это требует серьезной разработки на Python. Если у вас есть ресурсы - можно взять Custodian как основу и написать свой ресурс-менеджер для YC. Я пробовал такой подход, но времени уходит много. Для большинства компаний проще написать отдельный скрипт.

Также стоит упомянуть, что Yandex Cloud развивает свой Security Command Center (аналог AWS Security Hub), который включает в себя некоторые функции CSPM. На момент написания статьи он еще находится в активной разработке, но уже может быть использован для базового контроля. Рекомендую следить за новостями.

5.3. CI/CD gate: Prowler/Custodian в Terraform pipeline​

Shift-left - это когда мы проверяем безопасность конфигурации еще на этапе разработки, до деплоя в облако. Идеальный подход: запускать CSPM-проверки в пайплайне Terraform после выполнения terraform plan, но перед apply.

Как это сделать?

1. Генерируем план инфраструктуры в JSON.
2. Запускаем инструмент, который проверяет план на соответствие политикам. Здесь можно использовать tfsec, checkov, terrascan - они специально заточены на анализ Terraform кода. Но наш CSPM-инструмент тоже можно адаптировать, если он умеет работать с планом.
3. Блокируем apply, если найдены нарушения.

Рассмотрим вариант с Prowler в роли CI/CD gate. Prowler умеет проверять реальную инфраструктуру, но до деплоя инфраструктуры еще нет. Однако можно развернуть инфраструктуру в отдельном аккаунте/проекте (pre-prod) и прогнать Prowler на нем, или использовать статический анализ кода.

Проще использовать специализированные инструменты: checkov (от Bridgecrew) и tfsec. Они интегрируются в Terraform pipeline и проверяют код на основе политик, аналогичных CSPM. Например, checkov имеет сотни проверок для Terraform, включая запрет на публичные S3 бакеты, открытые Security Groups и т.д.

Пример для GitHub Actions:

name: Terraform Security Scan
on: [pull_request]

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          soft_fail: false

Если Checkov находит нарушение, pipeline падает, и разработчик должен исправить код до merge.

Но что, если мы хотим использовать именно Prowler для проверки уже развернутой инфраструктуры? Тогда можно развернуть инфраструктуру в тестовом окружении, запустить Prowler, и только если нарушений нет, продолжать деплой в прод. Это более тяжелый подход, но он дает реальную картину, потому что учитывает не только код, но и возможные ручные изменения.

Pipeline может выглядеть так:

1. Terraform apply в staging.
2. Запуск Prowler на staging-аккаунте.
3. Анализ отчета: если есть критические нарушения, откат (terraform destroy) и провал пайплайна.
4. Если все хорошо, переключиться на прод аккаунт и выполнить apply.

Такой подход требует автоматизации и управления состояниями Terraform (использование workspace или отдельных state-файлов). Но он обеспечивает высокий уровень уверенности, что в прод не уедет небезопасная конфигурация.