Pular para o conteúdo principal

Arquitetura do Apono

Visão Geral​

O Apono segue uma arquitetura SaaS com agentes leves (connectors) implantados na infraestrutura do cliente. O plano de controle fica na nuvem do Apono, enquanto os conectores fazem a ponte entre o Apono e os recursos da sua infraestrutura.

Componentes Principais​

Apono Cloud (Plano de Controle)​

O plano de controle é o coração do Apono e roda inteiramente na infraestrutura gerenciada pela Apono (SaaS). Ele é responsável por:

  • Access Engine: Motor de decisão que avalia solicitações de acesso contra as políticas definidas (Access Flows). Decide se o acesso deve ser aprovado automaticamente, encaminhado para aprovação manual ou negado.
  • Access Flows (Políticas): Regras que definem quem pode solicitar o quê, com qual nível de acesso, por quanto tempo, e quem aprova. São configuradas pelo time de segurança através do dashboard.
  • Audit Log: Registro imutável de todas as solicitações, aprovações, concessões e revogações de acesso. É a base para relatórios de compliance.
  • Dashboard: Interface web para configuração de políticas, visualização de acessos ativos, relatórios de auditoria e gerenciamento de conectores.

Apono Connector (Agente)​

O connector é um componente leve implantado dentro da infraestrutura do cliente — geralmente como um container em Kubernetes, uma instância EC2, ou uma VM. Ele é o ponto de comunicação entre o plano de controle do Apono e os recursos da infraestrutura.

Características importantes do connector:

  • Comunicação outbound: O connector inicia a comunicação com o Apono Cloud (saída), nunca o contrário. Isso significa que não é necessário abrir portas de entrada no firewall ou expor recursos internos à internet.
  • Sem armazenamento de credenciais no Apono: O connector utiliza as credenciais locais (IAM roles, service accounts, managed identities) para interagir com os recursos. As credenciais não saem da infraestrutura do cliente.
  • Leve e stateless: O connector não armazena estado localmente. Toda a lógica de decisão e auditoria permanece no plano de controle.
  • Alta disponibilidade: É possível implantar múltiplos connectors para redundância.

Integrações com Identity Providers​

O Apono se integra com provedores de identidade para autenticação e para entender a estrutura organizacional (quem pertence a qual time, qual é o gestor de cada pessoa):

  • Okta, Azure AD (Entra ID), Google Workspace: Sincroniza usuários, grupos e hierarquias.
  • SAML / OIDC: Suporte a protocolos padrão para autenticação SSO.
  • SCIM: Provisionamento automático de usuários — quando alguém é adicionado ou removido no Identity Provider, o Apono reflete automaticamente.

Essa integração é fundamental para que os Access Flows funcionem corretamente, porque o Apono precisa saber quem pertence a qual grupo e quem é o gestor de quem — informações que vêm diretamente do Identity Provider.

Na prática, cada Access Flow define não só quem pode solicitar e a qual recurso, mas também quem são os aprovadores. Isso é configurável por time e por recurso. Alguns exemplos:

  • O time backend-team solicita acesso ao banco de produção → aprovação do tech lead do time.
  • O time infra-team solicita acesso a uma instância EC2 via SSM → aprovação automática (sem aprovação manual, pois é acesso de baixo risco para esse time).
  • Qualquer pessoa solicita acesso admin ao cluster Kubernetes de produção → aprovação do gestor direto + time de segurança.
  • Acesso emergencial (break-glass) → aprovação automática com auditoria reforçada.

Os aprovadores podem ser definidos de diferentes formas:

  • Gestor direto: O Apono consulta a hierarquia do Identity Provider para identificar automaticamente quem é o gestor do solicitante.
  • Pessoas específicas: Você define uma lista fixa de aprovadores (ex: "Maria e João aprovam acessos ao banco de produção").
  • Proprietários do recurso (resource owners): O dono do recurso recebe a notificação e decide.
  • Aprovação automática: Para acessos de baixo risco, a aprovação é concedida automaticamente sem intervenção humana.

Essa flexibilidade permite que cada time tenha seu próprio fluxo de aprovação, adequado ao nível de risco e à estrutura organizacional.

O Problema da Aprovação Automática pelos Líderes​

Na prática, existe um risco real quando a aprovação depende exclusivamente dos líderes de time: eles tendem a aprovar tudo. O líder conhece seu time, confia nos seus engenheiros e quer desbloquear o trabalho o mais rápido possível. O resultado é que a aprovação vira uma formalidade — o líder clica em "aprovar" sem questionar o motivo ou avaliar o risco.

Isso é especialmente problemático em acessos sensíveis como produção, bancos de dados críticos ou permissões administrativas. Um líder que aprova tudo anula o propósito do fluxo de aprovação.

Para organizações que possuem um time de segurança voltado para IAM, o ideal é que esse time participe do fluxo de aprovação como uma camada obrigatória. O Apono permite configurar aprovações em múltiplos níveis, onde todos os níveis precisam aprovar para o acesso ser concedido:

  • Nível 1 — Líder do time: Valida que a solicitação faz sentido do ponto de vista técnico e de negócio.
  • Nível 2 — Time de segurança (IAM): Avalia o risco, verifica se o nível de acesso solicitado é adequado e se a justificativa é válida.

Dessa forma, mesmo que o líder aprove sem questionar, o time de segurança atua como um gate de controle que garante a governança. Alguns exemplos de como configurar isso:

  • Acesso read-only a ambientes de dev/staging → aprovação apenas do líder (baixo risco).
  • Acesso read-only a produção → aprovação do líder + notificação ao time de segurança.
  • Acesso write/admin a produção → aprovação do líder + aprovação obrigatória do time de segurança.
  • Acesso a bancos de dados com dados sensíveis (PII/financeiros) → aprovação do líder + aprovação do time de segurança + justificativa obrigatória.

O objetivo não é burocratizar o processo, mas garantir que acessos de alto risco passem por quem realmente entende o impacto. Acessos de baixo risco podem continuar fluindo rapidamente, enquanto os sensíveis recebem a atenção que merecem.

Modelo de Segurança​

A arquitetura do Apono foi desenhada com foco em segurança:

  • Zero trust: O connector não tem acesso direto ao plano de controle além do necessário. A comunicação é criptografada (TLS) e autenticada.
  • Credenciais nunca saem do cliente: O Apono Cloud nunca recebe ou armazena credenciais de acesso aos recursos. Toda a interação com AWS, Azure, GCP e bancos de dados é feita pelo connector usando credenciais locais.
  • Segregação de responsabilidades: O plano de controle decide quem pode acessar o quê. O connector executa a ação na infraestrutura. Nenhum componente sozinho tem poder total.
  • Audit trail imutável: Todos os eventos são registrados de forma imutável no plano de controle, garantindo rastreabilidade completa mesmo que o connector seja comprometido.