A Ramp dividiu as funções da AWS por equipe e depois tornou o acesso à produção temporário e sujeito a solicitação

A Ramp cresceu de menos de 100 para mais de 600 funcionários enquanto ainda administrava o acesso da engenharia de backend com 3 funções da AWS: Junior-Engineers, Engineers e Admins. Cada nova solicitação de acesso a um recurso exigia que a equipe de infraestrutura editasse manualmente uma política do IAM, o que criava dois problemas crônicos — engenheiros sêniores acumulavam acesso persistente à produção muito mais amplo do que seu trabalho real, aumentando o raio de impacto de qualquer erro individual ou conta comprometida, enquanto engenheiros júniores precisavam encaminhar consultas rotineiras por meio dos engenheiros sêniores, consumindo o tempo destes.

A correção da equipe teve duas camadas. Primeiro, controle de acesso refinado: substituíram as 3 funções por mais de 20 grupos do AWS SSO, um por equipe de engenharia, cada um definido por um módulo Terraform (`engineers_X.tf`) que listava exatamente quais pipelines de CI/CD, funções Lambda, contêineres ECS, caminhos S3 e segredos aquela equipe podia acessar. Isso tornou a propriedade legível — os engenheiros podiam ler o arquivo da própria equipe para ver seu acesso e solicitar mudanças via pull request em vez de um ticket de infraestrutura.

Segundo, acesso just-in-time (JIT): para cada função de equipe, criaram uma função elevada de produção correspondente, sem associação permanente. Usando o ConductorOne (já implantado na Ramp para provisionamento de aplicativos), engenheiros elegíveis solicitam uma função de produção; uma solicitação para a função da própria equipe é aprovada automaticamente, uma solicitação para a função de outra equipe é encaminhada ao tech lead dessa equipe para aprovação, e as concessões expiram após uma janela escolhida. Fizeram o lançamento primeiro em uma equipe, iteraram e depois implantaram em toda a AWS, além de incorporar o fluxo de solicitação à CLI que já usavam, para que os engenheiros não precisassem sair do terminal.

O resultado reforçou a postura de segurança — reduzindo a superfície de acesso permanente e vinculando cada ação em produção a uma justificativa declarada — mantendo a latência entre solicitação e acesso abaixo de 10 segundos, de modo que o ganho de segurança não reintroduziu a fricção do sistema original baseado em tickets.

Transformar cada função de produção em um superconjunto com prazo definido que os engenheiros precisam solicitar, e não em uma concessão permanente

Dividir as funções por equipe antes de automatizar o acesso criou uma unidade natural para aprovação automática (própria equipe) e para encaminhamento de aprovação (o responsável de outra equipe) — o JIT precisa de um mapa de propriedade para encaminhar solicitações.

Fazer das funções de produção superconjuntos das funções de equipe não relacionadas à produção significou que remover o acesso permanente não mudou o que os engenheiros já podiam fazer no dia a dia — apenas acrescentou uma etapa de solicitação.

Aprovar automaticamente solicitações da mesma equipe enquanto encaminhava solicitações entre equipes a um tech lead alinhou a fricção de aprovação ao risco real: seus próprios recursos são rotina, os de outra pessoa exigem uma segunda análise.

Incorporar o fluxo de solicitação à CLI que os engenheiros já usavam para deploys e SSH fez com que a adoção não dependesse de lembrar de abrir um aplicativo web separado sob pressão de tempo.

A propriedade refinada precisa existir antes que o acesso just-in-time possa funcionar — sem funções com escopo definido mapeadas para a propriedade real das equipes primeiro, não há uma unidade sensata para conceder ou aprovar automaticamente.

A Ramp relatou que o lançamento do JIT fortaleceu sua postura para frameworks como SOC 2 e ISO 27001, nos quais os auditores buscam acesso com prazo definido em vez de concessões permanentes, e reduziu o escopo da auditoria ao vincular cada ação em produção a uma justificativa declarada. As lições declaradas pela equipe: a propriedade do sistema precisava estar resolvida antes de construir a ferramenta de acesso, integrar centenas de engenheiros exigiu mais esforço do que construir o próprio fluxo de trabalho, e escolher cedo um fornecedor adequado à sua escala evitou retrabalho à medida que o quadro de funcionários continuava crescendo.