Em mais um artigo sobre segurança de identidades e acessos, vamos falar sobre o que é a autenticação baseada em certificados, quais os cenários em que pode ser utilizada e as características e peculiaridades de sua implementação. A solução base para esse artigo técnico, como sempre, será o IdP da Microsoft, o Entra ID.

Contexto

Temos notado hoje em dia que as senhas em texto plano tem entrado cada vez mais em desuso, com sua utilização desencorajada pelas principais empresas de tecnologia e orgãos reguladores. Com isso, a recomendação frequentemente vista nas empresas é do uso de passwordless, ou seja, autenticações que não requerem senha.

💡

Para mais informações sobre passwordless, veja este artigo.

Dentro das organizações é comum termos uma série de contextos referentes às identidades dos usuários. Temos dispositivos gerenciados (mobile, notebooks, desktops, tablets, etc.), redes internas (VPNs, SASEs, etc.) e escritórios, o que já nos possibilita personalizar o acesso de diferentes maneiras de acordo com o local onde o usuário está, com o dispositivo que está sendo utilizado e de acordo com outros "pontos" de informação que são retirados das suas interações com as aplicações corporativas.

Organizações com essas características estão bem postadas para utilização de autenticação passwordless, inclusive fazendo uso de certificados!

Por quê usar?

Habilitar diferentes maneiras de autenticação para seus usuários de acordo como cenário em que se encontram, deixará a jornada deles muito mais simples e agradável, permitindo que foquem na execução das atividades de negócio e trabalhem de maneira mais segura.

Os diferentes métodos de autenticação disponíveis servem para o mesmo propósito, porém fornecem ganhos diferentes. Um certificado deve ser utilizado em junção a outro fator de autenticação (como por exemplo uma leitura biométrica ou até mesmo um PIN), garantindo que o usuário que está fazendo uso daquele "objeto", é o owner do mesmo. Com os certificados em especial devemos implementar um fator de autenticação adicional, visto que o detentor do dispositivo onde o certificado está instalado, o poderá utilizar para acesso aos sistemas da organização.

Agora que entendemos a peculiaridade de utilizar um certificado como fator de autenticação, gostaria de esclarecer algo:

Um certificado não é nada além de um "objeto" que contém informações sobre um ator/agente (não necessariamente humano) e que é utilizado para provar que quem o detém, é quem diz ser. Para as autenticações, o certificado será emitido para o usuário que planeja o utilizar, não sendo válido para outros usuários.

Após esclarermos esse entendimento, vamos falar brevemente sobre como um certificado pode ser utilizado em uma autenticação.

Um usuário acessa aplicações empresariais conectadas ao Microsoft Entra ID através de dispositivos gerenciados (ou pelo menos conhecidos) pela organização. Esses dispositivos, confiáveis, contém certificados criados para o usuário e atribuídos aos dispositivos registrados em seu nome. Esse certificado, junto de outras informações de seu login, sessão, dispositivo e contexto, é utilizado nas regras de acesso condicional presentes do Entra ID da empresa.

É importante comentar que o certificado pode ser utilizado como único fator de autenticação e também como parte de uma autenticação mais rigorosa e forte, exigindo algo a mais para que consiga se autenticar corretamente na aplicação. Como você fará depende do contexto apresentado pela sua empresa, havendo a necessidade de se analisar os requisitos apresentados e de avaliar os possíveis impedimentos técnicos.

Pensando na implementação dos processos e na habilitação da tecnologia, vamos falar um pouco sobre como o Entra permite esse integração e o que deve ser feito para disponibilizá-la para seus usuários.

Entendendo a solução

Pensando em entender melhor como funciona o fluxo de autenticação de um usuário que utilizará um certificado, podemos ter como base a seguinte imagem:

No momento da autenticação do usuário no Entra ID, o browser disponibiliza uma caixa de seleção ao usuário para que o mesmo possa selecionar o certificado desejado dos presentes no dispositivo. Uma vez selecionado, certos campos do certificado são validados de acordo com as regras definidas no próprio IdP. Essa validação faz o match das informações da conta do usuário no Entra e do certificado utilizado. Esse processo de matching de atributos do certificado com a conta do usuário é chamado de binding. A imagem abaixo oferece uma visão de alguns bindings pré-configurados:

Como podemos ver na imagem acima, na seção username binding é onde devemos configurar o Entra para referenciar alguns campos do certificado com alguns campos do usuário.

A coluna "Affinity binding" define a "força" do atributo que será utilizado no binding, classificando alguns campos como "baixos" e alguns como "altos".

Acima estão listados os campos do certificado que podem ser selecionados e qual a "força" de cada um deles. Entenda que por "High affinity - alta afinidade" nós temos campos que são mais confiáveis e por isso tem valor maior no momento de autenticação do usuário.

Esses bindings são importantes pois no momento de autenticação do usuário perante o Entra, os valores cadastrados no binding serão validados e levados em conta no momento da avaliação do processo de autenticação.

A imagem abaixo mostra a visão de uma autenticação via certificado rejeitada pelo Entra.

Microsoft Entra certificate-based authentication technical deep dive - Microsoft Entra ID | Microsoft Learn

Os problemas podem ser dos mais variados, affinity bindings configurados de maneira errônea, certificado vencido, problemas com o certificado, entre outras. Ao receber um erro em seu processo de autenticação, valide o passo a passo realizado, conferindo todas as etapas do processo.

Pontos de preocupação

Como qualquer solução, além de seus pontos positivos, é necessário jogar luz nos pontos negativos.

Os certificados são extremamente úteis em diversos cenários, mas se implementados de maneira incorreta ou sem os devidos processos definidos, podem apresentar grande risco à sua organização.

Para que sua implementação tenha sucesso, os processos relacionados à gestão do ciclo de vida dos certificados devem estar maduros e eficientes. É importante que um certificado seja atualizado quando estiver próximo de seu vencimento, que um usuário desligado da organização tenha seu certificado invalidado (o proibindo de utilizá-lo em autenticações subsequentes), que os times de gestão tenham o histórico e as informações relacionadas aos certificados gerados e que todo o processo, desde a geração até a entrega do objeto seja automatizado e "limpo". Por se tratar de algo que impactará diretamente no dia a dia de trabalho dos funcionários, interrupções no processo e demora nas entregas poderão ser os grandes culpados da improdutividade das equipes, tornando assim a solução inviável.

Outro ponto importante e que foi mencionado anteriormente é a necessidade de se utilizar o certificado em junção a outra solução. Por estarem "presos" aos dispositivos, um usuário em posse daquela plataforma oferece grande risco aos ativos ali gerenciados. Combinar a autenticação baseada em certificado com uma leitura biométrica do windows hello for business ou com uma chave FIDO2 ou até com um push gerado pelo Microsoft Authenticator no dispositivo móvel do usuário, reduzirá os riscos exponencialmente, mantendo a experiência agradável e tornando o ambiente mais seguro.

O processo de autenticação da sua empresa não precisa ser moroso e complicado para ser seguro. Utilizando das tecnologias corretas e de processos bem implementados, a experiência dos usuários pode ser muito agradável e com segurança end-to-end.

Espero que tenha gostado do artigo e que de alguma forma eu tenha contribuido para a melhora da postura de segurança em seu ambiente.

Até logo!