Identidades para aplicações

Identidades para aplicações

Um conceito vindo do on-premise e potencializado com o uso da nuvem pública, as identidades para aplicações (workload IDs) existem para que possamos aplicar permissões no consumo dos recursos e controlar o acesso aos insumos da organização. Elas nos permitem identificar o consumidor (aplicação) e funcionam como se fossem credenciais de usuários humanos. Hoje falaremos sobre essas identidades, suas características técnicas e aplicações dentro do Microsoft Entra ID.


Entendendo o Conceito

Dentro do seu ambiente de nuvem pública (independente do provedor), os diversos workloads que estarão sendo executados precisarão de uma forma para autenticar e autorizar o consumo dos seus serviços e dos recursos de plataforma. Esses dois processos se dão por meio das chamadas Identidades de Aplicação (ou Workload IDs).

Ter bem estabelecida uma boa estratégia de autorização na sua organização é essencial para a boa manutenção do seu ambiente e para a aplicação do Zero Trust, por isso é de extrema importância que os times de segurança e arquitetura definam os baselines para uso dessas identidades e as melhores práticas de acordo com o fornecedor e com a empresa.


Estratégias para a proteção das identidades

Como qualquer identidade, o IdP (Identity Provider) necessita de algumas informações para validar a veracidade daquele recurso. Se tratando do Microsoft Entra ID (Identity Provider da Microsoft), nós temos duas maneiras de identificar o nosso workload id:

  • Object ID + Secret

  • Object ID + Certificate

As duas formas tem seus pontos positivos e negativos, vamos comentar sobre eles agora e entender melhor esses pontos e as características de cada um dos métodos.

Secret

Os segredos (também conhecidos como "senhas") são utilizados pela aplicação em questão para autenticar a chamada frente ao Identity Provider. Em todas as requisições, tanto o Object ID (que representa a aplicação perante do IdP) quando o Secret, devem ser transmitidos, para que o provedor de identidade consiga validar a veracidade daquela chamada.

As secrets são strings que apenas através da visualização a olho nu, não representam nada, porém devem ser guardadas a "sete chaves" pelos times de segurança da organização, visto que são valores sensíveis e que se expostos, poderão representar alto risco ao ambiente.

Por serem geradas diretamente no Identity Provider, a gestão das secrets pode ser considerada mais complicada pelo time de segurança, visto que novos processos e controles deverão ser implementados para identificar a expiração de uma secret, sendo necessário renová-la antes da expiração para evitar a interrupção nos serviços que utilizam aquelas credenciais.

Outro problema frequentemente enfrentado é o envio das secrets para os repositórios de código. Por serem utilizadas direto no código, é possível que algumas secrets sejam enviadas para o repositório de código da sua organização. Isso é especialmente perigoso caso o repositório seja público, expondo a secret para qualquer um que acessar o repo. Para evitar esse problema, é importante termos dentro da pipeline de desenvolvimento, controles para identificar essas secrets que foram enviadas de maneira errônea, reduzindo ainda mais a chance de termos problemas de segurança.

Certificate

Screenshot of PEM file

Os certificados são "objetos" de segurança utilizados de diversas maneiras. Nesse caso, o utilizariamos para identificar uma identidade e garantir que a mesma é valida dentro do nosso tenant.

Diferente dos segredos, um certificado não é apenas uma string, ele tem uma série de outras informações e atributos próprios, que permitem qualquer uma das partes possa identificar o certificado em questão e validar sua veracidade.

Os certificados devem ser gerados por uma autoridade certificadora confiável e devem ser carregados dentro do Microsoft Entra ID, sendo referenciados diretamente na identidade criada. Dessa forma, o identity provider consegue validar o certificado e garantir que o mesmo não tenha sido revogado.

Ainda fazendo referência aos certificados, seu uso é mais recomendado que o das secrets pois não só porque não são passados diretamente no código, mas também por conta dos processos de gestão de certificados já existentes na sua empresa. Por ser uma solução utilizada de diversas maneiras nas organizações, é costume que as empresas já tenham uma boa gestão desses objetos, pois a má gestão pode levar a interrupções nos serviços fornecidos pela organização, impactando não apenas clientes internos mas também os clientes finais.

Estratégias de proteção

Não importa se estivermos falando sobre secrets ou certificates, algo imprescindível é a boa gestão de expiração e distribuição desses objetos. Visando manter seus serviços disponíveis e sem interrupções, identificar quando um objeto estiver próximo da expiração permitirá que os times de segurança e engenharia atualizem o recurso em questão (manualmente ou via automação). O envio de alertas quando o objeto estiver próximo do vencimento facilitará esse trabalho.

Aplicar regras de acesso condicional pode reduzir drasticamente a possibilidade de uso de uma credencial comprometida. Criar regras referêntes à localização de onde vem a requisição possibilitará a recusa de conexões vindas de localidades não reconhecidas. Isso pode ser feito utilizando as Named Locations do Entra, que permitem o cadastro de ranges de IP para que possam ser utilizados posteriormente dentro das políticas de acesso condicional.

Como qualquer identidade dentro do Entra, as workload IDs também geram logs. Esses logs são objetos extremamente valiosos para o reforço da postura de identidade da organização, pois permitem validar para o que a identidade foi utilizada.


Explorando o Workload IDs do Microsoft Entra ID

Dentro do Microsoft Entra ID, as workload IDs podem ser visualizadas em um painel centralizado, parecido com esse:

Podemos visualizar a quantidade de identidades que temos dentro do nosso tenant, também separado pelo tipo de identidade.

💡
Essa seção dentro do Portal do Entra é relativamente nova, então tome seu tempo para explorá-la dentro do seu tenant e avalie tudo que ela há de oferecer.

Ter visibilidade e controle do que é criado no seu tenant é de extrema importância, para que os recursos possam ser bem governados e terem seu ciclo de vida gerenciado e acompanhado pelos times responsáveis.

Além disso, ao rolar a página para baixo, temos uma série de recomendações de melhores práticas fornecidas pela Microsoft, que podem ser acessadas e implementadas para incrementar os controles do seu ambiente.

💡
Essa visão do workload IDs é oferecida no plano free. A versão premium será tratada posteriormente em outro texto.

As identidades são o objeto central dentro da estratégia Zero Trust de todas as empresas, porém não podemos pensar que identidades são apenas de usuários humanos. Negligenciar as contas sistêmicas pode se tornar um problema de forma repentina caso sua empresa não tenha controles bem estabelecidos e ajustados.

Espero que tenha gostado do texto e que de alguma forma eu tenha conseguido contribuir com o seu planejamento de segurança.

Até logo!