本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 文件層級存取控制
<a name="kb-managed-ds-s3-acl"></a>

**ACL 意識不是授權**  
Bedrock 受管知識庫提供 ACL 感知篩選，而不是安全界限。Bedrock 受管知識庫不會驗證最終使用者 — 您的應用程式負責驗證使用者並傳遞已驗證的身分內容。由於 Bedrock 受管知識庫無法驗證您提供的使用者內容的真實性，因此此功能會根據您提供的身分篩選結果，但不會構成真正的授權。在沒有上游身分驗證的情況下，您不得依賴此功能做為唯一存取控制機制。

Amazon S3 資料來源可選擇性支援文件層級存取控制。與其他連接器不同，Amazon S3 沒有原生的爬取許可系統，因此您可以透過您管理的組態檔案來定義 ACLs。如需所有連接器的 ACL 意識概觀，請參閱 [存取控制清單意識啟用](kb-managed-acl.md)。

## 運作方式
<a name="kb-managed-ds-s3-acl-how"></a>

對於啟用 ACL 的 Amazon S3 資料來源，Bedrock 受管知識庫會在擷取前篩選期間套用客戶提供的存取控制清單，僅傳回查詢使用者允許存取的文件。Amazon S3 不支援即時 ACL 驗證，因為客戶提供的 ACL 中繼資料是事實來源。

## 啟用 ACL 意識
<a name="kb-managed-ds-s3-acl-enable"></a>

若要啟用 Amazon S3 資料來源的 ACL 意識，請在 `true`中將 `aclEnabled`設定為 `connectorParameters`，並使用下列兩種方法之一定義存取許可：
+ **全域 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` — 使用者的電子郵件地址。
+ `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`（使用者電子郵件）、 `Type` (`USER`) 和 `Access`(`ALLOW` 或 `DENY`)，而且 ACL 檔案與您的內容位於相同的儲存貯體中。

1. 針對您希望使用者擷取的文件，確認測試使用者的電子郵件完全符合 `ALLOW` 項目`Name`中的 。

## 疑難排解
<a name="kb-managed-ds-s3-acl-troubleshooting"></a>

**注意**  
ACL 設定錯誤不會在擷取期間產生明確的錯誤。擷取關閉失敗：會無提示地省略受影響的文件，因此查詢會傳回較少或零的結果，而不是錯誤。使用上述驗證檢查來診斷這些問題。


**啟用 ACL 的 Amazon S3 症狀、原因和修正**  

| 徵狀 | 可能原因 | 修正 | 
| --- | --- | --- | 
| 擷取應為應具有存取權的使用者傳回 0 個結果。 | 使用者的電子郵件不符合任何 ACL 項目 （電子郵件不相符）。 | 確保 ACL 完全Name符合使用者的電子郵件。 | 
| 文件永遠不會傳回給任何人。 | 文件沒有 ACL 項目，因此不會擷取。 | 透過全域 ACL 檔案或每個文件.metadata.json檔案新增文件的 ACL，然後重新同步。 | 
| 每個文件 ACL 不會生效。 | .metadata.json 檔案命名錯誤或路徑錯誤。 | 在相同的 S3 路徑{{filename}}.metadata.json中命名它；每個文件中繼資料會覆寫全域檔案。 | 
| ACL 變更不會反映。 | 全域 ACL 檔案變更需要重新索引受影響的字首。 | 重新同步受影響的字首。 |