翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# ナレッジベースで ACLs を管理するためのベストプラクティス
ドキュメントレベルのアクセスコントロールリスト (ACLs) を使用すると、Amazon Quick は ACL 対応ナレッジベースのソースドキュメントアクセス許可を適用します。承認された各ユーザーは、アクセス許可を持つインデックス付きドキュメントのみを取得します。異なるユーザーが同じナレッジベースの異なるドキュメントにアクセスする必要がある場合ACLs を使用します。
ソース ID、グループ、およびドキュメントのアクセス許可を正確に保つ責任があります。Quick は、取得するたびに同期されたドキュメントのアクセス許可を適用します。サポートされている統合では、結果を返すときに、ソースに対するドキュメントアクセスをリアルタイムで検証します。Quick がクエリのドキュメントのアクセス許可を評価できない場合、フィルタリングされていない結果ではなくドキュメントが返されません。
Quick は、ナレッジベースの更新スケジュールでアイデンティティとドキュメントのアクセス許可の変更を同期します。デフォルトでは 24 時間ごとです。アクセス変更要件が要求する場合に、別のスケジュールを設定します。
**共有とドキュメントアクセスは個別のコントロールです**
ナレッジベースを共有し、ドキュメントへのアクセスを許可することは、個別のコントロールです。ナレッジベースの共有は、ナレッジベースを使用できるユーザーを決定します。ACL 対応のナレッジベースの場合、ソースドキュメント ACLs、承認された各ユーザーが取得できるインデックス付きドキュメントをさらに制限します。アクセスを許可する前に、両方のコントロールを確認してください。
特定のデータソースの ACLs[Amazon S3](s3-integration.md)、、[Google Drive](google-drive-kb-acl.md)または」を参照してください[Microsoft SharePoint](sharepoint-kb-acl.md)。[Atlassian Confluence Cloud](confluence-kb-acl.md) および の場合[Microsoft OneDrive](onedrive-kb-acl.md)、利用可能な場合はコンソールでドキュメントレベルの ACLs を設定します。
ドキュメントレベルのアクセスコントロールを検証し、アクセス許可の問題をトラブルシューティングするには、「」を参照してください[ドキュメントアクセスの確認 (ACL 検証)](sync-reports-observability.md#sync-reports-acl-verification)。
**注記**
Quick は、すべての E メールアドレスを大文字と小文字を区別しません。`JohnDoe@example.com`、`johndoe@example.com`、および `JOHNDOE@example.com`はすべて同じユーザーと見なされます。
## 作成前に ACL 対応ナレッジベースを計画する
ACL 対応ナレッジベースを作成する前に、次の手順を実行します。
1. 統合がドキュメントレベルの ACLs をサポートしていることを確認します。
1. Quick がユーザーとグループの解決に使用する ID 属性を確認します。
Quick はACLs を解決します。詳細については、「[制限事項](#acl-limitations)」を参照してください。
1. 他のユーザーに割り当てる前に、ソース ACLs から共有またはリサイクルされた ID を削除します。
1. アクセス変更要件を満たす更新スケジュールを選択します。Amazon S3 の場合、アクセス許可の変更は次回の同期時に有効になるため、それに応じてスケジュールを計画します。
1. ナレッジベースを広く共有する前に、代表的なユーザーとドキュメントアクセスをテストします。ドキュメントへのアクセスを確認するには、「」を参照してください[ドキュメントアクセスの確認 (ACL 検証)](sync-reports-observability.md#sync-reports-acl-verification)。
1. Quick Research にナレッジベースが必要でないことを確認します。
1. 管理者管理ナレッジベースに追加の所有者を少なくとも 1 人割り当てて、元の作成者が退出しても管理できるようにします。
## 重要なユーザー管理シナリオ
**E メールバインディングについて**
E メールアドレスは、ユーザーがチャットインタラクションを開始すると、Quick ユーザーに動的にバインドされます。このバインディングは、first-come-first-serveのアプローチに従います。特定の E メールアドレスとチャットする最初のユーザーは、名前空間内でその ID のバインドを確立します。
**従業員が組織を離れたとき**
従業員が退職したら、すぐにアクセスをクリーンアップします。
1. ACL 設定ファイルを更新して、E メールアドレスへの参照を削除します。例えば、Amazon S3 では、グローバル ACL ファイルまたはメタデータファイルを更新します。
1. ナレッジベースを更新して変更を適用します。
これにより、E メールが後で別のユーザーに再割り当てされた場合に発生する可能性のあるセキュリティの問題を回避できます。
ナレッジベース ACLsは、クイックからユーザーを削除するのとは別のものです。ユーザーの削除がユーザーのアセットとデータにどのように影響するかの完全なモデルについては、「」を参照してください[Amazon Quick でのユーザーライフサイクルとデータ処理](user-lifecycle-data-handling.md)。
**管理者管理のナレッジベースを共同所有者と共有する**
管理者管理のナレッジベース (サービス認証情報) は、多くの場合、チームや組織全体で使用されます。元の作成者が退職し、共同所有者が存在しない場合、ナレッジベースは管理不能になります。誰も設定の編集、同期のトリガー、アクセス許可の更新を行うことはできません。これを回避するには、管理者管理のナレッジベースを少なくとも 1 人の追加の所有者と共有します。詳細については、「[ナレッジベースとデータソースの共有](sharing-kb-datasources.md)」を参照してください。
**E メールアドレスが新しい従業員に再割り当てされた場合**
+ ACL 対応ナレッジベースのアクセスは、データセキュリティを保護するために、再割り当てされた E メールアドレスに対して自動的にロックされます。
+ 新しい従業員がその E メールに関連付けられたドキュメントにアクセスする前に、クイックサポートに連絡して、以前のユーザーのアクセスをクリーンアップしてください。
## 制限事項
ナレッジベースのドキュメントレベルの ACLs を設定するときは、次の制限に注意してください。
+ **ドキュメントレベルの ACL 設定は永続的** – ACLs サポートなしで作成されたナレッジベースの ACL を有効にすることはできません。また、オンにした後でオフにすることはできません。ACL 設定を変更するには、最初から必要な設定で新しいナレッジベースを作成します。
+ **名前空間内の共有 E メールアドレス** – 複数の Quick ユーザーが名前空間内で同じ E メールアドレスを共有する場合、システムはその共有 E メールを使用したすべてのユーザーへのアクセスを拒否します。この保護により、誤ったユーザーにドキュメントアクセスを誤って付与することを防ぎます。
+ **ACL 解決スコープ** – ナレッジベース作成者の名前空間内のすべての ACLs をクイック解決します。これは、E メールアドレスまたはグループ名で ACLs を指定する場合に適用されます。クイックは、作成者の組織コンテキストで ID を検索して、一貫した ID 解決を確保します。
+ **E メールアドレスのリサイクルタイミング** – 組織が E メールアドレスをある従業員から別の従業員に再割り当てする場合は、重要なタイミングを考慮する必要があります。前の従業員がチャットや AI とのやり取りに Quick を使用したことがなく、次回の ACL 更新前に E メールが再割り当てされた場合、新しい従業員は前の従業員向けのドキュメントに一時的にアクセスすることがあります。
これを回避するには、次の手順を順番に実行します。
1. ACLs (該当する場合、Amazon S3 など) を更新して古いユーザーを削除し、新しいユーザーを追加します。
1. ナレッジベースを手動で更新するか、毎日の自動更新を待ちます。
1. 新しい従業員に E メールアドレスを割り当てます。
これにより、新しいユーザーが Quick の使用を開始する前に、アクセス許可が適切に同期されます。
**研究の互換性**
ドキュメントレベルの ACLsが有効になっているナレッジベースは、現在 Quick Research と互換性がありません。ACL 対応のナレッジベースのドキュメントを研究に使用する必要がある場合は、それらのドキュメントの ACLs なしで別のナレッジベースを作成します。