Capítulo 8 — Arquitetura de computadores
Mapa da aula
Aula 08 publicada. Mapa, exemplo, EX022.
flowchart TD
N0["8.1 Privilégio e observabilidade"]
N1["8.2 Canais laterais são físicos"]
N2["8.3 Evidência sem root"]
N3["8.3b Privilégio nos tickets"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX022"]
Desenho lógico
flowchart LR
N0["8.1 Privilégio e observabilidade"]
N1["8.2 Canais laterais são físicos"]
N2["8.3 Evidência sem root"]
N3["8.3b Privilégio nos tickets"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX022"]
[8.1 Privilégio e observabilidade]
|
v
[8.2 Canais laterais são físicos]
|
v
[8.3 Evidência sem root]
|
v
[8.3b Privilégio nos tickets]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX022]
Objetivos de aprendizagem
Você vai (1) mapear os níveis de privilégio para o que um teste autorizado pode observar; (2) explicar por que canais laterais de tempo e de cache precisam de cláusulas especiais na ROE; (3) desenhar um caminho de evidências que não exija privilégios de kernel.
8.1 Privilégio e observabilidade
O modo usuário vê a memória do processo e as chamadas de sistema que lhe são permitidas; o modo kernel vê dispositivos e tabelas de páginas; um hipervisor vê os convidados. Um engajamento autorizado que permanece em modo usuário não pode afirmar que "descartamos um rootkit de kernel". Declare o nível de privilégio de cada observação no pacote de evidências. O TrackScope deve registrar a conta e o papel usados em cada ação. Um achado é tão forte quanto o ponto de observação que o produziu. Evidências em modo usuário não conseguem descartar ameaças que vivem abaixo dele, e afirmar o contrário vende o engajamento por mais do que ele é. Registrar a conta e o papel ao lado de cada ação permite que um revisor veja se uma alegação posterior corresponde ao acesso usado. O TrackScope se recusa a guardar uma observação sem esse campo.
8.2 Canais laterais são físicos
Canais laterais de cache e de tempo medem o estado microarquitetural. São técnicas de pesquisa, ruidosas e muitas vezes fora do escopo de avaliações comerciais. Se estiverem no escopo, a ROE precisa nomear as plataformas, proibir tráfego de produção e exigir uma condição de parada caso a latência para os usuários suba. Não trate um laboratório de estudante num notebook como evidência sobre um servidor. Essas técnicas medem o estado de hardware compartilhado e podem perturbar a latência de produção, e é por isso que precisam de cláusulas próprias na ROE. Um laboratório num notebook não diz nada sobre o comportamento de cache de um servidor sob carga. Quando os canais laterais estão fora do escopo, Sam declara esse limite no relatório para que os leitores não presumam que foram tentados. As condições de parada protegem usuários que nunca concordaram em fazer parte do experimento.
8.3 Evidência sem root
A maior parte das evidências duráveis de uma avaliação autorizada são logs, leituras de configuração e respostas de aplicação — tudo disponível para uma conta de usuário devidamente autorizada. Prefira esse caminho: é mais seguro, mais fácil de revogar depois do engajamento e suficiente para achados sobre autenticação, autorização e exposição.
Caso sintético — Riverstone Transit. Uma proposta de "imagem completa de disco" de um validador de tarifas precisava de root e tiraria o dispositivo do ar. Sam a substituiu por uma exportação de configuração e uma leitura, no nível da aplicação, da lista de contas, ambas autorizadas pela ROE existente.
8.4 Erros e limites
Diagramas de arquitetura em apresentações de marketing omitem caches compartilhados e planos de gerenciamento. Verifique a plataforma real antes de prometer um nível de privilégio na ROE. Diagramas de marketing muitas vezes escondem interfaces de gerenciamento e hardware compartilhado. Sam confirma a plataforma real com o cliente antes que a ROE prometa um nível de privilégio. Se a plataforma não puder ser confirmada, o engajamento fica no menor privilégio cuja existência é conhecida, e o relatório declara esse limite para que os leitores não inventem um ponto de observação mais forte.
8.3b Privilégio nos tickets
O FindingsDesk deve guardar privilege_used como um enum (user, admin-local, admin-domain, hypervisor, out-of-band). A ordenação e a lógica de SLA podem então tratar achados de hipervisor de forma diferente de leituras de configuração em modo usuário. Sem o campo, dois achados com títulos parecidos podem ter sido obtidos sob autorizações radicalmente diferentes, e o plano de reteste estará errado. Um enum impede a deriva do texto livre, como 'admin' significar local num ticket e domínio em outro. Os relógios de SLA podem então dar aos achados de hipervisor um caminho diferente, porque verificá-los exige outro acesso e outras condições de parada. Os planos de reteste leem o campo para que quem faz o reteste leve a autorização certa. O FindingsDesk rejeita um ticket que o omita.
Exercícios
- EX022 — Mapa de privilégios. Liste três observações possíveis como usuário comum e três que exigem privilégios elevados. Rubrica: 3 = seis itens concretos mapeados corretamente; 2 = quatro; 1 = vago; 0 = nada.
- EX023 — ROE de canal lateral. Escreva duas cláusulas de ROE para um estudo autorizado de tempo de cache num host de laboratório reserva. Rubrica: 3 = plataforma nomeada, produção excluída, condição de parada; 2 = dois de três; 1 = um; 0 = nada.
- EX024 — Caminho de evidência. Proponha um caminho de evidência para "senha de administrador padrão na UI de staging" que não precise de root. Rubrica: 3 = tentativa de login sob a ROE, captura de tela/log, ticket, nenhuma credencial deixada para trás; 2 = falta um; 1 = vago; 0 = exige root.
Síntese
Diga qual privilégio você usou. Prefira evidências de nível de usuário. Trate canais laterais como algo especial, não como uma ferramenta padrão.
Continue estudando — capítulo 08 de 50
← Capítulo 07 (rascunho) · Índice de capítulos do curso · Capítulo 09 (rascunho) →