Skip to content
malak.cloud
  • Contact
  • Przemek Malak
  • Search Icon

malak.cloud

Cloud-native in everyday life

Łączymy Amazon GuardDuty z MS Teams i Slackiem

Łączymy Amazon GuardDuty z MS Teams i Slackiem

1 maja 2021

Nie będę się rozpisywał o usłudze GuardDuty. W dużym skrócie, na podstawie różnych danych potrafi wykryć na naszych kontach rzeczy, które nie powinny mieć miejsca. Ktoś na przykład zacznie kopać bitcoiny, to usługa powinna to wykryć i nas o tym powiadomić. No właśnie, powiadomić. Domyślnie dostajemy w konsoli tak zwane znaleziska

 

Tylko trzeba tam zaglądać. A to nie zawsze będzie miało miejsce. Jest tyle rzeczy, które mogą nam w tym przeszkodzić.

Sporo z nas używa dziś MS Teams. Pokażę więc jak przekazać problemy znalezione przez GuardDuty do Teamsów. Na koniec zrobimy małą zmianę i połączymy się ze Slackiem.

MS Teams

Aby móc przesyłać wiadomości do MS Teams trzeba utworzyć w nich tak zwany łącznik (connector).

Nie będę pokazywał na to zrobić. Łatwo znaleźć instrukcje. Będziemy po prostu potrzebowali unikalnego adresu URL, na który można wysyłać wiadomości na kanał w MS Teams.

Zakładam, że to mamy.

I po stronie AWS

Temat wydaje się dość skomplikowany. Pewnie będzie potrzebne jakieś programowanie. Otóż nie. Nie napiszemy ani jednej linijki kodu. Wszystko co będzie potrzebne zapewni nam AWS. Skorzystamy z dostępnych serwisów, które tylko odpowiednio skonfigurujemy.

Skorzystamy z usługi EventBridge, która z jednej strony pozwoli nam podpiąć się pod zdarzenia z GuardDuty, a ponad to umożliwi nam wyłuskanie danych ze zdarzenia i wysłanie ich w odpowiednim formacie do MS Teams.

Pierwsze co powinniśmy utworzyć to tak zwana EventRule, czyli subskrypcja do określonych zdarzeń w środowisku AWS. Nas będą interesowały zdarzenia przesyłane przez GuardDuty. Będziemy więc szukali takich eventów.

EventPattern: {"source": ["aws.guardduty"],"detail-type": ["GuardDuty Finding"]}

EventBridge pozwala rozsyłać wiadomości do wielu różnych usług. Aby wysłać wiadomość na adres connectora MS Teams użyjemy API Destinations, które pojawiły się niedawno. Pisałem już o tym, zachęcam do lektury.

Aby utworzyć API Destination potrzebujemy zdefiniować tak zwane Connection:

EventRuleConnection:
  Type: AWS::Events::Connection
  Properties: 
    AuthorizationType: BASIC 
    AuthParameters: 
      BasicAuthParameters:

które wykorzystamy w samym API Destination:

EventRuleApiDestination:
  Type: AWS::Events::ApiDestination
  Properties: 
    ConnectionArn: !GetAtt EventRuleConnection.Arn
    HttpMethod: POST
    InvocationRateLimitPerSecond: 10
    InvocationEndpoint: !Ref TeamsWebHook

Jako adres url naszego webhooka Teams wykorzystamy parametr i jego wartość ustalimy przy tworzeniu stacka.

Błędy, błędy, błędy

Teoretycznie w tym momencie wiadomości z GuardDuty zostaną przesłane do naszych MS Teams. Jednak niestety nie zostaną one wyświetlone. MS Teams, jak można się tego spodziewać, wymaga odpowiednich danych.  Zanim przejdziemy do formatowania danych, dodajmy do naszego stacka kolejkę na błędy (Dead Letter Queue)

DeadLetterQueue:
    Type: AWS::SQS::Queue

oraz przypiszmy ją do naszego targetu w Event Rule

GuardDutyEventRule:
  Type: AWS::Events::Rule
  Properties: 
    Targets:
      - Arn: !GetAtt EventRuleApiDestination.Arn
        ...
        DeadLetterConfig:
            Arn: !GetAtt DeadLetterQueue.Arn

Pozwoli nam to, w przypadku wystąpienia błędu na podejrzenie wiadomości wysyłanej przez API Destination

i sprawdzenie błędu, który spowodował problem.

Formatujemy wiadomości

Event Grid ma między innymi możliwość utworzenia wiadomości na podstawie danych, które zostały do niego przekazane. Służy do tego tak zwany InputTransformer. Więcej o tym możecie poczytać tutaj. To co my zrobimy, to wyłuskamy z wiadomości przesłanej z GuardDuty tytuł, id konta AWS oraz opis

InputPathsMap:
 title: $.detail.title
 account: $.detail.accountId
 description: $.detail.description

i użyjemy tych danych podczas tworzenia paylodu wysyłanego do MS Teams.

InputTransformer:
 InputTemplate: >
 {
  "themeColor": "FFA500",
  "title": <title>,
  "text": "Account: <account> Finding <description>"
 }

Dodatkowo, ustawimy kolor na pomarańczowy.

Testujemy

Aby wygenerować przykładowe zdarzenia (findings) w GardDuty w zakładce Settings klikamy w Generate sample findings

i po chwili powinno się pojawić kilkanaście testowych naruszeń

a po następnych kilku chwilach (pamiętajcie, jedna chwila to trzy momenty ;-), to nie nastąpi natychmiast) powinniście dostać powiadomienia w Teamsach.

Jeżeli coś pójdzie nie tak, sprawdźcie w pierwszej kolejności kolejkę DLQ.

A co ze Slackiem?

Nie ma oczywiście problemu, aby zamiast MS Teams użyć Slacka. Musimy podać oczywiście jako parametr przy tworzeniu stacka url go webhooka slackowego i zmienić format przesyłanych danych

InputTemplate: >
{
   "text": "Account: <account> Finding title <title> and description <description>"
}

To tyle.

Podsumowanie

Chmura publiczna pozwala na zautomatyzowanie prawie wszystkiego. Bardzo ważne jest to w przypadku bezpieczeństwa. Wyobraźcie sobie, ze macie kilkadziesiąt lub więcej kont AWS i próbujecie to ogarnąć ręcznie. Będzie to praktycznie niemożliwe.

Automatyczne reagowanie na zdarzenia i zagrożenia jest czymś o czym, myślę, powinniśmy pomyśleć i wdrożyć na naszych kontach.

Oczywiście Amazon EventBridge możemy wykorzystać na wiele innych sposobów, tu pokazałem jeden z nich. I to nie najważniejszy.

Przykładowy tempate dostępny jest na moim GitHub-ie.

 


AWS, CloudNative, Security
AWS, CloudNative, Security

Post navigation

PREVIOUS
AWS News – kwiecień 2021
NEXT
AWS News – maj 2021
Comments are closed.
Hi. My name is Przemek Malak. Thanks for visiting. I hope you found what I write about interesting.
If you'd like to chat with me, the easiest way is through LinkedIn.

Losowe wpisy

  • EventBridge i API Destinations

    14 marca 2021
  • Step Functions i obsługa błędów

    22 października 2022
  • Jak za pomocą funkcji Lambda włączyć i wyłączyć serwer EC2 w AWS

    25 października 2017
  • Jak przesłać plik do S3 za pomocą API Gateway

    16 listopada 2022
  • Jak skasować pliki w S3 przy usuwaniu stacka Cloudformation

    18 stycznia 2022
  • Apps
  • AWS
  • CloudNative
  • Cookbook
  • Data
  • DEV
  • EN
  • GCP
  • IoT
  • Istio
  • k8s
  • Security
  • Social
  • GitHub
  • LinkedIn
© 2025   All Rights Reserved.
Ta strona korzysta z ciasteczek aby świadczyć usługi na najwyższym poziomie. Dalsze korzystanie ze strony oznacza, że zgadzasz się na ich użycie.Zgoda