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

# Melhores práticas para gerenciar ACLs em bases de conhecimento
<a name="acl-best-practices-kb"></a>

Ao usar bases de conhecimento com listas de controle de acesso (ACLs), você é responsável por manter as identidades e permissões dos usuários precisas. Isso garante que as pessoas certas possam acessar os documentos certos. Por padrão, o Quick sincroniza automaticamente as alterações de ACL em nível de documento e de identidade a cada 24 horas. Qualquer atualização de usuários ou permissões levará até um dia para aparecer no sistema, a menos que você tenha configurado um cronograma de atualização diferente para suas bases de conhecimento.

[[Para obter mais informações sobre a configuração de ACLs para uma fonte de dados específica, consulte [Amazon S3](s3-integration.md), [Atlassian Confluence Cloud,](confluence-kb-acl.md) Google Drive ou Microsoft. SharePoint](sharepoint-kb-acl.md)](google-drive-kb-acl.md)

Para verificar os controles de acesso em nível de documento e solucionar problemas de permissão, consulte. [Verifique o acesso ao documento (verificação da ACL)](sync-reports-observability.md#sync-reports-acl-verification)

**nota**  
O Quick trata todos os endereços de e-mail como não diferenciando maiúsculas de minúsculas. `JohnDoe@example.com`,`johndoe@example.com`, e `JOHNDOE@example.com` são todos considerados o mesmo usuário.

## Cenários importantes de gerenciamento de usuários
<a name="acl-user-management-scenarios"></a>

**Compreendendo a vinculação de e-mail**

Os endereços de e-mail são vinculados dinamicamente aos usuários do Quick quando os usuários iniciam interações de bate-papo. Essa vinculação segue a abordagem “primeiro a chegar, primeiro a ser servido”. O primeiro usuário a conversar com um determinado endereço de e-mail estabelece a vinculação dessa identidade dentro do namespace.

**Quando um funcionário deixa sua organização**

Quando um funcionário sair, limpe seu acesso imediatamente:

1. Atualize os arquivos de configuração da ACL para remover referências ao endereço de e-mail. Por exemplo, no Amazon S3, atualize o arquivo ACL global ou os arquivos de metadados.

1. Atualize as bases de conhecimento para aplicar as mudanças.

Isso evita possíveis problemas de segurança se o e-mail for posteriormente reatribuído a outra pessoa.

**Compartilhe bases de conhecimento gerenciadas pelo administrador com coproprietários**

Admin-managed as bases de conhecimento (credenciais de serviço) são frequentemente usadas em equipes e organizações. Se o criador original deixar a empresa e não houver coproprietários, a base de conhecimento se tornará incontrolável — ninguém poderá editar configurações, acionar sincronizações ou atualizar permissões. Para evitar isso, compartilhe bases de conhecimento gerenciadas pelo administrador com pelo menos um proprietário adicional. Para obter mais informações, consulte [Compartilhamento de bases de conhecimento e fontes de dados](sharing-kb-datasources.md).

**Quando um endereço de e-mail é reatribuído a um novo funcionário**
+ ACL-aware o acesso à base de conhecimento é bloqueado automaticamente para o endereço de e-mail reatribuído para proteger a segurança dos dados.
+ Entre em contato com o suporte rápido para limpar o acesso do usuário anterior antes que o novo funcionário possa acessar os documentos associados a esse e-mail.

## Limitações
<a name="acl-limitations"></a>

Ao configurar ACLs em nível de documento para suas bases de conhecimento, esteja ciente dessas limitações:
+ Document-level A **configuração da ACL é permanente** — você não pode habilitar ACLs em bases de conhecimento criadas sem o suporte da ACL. Você também não pode desativar as ACLs depois de ativadas. Para alterar a configuração da ACL, crie uma nova base de conhecimento com a configuração desejada desde o início.
+ **Endereços de e-mail compartilhados em um namespace** — Se vários usuários do Quick compartilharem o mesmo endereço de e-mail em um namespace, o sistema negará o acesso a todos que usam esse e-mail compartilhado. Essa proteção evita a concessão acidental de acesso ao documento à pessoa errada.
+ **Escopo da resolução da ACL** — todas as ACLs são resolvidas no namespace Quick do criador da base de conhecimento. Isso se aplica se as ACLs forem especificadas por endereço de e-mail ou nome do grupo. O Quick pesquisa identidades no contexto organizacional do criador para garantir uma resolução consistente de identidade.
+ **Tempo de reciclagem de endereços de e-mail** — Se sua organização reatribuir um endereço de e-mail de um funcionário para outro, há uma consideração importante sobre o tempo. Se o funcionário anterior nunca usou o Quick para interações de bate-papo ou IA e o e-mail for reatribuído antes da próxima atualização da ACL, o novo funcionário poderá acessar temporariamente os documentos destinados ao funcionário anterior.

  Para evitar isso, conclua as seguintes etapas na ordem:

  1. Atualize suas ACLs (se aplicável, como no Amazon S3) para remover o usuário antigo e adicionar o novo usuário.

  1. Atualize manualmente sua base de conhecimento ou aguarde a atualização diária automática.

  1. Atribua o endereço de e-mail ao novo funcionário.

  Isso garante que as permissões de acesso sejam sincronizadas adequadamente antes que o novo usuário comece a usar o Quick.
+ **Compatibilidade de pesquisa** — As bases de conhecimento com ACLs em nível de documento habilitadas atualmente não são compatíveis com a Pesquisa Rápida. Se você precisar usar documentos de uma base de ACL-enabled conhecimento para fins de pesquisa, crie uma base de conhecimento separada sem ACLs para esses documentos.