Capítulo 10 — Ética e segurança operacional em engenharia
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX019.
flowchart TD
N0["10.1 Deveres"]
N1["10.2 Quem arca com o risco"]
N2["10.3 Interações com a segurança operacional"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX019"]
Desenho lógico
flowchart LR
N0["10.1 Deveres"]
N1["10.2 Quem arca com o risco"]
N2["10.3 Interações com a segurança operacional"]
N3["Síntese"]
N0 --> N1 --> N2 --> N3 --> Q["EX019"]
[10.1 Deveres]
|
v
[10.2 Quem arca com o risco]
|
v
[10.3 Interações com a segurança operacional]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX019]
Objetivos de aprendizagem
Você vai (1) aplicar a ética profissional às decisões de migração criptográfica; (2) identificar quem arca com o risco do "colete agora, decifre depois"; (3) tratar com responsabilidade as descobertas de vulnerabilidades; e (4) evitar exagerar o risco quântico para vender produtos. O capítulo fecha o primeiro bloco de fundamentos e orienta todas as decisões de projeto posteriores.
10.1 Deveres
Os códigos de ética da engenharia põem o bem-estar público em primeiro lugar. No trabalho com PQC, isso significa proteger pessoas cujos dados continuarão sensíveis por décadas — registros médicos, jurídicos, aduaneiros e pessoais —, mesmo que o dano, se vier, venha anos depois da decisão do engenheiro. Significa também honestidade: nem minimizar o risco ("computação quântica é ficção científica") nem inflá-lo para vender ("o RSA será quebrado no ano que vem").
Para um engenheiro da BPA, honestidade significa apresentar lado a lado a faixa das estimativas de especialistas e o tempo de vida de 25 anos dos registros, sem escolher a data que convém ao orçamento.
10.2 Quem arca com o risco
Os titulares dos dados arcam com o risco do "colete agora, decifre depois", mas raramente decidem os orçamentos de migração. Um engenheiro ético torna essa assimetria visível nos memorandos de decisão: "Se adiarmos, os dados comerciais dos declarantes aduaneiros gravados de agora até a migração poderão se tornar legíveis para um adversário futuro."
O memorando então nomeia quem decide e quem seria prejudicado, para que o conselho veja que adiar transfere o risco para pessoas que não estão na sala. Quantificar a exposição, como na comparação entre 8,0 e 16,3 TB, torna a transferência concreta. Também dá aos representantes dos declarantes algo a perguntar quando a BPA prestar contas sobre a proteção de dados.
10.3 Interações com a segurança operacional
As mudanças criptográficas podem quebrar a disponibilidade: um handshake grande demais que um middlebox descarta, uma assinatura de firmware que um bootloader não consegue verificar, um certificado que um dispositivo médico rejeita. Em sistemas relacionados à segurança operacional — guindastes, controle de tráfego do porto —, uma atualização malsucedida pode parar as operações ou criar perigos. A gestão de mudanças com planos de reversão, testes em ambientes isolados e implantações escalonadas é um dever ético, não burocracia.
Na prática, a mudança de firmware dos guindastes da BPA é testada num controlador reserva, implantada num guindaste e mantida assim por uma semana antes dos demais.
10.4 Divulgação responsável e limites dos testes
Se os testes revelarem uma vulnerabilidade num produto, relate-a ao fornecedor e dê tempo para a correção antes de publicar. Nunca teste sistemas que você não está autorizado a testar e nunca execute experimentos de rebaixamento (downgrade) sobre tráfego de produção.
Para as equipes da BPA, autorização significa um escopo escrito que nomeia sistemas, datas e técnicas permitidas. Um teste de rebaixamento que remove o grupo híbrido de um ClientHello pertence a uma cópia de laboratório do portal, não ao serviço em produção, onde poderia quebrar as sessões dos parceiros. As descobertas em produtos de fornecedores vão primeiro ao fornecedor, com uma data de divulgação combinada de antemão.
10.5 Exemplo resolvido
Um fornecedor oferece à BPA um equipamento "à prova de computação quântica" que usa um algoritmo não publicado. Avaliação ética: um algoritmo não verificado não oferece garantia (o Rainbow e o SIKE foram quebrados apesar de anos de escrutínio público — Beullens 2022, Castryck e Decru 2022); o marketing exagera; o dever do engenheiro é recomendar algoritmos padronizados e dizer por quê, mesmo que o fornecedor seja amigo da direção.
A avaliação escrita vai para o conselho, e não só para o fornecedor, para que as razões sobrevivam a qualquer pressão posterior para revertê-la.
10.6 Erros comuns e limites
- Adiar a migração porque o dano está longe.
- Aceitar termos de marketing como "à prova de computação quântica".
- Implantar mudanças criptográficas em sistemas de segurança operacional sem reversão.
Adiar parece seguro porque ninguém é prejudicado neste ano, mas o tráfego aduaneiro gravado acumula exposição a cada mês que a decisão espera. Alegações de "à prova de computação quântica" devem levar a pedir o algoritmo, a sua norma e o seu histórico de revisão. Sistemas de segurança operacional como os controladores de guindaste precisam de uma reversão testada antes de qualquer mudança na assinatura de firmware, já que um dispositivo que rejeita a própria atualização pode parar as operações.
Exercícios
- EX019 — Quem arca com o risco. Para a BPA, liste três grupos que arcam com o risco quântico e como cada um é representado nas decisões. Rubrica: 3 = grupos distintos, lacuna de representação identificada.
- EX020 — Carta ao fornecedor. Escreva uma carta cordial recusando um algoritmo "à prova de computação quântica" não verificado. Rubrica: 3 = cita as normas e as quebras, oferece um caminho adiante.
Síntese
A engenharia ética de PQC protege dados de vida longa em nome de pessoas que não conseguem ver o risco, comunica com honestidade, trata disponibilidade e segurança operacional como parte da segurança e rejeita criptografia não verificada.
Continue estudando — capítulo 10 de 50
← Capítulo 09 · Índice de capítulos do curso · Capítulo 11 →
Siga para a próxima lição escrita.