Série: Segurança SQL Server — Artigo 3 de 3

Este é o terceiro e último artigo da nossa série sobre proteção de bases de dados. Caso tenha perdido os artigos anteriores, pode ler sobre Data Discovery & Classification e Transparent Data Encryption (TDE).

-- 1. Criar o login ao nível da instância/servidor
CREATE LOGIN AppUser_Login WITH PASSWORD = 'P@ssw0rd!ForteExemplo';

-- 2. Na base de dados pretendida, criar o utilizador associado ao login
USE MinhaBaseDados;
CREATE USER AppUser FOR LOGIN AppUser_Login;

Boa Prática de Arquitetura: Aconselha-se a gestão de acessos ao nível do Schema em vez de configurar permissões tabela a tabela. Definir regras objeto a objeto torna o modelo ingovernável à medida que a aplicação cresce.

-- Abordagem correta: Permissões centralizadas por Schema
GRANT SELECT ON SCHEMA::vendas TO AppUser;
GRANT EXECUTE ON SCHEMA::api TO AppUser;

-- Prática a evitar: Granularidade excessiva objeto a objeto
GRANT SELECT ON dbo.Clientes TO AppUser;
GRANT SELECT ON dbo.Encomendas TO AppUser;
-- (...repetir manualmente para dezenas de tabelas)

-- Criar uma role para leitura de relatórios e atribuir permissão
CREATE ROLE leitura_relatorios;
GRANT SELECT ON SCHEMA::relatorios TO leitura_relatorios;

-- Adicionar utilizadores à role
ALTER ROLE leitura_relatorios ADD MEMBER AppUser;
ALTER ROLE leitura_relatorios ADD MEMBER AnalyticUser;

Alerta de Segurança: A role nativa db_owner concede privilégios totais sobre a base de dados. Em auditorias, encontramos frequentemente esta role associada a contas de aplicação web em produção, quase sempre por ser a solução mais rápida na fase de desenvolvimento, ficando esquecida sem a devida contenção.

-- Consulta de auditoria: Mapear utilizadores e respetivas Roles na base de dados
SELECT 
    r.name AS role_name,
    m.name AS member_name,
    m.type_desc AS member_type
FROM sys.database_role_members rm
JOIN sys.database_principals r ON rm.role_principal_id = r.principal_id
JOIN sys.database_principals m ON rm.member_principal_id = m.principal_id
ORDER BY r.name, m.name;

-- 1. Função de Predicado: Valida se o cliente da sessão coincide com o registo
CREATE FUNCTION seguranca.fn_filtro_encomendas(@ClienteID INT)
RETURNS TABLE WITH SCHEMABINDING AS
RETURN
    SELECT 1 AS resultado
    WHERE @ClienteID = CAST(SESSION_CONTEXT(N'ClienteID') AS INT);

-- 2. Política de Segurança: Associa o filtro automaticamente à tabela
CREATE SECURITY POLICY EncomendaPolicy
ADD FILTER PREDICATE seguranca.fn_filtro_encomendas(ClienteID)
ON dbo.Encomendas
WITH (STATE = ON);

-- Configurar mascaramento na coluna de e-mail
ALTER TABLE dbo.Clientes
ALTER COLUMN Email ADD MASKED WITH (FUNCTION = 'email()');

-- Utilizador sem permissão UNMASK visualiza: eXXX@XXXX.com
-- Utilizador com privilégio UNMASK visualiza: email_real@empresa.com

Recurso Técnico de Referência

A Microsoft disponibiliza um infográfico detalhado que mapeia toda a árvore de permissões, escopos e securables do SQL Server e Azure SQL Database.

Nota: Elaborado originalmente para a versão SQL Server 2017, este esquema mantém-se conceptualmente exato para compreender a herança de direitos no motor de dados.

Transferir Infográfico de Permissões (PDF) →

Conclusão

O modelo de permissões do SQL Server é robusto e extremamente granular. No entanto, a acumulação histórica de privilégios, contas partilhadas e a ausência de auditoria contínua podem degradar a postura de segurança. Proteger a informação crítica da empresa não é um projeto pontual com data de fim, mas sim uma prática contínua de governança e revisão de acessos.

Precisa de auditar e reforçar a segurança do seu SQL Server?

A Singular Data realiza auditorias de segurança em bases de dados: revisões de permissões, eliminação de privilégios excessivos e implementação de políticas avançadas como RLS e DDM.