И почему вы тоже должны!
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), спросите вы?
Короче говоря, если вы любите кодировать, вам понравится CDK. Вот схема инфраструктуры, которую мы предоставим с помощью этого решения:
Что касается инфраструктуры AWS, это центральная тема социальной сети, которую вы создаете и на которую подписываетесь. Затем с помощью CDK вы включите события GuardDuty для отправки сообщения об этой центральной теме SNS через функцию Lambda в каждом регионе AWS. Довольно аккуратно, да?
Развертывание решения
Хорошо, вот что вам понадобится, чтобы начать работу.
- AWS CLI установлен и настроен
- AWS CDK установлен
- Тема в соцсети создана
- Git установлен (вы также можете загрузить код с GitHub, разархивировать его и перейти к шагу 2.)
После того, как вы настроили вышеуказанные элементы, решение будет таким же простым, как 1, 2, 3!
- Откройте командную строку / терминал и запустите:
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.