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.

Prüfung von Amazon DocumentDB-Ereignissen

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 Auditing in Amazon DocumentDB deaktiviert und erfordert, dass Sie sich für die Nutzung dieser Funktion anmelden.

Wenn die Überwachung aktiviert ist, zeichnet Amazon DocumentDB Ereignisse in den Bereichen Data Definition Language (DDL), Data Manipulation Language (DML), Authentifizierung, Autorisierung und Benutzerverwaltung bei Amazon auf CloudWatch Protokolle. Wenn das Auditing aktiviert ist, exportiert Amazon DocumentDB die Audit-Aufzeichnungen (JSON-Dokumente) Ihres Clusters nach Amazon CloudWatch Protokolle. Sie können Amazon verwenden CloudWatch Protokolle zur Analyse, Überwachung und Archivierung Ihrer Amazon DocumentDB-Auditing-Ereignisse.

Amazon DocumentDB berechnet zwar keine zusätzlichen Kosten für die Aktivierung der Prüfung, Ihnen werden jedoch Standardtarife für die Nutzung von berechnet CloudWatch Protokolle. Für Informationen über CloudWatch Preise für Protokolle finden Sie unter Amazon CloudWatch Preisgestaltung.

Die Amazon DocumentDB-Auditing-Funktion unterscheidet sich deutlich von der Nutzung der Serviceressourcen, die mit überwacht wird AWS CloudTrail. CloudTrail zeichnet Operationen auf, die mit dem ausgeführt werden AWS Command Line Interface (AWS CLI) oder AWS-Managementkonsole auf Ressourcen wie Clustern, Instanzen, Parametergruppen und Snapshots. Prüfung von Ressourcen mit CloudTrail ist standardmäßig aktiviert und kann nicht deaktiviert werden. Die Amazon DocumentDB-Auditing-Funktion ist eine Opt-in-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 Auditing unterstützt die folgenden Ereigniskategorien:

Folgende Ereignistypen werden unterstützt:

Auditing aktivieren

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

Schritt 1. Aktivieren Sie den Clusterparameter audit_logs

Um das Auditing zu aktivieren, müssen Sie das ändern audit_logs Parameter in der Parametergruppe. audit_logs ist eine kommagetrennte Liste der zu protokollierenden Ereignisse. Ereignisse müssen in Kleinbuchstaben angegeben werden und zwischen den Listenelementen darf kein Leerzeichen stehen.

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 aktivieren CloudWatch Exportieren von Protokollen

Wenn der Wert von audit_logs Cluster-Parameter ist enabled, ddl, dml_read, oder dml_write, Sie müssen Amazon DocumentDB auch aktivieren, um Protokolle nach Amazon zu exportieren CloudWatch. Wenn Sie einen dieser Schritte auslassen, werden keine Auditprotokolle gesendet an CloudWatch.

Wenn Sie einen Cluster erstellen, eine Point-in-Time-Wiederherstellung durchführen oder einen Snapshot wiederherstellen, können Sie Folgendes aktivieren CloudWatch Protokolliert, indem Sie die folgenden Schritte ausführen.

Using the AWS-Managementkonsole

Um Amazon DocumentDB den Export von Protokollen zu ermöglichen nach CloudWatch Wenn Sie die Konsole verwenden, lesen Sie die folgenden Themen:

• Beim Erstellen eines Clusters — In Erstellen eines Clusters und einer primären Instance mit dem AWS-Managementkonsole, siehe Einen Cluster erstellen: Zusätzliche Konfigurationen (Schritt 5, Exporte protokollieren)

• 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 — Wiederherstellung auf einen bestimmten Zeitpunkt

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-Protokolle.

Beispiel

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 Audit-Protokolle.

Beispiel

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 in etwa wie folgt aus (JSON-Format).

{
    "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 deaktivieren

Sie können die Überwachung deaktivieren, indem Sie CloudWatch Export von Protokollen und Deaktivierung der audit_logs Parameter.

Deaktivierung CloudWatch Exportieren von Protokollen

Sie können den Export von Auditprotokollen mit einer der folgenden Optionen deaktivieren AWS-Managementkonsole oder der AWS CLI.

Using the AWS-Managementkonsole

Das folgende Verfahren verwendet AWS-Managementkonsole um den Amazon DocumentDB-Export von Protokollen zu deaktivieren CloudWatch.

So deaktivieren Sie Prüfungsprotokolle

1. Melden Sie sich bei der AWS-Managementkonsole, und öffnen Sie die Amazon 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 ändert den Cluster sample-cluster und deaktiviert CloudWatch Audit-Protokolle.

Beispiel

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 dieser Operation sieht in etwa folgendermaßen aus (JSON-Format).

{
    "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 Audit-Ereignisse bei Amazon zuzugreifen CloudWatch.

Filterung von DML-Audit-Ereignissen

Erste Schritte mit der DML-Auditfilterung

DML-Auditereignisse können gefiltert werden, bevor sie an Amazon geschrieben werden CloudWatch. Um diese Funktion nutzen zu können, müssen Audit-Log und DML-Logging aktiviert sein. Amazon DocumentDB unterstützt das Filtern nach atype, command, user, namespace, und auditAuthorizationSuccess.

Sie können die Überwachungsfilterung jederzeit aktivieren, indem Sie den Überwachungsfilter mithilfe der setAuditConfig, filter, und auditAuthorizationSuccess Parameter in der db.adminCommand( { command } ) Bedienung:

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

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

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

Sicherheitsanforderungen

Nur Datenbank users/roles mit privilegierter Aktion auditConfigure kann die obigen Befehle ausführen gegen admindb beim Setzen oder Auflisten von DML-Auditfiltern. Sie können entweder eine der integrierten Rollen von [verwendenclusterAdmin, hostManager, root] oder erstellen Sie benutzerdefinierte Rollen, die auditConfigure Privilegien. Das Folgende ist ein Beispiel für die Verwendung vorhandener Rollen mit auditConfigure Privileg und ein Beispiel mit benutzerdefinierten 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 anhand von 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: Filtern mithilfe mehrerer Filter, die durch Operatoren 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: Filtern 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

Bei Verwendung von beidem in $in und $nin, der Befehl wird nicht protokolliert, da zwischen den Bedingungen ein implizites „und“ steht. In diesem Beispiel blockiert Regex find Befehl, damit 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: Auf Standardfilter zurücksetzen

Das Zurücksetzen auf den Standardwert bedeutet, dass jedes DML-Audit-Ereignis 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
   }
)