Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["11.1 Processos e permissões"]
N1["11.2 Isolamento"]
N2["11.3 Controle de recursos"]
N3["11.4 Logs"]
N4["11.4b Correções e configuração"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["11.1 Processos e permissões"]
N1["11.2 Isolamento"]
N2["11.3 Controle de recursos"]
N3["11.4 Logs"]
N4["11.4b Correções e configuração"]
N5["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX031"]
[11.1 Processos e permissões]
|
v
[11.2 Isolamento]
|
v
[11.3 Controle de recursos]
|
v
[11.4 Logs]
|
v
[11.4b Correções e configuração]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) explicar processos, usuários, permissões de arquivos e isolamento; (2) executar serviços de IA com menor privilégio; (3) isolar em sandbox o código produzido ou acionado por IA; e (4) usar logs do sistema em investigações.
11.1 Processos e permissões
Todo programa roda como um processo pertencente a uma conta de usuário. O sistema operacional verifica as permissões dessa conta antes de permitir acesso a arquivos, conexões de rede ou uso de dispositivos. Um servidor de modelo deve rodar sob sua própria conta sem privilégios, que pode ler os arquivos do modelo, mas não pode alterar código, ler dados não relacionados nem administrar a máquina. Se um atacante encontrasse uma falha no servidor de modelo, obteria apenas os direitos dessa conta. É por isso que o worker de OCR do DocSort rodando como administrador, no exemplo resolvido, era um achado grave antes mesmo de algo dar errado.
11.2 Isolamento
Contêineres e máquinas virtuais isolam cargas de trabalho. O isolamento é essencial quando um sistema de IA pode executar código (por exemplo, uma ferramenta de análise de dados num chatbot): o código pode ser influenciado por injeção de prompt, então precisa rodar sem acesso à rede, com CPU e memória limitadas, um tempo limite curto e um sistema de arquivos temporário. O Ask Lumen não executa código, mas o DocSort processa digitalizações enviadas, que são arquivos não confiáveis. Rodar seu worker de OCR num contêiner com acesso somente leitura à pasta de entrada significa que um arquivo malicioso só consegue afetar esse contêiner. Cada restrição responde a um risco específico: sem rede, os dados não saem; o tempo limite detém laços sem fim; e o sistema de arquivos temporário desaparece após cada tarefa.
11.3 Controle de recursos
Sem limites, uma requisição pesada pode deixar as outras sem recursos. Os control groups (no Linux) e os limites de contêineres restringem o uso de CPU, memória e GPU por carga de trabalho, favorecendo a disponibilidade. No DocSort, uma única digitalização malformada que consumisse toda a memória poderia bloquear todas as cartas de encaminhamento da fila. Um teto de memória no contêiner do worker faz esse arquivo falhar sozinho, enquanto a tarefa seguinte prossegue. Os limites são definidos a partir do uso normal medido mais uma margem, e uma tarefa que atinge um limite é registrada em log para que a causa possa ser investigada, em vez de ser repetida silenciosamente.
11.4 Logs
Logs de autenticação, de processos e de acesso a arquivos ajudam a reconstruir o que aconteceu. Correlacioná-los com os identificadores de requisição da aplicação liga uma conversa do chatbot aos seus efeitos no sistema. No Ask Lumen, cada conversa recebe um identificador de requisição que aparece no log da aplicação, no log das chamadas ao modelo e no log da ferramenta de agendamento. Com esse identificador, Rina consegue seguir uma mensagem de paciente desde o chat até qualquer consulta que ela tenha alterado. Sem ele, casar entradas apenas pelo horário é lento e propenso a erros quando muitas conversas acontecem ao mesmo tempo.
11.4b Correções e configuração
Sistemas operacionais e software de serviço de IA recebem atualizações de segurança; aplique-as segundo um calendário e acompanhe as versões. Configurações padrão muitas vezes ativam recursos de depuração, páginas de erro detalhadas e contas de exemplo que devem ser desativados em produção. Os despejos de memória do DocSort, no exemplo resolvido, são um caso desse tipo de padrão: úteis no desenvolvimento, nocivos em produção. A LCH agora mantém, para cada serviço de IA, uma lista de verificação de configuração revisada antes de cada versão, com as opções de depuração, páginas de erro e contas de exemplo que precisam estar desligadas. As correções seguem um calendário mensal, e as urgentes são aplicadas antes quando uma vulnerabilidade grave é anunciada.
11.5 Exemplo resolvido (caso sintético da LCH)
O worker de OCR do DocSort rodava com uma conta de administrador "por conveniência". Um arquivo digitalizado malformado o derrubou, e o despejo de memória foi gravado numa pasta compartilhada legível por todos os funcionários, expondo o texto das cartas. A correção de Rina: uma conta dedicada sem privilégios, despejos de memória desativados em produção, o worker num contêiner com acesso somente leitura à pasta de entrada e alertas para quedas. Cada correção responde a uma causa: a conta sem privilégios limita o que um worker comprometido pode fazer, os despejos desativados impedem que texto chegue a uma pasta compartilhada, a entrada somente leitura impede o worker de alterar cartas, e os alertas tornam as quedas visíveis.
11.6 Erros e limites
Três erros são comuns: serviços rodando como administrador; ferramentas de IA que executam código com acesso à rede; e logs que não podem ser ligados às requisições. Rodar como administrador transforma qualquer bug em controle total da máquina, como quase aconteceu no caso do DocSort. Ferramentas de IA que executam código com acesso à rede podem ser conduzidas por injeção de prompt a enviar dados para fora. Logs que não podem ser ligados às requisições tornam impossível dizer qual conversa causou qual efeito, e as investigações empacam. Cada um desses pontos é uma escolha de configuração, barata de acertar desde o início.
Exercícios
- EX031 — Menor privilégio. Liste três permissões de que o worker do DocSort precisa e três que ele não deveria ter. Rubrica: 3 = os dois lados sensatos; 2 = um lado fraco; 1 = vago; 0 = nenhuma.
- EX032 — Sandbox. Especifique uma sandbox para a ferramenta "analisar planilha" de um chatbot. Rubrica: 3 = sem rede, limites de CPU/memória/tempo, sistema de arquivos temporário, usuário sem privilégios; 2 = três; 1 = um ou dois; 0 = nenhum.
- EX033 — Despejo de memória. Por que o despejo de memória era um problema de confidencialidade? Rubrica: 3 = continha texto sensível gravado num local amplamente legível; 2 = parcial; 1 = vago; 0 = errado.
Síntese
O sistema operacional impõe quem pode fazer o quê. Menor privilégio, isolamento, limites de recursos e logs rastreáveis tornam os serviços de IA mais seguros quando algo dá errado.
Continue estudando — capítulo 11 de 40
← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →