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à.

# Document-level controlli di accesso
<a name="kb-managed-ds-s3-acl"></a>

**La consapevolezza ACL non è un'autorizzazione**  
Bedrock Managed Knowledge Base fornisce un ACL-aware filtro, non un limite di sicurezza. Bedrock Managed Knowledge Base non autentica gli utenti finali: l'applicazione è responsabile dell'autenticazione degli utenti e del passaggio del contesto di identità verificato. Poiché Bedrock Managed Knowledge Base non è in grado di verificare l'autenticità del contesto utente fornito, questa funzione filtra i risultati in base all'identità fornita ma non costituisce una vera autorizzazione. Non devi fare affidamento su questa funzionalità come unico meccanismo di controllo degli accessi senza l'autenticazione a monte.

Le fonti di dati Amazon S3 supportano opzionalmente il controllo degli accessi a livello di documento. A differenza di altri connettori, Amazon S3 non dispone di un sistema di autorizzazione nativo per la scansione, quindi definisci gli ACL tramite i file di configurazione che gestisci. Per una panoramica del riconoscimento ACL su tutti i connettori, consulta. [Attivazione del riconoscimento delle liste di controllo degli accessi](kb-managed-acl.md)

## Come funziona
<a name="kb-managed-ds-s3-acl-how"></a>

Per un'origine dati ACL-enabled Amazon S3, Bedrock Managed Knowledge Base applica gli elenchi di controllo degli accessi forniti dal cliente durante il filtraggio di pre-recupero, restituendo solo i documenti a cui l'utente che effettua la richiesta è autorizzato a accedere. Real-time La verifica ACL non è supportata per Amazon S3 perché i metadati ACL forniti dal cliente sono la fonte della verità.

## Abilita il riconoscimento ACL
<a name="kb-managed-ds-s3-acl-enable"></a>

Per abilitare il riconoscimento ACL per un'origine dati Amazon S3, `aclEnabled` imposta `true` in e definisci `connectorParameters` le autorizzazioni di accesso utilizzando uno dei due metodi seguenti:
+ File di **configurazione ACL globale: un singolo file** JSON centralizzato che definisce le autorizzazioni di accesso a livello di cartella (prefisso). Ideale per organizzazioni con strutture di autorizzazione stabili. Le modifiche al file globale richiedono la reindicizzazione del prefisso interessato.
+ **Document-level file di metadati**: ogni documento ha il proprio file di metadati contenente informazioni sul controllo degli accessi. Ciò consente aggiornamenti più rapidi dell'indice quando le autorizzazioni cambiano, perché solo i documenti interessati devono essere reindicizzati.

**Importante**  
Per le origini dati ACL-enabled Amazon S3, i documenti senza una voce ACL associata non vengono importati. Assicurati che ogni documento abbia un ACL definito tramite il file ACL globale o nel relativo file di metadati.

```
"connectorParameters": {
    "type": "S3",
    "version": "1",
    "aclEnabled": true,
    "connectionConfiguration": {
        "bucketName": "{{your-bucket-name}}",
        "bucketOwnerAccountId": "{{123456789012}}"
    },
    "aclConfiguration": {
        "globalAccessControlListS3Uri": "s3://{{your-bucket-name}}/{{acl/global-acl.json}}"
    }
}
```

## Struttura globale dei file ACL
<a name="kb-managed-ds-s3-acl-global"></a>

Il file ACL globale è un array JSON in cui ogni voce associa un prefisso chiave a un insieme di voci di controllo degli accessi. Ciascuno `keyPrefix` è l'URI Amazon S3 assoluto di una cartella (applicabile a tutti i documenti in essa contenuti) o di un singolo documento.

```
[
    {
        "keyPrefix": "s3://{{your-bucket-name}}/{{finance/}}",
        "aclEntries": [
            {
                "Name": "{{user1@example.com}}",
                "Type": "USER",
                "Access": "ALLOW"
            }
        ]
    }
]
```

Ogni `aclEntries` elemento contiene:
+ `Name`— L'indirizzo e-mail di un utente.
+ `Type`— Deve essere`USER`.
+ `Access`— O `ALLOW` o`DENY`. Le eccezioni di negazione sono consentite.

## Per-document file di metadati
<a name="kb-managed-ds-s3-acl-perdoc"></a>

In alternativa al file ACL globale, è possibile definire gli ACL per documento utilizzando i file di metadati. Per ogni documento, crea un file denominato `{{filename}}.metadata.json` nello stesso percorso Amazon S3. Includi un `accessControlList` array con lo stesso formato di immissione del file globale.

```
{
    "metadataAttributes": {},
    "accessControlList": [
        {
            "Name": "{{user1@example.com}}",
            "Type": "USER",
            "Access": "ALLOW"
        },
        {
            "Name": "{{user2@example.com}}",
            "Type": "USER",
            "Access": "DENY"
        }
    ]
}
```

Per-document i metadati hanno la precedenza sul file ACL globale. Se un documento ha sia una voce di prefisso globale corrispondente sia un file di metadati per documento, vengono utilizzati i metadati per documento.

**Nota**  
Il file di configurazione ACL deve essere archiviato nello stesso bucket Amazon S3 del contenuto dell'origine dati.

## Verifica la tua configurazione
<a name="kb-managed-ds-s3-acl-verify"></a>

Poiché gli ACL di Amazon S3 sono forniti dal cliente, convalidali prima di eseguire la query:

1. `aclEnabled`La conferma è `true` nella fonte dei dati. `connectorParameters`

1. Verifica che ogni documento abbia un ACL, ovvero una voce nel file ACL globale o un file per documento. `.metadata.json` I documenti senza un ACL non vengono inseriti.

1. Convalida l'ACL JSON: ogni voce contiene `Name` (email utente), () e `Type` `Access` (`ALLOW`or `USER``DENY`) e i file ACL si trovano nello stesso bucket dei tuoi contenuti.

1. Conferma che l'email di un utente di prova corrisponda esattamente `Name` a quella `ALLOW` inserita in un documento che ti aspetti che recuperi.

## Risoluzione dei problemi
<a name="kb-managed-ds-s3-acl-troubleshooting"></a>

**Nota**  
Le configurazioni errate dell'ACL non producono errori espliciti durante il recupero. Il recupero non riesce a essere chiuso: i documenti interessati vengono omessi automaticamente, quindi una query restituisce un numero inferiore o nullo di risultati anziché un errore. Utilizza i controlli di verifica sopra riportati per diagnosticare questi problemi.


**ACL-enabled Sintomi, cause e correzioni di Amazon S3**  

| Caratteristiche | Causa probabile | Correggere | 
| --- | --- | --- | 
| Recupera restituisce 0 risultati per un utente che dovrebbe avere accesso. | L'e-mail dell'utente non corrisponde a nessuna voce ACL (mancata corrispondenza dell'e-mail). | Assicurati che l'ACL Name corrisponda esattamente all'e-mail dell'utente. | 
| Un documento non viene mai restituito a nessuno. | Il documento non ha una voce ACL, quindi non è stato ingerito. | Aggiungi un ACL per il documento tramite il file ACL globale o un file per documento, quindi risincronizza. .metadata.json | 
| Un ACL per documento non ha effetto. | Il nome del .metadata.json file è errato o il percorso è errato. | Assegnagli il nome nello stesso percorso S3; i metadati per documento sostituiscono il file globale. {{filename}}.metadata.json | 
| Le modifiche ACL non vengono riflesse. | Le modifiche globali ai file ACL richiedono la reindicizzazione del prefisso interessato. | Sincronizza nuovamente il prefisso interessato. |