Conceptos de caché de seguridad

Se aplica a:SQL ServerAzure SQL DatabaseAzure SQL Managed Instance

En este artículo se explica cómo SQL Server usa una caché de seguridad para validar los permisos que una entidad de seguridad tiene para acceder a objetos securizables.

Propósito

El motor de base de datos organiza una colección jerárquica de entidades, conocidas como elementos protegibles, que se pueden proteger con permisos. Los elementos protegibles más destacados son servidores y bases de datos, pero los permisos también se pueden establecer en un nivel más preciso. SQL Server controla las acciones de los principales sobre los recursos protegibles garantizando que tengan los permisos adecuados.

En el diagrama siguiente se muestra que un usuario, Alice, tiene un inicio de sesión en el nivel de servidor y tres usuarios diferentes asignados al mismo inicio de sesión en cada base de datos diferente.

Para optimizar el proceso de autenticación, SQL Server usa una caché de seguridad.

Sin flujo de trabajo de caché

Cuando la caché de seguridad no es válida, SQL Server sigue un flujo de trabajo sin caché para validar los permisos. En esta sección se describe el flujo de trabajo sin caché.

Para demostrarlo, tenga en cuenta la siguiente consulta:

SELECT t1.Column1,
       t2.Column1
FROM Schema1.Table1 AS t1
     INNER JOIN Schema2.Table2 AS t2
         ON t1.Column1 = t2.Column2;

Cuando la caché de seguridad no es válida, el servicio completa los pasos descritos en el flujo de trabajo siguiente antes de resolver la consulta.

Para SQL Server, las tareas sin una caché de seguridad incluyen:

1. Conéctese a la instancia.
2. Realice la validación de inicio de sesión.
3. Cree el token de contexto de seguridad y el token de inicio de sesión. Los detalles de estos tokens se explican en la sección siguiente.
4. Conéctese a la base de datos .
5. Cree un token de usuario de base de datos dentro de la base de datos.
6. Compruebe la pertenencia a roles de base de datos. Por ejemplo, db_datareader, db_datawriter o db_owner.
7. Compruebe los permisos de usuario en todas las columnas, por ejemplo, los permisos del usuario en t1.Column1 y t2.Column1.
8. Comprueba los permisos de usuario en todas las tablas, como table1 y table2, y los permisos de esquema en Schema1 y Schema2.
9. Comprueba los permisos de base de datos.

SQL Server repite el proceso para cada rol al que pertenece el usuario. Una vez obtenidos todos los permisos, el servidor realiza una comprobación para asegurarse de que el usuario tiene todas las concesiones necesarias en la cadena y no una sola denegación en la cadena. Una vez completada la comprobación de permisos, comienza la ejecución de la consulta.

Para obtener más información, consulte Resumen del algoritmo de comprobación de permisos.

Para simplificar la validación, SQL Server usa una caché de seguridad.

Definición de caché de seguridad

La caché de seguridad almacena permisos para un usuario o un inicio de sesión para varios objetos protegibles en una base de datos o servidor. Una de las ventajas es que acelera la ejecución de consultas. Antes de que SQL Server ejecute una consulta, comprueba si el usuario tiene los permisos necesarios para diferentes elementos protegibles de base de datos, como permisos de nivel de esquema, permisos de nivel de tabla y permisos de columna.

Objetos de caché de seguridad

Para que el flujo de trabajo se explique más rápido en la sección anterior, SQL Server almacena en caché muchos objetos diferentes dentro de las memorias caché de seguridad. Algunos de los objetos que se almacenan en caché son:

Seña	Descripción
SecContextToken	El contexto de seguridad a nivel del servidor para un principal se mantiene dentro de esta estructura. Contiene una tabla hash de tokens de usuario y sirve como punto de partida o base para todas las demás memorias caché. Incluye referencias al token de inicio de sesión, el token de usuario, la caché de auditoría y la caché de TokenPerm. Además, actúa como token base para un inicio de sesión en el nivel de servidor.
LoginToken	Similar al token de contexto de seguridad. Contiene detalles de los principales de nivel de servidor. El token de inicio de sesión incluye varios elementos como SID, identificador de inicio de sesión, tipo de inicio de sesión, nombre de inicio de sesión, estado isDisabled y pertenencia a roles fijos del servidor. Además, abarca roles especiales en el nivel de servidor, como sysadmin y administrador de seguridad.
UserToken	Esta estructura está relacionada con los principales a nivel de base de datos. Incluye detalles como nombre de usuario, roles de base de datos, SID, idioma predeterminado, esquema predeterminado, identificador, roles y nombre. Hay un token de usuario por base de datos para un inicio de sesión.
TokenPerm	Registra todos los permisos de un objeto protegible para un UserToken o SecContextToken.
TokenAudit	Key es la clase y el identificador de un objeto protegible. La entrada es una serie de listas que contienen identificadores de auditoría para cada operación auditable en un objeto. La auditoría del servidor se basa en comprobaciones de permisos, detallando cada operación auditable que un usuario específico tiene en un objeto determinado.
TokenAccessResult	Esta caché almacena los resultados de la comprobación de permisos de consulta para consultas individuales, con una entrada por plan de consulta. Es la memoria caché más importante y usada habitualmente, ya que es lo primero que se comprueba durante la ejecución de la consulta. Para evitar que las consultas ad hoc inunden la memoria caché, solo almacena los resultados de la comprobación de permisos de consulta si la consulta se ejecuta tres veces.
ObjectPerm	Esto registra todos los permisos de un objeto de la base de datos para todos los usuarios de la base de datos. La diferencia entre TokenPerm y ObjectPerm es que TokenPerm es para un usuario específico, mientras que ObjectPerm puede ser para todos los usuarios de la base de datos.

Almacenes de caché de seguridad

Los tokens se almacenan dentro de diferentes almacenes de caché.

Tienda	Descripción
TokenAndPermUserStore	Una gran tienda que contiene todos los objetos siguientes: - SecContextToken - LoginToken - UserToken - TokenPerm - TokenAudit
SecCtxtACRUserStore	Almacén de resultados de comprobación de acceso (ACR). Cada inicio de sesión tiene su propio almacén de usuarios de contexto de seguridad independiente.
ACRUserStore	Almacén de resultados de comprobación de acceso <unique id> - <db id> - <user id> Cada usuario tiene un almacén de usuarios de ACR individual. Por ejemplo, dos inicios de sesión con cinco usuarios en dos bases de datos diferentes equivalen a dos SecCtxtACRUserStore y 10 diferentes ACRUserStore.
ObjectPerm	Uno por tokens de base de datos ObjPerm . Todos los elementos protegibles diferentes dentro de la base de datos.

Problemas conocidos

En esta sección se describen los problemas con la memoria caché de seguridad.

Invalidaciones de caché de seguridad

Varios escenarios pueden desencadenar invalidaciones de caché de seguridad en el nivel de base de datos o servidor. Cuando se produce una invalidación, se invalidan todas las entradas de caché actuales. Todas las consultas futuras y comprobaciones de permisos siguen el flujo de trabajo completo "Sin caché" hasta que se vuelvan a rellenar las memorias caché. La invalidación puede afectar significativamente al rendimiento del servidor, especialmente bajo una carga alta, ya que todas las conexiones activas necesitan recompilar las entradas almacenadas en caché. Las invalidaciones repetidas de caché pueden empeorar este impacto. Las invalidaciones de la base de datos se tratan como invalidaciones en todo el master servidor, lo que afecta a las memorias caché de todas las bases de datos de la instancia.

SQL Server 2025 presenta una característica que invalida las memorias caché solo para un inicio de sesión específico. Esto significa que, cuando se invalidan las entradas de caché de seguridad, solo se ven afectadas las entradas que pertenecen al inicio de sesión afectado. Por ejemplo, si concede al inicio de sesión L1 un nuevo permiso, los tokens para el inicio de sesión L2 permanecen sin verse afectados.

Como paso inicial, esta característica se aplica a los escenarios de inicio de sesión CREATE, ALTER y DROP y los cambios de permisos para inicios de sesión individuales. Los inicios de sesión de grupo siguen experimentando la invalidación de nivel de servidor.

En la tabla siguiente se enumeran todas las acciones de lenguaje de definición de datos de seguridad (DDL) que invalidan la caché de seguridad.

Acción	Asunto	Ámbito
CREATE/ALTER/DROP	APPLICATION ROLE SYMMETRIC KEY ASYMMETRIC KEY AUTHORIZATION CERTIFICATE ROLE SCHEMA USER	Base de datos especificada
DROP	Cualquier objeto que aparezca en sys.all_objects o cualquier objeto protegible listado en la base de datos o en la lista de elementos protegibles con ámbito de esquema.	Base de datos especificada
GRANT/DENY/REVOKE	Cualquierpermiso para proteger contenido en la base de datos o el esquema.	Base de datos especificada
CREATE/ALTER/DROP	LOGIN (SERVICE) MASTER KEY	SQL Server instancia
ALTER	DATABASE	Base de datos especificada

Rendimiento de las consultas cuando crece el tamaño de TokenAndPermUserStore

Los problemas de rendimiento, como el uso elevado de cpu y el consumo de memoria aumentado, pueden deberse a entradas excesivas en la memoria caché de TokenAndPermUserStore. De forma predeterminada, SQL Server solo limpia las entradas de esta memoria caché cuando detecta presión de memoria interna. Sin embargo, en servidores con mucha RAM, es posible que la presión de memoria interna no se produzca con frecuencia. A medida que crece la memoria caché, aumenta el tiempo necesario para buscar entradas existentes para reutilizarlas. Esta caché se administra mediante un bloqueo por subproceso, lo que permite que solo un subproceso realice la búsqueda a la vez. Por lo tanto, este comportamiento puede provocar una disminución del rendimiento de las consultas y un mayor uso de CPU.

Solución

SQL Server proporciona dos marcas de seguimiento (TF) que se pueden usar para establecer una cuota para la caché de TokenAndPermUserStore. De forma predeterminada, no hay ninguna cuota, lo que significa que la memoria caché puede contener un número ilimitado de entradas.

• TF 4618: limita el número de entradas de TokenAndPermUserStore a 1024.
• TF 4618 y TF 4610: limita el número de entradas de TokenAndPermUserStore a 8192. Si el bajo límite de recuento de entradas de TF 4618 provoca otros problemas de rendimiento, se recomienda usar indicadores de seguimiento 4610 y 4618 juntos. Para obtener más información, consulte Establecimiento de marcas de seguimiento con DBCC TRACEON.

Para obtener más información, puede consultar el artículo Problemas de rendimiento pueden deberse a entradas excesivas en la caché de TokenAndPermUserStore: SQL Server.

procedimientos recomendados

En esta sección se enumeran los procedimientos recomendados para optimizar el flujo de trabajo de seguridad.

Administración de usuarios durante las horas no pico

Dada la naturaleza de invalidación de alto nivel de las memorias caché de seguridad (nivel de base de datos o servidor), realice DDL de seguridad durante las horas que no son de negocio cuando la carga del servidor es baja. Si se produce una invalidación de caché de seguridad durante cargas de trabajo intensivas, puede haber un impacto notable en el rendimiento en todo el servidor a medida que se repopulen las memorias caché de seguridad.

Uso de transacciones únicas para modificaciones de permisos

La realización de varias operaciones de lenguaje de definición de datos de seguridad (DDL) dentro de la misma transacción puede aumentar significativamente la posibilidad de encontrar interbloqueos con otras conexiones activas Para mitigar este riesgo, se recomienda evitar la ejecución de varias DDL de seguridad en una sola transacción. En su lugar, ejecute operaciones DDL relacionadas con la seguridad en transacciones independientes para minimizar la contención de bloqueos.

Contenido relacionado

• Introducción a los permisos del motor de base de datos