Usuário somente leitura no SQL Server: como verificar o acesso de verdade

“Pode usar esse login, ele é só de consulta.” Antes de conectar um relatório, uma integração ou um assistente de IA, vale transformar essa frase em uma condição verificável: quais dados a conta pode ler, quais operações não pode executar e por quais caminhos recebe acesso?

No SQL Server, o nome do usuário não define suas permissões. A configuração reúne papéis, concessões explícitas, grupos e contextos de execução. Uma checagem útil precisa olhar o conjunto, não apenas uma associação que parece tranquilizadora.

Leitura também precisa de escopo

A role db_datareader concede leitura nas tabelas e views de usuário do banco. Esse alcance pode ser maior do que uma ferramenta realmente precisa. Um relatório sobre a estrutura do dicionário não precisa, por esse motivo, receber acesso irrestrito a cadastros e movimentos.

Comece descrevendo a tarefa. Quais objetos são necessários? Quais colunas e quais registros? A partir daí, o responsável pelo banco pode escolher concessões específicas, views controladas ou outro mecanismo compatível com o cenário.

Uma conta dedicada facilita atribuir consultas à aplicação e revogar seu acesso sem afetar outras ferramentas. Compartilhar a credencial de um usuário humano costuma dificultar tanto a investigação quanto a manutenção das permissões.

Uma conta pode receber leitura por uma role e escrita por outra concessão. Também pode herdar privilégios de grupos. Conferir apenas que db_datareader aparece na lista não comprova ausência de outras capacidades.

A documentação da Microsoft explica a combinação entre permissões e papéis, incluindo contextos elevados.

Peça um inventário das permissões efetivas e dos caminhos que as concedem. O resultado deve informar o que a conta consegue fazer, e não apenas reproduzir a intenção de quem a cadastrou. Conectado com a credencial em teste, duas consultas respondem isso no banco atual:

SELECT r.name AS papel, m.name AS membro
  FROM sys.database_role_members rm
  JOIN sys.database_principals r ON r.principal_id = rm.role_principal_id
  JOIN sys.database_principals m ON m.principal_id = rm.member_principal_id
 WHERE m.name = USER_NAME()

SELECT permission_name
  FROM fn_my_permissions(NULL, 'DATABASE')
 ORDER BY permission_name

A primeira lista os papéis do usuário no banco; a segunda, o que ele efetivamente pode fazer nele, somando papéis e concessões diretas. Uma conta de consulta bem desenhada devolve db_datareader na primeira e, na segunda, quatro linhas: CONNECT, SELECT, VIEW ANY COLUMN ENCRYPTION KEY DEFINITION e VIEW ANY COLUMN MASTER KEY DEFINITION. As duas últimas não são concessão específica da credencial — o SQL Server on-premises as dá para public desde a versão 2016, por causa do Always Encrypted, e aparecem em qualquer login local, mesmo o mais restrito; no Azure SQL Database a public não as recebe por padrão, e um administrador pode revogá-las também on-premises, então a ausência delas ali não indica falha na credencial. O que importa continuar ausente é INSERT, UPDATE, DELETE, ALTER e CONTROL. Confira também os papéis de servidor em sys.server_role_members: sysadmin ali torna irrelevante tudo o que o banco diz.

Confirme quem está conectado

O teste pode dar uma conclusão errada se for executado numa janela ainda autenticada como administrador. Na segunda conexão, já autenticada com a credencial destinada à aplicação, identifique o contexto antes de continuar.

Esta consulta é apenas de diagnóstico:

SELECT
    ORIGINAL_LOGIN() AS login_original,
    SUSER_SNAME()    AS contexto_atual,
    DB_NAME()        AS banco_atual;

Os campos ajudam a distinguir o login de origem, o contexto de execução e o banco selecionado. A consulta, por si só, não avalia todas as permissões. Ela verifica a premissa sobre quem está participando do teste.

Registre o resultado sanitizado junto da versão do roteiro. Quando alguém reproduzir a conferência, terá como perceber se conectou ao banco ou à identidade errada antes de interpretar os próximos resultados.

Procedures e outros módulos também entram na análise

Não basta perguntar se a conta pode executar UPDATE diretamente. Uma operação pode ocorrer por meio de um módulo ao qual ela tem acesso. Cadeias de propriedade, assinatura de módulos e mudança de contexto podem afetar a verificação das permissões.

Isso não significa que toda stored procedure executa com privilégios elevados. Significa que o desenho precisa ser examinado. Liste quais módulos podem ser executados e qual efeito eles produzem no contexto real da aplicação.

O mesmo vale para capacidades de criar objetos, alterar permissões ou assumir outros contextos. Um perfil de consulta precisa ser definido pelo conjunto de capacidades permitido, e não por uma única proibição.

Na base descartável já preparada, monte uma matriz de testes: leitura permitida, leitura de objeto fora do escopo, tentativa de alteração e execução de módulo controlado. Para cada caso, defina antes qual resultado é esperado.

Os testes operacionais devem ser planejados pelo responsável pelo banco. Este artigo não propõe tentar escritas em tabelas reais para descobrir se uma credencial é segura.

Por que ROLLBACK não torna qualquer teste inofensivo

Uma transação pode permitir reverter alterações transacionais, mas não transforma todo efeito colateral em algo reversível. Bloqueios, execução de lógica adicional e comunicação com outros sistemas precisam ser considerados.

Por esse motivo, um exemplo de laboratório não deve ser copiado para produção apenas porque termina em ROLLBACK. Mesmo um comando que pretende não mudar valores continua sendo uma operação diferente de uma consulta.

Na revisão das permissões, use documentação, inspeção e testes controlados em conjunto. Um único comando negado comprova aquele cenário, não a impossibilidade de escrita por todos os caminhos existentes.

Uma conta sem escrita ainda pode executar consultas caras e ler informações sensíveis. Limites de escopo, duração, volume retornado e concorrência continuam relevantes, especialmente quando a ferramenta monta consultas dinamicamente.

Se o objetivo é fornecer contexto sobre o Protheus a uma IA, considere começar apenas com metadados curados. Saber que um campo existe costuma exigir muito menos acesso que ler o conteúdo de toda a tabela.