> ## 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. # O que é Access Manager? > Controle o acesso de pessoas e máquinas em todos os produtos Lerian com Auth, Identity e aplicação de autorização em nível de produto. Toda requisição a um produto Lerian levanta duas perguntas: quem está fazendo essa requisição e o que essa pessoa tem permissão para fazer? A autenticação responde à primeira; a autorização, à segunda. O **Access Manager** cuida das duas. O **Access Manager** é a camada de controle de acesso da Lerian para nossos produtos e plugins. Em vez de embutir identidade e permissões em cada produto, você gerencia tudo em um só lugar: quem são seus usuários, quais tokens eles carregam e o que esses tokens podem alcançar. Operadores, administradores e integrações máquina-a-máquina passam todos pelo mesmo portão, e cada um acessa apenas os recursos para os quais tem autorização. Por baixo dos panos, dois serviços fazem o trabalho, e os produtos protegidos se conectam a eles no nível da rota: * **Auth** opera o lado ativo do acesso: emite e renova tokens, valida sessões, verifica permissões, trata logout e informações de usuário e executa desafios de MFA. * **Identity** mantém os dados por trás dessas decisões: usuários, grupos, aplicações, provedores de comunicação, vínculos entre aplicações e providers e configuração de MFA. Quando uma requisição chega a um produto protegido, o Access Manager a confere contra o subject, o recurso e a ação antes que qualquer lógica de negócio rode. Um operador de back-office em um grupo como `midaz-viewer-group` consegue ler dados do Midaz, mas não consegue alterá-los. Uma integração de serviço que autentica com client credentials recebe exatamente o acesso máquina-a-máquina que foi configurado para ela. **Teste o Access Manager localmente** Execute os plugins da Lerian sem fazer deploy no Kubernetes usando nosso [repositório plugins-docker-compose](https://github.com/LerianStudio/plugins-docker-compose). Lembre-se de que esses serviços requerem uma licença válida para funcionar. Sem ela, a aplicação não iniciará. Para detalhes sobre licença, consulte nossa [documentação de Licença](/pt/reference/lerians-license). ## Por que usar o Access Manager? *** Use o Access Manager quando quiser controle de acesso nativo e refinado em todos os produtos Lerian, em vez de montar algo produto por produto. Ele permite que você: * gerencie usuários humanos e os grupos de produto que definem o acesso deles; * crie aplicações máquina-a-máquina para integrações de serviço; * aplique permissões até o nível do recurso e da ação, como `reports:get`, `templates:post` ou `accounts:patch`; * aplique um único modelo de controle de acesso a todos os produtos Lerian que você executa; * mantenha as APIs dos produtos protegidas atrás de bearer tokens e verificações no nível da rota. Como ele se encaixa na sua stack depende de como você faz o deploy: * Em **deployments SaaS**, ele é a camada de acesso da plataforma. As claims do JWT carregam o subject autenticado e o contexto de tenant dos quais a plataforma depende. * Em **deployments BYOC multi-tenant**, o contexto de tenant vem de claims de token confiáveis, nunca de payloads de requisição ou headers arbitrários. * Em **deployments BYOC single-tenant**, talvez você já execute seu próprio identity provider. Mesmo assim, o Access Manager pode adicionar autorização nativa da Lerian e credenciais de aplicação onde quer que você precise desse controle. O Access Manager está disponível como funcionalidade opcional no **modelo Enterprise**. Se você quiser saber mais ou avaliá-lo para seu caso de uso, [entre em contato com nossa equipe](https://lerian.studio/contact). ## Especificações técnicas *** O que você recebe out of the box: * APIs REST para operações de [Auth](/pt/reference/access-manager/am-auth-apis) e [Identity](/pt/reference/access-manager/am-identity-apis). * Configurações do Lerian Console para gerenciamento visual de usuários e aplicações suportado. * Aplicação de autorização em nível de produto para APIs HTTP e gRPC protegidas. * Feature flag `PLUGIN_AUTH_ENABLED` para habilitar a aplicação de autorização em nível de produto. * Fluxos de token OAuth2/OIDC para acesso por password e client credentials. * Suporte a MFA nos fluxos de autenticação de usuários. * Cache com Valkey para operações de token, permissão e MFA. * RBAC alinhado com recursos, ações, grupos e aplicações máquina-a-máquina dos produtos. ## Bootstrap e operação *** O Access Manager tem duas camadas distintas de ciclo de vida, e mantê-las separadas evita problemas depois: | Camada | Para que serve | | --------- | ------------------------------------------------------------------------------------------------------------------------------ | | Bootstrap | Configuração inicial do ambiente, incluindo organizações base, roles, grupos, aplicações e conjuntos de permissões integrados. | | Operação | Gerenciamento do dia a dia de usuários, atribuições de grupo, aplicações, providers, MFA e revisões de acesso. | O bootstrap é o que popula um ambiente novo em folha. Uma vez que esse ambiente está rodando, ele deixa de ser o lugar onde você faz mudanças. Para o passo a passo, em nível de operador, de deixar Auth e Identity prontos antes que qualquer produto aplique acesso, consulte [Instalando o Access Manager](/pt/platform/access-manager/installing-access-manager). A partir daí, gerencie o acesso pelas APIs do Identity ou pelo Lerian Console. O Console cobre o trabalho cotidiano de usuários e aplicações: criar usuários, atribuir grupos, atualizar senhas e criar aplicações máquina-a-máquina. As APIs do Identity dão a você toda a superfície operacional, incluindo providers, vínculos entre aplicações e providers e MFA. Recursos, ações, roles e conjuntos de permissões integrados são outra história. Entregue mudanças neles por meio de atualizações controladas da plataforma, como migrations ou um reconciler idempotente, e não edite os dados de seed do bootstrap para alterar o acesso em um ambiente que já está rodando. ## Comportamento multi-tenant *** Em deployments SaaS e BYOC multi-tenant, o tenant faz parte de quem é o chamador, não é algo que ele envia. O Access Manager o lê de claims de JWT confiáveis nos fluxos de usuário e da organização da aplicação nos fluxos máquina-a-máquina. Os clientes nunca enviam a posse do tenant em payloads, query parameters ou headers. Isso molda o comportamento em três pontos: * **Gerenciamento de identidade** — as APIs de usuário, grupo e aplicação retornam apenas registros da organização tenant do chamador. * **Autenticação** — os fluxos de password e refresh token mantêm o tratamento de token restrito ao tenant carregado pelo contexto do usuário. * **Autorização** — as verificações de permissão avaliam apenas os grupos, roles e permissões de aplicação que pertencem ao tenant resolvido. Deployments single-tenant pulam tudo isso e recorrem à organização padrão configurada. Não reutilize um token de um tenant para gerenciar usuários, aplicações ou permissões em outro. O Access Manager restringe essas operações ao contexto autenticado. ## Casos de uso *** O Access Manager se encaixa em cenários como: * Equipes que querem autenticação e autorização integradas em todos os produtos Lerian. * Organizações sem uma solução IAM pré-existente. * Equipes que já executam um identity provider, mas ainda precisam de autorização em nível de produto. * Integrações que dependem de acesso máquina-a-máquina seguro. * Deployments multi-produto que precisam de um modelo de acesso consistente para usuários, serviços e tenants. [Explore a API do Access Manager](/pt/reference/access-manager/am-api-introduction). Consulte os endpoints para usuários, grupos, aplicações e permissões.