Auditoría de eventos de Amazon DocumentDB

Con Amazon DocumentDB (con compatibilidad con MongoDB), puede auditar eventos que se realizaron en su clúster. Los intentos de autenticación correctos e incorrectos, la eliminación de una colección en una base de datos o la creación de un índice son algunos ejemplos de eventos registrados. De forma predeterminada, la auditoría está deshabilitada en Amazon DocumentDB y, para utilizar esta característica, es necesario suscribirse.

Cuando la auditoría está habilitada, Amazon DocumentDB registra los eventos del lenguaje de definición de datos (DDL), de manipulación (DML), de autenticación, de autorización y de administración de usuarios en Registros de Amazon CloudWatch. Cuando la auditoría está habilitada, Amazon DocumentDB exporta los registros de auditoría del clúster (documentos JSON) a Registros de Amazon CloudWatch. Puede utilizar Registros de Amazon CloudWatch para analizar, monitorizar y archivar sus eventos de auditoría de Amazon DocumentDB.

Aunque Amazon DocumentDB no cobra una tarifa adicional por habilitar la auditoría, se le cobrarán las tarifas estándar por el uso de los registros de CloudWatch. Para obtener más información sobre los precios de CloudWatch Logs, consulte Precios de Amazon CloudWatch.

La característica de auditoría de Amazon DocumentDB es claramente diferente del uso de los recursos de servicio que se monitorea con AWS CloudTrail. CloudTrail registra las operaciones que se realizan con la AWS Command Line Interface (AWS CLI) o la AWS Management Console en recursos como clústeres, instancias, grupos de parámetros e instantáneas. La auditoría de recursos de con CloudTrail está activada de forma predeterminada y no se puede deshabilitar. La característica de auditoría de Amazon DocumentDB es opcional. Registra las operaciones que tienen lugar dentro del clúster en los distintos objetos, como, por ejemplo, bases de datos, colecciones, índices y usuarios.

Eventos admitidos

La auditoría de Amazon DocumentDB admite las siguientes categorías de eventos:

Los tipos de eventos son los siguientes.

Habilitación de auditorías

Para habilitar la auditoría en un clúster, hay que seguir un proceso de dos pasos. Asegúrese de que se realizan ambos pasos, o los registros de auditoría no se enviarán a los registros de CloudWatch.

Paso 1. Habilitación del parámetro de clúster audit_logs

Para habilitar la auditoría, debe modificar el parámetro audit_logs en el grupo de parámetros. audit_logs es una lista delimitada por comas de los eventos que se deben registrar. Los eventos se deben especificar en minúsculas y no debe haber espacios en blanco entre los elementos de la lista.

Puede especificar los siguientes valores para el grupo de parámetro:

También puede utilizar los valores mencionados anteriormente en combinaciones.

Para más información, consulte los siguientes temas:

Paso 2. Habilitación de la exportación de registros de Amazon CloudWatch

Cuando el valor del parámetro de clúster audit_logs sea enabled, ddl, dml_read, o dml_write, también debe permitir que Amazon DocumentDB exporte los registros a Amazon CloudWatch. Si omite cualquiera de estos pasos, los registros de auditoría no se enviarán a CloudWatch.

Al crear un clúster, realizar una restauración a un momento dado o restaurar una instantánea, puede habilitar los registros de CloudWatch siguiendo estos pasos.

Using the AWS Management Console

Para habilitar la exportación de registros de Amazon DocumentDB a la consola de CloudWatch, consulte los temas siguientes:

• Al crear un clúster: en Creación de un clúster y una instancia principal mediante la AWS Management Console, consulte Creación de un clúster: configuraciones adicionales (paso 5, Exportaciones de registros)

• Al modificar un clúster existente — Modificación de un clúster de Amazon DocumentDB

• Al realizar una restauración de una instantánea de un clúster — Restauración de una instantánea del clúster

• Cuando se realiza una restauración a un momento dado — Restauración a un momento dado

Using the AWS CLI

Para habilitar los registros de auditoría al crear un nuevo clúster

El siguiente código crea el clúster sample-cluster y permite registros de auditoría de CloudWatch.

Para 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

Para 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

Para habilitar los registros de auditoría al modificar un clúster existente

El siguiente código modifica el clúster sample-cluster y permite registros de auditoría de CloudWatch.

Para Linux, macOS o Unix:

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

Para Windows:

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

El resultado de estas operaciones será similar al que se indica a continuación (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"
    }
}

Deshabilitación de auditorías

Puede deshabilitar la auditoría deshabilitando la exportación de registros de CloudWatch y deshabilitando el parámetro audit_logs.

Deshabilitación de la exportación de registros de CloudWatch

Puede deshabilitar la exportación de registros de auditoría mediante la AWS Management Console o la AWS CLI.

Using the AWS Management Console

El siguiente procedimiento utiliza la AWS Management Console para deshabilitar la exportación de registros de Amazon DocumentDB a CloudWatch.

Para deshabilitar los registros de auditoría

1. Inicie sesión en la AWS Management Console y abra la consola de Amazon DocumentDB en https://console.aws.amazon.com/docdb.

2. En el panel de navegación, seleccione Clusters (Clústeres). A continuación, elija el botón situado a la izquierda del nombre del clúster para el que desea deshabilitar la exportación de registros.

3. Elija Actions (Acciones) y después Modify (Modificar).

4. Desplácese hacia abajo hasta la sección Log exports (Exportaciones de registros) y, a continuación, elija Disabled (Deshabilitado).

5. Elija Continuar.

6. Revise los cambios y, a continuación, elija cuándo desea que se aplique este cambio en su clúster.

   • Apply during the next scheduled maintenance window (Aplicar durante el siguiente periodo de mantenimiento programado)

   • Apply immediately (Aplicar inmediatamente)

7. Elija Modify clúster (Modificar clúster).

Using the AWS CLI

El siguiente código modifica el clúster sample-cluster y deshabilita los registros de auditoría de CloudWatch.

Para Linux, macOS o Unix:

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

Para Windows:

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

La salida de esta operación será similar a lo que se indica a continuación (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"
            }
        ]
    }
}

Deshabilitación del parámetro audit_logs

Para deshabilitar el parámetro audit_logs del clúster, puede modificar el clúster para que utilice un grupo de parámetros donde el valor del parámetro audit_logs esté disabled. O bien, puede modificar el valor del parámetro audit_logs en el grupo de parámetros del clúster para que esté disabled.

Para obtener más información, consulte los temas siguientes:

Acceso a los eventos de auditoría

Siga estos pasos para obtener acceso a los eventos de auditoría en Amazon CloudWatch.

Filtrado de eventos de auditoría de DML

Introducción al filtrado de auditoría de DML

Los eventos de auditoría de DML se pueden filtrar antes de escribirlos en Amazon CloudWatch. Para utilizar esta característica, el registro de auditoría y el registro de DML deben estar habilitados. Amazon DocumentDB admite el filtrado en atype, command, user, namespace y auditAuthorizationSuccess.

Para habilitar el filtrado de auditoría en cualquier momento, especifique el filtro de auditoría mediante los parámetros setAuditConfig, filter y auditAuthorizationSuccess de la operación db.adminCommand( { command } ):

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

También puede recuperar la configuración del filtro de auditoría mediante la ejecución del siguiente comando:

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

Requisitos de seguridad

Solo los usuarios o roles de la base de datos con la acción privilegiada auditConfigure pueden ejecutar los comandos anteriores en admindb al configurar o enumerar los filtros de auditoría de DML. Puede utilizar uno de los roles integrados de [clusterAdmin, hostManager, root] o crear roles personalizados con privilegios de auditConfigure. A continuación, se muestra un ejemplo del uso de los roles existentes con el privilegio de auditConfigure y un ejemplo con los roles personalizados.

Usuario con rol integrado:

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

Usuario con roles personalizados:

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

Filtrado de casos de uso

Ejemplo: filtrado de eventos por comandos

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

Ejemplo: filtrado de eventos por nombre de usuario

En este ejemplo, solo se registrará el usuario “myUser”:

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

Ejemplo: filtrado mediante atype

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

Ejemplo: filtrado mediante varios filtros unidos por operadores

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

Ejemplo: filtrado mediante eventos por auditAuthorizationSuccess

En este filtro, no se registrarán todos los comandos que hayan pasado la autorización correctamente:

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

Ejemplo: filtrado con condiciones $in y $nin

Si se utiliza $in y $nin, el comando no se registrará, ya que habrá un “y” implícito entre las condiciones. En este ejemplo, regex bloqueará el comando find para que no se registre nada:

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

Ejemplo: filtrado mediante namespace

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

Ejemplo: restablecimiento del filtro predeterminado

Si se restablece el valor predeterminado, se registrarán todos los eventos de auditoría de DML. Para restablecer el filtrado al valor predeterminado, ejecute el siguiente comando:

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