Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Verifica degli eventi di Amazon DocumentDB

Con Amazon DocumentDB (compatibile con MongoDB), puoi controllare gli eventi che sono stati eseguiti nel tuo cluster. Sono esempi di eventi registrati i tentativi di autenticazione riusciti e non riusciti, l'eliminazione di una raccolta in un database o la creazione di un indice. Per impostazione predefinita, il controllo è disabilitato su Amazon DocumentDB e richiede l'attivazione di questa funzionalità.

Quando il controllo è abilitato, Amazon DocumentDB registra gli eventi di Data Definition Language (DDL), Data Manipulation Language (DML), autenticazione, autorizzazione e gestione degli utenti in Amazon Logs. CloudWatch Quando il controllo è abilitato, Amazon DocumentDB esporta i record di controllo del cluster (documenti JSON) in Amazon Logs. CloudWatch Puoi utilizzare Amazon CloudWatch Logs per analizzare, monitorare e archiviare i tuoi eventi di audit di Amazon DocumentDB.

Sebbene Amazon DocumentDB non addebiti costi aggiuntivi per abilitare l'audit, ti vengono addebitate tariffe standard per l'utilizzo dei log. CloudWatch Per informazioni sui prezzi di CloudWatch Logs, consulta i prezzi di Amazon CloudWatch .

La funzionalità di controllo di Amazon DocumentDB è nettamente diversa dall'utilizzo delle risorse di servizio con cui viene monitorato. AWS CloudTrail CloudTrail registra le operazioni eseguite con AWS Command Line Interface (AWS CLI) o Console di gestione AWS su risorse come cluster, istanze, gruppi di parametri e istantanee. Il controllo delle risorse con CloudTrail è attivo per impostazione predefinita e non può essere disabilitato. La funzionalità di controllo di Amazon DocumentDB è una funzionalità opzionale. Registra le operazioni eseguite all'interno del cluster sugli oggetti, ad esempio database, raccolte, indici e utenti.

Eventi supportati

Il controllo di Amazon DocumentDB supporta le seguenti categorie di eventi:

I tipi di evento sono i seguenti:

Abilitazione del controllo

La procedura per abilitare l'audit in un cluster prevede due fasi: Assicurati che entrambi i passaggi siano completati, altrimenti i log di controllo non verranno inviati a CloudWatch Logs.

Passaggio 1. Abilita il parametro del cluster audit_logs

Per abilitare il controllo, è necessario modificare il audit_logs parametro nel gruppo di parametri. audit_logsè un elenco delimitato da virgole di eventi da registrare. Gli eventi devono essere specificati in minuscolo e non devono esserci spazi vuoti tra gli elementi dell'elenco.

È possibile impostare i seguenti valori per il gruppo di parametri:

È inoltre possibile utilizzare i valori sopra indicati in combinazioni.

Per ulteriori informazioni, consulta gli argomenti seguenti:

Passaggio 2. Abilita l'esportazione di Amazon Logs CloudWatch

Quando il valore del parametro del audit_logs cluster èenabled,, o ddl dml_readdml_write, devi anche abilitare Amazon DocumentDB per esportare i log in Amazon CloudWatch. Se ometti uno di questi passaggi, i log di controllo non verranno inviati a. CloudWatch

Quando si crea un cluster, si esegue un ripristino point-in-time o si ripristina un'istantanea, è possibile abilitare i log seguendo questi passaggi. CloudWatch

Using the Console di gestione AWS

Per consentire ad Amazon DocumentDB di esportare i log CloudWatch utilizzando la console, consulta i seguenti argomenti:

• Durante la creazione di un cluster: inCreazione di un cluster e di un'istanza primaria utilizzando Console di gestione AWS, consulta Creazione di un cluster: configurazioni aggiuntive (passaggio 5, esportazioni di log)

• Quando si modifica un cluster esistente: Modifica di un cluster Amazon DocumentDB

• Quando si esegue un ripristino di un'istantanea del cluster: Ripristino da un'istantanea del cluster

• Quando si esegue un ripristino point-in-time: Ripristino a un determinato punto nel tempo

Using the AWS CLI

Per abilitare i log di audit durante la creazione di un nuovo cluster

Il codice seguente crea il cluster sample-cluster e abilita CloudWatch i log di controllo.

Esempio

Per Linux, macOS o 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

Per 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

Per abilitare i log di audit durante la modifica di un cluster esistente

Il codice seguente modifica il cluster sample-cluster e abilita i log di CloudWatch controllo.

Esempio

Per Linux, macOS o Unix:

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

Per Windows:

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

L'aspetto dell'output di queste operazioni è simile al seguente (formato JSON).

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

Disattivazione del controllo

È possibile disattivare il controllo disattivando l'esportazione dei CloudWatch log e disabilitando il parametro. audit_logs

Disattivazione dell'esportazione dei log CloudWatch

È possibile disattivare l'esportazione dei log di controllo utilizzando il Console di gestione AWS o il. AWS CLI

Using the Console di gestione AWS

La seguente procedura utilizza la disattivazione dell' Console di gestione AWS esportazione dei log in Amazon DocumentDB. CloudWatch

Per disabilitare i log di audit

1. Accedi a e apri Console di gestione AWS la console Amazon DocumentDB all'indirizzo. https://console.aws.amazon.com/docdb

2. Nel pannello di navigazione scegliere Cluster. Quindi, scegliere il pulsante a sinistra del nome del cluster per il quale si desidera disabilitare l'esportazione dei log.

3. Scegli Actions (Operazioni), quindi Modify (Modifica).

4. Scorrere verso il basso fino alla sezione Log exports (Esportazioni log) e scegliere Disabled (Disabilitato).

5. Scegli Continua.

6. Esaminare le modifiche, quindi scegliere quando applicare la modifica al cluster.

   • Apply during the next scheduled maintenance window (Applica durante la prossima finestra di manutenzione pianificata)

   • Apply immediately (Applica immediatamente)

7. Scegliere Modify cluster (Modifica cluster).

Using the AWS CLI

Il codice seguente modifica il cluster sample-cluster e disabilita CloudWatch i log di controllo.

Esempio

Per Linux, macOS o Unix:

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

Per Windows:

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

L'aspetto dell'output di questa operazione è simile al seguente (formato JSON).

{
    "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"
            }
        ]
    }
}

Disattivazione del parametro audit_logs

Per disabilitare il parametro audit_logs per il cluster, puoi modificarlo in modo che venga utilizzato un gruppo di parametri in cui il parametro audit_logs ha il valore disabled. In alternativa, puoi modificare il valore del parametro audit_logs nel gruppo di parametri del cluster in modo che sia disabled.

Per ulteriori informazioni, consulta i seguenti argomenti:

Accesso ai tuoi eventi di controllo

Utilizza i seguenti passaggi per accedere ai tuoi eventi di audit su Amazon CloudWatch.

Filtraggio degli eventi di controllo DML

Guida introduttiva al filtro di controllo DML

Gli eventi di controllo DML possono essere filtrati prima di essere scritti su Amazon. CloudWatch Per utilizzare questa funzionalità, è necessario abilitare il registro di controllo e il registro DML. Amazon DocumentDB supporta il filtraggio suatype,, ecommand. user namespace auditAuthorizationSuccess

È possibile abilitare il filtro di controllo in qualsiasi momento specificando il filtro di controllo utilizzando i parametrisetAuditConfig,filter, e auditAuthorizationSuccess nell'operazione: db.adminCommand( { command } )

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

È inoltre possibile recuperare le impostazioni del filtro di controllo eseguendo il comando seguente:

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

Requisiti di sicurezza

Solo il database users/roles con un'azione privilegiata auditConfigure può eseguire i comandi precedenti admindb quando si impostano o si elencano i filtri di controllo DML. È possibile utilizzare uno dei ruoli predefiniti di [clusterAdmin,hostManager,root] o creare ruoli personalizzati con auditConfigure privilegi. Di seguito è riportato un esempio di utilizzo di ruoli esistenti con il auditConfigure privilegio e un esempio con ruoli personalizzati.

Utente con ruolo integrato:

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

Utente con ruoli personalizzati:

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

Filtraggio dei casi d'uso

Esempio: filtraggio degli eventi in base ai comandi

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

Esempio: filtraggio degli eventi in base al nome utente

In questo esempio, verrà registrato solo l'utente «myUser»:

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

Esempio: filtraggio per atype

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

Esempio: filtraggio utilizzando più filtri uniti da operatori

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})

Esempio: filtraggio per eventi per auditAuthorizationSuccess

In questo filtro, tutti i comandi che hanno superato con successo l'autorizzazione non verranno registrati:

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

Esempio: filtraggio con e condizioni $in $nin

Quando si utilizza $in sia in che$nin, il comando non verrà registrato poiché tra le condizioni sarà presente un «e» implicito. In questo esempio, regex bloccherà il find comando in modo che non venga registrato nulla:

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})

Esempio: filtraggio per namespace

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

Esempio: ripristino del filtro predefinito

Il ripristino del valore predefinito significa che ogni evento di controllo DML verrà registrato. Per ripristinare il filtro al valore predefinito, eseguite il comando seguente:

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