翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ドキュメントレベルのアクセスコントロール
<a name="kb-managed-ds-s3-acl"></a>

**ACL 対応は認可ではありません**  
Bedrock マネージドナレッジベースは、セキュリティ境界ではなく、ACL 対応のフィルタリングを提供します。Bedrock マネージドナレッジベースはエンドユーザーを認証しません。アプリケーションはユーザーを認証し、検証済みの ID コンテキストを渡す責任があります。Bedrock マネージドナレッジベースは、指定したユーザーコンテキストの信頼性を検証できないため、この機能は、指定した ID に基づいて結果をフィルタリングしますが、真の認可を構成するものではありません。アップストリーム認証なしでは、この機能を唯一のアクセスコントロールメカニズムとして使用しないでください。

Amazon S3 データソースは、オプションでドキュメントレベルのアクセスコントロールをサポートします。他のコネクタとは異なり、Amazon S3 にはクロールするネイティブアクセス許可システムがないため、管理する設定ファイルを使用して ACLs を定義します。すべてのコネクタにおける ACL 対応の概要については、「」を参照してください[アクセスコントロールリストの認識の有効化](kb-managed-acl.md)。

## 仕組み
<a name="kb-managed-ds-s3-acl-how"></a>

ACL 対応の Amazon S3 データソースの場合、Bedrock Managed Knowledge Base は、取得前のフィルタリング中にお客様が用意したアクセスコントロールリストを適用し、クエリユーザーがアクセスできるドキュメントのみを返します。お客様が用意した ACL メタデータが信頼できるソースであるため、Amazon S3 ではリアルタイムの ACL 検証はサポートされていません。

## ACL 対応を有効にする
<a name="kb-managed-ds-s3-acl-enable"></a>

Amazon S3 データソースの ACL 対応を有効にするには、 `true` で `aclEnabled`を に設定`connectorParameters`し、次の 2 つの方法のいずれかを使用してアクセス許可を定義します。
+ **グローバル ACL 設定ファイル** — フォルダ (プレフィックス) レベルでアクセス許可を定義する単一の一元化された JSON ファイル。安定したアクセス許可構造を持つ組織に最適です。グローバルファイルを変更するには、影響を受けるプレフィックスのインデックスを再作成する必要があります。
+ **ドキュメントレベルのメタデータファイル** — 各ドキュメントには、アクセスコントロール情報を含む独自のメタデータファイルがあります。これにより、影響を受けるドキュメントのみがインデックスの再作成を必要とするため、アクセス許可が変更されたときのインデックスの更新が高速化されます。

**重要**  
ACL 対応 Amazon S3 データソースの場合、ACL エントリが関連付けられていないドキュメントは取り込まれません。すべてのドキュメントに、グローバル ACL ファイルまたはそのメタデータファイルを通じて定義された ACL があることを確認します。

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

## グローバル ACL ファイル構造
<a name="kb-managed-ds-s3-acl-global"></a>

グローバル ACL ファイルは、各エントリがキープレフィックスをアクセスコントロールエントリのセットにマッピングする JSON 配列です。各 `keyPrefix`は、フォルダ (その下にあるすべてのドキュメントに適用) または個々のドキュメントの絶対 Amazon S3 URI です。

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

各`aclEntries`要素には以下が含まれます。
+ `Name` — ユーザーの E メールアドレス。
+ `Type` — である必要があります`USER`。
+ `Access` — `ALLOW`または のいずれか`DENY`。オーバーライドの許可を拒否します。

## ドキュメントごとのメタデータファイル
<a name="kb-managed-ds-s3-acl-perdoc"></a>

グローバル ACL ファイルの代わりに、メタデータファイルを使用してドキュメントごとに ACLs を定義できます。ドキュメントごとに、同じ Amazon S3 パス`{{filename}}.metadata.json`に という名前のファイルを作成します。グローバルファイルと同じエントリ形式の`accessControlList`配列を含めます。

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

ドキュメントごとのメタデータは、グローバル ACL ファイルよりも優先されます。ドキュメントに一致するグローバルプレフィックスエントリとドキュメントごとのメタデータファイルの両方がある場合、ドキュメントごとのメタデータが使用されます。

**注記**  
ACL 設定ファイルは、データソースコンテンツと同じ Amazon S3 バケットに保存する必要があります。

## 設定を確認する
<a name="kb-managed-ds-s3-acl-verify"></a>

Amazon S3 ACLs はお客様が提供するため、クエリを実行する前に検証してください。

1. `aclEnabled` がデータソースの `true`にあることを確認します`connectorParameters`。

1. すべてのドキュメントに ACL があることを確認します。グローバル ACL ファイルまたはドキュメントごとの`.metadata.json`ファイルのエントリです。ACL のないドキュメントは取り込まれません。

1. ACL JSON を検証します。各エントリには `Name` (ユーザーの E メール)`Type`、 (`USER`)、 `Access` (`ALLOW` または `DENY`) があり、ACL ファイルはコンテンツと同じバケットにあります。

1. テストユーザーの E メールが、取得する予定のドキュメントの`ALLOW`エントリ`Name`の と正確に一致することを確認します。

## トラブルシューティング
<a name="kb-managed-ds-s3-acl-troubleshooting"></a>

**注記**  
ACL の設定ミスは、取得中に明示的なエラーを生成しません。取得がクローズに失敗する: 影響を受けるドキュメントはサイレントに省略されるため、クエリはエラーではなく少数またはゼロの結果を返します。上記の検証チェックを使用して、これらの問題を診断します。


**ACL 対応の Amazon S3 の症状、原因、修正**  

| 症状 | 考えられる原因 | Fix | 
| --- | --- | --- | 
| 取得は、アクセス権を持つ必要があるユーザーの結果を 0 回返します。 | ユーザーの E メールが ACL エントリと一致しません (E メールが一致しません）。 | ACL がユーザーの E メールと正確にName一致していることを確認します。 | 
| ドキュメントは誰にも返されません。 | ドキュメントには ACL エントリがないため、取り込まれませんでした。 | グローバル ACL ファイルまたはドキュメントごとの.metadata.jsonファイルを使用してドキュメントの ACL を追加し、再同期します。 | 
| ドキュメントごとの ACL は有効になっていません。 | .metadata.json ファイルの名前が間違っているか、パスが間違っています。 | 同じ S3 パス{{filename}}.metadata.jsonに名前を付けます。ドキュメントごとのメタデータはグローバルファイルを上書きします。 | 
| ACL の変更は反映されません。 | グローバル ACL ファイルの変更には、影響を受けるプレフィックスのインデックス再作成が必要です。 | 影響を受けるプレフィックスを再同期します。 |