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

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.

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.

 

Roles do SQL Server – Vida e Obra

s12

(Esse artigo faz parte da série Roles do SQL Server – Vida e Obra)

Bom dia!

Este post inicia o começo de uma série sobre as Server-roles:  Roles no SQL Server.

Entendo que é um assunto importante tanto pra DBA’s (essencial aqui) quanto pra Desenvolvedores, que por vezes que precisam gerenciar o SQL Server por motivo ou outro.

1 – Básico sobre Segurança

Tem um artigo legal do Laurentiu que trata dos aspectos básicos de segurança no SQL Server. Em resumo:

  • Existem dois escopos principais no SQL Server quando o assunto é segurança: Server (Instância) e Databases (Bancos de Dados);
  • Logins são relacionados à Instância (Server) e Usuários, aos bancos de dados;
  • Cada login é um principal. Principal é tudo aquilo que pode sofrer uma ação chamada permissionamento;
  • Existem “principals” que possuem permissões já pré-definidas, embora você também possa criá-los. Tais principals são chamados de Role (Papel, função)

Mas…o que é uma role?

2- Roles: Analogia 

Maria Queren é uma analista de sistemas pela manhã, trabalhando em uma multinacional. De tarde, ela vai para sua empresa, onde é dona, a fim de tomar decisões gerenciais. No final da tarde, vai para o curso de inglês, onde é aluna. De noite, vai pra casa, onde é esposa e mãe. Nos finais de semana, passa o tempo na casa dos pais.

Notou o que seriam “roles”? Observe a variedade de papéis que a Maria possui. Analistas de Sistema, proprietária de negócio, estudante, mãe, esposa, filha… Cada papel deste traz uma série de poderes e possui uma determinada atuação em determinado contexto (ambiente). Maria pode dar gerenciar pessoas em sua empresa, mas não na instituição onde tem curso de inglês.

3 – Voltando ao SQL Server

Então, o SQL Server possui também alguns papéis de servidor, tanto em contexto de servidor como em contexto de banco de dados. É importante associar o contexto de servidor aos logins (autenticação) do que usuários (estes estão no escopo de banco de dados).  Cada papel possui uma série de privilégios, e garante ao principal associado X permissões. No caso em específico do assunto atual, que são roles de servidor, garante algumas permissões à nível de instância.

4-   Mas o que são mesmo Server Roles?

Se dividem em duas categorias: Fixed Server Roles (Leia-se Funções fixas, pré-definidas) e as Custom Server Roles (referenciadas oficialmente como User Defined Server Roles, que é uma novidade trazida pelo SQL Server 2012). Vamos começar da raíz, conhecendo cada uma das roles fixas.

As nove Roles Fixas de Servidor, linkadas neste tópico, são:

5 – Mas porque falar sobre Server Roles em outros posts? “Faz um resumão aê”

Pode parecer simples resumir poucas linhas sobre cada role acima (como é comumente visto pela internet). Porém, algumas roles são  extremamente peculiares, pois, possuem mais privilégios do que se comumente acredita que tenham e é difícil fixar isso sem teste. Algumas são irrelevantes no dia de hoje (em linhas gerais), outras fáceis de entender e outras bastante delicadas e que escondem um canhão (por exemplo, dbcreator) se mal utilizados.

Nas próximas postagens, vou seguir a ordem da lista acima e conversamos sobre as roles bulkadmin e dbcreator.
De antemão, caso tenha alguma pergunta ou queira dar uma sugestão sobre o assunto (e quiser fazer perguntas sobre as roles), não hesite em comentar ou entrar em contato. Todo e qualquer feedback é bem vindo, ok?

[]’s