# 3LO no Bedrock Managed KB: 5 minutos de setup, 1 decisão irreversível

Em 4 de setembro de 2026 a AWS liberou o user-managed setup (3LO) para SharePoint, OneDrive e Confluence no Amazon Bedrock Managed Knowledge Base: você faz login com a sua própria conta e o data source sai em minutos. O que a documentação diz em letra miúda é que esse caminho não suporta controle de acesso por documento, e que a flag de ACL não muda depois do CreateDataSource. Este é o relato da migração que isso obriga — do protótipo em 3LO para um knowledge base de produção com ENTRA_ID_APP_ONLY, certificado e userContext.

- URL: https://fernando.moretes.com/blog/3lo-no-bedrock-managed-kb-5-minutos-de-setup-1-decisao-irreversivel-amazon-bedro

- Markdown: https://fernando.moretes.com/blog/3lo-no-bedrock-managed-kb-5-minutos-de-setup-1-decisao-irreversivel-amazon-bedro/article.md?lang=pt

- Published: 2026-09-05T10:15:56.145Z

- Category: IA & Agentes

- Tags: bedrock, rag, iam, sharepoint, confluence, governance, oauth

- Reading time: 9 min

- Source: [Amazon Bedrock Managed Knowledge Base introduces user-managed setup for SharePoint, OneDrive, and Confluence data sources](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-user-managed-setup-sharepoint-onedrive-confluence/)

---

A pergunta que importa nesse anúncio não é "quanto tempo leva para conectar o SharePoint?" — é "quem consegue ler o que foi indexado depois que você conectou?". O user-managed setup (3LO) que a AWS liberou em 4 de setembro de 2026 para SharePoint, OneDrive e Confluence no Amazon Bedrock Managed Knowledge Base resolve a primeira pergunta muito bem: você clica em **Sign in**, autoriza com a sua conta corporativa, e o Bedrock cria sozinho o segredo no Secrets Manager com o refresh token. A segunda pergunta é onde eu passei três semanas.

## O que o caminho de cinco minutos realmente troca

A página de setup do SharePoint é explícita e vale ler duas vezes: *user-managed setup does not support document-level access control (ACL)*. Todo conteúdo indexado fica acessível a qualquer pessoa que possa consultar o knowledge base, e as permissões individuais do SharePoint não são aplicadas. A mesma frase aparece na página do Confluence, palavra por palavra.

Isso não é um bug nem uma lacuna temporária — é consequência direta do fluxo. No 3LO o Bedrock guarda um **refresh token delegado**, emitido para você, com quatro permissões: `Sites.Read.All` e `User.Read` no Microsoft Graph, `offline_access` para renovar o token, e `AllSites.Read` na API do SharePoint Online. São permissões *delegated*, herdadas do que a sua conta enxerga. O crawler entra no tenant vestindo a sua identidade e copia tudo o que ela alcança para um índice que não tem noção de quem é quem.

O caminho que suporta ACL é outro: `ENTRA_ID_APP_ONLY` no SharePoint, `ENTRA_APP_ID` no OneDrive, `SERVICE_ACCOUNT` no Google Drive, `BASIC` no Confluence. São permissões **application**, com admin consent, e no caso do SharePoint com ACL exigem `Sites.FullControl.All` — ou `Sites.Selected` com grant `fullcontrol` por site — porque `Sites.Read.All` não basta para ler permissão de item.

A troca, dita sem eufemismo: o 3LO substitui um ticket de duas semanas com o time de identidade por um índice sem fronteira interna. Para um protótipo de wiki pública de engenharia, é um bom negócio. Para o repositório de políticas de crédito, é um incidente esperando a data.

## A jornada: do protótipo em 3LO ao knowledge base de produção

1. **Semana 0 — o protótipo nasce no console, sem pedir nada a ninguém** — Um analista com `bedrock:GetDataSourceAuthorizationUrl`, `bedrock:CreateDataSourceToken` e `secretsmanager:CreateSecret` completa o fluxo sozinho. O Bedrock cria o segredo em `arn:aws:secretsmanager:{region}:{account}:secret:bedrock-managedkb-oauth/{prefix}/{connector}/{uuid}` e o data source sai com `authType=MANAGED_OAUTH2`. Nenhum ticket, nenhum tenant ID, nenhuma revisão.

2. **Semana 1 — o portão que ninguém leu** — A página do Entra App-Only diz o que trava a jornada inteira: a decisão de habilitar ACL *não pode ser mudada depois que o data source é criado*. E o 3LO não oferece a opção. Ou seja: não existe upgrade in-place de `MANAGED_OAUTH2` para ACL — existe um data source novo e uma reingestão completa.

3. **Semana 2 — inventário do que já foi copiado** — Antes de construir o caminho novo, responda o que o antigo já indexou. O crawl seguiu a identidade de quem logou; se essa pessoa é sênior, o alcance é o dela. Liste os sites e espaços incluídos, cruze com a classificação de dados e trate o índice atual como um repositório de cópia — porque é isso que ele é.

4. **Semana 3 — app registration e certificado** — Aqui volta o ticket que o 3LO tinha eliminado. Um Global Administrator ou Privileged Role Administrator registra a aplicação single-tenant sem redirect URI, adiciona as permissões **application** e dá admin consent. Você gera um par com `openssl req -x509 -newkey rsa:2048`, sobe o `.cer` para o Entra e o bundle `.p12` para o S3 com SSE. O `.p12` é obrigatório quando há ACL.

5. **Semana 4 — segredo, service role e o data source novo** — O segredo leva `clientId` e `certificatePassword` — sempre defina a senha explicitamente; se omitir, o Bedrock abre o bundle usando o client ID como senha. A service role recebe `s3:GetObject` no objeto do certificado com condição `aws:ResourceAccount`, mais `kms:Decrypt` se você usou CMK. O data source sai com `certificateS3Path`, que é exigido no `ENTRA_ID_APP_ONLY` mesmo com ACL desligado.

6. **Semana 5 — a aplicação passa a provar quem está perguntando** — O `Retrieve` ganha `userContext.userId` com o e-mail universal do usuário. Sem isso, data sources com ACL devolvem zero resultados — o que é ótimo como fail-safe e péssimo como surpresa em produção. A autenticação continua sendo sua: o Bedrock filtra pela identidade que você afirma, não verifica se ela é verdadeira.

7. **Semana 6 — apagar o caminho antigo, inclusive o segredo** — Delete o data source `MANAGED_OAUTH2` e o segredo `bedrock-managedkb-oauth/*` que ficou órfão — ele ainda guarda um refresh token válido. Do lado da Microsoft, revogue desabilitando ou apagando o service principal em **Enterprise applications**; no Atlassian, o grant é por site, então cada `*.atlassian.net` precisa da sua própria revogação.

## As duas fases e o portão imutável entre elas

O 3LO é rápido porque termina em um refresh token delegado; a produção é lenta porque começa em um certificado e em consentimento administrativo. O portão no meio não é uma etapa — é uma decisão que só pode ser tomada uma vez por data source.

### 🧪 Fase 1 — Protótipo (3LO, minutos)

- Console Bedrock KB GetDataSourceAuthorizationUrl (frontend)
- Secrets Manager bedrock-managedkb-oauth/.../uuid (security)
- Data source authType=MANAGED_OAUTH2 (data)

### 🔐 Entra ID / Atlassian — consentimento

- Consentimento delegado Sites.Read.All + offline_access (external)
- Admin consent do tenant obrigatório se o tenant restringe apps (external)

### 🚧 O portão imutável

- aclEnabled não muda após CreateDataSource (security)

### 🟧 AWS — Fase 2 — Produção (2LO + ACL)

- Entra app registration application perms + Sites.FullControl.All (security)
- Amazon S3 certificate.p12 (SSE) (storage)
- Data source ENTRA_ID_APP_ONLY + ACL (data)
- Managed KB conteúdo + permissões crawladas (ai)
- Retrieve userContext.userId = e-mail (ai)

### 👤 Sua aplicação — autenticação verificada

- App corporativa OIDC valida o usuário final (compute)

### Fluxos

- analista -> signin: 1. Sign in
- signin -> consent: 2. popup OAuth
- consent -> adminconsent: bloqueado sem consent
- signin -> secret3lo: 3. grava refresh token
- secret3lo -> ds3lo: 4. secretArn gerado
- ds3lo -> gate: 5. sem ACL, definitivo
- gate -> dsprod: 6. data source novo + reingestão
- entraapp -> certs3: .p12 (chave privada)
- certs3 -> dsprod: certificateS3Path
- dsprod -> kb: crawl de conteúdo e ACL
- app -> retrieve: identidade já verificada
- retrieve -> kb: filtro pré-retrieval
- kb -> retrieve: verificação em tempo real no source

## Antes e depois, em números que a documentação confirma

- **4** — permissões delegadas concedidas no caminho 3LO. `Sites.Read.All`, `User.Read`, `offline_access` e `AllSites.Read` — leitura de tudo que a conta que logou enxerga, renovável indefinidamente.
- **0** — documentos filtrados por permissão no 3LO. Sem ACL não há `userContext`: quem consulta o knowledge base lê todo o índice, independentemente do que teria acesso no SharePoint.
- **365 dias** — validade padrão do certificado do caminho de produção. Certificado expirado faz todo sync falhar. A rotação vira item de runbook com dono e data — não uma lembrança.

## Identidade: o e-mail é a chave, e não há tradução

Chegar no caminho com ACL resolve menos coisas do que parece, e resolve de um jeito muito específico. O Bedrock Managed Knowledge Base usa **e-mail como identificador universal** — não há resolução de alias nem mapeamento entre provedores de identidade. O `userId` que você passa no `Retrieve` precisa bater exatamente com o e-mail associado àquele usuário em cada data source conectado. Se o seu IdP corporativo emite `fernando.azevedo@empresa.com` e o Confluence guarda `fazevedo@empresa.com`, o match falha em silêncio e o usuário simplesmente não recebe resultado daquela fonte. Silêncio é o pior modo de falha possível num sistema de busca: ninguém abre chamado por resposta incompleta, abre por resposta errada.

Grupos funcionam por outra régua. São identificados como a fonte os representa — nome, ID, o que for — e a associação usuário→grupo vem do crawl. A documentação é direta: **a associação de grupos é tão fresca quanto o último sync**. Mudou permissão entre syncs, o filtro pré-retrieval não sabe. O que salva é a segunda camada: para SharePoint, OneDrive, Google Drive e Confluence existe verificação em tempo real contra a fonte, que pega justamente essa janela. S3 e Custom não têm essa rede, porque o ACL deles vem de arquivo de metadados fornecido por você.

Duas notas que mudam o desenho da aplicação: credenciais do IdP terceiro ficam em cache por até **1 hora**, e mudanças de permissão são eventualmente consistentes, tipicamente em poucos minutos. Então "revoguei o acesso agora" e "o RAG parou de mostrar" não são o mesmo instante. Em ambiente sob BACEN ou LGPD, essa diferença precisa estar escrita no desenho, não descoberta na auditoria.

## Os dois caminhos, lado a lado
| Critério | Protótipo — `MANAGED_OAUTH2` (3LO) | Produção — `ENTRA_ID_APP_ONLY` (2LO) |
| --- | --- | --- |
| Quem autoriza | O próprio usuário, no popup — a menos que o tenant restrinja apps de terceiros, aí volta a exigir admin consent | Global Administrator ou Privileged Role Administrator, com admin consent explícito |
| Credencial armazenada | Refresh token delegado, em segredo criado pelo próprio Bedrock | Certificado `.p12` no S3 mais `clientId`/`certificatePassword` em segredo que você cria |
| Controle de acesso por documento | Não suportado — e a flag não muda depois | Suportado, com filtro pré-retrieval e verificação em tempo real |
| Alcance do crawl | O que a conta que logou enxerga — variável, invisível no console AWS | Todo o tenant com `Sites.Read.All`/`Sites.FullControl.All`, ou site a site com `Sites.Selected` |
| O que quebra | O desligamento de quem autorizou; o token revogado no Entra; conteúdo compartilhado depois do sync, que exige resync | Certificado expirado (todo sync falha); grant per-site esquecido para site novo, que não é retroativo |

## Os modos de falha que só aparecem depois

**O token tem dono, e dono pede demissão.** O refresh token do 3LO pertence a uma pessoa. Quando ela sai da empresa e a conta é desabilitada, o sync para — e o índice continua lá, com o conteúdo que ela alcançava. O caminho de produção não tem esse acoplamento: a aplicação se autentica com certificado, sem login humano nem no crawl nem na consulta.

**Fail closed é bom, mas parece bug.** A retrieval com ACL falha fechada: erro de resolução de grupo, timeout na verificação em tempo real ou erro interno não devolvem o documento. A resposta pode vir com menos resultados que o `maxResults` pedido, e o Bedrock **não** completa com outros documentos. Sua aplicação precisa tratar resposta parcial como normal, e distinguir "zero por ACL" de "zero por relevância" — a API sinaliza a falha de resolução justamente para isso.

**Documento sem ACL é documento invisível.** Em data source com ACL habilitado, documento cujas permissões não foram extraídas não vai para ninguém. Ausência é tratada como restrição, não como público. Depois da migração, espere uma queda de recall e investigue antes de culpar o embedding.

**O prefixo do segredo é a sua única alavanca de IAM, e o default é ambíguo.** A página de IAM do 3LO diz que sem prefixo o Bedrock usa `default`; as páginas de conector dizem que o segredo criado usa o prefixo `bedrock-managedkb-oauth`. Não construa policy em cima dessa suposição: informe um **secret name prefix** explícito no sign-in e escreva a policy com `Resource` escopado a ele *antes* de alguém rodar o fluxo. É a diferença entre `secretsmanager:CreateSecret` num caminho previsível e um `Resource: "*"` que ninguém vai revisar depois.

> **O risco não é o 3LO — é o 3LO que ninguém previu:** Duas permissões do Bedrock (`GetDataSourceAuthorizationUrl` e `CreateDataSourceToken`) mais `secretsmanager:CreateSecret` bastam para qualquer pessoa com acesso ao console indexar o SharePoint corporativo num knowledge base sem fronteira interna, sem tocar em nenhum processo de identidade. Se a sua conta de produção já concede essas ações por wildcard num policy de "desenvolvedor Bedrock", você não tem uma feature nova — tem um caminho novo de exfiltração autorizada por engano. Negue `bedrock:CreateDataSourceToken` fora das contas de sandbox antes de discutir arquitetura de RAG.

## Anti-padrões que eu já vi nascer nesse fluxo

- **Promover o protótipo trocando o `authType`**: não existe. A flag de ACL é imutável por data source, então promover significa criar data source novo e reingerir — planeje o custo de reingestão e a janela de índice duplicado.
- **Autorizar o 3LO com a conta do arquiteto**: quanto mais sênior o autorizador, maior o alcance do crawl. Se for usar 3LO, use uma conta com acesso deliberadamente estreito aos sites do escopo.
- **Tratar ACL awareness como autorização**: a própria documentação diz que é filtro, não fronteira de segurança. O Bedrock não autentica o usuário final — ele confia no `userId` que a sua aplicação afirma.
- **Desbloquear apps instalados por usuário no Atlassian "só por um minuto"**: enquanto o toggle está aberto, qualquer usuário autoriza qualquer app OAuth no site inteiro. Peça para o admin autorizar direto.
- **Deixar o segredo do 3LO para trás na limpeza**: o data source apagado não leva o segredo junto, e ele guarda um refresh token que ainda renova.

## Lente Well-Architected sobre a decisão

- **security**: Negue `bedrock:CreateDataSourceToken` em contas de produção por SCP; exija secret name prefix e escope o `Resource` a ele; use `Sites.Selected` em vez de `Sites.FullControl.All` sempre que a lista de sites for conhecida; guarde o `.p12` com SSE-KMS e `kms:Decrypt` restrito à service role.
- **reliability**: Certificado com validade padrão de 365 dias derruba todo sync ao expirar — alarme com 45 dias de antecedência. Grants per-site não são retroativos: site novo sem grant simplesmente não é crawlado, sem erro visível no data source.

## Deixe o protótipo existir — mas em uma conta onde ele não possa crescer

A tentação óbvia depois de ler tudo isso é bloquear o 3LO e pronto. Eu não faria. O atrito que ele remove é real: sem ele, todo experimento de RAG sobre a wiki interna vira um ticket de duas semanas com o time de identidade, e o resultado prático é que ninguém experimenta — ou pior, alguém exporta a wiki para um bucket e faz o RAG por fora, sem crawler, sem sync e sem nenhuma das verificações que a gente acabou de discutir.

O desenho que eu recomendo é topológico, não político. **Uma conta de sandbox** onde `bedrock:GetDataSourceAuthorizationUrl` e `bedrock:CreateDataSourceToken` são permitidas, sem dado classificado e com ciclo de vida curto — o índice inteiro morre em N dias por processo, não por lembrança. **As contas de produção** com essas duas ações negadas por SCP, o que faz o 3LO desaparecer do cardápio sem discussão caso a caso.

O que atravessa essa fronteira não é o data source; é o aprendizado. O protótipo responde as perguntas caras de verdade: quais espaços do Confluence têm conteúdo que resolve dúvida real, qual estratégia de chunking sobrevive a documento de política com 80 páginas, se a busca agêntica com `maxAgentIteration` acima do padrão de 5 muda a resposta o suficiente para pagar o custo. Nada disso depende de ACL. Quando a resposta for "vale", aí sim você abre o ticket com o time de Entra sabendo exatamente quais sites pedir no `Sites.Selected` — e o ticket fica mais curto porque você chega com escopo, não com intenção.

> **O que eu faria na segunda-feira:** Antes de habilitar qualquer coisa, eu rodaria uma busca por `bedrock:*` nos policies da conta de produção — a chance de as duas ações novas já estarem concedidas por wildcard é alta, e nenhuma revisão de IAM feita antes de setembro de 2026 poderia tê-las considerado. Depois eu criaria a conta de sandbox com o SCP invertido, porque bloquear na produção sem oferecer o lugar certo só empurra o problema para fora do meu campo de visão. Aprendi isso da forma cara em plataforma financeira: a decisão de arquitetura que parece de segurança quase sempre é de ergonomia — as pessoas contornam controle inconveniente com criatividade que nenhum policy prevê. E manteria a regra que uso para todo conector novo: se a flag não pode ser mudada depois, ela não é configuração, é design — e design vai para ADR, com o trade-off escrito e assinado antes do `CreateDataSource`.

## Veredito

Use o user-managed setup (3LO) quando as três condições valerem juntas: o conteúdo já é legível por toda a audiência do knowledge base, o índice vive em uma conta sem dado classificado, e existe data de expiração acordada para ele. Fora disso, vá direto para `ENTRA_ID_APP_ONLY` no SharePoint, `ENTRA_APP_ID` no OneDrive ou `BASIC` no Confluence — não porque o 3LO seja mal feito, mas porque a flag de ACL não muda depois do `CreateDataSource` e o desvio de cinco minutos hoje custa uma reingestão completa e um ticket com o time de Entra depois. O anúncio não é sobre autenticação; é sobre onde a fronteira de acesso da sua organização passa a existir — e o 3LO responde que ela passa a não existir dentro do índice. Isso é uma escolha legítima para um protótipo e é uma constatação de auditoria para o resto.

**Rating:** Adote em sandbox, negue em produção

## Referências

- [AWS What's New — Bedrock Managed Knowledge Base introduces user-managed setup for SharePoint, OneDrive, and Confluence (](https://aws.amazon.com/about-aws/whats-new/2026/09/amazon-bedrock-managed-knowledge-base-user-managed-setup-sharepoint-onedrive-confluence/)
- [Amazon Bedrock User Guide — SharePoint user-managed setup (3LO)](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-sharepoint-3lo-setup.html)
- [Amazon Bedrock User Guide — Confluence user-managed setup (3LO)](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-confluence-3lo-setup.html)
- [Amazon Bedrock User Guide — IAM permissions for user-managed setup (3LO)](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-3lo-setup.html)
- [Amazon Bedrock User Guide — Access Control Lists awareness enablement](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-acl.html)
- [Amazon Bedrock User Guide — ACL-aware retrieval on managed knowledge bases (userContext)](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-test-retrieve-acl.html)
- [Amazon Bedrock User Guide — Set up Microsoft Entra ID App-Only authentication for SharePoint](https://docs.aws.amazon.com/bedrock/latest/userguide/kb-managed-sharepoint-entra-setup.html)
- [AWS ML Blog — Build enterprise search for agents with Amazon Bedrock Managed Knowledge Base](https://aws.amazon.com/blogs/machine-learning/build-enterprise-search-for-agents-with-amazon-bedrock-managed-knowledge-base/)