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à.
Le migliori pratiche per la gestione degli ACL nelle knowledge base
Con gli elenchi di controllo degli accessi (ACL) a livello di documento, Amazon Quick applica le autorizzazioni dei documenti di origine per una knowledge base. ACL-aware Ogni utente autorizzato recupera solo i documenti indicizzati a cui ha il permesso di accedere. Utilizza gli ACL quando utenti diversi devono accedere a documenti diversi nella stessa knowledge base.
Sei responsabile dell'accuratezza delle identità di origine, dei gruppi e delle autorizzazioni dei documenti. Quick applica le autorizzazioni sincronizzate del documento a ogni recupero. Per le integrazioni supportate, verifica inoltre l'accesso ai documenti rispetto alla fonte in tempo reale quando restituisce i risultati. Se Quick non è in grado di valutare le autorizzazioni dei documenti per una query, non restituisce alcun documento anziché risultati non filtrati.
Quick sincronizza le modifiche all'identità e alle autorizzazioni dei documenti in base alla pianificazione di aggiornamento della knowledge base, che per impostazione predefinita è ogni 24 ore. Configura una pianificazione diversa quando i requisiti di modifica degli accessi lo richiedono.
La condivisione e l'accesso ai documenti sono controlli separati
La condivisione di una base di conoscenze e la concessione dell'accesso ai documenti sono controlli separati. Knowledge-base la condivisione determina chi può utilizzare la knowledge base. Per le ACL-aware knowledge base, gli ACL dei documenti di origine limitano ulteriormente i documenti indicizzati che ogni utente autorizzato può recuperare. Rivedi entrambi i controlli prima di concedere l'accesso.
Per ulteriori informazioni sulla configurazione degli ACL per una specifica origine dati, consulta Amazon S3,, o. Google Drive Microsoft SharePoint Per Atlassian Confluence Cloud e Microsoft OneDrive, configura gli ACL a livello di documento nella console, ove disponibili.
Per verificare i controlli di accesso a livello di documento e risolvere i problemi relativi alle autorizzazioni, consulta. Verifica l'accesso ai documenti (verifica ACL)
Nota
Quick considera tutti gli indirizzi e-mail senza distinzione tra maiuscole e minuscole. JohnDoe@example.come JOHNDOE@example.com sono tutti considerati lo stesso utente. johndoe@example.com
Pianifica ACL-aware le basi di conoscenza prima della creazione
Prima di creare una ACL-aware knowledge base, completa i seguenti passaggi:
-
Verifica che l'integrazione supporti gli ACL a livello di documento.
-
Conferma l'attributo di identità utilizzato da Quick per risolvere utenti e gruppi.
Quick risolve gli ACL all'interno dello spazio dei nomi del creatore della knowledge base. Per informazioni dettagliate, vedi Limitazioni.
-
Rimuovi le identità condivise o riciclate dagli ACL di origine prima di assegnarle a un'altra persona.
-
Seleziona una pianificazione di aggiornamento che soddisfi i requisiti di modifica dell'accesso. Per Amazon S3, le modifiche alle autorizzazioni hanno effetto alla sincronizzazione successiva, quindi pianifica la pianificazione di conseguenza.
-
Verifica l'accesso ai documenti con gli utenti rappresentativi prima di condividere ampiamente la knowledge base. Per verificare l'accesso ai documenti, vedereVerifica l'accesso ai documenti (verifica ACL).
-
Conferma che la knowledge base non è richiesta per Quick Research.
-
Assegna almeno un proprietario aggiuntivo a una knowledge base gestita dagli amministratori in modo che rimanga gestibile anche quando il creatore originale se ne va.
Scenari importanti di gestione degli utenti
Comprendere l'associazione delle e-mail
Gli indirizzi email sono associati agli utenti di Quick in modo dinamico quando gli utenti avviano interazioni via chat. Questa associazione segue un approccio «primo arrivato, primo servito». Il primo utente che chatta con un determinato indirizzo email stabilisce l'associazione di quell'identità all'interno del namespace.
Quando un dipendente lascia l'organizzazione
Quando un dipendente se ne va, ripulisci prontamente il suo accesso:
-
Aggiorna i file di configurazione ACL per rimuovere i riferimenti al relativo indirizzo email. Ad esempio, in Amazon S3, aggiorna il file ACL globale o i file di metadati.
-
Aggiorna le basi di conoscenza per applicare le modifiche.
In questo modo si evitano potenziali problemi di sicurezza se l'e-mail viene successivamente riassegnata a qualcun altro.
L'aggiornamento degli ACL della knowledge base è separato dalla rimozione dell'utente da Quick. Per un modello completo di come la rimozione degli utenti influisce sulle risorse e sui dati di un utente, consultaCiclo di vita degli utenti e gestione dei dati in Amazon Quick.
Condividi le knowledge base gestite dagli amministratori con i comproprietari
Admin-managed le knowledge base (credenziali di servizio) vengono spesso utilizzate da team e organizzazioni. Se il creatore originale lascia l'azienda e non esistono comproprietari, la knowledge base diventa ingestibile: nessuno può modificare le impostazioni, attivare sincronizzazioni o aggiornare le autorizzazioni. Per evitare che ciò accada, condividi le knowledge base gestite dagli amministratori con almeno un altro proprietario. Per ulteriori informazioni, consulta Condivisione di basi di conoscenze e fonti di dati.
Quando un indirizzo email viene riassegnato a un nuovo dipendente
-
ACL-aware L'accesso alla knowledge base viene bloccato automaticamente per l'indirizzo e-mail riassegnato per proteggere la sicurezza dei dati.
-
Contatta l'assistenza rapida per ripulire l'accesso dell'utente precedente prima che il nuovo dipendente possa accedere ai documenti associati a quell'email.
Limitazioni
Quando configuri gli ACL a livello di documento per le tue knowledge base, tieni presente queste limitazioni:
-
Document-level La configurazione ACL è permanente: non è possibile attivare gli ACL per una knowledge base creata senza il supporto ACL. Inoltre, non è possibile disattivarli dopo averli accesi. Per modificare la configurazione ACL, create sin dall'inizio una nuova knowledge base con l'impostazione desiderata.
-
Indirizzi email condivisi all'interno di un namespace: se più utenti Quick condividono lo stesso indirizzo email all'interno di un namespace, il sistema nega l'accesso a tutti coloro che utilizzano quell'email condivisa. Questa protezione impedisce di concedere accidentalmente l'accesso ai documenti alla persona sbagliata.
-
Ambito di risoluzione ACL: Quick risolve tutti gli ACL all'interno dello spazio dei nomi del creatore della knowledge base. Ciò vale indipendentemente dal fatto che si specifichino gli ACL tramite indirizzo e-mail o nome del gruppo. Ricerca rapidamente le identità nel contesto organizzativo dell'autore per garantire una risoluzione coerente delle identità.
-
Tempi di riciclo degli indirizzi e-mail: se la tua organizzazione riassegna un indirizzo email da un dipendente a un altro, è importante considerare le tempistiche. Se il dipendente precedente non ha mai utilizzato Quick per le interazioni via chat o AI e l'email viene riassegnata prima del successivo aggiornamento dell'ACL, il nuovo dipendente può accedere temporaneamente ai documenti destinati al dipendente precedente.
Per evitare che ciò accada, completa i seguenti passaggi in ordine:
-
Aggiorna i tuoi ACL (se applicabile, ad esempio in Amazon S3) per rimuovere il vecchio utente e aggiungere il nuovo utente.
-
Aggiorna manualmente la tua knowledge base o attendi l'aggiornamento giornaliero automatico.
-
Assegna l'indirizzo email al nuovo dipendente.
Ciò garantisce che le autorizzazioni di accesso siano sincronizzate correttamente prima che il nuovo utente inizi a utilizzare Quick.
-
Compatibilità della ricerca
Le knowledge base con ACL a livello di documento abilitati non sono attualmente compatibili con Quick Research. Se hai bisogno di utilizzare i documenti di una ACL-enabled knowledge base per la ricerca, crea una knowledge base separata senza ACL per tali documenti.
