Login compartilhado ou contas separadas? Como escolher um modelo de identidade para aplicações auto-hospedadas

A arquitetura de login se torna uma decisão operacional à medida que sua pilha cresce

Uma aplicação auto-hospedada normalmente pode ser gerenciada com contas de usuário locais. Porém, quando uma equipe opera várias aplicações, o design de login afeta mais do que a conveniência dos usuários. Ele afeta quem cria contas, com que rapidez o acesso é removido, onde os administradores mantêm acesso de recuperação e o que acontece se um serviço de login compartilhado ficar indisponível.

Um provedor de identidade compartilhado para aplicações auto-hospedadas pode reduzir o trabalho repetitivo de gerenciamento de contas. Ele também pode se tornar uma dependência crítica: se o serviço de identidade, seu processo de administração ou seu processo de recuperação falhar, os usuários poderão não conseguir acessar vários serviços ao mesmo tempo. Portanto, a escolha certa não é automaticamente “centralizar tudo”. É o modelo que sua equipe consegue operar e recuperar com segurança.

A Airbip gerencia infraestrutura em nuvem em torno de cargas de trabalho de aplicações Docker implantadas, incluindo automação de roteamento e certificados TLS, verificações de DNS, gerenciamento do ciclo de vida dos serviços e backups configuráveis. Esses serviços de infraestrutura não escolhem a fonte de identidade de uma aplicação, o modelo de permissões, o processo de recuperação de contas ou a governança de acesso. Essas continuam sendo decisões do cliente, que devem ser tomadas aplicação por aplicação.

• Trate a arquitetura de identidade como uma decisão de design operacional, e não apenas como uma preferência de tela de login.
• Avalie o impacto provável de uma indisponibilidade do serviço de identidade antes de torná-lo o ponto de entrada para todas as aplicações.
• Designe responsáveis nomeados pelas atividades do ciclo de vida dos usuários, pelo acesso privilegiado e pelos procedimentos de recuperação.
• Mantenha a decisão sobre identidade separada das decisões sobre backup da aplicação, retenção de dados, gerenciamento de sessões e autorização na aplicação.

Comece pela distinção: autenticação, autorização e funções

A autenticação responde: “Esta pessoa consegue comprovar o controle do autenticador associado a esta identidade?” O [NIST SP 800-63-4](https://pages.nist.gov/800-63-4/sp800-63.html) trata a autenticação e as decisões posteriores de autorização como etapas distintas.

A autorização responde: “O que esta pessoa autenticada pode fazer aqui?” Uma aplicação pode usar informações recebidas durante a autenticação ao tomar essa decisão, mas ainda precisa ter sua própria lógica de acesso. As funções no nível da aplicação expressam então as permissões disponíveis dentro dela, como uma função de administrador, de editor ou somente leitura.

Um login central pode estabelecer uma identidade em várias aplicações compatíveis, mas não torna inerentemente as permissões consistentes entre elas. A mesma pessoa pode, adequadamente, ser administradora em um sistema e ter acesso limitado em outro. A documentação oficial atual de cada aplicação deve ser a fonte de verdade sobre suas funções, comportamento de grupos e integrações de identidade.

• Autenticação: verifica o controle do requerente sobre um autenticador.
• Autorização: determina o acesso a um serviço ou recurso.
• Funções e grupos: representam permissões e responsabilidades específicas da aplicação.
• Sessões: regem como um navegador ou cliente autenticado permanece conectado; elas precisam de seus próprios controles e revisões.

Os três modelos de identidade viáveis

Contas locais separadas significam que cada aplicação mantém seus próprios usuários e métodos de autenticação. Esse modelo exige uma administração mais repetitiva, mas uma indisponibilidade ou problema de configuração em uma aplicação não impede automaticamente o login no restante da pilha.

Um modelo de provedor de identidade compartilhado usa federação quando há suporte: o provedor de identidade autentica a pessoa e envia uma afirmação à aplicação dependente. Os detalhes de validação da afirmação, provisionamento, criação de sessão e mapeamento de funções variam conforme a aplicação, o protocolo e a integração configurada. A federação pode reduzir a necessidade de autenticadores separados em várias aplicações e centralizar partes do gerenciamento de contas.

Um modelo híbrido combina os dois. Por exemplo, uma equipe pode usar um provedor de identidade compartilhado para aplicações que o suportam e manter contas locais cuidadosamente controladas onde uma aplicação as exige ou onde é necessário acesso administrativo de emergência. O híbrido pode ser um modelo operacional deliberado, e não uma migração incompleta.

• Contas locais: menos dependências compartilhadas; mais administração de contas em cada aplicação.
• Provedor de identidade compartilhado: um processo primário de autenticação; maior concentração de risco operacional.
• Híbrido: acomoda diferentes capacidades das aplicações enquanto preserva um caminho de contingência documentado.
• Não presuma que um produto oferece suporte a federação, provisionamento automatizado, mapeamento granular de grupos ou um protocolo específico. Confirme a documentação primária atual e sua configuração de implantação.

Quando contas separadas são a escolha mais proporcional

Contas separadas podem ser proporcionais para uma equipe pequena e estável, com um número limitado de aplicações, entradas e saídas pouco frequentes de pessoas e ninguém responsável por operar um serviço de identidade dedicado. Nessa situação, uma plataforma de identidade central pode adicionar mais trabalho de configuração, recuperação e monitoramento do que elimina.

Essa escolha depende de o trabalho repetitivo ser efetivamente controlável. Contas locais precisam de um processo claro para entradas, mudanças de função e saídas. Se a remoção de acesso depender de alguém se lembrar de cada aplicação, o modelo pode falhar silenciosamente à medida que a pilha se expande.

Aplique o princípio do menor privilégio em todas as aplicações: conceda apenas o acesso exigido para uma responsabilidade definida, mantenha contas administrativas limitadas e registre quem é responsável por cada função. Um ambiente pequeno pode usar um registro simples e uma revisão programada em vez de uma plataforma de identidade complexa, desde que o registro seja mantido atualizado.

• Considere contas locais quando o número de usuários for pequeno e as mudanças de conta forem incomuns.
• Considere contas locais quando sua equipe não tiver capacidade para administrar, proteger e recuperar um serviço de identidade compartilhado.
• Use registros de conta exclusivos em vez de um login compartilhado da equipe, para que as ações possam ser atribuídas e o acesso possa ser removido de uma pessoa.
• Mantenha um inventário de cada aplicação, responsável pela conta, conta privilegiada, contato de recuperação e data de revisão.
• Garanta que cada administrador crítico tenha um método de recuperação documentado e evite projetar a recuperação em torno de uma única pessoa.

Quando o login compartilhado se justifica

A autenticação centralizada se torna mais atraente quando a integração e o desligamento de pessoas acontecem com frequência, quando o número de aplicações torna a administração repetida pouco confiável ou quando a organização já possui controles de identidade maduros e responsabilidades administrativas claras. O benefício não é simplesmente ter menos senhas; é uma forma mais repetível de estabelecer e remover acesso aos serviços compatíveis.

A [orientação de federação do NIST SP 800-63C-4](https://pages.nist.gov/800-63-4/sp800-63c/Federation/) estabelece que uma conta da aplicação dependente deve ser provisionada antes que uma sessão autenticada possa ser criada. A aplicação também pode desabilitar ou encerrar sua conta local independentemente do provedor de identidade. Planeje os dois lados: o registro de identidade e a conta ou o registro de autorização da aplicação.

Centralize apenas onde o ganho for real. Uma aplicação que não tem integração compatível, precisa de um administrador local ou tem um ciclo de vida diferente pode permanecer local. Forçar cada serviço a passar por um único caminho de acesso pode criar soluções alternativas frágeis e obscurecer a responsabilização.

• Priorize o login compartilhado onde a rotatividade de contas torna a administração local manual propensa a erros.
• Verifique a opção exata de integração, o comportamento das funções e o método de provisionamento de contas na documentação oficial antes de se comprometer com um design.
• Defina quem pode administrar o provedor de identidade, aprovar acesso e alterar atribuições de funções nas aplicações.
• Documente como o acesso é revogado tanto no provedor de identidade quanto em cada aplicação dependente.
• Teste o efeito da indisponibilidade do provedor de identidade sobre usuários normais e administradores.

Perguntas a responder antes de centralizar a autenticação

Comece pela compatibilidade, mas não pare nela. Para cada aplicação, identifique na documentação primária atual as opções de autenticação e federação compatíveis, a configuração exigida, o comportamento de provisionamento de contas e como funcionam as exceções locais. As capacidades dos produtos podem diferir conforme o produto, a edição, a versão e a configuração de implantação.

Em seguida, projete a administração e a recuperação. A recuperação de conta é diferente da autenticação de rotina. O [NIST SP 800-63B-4](https://pages.nist.gov/800-63-4/sp800-63b/events/) identifica abordagens de recuperação que incluem códigos de recuperação salvos ou emitidos, contatos de recuperação, repetição da comprovação de identidade e métodos específicos da aplicação baseados em análise de risco documentada. O NIST também recomenda incentivar os usuários a manter pelo menos dois meios distintos de autenticação para reduzir eventos de recuperação.

Por fim, decida o que acontece se a rota normal estiver indisponível. Uma conta break-glass é um caminho de acesso administrativo de emergência, não um atalho cotidiano para contornar a governança. Ela deve ter um responsável nomeado, uso restrito, material de recuperação protegido, um procedimento de teste documentado e uma revisão após cada uso.

• Quais opções de autenticação ou federação cada aplicação oferece suporte atualmente?
• Quem é responsável pelo tenant ou serviço do provedor de identidade, por suas contas privilegiadas e pelas alterações de configuração?
• Quais contas de aplicação ainda precisam existir localmente e por quê?
• Como novos usuários são criados, mudanças de função são aprovadas e usuários desligados são removidos?
• Qual é o caminho break-glass se o provedor de identidade, uma conta de administrador ou um autenticador estiver indisponível?
• Quem detém os contatos ou materiais de recuperação e como esse acesso é protegido e testado?
• Como as sessões são encerradas ou reautenticadas quando risco ou mudanças de função exigirem isso?
• Quais evidências demonstrarão que acessos e permissões foram revisados?

A autenticação centralizada não cria permissões consistentes

Um provedor de identidade compartilhado pode proporcionar a uma pessoa uma experiência de autenticação única entre as aplicações compatíveis. Ele não define automaticamente o que essa pessoa pode fazer após o login. A [orientação de federação do NIST](https://pages.nist.gov/800-63-4/sp800-63c/Federation/) deixa a determinação de autorização e acesso no escopo da aplicação dependente.

Evite atribuir direitos administrativos amplos apenas porque um usuário entrou com sucesso pelo serviço central. Em vez disso, defina uma matriz de acesso para cada aplicação: responsabilidade de trabalho, função na aplicação, aprovador, responsável pela conta e frequência de revisão. Onde houver mapeamento de grupos ou atributos, verifique seu comportamento real na documentação atual do produto e, quando possível, teste-o com contas que não sejam de produção.

Camadas de autenticação externas também podem ter uma função restrita. Por exemplo, o [Traefik ForwardAuth](https://doc.traefik.io/traefik/middlewares/http/forwardauth/) delega a autenticação a um serviço externo e permite o acesso quando esse serviço retorna uma resposta 2XX. Isso descreve uma barreira de autenticação; não estabelece, por si só, as funções internas da aplicação, permissões de dados ou controles de ciclo de vida.

• Mantenha definições de funções específicas de cada aplicação, mesmo quando a autenticação for compartilhada.
• Exija aprovação explícita para funções privilegiadas.
• Revise os mapeamentos de grupo para função sempre que a configuração de identidade ou a configuração da aplicação mudar.
• Não trate uma barreira de autenticação de proxy reverso como um sistema de autorização completo.
• Mantenha controles de sessão e regras de acesso a dados no escopo como preocupações distintas de segurança da aplicação.

Opere o modelo com evidências, revisões e responsabilidades documentadas

Qualquer que seja o modelo escolhido, mantenha um registro de identidade aplicação por aplicação. Registre a fonte de identidade, o responsável pela aplicação, as contas privilegiadas, exceções de contas locais, contatos de recuperação, método normal de provisionamento, método de desprovisionamento e as evidências da última revisão de permissões. Isso proporciona a uma equipe em crescimento um registro operacional auditável sem presumir automação não compatível.

Estruture as revisões em torno de entradas, mudanças de função e saídas. Uma pessoa que entra precisa apenas do acesso aprovado necessário para começar o trabalho. Uma pessoa que muda de função precisa ter seus direitos antigos reavaliados conforme suas responsabilidades mudam, e não apenas receber novos direitos. Uma pessoa que sai precisa ter seu acesso removido ou desabilitado prontamente por todas as rotas relevantes, incluindo exceções locais e contas privilegiadas. Defina uma cadência com base no volume de mudanças e no risco, depois mantenha evidências de que a revisão ocorreu e de que as exceções foram resolvidas.

O [Cybersecurity Framework 2.0 do NIST](https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20) destaca a governança por meio de funções, responsabilidades, autoridades, políticas e supervisão. Aplique esse princípio de forma prática: alguém deve ser responsável pelo serviço de identidade, alguém deve ser responsável pelo modelo de autorização de cada aplicação, e os caminhos de escalonamento devem ser conhecidos antes que ocorra um bloqueio de acesso ou desligamento.

A hospedagem gerenciada de aplicações Docker pode reduzir a administração de infraestrutura em torno dos serviços implantados. Ela não substitui a engenharia de identidade ou a governança corporativa de identidade. Se a integração com diretório, obrigações regulatórias, alta disponibilidade ou requisitos formais de garantia de identidade excederem a capacidade de sua equipe, use um serviço de identidade especializado ou um acordo de hospedagem empresarial em vez de tratar uma plataforma geral de aplicações gerenciadas como uma solução completa de gerenciamento de identidade.

• Crie e mantenha um registro de identidade para cada aplicação.
• Revise o acesso após mudanças de função, e não apenas durante auditorias periódicas.
• Revise contas privilegiadas mais rigorosamente do que contas comuns.
• Documente exceções de contas locais e remova-as quando deixarem de ser justificadas.
• Teste procedimentos de recuperação e break-glass em uma cadência planejada; registre resultados e ações corretivas.
• Use a documentação oficial das aplicações e dos provedores de identidade como base para decisões de configuração e controles.
• Reavalie o modelo quando o número de aplicações, a rotatividade de pessoal, a sensibilidade dos dados ou os requisitos operacionais mudarem.