Diese Seite wurde von der Cloud Translation API übersetzt.

AWS CloudTrail-Logs erfassen

Unterstützt in:

Google SecOps SIEM

In diesem Dokument wird beschrieben, wie Sie AWS CloudTrail-Logs erfassen, indem Sie einen Google Security Operations-Feed einrichten, und wie Logfelder UDM-Feldern (Unified Data Model) von Google SecOps zugeordnet werden.

Weitere Informationen finden Sie unter [Datenerfassung in Google SecOps][1].

Eine typische Bereitstellung besteht aus AWS CloudTrail und dem Google SecOps-Feed, der so konfiguriert ist, dass Logs an Google SecOps gesendet werden. Ihre Bereitstellung kann von der in diesem Dokument beschriebenen typischen Bereitstellung abweichen. Die Bereitstellung enthält die folgenden Komponenten:

AWS CloudTrail: Die Plattform, auf der Logs erfasst werden.
AWS S3: Die Plattform, auf der Logs gespeichert werden.
Google SecOps-Feed: Der Google SecOps-Feed, mit dem Logs aus AWS S3 abgerufen und in Google SecOps geschrieben werden.
Google SecOps: Die Plattform, auf der die Logs aus AWS CloudTrail aufbewahrt und analysiert werden.

Ein Erfassungslabel identifiziert den Parser, der Rohdaten in das strukturierte UDM-Format normalisiert. Die Informationen in diesem Dokument gelten für den Parser mit dem Aufnahme-Label AWS_CLOUDTRAIL.

Hinweise

Prüfen Sie, ob folgende Voraussetzungen erfüllt sind:

AWS-Konto
die Voraussetzungen für die Verwendung von AWS CloudTrail erfüllt sind. Weitere Informationen finden Sie unter AWS CloudTrail einrichten.
Alle Systeme in der Bereitstellungsarchitektur verwenden die UTC-Zeitzone.

Grundlegende Schritte zum Erfassen von Logs aus S3 mit SQS

In diesem Abschnitt werden die grundlegenden Schritte zum Erfassen von AWS CloudTrail-Logs in Ihrer Google SecOps-Instanz beschrieben. In den Schritten wird beschrieben, wie Sie dies mit Amazon S3 und Amazon SQS als Feedquelltyp tun.

AWS CloudTrail und S3 konfigurieren

In diesem Verfahren konfigurieren Sie, dass AWS CloudTrail-Logs in einen S3-Bucket geschrieben werden.

Suchen Sie in der AWS-Konsole nach CloudTrail.
Klicken Sie auf Trail erstellen.
Geben Sie einen Namen für den Trail an.
Wählen Sie Neuen S3-Bucket erstellen aus. Sie können auch einen vorhandenen S3-Bucket verwenden.
Geben Sie einen Namen für den AWS KMS-Alias ein oder wählen Sie einen vorhandenen AWS KMS-Schlüssel aus.
Sie können die anderen Einstellungen auf den Standardwerten belassen und auf Weiter klicken.
Wählen Sie Ereignistyp aus, fügen Sie nach Bedarf Datenereignisse hinzu und klicken Sie auf Weiter.
Prüfen Sie die Einstellungen unter Überprüfen und erstellen und klicken Sie auf Testlauf erstellen.
Suchen Sie in der AWS-Konsole nach Amazon S3-Buckets.
Klicken Sie auf den neu erstellten Log-Bucket und wählen Sie den Ordner AWSLogs aus. Klicken Sie dann auf S3-URI kopieren und speichern Sie ihn für die folgenden Schritte.

Standard-SQS-Warteschlange und SNS einrichten

Wenn Sie eine SQS-Warteschlange verwenden, muss es sich um eine Standardwarteschlange und nicht um eine FIFO-Warteschlange handeln.

Aktivieren Sie AWS CloudTrail und konfigurieren Sie es so, dass Logs über einen neuen oder vorhandenen Trail an einen S3-Bucket gesendet werden.
Öffnen Sie die AWS SNS-Konsole und erstellen Sie ein neues Standard-Thema. Geben Sie ihm einen Namen, z.B. CloudTrail-Notification-Topic.

Erstellen Sie eine SQS-Warteschlange mit der AWS SQS-Konsole, z.B. CloudTrail-Notification-Queue und aktualisieren Sie die Zugriffsrichtlinie, damit der SNS-Themen-ARN Nachrichten senden kann. Weitere Informationen zum Erstellen von SQS-Warteschlangen finden Sie unter Erste Schritte mit Amazon SQS.

Beispiel für ein SQS-Richtlinien-Snippet:

{
   "Version": "2012-10-17",
   "Id": `PolicyForSNS`,
   "Statement": [
      {
         "Sid": "AllowSNS",
         "Effect": "Allow",
         "Principal": { "Service": "sns.amazonaws.com" },
         "Action": "SQS:SendMessage",
         "Resource": "arn:aws:sqs:REGION:ACCOUNT_ID:CloudTrail-Notification-Queue",
         "Condition": {
         "ArnEquals": { "aws:SourceArn": "arn:aws:sns:REGION:ACCOUNT_ID:CloudTrail-Notification-Topic"}
         }
      }
   ]
}

Gehen Sie zu SNS-Thema → Abos → Abo erstellen, legen Sie das Protokoll auf SQS und den Endpunkt auf den ARN der SQS-Warteschlange fest.
CloudTrail überträgt neue Logs nicht nativ an SNS. Um Benachrichtigungen zu aktivieren, können Sie einen CloudTrail-Ereignisauswahl für Verwaltungsereignisse verwenden oder CloudTrail in CloudWatch Logs einbinden und dann eine CloudWatch-Ereignisregel erstellen, die Benachrichtigungen auslöst, indem Sie ein SNS-Thema als Ziel festlegen. Weitere Informationen finden Sie unter Benachrichtigungen für Ihren S3-Bucket einrichten.

Beispiel für ein Ereignismuster:
```
{
   "source": ["aws.s3"],
   "detail-type": ["AWS API Call via CloudTrail"],
   "detail": {
      "eventName": ["PutObject"],
      "requestParameters": {
         "bucketName": [`CloudTrail-Notification-Topic`]
      }
   }
}
```
Achten Sie darauf, dass IAM-Rollen oder -Richtlinien CloudWatch Events das Veröffentlichen in SNS erlauben und dass SNS Nachrichten an SQS senden darf.

AWS IAM-Nutzer konfigurieren

Konfigurieren Sie einen AWS-IAM-Nutzer, mit dem Google SecOps sowohl auf die SQS-Warteschlange (falls verwendet) als auch auf den S3-Bucket zugreifen kann.

Suchen Sie in der AWS-Konsole nach IAM.
Klicken Sie auf Nutzer und dann auf dem folgenden Bildschirm auf Nutzer erstellen.
Geben Sie einen Namen für den Nutzer an, z. B. chronicle-feed-user, und wählen Sie Provide user access to the AWS Management Console (Nutzerzugriff auf die AWS Management Console gewähren) aus.
Wählen Sie Attach existing policies directly aus und wählen Sie nach Bedarf AmazonS3ReadOnlyAccess oder AmazonS3FullAccess aus. AmazonS3FullAccess wird verwendet, wenn Google SecOps die S3-Buckets nach dem Lesen von Logs leeren soll, um die AWS S3-Speicherkosten zu optimieren.
Als empfohlene Alternative zum vorherigen Schritt können Sie den Zugriff weiter auf den angegebenen S3-Bucket beschränken, indem Sie eine benutzerdefinierte Richtlinie erstellen. Klicken Sie auf Richtlinie erstellen und folgen Sie der AWS-Dokumentation, um eine benutzerdefinierte Richtlinie zu erstellen.
Achten Sie beim Anwenden einer Richtlinie darauf, dass Sie sqs:DeleteMessage angegeben haben. Google SecOps kann Nachrichten nicht löschen, wenn die Berechtigung sqs:DeleteMessage nicht an die SQS-Warteschlange angehängt ist. Alle Nachrichten werden auf der AWS-Seite gesammelt, was zu einer Verzögerung führt, da Google SecOps wiederholt versucht, dieselben Dateien zu übertragen.
Klicken Sie auf Weiter:Tags.
Fügen Sie bei Bedarf Tags hinzu und klicken Sie auf Weiter:Überprüfen.
Überprüfen Sie die Konfiguration und klicken Sie auf Nutzer erstellen.
Nachdem der Nutzer erstellt wurde, rufen Sie den Tab Security Credentials (Sicherheitsanmeldedaten) auf und klicken Sie auf Create Access Key (Zugriffsschlüssel erstellen).
Wählen Sie CLI aus und klicken Sie auf Weiter:Tags.
Fügen Sie bei Bedarf Tags hinzu und klicken Sie dann auf Zugriffsschlüssel erstellen: Überprüfen.
Kopieren Sie die Zugriffsschlüssel-ID und den geheimen Zugriffsschlüssel des erstellten Nutzers für den nächsten Schritt.

KMS-Schlüsselberechtigungen konfigurieren

Zum Entschlüsseln von CloudTrail-Logs, die serverseitig verschlüsselt sind, ist ein KMS-Schlüssel erforderlich. AWS KMS bietet eine verbesserte Verschlüsselung und Sicherheit für sensible Daten, die in Amazon S3 gespeichert sind.

Suchen Sie in der AWS Console nach Key Management Service (KMS).
Klicken Sie auf Schlüssel erstellen:Weiter.
Fügen Sie einen Alias für den Schlüssel hinzu. Fügen Sie bei Bedarf optional eine Beschreibung und Tags hinzu. Klicken Sie auf Weiter: Überprüfen.
Klicken Sie nach der Überprüfung der Konfiguration auf Weiter.
Wählen Sie die Schlüsselnutzer aus, die Zugriff auf diesen Schlüssel haben sollen, und klicken Sie dann auf Fertigstellen.

Feeds einrichten

Es gibt zwei verschiedene Einstiegspunkte zum Einrichten von Feeds in der Google SecOps-Plattform:

SIEM-Einstellungen > Feeds > Neu hinzufügen
Content Hub > Content-Pakete > Erste Schritte

AWS CloudTrail-Feed einrichten

Klicken Sie auf das Paket Amazon Cloud Platform.
Geben Sie für den Logtyp AWS CloudTrail die folgenden Werte an:
Geben Sie Werte für die folgenden Felder an:
- Quelltyp: Amazon SQS V2
- Warteschlangenname: Der Name der SQS-Warteschlange, aus der gelesen werden soll.
- S3-URI: Der Bucket-URI.
  - s3://your-log-bucket-name/
    - Ersetzen Sie your-log-bucket-name durch den tatsächlichen Namen Ihres S3-Buckets.
- Optionen zum Löschen der Quelle: Wählen Sie die Löschoption entsprechend Ihren Aufnahmeeinstellungen aus.
  
  Hinweis: Wenn Sie die Option Delete transferred files oder Delete transferred files and empty directories auswählen, müssen Sie dem Dienstkonto die entsprechenden Berechtigungen erteilen.
- Maximales Dateialter: Dateien einschließen, die in den letzten Tagen geändert wurden. Der Standardwert ist 180 Tage.
- SQS Queue Access Key ID (SQS-Warteschlange-Zugriffsschlüssel-ID): Ein Konto-Zugriffsschlüssel, der ein 20-stelliger alphanumerischer String ist.
- SQS Queue Secret Access Key (geheimer Zugriffsschlüssel für SQS-Warteschlange): Ein Konto-Zugriffsschlüssel, der ein 40-stelliger alphanumerischer String ist.
Erweiterte Optionen
- Feedname: Ein vorausgefüllter Wert, der den Feed identifiziert.
- Asset-Namespace: Der Namespace, der dem Feed zugeordnet ist.
- Aufnahmelabels: Labels, die auf alle Ereignisse aus diesem Feed angewendet werden.
Klicken Sie auf Feed erstellen.

Weitere Informationen zum Konfigurieren mehrerer Feeds für verschiedene Logtypen in dieser Produktfamilie finden Sie unter Feeds nach Produkt konfigurieren.

Unterstützte AWS CloudTrail-Logtypen

Der AWS CloudTrail-Parser unterstützt die folgenden Dienste:

apigateway.amazonaws.com
appconfig.amazonaws.com
autoscaling.amazonaws.com
cloud9.amazonaws.com
cloudsearch.amazonaws.com
cloudshell.amazonaws.com
cloudtrail.amazonaws.com
config.amazonaws.com
devicefarm.amazonaws.com
ds.amazonaws.com
dynamodb.amazonaws.com
ec2-instance-connect.amazonaws.com
ec2.amazonaws.com
ecr-public.amazonaws.com
ecr.amazonaws.com
ecs.amazonaws.com
eks.amazonaws.com
elasticache.amazonaws.com
elasticloadbalancing.amazonaws.com
firehose.amazonaws.com
guardduty.amazonaws.com
health.amazonaws.com
iam.amazonaws.com
imagebuilder.amazonaws.com
kinesis.amazonaws.com
kinesisanalytics.amazonaws.com
kinesisvideo.amazonaws.com
kms.amazonaws.com
lambda.amazonaws.com
logs.amazonaws.com
macie2.amazonaws.com
monitoring.amazonaws.com
network-firewall.amazonaws.com
organizations.amazonaws.com
quicksight.amazonaws.com
ram.amazonaws.com
rds.amazonaws.com
resource-explorer-2.amazonaws.com
resource-groups.amazonaws.com
route53-recovery-readiness.amazonaws.com
route53.amazonaws.com
route53domains.amazonaws.com
route53resolver.amazonaws.com
s3-outposts.amazonaws.com
s3.amazonaws.com
s3express.amazonaws.com
secretsmanager.amazonaws.com
securityhub.amazonaws.com
ses.amazonaws.com
signin.amazonaws.com
ssm.amazonaws.com
sts.amazonaws.com
waf-regional.amazonaws.com
waf.amazonaws.com
wafv2.amazonaws.com

Weitere Informationen zur Feldzuordnung und UDM-Zuordnung finden Sie unter AWS CloudTrail-Feldzuordnung.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten