Amazon S3 の Amazon QuickSight キーベースにおける機密ドキュメントへのアクセス制限機能の追加

Organizations that must restrict access to sensitive documents increasingly rely on AI-driven search and chat to help employees find answers across large repositories. Coarse-grained permissions that control access at the knowledge base level work well for many teams, but sensitive documents require more granular control to restrict specific documents or folders to authorized teams, individuals, or systems.

Document-level access control list (ACL) support for Amazon Simple Storage Service (Amazon S3) knowledge bases in Amazon Quick gives you that fine-grained control. You restrict sensitive S3 documents to only the users and groups who should see them, at the document or folder level. When a user asks a question, Quick evaluates their identity against your ACL configuration and only surfaces content that they’re authorized to view. With these controls in place, you can safely bring your full document library into Quick while meeting your compliance and data governance requirements.

In this post, we walk through how to configure document-level ACLs for your S3 knowledge base in Amazon Quick. You will learn how to set up and verify an ACL configuration that enforces document-level permissions across chat and automated workflows. The post covers:

• Controlling which S3 buckets users can access for knowledge base creation using IAM policy assignments

• Planning your access control structure

• Choosing between two ACL configuration methods (Global ACL file and document-level metadata files)

• Setting up permissions for users and groups

• Verifying that your access controls work correctly through chat and ACL-aware Flows

• Updating and maintaining your ACL configuration over time

How S3 ACL works in Quick

You can use the S3 ACL feature in Amazon Quick to attach access permissions to your documents so that chat responses only include content that you’re authorized to view. You specify who can access what documents using standard ALLOW and DENY policies for individual users or groups, and Quick enforces these permissions at query time.

There are two ways to configure ACLs, each suited to different operational needs:

• Global ACL configuration file (such as ACL.json) – A single centralized file that specifies access permissions at the folder (prefix) level. Use this method when your organization has stable, folder-based permission structures.

• Document-level metadata files – Individual metadata files alongside each document that contain per-document access control entries. Use this method when permissions change frequently, because only affected documents need to be reindexed rather than entire folder structures.

Choose your approach based on how often permissions change and how granular you need them to be:

Consideration

Global ACL File

Document-level metadata

Permission granularity

Folder (S3 prefix) level

Individual document level

Management overhead

Single file to maintain

One metadata file per document

Reindex scope on permission change

Entire affected prefix

Only the affected document(s)

Recommended for

Stable folder-based access structures

Frequently changing per-document permissions

Understanding reindex scope

The reindex scope of your chosen method has meaningful operational implications. With the global ACL approach, a permission change triggers a full reindex of the affected prefix. If your organization requires frequent permission updates, consider using document-level metadata files instead, where only the affected documents are reindexed rather than entire folder structures.

Deny-by-default behavior

When you enable ACLs on an S3 knowledge base in Quick, a document or prefix not explicitly listed in your ACL configuration is denied by default. This deny-by-default approach (sometimes called “fail closed,” meaning the system defaults to denying access when no explicit rule exists) means that if you configure ACLs, you must explicitly grant access to every prefix or document you want users to reach.

For example, if your S3 bucket has three folders (/finance/, /legal/, and /policies/) and your ACL file only grants access to /finance/ and /policies/, the /legal/ folder and its contents are automatically denied to everyone, even if no DENY rule exists for it.

The implicit deny model used by IAM works the same way. Quick denies access unless you explicitly grant it. When you configure ACLs, you have explicit control over access and nothing is inadvertently exposed.

If a user or group has both an ALLOW and a DENY entry for the same document or prefix, the DENY always takes precedence. This means that you can use broad ALLOW rules for a team or group and then apply targeted DENY entries to restrict access to specific resources, giving you fine-grained control without having to restructure your entire ACL configuration.

Prerequisites

Before you begin, verify that you have the following:

• An AWS account with Amazon Quick enabled. If you don’t have a Quick account, refer to Getting started with Amazon Quick.

• An Amazon S3 bucket containing the documents you want to index.

• An idea of how you want to structure your access control lists. The following sections explain how to create these files.

• Users provisioned in Quick with email addresses that match the identities in your ACL files. For details on provisioning users, see Managing user access in Amazon Quick.

• Quick admin access for configuring IAM policy assignments and knowledge base creation.

• Familiarity with IAM concepts and basic JSON syntax.

• A test or non-production knowledge base for validating your ACL configuration. Enabling ACLs is a one-way operation that cannot be reversed, so verify your setup before enabling it in production.

Controlling S3 bucket access for knowledge base creation

Document-level ACLs control which documents users can access within a knowledge base, but they don’t control who can create knowledge bases in the first place. Keep this distinction in mind. If your organization has S3 buckets that should always require ACLs (for example, a bucket containing sensitive HR or legal documents), you want to verify that only authorized administrators can create knowledge bases against those buckets. Without this control, a Quick user can create a new knowledge base on the same bucket without turning on ACLs, bypassing your document-level access controls entirely. This section describes how to implement these controls.

IAM policy assignments in Quick let you solve this by restricting which S3 buckets specific users or groups can access for knowledge base creation. For example, you can limit ACL-sensitive buckets to a small set of trusted administrators who will always turn on ACLs during setup, allow broader knowledge base creation for non-sensitive buckets where ACLs aren’t required, or block certain buckets from knowledge base creation entirely by not granting users access to them.

Note: IAM policies assigned through Quick take precedence over AWS resource-level policies. Confirm that your IAM policies meet your access requirements before assigning them.

This step is optional. However, be aware that without IAM policy assignments restricting knowledge base creation, any Quick user with access to an S3 bucket could create a separate knowledge base on that same bucket without enabling ACLs, effectively bypassing your document-level access controls. Consider whether this risk applies to your organization before skipping this section.

Step 1: Create an S3 access policy in IAM

Create an IAM policy in the IAM console that specifies which S3 buckets the assigned users can access. The following example policy grants access to two specific buckets:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "arn:aws:s3:::*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket",
        "s3:ListBucketVersions",
        "s3:GetBucketLocation"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket1",
        "arn:aws:s3:::amzn-s3-demo-bucket2"
      ]
    },
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion"
      ],
      "Resource": [
        "arn:aws:s3:::amzn-s3-demo-bucket1/*",
        "arn:aws:s3:::amzn-s3-demo-bucket2/*"
      ]
    }
  ]
}

Replace amzn-s3-demo-bucket1 and amzn-s3-demo-bucket2 with the names of the S3 buckets that you want to grant access to.

Step 2: Assign the policy in Quick

After creating the IAM policy, assign it to Quick users or groups through the admin console.

To assign the policy in Quick:

• In the Quick admin console, under Permissions, choose IAM policy assignments.

• Choose Add new assignment.

• Enter a name for the assignment (for example, s3-kb-restrict).

• On the Select an IAM policy page, search for and select the IAM policy you created in Step 1. Choose Next.

• On the Assign users and groups page, choose one of the following:

Select Assign to users and groups to apply the policy to current and future users.

• Search for and select specific users or groups to assign the policy to.

• Choose Next.

• On the Review and enable changes page, verify your assignment details and choose Save and enable.

Users who aren’t explicitly granted access through an IAM policy assignment can’t use the restricted S3 buckets to create knowledge bases. A user can still access a knowledge base shared with them. The restriction only applies to knowledge base creation. The IAM policy assignment gives you a layer of administrative control that complements the document-level ACLs you configure within each knowledge base.

For more details, see Restrict Amazon S3 bucket access with IAM policy assignments in the Amazon Quick documentation.

Planning your access control structure

Before creating your ACL files, determine your access control structure. Quick enforces the permissions you configure, but it’s up to you to decide who should have access to which documents and to build the corresponding ACL files.

Start by mapping your organizational access needs. Identify which teams, roles, or individuals need access to which document sets. Then choose your ACL method: a single global ACL file or ACL entries in metadata files at the document-level. Finally, align your identities. The user and group names in your ACL files must match the email addresses and group names of your Quick users (email matching is case-insensitive, but group names must match exactly). Group membership is managed in your Identity provider (IdP), such as IAM Identity Center, and synced with Quick, not in the ACL files themselves.

The following examples illustrate common access patterns and how you might structure them.

Access pattern

Method

Example configuration

Team-wide folder access

Global ACL file

ALLOW group finance-team on s3://amzn-s3-demo-bucket/finance/

Company-wide read access

Global ACL file

ALLOW group all-employees on s3://amzn-s3-demo-bucket/policies/

Single-user document access

Document-level metadata

ALLOW user vp-eng@example.com on roadmap-2026.pdf

Restricted folder (deny-by-default)

Global ACL file

ALLOW group legal-team on s3://amzn-s3-demo-bucket/legal/ (other prefixes denied by default)

Combined approach

Both methods

Global ACL ALLOWs hr-team on s3://amzn-s3-demo-bucket/hr/ + metadata file ALLOWs manager@example.com on a specific file

Option 1: Configure access using a Global ACL file

Before you begin: Enabling document-level ACLs on a knowledge base is a one-way operation and can’t be reversed. If you need to remove ACL functionality later, you must create a new knowledge base without ACLs. Test your ACL configuration on a non-production knowledge base first, because this setting can’t be turned off after it’s enabled.

The global ACL file is a single JSON file that maps S3 prefixes to access control entries. Upload this file to the root of your S3 bucket. The file doesn’t need to be named acl.json.

Global ACL file structure

The file is a JSON array where each entry specifies an S3 prefix and its associated access control entries.

Each aclEntries item includes:

• Name – The user email address or group name. This must match the identity within Quick exactly. For example, a user’s email or group from IAM Identity Center.

• Type – Either USER or GROUP.

• Access – Either ALLOW or DENY.

Remember, prefixes not listed in this file are denied by