Capítulo 10 — Arquitetura e engenharia de segurança: configuração de controles
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["10.1 Escrever as regras"]
N1["Laboratório — Teste de fluxos contra a lista de regr"]
N2["10.2 Documentar o propósito"]
N3["10.3 Revisar as regras"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["10.1 Escrever as regras"]
N1["Laboratório — Teste de fluxos contra a lista de regr"]
N2["10.2 Documentar o propósito"]
N3["10.3 Revisar as regras"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX037"]
[10.1 Escrever as regras]
|
v
[Laboratório — Teste de fluxos contra a lista de regr]
|
v
[10.2 Documentar o propósito]
|
v
[10.3 Revisar as regras]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) configurar as regras de firewall entre segmentos; (2) documentar o propósito de cada regra; (3) revisar as regras em busca de erros.
10.1 Escrever as regras
Nadia transforma o projeto segmentado do capítulo 6 em regras de firewall para o roteador de Elmfield. Cada regra nomeia um segmento de origem, um destino, uma porta e uma ação. Os PCs dos consultórios podem alcançar o servidor de imagens na porta do visualizador. O servidor de imagens pode alcançar os backups do escritório central pela VPN. As maquininhas de cartão podem alcançar apenas os endereços do provedor de pagamentos. Os visitantes podem alcançar apenas a internet. Uma regra final nega todo o resto entre os segmentos. A ordem importa: os roteadores aplicam a primeira regra que corresponde, então as permissões específicas vêm antes da negação geral.
Laboratório — Teste de fluxos contra a lista de regras
# Test expected and forbidden flows against an ordered rule list (synthetic).
def allowed(rules, src, dst, port):
for s, d, p, act in rules:
if s in (src, "*") and d in (dst, "*") and p in (port, "*"): return act == "allow"
return False
tests = [("surgery", "imaging", 8443, True), ("imaging", "backup", 445, True), ("payment", "provider", 443, True),
("guest", "internet", 443, True), ("reception", "imaging", 8443, False), ("guest", "imaging", 8443, False),
("reception", "payment", 443, False)]
v1 = [("staff", "imaging", 8443, "allow"), ("imaging", "backup", 445, "allow"), ("payment", "provider", 443, "allow"),
("guest", "internet", "*", "allow"), ("*", "*", "*", "deny")]
seg = {"surgery": "staff", "reception": "staff"}
v2 = [("surgery", "imaging", 8443, "allow")] + v1[1:]
for name, rules, mapping in (("first draft", v1, seg), ("split segments", v2, {})):
fails = [t for t in tests if allowed(rules, mapping.get(t[0], t[0]), t[1], t[2]) != t[3]]
print(f"{name}: {len(tests) - len(fails)}/{len(tests)} pass; failures {[(f[0], f[1], f[2]) for f in fails]}")
Execute com python3 lab_fw.py. Saída verificada:
first draft: 6/7 pass; failures [('reception', 'imaging', 8443)]
split segments: 7/7 pass; failures []
10.2 Documentar o propósito
Ao lado de cada regra, Nadia escreve seu propósito e seu responsável, como "visualização de raio X nos consultórios, responsável Grace". As regras sem propósito documentado são as que se acumulam e nunca são removidas, porque ninguém se atreve a apagá-las. Ela guarda a lista de regras com o diagrama de rede. Quando, mais tarde, um fornecedor pede uma nova regra, Grace consegue conferir se ela se encaixa no projeto e registrar por que foi acrescentada, mantendo o conjunto de regras compreensível por anos. A lista de regras é revisada uma vez por ano junto com o diagrama de rede.
10.3 Revisar as regras
Antes de aplicar as regras, Nadia as testa com um pequeno script que confere uma lista de fluxos esperados e proibidos. O laboratório mostra que todos os fluxos esperados são permitidos, mas que um fluxo proibido, dos PCs da recepção para o servidor de imagens, também é permitido, porque ela escreveu a regra dos consultórios para todo o segmento da equipe. Ela divide a equipe em segmentos de recepção e de consultórios e roda o teste de novo, que então passa. Testar as regras antes de aplicá-las evita tanto indisponibilidades quanto lacunas. Ela guarda a lista de testes para reutilizá-la depois da implantação.
Exemplo resolvido
Nadia escreve regras de segmentos ordenadas, com propósitos e responsáveis, testa fluxos esperados e proibidos e corrige uma regra ampla demais.
Caso sintético. As regras e os segmentos são sintéticos.
Erros e limites
Os testes cobrem apenas os fluxos listados. A sintaxe do roteador difere do modelo de teste.
Exercícios
-
EX037 — Ordem das regras. Por que as permissões específicas precisam vir antes da negação geral? Rubrica: 3 = os roteadores aplicam a primeira regra que corresponde;; 2 = primeira correspondência;; 1 = vago;; 0 = nenhuma.
-
EX038 — Regras não documentadas. Por que as regras não documentadas se acumulam? Rubrica: 3 = ninguém se atreve a apagá-las;; 2 = medo;; 1 = vago;; 0 = nenhuma.
-
EX039 — Falha no laboratório. Que fluxo proibido o primeiro teste permitiu? Rubrica: 3 = recepção para imagens na porta 8443;; 2 = recepção;; 1 = vago;; 0 = nenhuma.
-
EX040 — Correção. Como Nadia corrigiu a regra ampla? Rubrica: 3 = dividindo a equipe em segmentos de recepção e de consultórios;; 2 = dividir;; 1 = vago;; 0 = nenhuma.
Síntese
Regras ordenadas, documentadas e testadas transformam um desenho de segmentação em uma configuração funcional.
Continue estudando — aula 10 (capítulo 10 de 18)
← Capítulo 09 · Índice das aulas · Capítulo 11 →
Continue para a próxima aula já escrita.