И почему вы тоже должны!

TL; DR - используйте CDK, чтобы активировать и отслеживать результаты GuardDuty по всей вашей учетной записи AWS. Все, что вам нужно, - это учетная запись AWS, компьютер и тема в социальных сетях. Https://github.com/tlh2857/GuardDuty-Global-Notifier

Недавно я начал работать над проблемой:

Как можно легко включить GuardDuty во всех регионах AWS (передовой опыт безопасности AWS) и настроить оповещения при появлении результатов в любом из этих регионов?

Ключевое слово - легко.

Если вы не знакомы с GuardDuty и используете AWS, я рекомендую вам проверить это. Он использует машинное обучение (ML) для выявления необычных и вредоносных действий путем анализа журналов CloudTrail, журналов потоков VPC, операций с данными S3 и журналов DNS. Это действительно эффективный способ обнаружить вторжение в вашу базу пользователей или инфраструктуру AWS. Подумайте об обнаружении нового экземпляра EC2 в регионе, к которому вы никогда раньше не прикасались, или об обнаружении сканирования портов в своем частном VPC. Вы можете включить GuardDuty для отслеживания этой неприятной активности, а затем вы можете настроить оповещения, чтобы получать уведомления, когда это действие происходит. Звучит неплохо, правда?

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

Таким образом, задача, которую я поставил перед собой, заключалась в том, чтобы автоматизировать процесс включения и реагирования на события в GuardDuty в каждом регионе AWS. Пусть игры начнутся!

Возможные решения

Пытаясь решить эту задачу, я рассматривал несколько разных вариантов. Некоторые из них могли сработать, если бы я хотел потратить больше денег (я знаю, что я дешевка).

Моя первая мысль заключалась в том, чтобы отслеживать журналы CloudTrail непосредственно на предмет обнаружения GuardDuty. Что хорошо в этом варианте, так это то, что он уменьшил количество региональных услуг, которые вы предоставляли. Если CloudTrail уже включен во всех регионах и для всех сервисов, это было бы так же просто, как отправить мои журналы CloudTrail в CloudWatch Logs, а затем использовать фильтр подписки для пересылки журналов поиска GuardDuty в функцию Lambda, которая служит прокси для темы SNS.

Единственная проблема? GuardDuty не регистрирует результаты в CloudTrail. Он отправляет их только в CloudWatch Events. И хотя CloudTrail регистрирует вызовы, выполняемые сервисами AWS, он не регистрирует создание самого GuardDuty. Вздох.

Затем я посмотрел на отправку результатов GuardDuty в центральную корзину S3. Затем я мог бы вызвать функцию Lambda для отправки предупреждения всякий раз, когда результаты помещаются в это ведро. Это показалось приятным, особенно потому, что результаты можно было отправить в центральную корзину ,, но потом я понял, что вам придется использовать KMS ключ для шифрования этих результатов. GuardDuty буквально не дает вам возможности отправить эти результаты без привязки ключа KMS. Хотя это хорошая практика безопасности, я не хочу тратить 16 долларов, необходимых для предоставления ключа KMS в каждом регионе. Я знаю, я дешевка!

После этого я рассмотрел отправку журналов на шину событий EventBridge. Это круто, потому что вы можете использовать их для агрегирования событий по нескольким аккаунтам AWS. Особенность в том, что он может агрегировать события только в пределах одного региона. Опять вздох!

Теперь вы можете задаться вопросом:

«Почему бы не использовать правила событий CloudWatch с темой для социальных сетей в качестве цели?»

Проблема только в том, что услуги тоже региональные. Я просто не хотел выделять 16 отдельных тем в социальных сетях, потому что управление этими подписками казалось утомительным. Мне нужен был способ узнавать обо всех выводах GuardDuty во всех регионах AWS с помощью единой подписки на SNS.

Окончательное решение

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

Создайте правило событий CloudWatch в каждом регионе, каждое из которых указывает на региональную функцию Lambda, которая использует AWS SDK для вызова одной темы в социальной сети, на которую я подписан.

Ура!

Но как?

Моя первоначальная мысль заключалась в том, чтобы использовать CloudFormation StackSets для развертывания ресурсов в каждом регионе AWS. Это абсолютно сработало бы, если бы я не хотел писать CloudFormation с нуля. Отказавшись от этого плана, я выдвинул вторую идею: AWS CDK.

Что такое AWS Cloud Development Kit (CDK), спросите вы?

« AWS Cloud Development Kit (AWS CDK) - это среда разработки программного обеспечения с открытым исходным кодом для определения ресурсов облачных приложений с использованием знакомых языков программирования ».

Короче говоря, если вы любите кодировать, вам понравится CDK. Вот схема инфраструктуры, которую мы предоставим с помощью этого решения:

Что касается инфраструктуры AWS, это центральная тема социальной сети, которую вы создаете и на которую подписываетесь. Затем с помощью CDK вы включите события GuardDuty для отправки сообщения об этой центральной теме SNS через функцию Lambda в каждом регионе AWS. Довольно аккуратно, да?

Развертывание решения

Хорошо, вот что вам понадобится, чтобы начать работу.

После того, как вы настроили вышеуказанные элементы, решение будет таким же простым, как 1, 2, 3!

  1. Откройте командную строку / терминал и запустите:

git clone https://github.com/tlh2857/GuardDuty-Global-Notifier.git`

2. Затем перейдите в папку «ресурсы» и отредактируйте файл «variables.js». Замените значение «SNSTopicARN» на ARN темы SNS, которую вы создали и на которую подписаны. Видеть:

3. Если у вас уже включен GuardDuty во всех регионах, продолжайте и удалите эту строку кода в файле event_stack.js в папке lib. :

new guardduty.CfnDetector(this, “GuardDutyDetector”, { enable: true })

Таким образом вы избежите ошибки, которая может остановить развертывание решения, если GuardDuty уже включен в этом регионе.

4. Идеально. Теперь вернитесь в этот терминал и запустите:

npm install

cdk bootstrap

cdk deploy

И если все пойдет хорошо, вы увидите, как решение развернется прямо на ваших глазах! Обратите внимание, что вам нужно будет ввести «y» в консоль, поскольку она будет предлагать вам внести изменения в ресурсы IAM в каждом регионе, в котором вы развертываете решение. К сожалению, один «y» на регион.

Для тестирования возьмите идентификатор детектора GuardDuty любого региона в AWS и запустите:

aws guardduty create-sample-findings --detector-id REGIONAL-DETECTOR-ID --finding-types Backdoor:EC2/DenialOfService.Tcp --region AWS-REGION

Затем дайте ему около 5 минут, и вы должны получить электронное письмо из этой темы в соцсети. Это может быть другой протокол в зависимости от типа вашей подписки.

И вот оно! Единое оповещение о событиях с помощью GuardDuty, CloudWatch Events, Lambda и единой темы SNS. Аккуратный!

А что, если у вас есть GuardDuty, развернутый в некоторых регионах, но не во всех? У меня было ощущение, что вы спросите об этом. И вместо элегантных скриптов, которые проверяют это как условие, вам нужно будет развернуть это решение в двух частях, изменив регионы и конструктор GuardDuty, упомянутый выше на шаге 3.

Перейдите к файлу cwe-gd-cdk.js в папке bin и измените регионы на те, которые вам нужны.

Фактически, вы можете создать две переменные: одну для регионов с уже включенным GuardDuty и одну для регионов, в которых GuardDuty не включен. Затем просто разверните оба решения с опущенным конструктором GuardDuty или без него соответственно.

Вот и все, ребята! Сообщите мне, если у кого-то возникнут трудности с этим, и я постараюсь помочь!

-Терри

P.S. - Вы можете обойти часть уведомлений с помощью сторонних решений, таких как Trend Micro's Cloud One - Conformity. Он сообщит, если какие-либо выводы GuardDuty будут получены по всей вашей учетной записи AWS.