

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 degli 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 funzionalità filtra i risultati in base all'identità fornita ma non costituisce una vera autorizzazione. Non è necessario 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 autorizzazioni nativo per la scansione, quindi puoi definire gli ACL tramite i file di configurazione che gestisci. Per una panoramica del riconoscimento degli ACL su tutti i connettori, consulta. [Abilitazione alla sensibilizzazione degli elenchi 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 preliminare, restituendo solo i documenti a cui l'utente che effettua la query è autorizzato ad 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 degli ACL
<a name="kb-managed-ds-s3-acl-enable"></a>

Per abilitare il riconoscimento degli ACL per un'origine dati Amazon S3, imposta `aclEnabled` `connectorParameters` e definisci le autorizzazioni di accesso utilizzando uno dei due metodi seguenti: `true`
+ **File di configurazione ACL globale**: un singolo file JSON centralizzato che definisce le autorizzazioni di accesso a livello di cartella (prefisso). Ideale per le 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 fonti di dati ACL-enabled Amazon S3, i documenti senza una voce ACL associata non vengono inseriti. 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 set 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 email di un utente.
+ `Type`— Deve essere`USER`.
+ `Access`— Uno `ALLOW` o l'altro`DENY`. Nega le sostituzioni 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 un 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 una query:

1. `aclEnabled`La conferma è `true` nell'origine dei dati. `connectorParameters`

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

1. Convalida l'ACL JSON: ogni voce contiene `Name` (email dell'utente), `Type` () e `Access` (`ALLOW`o `USER``DENY`) e i file ACL si trovano nello stesso bucket del contenuto.

1. Conferma che l'email di un utente di prova corrisponda esattamente `Name` a quella contenuta in una `ALLOW` voce relativa a un documento che ti aspetti venga recuperato.

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

**Nota**  
Le configurazioni errate degli ACL non producono errori espliciti durante il recupero. Chiusura del recupero non riuscita: 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 | 
| --- | --- | --- | 
| Retrieve restituisce 0 risultati per un utente che dovrebbe avere accesso. | L'email dell'utente non corrisponde a nessuna voce ACL (email mismatch). | Assicurati che l'ACL Name corrisponda esattamente all'email dell'utente. | 
| Un documento non viene mai restituito a nessuno. | Il documento non contiene alcuna voce ACL, quindi non è stato inserito. | 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. | Assegna un nome {{filename}}.metadata.json allo stesso percorso S3; i metadati per documento hanno la precedenza sul file globale. | 
| Le modifiche ACL non vengono riflesse. | Le modifiche globali ai file ACL richiedono la reindicizzazione del prefisso interessato. | Risincronizza il prefisso interessato. | 