Identificando logins com permissões elevadas no SQL Server

Outro título: "sabes quem tem poder de fogo no teu servidor?"

Introdução

É uma informação crítica e vital caso você administre servidores de banco de dados  conhecer quem possui permissões elevadas.

O que defino aqui como login com permissão elevada é aquele que:

• Está incluído na role de servidor sysadmin;
• Está incluído na role de servidor securityadmin
• Possui a permissão de CONTROL SERVER;

O post traz um script básico com o intuito de identificar quem são eles:

Script

O script se divide em duas partes: a primeira analisa roles de servidor com permissões importantes (nesse caso, sysadmin e securityadmin).  A segunda analisa permissões de servidor (CONTROL SERVER, leia os motivos aqui). Ambas as partes ignoram logins desativados.

Compatibilidade do script: SQL Server 2005 ou superior.

 

Segue exemplo de resultado:

EvidenciaPermiss

Customização vai a gosto do freguês: filtrar certificados, outras roles que você pode considerar importante (dbcreator por exemplo), considerar também logins desabilitados…

Espero que você não tenha surpresas ao localizar algum login de modo inesperado e que o script ajude alguém. Mas se encontrar, espero que você resolva da melhor forma possível antes de ter algum problema chato por causa de falha na segurança.
[]’s

 

Sugestões de leitura

Roles do SQL Server: Sysadmin – http://renatomsiqueira.com/roles-do-sql-server-sysadmin/

Roles do SQL Server: Setupadmin e Securityadmin – http://renatomsiqueira.com/roles-do-sql-server-setupadmin-e-securityadmin/

[]’s

Permissionamento no SQL Server – O básico (Parte 1 de 3)

keep-calm-and-ask-permission-5

Olá,

Conforme prometido no post de abertura , a ideia da primeira parte da série aqui é explicar de forma descomplicada alguns conceitos básicos sobre permissionamento, sobretudo no SQL Server (embora grande parte dos conceitos possa ser aplicada em outras tecnologias).

Os tópicos quentes são:

1. Conceito de permissão
2. Permissionamento mínimo
3. DCL
4. Concessão de permissões
5. Permission Chain

Permissionamento no SQL Server – Piloto

Seguranca

Olá,

Há algum tempo, publiquei uma série de posts sobre Server Roles, que eu gostei bastante de escrever e tenho vontade de falar mais um pouco sobre o assunto, já que ainda é comum encontrar algumas dúvidas de permissionamento que na maioria das vezes, poderia ser resolvida utilizando o básico do assunto.

Este post irá concentrar os demais posts da série, que serão:

De adianto, recomendo aqui um excelente material que, na minha opinião, todo DBA deveria analisar  com carinho pelo menos uma vez na vida:  Database Engine Permission Posters 

Ao longo da série, muito do que está no poster será explicado, mas já deixo aqui para ambientação pros próximos posts.

Até a próxima

[]’s

 

 

 

Roles do SQL Server – Sysadmin

Superman-Unchained

Olá,

Conforme prometido, o post de hoje será sobre a última server role que faltava pra série aqui do blog: sysadmin! Na verdade é mais um post sobre CONTROL SERVER do que sysadmin, mas anyway…

Você conhece quem é sysadmin em seu ambiente e até onde ele pode chegar?

Roles do SQL Server – Serveradmin

Imagem

Olá,

Continuando a  antiga série básica sobre roles do SQL Server, vamos dar uma olhada na role: serveradmin.

Essa role é responsável por realizar atividades inerentes à configuração do servidor.

Na hora de logar, cuidado com os (in)sensitives!

Insensitive
Pra quem não sabe o que é sobre o que é case (in)sensitive clique aqui
Olá,

Agorinha recebi um pedido pra criação de login/senha.

Código:

E concedi as permissões necessárias para o programador (aqui chamado de bro) realizar o teste em desenvolvimento.
No telefone:

Eu: testa aí por favor.
Bro: cara, não deu certo não.
Eu: Fiz o teste em minha máquina e funcionou…(carregando o errorlog)
Bro: Aqui continua dando erro, olha, tentei cinco vezes. O login no SQL Server é INSENSITIVO né?
Eu: Depende do Collate do servidor SQL, aí no caso de desenvolvimento, é Latin1_General_CI_AI, que é insensitivo.
Bro: Cara, então não sei o que é, na boa, não consigo logar.
Eu: *depois de ler o errorlog* e a senha, como é que tá? Tudo em minúsculo?
Bro: sim, porque?

Pedi pra que ele capitalizasse o que precisa ser capitalizado (algumas letras da senha estão em maiúsculo).
Aí vem a pergunta mais que óbvia: Mas a instância não é case insensitive?

É sim! Nesse caso especificamente, tanto faz se o login estiver UserAPP, USERAPP,UsErApP, ambos vão funcionar, exceto se o collate do servidor estiver configurado de algum modo para SENSITIVE. No caso de senhas, por funcionamento interno do SQL Server (leia-se, transformação da senha para hash, que é um procedimento interno que garante segurança das autenticações) seu texto SERÁ SENSITIVO independente do seu collate ou da versão do SQL Server.

Curiosidade leve, mas, pode ser útil pra alguém 🙂

Roles do SQL Server – Public

public

 

 

 

 

 

 

 

 

Olá!

Continuando com a série de Roles do SQL Server, vamos conversar sobre a role Public.

Provavelmente o post mais rápido do blog =)

Public

De cara, vale dizer que public possui uma implementação diferente das outras roles de servidor. Alguma peculiaridades:

  • Todo login criado no SQL Server, por padrão está vinculado à role public;
  • Das roles de servidor padrão (entenda-se excluindo as roles de servidor customizadas), é a única server role que pode ter as permissões controladas através de GRANT, DENY e REVOKE;
  • É gerado em cada banco uma database role com o mesmo nome. Embora estejam estritamente relacionadas, não são a mesma coisa;

Qual a ideia afinal do public? Bem… Sabe o nosso direito de ser cidadão, independente de quem seja? Liberdade de ir e vir, liberdade de expressão, etc? Segue a mesma ideia. Os direitos (e restrições) valem pra todo mundo, exceto para os sysadmins (que não possuem nenhuma restrição). Public contém as instruções padrões para TODOS os logins que se autenticam na instância.

 

Acabamos de criar um login qualquer. Quais permissões ele possui? Até o momento nenhuma, exceto as automaticamente herdadas pelo public. Pra ficar mais claro ainda, vamos aos testes de laboratório. Logue com o usuário recém-criado e tente criar um base:

Obviamente, o esperado é…

Msg 262, Level 14, State 1, Line 1
CREATE DATABASE permission denied in database ‘master’.

Agora, logado em seu usuário que seja sysadmin ou que tenha privilégios suficientes para executar o comando abaixo, tire a prova…

Com o login NaoFazNada, tente criar a base novamente…

 

Observações de public

Embora conceder permissões para public sempre seja o caminho mais fácil, evite isso sempre que possível. É a mesma coisa de, na preguiça, conceder acesso para Everyone em determinado diretório no Windows Server… Resolver resolve, mas abre a porta pra qualquer um entrar. Será que isso pode causar dor de cabeça futuramente?

E mais algumas enquanto database-role…

Existe outro cuidado bastante peculiar quando falamos de public enquanto DATABASE-ROLE (É importante distinguir uma da outra). É comum encontrarmos por aí solicitações, por exemplo, de conceder permissão para executar functions de tratamento de caracteres para o public em determinado banco. Esse public  como database-role na verdade contêm as definições que TODOS os usuários com acesso em determinada base.

Não é foco desta postagem granular a atuação do public ao nível de banco, mas, sobre tal tipo de solicitação bastante recorrente, só tenho a dizer que, embora facilite demais a vida de quem utiliza essas funções, sempre se deve levar em conta o permissionamento mínimo, logo…

Futuramente, vou criar um post sobre o tema, mas enquanto isso…

Por fim..

A conclusão é: nunca confie demais algo ao público, você pode não saber quem está lá.

Fique à vontade para acrescentar algo nos comentários abaixo, caso queira. Nos vemos por aí.

Roles do SQL Server – Diskadmin e Processadmin

hard-drive-inside

 

 

 

 

 

 

 

 

 

 

 

Olá.

Depois de algum tempo sem postar (falta de tempo mas por motivos profissionais, graças à Deus) aqui estamos. Pra abreviar um pouco a série sobre as roles de servidor, não seguirei a mesma linha dos posts anteriores se não for extremamente necessário.

Vamos falar um pouco agora sobre duas roles em específico (até porque não temos muito o que falar sobre: DiskAdmin e ProcessAdmin)

Diskadmin

Administra dispositivos de backup (obs: dispositivos, não o backup). Hoje em dia, esta role foi pro museu. Um motivo forte pra isso é caiu no desuso o uso de dispositivos para backup em fita (antigamente era comum fazer backup diretamente na fita, e hoje, é algo raro, pois, o desempenho de uma fita é ligeiramente inferior à backup no disco.

Funcionalidades:

  • sp_addumpdevice/sp_dropdevice = Adiciona/deleta um dispositivo de backup novo  à instância.
  • sp_diskdefault  e DISK INIT = Deprecated desde o SQL Server 2000. Fora do escopo (adorei essa frase).
  • Add member to diskadmin = Milagre da multiplicação, o famoso “passa a corrente pra frente”, etc. Dispensa explicações se você está acompanhando a série do começo =)

É interessante notar que um Disdkadmin não equivale a um backup operator ou algo do tipo (fazendo aqui referência à outros SGBD’s) pois por padrão, ele não possui direito de backup, a menos que seja dado tal direito explicitamente por outras formas.  Isso é um tanto quanto engraçado, poder gerenciar pra onde o backup vai mas não poder fazer backup. É muita falta de moral (risos).

ProcessAdmin

Possui o poder de matar conexões. Mas não só isso. Literalmente, ele é um administrador de processos, logo, com certeza, consegue enxergar todos eles. Em suma, ele consegue verificar todas as conexões da instância de várias formas, como por exemplo: a procedure sp_who2 e a dmv dm_exec_connections.

Funcionalidades:

  • Add member to processadmin = Milagre da multiplicação…
  • KILL = Possibilita utilizar o comando KILL, que encerra uma conexão. Leia-se: pode desconectar quem quiser.

Apesar de parecer pouca coisa, tal role possui um poder de fogo considerável. Matar conexões é um tanto quanto perigoso e pode trazer problemas se tal permissão for concedida à pessoas inexperientes/mal-intencionadas.

Geralmente quem tem o poder de matar conexões é um sa (sysadmin), então, é muito mais interessante deixar tal tarefa para algum membro desta role do que “granular” o fato de administrar conexões com o ProcessAdmin.

 —-

Em breve, continuo o post sobre as server roles. Obrigado pela leitura e sinta-se à vontade para comentar.

Roles do SQL Server – Dbcreator

DBCREATOR

Mais um post da série SQL Server Vida e Obra   , dessa vez sobre uma role bem peculiar: dbcreator, também conhecido como filho do sa. Cuidado com essa permissão, beleza?

O que é o DBCREATOR?

A documentação oficial da Microsoft (meio datada, mas ainda vale), diz:

Members of the dbcreator fixed server role can create databases, and can alter and restore their own databases.

Em português simples traduzido no popular:

Membros da função fixa dbcreator podem criar bases de dados, e podem alterar e restaurar suas próprias bases

Bem, vamos explorar um pouco e mostrar que a role vai um pouco além do que o nome sugere (criar bases)…O que pode ser uma benção e uma maldição, dependendo do ambiente.

Aplicação

É uma conta com permissões importantíssimas. O primeiro ponto a ser observado é que um dbcreator possui permissão para criar, alterar e dropar qualquer banco, até os que não é de sua criação (sentiu o perigo?) assim como pode utilizar o comando RESTORE tanto pra banco quanto pra LOG (este porém restrito às suas bases e/ou com as permissões adequadas. Tal assunto será abordado futuramente com maiores detalhes).

Testes

Primeiramente vamos verificar as permissões que a role possui:

Listando (os riscados não serão abordados neste post.):

– Add member to dbcreator (também conhecido como milagre da multiplicação)
– ALTER DATABASE
– CREATE DATABASE
– DROP DATABASE
– Extend database (Alterar o tamanho de um arquivo da base)
– RESTORE DATABASE
– RESTORE LOG
– sp_renamedb  (Procedure que renomeia o banco)

Bem, vamos começar oficialmente com os testes….

1) Criação do login

Agora logue como DbaCriador no Management Studio (ou da forma que preferir, contanto que consiga se passar pelo login).

2) Rename e Drop

Perceba agora o quanto a role é potente no sentido de permissões:

Consegue observar o tamanho da possível encrenca? É sempre bom reforçar que, dentro de uma instância, o maior bem é o banco de dados, e sua destruição e criação são sem dúvida uma das permissões mais sagradas que um principal pode ter.

Não precisamos comentar também a habilidade de repassar a Role para outros membros, e com o poder “milagre da multiplicação” temos mais um problema: um dbcreator criando outro dbcreator!

Veja ainda logado como dbcreator:

Considerações finais

Considere essa role uma das mais próximas do sa propriamente dito (assim como a security admin). Ultimamente caiu um pouco em desuso, pois, geralmente quem tem permissão de criar bases, pelo menos nos ambientes que observei, já possuem permissão de sysadmin, logo, não possuem restrição alguma. Se realmente for necessário que um principal crie bases, existe uma abordagem muito mais esperta:

Privilégio mínimo na prática.