Serviços que somam ao Bedrock II: segurança, identidade e conformidade
- ⬜🎯 Serviços que somam ao Bedrock I: IA especializada e ML clássico(AWS Bedrock — GenAI em Produção)
Recomendamos completar os pré-requisitos antes de seguir, mas nada te impede de continuar.
Esta é a camada que nunca aparece no diagrama que o time desenha no quadro branco — e a que decide se o projeto vai para produção. Ela não soma capacidade ao Bedrock: soma permissão para existir. O padrão é sempre o mesmo e vale gravar: um controle ausente não impede absolutamente nada durante o desenvolvimento, e vira bloqueio total na véspera do lançamento, quando não dá mais para retroagir. Registro de invocação não reconstitui o passado; varredura de dado sensível depois da indexação exige reprocessar tudo. Este módulo percorre os 16 serviços dessa camada com o vínculo específico de cada um com uma arquitetura de IA.
Como escolher nesta camada
- Quem é o ator da chamada? Aplicação (role), colaborador (SSO corporativo) ou cliente final (identidade do app). Cada um tem serviço próprio e misturá-los é a origem de metade dos problemas de autorização.
- O controle é preventivo ou detectivo? Preventivo impede a ação (policy, SCP, filtro). Detectivo avisa depois (alarme, achado). Comitê de risco aceita os dois, mas só o preventivo fecha a pergunta.
- É reconstituível depois? Se a resposta for não — registro de conteúdo, varredura de origem, atribuição de custo — o item é obrigatoriamente de dia 1.
O que muda quando a carga é de IA
Três coisas que uma API comum não tem. Primeira: cada requisição custa dinheiro real, então custo é superfície de ataque. Segunda: o conteúdo trafegado é a pergunta do usuário e a resposta do modelo — dado sensível por natureza, e é exatamente o que a auditoria vai querer ler. Terceira: a permissão precisa chegar até a camada de recuperação, porque instrução no prompt não é controle de acesso. Nenhum dos três aparece num questionário de segurança genérico.
Identidade: quem é quem e o que pode
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| AWS IAM | Autorização de tudo na AWS: quem pode chamar qual API, sobre qual recurso, sob quais condições | É onde se declara qual app pode invocar qual modelo, com qual guardrail e por qual caminho de rede — de forma verificável | Política é por recurso e condição, não por usuário final do seu app: a autorização do cliente é outra camada |
| IAM Identity Center | SSO corporativo: identidade de pessoa, com grupos herdados do diretório da empresa | Acesso de colaborador ao assistente interno e do desenvolvedor às ferramentas apontadas ao Bedrock — sem chave pessoal | Serve pessoa, não aplicação; carga de máquina continua em role |
| Amazon Cognito | Identidade de usuário final do seu produto, com federação e pool de usuários | Autentica o cliente do chat e produz o token que o gateway usa para resolver tenant e quota | Não substitui IAM na autorização de recurso AWS — os dois convivem em papéis distintos |
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "InvocarApenasOsModelosHomologados",
"Effect": "Allow",
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
"Resource": [
"arn:aws:bedrock:us-east-1:111122223333:application-inference-profile/credito",
"arn:aws:bedrock:us-east-1::foundation-model/<modelo-homologado>"
]
},
{
"Sid": "ExigirGuardrailEmTodaChamada",
"Effect": "Deny",
"Action": ["bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream"],
"Resource": "*",
"Condition": {
"Null": { "bedrock:GuardrailIdentifier": "true" }
}
},
{
"Sid": "SomenteDentroDaVPC",
"Effect": "Deny",
"Action": "bedrock:*",
"Resource": "*",
"Condition": {
"StringNotEquals": { "aws:SourceVpce": "vpce-0abc123" }
}
},
{
"Sid": "ApenasKnowledgeBaseDoDominio",
"Effect": "Allow",
"Action": ["bedrock:Retrieve", "bedrock:RetrieveAndGenerate"],
"Resource": "arn:aws:bedrock:us-east-1:111122223333:knowledge-base/kb-politicas-credito"
}
]
}
A negação condicional é o que impressiona a auditoria
Permitir é o fácil. O que transforma boa intenção em controle demonstrável são as negações condicionais: negar a invocação sem guardrail e negar qualquer chamada que não venha pelo endpoint privado. São duas cláusulas que respondem sozinhas a metade das perguntas de um questionário de segurança — e, diferente de uma política escrita em documento, elas são verificáveis por qualquer pessoa que leia a policy.
O ponto que o Identity Center resolve e que quase todo copiloto interno erra: a permissão do funcionário precisa viajar até a camada de recuperação. O grupo que vem do diretório corporativo tem que virar filtro de metadados na consulta ao índice — não instrução no prompt pedindo ao modelo que se contenha. Se o documento restrito entrou no contexto, o vazamento já aconteceu e o resto é sorte. É a diferença entre um controle auditável e uma promessa.
Três atores, três serviços — nunca uma role para todos
Uma role de plataforma compartilhada entre todos os apps destrói a atribuição de custo e a investigação de incidente ao mesmo tempo: você não sabe quem gastou nem quem chamou. Uma role por aplicação, SSO para pessoa e identidade de app para cliente final. Custa uma tarde a mais no começo e é irrecuperável depois — porque atribuir retroativamente exige reprocessar log que talvez não exista.
Segredo e criptografia
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| AWS KMS | Gerenciamento de chave criptográfica, com trilha de uso e possibilidade de revogação | Chave sua no bucket de origem do RAG, no destino do registro de invocação, na base de conhecimento e na tabela de conversas | Cobra por chave e por operação; chave gerenciada pelo cliente é requisito comum em setor regulado |
| AWS Secrets Manager | Segredo versionado, com rotação automática e trilha de leitura | Credencial que as ferramentas do agent usam — a única resposta correta para "onde guardo a chave da API interna" | Cobra por segredo e por chamada; rotação exige que a aplicação releia o valor |
| Parameter Store | Parâmetro e configuração versionados, mais barato que segredo | Model ID, versão de prompt, limiar de confiança e mapa de tier — trocar sem novo deploy, e reverter na mesma velocidade | Não é cofre: não use para segredo. Há limite de tamanho por parâmetro |
Segredo em prompt é segredo publicado
Chave de API no prompt de sistema não é atalho: o histórico da conversa é persistido, retorna em listagem de eventos e entra em resumo de compactação. Uma vez lá, ela vive pelo tempo de vida da sessão e do log. A credencial fica no cofre e é lida pelo código que executa a ferramenta — nunca pelo modelo, e nunca no texto que trafega.
Parameter Store é o botão de reverter
O erro operacional mais comum em plataforma de IA madura: alguém melhora uma frase do prompt direto em produção na sexta, a qualidade cai e não existe diff para reverter. Com prompt, versão de guardrail, limiar e tier em configuração versionada — e o identificador registrado em cada chamada — você responde "o que mudou?" e volta atrás em minutos, sem deploy.
Rede
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| VPC endpoints / PrivateLink | Endpoint de interface dentro da sua VPC para um serviço AWS | O tráfego de inferência não sai para a internet pública — e vira condição verificável na policy de IAM | Cobra por endpoint e por hora, além do tráfego; um endpoint por serviço e por zona |
| AWS WAF | Firewall de aplicação: regra gerenciada, limite de taxa e regra própria na borda | Contra abuso do endpoint de chat — em IA, tráfego excedente não custa capacidade, custa fatura | Regra é por requisição; não entende semântica do prompt (injeção não é problema de WAF) |
| AWS Shield | Proteção contra negação de serviço, com camada avançada opcional | Endpoint público de alto valor exposto a volume malicioso | A camada avançada tem custo mensal significativo; só se justifica em exposição real |
Endpoint privado resolve mais que segurança
Além de manter o tráfego fora da internet pública, o endpoint de interface dá a você uma condição verificável para escrever na policy — e é ela que permite negar qualquer chamada vinda de fora da VPC. Ou seja: uma decisão de rede vira um controle de identidade. É por isso que vale configurar no primeiro dia, mesmo em piloto, e não quando o time de segurança pedir.
Um endpoint de IA exposto é um cartão de crédito exposto
Diferente de uma API comum, cada requisição ao seu chat custa dinheiro real. Sem limite de taxa e sem regra de abuso, um script simples vira uma fatura inesperada em horas. O conjunto mínimo é: autenticação obrigatória, limite por usuário e por origem, regra de bot na borda, teto de tokens por requisição no gateway e alerta de variação diária de gasto. Trate custo como superfície de ataque, porque é exatamente isso que ele é.
Proteção de dado e detecção
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Amazon Macie | Descoberta de dado sensível e pessoal dentro de buckets, com classificação | Varre a ORIGEM do RAG antes da indexação — evita indexar o que não podia ser recuperado | Cobra por volume inspecionado; varredura de acervo grande precisa de escopo e amostragem |
| Amazon GuardDuty | Detecção de ameaça e comportamento anômalo na conta | Uso atípico de credencial ou padrão estranho de chamada de API do Bedrock | É detectivo: avisa depois. Não impede a ação, e o achado precisa de alguém para tratar |
Varra a origem antes de indexar, não depois
O momento certo de descobrir que há CPF em planilha solta no bucket de documentos é antes da indexação. Depois que o conteúdo virou embedding e chunk, retirá-lo exige reindexação e, pior, ele já pode ter aparecido em respostas e em logs. Uma varredura da origem antes da primeira ingestão é barata e evita o tipo de incidente que suspende o projeto inteiro.
Qual controle garante, de forma que a auditoria aceite, que nenhuma aplicação invoque o modelo sem guardrail?
Governança organizacional
Enquanto IAM controla o que uma aplicação pode fazer, esta família controla o que a organização inteira pode fazer — inclusive contra a vontade de um administrador de conta. É o nível em que "só usamos modelo homologado" e "só operamos nesta região" deixam de ser política escrita e viram barreira técnica.
| Serviço | O que é | O que soma ao Bedrock | O limite que decide |
|---|---|---|---|
| Organizations + SCP | Hierarquia de contas com políticas de controle que limitam o que qualquer principal pode fazer | Bloqueia região não aprovada e modelo não homologado no nível da organização — nenhuma conta filha contorna | SCP só nega e restringe; não concede. E não se aplica à conta de gerenciamento |
| AWS Control Tower | Landing zone padronizada: contas, barreiras e baseline provisionados | Separa produção, homologação e sandbox de IA desde o começo, com controle uniforme | Opinativo sobre estrutura; adotar depois de a organização crescer é migração, não configuração |
| AWS Config | Avaliação contínua de conformidade de recursos, com histórico de configuração | Garante que o bucket de log nasce cifrado e que o registro de invocação não é desligado sem alarme | É detectivo com remediação opcional; regra própria exige código |
| AWS Audit Manager | Coleta contínua de evidência de controle, mapeada para frameworks | Monta o pacote de auditoria sem alguém caçar captura de tela do console na véspera | Frameworks prontos raramente cobrem IA; controle específico precisa ser modelado à mão |
| AWS Security Hub | Consolidação de achados de segurança de várias fontes e contas | Visão única quando a plataforma de IA cresce por várias contas e times | Consolida, não corrige; sem processo de tratamento, vira painel que ninguém abre |
SCP é o único controle que sobrevive a um administrador distraído
Policy de IAM pode ser alterada por quem tem permissão de IAM na conta. Política de controle de serviço na organização, não — ela é o teto. Para IA isso importa em dois pontos concretos e baratos de implementar: impedir invocação em região fora da residência de dados acordada, e impedir uso de modelo fora da lista homologada. Dois SCPs resolvem uma classe inteira de risco que nenhuma revisão de código pegaria.
- → autentica no diretório corporativo
- → limite de taxa antes de qualquer custo de token
- → negação condicional: sem guardrail, não invoca
- → só pelo endpoint privado
- → grupo do usuário vira filtro de metadados
- → SCP é o teto que ninguém contorna
- Fora da AWS
- Segurança e identidade
- Rede e entrega
- IA e machine learning
- Gestão e governança
Repare que o controle de acesso ao conhecimento acontece no retrieval, não no prompt. É a única forma de o documento restrito não existir para quem não pode lê-lo — e a única que a auditoria consegue verificar.
- Autenticar o ator certo. Colaborador entra pelo SSO corporativo com seus grupos; cliente final pela identidade do app. Nunca a mesma role para os dois.
- Barrar abuso antes do custo. Limite de taxa na borda: em IA, tráfego excedente não custa capacidade, custa fatura.
- Autorizar com negação condicional. A policy nega invocação sem identificador de guardrail e nega qualquer chamada que não venha do endpoint privado.
- Filtrar o conhecimento pela identidade. O grupo do usuário vira filtro de metadados na consulta. O documento restrito não é recuperado — não é o modelo que se contém.
- Proteger a saída. Guardrail aplica grounding contra alucinação e redação de dado pessoal no que volta ao usuário.
- Sustentar com governança. SCP limita região e modelo acima de qualquer administrador de conta; varredura da origem, conformidade contínua e evidência coletada sem esforço manual.
As perguntas do comitê e quem as responde
| Serviço que responde | Forma da evidência | Se não existir | |
|---|---|---|---|
| "Quem pode invocar o modelo?" | IAM | Policy com allowlist de modelo e negação condicional, legível por qualquer auditor | A resposta é uma opinião sobre a intenção do time |
| "O dado sai da nossa rede?" | PrivateLink + IAM | Endpoint de interface mais a condição de origem na policy | Você afirma que não sai, sem poder demonstrar |
| "Onde o dado é processado?" | Organizations (SCP) | Política de controle restringindo região, acima da conta | Depende de disciplina de cada administrador |
| "Há dado pessoal no acervo indexado?" | Macie | Relatório de classificação da origem, anterior à indexação | Descobre pelo incidente, e corrigir exige reindexar |
| "Quem pode ler o quê no assistente?" | Identity Center + filtro de metadados | Grupo do diretório propagado até a consulta ao índice | Permissão vira instrução no prompt — não é controle |
| "Quem revisou esta decisão?" | Log da aplicação | Registro de quem aprovou, quando e o que alterou | O controle de revisão humana não é auditável |
A coluna da direita é o argumento de orçamento
Quando alguém pergunta por que investir nesta camada antes de o produto existir, a resposta está na terceira coluna. Nenhum dos itens dela é recuperável com esforço depois: varredura de origem exige reindexação, atribuição de identidade exige log que não foi gravado, e residência de dados exige refazer a topologia. É por isso que esta camada é de dia 1 e não de sprint de endurecimento.
Checklist do dia 1 desta camada
- Uma role IAM por aplicação, com allowlist explícita de modelo e de base de conhecimento.
- Negação condicional de invocação sem guardrail e de chamada fora do endpoint privado.
- Endpoint de interface configurado, mesmo em piloto — ele vira condição verificável na policy.
- Chave gerenciada pelo cliente no bucket de origem, no destino de log e na base de conhecimento.
- Credencial de sistema em gerenciador de segredos; nada de segredo em prompt ou variável fixa.
- Prompt, versão de guardrail, limiar e mapa de tier em configuração versionada.
- Varredura de dado sensível na origem antes da primeira indexação.
- SCP restringindo região e modelo homologado no nível da organização.
- Identidade do SSO propagada até o filtro de metadados do retrieval — testada com um usuário sem acesso.
Teste o vazamento lateral de propósito
O item 9 é o único que exige teste ativo, e é o mais importante do checklist. Pegue um usuário sem acesso a um domínio restrito e tente chegar ao conteúdo por várias formulações diferentes, incluindo pedidos indiretos. Se alguma delas trouxer trecho restrito, o filtro não está no retrieval — está no prompt. Fazer esse teste antes de abrir para a empresa custa uma hora; descobrir depois custa o projeto.
Erros clássicos desta camada
- Uma role de plataforma compartilhada entre todos os apps: destrói atribuição de custo e investigação de incidente ao mesmo tempo.
- Permissão resolvida no prompt: o documento restrito entra no contexto e a proteção passa a depender de o modelo se conter.
- Segredo no prompt de sistema: o histórico é persistido, retorna em listagem de eventos e entra em resumo de compactação.
- Endpoint de chat autenticado mas sem limite de taxa: em IA, um script simples vira fatura inesperada em horas.
- Varredura de dado sensível depois da indexação: o conteúdo já virou embedding, já pode ter aparecido em resposta e em log.
- Confiar em WAF contra injeção de prompt: WAF não entende semântica; injeção é problema de arquitetura de capacidade, não de regra de borda.
- Só controles detectivos: alarme avisa depois que a ação aconteceu. Comitê de risco quer ver ao menos um preventivo por risco relevante.
- Deixar a residência de dados implícita: roteamento entre regiões pode processar fora do país que o contrato promete.
- Adotar landing zone depois de a organização crescer: aí não é mais configuração, é migração.
A empresa exige que o processamento aconteça apenas em uma região específica. O time de plataforma configurou isso nas policies de IAM de cada aplicação. Qual é a fragilidade?
Em que momento do ciclo de vida de um RAG a varredura de dado sensível na origem deve acontecer, e por quê?
Próximo passo
Segurança responde "podemos?". A próxima camada responde "está funcionando e quanto custa?" — observabilidade, os três registros diferentes que a auditoria pede, FinOps e a esteira de entrega. É também onde mora a instrumentação que, se não existir no dia 1, não é recuperável depois.
Perguntas frequentes
❓ Como aplicar negação condicional em IAM para IA?
❓ O que a conformidade normalmente exige de um projeto de IA?
❓ Rede privada é obrigatória para usar Bedrock?
Terminou de ler?
Marcar como concluído registra o XP, mantém sua sequência e coloca 3 cartas deste módulo na fila de revisão espaçada.
Próximos passos sugeridos
Temas deste módulo
Discussão
Carregando comentários…