Die übermäßig komplexe Art, wie CloudTrail und CloudWatch Events zusammenarbeiten

Eines der ärgerlichsten Themen auf meinem Weg in die Cloud war das Verständnis dafür, wie CloudTrail und CloudWatch Events zusammenarbeiten. Aus irgendeinem Grund hat es Jahre gedauert (und sehr viele Tests), bis ich verstanden hatte, wie diese Verbindung wirklich funktioniert; und insbesondere, wie sie im Zusammenspiel mit dem Konzept der Multi-Region- und AWS-Organization-Trails funktioniert. Nachdem ich es herausgefunden hatte, nahm ich an, dass es ohnehin alle wüssten, doch jüngste Gespräche haben deutlich gemacht, dass diese Verwirrung recht verbreitet ist. Hier also mein bester Versuch, die Dinge zu vereinfachen.

Zunächst das Problem, das wir lösen wollen: CloudWatch Rules auf Basis von CloudTrail Events erstellen und damit Benachrichtigungen versenden oder Lambda-Funktionen auslösen.

Das war's – ich möchte eine Benachrichtigung für etwas so Einfaches wie den API-Aufruf zum Öffnen einer neuen Security-Group-Regel versenden (AuthorizeSecurityGroupIngress, falls Sie sich das gefragt haben).

Damit das funktioniert, benötigen Sie Folgendes:

• CloudTrail aktiviert in der Region, in der der API-Aufruf erfolgt.
• CloudTrail-Streaming an CloudWatch.
• Eine CloudWatch Rule in der Region des API-Aufrufs, die nach diesem bestimmten API-Aufruf oder nach allen CloudTrail-API-Aufrufen sucht.

Nun zur Verwirrung:

• Wenn Sie einen Multi-Region-CloudTrail oder einen Organization-Trail erstellen, richtet AWS im Hintergrund tatsächlich Trails in jeder einzelnen Region ein (und in jedem Konto, im Fall eines Org-Trails). Es handelt sich dabei um lauter separate Trails, von denen jeder jedoch so konfiguriert ist, dass er seine Ergebnisse an einen gemeinsamen S3-Bucket sendet, und Sie können jeden einzelnen nur in seinem Heimatkonto und seiner Heimatregion verwalten.
• CloudWatch Events für API-Aufrufe werden jedoch nur in der Region des API-Aufrufs erzeugt.
• Wenn Sie also einen Multi-Region-Trail erstellen, werden die Daten zwar zentral gesammelt, die Events erscheinen aber nur lokal. Eine CloudWatch Rule in der Region des Heimat-Trails wird nur bei API-Aufrufen ausgelöst, die in dieser (Heimat-)Region erfolgen. Wenn Sie also einen Alarm für Änderungen an Security Groups einrichten, funktioniert dieser nur in der Heimatregion – nicht in den anderen Regionen –, selbst wenn CloudTrail dort aktiviert ist.
• Die CloudWatch Log Group bzw. der Stream erscheint in der primären Region, nicht in den anderen Regionen, doch jedes Event wird in der Region erzeugt, die das Event ausgelöst hat.
• Wenn Sie alle Events für API-Aufrufe erfassen möchten, müssen Sie eine undokumentierte Event-Definition verwenden (die ich unten eingefügt habe).
• Wenn Sie die Dokumentation von Amazon lesen … nichts davon wird dort klar benannt. Zumindest habe ich es nicht finden können. Tatsächlich war ich einmal in einem Support-Gespräch, in dem ich es herausfand, und der AWS-Mitarbeiter murmelte immer wieder: „Ich glaube nicht, dass es so funktioniert“, während meine Events hereinströmten. Er hatte eine harte Nacht.

Das war für mich aus irgendeinem Grund wirklich wenig intuitiv. Ich war davon ausgegangen, dass man bei einem zentralisierten Trail auch die CloudWatch Rule zentralisieren kann, um sie durch API-Aufruf-Events auszulösen. Leider war das völlig falsch: Selbst wenn Sie den Trail zentralisieren, müssen Sie die Rule weiterhin in jeder Region anlegen, die für Sie relevant ist. Auch wenn Sie einen Event Bus nutzen, um Events aus mehreren Konten zu sammeln, müssen Sie dennoch in jeder Region jedes Kontos eine CloudWatch Rule erstellen, um das Event an den Bus zu senden, und anschließend in jeder Region des Event Bus Rules aufbauen, die die gewünschte Benachrichtigung bzw. Aktion auslösen.

So gehen Sie meiner Empfehlung nach vor, wenn Sie die Near-Real-Time-Alarmierung oder die von CloudWatch Rules unterstützten automatischen Gegenmaßnahmen und Aktionen nutzen möchten:

• Aktivieren Sie einen Multi-Region-Trail. Das ist nur einmal erforderlich, und ein Organization-Trail genügt.
• Dadurch werden alle regionalen Trails erstellt, die Sie benötigen. Es sieht aus wie ein zentraler Trail, ist in Wirklichkeit aber eine Sammlung regionaler Trails, die ihre Daten an einen zentralen Empfänger senden.
• Option 1: Erstellen Sie in jeder Region, für die Sie eine Near-Real-Time-Alarmierung wünschen, eine CloudWatch Rule. CloudFormation und Terraform sind hier Ihre Freunde.
• Option 2: Zentralisieren Sie alle Ihre Events. Erstellen Sie in jeder Region eine Rule, die alle CloudTrail-Events an eine Lambda-Funktion oder ein SNS-Topic sendet, das sie dann an Ihr Ziel weiterleitet. Wir setzen diese Technik selbst ein; wir versenden über einen eigenen API-Endpunkt, Sie können aber auch an Kinesis oder nahezu alles andere streamen.

Zum Einstieg hier zwei Codebeispiele.

Das geheime Filtermuster für Ihre CloudWatch Rule, um alle Events aus CloudTrail zu erfassen:

{

"detail-type": [

"AWS API Call via CloudTrail"

] }

Und hier ein Beispiel für Lambda-Code, der Events weiterleitet, in diesem Fall an Kinesis:

import json

import boto3

def lambda_handler(event, context):

kinesis = boto3.client('kinesis', region_name='us-west-2')

data = json.dumps(event)

print(data)

response = kinesis.put_record(

StreamName='cloudsec_prod_stream_alert_kinesis',

Data=data,

PartitionKey='test-client-id'

)

print(response)

return {

'statusCode': 200,

'body': json.dumps('Record added')

}