Capítulo 10 — Configuração de controles

Mapa da aula

Aula 10 publicada. Mapa, exemplo, EX037.

flowchart TD
  N0["10.1 Achados de configuração"]
  N1["10.2 Achados de código"]
  N2["10.3 Propostas seguras"]
  N3["10.4 Verificação pelo responsável"]
  N4["10.5 Baselines"]
  N5["10.6 Desvio"]
  N6["10.7 Reversão testada"]
  N7["10.8 Homologação primeiro"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX037"]

Desenho lógico

flowchart LR
  N0["10.1 Achados de configuração"]
  N1["10.2 Achados de código"]
  N2["10.3 Propostas seguras"]
  N3["10.4 Verificação pelo responsável"]
  N4["10.5 Baselines"]
  N5["10.6 Desvio"]
  N6["10.7 Reversão testada"]
  N7["10.8 Homologação primeiro"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]

[10.1 Achados de configuração]
    |
    v
[10.2 Achados de código]
    |
    v
[10.3 Propostas seguras]
    |
    v
[10.4 Verificação pelo responsável]
    |
    v
[10.5 Baselines]
    |
    v
[10.6 Desvio]
    |
    v
[10.7 Reversão testada]
    |
    v
[10.8 Homologação primeiro]
    |
    v
[Exemplo resolvido] --> [Exercício EX037]

Objetivos de aprendizagem

Você vai (1) ler baselines comuns de configuração segura; (2) distinguir um achado de configuração de um achado de código; (3) propor mudanças de configuração seguras; (4) verificar com o responsável.

10.1 Achados de configuração

Configurações de TLS, flags de cookie, cabeçalhos de segurança, conjuntos de cifras da VPN e a política de senhas do AD são configuração e muitas vezes se corrigem sem lançamento de código. Achados de configuração, como uma flag de cookie ausente ou um serviço aberto na 8080, nomeiam o arquivo ou o serviço, a baseline esperada e o responsável. Os chamados de configuração citam a linha da baseline e o desvio observado, por exemplo a falta da flag Secure num cookie de sessão, com o responsável pelo planejador de viagens nomeado. Linhas vagas como "endurecer os servidores" são reescritas antes de os chamados serem abertos, porque ninguém consegue verificar a correção de uma frase que não nomeia nenhuma configuração.

10.2 Achados de código

Falhas de lógica na autorização exigem mudanças dos desenvolvedores e testes de regressão. Quando as ROE permitem acesso de leitura ao código ou à configuração dos aplicativos da NMT, Sam cita no achado o arquivo e a linha ou a chave, para que o desenvolvedor vá direto ao ponto que precisa mudar. Os binários do fornecedor de tarifas são outra história: descompilá-los continua proibido no ENG-512, seja o que for que uma ferramenta sugira. Os achados nessa área são descritos a partir do comportamento observado na homologação e encaminhados ao responsável pelas tarifas, em vez de serem sustentados por engenharia reversa.

10.3 Propostas seguras

Uma proposta segura nomeia a configuração, o sistema, o risco caso esteja errada e uma reversão. Nunca aplique você mesmo uma configuração na produção, a menos que as ROE e o processo de mudanças digam isso. As propostas de Sam preferem mudanças de configuração na homologação, com reversão, e cada uma inclui um caminho de correção na homologação e uma nota de reversão. Ele nunca propõe um ajuste só para a produção que não possa ser testado antes na zona âmbar; ideias só para a produção esperam por janelas de mudança que não pertencem a Sam. Escrever a linha de risco caso esteja errada o obriga a pensar em quais passageiros ou funcionários perceberiam primeiro uma mudança ruim.

10.4 Verificação pelo responsável

Os responsáveis aplicam as mudanças pelo próprio pipeline; Sam verifica. A verificação começa pelo responsável. O responsável pelo planejador de viagens precisa confirmar a correção na conversa do chamado e marcar a caixa do responsável antes que Sam reteste qualquer coisa. Sam deixa essa caixa em branco até que o líder tenha escrito a confirmação, e uma correção sem nome de responsável continua aberta. Correções sem dono, portanto, não podem chegar a FIXED na linguagem do lab_retest, o que impede que uma mudança pela qual ninguém responde seja relatada como encerrada. O histórico do chamado mostra então quem confirmou a mudança e quando.

10.5 Baselines

A baseline de endurecimento da NMT é a lista de verificação; desvios exigem chamados. As baselines de versões de TLS e de flags de cookie ficam na tag do runbook que as ROE nomeiam. Sam escreve os achados como desvio dessa baseline, citando o valor esperado e o valor observado, e qualquer redação do tipo "parece ruim" é reescrita antes de o relatório sair. A linguagem de desvio dá ao responsável um alvo concreto a restaurar e dá ao reteste uma condição clara de aprovação, coisa que uma opinião sobre a aparência não oferece. A mesma tag é usada de novo no reteste, para que as duas execuções meçam contra uma única baseline.

10.6 Desvio

O desvio de configuração depois de mudanças emergenciais é uma fonte recorrente de achados. Depois de uma mudança na CDN, Sam compara a homologação com o modelo datado. Se as flags de cookie regrediram, um chamado é aberto no meio da semana, mesmo sem nova janela de ENG agendada, porque esperar o próximo horário de sábado deixaria uma regressão conhecida sem nome por dias. O chamado cita a baseline e os valores observados, para que o responsável veja exatamente qual mudança introduziu o desvio e onde ele precisa ser revertido.

10.7 Reversão testada

Uma proposta de configuração sem uma reversão testada está incompleta. Sam pergunta ao responsável como ele desfaria a mudança em quinze minutos. Sam não aceita que uma mudança de configuração arriscada seja a correção até que sua reversão tenha sido treinada na homologação e o treino esteja anexado ao chamado como evidência. Uma reversão não testada é registrada como nota de risco e mantém o chamado aberto. Ninguém declara prontidão para a produção antes de esse treino existir, porque uma correção que não pode ser desfeita depressa pode transformar um achado menor numa indisponibilidade durante a janela de mudança.

10.8 Homologação primeiro

No trabalho de configuração do ENG-512, a homologação primeiro é absoluta. Achados de configuração da produção são reproduzidos na homologação, quando possível, antes de se insistir numa mudança na produção. Sam conclui a verificação na zona âmbar antes de qualquer mudança na produção ser discutida, e as mudanças na produção esperam então pelas janelas de mudança dos responsáveis, que Sam não controla. Até essas janelas acontecerem, os retestes continuam âmbar, e Sam não escreve "pronto para produção" no relatório nem no chamado. O status só muda quando os retestes âmbar passam e o responsável aplicou a mudança na produção.

10.9 Disciplina de campo

Sam mantém uma biblioteca pessoal de boas propostas de configuração (HSTS, flags de cookie, cifras da VPN) escritas no estilo dos chamados de mudança da NMT. Reaproveitar a estrutura acelera o trabalho, mas ele ainda preenche o risco e a reversão específicos do sistema a cada vez. Copiar e colar sem mudanças uma proposta feita para a homologação num chamado de produção é o caminho pelo qual se propõem cifras erradas, então ele trata cada proposta como um texto novo. A disciplina de campo para configuração é baseline, responsável, homologação primeiro e reversão testada; uma reversão que nunca rodou na homologação conta como não testada, por mais simples que pareça no papel, e a revisão por pares rejeita chamados a que falte qualquer um dos quatro.

10.10 Nota de encerramento

Sam também pergunta se uma mudança de configuração precisa de uma janela de manutenção. Mudanças de cabeçalho no proxy reverso podem ser instantâneas; mudanças de cifras da VPN podem derrubar sessões dos funcionários e exigir um comunicado. O momento faz parte de uma proposta completa. O trabalho de configuração na NMT protege os passageiros ficando longe do equipamento de tarifa e nomeando responsáveis. O sucesso do ENG-512 são baselines verificadas na web e na API, e não uma longa lista de ruído de ferramentas não verificado, e encerrar o trabalho de configuração nunca inclui uma promessa sobre o equipamento de tarifa em que Sam não tocou.

Exemplo resolvido (NMT sintética)

Sam descobre que a API de homologação não envia o Strict-Transport-Security. Ele registra um achado de configuração com o cabeçalho recomendado e pede à equipe de segurança de aplicações que o aplique pela configuração do proxy reverso.

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

• EX037 — Configuração versus código. Classifique: cabeçalho HSTS ausente; o passageiro A consegue ler as viagens do passageiro B.
  Mostrar critérios de avaliação

  Rubrica: 3 = configuração; código/lógica; 2 = invertidos; 1 = ambos configuração; 0 = nada.
• EX038 — Conteúdo da proposta. Quais quatro coisas entram numa proposta de configuração segura?
  Mostrar critérios de avaliação

  Rubrica: 3 = configuração, sistema, risco caso esteja errada, reversão; 2 = três; 1 = uma; 0 = nada.
• EX039 — Quem aplica. Quem aplica as mudanças de configuração na produção?
  Mostrar critérios de avaliação

  Rubrica: 3 = o responsável, pelo processo de mudanças; não o testador sozinho; 2 = parcial; 1 = o testador, livremente; 0 = nada.
• EX040 — Desvio. Por que mudanças emergenciais geram achados depois?
  Mostrar critérios de avaliação

  Rubrica: 3 = baselines contornadas; não revertidas; 2 = parcial; 1 = sem motivo; 0 = nada.

Síntese

Achados de configuração precisam de propostas claras e de mudanças aplicadas pelo responsável; os testadores verificam.

Continue estudando — capítulo 10 de 18

← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →