Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

# Tag-based controllo degli accessi per le operazioni sul piano dati di Amazon Neptune
<a name="iam-data-tbac"></a>

Tag-based il controllo degli accessi (TBAC) consente di utilizzare i tag AWS delle risorse e i tag principali IAM come condizioni nelle politiche IAM e nelle politiche di controllo dei servizi (SCP) per controllare l'accesso alle operazioni del piano dati di Amazon Neptune. Con TBAC, puoi far sì che solo gli amministratori i cui tag corrispondono ai tag di un cluster Neptune DB possano eseguire `neptune-db:*` azioni su quel cluster, senza enumerare Amazon Resource Names (ARN) di cluster specifici in ogni policy.

TBAC si basa sul modello di sicurezza esistente di Neptune e integra le azioni del piano dati di controllo degli accessi basate sull'azione. [Azioni IAM per l'accesso ai dati in Amazon Neptune](iam-dp-actions.md)

## In che modo il TBAC si inserisce nei livelli di sicurezza di Neptune
<a name="iam-data-tbac-security-layers"></a>

Neptune protegge i tuoi dati tramite molteplici meccanismi di sicurezza sovrapposti. TBAC aggiunge un livello di autorizzazione basato sugli attributi che funziona insieme a tutti:


**I livelli di sicurezza di Neptune e il modo in cui TBAC li integra**  

| Livello | Meccanismo | Scope | 
| --- | --- | --- | 
| Isolamento della rete | Cloud privato virtuale (VPC), gruppi di sicurezza, endpoint VPC () PrivateLink | Controlla quali host possono raggiungere gli endpoint Neptune | 
| Encryption (Crittografia) | Transport Layer Security (TLS) 1.3 in transito; AWS KMS crittografia gestita a riposo | Protegge la riservatezza dei dati | 
| Autenticazione IAM | AWS Richieste firmate Signature Version 4 (Sigv4) all'endpoint di dati Neptune | Autentica il chiamante | 
| Action-based controllo degli accessi | neptune-db:azioni (ReadDataViaQueryWriteDataViaQuery, ecc.) | Controlla quali operazioni può eseguire un preside | 
| Chiavi di condizione | neptune-db:QueryLanguage, chiavi di contesto globali | Aggiunge vincoli contestuali alle politiche | 
| TBAC | aws:ResourceTag/${TagKey}valutato rispetto aws:PrincipalTag/${TagKey} | Limita l'accesso in base all'allineamento dei tag tra principale e risorsa | 
| Accesso amministrativo basato su tag | aws:ResourceTagrds:cluster-tag, ecc. sulle azioni del piano di gestione | Controlla chi può gestire l'infrastruttura Neptune | 

## Concetti chiave del TBAC
<a name="iam-data-tbac-concepts"></a>

Tag principali  
Tag associati agli utenti, ai ruoli o ai presidi di sessione federati di IAM. Puoi impostarli tramite la console IAM o le mappature degli AWS CLI attributi Security Assertion Markup Language (SAML) /OpenID Connect (IdP) (IdP).

Tag delle risorse  
Tag allegati ai cluster Neptune DB utilizzando. `AddTagsToResource` Questi si propagano a tutte le istanze del cluster per la valutazione delle policy del piano dati.

Variabili chiave di condizione  
+ `aws:PrincipalTag/{{TagKey}}`— si risolve nel valore del tag sul principale chiamante.
+ `aws:ResourceTag/{{TagKey}}`— si risolve nel valore del tag sulla risorsa Neptune di destinazione.

Tipi di policy supportati  
+ **Policy di identità IAM**: collegate a utenti, gruppi o ruoli.
+ **SCP**: applicati a livello di unità AWS organizzativa (OU) o di account dell'organizzazione per impostare i criteri di protezione delle autorizzazioni.

## Prerequisiti per l'utilizzo del TBAC
<a name="iam-data-tbac-prerequisites"></a>

Prima di poter utilizzare TBAC con le operazioni sul piano dati Neptune, è necessario disporre di quanto segue:

1. **Versione del motore Neptune 1.2.0.0 o successiva, necessaria per il supporto del TBAC sul piano dati. **

1. **Autenticazione IAM abilitata sul cluster Neptune DB. **

1. **Tag applicati ai cluster Neptune DB**: i tag delle risorse che le policy valuteranno.

1. **Tag applicati ai principali IAM**: i tag principali che verranno confrontati con i tag delle risorse.

## Schemi politici TBAC
<a name="iam-data-tbac-patterns"></a>

I modelli seguenti mostrano i modi comuni di utilizzare il TBAC nelle politiche IAM per le operazioni sul piano dati di Neptune.

### Nega l'accesso quando i tag principale e quelli delle risorse non corrispondono
<a name="iam-data-tbac-pattern-deny-mismatch"></a>

Questo è il pattern TBAC più comune. Nega tutte le azioni del piano dati di Neptune a meno che i tag del principale non corrispondano ai tag della risorsa. Puoi applicarlo come SCP per l'applicazione a livello di organizzazione o come policy IAM per un controllo mirato.

```
{
  "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}"
        }
      }
    }
  ]
}
```

**Come funziona: ** ogni istruzione utilizza una `StringNotEquals` condizione separata per una singola chiave di tag. Il Deny si attiva indipendentemente per ogni tag: se il `Project` tag della risorsa non corrisponde al tag del principale, l'accesso viene negato indipendentemente dal `Project` tag. `Department` Ciò garantisce che un principale taggato con `Project=FraudDetection` possa accedere solo ai cluster Neptune a cui è stato assegnato anche il tag, e analogamente per. `Project=FraudDetection` `Department`

### Nega l'accesso quando mancano i tag delle risorse richiesti
<a name="iam-data-tbac-pattern-deny-missing"></a>

Questo pattern impedisce l'accesso ai cluster Neptune che non sono stati etichettati correttamente, garantendo che tutti i cluster siano iscritti nello schema 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"
        }
      }
    }
  ]
}
```

**Come funziona: ** la `Null` condizione viene valutata vera quando la chiave tag specificata non esiste nella risorsa. Ciò obbliga tutti i cluster Neptune a contenere i tag di classificazione richiesti prima che qualsiasi principale possa accedervi.

### Combinazione del TBAC con il controllo degli accessi basato sull'azione
<a name="iam-data-tbac-pattern-combined-actions"></a>

Il TBAC può essere combinato con `neptune-db:` azioni specifiche per creare politiche dettagliate e basate sui tag:

```
{
  "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}"
        }
      }
    }
  ]
}
```

### Restrizione del linguaggio di interrogazione con TBAC
<a name="iam-data-tbac-pattern-query-language"></a>

Combina TBAC con la chiave `neptune-db:QueryLanguage` condizionale per limitare sia i cluster a cui può accedere un principale sia i linguaggi di interrogazione che può utilizzare:

```
{
  "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"
        }
      }
    }
  ]
}
```

## Utilizzo del TBAC con le politiche di controllo del servizio
<a name="iam-data-tbac-scps"></a>

Gli SCP sono ideali per applicare il TBAC perché stabiliscono i limiti di autorizzazione su un'intera unità organizzativa (OU) o account senza richiedere modifiche alle singole politiche IAM.

Consigliamo la seguente strategia SCP:

1. Applica un Deny-based SCP a livello di unità organizzativa che blocchi `neptune-db:*` quando i tag non corrispondono.

1. Applica una seconda dichiarazione che neghi l'accesso alle risorse senza tag.

1. I tuoi account individuali possono mantenere le loro politiche di autorizzazione per `neptune-db:` azioni specifiche: l'SCP funge da guardrail.

```
{
  "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"
        }
      }
    }
  ]
}
```

## Implementazione del TBAC per Neptune
<a name="iam-data-tbac-implementation"></a>

### Fase 1: Definisci la tassonomia dei tag
<a name="iam-data-tbac-step-taxonomy"></a>

Scegli le chiavi dei tag che rappresentino i confini della tua organizzazione. Schemi comuni:


**Esempio di tassonomia dei tag**  

| Chiave tag | Scopo | Valori di esempio | 
| --- | --- | --- | 
| Project | Identificatore dell'applicazione o del carico di lavoro | FraudDetection, RecommendationEngine | 
| Department | Unità aziendale o centro di costo | Engineering, Finance, Analytics | 
| Environment | Fase di implementazione | production, staging, development | 
| Team | Squadra proprietaria | graph-platform, data-science | 

### Passaggio 2: contrassegna i cluster Neptune DB
<a name="iam-data-tbac-step-tag-clusters"></a>

Usa il AWS CLI per aggiungere i tag di classificazione richiesti ai tuoi cluster Neptune DB:

```
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
```

### Passaggio 3: tagga i tuoi principali IAM
<a name="iam-data-tbac-step-tag-principals"></a>

Usa il AWS CLI per etichettare i ruoli IAM con le stesse chiavi e valori usati sui tuoi cluster Neptune. Per i ruoli IAM:

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

Per gli utenti federati, passa i tag tramite i tag di SAML/OIDC sessione utilizzando `aws:PrincipalTag` gli attributi del tuo provider di identità.

### Fase 4: Implementazione della politica TBAC
<a name="iam-data-tbac-step-deploy"></a>

Aggiungila come SCP per l'applicazione a livello di organizzazione o come policy IAM per un controllo mirato.

### Fase 5: Proteggi l'integrità dei tag
<a name="iam-data-tbac-step-protect-tags"></a>

Limita chi può modificare i tag sulle risorse Neptune e sui presidi IAM:

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

## Considerazioni importanti per il TBAC
<a name="iam-data-tbac-considerations"></a>
+ **Ritardo di propagazione**: le modifiche alle policy IAM richiedono fino a 10 minuti per essere applicate alle risorse Neptune. Le modifiche ai tag del cluster (aggiunta, modifica o rimozione di tag) richiedono circa 5 minuti per propagarsi alla valutazione delle policy del piano dati. Pianifica questo ritardo durante l'aggiornamento dei tag sui cluster attivi.
+ **Cluster-level granularità**: si applicano i tag ai cluster Neptune DB a livello di cluster. Tutte le istanze di un cluster condividono la stessa valutazione delle politiche. TBAC non fornisce un controllo degli accessi a livello di sottografo o vertex/edge a livello.
+ **Autenticazione IAM richiesta**: il TBAC si applica solo quando l'autenticazione IAM è abilitata sul cluster. Le connessioni senza autenticazione IAM aggirano completamente queste politiche.
+ **Immutabilità dei tag**: proteggi le tue operazioni di tagging. Se un responsabile può modificare i propri tag o i tag delle risorse, può bypassare i controlli TBAC. Usa gli SCP o i limiti di autorizzazione per limitare`iam:TagRole`,, e`iam:TagUser`. `rds:AddTagsToResource` `rds:RemoveTagsFromResource`
+ **Gestione dei tag nulli**: se a un principale manca un tag a cui fa riferimento la policy`${aws:PrincipalTag/{{Key}}}`, la variabile si risolve in una stringa vuota. Progetta le tue policy in modo da gestire questo caso (lo schema di negazione dei «tag mancanti» riportato sopra risolve questo problema per i tag delle risorse).
+ **Chiavi di condizione multiple**: quando più chiavi di condizione appaiono nello stesso `Condition` blocco, vengono valutate con la logica AND. Infatti`StringNotEquals`, un Deny si attiva solo quando * tutte le condizioni * specificate sono vere contemporaneamente. Per negare la mancata corrispondenza di * un singolo tag, utilizzate dichiarazioni politiche separate per ogni chiave del tag (come mostrato negli schemi precedenti). *

## Relazione con le funzionalità di sicurezza esistenti di Neptune
<a name="iam-data-tbac-relationship"></a>


**In che modo TBAC integra le funzionalità di sicurezza di Neptune esistenti**  

| Funzionalità esistente | Cosa controlla | In che modo TBAC lo integra | 
| --- | --- | --- | 
| VPC/Gruppi di sicurezza | Network-level accesso alla porta 8182 | TBAC aggiunge l'autorizzazione basata sull'identità ai controlli di rete | 
| Autenticazione IAM (SIGv4) | Verifica l'identità del chiamante | TBAC utilizza i tag dell'identità autenticata per le decisioni di autorizzazione | 
| Action-based controllo degli accessi | Quali operazioni (read/write/delete/load) può eseguire un preponente | Il TBAC aggiunge i cluster che un principale può scegliere come target, in base all'allineamento dei tag | 
| Chiave di condizione neptune-db:QueryLanguage | Quali linguaggi di interrogazione (Gremlin, OpenCypher, SPARQL) sono consentiti | Può essere combinato con TBAC nella stessa dichiarazione politica | 
| Accesso amministrativo basato su tag (azioni) rds:\* | Chi può gestire l'infrastruttura Neptune | TBAC estende lo stesso modello basato su tag alle azioni data-plane () neptune-db:\* | 
| AWS KMS crittografia | Riservatezza dei dati a riposo | Ortogonale: il TBAC controlla l'autorizzazione, non la crittografia |