Настройка AWS GuardDuty: обнаружение угроз и автоматическое реагирование

Настройка AWS GuardDuty для обнаружения угроз

Представьте: в 3 часа ночи вы получаете алерт от GuardDuty о критическом инциденте. Без предварительной настройки это, скорее всего, ложное срабатывание. Но если это реальная атака, каждый час простоя обходится в значительные суммы, а утечка данных может привести к многомиллионным потерям. Без правильной настройки вы рискуете пропустить критическую атаку или утонуть в ложных срабатываниях. Мы настраиваем GuardDuty так, чтобы вы видели только реальные угрозы, а автоматическое реагирование блокировало атаки за минуты. За нашими плечами сотни проектов — от стартапов до enterprise с десятками аккаунтов. После нашей настройки количество ложных срабатываний снижается на 90%. При этом мы документируем каждый этап и проводим обучение команды заказчика. 5 лет на рынке подтверждают наш опыт в безопасности AWS.

Почему GuardDuty нужно настраивать правильно?

GuardDuty включается за три клика в консоли, но без правильной конфигурации он не приносит пользы. Нужно:

• указать, какие данные анализировать (CloudTrail, VPC Flow Logs, DNS, S3-логи);
• настроить multi-account через Organizations, чтобы не подключать каждый аккаунт вручную;
• определить каналы оповещений (Slack, PagerDuty, Telegram) и создать severity-фильтры;
• написать suppression rules для белых зон — пентест-серверов, сканеров, легитимных скриптов.

Без этих шагов вы рискуете либо пропустить атаку, либо утонуть в false positives. Один пропущенный инцидент — и затраты на восстановление могут превысить разумные пределы. В нашей практике был случай, когда стартап с 5 аккаунтами за месяц получил более 3000 алертов, из которых реальными оказались только 15 — остальное шум от сканеров безопасности. После настройки suppression rules и фильтрации по severity число ложных срабатываний снизилось до 5%.

Как GuardDuty анализирует данные: источники и severity

GuardDuty анализирует три слоя данных и выдаёт findings трёх категорий.

Скомпрометированные учётные данные

• UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B — успешный вход с аномального IP или необычной геолокации.
• Recon:IAMUser/MaliciousIPCaller — попытки перечисления IAM-ресурсов с IP из TOR или известных атакующих сетей.

Скомпрометированные инстансы

• Backdoor:EC2/C&CActivity.B — EC2 обращается к C2-инфраструктуре.
• CryptoCurrency:EC2/BitcoinTool.B!DNS — DNS-запросы к майнинговым пулам (классика после компрометации через веб-уязвимость).

Аномалии данных

• Exfiltration:S3/AnomalousBehavior — внезапный большой объём скачанных данных из S3 за короткое время.

Как автоматизировать реагирование на инциденты через EventBridge?

GuardDuty отправляет findings в EventBridge. Оттуда — в SNS, Lambda, SQS. Минимальная связка для оповещений:

resource "aws_cloudwatch_event_rule" "guardduty_high" {
  name        = "guardduty-high-severity"
  description = "GuardDuty findings severity >= 7"
  event_pattern = jsonencode({
    source      = ["aws.guardduty"]
    detail-type = ["GuardDuty Finding"]
    detail = {
      severity = [{
        numeric = [">=", 7]
      }]
    }
  })
}

resource "aws_cloudwatch_event_target" "sns" {
  rule      = aws_cloudwatch_event_rule.guardduty_high.name
  target_id = "SendToSNS"
  arn       = aws_sns_topic.security_alerts.arn
}

Severity в GuardDuty: Low (1–3.9), Medium (4–6.9), High (7–8.9), Critical (9–10). Для автоматической блокировки IP в WAF или Security Group реагируем на High и выше. Medium — в очередь для ручного разбора.

Экономический эффект от внедрения

GuardDuty — один из самых экономичных инструментов безопасности. Средняя стоимость для компании с 10 аккаунтами невысока, а предотвращение одного инцидента может сэкономить сотни тысяч долларов. По данным AWS, внедрение окупается в среднем за несколько месяцев. В нашей практике клиенты отмечают снижение затрат на расследование инцидентов в разы.

Процесс настройки за 5 шагов

1. Аудит текущих логов и конфигурации безопасности.
2. Включение детектора с нужными источниками (S3, Kubernetes, Malware Protection).
3. Подключение multi-account через AWS Organizations с делегированным администратором.
4. Создание EventBridge-правил для оповещений (Slack, PagerDuty, Telegram).
5. Написание suppression rules для белых IP и штатных сканеров.

Каждый шаг сопровождается кодом на Terraform и документацией. Среднее время внедрения — 2 дня. В результате вы получаете работающую систему с автоматическим реагированием и чётким планом действий на каждый тип инцидента.

Что входит в работу

Terraform-конфигурация multi-account

В организациях на AWS Organizations GuardDuty лучше настраивать централизованно. Один account (Security или Audit) становится делегированным администратором и собирает findings со всех member accounts.

# В management account
resource "aws_guardduty_organization_admin_account" "main" {
  admin_account_id = var.security_account_id
}

# В security account
resource "aws_guardduty_detector" "main" {
  enable = true
  datasources {
    s3_logs {
      enable = true
    }
    kubernetes {
      audit_logs {
        enable = true
      }
    }
    malware_protection {
      scan_ec2_instance_with_findings {
        ebs_volumes {
          enable = true
        }
      }
    }
  }
}

resource "aws_guardduty_organization_configuration" "main" {
  auto_enable_organization_members = "ALL"
  detector_id = aws_guardduty_detector.main.id
}

auto_enable_organization_members = "ALL" включает GuardDuty для новых аккаунтов автоматически. Иначе каждый аккаунт нужно подключать вручную.

Suppression rules: как убрать шум

После включения GuardDuty первые недели будет шум. Типичный пример: пентест внутри инфраструктуры генерирует Recon:EC2/PortProbeUnprotectedPort. Для известных источников создаём suppression rule:

resource "aws_guardduty_filter" "pentest_suppression" {
  detector_id = aws_guardduty_detector.main.id
  name = "suppress-internal-pentest"
  action = "ARCHIVE"
  rank = 1
  finding_criteria {
    criterion {
      field = "service.action.networkConnectionAction.remoteIpDetails.ipAddressV4"
      equals = ["10.0.1.50"] # IP пентест-сервера
    }
  }
}

Suppression не удаляет findings — они архивируются. При необходимости аудита вся история сохранена.

Для настройки оптимальных suppression rules под вашу инфраструктуру свяжитесь с нами — мы проанализируем логи и предложим готовые правила. Закажите консультацию по внедрению GuardDuty на вашем проекте.