Pular para o conteúdo principal
O Access Manager guarda a identidade, a autorização e as credenciais de todo produto Lerian protegido, o que o torna uma das peças mais sensíveis da sua stack. Trate-o como infraestrutura crítica e opere-o com os controles abaixo.

​
Credenciais

​
Crie credenciais em ambas as pontas

Se dois serviços precisam se comunicar, ambos devem ter as credenciais M2M necessárias criadas. Não assuma simetria. Defina credenciais explicitamente nos dois lados.

​
Blinde o ambiente físico

O Access Manager armazena credenciais localmente. Qualquer pessoa com acesso ao host pode extraí-las. Proteja a máquina física ou virtual que hospeda o serviço. Esta é sua primeira linha de defesa.

​
Evite expor endpoints que recuperam credenciais

Administradores no Access Manager (via Identity) podem recuperar credenciais. Por isso, esses endpoints não devem ser integrados a nenhum sistema de back-office. Mantenha operações sensíveis isoladas para reduzir a chance de exposição acidental.

​
Recomendações de segurança

​
Use fluxos Application-to-Application para endpoints sensíveis

Para acessos críticos, como a automação do Ledger, use Applications. Isso dá controle claro sobre cada credencial. Se algo vazar, você pode revogar ou excluir a Application sem afetar usuários ou serviços não relacionados.

​
Use credenciais baseadas em usuário para ações manuais

Quando o acesso humano é necessário (para debugging, operações ou suporte), emita credenciais por usuário em vez de compartilhar client_credentials, para que você possa gerenciar o acesso, revogar permissões e forçar logouts de cada pessoa através do endpoint apropriado. Para o fluxo de login, siga a orientação de segurança OAuth vigente: o grant de credenciais de senha do proprietário do recurso (password) não deve ser usado (RFC 9700) — prefira um fluxo de código de autorização interativo com PKCE. Reserve client_credentials para aplicações máquina a máquina. Implemente uma política de rotação de credenciais e realize revisões de acesso regulares. Isso minimiza a exposição e mantém o acesso limitado a usuários autorizados. Sempre aplique o princípio do menor privilégio tanto para usuários quanto para aplicações. Conceda apenas as permissões exatas que cada um precisa.

​
Mudanças operacionais

Como você altera o acesso depende do que está alterando, e a linha divisória corre entre operações do dia a dia e dados da plataforma.

​
Use as superfícies de gerenciamento após o bootstrap

Com o ambiente em execução, use as APIs do Identity ou o Lerian Console para mudanças operacionais de acesso:
  • criar, atualizar ou remover usuários;
  • atribuir usuários a grupos;
  • criar ou excluir aplicações machine-to-machine;
  • rotacionar credenciais;
  • configurar providers e MFA.
Os dados de seed do bootstrap não são uma superfície de configuração do dia a dia. Editar arquivos de seed após o deploy não atualiza de forma confiável um ambiente existente.

​
Entregue mudanças de permissão da plataforma como atualizações controladas

Resources, actions, roles, groups e permission sets nativos são dados da plataforma. Altere-os por migrations ou por um reconciler idempotente para que os ambientes existentes convirjam de forma previsível. Evite edições pontuais no banco de dados e mudanças manuais de permissão. Elas criam drift entre ambientes e tornam as revisões de acesso menos confiáveis.
Consulte nossas Recomendações de Segurança para mais orientações sobre como proteger sua infraestrutura.