Auditoría de la base de datos SQL en Fabric

Se aplica a :✅base de datos SQL en Microsoft Fabric

La auditoría de bases de datos SQL en Fabric es una característica crítica de seguridad y cumplimiento que permite a las organizaciones realizar un seguimiento de las actividades de base de datos y registrarlas. La auditoría facilita el cumplimiento, la detección de amenazas y las investigaciones forenses al ayudar a responder a preguntas como quién, cuándo y cómo se accedieron los datos.

¿Qué es la auditoría de SQL?

La auditoría de SQL hace referencia al proceso de captura y almacenamiento de eventos relacionados con la actividad de la base de datos. Estos eventos incluyen el acceso a datos, los cambios de esquema, las modificaciones de permisos y los intentos de autenticación.

En Fabric, la auditoría funciona en el nivel de base de datos y admite:

  • Supervisión del cumplimiento (por ejemplo: HIPAA, SOX)
  • Investigaciones de seguridad
  • Información operativa

Objetivo de auditoría

Los registros de auditoría se escriben en una carpeta de solo lectura en OneLake y se pueden consultar mediante la sys.fn_get_audit_file_v2 función T-SQL o oneLake Explorer.

Para SQL Database en Fabric, los registros de auditoría se almacenan en OneLake: https://onelake.blob.fabric.microsoft.com/{workspace_id}/{artifact_id}/Audit/sqldbauditlogs/

Estos registros son inmutables y accesibles para los usuarios con los permisos adecuados. Los registros también se pueden descargar mediante el Explorador de OneLake o el Explorador de Azure Storage.

Facturación

Actualmente, escribir registros de auditoría en Fabric OneLake no genera cargos adicionales, y el almacenamiento se incluye dentro de los límites de almacenamiento de OneLake que forman parte de la capacidad.

Opciones de configuración

De forma predeterminada, la opción Auditar todo captura todos los eventos, incluidas las completaciones de lotes, y la autenticación correcta y errónea.

Para ser más selectivo, elija entre escenarios de auditoría preconfigurados, por ejemplo: Cambios de permisos e intentos de inicio de sesión, Lecturas y escrituras de datos, o Cambios de esquema.

Cada escenario preconfigurado se asigna a grupos de acciones de auditoría específicos (por ejemplo, SCHEMA_OBJECT_ACCESS_GROUP, DATABASE_PRINCIPAL_CHANGE_GROUP). También puede elegir qué eventos auditar en Eventos personalizados. Puede seleccionar grupos de acciones individuales para adaptar la auditoría a sus necesidades. Esta opción es ideal para las organizaciones con directivas de seguridad internas estrictas.

Para filtrar las consultas de acceso comunes o conocidas, puede proporcionar expresiones de predicado en Transact-SQL (T-SQL) para filtrar los eventos de auditoría en función de las condiciones (por ejemplo, para excluir instrucciones SELECT): WHERE statement NOT LIKE '%select%'.

Permissions

Para administrar la auditoría mediante roles de área de trabajo de Fabric (recomendado), debe tener pertenencia al rol Colaborador del área de trabajo de Fabric o permisos superiores.

Para administrar la auditoría con permisos de SQL:

  • Para configurar la auditoría de base de datos, debe tener el permiso ALTER ANY DATABASE AUDIT.
  • Para ver los registros de auditoría mediante T-SQL, debe tener el permiso de visualización de la auditoría de seguridad de la base de datos.

Retention

De forma predeterminada, los datos de auditoría se conservan indefinidamente, a menos que configure un período de retención personalizado para eliminar automáticamente los registros después de esta duración.

Fabric almacena actualmente los registros de auditoría en la carpeta del elemento en OneLake y los limita al ciclo de vida del elemento. Si elimina el elemento, Fabric también elimina sus registros de auditoría. Si necesita retención independiente del ciclo de vida del elemento, mueva los registros de auditoría a una ubicación de almacenamiento independiente (por ejemplo, otra instancia de Lakehouse o una cuenta de Azure Storage) mediante herramientas como AzCopy o SSDT.

Retención de configuración después de la restauración

Después de una operación de restauración, se conserva la configuración de auditoría, pero la auditoría debe volver a habilitarse en Fabric SQL Database. En el portal de Fabric, abra Administrar auditoría de SQL, seleccione Guardar.

Configurar la auditoría para SQL Database en el portal Fabric

Para empezar a auditar una base de datos SQL de Fabric:

  1. Vaya a y abra la base de datos SQL en el portal de Fabric.
  2. En el menú principal, seleccione la pestaña Seguridad y, a continuación, seleccione Administrar auditoría de SQL. Captura de pantalla del portal de Fabric, que muestra la pestaña Seguridad y el botón Administrar auditoría de SQL.
  3. Se abre el panel Administrar auditoría de SQL .
  4. Seleccione el botón Guardar eventos en registros de auditoría de SQL para habilitar la auditoría.
  5. Configure los eventos que se van a registrar en la sección Eventos de base de datos . Elija Auditar todo (valor predeterminado) para capturar todos los eventos.
  6. Opcionalmente, configure una directiva de retención en Retención.
  7. Opcionalmente, configure una expresión de predicado de comandos T-SQL para omitir en el campo Expresión de predicado .
  8. Haga clic en Guardar.

Registros de auditoría de consultas

Los registros de auditoría se pueden consultar mediante las funciones de T-SQL sys.fn_get_audit_file y sys.fn_get_audit_file_v2.

En el script siguiente, debe proporcionar el identificador del área de trabajo y el identificador de base de datos. Ambos se pueden encontrar en la URL del portal Fabric. Por ejemplo: https://fabric.microsoft.com/groups/<fabric workspace id>/sqldatabases/<fabric sql database id>. La primera cadena de identificadores únicos en la URL es el ID del espacio de trabajo de Fabric, y la segunda cadena de identificador único es el ID de la base de datos SQL.

  • Reemplace por <fabric_workspace_id> el identificador del área de trabajo de Fabric. Puede encontrar el identificador de un área de trabajo en la dirección URL, es la cadena única dentro de dos / caracteres después /groups/ en la ventana del explorador.
  • Reemplace <fabric sql database id> con la base de datos SQL en el identificador de base de datos de Fabric. Puede encontrar el identificador del elemento de base de datos en la dirección URL, es la cadena única dentro de dos / caracteres después /sqldatabases/ en la ventana del explorador.

Por ejemplo:

SELECT * FROM sys.fn_get_audit_file_v2(
  'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
  DEFAULT, DEFAULT, DEFAULT, DEFAULT );

En este ejemplo se recuperan los registros de auditoría entre 2025-11-17T08:40:40Z y 2025-11-17T09:10:40Z.

SELECT *
FROM sys.fn_get_audit_file_v2(
    'https://onelake.blob.fabric.microsoft.com/<fabric workspace id>/<fabric sql database id>/Audit/sqldbauditlogs/',
    DEFAULT,
    DEFAULT,
    '2025-11-17T08:40:40Z',
    '2025-11-17T09:10:40Z')

Para obtener más información, consulte sys.fn_get_audit_file y sys.fn_get_audit_file_v2.

Administración de auditorías con la API REST

También puede ver y configurar las opciones de auditoría de SQL Database programáticamente a través de la API REST de Fabric. La API REST le permite administrar la auditoría de forma coherente en todas las bases de datos de un área de trabajo mediante scripts de PowerShell.

Para más información, consulte Administración de la auditoría de SQL Database con la API REST.

Proteger la información sensible en los registros de auditoría

Cuando construyes SQL dinámico concatenando valores de entrada directamente en la sentencia SQL, esos valores pasan a formar parte del texto de la sentencia. Si auditas el extracto, el registro de auditoría podría recoger información sensible incluida en el texto del extracto.

Para reducir el riesgo de exponer información sensible, sigue estas prácticas:

  • Evita SQL dinámico para operaciones que contengan valores sensibles

    Para operaciones administrativas sensibles a la seguridad, evita construir sentencias concatenando valores sensibles en SQL dinámico. Siempre que sea posible, utiliza sentencias SQL nativas u otros enfoques que impidan que valores sensibles se incrusten directamente en el texto de la sentencia.

    Las sentencias SQL dinámicas que se construyen a partir de cadenas accesibles por el usuario también hacen que tus aplicaciones sean vulnerables a ataques de inyección SQL. La inyección SQL es un ataque en el que se inserta código malicioso en cadenas que luego se pasan a la base de datos para su análisis y ejecución. Debes probar cualquier procedimiento que construya vulnerabilidades de inyección SQL en T-SQL, porque el motor de base de datos ejecuta todas las consultas sintácticamente válidas que recibe. Usa parámetros para los valores de los datos y nunca concatenes los valores de los parámetros en el texto de consulta. Los valores debidamente parametrizados se tratan como datos en lugar de sintaxis SQL ejecutable.

  • Restringir el acceso a los registros de auditoría

    Limitar el acceso a los registros de auditoría a usuarios y administradores autorizados. Dentro del SQL Motor de base de datos, los permisos SQL rigen el acceso a la auditoría dentro del SQL Motor de base de datos y pueden variar según la plataforma y el alcance de la auditoría. Sigue el principio de privilegio mínimo y concede solo los permisos necesarios para gestionar o revisar la información de auditoría. Existen modelos de permisos de auditoría a nivel de servidor y base de datos, y Azure SQL Database difiere de SQL Server en la disponibilidad de permisos a nivel de servidor. Restringir el acceso a los datos de auditoría ayuda a reducir el riesgo de divulgación no autorizada cuando hay información sensible presente en eventos grabados de auditoría.

    El acceso a los registros de auditoría fuera del SQL Motor de base de datos depende de los permisos en el destino configurado (como OneLake). Sigue el principio de privilegio mínimo y concede solo los permisos necesarios para gestionar o revisar la información de auditoría.

Contenido relacionado

  • Last updated on