Налаштування AWS GuardDuty для виявлення загроз

Налаштування AWS GuardDuty для виявлення загроз

Уявіть: о 3 годині ночі ви отримуєте алерт від GuardDuty про критичний інцидент. Без попереднього налаштування це, швидше за все, хибне спрацювання. Але якщо це реальна атака, кожна година простою коштує значних сум, а витік даних може призвести до багатомільйонних втрат. Без правильного налаштування ви ризикуєте пропустити критичну атаку або потонути в хибних спрацюваннях. Ми налаштовуємо GuardDuty так, щоб ви бачили лише реальні загрози, а автоматичне реагування блокувало атаки за хвилини. За нашими плечима сотні проєктів — від стартапів до enterprise з десятками акаунтів. Після нашого налаштування кількість хибних спрацювань знижується на 90%. При цьому ми документуємо кожен етап і проводимо навчання команди замовника. 5+ років на ринку та 300+ успішних проєктів підтверджують наш досвід у безпеці AWS. Ми гарантуємо якість і маємо відповідні сертифікати 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 трьох категорій. Як зазначається в документації AWS, „GuardDuty is a threat detection service that continuously monitors for malicious activity and unauthorized behavior“.

Скомпрометовані облікові дані

• 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 акаунтами середня вартість GuardDuty становить близько $150 на місяць при помірному обсязі логів. А запобігання одному інциденту може заощадити сотні тисяч доларів. Порівняно з традиційними SIEM системами, GuardDuty виявляє загрози в 3 рази швидше, а вартість володіння — у 5 разів нижча. За даними AWS, впровадження окупається в середньому за 3 місяці. У нашій практиці клієнти відзначають зниження витрат на розслідування інцидентів у 4 рази.

Процес налаштування за 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 на вашому проєкті.