Landing Zone soberana na AWS para o Grupo Autoglass: residência de dados e isolamento por unidade de negócio

O Grupo Autoglass é um ecossistema de soluções que vai além do setor automotivo. Sua história começou com a Autoglass, referência em vidros e peças automotivas, presente em mais de 85 lojas no Brasil e na Colômbia e com um e-commerce em constante crescimento. O grupo expandiu sua atuação e hoje é composto também pela Maxpar, especializada em assistências para seguradoras, e pela B4B.tech, unidade de tecnologia focada em digitalização e BPO de operações de seguros.

Esse portfólio significa que o Grupo trata dados pessoais de clientes finais, de segurados e de sinistros — informações regidas pela Lei Geral de Proteção de Dados (LGPD) e, no caso das operações de seguros, sujeitas a expectativas regulatórias do setor. Cinco unidades de negócio autônomas compartilhando o mesmo ambiente de nuvem, sem fronteiras técnicas entre elas e sem controle sobre onde os dados podiam ser criados, era um risco de soberania e de conformidade, não apenas um problema de organização.

Desafios — soberania e isolamento como requisito

As cerca de seis contas AWS existentes eram compartilhadas entre cinco Business Units diferentes. A dataRain identificou lacunas que impediam o Grupo de comprovar controle sobre os próprios dados:

• Ausência de controle sobre as Regiões AWS utilizadas — nada impedia que dados pessoais de clientes brasileiros fossem criados ou copiados para Regiões fora do país, sem visibilidade e sem aprovação;
• Logs de segurança descentralizados — sem trilha de auditoria única e imutável, era impossível reconstruir com confiança quem acessou o quê;
• Ausência de políticas preventivas e detectivas no nível da organização — os controles dependiam da disciplina de cada equipe;
• Sem isolamento entre unidades de negócio — um incidente em uma BU podia alcançar recursos de outra;
• Sem rastreabilidade de custos por BU, o que impedia responsabilização financeira.

Para um grupo que processa dados de segurados e de sinistros, essas lacunas significavam não poder demonstrar, a um auditor ou ao titular dos dados, onde os dados residem e quem tem acesso a eles.

Solução — Landing Zone soberana por design

A dataRain reestruturou o ambiente em uma Landing Zone com AWS Control Tower + AWS Organizations, com os controles de soberania aplicados de forma preventiva:

• Residência de dados (region lock): SCPs no nível da organização com políticas region-deny bloqueiam qualquer chamada de API que crie recursos ou transfira dados para fora da Região sa-east-1 (São Paulo), com exceções restritas apenas a serviços globais (IAM, Route 53, CloudFront, AWS WAF). O controle é preventivo: a ação é negada, não apenas registrada.
• Isolamento por unidade de negócio: cada BU passou a operar em conta AWS dedicada, sob OUs segmentadas (OU exclusiva para a conta de gestão, OU de serviços de infraestrutura e OU de contas excluídas), com políticas específicas por OU. O raio de impacto de um incidente fica contido na conta da BU afetada.
• Auditoria imutável e criptografada: AWS CloudTrail no nível da organização, com logs criptografados via AWS KMS e centralizados em uma conta Log Archive dedicada, protegidos com Amazon S3 Object Lock (WORM) — impedindo alteração ou exclusão, inclusive por administradores.
• Compliance contínuo: AWS Config com conformance packs avaliando o baseline continuamente e detectando desvios de configuração e de residência.
• Detecção e postura: Amazon GuardDuty e AWS Security Hub habilitados em todas as contas, com achados centralizados na conta de segurança.
• Identidade centralizada: IAM Identity Center com permission sets por papel e MFA, substituindo credenciais locais por acesso federado e temporário.
• Continuidade: AWS Backup com políticas centralizadas e cópias mantidas na própria Região, preservando a residência.
• Governança financeira: política de tags obrigatórias permitindo alocação de custos por BU.
• Infraestrutura como código: o baseline é versionado e aplicado via Control Tower Account Factory e CloudFormation StackSets, de modo que toda conta nova nasce com os mesmos controles de soberania.

Residência de dados (explícita)

Todas as cargas e dados do Grupo Autoglass residem exclusivamente em sa-east-1 (São Paulo, Brasil). As políticas deny das SCPs impedem a criação de recursos e a transferência de dados para fora da Região aprovada, mantendo os dados e o control plane sob jurisdição nacional e sustentando o requisito de localização de dados da LGPD. As cópias de segurança do AWS Backup são mantidas in-Region, com o risco residual de Região única documentado e formalmente aceito pelo cliente.

Transferência de conhecimento

Um diferencial do projeto foi o modelo de trabalho conjunto: em vez de substituir o time do cliente, a equipe da dataRain trabalhou lado a lado com os profissionais do Grupo, com treinamentos práticos, documentação detalhada e sessões colaborativas de priorização. O objetivo — atingido — era que o time interno pudesse operar e evoluir os controles de soberania com autonomia, sem depender do parceiro para manter o baseline.

Resultados e métricas

• 100% das cargas confinadas em sa-east-1 — residência de dados garantida por SCPs region-deny preventivas.
• 100% das contas sob guardrails obrigatórios desde o provisionamento, sem exceção manual.
• Cinco unidades de negócio isoladas em contas dedicadas, com raio de impacto contido.
• Provisionamento de nova conta reduzido de ~5 dias para menos de 1 dia, já em conformidade com o baseline soberano (Account Factory).
• MTTD inferior a 15 minutos para eventos de segurança, via GuardDuty e Security Hub centralizados.
• MTTR inferior a 1 hora para desvios de conformidade detectados pelo AWS Config.
• ~80% de redução de acessos superprovisionados, com a migração para permission sets de menor privilégio no IAM Identity Center.
• Logs de auditoria imutáveis e criptografados com KMS (S3 Object Lock), com trilha completa por conta e por BU.
• Rastreabilidade de custos por unidade de negócio, viabilizando responsabilização financeira.

Lições aprendidas

• Controle de Região precisa ser preventivo, não detectivo. Detectar que um dado saiu do país é tarde demais: a SCP region-deny precisa existir antes da primeira carga. Aplicar retroativamente exige inventariar e migrar recursos já criados fora da Região.
• Autonomia de BU e soberania não são objetivos opostos. Conta dedicada por unidade dá liberdade de operação; as SCPs herdadas da OU garantem que essa liberdade não alcance a residência dos dados nem os controles de auditoria.
• Imutabilidade de log deve ser habilitada no primeiro dia. Ativar o S3 Object Lock depois, sobre uma trilha existente, é significativamente mais complexo do que nascer com ele.
• Guardrails diferenciados por ambiente (rígidos em produção, mais flexíveis em sandbox) sustentam a experimentação das equipes sem enfraquecer o baseline soberano.

Próximos passos

Para elevar a maturidade de soberania, a dataRain recomendou ao Grupo expandir os conformance packs com controles específicos de residência, automatizar a coleta de evidências de auditoria e formalizar a estratégia de Disaster Recovery in-Region por classificação de dado.