## Capítulo 11 — Sistemas operacionais ### Mapa da aula Aula 11 publicada. Mapa, exemplo, EX021. ```mermaid flowchart TD N0["11.1 O que o sistema operacional faz"] N1["11.2 Tipos de SO nos serviços críticos"] N2["11.3 Hardening"] N3["11.4 Patches na operação"] N4["11.6 Atividade prática"] N5["Síntese do capítulo"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 N5 --> EX["Exemplo resolvido"] EX --> Q["Exercício EX021"] ``` ### Desenho lógico ```mermaid flowchart LR N0["11.1 O que o sistema operacional faz"] N1["11.2 Tipos de SO nos serviços críticos"] N2["11.3 Hardening"] N3["11.4 Patches na operação"] N4["11.6 Atividade prática"] N5["Síntese do capítulo"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX021"] ``` ```text [11.1 O que o sistema operacional faz] | v [11.2 Tipos de SO nos serviços críticos] | v [11.3 Hardening] | v [11.4 Patches na operação] | v [11.6 Atividade prática] | v [Síntese do capítulo] | v [Exemplo resolvido] --> [Exercício EX021] ``` ### Objetivos de aprendizagem e conexão Depois deste capítulo, você consegue (1) explicar processos, proteção de memória, permissões de arquivos e privilégio; (2) descrever como um sistema operacional impõe o menor privilégio e onde ele não consegue; (3) comparar sistemas operacionais de uso geral, de tempo real e embarcados nos serviços críticos; e (4) montar uma lista de hardening e uma decisão de patch para um dispositivo que não pode ser reiniciado à vontade. O capítulo se apoia nas camadas do Capítulo 2 e prepara o Capítulo 13 (identidade) e o Capítulo 24 (controles). ### 11.1 O que o sistema operacional faz O **sistema operacional** (SO) reparte uma máquina entre muitos programas e usuários. Um **processo** é um programa em execução com a sua própria memória; o SO usa a proteção de memória do hardware para que um processo não consiga ler nem sobrescrever a memória de outro. O **kernel** é o núcleo privilegiado que gerencia o hardware; os programas de usuário pedem serviços a ele por meio de **chamadas de sistema**. Os arquivos têm **permissões** — em sistemas do tipo Unix, leitura, escrita e execução para o dono, um grupo e os demais — e o SO as confere a cada acesso. O **privilégio** é a capacidade de contornar essas verificações: a conta root do Unix, o Administrator do Windows. Os princípios de Saltzer e Schroeder do **menor privilégio** e da **mediação completa** — todo acesso conferido, todo programa recebendo só os direitos de que precisa — continuam sendo a base ([Saltzer and Schroeder, 1975](https://doi.org/10.1109/PROC.1975.9939)). ### 11.2 Tipos de SO nos serviços críticos Os sistemas de **uso geral** (Windows, Linux, macOS) rodam servidores, estações de trabalho de operadores e PCs de escritório; são ricos em recursos, recebem patches com frequência e são amplamente atacados. Os **sistemas operacionais de tempo real** (RTOS) garantem que as tarefas cumpram prazos — um relé de proteção precisa agir em milissegundos — e rodam em controladores, relés e dispositivos médicos; são pequenos e recebem patches com menos frequência. O **firmware embarcado** em sensores e dispositivos simples pode não ter separação alguma entre programas. A consequência: as proteções de SO mais fortes existem nas máquinas mais fáceis de substituir, e as mais fracas, nas máquinas que duram mais. ### 11.3 Hardening O **hardening** reduz o que um atacante pode usar. Uma lista prática: remover ou desativar serviços e softwares não usados; trocar contas e senhas padrão; rodar os serviços com contas sem privilégio; ativar os logs e enviá-los para fora do host; restringir mídias removíveis; ativar a allowlist de aplicações onde a carga de trabalho for estável (as estações de trabalho de operadores são boas candidatas — rodam os mesmos poucos programas por anos); manter o horário sincronizado para que os logs possam ser correlacionados. Cada item deve ser verificável — um padrão de hardening que não pode ser verificado é um desejo. ### 11.4 Patches na operação Na TI de escritório, aplicar patches é rotina. Numa estação de trabalho de operador ou num controlador, um patch pode exigir validação do fornecedor, uma janela de manutenção e um plano de reversão, porque uma atualização que falha pode parar o processo. Uma **decisão de patch baseada em risco** pergunta: a falha é explorável neste dispositivo tal como está implantado (alcançável? exige acesso local?); ela é sabidamente explorada; o que o dispositivo controla; quais controles compensatórios existem; quando é a próxima janela? O resultado é um destes: aplicar agora (mudança emergencial), aplicar na próxima janela, mitigar e monitorar até a substituição, ou aceitar com um dono nomeado. O guia de TO do NIST discute esses trade-offs ([SP 800-82 Rev. 3](https://csrc.nist.gov/pubs/sp/800/82/r3/final)). ### 11.5 Exemplo resolvido: a estação de sinalização da CT (sintético) **Este caso é sintético.** A estação de trabalho de controle de sinalização da Calder Transit roda um SO de uso geral. Uma atualização mensal corrige uma falha que permite a um usuário local de baixo privilégio tornar-se administrador. A estação não tem acesso à internet nem e-mail, tem a allowlist de aplicações ativada e só três sinaleiros nomeados fazem login nela. O fornecedor valida as atualizações do SO trimestralmente; o próximo pacote validado sai em sete semanas. Decisão: **aplicar na próxima janela**, porque a exploração exige uma conta local numa máquina rigidamente controlada; enquanto isso, confirmar que a allowlist está sendo imposta e revisar as três contas. Se a falha fosse explorável remotamente por um serviço de rede que a estação expõe, a resposta seria uma mudança emergencial ou a desativação desse serviço. ### 11.6 Atividade prática No seu próprio computador, liste os processos em execução e a conta com que cada um roda; encontre um serviço que você não usa e descubra como ele poderia ser desativado (não desative nada sobre o que você tenha dúvida). Escreva uma lista de hardening de cinco itens para uma estação de atendimento de chamadas do CEDC, cada item com a forma de verificá-lo. Para a estação do CEDC, escreva itens como "os atendentes fazem login com contas individuais sem direitos de administrador; verificação: listar os administradores locais todo mês" ou "armazenamento USB bloqueado; verificação: inserir um pendrive de teste durante a revisão trimestral". ### 11.7 Erros comuns e limites - Rodar tudo como administrador "para evitar problemas de permissão". - Fazer o hardening uma vez e nunca verificar o desvio. - Aplicar a cadência de patches da TI de escritório à TO sem validação e reversão. - Supor que um dispositivo sem interface de usuário de SO não tem SO. A estação de sinalização da CT mostra as alternativas: allowlist e três contas nomeadas em vez de uso de administrador, um pacote trimestral validado pelo fornecedor em vez da cadência mensal do escritório, e uma revisão que confere se a allowlist ainda está sendo imposta. O quarto erro abrange as bombas de infusão do CVH, que rodam um RTOS que precisa de atualizações do fornecedor. ### Exercícios — capítulo 11 **EX021 — Decisão de patch.** *Objetivo:* aplicar as perguntas baseadas em risco. *Entradas:* uma falha explorável remotamente na interface web de um controlador do BMS do CVH; a interface é alcançável a partir da rede corporativa; a correção do fornecedor exige reiniciar o controlador por 30 minutos; a ventilação do centro cirúrgico depende do BMS. *Etapas:* responda às cinco perguntas de decisão de patch baseada em risco deste capítulo e recomende. *Evidência esperada:* respostas e recomendação com controles provisórios. *Rubrica:* 3 = restringir imediatamente o acesso à interface, agendar a reinicialização com a manutenção predial e o centro cirúrgico numa janela planejada, monitorar; 2 = desfecho certo, controles provisórios fracos; 1 = "aplicar o patch imediatamente" sem considerar a ventilação; 0 = nada. **EX022 — Hardening verificável.** *Objetivo:* tornar os controles verificáveis. *Entradas:* três itens vagos: "proteger as contas", "ligar os logs", "travar o USB". *Etapas:* reescreva cada um como uma afirmação específica e verificável, com a verificação. *Evidência esperada:* três itens reescritos. *Rubrica:* 3 = específicos, observáveis, com método de verificação; 2 = específicos, sem verificação; 1 = ainda vagos; 0 = nada. ### Síntese do capítulo O SO impõe separação, permissões e privilégio; o menor privilégio e a mediação completa são as suas ideias orientadoras. Nos serviços críticos, os dispositivos mais duráveis muitas vezes têm as proteções mais fracas, então o hardening precisa ser verificável e os patches precisam ser baseados em risco, agendados e reversíveis. ### Continue estudando — capítulo 11 de 40 [← Capítulo 10](#ch-10) · [Índice de capítulos do curso](../SUBJECTS.md) · [Capítulo 12 →](#ch-12) Siga para a próxima lição escrita. ## Worked answers **EX021.** Explorável como implantado: sim, remotamente a partir da rede corporativa. Sabidamente explorada: presumir desconhecido; conferir. Controla: ventilação das salas cirúrgicas — consequência alta. Controles compensatórios: restringir agora o acesso à interface a duas estações da manutenção predial; monitorar. Janela: agendar a reinicialização de 30 minutos com a manutenção predial e o centro cirúrgico quando as salas não estiverem em uso (por exemplo, numa noite de fim de semana), com verificações manuais da ventilação. Recomendação: restringir agora, aplicar o patch na janela segura mais próxima, confirmar depois. **EX022.** "Proteger as contas" → "Todo login de IHM é uma conta individual nominal; nenhuma conta padrão do fornecedor está habilitada; conferido mensalmente exportando a lista de contas e comparando-a com a escala." "Ligar os logs" → "Os logs de segurança e de aplicação são encaminhados ao servidor central de logs em até 5 minutos; conferido semanalmente confirmando o evento mais recente de cada host." "Bloquear o USB" → "O armazenamento em massa USB está desabilitado por política nas estações dos operadores; conferido por exportação trimestral da política e por um teste com um dispositivo aprovado."