Conceitos de cache de segurança

Aplica-se a:SQL ServerBanco de Dados SQL do AzureInstância Gerenciada de SQL do Azure

Este artigo explica como o SQL Server usa um cache de segurança para validar as permissões que uma entidade de segurança possui para acessar elementos de segurança.

Propósito

O Mecanismo de Banco de Dados organiza uma coleção hierárquica de entidades, conhecida como protegíveis, que pode ser protegida com permissões. Os elementos protegíveis mais proeminentes são servidores e bancos de dados, mas as permissões também podem ser definidas em um nível mais detalhado. O SQL Server controla as ações dos principais em seguráveis, garantindo que eles tenham as permissões apropriadas.

O diagrama a seguir mostra que um usuário, Alice, tem um logon no nível do servidor e três usuários diferentes mapeados para o mesmo logon em cada banco de dados diferente.

Para otimizar o processo de autenticação, o SQL Server usa um cache de segurança.

Nenhum fluxo de trabalho de cache

Quando o cache de segurança é inválido, o SQL Server segue um fluxo de trabalho sem cache para validar permissões. Esta seção descreve o fluxo de trabalho sem cache.

Para demonstrar, considere a seguinte consulta:

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

Quando o cache de segurança é inválido, o serviço conclui as etapas descritas no fluxo de trabalho a seguir antes de resolver a consulta.

Para o SQL Server, as tarefas sem um cache de segurança incluem:

1. Conecte-se à instância.
2. Execute a validação de logon.
3. Crie o token de contexto de segurança e o token de logon. Os detalhes desses tokens são explicados na próxima seção.
4. Conecte-se ao banco de dados .
5. Crie um token de usuário de banco de dados dentro do banco de dados.
6. Verifique a associação de funções de banco de dados. Por exemplo, db_datareader, db_datawriter ou db_owner.
7. Verifique as permissões de usuário em todas as colunas, por exemplo, as permissões do usuário t1.Column1 e t2.Column1.
8. Verifica as permissões de usuário em todas as tabelas, como table1 e table2, e permissões de esquema em Schema1 e Schema2.
9. Verifica as permissões de banco de dados.

O SQL Server repete o processo para cada função à qual o usuário pertence. Depois que todas as permissões são obtidas, o servidor executa uma verificação para garantir que o usuário tenha todas as autorizações necessárias na sequência e nenhuma negação na sequência. Depois que a verificação de permissão for concluída, a execução da consulta será iniciada.

Para obter mais informações, examine o resumo do algoritmo de verificação de permissões.

Para simplificar a validação, o SQL Server usa um cache de segurança.

Definição de cache de segurança

O cache de segurança armazena permissões para um usuário ou um logon para vários objetos protegíveis em um banco de dados ou servidor. Um dos benefícios é que ele acelera a execução da consulta. Antes de o SQL Server executar uma consulta, ele verifica se o usuário tem as permissões necessárias para protegíveis de banco de dados diferentes, como permissões no nível do esquema, permissões no nível da tabela e permissões de coluna.

Objetos de cache de segurança

Para tornar o fluxo de trabalho explicado na seção anterior mais rapidamente, o SQL Server armazena em cache muitos objetos diferentes dentro de caches de segurança. Alguns dos objetos armazenados em cache incluem:

Repositórios de cache de segurança

Os tokens são armazenados em repositórios de cache diferentes.

Problemas conhecidos

Esta seção descreve problemas com o cache de segurança.

Invalidações do cache de segurança

Vários cenários podem disparar invalidações de cache de segurança no nível do banco de dados ou do servidor. Quando ocorre uma invalidação, todas as entradas de cache atuais são invalidadas. Todas as consultas futuras e verificações de permissão seguem o fluxo de trabalho completo "Sem cache" até que os caches sejam repovoados. A invalidação pode afetar significativamente o desempenho do servidor, especialmente sob alta carga, pois todas as conexões ativas precisam recompilar as entradas armazenadas em cache. Invalidações de cache repetidas podem piorar esse impacto. As invalidações no master banco de dados são tratadas como invalidações em todo o servidor, afetando os caches em todos os bancos de dados na instância.

O SQL Server 2025 apresenta um recurso que invalida caches para apenas um logon específico. Isso significa que, quando as entradas de cache de segurança são invalidadas, somente as entradas pertencentes ao logon afetado são afetadas. Por exemplo, se você conceder ao logon L1 uma nova permissão, os tokens para logon L2 permanecerão inalterados.

Como uma etapa inicial, esse recurso se aplica aos cenários de logon CREATE, ALTER e DROP e alterações de permissão para logons individuais. Os logons de grupo continuam a apresentar invalidação no nível do servidor.

A tabela a seguir lista todas as ações de DDL (Linguagem de Definição de Dados) de segurança que invalidam o cache de segurança.

Desempenho da consulta quando o tamanho de TokenAndPermUserStore cresce

Problemas de desempenho, como alto uso da CPU e aumento do consumo de memória, podem ser causados por entradas excessivas no cache TokenAndPermUserStore. Por padrão, o SQL Server só limpa entradas nesse cache quando detecta pressão de memória interna. No entanto, em servidores com muita RAM, a pressão de memória interna pode não ocorrer com frequência. À medida que o cache aumenta, o tempo necessário para pesquisar entradas existentes para reutilizar aumenta. Esse cache é gerenciado por um spinlock, permitindo que apenas um thread execute a pesquisa de cada vez. Consequentemente, esse comportamento pode levar à diminuição do desempenho da consulta e ao maior uso da CPU.

Solução Alternativa

O SQL Server fornece dois TF (sinalizadores de rastreamento) que podem ser usados para definir uma cota para o cache TokenAndPermUserStore. Por padrão, não há cota, o que significa que o cache pode conter um número ilimitado de entradas.

• TF 4618: limita o número de entradas no TokenAndPermUserStore para 1024.
• TF 4618 e TF 4610: limita o número de entradas no TokenAndPermUserStore para 8192. Se o limite de contagem de entradas baixo do TF 4618 causar outros problemas de desempenho, é recomendável usar sinalizadores de rastreamento 4610 e 4618 juntos. Para obter mais informações, consulte Definir sinalizadores de rastreamento com DBCC TRACEON.

Para obter mais informações, você pode consultar o artigo Problemas de desempenho podem ser causados por entradas excessivas no cache TokenAndPermUserStore – SQL Server

Práticas recomendadas

Esta seção lista as práticas recomendadas para otimizar o fluxo de trabalho de segurança.

Gerenciamento de usuários durante o horário não comercial

Dada a natureza de invalidação de alto nível dos caches de segurança (nível de banco de dados/servidor), execute DDLs de segurança durante o horário não comercial quando a carga do servidor estiver baixa. Se ocorrer uma invalidação de cache de segurança durante cargas de trabalho pesadas, poderá haver um impacto notável no desempenho em todo o servidor à medida que os caches de segurança são repovoados.

Usar transações simples para modificações de permissão

Executar várias operações de DDL (Linguagem de Definição de Dados) de segurança dentro da mesma transação pode aumentar significativamente a chance de encontrar deadlocks com outras conexões ativas. Para atenuar esse risco, é recomendável evitar a execução de várias DDLs de segurança em uma única transação. Em vez disso, execute operações DDL relacionadas à segurança em transações separadas para minimizar a contenção de bloqueio.

Conteúdo relacionado

• Introdução às permissões do Mecanismo de Banco de Dados