AI Security Maturity Model·AWS v1.0.0

Arrastra para explorar · pellizca para ampliar

Fundacional Protección de datosCapa de defensa en profundidad: Identidad y datos Capacidad 3 · Generación aumentada por recuperación (RAG)Caso de uso: IA que conecta 👤 ClienteModelo de Responsabilidad Compartida de AWS: quién implementa y opera este control. Cliente = es tuyo; AWS = lo opera AWS y tú lo heredas; Compartida = ambos tienen obligaciones.

c3.1 Cifra la base de conocimiento y el vector store con una CMK

Cifra los jobs de ingesta de datos, el vector store, las sesiones de consulta y las fuentes de datos en S3 con una clave KMS gestionada por el cliente, para que los datos de RAG estén protegidos en reposo y en tránsito.

Fundacional
Mejorada
Avanzada
Esfuerzo: Bajo Impacto: Alto Scopes de IA generativaDe la AWS Generative AI Security Scoping Matrix.: 3 · Modelos preentrenados; 4 · Modelos ajustados (fine-tuned)

Guía de implementación

Cómo implementarlo en AWS

Configura el job de ingesta de la base de conocimiento de Bedrock, el vector store de OpenSearch Serverless y las sesiones de consulta para usar una clave KMS gestionada por el cliente. Cifra los buckets S3 de las fuentes de datos y cualquier secreto de Secrets Manager con el mismo control, y exige TLS 1.2+ en tránsito.

Los datos de RAG necesitan cifrado en varios puntos

Un knowledge base mueve tus datos por varias etapas, cada una un lugar donde los datos residen o transitan: las fuentes de datos en S3, el trabajo de ingesta que los fragmenta e incrusta (embeddings), el almacenamiento transitorio que Bedrock usa durante la ingesta, el vector store y las sesiones de consulta en el momento de la recuperación. Una clave administrada por el cliente (CMK) te permite poner todo esto bajo una clave cuyo acceso controlas y auditas, en lugar de depender de claves administradas por AWS que no puedes inspeccionar.

Deja que Bedrock use tu clave

Como en otras funciones de Bedrock, la política de clave concede al principal de servicio las operaciones necesarias, acotadas a Bedrock con kms:ViaService:

{
  "Sid": "AllowBedrockKnowledgeBaseUseOfKey",
  "Effect": "Allow",
  "Principal": { "Service": "bedrock.amazonaws.com" },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey",
    "kms:CreateGrant",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": { "kms:ViaService": "bedrock.us-east-1.amazonaws.com" }
  }
}

Cifra cada etapa, no solo una

  • Fuentes de datos: habilita SSE-KMS con esta CMK en el bucket de S3 que contiene los documentos fuente.
  • Datos transitorios durante la ingesta: pasa la CMK al crear la fuente de datos / configuración de ingesta para que Bedrock cifre los datos intermedios con tu clave.
  • Vector store: cifra la colección de OpenSearch Serverless (o el almacén que elijas) con una CMK, configurado en el propio almacén.
  • Sesiones de consulta: proporciona una CMK para los datos de sesión en el momento de la recuperación, de modo que los prompts y el contexto recuperado se cifren con tu clave.

Una cadena es tan fuerte como su eslabón más débil: si el vector store recae en una clave predeterminada, los embeddings de tus datos confidenciales quedan protegidos por una clave que no controlas.

Da al rol de servicio permiso de descifrado sobre la clave

El rol de servicio del knowledge base (consulta el control del rol de mínimo privilegio de KB) necesita kms:Decrypt (y kms:GenerateDataKey) sobre esta clave, o la ingesta y la recuperación fallan con errores de acceso. Mantén la administración de la clave en un rol separado del uso de la clave.

Nota de nomenclatura: reemplaza la región en kms:ViaService y usa una CMK local a la región. Usa la misma clave de forma consistente en fuentes, almacén y sesiones para que nada recaiga en una clave predeterminada.

Criterios de aceptación

La ingesta, el vector store, las sesiones y las fuentes S3 se cifran con una clave gestionada por el cliente; el rol de servicio de la KB tiene las políticas de clave necesarias; el tránsito usa TLS 1.2+.

Implementación práctica

Cómo se implementa este control en cada arquitectura de referencia:

Una clave gestionada por el cliente en la cuenta de IA generativa cifra toda la cadena de RAG —ingesta, el vector store de OpenSearch Serverless, las sesiones de consulta y las fuentes S3— con TLS en tránsito.

  1. Crea una clave KMS gestionada por el cliente y aplícala al job de ingesta de la base de conocimiento de Bedrock, a la colección de OpenSearch Serverless y a las sesiones de consulta en la cuenta de IA generativa.
    Cuenta de IA generativa AWS KMS Amazon Bedrock OpenSearch Service
  2. Cifra los buckets S3 de fuentes de datos y cualquier secreto de Secrets Manager con la misma clave, y exige TLS 1.2+ en todos los endpoints.
    Cuenta de IA generativa AWS KMS Amazon S3 Secrets Manager
  3. Otorga al rol de servicio de la KB solo los permisos de política de clave que necesita, y mantén la administración de la clave en el equipo de plataforma.
    Cuenta de IA generativa AWS KMS IAM

Cómo validar: La ingesta, el vector store, las sesiones y las fuentes S3 muestran la clave gestionada por el cliente; el rol de la KB tiene solo los permisos de clave necesarios; el tránsito es TLS 1.2+.

Evita: Cifrar el bucket fuente pero dejar el vector store con una clave por defecto. Los embeddings pueden reconstruir el contenido fuente, así que cifra también el vector store con tu propia clave.

OU de IA generativa (multi-cuenta) →

Una clave gestionada por el cliente en la cuenta cifra la ingesta, el vector store, las sesiones y las fuentes S3, con el rol de la KB acotado solo a los permisos de clave que necesita.

  1. Crea una clave KMS dedicada gestionada por el cliente y aplícala al job de ingesta de la base de conocimiento, a la colección de OpenSearch Serverless y a las sesiones de consulta.
    Capa de IA generativa (rol IAM) AWS KMS Amazon Bedrock OpenSearch Service
  2. Cifra los buckets S3 fuente y los secretos de Secrets Manager con la misma clave e impón TLS 1.2+.
    Capa de IA generativa (rol IAM) AWS KMS Amazon S3 Secrets Manager
  3. Acota los permisos de clave del rol de la KB y mantén la administración de la clave separada de los roles en ejecución.
    Capa de aplicación (rol IAM) AWS KMS IAM

Cómo validar: La ingesta, el vector store, las sesiones y las fuentes usan la clave gestionada por el cliente; el rol de la KB tiene permisos de clave mínimos; el tránsito es TLS 1.2+.

Evita: Usar claves por defecto porque el store es 'interno'. Cifra el vector store y las fuentes con una clave gestionada por el cliente que puedas acotar y auditar.

Cuenta única (punto de entrada) →

Amenazas que atiende

  • Fuentes de datos de RAG o embeddings legibles si las claves por defecto o el almacenamiento se comprometen.
  • Contexto sensible recuperado expuesto en tránsito.

Servicios AWS

AWS KMS Amazon Bedrock Knowledge Bases Amazon OpenSearch Serverless Amazon S3

Precios

La CMK conlleva una pequeña tarifa mensual más cargos por solicitud de KMS durante la ingesta y la recuperación. Son menores frente a los costos de embeddings y del vector store; el valor es el control y la auditabilidad de extremo a extremo de la clave que protege tus datos de RAG. Consulta Encryption of knowledge base resources.

Mapeos de frameworks

OWASP GenAI/LLM Top 10 (2026)

  • LLM02 Sensitive Information Disclosure

NIST AI Risk Management Framework (AI 100-1)

  • MANAGE.1 AI risks are prioritized, responded to and managed

AWS Security Hub — AI Security Best Practices

  • Bedrock.1 Amazon Bedrock data sources should be encrypted with customer managed AWS KMS keys

AWS Well-Architected Generative AI Lens (Security)

  • GENSEC01-BP03 Implement least privilege access to data stores

Recursos de aprendizaje

Referencias

  • AWS SRA para IA — Capacidad 3, Protección de datos