View a markdown version of this page

文件層級存取控制 - Amazon Bedrock
運作方式啟用 ACL 意識全域 ACL 檔案結構每個文件中繼資料檔案驗證您的組態疑難排解

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

文件層級存取控制

ACL 意識不是授權

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

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

運作方式

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

啟用 ACL 意識

若要啟用 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 檔案結構

全域 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。拒絕覆寫允許。

每個文件中繼資料檔案

作為全域 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 儲存貯體中。

驗證您的組態

由於 Amazon S3 ACLs 是由客戶提供，因此請在查詢之前對其進行驗證：

  1. 確認 aclEnabled 位於資料來源的 true中connectorParameters。

  2. 確認每個文件都有 ACL — 全域 ACL 檔案中的項目或每個文件.metadata.json檔案中的項目。沒有 ACL 的文件不會擷取。

  3. 驗證 ACL JSON：每個項目都有 Name（使用者電子郵件）、 Type (USER) 和 Access(ALLOW 或 DENY)，而且 ACL 檔案與您的內容位於相同的儲存貯體中。

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

疑難排解

注意

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

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