Dando continuidade no tópico anterior, neste, vamos finalizar o assunto que tange a criação de roles, acessos e permissões.

Vamos começar tratando sobre as duas roles que são exclusivas ao Azure SQL:

  • DBManager
  • Login Manager

Essas duas roles de banco se encontram no banco de sistema Master e são gerenciadas pelo criador do servidor no portal Azure. Essas permissões também podem ser atribuídas aos usuários ou user roles de banco e dão as seguintes permissões:

  • DBManager – o usuário consegue criar quantos bancos quiser dentro do Azure e se torna o owner do banco criado. Embora sejam dbmanager de um banco que foi criado, isso não os garante permissão em outros
  • Login manager – Aqui, dá permissão para um usuário em específico de criar logins para outros usuários que ficarão com o default_database na Master.

Como essas roles ficam armazenadas na Master, não é possível adicionar roles de outros bancos e dar permissão em grupo aqui.

Segue a sintaxe como exemplo:

Alter role dbmanager [nome_usuario]
Alter role loginmanager [nome_usuario]

PERMISSÃO E CRIAÇÃO DE SERVER ROLES

As server roles, são roles dentro das instâncias do SQL Server que dão autorizações a nível de servidor, podendo reconfigurar todo o ambiente em que o(s) banco(s) estão hospedados.

A ideia aqui, funciona basicamente igual ao user-defined database role no que diz respeito às permissões, a grande diferença é que são aplicadas a nível de instância e com isso, a cautela deve ser maior.

Não há a opção de server roles para o Azure SQL e não é possível adicionar uma database role que esteja fora do banco Master.

Veja abaixo, como criar Server Role.

APPLICATION ROLE

Independente do modelo de sistema que escolhemos, seja on-premisses ou cloud, é possível criar usuários e roles específicas para as aplicações que sustentam o negócio.

Além de serem criadas, é necessário habilitá-las via stored procedure.

NOTA: quando executamos a sp_setapprole, a conexão ao qual ela foi executada, se torna a conexão do approle, logo, as permissões passam a ser da aplicação.

A sintaxe para criação é um pouco diferente, e com suas particularidades.  

O procedimento abaixo foi feito no Azure Data Studio.

EXTRA: ORPHANED USER (TROUBLESHOOTING)

Essa situação ocorre quando um usuário associado para um login perde a referência do SID não podendo mais acessar o servidor e por consequência, o banco de dados.

Costuma ocorrer em ambientes muito grandes onde há muitos bancos e diversos membros de equipe.

Esse fato também acontece pois quando excluímos um login do SQL Server, ele não exclui o usuário vinculado, ficando este, no banco perdido e sem acesso.

NOTA: esse tipo de situação não ocorre com o Azure SQL pois não há atribuição de um usuário para um login como ocorre no On-Premisses.

Com este post, finalizo toda a questão de acesso dentro do SQL Server assim como suas permissões. Existem diversas formas de atribuir permissões dentro dos serviços mas, são variações dos comandos GRANT, DENY E REVOKE e claro, não foram abordados aqui pois se tornaria repetitivo.

Nos próximos posts, irei iniciar sobre o assunto criptografia e como manter os dados criptofrados, seja local ou na transmissão entre aplicação e banco.

Espero que tenham gostado, até a próxima!

Publicidade