Porque proteger uma palavra-passe se é possível dispensá-la?

Um problema que nos habituámos a considerar normal

Praticamente todas as aplicações Web têm um painel de administração. E, regra geral, o painel de administração tem um endereço de acesso, um formulário de autenticação, um nome de utilizador e uma palavra-passe.

Habituámo-nos tanto a esta estrutura que praticamente deixámos de nos perguntar: será que tudo tem mesmo de funcionar assim?

Quando temos um único site, o problema não parece significativo. Criamos uma palavra-passe complexa, ativamos a autenticação de dois fatores, configuramos um limite de tentativas de início de sessão — e seguimos com o trabalho.

Mas o que acontece quando passamos a ter dez, vinte ou trinta projetos?

No meu caso, trata-se do ecossistema DigiMeld, que reúne mais de trinta projetos de software independentes. Cada um tem a sua própria arquitetura, lógica de servidor e interface de administração.

Por conseguinte, cada um precisa de um mecanismo de acesso administrativo.

Durante muito tempo, usei uma abordagem bastante habitual: credenciais administrativas separadas, palavras-passe complexas e o seu armazenamento no navegador.

Funcionava.

Mas, a certa altura, comecei a pensar: porque é que tenho de guardar tantas palavras-passe administrativas? Porque tenho de proteger não só os servidores, mas também os próprios meios de lhes aceder?

E será que não posso dispensar essa necessidade?

Cheguei a uma ideia que, mais tarde, se tornou a base da minha solução:

Talvez devamos proteger não um acesso permanente, mas o próprio direito a obter acesso temporariamente.

E se não houvesse sequer uma página de início de sessão convencional?

Decidi abandonar o modelo tradicional de autenticação administrativa nos meus projetos.

Não me limitei a esconder o formulário de início de sessão.

Não mudei o endereço.

Não substituí a palavra-passe por outra ainda mais complexa.

Eliminei a própria necessidade de existir permanentemente um acesso por palavra-passe.

Naturalmente, as interfaces de administração não desapareceram. Continuam a ser necessárias para gerir as aplicações.

O que mudou foi a forma de lhes aceder.

Agora, para entrar nos painéis de administração dos projetos ligados, não é necessário introduzir um nome de utilizador e uma palavra-passe guardados.

Em vez disso, utilizo o meu próprio sistema de identificação e gestão de acessos, o MeldID.

A ideia é bastante simples: o acesso administrativo é concedido apenas quando é realmente necessário, a um utilizador específico e para um projeto específico.

E o simples facto de ter uma conta não significa que se tenha o direito de abrir o painel de administração.

Esse direito tem de ser concedido separadamente.

Um acesso que não existia há um minuto

Esta é, talvez, a parte mais interessante de todo o conceito.

No modelo tradicional, o administrador tem sempre meios de acesso à sua disposição. Pode utilizá-los hoje, amanhã ou daqui a um mês, enquanto continuarem válidos.

Decidi mudar este princípio.

Em vez de credenciais administrativas permanentes, existe a possibilidade temporária de iniciar sessão.

Esta possibilidade é criada a pedido através de um dispositivo móvel de confiança, inclui um componente aleatório criptograficamente robusto e tem um prazo de validade limitado.

Mas nem sequer ter acesso a essa ligação temporária significa, por si só, obter acesso.

Este é um ponto fundamental.

Suponhamos que alguém obtém a ligação de alguma forma. Num sistema convencional, baseado exclusivamente no sigilo do endereço, essa fuga poderia tornar-se um problema grave.

No meu modelo, a ligação apenas permite iniciar o processo de confirmação.

Para continuar, é necessária uma autorização separada através de um dispositivo móvel de confiança com o MeldID.

Sem a confirmação correspondente, não é criada uma sessão administrativa.

É por isso que encaro a ligação temporária não como um substituto da palavra-passe, mas como um dos elementos do processo de concessão de acesso.

Saber onde pedir acesso e ter o direito de entrar são coisas completamente diferentes.

O telemóvel torna-se uma ferramenta de gestão de acessos

Neste modelo, o dispositivo móvel desempenha um papel muito mais importante do que o de um gerador comum de códigos de utilização única.

É utilizado para confirmar ações relacionadas com o acesso administrativo.

Quando quero abrir o painel de administração, o sistema solicita uma confirmação através do MeldID.

Vejo o pedido correspondente no dispositivo de confiança e confirmo a ação.

Só depois de a verificação ser concluída com êxito é que o sistema permite continuar o processo de início de sessão.

A confirmação está associada a uma ação específica, e não apenas ao facto de o telemóvel ter sido desbloqueado.

A biometria móvel permite verificar o utilizador localmente, enquanto o servidor verifica a confirmação criptográfica do dispositivo registado.

Esta abordagem permite não depender exclusivamente de uma palavra-passe ou de uma mensagem a indicar que o utilizador alegadamente confirmou o início de sessão.

E surge aqui outra vantagem: é possível gerir os dispositivos de confiança.

Se um dispositivo deixar de poder ser utilizado para confirmar o acesso, é possível revogar o seu estatuto de confiança.

A partir daí, deixa de ser um meio válido de autorização para as operações correspondentes.

Um sistema — muitos projetos independentes

Quando comecei a desenvolver este mecanismo, um dos principais objetivos era preservar a independência de cada projeto.

Não queria reunir todos os painéis de administração numa única aplicação gigantesca.

Cada serviço DigiMeld devia continuar a gerir a sua própria lógica, configurações, utilizadores e dados.

Por isso, separei duas tarefas.

O MeldID é responsável pela identificação e pela concessão de autorização administrativa.

O próprio projeto é responsável pelas suas funções de administração e pela verificação das permissões em vigor.

Assim, obtive um modelo centralizado de gestão de acessos, sem necessidade de centralizar as próprias aplicações.

Além disso, as permissões são concedidas separadamente.

O administrador de um projeto não obtém automaticamente acesso aos restantes só por ter uma conta MeldID.

É possível definir um conjunto próprio de utilizadores autorizados para cada área administrativa.

As permissões dos utilizadores comuns e os privilégios administrativos também são mantidos separadamente.

Isso revelou-se especialmente prático para um ecossistema com dezenas de serviços.

Porque prefiro o acesso temporário ao permanente

Há ainda outro princípio que incorporei deliberadamente no sistema.

O acesso administrativo não deve durar indefinidamente.

A autorização é válida durante um período limitado e termina independentemente de o utilizador continuar ou não a trabalhar no navegador.

Para continuar a trabalhar depois de o prazo expirar, é necessário iniciar um novo processo de confirmação.

Assim, uma autorização concedida uma vez não se transforma num direito permanente.

Mas limitar o tempo, por si só, não é suficiente.

É importante poder terminar antecipadamente o acesso já concedido.

Por isso, o MeldID inclui a revogação centralizada das autorizações administrativas.

Quando uma autorização é revogada, os projetos ligados recebem o evento correspondente e invalidam as sessões administrativas associadas.

Desta forma, a gestão de acessos não termina no momento em que o utilizador inicia sessão com êxito.

Para mim, a possibilidade de revogar privilégios é tão importante como a possibilidade de os conceder.

Ao mesmo tempo, um sistema distribuído tem de ter em conta atrasos na transmissão de eventos, indisponibilidade temporária de determinados componentes e outras circunstâncias operacionais. O prazo de validade das sessões funciona como uma salvaguarda adicional.

E o que mudou no trabalho do dia a dia?

Antes de mais, deixou de ser necessário recorrer constantemente às palavras-passe administrativas guardadas.

Já não preciso de manter no navegador um conjunto de credenciais para iniciar sessão em cada painel de administração ligado.

Em vez disso, faço a gestão das autorizações através de um mecanismo único.

Seleciono o projeto necessário, confirmo o acesso e trabalho.

Quando o acesso administrativo deixa de ser necessário, pode ser revogado.

É especialmente prático não ser necessário voltar a conceber todo o sistema de autenticação administrativa sempre que surge um novo projeto.

Basta ligá-lo ao modelo existente e definir as autorizações necessárias.

Naturalmente, isto não significa que todos os riscos de segurança tenham desaparecido.

As autorizações temporárias, os dispositivos de confiança, as sessões do servidor e a infraestrutura central também precisam de proteção.

Mas já não tenho de resolver o mesmo problema de gestão de palavras-passe administrativas separadamente para cada aplicação.

E esse era um dos meus objetivos iniciais.

Mas estas tecnologias já não existem?

Claro que existem.

A autenticação sem palavra-passe, a gestão de acessos privilegiados, as autorizações temporárias e a confirmação através de dispositivos de confiança são há muito conhecidas na indústria da segurança da informação.

Estas abordagens encontram-se em sistemas de Identity and Access Management, Privileged Access Management e nos conceitos de Zero Trust.

Não reivindico a invenção destes princípios.

O meu objetivo era outro.

Precisava de criar um sistema integrado próprio que resolvesse problemas específicos da infraestrutura DigiMeld e permitisse gerir o acesso administrativo a muitos projetos independentes.

O resultado foi a combinação de várias abordagens conhecidas numa única arquitetura, adequada às minhas necessidades.

E considero que o valor do trabalho de engenharia não reside necessariamente em inventar uma tecnologia completamente nova.

Por vezes, reside em formular corretamente o problema e encontrar uma solução adequada.

O MeldID não serve apenas para painéis de administração

Importa fazer aqui uma ressalva.

O MeldID não foi criado exclusivamente como ferramenta para o meu próprio acesso administrativo.

Também disponibiliza aos programadores um SDK para integrar mecanismos de identificação e confirmação de início de sessão nas suas próprias aplicações.

E esse SDK está disponível gratuitamente.

Por exemplo, um programador externo pode usar o MeldID como uma camada adicional de confirmação da autenticação dos utilizadores.

Mesmo que a aplicação mantenha o início de sessão tradicional com nome de utilizador e palavra-passe, a introdução correta destes dados pode não ser suficiente para concluir a autenticação.

O utilizador recebe um pedido num dispositivo móvel de confiança, onde pode confirmar ou rejeitar a tentativa de início de sessão.

Isto permite reduzir o risco de acesso não autorizado caso as credenciais sejam comprometidas.

É importante distinguir esta funcionalidade do MeldID, disponível ao público, do modelo de acesso administrativo que desenvolvi para os projetos DigiMeld.

Ambos utilizam princípios comuns de confiança e confirmação de ações, mas resolvem problemas diferentes.

Segurança não é apenas proteger o que já existe

O trabalho neste sistema levou-me a olhar de outra forma para os mecanismos de autenticação habituais.

Muitas vezes, tentamos proteger algo que existe por razões históricas.

Acrescentamos novas verificações, restrições, palavras-passe adicionais e camadas de proteção.

Por vezes, isso é realmente necessário.

Mas, por vezes, é mais útil fazer uma pergunta diferente:

Será que o próprio mecanismo que estamos a proteger tem mesmo de continuar a existir na sua forma atual?

No meu caso, a resposta foi não.

Não precisava de um formulário de acesso administrativo sempre disponível.

Precisava de poder obter privilégios administrativos de forma segura, precisamente quando fossem necessários.

São duas tarefas diferentes.

E a passagem da primeira para a segunda alterou não só a arquitetura técnica, mas também o trabalho quotidiano com os projetos.

Não é um ponto final, mas uma direção escolhida

Atualmente, esta arquitetura já funciona numa parte significativa do ecossistema DigiMeld.

Os projetos restantes estão a ser gradualmente migrados para o novo modelo de acesso administrativo.

Estou a realizar a migração por etapas, verificando o funcionamento de cada aplicação e, depois de concluída a transição, planeio fazer uma auditoria adicional a todo o sistema.

Alguns elementos da interface e regras de gestão de sessões ainda podem mudar.

Mas a ideia principal já está definida.

Não quero voltar a um modelo em que preciso de guardar e utilizar permanentemente dezenas de palavras-passe administrativas para gerir dezenas de projetos próprios.

Ao mesmo tempo, não considero que a minha implementação seja uma solução universal para todos.

As diferentes organizações têm necessidades, infraestruturas, modelos de ameaças e formas de administração distintos.

O que é prático e adequado para o ecossistema DigiMeld pode não ser a solução ideal para outro programador.

No entanto, o próprio princípio de conceder privilégios temporariamente merece atenção.

Em jeito de conclusão

Decidi partilhar esta experiência não por me considerar o inventor de um novo método de autenticação.

Nem por querer apresentar mais um sistema como absolutamente seguro.

A segurança absoluta não existe.

Simplesmente, parece-me interessante a própria forma de colocar a questão.

Em vez de proteger indefinidamente um acesso administrativo permanente, podemos reavaliar se ele precisa de existir.

Em vez de guardar muitas palavras-passe, podemos usar autorizações temporárias.

Em vez de confiar automaticamente após a primeira autenticação, podemos confirmar a concessão de privilégios específicos.

Em vez de esperar que a sessão termine, podemos prever a possibilidade de revogar o acesso de forma centralizada.

E, finalmente, em vez de ter um mecanismo de início de sessão separado em cada projeto, podemos criar um sistema unificado de gestão de autorização administrativa, preservando a independência das aplicações.

Não afirmo que esta abordagem elimine a possibilidade de comprometimento.

Limita-se a transferir o foco da proteção de credenciais permanentemente existentes para a concessão e revogação controladas de privilégios.

Talvez, por vezes, a forma mais eficaz de reduzir a superfície de ataque não seja acrescentar mais um mecanismo de proteção, mas sim prescindir daquilo sem o qual o sistema consegue perfeitamente funcionar.

Foi precisamente com esta ideia que começou, para mim, a história do MeldID Admin Gateway.