Boas práticas

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ê está mudando, e a linha passa entre a operação do dia a dia e 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.