Conceitos de cache de segurança

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

Este artigo explica como o SQL Server usa um cache de segurança para validar as permissões que um principal tem para acessar objetos protegidos.

Propósito

O Mecanismo de Banco de Dados organiza uma coleção hierárquica de entidades, conhecidas como protegíveis, que podem ser protegidas com permissões. Os protegíveis principais são servidores e bases de dados, mas as permissões também podem ser definidas num nível mais detalhado. O SQL Server controla as ações dos principais sobre os objetos de segurança, garantindo que eles tenham as permissões apropriadas.

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

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

Sem 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 login.
3. Crie o token de contexto de segurança e o token de login. Os detalhes desses tokens são explicados na próxima seção.
4. Ligue-se à base 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 do usuário em todas as colunas, por exemplo, as permissões do usuário em t1.Column1 e t2.Column1.
8. Verifica as permissões de usuário em todas as tabelas, como table1 e table2, e as permissões de esquema em Schema1 e Schema2.
9. Verifica as permissões do banco de dados.

O SQL Server repete o processo para cada função à qual o usuário pertence. Uma vez que todas as permissões são obtidas, o servidor executa uma verificação para garantir que o usuário tenha todas as concessões necessárias na cadeia e nenhuma única rejeição na cadeia. Após a conclusão da verificação de permissão, a execução da consulta é iniciada.

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

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 login 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. O SQL Server verifica, antes de executar uma consulta, se o utilizador tem as permissões necessárias para diferentes elementos protegidos do banco de dados, como permissões a nível de esquema, a nível de tabela e permissões de coluna.

Objetos de cache de segurança

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

Armazenamentos de cache de segurança

Os tokens são armazenados dentro de diferentes armazenamentos de cache.

Problemas conhecidos

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

Invalidações de 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 e verificações de permissão futuras seguem o fluxo de trabalho completo "Sem cache" até que os caches sejam preenchidos novamente. A invalidação pode afetar significativamente o desempenho do servidor, especialmente sob alta carga, pois todas as conexões ativas precisam reconstruir as entradas armazenadas em cache. Invalidações repetidas de cache podem agravar esse impacto. As invalidações no master banco de dados são tratadas como invalidações abrangentes ao servidor, afetando os caches em todos os bancos de dados na instância.

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

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

A tabela abaixo lista todas as ações DDL (Data Definition Language) 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 deteta pressão interna da memória. No entanto, em servidores com muita RAM, a pressão da memória interna pode não ocorrer com frequência. À medida que o cache cresce, o tempo necessário para pesquisar entradas existentes para reutilização 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

O SQL Server fornece dois sinalizadores de rastreamento (TF) 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 a 1024.
• TF 4618 e TF 4610: Limita o número de entradas no TokenAndPermUserStore a 8192. Se o limite baixo de contagem de entrada do TF 4618 causar outros problemas de desempenho, é recomendável usar flags de rastreamento 4610 e 4618 em conjunto. Para obter mais informações, consulte Definir sinalizadores de rastreamento com DBCC TRACEON.

Para obter mais informações, consulte o artigo Problemas de desempenho podem ser causados por entradas excessivas no cache TokenAndPermUserStore - SQL Server

Melhores práticas

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

Gestão de utilizadores fora das horas de ponta

Dada a natureza de invalidação avançada dos caches de segurança (a nível de base de dados/servidor), execute comandos DDL de segurança fora do horário comercial, quando a carga do servidor estiver baixa. Se ocorrer uma invalidação de cache de segurança durante cargas de trabalho pesadas, pode haver um impacto notável no desempenho de todo o servidor à medida que os caches de segurança são preenchidos novamente.

Usar transações únicas para modificações de permissão

Executar várias operações de segurança DDL (Data Definition Language) dentro da mesma transação pode aumentar significativamente a chance de encontrar impasses com outras conexões ativas, e para reduzir este 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