Discovery e Inventory

Após o deploy, com o connector em status Connected no dashboard, o primeiro processo que ele executa é o discovery de recursos. Isso significa que o connector varre automaticamente todas as contas da Organization (ou a conta específica configurada) e identifica os recursos disponíveis com base nos tipos de recursos selecionados durante o deploy.

Esse processo é contínuo — não é uma varredura única. O connector periodicamente verifica se há novos recursos criados, recursos removidos ou alterações em recursos existentes. O catálogo no Apono é atualizado automaticamente, sem necessidade de ação manual.

O discovery é passivo e de leitura. Ele apenas identifica e cataloga recursos — não altera, cria ou remove nada na sua infraestrutura. As permissões de escrita são usadas apenas quando um Access Flow concede ou revoga um acesso.

O escopo do discovery depende das integrações selecionadas durante o deploy do connector. Para AWS, os principais tipos de recursos são:

Inventory — O Catálogo Centralizado

Todos os recursos descobertos de todos os connectors e integrações ficam reunidos em um único lugar: a aba Inventory no dashboard do Apono. Isso inclui recursos da AWS, GCP, Azure, Kubernetes, bancos de dados e qualquer outra integração configurada — tudo centralizado na mesma visão.

A listagem do Inventory exibe as seguintes colunas:

Coluna	Descrição
Resources	Nome do recurso descoberto.
Permissions	Quantidade de permissões associadas ao recurso.
Risk Scores	Pontuação de risco calculada pelo Apono com base no tipo de recurso e nas permissões.
Integration	A qual integração o recurso pertence (ex: AWS, GCP, Kubernetes).
Resource Type	Tipo do recurso (ex: EC2 Instance, RDS Database, S3 Bucket).

Ao clicar em um recurso, você acessa duas visões detalhadas:

• Permissions — lista todas as permissões disponíveis para aquele recurso e quem tem acesso.
• Resource Details — exibe as tags do recurso, incluindo metadados como aws_account_id, aws_account_name, região e quaisquer tags customizadas que você tenha aplicado na AWS.

Essa visibilidade centralizada é valiosa mesmo antes de criar qualquer Access Flow. Com o Inventory, você consegue visualizar rapidamente todo o inventário de recursos de todas as contas e integrações em um único painel.

É exatamente aqui que o modo Read-Only do connector se mostra útil. Organizações que querem primeiro visualizar o inventário de recursos antes de gerenciar acessos podem fazer o deploy em Read-Only, validar o discovery e depois atualizar para Full-Access quando estiverem prontas.

Filtragem e Organização de Recursos

Com uma Organization grande, o discovery pode retornar centenas ou milhares de recursos. O Inventory oferece filtros para navegar e organizar esse volume:

Filtros Disponíveis

Diretamente na interface do Inventory, é possível filtrar por:

• Integration — filtrar por integração (AWS, GCP, Kubernetes, etc.).
• Resource Type — filtrar por tipo de recurso (EC2 Instance, RDS Database, S3 Bucket, etc.).
• Resource Name — buscar recursos pelo nome.
• More Filters — filtros adicionais disponíveis:
  • Resource Path — caminho do recurso na hierarquia da integração.
  • Resource Tag — filtrar por tags associadas ao recurso.
  • Resource Status — status atual do recurso.
  • Permission Name — filtrar por nome de permissão associada.
  • Resource Risk Level — nível de risco do recurso.
  • Permission Risk Level — nível de risco da permissão.

Os filtros disponíveis por clique já são suficientes para a grande maioria dos casos. Porém, para cenários mais complexos, o Apono também suporta AQL (Apono Query Language) — uma linguagem de consulta que permite construir filtros avançados combinando múltiplos critérios com operadores lógicos.

Scopes — Salvando Filtros como Agrupamentos

Um dos recursos poderoso do Inventory é a possibilidade de salvar um filtro como um Scope. Um Scope é um agrupamento lógico de recursos baseado nos critérios de filtragem que você definiu.

Por que isso é importante? Porque ao criar um Access Flow, você pode apontar para um Scope em vez de selecionar recursos individualmente. Isso significa que:

• Um único Flow cobre todos os recursos do Scope — em vez de criar um flow por recurso, ou por tipo de recurso, você cria um flow para o agrupamento inteiro muito mais abrangente.
• O Scope é dinâmico — quando um novo recurso é descoberto e corresponde aos critérios do filtro, ele automaticamente entra no Scope e passa a ser coberto pelo Access Flow associado.
• Sem manutenção manual — não é necessário atualizar o flow quando recursos são criados ou removidos.

Uma boa prática é alinhar a estratégia de tagging da AWS com os Scopes no Apono. Se seus recursos já estão tagueados por ambiente, time e sensibilidade, basta criar Scopes baseados nessas tags e associá-los aos Access Flows correspondentes — a configuração se torna simples e escalável.

A Importância de Taguear os Recursos

O Apono funciona melhor quando os recursos da AWS estão bem tagueados. Sem tags, a única forma de definir o escopo de um Access Flow é selecionar recursos individualmente — o que não escala e exige atualização manual sempre que um recurso é criado ou removido.

Com tags, os Access Flows se tornam declarativos: em vez de dizer "este flow se aplica ao banco prod-db-orders", você diz "este flow se aplica a todos os recursos com Environment: production e DataClassification: pii". Isso cobre automaticamente qualquer recurso atual e futuro que corresponda aos critérios.

Tags Recomendadas para o Apono

Nem toda tag existente na sua organização é relevante para controle de acesso. As tags mais úteis para o Apono são aquelas que refletem nível de risco, propriedade e contexto de negócio:

Tag	Valores Comuns	Como o Apono Utiliza
Environment	production, staging, development, pci-dss	Definir regras de aprovação diferentes por ambiente — automática em dev, gestor em staging, gestor + security em produção ou pci
Team	backend, infra, data, security	Restringir quais times podem solicitar acesso a quais recursos
DataClassification	public, internal, confidential, pii	Aplicar fluxos de aprovação mais rigorosos para recursos com dados sensíveis
CostCenter ou Project	projeto-x, plataforma, fintech	Segmentar acessos por projeto ou área de negócio
ManagedBy	terraform, manual, cloudformation	Identificar recursos gerenciados por IaC (útil para restringir alterações manuais)

Não é necessário ter todas essas tags desde o início. O mais importante é ter pelo menos a tag de ambiente (Environment) — ela sozinha já permite diferenciar entre recursos de produção e não-produção, que é a segmentação mais crítica para controle de acesso.

Aplicando Tags em Escala

Se sua organização ainda não tem uma estratégia de tagging consolidada, existem formas de implementar sem depender de ação manual em cada recurso:

• Tag Policies (AWS Organizations): Definem quais tags são obrigatórias e quais valores são permitidos. Isso garante consistência — um recurso sem a tag Environment pode ser bloqueado na criação.
• Terraform/CloudFormation: Adicione default_tags no provider do Terraform ou tags nos templates do CloudFormation para que todo recurso criado por IaC já nasça tagueado.
• AWS Config Rules: Crie regras que identifiquem recursos sem tags obrigatórias e gere alertas para correção.
• Tagging retroativo: Para recursos existentes, use o AWS Tag Editor (no console) ou scripts com a API resourcegroupstaggingapi para aplicar tags em lote.

# Exemplo: default_tags no provider Terraform
# Todos os recursos criados por este provider herdam essas tags automaticamente
provider "aws" {
  region = "us-east-1"

  default_tags {
    tags = {
      Environment        = "production"
      Team               = "backend"
      DataClassification = "internal"
      ManagedBy          = "terraform"
    }
  }
}

Taguear recursos não é apenas uma boa prática para o Apono — é uma boa prática para tudo na AWS: controle de custos, segurança, compliance e operações. Se a sua organização investir tempo em uma estratégia de tagging consistente, o benefício se multiplica em todas as ferramentas que consomem essas tags, incluindo o Apono.

Workaround: Integrações Separadas por Conta

Para organizações que ainda não possuem uma estratégia de tagging madura, existe uma alternativa: criar integrações separadas na AWS — uma para cada conta ou grupo de contas.

Em vez de uma única integração que descobre tudo, você pode configurar integrações individuais como:

• Integração Produção — cobre apenas as contas de produção.
• Integração Staging — cobre apenas as contas de staging.
• Integração Dev — cobre apenas as contas de desenvolvimento.

Com isso, mesmo sem tags, é possível criar um Access Flow que aponta para a integração de produção e automaticamente cobre todos os recursos daquela conta. Funciona como uma segmentação por conta em vez de por tag.

Embora funcione, essa abordagem gera mais integrações para gerenciar e é menos flexível do que usar tags. O ideal é combiná-la com uma estratégia de tagging progressiva — comece separando por contas e, à medida que a maturidade de tagging aumenta, migre para Scopes baseados em tags.

Frequência e Latência do Discovery

O discovery não é em tempo real — ele opera em ciclos periódicos. Na prática isso significa:

• Recursos novos podem levar alguns minutos para aparecer no catálogo do Apono após serem criados na AWS.
• Recursos removidos são eventualmente removidos do catálogo quando o connector detecta que não existem mais.
• Alterações em tags são atualizadas no próximo ciclo de discovery.

Para a maioria dos cenários, essa latência é insignificante. Access Flows são configurados uma vez e se aplicam automaticamente a recursos que entram e saem do escopo. O fato de um recurso levar alguns minutos para aparecer não impacta o fluxo de trabalho diário.

Troubleshooting do Discovery

Se recursos esperados não aparecem no catálogo, verifique:

• Tipo de recurso habilitado: O tipo de recurso (ex: RDS, EC2) foi selecionado durante o deploy ou adicionado posteriormente nas integrações?
• Escopo de contas: O recurso está em uma conta que faz parte do escopo configurado (OU ou conta específica)?
• Permissões do connector: A cross-account role tem permissões de leitura para o tipo de recurso em questão? Em modo Read-Only, as permissões são de leitura; em Full-Access, são de leitura e escrita.
• Região: O recurso está em uma região coberta pelo connector? O discovery abrange todas as regiões por padrão, mas verifique se não há restrições de rede.
• SSM Agent (para EC2): Instâncias EC2 só aparecem para acesso SSM se tiverem o SSM Agent instalado e ativo.

Se o connector está com status Connected mas nenhum recurso aparece, o problema mais comum é que o tipo de recurso não foi habilitado nas integrações. Verifique em Integrations → Catalog → AWS se os recursos desejados estão selecionados.