Logins vs Users no SQL Server: Qual é a Diferença?

A segurança do SQL Server torna-se muito mais simples quando separas duas perguntas: Quem consegue ligar à instância? E o que essa identidade pode fazer dentro de uma base específica? Logins e users respondem a essas perguntas em níveis diferentes. Para uma explicação específica, consulte o trabalho de um DBA de SQL Server.

Login existe ao nível do servidor

Um login é um principal de segurança ao nível da instância SQL Server. É utilizado para autenticar ou representar uma identidade no servidor. Pode ser uma identidade Windows, SQL authentication ou outro modelo suportado pelo ambiente.

Um login pode existir e, mesmo assim, não ter acesso a determinada base de dados.

Database user existe dentro da base

Um database user é um principal ao nível da base de dados. Ele representa a identidade dentro daquela base e recebe database roles e permissões.

O mesmo login pode mapear para users em várias bases e ter permissões diferentes em cada uma.

Exemplo prático

Imagina um login chamado AppReporting. A instância sabe que o login existe. Na base Sales, ele pode mapear para um user que pertence apenas a um role de leitura. Noutra base, pode não existir user nenhum.

CREATE LOGIN [AppReporting]
WITH PASSWORD = 'Use-a-secure-secret-here';

USE [Sales];
CREATE USER [AppReporting]
FOR LOGIN [AppReporting];

Depois concede apenas o necessário

Em vez de tornar a conta da aplicação db_owner, atribui um role ou permissões específicas que correspondam ao trabalho real. Para reporting pode ser leitura; para uma aplicação pode ser acesso limitado a determinados schemas, tabelas ou procedures.

O que é SID e por que importa?

SQL Server utiliza security identifiers para associar logins de servidor a users de base de dados. Quando uma base é restaurada ou migrada, o user pode chegar com o SID original enquanto o novo servidor não tem o login correspondente, ou tem um login com SID diferente. Explore o percurso para se tornar DBA de SQL Server para aprofundar este ponto.

Isso cria o que normalmente chamamos orphaned user.

Por que aparecem orphaned users

O backup da base contém users, mas os logins de servidor vivem fora da user database. Se migrares a base sem recriar corretamente os logins, o user pode deixar de mapear para a identidade esperada. O artigo complementar sobre os tipos de backup no SQL Server desenvolve este tema.

Como inspecionar users

SELECT dp.name AS DatabaseUser,
       dp.type_desc,
       dp.sid
FROM sys.database_principals AS dp
WHERE dp.type IN ('S','U','G')
ORDER BY dp.name;

Ao nível do servidor, sys.server_principals mostra os principais de servidor. Comparar a identidade e SID ajuda a diagnosticar problemas de mapping.

Roles não são users

Um role é um contentor de permissões. Em vez de conceder as mesmas permissões individualmente a várias pessoas, podes concedê-las ao role e adicionar os users adequados. Isso simplifica revisão e manutenção.

GRANT, DENY e REVOKE

GRANT concede uma permissão. DENY impede explicitamente. REVOKE remove um GRANT ou DENY para que a avaliação normal continue. É importante utilizá-los de forma intencional, porque combinações complexas tornam-se difíceis de compreender.

Erros comuns

• Adicionar contas de aplicação a sysadmin para resolver problemas rapidamente.
• Usar db_owner para acesso normal da aplicação.
• Criar SQL logins com passwords fracas ou partilhadas.
• Migrar bases e esquecer logins associados.
• Assumir que um login tem acesso automático a todas as bases.
• Conceder permissões diretamente a muitas pessoas quando um role seria melhor.
• Não testar a configuração usando a própria identidade.

Contained users

SQL Server também suporta contained database users em determinados cenários, reduzindo a dependência de um login tradicional de servidor para autenticação naquela base. Mesmo assim, é preciso compreender bem o scope dos principals e o desenho das permissões.

Sequência de troubleshooting

1. A identidade consegue autenticar na instância?
2. Existe database user correspondente?
3. O mapping aponta para a identidade esperada?
4. A que roles o user pertence?
5. Que GRANT ou DENY explícitos existem?
6. Ownership ou schema estão a influenciar?
7. O problema pode ser reproduzido usando a conta real?

Princípio principal

Formação relacionada

O curso de DBA SQL Server inclui autenticação, logins, users, roles, privilégio mínimo, orphaned users e testes práticos de permissões.

Ver o curso de Administração de Bases de Dados SQL Server

Precisa de ajuda para escolher o curso certo?

Se não tiver a certeza por onde começar, contacte a Goalbi Academy e diga-nos qual é o seu nível atual e o que pretende aprender.

Contactar a Goalbi Academy

Referências

Create a Login - SQL Server

Database-Level Roles - SQL Server

Permissions (Database Engine) - SQL Server