# TBAC vs ARN Explícito vs SCP vs VPC Isolation no Neptune O Neptune agora suporta Tag-Based Access Control (TBAC) para IAM, adicionando um quarto modelo de controle de acesso a um serviço que já oferecia isolamento por VPC, autenticação IAM com ARNs explícitos e Service Control Policies. Escolher o modelo certo — ou a combinação certa — tem implicações diretas em postura de segurança, velocidade de onboarding de times e custo operacional em plataformas de dados financeiros. - URL: https://fernando.moretes.com/blog/tbac-vs-arn-explicito-vs-scp-vs-vpc-isolation-no-neptune-amazon-neptu - Markdown: https://fernando.moretes.com/blog/tbac-vs-arn-explicito-vs-scp-vs-vpc-isolation-no-neptune-amazon-neptu/article.md?lang=pt - Published: 2026-07-28T09:03:45.647Z - Category: IA & Agentes - Tags: neptune, iam, tbac, abac, zero-trust, graph-database, financial-grade, aws-security - Reading time: 9 min - Source: [Amazon Neptune now supports tag-based access control for IAM](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-neptune-tbac/) --- Quatro modelos de controle de acesso ao Amazon Neptune coexistem hoje: isolamento por VPC, autenticação IAM com ARNs enumerados, Service Control Policies organizacionais e, desde julho de 2026, Tag-Based Access Control (TBAC). Cada um resolve um problema real — e cada um falha de formas específicas quando aplicado fora do seu contexto ideal. Em ambientes financeiros onde múltiplos times compartilham infraestrutura Neptune para detecção de fraude, análise de relacionamentos e grafos de conhecimento regulatório, a escolha errada entre esses modelos cria tanto risco de segurança quanto gargalos operacionais que atrasam entregas. Este artigo faz um bake-off honesto entre os quatro, com números, falhas conhecidas e uma recomendação clara. ## O problema que o TBAC realmente resolve — e o que ele não resolve Antes de comparar modelos, vale ser preciso sobre o problema de escala que motivou o TBAC. Em uma plataforma de dados financeiros com, digamos, 40 clusters Neptune distribuídos entre ambientes de desenvolvimento, homologação e produção para seis times de produto, a abordagem de ARN explícito em políticas IAM produz um efeito colateral bem conhecido: **policy bloat**. Cada nova política de acesso precisa enumerar os ARNs dos clusters permitidos. Quando um cluster é recriado — rotina em pipelines de IaC com Terraform ou CDK — o ARN muda, e todas as políticas que o referenciam precisam ser atualizadas. Em organizações com dezenas de roles IAM por time, isso vira um problema de sincronização que frequentemente resulta em permissões excessivamente amplas (`neptune-db:*` em `*`) aplicadas por pressa operacional. O TBAC resolve exatamente esse ponto: a política é escrita uma vez com condições de tag (`aws:ResourceTag/Project` e `aws:PrincipalTag/Project`), e a associação entre principal e recurso é mantida pelas tags — não pela enumeração de ARNs. Um principal tagged `Project=FraudDetection` só consegue executar `neptune-db:*` contra clusters com a mesma tag, independentemente de quantos clusters existam ou sejam recriados. A política não precisa mudar. O que o TBAC **não** resolve: ele não substitui controles de rede. Um principal com a tag correta mas sem rota de rede para o endpoint do cluster ainda não consegue conectar — e isso é intencional. TBAC opera na camada de autorização IAM (plano de dados), não na camada de conectividade. Também não resolve o problema de exfiltração de dados dentro do mesmo projeto: dois serviços com `Project=FraudDetection` têm acesso mútuo aos clusters desse projeto, o que pode ser indesejado em cenários de separação de responsabilidades regulatória. ## ARN Explícito: o modelo maduro com custo de manutenção crescente O modelo de ARN explícito é o mais antigo e o mais auditável. Uma política IAM que lista `arn:aws:neptune-db:us-east-1:123456789012:cluster:fraud-prod-cluster-01/database` é inequívoca: qualquer auditor de segurança ou ferramenta de análise de políticas (IAM Access Analyzer, por exemplo) consegue determinar exatamente quais recursos estão cobertos sem precisar rastrear tags em múltiplas entidades. Em ambientes financeiros com requisitos de auditoria SOX ou PCI-DSS, essa rastreabilidade direta tem valor real. O ARN é imutável durante o ciclo de vida do recurso (exceto quando o recurso é destruído e recriado), e a relação entre política e recurso é explícita no JSON da política — sem dependência de estado externo (as tags podem ser modificadas por qualquer principal com permissão `neptune:AddTagsToResource`). O custo: em escala, políticas com ARNs enumerados atingem o limite de 6.144 caracteres por política gerenciada da AWS com surpreendente rapidez. Um cluster Neptune tem ARN no formato `arn:aws:neptune-db:REGION:ACCOUNT:cluster:CLUSTER-ID/database` — facilmente 80-100 caracteres. Com 60 clusters em uma política, você já está em ~6.000 caracteres só nos ARNs, sem contar as actions e condições. A solução usual é fragmentar em múltiplas políticas e agrupá-las em um role, mas isso aumenta a complexidade de auditoria. Além disso, o ARN explícito não suporta federação de identidade de forma elegante. Quando um usuário autentica via SAML/OIDC e recebe uma session role, as permissões são determinadas pela role assumida — não por atributos do usuário. Para restringir acesso por time ou projeto em cenários de federação, você precisa de uma role por time, o que multiplica o número de roles e políticas a gerenciar. ## Quatro modelos de controle de acesso ao Neptune: fluxo de decisão por camada Cada modelo opera em uma camada diferente da pilha de segurança. VPC controla conectividade de rede. SCP define guardrails organizacionais. ARN explícito e TBAC operam no plano de dados IAM — mas com semânticas de binding muito diferentes. ### 🏢 Organization Layer - SCP Deny neptune-db:* without tag condition (security) - OU Prod / NonProd (network) ### 🔐 IAM Authorization Layer - TBAC Policy aws:ResourceTag/Project = aws:PrincipalTag/Project (security) - ARN Policy neptune-db:* on explicit cluster ARNs (security) - IAM Role / OIDC Session Principal Tag: Project=FraudDetection (user) ### 🌐 Network Layer - VPC + Security Group Private Subnet No IGW (network) - VPC Endpoint (Interface) neptune-db (network) ### 🗄️ Neptune Data Plane - Neptune Cluster Tag: Project=FraudDetection Engine ≥ 1.2.0.0 (data) - Neptune Cluster Tag: Project=KYC Engine ≥ 1.2.0.0 (data) - Neptune Cluster Tag: Project=OtherTeam (blocked by TBAC) (data) ### Fluxos - ou -> scp: aplica guardrail - scp -> principal: nega sem tag válida - principal -> tbac_policy: avalia condição de tag - principal -> arn_policy: ou ARN explícito - tbac_policy -> cluster_fraud: ALLOW (tags batem) - tbac_policy -> cluster_kyc: ALLOW (tags batem) - tbac_policy -> cluster_other: DENY (tags divergem) - principal -> vpc_ep: tráfego de rede - vpc_ep -> vpc: roteamento privado - vpc -> cluster_fraud: conectividade L3 ## SCPs como guardrail organizacional: o teto, não o chão Service Control Policies são frequentemente mal posicionadas na discussão de controle de acesso ao Neptune. SCPs **não concedem permissões** — elas definem o envelope máximo de permissões que qualquer principal em uma OU pode ter. Isso as torna ideais para guardrails preventivos, mas inadequadas como mecanismo primário de controle de acesso em nível de recurso. Um padrão que funciona bem em ambientes financeiros multi-conta é usar SCPs para negar `neptune-db:*` a menos que a tag `Environment` do recurso corresponda ao ambiente da conta. Por exemplo, uma SCP na OU `Production` pode incluir: ```json { "Effect": "Deny", "Action": "neptune-db:*", "Resource": "*", "Condition": { "StringNotEquals": { "aws:ResourceTag/Environment": "production" } } } ``` Isso impede que qualquer principal em contas de produção acesse clusters não-produção — mesmo que a política IAM da role permita. A SCP opera antes da avaliação da política IAM na cadeia de autorização da AWS, então funciona como um hard stop independente da configuração de roles individuais. O limite prático das SCPs: elas são aplicadas por conta/OU, não por recurso individual. Para isolamento granular entre times dentro da mesma conta — o cenário mais comum em plataformas de dados compartilhadas — SCPs sozinhas são insuficientes. Você precisa combiná-las com TBAC ou ARN explícito para o controle em nível de cluster. SCPs também não suportam `aws:PrincipalTag` como condição de forma direta em todos os cenários de federação, o que limita sua expressividade em pipelines de identidade complexos. A recomendação operacional é tratar SCPs como a camada de **conformidade organizacional** e TBAC como a camada de **isolamento de time** — camadas complementares, não alternativas. ## VPC Isolation: necessária mas não suficiente — e por que isso importa em Zero Trust O isolamento por VPC é o controle mais antigo disponível para Neptune e, em muitos ambientes legados, é o **único** controle de acesso efetivo. O cluster fica em subnets privadas, sem Internet Gateway, acessível apenas via Security Groups que permitem tráfego da subnet da aplicação na porta 8182 (Gremlin/openCypher) ou 8183 (SPARQL). Simples, auditável, eficaz contra ameaças externas. O problema fundamental do VPC isolation como controle primário é que ele opera na camada de rede (L3/L4) e não tem semântica de identidade. Qualquer workload dentro da VPC com acesso de rede ao endpoint do cluster pode conectar — independentemente de qual time, aplicação ou contexto de negócio esse workload representa. Em um ambiente de plataforma de dados compartilhada, isso significa que um serviço de análise de KYC pode, tecnicamente, executar queries Gremlin em um cluster de detecção de fraude se ambos estiverem na mesma VPC. Do ponto de vista de Zero Trust, VPC isolation viola o princípio de **never trust, always verify** porque a confiança é implícita para qualquer entidade dentro do perímetro de rede. A AWS recomenda explicitamente habilitar autenticação IAM no Neptune (que é opcional por padrão) exatamente para adicionar verificação de identidade sobre o controle de rede. Com IAM auth habilitado, cada request HTTP ao endpoint Neptune precisa de uma assinatura SigV4 válida — e é nesse ponto que TBAC e ARN explícito entram em jogo. Em termos de latência, VPC isolation não adiciona overhead mensurável — é puro roteamento de rede. IAM auth com SigV4 adiciona ~1-3ms de overhead de assinatura no cliente, o que é irrelevante para a maioria dos workloads de grafo, mas pode ser relevante em queries de baixíssima latência em grafos de tempo real. Para esses casos, o padrão usual é usar um proxy de autenticação (como um Lambda Authorizer ou um sidecar) que centraliza a assinatura e reutiliza credenciais com cache. ## Comparação direta: quatro modelos de controle de acesso ao Neptune | Critério | Dimensão | VPC Isolation | ARN Explícito (IAM) | SCP Organizacional | TBAC (novo) | | --- | --- | --- | --- | --- | --- | | Camada de operação | Rede (L3/L4) | IAM — plano de dados | IAM — envelope máximo | IAM — plano de dados | — | | Semântica de identidade | Nenhuma (IP/SG) | Role/User específico | Conta/OU | Atributo de principal + recurso | — | | Suporte a federação SAML/OIDC | Não aplicável | Parcial (via role assumida) | Limitado | Nativo via session tags | — | | Custo de manutenção em escala (40+ clusters) | Baixo | Alto (policy bloat, ARN sync) | Baixo (por OU) | Baixo (tag-driven) | — | | Granularidade de controle | Cluster (por subnet/SG) | Cluster + Action específica | Conta/OU (não por cluster) | Tag match + Action (ex: neptune-db:QueryLanguage) | — | | Risco de tag manipulation | Não aplicável | Não aplicável | Baixo (SCP protege) | Alto se neptune:AddTagsToResource não for restrito | — | | Auditabilidade (Access Analyzer / CloudTrail) | Via VPC Flow Logs | Alta (ARN explícito no policy) | Alta (SCP no Organizations) | Média (requer rastrear estado de tags) | — | | Requisito de versão Neptune | Qualquer | Qualquer (com IAM auth) | Qualquer | ≥ 1.2.0.0 com IAM auth | — | | Proteção contra movimentação lateral intra-VPC | Fraca (mesmo SG = acesso) | Forte (por role) | Nenhuma (não opera em L7) | Forte (por tag de projeto) | — | > **O vetor de ataque silencioso do TBAC: tag modification:** TBAC introduz um novo vetor de escalonamento de privilégios que não existe nos modelos anteriores: se um principal tem permissão para modificar tags de recursos Neptune (`neptune:AddTagsToResource` ou `neptune:RemoveTagsFromResource`), ele pode alterar as tags de um cluster para corresponder às suas próprias tags de principal — obtendo acesso a clusters que originalmente não deveria acessar. Em ambientes financeiros, isso é um risco de compliance crítico. A mitigação obrigatória é usar uma SCP ou política de permissão de boundary que nega explicitamente `neptune:AddTagsToResource` e `neptune:RemoveTagsFromResource` para qualquer principal que não seja um pipeline de IaC com role dedicada. Monitore CloudTrail para `AddTagsToResource` em recursos Neptune com alertas de alta prioridade no CloudWatch. ## Matriz de decisão: qual modelo (ou combinação) usar ### VPC Isolation apenas **Pros** - Zero overhead de configuração IAM - Funciona com qualquer versão do Neptune, IAM auth desabilitado - Latência mínima, sem overhead de autenticação **Cons** - Sem semântica de identidade — qualquer workload na VPC tem acesso - Viola princípios de Zero Trust - Não detectável por IAM Access Analyzer - Inaceitável para ambientes regulados (PCI, SOX) **Verdict:** Apenas para ambientes de desenvolvimento isolados sem dados sensíveis ### ARN Explícito (IAM auth) **Pros** - Máxima auditabilidade — relação policy/recurso explícita no JSON - Sem dependência de estado externo (tags) - Compatível com todas as versões Neptune com IAM auth - Granularidade por action (neptune-db:ReadDataViaQuery, etc.) **Cons** - Policy bloat em escala — limite de 6.144 chars por política - ARN muda quando cluster é recriado (IaC drift) - Não escala elegantemente com federação SAML/OIDC - Requer automação de sincronização de políticas **Verdict:** Ideal para ambientes com ≤15 clusters e sem requisito de federação de identidade ### SCP Organizacional **Pros** - Guardrail preventivo que não pode ser contornado por políticas de conta - Ideal para separação prod/não-prod por OU - Baixo custo de manutenção — uma SCP cobre toda a OU **Cons** - Não opera em nível de cluster individual - Não substitui controle de acesso em nível de time/projeto - Suporte limitado a aws:PrincipalTag em cenários de federação **Verdict:** Camada obrigatória de conformidade organizacional, sempre combinada com outro modelo ### TBAC (Tag-Based Access Control) **Pros** - Escala dinamicamente — política não muda quando clusters são criados/destruídos - Suporte nativo a session tags via SAML/OIDC - Elimina lateral access risk intra-VPC por projeto - Combinável com neptune-db:QueryLanguage para controle fino **Cons** - Requer Neptune ≥ 1.2.0.0 com IAM auth habilitado - Risco de tag manipulation se AddTagsToResource não for restrito - Auditabilidade menor — requer rastrear estado de tags no tempo - Requer disciplina de tagging em toda a organização **Verdict:** Modelo preferencial para plataformas com 15+ clusters, múltiplos times e pipelines de federação de identidade > **TBAC + SCP: o padrão de defesa em profundidade para Neptune em escala financeira:** A combinação que maximiza segurança e minimiza custo operacional em plataformas Neptune de larga escala é: (1) SCP na OU para impedir acesso cross-environment (prod → dev), (2) TBAC com tags `Project` e `Environment` para isolamento de time dentro da conta, (3) restrição explícita de `neptune:AddTagsToResource` via permission boundary em todos os roles não-IaC, e (4) `neptune-db:QueryLanguage` como condição adicional para restringir quais linguagens de query (Gremlin, openCypher, SPARQL) cada time pode usar. Essa combinação de quatro camadas é auditável, escala com IaC e não requer atualização de políticas quando clusters são recriados. ## Implementação em produção: o que o anúncio não diz O anúncio da AWS é claro sobre o mecanismo, mas há detalhes de implementação que só aparecem quando você está configurando isso em um ambiente financeiro real com múltiplos times, pipelines de CI/CD e auditoria contínua. **Tag governance como pré-requisito.** TBAC é tão forte quanto a disciplina de tagging da organização. Antes de habilitar TBAC em produção, você precisa de: (a) um tag policy no AWS Organizations que force os valores permitidos para `Project` e `Environment`, (b) um pipeline de IaC (Terraform/CDK) que aplica tags obrigatórias em todos os recursos Neptune no momento da criação, e (c) uma verificação de conformidade de tags (AWS Config rule `required-tags`) que alerta ou remedia clusters sem as tags corretas. Sem esses três elementos, TBAC pode criar uma falsa sensação de segurança: um cluster criado sem a tag `Project` não corresponde a nenhum principal tagueado, efetivamente bloqueando acesso legítimo — ou, pior, um cluster tagueado incorretamente pode ser acessível por times errados. **Session tags em pipelines OIDC.** Para workloads que assumem roles via OIDC (EKS com IRSA, Lambda com execution role, ECS tasks), as tags de principal são as tags da role IAM — não do workload individual. Para obter isolamento por workload via TBAC, você precisa de uma role IAM por projeto (não por time), o que é uma granularidade maior do que muitas organizações mantêm atualmente. Alternativamente, para pipelines com federação SAML (usuários humanos via SSO), as session tags podem ser injetadas pelo IdP no momento da autenticação, mapeando atributos de grupo LDAP para tags de sessão AWS — esse é o cenário mais poderoso do TBAC e o que justifica a menção explícita a SAML/OIDC no anúncio. **Observabilidade do controle de acesso.** CloudTrail registra todas as chamadas `neptune-db:*` com o contexto de identidade completo, incluindo tags de principal. Para auditoria de TBAC, o padrão é criar um CloudWatch Log Insights query que correlaciona `errorCode: AccessDenied` em chamadas Neptune com o campo `requestParameters.resourceTag` — isso permite identificar tentativas de acesso cross-project que foram bloqueadas pelo TBAC, o que é um sinal de segurança valioso em ambientes financeiros. ## TBAC no Neptune pela lente do AWS Well-Architected - **security**: TBAC implementa o princípio de least privilege de forma dinâmica: a superfície de acesso cresce apenas com a criação de recursos corretamente tagueados, não com atualizações manuais de política. Combinado com SCP e restrição de tag modification, atende aos controles de separação de responsabilidades exigidos por PCI-DSS e SOX. - **reliability**: Requer Neptune ≥ 1.2.0.0 — planejar upgrade de engine como pré-requisito. A dependência de tags como estado externo introduz um novo modo de falha: cluster sem tag correta = acesso bloqueado. Incluir verificação de tags em health checks de infraestrutura. > **Nota do curador: o que eu faria de verdade:** Em todo ambiente Neptune que gerenciei com mais de 20 clusters e múltiplos times, o problema real nunca foi a tecnologia de controle de acesso — foi a disciplina de tagging. Antes de habilitar TBAC, eu investiria duas semanas em tag governance: tag policies no Organizations, módulo Terraform obrigatório para Neptune com tags validadas, e uma AWS Config rule custom que coloca clusters sem tag `Project` em quarentena (security group bloqueante). Só depois habilitaria TBAC. A lição dura aprendida: TBAC com tagging inconsistente é pior que ARN explícito com policy bloat — pelo menos o bloat é visível. Tags erradas são silenciosas e só aparecem em auditorias de compliance ou, pior, em incidentes de acesso indevido. ## Recomendação: TBAC + SCP como padrão, ARN explícito como fallback auditável Para plataformas Neptune com 15 ou mais clusters, múltiplos times de produto e pipelines de identidade federada (SAML/OIDC), **TBAC é o modelo correto** — mas apenas quando combinado com SCPs organizacionais para guardrails de ambiente e com restrição explícita de modificação de tags via permission boundaries. A combinação resolve o problema de escala do ARN explícito sem sacrificar o isolamento de time que o VPC isolation não oferece. Para ambientes menores (≤15 clusters) com requisitos de auditoria muito rígidos e sem federação de identidade, ARN explícito ainda é defensável — a rastreabilidade direta no JSON da política tem valor real em auditorias SOX/PCI onde o auditor quer ver a relação policy-recurso sem precisar rastrear estado de tags. VPC isolation nunca deve ser o único controle em ambientes com dados sensíveis — é uma camada necessária, não suficiente. SCPs são sempre obrigatórias como camada de conformidade organizacional, independentemente do modelo de acesso escolhido. O pré-requisito inegociável para adotar TBAC em produção: tag governance automatizado e auditado, com Neptune engine ≥ 1.2.0.0 e IAM authentication habilitado em todos os clusters. ## Referências - [Amazon Neptune now supports tag-based access control for IAM — AWS What's New](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-neptune-tbac/) - [IAM condition keys for administering Amazon Neptune — AWS Documentation](https://docs.aws.amazon.com/en_us/neptune/latest/userguide/iam-admin-condition-keys.html) - [Tagging Amazon Neptune resources — AWS Documentation](https://docs.aws.amazon.com/neptune/latest/userguide/tagging.html) - [Amazon Neptune Adds Tag-Based Access Control for IAM — Modern Workspace Pro](https://mwpro.co.uk/blog/2026/07/28/amazon-neptune-now-supports-tag-based-access-control-for-iam/) - [AWS Weekly Roundup — July 27, 2026 — AWS News Blog](https://aws.amazon.com/blogs/aws/aws-weekly-roundup-july-27-2026/) - [IAM Access Analyzer — AWS Documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) - [AWS Organizations Tag Policies — AWS Documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_tag-policies.html) - [Service Control Policies — AWS Organizations Documentation](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)