Capítulo 12 — Sistemas operacionais
Mapa da aula
Aula 12 publicada. Mapa, exemplo, EX023.
flowchart TD
N0["12.1 O que um sistema operacional faz"]
N1["12.2 Sistemas operacionais de tempo real"]
N2["12.3 Mecanismos de segurança do sistema operacional"]
N3["12.4 Aplicação de correções sob restrições de dispon"]
N4["12.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX023"]
Desenho lógico
flowchart LR
N0["12.1 O que um sistema operacional faz"]
N1["12.2 Sistemas operacionais de tempo real"]
N2["12.3 Mecanismos de segurança do sistema operacional"]
N3["12.4 Aplicação de correções sob restrições de dispon"]
N4["12.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX023"]
[12.1 O que um sistema operacional faz]
|
v
[12.2 Sistemas operacionais de tempo real]
|
v
[12.3 Mecanismos de segurança do sistema operacional]
|
v
[12.4 Aplicação de correções sob restrições de dispon]
|
v
[12.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX023]
Objetivos de aprendizagem e conexão
Ao fim deste capítulo você será capaz de (1) explicar processos, threads, escalonamento, gerenciamento de memória e sistemas de arquivos; (2) distinguir sistemas operacionais de propósito geral e de tempo real e escolher entre eles; (3) aplicar os mecanismos de segurança do sistema operacional — contas, permissões, isolamento, registro em log, aplicação de correções — aos servidores do centro de controle e às estações de engenharia; e (4) planejar a aplicação de correções e o endurecimento sob as restrições de disponibilidade da tecnologia operacional. Ele se apoia no Capítulo 8 e prepara os capítulos 18 e 39.
12.1 O que um sistema operacional faz
Um sistema operacional multiplexa o hardware entre os programas e oferece abstrações: processos (espaços de endereçamento isolados), threads (execução concorrente dentro de um processo), memória virtual, arquivos e dispositivos. O kernel executa com privilégios; as aplicações pedem serviços por meio de chamadas de sistema. O escalonador decide qual thread executa; sua política determina a latência. Na LRWA, os servidores SCADA e as estações de engenharia executam sistemas operacionais de propósito geral, enquanto a lógica de proteção das bombas executa nas RTUs e nos PLCs de cada estação. Saber qual código executa onde diz quais máquinas precisam de garantias de tempo real e quais precisam de endurecimento, aplicação de correções e registro em log do tipo descrito abaixo.
12.2 Sistemas operacionais de tempo real
Um sistema operacional de tempo real garante resposta limitada: as tarefas com prazos são escalonadas de modo que, se a análise disser que elas cabem, elas cumprem seus prazos. O escalonamento por prioridade fixa com atribuição de prioridades rate-monotonic é uma abordagem clássica; a análise de Liu e Layland dá um limite suficiente de utilização para tarefas periódicas sob essa política. Os sistemas operacionais de propósito geral (Windows, Linux de desktop) otimizam a vazão e a equidade; sua latência de pior caso não é limitada sem configuração especial. Regra: as funções de proteção executam em controladores de tempo real; as funções de supervisão (IHM, historiador) podem executar em sistemas de propósito geral.
12.3 Mecanismos de segurança do sistema operacional
- Privilégio mínimo: os serviços executam sob contas dedicadas, apenas com os direitos necessários; nada de contas de administrador compartilhadas. Saltzer and Schroeder (1975) apresentaram o privilégio mínimo, os padrões à prova de falhas, a mediação completa e a economia de mecanismo como princípios de projeto que continuam válidos.
- Controle de acesso: permissões de arquivos e de objetos; controle de acesso obrigatório onde estiver disponível.
- Lista de permissões de aplicações: apenas executáveis aprovados executam — prático em hosts de TO de propósito único, cujo software raramente muda.
- Registro em log: autenticação, uso de privilégios, mudanças de serviços e criação de processos, encaminhados para fora do host.
- Endurecimento: remover serviços não usados, fechar portas não usadas, desabilitar a execução automática de mídias removíveis.
- Aplicação de correções: aplicar as atualizações de segurança, testadas e agendadas.
12.4 Aplicação de correções sob restrições de disponibilidade
Sistemas de TO muitas vezes não podem ser reiniciados à vontade, e os fornecedores podem suportar apenas níveis específicos de correções. A aplicação de correções é, portanto, baseada em risco: avalie a explorabilidade de cada vulnerabilidade na sua arquitetura (o serviço vulnerável é alcançável?), sua consequência e o risco para a disponibilidade de aplicá-la; depois corrija, mitigue (bloqueie a porta, desabilite o recurso) ou aceite com uma data de revisão. Mantenha um sistema de teste que espelhe a produção para validar as correções. O guia de TO do NIST (SP 800-82 Rev. 3) discute esses compromissos.
12.5 Exemplo resolvido: endurecendo os servidores SCADA (sintético)
Os dois servidores SCADA da LRWA executam um sistema operacional de propósito geral. A linha de base do TMRP: contas de serviço dedicadas; os operadores entram com contas nominais; administrador local desabilitado, exceto uma conta de emergência (break-glass) cuja senha fica lacrada e cujo uso gera alarme; lista de permissões habilitada após um período de aprendizado de duas semanas num ambiente de teste; armazenamento USB bloqueado; logs encaminhados ao coletor da DMZ; uma janela mensal de correções alternando entre os servidores, para que um deles esteja sempre em funcionamento. O risco residual — o fornecedor certifica as correções 30 dias após o lançamento — é mitigado por regras de rede que expõem ao campo e à DMZ apenas as portas da aplicação SCADA.
12.6 Atividade prática
Numa máquina virtual Linux que seja sua, liste os serviços em escuta (ss -tulpn), as contas locais com shell de login e os serviços habilitados. Escreva uma nota de endurecimento: quais serviços você desabilitaria num host historiador de propósito único e por quê. Não execute isso contra nenhum sistema que não seja seu. Registre a saída com a data e o nome da máquina e, para cada serviço que você desabilitaria, anote o que quebraria se você estivesse errado. Um host historiador na LRWA precisaria de seu serviço de banco de dados e do encaminhamento de logs, mas raramente de um servidor de e-mail ou de um serviço de compartilhamento de arquivos. Compare sua lista com as medidas de endurecimento do exemplo do SCADA e explique qualquer diferença. O exercício treina o hábito de perguntar por que cada serviço está em execução antes de decidir se ele deveria estar.
12.7 Erros comuns e limites
- Executar a lógica de proteção num sistema operacional de propósito geral.
- Contas compartilhadas, que destroem a responsabilização.
- Aplicar correções pelo calendário sem avaliar a explorabilidade — ou nunca aplicá-las porque "a TO é especial".
- Logs mantidos apenas no host que um atacante controla.
- Lista de permissões ligada em produção sem um período de aprendizado.
O endurecimento do SCADA da LRWA evita cada um desses erros: contas nominais substituem as compartilhadas, os logs saem do host, a lista de permissões veio após duas semanas de aprendizado num ambiente de teste, e a janela mensal de correções alterna entre os dois servidores. O risco residual está registrado.
Exercícios — capítulo 12
EX023 — Verificação rate-monotonic. Objetivo: testar a escalonabilidade com o limite de Liu–Layland. Entradas: três tarefas periódicas numa RTU: (C=2 ms, T=10 ms), (C=4 ms, T=40 ms), (C=10 ms, T=100 ms). Passos: calcule a utilização; calcule o limite $n(2^{1/n}-1)$ para $n = 3$; conclua. Evidência esperada: números e conclusão. Rubrica: 3 = U = 0,40, limite ≈ 0,780, escalonável pelo teste suficiente, com a ressalva de que ultrapassar o limite não provaria a não escalonabilidade; 2 = ressalva ausente; 1 = erro aritmético; 0 = nada.
EX024 — Decisão de correção. Objetivo: tomar uma decisão de correção baseada em risco. Entradas: uma vulnerabilidade de execução remota de código no serviço de compartilhamento de arquivos do sistema operacional; o serviço está habilitado no historiador, mas bloqueado pelo firewall da zona de controle para todas as zonas exceto a de engenharia; a certificação da correção pelo fornecedor está a 30 dias. Passos: recomende corrigir / mitigar / aceitar, com controles provisórios e uma data de revisão. Evidência esperada: nota de decisão. Rubrica: 3 = mitigação agora (desabilitar o serviço ou restringir mais), correção após a certificação, monitoramento, data; 2 = sem controle provisório; 1 = "corrigir imediatamente", ignorando o suporte do fornecedor, ou "aceitar" sem raciocínio; 0 = nada.
Síntese do capítulo
O sistema operacional determina tanto a temporização quanto a linha de base de segurança. Coloque os prazos em plataformas de tempo real. Aplique privilégio mínimo, lista de permissões, endurecimento e registro em log fora do host. Aplique correções com base no risco avaliado, com procedimentos testados e controles compensatórios quando ainda não puder corrigir, e mantenha um ambiente espelho para tornar isso possível.
Continue estudando — capítulo 12 de 50
← Capítulo 11 · Índice de capítulos do curso · Capítulo 13 →
Siga para a próxima lição escrita.