O perigo da Server Role Securityadmin

Olá pessoal tudo certo?

No último post eu falei sobre as “server roles” e “database roles” e a importância de conhecer os níveis de permissão e acesso de cada uma delas.

Conhecendo as Server Roles e Database Roles do SQL Server

No post, quando eu falei sobre a server role securityadmin, eu falei que devemos ter muito cuidado ao conceder acesso nessa role, pois um membro dessa role pode conceder acesso para ele mesmo virar sysadmin.

Mas como assim Tiago? Tá loko???

Os membros da role securityadmin tem a permissão de conceder permissões a nível de servidor como GRANT, DENY e REVOKE, como podemos ver na imagem abaixo:

EXEC sp_srvrolepermission 'securityadmin'

Justamente por essa permissão de adicionar outros usuários na role securityadmin e conceder GRANT, é nesse ponto onde mora o perigo. Se um membro da role conceder a permissão de GRANT IMPERSONATE a um usuário, ele pode simplesmente se adicionar na role sysadmin.

Veja como:

Vou criar um usuário chamado tiago.neves na instancia e conceder acesso a role securityadmin.

USE [master]
GO
CREATE LOGIN [tiago.neves] WITH PASSWORD=N'123', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
GO
ALTER SERVER ROLE [securityadmin] ADD MEMBER [tiago.neves]
GO

Vou logar na instância com o usuário “tiago.neves”, que acabei de criar.

Apenas para validar o nível de acesso do usuário:

SELECT
    SUSER_NAME() AS [SUSER_NAME],
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],
    IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]

Agora começa a brincadeira, vou dar um GRANT IMPERSONATE ao meu próprio usuário. Veja o perigo do GRANT IMPERSONATE.

GRANT IMPERSONATE ANY LOGIN TO [tiago.neves]

Com a permissão concedida, sabendo que todo servidor tem um usuário SA, posso executar alguns comandos como SA ou até mesmo me adiconar na role sysadmin.

EXECUTE AS LOGIN = 'sa'

SELECT
    SUSER_NAME() AS [SUSER_NAME],
    ORIGINAL_LOGIN() AS [ORIGINAL_LOGIN],
    IS_SRVROLEMEMBER('sysadmin') AS [IS_SYSADMIN],
    IS_SRVROLEMEMBER('securityadmin') AS [IS_SECURITYADMIN]

Agora estou com permissão de sysadmin e posso fazer qualquer ação no banco, como acessar qualquer base de dados ou tabela, alterar, criar, deletar, destruir, fazer o que eu quiser com o usuário “tiago.neves”.

Esse é um dos motivos que é recomendado a DESATIVAR o usuário SA.

Vejamos o exemplo.

Abri uma nova sessão no banco com o usuário “tiago.neves”.

Ao tentar conectar no banco “Teste”, vou receber um erro informando que não tenho acesso ao banco.

Mas como eu tenho a permissão de “IMPERSONATE”, posso executar o comando “EXECUTE AS”.

EXECUTE AS LOGIN = 'sa'

Apesar de estar logado no servidor com o usuário “tiago.neves”, agora estou com a sessão como SA. Como podemos observar, antes eu não tinha acesso no banco de dados “Teste”, mas agora eu consigo logar na base de dados e executar comandos normalmente.

SELECT *
FROM teste

INSERT INTO Teste VALUES (2)
INSERT INTO Teste VALUES (3)
INSERT INTO Teste VALUES (4)
INSERT INTO Teste VALUES (5)

UPDATE Teste
SET COL1 = 0
WHERE COL1 = 4;

DELETE Teste
WHERE COL1 = 3;

Para amenizar a situação podemos criar uma auditoria para logar os comandos executados na base, pois assim seria possível saber o usuário que executou os comandos, mesmo ele não tendo acesso na base de dados.

Na base de dados “Teste” eu configurei uma auditoria que vai logar todas as instruções SELECT, UPDATE, INSERT e DELETE.

Como podemos ver, foram executas as instruções SELECT, INSERT, UPDATE e DELETE. Vamos conferir na auditoria quem apagou os dados ou quem alterou e inseriu os dados.

SELECT event_time,action_id,server_principal_name,statement,* 
FROM Sys.fn_get_audit_file('D:\XEvent\*.sqlaudit',default,default)

Se não tivéssemos a auditoria habilitada na base de dados seria impossível descobrir qual usuário realizou todas as alterações.

A consulta abaixo retorna os usuários que possuem o acesso ao “GRANT IMPERSONATE”.

SELECT B.name Usuario
FROM sys.server_permissions a
JOIN sys.server_principals b ON a.grantee_principal_id = b.principal_id
WHERE permission_name = 'IMPERSONATE ANY LOGIN'

Segurança é um assunto MUITOO sério e devemos ficar atentos a todos os detalhes. Pelo incrível que pareça, é muito comum encontrar ambientes com usuários sendo membros da role securityadmin sem ser necessário.

Bom pessoal, por hoje é isso.

Até o próximo post.

Abraços,

Tiago Neves

Curta a minha página no facebook e fique por dentro das novidades do mundo SQL Server.