Compartir a través de


Auditoría de Azure SQL Database y Azure Synapse Analytics

Applies to:Azure SQL DatabaseAzure Synapse Analytics

La auditoría de Azure SQL Database y Azure Synapse Analytics realiza un seguimiento de los eventos de base de datos y los escribe en un registro de auditoría en su cuenta de almacenamiento de Azure, área de trabajo de Log Analytics o Event Hubs.

La auditoría también puede hacer lo siguiente:

  • Ayudar a mantener el cumplimiento de normativas, comprender la actividad de las bases de datos y conocer las discrepancias y anomalías que pueden indicar problemas en el negocio o infracciones de seguridad sospechosas.

  • Posibilitar y facilitar la observancia de estándares reguladores aunque no garantiza el cumplimiento. Para obtener más información, consulte la Microsoft Azure Centro de confianza donde puede encontrar la lista más reciente de certificaciones de cumplimiento de SQL Database.

Nota:

Para obtener información sobre la auditoría de Azure SQL Managed Instance, vea Comience con la auditoría de Azure SQL Managed Instance.

Información general

Puede usar la auditoría de SQL Database para:

  • Conservar un registro de auditoría de los eventos seleccionados. Puede definir categorías de acciones de base de datos para auditar.
  • Informar sobre la actividad de la base de datos. Puede usar informes preconfigurados y un panel para empezar rápidamente con el informe de actividades y eventos.
  • Analizar informes. Puede buscar eventos sospechosos, actividades inusuales y tendencias.

Importante

La auditoría de Azure SQL Database, Azure Synapse Analytics grupos de SQL y Azure SQL Managed Instance está optimizada para la disponibilidad y el rendimiento de la base de datos o la instancia que se audita. Durante períodos de actividad muy alta o carga de red alta, la característica de auditoría puede permitir que las transacciones continúen sin registrar todos los eventos marcados para la auditoría.

Mejoras en el rendimiento, la disponibilidad y la fiabilidad en la auditoría de servidores para Azure SQL Database (Disponibilidad General en julio de 2025)

  • Se han rediseñado las partes principales de la auditoría de SQL, lo que da lugar a una mayor disponibilidad y confiabilidad de las auditorías de servidor. Como ventaja adicional, hay una alineación más estrecha de las características con SQL Server y Azure SQL Managed Instance. La auditoría de la base de datos permanece sin cambios.
  • El diseño anterior de la auditoría desencadena una auditoría de nivel de base de datos y ejecuta una sesión de auditoría para cada base de datos del servidor. La nueva arquitectura de auditoría crea una sesión de eventos extendidos en el nivel de servidor que captura eventos de auditoría para todas las bases de datos.
  • El nuevo diseño de auditoría optimiza la memoria y la CPU, y es coherente con el funcionamiento de la auditoría en SQL Server y Azure SQL Managed Instance.

Cambios de la nueva arquitectura de auditoría de servidor

  • Cambio de estructura de carpetas para la cuenta de almacenamiento:
    • Uno de los cambios principales implica un cambio de estructura de carpetas para los registros de auditoría almacenados en contenedores de cuentas de almacenamiento. Anteriormente, los registros de auditoría de servidor se escribieron en carpetas independientes; una para cada base de datos, con el nombre de la base de datos que actúa como nombre de carpeta. Con la nueva actualización, todos los registros de auditoría del servidor se consolidan en una sola carpeta etiquetada master. Este comportamiento es el mismo que Azure SQL Managed Instance y SQL Server.
  • Cambio de estructura de carpetas para réplicas de solo lectura:
    • Las réplicas de base de datos de solo lectura anteriormente tenían sus registros almacenados en una carpeta de solo lectura. Esos registros ahora se escriben en la master carpeta . Para recuperar estos registros, filtre por la nueva columna is_secondary_replica_true.
  • Permisos necesarios para ver los registros de auditoría:
    • VIEW DATABASE SECURITY AUDIT permiso en la base de datos de usuarios

En el caso de entornos con muchas bases de datos que ejecutan cargas de trabajo OLTP pesadas, el uso de la auditoría de nivel de servidor con la configuración predeterminada puede provocar volúmenes de auditoría muy grandes en el servidor lógico. Dado que todos los eventos de todas las bases de datos se escriben en la misma carpeta de auditoría, la consulta de registros de auditoría para una base de datos única se vuelve lenta y operativamente costosa. Para mejorar el rendimiento y reducir el ruido:

  • Cambie a la auditoría de nivel de base de datos. Cada base de datos escribe en su propia carpeta de registro de auditoría, lo que reduce el volumen total examinado y hace que la recuperación sea más rápida.
  • Revise la configuración de auditoría. Determine si es necesario capturar todos los eventos completados por lotes o si una configuración filtrada personalizada puede cumplir los requisitos de seguridad y cumplimiento.

Limitaciones de auditoría

  • No se admite la habilitación de la auditoría en un grupo de SQL de Azure Synapse en pausa. Para habilitar la auditoría, reanude el grupo de SQL de Synapse.
  • No se admite la habilitación de la auditoría mediante la identidad administrada asignada por el usuario (UAMI) en Azure Synapse.
  • Actualmente, las identidades administradas no se admiten para Azure Synapse, a menos que la cuenta de almacenamiento esté detrás de una red virtual o un firewall.

Nota:

Para Azure Synapse Analytics, auditar una cuenta de almacenamiento que está detrás de una red virtual requiere la identidad administrada asignada por el sistema con el rol Storage Blob Data Contributor. Las identidades administradas asignadas por el usuario (UAMI) no se admiten para la auditoría de Synapse. Si necesita realizar una auditoría en una cuenta de almacenamiento que usa solo autenticación de Microsoft Entra, configure la identidad administrada asignada por el sistema en el servidor y concédale el rol Storage Blob Data Contributor en la cuenta de almacenamiento de destino. Para obtener más información, consulte Escribir auditorías en una cuenta de almacenamiento con VNet y firewall.

  • Debido a las restricciones de rendimiento, no auditamos las tempdbtablas temporales y . Aunque el grupo de acciones completado por lotes captura instrucciones en tablas temporales, es posible que no rellene correctamente los nombres de objeto. Sin embargo, la tabla de origen siempre se audita, lo que garantiza que todas las inserciones de la tabla de origen a las tablas temporales se registren.

  • La auditoría para pools de SQL de Azure Synapse admite únicamente grupos de acciones de auditoría predeterminados.

  • Al configurar la auditoría de un servidor logical en Azure o Azure SQL Database con el destino del registro como una cuenta de almacenamiento, el modo de autenticación debe coincidir con la configuración de esa cuenta de almacenamiento. Si usa claves de acceso de almacenamiento como tipo de autenticación, la cuenta de almacenamiento de destino debe estar habilitada con acceso a las claves de la cuenta de almacenamiento. Si la cuenta de almacenamiento está configurada para usar solo la autenticación con Microsoft Entra ID (formerly Azure Active Directory), la auditoría se puede configurar para usar identidades administradas para la autenticación.

  • La auditoría no es compatible en bases de datos con nombres que contengan el carácter ?. Esto se aplica tanto a la auditoría a nivel de servidor como a nivel de base de datos, ya que las bases de datos que tienen ? en sus nombres ya no son compatibles con Azure.

  • Azure SQL Database y Azure Synapse los registros de auditoría capturan hasta 4000 caracteres en los campos statement y data_sensitivity_information. Si la salida de una acción auditable supera este límite, cualquier contenido que supere los primeros 4000 caracteres se trunca y se excluye del registro de auditoría.

Comentarios

  • Los eventos iniciados por SQLDBControlPlaneFirstPartyApp en el registro de actividad son una función Azure interna del plano de control Azure SQL Database. Los eventos iniciados por SQLDBControlPlaneFirstPartyApp forman parte de una operación de sincronización interna entre el motor de SQL y Azure Resource Manager. Estos eventos son una parte normal de la administración de Azure SQL Database y son necesarios para la representación y el funcionamiento correctos de los recursos en Azure.
  • Se admite el almacenamiento Premium con BlockBlobStorage. Se admite el almacenamiento estándar. Sin embargo, para que la auditoría escriba en una cuenta de almacenamiento protegida por una red virtual o firewall, necesita tener una cuenta de almacenamiento de uso general v2. Si tiene una cuenta de uso general v1 o Blob Storage, actualice a una cuenta de almacenamiento de uso general v2. Para obtener instrucciones específicas, consulte cómo Escribir auditorías en una cuenta de almacenamiento detrás de una red virtual y un firewall. Para obtener más información, consulte la sección Tipos de cuentas de almacenamiento.
  • Cuando los clientes habilitan la auditoría de SQL y también configuran restricciones de red salientes , deben permitir enumerar los nombres de dominio completos de su cuenta de almacenamiento de auditoría para asegurarse de que los eventos de auditoría puedan llegar correctamente al destino. Si el punto de conexión de almacenamiento no está permitido, se bloquea el tráfico de auditoría, lo que da lugar a una pérdida de eventos de auditoría. Después de agregar los FQDN de las cuentas de almacenamiento necesarios a la lista de permitidos, los clientes deben volver a guardar su configuración de auditoría para reanudar el flujo normal de eventos de auditoría.
  • Se admite el espacio de nombres jerárquico para todos los tipos de cuenta de almacenamiento estándar y cuenta de almacenamiento premium con BlockBlobStorage.
  • Los registros de auditoría se escriben en Append Blobs en un Azure Blob Storage en la suscripción de Azure
  • Los registros de auditoría están en formato .xel y se pueden abrir con SQL Server Management Studio (SSMS).
  • Para configurar un almacén de registros inmutable para los eventos de auditoría de nivel de base de datos o del servidor, siga las instrucciones proporcionadas por Azure Storage. Al configurar el almacenamiento inmutable de blobs para su auditoría, asegúrese de que Permitir escrituras de anexos protegidas esté establecido como Blobs anexos o como Blobs en bloques. No se admite la opción Ninguno . En el caso de las directivas de retención con duración definida, el intervalo de retención de la cuenta de almacenamiento debe ser inferior a la configuración de retención de la auditoría de SQL. Las configuraciones en las que se establezca una directiva de almacenamiento, pero la retención de la auditoría de SQL esté fijada en 0, no son compatibles.
  • Puede escribir registros de auditoría en una cuenta de Azure Storage detrás de una red virtual o un firewall.
  • Para obtener más información sobre el formato del registro, la jerarquía de la carpeta de almacenamiento y las convenciones de nomenclatura, consulte el artículo sobre el formato del registro de auditoría de SQL Database.
  • La Auditoría en Utilizar réplicas de solo lectura para descargar cargas de trabajo de consulta de solo lectura se activa automáticamente. Para más información sobre la jerarquía de las carpetas de almacenamiento, las convenciones de nomenclatura y el formato del registro, consulte el artículo sobre el formato del registro de auditoría de SQL Database.
  • Al usar la autenticación Microsoft Entra, los registros de inicios de sesión con errores no aparecen en el registro de auditoría de SQL. Para ver los registros de auditoría de inicio de sesión con errores, debe visitar el Centro de administración Microsoft Entra, que registra los detalles de estos eventos.
  • La puerta de enlace enruta los inicios de sesión a la instancia específica en la que se encuentra la base de datos. En los inicios de sesión con Microsoft Entra, se verifican las credenciales antes de intentar usar ese usuario para iniciar sesión en la base de datos solicitada. En caso de error, nunca se accede a la base de datos solicitada, por lo que no se produce ninguna auditoría. Con los inicios de sesión de SQL, las credenciales se comprueban en los datos solicitados, por lo que en este caso se pueden auditar. Los inicios de sesión correctos, que obviamente llegan a la base de datos, se auditan en ambos casos.
  • Después de configurar los valores de auditoría, puede activar la nueva característica de detección de amenazas y configurar los mensajes de correo para recibir alertas de seguridad. Cuando se usa la detección de amenazas, se reciben alertas proactivas sobre actividades anómalas de la base de datos que pueden indicar posibles amenazas de seguridad. Para obtener más información, consulte SQL Protección contra amenazas avanzada.
  • Una vez que una base de datos con la auditoría habilitada se copia en otro servidor lógico, es posible que reciba un correo electrónico que le notificará que se ha producido un error en la auditoría. Se trata de un problema conocido y la auditoría debe funcionar según lo previsto en la base de datos recién copiada.