Ограничение доступа к чувствительным документам в базах знаний Amazon Quick для Amazon S3

Организации, которым нужно ограничивать доступ к чувствительным документам, все чаще используют поиск и чат на базе ИИ, чтобы сотрудники могли находить ответы в больших хранилищах данных. Грубые разрешения на уровне базы знаний подходят многим командам, но для чувствительных документов нужен более детальный контроль, чтобы ограничивать доступ к отдельным документам или папкам только для авторизованных команд, людей или систем.

Поддержка списков управления доступом на уровне документов для баз знаний Amazon Simple Storage Service (Amazon S3) в Amazon Quick дает именно такой точный контроль. Вы ограничиваете чувствительные документы S3 только тем пользователям и группам, которые должны их видеть, на уровне документа или папки. Когда пользователь задает вопрос, Quick сопоставляет его идентичность с вашей конфигурацией ACL и показывает только тот контент, к которому у него есть доступ. С такими настройками вы можете безопасно перенести всю библиотеку документов в Quick и при этом соблюдать требования комплаенса и управления данными.

В этой статье мы покажем, как настроить ACL на уровне документов для базы знаний S3 в Amazon Quick. Вы узнаете, как подготовить и проверить конфигурацию ACL, которая обеспечивает права доступа на уровне документов в чатах и автоматизированных workflow. Статья охватывает:

• контроль того, к каким S3 buckets пользователи могут получать доступ для создания базы знаний, с помощью назначений политик IAM
• планирование структуры контроля доступа
• выбор между двумя методами настройки ACL: глобальным файлом ACL и файлами метаданных на уровне документов
• настройку прав для пользователей и групп
• проверку корректности контроля доступа через чат и ACL-aware Flows
• обновление и сопровождение конфигурации ACL со временем

Как ACL для S3 работает в Quick

С помощью функции ACL для S3 в Amazon Quick можно назначать документам права доступа так, чтобы ответы чата включали только тот контент, который вам разрешено просматривать. Вы задаете, кто может получать доступ к каким документам, используя стандартные политики ALLOW и DENY для отдельных пользователей или групп, а Quick применяет эти правила во время запроса.

Есть два способа настроить ACL, каждый подходит для разных операционных задач:

• Глобальный файл конфигурации ACL, например ACL.json — один централизованный файл, который задает права доступа на уровне папки (prefix). Используйте этот метод, если у вашей организации стабильная структура прав, построенная вокруг папок.
• Файлы метаданных на уровне документов — отдельные файлы метаданных рядом с каждым документом, содержащие записи контроля доступа для конкретного документа. Используйте этот метод, если права меняются часто, потому что тогда переиндексируются только затронутые документы, а не вся структура папок.

Выбирайте подход в зависимости от того, как часто меняются права и насколько детальным должен быть контроль:

Понимание области переиндексации

Область переиндексации зависит от выбранного метода и имеет важные операционные последствия. При использовании глобального ACL изменение прав запускает полную переиндексацию затронутого prefix. Если в вашей организации права меняются часто, лучше использовать файлы метаданных на уровне документов: тогда переиндексируются только затронутые документы, а не вся структура папок.

Поведение deny-by-default

Когда вы включаете ACL в базе знаний S3 в Quick, документ или prefix, который не указан явно в конфигурации ACL, запрещается по умолчанию. Такой подход deny-by-default, иногда называемый “fail closed” — это режим, при котором система по умолчанию запрещает доступ, если нет явного правила. Это означает, что при настройке ACL вы должны явно выдавать доступ к каждому prefix или документу, к которому пользователи должны иметь доступ.

Например, если в вашем S3 bucket есть три папки (/finance/, /legal/ и /policies/), а в ACL-файле доступ разрешен только к /finance/ и /policies/, папка /legal/ и все ее содержимое будут автоматически запрещены для всех, даже если для нее нет отдельного правила DENY.

Модель неявного запрета, используемая в IAM, работает так же. Quick запрещает доступ, если вы не разрешили его явно. Когда вы настраиваете ACL, у вас есть явный контроль над доступом, и ничего не раскрывается случайно.

Если у пользователя или группы есть и запись ALLOW, и запись DENY для одного и того же документа или prefix, приоритет всегда имеет DENY. Это значит, что можно использовать широкие правила ALLOW для команды или группы, а затем точечно добавлять записи DENY, чтобы ограничить доступ к конкретным ресурсам, не перестраивая всю ACL-конфигурацию.

Необходимые условия

Перед началом убедитесь, что у вас есть следующее:

• аккаунт AWS с включенным Amazon Quick. Если у вас нет аккаунта Quick, см. Начало работы с Amazon Quick.
• S3 bucket Amazon S3 с документами, которые вы хотите индексировать.
• понимание того, как вы хотите структурировать списки контроля доступа. В следующих разделах показано, как создавать такие файлы.
• пользователи, подготовленные в Quick, с адресами электронной почты, которые совпадают с идентичностями в ваших ACL-файлах. Подробности о подготовке пользователей см. в статье Управление доступом пользователей в Amazon Quick.
• доступ администратора Quick для настройки назначений политик IAM и создания базы знаний.
• знание концепций IAM и базового синтаксиса JSON.
• тестовая или непроизводственная база знаний для проверки конфигурации ACL. Включение ACL — это необратимая операция, поэтому сначала проверьте настройку перед включением в production.

Контроль доступа к S3 bucket при создании базы знаний

ACL на уровне документов контролируют, к каким документам пользователи могут получать доступ внутри базы знаний, но не управляют тем, кто вообще может создавать базы знаний. Важно не путать эти два уровня. Если в вашей организации есть S3 buckets, для которых ACL должны использоваться всегда, например bucket с чувствительными HR- или юридическими документами, нужно убедиться, что только авторизованные администраторы могут создавать базы знаний на основе этих buckets. Без такого контроля пользователь Quick может создать новую базу знаний на том же bucket, не включив ACL, и полностью обойти ваши документные ограничения доступа. В этом разделе объясняется, как реализовать такие ограничения.

Назначения политик IAM в Quick позволяют решить эту задачу, ограничив, к каким S3 buckets конкретные пользователи или группы могут обращаться при создании базы знаний. Например, можно ограничить ACL-чувствительные buckets небольшим числом доверенных администраторов, которые всегда включают ACL при настройке; разрешить более широкое создание баз знаний для не чувствительных buckets, где ACL не требуются; либо полностью заблокировать создание баз знаний для некоторых buckets, просто не предоставляя пользователям доступ к ним.

Примечание: Политики IAM, назначенные через Quick, имеют приоритет над политиками AWS на уровне ресурса. Перед назначением убедитесь, что ваши политики IAM соответствуют требованиям к доступу.

Этот шаг необязателен. Однако помните: если не ограничить создание баз знаний с помощью назначений политик IAM, любой пользователь Quick, у которого есть доступ к S3 bucket, сможет создать отдельную базу знаний на том же bucket без включения ACL, фактически обойдя ваши ограничения на уровне документов. Прежде чем пропускать этот раздел, оцените, актуален ли такой риск для вашей организации.

Шаг 1. Создайте политику доступа к S3 в IAM

Создайте политику IAM в консоли IAM, которая определяет, к каким S3 buckets смогут обращаться назначенные пользователи. В следующем примере политика дает доступ к двум конкретным 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/*"
 ]
 }
 ]
}

Замените amzn-s3-demo-bucket1 и amzn-s3-demo-bucket2 на названия S3 buckets, к которым вы хотите предоставить доступ.

Шаг 2. Назначьте политику в Quick

После создания политики IAM назначьте ее пользователям или группам Quick через консоль администратора.

Чтобы назначить политику в Quick:

1. В консоли администратора Quick в разделе Permissions выберите IAM policy assignments.

1. Выберите Add new assignment.

1. Введите имя назначения, например s3-kb-restrict.

1. На странице Select an IAM policy найдите и выберите политику IAM, которую вы создали на шаге 1. Нажмите Next.

1. На странице Assign users and groups выберите один из вариантов:
   1. выберите Assign to users and groups, чтобы применить политику к текущим и будущим пользователям;
   2. найдите и выберите конкретных пользователей или группы, к которым нужно назначить политику.
2. Нажмите Next.
3. На странице Review and enable changes проверьте детали назначения и нажмите Save and enable.

Пользователи, которым не предоставлен явный доступ через назначение политики IAM, не смогут использовать ограниченные S3 buckets для создания баз знаний. При этом пользователь все равно может пользоваться базой знаний, если она была с ним поделена. Ограничение относится только к созданию базы знаний. Назначение политики IAM дает вам административный уровень контроля, который дополняет ACL на уровне документов, настроенные внутри каждой базы знаний.

Подробнее см. в документации Amazon Quick: Ограничение доступа к S3 bucket с помощью назначений политик IAM.

Планирование структуры контроля доступа

Прежде чем создавать файлы ACL, определите структуру контроля доступа. Quick применяет заданные вами права, но именно вы решаете, кто должен иметь доступ к каким документам, и создаете соответствующие ACL-файлы.

Сначала опишите потребности вашей организации в доступе. Определите, какие команды, роли или отдельные сотрудники должны получать доступ к каким наборам документов. Затем выберите метод ACL: один глобальный файл ACL или записи ACL в файлах метаданных на уровне документов. Наконец, согласуйте идентичности. Имена пользователей и групп в ACL-файлах должны совпадать с адресами электронной почты и названиями групп пользователей Quick (совпадение по email не зависит от регистра, но названия групп должны совпадать точно). Участие в группах управляется в вашем Identity provider (IdP), например IAM Identity Center, и синхронизируется с Quick, а не задается в самих ACL-файлах.

Следующие примеры показывают распространенные модели доступа и то, как можно их структурировать.

Вариант 1. Настройка доступа с помощью глобального файла ACL

⚠️ Перед началом: Включение ACL на уровне документов в базе знаний — необратимая операция, которую нельзя отменить. Если позже вам понадобится удалить функциональность ACL, придется создать новую базу знаний без ACL. Сначала протестируйте конфигурацию ACL на непроизводственной базе знаний, потому что после включения этот параметр нельзя выключить.

Глобальный файл ACL — это один JSON-файл, который сопоставляет S3 prefix с записями контроля доступа. Загрузите этот файл в корень вашего S3 bucket. Файл не обязательно должен называться acl.json.

Структура глобального файла ACL

Файл представляет собой JSON-массив, где каждая запись задает S3 prefix и связанные с ним записи контроля доступа.

Каждый элемент aclEntries включает:

• Name — адрес электронной почты пользователя или имя группы. Он должен точно совпадать с идентичностью в Quick. Например, с email пользователя или группой из IAM Identity Center.
• Type — либо USER, либо GROUP.
• Access — либо ALLOW, либо DENY.

Помните: prefix, не указанные в этом файле, запрещены по умолчанию.

Шаги настройки

1. Создайте файл acl.json по структуре, показанной выше.
2. Загрузите файл acl.json в корень вашего S3 bucket, то же место, где находятся документы.
3. В консоли Quick перейдите в раздел Knowledge.
4. Выберите Amazon S3 как базу знаний и настройте параметры своего S3 bucket.
5. Введите сведения о базе знаний и выберите Next: Additional settings.
6. В разделе Additional settings включите параметр Access control list (ACL).
7. В поле Global ACL file location укажите S3 URI к файлу acl.json, например s3://amzn-s3-demo-bucket/acl.json.
8. Запустите синхронизацию, чтобы проиндексировать документы. Quick применяет правила ACL во время индексирования.

После завершения синхронизации только документы под prefix с явными записями ALLOW будут проиндексированы и доступны в чате. Вы можете просмотреть отчет о запуске синхронизации, чтобы увидеть, какие документы были проиндексированы, а какие не были проиндексированы из-за ограничений ACL.

Файлы, добавленные успешно:

Файлы с ошибкой:

Вариант 2. Настройка доступа с помощью файлов метаданных на уровне документов

⚠️ Перед началом: Включение ACL на уровне документов в базе знаний — необратимая операция, которую нельзя отменить. Если позже вам понадобится удалить функциональность ACL, придется создать новую базу знаний без ACL. Сначала протестируйте конфигурацию ACL на непроизводственной базе знаний, потому что после включения этот параметр нельзя выключить.

Если вам нужен контроль на уровне отдельных документов или более быстрое переиндексирование при изменении прав, можно использовать файлы метаданных на уровне документов. Каждый документ в вашем S3 bucket получает соответствующий JSON-файл метаданных, содержащий записи контроля доступа.

Структура файла метаданных

Создайте файл .metadata.json для каждого документа. Файл метаданных должен храниться в том же S3 bucket, в папке метаданных, которую вы укажете при настройке базы знаний, либо рядом с самим документом, который индексируется. Оба варианта описаны в следующем разделе.

Файл включает массив AccessControlList. Для применения ACL обязательным является только поле AccessControlList. Остальные поля (DocumentId, Attributes, Title, ContentType) необязательны и используются для дополнительного обогащения метаданных:

{
 "DocumentId": "finance-q3-report",
 "Attributes": {
 "_category": "financial-reports",
 "_created_at": "2025-10-01T00:00:00Z",
 "_source_uri": "s3://amzn-s3-demo-bucket/reports/q3-report.pdf"
 },
 "AccessControlList": [
 {
 "Name": "finance-team",
 "Type": "GROUP",
 "Access": "ALLOW"
 },
 {
 "Name": "contractor@example.com",
 "Type": "USER",
 "Access": "DENY"
 }
 ],
 "Title": "Q3 Financial Report",
 "ContentType": "PDF"
}

Элементы AccessControlList имеют тот же формат, что и в глобальном файле ACL. Каждая запись содержит Name, Type (USER или GROUP) и Access (ALLOW или DENY).

Документы без файла метаданных или с файлом метаданных, в котором нет AccessControlList, при включенном ACL запрещаются по умолчанию.

Имя и расположение файла метаданных

Чтобы база знаний нашла нужный файл метаданных, к расположению папки метаданных добавляется S3 key документа, а затем добавляется суффикс .metadata.json, формируя путь S3 для файла метаданных в Amazon S3. Например, если S3 key файла — recipe.pdf, то S3 key файла метаданных будет recipe.pdf.metadata.json.

Есть два варианта размещения файлов метаданных. Их можно хранить в отдельной папке, например s3://amzn-s3-demo-bucket/metadata, либо в той же папке, что и соответствующий файл.

Вот пример, когда файлы находятся вместе в одной папке:

Другой пример — с выделенной папкой metadata:

Шаги настройки

1. Создайте файл .metadata.json для каждого документа, который вы хотите индексировать, включая поле AccessControlList.
2. Загрузите файлы метаданных в ваш S3 bucket либо в отдельную папку metadata, либо в ту же папку, где лежит каждый соответствующий S3-файл.
3. В консоли Quick перейдите в раздел Knowledge.
4. Выберите Amazon S3 как новую базу знаний.
5. В разделе Additional settings включите параметр access control list (ACL).
6. Для расположения файла метаданных выберите один из вариантов:
   1. Вариант с той же папкой: оставьте поле расположения папки метаданных пустым.

• 1. Вариант с отдельной папкой: в поле Metadata folder location укажите S3 URI к папке метаданных, например s3://amzn-s3-demo-bucket/metadata/.

1. Выберите Create.
2. Запустите синхронизацию. Quick считывает записи ACL из каждого файла метаданных и применяет их во время запроса.

Проверка вашей конфигурации

После завершения синхронизации базы знаний вы можете проверить, что ACL работают корректно, через чат и Flows.

Чат

Чтобы проверить ACL в чате:

1. Откройте чат в Quick и подключите его к базе знаний с включенным ACL.
2. Отключите веб-поиск в нижней части сессии чата, чтобы ограничить результаты только вашей базой знаний.
3. Задайте вопрос о документе, к которому у вас есть доступ. Вы должны получить релевантный ответ.

1. Задайте вопрос о документе, к которому у вас нет доступа. Quick не должен показывать контент из этого документа.

Проверка ACL подтверждает, что Quick фильтрует ответы на основе вашей идентичности и конфигурации ACL.

Flows

С помощью Quick Flows и S3 ACL можно строить интеллектуальные конвейеры автоматизации с учетом прав доступа, которые соблюдают правила управления данными и при этом масштабно дают полезные результаты.

Следующий пример описывает концепцию flow: ACL-aware flows для executive summaries.

Flow включает следующие шаги:

1. Триггер и контекст пользователя: пользователь отправляет тему через чат или консоль Flow. Flow фиксирует его идентичность для оценки доступа.
2. Проверка ACL для S3: flow проверяет конфигурацию ACL, чтобы определить, к каким документам у вас есть доступ, обеспечивая управление данными на уровне автоматизации.
3. Генерация внутренней сводки: если есть авторизованные документы, flow извлекает их и создает executive summary на основе внутренних источников.
4. Резервный веб-поиск: если внутренние источники недоступны, flow автоматически выполняет поиск в интернете. Внешние сводки помечаются явно для прозрачности. Это необязательный шаг flow.

Этот сценарий можно расширить дальше: передавать сводку в последующий шаг, который создает структурированный набор слайдов для брифинга руководства, либо добавить шаг отправки email с рассылкой сводок пользователям или спискам рассылки по расписанию.

Обновление ACL после начальной настройки

Когда ваша организация меняется — появляются новые сотрудники, меняются команды, происходят переходы между ролями — обновляйте конфигурацию контроля доступа соответствующим образом. Quick не отслеживает изменения в ACL-файлах в реальном времени. Обновленные права вступают в силу при следующей синхронизации базы знаний, которая по умолчанию запускается ежедневно. Для срочных изменений, например отзыва доступа, запустите ручную синхронизацию сразу после обновления ACL-файлов. Чтобы обновить права:

1. Обновите ACL-файлы в S3. Измените глобальный ACL-файл или соответствующие файлы метаданных на уровне документов, чтобы отразить новые права — добавление пользователей, удаление доступа, изменение членства в группах и так далее.
2. Повторно синхронизируйте базу знаний. После загрузки обновленных файлов в S3 запустите новую синхронизацию базы знаний из консоли Quick. Quick повторно оценивает записи ACL во время синхронизации и обновляет индекс соответствующим образом.

До завершения синхронизации продолжают действовать прежние права.

Область переиндексации зависит от выбранного метода конфигурации:

• Глобальный файл ACL. Переиндексируется весь затронутый prefix.
• Метаданные на уровне документов. Переиндексируются только те документы, чьи файлы метаданных были изменены.

Если вы ожидаете частые изменения прав, файлы метаданных на уровне документов дают более быстрый отклик на обновления доступа.

Защита файлов ACL

Ограничьте права s3:PutObject на ACL-файлы и файлы метаданных только для небольшой группы администраторов. Любой, кто может изменять эти файлы, может выдать себе доступ к любому документу, поэтому доступ на запись к ACL-файлам следует считать привилегированной операцией. Включите версионирование S3 для ACL-файлов, чтобы сохранять историю изменений прав. Для файлов метаданных на уровне документов назначьте ответственность тем, кто хорошо понимает чувствительность каждого набора документов, например владельцам данных или руководителям по безопасности, чтобы решения по доступу оставались согласованными с бизнес-контекстом.

Мониторинг и аудит активности ACL

Для функции безопасности, такой как ACL на уровне документов, критически важна прозрачность изменений конфигурации и шаблонов доступа. Amazon Quick предоставляет несколько механизмов, которые помогают отслеживать и аудитировать базы знаний с включенным ACL.

Все действия по созданию и обновлению базы знаний записываются в AWS CloudTrail, включая информацию о том, включены ли ACL в базе знаний. Это дает администраторам журнал того, кто и когда настраивал ACL, помогает отслеживать изменения в конфигурации доступа и расследовать неожиданные изменения.

Amazon Quick также предоставляет возможность отслеживать размер баз знаний, что помогает следить за ростом и выявлять неожиданные изменения в проиндексированном контенте. Подробнее см. мониторинг использования хранилища индекса в документации Quick.

Ограничения и особенности

Перед включением ACL в базе знаний S3 обратите внимание на следующее:

• ACL нельзя отключить после включения. Включение ACL на уровне документов в базе знаний — это необратимая операция. Если позже вам нужно удалить функциональность ACL, придется создать новую базу знаний без ACL.
• Сопоставление идентичности пользователя основано на email. Поле Name в записях ACL должно точно совпадать с адресом электронной почты, связанным с идентичностью пользователя Quick. Если email пользователя изменится, обновите ACL-файлы и выполните повторную синхронизацию.

Дополнительные ограничения см. в разделах Ограничения коннектора S3 data source и Ограничения ACL базы знаний в документации Amazon Quick.

Очистка ресурсов

Если вы создали ресурсы в процессе работы по этой статье и они больше не нужны, выполните следующие действия, чтобы избежать дальнейших расходов:

1. Удалите базу знаний. В консоли Quick перейдите в раздел Knowledge, выберите созданную базу знаний и нажмите Delete.
2. Удалите ACL- и metadata-файлы. Удалите глобальный ACL-файл и файлы .metadata.json на уровне документов из вашего S3 bucket, если вы создавали их для тестирования.
3. Удалите политики IAM. Если вы создавали политику IAM для ограничения доступа к S3 bucket, сначала удалите назначение политики IAM в консоли администратора Quick, а затем удалите саму политику IAM в консоли IAM.

Заключение

ACL на уровне документов для баз знаний Amazon S3 в Amazon Quick дают вам детальный контроль над тем, кто может получать доступ к конкретным документам в вашей базе знаний. В этой статье вы настроили назначения политик IAM для контроля создания баз знаний, спланировали структуру контроля доступа, настроили как глобальные ACL-файлы, так и файлы метаданных на уровне документов, проверили конфигурацию через чат и Flows и узнали, как разбирать типичные проблемы.

С такими настройками вы можете уверенно расширять содержимое баз знаний, зная, что каждый пользователь видит только те документы и данные, к которым у него есть доступ. Это помогает вашей организации получать больше пользы от Quick, соблюдая требования безопасности, комплаенса и управления данными. Quick Flows расширяет эти настройки в автоматизированные workflow, проверяя доступ пользователя во время выполнения и формируя результаты только на основе тех документов, которые пользователь имеет право видеть. С ACL на уровне документов ваша организация может уверенно использовать ИИ, чтобы безопасно раскрывать ценность чувствительных данных.

Следующие шаги

Чтобы продолжить работу с тем, что вы узнали:

• изучите документацию по коннектору Amazon S3 для подробного справочника по настройке;
• прочитайте руководство по лучшим практикам ACL с рекомендациями по масштабированию структуры контроля доступа;
• попробуйте настроить ACL на тестовой базе знаний с примерными документами, прежде чем выкатывать решение в production. Начните с небольшого набора документов и нескольких тестовых пользователей, а затем расширяйте конфигурацию после того, как убедитесь, что она работает как ожидается.

Чтобы узнать больше об Amazon Quick, посетите страницу продукта Quick, изучите функции безопасности в Quick и присоединяйтесь к сообществу Quick, чтобы задавать вопросы и делиться опытом.

Материал — перевод статьи с английского.

Оригинал: Restrict access to sensitive documents in your Amazon Quick knowledge bases for Amazon S3