Gerenciamento de resumo

  • Artigo

Aplica-se a: SQL Server 2022 (16.x) Banco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

Resumos de banco de dados

O hash do bloco mais recente no razão do banco de dados é chamado de resumo de banco de dados. Ele representa o estado de todas as tabelas razão no banco de dados quando o bloco foi gerado. A geração do resumo de banco de dados é eficiente, pois envolve apenas a computação somente dos hashes dos blocos que foram anexados recentemente.

Os resumos de banco de dados podem ser gerados automaticamente pelo sistema ou manualmente pelo usuário. Você pode usá-los posteriormente para verificar a integridade do banco de dados.

Os resumos de banco de dados são gerados na forma de um documento JSON que contém o hash do bloco mais recente, junto com os metadados relacionados à ID do bloco. Os metadados incluem a hora em que o resumo foi gerado e o carimbo de data/hora de confirmação da última transação neste bloco.

O processo de verificação e a integridade do banco de dados dependem da integridade dos resumos de entrada. Para essa finalidade, os resumos extraídos do banco de dados precisam ser armazenados de maneira confiável e de modo que os usuários com privilégios elevados ou os invasores do banco de dados não possam adulterar.

Geração e armazenamento automáticos de resumos de banco de dados

Observação

A geração e o armazenamento automáticos de resumos de banco de dados no SQL Server dão suporte apenas a contas de Armazenamento do Azure.

O razão se integra ao recurso de armazenamento imutável do Armazenamento de Blobs do Azure e do Razão Confidencial do Azure. Essa integração fornece serviços de armazenamento seguros no Azure para ajudar a proteger os resumos do banco de dados contra possíveis adulterações. Essa integração fornece uma maneira simples e econômica para os usuários automatizarem o gerenciamento de resumos sem precisar se preocupar com sua disponibilidade e replicação geográfica. O Razão Confidencial do Azure tem uma garantia de integridade mais forte para clientes que podem estar preocupados com o acesso de administradores privilegiados ao resumo. Esta tabela compara o recurso de armazenamento imutável de Armazenamento de Blobs do Azure com o Razão Confidencial do Azure.

Você pode configurar a geração e do armazenamento automáticos de resumos do banco de dados por meio do portal do Azure, do PowerShell ou da CLI do Azure. Para obter mais informações, confira Habilitar o armazenamento de resumo automático. Quando você configura a geração e o armazenamento automáticos, resumos de banco de dados são gerados em um intervalo predefinido de 30 segundos e carregados no serviço de armazenamento selecionado. Caso não ocorra nenhuma transação no intervalo de 30 segundos, o resumo de banco de dados não será gerado e carregado. Esse mecanismo garante que os resumos de banco de dados sejam gerados somente quando os dados tiverem sido atualizados no banco de dados. Quando o ponto de extremidade é um Armazenamento de Blobs do Azure, o servidor lógico do Banco de Dados SQL do Azure ou da Instância Gerenciada SQL do Azure cria um novo contêiner, chamado sqldbledgerdigests e usa um padrão de nomenclatura como: ServerName/DatabaseName/CreationTime. A hora de criação é necessária porque um banco de dados com o mesmo nome pode ser descartado e recriado ou restaurado, permitindo diferentes encarnações do banco de dados com o mesmo nome. Para obter mais informações, confira Considerações de Gerenciamento de Hashes.

Observação

Para o SQL Server, o contêiner precisa ser criado manualmente pelo usuário.

Política de Imutabilidade da Conta de Armazenamento do Azure

Caso use uma conta de Armazenamento do Azure para o armazenamento de hashes de banco de dados, configure uma política de imutabilidade no contêiner após o provisionamento para garantir que os hashes do banco de dados sejam protegidos contra adulterações. Verifique se a política de imutabilidade permite gravações de acréscimo protegido em blobs de acréscimo e se a política está bloqueada.

Permissão da conta de Armazenamento do Azure

Se você usar o Banco de Dados SQL do Azure ou a Instância Gerenciada de SQL do Azure, verifique se o servidor lógico ou a instância gerenciada (Identidade do Sistema) tem permissões de RBAC (controle de acesso baseado em função) suficientes para gravar resumos adicionando-o à função Colaborador de Dados do Blob de Armazenamento. Caso você use grupos de replicação geográfica ativa ou de failover automático, verifique se as réplicas secundárias têm a mesma permissão de RBAC na conta de Armazenamento do Azure.

Se você usar o SQL Server, precisará criar uma assinatura de acesso compartilhado (SAS) no contêiner de resumo para permitir que o SQL Server se conecte e se autentique na conta de Armazenamento do Azure.

  • Crie um contêiner na conta de Armazenamento do Azure, chamado sqldbledgerdigests.
  • Crie uma política em um contêiner com as permissões Ler, Adicionar, Criar, Gravar e Listar e gere uma chave de assinatura de acesso compartilhado.
  • Para cada contêiner sqldbledgerdigests usado para hash de armazenamento de arquivos, crie uma Credencial do SQL Server cujo nome corresponda ao caminho do contêiner.

O exemplo a seguir pressupõe que foram criados um contêiner de Armazenamento do Azure, uma política e uma chave SAS. Isso é necessário para o SQL Server acessar os arquivos de resumo no contêiner.

No snippet de código a seguir, substitua <your SAS key> pela chave SAS. A chave SAS será parecida com 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.

CREATE CREDENTIAL [https://ledgerstorage.blob.core.windows.net/sqldbledgerdigests]  
WITH IDENTITY='SHARED ACCESS SIGNATURE',  
SECRET = '<your SAS key>'

Permissão de Razão Confidencial do Azure

Se você usar o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure, verifique se o servidor lógico ou a instância gerenciada (Identidade do Sistema) tem permissões suficientes para gravar resumos adicionando-o à função de Colaborador. Para fazer isso, siga as etapas para o gerenciamento de usuários do Razão Confidencial do Azure.

Observação

A geração e o armazenamento automáticos de resumos de banco de dados no SQL Server dão suporte apenas a contas de Armazenamento do Azure.

Configurar regras de NSG de Instância Gerenciada de SQL do Azure para funcionar com o Razão Confidencial do Azure

Se usar a Instância Gerenciada de SQL do Azure, não se esqueça de configurar as regras da rede virtual da Instância Gerenciada de SQL do Azure para viabilizar a comunicação com o Razão Confidencial do Azure. Para obter mais informações, consulte Configurar regras de NSG de Instância Gerenciada de SQL do Azure para funcionar com o Razão Confidencial do Azure.

Geração e armazenamento manuais de resumos de banco de dados

Você também pode gerar um resumo do banco de dados sob demanda para armazenar manualmente o resumo em qualquer serviço ou dispositivo que considere um destino de armazenamento confiável. Por exemplo, você pode escolher um dispositivo WORM (grava uma vez, lê muitas) local como destino. A geração manual de um resumo do banco de dados é feita executando do procedimento armazenado sys.sp_generate_database_ledger_digest no SQL Server Management Studio ou Azure Data Studio.

EXECUTE sp_generate_database_ledger_digest;

O conjunto de resultados retornado é uma única linha de dados. Ele deve ser salvo no local de armazenamento confiável como um documento JSON da seguinte forma:

    {
        "database_name":  "ledgerdb",
        "block_id":  0,
        "hash":  "0xDC160697D823C51377F97020796486A59047EBDBF77C3E8F94EEE0FFF7B38A6A",
        "last_transaction_commit_time":  "2020-11-12T18:01:56.6200000",
        "digest_time":  "2020-11-12T18:39:27.7385724"
    }

Permissões

A geração de resumos de banco de dados requer a permissão GENERATE LEDGER DIGEST. Para obter detalhes sobre as permissões relacionadas às tabelas do razão, confira Permissões.

Considerações do gerenciamento de resumos

Restauração do banco de dados

A restauração de um banco de dados para um ponto anterior no tempo, também conhecida como Restauração Pontual, é uma operação frequentemente usada quando ocorre um erro e os usuários precisam reverter rapidamente o estado do banco de dados para um ponto anterior no tempo. Ao carregar os resumos gerados no Armazenamento do Azure ou no Razão Confidencial do Azure, a hora de criação do banco de dados é capturada para a qual esses resumos são mapeados. Toda vez que o banco de dados é restaurado, ele é marcado com uma nova hora de criação. Essa técnica nos permite armazenar os resumos em diferentes "encarnações" do banco de dados. Para o SQL Server, a hora de criação é a hora UTC atual quando o carregamento de resumo é habilitado pela primeira vez. O razão preserva as informações sobre quando ocorreu uma operação de restauração, permitindo que o processo de verificação use todos os resumos relevantes nas várias encarnações do banco de dados. Além disso, os usuários podem inspecionar todos os resumos para diferentes horas de criação para identificar quando o banco de dados foi restaurado e até que ponto ele foi restaurado. Como esses dados são gravados no armazenamento imutável, essas informações também ficarão protegidas.

Observação

Se você executar uma restauração nativa de um backup de banco de dados na Instância Gerenciada de SQL do Azure, precisará alterar o caminho do resumo manualmente usando o Portal do Azure, o PowerShell ou a CLI do Azure.

Replicação geográfica ativa e Grupos de Disponibilidade Always On

A replicação geográfica ativa ou os grupos de failover automático podem ser configurados para o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure. A replicação entre regiões geográficas é assíncrona por motivos de desempenho e, portanto, permite que o banco de dados secundário fique um pouco atrasado em comparação com o primário. No caso de um failover geográfico, todos os dados mais recentes que ainda não foram replicados serão perdidos. O razão só emitirá resumos de banco de dados para dados que foram replicados para bancos de dados secundários geográficos para garantir que os resumos nunca façam referência a dados que possam ser perdidos em caso de um failover geográfico. Isso só se aplica à geração automática e ao armazenamento de resumos de banco de dados. Em um grupo de failover, o banco de dados primário e secundário terá o mesmo caminho de resumo. Mesmo quando você executa um failover, o caminho de resumo não é alterado para o banco de dados primário e secundário.

Se o grupo de failover for excluído ou você descartar o link, ambos os bancos de dados se comportarão como bancos de dados primários. Nesse ponto, o caminho de resumo do banco de dados secundário anterior será alterado e adicionaremos uma pasta RemovedSecondaryReplica ao caminho.

Quando o banco de dados faz parte de um grupo de disponibilidade Always On ou um vínculo de instância gerenciada no SQL Server, o mesmo princípio da replicação geográfica ativa é usado. O carregamento dos hashes só será feito se todas as transações tiverem sido replicadas para as réplicas secundárias.

Conteúdo relacionado