Roles do SQL Server – Sysadmin

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?

Sysadmin tem o privilégio máximo dentro de uma instância, podendo realizar qualquer ação, sem restrições. Uma das definições mais sinceras que eu já vi sobre o tema:

Basicamente, ele possui dois poderes bem intuitivos:

–  Pode realizar qualquer atividade no servidor;
–  IGNORA qualquer checagem de segurança realizada pelo SQL Server (Ato conhecido como Bypass);

Permission Check Algorithm e Bypass

Antes de explicar o que é o bypass, é importante citar o algoritmo de checagem de permissão (Permission Check Algorithm), utilizado quando qualquer comando é executado no servidor.  Não citarei detalhes nesse post, mas uma série de verificações é realizada quando qualquer comando é disparado na instância…Uma das primeiras verificações que o algoritmo faz no comando é localizar nas informações de permissionamento se há algum  DENY que esteja relacionado com os logins  envolvidos. Se houver algum DENY, o acesso é mal-sucedido

E porque o algoritmo procura o primeiro DENY que seja de seu interesse?

Porque o DENY (Negação) SEMPRE sobreescreve qualquer outra permissão. Essa é uma verdade para toda entidade no SQL Server, exceto uma certa role de servidor, e adivinha qual é? O Sysadmin. é claro! Não importa qual ação realize dentro de determinada instância, se naquele contexto de execução pertencer a um sysadmin, automaticamente o servidor diz: – “Ok, você pode fazer tudo aqui, não preciso sequer checar as suas permissões”. Já viu um empregado barrar o patrão da casa? É tipo isso.

E aí ocorre o que é chamado de Bypass, que em tradução livre, significa ignorar, e é literalmente o que acontece quando a execução é realizada no contexto de um sysadmin: ele ignora o algoritmo de checagem de permissão. É mais ou menos o que acontece quando um carro do DETRAN ou da PM (em exercício de sua profissão) faz um cavalo de pau e sobe no meio fio  acelerando. Não tem problema (pra eles) eles agirem assim. Contudo, seres normais normalmente seriam checados e barrados/multados, pois não possuem permissão pra fazer esse tipo de coisa.

Como o SQL Server não precisa realizar as checagens, internamente, é uma etapa a menos no ciclo de vida de um comando. Isso durante algum tempo levantou o seguinte argumento: “todo comando executado pelo sysadmin é mais rápido”.  Não é mito, é uma verdade por causa do bypass que ocorre entre o comando e as checagens de segurança do SQL Server, mas o ganho de desempenho na minha opinião não é justificável e logo tal argumento é irrelevante no quesito de performance.

Sysadmin pode tudo?

Sim, sysadmin faz tudo o que todas as roles faz e muito mais (como por exemplo, uso da conexão DAC, uso de procedures como xp_cmdshell, etc).  O SQL Server entende que, os logins inseridos nesta role são extremamente confiáveis e que não precisam ser verificados em momento algum.

Parece simples entender o quão poderosa é a role, mas ainda assim é comum encontrar perguntas como:

– Como eu proibo o sysadmin de fazer backup?
– Como eu proibo o sysadmin de logar no SQL Server?
– Como eu impeço o sysadmin de dropar login?

Uma resposta pobre (mas resolve o problema, rs): tire do sysadmin. Existem mil implementações malucas para impedir ações de sysadmin mas todas elas são ignoradas devido ao Bypass. Um bom exemplo são triggers: elas podem até restringir a atuação de um sysadmin, MAS, são frágeis podendo ser desabilitadas e/ou até alteradas pela suposta vítima.

Agora, uma resposta sensata: Talvez CONTROL SERVER seja a solução.

CONTROL SERVER

Existe uma permissão que foi criada com o intuito de ser uma alternativa  ao sysadmin chamada CONTROL SERVER. Essa permissão tem direito,  a fazer praticamente tudo o que um sysadmin faria. Como o proprio nome sugere, essa permissão concede o controle inteiro do servidor, e logo, imagina-se que seja algo perto do termo irrestrito.

Pergunta óbvia: Ué, então qual é a diferença entre essa permissão e a role sysadmin?

A resposta é simples! Como é uma permissão e não uma role, O SQL Server vai executar o algoritmo de checagem de permissões normalmente, sem realizar o bypass e vai considerar todas as etapas,  inclusive a etapa em que DENY é verificado! Ou seja, um DENY pode barrar quem possui um CONTROL SERVER.
Em outras palavras, é possível você ter um login com CONTROL SERVER mas que não possa criar bases (concedendo um DENY ALTER ANY DATABASE) por exemplo. Esse exemplo não se aplica para o sysadmin (é impossível negar que o sysadmin seja impedido de qualquer ação dentro determinada instância, conforme já vimos aqui). Contudo, um login com CONTROL SERVER já tem a faca e o queijo na mão: mesmo que ele tenha permissões negadas, existem N formas de ele mesmo recuperar as suas permissões através de escalação de privilégios. Vale lembrar também que um securable  com CONTROL SERVER pode ser propagado para outros logins mesmo que o WITH GRANT OPTION não tenha sido utilizado no ato da concessão do privilégio.

Outra observação: CONTROL SERVER apesar de ser a permissão mais elevada de todas não pode lidar diretamente com  server roles (por exemplo, incluir ou excluir alguém da role). Significa que um login com CONTROL SERVER não pode acrescentar outro em qualquer server role, e muito menos alterar ou remover logins dentre os sysadmin…

Securityadmin e Control Server, existe uma relação entre os dois?

Em várias documentações, artigos e etc, inclusive da Microsoft, é dito que você deve tratar o securityadmin como equivalente à sysadmin. Essa é uma declaração um tanto quanto séria, certo? Vimos que tecnicamente securityadmin tem permissões importantes porém diferentes e nem  tantas quanto um sysadmin tem, como foi visto no post sobre essa role, na mesma série.

Veja esse truque: mesmo que ele mesmo não possua a permissão CONTROL SERVER, o securityadmin pode conceder essa permissão para outro login. É um conceito similar ao de “escalação de privilégios”, o que vai possibilitar, de fato, se aproximar de um privilégio similar ao sysadmin.

Lembram do post onde o securityadmin conseguiu burlar a restriçao de criação de bases criando outro login?
A mesma lógica é utilizada no exemplo abaixo:

CREATE LOGIN guardinha WITH PASSWORD = '', CHECK_POLICY=OFF

EXEC SP_ADDSRVROLEMEMBER 'guardinha','securityadmin'

2) Logue como guardinha. Tente dropar uma base, e você verá que ocorrerá um erro, assim como aconteceu no post passado. Ainda como guardinha, crie um outro login e atribua a permissão de CONTROL SERVER pra ele.

CREATE LOGIN darthVader WITH PASSWORD ='',CHECK_POLICY=OFF;
 GO
 GRANT CONTROL SERVER TO darthVader ;

Pronto. Basta logar como DarthVader e ter a força, pra fazer quase tudo o que um sysadmin faria.

Conclusão: É correto dizer que securityadmin equivale a um sysadmin? NÃO, pois primeiramente é necessário escalar privilégios de outros logins (e isso é evitável). E ainda assim, existem coisas que só o sysadmin pode fazer.

Sysadmin Only

Nem tudo que o Sysadmin faz pode ser realizado por um login com CONTROL SERVER, pois caso algum código verifique:

• Se o login está dentro de alguma SERVER ROLE, como por exemplo a função  IS_SRVROLEMEMBER();
• Se determinado login está especificamente dentro da server role sysadmin (Via IF’s e similares);

Vamos sair da teoria e partir pra um exemplo prático? Esse é o código da SP_READERRORLOG, que é uma procedure utilizada para ler o errorlog (duh!), cuja concepção foi realizada pensando nos securityadmins.

De cara vamos uma verificação específica: se o login e/ou seu contexto de execução de quem tiver executando não for securityadmin, aborte a operação e mostre um erro. Um detalhe importante que vale citar aqui: como o sysadmin possui permissão total, ele passa em qualquer verificação da função IS_SRVROLEMEMBER.

É por isso que a única role que pode executar essa procedure além do securityadmin, é o sysadmin (pois ele retorna TRUE no valor de 1 em qualquer verificação realizada pela função IS_SRVROLEMEMBER). E justamente por causa dessa verificação, um login com CONTROL SERVER se não estiver em nenhuma das server roles citadas acima, não vai conseguir executar a procedure (simplesmente por causa da verificação que é bem específica). Curioso, não?

Existem vários workarounds pra resolver o problema, e alguns são óbvios e bastante fáceis. Não serão abordados aqui, mas são possíveis 🙂

Existem outras operações que também realizam a verificação específica de server roles, algumas especificamente o sysadmin.  Por exemplo, operações do SQL Server Agent, uso de conexão via DAC, dentre outros.
Quem deve ser Sysadmin?

A resposta é clara e simples: pessoas na qual você pode confiar a instância inteira do SQL Server.

E lembre-se da regra sagrada do milagre da multiplicação (e por um milagre divino muita gente não sabe disso): Um sysadmin pode atribuir o mesmo privilégio para outros.

Tenha cautela com o sysadmin que não sabe o poder que tem e acaba descobrindo! Sysadmin que acaba de descobrir que tem superpoderes é igual a um mutante dos X-men que acabou de descobrir que tem superpoderes mas não tem muita noção de como controlá-lo. E geralmente um poder mal controlado e mal aplicado pode resultar em desgraça desastres.

Embora CONTROL SERVER seja uma permissão extremamente poderosa e possui milagre da multiplicação (aka pode propagar sua permissão para outros), ainda é inferior ao sysadmin e pode ser uma opção a ser considerada.

---

E assim chega ao fim a série sobre server roles! Foi divertido escrevê-la.

Alguma observação? Elogio, crítica?

Fique à vontade para comentar.

---

Referências

Why CONTROL SERVER doesn’t cut it  (Bom exemplo sobre um caso onde o CONTROL SERVER não é suficiente)
http://www.sqlservercentral.com/blogs/brian_kelley/2010/10/26/why-control-server-doesn-t-cut-it/

Permissions (Leia mais sobre o Permission Check Algorithm)

http://msdn.microsoft.com/en-us/library/ms191291.aspx