[SCRIPTANDO], Microsoft Azure

RBAC | Role-Based Access Control, O que é? Como Usar? [#Scriptando]

Share-it!
Share on Facebook3Tweet about this on TwitterShare on LinkedIn8Share on Google+0Email this to someone

Fala Pessoall! Td bem?

Vamo que vamo continuar com série #Scriptando, falando um pouco mais sobre os scripts que eu uso no meu dia a dia.

A dica de hoje é sobre controle de acesso, baseado em função. O que é isso?

Antes de tudo (como sempre), vamos entender um pouco sobre o RBAC no Azure, antes de prosseguirmos para o Script.

RBAC (ou Controle de Acesso Baseado em Função) 

Como toda plataforma de Cloud Computing, o Azure permite a criação, gerência e implantação de diversos tipos de serviço sendo eles IaaS, PaaS ou SaaS.

No entanto, era um desafio assegurar que um determinado indivíduo, tivesse acesso apenas ao recurso que ele deveria utilizar.

A Segurança da Informação é um ponto muito importante em uma empresa, porém, poucas empresas sabem efetivamente trabalhar com concessão e recogação de acessos.

Ter perfis muito permissivos, podem expor uma conta à ataques e até mesmo possibilitar que um usuário tenha acesso ao que não é de seu papel na organização.

Em contra partida, ter perfis muito restritivos pode dificultar o trabalho a ser feito pelos colaboradores, interferindo na produtividade e eficiência.

Com o advento do RBAC, foi possível separar totalmente as tarefas dentro de uma equipe, e com isso conceder apenas a quantidade de acesso necessária para realizar determinadas tarefas.

Exemplo: Posso usar o RBAC para permitir que meu Administrador de Infraestrutura, gerencie máquinas Virtuais de toda a minha assinatura, enquanto o meu DBA (Database Administrator) pode gerenciar todos os bancos de dados da minha assinatura.

Ou seja: Os 2 possuem acesso à mesma assinatura, porém, cada um gerencia tipos de serviços diferentes.

Azure Active Directory (AAD) 

Toda assinatura do Azure está associada a um diretório AAD. Significa que uma assinatura possui usuários, grupos e aplicativos, os quais podem gerenciar os recursos na mesma assinatura.

Com isso eu posso atribuir acesso a um Usuário específico, a um Grupo específico (Contendo um ou  ais usuários) ou a um Aplicativo específico.

Basicamente o RBAC possui 3 “perfis” de funções:

Owner (Proprietário): Possui acesso total aos recursos e pode (inclusive) delegar acesso para outros usuários.

Contributor (Colaborador): Possui o mesmo padrão de permissionamento do Owner, porém, não pode delegar acesso à outros usuários.

Reader (Leitor): Somente exibe os recursos existentes em uma assinatura. (Não consegue criar, apagar, movimentar, redimensionar, etc)

Essas permissões podem ser concedidas por recurso, grupo de recursos ou subscription.

Subscription (Assinatura): Todos os recursos herdam as permissões. (Ou seja: Se eu coloco um usuário como “Reader” no nível de assinatura, ele conseguirá listar TODOS os recursos de uma assinatura)

Resource Group (Grupo de Recursos): Todos os recursos que estão dentro de um Grupo de Recursos específico, herdam as permissões. (Ou Seja: Só consigo acesso aos recursos que estejam dentro de um Grupo de Recurso X. Caso eu tenha outros recursos na assinatura, que façam parte de outro grupo de recursos, eu não conseguirei acesso à eles.)

Resource (Recurso): O usuário/grupo/aplicação terá acesso apenas ao recurso X. (Ou Seja: Com isso eu posso permitir por exemplo, acesso à apenas uma VM, ou apenas um Banco de Dados em minha assinatura)

Mas essas não são todas as funções que eu tenho disponíveis em uma assinatura Azure. Com o intuito de dividir melhor as funções e conceder um acesso mais “justo”, o RBAC possui as chamadas “Funções Internas”.

O que são Funções Internas? 

São funções préviamente já definidas pela Microsoft, que ajudam a granularizar as permissões em nosso ambiente, e assim ser mais assertivo no que diz respeito à acessos.

Recomendo a você, dar uma olhada nas funções internas através nesse link: https://docs.microsoft.com/pt-br/azure/active-directory/role-based-access-built-in-roles

Show de bola ! Então vamos colocar a mão na massa?

RBAC | Gerenciando perfis e permissões via Powershell

[1] Primeiro, devemos logar no Portal (portal.azure.com)

 

[2] Agora, acessamos o AAD (Azure Active Directory)

[3] Acesse o console de gerenciamento de Usuários e Grupos

[4] Logo em seguida temos 2 opções:

a) Convidar um usuário de dentro da minha organização/domínio

b) Convidar um “Guest User” (Usuário fora da minha organização/domínio)

[5] Vamos optar pela opção [New Guest User]. Deveremos informar o e-mail desse usuário, e o mesmo irá receber o convite por e-mail.

[5] O usuário deverá OBRIGATORIAMENTE aceitar o convite por e-mail (clicando), e após a validação, o objeto de usuário já estará criado e apto a receber as permissões.

[6] O usuário deverá clicar em [Começar Agora], e aceitar o convite à subscription. (Após clicar em [Next], ele será direcionado para uma tela de applications, do Active Directory. Feche a tela e entre no portal [Agora com o usuário convidado])

[7] Notamos que o usuário convidado já possui acesso à subscription, porém não consegue listar nenhum recurso.

[8] Agora é que a coisa fica séria: Vamos conceder permissão para esse usuário em nossos recursos já existentes.

Vamos Logar via Powershell, em nossa conta “Mãe”.

Login-AzureRmAccount

[9] Agora, vamos pegar o ID da Conta de usuário que acabamos de adicionar em nossa subscription.

Get-AzureRmADUser | select DisplayName,Id

Obs.: Copie o ID do usuário em questão (no meu  caso é a segunda linha) e armazene em uma variável, para utilizarmos no próximo passo.

[10] Agora podemos conceder as permissões via Powershell. Vamos começar, armazenando algumas informações nas variáveis abaixo:

Obs.: Nesse tutorial, estou optando por conceder acesso à nível de grupo de recursos. Logo, o usuário terá acesso à um grupo de recursos específico e a todos os recursos que estão vinculados ao mesmo.

# Nome do grupo de recursos o qual deseja conceder o acesso.

$rg="AZR-BR"

# O ID da conta que você deseja dar o acesso. Nesse caso, vamos armazenar o ID que pegamos no passo anterior.</div>

$idconta="257860d6-9b90-45b6-95ff-74b93bc3231d"

# Agora, vamos passar o comando de atribuição de permissão no Grupo de Recursos selecionado.

# Obs.: O parâmetro -RoleDefinitionName, pode conter os valores: "Reader", "Contributor", "Owner".

New-AzureRmRoleAssignment -ObjectId $idconta -RoleDefinitionName "Contributor" -ResourceGroupName $rg

[11] Após a execução desse comando, já é possível acessar o grupo de recursos através da conta convidada:

[12] Para remover as permissões, basta usar o comando:


Remove-AzureRmRoleAssignment -ObjectId $idconta -RoleDefinitionName "Contributor" -ResourceGroupName $rg

E consequentemente, já não temos mais a permissão no Grupo de Recursos.

Et prêt! Já sabemos como dar permissões em nossos recursos.

Simples?  Fácil? Rápido? (Deixe seu feedback!)

“Et allons-y allons” com o #Scriptando, automatizando tarefas e ganhando tempo!

Aguardo você para ler meu próximo post! (Vê se não some hein?)  😉

Mais um bjo no coração de vocês!

Um Forte Abraço!

Gustavo Magella

#borapranuvem #cloud4all

Leave a Reply

Your email address will not be published. Required fields are marked *

Responda o enigma: * Time limit is exhausted. Please reload CAPTCHA.