Secure multi-tenant RAG with Amazon Bedrock and Verified Permissions使用 Amazon Bedrock 和 Verified Permissions 实现安全的多租户 RAG

Large organizations building internal generative AI applications face a recurring challenge: controlling which teams or departments can access which documents, without duplicating infrastructure for each group. Within a single tenant, employees from a specific department should only access material assigned to that department. However, executives, with a wider span of control, will require access to material across multiple departments. Retrieval Augmented Generation (RAG) is one of several complementary techniques, including fine-tuning and continued pre-training, for customizing generative AI application responses with your data.构建内部生成式 AI 应用程序的大型组织面临一个反复出现的挑战：控制哪些团队或部门可以访问哪些文档，同时避免为每个组重复建设基础设施。在单个租户内，来自特定部门的员工应只能访问分配给该部门的材料。然而，控制范围更广的高管需要跨多个部门的访问权限。检索增强生成（RAG）是定制生成式 AI 应用程序响应的几种互补技术之一，包括微调和持续预训练。

In an enterprise context, with fast-moving data and many users, RAG provides a middle ground between cost and performance. This post shows you how to use a single, shared Knowledge Base (KB) instance to reduce the cost and complexity of separate instances. You can update access rules in minutes without redeploying code and maintain a detailed audit trail of every authorization decision. You run a single RAG application that serves multiple departments, with document access evaluated at retrieval time.在企业环境中，面对快速变化的数据和众多用户，RAG 在成本和性能之间提供了中间地带。本文向您展示如何使用单个共享知识库（KB）实例来降低多个实例的成本和复杂性。您可以在几分钟内更新访问规则，无需重新部署代码，并保留每个授权决策的详细审计跟踪。您运行一个服务多个部门的 RAG 应用程序，文档访问在检索时进行评估。

Figure 1 illustrates the requirement.图 1 展示了该需求。

A previous post, Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering, demonstrates how to use Amazon Simple Storage Service (Amazon S3) folder structures and metadata filtering to segregate data between tenants within a single knowledge base. That pattern works well for broad, tenant-level boundaries where the filter value is known at design time and embedded in application code. However, within a single tenant, different departments or roles often need different document visibility and executives may need cross-cutting access that spans multiple boundaries. This post extends that foundation by externalizing the filter selection logic into Cedar policies managed by Amazon Verified Permissions, allowing dynamic, runtime-evaluated authorization decisions.之前的一篇文章《在单个 Amazon Bedrock 知识库中使用元数据过滤实现 RAG 应用程序的多租户》演示了如何使用 Amazon Simple Storage Service（Amazon S3）文件夹结构和元数据过滤在单个知识库中隔离不同租户的数据。该模式适用于广泛的租户级边界，其中过滤值在设计时已知并嵌入到应用程序代码中。然而，在单个租户内，不同部门或角色通常需要不同的文档可见性，高管可能需要跨多个边界的跨部门访问。本文通过将过滤选择逻辑外部化为由 Amazon Verified Permissions 管理的 Cedar 策略来扩展该基础，实现动态的、运行时评估的授权决策。

This pattern lets a single RAG application serve many departments while keeping each department’s documents isolated, without standing up a knowledge base per team. It builds on metadata filtering in Amazon Bedrock Knowledge Bases, a fully managed RAG capability that handles ingestion, retrieval, and prompt augmentation through a single API. Metadata filtering is a strong foundation, but it creates a gap. Filter selection logic has no external governance, and changing the rules requires a code redeployment.此模式允许一个 RAG 应用程序服务多个部门，同时保持每个部门的文档隔离，无需为每个团队建立知识库。它建立在 Amazon Bedrock Knowledge Bases 的元数据过滤之上，这是一种完全托管的 RAG 功能，通过单个 API 处理摄取、检索和提示增强。元数据过滤是一个坚实的基础，但它也带来了差距。过滤选择逻辑没有外部治理，更改规则需要重新部署代码。

When authorization logic lives inside code, rules can become inconsistent over time and require a full deployment cycle to change. Amazon Verified Permissions addresses this by providing scalable, fine-grained authorization and permissions management for custom applications. Externalized Cedar policies in Verified Permissions are auditable, version-controlled, and updatable at runtime.当授权逻辑存在于代码中时，规则可能随着时间推移变得不一致，并且需要完整的部署周期才能更改。Amazon Verified Permissions 通过为自定义应用程序提供可扩展的细粒度授权和权限管理解决了这个问题。Verified Permissions 中外部化的 Cedar 策略是可审计的、受版本控制且可在运行时更新。

This post walks you through a two-layer, defense-in-depth authorization pattern for granular, intra-tenant access control in RAG applications. Defense in depth is a security strategy that uses multiple independent layers of protection. Each layer operates independently. If one layer is misconfigured, the other layer still enforces access control. The pattern runs on Amazon Bedrock, a fully managed service that offers a choice of high-performing foundation models (FMs) from Amazon and AI companies through a single API, along with a broad set of capabilities you need to build generative AI applications with security, privacy, and responsible AI.本文引导您了解一个用于 RAG 应用程序中细粒度租户内访问控制的两层纵深防御授权模式。纵深防御是一种使用多个独立保护层的安全策略。每个层独立运行。如果一个层配置错误，另一层仍然强制实施访问控制。该模式运行在 Amazon Bedrock 上，这是一项完全托管的服务，通过单个 API 提供来自 Amazon 和 AI 公司的高性能基础模型（FM）选择，以及构建具有安全性、隐私性和负责任的 AI 的生成式 AI 应用程序所需的广泛功能。

In this post, you learn how to:在本文中，您将了解如何：

1. Enforce fine-grained, document-level access control at retrieval time using a single Amazon Bedrock Knowledge Bases instance.使用单个 Amazon Bedrock Knowledge Bases 实例在检索时实施细粒度的文档级访问控制。
2. Evaluate Cedar policies at runtime to dynamically construct the metadata filter passed to the RetrieveAndGenerate API.在运行时评估 Cedar 策略，以动态构造传递给 RetrieveAndGenerate API 的元数据过滤器。
3. Update authorization rules without changing application code or triggering a deployment.在不更改应用程序代码或触发部署的情况下更新授权规则。
4. Design a deny-by-default authorization system intended to deny access when the authorization service is unavailable.设计一个默认拒绝的授权系统，当授权服务不可用时拒绝访问。

Isolation model and scope隔离模型和范围

This pattern provides filter-level (logical) isolation, not IAM-enforced (infrastructure) isolation. Metadata filters control which documents are returned at retrieval time, but the underlying knowledge base remains a shared resource. If the middleware logic that constructs the filter were to fail open, documents from other groups would be exposed.此模式提供过滤器级（逻辑）隔离，而非 IAM 强制（基础设施）隔离。元数据过滤器控制在检索时返回哪些文档，但底层知识库仍然是共享资源。如果构造过滤器的中间件逻辑开放失败，其他组的文档将暴露。

This pattern is designed for granular access control within a single tenant. For example, controlling which departments, teams, or roles within one organization can access which documents. It is not a substitute for hard tenant isolation in a multi-tenant SaaS product. For cross-tenant isolation where a compliance boundary is required between separate customers or organizations, provision a dedicated knowledge base per tenant with IAM-enforced resource boundaries. Within each tenant’s knowledge base, you can then layer this filter-based pattern for finer-grained access control.此模式专为单个租户内的细粒度访问控制而设计。例如，控制一个组织内哪些部门、团队或角色可以访问哪些文档。它不能替代多租户 SaaS 产品中的硬租户隔离。对于需要在不同客户或组织之间建立合规边界的跨租户隔离，请为每个租户配置专用知识库，并设置 IAM 强制资源边界。在每个租户的知识库内，您可以叠加这种基于过滤器的模式，以实现更细粒度的访问控制。

Use this pattern when:在以下情况下使用此模式：

• You need to control document access across departments, teams, or roles within a single organization.您需要控制单个组织内部门、团队或角色之间的文档访问。
• Access rules change frequently and you want to update them without code redeployment.访问规则频繁变化，您希望无需重新部署代码即可更新它们。
• You want a single knowledge base instance to reduce cost and operational overhead for intra-tenant document segregation.您希望使用单一知识库实例来降低租户内文档隔离的成本和运营开销。

Do not use this pattern when:在以下情况下请勿使用此模式：

• You require hard isolation between separate customers or organizations (use a knowledge base per tenant with IAM boundaries instead).您需要在不同客户或组织之间实现硬隔离（请改用带 IAM 边界的按租户知识库）。
• Your compliance or audit requirements mandate infrastructure-level separation between data sets.您的合规或审计要求强制数据集之间进行基础设施级分离。
• A failure of the filter mechanism would constitute a regulatory breach (filter-level isolation is a logical boundary, not a physical one).过滤器机制故障将构成监管违规（过滤器级隔离是逻辑边界，而非物理边界）。

Residual risk, ingestion race condition: A brief window exists between document upload and sidecar creation. The ingestion safeguard (Step 1) reduces this by excluding documents without sidecars. However, if you modify the ingestion schedule to run continuously or with short intervals, verify that the batching window in Amazon Simple Queue Service (Amazon SQS) (default 30 seconds) provides sufficient time for the tagging Lambda to complete before the next ingestion cycle.残余风险，摄取竞争条件：文档上传和 sidecar 创建之间存在一个短暂的时间窗口。摄取保护（步骤 1）通过排除没有 sidecar 的文档来减少这种情况。但是，如果您将摄取计划修改为连续运行或使用较短间隔，请验证 Amazon Simple Queue Service (Amazon SQS) 中的批处理窗口（默认 30 秒）是否提供足够的时间，以便标记 Lambda 在下一次摄取周期之前完成。

Prerequisites前提条件

Before implementing this pattern, you need:在实现此模式之前，您需要：

1. Familiarity with Python, AWS Lambda, and infrastructure as code concepts.熟悉 Python、AWS Lambda 和基础设施即代码概念。
2. An AWS account with AWS Identity and Access Management (AWS IAM) permissions to create AWS Lambda functions, an Amazon API Gateway REST API, Amazon Cognito user pools, Verified Permissions policy stores, and Amazon Bedrock Knowledge Bases.拥有具备 AWS Identity and Access Management (AWS IAM) 权限的 AWS 账户，可创建 AWS Lambda 函数、Amazon API Gateway REST API、Amazon Cognito 用户池、Verified Permissions 策略存储和 Amazon Bedrock Knowledge Bases。
3. Amazon Cognito configured with department-based user groups (such as dept-a, dept-b, dept-c) and cognito:groups included in the JSON Web Token (JWT) issued to clients.配置了基于部门的用户组（例如 dept-a、dept-b、dept-c）的 Amazon Cognito，并且颁发给客户端的 JSON Web Token (JWT) 中包含 cognito:groups。
4. Amazon Bedrock model access for the FMs you plan to use (such as Anthropic Claude 3 Haiku, and Amazon Nova Lite 2).为计划使用的 FM 提供 Amazon Bedrock 模型访问权限（例如 Anthropic Claude 3 Haiku 和 Amazon Nova Lite 2）。
5. A Verified Permissions policy store created and the Cedar schema defined (principals, resources, actions) before deployment.在部署前创建 Verified Permissions 策略存储并定义 Cedar 架构（主体、资源、操作）。
6. AWS Cloud Development Kit (AWS CDK) or AWS CloudFormation to deploy the infrastructure described in this walkthrough.使用 AWS Cloud Development Kit (AWS CDK) 或 AWS CloudFormation 部署本指南中描述的基础设施。
7. Sample documents prepared with department prefixes (such as docs/dept-a/report.pdf) for upload to Amazon S3.准备带有部门前缀（例如 docs/dept-a/report.pdf）的示例文档，用于上传到 Amazon S3。

Important: Implementing this pattern creates billable AWS resources, including Amazon Bedrock Knowledge Bases, AWS Lambda functions, Amazon API Gateway, Amazon S3, Amazon Cognito, Amazon Verified Permissions, Amazon EventBridge, Amazon SQS, Amazon DynamoDB, AWS WAF, and Amazon CloudFront. Costs vary based on usage volume and AWS Region. Review AWS Pricing for each service before deploying and see the Cleaning up section at the end of this post to remove resources when testing is complete.重要提示：实施此模式会创建计费的 AWS 资源，包括 Amazon Bedrock Knowledge Bases、AWS Lambda 函数、Amazon API Gateway、Amazon S3、Amazon Cognito、Amazon Verified Permissions、Amazon EventBridge、Amazon SQS、Amazon DynamoDB、AWS WAF 和 Amazon CloudFront。成本因使用量和 AWS 区域而异。部署前请查看每个服务的 AWS Pricing，并在测试完成后参阅本文末尾的“清理”部分移除资源。

Solution overview解决方案概览

Serving many departments from one application shouldn’t mean giving every department access to every document. This solution keeps each department’s documents isolated inside a single Amazon Bedrock Knowledge Bases instance, so you avoid the cost and operational overhead of a knowledge base per team within that tenant. Metadata tags logically separate documents, and Verified Permissions acts as an externalized policy enforcement point, deciding which documents a user’s group or role is authorized to see on every request.用一个应用程序服务许多部门并不意味着让每个部门都能访问所有文档。此解决方案将每个部门的文档隔离在单个 Amazon Bedrock Knowledge Bases 实例内，从而避免在该租户内为每个团队建立知识库的成本和运营开销。元数据标签在逻辑上分隔文档，而 Verified Permissions 作为外部化策略执行点，在每次请求时决定用户的组或角色可以查看哪些文档。

A key objective is to serve multiple departments within a single tenant from one Knowledge Base instance. If you had to provision a separate instance per department, it would multiply the infrastructure: separate data sources, ingestion pipelines and management overhead. A single knowledge base with metadata filtered access avoids this duplication while providing logical document isolation within the tenant boundary. Documents are logically separated by their metadata tags, and Verified Permissions provides a reliable, externalized policy enforcement point to determine which tags a user, in a specific group or role, is authorized to access.一个关键目标是在单个租户内用一个知识库实例服务多个部门。如果必须为每个部门配置单独的实例，将使基础设施成倍增加：单独的数据源、摄取管道和管理开销。具有元数据过滤访问的单一知识库避免了这种重复，同时在租户边界内提供逻辑文档隔离。文档通过其元数据标签在逻辑上分离，而 Verified Permissions 提供可靠的外部化策略执行点，以确定特定组或角色的用户有权访问哪些标签。

The ingestion pipeline tags documents with department metadata. Verified Permissions evaluates Cedar policies at query time to determine which department tags you are permitted to see. A middleware service (implemented as an AWS Lambda function) converts that policy decision into a metadata filter and uses this in the Amazon Bedrock RetrieveAndGenerate API. This API combines the retrieval and generation steps, returning a grounded response based on the filtered document set. The FM only processes documents that passed the filter.摄取管道使用部门元数据标记文档。Verified Permissions 在查询时评估 Cedar 策略，以确定允许您查看哪些部门标签。中间件服务（作为 AWS Lambda 函数实现）将该策略决策转换为元数据过滤器，并在 Amazon Bedrock RetrieveAndGenerate API 中使用。此 API 结合了检索和生成步骤，基于过滤后的文档集返回有根据的响应。FM 仅处理通过过滤器的文档。

Two independent layers enforce authorization:两个独立的层强制执行授权：

• Layer 1 (API access): A Lambda Authorizer on Amazon API Gateway calls Verified Permissions to decide whether you can invoke the API at all.第 1 层（API 访问）：Amazon API Gateway 上的 Lambda Authorizer 调用 Verified Permissions，以决定您是否能够调用该 API。
• Layer 2 (document access): A middleware Lambda, used to orchestrate the call to the Knowledge Base, also calls Verified Permissions to determine which Knowledge Base resources your department is permitted to query, then constructs a metadata filter accordingly.第 2 层（文档访问）：用于编排对知识库调用的中间件 Lambda 也会调用 Verified Permissions，以确定您的部门被允许查询哪些知识库资源，然后据此构造元数据过滤器。

Neither layer depends on the other for correctness. If Layer 1 were bypassed then Layer 2 is designed to enforce document-level isolation at the KB metadata filter.两个层在正确性上互不依赖。如果第 1 层被绕过，第 2 层被设计为在知识库元数据过滤器上强制实施文档级隔离。

Figure 2 shows the ingestion pipeline: documents uploaded to Amazon Simple Storage Service (Amazon S3) trigger Amazon EventBridge, which routes through Amazon Simple Queue Service (Amazon SQS) to an AWS Lambda function that writes metadata. A scheduled Lambda then triggers the Amazon Bedrock Knowledge Bases ingestion job.图 2 显示了摄取管道：上传到 Amazon Simple Storage Service (Amazon S3) 的文档触发 Amazon EventBridge，通过 Amazon Simple Queue Service (Amazon SQS) 路由到写入元数据的 AWS Lambda 函数。然后，一个计划 Lambda 触发 Amazon Bedrock Knowledge Bases 摄取作业。

Figure 3 shows the query flow: a user request passes through Amazon CloudFront and AWS WAF to Amazon API Gateway, where the Lambda Authorizer evaluates Layer 1 (API-level) authorization against Verified Permissions. If permitted, the middleware Lambda evaluates Layer 2 (document-level) authorization, constructs the metadata filter, and calls RetrieveAndGenerate.图 3 显示了查询流程：用户请求通过 Amazon CloudFront 和 AWS WAF 到达 Amazon API Gateway，Lambda Authorizer 在此对照 Verified Permissions 评估第 1 层（API 级别）授权。如果允许，中间件 Lambda 评估第 2 层（文档级别）授权，构造元数据过滤器，并调用 RetrieveAndGenerate。

Authorization decision flow授权决策流程

Key AWS services关键 AWS 服务

Technical implementation技术实现

The walkthrough presents ingestion pipeline first to tag and index your documents. You then move on to the Query Flow which contains the core authorization pattern. Each section following maps to a distinct component in the architecture.本指南首先介绍摄取管道，以标记和索引您的文档。然后进入包含核心授权模式的查询流程。接下来的每个部分对应架构中的不同组件。

Step 1: Set up the event-driven ingestion pipeline with metadata tagging步骤 1：使用元数据标记设置事件驱动的摄取管道

For the metadata filter to work at query time, documents need to be tagged with their department before they are indexed. The ingestion pipeline handles this in two phases.为了让元数据过滤器在查询时正常工作，文档在索引前需要标记其部门。摄取管道分两个阶段处理此操作。

Phase 1 (event-driven): When a document is uploaded to Amazon S3 under a department prefix (such as docs/dept-a/report.pdf), Amazon EventBridge fires an ObjectCreated event. The event routes through Amazon SQS to an AWS Lambda function that writes a .metadata.json sidecar file alongside the document.阶段 1（事件驱动）：当文档上传到 Amazon S3 的部门前缀（例如 docs/dept-a/report.pdf）下时，Amazon EventBridge 触发 ObjectCreated 事件。该事件通过 Amazon SQS 路由到 AWS Lambda 函数，该函数在文档旁边写入 .metadata.json sidecar 文件。

The Amazon SQS queue buffers bulk uploads and routes failed tagging attempts to a dead-letter queue for retry.Amazon SQS 队列缓冲批量上传，并将失败的标记尝试路由到死信队列以进行重试。

Phase 2 (scheduled): An Amazon EventBridge schedule triggers an ingestion Lambda every five minutes, which calls the StartIngestionJob API on the Amazon Bedrock Knowledge Bases data source. Amazon Bedrock reads the documents and their sidecars from Amazon S3, chunks them, generates embeddings, and indexes the vectors with the department attribute.阶段 2（计划）：Amazon EventBridge 计划每五分钟触发一次摄取 Lambda，调用 Amazon Bedrock Knowledge Bases 数据源上的 StartIngestionJob API。Amazon Bedrock 从 Amazon S3 读取文档及其 sidecar，对其进行分块、生成嵌入，并使用部门属性对向量建立索引。

# Validate sidecar presence before ingestion
objects = s3.list_objects_v2(Bucket=BUCKET, Prefix=f"docs/{dept}/")
docs = [o["Key"] for o in objects.get("Contents", []) if not o["Key"].endswith(".metadata.json")]
for doc_key in docs:
    sidecar_key = f"{doc_key}.metadata.json"
    try:
        s3.head_object(Bucket=BUCKET, Key=sidecar_key)
    except s3.exceptions.ClientError:
        logger.warning(f"Skipping {doc_key}: no metadata sidecar found")
        docs.remove(doc_key)

Tamper detection for metadata sidecars: Enable S3 Versioning on the document bucket and configure AWS CloudTrail S3 data events to log PutObject and DeleteObject calls. Create an Amazon CloudWatch Alarms metric filter that alerts when a PutObject to a .metadata.json key originates from principals other than the tagging Lambda role. For workloads with strict compliance requirements, consider S3 Object Lock in compliance mode to make sidecars immutable after creation – noting that document re-classification would then require a deliberate workflow to create a new version.元数据 sidecar 的篡改检测：在文档存储桶上启用 S3 版本控制，并配置 AWS CloudTrail S3 数据事件以记录 PutObject 和 DeleteObject 调用。创建一个 Amazon CloudWatch Alarms 指标筛选器，当对 .metadata.json 键的 PutObject 来自除标记 Lambda 角色之外的主体时发出警报。对于具有严格合规要求的工作负载，请考虑在合规模式下使用 S3 Object Lock，使 sidecar 在创建后不可变——请注意，文档重新分类随后将需要专门的工作流来创建新版本。

Upload prefix enforcement: The metadata tagging Lambda derives the department label from the S3 key prefix (for example, docs/dept-a/ → department: dept-a). To help prevent a user or process from uploading documents under another department’s prefix, scope upload permissions using an IAM policy condition:上传前缀强制：元数据标记 Lambda 从 S3 键前缀（例如 docs/dept-a/ → department: dept-a）派生部门标签。为防止用户或进程在另一个部门的前缀下上传文档，请使用 IAM 策略条件限制上传权限：

{
    "Effect": "Allow",
    "Action": "s3:PutObject",
    "Resource": "arn:aws:s3:::your-doc-bucket/docs/dept-a/*",
    "Condition": {
        "StringEquals": {
            "aws:PrincipalTag/department": "dept-a"
        }
    }
}

Each upload principal (whether a user role, CI/CD pipeline, or application) should carry a department tag that matches its permitted prefix. This helps prevent the tagging Lambda from being tricked into mislabeling a document by an upload to the wrong path.每个上传主体（无论是用户角色、CI/CD 管道还是应用程序）都应携带与其允许前缀匹配的部门标签。这有助于防止标记 Lambda 因上传到错误路径而被欺骗，从而错误标记文档。

Ingestion safeguard: Before triggering the ingestion job, the scheduling Lambda lists objects under each department prefix and verifies that every document has a corresponding .metadata.json sidecar. Documents without a sidecar are excluded from the ingestion scope and logged to CloudWatch as untagged. This helps prevent an untagged document from being indexed without a department attribute, which could cause it to bypass metadata filters at query time. If your workload requires stricter guarantees, move untagged documents to a quarantine prefix and alert via Amazon Simple Notification Service (Amazon SNS).摄取保护：在触发摄取作业之前，调度 Lambda 列出每个部门前缀下的对象，并验证每个文档都有对应的 .metadata.json sidecar。没有 sidecar 的文档将从摄取范围中排除，并作为未标记记录到 CloudWatch。这有助于防止未标记文档在没有部门属性的情况下被索引，从而可能在查询时绕过元数据过滤器。如果您的工作负载需要更严格的保证，请将未标记的文档移至隔离前缀，并通过 Amazon Simple Notification Service (Amazon SNS) 发出警报。

S3 write restriction: Restrict s3:PutObject permission on the document bucket to the metadata tagging Lambda’s IAM execution role. All other principals – including application roles, CI/CD pipelines, and human operators should have at most s3:GetObject and s3:ListBucket. This helps prevent accidental or malicious modification of .metadata.json sidecar files, which could re-tag a document under a different department and expose it to unauthorized users on the next ingestion cycle. Use a bucket policy with an explicit deny for s3:PutObject that exempts only the tagging Lambda’s role ARN:S3 写入限制：将文档存储桶上的 s3:PutObject 权限限制为元数据标记 Lambda 的 IAM 执行角色。所有其他主体——包括应用程序角色、CI/CD 管道和人工操作员——最多应具有 s3:GetObject 和 s3:ListBucket。这有助于防止意外或恶意修改 .metadata.json sidecar 文件，否则可能会将文档重新标记为不同部门，并在下一个摄取周期将其暴露给未经授权的用户。使用显式拒绝 s3:PutObject 的存储桶策略，仅豁免标记 Lambda 的角色 ARN：

{
    "Effect": "Deny",
    "Principal": "*",
    "Action": ["s3:PutObject", "s3:DeleteObject"],
    "Resource": "arn:aws:s3:::your-doc-bucket/*",
    "Condition": {
        "StringNotEquals": {
            "aws:PrincipalArn": "arn:aws:iam::123456789012:role/MetadataTaggingLambdaRole"
        }
    }
}

A 30-second batching window on the Amazon SQS event source means bulk uploads are processed together rather than one document per Lambda invocation. The two-phase separation helps confirm that department metadata sidecars are written before the ingestion job runs, reducing the risk of a race condition where a document might be indexed without a department tag.Amazon SQS 事件源上 30 秒的批处理窗口意味着批量上传会一起处理，而不是每次 Lambda 调用处理一个文档。两阶段分离有助于确认部门元数据 sidecar 在摄取作业运行之前写入，从而降低文档在未标记部门标签的情况下被索引的竞争条件风险。

# metadata_lambda/handler.py
import boto3, json

def handler(event, context):
    for record in event["Records"]:
        body = json.loads(record["body"])
        s3_key = body["detail"]["object"]["key"]
        # Extract department from prefix: docs/dept-a/report.pdf -> dept-a
        dept = s3_key.split("/")[1]
        meta_key = s3_key + ".metadata.json"
        s3 = boto3.client("s3")
        s3.put_object(
            Bucket=BUCKET,
            Key=meta_key,
            Body=json.dumps({"metadataAttributes": {"department": dept}})
        )

Implementation note: Deploy this as the handler for your metadata tagging AWS Lambda function (Python 3.12 runtime). Set the BUCKET environment variable. The function’s IAM execution role requires s3:PutObject permission on the document bucket.实现说明：将此作为元数据标记 AWS Lambda 函数的处理程序部署（Python 3.12 运行时）。设置 BUCKET 环境变量。函数的 IAM 执行角色需要对文档存储桶具有 s3:PutObject 权限。

Step 2: Configure Amazon Bedrock Knowledge Bases步骤 2：配置 Amazon Bedrock Knowledge Bases

With Amazon Bedrock Knowledge Bases, you configure document chunking, embedding model selection, vector indexing, and metadata filtering without managing the underlying infrastructure. You configure a data source backed by the same Amazon S3 bucket as the ingestion pipeline.使用 Amazon Bedrock Knowledge Bases，您可以配置文档分块、嵌入模型选择、向量索引和元数据过滤，而无需管理底层基础设施。您配置一个由与摄取管道相同的 Amazon S3 存储桶支持的数据源。

Amazon Bedrock Knowledge Bases chunks documents at 300 tokens with 20% overlap (the default, which works well for structured enterprise documents). An embedding model, such as Amazon Titan Text Embeddings V2, generates the embeddings. The metadata attributes defined in the .metadata.json sidecar files are indexed alongside the vectors, making them available as pre-filters on the RetrieveAndGenerate call.Amazon Bedrock Knowledge Bases 以 300 个 token 和 20% 重叠对文档进行分块（默认设置，适用于结构化企业文档）。嵌入模型（例如 Amazon Titan Text Embeddings V2）生成嵌入。.metadata.json sidecar 文件中定义的元数据属性与向量一起建立索引，使其可作为 RetrieveAndGenerate 调用上的预过滤器使用。

Step 3: Define the Cedar schema and policies in Amazon Verified Permissions步骤 3：在 Amazon Verified Permissions 中定义 Cedar 架构和策略

Verified Permissions provides fine-grained authorization through Cedar, a purpose-built policy language. The Cedar schema defines three entity types for this solution:Verified Permissions 通过 Cedar（一种专为策略设计的语言）提供细粒度授权。Cedar 架构为此解决方案定义了三种实体类型：

1. Principal: GenAIApp::UserGroup (the department group extracted from the JWT)主体：GenAIApp::UserGroup（从 JWT 中提取的部门组）
2. Action: query (retrieves documents from a knowledge base) and invokeModel (calls an FM)操作：query（从知识库检索文档）和 invokeModel（调用 FM）
3. Resource: GenAIApp::KnowledgeBase and GenAIApp::Model资源：GenAIApp::KnowledgeBase 和 GenAIApp::Model

The namespace GenAIApp is a custom prefix you define when creating the Cedar schema. You can replace it with your own application namespace (such as MyCompany or RAGApp).命名空间 GenAIApp 是您在创建 Cedar 架构时定义的自定义前缀。您可以用自己的应用程序命名空间（例如 MyCompany 或 RAGApp）替换它。

The following six policies cover the three departments used in this walkthrough. Department C has a cross-department access grant that covers each Knowledge Base resource, which suits a leadership or executive group:以下六个策略涵盖本指南中使用的三个部门。部门 C 具有涵盖每个知识库资源的跨部门访问授权，适用于领导层或高管团队：

// dept-a: query own knowledge base + use Claude 3 Haiku
permit(
    principal in GenAIApp::UserGroup::"dept-a",
    action == GenAIApp::Action::"query",
    resource == GenAIApp::KnowledgeBase::"dept-a"
);

permit(
    principal in GenAIApp::UserGroup::"dept-a",
    action == GenAIApp::Action::"invokeModel",
    resource == GenAIApp::Model::"anthropic.claude-3-haiku-20240307-v1:0"
);

// dept-b: query own knowledge base + use Claude 3 Haiku
permit(
    principal in GenAIApp::UserGroup::"dept-b",
    action == GenAIApp::Action::"query",
    resource == GenAIApp::KnowledgeBase::"dept-b"
);

permit(
    principal in GenAIApp::UserGroup::"dept-b",
    action == GenAIApp::Action::"invokeModel",
    resource == GenAIApp::Model::"anthropic.claude-3-haiku-20240307-v1:0"
);

// dept-c: cross-department access + use Amazon Nova Lite 2
permit(
    principal in GenAIApp::UserGroup::"dept-c",
    action == GenAIApp::Action::"query",
    resource
);

permit(
    principal in GenAIApp::UserGroup::"dept-c",
    action == GenAIApp::Action::"invokeModel",
    resource == GenAIApp::Model::"amazon.nova-2-lite-v1:0"
);

To adapt these policies for your organization, replace the department identifiers (dept-a, dept-b, dept-c) with your own group names. The pattern supports multiple access models: per-team, per-project, or hierarchical. For temporary access grants, add a Cedar policy with a when condition that evaluates a time-based attribute, and remove the policy when access should expire.要将这些策略调整为您所在组织的需求，请将部门标识符（dept-a、dept-b、dept-c）替换为您自己的组名。该模式支持多种访问模型：按团队、按项目或分层。对于临时访问授权，添加一个带有 when 条件的 Cedar 策略，该条件评估基于时间的属性，并在访问应过期时移除该策略。

Policy changes take effect on the next API call. You do not need a Lambda redeployment or AWS CDK update.策略更改在下次 API 调用时生效。您无需重新部署 Lambda 或更新 AWS CDK。

Policy governance: Because Cedar policy changes take effect immediately, restrict who can modify policies in production. Apply IAM conditions on verifiedpermissions:CreatePolicy, UpdatePolicy, and DeletePolicy so that only a dedicated CI/CD pipeline role or a small set of authorized administrators can mutate the policy store. Enable AWS CloudTrail logging for Verified Permissions API calls and create a CloudWatch Alarm that triggers when policy mutation events occur outside your change management workflow. For production deployments, validate Cedar policies against test scenarios in a non-production policy store before promoting them. Treat policy changes with the same rigor as application code deployments.策略治理：由于 Cedar 策略更改会立即生效，请限制谁可以在生产环境中修改策略。在 verifiedpermissions:CreatePolicy、UpdatePolicy 和 DeletePolicy 上应用 IAM 条件，以便只有专用的 CI/CD 管道角色或一小部分授权管理员才能更改策略存储。为 Verified Permissions API 调用启用 AWS CloudTrail 日志记录，并创建一个 CloudWatch Alarm，在变更管理工作流之外发生策略更改事件时触发。对于生产部署，在提升策略之前，先在非生产策略存储中针对测试场景验证 Cedar 策略。对待策略更改应与应用程序代码部署一样严格。

Step 4: Configure Layer 1: API-level authorization (Lambda Authorizer)步骤 4：配置第 1 层：API 级授权（Lambda Authorizer）

When a request arrives at Amazon API Gateway, the Lambda Authorizer runs before your application logic. It validates the JWT signature against the Amazon Cognito JSON Web Key Set (JWKS) endpoint, then calls Verified Permissions IsAuthorized with your group membership. This is the traditional “authorization/access level” check: it verifies that you are allowed to invoke the API, not which documents you can access.当请求到达 Amazon API Gateway 时，Lambda Authorizer 在应用程序逻辑之前运行。它会根据 Amazon Cognito JSON Web Key Set (JWKS) 端点验证 JWT 签名，然后使用您的组成员身份调用 Verified Permissions IsAuthorized。这是传统的“授权/访问级别”检查：它验证您是否被允许调用 API，而不是您可以访问哪些文档。

The authorizer denies access by default. If Verified Permissions is unavailable, the function raises an exception and Amazon API Gateway returns a 403.授权者默认拒绝访问。如果 Verified Permissions 不可用，该函数会引发异常，Amazon API Gateway 返回 403。

import boto3, json

avp = boto3.client("verifiedpermissions")

def handler(event, context):
    token = event["authorizationToken"]
    claims = decode_and_verify_jwt(token)  # validates against Amazon Cognito JWKS
    groups = claims.get("cognito:groups", [])

    if not groups:
        raise Exception("Unauthorized")

    # Evaluate each group; allow if any group has a permit policy
    allowed = False
    for group in groups:
        response = avp.is_authorized(
            policyStoreId=POLICY_STORE_ID,
            principal={"entityType": "GenAIApp::UserGroup", "entityId": group},
            action={"actionType": "GenAIApp::Action", "actionId": "query"},
            resource={"entityType": "GenAIApp::Application", "entityId": "api"}
        )
        if response["decision"] == "ALLOW":
            allowed = True
            break

    if not allowed:
        raise Exception("Unauthorized")

    return generate_policy("Allow", event["methodArn"], claims)

Implementation note: Deploy this as a Lambda Authorizer (TOKEN type) on your Amazon API Gateway REST API. Set the TTL on the authorizer cache to 0 during testing so that policy changes take effect immediately.实现说明：将此作为 Lambda Authorizer（TOKEN 类型）部署在您的 Amazon API Gateway REST API 上。测试期间将授权者缓存的 TTL 设置为 0，以便策略更改立即生效。

Production cache TTL: In production, the API Gateway authorizer cache TTL controls how quickly policy revocations take effect. A TTL of 0 means every request triggers a fresh Verified Permissions evaluation. Revocations are immediate but latency increases. A TTL of 300 seconds (the API Gateway default) improves latency but means a revoked policy could continue to permit access for up to 5 minutes. For workloads where timely revocation matters (for example an employee offboarding or incident response), set the TTL to 0 or a deliberately short value (for example, 30–60 seconds) and accept the additional Verified Permissions API calls. The claim that “policy changes take effect on the next API call” holds true only when the authorizer cache TTL is zero or the cached entry has expired.生产环境缓存 TTL：在生产环境中，API Gateway 授权者缓存 TTL 控制策略撤销生效的速度。TTL 为 0 意味着每个请求都会触发一次全新的 Verified Permissions 评估。撤销是立即生效的，但延迟会增加。TTL 为 300 秒（API Gateway 默认值）可改善延迟，但意味着被撤销的策略可能继续允许访问最多 5 分钟。对于及时撤销很重要的工作负载（例如员工离职或事件响应），将 TTL 设置为 0 或刻意设置较短的值（例如 30–60 秒），并接受额外的 Verified Permissions API 调用。“策略更改在下次 API 调用时生效”的说法仅在授权者缓存 TTL 为零或缓存条目已过期时才成立。

Multi-group membership: A user may belong to more than one Cognito group. For example, an employee who is a member of both dept-a and a cross-functional leadership group. The authorizer evaluates the group memberships present in the JWT and permits the API call if a group has a matching Cedar permit policy. This helps prevent arbitrary access restrictions based on the order in which groups appear in the token. Document-level access is then determined independently at Layer 2, where the middleware evaluates each department resource against the user’s groups to construct the appropriate metadata filter.多组身份：一个用户可能属于多个 Cognito 组。例如，一名员工既是 dept-a 的成员，又是跨职能领导团队的成员。授权者评估 JWT 中存在的组成员身份，如果某个组具有匹配的 Cedar 允许策略，则允许 API 调用。这有助于防止基于组在令牌中出现的顺序而施加任意访问限制。文档级访问随后在第 2 层独立确定，中间件根据用户的组评估每个部门资源，以构造适当的元数据过滤器。

For error handling patterns, implement exponential backoff with jitter on the Verified Permissions API call. Log authorization decisions to Amazon CloudWatch for monitoring and auditing.对于错误处理模式，请在 Verified Permissions API 调用上实现带抖动的指数退避。将授权决策记录到 Amazon CloudWatch 以进行监控和审计。

Step 5: Configure Layer 2: Document-level authorization (middleware Lambda)步骤 5：配置第 2 层：文档级授权（中间件 Lambda）

Once a request passes Layer 1, the middleware Lambda runs a second, independent Verified Permissions evaluation. This time, it checks which KB resources you are permitted to query based on your group membership, then translates the decision directly into a metadata filter on the RetrieveAndGenerate call.一旦请求通过第 1 层，中间件 Lambda 会运行第二次独立的 Verified Permissions 评估。这一次，它会根据您的组成员身份检查您被允许查询哪些 KB 资源，然后将决策直接转换为 RetrieveAndGenerate 调用上的元数据过滤器。

Amazon Bedrock Knowledge Bases applies the metadata filter before the vector similarity search runs. This means the FM processes only documents you are authorized to access. The filter helps prevent unauthorized documents from appearing in the retrieval set.Amazon Bedrock Knowledge Bases 在向量相似性搜索运行之前应用元数据过滤器。这意味着 FM 仅处理您有权访问的文档。该过滤器有助于防止未经授权的文档出现在检索集中。

Department access model部门访问模型

def build_filter_and_invoke(user_group, query, session_id):
    permitted_depts = []
    for dept in ["dept-a", "dept-b", "dept-c"]:
        resp = avp.is_authorized(
            policyStoreId=POLICY_STORE_ID,
            principal={"entityType": "GenAIApp::UserGroup",
                       "entityId": user_group},
            action={"actionType": "GenAIApp::Action",
                    "actionId": "query"},
            resource={"entityType": "GenAIApp::KnowledgeBase",
                      "entityId": dept}
        )
        if resp["decision"] == "ALLOW":
            permitted_depts.append(dept)

    if not permitted_depts:
        raise PermissionError("No permitted Knowledge Base resources")

    # Implement retry with exponential backoff on avp.is_authorized calls

    # Build metadata filter based on permitted departments
    if len(permitted_depts) == 1:
        kb_filter = {"equals": {"key": "department",
                                "value": permitted_depts[0]}}
    else:
        kb_filter = {"orAll": [{"equals": {"key": "department",
                                           "value": d}}
                               for d in permitted_depts]}

    return bedrock_agent.retrieve_and_generate(
        input={"text": query},
        retrieveAndGenerateConfiguration={
            "type": "KNOWLEDGE_BASE",
            "knowledgeBaseConfiguration": {
                "knowledgeBaseId": KB_ID,
                "modelArn": get_permitted_model(user_group),
                "retrievalConfiguration": {
                    "vectorSearchConfiguration": {
                        "filter": kb_filter
                    }
                }
            }
        }
    )

Implementation note: Deploy this as the handler for your middleware AWS Lambda function (Python 3.12 runtime). Set environment variables POLICY_STORE_ID and KB_ID. The function’s IAM execution role requires verifiedpermissions:IsAuthorized and bedrock:RetrieveAndGenerate permissions.实现说明：将此作为中间件 AWS Lambda 函数的处理程序部署（Python 3.12 运行时）。设置环境变量 POLICY_STORE_ID 和 KB_ID。函数的 IAM 执行角色需要 verifiedpermissions:IsAuthorized 和 bedrock:RetrieveAndGenerate 权限。

The FM selection uses the same Verified Permissions policy store. Cedar policies that grant invokeModel access determine which model ID the middleware passes to Amazon Bedrock, so model access control is driven by the same externalized policies as document access.FM 选择使用相同的 Verified Permissions 策略存储。授予 invokeModel 访问权限的 Cedar 策略决定中间件将哪个模型 ID 传递给 Amazon Bedrock，因此模型访问控制由与文档访问相同的外部化策略驱动。

Security note: The metadata filter excludes unauthorized documents from the retrieval set before the FM processes them. If a user queries for another department’s data, the request returns no relevant results. To monitor for unexpected retrieval behavior, use Amazon CloudWatch logging on the middleware AWS Lambda function.安全说明：元数据过滤器在 FM 处理文档之前将未经授权的文档从检索集中排除。如果用户查询另一个部门的数据，请求将返回不相关的结果。要监控意外的检索行为，请在中间件 AWS Lambda 函数上使用 Amazon CloudWatch 日志记录。

Benefits of two independent authorization layers两个独立授权层的优势

Availability trade-off: Both layers depend on Amazon Verified Permissions. If the service is throttled or unavailable, the deny-by-default design means users are denied access. This is the correct and intended secure behavior. For most workloads, a brief period of denial is preferable to failing open. If your application has strict availability requirements, consider implementing exponential backoff with jitter on all IsAuthorized calls (in both the Lambda Authorizer and the middleware Lambda) to handle transient throttling gracefully. A circuit-breaker that falls back to cached last-known-good authorization decisions can improve availability, but introduces a window where revoked access may still be honored. Document this trade-off explicitly if you adopt it, and make sure cached decisions expire on a short TTL.可用性权衡：两个层都依赖 Amazon Verified Permissions。如果服务被限流或不可用，默认拒绝的设计意味着用户将被拒绝访问。这是正确且预期的安全行为。对于大多数工作负载，短暂的拒绝优于失败开放。如果您的应用程序有严格的可用性要求，请考虑在所有 IsAuthorized 调用（包括 Lambda Authorizer 和中间件 Lambda）上实现带抖动的指数退避，以优雅地处理瞬时限流。如果断路器回退到缓存的上次已知良好授权决策，可以提高可用性，但会引入一个窗口期，其中被撤销的访问可能仍被允许。如果您采用此做法，请明确记录此权衡，并确保缓存的决策在较短的 TTL 内过期。

Step 6: Add Guardrails for Amazon Bedrock as an output safety layer步骤 6：添加 Amazon Bedrock 的 Guardrails 作为输出安全层

Guardrails for Amazon Bedrock applies contextual source fidelity checks and content filtering as a complementary safety layer. Where Verified Permissions controls which documents the FM accesses, Guardrails evaluates the FM’s response before it’s returned to you.Amazon Bedrock 的 Guardrails 将上下文来源保真度检查和内容过滤作为互补的安全层。Verified Permissions 控制 FM 访问哪些文档，而 Guardrails 在将 FM 的响应返回给您之前对其进行评估。

Contextual source fidelity checks help confirm that the response stays faithful to the retrieved documents rather than drawing from the FM’s pre-training data. Combine this with the metadata filter from Layer 2 for a complete defense in depth approach: authorization restricts the retrieval set, and Guardrails validates the generated output.上下文来源保真度检查有助于确认响应与检索到的文档保持一致，而不是从 FM 的预训练数据中提取。将其与第 2 层的元数据过滤器结合，形成完整的纵深防御方法：授权限制检索集，而 Guardrails 验证生成的输出。

The Guardrail configuration in the RetrieveAndGenerate call applies two checks:RetrieveAndGenerate 调用中的 Guardrail 配置应用两项检查：

1. Contextual grounding: Helps limit responses that extrapolate beyond the retrieved context. This supports factual accuracy tied to your documents.上下文接地：有助于限制超出检索上下文的推断性响应。这支持与您的文档相关的事实准确性。
2. Content filtering: Blocks responses containing harmful or inappropriate content based on your configured thresholds.内容过滤：根据您配置的阈值阻止包含有害或不适当内容的响应。

You apply the Guardrail in the RetrieveAndGenerate call by passing the guardrailConfiguration parameter with your Guardrail ID and version. Contextual grounding helps mitigate prompt injection by limiting responses to the retrieved context but does not eliminate all injection vectors. For additional defense, validate input length and sanitize queries before passing them to RetrieveAndGenerate. For more information, see the Guardrails for Amazon Bedrock documentation.您可以通过传递带有 Guardrail ID 和版本的 guardrailConfiguration 参数，在 RetrieveAndGenerate 调用中应用 Guardrail。上下文接地通过将响应限制在检索上下文中来帮助缓解提示注入，但并不能消除所有注入向量。为了额外防御，在将查询传递给 RetrieveAndGenerate 之前，请验证输入长度并清理查询。有关更多信息，请参阅 Amazon Bedrock 的 Guardrails 文档。

Step 7: Test the end-to-end authorization flow步骤 7：测试端到端授权流程

With the solution deployed, here is what happens when a dept-a user submits a query:部署解决方案后，当 dept-a 用户提交查询时，会发生以下情况：

1. A user submits a query using a web application with Authorization: Bearer through Amazon CloudFront to AWS WAF.用户使用带有 Authorization: Bearer 的 Web 应用程序通过 Amazon CloudFront 向 AWS WAF 提交查询。
2. AWS WAF applies rate limiting and managed rules, then forwards clean traffic to Amazon API Gateway.AWS WAF 应用速率限制和托管规则，然后将干净流量转发到 Amazon API Gateway。
3. The Lambda Authorizer validates the JWT and calls Verified Permissions. The dept-a group has a query permit policy, so the call is allowed.Lambda Authorizer 验证 JWT 并调用 Verified Permissions。dept-a 组具有查询允许策略，因此允许该调用。
4. The middleware Lambda calls Verified Permissions for each Knowledge Base resource. Only dept-a is permitted, so the filter {“equals”: {“key”: “department”, “value”: “dept-a”}} is constructed.中间件 Lambda 为每个知识库资源调用 Verified Permissions。仅允许 dept-a，因此构造过滤器 {“equals”: {“key”: “department”, “value”: “dept-a”}}。
5. The middleware calls RetrieveAndGenerate with the metadata filter applied. Amazon Bedrock Knowledge Bases filters the document set before running the vector similarity search.中间件在应用元数据过滤器的情况下调用 RetrieveAndGenerate。Amazon Bedrock Knowledge Bases 在运行向量相似性搜索之前过滤文档集。
6. Department B and C documents are excluded from the search space. The FM generates a response that stays grounded only in Department A documents.部门 B 和 C 的文档被排除在搜索空间之外。FM 生成的响应仅基于部门 A 的文档。
7. The response is checked by Guardrails for Amazon Bedrock before it is returned.响应在返回之前由 Amazon Bedrock 的 Guardrails 检查。

To test, use the following curl command with a valid JWT from Amazon Cognito:要进行测试，请使用以下带有来自 Amazon Cognito 的有效 JWT 的 curl 命令：

curl -X POST https://<api-id>.execute-api.<region>.amazonaws.com/prod/query \
  -H "Authorization: Bearer <id_token>" \
  -d '{"query": "Summarize the latest department report"}'

A successful dept-a request returns a response grounded in Department A documents only. If authorization fails at Layer 1, you receive a 403 response. If Layer 2 finds no permitted resources, the function returns a PermissionError.成功的 dept-a 请求仅返回基于部门 A 文档的响应。如果第 1 层授权失败，您将收到 403 响应。如果第 2 层找不到允许的资源，该函数将返回 PermissionError。

Monitor authorization decisions in Amazon CloudWatch Logs for both the Lambda Authorizer and middleware functions. Set up CloudWatch metric filters and alarms for the following:在 Amazon CloudWatch Logs 中监控 Lambda Authorizer 和中间件函数的授权决策。为以下内容设置 CloudWatch 指标筛选器和警报：

• Authorization deny rate (Layer 1 and Layer 2) – a spike may indicate credential probing, misconfigured clients, or a policy error.授权拒绝率（第 1 层和第 2 层）——激增可能表明凭据探测、客户端配置错误或策略错误。
• Verified Permissions latency – sustained increases may signal throttling.Verified Permissions 延迟——持续增加可能表明被限流。
• SQS dead-letter queue message count – messages in the DLQ indicate failed metadata tagging events that need attention.SQS 死信队列消息数——DLQ 中的消息表明存在需要关注的元数据标记失败事件。
• Ingestion job failure rate – alerts you to documents that were not indexed.摄取作业失败率——提醒您注意未建立索引的文档。

AWS CloudTrail automatically logs Verified Permissions IsAuthorized calls, providing an audit trail of every authorization decision without additional configuration.AWS CloudTrail 自动记录 Verified Permissions IsAuthorized 调用，无需额外配置即可提供每个授权决策的审计追踪。

To observe the live policy update behavior, grant a dept-a Cedar policy that allows access to dept-b resources, then immediately resubmit the query. The next API call reflects the change. Revoke the policy and the restriction is restored on the following call.要观察实时策略更新行为，请授予允许访问 dept-b 资源的 dept-a Cedar 策略，然后立即重新提交查询。下一次 API 调用将反映此更改。撤销该策略后，限制将在下一次调用时恢复。

Single knowledge base with metadata isolation具有元数据隔离的单一知识库

Adding a department requires adding a Cedar policy and tagging new documents. You do not need to provision additional infrastructure, deploy new stacks, or manage separate ingestion pipelines. The FM is presented with only the authorized document subset based on the applied metadata pre-filter.添加部门需要添加 Cedar 策略并标记新文档。您无需配置额外的基础设施、部署新的堆栈或管理单独的摄取管道。根据应用的元数据预过滤器，FM 仅看到授权的文档子集。

For session management, use an Amazon DynamoDB table with a session TTL to maintain conversation context across requests. The RetrieveAndGenerate API accepts a sessionId parameter that manages multi-turn context automatically. Generate session IDs using a cryptographically random value (for example, uuid4) and bind each session to the authenticated user’s identity and group at creation time.对于会话管理，使用带有会话 TTL 的 Amazon DynamoDB 表来跨请求维护对话上下文。RetrieveAndGenerate API 接受 sessionId 参数，自动管理多轮上下文。使用加密随机值（例如 uuid4）生成会话 ID，并在创建时将每个会话绑定到已认证用户的身份和组。

On every subsequent request, validate that the bearer token’s subject and group claims match the session owner before continuing the conversation. Invalidate sessions when a user’s group membership changes or their token is revoked and set a TTL appropriate to your use case (for example, 30 minutes of inactivity).在每个后续请求中，在继续对话之前，验证 bearer 令牌的主题和组声明与会话所有者匹配。当用户的组成员身份更改或其令牌被撤销时，使会话失效，并设置适合您用例的 TTL（例如，30 分钟不活动）。

Cleaning up清理

If you deployed resources individually, delete them in the following order to avoid dependency errors:如果您单独部署了资源，请按以下顺序删除它们以避免依赖错误：

1. Amazon CloudFront distribution and AWS WAF web ACL.Amazon CloudFront 分配和 AWS WAF Web ACL。
2. Amazon API Gateway REST API (this also removes the Lambda Authorizer association).Amazon API Gateway REST API（这也会移除 Lambda Authorizer 关联）。
3. AWS Lambda functions (metadata tagging, authorizer, middleware). Amazon Bedrock Knowledge Base and its associated data source.AWS Lambda 函数（元数据标记、授权者、中间件）。Amazon Bedrock Knowledge Base 及其关联的数据源。
4. Amazon S3 bucket — empty the bucket first. If versioning is enabled, delete all object versions and delete markers before removing the bucket.Amazon S3 存储桶——首先清空存储桶。如果启用了版本控制，请在删除存储桶之前删除所有对象版本和删除标记。
5. Amazon EventBridge rule and Amazon SQS queue.Amazon DynamoDB table.Amazon Verified Permissions policy store.Amazon Cognito user pool (if created specifically for this pattern).Amazon EventBridge 规则和 Amazon SQS 队列。Amazon DynamoDB 表。Amazon Verified Permissions 策略存储。Amazon Cognito 用户池（如果是专门为此模式创建的）。
6. IAM roles and policies created for the Lambda functions and API Gateway.为 Lambda 函数和 API Gateway 创建的 IAM 角色和策略。
7. Amazon CloudWatch log groups for each Lambda function.每个 Lambda 函数的 Amazon CloudWatch 日志组。

Warning: Deleting these resources is irreversible. Back up any documents in S3, DynamoDB data, or Verified Permissions policies you may need before proceeding.警告：删除这些资源是不可逆的。在继续之前，请备份您可能需要的 S3 中的任何文档、DynamoDB 数据或 Verified Permissions 策略。

Conclusion结论

You now have a working defense-in-depth authorization pattern for granular, intra-tenant document access control in RAG applications that you built on Amazon Bedrock. With this approach, you can: change access policies at runtime without redeploying code, maintain logical document-level isolation that remains effective even if the API layer is misconfigured, and audit every authorization decision from a single Verified Permissions policy store.您现在拥有了一个在 Amazon Bedrock 上构建的、适用于 RAG 应用程序中细粒度租户内文档访问控制的可用纵深防御授权模式。使用这种方法，您可以：在运行时更改访问策略而无需重新部署代码；保持逻辑文档级隔离，即使 API 层配置错误仍然有效；从单个 Verified Permissions 策略存储审计每个授权决策。

Key takeaways要点

• Updates without redeployment. Cedar policies in Verified Permissions are human-readable, version-controlled outside your Lambda code, and take effect on the next API call. You can revoke a department’s access or grant cross-department access to an executive group by updating a policy in the Verified Permissions console.无需重新部署即可更新。Verified Permissions 中的 Cedar 策略是人类可读的，在 Lambda 代码之外进行版本控制，并在下次 API 调用时生效。您可以通过在 Verified Permissions 控制台中更新策略来撤销部门的访问权限或向高管团队授予跨部门访问权限。
• Cost-effective document isolation without infrastructure duplication. A single Amazon Bedrock Knowledge Bases instance with metadata pre-filtering delivers logical isolation between departments within a tenant, at a fraction of the cost and operational overhead of separate instances. Note that this is filter-level isolation, not infrastructure-level isolation – for hard tenant boundaries, use a dedicated knowledge base per tenant.经济高效的文档隔离，无需基础设施重复。具有元数据预过滤的单个 Amazon Bedrock Knowledge Bases 实例可在租户内实现部门之间的逻辑隔离，成本和运营开销仅为单独实例的一小部分。请注意，这是过滤器级隔离，而非基础设施级隔离——对于硬租户边界，请为每个租户使用专用的知识库。
• Independent enforcement layers help reduce the risk of a single point of failure. Layer 1 (Lambda Authorizer) and Layer 2 (middleware Lambda) enforce independent policy checks. Both call Verified Permissions separately, and both fail closed (deny by default).独立的执行层有助于降低单点故障风险。第 1 层（Lambda Authorizer）和第 2 层（中间件 Lambda）执行独立的策略检查。两者分别调用 Verified Permissions，并且都默认失败关闭（默认拒绝）。

Next steps后续步骤

To extend this pattern further:要进一步扩展此模式：

1. Recommended first step: Test with your own documents. Replace the sample department documents with your own content, upload them under the appropriate prefix, and verify that the metadata filter isolates them correctly.推荐的第一步：用您自己的文档进行测试。将示例部门文档替换为您自己的内容，上传到合适的前缀下，并验证元数据过滤器能否正确隔离它们。
2. Add a fourth department. Create a new Cedar policy, add a user group in Amazon Cognito, and upload tagged documents to validate that the pattern scales without code changes.添加第四个部门。创建新的 Cedar 策略，在 Amazon Cognito 中添加用户组，并上传带标签的文档，以验证该模式无需更改代码即可扩展。
3. Extend to agent tool authorization with Amazon Bedrock AgentCore. The Policy feature uses the same Cedar language to enforce fine-grained authorization on agent tool calls and gateways.使用 Amazon Bedrock AgentCore 扩展到代理工具授权。Policy 功能使用相同的 Cedar 语言，以对代理工具调用和网关实施细粒度授权。
4. Add attribute-based access control (ABAC). Extend Cedar policies to evaluate user attributes beyond group membership, such as project assignment, clearance level, or geographic location.添加基于属性的访问控制 (ABAC)。扩展 Cedar 策略，以评估除组成员资格之外的用户属性，例如项目分配、安全许可级别或地理位置。
5. Integrate with your identity provider. Replace Amazon Cognito with your enterprise identity provider (such as Okta or Microsoft Entra ID) by configuring a Verified Permissions identity source.与您的身份提供商集成。通过配置 Verified Permissions 身份源，将 Amazon Cognito 替换为您企业的身份提供商（例如 Okta 或 Microsoft Entra ID）。
6. Automate policy testing. Build a Continuous Integration/Continuous Deployment (CI/CD) pipeline that validates Cedar policies against test scenarios before deploying them to the policy store.自动化策略测试。构建持续集成/持续部署 (CI/CD) 流水线，在将 Cedar 策略部署到策略存储之前，针对测试场景对其进行验证。

Related resources相关资源

1. Multi-tenancy in RAG applications in a single Amazon Bedrock knowledge base with metadata filtering (AWS Machine Learning Blog, April 2025)在单个 Amazon Bedrock 知识库中使用元数据过滤实现 RAG 应用中的多租户（AWS Machine Learning Blog，2025年4月）
2. Amazon Verified Permissions documentationAmazon Bedrock Knowledge Bases documentationAmazon Verified Permissions 文档和 Amazon Bedrock Knowledge Bases 文档
3. Amazon Bedrock Knowledge Bases with metadata filtering (AWS Machine Learning Blog, July 2024)使用元数据过滤的 Amazon Bedrock Knowledge Bases（AWS Machine Learning Blog，2024年7月）
4. Design secure generative AI application workflows with Amazon Verified Permissions and Amazon Bedrock Agents (AWS Machine Learning Blog, October 2024)使用 Amazon Verified Permissions 和 Amazon Bedrock Agents 设计安全的生成式 AI 应用工作流（AWS Machine Learning Blog，2024年10月）
5. Authorizing access to data with RAG implementations (AWS Security Blog, September 2025)通过 RAG 实现授权数据访问（AWS Security Blog，2025年9月）
6. Cedar policy language documentationCedar 策略语言文档

About the authors关于作者