Este documento oferece práticas recomendadas para equipes de plataforma, engenheiros de segurança e arquitetos de nuvem que implantam cargas de trabalho de IA no Google Kubernetes Engine (GKE). É possível usar o GKE para proteger a propriedade intelectual (PI) exclusiva, como pesos de modelos, proteger a reputação da marca filtrando conteúdo e melhorar a conformidade regulatória.
Implemente essas práticas recomendadas, além de outras práticas recomendadas de segurança de carga de trabalho do GKE e de IA, como:
- Práticas recomendadas de segurança da IA generativa
- Práticas recomendadas para aumentar a segurança do cluster
Entenda suas responsabilidades de segurança
A postura de segurança das suas cargas de trabalho de IA depende de várias camadas do seu ambiente, como a infraestrutura e os modelos que você usa. Cloud de Confiance by S3NS A tabela a seguir descreve essas camadas, quem é responsável por proteger cada uma delas e as responsabilidades de segurança de cada camada:
| Camada | Descrição | Responsabilidades |
|---|---|---|
| Infraestrutura | A infraestrutura subjacente, como máquinas virtuais (VMs), componentes de rede e hardware de armazenamento em que suas cargas de trabalho de IA são executadas.O Cloud de Confiance é proprietário da infraestrutura e oferece uma base de segurança sólida. | Os administradores de plataforma na sua organização implementam controles para melhorar a segurança nas seguintes áreas:
|
| Modelo | O modelo, as ponderações do modelo, o pipeline de treinamento e as propriedades de segurança. Se você executar modelos treinados ou ajustados, será responsável por proteger a camada de modelo. Se você executar modelos gerenciados de provedores terceirizados (como o Gemini), o provedor será responsável pela segurança do modelo. | Na camada de modelo, o proprietário é responsável pela segurança nas seguintes áreas:
|
| Aplicativo | Os comandos, o código, as instruções do sistema e a experiência do usuário final. Os operadores de aplicativos e administradores de plataforma na sua organização são responsáveis pela segurança na camada de aplicativo. | Na camada de aplicativo, os operadores, desenvolvedores e administradores de plataforma são responsáveis pela segurança nas seguintes áreas:
|
Você aplica controles para proteger as camadas de que é responsável. Os exemplos a seguir mostram tipos comuns de implantação para clientes do GKE e as responsabilidades de segurança correspondentes para essas implantações:
- Você executa um modelo gerenciado, como o Gemini: aplica controles nas camadas de infraestrutura e aplicativo. Mesmo quando você usa um modelo gerenciado com filtros de segurança integrados, ainda é responsável pelas defesas contra injeção de comandos necessárias para proteger a lógica específica do aplicativo.
- Você executa seu próprio modelo: se você executa um modelo ajustado, de código aberto ou treinado, é responsável pela segurança em todas as camadas.
- Você é um provedor de serviços de IA multilocatário: se você fornece serviços de IA aos seus próprios usuários finais executando seu modelo no GKE e expondo endpoints de inferência a vários locatários, você é responsável por controles adicionais. Esses controles multitenant incluem isolamento lógico e físico do locatário (como pools de nós, namespaces e políticas de rede dedicados), limitação de taxa por locatário e criptografia de dados do locatário em repouso usando chaves de criptografia gerenciadas pelo cliente (CMEK) distintas.
Melhorar a segurança na camada de infraestrutura
Na camada de infraestrutura,o Cloud de Confiance e o GKE oferecem uma postura de segurança básica que implementa vários controles de segurança por padrão. Para melhorar a segurança da sua infraestrutura para cargas de trabalho de IA, configure controles de segurança adicionais com base no tipo de cargas de trabalho de IA que você executa e nas metas de segurança específicas que quer alcançar. As seções a seguir descrevem os produtos e serviços que você pode usar para proteger vários componentes da sua infraestrutura de IA.
Proteger nós do GKE
Use os seguintes serviços para proteger dados sensíveis, como cargas de trabalho de inferência que processam comandos e respostas ou cargas de trabalho de treinamento que acessam modelos proprietários:
Criptografar dados sensíveis em uso com comprovação de hardware: execute suas cargas de trabalho de inferência em nós confidenciais do Google Kubernetes Engine, estendendo a criptografia de memória no nível do hardware para aceleradores, incluindo GPUs e TPUs, além de CPUs AMD SEV-SNP ou Intel TDX. Use nós confidenciais do GKE para implantações regulamentadas e cargas de trabalho de inferência sensíveis. Os nós confidenciais do GKE não protegem as cargas de trabalho contra exploits no nível do aplicativo ou usuários autorizados com acesso no nível do nó.
Para provedores cujos clientes têm requisitos de isolamento estritos (como cargas de trabalho soberanas), o GKE Hypercluster oferece atestado criptográfico para que nem mesmo o operador da infraestrutura subjacente,Cloud de Confiance, possa inspecionar os dados do locatário.
Reduza o risco de representação de nós: execute cargas de trabalho em nós protegidos do GKE, que fornecem integridade verificável do nó e declarações de identidade. Use nós protegidos do GKE para todos os tipos de carga de trabalho.
Elimine o uso de credenciais estáticas para cargas de trabalho: use a federação de identidade da carga de trabalho para GKE para acessar serviços do Cloud de Confiance código do aplicativo usando credenciais federadas de curta duração e evite que metadados não essenciais do Compute Engine sejam expostos a aplicativos. Use a federação de identidade da carga de trabalho para o GKE em todos os clusters de produção, principalmente quando precisar acessar dados que estão em serviços fora do cluster.
Implementar controles de rede
Você pode usar os seguintes recursos e produtos para melhorar a segurança de rede das cargas de trabalho de IA:
Usar intervalos de endereços IP de alias: os clusters nativos de VPC usam intervalos de endereços IP de alias para rotear o tráfego entre pods em vez de usar rotas estáticas na rede VPC. Sempre use clusters nativos de VPC.
Restrinja o acesso à rede aos nós: use nós particulares para impedir o tráfego entre os nós e a Internet pública por padrão. Os endpoints de inferência que precisam ser expostos devem ter um serviço gerenciado, como o Google Cloud Armor, entre os endpoints e a Internet.
Negar o tráfego no cluster por padrão: use as políticas de rede do Kubernetes para negar o tráfego entre pods, entre namespaces e o tráfego de saída para a Internet. Permita o tráfego de rede apenas para aplicativos que exigem acesso específico.
Adicionar proteção de borda aos endpoints da Internet: use o Google Cloud Armor para proteger os endpoints de inferência expostos à Internet implementando limitação de taxa, proteção contra DDoS, controle de acesso baseado em localização geográfica e mitigação de ataques da camada 7. Se você tiver APIs de IA voltadas ao público, use o Cloud Armor para lidar com ataques volumétricos e na camada de aplicativo antes que eles atinjam sua infraestrutura de computação. Combine o Cloud Armor com nós particulares para otimizar a segurança dos endpoints de inferência.
Evite a exfiltração de dados durante um ataque: use o VPC Service Controls para criar um perímetro de segurança em torno dos seus recursos do Cloud de Confiance . Mesmo que as credenciais sejam comprometidas, os invasores não podem extrair dados do perímetro. Use o VPC Service Controls para cargas de trabalho regulamentadas.
Gerenciar identidade e acesso
Para identificar usuários e controlar o acesso a clusters e cargas de trabalho, use os seguintes mecanismos de autorização:
Controle o acesso aos Cloud de Confiance recursos: use as políticas de acesso do Cloud de Confiance Identity and Access Management (IAM) para controlar quais principais podem interagir com clusters e nós do GKE.
Controlar o acesso aos recursos do Kubernetes em clusters: use políticas de controle de acesso baseado em papéis (RBAC) do Kubernetes para controlar o que vários principais podem fazer com os recursos da API Kubernetes em cada cluster.
Configure o acesso de confiança zero a endpoints de inferência e interfaces de administrador: use um serviço como o Chrome Enterprise Premium para configurar o acesso do usuário com base na identidade e na postura do dispositivo, em vez da topologia de rede.
Gerenciar chaves e secrets
Mantenha todas as chaves de criptografia e dados sensíveis, como chaves de API e credenciais, fora do cluster. Os seguintes produtos podem ajudar você a armazenar esses recursos:
Gerenciar chaves de criptografia: use o Cloud Key Management Service para gerenciar todas as chaves de criptografia. Você também pode criar chaves de criptografia gerenciadas pelo cliente (CMEKs) no Cloud KMS para criptografar dados com chaves controladas por você, o que geralmente é um requisito em setores regulamentados.
Armazenar dados sensíveis de aplicativos: use o Secret Manager para armazenar dados sensíveis usados por cargas de trabalho, como secrets de aplicativos, chaves de API e credenciais. Para ler esses dados dos pods, use a federação de identidade da carga de trabalho para GKE e conceda a identidades de carga de trabalho específicas acesso apenas aos recursos necessários para os pods.
Melhorar a segurança da cadeia de suprimentos
Os seguintes serviços do Cloud de Confiance podem ajudar você a melhorar a segurança em toda a cadeia de suprimentos de software:
- Verificar vulnerabilidades de imagens de contêiner: armazene suas imagens de contêiner em repositórios do Artifact Registry que têm a verificação de vulnerabilidades ativada por padrão. Ative a detecção contínua de CVEs em todas as imagens do seu registro.
Permitir que apenas imagens verificadas cheguem à produção: use a autorização binária para aplicar a autorização com base em políticas de assinaturas de imagens de contêiner no momento da implantação. Somente imagens atestadas chegam à produção.
Configure a detecção de segurança e o gerenciamento de postura: use o Security Command Center para ver descobertas de detecção de ameaças e gerenciamento de postura específicas da IA, como endpoints da Plataforma de Agentes do Gemini Enterprise mal configurados ou buckets de dados de treinamento expostos. O Security Command Center integra essas descobertas de IA com as vulnerabilidades do Artifact Registry e a análise do IAM para oferecer uma visão abrangente da sua frota.
Rastrear artefatos de IA: use ferramentas de lista de materiais criadas para cargas de trabalho de IA do Kubernetes, como
k8s-aibom, para gerar inventários abrangentes de modelos, conjuntos de dados e frameworks.
Melhorar a segurança na camada de modelo
Se você executar modelos treinados ou ajustados ou modelos de código aberto que você configurou, configure vários controles para melhorar a segurança do modelo. Se você executa modelos gerenciados de provedores terceirizados, essa camada não se aplica a você. As seções a seguir descrevem o que você pode fazer para melhorar a integridade, a confidencialidade e a segurança dos seus modelos.
Melhorar a integridade do modelo
Melhore a integridade dos seus modelos para encontrar evidências de adulteração antes que o modelo fique acessível em um endpoint de inferência. As diretrizes a seguir podem ajudar você a melhorar a integridade do modelo:
- Assine os artefatos do modelo: assine criptograficamente os pesos do modelo antes de publicá-los no registro. Ao implantar o modelo, verifique a assinatura usando atestados de autorização binária. A assinatura e a verificação dos artefatos do modelo ajudam a identificar se eles foram adulterados durante o armazenamento ou o trânsito e oferecem uma cadeia de custódia verificável para modelos de produção.
- Encontrar modificações pós-treinamento: o Activation Model Scanner (AMS) de código aberto detecta modelos que foram modificados após o treinamento (por exemplo, para adicionar backdoors, perturbações de peso ou ajustes refinados não autorizados) analisando as assinaturas de ativação do modelo em relação a um valor de referência. Execute um scanner como o AMS como parte do pipeline de CI/CD antes de publicar seus modelos em registros de produção. Para modelos de alto valor ou regulamentados, programe verificações periódicas do AMS em relação a artefatos de produção para detectar adulterações que ocorram após a publicação inicial.
Proteger a confidencialidade do modelo
Se você tiver pesos de modelos sensíveis, como ajustes refinados proprietários, modelos treinados com dados regulamentados ou propriedade intelectual competitiva, use as seguintes diretrizes para proteger os pesos:
Criptografar pesos em repouso: armazene pesos em armazenamento de objetos criptografados, como em buckets do Cloud Storage, com acesso restrito do IAM. Por padrão, o Cloud Storage criptografa o conteúdo do cliente em repouso. Você pode usar CMEKs para criptografar os dados com chaves controladas por você, o que geralmente é um requisito em setores regulamentados. Para mais informações, consulte Opções de criptografia de dados na documentação do Cloud Storage.
Proteja os pesos em uso: execute modelos em nós confidenciais do GKE para garantir que os pesos sejam criptografados na memória durante a inferência. Os nós confidenciais do GKE ajudam a proteger sua propriedade intelectual contra comprometimento no nível do hipervisor e acesso não autorizado pelo operador de infraestrutura. Os nós confidenciais do GKE não protegem contra exploits no nível do aplicativo ou usuários autorizados com acesso no nível do nó.
Controlar todo o acesso aos pesos: registre todo o acesso aos artefatos do modelo no armazenamento. Use políticas de acesso do IAM para restringir o acesso a contas de serviço específicas e pessoas que têm uma necessidade de acesso documentada. Restrinja o acesso administrativo ao cluster, incluindo acesso ao shell de contêineres, acesso SSH a VMs de nós ou depuração no nível do nó, usando políticas de RBAC do Kubernetes e o Chrome Enterprise Premium. Essas medidas podem ajudar a proteger os pesos do modelo de usuários com acesso no nível do nó, o que não é coberto pelos Confidential GKE Nodes.
Melhorar as propriedades de segurança do modelo
É possível implementar várias configurações de segurança para modelos durante o treinamento. Se você estiver treinando ou ajustando seu próprio modelo, invista em um treinamento de segurança relevante para o caso de uso do modelo. As propriedades de segurança dos modelos incluem comportamento de recusa, treinamento de alinhamento e resistência a jailbreaks. Se você usar um modelo pré-treinado, escolha um que tenha propriedades de segurança que correspondam aos requisitos do seu aplicativo.
Os desenvolvedores e operadores de aplicativos podem implementar vários controles na camada de aplicativo para melhorar a segurança em áreas que o modelo não pode cobrir.
Melhorar a segurança na camada de aplicativo
É na camada de aplicativo que os operadores e desenvolvedores têm mais controle sobre as configurações de segurança específicas da IA. Na camada de aplicativo, é possível implementar controles de segurança que protegem dados, criam solicitações bem formadas e protegem comandos e respostas. Esses controles geralmente são úteis para cargas de trabalho de inferência, que processam comandos, sessões e respostas do usuário. As seções a seguir descrevem vários controles, produtos e serviços que podem ajudar você a alcançar metas de segurança específicas na camada de aplicativo.
Defenda-se contra ameaças na camada de conteúdo
Inspecione todos os comandos e respostas em busca de problemas de segurança, como injeção de comandos, exposição de dados sensíveis e conteúdo nocivo. Como os nós do GKE são projetados para não ter acesso ao conteúdo, implante o Model Armor entre o aplicativo e o endpoint de inferência. O Model Armor tem princípios de tratamento e armazenamento de dados específicos projetados para melhorar a privacidade dos seus dados durante a verificação.
Proteger comandos do sistema
Filtre as saídas para evitar vazamento de comandos e configure a detecção de exfiltração de dados do Model Armor para identificar padrões de extração. Para instruções altamente sensíveis, processe as instruções em uma invocação que não retorne texto ao usuário.
Gerenciar sessões e roteamento
Ao expor endpoints de inferência para usuários finais, use o gateway de inferência do GKE. O Inference Gateway estende a API Gateway para rotear o tráfego com base em métricas e dados específicos para cargas de trabalho de inferência de IA. É possível fazer escalonamento automático de cargas de trabalho para atender à demanda e integrar com o Model Armor e o Apigee para filtragem de conteúdo, observabilidade no nível da sessão e aplicação de cotas.
Melhorar a segurança dos agentes de IA
Se a carga de trabalho de IA for um agente, você precisará de controles adicionais na camada de aplicativo, como:
- Restrinja o acesso às APIs Cloud de Confiance :use a federação de identidade da carga de trabalho para GKE com políticas de acesso do IAM para limitar quais APIs os pods de carga de trabalho do agente podem acessar. Use uma conta de serviço do Kubernetes dedicada para cada agente e conceda ao principal apenas as permissões do IAM necessárias para a carga de trabalho.
- Executar execução de código ou ferramentas não confiáveis em sandboxes: execute agentes que executam código gerado ou interagem com ferramentas de terceiros não verificadas em ambientes de sandbox usando o Agent Sandbox. O Agent Sandbox usa um mecanismo de isolamento, como o GKE Sandbox ou o Kata Containers, para proteger contra escapes de contêiner.
Configurar a observabilidade e a resposta a incidentes
Colete registros e monitore várias métricas para identificar possíveis ataques com antecedência e limitar o impacto de exploits. As seções a seguir fornecem diretrizes que podem ajudar você a melhorar a detecção e a resposta.
Coletar registros e métricas
Para identificar ameaças o mais rápido possível, implemente o máximo possível das seguintes práticas recomendadas de observabilidade:
- Colete registros do GKE.
- Ative os registros de auditoria de acesso a dados para operações sensíveis, como o uso de chaves do KMS.
- Não registre conteúdo de solicitação ou conclusão, a menos que sua política permita isso explicitamente. Se você coletar dados de solicitação e resposta multimodais (prévia), exclua ou restrinja o acesso aos dados armazenados com base nas políticas de segurança.
- Colete métricas importantes para seus SREs.
- Configure o monitoramento automático de aplicativos para tipos específicos de servidores de modelos de IA.
- Agregue registros no Cloud Logging ou na sua própria plataforma de gerenciamento de eventos e informações de segurança (SIEM).
- Use métricas com base em registros para criar métricas com base no conteúdo dos registros.
Detectar ameaças específicas de IA
Configure alertas no Logging e no Cloud Monitoring para detectar várias ameaças específicas de IA. As políticas de alertas específicas que você configura dependem dos tipos de registros coletados e dos requisitos da sua organização. Para mais informações sobre as políticas de alertas disponíveis, consulte Comparação das opções de alertas. Configure alertas para ameaças específicas de IA, como:
| Ameaças e indicadores específicos de IA | |
|---|---|
| Injeção de comando | Registros do Model Armor para higienização ou negação de comandos |
| Extração de comandos do sistema | Model Armor e anomalias de ocorrência em cache |
| Exposição de dados sensíveis | Registros de resposta do Model Armor |
| Abuso de custo de inferência | Uso de tokens no nível da sessão com base nas métricas do Inference Gateway |
| Manipulação de sessão | Velocidade de novas sessões por locatário das métricas do Inference Gateway |
| Impressão digital do modelo | Padrões de sondagem de recursos |
| Canal lateral de tempo | Mitigação arquitetônica (particionamento de cache) |
Estabelecer um processo de resposta a incidentes
A resposta a vários incidentes depende da estrutura organizacional e dos requisitos de segurança. As diretrizes a seguir descrevem o que fazer quando você detecta tipos específicos de ameaças às suas cargas de trabalho de IA:
Detecções de conteúdo no Model Armor: bloqueie a solicitação, documente o evento e configure um alerta para notificar você se a taxa exceder um limite. Configure a limitação de taxa para usuários que violaram as políticas várias vezes.
Detecções de inferência: limite os locatários usando o gateway de inferência. Encerre sessões por abuso confirmado.
Correlação entre camadas:uma detecção do Model Armor mais um padrão de abuso de token indicam abuso coordenado. Defina regras de correlação e identifique um limite de confiança abaixo do qual o risco de um alerta falso positivo é baixo. Automatizar o encerramento de sessões que cruzam esse limite.
Implementar a segurança em todo o ciclo de vida de implantação
Otimize suas implantações de IA para segurança durante todo o ciclo de vida da implantação. Durante estágios específicos do ciclo de vida, implemente controles que protejam uma ou mais camadas. As seções a seguir fornecem diretrizes para cada etapa do ciclo de vida.
Implantar infraestrutura
Ao criar ou projetar a infraestrutura que executa suas cargas de trabalho de IA, implemente o máximo possível dos seguintes controles:
| Categoria | |
|---|---|
| Nós do GKE |
|
| Rede |
|
| Gerenciamento de identidade e acesso |
|
| Gerenciamento de dados sensíveis |
|
| Observabilidade |
|
Operar cargas de trabalho e infraestrutura
Ao implantar cargas de trabalho de IA e executar um sistema de produção, implemente o máximo possível dos seguintes controles:
| Categoria | |
|---|---|
| Segurança de cargas de trabalho |
|
| Rede |
|
| Proteção de dados sensíveis | Use a CMEK para criptografar dados com suas próprias chaves em ambientes regulamentados. |
| Observabilidade |
|
Controlar implantações em grande escala
À medida que sua organização cresce, implemente os seguintes controles para automatizar o gerenciamento de segurança:
- Configure proteções no nível da organização usando o serviço de políticas da organização.
- Aplicar a política de tempo de admissão usando webhooks de admissão do Kubernetes.
- Automatize a primeira resposta para detecções de alta confiança.
- Estabelecer correlação de SIEM entre camadas e comparativos comportamentais por locatário.
Resumo das práticas recomendadas
A tabela a seguir resume as práticas recomendadas neste documento:
| Tópico | |
|---|---|
| Melhorar a segurança na camada de infraestrutura | Proteja os nós do GKE, implemente controles de rede, gerencie a identidade e o acesso, gerencie chaves e secrets e melhore a segurança da cadeia de suprimentos. |
| Melhorar a segurança na camada de modelo | Melhorar a integridade, proteger a confidencialidade e aprimorar as propriedades de segurança do modelo. |
| Melhorar a segurança na camada de aplicativo | Defenda-se contra ameaças na camada de conteúdo, proteja os comandos do sistema, gerencie sessões e roteamento e melhore a segurança dos agentes de IA. |
| Configurar a observabilidade e a resposta a incidentes | Colete registros e métricas, detecte ameaças específicas de IA e estabeleça um processo de resposta a incidentes. |
| Implementar a segurança em todo o ciclo de vida de implantação | Implante infraestrutura, opere cargas de trabalho e infraestrutura e governe implantações em grande escala. |
A seguir
- Práticas recomendadas de segurança da IA generativa
- Práticas recomendadas para aumentar a segurança do cluster