Erfassung von Daten von AWS -Services - Amazon Security Lake

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Erfassung von Daten von AWS -Services

Amazon Security Lake kann Protokolle und Ereignisse von den folgenden nativ AWS -Services unterstützten Geräten sammeln:

  • AWS CloudTrail Verwaltung und Datenereignisse (S3, Lambda)

  • Auditprotokolle für Amazon Elastic Kubernetes Service (Amazon EKS)

  • Amazon-Route-53-Resolver-Abfrageprotokolle

  • AWS Security Hub Ergebnisse

  • Amazon Virtual Private Cloud (Amazon VPC)-Datendurchflussprotokolle

  • AWS WAF v2-Protokolle

Security Lake wandelt diese Daten automatisch in das Apache Offenes Cybersecurity Schema Framework (OCSF) Parquet-Format um.

Tipp

Um einen oder mehrere der oben genannten Dienste als Protokollquelle in Security Lake hinzuzufügen, müssen Sie die Protokollierung für diese Dienste nicht separat konfigurieren, mit Ausnahme von CloudTrail Verwaltungsereignissen. Wenn Sie die Protokollierung in diesen Diensten konfiguriert haben, müssen Sie Ihre Protokollierungskonfiguration nicht ändern, um sie als Protokollquellen in Security Lake hinzuzufügen. Security Lake ruft Daten über einen unabhängigen und duplizierten Ereignisstrom direkt von diesen Diensten ab.

Voraussetzung: Überprüfen Sie die Berechtigungen

Um eine AWS -Service als Quelle in Security Lake hinzuzufügen, benötigen Sie die erforderlichen Berechtigungen. Stellen Sie sicher, dass die AWS Identity and Access Management (IAM-) Richtlinie, die der Rolle zugeordnet ist, die Sie zum Hinzufügen einer Quelle verwenden, berechtigt ist, die folgenden Aktionen auszuführen:

  • glue:CreateDatabase

  • glue:CreateTable

  • glue:GetDatabase

  • glue:GetTable

  • glue:UpdateTable

  • iam:CreateServiceLinkedRole

  • s3:GetObject

  • s3:PutObject

Es wird empfohlen, dass die Rolle die folgenden Bedingungen und den folgenden Ressourcenbereich für die s3:PutObject Berechtigungen S3:getObject und erfüllt.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AllowUpdatingSecurityLakeS3Buckets", "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject" ], "Resource": "arn:aws:s3:::aws-security-data-lake*", "Condition": { "StringEquals": { "aws:ResourceAccount": "${aws:PrincipalAccount}" } } } ] }

Diese Aktionen ermöglichen es Ihnen, Protokolle und Ereignisse aus dem AN zu sammeln AWS -Service und sie an die richtige AWS Glue Datenbank und Tabelle zu senden.

Wenn Sie einen AWS KMS Schlüssel für die serverseitige Verschlüsselung Ihres Data Lakes verwenden, benötigen Sie auch eine Genehmigung dafürkms:DescribeKey.

CloudTrail Ereignisprotokolle

AWS CloudTrail bietet Ihnen einen Verlauf der AWS API-Aufrufe für Ihr Konto, einschließlich API-Aufrufe, die mithilfe der AWS SDKs AWS Management Console, der Befehlszeilentools und bestimmter AWS Dienste getätigt wurden. CloudTrail ermöglicht es Ihnen auch, zu ermitteln, welche Benutzer und Konten AWS APIs für unterstützte Dienste aufgerufen haben CloudTrail, von welcher Quell-IP-Adresse aus die Aufrufe getätigt wurden und wann die Aufrufe erfolgten. Weitere Informationen finden Sie im AWS CloudTrail -Benutzerhandbuch.

Security Lake kann Protokolle im Zusammenhang mit CloudTrail Verwaltungsereignissen und CloudTrail Datenereignissen für S3 und Lambda sammeln. CloudTrail Verwaltungsereignisse, S3-Datenereignisse und Lambda-Datenereignisse sind drei separate Quellen in Security Lake. Aus diesem Grund haben sie unterschiedliche Werte, sourceNamewenn Sie einen dieser Werte als aufgenommene Protokollquelle hinzufügen. Verwaltungsereignisse, auch bekannt als Ereignisse auf Kontrollebene, geben Aufschluss über Verwaltungsvorgänge, die mit Ressourcen in Ihrem AWS-Konto System ausgeführt werden. CloudTrail Datenereignisse, auch bekannt als Operationen auf Datenebene, zeigen die Ressourcenoperationen, die auf oder innerhalb von Ressourcen in Ihrem System ausgeführt wurden AWS-Konto. Bei diesen Vorgängen handelt es sich häufig um umfangreiche Aktivitäten.

Um CloudTrail Verwaltungsereignisse in Security Lake zu sammeln, benötigen Sie mindestens einen CloudTrail regionsübergreifenden Organisationspfad, der CloudTrail Verwaltungsereignisse mit Lese- und Schreibzugriff sammelt. Die Protokollierung muss für den Trail aktiviert sein. Wenn Sie die Protokollierung in den anderen Diensten konfiguriert haben, müssen Sie Ihre Protokollierungskonfiguration nicht ändern, um sie als Protokollquellen in Security Lake hinzuzufügen. Security Lake ruft Daten über einen unabhängigen und duplizierten Ereignisstrom direkt von diesen Diensten ab.

Ein Trail mit mehreren Regionen liefert Protokolldateien aus mehreren Regionen an einen einzigen Amazon Simple Storage Service (Amazon S3) -Bucket für einen einzigen AWS-Konto. Wenn Sie bereits einen Trail mit mehreren Regionen haben, der über die CloudTrail Konsole oder verwaltet wird AWS Control Tower, sind keine weiteren Maßnahmen erforderlich.

Wenn Sie CloudTrail Ereignisse als Quelle hinzufügen, beginnt Security Lake sofort mit der Erfassung Ihrer CloudTrail Ereignisprotokolle. Es verarbeitet CloudTrail Verwaltungs- und Datenereignisse direkt aus CloudTrail einem unabhängigen und duplizierten Ereignisstrom.

Security Lake verwaltet Ihre CloudTrail Ereignisse nicht und hat auch keine Auswirkungen auf Ihre bestehenden CloudTrail Konfigurationen. Um den Zugriff und die Aufbewahrung Ihrer CloudTrail Ereignisse direkt zu verwalten, müssen Sie die CloudTrail Servicekonsole oder API verwenden. Weitere Informationen finden Sie im AWS CloudTrail Benutzerhandbuch unter Ereignisse mit CloudTrail Ereignisverlauf anzeigen.

Die folgende Liste enthält GitHub Repository-Links zur Mapping-Referenz, in der beschrieben wird, wie Security Lake CloudTrail Ereignisse auf OCSF normalisiert.

GitHub OCSF-Repository für Ereignisse CloudTrail

Amazon EKS-Auditprotokolle

Wenn Sie Amazon EKS Audit Logs als Quelle hinzufügen, beginnt Security Lake mit der Erfassung detaillierter Informationen über die Aktivitäten, die auf den Kubernetes-Ressourcen ausgeführt werden, die in Ihren Elastic Kubernetes Service (EKS) -Clustern ausgeführt werden. EKS-Auditprotokolle helfen Ihnen dabei, potenziell verdächtige Aktivitäten in Ihren EKS-Clustern innerhalb des Amazon Elastic Kubernetes Service zu erkennen.

Security Lake verarbeitet EKS-Audit-Log-Ereignisse direkt aus der Protokollierungsfunktion der Amazon EKS-Kontrollebene über einen unabhängigen und duplizierten Stream von Audit-Protokollen. Dieser Prozess ist so konzipiert, dass keine zusätzliche Einrichtung erforderlich ist und sich auch nicht auf bestehende Protokollierungskonfigurationen der Amazon EKS-Steuerungsebene auswirkt, die Sie möglicherweise haben. Weitere Informationen finden Sie unter Protokollierung der Amazon EKS-Kontrollebene im Amazon EKS-Benutzerhandbuch.

Amazon EKS-Auditprotokolle werden nur in OCSF v1.1.0 unterstützt. Informationen darüber, wie Security Lake EKS Audit Logs-Ereignisse auf OCSF normalisiert, finden Sie in der Zuordnungsreferenz im GitHub OCSF-Repository für Amazon EKS Audit Logs-Ereignisse (v1.1.0).

Route-53-Resolver-Abfrageprotokolle

Route 53-Resolver-Abfrageprotokolle verfolgen DNS-Abfragen, die von Ressourcen in Ihrer Amazon Virtual Private Cloud (Amazon VPC) gestellt wurden. Auf diese Weise können Sie besser verstehen, wie Ihre Anwendungen funktionieren, und Sicherheitsbedrohungen erkennen.

Wenn Sie Route 53-Resolver-Abfrageprotokolle als Quelle in Security Lake hinzufügen, beginnt Security Lake sofort, Ihre Resolver-Abfrageprotokolle direkt von Route 53 über einen unabhängigen und duplizierten Ereignisstrom zu sammeln.

Security Lake verwaltet Ihre Route 53-Protokolle nicht und hat auch keinen Einfluss auf Ihre bestehenden Resolver-Abfrageprotokollierungskonfigurationen. Um Resolver-Abfrageprotokolle zu verwalten, müssen Sie die Route 53-Servicekonsole verwenden. Weitere Informationen finden Sie unter Managing Resolver Query Logging Configurations im Amazon Route 53 Developer Guide.

Die folgende Liste enthält GitHub Repository-Links zur Mapping-Referenz, in der beschrieben wird, wie Security Lake Route 53-Protokolle auf OCSF normalisiert.

GitHub OCSF-Repository für Route 53-Protokolle

Ergebnisse von Security Hub

Die Ergebnisse von Security Hub helfen Ihnen dabei, Ihre Sicherheitslage zu verstehen, AWS und ermöglichen es Ihnen, Ihre Umgebung anhand von Industriestandards und Best Practices zu überprüfen. Security Hub sammelt Ergebnisse aus verschiedenen Quellen, einschließlich Integrationen mit anderen Produktintegrationen von Drittanbietern AWS -Services, und überprüft sie anhand der Security Hub Hub-Kontrollen. Security Hub verarbeitet Ergebnisse in einem Standardformat namens AWS Security Finding Format (ASFF).

Wenn Sie Security Hub-Ergebnisse als Quelle in Security Lake hinzufügen, beginnt Security Lake sofort, Ihre Ergebnisse über einen unabhängigen und duplizierten Ereignisstrom direkt von Security Hub zu sammeln. Security Lake wandelt auch die Ergebnisse von ASFF in Offenes Cybersecurity Schema Framework (OCSF) (OCSF) um.

Security Lake verwaltet Ihre Security Hub Hub-Ergebnisse nicht und hat auch keinen Einfluss auf Ihre Security Hub Hub-Einstellungen. Um die Security Hub-Ergebnisse zu verwalten, müssen Sie die Security Hub-Servicekonsole, API oder verwenden AWS CLI. Weitere Informationen finden Sie unter Ergebnisse AWS Security Hub im AWS Security Hub Benutzerhandbuch.

Die folgende Liste enthält GitHub Repository-Links zur Mapping-Referenz, in der beschrieben wird, wie Security Lake Security Hub Hub-Ergebnisse auf OCSF normalisiert.

GitHub OCSF-Repository für Security Hub Hub-Ergebnisse

VPC Flow Logs

Die VPC Flow Logs-Funktion von Amazon VPC erfasst Informationen über den IP-Verkehr zu und von Netzwerkschnittstellen in Ihrer Umgebung.

Wenn Sie VPC Flow Logs als Quelle in Security Lake hinzufügen, beginnt Security Lake sofort mit der Erfassung Ihrer VPC Flow Logs. Es verwendet VPC Flow Logs direkt von Amazon VPC über einen unabhängigen und duplizierten Stream von Flow Logs.

Security Lake verwaltet Ihre VPC Flow Logs nicht und hat auch keinen Einfluss auf Ihre Amazon VPC-Konfigurationen. Um Ihre Flow Logs zu verwalten, müssen Sie die Amazon VPC-Servicekonsole verwenden. Weitere Informationen finden Sie unter Arbeiten mit Flow-Protokollen im Amazon VPC Developer Guide.

Die folgende Liste enthält GitHub Repository-Links zur Mapping-Referenz, in der beschrieben wird, wie Security Lake VPC Flow Logs auf OCSF normalisiert.

GitHub OCSF-Repository für VPC Flow Logs

AWS WAF Logs

Wenn Sie Security Lake AWS WAF als Protokollquelle hinzufügen, beginnt Security Lake sofort mit der Erfassung der Protokolle. AWS WAF ist eine Firewall für Webanwendungen, mit der Sie Webanfragen überwachen können, die Ihre Endbenutzer an Ihre Anwendungen senden, und den Zugriff auf Ihre Inhalte kontrollieren können. Zu den protokollierten Informationen gehören die Uhrzeit, zu der eine Webanfrage von Ihrer AWS Ressource AWS WAF empfangen wurde, detaillierte Informationen zu der Anfrage und Details zu den Regeln, denen die Anfrage entsprach.

Security Lake verarbeitet AWS WAF Protokolle direkt aus einem AWS WAF unabhängigen und duplizierten Protokollstrom. Dieser Prozess ist so konzipiert, dass keine zusätzliche Einrichtung erforderlich ist und sich auch nicht auf bestehende AWS WAF Konfigurationen auswirkt. Weitere Informationen dazu, wie Sie Ihre Anwendungsressourcen schützen können, finden Sie im AWS WAF Entwicklerhandbuch unter So AWS WAF funktioniert es. AWS WAF

Wichtig

Wenn Sie Amazon CloudFront Distribution als Ressourcentyp verwenden AWS WAF, müssen Sie USA Ost (Nord-Virginia) auswählen, um die globalen Protokolle in Security Lake aufzunehmen.

AWS WAF Logs wird nur in OCSF v1.1.0 unterstützt. Informationen darüber, wie Security Lake AWS WAF Log-Ereignisse auf OCSF normalisiert, finden Sie in der Mapping-Referenz im GitHub OCSF-Repository für AWS WAF Logs (v1.1.0).

Eine als Quelle hinzufügen AWS -Service

Nachdem Sie eine AWS -Service als Quelle hinzugefügt haben, beginnt Security Lake automatisch mit der Erfassung von Sicherheitsprotokollen und Ereignissen aus dieser Quelle. In diesen Anweisungen erfahren Sie, wie Sie eine nativ unterstützte Quelle in AWS -Service Security Lake hinzufügen. Anweisungen zum Hinzufügen einer benutzerdefinierten Quelle finden Sie unter. Sammeln von Daten aus benutzerdefinierten Quellen

Console
So fügen Sie eine AWS Protokollquelle hinzu (Konsole)
  1. Öffnen Sie die Security Lake-Konsole unter https://console.aws.amazon.com/securitylake/.

  2. Wählen Sie im Navigationsbereich Quellen aus.

  3. Wählen Sie AWS -Service die Datei aus, von der Sie Daten sammeln möchten, und klicken Sie auf Konfigurieren.

  4. Aktivieren Sie im Abschnitt Quelleinstellungen die Quelle und wählen Sie die Version der Datenquelle aus, die Sie für die Datenaufnahme verwenden möchten. Standardmäßig wird die neueste Version der Datenquelle von Security Lake aufgenommen.

    Wichtig

    Wenn Sie nicht über die erforderlichen Rollenberechtigungen verfügen, um die neue Version der AWS Protokollquelle in der angegebenen Region zu aktivieren, wenden Sie sich an Ihren Security Lake-Administrator. Weitere Informationen finden Sie unter Rollenberechtigungen aktualisieren.

    Damit Ihre Abonnenten die ausgewählte Version der Datenquelle aufnehmen können, müssen Sie auch Ihre Abonnenteneinstellungen aktualisieren. Einzelheiten zur Bearbeitung eines Abonnenten finden Sie unter Abonnentenverwaltung in Amazon Security Lake.

    Optional können Sie festlegen, dass nur die neueste Version aufgenommen und alle vorherigen Quellversionen, die für die Datenaufnahme verwendet wurden, deaktiviert werden.

  5. Wählen Sie im Abschnitt Regionen die Regionen aus, in denen Sie Daten für die Quelle sammeln möchten. Security Lake sammelt Daten aus der Quelle von allen Konten in den ausgewählten Regionen.

  6. Wählen Sie Enable (Aktivieren) aus.

API

Um eine AWS Protokollquelle (API) hinzuzufügen

Verwenden Sie den CreateAwsLogSourceBetrieb der Security Lake-API, um eine programmgesteuert AWS -Service als Quelle hinzuzufügen. Wenn Sie AWS Command Line Interface (AWS CLI) verwenden, führen Sie den Befehl create-aws-log-source aus. Die Parameter sourceName und regions müssen angegeben werden. Optional können Sie den Umfang der Quelle auf einen bestimmten oder einen bestimmten Bereich beschränken. accounts sourceVersion

Wichtig

Wenn Sie in Ihrem Befehl keinen Parameter angeben, geht Security Lake davon aus, dass sich der fehlende Parameter auf den gesamten Satz bezieht. Wenn Sie den accounts Parameter beispielsweise nicht angeben, gilt der Befehl für die gesamte Gruppe von Konten in Ihrer Organisation.

Im folgenden Beispiel werden VPC Flow Logs als Quelle in den angegebenen Konten und Regionen hinzugefügt. Dieses Beispiel ist für Linux, macOS oder Unix formatiert und verwendet den umgekehrten Schrägstrich (\) zur Verbesserung der Lesbarkeit.

Anmerkung

Wenn Sie diese Anfrage auf eine Region anwenden, in der Sie Security Lake nicht aktiviert haben, erhalten Sie eine Fehlermeldung. Sie können den Fehler beheben, indem Sie Security Lake in dieser Region aktivieren oder indem Sie den regions Parameter verwenden, um nur die Regionen anzugeben, in denen Sie Security Lake aktiviert haben.

$ aws securitylake create-aws-log-source \ --sources sourceName=VPC_FLOW,accounts='["123456789012", "111122223333"]',regions=["us-east-2"],sourceVersion="2.0"

Rollenberechtigungen werden aktualisiert

Wenn Sie nicht über die erforderlichen Rollenberechtigungen oder Ressourcen — neue AWS Lambda Funktion und Amazon Simple Queue Service (Amazon SQS) -Warteschlange — verfügen, um Daten aus einer neuen Version der Datenquelle aufzunehmen, müssen Sie Ihre AmazonSecurityLakeMetaStoreManagerV2 Rollenberechtigungen aktualisieren und einen neuen Satz von Ressourcen erstellen, um Daten aus Ihren Quellen zu verarbeiten.

Wählen Sie Ihre bevorzugte Methode und folgen Sie den Anweisungen, um Ihre Rollenberechtigungen zu aktualisieren und neue Ressourcen zu erstellen, um Daten aus einer neuen Version einer AWS Protokollquelle in einer bestimmten Region zu verarbeiten. Dies ist eine einmalige Aktion, da die Berechtigungen und Ressourcen automatisch auf future Datenquellenversionen angewendet werden.

Console
Um die Rollenberechtigungen zu aktualisieren (Konsole)
  1. Öffnen Sie die Security Lake-Konsole unter https://console.aws.amazon.com/securitylake/.

    Melden Sie sich mit den Anmeldeinformationen des delegierten Security Lake-Administrators an.

  2. Klicken Sie im Navigationsbereich unter Settings auf General.

  3. Wählen Sie „Rollenberechtigungen aktualisieren“.

  4. Führen Sie im Abschnitt Dienstzugriff einen der folgenden Schritte aus:

    • Eine neue Servicerolle erstellen und verwenden — Sie können die von Security Lake erstellte AmazonSecurityLakeMetaStoreManagerV2-Rolle verwenden.

    • Eine bestehende Servicerolle verwenden — Sie können eine vorhandene Servicerolle aus der Liste der Servicerollennamen auswählen.

  5. Wählen Sie Apply (Anwenden) aus.

API

So aktualisieren Sie die Rollenberechtigungen (API)

Verwenden Sie den UpdateDataLakeBetrieb der Security Lake-API, um Berechtigungen programmgesteuert zu aktualisieren. Um Berechtigungen mit dem zu aktualisieren AWS CLI, führen Sie den update-data-lakeBefehl aus.

Um Ihre Rollenberechtigungen zu aktualisieren, müssen Sie die AmazonSecurityLakeMetastoreManagerRichtlinie an die Rolle anhängen.

Die AmazonSecurityLakeMetaStoreManager Rolle wird gelöscht

Wichtig

Nachdem Sie Ihre Rollenberechtigungen auf aktualisiert habenAmazonSecurityLakeMetaStoreManagerV2, stellen Sie sicher, dass der Data Lake ordnungsgemäß funktioniert, bevor Sie die alte AmazonSecurityLakeMetaStoreManager Rolle entfernen. Es wird empfohlen, mindestens 4 Stunden zu warten, bevor Sie die Rolle entfernen.

Wenn Sie sich entscheiden, die Rolle zu entfernen, müssen Sie zuerst die AmazonSecurityLakeMetaStoreManager Rolle von AWS Lake Formation löschen.

Gehen Sie wie folgt vor, um die AmazonSecurityLakeMetaStoreManager Rolle aus der Lake Formation Formation-Konsole zu entfernen.

  1. Melden Sie sich bei der AWS Management Console an und öffnen Sie die Lake Formation Formation-Konsole unter https://console.aws.amazon.com/lakeformation/.

  2. Wählen Sie in der Lake Formation Formation-Konsole im Navigationsbereich die Option Administrative Rollen und Aufgaben aus.

  3. AmazonSecurityLakeMetaStoreManagerAus jeder Region entfernen.

AWS -Service Als Quelle entfernen

Wählen Sie Ihre Zugriffsmethode und gehen Sie wie folgt vor, um eine nativ AWS -Service als Security Lake unterstützte Quelle zu entfernen. Sie können eine Quelle für eine oder mehrere Regionen entfernen. Wenn Sie die Quelle entfernen, beendet Security Lake die Erfassung von Daten aus dieser Quelle in den angegebenen Regionen und Konten, und Abonnenten können keine neuen Daten mehr aus der Quelle nutzen. Abonnenten können jedoch weiterhin Daten nutzen, die Security Lake vor dem Entfernen aus der Quelle gesammelt hat. Sie können diese Anweisungen nur verwenden, um eine nativ unterstützte AS-Quelle AWS -Service zu entfernen. Informationen zum Entfernen einer benutzerdefinierten Quelle finden Sie unter. Sammeln von Daten aus benutzerdefinierten Quellen

Console
  1. Öffnen Sie die Security Lake-Konsole unter https://console.aws.amazon.com/securitylake/.

  2. Wählen Sie im Navigationsbereich Quellen aus.

  3. Wählen Sie eine Quelle aus und klicken Sie auf Deaktivieren.

  4. Wählen Sie eine oder mehrere Regionen aus, in denen Sie die Erfassung von Daten aus dieser Quelle beenden möchten. Security Lake beendet die Erfassung von Daten aus der Quelle für alle Konten in den ausgewählten Regionen.

API

Verwenden Sie den DeleteAwsLogSourceBetrieb der Security Lake-API, um eine AWS -Service als Quelle programmgesteuert zu entfernen. Wenn Sie AWS Command Line Interface (AWS CLI) verwenden, führen Sie den Befehl delete-aws-log-source aus. Die Parameter sourceName und regions müssen angegeben werden. Optional können Sie den Umfang der Entfernung auf einen bestimmten oder einen bestimmten Bereich beschränken. accounts sourceVersion

Wichtig

Wenn Sie in Ihrem Befehl keinen Parameter angeben, geht Security Lake davon aus, dass sich der fehlende Parameter auf den gesamten Satz bezieht. Wenn Sie den accounts Parameter beispielsweise nicht angeben, gilt der Befehl für die gesamte Gruppe von Konten in Ihrer Organisation.

Im folgenden Beispiel werden VPC Flow Logs als Quelle in den angegebenen Konten und Regionen entfernt.

$ aws securitylake delete-aws-log-source \ --sources sourceName=VPC_FLOW,accounts='["123456789012", "111122223333"]',regions='["us-east-1", "us-east-2"]',sourceVersion="2.0"

Im folgenden Beispiel wird Route 53 als Quelle im angegebenen Konto und in den angegebenen Regionen entfernt.

$ aws securitylake delete-aws-log-source \ --sources sourceName=ROUTE53,accounts='["123456789012"]',regions='["us-east-1", "us-east-2"]',sourceVersion="2.0"

Die obigen Beispiele sind für Linux, macOS oder Unix formatiert und verwenden zur besseren Lesbarkeit den umgekehrten Schrägstrich (\) als Zeilenfortsetzung.

Den Status der Quellensammlung abrufen

Wählen Sie Ihre Zugriffsmethode und folgen Sie den Schritten, um einen Überblick über die Konten und Quellen zu erhalten, für die die Protokollerfassung in der aktuellen Region aktiviert ist.

Console
Um den Status der Protokollerfassung in der aktuellen Region abzurufen
  1. Öffnen Sie die Security Lake-Konsole unter https://console.aws.amazon.com/securitylake/.

  2. Wählen Sie im Navigationsbereich Accounts aus.

  3. Zeigen Sie mit der Maus auf die Zahl in der Spalte Quellen, um zu sehen, welche Protokolle für das ausgewählte Konto aktiviert sind.

API

Um den Status der Protokollerfassung in der aktuellen Region abzurufen, verwenden Sie den GetDataLakeSourcesBetrieb der Security Lake-API. Wenn Sie den verwenden AWS CLI, führen Sie den Befehl get-data-lake-sources aus. Für den accounts Parameter können Sie eine oder mehrere AWS-Konto IDs als Liste angeben. Wenn Ihre Anfrage erfolgreich ist, gibt Security Lake einen Snapshot für die Konten in der aktuellen Region zurück, einschließlich der AWS Quellen, aus denen Security Lake Daten sammelt, und des Status der einzelnen Quellen. Wenn Sie den accounts Parameter nicht angeben, enthält die Antwort den Status der Protokollerfassung für alle Konten, für die Security Lake in der aktuellen Region konfiguriert ist.

Mit dem folgenden AWS CLI Befehl wird beispielsweise der Status der Protokollerfassung für die angegebenen Konten in der aktuellen Region abgerufen. Dieses Beispiel ist für Linux, macOS oder Unix formatiert und verwendet den umgekehrten Schrägstrich (\) zur Verbesserung der Lesbarkeit.

$ aws securitylake get-data-lake-sources \ --accounts "123456789012" "111122223333"