Como auditar operações do plano de controlo do Azure Cosmos DB

APLICA-SE A: NoSQL MongoDB Cassandra Gremlin Tabela

O Plano de Controlo no Azure Cosmos DB é um serviço RESTful que lhe permite efetuar um conjunto diversificado de operações na conta do Azure Cosmos DB. Expõe um modelo de recursos públicos (por exemplo: base de dados, conta) e várias operações aos utilizadores finais para realizar ações no modelo de recursos. As operações do plano de controlo incluem alterações à conta ou contentor do Azure Cosmos DB. Por exemplo, operações como criar uma conta do Azure Cosmos DB, adicionar uma região, atualizar débito, ativação pós-falha da região, adicionar uma VNet, etc. são algumas das operações do plano de controlo. Este artigo explica como auditar as operações do plano de controlo no Azure Cosmos DB. Pode executar as operações do plano de controlo em contas do Azure Cosmos DB com a CLI do Azure, o PowerShell ou o portal do Azure, ao passo que, para contentores, utilize a CLI do Azure ou o PowerShell.

Seguem-se alguns cenários de exemplo em que as operações do plano de controlo de auditoria são úteis:

  • Quer receber um alerta quando as regras de firewall da sua conta do Azure Cosmos DB forem modificadas. O alerta é necessário para encontrar modificações não autorizadas a regras que regem a segurança de rede da sua conta do Azure Cosmos DB e tomar medidas rápidas.

  • Quer receber um alerta se uma nova região for adicionada ou removida da sua conta do Azure Cosmos DB. Adicionar ou remover regiões tem implicações nos requisitos de faturação e soberania de dados. Este alerta irá ajudá-lo a detetar uma adição ou remoção acidental da região na sua conta.

  • Quer obter mais detalhes dos registos de diagnóstico sobre o que mudou. Por exemplo, uma VNet foi alterada.

Desativar o acesso de escrita de metadados baseados em chaves

Antes de auditar as operações do plano de controlo no Azure Cosmos DB, desative o acesso de escrita de metadados baseados em chaves na sua conta. Quando o acesso de escrita de metadados baseados em chaves está desativado, os clientes que se ligam à conta do Azure Cosmos DB através de chaves de conta são impedidos de aceder à conta. Pode desativar o acesso de escrita ao definir a disableKeyBasedMetadataWriteAccess propriedade como verdadeira. Depois de definir esta propriedade, as alterações a qualquer recurso podem ocorrer a partir de um utilizador com a função e credenciais do Azure adequadas. Para saber mais sobre como definir esta propriedade, veja o artigo Impedir alterações dos SDKs .

disableKeyBasedMetadataWriteAccess Depois de ativado, se os clientes baseados no SDK executarem operações de criação ou atualização, é devolvido um erro "Operação "POST" no recurso "ContainerNameorDatabaseName" através do ponto final do Azure Cosmos DB. Tem de ativar o acesso a essas operações para a sua conta ou executar as operações de criação/atualização através do Azure Resource Manager, da CLI do Azure ou Azure PowerShell. Para voltar atrás, defina disableKeyBasedMetadataWriteAccess como falso com a CLI do Azure, conforme descrito no artigo Impedir alterações do SDK do Azure Cosmos DB . Certifique-se de que altera o valor de disableKeyBasedMetadataWriteAccess para falso em vez de verdadeiro.

Considere os seguintes pontos ao desativar o acesso de escrita de metadados:

  • Avalie e certifique-se de que as suas aplicações não efetuam chamadas de metadados que alterem os recursos acima (por exemplo, criar coleção, atualizar débito, ...) com o SDK ou chaves de conta.

  • Quando disableKeyBasedMetadataWriteAccess está definido como verdadeiro, as operações de metadados emitidas pelo SDK são bloqueadas. Em alternativa, pode utilizar implementações de modelos portal do Azure, da CLI do Azure, do Azure PowerShell ou do Azure Resource Manager para efetuar estas operações.

Ativar registos de diagnóstico para operações do plano de controlo

Pode ativar os registos de diagnóstico para operações do plano de controlo com o portal do Azure. Após a ativação, os registos de diagnóstico irão registar a operação como um par de eventos de início e conclusão com detalhes relevantes. Por exemplo, RegionFailoverStart e RegionFailoverComplete concluirão o evento de ativação pós-falha da região.

Utilize os seguintes passos para ativar o registo nas operações do plano de controlo:

  1. Inicie sessão no portal do Azure e navegue para a sua conta do Azure Cosmos DB.

  2. Abra o painel Definições de diagnóstico e forneça um Nome para os registos criarem.

  3. Selecione ControlPlaneRequests para o tipo de registo e selecione a opção Enviar para o Log Analytics.

  4. Opcionalmente, envie os registos de diagnóstico para o Armazenamento do Azure, Hubs de Eventos do Azure, o Azure Monitor ou um terceiro.

Também pode armazenar os registos numa conta de armazenamento ou transmitir em fluxo para um hub de eventos. Este artigo mostra como enviar registos para a análise de registos e, em seguida, como os consultar. Depois de ativar, os registos de diagnóstico demoram alguns minutos a entrar em vigor. Todas as operações do plano de controlo executadas após esse ponto podem ser controladas. A seguinte captura de ecrã mostra como ativar os registos do plano de controlo:

Ativar o registo de pedidos do plano de controlo

Ver as operações do plano de controlo

Depois de ativar o registo, utilize os seguintes passos para monitorizar as operações de uma conta específica:

  1. Inicie sessão no portal do Azure.

  2. Abra o separador Monitor no painel de navegação esquerdo e, em seguida, selecione o painel Registos . Abre uma IU onde pode executar facilmente consultas com essa conta específica no âmbito. Execute a seguinte consulta para ver os registos do plano de controlo:

    AzureDiagnostics
    | where ResourceProvider=="MICROSOFT.DOCUMENTDB" and Category=="ControlPlaneRequests"
    | where TimeGenerated >= ago(1h)
    

    As capturas de ecrã seguintes capturam registos quando um nível de consistência é alterado para uma conta do Azure Cosmos DB. O activityId_g valor dos resultados é diferente do ID de atividade de uma operação:

    Controlar registos do plano quando é adicionada uma VNet

    As capturas de ecrã seguintes capturam registos quando o espaço de chaves ou uma tabela de uma conta do Cassandra são criados e quando o débito é atualizado. Os registos do plano de controlo para operações de criação e atualização na base de dados e no contentor são registados separadamente, conforme mostrado na seguinte captura de ecrã:

    Controlar os registos do plano quando o débito é atualizado

Identificar a identidade associada a uma operação específica

Se quiser depurar ainda mais, pode identificar uma operação específica no Registo de atividades através do activityId_g ou pelo carimbo de data/hora da operação. O carimbo de data/hora é utilizado para alguns clientes Resource Manager em que o ID da atividade não é explicitamente transmitido. O Registo de atividades fornece detalhes sobre a identidade com a qual a operação foi iniciada. A seguinte captura de ecrã mostra como utilizar o activityId_g para localizar as operações associadas ao mesmo no Registo de atividades:

Utilizar o ID da atividade e encontrar as operações

Operações do plano de controlo para a conta do Azure Cosmos DB

Seguem-se as operações do plano de controlo disponíveis ao nível da conta. A maioria das operações é controlada ao nível da conta. Estas operações estão disponíveis como métricas no Azure Monitor:

  • Região adicionada
  • Região removida
  • Conta eliminada
  • A região efetuou a ativação pós-falha
  • Conta criada
  • Rede virtual eliminada
  • Definições de rede da conta atualizadas
  • Definições de replicação de conta atualizadas
  • Chaves de conta atualizadas
  • Definições de cópia de segurança da conta atualizadas
  • Definições de diagnóstico da conta atualizadas

Controlar operações do plano para bases de dados ou contentores

Seguem-se as operações do plano de controlo disponíveis ao nível da base de dados e do contentor. Estas operações estão disponíveis como métricas no Azure Monitor:

  • Base de Dados SQL Criado
  • Base de Dados SQL Atualizado
  • Débito Base de Dados SQL Atualizado
  • Base de Dados SQL Eliminado
  • Contentor do SQL Criado
  • Contentor do SQL Atualizado
  • Débito de Contentor SQL Atualizado
  • Contentor do SQL Eliminado
  • Cassandra Keyspace Criado
  • Keyspace do Cassandra Atualizado
  • Débito do Keyspace do Cassandra Atualizado
  • Keyspace do Cassandra Eliminado
  • Tabela do Cassandra Criada
  • Tabela do Cassandra Atualizada
  • Débito de Tabela do Cassandra Atualizado
  • Tabela do Cassandra Eliminada
  • Base de Dados do Gremlin Criada
  • Base de Dados do Gremlin Atualizada
  • Débito da Base de Dados do Gremlin Atualizado
  • Base de Dados do Gremlin Eliminada
  • Gremlin Graph Criado
  • Gremlin Graph Atualizado
  • Débito do Gremlin Graph Atualizado
  • Gremlin Graph Eliminado
  • Base de Dados do Mongo Criada
  • Base de Dados do Mongo Atualizada
  • Débito da Base de Dados do Mongo Atualizado
  • Base de Dados do Mongo Eliminada
  • Coleção Mongo Criada
  • Coleção do Mongo Atualizada
  • Débito da Coleção do Mongo Atualizado
  • Coleção do Mongo Eliminada
  • Tabela AzureTable Criada
  • Tabela AzureTable Atualizada
  • Débito de Tabela do AzureTable Atualizado
  • Tabela AzureTable Eliminada

Operações de registo de diagnóstico

Seguem-se os nomes das operações nos registos de diagnóstico para diferentes operações:

  • RegionAddStart, RegionAddComplete
  • RegionRemoveStart, RegionRemoveComplete
  • AccountDeleteStart, AccountDeleteComplete
  • RegionFailoverStart, RegionFailoverComplete
  • AccountCreateStart, AccountCreateComplete
  • AccountUpdateStart, AccountUpdateComplete
  • VirtualNetworkDeleteStart, VirtualNetworkDeleteComplete
  • DiagnosticLogUpdateStart, DiagnosticLogUpdateComplete

Para operações específicas da API, o nome da operação tem o seguinte formato:

  • ApiKind + ApiKindResourceType + OperationType
  • ApiKind + ApiKindResourceType + "Débito" + operationType

Exemplo

  • CassandraKeyspacesCriar
  • CassandraKeyspacesUpdate
  • CassandraKeyspacesThroughputUpdate
  • SqlContainersUpdate

A propriedade ResourceDetails contém todo o corpo do recurso como um payload de pedido e contém todas as propriedades pedidas para atualizar

Consultas de registo de diagnóstico para operações do plano de controlo

Seguem-se alguns exemplos para obter registos de diagnóstico para operações do plano de controlo:

AzureDiagnostics 
| where Category startswith "ControlPlane"
| where OperationName contains "Update"
| project httpstatusCode_s, statusCode_s, OperationName, resourceDetails_s, activityId_g
AzureDiagnostics 
| where Category =="ControlPlaneRequests"
| where TimeGenerated >= todatetime('2020-05-14T17:37:09.563Z')
| project TimeGenerated, OperationName, apiKind_s, apiKindResourceType_s, operationType_s, resourceDetails_s
AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName startswith "SqlContainersUpdate"
AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName startswith "SqlContainersThroughputUpdate"

Consulte para obter o activityId e o autor da chamada que iniciou a operação de eliminação do contentor:

(AzureDiagnostics
| where Category == "ControlPlaneRequests"
| where OperationName == "SqlContainersDelete"
| where TimeGenerated >= todatetime('9/3/2020, 5:30:29.300 PM')
| summarize by activityId_g )
| join (
AzureActivity
| parse HTTPRequest with * "clientRequestId\": \"" activityId_g "\"" * 
| summarize by Caller, HTTPRequest, activityId_g)
on activityId_g
| project Caller, activityId_g

Consulte para obter atualizações de índice ou ttl. Em seguida, pode comparar o resultado desta consulta com uma atualização anterior para ver a alteração no índice ou ttl.

AzureDiagnostics
| where Category =="ControlPlaneRequests"
| where  OperationName == "SqlContainersUpdate"
| project resourceDetails_s

saída:

{id:skewed,indexingPolicy:{automatic:true,indexingMode:consistent,includedPaths:[{path:/*,indexes:[]}],excludedPaths:[{path:/_etag/?}],compositeIndexes:[],spatialIndexes:[]},partitionKey:{paths:[/pk],kind:Hash},defaultTtl:1000000,uniqueKeyPolicy:{uniqueKeys:[]},conflictResolutionPolicy:{mode:LastWriterWins,conflictResolutionPath:/_ts,conflictResolutionProcedure:}

Passos seguintes