Já sabemos que devemos repensar alguns paradigmas da TI quando olhamos para o mundo de segurança em cloud. Gestão de Identidade, ou Identity Access Management é um destes conceitos. Quando pensamos em segurança em cloud, um dos pontos principais e mais importantes é definirmos e trabalharmos de forma correta como iremos gerenciar Identidades. Neste artigo vamos abordar alguns pontos que são hoje alguns dos mais desafiadores para as equipes de segurança quanto o tema é o IAM e a segurança do CI/CD.
Você pode também ouvir a versão em áudio deste conteúdo:
Gestão de Identidade em cloud
Podemos aplicar o conceito de Gestão de Identidade em cloud a um grande conjunto de coisas. Mas para sermos mais eficientes na descrição deste conceito, vamos nos ater a somente dois – usuários e recursos na cloud. Conceitualmente, a segurança de forma tradicional usa muito o pensamento de defesa em camadas (Defense-in-Depth) e em outro momento, esse tipo de proteção era muito mais forte quando pensamos em segurança de rede.
Não me entenda mal, eu sou uma cara que veio de segurança de infra e sei que esse tipo de proteção ainda é muito importante. Mas nos dias de hoje, onde tudo – ou quase tudo – migra para cloud, isso não é mais o suficiente. Hoje temos uma gama muito grande de ofertas quando pensamos em serviços na cloud, e isso não para de crescer. Se olharmos as duas maiores ofertas de serviços – AWS e Azure – teremos mais de 150 serviços oferecidos nos mais diversos temas.
Para proteger e gerenciar uma grande quantidade de serviços, usuários e recursos, é necessário reavaliar as formas tradicionais. E assim, chegamos à conclusão que, para gerenciar e controlar essa grande quantidade, precisamos de um gerenciamento de identidade e acesso (IAM).
O que é um IAM?
Neste artigo, vamos usar como base o IAM oferecido pela AWS. Mas é importante ressaltar que temos serviços semelhantes em quase todos os fornecedores de cloud do mercado, como por exemplo, na Azure ou no Google. Até porque mesmo sendo de fornecedores diferentes, todos continuam com o mesmo conceito básico – gerenciar os usuários e acessos dentro de uma estrutura, neste caso, de cloud.
Conceitualmente o pensamento sobre um IAM é bem simples. Precisamos gerenciar de forma granular e específica os usuários, seus acessos e permissões. Pronto, é isso !Mas o conceito é bem mais fácil do que a realização do fato !Em seu artigo intitulado “Guide to Initiating and Running an Effective IAM Program. (ID: G00389672)”, Gartner aponta que em 2021, as empresas que não possuírem um programa de IAM efetivo irão gastar até 40% a mais que as empresas que já possuem ou trabalham em um programa de IAM.
Isso foi publicado em 2019, portanto, quem ainda não estiver trabalhando no programa de IAM pode estar defasado.
O ponto principal de qualquer sistema IAM é uma identidade digital de cada um dos indivíduos, ou mesmo os recursos. Assim, uma vez que a identidade digital tenha sido criada, é necessário manter, modificar e monitorar todo o ciclo de vida de acesso para cada usuário.
Os desafios ao implementar um IAM
Assim, precisamos entender que o IAM tem como foco conceder o acesso aos recursos (ativos) da empresa. Estes recursos(ativos) devem ser os corretos a certos grupos ou usuários individuais, pensando desde a integração dos sistemas do usuário ao sistema ou recurso até sua revogação de permissões. Tudo isso em um tempo que seja o adequado ao processo da empresa.
Então, sistemas de IAM permitem aos administradores manter o processo de gerenciamento de usuários e recursos sempre alinhados com as necessidades das políticas e serviços da empresa.
Agora que entendemos o que é um IAM, vamos falar um pouco sobre os os aspectos que entendemos como os mais desafiadores para os times de segurança na implantação de um IAM.
Mas, caso você queira ir um pouco mais afundo e entender melhor como o modelo da AWS funciona, talvez este documento seja indicado e a leitura muito recomendada.
SSO dentro do processo de IAM
É comum encontrarmos em empresas processos de autenticação feitos por mecanismos de logon único – os famosos SSO(Single Sign-On). Normalmente eles são utilizados para facilitar e melhorar a experiência do usuário quando acessando seus recursos.
Além de trazer uma experiência melhor ao usuário – que não precisa ficar fazendo logon em cada um dos recursos – isto também é uma ferramenta muito importante para o pessoal de estrutura e segurança. Afinal, permite o gerenciamento centralizado de um grande número de usuários e serviços.
No entanto, o grande desafio aqui é o mapeamento de seus usuários e as possíveis várias funções e perfis que cada um pode ter em cada serviço ou mesmo recurso. Facilmente alguém vai cometer algum equívoco !
Esse tipo de cenário exige ainda mais atenção quando envolve legislações de privacidade, ou mesmo contratos, regulamentos e ou políticas internas.
Sendo assim, o primeiro ponto de muita atenção é: Tenha um mapeamento de seus usuários, grupos e permissões.
Federation
Muitas empresas já têm um estrutura de autenticação estabelecida, não precisando refazer este procedimento em serviços em cloud. O que precisa ser feito é uma integração deste processo de autenticação com o IAM do cloud – um processo chamado de “federation”.
Se sua empresa está desenvolvendo uma aplicação mobile ou web, e quer permitir que seus usuários possam se autenticar com algum serviço já existente, como um Google, Amazon, Facebook ou outro, pode usar novamente o conceito de “federation”. Além de mais fácil a seu usuário, pode ser muito mais prático o gerenciamento de seus usuários.
Continuando com o exemplo do app mobile, se seu aplicativo precisa armazenar algum tipo de dado em um serviço AWS, este só pode ser feito por meio de uma validação usando uma chave de acesso da AWS, mas isso de forma alguma é recomendado.
O que recomendamos é que seja incorporado ao aplicativo um mecanismos de solicitação de credenciais temporárias de segurança. Isto permite que o acesso ainda seja concedido, mas agora de forma mais segura.
Permissionamento
Aqueles que são um pouco mais experientes vão lembrar que uma das principais recomendações quando implementamos um servidor é nunca usar a senha do root ou administrador para as tarefas do dia a dia. O recomendado é ter sempre um outro usuário e senha.
No entanto, temos que pensar que usuários em estruturas complexas possuem um grande conjunto de acessos e permissões atrelados a eles. É só você pensar no seu processo de desenvolvimento: quantos acessos e permissões seus usuários têm ?
Gerenciar e manter este conjunto de permissões e acessos sempre corretos é uma verdadeira batalha, que pode ser desastrosa dentro de um processo de desenvolvimento se não for bem estruturada.
Um bom conceito é ter uma estrutura baseada em grupos e permissões. Isso pode e vai implementar em seu processo de desenvolvimento uma segregação ou separação das funções. Esta é uma das várias camadas de segurança que você pode implementar.
Há muitas formas e serviços dentro de provedores de cloud que podem ajudar nesta tarefa, o que queremos colocar aqui é a “pulga atrás da orelha” para aqueles que vão ou já têm um estrutura de desenvolvimento que é ou tem integração com serviços em cloud. Afinal, essa questão exige mais cuidado.
Muito do que temos visto sobre vazamento de dados e informações pelo meio de serviços S3 bucket, por exemplo, é por falta de um entendimento mais profundo de como este serviço funciona. Então, é fácil deduzir que um sistema mais complexo como o IAM pode sim estar sendo usado de forma equivocada.
Algumas orientações de segurança no IAM
Serviços de IAM são peças fundamentais dentro de uma estrutura de segurança em cloud. Processos de desenvolvimento que usam estas estruturas como base, deveriam olhar com mais atenção para esse serviço.
O uso de IAM no ciclo de vida da aplicação pode integrar mais uma camada de segurança a todo o processo.
Desta forma, vamos colocar aqui algumas dicas que podem ajudar a melhorar a segurança com o IAM.
Usando grupos
Por mais que existam controles individuais para cada usuário dentro do IAM, gerenciar permissionamento para cada um pode ser um grande desafio.
Para isso, pense em criar grupos relacionados a funções de trabalho (administradores, desenvolvedores, testadores, etc.) isso vai facilitar.
Em seguida, defina as permissões relevantes para cada grupo. Isso não é nada além do que já estamos acostumados quando tratamos de segregação de funções !
Assim que os grupos estejam criados, inclua seus usuários do IAM a esses grupos. Esse simples procedimento pode melhorar a segurança do seu processo de desenvolvimento, garantindo que somente as pessoas certas tenham determinadas permissões em determinados momentos.
Limite os privilégios
Se estamos falando em ter mais controle sobre seus usuários e como eles podem interagir com seu processo de desenvolvimento, temos que pensar nos privilégios que cada um possa vir a ter. Em um artigo anterior, abordamos segurança em CI/CD, e o IAM pode se encaixar perfeitamente na sua estratégia.
Manter os privilégios controlados sempre foi um dos princípios de segurança mais usados. Mas para que isso funcione de forma correta, um primeiro passo é determinar a função e a permissão de cada usuário ou de cada grupo, e quando não há essa mapeamento a tarefa de permissionamento e privilégio fica muito mais difícil.
Se já tem este mapeamento fica fácil, crie políticas no seu IAM que possa permitir somente as permissões determinadas assim, você consegue controlar, por exemplo, permissionamento de leitura e escrita em componentes do seu processo de CI/CD.
Uma boa dica é: “comece com um perfil mais restritivo de acesso, e depois vá melhorando as permissões.”. Fazer isso é bem mais fácil do que tentar eliminar as permissões de um conjunto muito mais amplo, sempre se esquece alguma coisa.
Como falamos no início, vamos usar a AWS como modelo mas outras plataformas de cloud podem ter serviços semelhantes.
Caso durante o seu processo de criação de políticas de permissionamento ficou na dúvida se uma certa permissão vai ou não ser usada, não tem problema você pode analisar o histórico de uso pelo usuário.
A ideia é entender se o usuário uso ou não a permissão, e isso pode ajudar a refinar ainda mais a política de permissionamento. Na AWS isso pode ser feito com o AWS CloudTrail. Este serviço pode ser usado para validar o uso, já que os logs do serviço incluem informações detalhadas de eventos.
Use MFA
Sabemos que as senhas ainda são a barreira mais comum para controle de acesso de usuários. Mas também sabemos que é um dos mecanismos que mais sofrem quando falamos de segurança. Alguns até apontam que já é um mecanismo obsoleto de segurança.
Mas, ainda podemos usar este mecanismos – desde que possamos ajudar a reforçar a sua segurança. E uma das formas que podemos fazer isso é garantir que nossos usuários usarão meios de validar seu acesso de forma mais segura.
É possível dentro do mecanismo de IAM habilitar o uso de um segundo ou múltiplos fatores de autenticação, permitindo estender a segurança da senha.
Ao habilitar o MFA, o usuário tem um dispositivo, ou aplicação, que pode ser usado para gerar uma resposta a um desafio de autenticação. E somente é concedido acesso se as credenciais e a resposta ao desafio estiverem corretos.
Pense em habilitar esse mecanismos dentro de sua estrutura para garantir ainda mais segurança para o seu processo de desenvolvimento.
SAIBA MAIS SOBRE NOSSOS SERVIÇOS
Conclusão
Como comentamos, não temos aqui a pretensão de prover uma fórmula mágica a ser seguida. O que queremos é gerar curiosidade sobre o tema.
Como vimos até aqui, o IAM é um assunto bem complexo, cheio de detalhes e que facilmente pode ser deixado em um segundo plano.
Precisamos entender que o IAM, como qualquer serviço ou recurso de uma solução de cloud, ou on-premise, deve ser entendido e planejado com o máximo de cuidado, pois muitas vezes eles são a barreira entre seus dados e o mundo exterior.
Entenda o que está usando, quais os recursos, como utilizar e como melhor configurar, se fizer isso de forma correta, dificilmente terá algum problema.
