As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Auditar eventos do Amazon DocumentDB

Com o Amazon DocumentDB (compatível com MongoDB), é possível auditar eventos que foram realizados em seu cluster. Exemplos de eventos registrados incluem tentativas de autenticação bem-sucedidas e com falha, eliminação de uma coleção em um banco de dados ou criação de um índice. Por padrão, a auditoria fica desabilitada no Amazon DocumentDB e requer que você opte por esse atributo.

Quando a auditoria está habilitada, o Amazon DocumentDB registra eventos de Data Definition Language DDL (), Data Manipulation Language DML (), autenticação, autorização e gerenciamento de usuários no Amazon Logs. CloudWatch Quando a auditoria está habilitada, o Amazon DocumentDB exporta os registros de auditoria JSON (documentos) do seu cluster para o Amazon Logs. CloudWatch Você pode usar o Amazon CloudWatch Logs para analisar, monitorar e arquivar seus eventos de auditoria do Amazon DocumentDB.

Embora o Amazon DocumentDB não cobre um custo adicional para permitir a auditoria, são cobradas taxas padrão pelo uso de registros. CloudWatch Para obter informações sobre CloudWatch os preços do Logs, consulte os CloudWatch preços da Amazon.

O recurso de auditoria do Amazon DocumentDB é nitidamente diferente do uso de recursos de serviço que é monitorado com. AWS CloudTrail CloudTrail registra operações que são realizadas com o AWS Command Line Interface (AWS CLI) ou AWS Management Console em recursos como clusters, instâncias, grupos de parâmetros e instantâneos. A auditoria de recursos com CloudTrail está ativada por padrão e não pode ser desativada. O atributo de auditoria do Amazon DocumentDB é um atributo opcional. Ele registra operações que ocorrem dentro do seu cluster em objetos, como bancos de dados, coleções, índices e usuários.

Eventos com suporte

A auditoria do Amazon DocumentDB oferece suporte às seguintes categorias de eventos:

Os tipos de evento são os seguintes.

Ativar a auditoria

A ativação da auditoria em um cluster é um processo de duas etapas. Verifique se as duas etapas foram concluídas ou os registros de auditoria não serão enviados para o CloudWatch Logs.

Etapa 1. Habilitar o parâmetro de cluster audit_logs

Para habilitar a auditoria, você precisa modificar o parâmetro audit_logs no grupo de parâmetros. audit_logs é uma lista de eventos delimitada por vírgulas, os quais serão registrados. Os eventos devem ser especificados em letras maiúsculas, e não pode haver espaço em branco entre os elementos da lista.

É possível especificar os seguintes valores para o grupo de parâmetros:

Você também pode usar os valores mencionados acima em combinações.

Para obter mais informações, consulte as informações a seguir:

Etapa 2. Ativar a exportação do Amazon CloudWatch Logs

Quando o valor do parâmetro do audit_logs cluster éenabled,,, ou ddl dml_readdml_write, você também deve habilitar o Amazon DocumentDB para exportar registros para a Amazon. CloudWatch Se você omitir qualquer uma dessas etapas, os registros de auditoria não serão enviados para CloudWatch.

Ao criar um cluster, executar um point-in-time-restore ou restaurar um snapshot, você pode ativar CloudWatch os registros seguindo estas etapas.

Using the AWS Management Console

Para permitir que o Amazon DocumentDB exporte logs para CloudWatch usar o console, consulte os seguintes tópicos:

• Ao criar um cluster : em Criação de um cluster e de uma instância primária usando o AWS Management Console, consulte Criar um cluster: configurações adicionais, (etapa 5, Exportações de log)

• Ao modificar um cluster existente — Modificar um cluster do Amazon DocumentDB

• Ao executar uma restauração de snapshot de cluster — Restauração de um snapshot de cluster

• Ao realizar uma point-in-time restauração — Restauração para um ponto no tempo

Using the AWS CLI

Como habilitar logs de auditoria ao criar um novo cluster

O código a seguir cria o cluster sample-cluster e ativa os registros CloudWatch de auditoria.

Para Linux, macOS ou 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

Como habilitar logs de auditoria ao modificar um cluster existente

O código a seguir modifica o cluster sample-cluster e ativa os registros CloudWatch de auditoria.

Para Linux, macOS ou 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"]}'

A saída dessas operações se parece com a seguinte (JSONformato).

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

Desativar a auditoria

Você pode desativar a auditoria desativando a exportação de CloudWatch registros e desativando o parâmetro. audit_logs

Desativando a exportação de CloudWatch registros

Você pode desativar a exportação de registros de auditoria usando o AWS Management Console ou o. AWS CLI

Using the AWS Management Console

O procedimento a seguir usa o AWS Management Console para desativar a exportação de registros do Amazon DocumentDB para o. CloudWatch

Como desabilitar logs de auditoria

1. Faça login no e abra AWS Management Console o console do Amazon DocumentDB em https://console.aws.amazon.com /docdb.

2. No painel de navegação, escolha Clusters. Depois disso, escolha o botão à esquerda do nome do cluster para o qual você deseja desabilitar a exportação de logs.

3. Escolha Ações e, em seguida, Modificar.

4. Role para baixo até a seção Exportações de log e escolha Desativado.

5. Escolha Continuar.

6. Analise as alterações e escolha quando você deseja que essa mudança seja aplicada ao seu cluster.

   • Aplicar durante a próxima janela de manutenção programada

   • Aplicar imediatamente

7. Escolha Modificar cluster.

Using the AWS CLI

O código a seguir modifica o cluster sample-cluster e desativa os registros de CloudWatch auditoria.

Para Linux, macOS ou 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"]}'

A saída dessa operação se parece com a seguinte (JSONformato).

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

Desativar o parâmetro audit_logs

Para desabilitar o parâmetro audit_logs para o cluster, é possível modificar o cluster para que ele use um grupo de parâmetros em que o valor do parâmetro audit_logs é disabled. Ou é possível modificar o valor do parâmetro audit_logs no grupo de parâmetros de cluster para que ele seja disabled.

Para obter mais informações, consulte os tópicos a seguir.

Acessar seus eventos de auditoria

Use as etapas a seguir para acessar seus eventos de auditoria na Amazon CloudWatch.

Filtrando eventos DML de auditoria

Introdução à filtragem DML de auditoria

DMLos eventos de auditoria podem ser filtrados antes de serem gravados na Amazon CloudWatch. Para utilizar esse recurso, o registro e DML o registro de auditoria devem estar habilitados. O Amazon DocumentDB oferece suporte à filtragem em atype, command, user, namespace e auditAuthorizationSuccess.

Você pode ativar a filtragem de auditoria a qualquer momento especificando o filtro de auditoria usando os parâmetros setAuditConfig, filter e auditAuthorizationSuccess na operação db.adminCommand( { command } ):

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

Você também pode recuperar as configurações do filtro de auditoria executando o seguinte comando:

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

Requisitos de segurança

Somente usuários/funções do banco de dados com ação privilegiada auditConfigure podem executar os comandos acima admindb ao definir ou listar DML filtros de auditoria. Você pode usar uma das funções integradas de [clusterAdmin, hostManager, root] ou criar funções personalizadas com privilégios auditConfigure. Veja a seguir um exemplo do uso de funções existentes com o privilégio auditConfigure e um exemplo com funções personalizadas.

Usuário com função integrada:

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

Usuário com funções personalizadas:

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

Filtrar casos de uso

Exemplo: filtrar eventos por comandos

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

Exemplo: filtrar eventos por nome de usuário

Neste exemplo, somente o usuário myUser "" será registrado:

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

Exemplo: filtrar por atype

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

Exemplo: filtrar usando vários 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})

Exemplo: filtragem por eventos por auditAuthorizationSuccess

Nesse filtro, todos os comandos aprovados com sucesso na autorização não serão registrados:

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

Exemplo: filtrar com as condições $in e $nin

Ao usar tanto em $in quanto em $nin, o comando não será registrado, pois haverá um “e” implícito entre as condições. Neste exemplo, a regex bloqueará o comando find para que nada seja registrado:

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

Exemplo: filtrar por namespace

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

Exemplo: redefinir para o filtro padrão

A redefinição para o valor padrão significa que cada evento de DML auditoria será registrado. Para redefinir a filtragem para o valor padrão, execute o comando a seguir:

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