Bedrock разрешила подключать рабочие хранилища через пользовательский вход

Вместо service account — обычный OAuth-вход

Amazon Bedrock Managed Knowledge Base получила user-managed setup для SharePoint, OneDrive и Confluence. Пользователь входит со своими существующими учётными данными стороннего сервиса, а Bedrock проводит authentication flow; AWS называет этот вариант 3LO и обещает настройку источника за несколько минут.

Раньше для этих источников требовались 2LO credentials, созданные на стороне сторонней системы. Такой процесс обычно зависел от администратора. Новый поток ориентирован на пользователя, у которого уже есть доступ к нужным документам, но нет административных прав для выпуска service account credentials.

AWS сохраняет оба варианта: user-managed setup предлагает более короткий путь для прототипа, а service account authentication остаётся программируемой enterprise-опцией для production workloads. Поэтому запуск 3LO не отменяет прежнюю схему, а добавляет выбор между скоростью старта и более строгой эксплуатационной моделью.

Bedrock сама создаёт секрет с refresh token

При user-managed setup пользователь не создаёт AWS Secrets Manager secret вручную. После входа Bedrock создаёт в AWS account секрет с системным ARN и сохраняет в нём 3LO refresh token. Для SharePoint и OneDrive также не нужно передавать tenant ID в форме подключения.

Для Confluence можно задать prefix имени секрета, чтобы заранее ограничить IAM policy ресурсами с этим prefix. После завершения consent flow data source создаётся с authType MANAGED_OAUTH2; аналогичное значение используется в инструкциях для SharePoint и OneDrive.

Автоматическое создание секрета не означает отсутствие IAM. Principal, вызывающий CreateDataSource, должен иметь доступ к нужному secret, а пользователь console — разрешения Bedrock для завершения 3LO flow. AWS приводит отдельные действия Secrets Manager для создания, чтения и обновления сохранённого token.

Microsoft tenant может всё равно потребовать администратора

Для SharePoint и OneDrive базовые prerequisites — Microsoft 365 account с доступом к индексируемому содержимому, права на создание knowledge bases в Bedrock и браузер, разрешающий popup окна console. У большинства пользователей дополнительных действий не требуется.

Но если Microsoft 365 tenant запрещает пользовательское согласие для сторонних приложений, администратор должен один раз выдать consent приложению Amazon Bedrock KB. AWS указывает роли Global Administrator или Privileged Role Administrator и описывает выдачу согласия через Microsoft dialog либо Entra admin center.

Следовательно, заявление «без администратора» справедливо не для любой корпоративной политики. Новый flow убирает обязательное создание 2LO credentials для каждого старта, но централизованная политика tenant может по-прежнему потребовать разовое разрешение приложения. Это важно проверить до обещания self-service внутренним командам.

Ускорение прототипа имеет явную границу доступа

Во всех трёх руководствах AWS отдельно предупреждает: user-managed setup не поддерживает document-level ACL. После индексации все пользователи, имеющие query access к knowledge base, получают доступ ко всему включённому контенту; индивидуальные права SharePoint, OneDrive или Confluence при retrieval не применяются.

Если необходим document-level access control, AWS предлагает другие способы authentication: Microsoft Entra ID App-Only для SharePoint, Microsoft Entra App ID для OneDrive и Basic authentication для Confluence. То есть 3LO следует выбирать не как универсальную замену production credentials, а как отдельный режим с иным security contract.

Особенно опасна интуитивная ошибка «Bedrock вошла от имени пользователя, значит каждый ответ сохранит права этого пользователя». Документация говорит обратное: права используются для выбора доступного при ingestion содержимого, но не воспроизводятся как per-document фильтр для каждого последующего запроса к knowledge base.

Как применять новый режим без ложного чувства безопасности

Managed Knowledge Base берёт на себя ingestion, vector storage, embeddings, re-ranking и retrieval optimization. Она уже поддерживает корпоративные источники вроде SharePoint, Confluence и OneDrive, а Smart Parsing выбирает стратегию обработки и сохраняет metadata, embedded images и thread context там, где это поддерживается.

Для быстрого эксперимента полезно создать отдельную knowledge base, подключить небольшой заведомо несекретный набор документов и проверить sync, удаление, обновление token и качество retrieval. Query permission нужно выдавать только аудитории, которой допустимо видеть весь индексируемый набор.

Переход к production требует отдельного решения. Если документы имеют разные ACL или содержат чувствительные разделы, стоит использовать рекомендованный AWS authentication mode с document-level access control либо физически разделить данные и knowledge bases по аудиториям. User-managed setup действительно сокращает путь до первого работающего прототипа, но не должен незаметно стать обходом корпоративной модели доступа.