Roles do SQL Server – Setupadmin e Securityadmin

Olá,

Penúltimo post sobre a série, o tema serão as roles Setupadmin e Securityadmin.

Setupadmin

É uma role simples de entender e mais ainda de descrever.

• Add member to setupadmin: Também conhecido como milagre da multiplicação. Adiciona outro membro da role.
• Add/drop/configure linked servers: Possui a permissão de adicionar, editar e deletar configurações de Linked Servers. É, basicamente, a função primária dessa role.
• Mark a stored procedure as startup: Tá aí uma funcionalidade interessante (embora não seja, comumente, necessária). É possível configurar uma stored procedure para ser executada toda vez que o SQL Server é iniciado. Para quem tiver interesse, tem uma referência pro Books Online no final do post.

Em suma, geralmente, quem realiza configurações de linked servers na maioria das vezes são pessoas que detém a maioria ou todas as  credenciais do ambiente. Geralmente, essa tarefa é realizada por pessoas com permissões mais elevadas. Se você imaginou sysadmin, ponto pra ti.

---

Securityadmin

O último post da série é sobre sysadmin, então, nada mais justo que o seu filho seja apresentado primeiro.

Abaixo de sysadmin, Securityadmin é a server-role mais importante sem sombra de dúvida, com permissões bastante elevadas.

Vejamos:

• Add member to securityadmin: O milagre da multiplicação já mencionado em outros posts.
• Grant/deny/revoke CREATE DATABASE: Aqui vai uma permissão no mínimo curiosa. Qualquer securityadmin consegue manipular as permissões de CREATE ANY DATABASE para qualquer outro login. E por muita curiosidade (pode testar pra conferir), o mesmo ocorre para o comando ALTER ANY DATABASE. Em suma, securityadmin pode realizar esses comandos abaixo sem pudor nenhum:

GRANT CREATE ANY DATABASE TO loginQualquer;
GRANT ALTER ANY DATABASE TO loginQualquer

Esse tópico merece uma demo rapidinha, só pra degustação….

Crie um login  chamado mestre:

CREATE LOGIN mestre WITH PASSWORD = '', CHECK_POLICY=OFF;
EXEC SP_ADDSRVROLEMEMBER 'securityadmin',mestre;

Agora, logue como o  “mestre”.
Você sabe que, como securityadmin, pode conceder permissão de CREATE e ALTER ANY DATABASE. Mas o que acontece quando se tenta conceder permissão pra si mesmo?

GRANT CREATE ANY DATABASE TO mestre;

Cannot grant, deny, or revoke permissions to sa, dbo, entity owner, information_schema, sys, or yourself.

Aí o mestre pensa: pô, mas se eu não posso conceder permissão pra eu mesmo…

CREATE LOGIN minimestre WITH PASSWORD ='',CHECK_POLICY=OFF;

GRANT CREATE ANY DATABASE TO minimestre;

Problema resolvido. Agora o mestre vai usar o login que acabou de criar, o minimestre, e vai executar o comando:

CREATE DATABASE TomeEssaSociedadeHAHA

Guarde esse workaround com você. Você verá o quanto isso é importante no post sobre sysadmin.

• Read the error log: Sem dúvida outra habilidade importante que o securityadmin pode desempenhar. O errorlog do servidor possui informações importantes, principalmente no que tange à configuração do SQL Server.
  A procedure a ser utilizada, neste caso, é a sp_readerrorlog.
  Uma curiosidade interessante: A XP_READERRORLOG, que é mantida por motivos de compatibilidade e faz exatamente a mesma coisa da sp_readerrorlog não vai ser executada pelo securityadmin. É uma pequena curiosidade pra quem gosta de aprender uma coisa diferente por mais pequena que pareça todos os dias.
•  sp_addlinkedsrvlogin/sp_droplinkedsrvlogin: Adiciona, altera ou remove mapeamentos entre um login de instância e uma conta de segurança em servidores remotos. Em suma, essas permissões dão direito à edição em logins também no contexto de linked servers.
• sp_dropremotelogin: Possibilita remoção de um login que está em servidores remotos que está mapeado para um login local. Esse recurso está em deprecated, btw.
• sp_defaultdb – sp_defaultlanguage  sp_password: Possibilita alterar algumas informações dos logins. Essas procedures estão deprecateds, e agora, a construção que deve ser utilizada é a ALTER LOGIN. A correspondência de cada comando seria:

sp_defaultdb -> ALTER LOGIN  mestre WITH DEFAULT_DATABASE = master

sp_defaultlanguage -> ALTER LOGIN mestre WITH DEFAULT_LANGUAGE = british

sp_password -> ALTER LOGIN mestre WITH PASSWORD = ‘123’

• sp_droplogin: Deleta um login do SQL Server. Essa procedure está em deprecated e você deve utilizar a construção correspondente (no caso, seria DROP LOGIN)
• sp_denylogin: Procedure específica para negar acesso à logins do Windows (seja de usuários individuais e grupos).
• sp_revokelogin: Procedure que revoga uma permissão de login. Como é um comando deprecated, não vamos nos atentar a ele.
• sp_grantlogin: É a criação do login propriamente dito. A procedure foi substituída pela instrução….CREATE LOGIN, claro 😀
• sp_helplogin: Procedure que traz informações sobre o login (como banco default, linguagem e usuários e em quais bancos ele tem permissão (e de que) :

• sp_remoteoption: Permite mostrar e alterar configurações para logins remotos. Essa opção é deprecated.

Em suma, é uma server role poderosa. Pode ser usada caso você precise de alguém para gerenciamento de logins, mas por algum motivo não é interessante conceder sysadmin. É uma opção, mas é importante saber alguns pormenores, como o exemplo de criação de bancos.

EDIT PLANEJADO: Existe uma permissão muito importante que faz com que a Microsoft diga que securityadmin  equivale à sysadmin. Não coloquei essa informação de inicio, pois, precisava antes desenvolver a ideia do sysadmin. Peço que, caso tenha interesse, leia o post do sysadmin, pois ele é essencial para complementar a real importância do securityadmin.

---

Próximo e último post da série: sysadmin!

[]’s