> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Boas práticas > Opere o Access Manager com segurança — gerencie credenciais, blinde ambientes e proteja identidade e autorização em escala. 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](https://www.rfc-editor.org/rfc/rfc9700.html#section-2.4)) — 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](/pt/midaz/security-recommendations) para mais orientações sobre como proteger sua infraestrutura.