Capítulo 12 — Sistemas operacionais | Engenharia Segurança de IA e aprendizado de máquina

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 12 publicada. Mapa, exemplo, EX034.

flowchart TD
  N0["12.1 Processos e privilégios"]
  N1["12.2 Mecanismos de isolamento"]
  N2["12.4 Segredos e permissões de arquivos"]
  N3["12.5 Logs"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX034"]

Desenho lógico

flowchart LR
  N0["12.1 Processos e privilégios"]
  N1["12.2 Mecanismos de isolamento"]
  N2["12.4 Segredos e permissões de arquivos"]
  N3["12.5 Logs"]
  N4["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX034"]

[12.1 Processos e privilégios]
    |
    v
[12.2 Mecanismos de isolamento]
    |
    v
[12.4 Segredos e permissões de arquivos]
    |
    v
[12.5 Logs]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX034]

Objetivos de aprendizagem

Você vai (1) explicar processos, usuários, permissões e isolamento; (2) colocar em sandbox os componentes que executam ações geradas pelo modelo; (3) configurar o menor privilégio para processos que servem modelos; e (4) coletar logs do sistema operacional úteis para investigar incidentes de IA.

12.1 Processos e privilégios

O sistema operacional executa programas como processos com uma identidade (usuário, grupos) e impõe permissões sobre arquivos, dispositivos e sockets de rede. Um servidor de modelo deve rodar como um usuário dedicado sem privilégios, com acesso somente de leitura a seus pesos e sem acesso de escrita aos diretórios de código. Com essas configurações, um bug ou uma instrução injetada que tome o processo do servidor consegue ler os pesos que ele já serve, mas não consegue substituí-los, mudar o código do servidor nem ler arquivos de outros usuários. Rodar como root remove todas essas barreiras de uma vez, e é por isso que os revisores conferem primeiro a identidade do processo.

12.2 Mecanismos de isolamento

Contêineres (namespaces e control groups no Linux), máquinas virtuais e filtros de chamadas de sistema (seccomp) isolam processos. Quando um agente de IA pode executar código — uma ferramenta de "interpretador de código" —, esse código precisa rodar numa sandbox sem rede, com sistema de arquivos temporário, limites de CPU e de memória e um limite de tempo. Trate toda string de código produzida por um modelo como não confiável, porque a injeção de prompt pode controlá-la. Contêineres compartilham o kernel do host, então uma falha no kernel pode permitir que o código escape; máquinas virtuais acrescentam uma fronteira mais forte, a um custo maior. Para código gerado pelo modelo, que pode ser qualquer coisa, Sam prefere uma máquina virtual dedicada ou uma sandbox endurecida com filtragem de chamadas de sistema, e descarta o ambiente depois de cada execução.

12.3 Limites de recursos

Control groups limitam a CPU, a memória e a fatia de GPU; sem eles, uma requisição grande demais pode deixar as outras sem recursos. Essa é a parte, no nível do sistema operacional, da defesa contra o consumo ilimitado. Os limites precisam ser definidos a partir de medições. Sam traça o perfil das requisições normais para descobrir suas necessidades de memória e de tempo e depois define limites com alguma folga. Uma requisição que atinge um limite é interrompida e registrada, então um padrão de requisições grandes demais fica visível. Os limites também protegem o host: um worker de inferência que fica sem memória, sem limite, pode derrubar consigo outros serviços da mesma máquina, transformando uma requisição ruim numa indisponibilidade mais ampla.

12.4 Segredos e permissões de arquivos

Servidores de modelo frequentemente precisam de credenciais — para um banco de dados vetorial, uma API de ferramenta ou um registro. Guarde-as no gerenciador de segredos da plataforma ou em arquivos legíveis apenas pelo usuário do serviço, nunca em prompts, despejos de variáveis de ambiente ou imagens compartilhadas entre equipes. Um modelo pode ser induzido a revelar qualquer coisa que esteja em sua janela de contexto; o OWASP LLM 2025 lista o vazamento do prompt de sistema (LLM07) em parte porque desenvolvedores colocam segredos ali. Mantenha as credenciais fora do alcance do modelo e dê a cada ferramenta sua própria credencial de escopo restrito.

12.5 Logs

Os logs do sistema (autenticação, inícios de processos, auditoria de acesso a arquivos) complementam os logs da aplicação. Em incidentes de IA, correlacione o ID da requisição do modelo com os eventos do sistema operacional: uma chamada de ferramenta fez um processo iniciar ou um arquivo mudar? Um identificador de requisição compartilhado é o elo. O serviço do modelo o grava com cada prompt e cada chamada de ferramenta, os serviços de ferramentas o incluem em seus próprios logs e a sandbox o registra com cada processo que inicia. Numa investigação, uma única busca mostra então a cadeia completa, do boletim que trazia uma instrução até o processo que tentou executá-la. Os relógios precisam estar sincronizados, ou os eventos de hosts diferentes não poderão ser ordenados.

12.6 Exemplo resolvido (caso sintético da NRS)

O Wrench ganhou uma ferramenta "calculate" que executa pequenos trechos de Python para cálculos de torque e desgaste. Sam a executou num contêiner sem rede, com raiz somente de leitura, limite de memória de 64 MB, limite de CPU de 2 segundos e um perfil seccomp. Um boletim de teste sintético contendo uma instrução para "calcular" algo que abria um socket de rede falhou de forma segura e foi registrado. Várias camadas estavam no caminho: não havia rede à qual se conectar, o perfil seccomp pode recusar de imediato chamadas de socket e o log registrou o identificador da requisição, de modo que o boletim de origem pudesse ser rastreado. Sam mantém o boletim como teste de regressão, para que mudanças futuras na sandbox sejam conferidas contra ele.

12.7 Erros e limites

Três erros são comuns: servidores de modelo rodando como root; ferramentas de código com acesso à rede; e nenhum limite de recursos nos workers de inferência. Servidores de modelo como root transformam qualquer bug do servidor em controle total do host. Ferramentas de código com acesso à rede deixam instruções injetadas enviar dados para qualquer lugar. Workers de inferência sem limites deixam uma única requisição esgotar as demais. Cada erro é fácil de encontrar com uma verificação simples: o usuário do processo, uma tentativa de conexão de dentro da sandbox e uma requisição deliberadamente grande demais em homologação, por isso Sam executa as três antes de cada liberação.

Exercícios

EX034 — Especificação da sandbox. Escreva seis restrições para uma ferramenta de execução de código. Rubrica: 3 = seis entre sem rede, sistema de arquivos somente de leitura, diretório temporário, limites de CPU/memória/tempo, filtro de chamadas de sistema, usuário sem privilégios; 2 = quatro; 1 = duas; 0 = nenhuma.
EX035 — Menor privilégio. Liste três permissões que o processo do servidor de modelo não deve ter. Rubrica: 3 = escrita no código/pesos, root, acesso a dados de treinamento/segredos, rede irrestrita; 2 = duas; 1 = uma; 0 = nenhuma.
EX036 — Correlação. Por que correlacionar os IDs de requisição do modelo com os logs do sistema operacional? Rubrica: 3 = vincular decisões do modelo a efeitos colaterais para a investigação; 2 = parcial; 1 = vago; 0 = errado.

Síntese

O isolamento do sistema operacional transforma "o modelo pode ser manipulado" em "um modelo manipulado pouco pode fazer". Menor privilégio, sandboxes, limites de recursos e logs correlacionados são as ferramentas.

Continue estudando — capítulo 12 de 50

← Capítulo 11 (rascunho) · Índice de capítulos do curso · Capítulo 13 (rascunho) →