Capítulo 1 — Sistemas computacionais
Mapa da aula
Aula 01 publicada. Mapa, exemplo, EX001.
flowchart TD
N0["1.1 Camadas que um avaliador precisa nomear"]
N1["1.2 Por que capacidade e fragilidade importam"]
N2["1.3 Infraestrutura compartilhada e virtual"]
N3["1.4 O registro de ativo"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX001"]
Desenho lógico
flowchart LR
N0["1.1 Camadas que um avaliador precisa nomear"]
N1["1.2 Por que capacidade e fragilidade importam"]
N2["1.3 Infraestrutura compartilhada e virtual"]
N3["1.4 O registro de ativo"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX001"]
[1.1 Camadas que um avaliador precisa nomear]
|
v
[1.2 Por que capacidade e fragilidade importam]
|
v
[1.3 Infraestrutura compartilhada e virtual]
|
v
[1.4 O registro de ativo]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX001]
Objetivos de aprendizagem
Você vai (1) descrever as camadas de hardware, firmware, sistema operacional e aplicação de um computador nos termos de que um avaliador precisa; (2) explicar por que sistemas frágeis ou compartilhados mudam o planejamento de um teste; (3) escrever um registro de ativo que uma reunião de escopo possa usar; (4) reconhecer quando um sistema pertence a alguém que não autorizou testes.
1.1 Camadas que um avaliador precisa nomear
Um sistema computacional é uma pilha. Na base ficam processador, memória, armazenamento e interface de rede. Firmwares como o UEFI ou um controlador de gerenciamento da placa-mãe (BMC) dão a partida na máquina e muitas vezes continuam rodando ao lado dela. O sistema operacional agenda processos, aplica permissões de arquivo e expõe serviços. As aplicações ficam no topo e guardam os dados que interessam ao negócio. Quando um relatório de teste diz "o host", o leitor não consegue saber qual camada foi examinada; um tecnólogo nomeia a camada, porque o responsável, o caminho de correção e o risco são diferentes em cada uma.
1.2 Por que capacidade e fragilidade importam
O tráfego de avaliação consome recursos. Um serviço que responde a cinquenta requisições por minuto em uso normal pode se degradar quando uma ferramenta de inventário envia milhares. O NIST SP 800-115 adverte que os testes podem perturbar as operações e pede que os planejadores pesem esse risco antes de escolher as técnicas. Controladores embarcados antigos, daemons legados de thread única e storages perto do limite são as vítimas habituais. A resposta não é pulá-los em silêncio, e sim registrar a restrição e combinar com o responsável um método mais brando, como a revisão de configuração.
O primeiro diagrama de Priya para o ENG-712 separa os caminhos de internet dos passageiros dos caminhos da VPN dos funcionários antes que qualquer lista de prefixos seja montada. As premissas de confiança diferem em cada caminho, então um inventário único e plano esconderia onde a autorização precisa mudar.
1.3 Infraestrutura compartilhada e virtual
Muitos sistemas rodam em hardware de outra pessoa: um provedor de hospedagem, um parceiro de serviços gerenciados, uma plataforma de nuvem. O cliente pode ser dono da máquina virtual, mas não do hipervisor nem da malha de armazenamento por baixo dela. A autorização do cliente, portanto, cobre apenas o que o cliente controla. Os termos do provedor, que às vezes exigem aviso prévio e às vezes proíbem certos tipos de teste, precisam ser lidos antes do planejamento. Hospedagem compartilhada significa que a TRT pode não enxergar o hipervisor subjacente. Por isso o escopo do ENG-712 elaborado por Priya nomeia as máquinas virtuais e as URLs que a TRT controla, e não o plano de gerenciamento do provedor. Quando um achado toca a infraestrutura compartilhada, ela escala para o responsável pela nuvem em vez de sondar lateralmente. As regras de engajamento (ROE) da Northpoint repetem esse limite para que os testadores não inventem permissão.
1.4 O registro de ativo
Um registro útil contém: identificador, função de negócio, responsável, localização (física ou lógica), sistema operacional e versão, criticidade, fragilidade conhecida e o status de autorização para testes. Todos os capítulos seguintes se apoiam nesses campos: as verificações de escopo leem o endereço, as classificações de risco leem a criticidade, os relatórios leem o responsável. A linha de ativo de Priya para o portal dos funcionários traz responsável, criticidade e a nota de fragilidade "congelamento de mudanças às sextas". Sem esse registro, as decisões do lab_scope parecem arbitrárias. Ela atualiza a linha quando o DNS muda, porque um identificador desatualizado é o caminho pelo qual hosts OUT-OF-SCOPE acabam testados por engano.
Exemplo resolvido
Priya inventaria o servidor de horários da TRT. Hardware: um servidor de rack com três anos de uso. Firmware: BMC do fabricante com porta de rede própria. Sistema operacional: uma versão de Linux com suporte. Aplicação: a API de horários. Ela registra o BMC como um ativo separado, porque sua porta de rede fica numa VLAN de gerenciamento que o escopo da Northpoint não menciona. A reunião de escopo terá de decidir se ele está dentro ou fora.
Caso sintético. A Tidewater Regional Transit e seu servidor de horários foram inventados para este capítulo.
Erros e limites
Tratar "o servidor" como uma coisa só esconde o firmware e as interfaces de gerenciamento. Supor que ser locatário na nuvem concede permissão sobre as camadas do provedor é um erro comum e grave. Este capítulo descreve apenas arquitetura; não explica como atacar nenhuma camada.
Exercícios
- EX001 — Interface oculta. Por que um controlador de gerenciamento da placa-mãe com porta de rede própria deve aparecer como um registro de ativo próprio? Rubrica: 3 = interface separada, responsável/caminho de correção separados, o escopo precisa decidir explicitamente; 2 = só a interface separada; 1 = "faz parte do servidor"; 0 = nada.
- EX002 — Daemon frágil. Um daemon legado de planejamento de rotas cai sob carga pesada. Proponha como o plano deve tratá-lo. Rubrica: 3 = registrar a fragilidade, combinar com o responsável um método de menor impacto (revisão de configuração ou verificação com limitação de taxa), documentar nas ROE; 2 = excluir sem discussão; 1 = testar normalmente; 0 = nada.
- EX003 — Limite da hospedagem. A TRT aluga máquinas virtuais de uma empresa de hospedagem. Quais camadas a TRT pode autorizar e o que precisa ser verificado para o restante? Rubrica: 3 = a TRT autoriza suas VMs/aplicações; hipervisor e malha exigem termos/aviso ao provedor; 2 = em parte; 1 = a TRT autoriza tudo; 0 = nada.
Síntese
Nomeie a camada, registre o responsável e a fragilidade, e nunca deixe a condição de locatário se passar por autoridade sobre o hardware de outra pessoa.
Continue estudando — capítulo 01 de 30
← Página do curso · Índice de capítulos do curso · Capítulo 02 (rascunho) →