AI Security Maturity Model·AWS v1.0.0

Arrastra para explorar · pellizca para ampliar

Avanzada Gobernanza y cumplimientoCapa de defensa en profundidad: Aplicación de IA Capacidad 1 · Inferencia de modelosCaso de uso: IA que responde 👤 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.

c1.11 Aísla las cargas de IA entre cuentas con guardrails

Separa desarrollo, inferencia y entrenamiento en cuentas/OU distintas con SCPs y líneas base de Config, para contener el radio de impacto y mantener una gobernanza consistente.

Fundacional
Mejorada
Avanzada
Esfuerzo: Alto Impacto: Alto Scopes de IA generativaDe la AWS Generative AI Security Scoping Matrix.: 3 · Modelos preentrenados

Guía de implementación

Cómo implementarlo en AWS

Establece una OU de IA generativa con cuentas separadas de desarrollo, inferencia y (donde se use) entrenamiento. Aplica SCPs (p. ej. denegar acciones de entrenamiento en cuentas de inferencia), aplica conformance packs de AWS Config para una línea base común y agrega los logs a una cuenta central de log-archive.

Contén el radio de impacto con límites de cuenta

El límite de aislamiento más fuerte en AWS es la cuenta. Separar desarrollo, inferencia/producción y entrenamiento/personalización de modelos en cuentas distintas (agrupadas en OUs) significa que un compromiso o una mala configuración en una no alcanza a las demás. AWS Organizations te permite entonces establecer políticas de control de servicios (SCP): barreras de toda la organización que limitan los permisos máximos que puede tener cualquier principal de una cuenta, por muy permisiva que sea su política de IAM.

Una SCP no concede acceso; establece el techo. Los permisos del día a día se conceden con IAM.

Restringe qué modelos pueden usarse en toda la organización

Una barrera común es denegar el acceso a cualquier modelo fundacional salvo los que tu organización ha aprobado y evaluado en riesgo. El patrón documentado por AWS usa NotResource para que todo, excepto los ARN de modelo listados, quede denegado:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUnapprovedBedrockModels",
      "Effect": "Deny",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream"
      ],
      "NotResource": [
        "arn:aws:bedrock:*::foundation-model/anthropic.claude-3-5-sonnet-20240620-v1:0",
        "arn:aws:bedrock:*::foundation-model/amazon.titan-embed-text-v2:0"
      ]
    }
  ]
}

Mantén la inferencia dentro de regiones aprobadas

Combina la restricción de modelos con una barrera regional para que Bedrock solo pueda llamarse en las regiones que has aprobado por motivos de residencia de datos:

{
  "Sid": "RestrictBedrockToApprovedRegions",
  "Effect": "Deny",
  "Action": "bedrock:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:RequestedRegion": ["us-east-1", "us-west-2"]
    }
  }
}

Añade una base de referencia con Config

Las SCP fijan el techo de permisos; AWS Config confirma la realidad. Despliega una base de referencia de Config (idealmente mediante un conformance pack en toda la OU) para detectar la deriva —un recurso de Bedrock creado sin cifrado, el registro de invocación desactivado o un guardrail eliminado— y alertar o remediar automáticamente.

Nota: las SCP nunca se aplican a la cuenta de gestión, y solo restringen; no pueden conceder. Prueba una SCP nueva en una sola OU antes de desplegarla en toda la organización, ya que un Deny demasiado amplio puede dejar fuera cargas de trabajo legítimas.

Criterios de aceptación

Las cargas de IA corren en cuentas dedicadas bajo una OU con SCPs; las líneas base de Config aplican en toda la org; los logs se agregan de forma central.

Implementación práctica

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

Una OU de IA generativa dedicada con cuentas separadas, guardrails por SCP y líneas base de Config en toda la org contiene el radio de impacto y aplica una postura consistente.

  1. Crea la OU de IA generativa con cuentas separadas de desarrollo, inferencia y (donde se use) entrenamiento bajo AWS Organizations / Control Tower.
    OU de IA generativa AWS Organizations Control Tower
  2. Adjunta SCPs en la OU que impongan límites (p. ej. denegar acciones de entrenamiento en cuentas de inferencia, denegar la desactivación del registro/guardrails).
    OU de IA generativa (guardrail) AWS Organizations
  3. Aplica conformance packs de AWS Config en toda la org para una línea base común y agrega todos los logs a la cuenta central de Log archive.
    Herramientas de seguridad → Log archive AWS Config Amazon S3

Cómo validar: Las cargas de IA corren en cuentas dedicadas bajo la OU; una acción denegada por SCP (p. ej. entrenar en una cuenta de inferencia) falla; las líneas base de Config aplican en toda la org; los logs se agregan de forma central.

Evita: Separar solo por IAM dentro de una cuenta y llamarlo aislamiento. Los límites de cuenta más los SCPs son lo que de verdad contiene el radio de impacto; úsalos para IA en producción.

OU de IA generativa (multi-cuenta) →

Este control es donde la variante de cuenta única llega a su límite: aproxima el aislamiento con IAM y separación de entornos, y trata la graduación a la OU como la solución real.

  1. Separa las cargas de desarrollo y producción con roles IAM, tags y (idealmente) VPCs distintas dentro de la cuenta, ya que aquí no hay aislamiento por SCP a nivel de cuenta.
    Capa de aplicación (rol IAM) / Capa de IA generativa (rol IAM) IAM Amazon VPC
  2. Usa reglas de AWS Config en la cuenta para una línea base consistente y permission boundaries para acotar lo que cualquier rol puede hacer.
    Registro en la cuenta AWS Config IAM
  3. Planifica y agenda la graduación a una OU de IA generativa multi-cuenta antes de que la escala o una revisión de seguridad lo obliguen; esta es la razón principal para graduarse.
    OU de IA generativa (estado objetivo) AWS Organizations Control Tower

Cómo validar: Dev y prod están separados por roles/tags/VPCs; hay reglas de Config y permission boundaries; existe un plan documentado de graduación a la OU.

Evita: Tratar la cuenta única como hogar permanente de IA en producción. La separación lógica no iguala el aislamiento por SCP a nivel de cuenta; gradúate antes de que la carga se vuelva crítica.

Cuenta única (punto de entrada) →

Amenazas que atiende

  • Un error de desarrollo o un dataset envenenado que afecta producción.
  • Líneas base de seguridad inconsistentes entre los entornos de IA.

Servicios AWS

AWS Organizations AWS Control Tower AWS Config

Precios

AWS Organizations y las SCP son gratuitas. AWS Config factura por elemento de configuración registrado y por evaluación de conformance pack, así que acota el grabador a los tipos de recurso que realmente necesitas gobernar. Consulta Example SCPs for Amazon Bedrock.

Mapeos de frameworks

OWASP GenAI/LLM Top 10 (2026)

  • LLM05 Data and Model Poisoning

NIST AI Risk Management Framework (AI 100-1)

  • GOVERN.1 Policies, processes, procedures and accountability structures
  • GOVERN.4 Organizational culture that prioritizes risk awareness
  • MANAGE.1 AI risks are prioritized, responded to and managed

AWS Well-Architected Generative AI Lens (Security)

  • GENSEC03-BP01 Implement control plane and data access monitoring

Recursos de aprendizaje

Referencias

  • AWS SRA para IA — Capacidad 1, Arquitectura multi-cuenta