Identidade centralizada no Ipiranga agilizando acessos a repositórios

Na manhã de uma segunda-feira típica, a equipe de plataforma de uma fintech sediada no Ipiranga recebeu um chamado urgente: um desenvolvedor recém-contratado não conseguia clonar o repositório principal, enquanto outro, desligado na sexta, ainda mantinha push ativo em branches protegidas. O cenário expunha o custo invisível da gestão fragmentada de identidades — contas locais no GitHub, chaves SSH espalhadas em máquinas pessoais, grupos de acesso desatualizados e nenhum ponto único de revogação. O incidente virou catalisador para um projeto de centralização de identidade que, em doze semanas, reduziu o tempo médio de provisionamento de acessos de 36 horas para 12 minutos e eliminou 100% das contas órfãs detectadas na auditoria inicial.

A raiz do problema não era tecnológica, mas organizacional: cada squad adotava seu próprio fluxo de onboarding, criando usuários manuais no provedor Git, compartilhando tokens pessoais de longa duração e solicitando acesso via planilhas que ninguém revisava. A ausência de single source of truth tornava a conformidade um exercício de arqueologia — auditores pediam evidências de quem tinha acesso a quê, e a resposta exigia cruzar logs de três sistemas distintos, planilhas desatualizadas e depoimentos orais. A decisão de migrar para identidade centralizada nasceu da necessidade de transformar acessos em algo auditável, efêmero e alinhado ao ciclo de vida real das pessoas.

O primeiro passo foi mapear a superfície de ataque: 142 repositórios ativos, 87 desenvolvedores, 4 provedores de identidade legados (LDAP on-prem, Google Workspace, Azure AD de um antigo piloto e contas locais no GitHub Enterprise) e zero integração entre eles. O time de arquitetura definiu o Azure AD como provedor canônico, não por preferência de vendor, mas porque já era o backbone de colaboração (Teams, SharePoint) e suportava SAML 2.0, OIDC e SCIM 2.0 nativamente. A estratégia evitou big bang: um time-piloto de 12 pessoas migrou primeiro, validando fluxos de just-in-time provisioning, sincronização de grupos e conditional access com MFA resistente a phishing (FIDO2).

Arquitetura de federação e provisionamento automatizado

A federação SAML entre Azure AD e GitHub Enterprise Cloud permitiu que a autenticação ocorresse no provedor corporativo, emitindo assertions com atributos imutáveis (userPrincipalName, department, costCenter) e grupos de segurança mapeados para teams no GitHub. O provisionamento SCIM 2.0 eliminou a criação manual de contas: quando um usuário entra no grupo “dev-platform-core” no Azure AD, a API SCIM cria a conta no GitHub, adiciona aos teams correspondentes e aplica branch protection rules via team permissions. A revogação é simétrica — remover do grupo no Azure AD desativa a sessão no GitHub em segundos, invalida tokens e remove de teams.

Para repositórios sensíveis (PCI, LGPD), camadas adicionais de conditional access exigem device compliance (Intune) e localização de rede corporativa ou VPN. Desenvolvedores em workstations não gerenciadas recebem acesso read-only via browser isolation; write exige managed device com certificado de máquina válido. Essa graduação evita o binário “tem acesso/não tem acesso” e reduz atrito sem abrir mão de postura de zero trust.

Modelo RBAC alinhado à estrutura de squads

O desenho de papéis (roles) partiu da matriz de responsabilidades RACI já usada nos squads: Developer (read/write em repositórios do squad), Tech Lead (admin no repositório, maintain em environments de staging), Security Champion (read em todos, write em security-policies), Platform Engineer (admin em infra-as-code, maintain em shared-libraries), Auditor (read-only em todos com logs de acesso). Cada papel virou grupo de segurança no Azure AD com owner definido e revisão trimestral obrigatória. A adesão ao grupo passou a ser requisito para merge em main — branch policies exigem approval de pelo menos um membro do grupo Tech Lead e status checks de CI/CD.

A transição exigiu governança de exceções: service accounts para pipelines CI/CD continuaram usando GitHub Apps com private keys rotacionadas a cada 30 dias via Vault, não identidades federadas. Contas de break-glass (duas, custodidas por Security e Platform) mantêm owner global para recuperação de desastre, com alerta imediato ao SOC a cada uso. O registro de exceções vive em Confluence com expiry date e owner, evitando shadow IT institucionalizado.

Observabilidade unificada e resposta a incidentes

A centralização de logs no Log Analytics Workspace (Azure Monitor) correlaciona sign-in logs (sucesso, falha, MFA, conditional access evaluation) com GitHub Audit Log (git.push, repo.create, team.add_member, secret.scanning.alert). Kusto queries detectam padrões anômalos: impossible travel entre sign-in e push, token replay em non-managed devices, privilege escalation via team membership change fora de janela de change management. Alertas disparam playbooks no Sentinel: isolamento de sessão, revogação de refresh tokens, notificação ao manager e abertura de incident ticket no ServiceNow.

Essa visibilidade transformou a preparação para auditorias ISO 27001 e SOC 2 Tipo II: relatórios de access review são gerados em minutos, não dias. A evidência de least privilege deixou de ser captura de tela de configuração e passou a ser query reproduzível com timestamp e hash de integridade. O time de compliance agora valida attestation trimestral via Access Reviews no Azure AD, com recertification automática para grupos de baixo risco e manual para break-glass e admin global.

Lições de migração incremental sem parar o desenvolvimento

A migração em ondas (piloto → early adopters → bulk → legacy cleanup) exigiu feature flags de autenticação: durante a coexistência, SAML e username/password + SSH conviveram, mas branch policies exigiam SAML session para write em main. Usuários legados recebiam banner no GitHub com contagem regressiva (60 dias) e self-service para vincular identidade corporativa via account linking. Service accounts foram migrados por último, após validação de GitHub Apps com fine-grained PAT e IP allowlist.

O maior obstáculo não foi técnico, mas cultural: developers acostumados a ssh-keygen e gh auth login resistiram a browser-based auth com device code flow. A solução foi developer experience (DevEx) first: VS Code com GitHub Authentication extension nativa, CLI (gh) com –hostname configurado para SAML, git credential manager (GCM) pré-instalado nas golden images de workstation. Workshops de 30 minutos com pair programming real reduziram a curva de adoção de semanas para dias.

Métricas de resultado e próximos passos

Doze semanas após o go-live completo: tempo médio de onboarding de acesso a repositórios caiu de 36h para 12min (p95 < 30min); contas órfãs detectadas em auditoria trimestral: zero; mean time to revoke (offboarding): 47 segundos; access review completion rate: 98% no prazo; incidentes de credential leak em repositórios públicos: zero (antes: 3/trimestre). O custo operacional de identity admin reduziu 62% (menos tickets, menos manual work).

O roadmap agora avança para workload identity federation (GitHub Actions OIDC para Azure sem secrets), fine-grained PAT obrigatório para CLI scripts legados, entitlement management com access packages para contractors (tempo de vida automático) e continuous access evaluation (CAE) para revogação em tempo real frente a risk events do Identity Protection. A identidade deixou de ser barreira e virou enabler de velocidade segura.

A centralização de identidade no Ipiranga provou que governança e agilidade não são opostos — são faces da mesma moeda quando a arquitetura respeita o fluxo real das pessoas. Comece pequeno, meça o que importa (tempo de provisionamento, contas órfãs, mean time to revoke), automatize o que é repetitivo e trate exceções como dívida técnica com data de validade. O repositório mais seguro não é o que ninguém acessa, mas o que só as pessoas certas acessam, pelo tempo certo, com rastro auditável a cada ação.

Para equipes que iniciam essa jornada, o primeiro passo prático é validar a federação SAML/OIDC em um repositório piloto com um grupo pequeno, medindo a experiência do desenvolvedor e a latência de provisionamento. A infraestrutura de diretório já existente na maioria das organizações (Active Directory, Azure AD, Okta, Google) costuma ser suficiente — o gap costuma estar na integração com as ferramentas de código. Um parceiro especializado em active directory na nuvem em Ipiranga pode acelerar a configuração de conditional access, SCIM provisioning e access reviews sem reinventar a roda. Consulte também nossas referências sobre boas práticas essenciais no desenvolvimento frontend moderno, como a tecnologia impacta a arquitetura de projetos web atuais e cases de e-commerce: manutenção preventiva de encanamento em lojas virtuais para contextualizar como identidade e infraestrutura caminham juntas na entrega de software confiável.

Checklist prático

Perguntas frequentes

O que é identidade centralizada e por que ela importa para times de desenvolvimento?

Identidade centralizada significa gerenciar usuários, grupos e permissões em um único diretório (como Active Directory ou Azure AD) em vez de criar contas separadas em cada ferramenta. Isso elimina contas órfãs, padroniza políticas de senha e MFA, e permite revogar acesso instantaneamente quando alguém sai da equipe.

Como a federação de identidade agiliza o acesso a repositórios Git?

Com federação (SAML/OIDC), o provedor de identidade corporativo autentica o desenvolvedor e emite tokens de curta duração para GitHub, GitLab ou Bitbucket. Não há necessidade de chaves SSH manuais nem tokens pessoais de longa vida; o provisionamento e desprovisionamento tornam-se automáticos via SCIM ou grupos sincronizados.

Quais riscos a gestão descentralizada de acessos traz para repositórios?

Contas locais dispersas dificultam auditoria, permitem credenciais fracas ou reutilizadas, e tornam lenta a revogação em caso de incidente. Também aumentam a superfície de ataque com chaves SSH não rotacionadas e tokens pessoais sem expiração, violando princípios de menor privilégio.

Como implementar RBAC (controle de acesso baseado em funções) sobre a identidade centralizada?

Mapeie papéis de negócio (dev, lead, security, auditor) a grupos no diretório central. Cada grupo recebe permissões padronizadas nos repositórios (read, write, admin, maintain). Mudanças de função tornam-se movimentação de usuário entre grupos, com efeito imediato em todos os sistemas federados.

Qual o papel de logs unificados na conformidade e resposta a incidentes?

A centralização permite correlacionar eventos de autenticação (login, MFA, falhas) com ações nos repositórios (push, merge, alteração de config). SIEMs consomem esses logs para detectar anomalias, gerar alertas e produzir evidências de conformidade (LGPD, ISO 27001, SOC 2) sem costurar fontes dispersas.

Por onde começar a migrar para identidade centralizada sem parar o desenvolvimento?

Inicie com piloto em um time pequeno: configure SAML/OIDC no provedor Git, sincronize grupos via SCIM, valide fluxos de onboarding/offboarding e meça tempo de provisionamento. Expanda gradualmente, mantendo chaves SSH legadas apenas como fallback temporário com data de expiração definida.