As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Tag-based controle de acesso para operações de plano de dados do Amazon Neptune
<a name="iam-data-tbac"></a>

Tag-based o controle de acesso (TBAC) permite que você use tags de AWS recursos e tags principais do IAM como condições nas políticas do IAM e nas políticas de controle de serviços (SCPs) para controlar o acesso às operações do plano de dados do Amazon Neptune. Com o TBAC, você pode garantir que somente os principais cujas tags correspondam às tags em um cluster de banco de dados Neptune possam realizar `neptune-db:*` ações nesse cluster, sem enumerar nomes de recursos da Amazon (ARNs) específicos do cluster em cada política.

O TBAC se baseia no modelo de segurança existente da Neptune e complementa as ações do plano de dados de controle de acesso baseadas em ações. [Ações do IAM para acesso a dados no Amazon Neptune](iam-dp-actions.md)

## Como o TBAC se encaixa nas camadas de segurança do Neptune
<a name="iam-data-tbac-security-layers"></a>

O Neptune protege seus dados por meio de vários mecanismos de segurança sobrepostos. O TBAC adiciona uma camada de autorização baseada em atributos que funciona junto com todas elas:


**Camadas de segurança do Neptune e como o TBAC as complementa**  

| Camada | Mecanismo | Escopo | 
| --- | --- | --- | 
| Isolamento de rede | Nuvem privada virtual (VPC), grupos de segurança, endpoints de VPC () PrivateLink | Controla quais hosts podem acessar os endpoints do Neptune | 
| Criptografia | Transport Layer Security (TLS) 1.3 em trânsito; criptografia AWS KMS gerenciada em repouso | Protege a confidencialidade dos dados | 
| Autenticação do IAM | AWS Solicitações assinadas do Signature Version 4 (SigV4) para o endpoint de dados do Neptune | Autentica o chamador | 
| Action-based controle de acesso | neptune-db:ações (ReadDataViaQuery,WriteDataViaQuery, etc.) | Controla quais operações um diretor pode realizar | 
| Chaves de condição | neptune-db:QueryLanguage, chaves de contexto global | Adiciona restrições contextuais às políticas | 
| TABC | aws:ResourceTag/${TagKey}avaliado contra aws:PrincipalTag/${TagKey} | Restringe o acesso com base no alinhamento da tag entre principal e recurso | 
| Acesso administrativo baseado em tags | aws:ResourceTag,rds:cluster-tag, etc. em ações do plano de gerenciamento | Controla quem pode gerenciar a infraestrutura do Neptune | 

## Principais conceitos do TBAC
<a name="iam-data-tbac-concepts"></a>

Tags principais  
Tags anexadas a usuários, funções ou diretores de sessão federada do IAM. Você pode defini-los por meio do console do IAM ou dos mapeamentos de AWS CLI atributos Security Assertion Markup Language (SAML) /OpenID Connect (OIDC) do provedor de identidade (IdP).

Tags de recursos  
Tags anexadas aos clusters de banco de dados Neptune usando. `AddTagsToResource` Eles se propagam para todas as instâncias no cluster para avaliação da política do plano de dados.

Variáveis-chave de condição  
+ `aws:PrincipalTag/{{TagKey}}`— resolve para o valor da tag no principal chamador.
+ `aws:ResourceTag/{{TagKey}}`— resolve para o valor da tag no recurso Neptune de destino.

Tipos de políticas compatíveis  
+ **Políticas de identidade do IAM ** — anexadas a usuários, grupos ou funções.
+ **SCPs ** — aplicados na unidade AWS organizacional (OU) ou no nível da conta da organização para definir barreiras de permissão.

## Pré-requisitos para usar o TBAC
<a name="iam-data-tbac-prerequisites"></a>

Antes de usar o TBAC com as operações de plano de dados do Neptune, você deve ter o seguinte em vigor:

1. **Motor Neptune versão 1.2.0.0 ou posterior ** — necessário para suporte a TBAC no plano de dados.

1. **Autenticação IAM ativada ** no cluster de banco de dados Neptune.

1. **Tags aplicadas aos clusters de banco de dados Neptune ** — as tags de recursos que as políticas avaliarão.

1. **Tags aplicadas às principais do IAM ** — as tags principais que serão comparadas com as tags de recursos.

## Padrões de política do TBAC
<a name="iam-data-tbac-patterns"></a>

Os padrões a seguir mostram maneiras comuns de usar o TBAC nas políticas do IAM para operações de plano de dados do Neptune.

### Negar acesso quando as tags principal e de recurso não coincidirem
<a name="iam-data-tbac-pattern-deny-mismatch"></a>

Esse é o padrão TBAC mais comum. Ele nega todas as ações do plano de dados do Neptune, a menos que as tags do principal correspondam às tags do recurso. Você pode aplicar isso como um SCP para fiscalização em toda a organização ou como uma política de IAM para controle direcionado.

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    }
  ]
}
```

**Como funciona: ** cada instrução usa uma `StringNotEquals` condição separada para uma única chave de tag. O Deny é acionado de forma independente para cada tag — se a `Project` tag do recurso não corresponder à tag do principal, o acesso será negado independentemente da `Project` tag. `Department` Isso garante que um principal marcado com só `Project=FraudDetection` possa acessar clusters de Netuno também marcados e`Project=FraudDetection`, da mesma forma, para. `Department`

### Negar acesso quando as tags de recursos necessárias estiverem ausentes
<a name="iam-data-tbac-pattern-deny-missing"></a>

Esse padrão impede o acesso aos clusters do Neptune que não foram marcados corretamente, garantindo que todos os clusters estejam inscritos no esquema TBAC:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}
```

**Como funciona: ** a `Null` condição é avaliada como verdadeira quando a chave de tag especificada não existe no recurso. Isso força todos os aglomerados de Netuno a carregarem as etiquetas de classificação necessárias antes que qualquer diretor possa acessá-las.

### Combinando o TBAC com o controle de acesso baseado em ações
<a name="iam-data-tbac-pattern-combined-actions"></a>

O TBAC pode ser combinado com `neptune-db:` ações específicas para criar políticas refinadas e com reconhecimento de tags:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadOnlyForMatchingTags",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:GetQueryStatus",
        "neptune-db:GetEngineStatus"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    }
  ]
}
```

### Restrição de idioma de consulta com TBAC
<a name="iam-data-tbac-pattern-query-language"></a>

Combine o TBAC com a chave de `neptune-db:QueryLanguage` condição para restringir quais clusters um principal pode acessar e quais linguagens de consulta eles podem usar:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowOpenCypherOnlyForMatchingProject",
      "Effect": "Allow",
      "Action": [
        "neptune-db:ReadDataViaQuery",
        "neptune-db:WriteDataViaQuery"
      ],
      "Resource": "arn:aws:neptune-db:*:*:*/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}",
          "neptune-db:QueryLanguage": "OpenCypher"
        }
      }
    }
  ]
}
```

## Usando o TBAC com políticas de controle de serviços
<a name="iam-data-tbac-scps"></a>

Os SCPs são ideais para aplicar o TBAC porque definem limites de permissão em toda uma unidade organizacional (OU) ou conta sem exigir alterações nas políticas individuais do IAM.

Recomendamos a seguinte estratégia de SCP:

1. Aplique um Deny-based SCP no nível da OU que bloqueie `neptune-db:*` quando as tags não coincidem.

1. Aplique uma segunda declaração negando acesso a recursos não marcados.

1. Suas contas individuais podem manter suas políticas de Permissão para `neptune-db:` ações específicas — o SCP atua como uma barreira.

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNeptuneProjectMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Project": "${aws:PrincipalTag/Project}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneDepartmentMismatch",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:ResourceTag/Department": "${aws:PrincipalTag/Department}"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingProjectTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Project": "true"
        }
      }
    },
    {
      "Sid": "DenyNeptuneMissingDepartmentTag",
      "Effect": "Deny",
      "Action": "neptune-db:*",
      "Resource": "*",
      "Condition": {
        "Null": {
          "aws:ResourceTag/Department": "true"
        }
      }
    }
  ]
}
```

## Implementando o TBAC para Neptune
<a name="iam-data-tbac-implementation"></a>

### Etapa 1: defina sua taxonomia de tags
<a name="iam-data-tbac-step-taxonomy"></a>

Escolha chaves de tag que representem seus limites organizacionais. Padrões comuns:


**Exemplo de taxonomia de tags**  

| Chave de tag | Finalidade | Exemplos de valores | 
| --- | --- | --- | 
| Project | Identificador de aplicativo ou carga de trabalho | FraudDetection, RecommendationEngine | 
| Department | Unidade de negócios ou centro de custo | Engineering, Finance, Analytics | 
| Environment | Estágio de implantação | production, staging, development | 
| Team | Equipe proprietária | graph-platform, data-science | 

### Etapa 2: marque seus clusters de banco de dados Neptune
<a name="iam-data-tbac-step-tag-clusters"></a>

Use o AWS CLI para adicionar as tags de classificação necessárias aos seus clusters de banco de dados Neptune:

```
aws neptune add-tags-to-resource \
  --resource-name arn:aws:rds:{{us-east-1}}:{{123456789012}}:cluster:{{my-neptune-cluster}} \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering
```

### Etapa 3: marque seus diretores do IAM
<a name="iam-data-tbac-step-tag-principals"></a>

Use o AWS CLI para marcar as funções do IAM com as mesmas chaves e valores usados em seus clusters do Neptune. Para funções do IAM:

```
aws iam tag-role \
  --role-name {{NeptuneAppRole}} \
  --tags Key=Project,Value=FraudDetection Key=Department,Value=Engineering
```

Para usuários federados, passe tags por meio de tags de SAML/OIDC sessão usando `aws:PrincipalTag` atributos do seu provedor de identidade.

### Etapa 4: implantar a política TBAC
<a name="iam-data-tbac-step-deploy"></a>

Anexe como um SCP para aplicação em toda a organização ou como uma política de IAM para controle direcionado.

### Etapa 5: Proteger a integridade da tag
<a name="iam-data-tbac-step-protect-tags"></a>

Restrinja quem pode modificar tags nos recursos do Neptune e nos principais do IAM:

```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyTagModification",
      "Effect": "Deny",
      "Action": [
        "rds:AddTagsToResource",
        "rds:RemoveTagsFromResource"
      ],
      "Resource": "*",
      "Condition": {
        "ForAnyValue:StringEquals": {
          "aws:TagKeys": ["Project", "Department"]
        }
      }
    }
  ]
}
```

## Considerações importantes para o TBAC
<a name="iam-data-tbac-considerations"></a>
+ **Atraso na propagação ** — as alterações nas políticas do IAM levam até 10 minutos para serem aplicadas aos recursos do Neptune. As alterações nas tags de cluster (adição, modificação ou remoção de tags) levam aproximadamente 5 minutos para serem propagadas para a avaliação da política do plano de dados. Planeje esse atraso ao atualizar as tags em clusters ativos.
+ **Cluster-level granularidade ** — Você aplica tags aos clusters de banco de dados Neptune no nível do cluster. Todas as instâncias em um cluster compartilham a mesma avaliação de política. O TBAC não fornece controle de acesso em nível subgráfico ou vertex/edge de nível.
+ **Autenticação IAM necessária ** — o TBAC só se aplica quando a autenticação IAM está habilitada no cluster. As conexões sem a autenticação do IAM ignoram totalmente essas políticas.
+ **Imutabilidade de tags ** — Proteja suas operações de marcação. Se um diretor puder modificar suas próprias tags ou as tags de recursos, ele poderá ignorar os controles do TBAC. Use SCPs ou limites de permissão para restringir `iam:TagRole``iam:TagUser`,`rds:AddTagsToResource`, e. `rds:RemoveTagsFromResource`
+ **Tratamento de tags nulas ** — Se um principal não tiver uma tag pela qual a política faça referência`${aws:PrincipalTag/{{Key}}}`, a variável será resolvida como uma string vazia. Crie suas políticas para lidar com esse caso (o padrão de negação de “tags ausentes” acima aborda isso para tags de recursos).
+ **Várias chaves de condição ** — Quando várias chaves de condição aparecem no mesmo `Condition` bloco, elas são avaliadas com a lógica AND. Pois`StringNotEquals`, uma negação só é acionada quando * todas as condições * especificadas são verdadeiras simultaneamente. Para negar * qualquer incompatibilidade de tag * única, use declarações de política separadas para cada chave de tag (conforme mostrado nos padrões acima).

## Relação com os recursos de segurança existentes do Neptune
<a name="iam-data-tbac-relationship"></a>


**Como o TBAC complementa os recursos de segurança existentes do Neptune**  

| Recurso existente | O que ele controla | Como o TBAC o complementa | 
| --- | --- | --- | 
| VPC//Grupos de segurança | Network-level acesso à porta 8182 | O TBAC adiciona autorização com reconhecimento de identidade aos controles de rede | 
| Autenticação IAM (SigV4) | Verifica a identidade do chamador | O TBAC usa as tags da identidade autenticada para decisões de autorização. | 
| Action-based controle de acesso | Quais operações (read/write/delete/load) um diretor pode realizar | O TBAC adiciona quais clusters um diretor pode segmentar, com base no alinhamento das tags | 
| Chave da condição neptune-db:QueryLanguage | Quais linguagens de consulta (Gremlin, OpenCypher, SPARQL) são permitidas | Pode ser combinado com o TBAC na mesma declaração de política | 
| Acesso administrativo baseado em tags (rds:\*ações) | Quem pode gerenciar a infraestrutura do Neptune | O TBAC estende o mesmo padrão baseado em tags para ações data-plane () neptune-db:\* | 
| AWS KMS criptografia | Confidencialidade de dados em repouso | Ortogonal — o TBAC controla a autorização, não a criptografia |