Security- und Compliance-Auditing unter AWS, Teil 1 Einstieg in Cloud Trail und AWS Config

Wer Anwendungen in der Cloud betreibt, darf Compliance, Governance und Change Management nicht außer Acht lassen. Mit AWS Cloud Trail und AWS Config gestaltet sich der Einstieg in Compliance-Prüfung, Sicherheitsanalyse, Fehlerbehebung und Change Management jedoch recht einfach.

AWS CloudTrail (im Folgenden: Cloud Trail) ist ein Dienst zum Überwachen von Governance, Compliance, Betrieb und der Risiken im Kontext eines AWS-Kontos. Der Dienst erfasst dazu sämtliche API-Aufrufe, die von einem Benutzer, einer Rolle oder einem AWS-Service in der AWS Management Console, im AWS Command Line Interface oder über die AWS-SDKs und deren APIs aufgerufen werden.

Gesammelt werden die API-Aufrufe in Form von „Ereignissen“ (Events), der gesamte Ereignisverlauf der letzten 90 Tage wird zur nachgelagerten Analyse aufbewahrt. Anfangs war Cloud Trail nur mit ausgewählten anderen AWS-Services integriert, heute gilt das für jeden neu veröffentlichten Dienst sowie einen großen Anteil von Diensten, die AWS nach Erscheinen von Cloud Trail integriert hat.

Da Cloud Trail sämtliche in einen AWS-Konto ausgeführte Aktionen mitschneidet, erhöht der Dienst die Transparenz hinsichtlich der Benutzeraktivitäten. Zu den von Cloud Trail bei jeder Aktion aufgezeichneten Informationen gehören z. B. der anfordernde Benutzer (in AWS IAM kann ein Benutzer auch ein Service-Prinzipal sein) der oder die verwendeten Dienste, die durchgeführten Aktionen selbst, die dabei verwendeter Parameter und die Antwort des jeweiligen AWS-Service verpackt in JSON.

Zusammen mit dem Dienst AWS Config können Admins mit Hilfe der von Cloud Trail aufgezeichneten Informationen sogar sämtliche „Änderungen“ an AWS-Ressourcen nachverfolgen. Dies ist nicht nur für das Beheben von Betriebsproblemen nützlich, sondern auch für das Security-Auditing und die Einhaltung der Compliance, also interner Richtlinien oder gesetzlicher Vorschriften.

Wie Cloud Trail funktioniert

AWS Cloud Trail ist bei jeder Eröffnung eines neuen AWS-Kontos automatisch aktiviert und verursacht keine Extrakosten, solange man nur den Ereignisverlauf nutzt, der jedes Ereignis bis zu 90 Tage direkt in der Cloud Trail Console anzeigt. Eine grobe Übersicht liefert das vorangestellte Dashboard.

Klickt man auf den Link „View full Event history“, zeigt der Ereignisverlauf alle Events der letzten 90 Tage. Im Menü „Lookup attributes“ lässt sich die Ansicht komfortabel filtern, z. B. Ressource-Type. In der zweiten Spalte steht die Zeit des Events und in der dritten Zeile die IAM-Entität, die das Event ausgelöst hat.

Dann folgen die Event-Ressource selbst, schließlich der Ressource-Typ und der Ressourcen-Name. Die angezeigten Spaltenköpfe und weitere lassen sich durch einen Klick auf das Zahnradsymbol, das weiter zur Einblendung der „Preferences“ führt, nach Belieben arrangieren.

Außerdem kann der Nutzer das Filterfeld rechts neben dem gewählten Lookup-Attribut nutzen, um gezielt nach Events zu fahnden; auch das Zeitintervall lässt sich oben in 1, 3 oder 12-Stunden-Intervallen oder nach Bedarf benutzerdefiniert einstellen. So findet man schnell das gewünschte Ereignis, im Beispiel den manuellen Start einer EC2-Instanz durch einen IAM-User.

Folgt man dem Link zum jeweiligen Event (z. B. StartInstances) zeigt der Abschnitt „Details“ alle Meta-Daten zum jeweiligen Events mit „Event ID“, „Event name“, „Event time“, „User name“, „Source IP adress“ usw. In der Mitte finden sich bei „Ressources referenced“ die mit dem Event in Verbindung stehenden Ressourcen (hier die Instance-ID der betreffenden EC2-Instanz) und unten das eigentliche „Event record“.

Erst ein Klick auf „View event“ präsentiert dem Betrachter das vollständige Ereignis als JSON-File. Hier stehen z. B. die IP-Adresse, von der aus der Call erfolgte, der User Agent, der Quell-Dienst, die Zeit, der API-Call selbst, das Ergebnis des Calls (erfolgreiche wie nicht erfolgreiche Ergebnisse, etwa bei Instrusion Detection), die Parameter des API-Calls usw.

Trails verwenden

Die kontinuierliche Erfassung und Anzeige sämtlicher API-Aufrufe in der Cloud Trail Console ist für jedes AWS-Konto bis zu 90 Tage kostenlos. Die eigentliche Mächtigkeit von Cloud Trail entpuppt sich indes erst mit der Konfiguration so genannter „Trails“ sowie in der Zusammenarbeit mit AWS Config.

Ein so genannter Trail (Pfad) ist eine vom Nutzer erstellte Konfiguration, welche die Art der aufzuzeichnenden Ereignisse sowie deren „Zustellung“ an ein bestimmtes Ziel, wie z. B. per Default einen Amazon-S3-Bucket oder optional an „CloudWatch Logs“ regelt. Admins können so mithilfe eines Trails Cloud-Trail-Ereignisse gezielt filtern, den für die Weiterverarbeitung (Analyse) geeigneten Dienst festlegen oder beispielsweise das Verschlüsseln von Cloud Trail-Ereignisprotokolldateien erzwingen.

Somit bietet erst der Trail die Option, die von Cloud Trail erfassten Daten anschließend komfortabel zu analysieren. Das kann dann wahlweise mit den AWS-eigenen Tools wie z. B. CloudWatch erfolgen, man kann die Cloud Trail-Daten aber auch jederzeit nach Elastic Search laden und z. B. mit Kibana analysieren.

Die Option zur Verschlüsselung ist insbesondere aus Gründen des Datenschutzes wichtig, weil ja jeder Trail Daten zur erfassten Quelle wie IP-Adresse und Benutzername enthält. Viele professionelle AWS-Kunden analysieren daher nur zeitnahe Daten direkt in AWS und, geben langfristigen Daten automatisiert und anonymisiert an einen externen Service weiter.

Beim Anlegen eines Trails verlangt der entsprechende Dialog neben dem Trail-Namen, den Namen eines existierenden oder neu anzulegenden S3-Buckets und den Namen eines neu anzulegenden oder existenten KMS-Keys, sofern die Log-File-SSE-Verschlüsselung zum Einsatz kommen soll. Die Zustellung an CloudWatch Logs ist optional, verlangt aber ggf. nach einer neu anzulegenden oder existenten Protokoll-Gruppe und einer passenden IAM-Rolle.

Der Schritt 2 des Assistenten „Choose log events“ offenbart, dass Cloud Trail zwischen „Managements events“, „Data events“ und „Insights events“ unterscheidet, welche jeweils auf Einfluss auf die Preise haben. Speicher-Preise für Cloud Trail fallen an, sobald ein Cloud Trail eingerichtet ist, nämlich indirekt dadurch, dass ein S3-Bucket als Lieferziel benutzt wird. Hinzu kommen Preise für die Ereignisse an sich, die in einem Trail konfiguriert sind.

Die drei Ereignistypen von AWS Cloud Trail

• Verwaltungsereignisse machen Verwaltungsvorgänge transparent („Steuerungsebene“), welche an Ressourcen im überwachten AWS-Konto durchgeführt werden. Verwaltungsereignisse sind beim Einrichten eines Dienstes per Default aktiviert und zeichnen unterstützte Aktivitäten auf Kontoebene auf. Die erste Kopie der Verwaltungsereignisse in jeder Region wird kostenlos bereitgestellt. Zusätzliche Kopien von Verwaltungsereignissen werden mit 2 US-Dollar pro 100.000 Ereignissen berechnet.

• Datenereignisse machen Ressourcenvorgänge sichtbar („Datenebene“), die „an“ oder „in“ der Ressource selbst durchgeführt wurden. Cloud Trail generiert Datenereignisse für die AWS Lambda-APIs zum Aufrufen von Funktionen und die Amazon S3-APIs auf Objektebene wie Get-, Put-, Delete- und List-Aktionen. Datenereignisse werden nur für die angegebenen Lambda-Funktionen und S3-Buckets aufgezeichnet und mit 0,10 USD pro 100.000 Ereignissen in Rechnung gestellt. Allerdings kommen hier naturgemäß meist deutlich mehr Ereignisse zusammen, als bei Verwaltungsereignissen.

• Der dritte unterstützte Ereignistyp sind Cloud Trail Insights. Insights bietet Einblick in „ungewöhnliche“ betriebliche Aktivitäten im jeweiligen AWS-Konto. Dazu wird das API-Anrufvolumen von write-Verwaltungsereignissen analysiert. Cloud Trail Insights-Ereignisse werden mit {priceOf cloudtrail/cloudtrail Insights Events * 100000} pro 100.000 analysierten Schreibverwaltungsereignissen in Rechnung gestellt. Erkennt Cloud Trail Insights ungewöhnliche Aktivitäten, wird ein Insights-Ereignis generiert. Jeder Trail lässt sich wahlweise für Eine oder für alle Regionen im jeweiligen AWS-Konto einrichten.

Die hier eingefügte Abbildung zeigt ein Beispiel-Event. Das „Event record“ enthält im Abschnitt „userIdentity“ umfangreiche Informationen zum aufrufenden User. In diesem Fall handelt es sich um einen IAM-User mit der User-Identität „tdrilling“ im Account „ 204730830381“, der um 08:58 Uhr am 24.06.2020 von der Source-IP 84.150.181.221 das Event „StartInstances“ ausgelöst hat.

Das Event enthält auch die zugehörige Antwort, sprich Response.

(ID:46672362)