AI Security Maturity Model·AWS v1.0.0

Arraste para explorar · faça pinça para ampliar

Avançada Governança e conformidadeCamada de defesa em profundidade: Aplicação de IA Capacidade 1 · Inferência de modelosCaso de uso: IA que responde 👤 ClienteModelo de Responsabilidade Compartilhada da AWS: quem implementa e opera este controle. Cliente = é seu; AWS = a AWS opera e você o herda; Compartilhada = ambos têm obrigações.

c1.11 Isole as cargas de IA entre contas com guardrails

Separe desenvolvimento, inferência e treinamento em contas/OUs distintas com SCPs e linhas de base do Config, para conter o raio de impacto e manter governança consistente.

Fundacional
Aprimorada
Avançada
Esforço: Alto Impacto: Alto Scopes de IA generativaDa AWS Generative AI Security Scoping Matrix.: 3 · Modelos pré-treinados

Guia de implementação

Como implementar na AWS

Estabeleça uma OU de IA generativa com contas separadas de desenvolvimento, inferência e (onde usado) treinamento. Aplique SCPs (por exemplo, negar ações de treinamento em contas de inferência), aplique conformance packs do AWS Config para uma linha de base comum e agregue os logs a uma conta central de log-archive.

Contenha o raio de impacto com limites de conta

O limite de isolamento mais forte na AWS é a conta. Separar desenvolvimento, inferência/produção e treinamento/personalização de modelos em contas distintas (agrupadas em OUs) significa que um comprometimento ou uma configuração incorreta em uma não alcança as demais. O AWS Organizations então permite definir políticas de controle de serviço (SCPs) — barreiras de toda a organização que limitam as permissões máximas que qualquer principal de uma conta pode ter, por mais permissiva que seja sua política de IAM.

Uma SCP não concede acesso; ela define o teto. As permissões do dia a dia continuam sendo concedidas com o IAM.

Restrinja quais modelos podem ser usados em toda a organização

Uma barreira comum é negar o acesso a qualquer modelo de fundação, exceto os que sua organização aprovou e avaliou quanto ao risco. O padrão documentado pela AWS usa NotResource para que tudo, exceto os ARNs de modelo listados, seja negado:

{
  "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"
      ]
    }
  ]
}

Mantenha a inferência dentro de regiões aprovadas

Combine a restrição de modelos com uma barreira regional para que o Bedrock só possa ser chamado nas regiões que você aprovou por motivos de residência de dados:

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

Adicione uma base de referência com o Config

As SCPs definem o teto de permissões; o AWS Config confirma a realidade. Implante uma base de referência do Config (idealmente por meio de um conformance pack em toda a OU) para detectar desvios — um recurso do Bedrock criado sem criptografia, o registro de invocação desativado ou um guardrail removido — e alertar ou remediar automaticamente.

Nota: as SCPs nunca se aplicam à conta de gerenciamento e apenas restringem; não podem conceder. Teste uma SCP nova em uma única OU antes de implantá-la em toda a organização, pois um Deny amplo demais pode bloquear cargas de trabalho legítimas.

Critérios de aceitação

As cargas de IA rodam em contas dedicadas sob uma OU com SCPs; as linhas de base do Config aplicam em toda a organização; os logs são agregados de forma central.

Implementação prática

Como este controle é implementado em cada arquitetura de referência:

Uma OU de IA generativa dedicada com contas separadas, guardrails por SCP e linhas de base do Config em toda a org contém o raio de impacto e aplica uma postura consistente.

  1. Crie a OU de IA generativa com contas separadas de desenvolvimento, inferência e (onde usado) treinamento sob o AWS Organizations / Control Tower.
    OU de IA generativa AWS Organizations Control Tower
  2. Anexe SCPs na OU que imponham limites (por exemplo, negar ações de treinamento em contas de inferência, negar a desativação do registro/guardrails).
    OU de IA generativa (guardrail) AWS Organizations
  3. Aplique conformance packs do AWS Config em toda a org para uma linha de base comum e agregue todos os logs à conta central de Log archive.
    Ferramentas de segurança → Log archive AWS Config Amazon S3

Como validar: As cargas de IA rodam em contas dedicadas sob a OU; uma ação negada por SCP (por exemplo, treinar em uma conta de inferência) falha; as linhas de base do Config aplicam em toda a org; os logs são agregados de forma central.

Evite: Separar apenas por IAM dentro de uma conta e chamar isso de isolamento. Os limites de conta mais os SCPs são o que de fato contém o raio de impacto; use-os para IA em produção.

OU de IA generativa (multi-conta) →

Este controle é onde a variante de conta única chega ao seu limite: aproxime o isolamento com IAM e separação de ambientes, e trate a graduação para a OU como a solução real.

  1. Separe as cargas de desenvolvimento e produção com papéis IAM, tags e (idealmente) VPCs distintas dentro da conta, já que aqui não há isolamento por SCP no nível de conta.
    Camada de aplicação (papel IAM) / Camada de IA generativa (papel IAM) IAM Amazon VPC
  2. Use regras do AWS Config na conta para uma linha de base consistente e permission boundaries para limitar o que qualquer papel pode fazer.
    Registro na conta AWS Config IAM
  3. Planeje e agende a graduação para uma OU de IA generativa multi-conta antes que a escala ou uma revisão de segurança o exijam; esta é a razão principal para graduar-se.
    OU de IA generativa (estado-alvo) AWS Organizations Control Tower

Como validar: Dev e prod estão separados por papéis/tags/VPCs; há regras do Config e permission boundaries; existe um plano documentado de graduação para a OU.

Evite: Tratar a conta única como lar permanente de IA em produção. A separação lógica não iguala o isolamento por SCP no nível de conta; gradue-se antes de a carga se tornar crítica.

Conta única (ponto de entrada) →

Ameaças atendidas

  • Um erro de desenvolvimento ou um dataset envenenado afetando a produção.
  • Linhas de base de segurança inconsistentes entre os ambientes de IA.

Serviços AWS

AWS Organizations AWS Control Tower AWS Config

Preços

O AWS Organizations e as SCPs são gratuitos. O AWS Config cobra por item de configuração registrado e por avaliação de conformance pack, então restrinja o gravador aos tipos de recurso que você realmente precisa governar. Consulte Example SCPs for Amazon Bedrock.

Mapeamentos 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 aprendizado

Referências

  • AWS SRA para IA — Capacidade 1, Arquitetura multi-conta