Scopes e Estratégia de Segmentação

No artigo sobre Inventory, vimos que Scopes são filtros salvos que agrupam recursos logicamente. Mas o Scope não é apenas uma conveniência de organização, ele é a uma das peças mais crítica de segurança em toda a configuração do Apono. É o Scope que define a superfície de ataque de cada Access Flow.

O Problema: Flows Sem Escopo

Imagine o cenário mais simples de configuração: você cria um Access Flow apontando diretamente para a integração AWS, sem nenhum Scope. O flow permite que engenheiros do time de backend solicitem acesso a recursos da AWS com aprovação do gestor.

O que acontece na prática?

Quando um engenheiro abre o portal do Apono para solicitar acesso, ele vê todos os recursos da integração AWS: todas as instâncias EC2, todos os bancos RDS, todos os buckets S3, todas as contas da Organization. O flow não filtra nada, ele apenas exige uma aprovação.

O problema não é apenas que o engenheiro pode solicitar acesso a recursos críticos, mas tammbém é que ele vê que esses recursos existem. Visibilidade já é um risco. Um engenheiro que não deveria saber da existência de um banco de dados com dados PII em uma conta de compliance agora sabe que ele existe, qual é o nome, e que pode pedir acesso.

E a única barreira entre ele e esse acesso é a aprovação do gestor.

A Realidade das Aprovações

Em teoria, o gestor deveria avaliar cada solicitação criteriosamente: verificar se o engenheiro realmente precisa daquele acesso, se o recurso é o correto, se o nível de permissão é adequado e se a duração é razoável. Em cenários mais críticos, o ideal seria ainda consultar o time de compliance ou GRC (Governança, Risco e Conformidade) para garantir que o acesso está em conformidade com políticas internas e regulatórias.

Na prática, a maioria dos aprovadores simplesmente aprova. As razões são previsíveis:

• O engenheiro diz que precisa para resolver um incidente e há pressão para desbloquear rápido.
• O aprovador é o gestor do time e confia na equipe.
• A solicitação chega no Slack e aprovar é um clique.
• O aprovador não tem contexto técnico para avaliar se aquele nível de acesso é realmente necessário.
• Envolver compliance ou GRC em cada solicitação tornaria o processo lento demais para o dia a dia.

Isso não elimina a responsabilidade dos aprovadores, eles continuam sendo uma peça importante do processo. Mas depender exclusivamente de aprovação humana sob pressão é um controle frágil. Scopes e Access Flows bem configurados reduzem a margem de erro e garantem que, mesmo quando o aprovador libera rápido, o acesso concedido já está dentro de limites seguros.

A aprovação deve ser o último filtro, não o único. Aprovadores são responsáveis pela decisão, mas Scopes e Access Flows existem para que essa decisão aconteça dentro de um perímetro seguro.

Como Scopes Resolvem o Problema

Um Scope limita o que um Access Flow pode conceder. Ele age como um filtro no inventário que define quais recursos estão dentro do alcance daquele flow. Recursos fora do Scope simplesmente não aparecem para o solicitante, por isso ele não pode pedir acesso ao que não vê.

Com Scopes bem definidos:

• O engenheiro de backend que precisa acessar EC2 em desenvolvimento só vê instâncias de desenvolvimento.
• O DBA que precisa acessar bancos de produção só vê bancos de produção e passa por um fluxo de aprovação diferente.
• Recursos de compliance, segurança ou infraestrutura crítica não aparecem em nenhum flow de engenharia.

Mesmo que o aprovador aprove sem pensar, o dano é limitado ao que o Scope permite. O blast radius de uma aprovação descuidada é contido pelo escopo.

Vale lembrar que um mesmo usuário, ou grupo de usuários, pode estar associado a mais de um Access Flow. Nesse caso, os acessos disponíveis se somam: ele pode solicitar tudo o que cada flow permite. A diferença entre os flows pode estar nos aprovadores, nos recursos visíveis ou no nível de permissão concedido por cada Scope.

Estratégia de Segmentação

A forma como você define seus Scopes determina o nível de segurança de toda a operação do Apono. Uma boa estratégia de segmentação segue dois eixos: ambiente e criticidade.

Eixo 1: Por Ambiente ou Conta AWS

A segmentação mais básica e indispensável. Recursos de produção e desenvolvimento nunca devem estar no mesmo Scope.

Na prática, muitas empresas utilizam múltiplas contas AWS para separar ambientes — uma conta para desenvolvimento, outra para staging e outra para produção. Essa é uma recomendação da própria AWS (AWS Organizations com estratégia multi-account). Quando a organização segue esse modelo, o Scope pode ser definido diretamente pela conta AWS em vez de depender de tags de ambiente:

Scope	Filtro	Flow Associado
EC2 Desenvolvimento	Conta 111111111111 (dev) + ResourceType=EC2	Auto-aprovação, 8 horas
EC2 Staging	Conta 222222222222 (staging) + ResourceType=EC2	Aprovação do gestor, 4 horas
EC2 Produção	Conta 333333333333 (prod) + ResourceType=EC2	Aprovação do gestor + security, 2 horas

Se a empresa usa uma única conta AWS para todos os ambientes, a segmentação depende de tags como Environment=production. Mas em organizações com contas separadas, a conta em si já é o filtro mais confiável — não há risco de alguém esquecer de aplicar uma tag e o recurso acabar no Scope errado.

Empresas que usam AWS Organizations com múltiplas contas têm uma vantagem natural: a separação de ambientes já está na estrutura das contas. Mesmo com uma única integração na conta principal, os Scopes conseguem filtrar recursos por conta, tornando a segmentação mais robusta e menos dependente de tags.

Com essa segmentação, o engenheiro que precisa fazer troubleshooting em dev consegue acesso rápido sem esperar aprovação. Mas para produção, o flow exige mais rigor. E o Scope garante que, mesmo com auto-aprovação em dev, ele nunca acessa produção por esse flow.

Eixo 2: Por Criticidade

Dentro de um mesmo ambiente, nem todos os recursos têm o mesmo nível de risco. Um banco de dados com dados de clientes (PII) é mais sensível do que um cache Redis. Um bucket S3 com backups de banco é mais crítico do que um bucket com assets estáticos de um site:

Scope	Filtro	Flow Associado
RDS Produção — PII	Environment=production + DataClassification=pii	Aprovação do DBA + compliance, 1 hora, somente SELECT
RDS Produção — Interno	Environment=production + DataClassification=internal	Aprovação do DBA, 2 horas
RDS Dev	Environment=development + ResourceType=RDS	Auto-aprovação, 4 horas
S3 Produção — Sensível	Environment=production + DataClassification=sensitive	Aprovação do gestor + security, 1 hora, somente ReadOnly
S3 Produção — Público	Environment=production + DataClassification=public	Aprovação do gestor, 4 horas
S3 Dev	Environment=development + ResourceType=S3	Auto-aprovação, 8 horas

Perceba que os mesmos buckets S3 no mesmo ambiente de produção têm flows completamente diferentes dependendo da tag DataClassification. Um bucket com backups de banco de dados, logs com dados pessoais ou exports de relatórios financeiros exige um controle muito mais rígido do que um bucket que serve imagens de um site público.

Combinando os Eixos

Na prática, os dois eixos se combinam para formar uma matriz de Scopes que cobre toda a organização:

Quanto mais à direita e acima na matriz, mais restritivo deve ser o flow: mais aprovadores, menor duração, permissões mais granulares.

Exemplo Prático

Uma organização com 3 contas AWS (dev, staging, produção) e 2 times (backend, data) pode configurar:

Scopes:

• ec2-dev — EC2 nas contas de desenvolvimento
• ec2-staging — EC2 nas contas de staging
• ec2-prod — EC2 nas contas de produção
• rds-dev — RDS nas contas de desenvolvimento
• rds-prod-internal — RDS de produção com DataClassification=internal
• rds-prod-pii — RDS de produção com DataClassification=pii
• s3-dev — S3 nas contas de desenvolvimento
• s3-prod-public — S3 de produção com DataClassification=public
• s3-prod-sensitive — S3 de produção com DataClassification=sensitive

Access Flows:

Flow	Quem Pode Solicitar	Scope	Aprovação	Duração
Dev EC2	Backend + Data	ec2-dev	Auto-aprovação	8h
Staging EC2	Backend + Data	ec2-staging	Gestor	4h
Prod EC2	Backend	ec2-prod	Gestor + SRE	2h
Dev RDS	Data	rds-dev	Auto-aprovação	4h
Prod RDS (interno)	Data	rds-prod-internal	Gestor + DBA	2h
Prod RDS (PII)	Data	rds-prod-pii	Gestor + DBA + Compliance	1h, somente SELECT
Dev S3	Backend + Data	s3-dev	Auto-aprovação	8h
Prod S3 (público)	Backend	s3-prod-public	Gestor	4h
Prod S3 (sensível)	Data	s3-prod-sensitive	Gestor + Security	1h, somente ReadOnly

O engenheiro de backend nunca vê bancos RDS em nenhum flow. O engenheiro de data nunca vê EC2 de produção. E buckets S3 com dados sensíveis só são acessíveis pelo time de data com aprovação de security. Mesmo dentro dos flows que cada um pode acessar, o Scope limita os recursos visíveis.

A Importância das Tags na AWS

Nem toda segmentação depende exclusivamente de tags. Se a empresa já tem contas AWS separadas por ambiente, a própria estrutura de contas serve como filtro. Se os recursos seguem uma convenção de nomenclatura clara (ex: prod-api-rds-01, dev-worker-ec2-03), o nome do recurso já ajuda a diferenciá-los. Mas na prática, poucas organizações têm uma arquitetura tão bem organizada. Tags existem justamente para compensar essa falta de estrutura — e mesmo em ambientes bem arquitetados, elas adicionam uma camada extra de classificação que vai além do que contas e nomes conseguem expressar, como nível de sensibilidade dos dados (DataClassification=pii) ou time responsável (Team=data).

AWS Tag Editor: Seu Aliado

A AWS oferece o Tag Editor no console (Resource Groups & Tag Editor) que permite:

• Visualizar todos os recursos de uma região e suas tags em uma única tela
• Editar tags em massa — selecionar múltiplos recursos e aplicar a mesma tag de uma vez
• Identificar recursos sem tags — filtrar por recursos que não possuem uma tag específica
• Auditar a consistência — verificar se todos os RDS de produção realmente têm Environment=production

Na prática, o processo é:

1. Acesse o Tag Editor no console da AWS
2. Filtre por tipo de recurso (ex: RDS, S3, EC2)
3. Identifique recursos sem as tags obrigatórias
4. Selecione os recursos e adicione as tags faltantes em lote
5. Repita periodicamente — novos recursos criados sem tags quebram silenciosamente os Scopes do Apono

Tags e Infraestrutura como Código

O ideal é que as tags sejam definidas na criação do recurso via Terraform, CloudFormation ou outra ferramenta de IaC. Isso garante que todo recurso já nasce com as tags corretas:

# Exemplo em Terraform
resource "aws_db_instance" "customers" {
  # ... configuração do RDS

  tags = {
    Environment        = "production"
    DataClassification = "pii"
    Team               = "data"
    Service            = "customers-db"
  }
}

resource "aws_s3_bucket" "reports" {
  # ... configuração do bucket

  tags = {
    Environment        = "production"
    DataClassification = "sensitive"
    Team               = "data"
    Service            = "financial-reports"
  }
}

Sem esse padrão, você depende de alguém lembrar de adicionar tags manualmente — e a experiência mostra que isso não funciona de forma consistente. Um recurso sem tags não desaparece do Apono — ele continua no inventário da integração. O risco é que ele escape dos filtros dos Scopes, podendo aparecer em flows genéricos onde não deveria estar, ou não ser capturado por nenhum Scope específico que dependa de tags para segmentação.

Erros Comuns

1. Scope único para toda a integração

Um Scope que aponta para "todos os recursos da integração AWS" é o mesmo que não ter Scope. Toda a segurança que o Apono oferece depende de uma segmentação adequada.

2. Scopes baseados apenas em tipo de recurso

Criar um Scope "todos os EC2" ou "todos os RDS" sem diferenciar por ambiente ou criticidade coloca produção e desenvolvimento no mesmo saco. O aprovador se acostuma a aprovar tudo porque a maioria das solicitações é para dev, e quando uma solicitação de produção aparece, ele aprova no automático.

3. Não atualizar Scopes quando a infraestrutura muda

Scopes baseados em tags são dinâmicos e se atualizam automaticamente. Mas se a estratégia de tagging mudar (ex: Environment vira env), os Scopes ficam vazios silenciosamente. Monitore periodicamente se os Scopes estão capturando os recursos esperados.

4. Delegar a segurança apenas para o aprovador

Se o seu modelo de segurança depende de o gestor negar solicitações indevidas, você já perdeu. Scopes existem para garantir que solicitações indevidas não sejam possíveis, independente de quem aprova.

A configuração de Scopes é trabalho dos administradores do Apono, não dos aprovadores. Quem define os Scopes define a superfície de ataque de toda a organização. Invista tempo nessa configuração — é a decisão de segurança mais impactante que você fará no Apono.