Capítulo 10 — Infraestrutura crítica e segurança setorial: configuração de controles
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["10.1 Conjuntos de regras como programas"]
N1["10.2 Padrões que corroem uma política"]
N2["10.3 Acesso remoto e de fornecedores"]
N3["10.5 Planejamento de mudanças"]
N4["10.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["10.1 Conjuntos de regras como programas"]
N1["10.2 Padrões que corroem uma política"]
N2["10.3 Acesso remoto e de fornecedores"]
N3["10.5 Planejamento de mudanças"]
N4["10.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX037"]
[10.1 Conjuntos de regras como programas]
|
v
[10.2 Padrões que corroem uma política]
|
v
[10.3 Acesso remoto e de fornecedores]
|
v
[10.5 Planejamento de mudanças]
|
v
[10.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem e conexão
Ao final deste capítulo, você deverá ser capaz de:
- traduzir os conduítes declarados (Capítulo 6) numa política de firewall de primeira correspondência com negação padrão;
- avaliar um conjunto de regras frente a fluxos de teste em código e detectar regras sombreadas e redundantes;
- reconhecer os padrões de configuração que ampliam o acesso em silêncio — regras amplas "temporárias", "duplicatas" sobrepostas, permissões para qualquer porta;
- configurar o acesso de fornecedores e o acesso remoto com prazo, com registro e roteado pela zona de gerência;
- planejar uma mudança de configuração de modo que ela possa ser verificada (Capítulo 11) e revertida.
Os Capítulos 6–9 descreveram e observaram o sistema. Este capítulo o altera, começando pelo controle que mais diretamente limita quem pode alcançar um protocolo sem autenticação: o firewall de conduíte.
10.1 Conjuntos de regras como programas
A maioria dos firewalls de rede avalia as regras de cima para baixo e aplica a primeira correspondência. O guia de firewalls do NIST descreve o desenho de políticas, a negação padrão e a gestão de conjuntos de regras (SP 800-41 Rev. 1). Pensar num conjunto de regras como um pequeno programa esclarece três defeitos:
- Regra sombreada: uma regra posterior cujo tráfego é inteiramente casado por uma regra anterior com a ação oposta. Ela nunca tem efeito, embora o seu comentário diga que tem.
- Regra redundante: uma regra posterior inteiramente casada por uma regra anterior com a mesma ação. Inofensiva hoje; confusa amanhã, quando alguém apagar a anterior.
- "Duplicata" ampliadora: uma regra que parece cópia de outra, mas tem origem, destino ou porta mais amplos. Não é redundante; é uma nova permissão.
A ordem importa; portanto, toda mudança precisa ser revisada no contexto, não como uma linha isolada.
10.2 Padrões que corroem uma política
- Regras temporárias que sobrevivem ao seu propósito ("permitir corporativo para o centro de controle durante a migração").
- Permissões para qualquer porta (
tcp any) onde era necessária uma única porta. - Sub-redes como origem onde era necessário um único host.
- Regras sem responsável, chamado ou validade.
- Acesso de gerência a partir de zonas de usuários, em vez de pelo host de salto.
As mitigações primárias da CISA para tecnologia operacional enfatizam remover a exposição à internet, trocar as senhas padrão, proteger o acesso remoto e segmentar a TI da TO (CISA primary mitigations for OT).
10.3 Acesso remoto e de fornecedores
Configure o acesso de fornecedores para que ele exista apenas quando necessário: a conta ou o caminho fica desabilitado por padrão; é habilitado para um trabalho com chamado e uma janela fixa; é autenticado com autenticação multifator no host de salto; a sessão é registrada; e um alerta dispara em qualquer uso fora de uma janela habilitada. O alerta da CISA sobre atores patrocinados pelo Estado chinês descreve atores que mantêm acesso de longo prazo a ambientes de infraestrutura crítica, inclusive por meio de contas válidas e acesso remoto (CISA AA24-038A) — o motivo pelo qual o acesso permanente é uma constatação mesmo quando ninguém o está usando indevidamente hoje.
10.4 Exemplo resolvido: o fw-01 (sintético)
A política do fw-01 entre as zonas do KVROC tem sete regras. O Laboratório 10 a verifica quanto a sombreamento e frente a cinco fluxos de teste, cada um com o resultado que a lista de conduítes espera.
Laboratório 10 (salve como lab10.py e execute com python3 lab10.py):
# Lab 10 - evaluate a first-match firewall policy and find shadowed rules (offline, stdlib)
# Synthetic conduit policy for fw-01 between Kestrel Vale zones; addresses are RFC 1918.
from ipaddress import ip_address, ip_network
rules = [ # id, action, source, destination, protocol, port (None = any)
("R1", "allow", "10.20.0.10/32", "10.10.0.0/16", "tcp", 502), # SCADA server polls stations
("R2", "allow", "10.20.0.15/32", "10.10.0.0/16", "tcp", 502), # engineering workstation
("R3", "allow", "10.90.0.20/32", "10.20.0.0/24", "tcp", 22), # jump host to control centre
("R4", "allow", "10.30.0.0/16", "10.20.0.0/24", "tcp", None), # "temporary" corporate access
("R5", "deny", "10.30.3.0/24", "10.20.0.0/24", "tcp", 3389), # intended: block RDP from desks
("R6", "allow", "10.20.0.0/24", "10.10.4.0/24", "tcp", 502), # duplicate of R1 for KW-04
("R7", "deny", "0.0.0.0/0", "0.0.0.0/0", "any", None), # default deny
]
def matches(rule, src, dst, proto, port):
_, _, s, d, p, pt = rule
return (ip_address(src) in ip_network(s) and ip_address(dst) in ip_network(d)
and p in ("any", proto) and pt in (None, port))
def covers(a, b): # does earlier rule a match everything rule b matches?
return (ip_network(b[2]).subnet_of(ip_network(a[2])) and ip_network(b[3]).subnet_of(ip_network(a[3]))
and a[4] in ("any", b[4]) and a[5] in (None, b[5]))
for i, r in enumerate(rules):
for earlier in rules[:i]:
if covers(earlier, r):
kind = "redundant" if earlier[1] == r[1] else "SHADOWED (never takes effect)"
print(f"{r[0]} {kind}: fully covered by {earlier[0]}"); break
tests = [("10.20.0.10", "10.10.4.2", "tcp", 502, "allow"), ("10.30.3.7", "10.20.0.5", "tcp", 3389, "deny"),
("10.30.3.7", "10.10.4.2", "tcp", 502, "deny"), ("10.30.8.2", "10.20.0.5", "tcp", 445, "deny"),
("10.20.0.12", "10.10.4.2", "tcp", 502, "deny")]
for src, dst, proto, port, expect in tests:
hit = next(r for r in rules if matches(r, src, dst, proto, port))
status = "PASS" if hit[1] == expect else "FAIL"
print(f"{status} {src}->{dst} {proto}/{port}: {hit[1]} by {hit[0]} (expected {expect})")
Saída esperada (Python 3.13.5):
R5 SHADOWED (never takes effect): fully covered by R4
PASS 10.20.0.10->10.10.4.2 tcp/502: allow by R1 (expected allow)
FAIL 10.30.3.7->10.20.0.5 tcp/3389: allow by R4 (expected deny)
PASS 10.30.3.7->10.10.4.2 tcp/502: deny by R7 (expected deny)
FAIL 10.30.8.2->10.20.0.5 tcp/445: allow by R4 (expected deny)
FAIL 10.20.0.12->10.10.4.2 tcp/502: allow by R6 (expected deny)
Três constatações:
- A R5 é sombreada pela R4. O comentário diz que o RDP vindo das mesas corporativas é bloqueado, mas a R4 já permitiu todo o TCP a partir de 10.30.0.0/16, de modo que a R5 nunca se aplica — o "bloqueio" nunca funcionou.
- A R4 é o problema real. Uma regra "temporária" permite todas as portas TCP da zona corporativa inteira para dentro do centro de controle. Os seus testes falham (RDP e SMB são permitidos). Repare no que os testes não mostram: a mesa corporativa até a porta 502 de uma estação é negada pela R7, de modo que o fw-01 não explica as escritas da mesa corporativa capturadas na KW-04 no Capítulo 2. Esse caminho precisa existir em outro lugar; registre-o como em aberto (o Capítulo 13 o encontra).
- A R6 não é uma duplicata da R1. Ela permite que a sub-rede inteira do centro de controle escreva na KW-04, incluindo 10.20.0.12, que não tem nada a fazer ali.
Uma mudança sólida: apagar a R4 (depois de confirmar com o responsável o que ainda a usa — os logs do firewall mostrarão); mover o bloqueio de RDP para cima de qualquer permissão, se ele ainda for necessário, ou confiar na negação padrão; substituir a R6 por nada (a R1 e a R2 já cobrem os caminhos necessários). Execute de novo o avaliador com o novo conjunto de regras antes da mudança e os testes ao vivo depois (Capítulo 11).
10.5 Planejamento de mudanças
Toda mudança de configuração num ambiente de controle precisa de: o antes e o depois exatos; o motivo (constatação ou requisito); o efeito esperado, escrito como testes; um plano de reversão; a janela combinada com as operações; e quem verifica. O guia do NIST sobre gestão de configuração focada em segurança descreve linhas de base e controle de mudanças (SP 800-128). A exportação do firewall antes e depois é evidência; calcule o seu hash (Capítulo 5).
Exporte e calcule o hash do conjunto de regras antes e depois da mudança e guarde os dois resumos no registro de mudança. Escreva o efeito esperado como os mesmos testes que o Laboratório 10 executa, para que a verificação seja uma nova execução, e não uma invenção nova. Combine a janela com as operações e nomeie quem vai confirmar que a varredura do SCADA continua atendendo ao requisito de atualidade depois da mudança.
10.6 Atividade prática
Reescreva a política do fw-01 a partir da lista de conduítes do Capítulo 6: uma regra por conduíte declarado, cada uma com chamado e responsável no comentário, e depois a negação padrão. Execute o Laboratório 10 sobre a sua versão até que os cinco testes passem e nenhuma regra seja sombreada ou redundante. Acrescente dois testes seus para o conduíte C3.
Ponha cada permissão acima da negação padrão, com chamado e responsável no comentário. Remova a R4 e a R6 em vez de tentar remendá-las. Acrescente dois testes para o conduíte C3: host de salto para o centro de controle em tcp/22 permitido, e uma mesa corporativa para a mesma porta negada. Execute de novo até que todo teste passe e nenhuma regra seja sombreada ou redundante.
10.7 Erros comuns e limites
- Revisar uma regra nova sem ler as regras acima dela, que podem já permitir ou negar o mesmo tráfego.
- Apagar uma regra ampla sem verificar nos logs os seus usuários atuais.
- Tratar "parece uma duplicata" como "pode ficar".
- Configurar o acesso de fornecedores como permanentemente habilitado "para emergências".
-
O Laboratório 10 modela uma política de primeira correspondência sem estado, com contenção exata; firewalls reais acrescentam estado, objetos, NAT e zonas, e têm as suas próprias ferramentas de análise.
-
Estreitar a R4 para corrigir as falhas em tcp/3389 e tcp/445 sem antes verificar nos logs quais hosts corporativos dependem dela hoje.
- Habilitar a conta de um fornecedor para um serviço com chamado e esquecer de desabilitá-la quando a janela fixa termina.
Exercícios — capítulo 10
EX037 — Explique o sombreamento. Objetivo: raciocinar sobre a ordem. Insumos: Laboratório 10. Passos: (1) mover a R5 para cima da R4 e prever os resultados dos testes; (2) executar e comparar. Evidência esperada: previsão e saída. Rubrica: 3 = nenhum sombreamento relatado; o teste 2 (RDP) passa (negado pela R5); o teste 4 (SMB) continua falhando (permitido pela R4); o teste 5 continua falhando (R6); 2 = quase tudo; 1 = palpites; 0 = nada.
EX038 — Conserte a política. Objetivo: produzir um conjunto de regras correto. Insumos: Laboratório 10. Passos: remover a R4 e a R6 (manter a R5 ou removê-la com justificativa); executar. Evidência esperada: nova lista de regras e saída com cinco linhas PASS. Rubrica: 3 = cinco linhas PASS; justificativa para a R5 (redundante com a negação padrão quando a R4 sai, portanto remover ou manter para um registro explícito); observa a necessidade de verificar antes nos logs os usuários da R4; 2 = passa, sem justificativa; 1 = parcial; 0 = nada.
EX039 — Configuração do acesso de fornecedores. Objetivo: configurar um acesso com prazo. Insumos: o fornecedor dos relés da SS-3 precisa de acesso remoto cerca de duas vezes por ano. Passos: especificar o estado da conta, as etapas de habilitação, o caminho, a autenticação, o registro, os alertas e a validade. Evidência esperada: uma especificação de configuração. Rubrica: 3 = desabilitada por padrão; habilitada pelo plantão do KVROC mediante um chamado aprovado pela Kestrel Grid; caminho pelo jump-01 com MFA e gravação da sessão; nunca diretamente para a rede dos relés; alerta em uso fora de uma janela; validade automática; revisão no dia seguinte; 2 = falta um elemento; 1 = "VPN para o fornecedor"; 0 = nada.
EX040 — Detecte ampliações. Objetivo: estender o avaliador. Insumos: a covers do Laboratório 10. Passos: acrescentar uma verificação que relate quando uma regra posterior com a mesma ação se sobrepõe parcialmente a uma anterior e é mais ampla na origem ou no destino. Evidência esperada: código e saída. Rubrica: 3 = relata a R6 como ampliação da R1 (a origem /24 contém a /32 da R1; o destino /24 está dentro do /16; mesma porta), explica por que isso merece revisão; 2 = detecta, sem explicação; 1 = tentativa; 0 = nada.
Síntese do capítulo
Um conjunto de regras de firewall é um programa de primeira correspondência, e os seus defeitos são defeitos de programa: regras sombreadas que nunca agem, regras redundantes que confundem e regras parecidas que ampliam o acesso. Configure os conduítes com uma regra por propósito declarado e negação padrão, mantenha o acesso de fornecedores desabilitado até ser necessário e planeje cada mudança com os seus testes e a sua reversão. Depois, verifique, que é o assunto do próximo capítulo.
Continue estudando — capítulo 10 de 18
← Capítulo 09 · Índice de capítulos do curso · Capítulo 11 →
Siga para a próxima lição escrita.