Access Flows — O Motor do Apono

Nos artigos anteriores, vimos como o Inventory cataloga os recursos, como os Scopes segmentam o que cada fluxo pode alcançar e como as permissões funcionam por dentro. Agora chegamos à peça que conecta tudo: o Access Flow.

O Access Flow é onde você define quem pode solicitar acesso, a quê, com qual aprovação, por quanto tempo e com quais permissões. É o motor do Apono — sem ele, o inventário é apenas um catálogo de leitura e os Scopes são filtros sem propósito.

Anatomia de um Access Flow

Todo Access Flow é composto por cinco elementos fundamentais:

Cada um desses elementos é uma decisão de segurança. Vamos detalhar cada um.

1. Quem Solicita (Requesters)

Define quais usuários ou grupos podem solicitar acesso por meio desse flow. A configuração é feita apontando para grupos do Identity Provider (IdP) — como Entra ID, Okta ou Google Workspace.

Boas práticas:

• Use grupos do IdP, não usuários individuais. Se um engenheiro sai do time, basta removê-lo do grupo no IdP e ele perde automaticamente o acesso a todos os flows associados.
• Granularize por função. Em vez de um grupo genérico "Engenharia", use grupos como "Backend", "Data", "SRE". Isso permite criar flows diferentes com permissões adequadas para cada função.
• Evite o grupo "Todos". Um flow disponível para toda a organização é quase sempre excessivo. Mesmo em ambientes de desenvolvimento, restrinja por time.

Na configuração dos requesters, o Apono permite escolher entre grupos do próprio Apono ou grupos do Identity Provider (IdP). Sempre que possível, prefira grupos do IdP — eles já refletem a estrutura organizacional, são gerenciados pelo time de identidade e se atualizam automaticamente quando alguém entra ou sai de um time. Grupos internos do Apono podem ser úteis para casos pontuais, mas criar uma estrutura paralela de grupos gera duplicidade e risco de divergência.

2. O Que Pode Acessar (Scope + Permissões)

Aqui entram os dois elementos que definem a superfície de acesso:

• Scope — quais recursos estão disponíveis para esse flow (definido no artigo anterior)
• Permissões — qual nível de acesso será concedido sobre esses recursos

As permissões variam por tipo de recurso. Alguns exemplos:

Recurso	Permissões Comuns	Quando Usar
EC2	SSM Session (shell)	Troubleshooting, debugging
RDS	SELECT only	Consulta de dados, investigação
RDS	Full Access (CRUD)	Migrações, correções pontuais
S3	ReadOnly	Download de logs, análise
S3	ReadWrite	Upload de arquivos, correções
IAM	ViewOnly	Auditoria, investigação

A combinação de Scope + Permissões é o que determina o blast radius real do flow. Um Scope amplo com permissões restritas (ex: todos os RDS de dev, somente SELECT) pode ser aceitável. Um Scope restrito com permissões amplas (ex: um RDS específico, Full Access) também. O perigo está em Scope amplo com permissões amplas.

3. Como é Aprovado (Approval Policy)

A política de aprovação define o que acontece quando alguém solicita acesso por esse flow. O Apono oferece diferentes modelos:

Auto-aprovação

O acesso é concedido automaticamente, sem intervenção humana. O solicitante clica, espera alguns segundos e já tem acesso.

Quando usar:

• Ambientes de desenvolvimento e sandbox
• Recursos de baixo risco com permissões restritas
• Cenários onde a velocidade é mais importante que o controle individual

Quando evitar:

• Qualquer recurso de produção
• Recursos com dados sensíveis, independente do ambiente

Aprovação por gestor ou responsável

Uma ou mais pessoas precisam aprovar a solicitação antes do acesso ser concedido. O aprovador recebe uma notificação (email, Slack ou Teams) com os detalhes da solicitação.

Quando usar:

• Ambientes de staging e produção
• Recursos com dados internos ou de baixa criticidade em produção

Boas práticas para aprovadores:

• Quando há um único aprovador, geralmente é o manager direto do time — o responsável que conhece o contexto do trabalho e sabe se a solicitação faz sentido.
• Defina mais de um aprovador para evitar bloqueios quando o manager está ausente (férias, licença, fuso horário diferente). Um backup evita que o time fique parado esperando aprovação.
• Escolha aprovadores com contexto técnico sobre os recursos — um gestor de produto aprovando acesso a um banco de dados é um controle frágil
• Para recursos críticos, considere incluir alguém do time de security ou compliance/GRC como aprovador adicional

Múltiplos aprovadores para recursos críticos

Para recursos de alta criticidade, a estratégia é configurar múltiplos aprovadores no mesmo flow — por exemplo, o gestor do time, o DBA e alguém de compliance. O Apono notifica todos e qualquer um deles pode aprovar ou negar.

Quando usar:

• Acesso a dados PII em produção
• Modificações em IAM Roles ou políticas de segurança
• Ambientes regulados (PCI-DSS, HIPAA, SOC 2)
• Qualquer cenário onde o time de GRC exige rastreabilidade formal

A ideia é que quanto mais crítico o recurso, mais pessoas devem ter visibilidade sobre a solicitação. Mesmo que apenas um aprovador seja necessário para liberar, o fato de múltiplas pessoas serem notificadas aumenta a chance de alguém questionar uma solicitação indevida.

Ponto de atenção: atualmente, quando um flow tem múltiplos aprovadores, todos recebem a notificação de aprovação ao mesmo tempo. Na prática, isso gera um broadcast desnecessário — especialmente quando o primeiro aprovador já resolveu a solicitação em segundos e os demais recebem uma notificação que já não tem utilidade. O ideal seria uma lógica de escalonamento: notificar o aprovador primário primeiro e, caso ele não responda dentro de um tempo configurável, escalar para os demais. Isso reduziria o ruído e evitaria a fadiga de notificação que, com o tempo, faz os aprovadores ignorarem os alertas.

Como Funciona a Estrutura de Aprovadores

O Apono permite configurar a aprovação em camadas com lógica flexível. Cada flow pode ter múltiplos grupos de aprovadores, e cada grupo pode conter uma ou mais pessoas (ou um grupo inteiro do IdP). A lógica de aprovação funciona em dois níveis:

Dentro de cada grupo de aprovadores:

• Qualquer um (OR) — basta uma pessoa do grupo aprovar para que o grupo seja considerado aprovado. Útil para grupos onde qualquer membro tem autoridade equivalente (ex: qualquer SRE do time).
• Todos eles (AND) — todas as pessoas do grupo precisam aprovar. Útil quando cada membro traz uma perspectiva diferente que precisa ser considerada (ex: o DBA e o responsável pela aplicação).

Entre os grupos de aprovadores:

A mesma lógica se aplica entre os grupos. Se o flow tem Aprovador 1 (gestor) e Aprovador 2 (security):

• Qualquer um (OR) — basta um dos grupos aprovar
• Todos eles (AND) — ambos os grupos precisam aprovar

Exemplo prático:

Flow: Acesso RDS Produção PII

Aprovador 1: Time de Data (qualquer um)
  - Maria (DBA)
  - João (DBA)

Aprovador 2: Security (qualquer um)
  - Ana (Security Engineer)
  - Carlos (Security Lead)

Lógica entre grupos: Todos eles (AND)

Nesse exemplo, qualquer DBA pode aprovar pelo grupo 1, e qualquer pessoa de security pode aprovar pelo grupo 2 — mas os dois grupos precisam aprovar para o acesso ser concedido. Isso combina agilidade (não depende de uma pessoa específica) com rigor (duas áreas diferentes validam).

4. Por Quanto Tempo (Duration)

A duração define por quanto tempo o acesso permanece ativo após a aprovação. Quando o tempo expira, o Apono revoga automaticamente as permissões — sem depender de ação manual.

Embora o Apono seja uma ferramenta de Just-in-Time Access, é preciso ser pragmático com a duração. No mundo ideal, todo acesso seria o mais curto possível. Na prática, se o manager precisa aprovar o mesmo acesso 5 vezes por dia para a mesma pessoa nos mesmos recursos, o controle se torna burocracia — e o aprovador começa a aprovar no automático, o que derrota o propósito da ferramenta.

A regra é simples: a duração deve ser proporcional ao risco do recurso. Recursos de uso diário em ambientes de baixo risco devem ter durações mais longas para evitar fricção. Recursos críticos em produção devem ter durações curtas, mesmo que isso gere mais solicitações — porque nesses casos, cada solicitação merece ser avaliada.

Cenário	Duração Sugerida	Justificativa
Dev / Sandbox (uso diário)	1-7 dias	O engenheiro usa os mesmos recursos durante a semana toda. Durações de uma semana com possibilidade de extensão evitam solicitações repetitivas sem ganho de segurança
Staging (uso frequente)	4-8 horas	Ambiente intermediário — menos sensível que produção, mas acesso não precisa ser permanente
Troubleshooting em produção	2-6 horas	Ambiente crítico, acesso pontual. A duração curta é justificada pelo risco
Consulta de dados PII	30 min - 1 hora	Dados sensíveis exigem janela mínima, independente do ambiente
Deploy ou migração	2-4 horas	Operação planejada com início e fim definidos
Break-glass (incidente)	30 min - 1 hora	Emergência — o mínimo para conter e diagnosticar

Fricção excessiva é inimiga da segurança. Quando o processo é pesado demais para tarefas rotineiras, as pessoas encontram atalhos — pedem credenciais a colegas, mantêm sessões abertas ou pressionam para obter acessos permanentes. Um flow com duração generosa em dev e auto-aprovação é mais seguro do que um flow restritivo que ninguém quer usar.

Para recursos críticos de produção e dados sensíveis, durações curtas são inegociáveis. Nesses casos, o custo da fricção compensa: cada solicitação gera um registro de auditoria, e o aprovador tem a responsabilidade real de avaliar se aquele acesso faz sentido.

O engenheiro também pode encerrar o acesso manualmente antes do tempo expirar, caso termine a tarefa antes. Isso é uma boa prática que o time de segurança pode incentivar — e que reforça a cultura de menor privilégio sem depender apenas de timers automáticos.

Os valores acima são sugestões, não regras absolutas. A duração ideal depende muito do momento que a empresa está vivendo. Organizações com times de segurança maduros e aprovadores dedicados podem trabalhar com janelas mais curtas. Mas empresas menores ou em fase de adoção do Apono podem precisar de durações muito mais longas — até 1 mês em alguns casos — simplesmente porque não há pessoas suficientes para avaliar solicitações com frequência. Se ninguém aprova, as pessoas ficam bloqueadas e não conseguem trabalhar — e isso é pior do que um acesso com duração mais longa.

O equilíbrio certo é encontrado com o tempo. Comece com durações mais generosas, monitore o uso e ajuste conforme a maturidade do processo de aprovação aumenta.

5. Onde Solicita (Portal / Slack / Teams)

O Access Flow é acessível por todos os canais configurados no Apono:

• Portal Web — o dashboard do Apono, interface completa com todos os detalhes
• Slack — via ChatOps, solicitação e aprovação diretamente no chat
• Microsoft Teams — mesma experiência do Slack para organizações que usam Teams

Independente do canal, o flow é o mesmo. A diferença é onde o solicitante interage — o que importa é reduzir a fricção para que o desenvolvedor use o Apono em vez de buscar atalhos.

Estruturando Flows na Prática

A estrutura dos flows deve refletir a realidade da organização. Não existe um modelo único, mas existem padrões que funcionam bem.

Padrão 1: Um Flow por Combinação de Time + Ambiente + Recurso

É o modelo mais granular e seguro. Cada flow tem um propósito claro:

Flow	Requesters	Scope	Aprovação	Duração	Permissões
Backend → EC2 Dev	Backend	ec2-dev	Auto	8h	SSM Session
Backend → EC2 Prod	Backend	ec2-prod	Gestor + SRE	2h	SSM Session
Data → RDS Dev	Data	rds-dev	Auto	4h	Full Access
Data → RDS Prod (PII)	Data	rds-prod-pii	Gestor + DBA + Compliance	1h	SELECT
SRE → EC2 Prod	SRE	ec2-prod	Gestor	4h	SSM Session
Data → S3 Prod (sensível)	Data	s3-prod-sensitive	Gestor + Security	1h	ReadOnly

Vantagem: Controle total sobre cada combinação. Cada flow é auditável individualmente.

Desvantagem: Número de flows cresce com a combinação de times × ambientes × recursos. Em organizações grandes, pode chegar a dezenas de flows.

Padrão 2: Flows Agrupados por Cenário de Uso

Agrupa flows pelo cenário de negócio em vez de por recurso individual:

Flow	Requesters	Scopes Incluídos	Aprovação	Duração
Troubleshooting Dev	Backend + Data	ec2-dev, rds-dev, s3-dev	Auto	4h
Troubleshooting Prod	Backend + SRE	ec2-prod, rds-prod-internal	Gestor + SRE	2h
Análise de Dados	Data	rds-prod-pii, s3-prod-sensitive	Gestor + Compliance	1h
Auditoria	Security + Compliance	Todos os scopes ReadOnly	Auto	2h

Vantagem: Menos flows para gerenciar. Reflete como os times realmente trabalham.

Desvantagem: Menos granularidade. Um flow de "Troubleshooting Prod" pode incluir recursos que nem sempre são necessários para a tarefa específica.

Qual Padrão Escolher?

Na prática, a maioria das organizações usa uma combinação dos dois:

• Padrão 1 para recursos críticos (produção, PII, IAM) — controle granular onde importa
• Padrão 2 para ambientes de baixo risco (dev, sandbox) — simplicidade onde o risco é menor

O importante é que a estrutura seja revisada periodicamente. Times mudam, recursos são criados e removidos, e a organização pode precisar de novos flows ou ajustar os existentes.

Break-Glass: Acesso de Emergência

Nem todo acesso segue o fluxo padrão. Em incidentes críticos — como uma queda de produção às 3h da manhã — esperar uma cadeia de aprovação não é viável. Para esses cenários, o Apono permite configurar flows de break-glass.

Um flow break-glass tem características específicas:

• Auto-aprovação ou aprovação mínima — o acesso é concedido imediatamente ou com um único aprovador
• Duração curta — 30 minutos a 1 hora, o mínimo para conter o incidente
• Escopo restrito — apenas os recursos necessários para diagnóstico e mitigação
• Notificação ampla — o time de security, gestores e compliance são notificados imediatamente de que um acesso break-glass foi utilizado
• Auditoria reforçada — toda ação durante o acesso é registrada para revisão posterior

O break-glass não é um atalho para evitar o processo de aprovação. É um flow formal, auditado e monitorado. A diferença é que a verificação acontece depois do acesso, não antes. Qualquer uso de break-glass deve gerar uma revisão pós-incidente documentada.

Justificativa na Solicitação

Um recurso importante dos Access Flows é a possibilidade de exigir que o solicitante forneça uma justificativa ao pedir acesso. Essa justificativa fica registrada na auditoria e ajuda o aprovador a tomar uma decisão mais informada.

Boas práticas:

• Exija justificativa em todos os flows de produção. Mesmo que o aprovador não leia todas, o registro existe para auditoria.
• Vincule a tickets ou incidentes. Incentive os solicitantes a incluir o número do ticket (Jira, ServiceNow, PagerDuty) na justificativa. Isso cria rastreabilidade entre o acesso e o motivo de negócio.
• Em flows de auto-aprovação em dev, a justificativa pode ser opcional para reduzir fricção.

Erros Comuns

1. Um flow para tudo

Criar um único Access Flow genérico que serve para todos os times e todos os recursos. Na prática, isso é o equivalente a não ter segmentação — e toda a segurança depende exclusivamente do aprovador.

2. Mesmo aprovador para tudo

Usar o mesmo gestor como aprovador de todos os flows. Além de criar um gargalo (se ele estiver ausente, ninguém é aprovado), o aprovador sofre de fadiga de aprovação — aprova tudo sem avaliar porque o volume é alto demais.

3. Não usar Scopes

Criar flows apontando diretamente para a integração sem Scope. Já detalhamos esse problema no artigo sobre Scopes — sem Scope, o solicitante vê todos os recursos e o blast radius de uma aprovação é toda a integração.

4. Ignorar o break-glass

Não ter um flow de emergência faz com que, em incidentes, as pessoas busquem atalhos — como usar credenciais compartilhadas, pedir acesso permanente a um administrador ou contornar o Apono completamente. Um flow break-glass formal é mais seguro do que a improvisação.

5. Não revisar flows periodicamente

Flows criados há meses podem estar desatualizados: times mudaram, recursos foram decomissionados, aprovadores saíram da empresa. Uma revisão trimestral dos flows é o mínimo recomendado — e o time de GRC ou compliance deve ser envolvido nessa revisão.

Ciclo de Vida de uma Solicitação

Para fechar, vamos acompanhar o ciclo completo de uma solicitação de acesso por um Access Flow:

Cada etapa desse ciclo gera um registro de auditoria no Apono — quem solicitou, quando, por quê, quem aprovou, quanto tempo durou e quando foi revogado. Essa trilha de auditoria é fundamental para compliance e para investigações de segurança.