Capítulo 4 — Scripts e formatos de dados
Mapa da aula
Aula 04 publicada. Mapa, exemplo, EX013.
flowchart TD
N0["4.1 Por que scripts"]
N1["4.2 Dados não confiáveis"]
N2["4.3 Reprodutibilidade"]
N3["4.4 Formatos"]
N4["4.5 Segredos em scripts"]
N5["4.6 Revisão de código"]
N6["4.8 Códigos de saída"]
N7["4.9 Disciplina de campo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX013"]
Desenho lógico
flowchart LR
N0["4.1 Por que scripts"]
N1["4.2 Dados não confiáveis"]
N2["4.3 Reprodutibilidade"]
N3["4.4 Formatos"]
N4["4.5 Segredos em scripts"]
N5["4.6 Revisão de código"]
N6["4.8 Códigos de saída"]
N7["4.9 Disciplina de campo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]
[4.1 Por que scripts]
|
v
[4.2 Dados não confiáveis]
|
v
[4.3 Reprodutibilidade]
|
v
[4.4 Formatos]
|
v
[4.5 Segredos em scripts]
|
v
[4.6 Revisão de código]
|
v
[4.8 Códigos de saída]
|
v
[4.9 Disciplina de campo]
|
v
[Exemplo resolvido] --> [Exercício EX013]
Objetivos de aprendizagem
Você vai (1) analisar com segurança evidências simples em JSON/CSV; (2) evitar executar artefatos não confiáveis; (3) manter os scripts reproduzíveis; (4) registrar as versões do interpretador.
4.1 Por que scripts
Técnicos automatizam comparações de inventário, verificações de hash e a formatação de chamados, e os scripts precisam ser legíveis pela próxima pessoa. Os scripts existem para que Sam possa repetir verificações no estilo do lab_ports e calcular hashes de evidências do mesmo jeito todo sábado. Eles não existem para inventar novos caminhos de ataque; todo script do ENG-512 corresponde a um cartão de método da lista assinada. Os cabeçalhos dos scripts citam os IDs dos cartões de método, para que a automação não se afaste dessa lista, e scripts órfãos, sem citação, são apagados da pasta de tarefas de sábado.
4.2 Dados não confiáveis
Arquivos vindos dos alvos são dados, e não código. Não execute binários ou macros desconhecidos de um alvo de teste numa estação administrativa. Dados não confiáveis incluem o JSON da API de homologação e qualquer arquivo que uma ferramenta grave. Sam valida as estruturas antes de analisá-las, e a validação de esquema descarta chaves JSON desconhecidas antes do registro. Um campo inesperado que parece um ID de transação de tarifa é mascarado e escalado, e não registrado por inteiro; campos com cara de pagamento nas respostas da homologação são tratados como sensíveis mesmo fora da produção, porque os dados de homologação às vezes são copiados de sistemas em operação.
4.3 Reprodutibilidade
Fixe as versões do Python, defina a semente de qualquer aleatoriedade e guarde os arquivos de entrada ao lado do script no pacote de evidências. Reprodutibilidade significa que outro técnico pode executar o mesmo script sobre o mesmo inventário e obter as mesmas linhas ok e NOT APPROVED. Sam fixa as versões dos scripts no caderno, ao lado do ID do chamado do ENG-512. Os colegas reproduzem usando o hash do script registrado no caderno, e hashes divergentes abortam a comparação. A maioria das disputas sobre reprodutibilidade acaba sendo uma disputa de versões, e ela termina quando as versões fixadas coincidem.
4.4 Formatos
JSON e CSV são comuns nas exportações de ferramentas, e Sam valida o esquema antes de confiar em campos para um achado. Os formatos de inventários e de índices de evidências são CSV ou texto simples, combinados no runbook. Dumps binários e blobs JSON sem documentação reprovam na conferência por pares, porque o próximo operador não consegue lê-los sob pressão de tempo. As colunas do CSV de inventário são name, ip, port, proto, approved. Reordená-las quebra o lab_ports, por isso Sam valida a linha de cabeçalho antes de a tarefa rodar; um arquivo com uma coluna ausente ou renomeada interrompe a tarefa, em vez de ser classificado em silêncio.
4.5 Segredos em scripts
Nada de senhas fixas no código: os scripts leem do cofre ou de um ambiente injetado pelo jump host. Esses são os únicos padrões que Sam aceita na revisão de código da automação do ENG-512. A varredura de segredos antes do merge no repositório de automação reprova o build quando encontra tokens. Sam troca qualquer token que um dia tenha aparecido no diff de um pull request, porque apagar a linha não apaga o histórico que revisores, espelhos e backups já guardam. A troca é registrada no chamado do ENG-512, com o commit que expôs o token, para que um revisor posterior possa confirmar que o valor antigo está morto.
4.6 Revisão de código
Outro técnico lê o script de Sam antes que ele rode numa janela de engajamento. A revisão de código pega listas de portas livres e senhas fixas no código antes de uma janela. Uma nota de revisão abaixo do mínimo significa que o script fica fora da lista de tarefas de sábado. Os revisores procuram padrões de host que parecem sub-redes de tarifa e rejeitam esses laços. A revisão de código é um controle de escopo, e não apenas um clube de estilo. O nome do revisor e o hash do script vão para o caderno do ENG-512, para que a tarefa que roda no sábado seja comprovadamente a que foi lida. Um script alterado depois da revisão volta para a fila, mesmo que a correção tenha uma linha só.
4.7 Limites de tamanho da entrada
Scripts que leem exportações de ferramentas limitam o tamanho do arquivo, para que um dump enorme não esgote o jump host. Limites são recursos de segurança, e não pessimismo. Limites de tamanho da entrada impedem que um inventário descontrolado trave o jump host. Sam limita as linhas processadas por execução e falha de forma fechada quando o limite é atingido: a tarefa imprime ERROR: inventory exceeds cap e sai com código 2. Truncar sem erro esconderia o 8080/http-alt depois da linha de corte. Quando o limite é atingido, Sam confere a exportação com o responsável antes de aumentar o limite numa mudança revisada, em vez de editar o valor no jump host.
4.8 Códigos de saída
Os scripts de Sam saem com código diferente de zero em MISMATCH ou NOT APPROVED, para que a integração contínua e as pessoas percebam as falhas em vez de passar os olhos por logs que parecem verdes. Os códigos de saída distinguem serviços em escuta ok de achados NOT APPROVED, para que a integração contínua e as pessoas concordem; tarefas no estilo do lab_ports que sempre saem com zero escondem o 3389/rdp até alguém ler a saída padrão com cuidado. O SOC monitora saídas diferentes de zero dos usuários de tarefas de ENG. Scripts que saem com 0 enquanto imprimem NOT APPROVED são defeitos corrigidos antes do próximo sábado. A lista de revisão de Sam inclui executar cada tarefa sobre uma lista com uma porta não aprovada e confirmar a saída diferente de zero.
4.9 Disciplina de campo
O padrão de scripts de Sam é curto o bastante para ser lembrado: um propósito por script, argparse ou constantes explícitas no topo, nenhuma chamada de rede a menos que o caminho do arquivo de ROE seja passado, e um modo --dry-run que imprime o que aconteceria. O dry-run o salvou quando um erro de digitação num caminho teria apontado uma tarefa de hash para a listagem de um compartilhamento de produção. Os revisores procuram o dry-run e a ausência de hosts fixos no código mais do que código engenhoso. A disciplina de campo para scripts acrescenta versões fixadas, árvores sem segredos, limites de tamanho e códigos de saída que batem com o relatório, e o índice do caderno do ENG-512 liga o hash de cada script ao cartão de método que ele implementa.
Exemplo resolvido (NMT sintética)
O script de verificação de hash de Sam (laboratório do Capítulo 5) recebe uma pasta de evidências e imprime MATCH/MISMATCH; ele nunca abre imagens além de calcular o hash dos bytes.
Caso sintético — Northline Municipal Transit (NMT). A operadora de transporte, Sam Park e todos os números foram inventados para fins didáticos.
Erros e limites
Sistemas de transporte reais e equipamentos de tarifa nunca são testados sem uma autorização separada e especializada. Este livro usa apenas dados sintéticos e não concede autorização para testar sistemas reais.
Exercícios
- EX013 — Dados, não código. Por que não dar um duplo clique num .doc vindo do servidor web alvo? Rubrica: 3 = pode executar macros/malware no PC administrativo; tratar como não confiável; 2 = parcial; 1 = tudo bem; 0 = nada.
- EX014 — Itens de reprodução. Nomeie três coisas que tornam um script reproduzível. Rubrica: 3 = versão, entradas, semente/configurações; 2 = duas; 1 = uma; 0 = nada.
- EX015 — Segredos. Como um script deve obter uma senha de homologação? Rubrica: 3 = cofre/injeção pelo ambiente; não fixa no código; 2 = parcial; 1 = fixar no código; 0 = nada.
- EX016 — Leitura por um colega. Por que outro técnico lê o script primeiro? Rubrica: 3 = pegar defeitos de escopo/segurança; entendimento compartilhado; 2 = parcial; 1 = burocracia; 0 = nada.
Síntese
Scripts são ferramentas controladas: reproduzíveis, sem segredos e revisadas.
Continue estudando — capítulo 04 de 18
← Capítulo 03 (rascunho) · Índice de capítulos do curso · Capítulo 05 (rascunho) →