# 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/)