Administración de resúmenes

  • Artículo

Se aplica a: SQL Server 2022 (16.x) Azure SQL DatabaseAzure SQL Managed Instance

Resúmenes de base de datos

El hash del bloque más reciente del libro de contabilidad de base de datos se denomina resumen de la base de datos. Representa el estado de todas las tablas del libro de contabilidad de la base de datos en el momento en que se generó el bloque. Generar un resumen de base de datos es eficaz, ya que solo implica calcular los hash de los bloques que se anexaron recientemente.

El sistema puede generar los resúmenes de la base de datos automáticamente o bien el usuario puede hacerlo manualmente. Puede usarlos más adelante para verificar la integridad de la base de datos.

Los resúmenes de la base de datos se generan como documento JSON que contiene el hash del bloque más reciente, junto con los metadatos del identificador de bloque. Los metadatos presentan el momento en que se generó el resumen y la marca de tiempo de confirmación de la última transacción de este bloque.

El proceso de verificación y la integridad de la base de datos dependen de la integridad de los resúmenes de entrada. Para ello, los resúmenes de base de datos que se extraen de la base de datos deben residir en almacenamientos de confianza que los usuarios con muchos privilegios o los atacantes de la base de datos no puedan manipular.

Generación automática y almacenamiento de resúmenes de base de datos

Nota:

La generación y almacenamiento automáticos de resúmenes de base de datos en SQL Server solo admiten cuentas de Azure Storage.

El libro de contabilidad se integra con la característica de almacenamiento inmutable de Azure Blob Storage y Azure Confidential Ledger. Esta integración proporciona servicios de almacenamiento seguros en Azure para ayudar a proteger los resúmenes de la base de datos frente a posibles alteraciones. Esta integración proporciona una manera sencilla y rentable para que los usuarios automaticen la administración de los resúmenes sin tener que preocuparse por su disponibilidad y replicación geográfica. Azure Confidential Ledger tiene una garantía de integridad más sólida para los clientes que puedan estar preocupados por el acceso de administradores con privilegios al resumen. En esta tabla se compara la característica de almacenamiento inmutable de Azure Blob Storage con Azure Confidential Ledger.

Puede configurar la generación y el almacenamiento automáticos de resúmenes de bases de datos a través de Azure Portal, PowerShell o la CLI de Azure. Para obtener más información, consulte Habilitación del almacenamiento de resumen automático. Al configurar la generación y el almacenamiento automáticos, los resúmenes de base de datos se generan en un intervalo predefinido de 30 segundos y se cargan en el servicio de almacenamiento seleccionado. Si no se producen transacciones en el sistema en el intervalo de 30 segundos, no se generará ni cargará ningún resumen de la base de datos. Este mecanismo garantiza que los resúmenes de la base de datos solo se generan cuando los datos se han actualizado en la base de datos. Cuando el punto de conexión es una instancia de Azure Blob Storage, el servidor lógico para Azure SQL Database o Azure SQL Managed Instance crea un nuevo contenedor, denominado sqldbledgerdigests y usa un patrón de nomenclatura como: ServerName/DatabaseName/CreationTime. La hora de creación es necesaria porque se puede quitar y restaurar una base de datos con el mismo nombre, lo que permite diferentes encarnaciones de la base de datos con el mismo nombre. Para más información, consulte Consideraciones de la administración de resúmenes.

Nota:

Para SQL Server, el usuario debe crear manualmente el contenedor.

Directiva de inmutabilidad de la cuenta de Azure Storage

Si usa una cuenta de Azure Storage para el almacenamiento de los resúmenes de base de datos, configure una directiva de inmutabilidad en el contenedor después del aprovisionamiento para asegurarse de que los resúmenes de la base de datos están protegidos frente a alteraciones. Asegúrese de que la directiva de inmutabilidad permite escrituras de anexos protegidas en blobs en anexos y de que la directiva está bloqueada.

Permiso de la cuenta de Azure Storage

Si usas Azure SQL Database o Azure SQL Managed Instance, asegúrate de que el servidor lógico o la instancia administrada (identidad del sistema) tenga permisos de RBAC suficientes para escribir resúmenes al agregarlos al rol Colaborador de datos de Storage Blob. En caso de que use la replicación geográfica activa o los grupos de conmutación por error automática, asegúrate de que la réplica o réplicas secundarias tengan el mismo permiso RBAC en la cuenta de Azure Storage.

Si usa SQL Server, debe crear una firma de acceso compartido (SAS) en el contenedor de resumen para permitir que SQL Server se conecte a la cuenta de Azure Storage y la autentique.

  • Cree un contenedor en la cuenta de Azure Storage, denominada sqldbledgerdigests.
  • Cree una directiva en un contenedor con los permisos Leer, Agregar, Crear, Escribir y Enumerar y genere una clave de firma de acceso compartido.
  • Para cada contenedor sqldbledgerdigests utilizado para el almacenamiento de archivos de resumen, debe crear una credencial de SQL Server cuyo nombre coincida con la ruta de acceso del contenedor.

En el siguiente ejemplo se supone que se ha creado un contenedor de Azure Storage, una directiva y una clave SAS. SQL Server lo necesita para acceder a los archivos de resumen del contenedor.

En el siguiente fragmento de código, reemplace <your SAS key> por la clave SAS. La clave SAS tiene el siguiente aspecto: 'sr=c&si=<MYPOLICYNAME>&sig=<THESHAREDACCESSSIGNATURE>'.

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

Permiso de Azure Confidential Ledger

Si usa Azure SQL Database o Azure SQL Managed Instance, asegúrese de que el servidor lógico o la instancia administrada (Identidad del sistema) tenga permisos suficientes para escribir resúmenes mediante la adición al rol Colaborador. Para ello, siga los pasos para la administración de usuarios de Azure Confidential Ledger.

Nota:

La generación y almacenamiento automáticos de resúmenes de base de datos en SQL Server solo admiten cuentas de Azure Storage.

Configuración de reglas de NSG de Azure SQL Managed Instance para trabajar con Azure Confidential Ledger

Si usas Azure SQL Managed Instance, asegúrate de configurar las reglas de red virtual de Azure SQL Managed Instance para comunicarse con Azure Confidential Ledger. Para obtener más información, consulta Configuración de reglas de NSG de Azure SQL Managed Instance para trabajar con Azure Confidential Ledger.

Generación y almacenamiento manual de resúmenes de base de datos

También puede generar un resumen de la base de datos bajo demanda, de modo que pueda almacenarlo manualmente en cualquier servicio o dispositivo que considere un destino de almacenamiento de confianza. Por ejemplo, puede elegir un dispositivo write once, read many (WORM) como destino. Para generar manualmente un resumen de base de datos, ejecute el procedimiento almacenado sys.sp_generate_database_ledger_digest en SQL Server Management Studio o Azure Data Studio.

EXECUTE sp_generate_database_ledger_digest;

El conjunto de resultados devuelto es una sola fila de datos. Debe guardarse en la ubicación de almacenamiento de confianza como un documento JSON de la siguiente manera:

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

Permisos

La generación de resúmenes de base de datos requiere el permiso de GENERATE LEDGER DIGEST. Para obtener más información sobre los permisos relacionados con las tablas del libro de contabilidad, consulte Permisos.

Consideraciones de la administración de resúmenes

Restauración de base de datos

La restauración de la base de datos a un momento dado anterior, también conocida como Restauración a un momento dado, es una operación que se usa con frecuencia cuando se produce un error y los usuarios necesitan revertir rápidamente el estado de la base de datos a un momento dado anterior. Al cargar los resúmenes generados en Azure Storage o Azure Confidential Ledger, se captura la hora de creación de la base de datos a la que se asignan estos resúmenes. Cada vez que se restaura la base de datos, se etiqueta con una nueva hora de creación, y esta técnica nos permite almacenar los resúmenes en diferentes "encarnaciones" de la base de datos. Para SQL Server, la hora de creación es la hora UTC actual cuando la carga del resumen se habilita por primera vez. Ledger conserva la información relativa a cuándo se produjo una operación de restauración, lo que permite que el proceso de comprobación use todos los resúmenes pertinentes en las diversas encarnaciones de la base de datos. Además, los usuarios pueden inspeccionar todos los resúmenes de las diferentes horas de creación para identificar cuándo se restauró la base de datos y hasta dónde se restauró. Dado que estos datos se escriben en un almacenamiento inmutable, esta información también se protege.

Nota:

Si realiza una restauración nativa de una copia de seguridad de una base de datos en Azure SQL Managed Instance, deberá cambiar la ruta de resumen manualmente utilizando el Azure Portal, PowerShell o la CLI de Azure.

Replicación geográfica activa y grupos de disponibilidad Always On

La replicación geográfica activa o los grupos de conmutación por error automática se pueden configurar para Azure SQL Database o Azure SQL Managed Instance. La replicación entre regiones geográficas es asincrónica por motivos de rendimiento y, por lo tanto, permite que la base de datos secundaria esté ligeramente detrás en comparación con la principal. En caso de una conmutación por error geográfica, se pierden los datos más recientes que aún no se han replicado. Ledger solo emitirá resúmenes de base de datos para los datos que se han replicado en ubicaciones secundarias geográficas para garantizar que los resúmenes nunca harán referencia a datos que podrían perderse en caso de una conmutación por error geográfica. Esto solo se aplica a la generación y el almacenamiento automáticos de los resúmenes de bases de datos. En un grupo de conmutación por error, tanto la base de datos principal como la secundaria tendrán la misma ruta de resumen. Incluso cuando se realiza una conmutación por error, la ruta de resumen no cambia para la base de datos principal y secundaria.

Si se elimina el grupo de conmutación por error o si quita el vínculo, ambas bases de datos se comportarán como bases de datos principales. En ese momento, la ruta de resumen de la base de datos secundaria anterior cambiará y agregaremos una carpeta RemovedSecondaryReplica a la ruta.

Cuando su base de datos forma parte de un grupo de disponibilidad Always On o de un enlace de instancias administradas en SQL Server, se utiliza el mismo principio que la replicación geográfica activa. La carga de los resúmenes solo se realiza si todas las transacciones se han replicado en las réplicas secundarias.

Contenido relacionado