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.

Amazon DocumentDB DocumentDB-Ereignisse prüfen

Mit Amazon DocumentDB (mit MongoDB-Kompatibilität) können Sie Ereignisse überprüfen, die in Ihrem Cluster durchgeführt wurden. Beispiele für protokollierte Ereignisse sind erfolgreiche und fehlgeschlagene Authentifizierungsversuche, Drop-Ereignisse für Sammlungen in einer Datenbank oder das Erstellen eines Index. Standardmäßig ist die Prüfung in Amazon DocumentDB deaktiviert und erfordert, dass Sie sich für die Nutzung dieser Funktion anmelden.

Wenn die Prüfung aktiviert ist, zeichnet Amazon DocumentDB Ereignisse in Data Definition Language (DDL), Data Manipulation Language (DML), Authentifizierung, Autorisierung und Benutzerverwaltung in Amazon CloudWatch Logs auf. Wenn Auditing aktiviert ist, exportiert Amazon DocumentDB die Auditing-Datensätze (JSONDokumente) Ihres Clusters nach Amazon CloudWatch Logs. Sie können Amazon CloudWatch Logs verwenden, um Ihre Amazon DocumentDB-Prüfungsereignisse zu analysieren, zu überwachen und zu archivieren.

Amazon DocumentDB berechnet zwar keine zusätzlichen Kosten für die Aktivierung der Prüfung, Ihnen werden jedoch Standardtarife für die Nutzung von CloudWatch Logs berechnet. Informationen zu den Preisen für CloudWatch Logs finden Sie unter CloudWatch Amazon-Preise.

Die Amazon DocumentDB-Prüfungsfunktion unterscheidet sich deutlich von der Nutzung der Serviceressourcen, mit der überwacht wird. AWS CloudTrail CloudTrail zeichnet Operationen AWS Management Console auf, die mit AWS Command Line Interface (AWS CLI) oder mit Ressourcen wie Clustern, Instances, Parametergruppen und Snapshots ausgeführt werden. Die Überwachung von Ressourcen mit CloudTrail ist standardmäßig aktiviert und kann nicht deaktiviert werden. Die Amazon DocumentDB-Prüfungsfunktion ist eine optionale Funktion. Sie zeichnet Operationen auf, die innerhalb Ihres Clusters für Objekte, wie z. B. Datenbanken, Sammlungen, Indizes und Benutzer ausgeführt werden.

Unterstützte Ereignisse

Amazon DocumentDB DocumentDB-Auditing unterstützt die folgenden Ereigniskategorien:

Folgende Ereignistypen werden unterstützt:

Überwachung wird aktiviert

Die Aktivierung des Prüfens für einen Cluster ist ein zweistufiger Prozess. Stellen Sie sicher, dass beide Schritte abgeschlossen sind, da andernfalls keine Auditprotokolle an CloudWatch Logs gesendet werden.

Schritt 1. Aktivieren Sie den Clusterparameter audit_logs

Um die Überwachung zu aktivieren, müssen Sie den audit_logs Parameter in der Parametergruppe ändern. audit_logsist eine durch Kommas getrennte Liste von Ereignissen, die protokolliert werden sollen. Ereignisse müssen in Kleinbuchstaben angegeben werden und es darf kein Leerzeichen zwischen den Listenelementen sein.

Sie können die folgenden Werte für die Parametergruppe festlegen:

Sie können die oben genannten Werte auch in Kombinationen verwenden.

Weitere Informationen finden Sie hier:

Schritt 2. Amazon CloudWatch Logs-Export aktivieren

Wenn der Wert des audit_logs Cluster-Parametersenabled,, oder dml_write ist ddldml_read, müssen Sie Amazon DocumentDB auch für den Export von Protokollen nach Amazon CloudWatch aktivieren. Wenn Sie einen dieser Schritte auslassen, werden keine Audit-Logs an gesendet. CloudWatch

Wenn Sie einen Cluster erstellen, einen Snapshot ausführen oder einen point-in-time-restore Snapshot wiederherstellen, können Sie CloudWatch Logs aktivieren, indem Sie die folgenden Schritte ausführen.

Using the AWS Management Console

Informationen zum Exportieren von Protokollen durch Amazon DocumentDB in die CloudWatch Konsole finden Sie in den folgenden Themen:

• Beim Erstellen eines Clusters — siehe Cluster erstellen: Zusätzliche Konfigurationen (Schritt 5, Protokollexporte) Erstellen eines Clusters und einer primären Instance mithilfe der AWS Management Console

• Beim Ändern eines vorhandenen Clusters — Ändern eines Amazon DocumentDB-Clusters

• Bei der Durchführung einer Cluster-Snapshot-Wiederherstellung — Wiederherstellung aus einem Cluster-Snapshot

• Bei der Durchführung einer point-in-time Wiederherstellung — Zu einem bestimmten Zeitpunkt wiederherstellen

Using the AWS CLI

So aktivieren Sie Prüfungsprotokolle beim Erstellen eines neuen Clusters

Der folgende Code erstellt den Cluster sample-cluster und aktiviert CloudWatch Audit-Logs.

Für Linux, macOS oder Unix:

aws docdb create-db-cluster \
    --db-cluster-identifier sample-cluster \
    --port 27017 \
    --engine docdb \
    --master-username master-username \
    --master-user-password password \
    --db-subnet-group-name default \
    --enable-cloudwatch-logs-exports audit

Für Windows:

aws docdb create-db-cluster ^
    --db-cluster-identifier sample-cluster ^
    --port 27017 ^
    --engine docdb ^
    --master-username master-username ^
    --master-user-password password ^
    --db-subnet-group-name default ^
    --enable-cloudwatch-logs-exports audit

So aktivieren Sie Prüfungsprotokolle beim Ändern eines vorhandenen Clusters

Der folgende Code ändert den Cluster sample-cluster und aktiviert CloudWatch Auditprotokolle.

Für Linux, macOS oder Unix:

aws docdb modify-db-cluster \
   --db-cluster-identifier sample-cluster \
   --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'

Für Windows:

aws docdb modify-db-cluster ^
   --db-cluster-identifier sample-cluster ^
   --cloudwatch-logs-export-configuration '{"EnableLogTypes":["audit"]}'

Die Ausgabe dieser Operationen sieht etwa wie folgt aus (JSONFormat).

{
    "DBCluster": {
        "HostedZoneId": "ZNKXH85TT8WVW",
        "StorageEncrypted": false,
        "DBClusterParameterGroup": "default.docdb4.0",
        "MasterUsername": "<user-name>",
        "BackupRetentionPeriod": 1,
        "Port": 27017,
        "VpcSecurityGroups": [
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-77186e0d"
            }
        ],
        "DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster",
        "Status": "creating",
        "Engine": "docdb",
        "EngineVersion": "4.0.0",
        "MultiAZ": false,
        "AvailabilityZones": [
            "us-east-1a",
            "us-east-1c",
            "us-east-1f"
        ],
        "DBSubnetGroup": "default",
        "DBClusterMembers": [],
        "ReaderEndpoint": "sample-cluster.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
        "EnabledCloudwatchLogsExports": [
            "audit"
        ],
        "PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
        "AssociatedRoles": [],
        "ClusterCreateTime": "2019-02-13T16:35:04.756Z",
        "DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
        "Endpoint": "sample-cluster.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
        "PreferredBackupWindow": "07:16-07:46",
        "DBClusterIdentifier": "sample-cluster"
    }
}

Auditing wird deaktiviert

Sie können die Überwachung deaktivieren, indem Sie den CloudWatch Protokollexport und den audit_logs Parameter deaktivieren.

Den Export von Protokollen deaktivieren CloudWatch

Sie können den Export von Auditprotokollen entweder mit dem AWS Management Console oder dem AWS CLI deaktivieren.

Using the AWS Management Console

Das folgende Verfahren verwendet die AWS Management Console , um den Export von Protokollen durch Amazon DocumentDB zu CloudWatch deaktivieren.

So deaktivieren Sie Prüfungsprotokolle

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

2. Klicken Sie im Navigationsbereich auf Cluster. Wählen Sie anschließend die Schaltfläche links neben dem Namen des Clusters aus, für den Sie das Exportieren von Protokollen deaktivieren möchten.

3. Wählen Sie Actions (Aktionen) und dann Modify (Ändern) aus.

4. Scrollen Sie nach unten zum Abschnitt Log exports (Protokollexporte) und wählen Sie Disabled (Deaktiviert) aus.

5. Klicken Sie auf Weiter.

6. Überprüfen Sie Ihre Änderungen. Wählen Sie anschließend den Zeitpunkt aus, an dem diese Änderung auf Ihren Cluster angewendet werden soll.

   • Apply during the next scheduled maintenance window (Anwendung während des nächsten geplanten Wartungsfensters)

   • Apply immediately (Sofort anwenden)

7. Wählen Sie Cluster bearbeiten aus.

Using the AWS CLI

Der folgende Code modifiziert den Cluster sample-cluster und deaktiviert Audit-Logs. CloudWatch

Für Linux, macOS oder Unix:

aws docdb modify-db-cluster \
   --db-cluster-identifier sample-cluster \
   --cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'

Für Windows:

aws docdb modify-db-cluster ^
   --db-cluster-identifier sample-cluster ^
   --cloudwatch-logs-export-configuration '{"DisableLogTypes":["audit"]}'

Die Ausgabe dieses Vorgangs sieht etwa wie folgt aus (JSONFormat).

{
    "DBCluster": {
        "DBClusterParameterGroup": "default.docdb4.0",
        "HostedZoneId": "ZNKXH85TT8WVW",
        "MasterUsername": "<user-name>",
        "Status": "available",
        "Engine": "docdb",
        "Port": 27017,
        "AvailabilityZones": [
            "us-east-1a",
            "us-east-1c",
            "us-east-1f"
        ],
        "EarliestRestorableTime": "2019-02-13T16:35:50.387Z",
        "DBSubnetGroup": "default",
        "LatestRestorableTime": "2019-02-13T16:35:50.387Z",
        "DBClusterArn": "arn:aws:rds:us-east-1:900083794985:cluster:sample-cluster2",
        "Endpoint": "sample-cluster2.cluster-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
        "ReaderEndpoint": "sample-cluster2.cluster-ro-corcjozrlsfc.us-east-1.docdb.amazonaws.com",
        "BackupRetentionPeriod": 1,
        "EngineVersion": "4.0.0",
        "MultiAZ": false,
        "ClusterCreateTime": "2019-02-13T16:35:04.756Z",
        "DBClusterIdentifier": "sample-cluster2",
        "AssociatedRoles": [],
        "PreferredBackupWindow": "07:16-07:46",
        "DbClusterResourceId": "cluster-YOS52CUXGDTNKDQ7DH72I4LED4",
        "StorageEncrypted": false,
        "PreferredMaintenanceWindow": "wed:03:08-wed:03:38",
        "DBClusterMembers": [],
        "VpcSecurityGroups": [
            {
                "Status": "active",
                "VpcSecurityGroupId": "sg-77186e0d"
            }
        ]
    }
}

Deaktivierung des Parameters audit_logs

Um den Parameter audit_logs für Ihren Cluster zu deaktivieren, können Sie den Cluster so ändern, dass er eine Parametergruppe mit dem Wert disabled für den Parameter audit_logs verwendet. Sie können auch den Wert des Parameters audit_logs in der Parametergruppe des Clusters in disabled ändern.

Weitere Informationen finden Sie unter den folgenden Themen:

Zugriff auf Ihre Prüfereignisse

Gehen Sie wie folgt vor, um auf Ihre Prüfereignisse bei Amazon zuzugreifen CloudWatch.

DMLPrüfereignisse filtern

Erste Schritte mit der DML Auditfilterung

DMLPrüfereignisse können gefiltert werden, bevor sie an Amazon geschrieben werden CloudWatch. Um diese Funktion nutzen zu können, müssen das Auditprotokoll und die DML Protokollierung aktiviert sein. Amazon DocumentDB unterstützt das Filtern nach atypecommand,user,namespace, undauditAuthorizationSuccess.

Sie können die Überwachungsfilterung jederzeit aktivieren, indem Sie den Überwachungsfilter mithilfe der auditAuthorizationSuccess Parameter setAuditConfigfilter, und im db.adminCommand( { command } ) Vorgang angeben:

db.admin.runCommand(
   {
      setAuditConfig: 1, 
      filter:
         {
            //filter conditions
         },
      auditAuthorizationSuccess: true | false
   }
)

Sie können die Auditfiltereinstellungen auch abrufen, indem Sie den folgenden Befehl ausführen:

db.admin.runCommand( { getAuditConfig: 1})

Sicherheitsanforderungen

Nur Datenbankbenutzer/Rollen mit privilegierten Aktionen auditConfigure können die oben genannten Befehle admindb beim Setzen oder Auflisten von DML Auditfiltern ausführen. Sie können entweder eine der integrierten Rollen von [clusterAdmin,hostManager,root] verwenden oder benutzerdefinierte Rollen mit Rechten erstellen. auditConfigure Im Folgenden finden Sie ein Beispiel für die Verwendung vorhandener Rollen mit dieser auditConfigure Berechtigung und ein Beispiel für benutzerdefinierte Rollen.

Benutzer mit integrierter Rolle:

use admin
db.createUser(
  {
    user: "myClusterAdmin",
    pwd: "password123",
    roles: [ { role: "clusterAdmin", db: "admin" } ]
  }
)

Benutzer mit benutzerdefinierten Rollen:

use admin
db.createRole(
   {
     role: "myRole",
     privileges: [
       { resource: { cluster: true }, actions: [ "auditConfigure" ] }
     ],
     roles: []
   }
)
db.createUser(
  {
    user: "myUser",
    pwd: "myPassword",
    roles: [ { role: "myRole", db: "admin" } ]
  }
)

Anwendungsfälle filtern

Beispiel: Ereignisse nach Befehlen filtern

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {
        "$and": [
         {
            "param.command":
               {
                  $in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
               }
         }
         ]
      },
      auditAuthorizationSuccess: true
   }
)

Beispiel: Ereignisse nach Benutzernamen filtern

In diesem Beispiel wird nur der Benutzer myUser "" protokolliert:

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {
      "$and": [
         {
            "param.user":
               {
                  $in: [ "myUser" ]
               }
         }
         ]},
      auditAuthorizationSuccess: true})

Beispiel: Filtern nach atype

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {atype: "authCheck"},
      auditAuthorizationSuccess: true
   })

Beispiel: Filterung mithilfe mehrerer Filter, die durch Operatoren miteinander verbunden sind

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {
      "$and": [
         {
            "param.command":
               {
                  $in: [ "find","count", "insert", "delete", "update", "findandmodify" ]
               }
         }
         ],
       "$nor": [
         {
            "param.command":
               {
                  $in: ["count", "insert", "delete", "update", "findandmodify" ]
               }
         }]  
       },
      auditAuthorizationSuccess: true})

Beispiel: Filterung nach Ereignissen nach auditAuthorizationSuccess

In diesem Filter werden alle Befehle, die die Autorisierung erfolgreich bestanden haben, nicht protokolliert:

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {},
      auditAuthorizationSuccess: false
   }
)

Beispiel: Filtern mit $in und $nin -Bedingungen

Wenn Sie $in sowohl in als auch verwenden$nin, wird der Befehl nicht protokolliert, da zwischen den Bedingungen ein implizites „und“ steht. In diesem Beispiel blockiert Regex den find Befehl, sodass nichts protokolliert wird:

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {
      "$and": [
         {
            atype: "authCheck",
            "param.command":
               {
                  $in: [ "find", "insert", "delete", "update", "findandmodify" ],
                  $nin: ["count", "insert", "delete", "update", "findandmodify" ],
                  $not: /^^find.*/
               }
         }, 
         ],
       "$or": [
         {
            "param.command":
               {
                  $nin: ["count", "insert", "delete", "update", "findandmodify" ]
               }
         }]  
       },
      auditAuthorizationSuccess: true})

Beispiel: Filtern nach namespace

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {
      "$and": [
         {
            "param.ns":
               {
                  $in: [ "test.foo" ]
               }
         }
         ]},
      auditAuthorizationSuccess: true})

Beispiel: Zurücksetzen auf den Standardfilter

Das Zurücksetzen auf den Standardwert bedeutet, dass jedes DML Prüfereignis protokolliert wird. Führen Sie den folgenden Befehl aus, um die Filterung auf den Standardwert zurückzusetzen:

db.admin.runCommand(
   {
      setAuditConfig: 1,
      filter: {},
      auditAuthorizationSuccess: true
   }
)