TBAC vs ARN Explícito vs SCP vs VPC Isolation no Neptune

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.

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.

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:

{
  "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.

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.

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.