Gestão de resumos
se aplica a:
SQL Server 2022 (16.x) Banco de Dados SQL do AzureInstância Gerenciada SQL do Azure
Resumos de bases de dados
O hash do bloco mais recente no livro-razão da base de dados é chamado de resumo do banco de dados . Ele representa o estado de todas as tabelas contábeis no banco de dados no momento em que o bloco foi gerado. Gerar um resumo de banco de dados é eficiente, porque envolve a computação apenas dos hashes dos blocos que foram anexados recentemente.
Os resumos do 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 do banco de dados são gerados na forma de um documento JSON que contém o hash do bloco mais recente, juntamente com metadados para o 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 isso, os resumos do banco de dados extraídos do banco de dados precisam ser armazenados em um armazenamento confiável que os usuários com privilégios elevados ou invasores do banco de dados não podem adulterar.
Geração e armazenamento automáticos de resumos de bancos 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 Ledger integra-se com o recurso de armazenamento imutável do Armazenamento de Blobs do Azure e com o Razão Confidencial do Azure . Essa integração fornece serviços de armazenamento seguro 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 ter que se preocupar com sua disponibilidade e replicação geográfica. Azure Confidential Ledger tem uma garantia de integridade mais forte para clientes que possam estar preocupados com o acesso de administradores privilegiados ao digest. Esta tabela compara o recurso de armazenamento imutável do Armazenamento de Blobs do Azure com o Azure Confidential Ledger.
Você pode configurar a geração e o armazenamento automáticos de resumos de banco de dados por meio do portal do Azure, do PowerShell ou da CLI do Azure. Para obter mais informações, consulte Habilitarde armazenamento digest automático . Quando você configura a geração e o armazenamento automáticos, os resumos do banco de dados são gerados em um intervalo predefinido de 30 segundos e carregados no serviço de armazenamento selecionado. Se nenhuma transação ocorrer no sistema no intervalo de 30 segundos, um resumo do banco de dados não será gerado e carregado. Esse mecanismo garante que os resumos do banco de dados sejam gerados somente quando os dados tiverem sido atualizados em seu banco de dados. Quando o ponto de extremidade é um Armazenamento de Blob do Azure, o servidor lógico para o do Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure cria um novo contêiner, chamado sqldbledgerdigests e usa um padrão de nomenclatura como: ServerName/DatabaseName/CreationTime. O tempo de criação é necessário 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, consulte Digest Management Considerations.
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
Se você usar uma conta de Armazenamento do Azure para o armazenamento dos resumos do banco de dados, configure uma política de imutabilidade em seu contêiner após o provisionamento para garantir que os resumos do banco de dados sejam protegidos contra adulteração. Verifique se a política de imutabilidade permite gravações de acréscimo protegidas para acrescentar blobs e se a política está bloqueada.
Permissão da conta de Armazenamento do Azure
Se usar o Banco de Dados SQL do Azure ou a Instância Gerenciada SQL do Azure , assegure-se de que o seu servidor lógico ou instância gerenciada (Identidade do Sistema) tenha permissões RBAC (controle de acesso baseado em função) suficientes para escrever digests, adicionando-o à função Colaborador de Dados de Blob de Armazenamento . Caso utilize a replicação geográfica ativa ou grupos de failover automático, assegure-se de que as réplicas secundárias tenham a mesma permissão RBAC na conta de Armazenamento do Azure.
Se você usar SQL Server, precisará criar uma assinatura de acesso compartilhado (SAS) no contêiner digest para permitir que o SQL Server se conecte e autentique na conta de Armazenamento do Azure.
- Crie um contêiner na conta de Armazenamento do Azure, chamado sqldbledgerdigests.
- Crie uma política num contêiner com as permissões Ler, Adicionar, Criar, Gravare Listar e gerar uma chave de assinatura de acesso partilhado.
- Para o contêiner sqldbledgerdigests usado para armazenamento de arquivos digest, crie um de credenciais do SQL Server cujo nome corresponda ao caminho do contêiner.
O exemplo a seguir pressupõe que um contêiner de Armazenamento do Azure, uma política e uma chave SAS foram criados. Isso é necessário para o SQL Server acessar os arquivos de resumo no contêiner.
No trecho de código a seguir, substitua <your SAS key> pela chave SAS. A chave SAS tem a aparência '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 do Livro-razão Confidencial do Azure
Se utilizar o Banco de Dados SQL do Azure ou a Instância Gerida de SQL do Azure, assegure-se de que o seu servidor lógico ou instância gerida (Identidade do Sistema) tenha permissões suficientes para escrever resumos, adicionando-o ao papel de Colaborador. Para fazer isto, siga as etapas para gestão de utilizadores do Azure Ledger Confidencial.
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 as regras NSG da SQL Managed Instance do Azure para trabalhar com o Livro Razão Confidencial do Azure
Se você usar de Instância Gerenciada SQL do Azure, certifique-se de configurar as regras de rede virtual da sua Instância Gerenciada SQL do Azure para se comunicar com o Razão Confidencial do Azure. Para obter mais informações, consulte Configurar regras NSG da Instância Gerida do SQL do Azure para funcionar com o Azure Confidential Ledger.
Geração manual e armazenamento de resumos de banco de dados
Você também pode gerar um resumo do banco de dados sob demanda para que possa armazenar manualmente o resumo em qualquer serviço ou dispositivo que considere um destino de armazenamento confiável. Por exemplo, poderá optar por um dispositivo WORM (write once, read many) instalado localmente como destino. Você gera manualmente um resumo do banco de dados executando o sys.sp_generate_database_ledger_digest procedimento armazenado 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 maneira:
{
"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 permissões relacionadas a tabelas contábeis, consulte Permissions.
Considerações sobre a gestão de resumos
Restauração do banco de dados
Restaurar o banco de dados de volta para um ponto anterior no tempo, também conhecido como Point in Time Restore, é uma operação freqüentemente usada quando ocorre um erro e os usuários precisam reverter rapidamente o estado do banco de dados de volta para um ponto anterior no tempo. Ao carregar os resumos gerados no Armazenamento do Azure ou no Azure Confidential Ledger, o tempo de criação do banco de dados é capturado para o qual esses resumos são mapeados. Todas as vezes que o banco de dados é restaurado, ele é marcado com um novo tempo de criação, e 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 do resumo é ativado pela primeira vez. O Ledger preserva as informações sobre quando uma operação de restauração ocorreu, 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 utilizadores podem examinar todos os resumos de diferentes momentos de criação para identificar quando o banco de dados foi restaurado e quão longe foi restaurado no tempo. Como esses dados são gravados em armazenamento imutável, essas informações também são protegidas.
Observação
Se você executar uma restauração nativa de um backup de banco de dados na Instância Gerenciada SQL do Azure, precisará alterar o caminho de 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
Os grupos de replicação geográfica ativa ou de failover automático podem ser configurados para o Azure SQL Database ou para o Azure SQL Managed Instance. 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 principal. No caso de um failover geográfico, todos os dados mais recentes que ainda não foram replicados são perdidos. O Ledger só emitirá resumos de banco de dados para dados que foram replicados para secundários geográficos para garantir que os resumos nunca farão referência a dados que possam ser perdidos em caso de failover geográfico. Isso só se aplica à geração e armazenamento automáticos de resumos de banco de dados. Num grupo de tolerância a falhas, os bancos de dados primário e secundário terão o mesmo caminho de digestão. Mesmo quando se executa um failover, o caminho de resumo não é alterado para o banco de dados primário e secundário.
Se o grupo de contingência for eliminado ou se o link for removido, ambos os bancos de dados se comportarão como bancos de dados primários. Nesse ponto, o caminho de digestão do banco de dados secundário anterior será alterado e iremos adicionar uma pasta RemovedSecondaryReplica ao caminho.
Quando seu banco de dados faz parte de um grupo de disponibilidade Always On ou de um link de Instância Gerenciada no SQL Server, o mesmo princípio da replicação geográfica ativa é usado. O upload dos resumos só é feito se todas as transações tiverem sido replicadas para as réplicas secundárias.