Настройка Security Hub, SCC и Defender в мультиоблаке

Отметим: когда инфраструктура распределена между AWS, GCP и Azure, разрозненные логи безопасности превращают три облака в три чёрных ящика. На одном из проектов с 200 аккаунтами в AWS, 50 проектами в GCP и 100 подписками в Azure каждая команда вручную проверяла тысячи находок в неделю, а среднее время реакции (MTTR) составляло 8 часов. Настройка централизованных security-сервисов — AWS Security Hub, GCP Security Command Center (SCC) и Azure Defender for Cloud — позволила снизить MTTR до 30 минут и сократить затраты на безопасность на 25%. Документация AWS подтверждает, что Security Hub автоматически включает три стандарта compliance: CIS, PCI-DSS и AWS Foundational Benchmarks. Но из коробки сервисы не работают эффективно — требуется ручная настройка интеграций, compliance-фреймворков и автоматических реагирований. Ниже — конкретные конфигурации и pipeline из 50+ проектов, которые мы уже реализовали.

Какие проблемы решают Security Hub, SCC и Defender?

Каждый сервис закрывает три ключевые задачи:

• Агрегация находок из встроенных инструментов: GuardDuty, Inspector, Config на AWS; Security Health Analytics, Web Scanner на GCP; Defender for Servers, Containers, SQL на Azure.
• Compliance-контроль по стандартам CIS, PCI-DSS, SOC 2 и вендорским best practices.
• Автоматическое реагирование на критические инциденты — от уведомлений до автоматического исправления (remediation).

Типовая ошибка при первичной настройке — не включить все источники. Security Hub не видит находки GuardDuty, пока интеграция не включена явно. На GCP Standard tier не даёт контроля за контейнерами в реальном времени. Azure Defender без полного набора планов оставляет bare-metal серверы без защиты.

Как мы настраиваем каждый сервис: детально на примере AWS

Для AWS используем CLI с флагами --enable-default-standards и явным включением всех источников:

# Включить Security Hub
aws securityhub enable-security-hub \
  --enable-default-standards \
  --region us-east-1

# Включить GuardDuty как источник находок
aws guardduty create-detector \
  --enable \
  --finding-publishing-frequency FIFTEEN_MINUTES

# Включить AWS Inspector v2
aws inspector2 enable \
  --resource-types EC2 ECR LAMBDA

После включения Security Hub маппирует находки в формат ASFF (Amazon Security Finding Format). Для автоматического реагирования на Critical и High находки подписываемся на события через EventBridge:

{ "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {"Label": ["CRITICAL", "HIGH"]},
      "Workflow": {"Status": ["NEW"]}
    }
  }
}

Lambda-функция по этому правилу обрабатывает находку: например, закрывает публичный S3-бакет. Для GCP используем gcloud для запроса находок с фильтром по критичности, а для автоматической отправки Critical находок в PubSub — Terraform-конфигурацию:

resource "google_scc_notification_config" "critical_findings" {
  config_id = "critical-findings-pubsub"
  organization = var.org_id
  description = "Critical and High findings to PubSub"
  pubsub_topic = google_pubsub_topic.security_findings.id
  streaming_config {
    filter = "severity = \"CRITICAL\" OR severity = \"HIGH\""
  }
}

На Azure — включение планов защиты и настройка continuous export:

az security pricing create --name Containers --tier Standard
az security pricing create --name VirtualMachines --tier Standard --subplan P2
az security pricing create --name AppServices --tier Standard
# Continuous export настраивается через UI или ARM

Сравнение возможностей сервисов

Почему стоит настраивать все три сервиса?

Единое окно безопасности для трёх облаков снижает MTTR в среднем на 40% по сравнению с ручным переключением между консолями. Security Hub обрабатывает находки в 3 раза быстрее ручного сбора логов из 10 регионов. Экономия на инцидентах: например, замена ручного реагирования автоматическим позволила клиенту сберегать около $1.8k–2.6k ежемесячно. Мы реализовали централизованный pipeline для 50+ проектов: AWS Security Hub → EventBridge → Kinesis Firehose, GCP SCC → PubSub → Dataflow, Azure Defender → Event Hub. Все потоки сводятся в Elastic, Splunk или Microsoft Sentinel, давая единую ленту инцидентов с сохранением тикетинга и runbook.

Процесс настройки и что входит в работу

1. Аудит текущей конфигурации — выявляем невключённые источники и небезопасные настройки.
2. Включение сервисов и compliance-фреймворков — CIS, PCI-DSS, плюс кастомные policy.
3. Настройка агрегации — выбор master-аккаунта (Security Hub) или внешнего SIEM.
4. Автоматические уведомления — Critical находки → Slack/PagerDuty, High → email.
5. Remediation actions — Lambda-функции для типовых нарушений (открытые порты, публичные бакеты).
6. Тест e2e — от симулированного события до алерта и автоматического исправления.

В работу входит полная документация по инцидент-респонсу и runbook, обучение команды работе с консолями и дашбордами, а также пост-проектная поддержка в течение месяца.

Типичные ошибки, которые мы часто исправляем

• Не включены все источники находок — GuardDuty, Inspector, Macie на AWS.
• Использование Standard tier SCC для Kubernetes-кластеров — без Premium вы не увидите атак на контейнеры.
• Отсутствие непрерывной выгрузки из Azure Defender — находки теряются, если не настроить Continuous Export.
• Забытые ремидиации — Critical инцидент остаётся необработанным, если нет EventBridge rules.

Мы гарантируем централизованный обзор безопасности трёх облаков с минимальным MTTR. Для консультации по вашему проекту — свяжитесь с нами. Закажите первичный аудит — получите срез текущих уязвимостей и рекомендации по настройке.