Налаштування 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 регіонів. Економія на інцидентах: наприклад, заміна ручного реагування автоматичним дозволила клієнту зберігати близько 200 000 грн щомісяця. Ми реалізували централізований 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. Для консультації по вашому проєкту — зв'яжіться з нами. Замовте первинний аудит — отримайте зріз поточних вразливостей та рекомендації з налаштування.