> ## 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 > Boas práticas para operar o Access Manager com segurança: gerenciar credenciais, fechar os ambientes e proteger identidade e autorização em escala. O Access Manager guarda a identidade, a autorização e as credenciais de cada produto Lerian protegido. Trate-o como infraestrutura crítica e opere-o com os controles abaixo. ## Credenciais *** ### Crie credenciais para as applications chamadoras Para acesso máquina a máquina, a application chamadora usa o `client_id` e o `client_secret` dela para pedir um token. O serviço que recebe valida esse bearer token. Configure o serviço que recebe para aplicar a rota. Ele não precisa de uma segunda credencial M2M para a mesma chamada. ### Proteja o ambiente de deploy Proteja os hosts, os segredos de deploy e o acesso de administrador que sustentam o Access Manager. Limite o acesso às máquinas físicas ou virtuais e aos sistemas de gestão de segredos que entregam a configuração dele. ### Limite o acesso aos endpoints de gestão de credenciais Os endpoints de gestão de identidade podem expor dados de application. Restrinja o acesso a esses endpoints e mantenha as operações de gestão sensíveis isoladas dos fluxos gerais de back-office. ## Recomendações de segurança *** ### Use fluxos entre applications para endpoints sensíveis Para acessos críticos como a automação do Ledger, use Applications dedicadas. Isso dá a você controle claro sobre cada integração. Exclua uma application pela API do Identity documentada quando você não precisar mais dela. Trate qualquer token ou credencial existente pelo procedimento de resposta a incidentes do seu ambiente. ### Use credenciais de usuário para ações manuais Quando uma pessoa precisa de acesso para depuração, operação ou suporte, emita credenciais por usuário em vez de compartilhar `client_credentials`. Assim você consegue gerenciar o acesso e remover permissões de cada pessoa separadamente. Encerre uma sessão apenas pelo fluxo normal de logout com o `id_token_hint` daquela sessão. Esse fluxo não é um controle de "deslogar outro usuário" voltado ao administrador. Reserve `client_credentials` para applications máquina a máquina. Faça revisões de acesso regulares de applications e permissões. Isso reduz a exposição e mantém o acesso limitado aos usuários autorizados. Sempre aplique o princípio do menor privilégio tanto para usuários quanto para applications. Conceda apenas as permissões exatas de que cada um precisa. ## Mudanças operacionais *** Como você muda o acesso depende do que você muda: a operação do dia a dia ou os dados de plataforma. ### Use as superfícies de gestão depois do bootstrap Depois que o ambiente sobe, 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 applications máquina a máquina * configurar provedores e MFA. Os dados de seed do bootstrap não são uma superfície de configuração do dia a dia. Editar os arquivos de seed depois do deploy não atualiza um ambiente existente de forma confiável. ### Entregue mudanças de permissão de plataforma como atualizações controladas Recursos, ações, papéis, grupos e conjuntos de permissões nativos são dados de plataforma. Mude-os por migrações ou por um conciliador 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 divergência entre ambientes e tornam as revisões de acesso menos confiáveis. > [!TIP] > > Veja nossas [Recomendações de segurança](https://docs.lerian.studio/pt/products/midaz/security-recommendations.md) para mais orientações sobre como proteger sua infraestrutura. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.