Capítulo 16 — Arquitetura de segurança
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 Zonas"]
N1["16.2 Fluxos"]
N2["16.3 Falhar fechado"]
N3["16.4 Conduítes"]
N4["16.5 Terceiros"]
N5["16.6 Diagramas"]
N6["16.7 Detectar mudanças de regras durante um engajame"]
N7["16.8 Contatar os donos dos conduítes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 Zonas"]
N1["16.2 Fluxos"]
N2["16.3 Falhar fechado"]
N3["16.4 Conduítes"]
N4["16.5 Terceiros"]
N5["16.6 Diagramas"]
N6["16.7 Detectar mudanças de regras durante um engajame"]
N7["16.8 Contatar os donos dos conduítes"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[16.1 Zonas]
|
v
[16.2 Fluxos]
|
v
[16.3 Falhar fechado]
|
v
[16.4 Conduítes]
|
v
[16.5 Terceiros]
|
v
[16.6 Diagramas]
|
v
[16.7 Detectar mudanças de regras durante um engajame]
|
v
[16.8 Contatar os donos dos conduítes]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) desenhar as zonas do TRB; (2) impor matrizes de fluxo; (3) falhar fechado.
16.1 Zonas
Internet, DMZ, corporativa, vizinha dos pagamentos (restrita), avaliação. Uma zona agrupa sistemas que compartilham um nível de confiança e as mesmas regras sobre o que pode alcançá-los. A zona de internet do TRB não é confiável. A DMZ abriga o front-end público do banco, que precisa falar tanto com a internet quanto com o núcleo. A zona corporativa abriga os notebooks dos funcionários e o e-mail. A zona vizinha dos pagamentos é restrita porque faz fronteira com o gateway SWIFT e com o razão, e a zona de avaliação abriga a plataforma de testes. Os testadores leem um achado pelas zonas que ele atravessa. Um caminho da zona corporativa direto para a zona vizinha dos pagamentos é grave mesmo quando o sistema na outra ponta é apenas moderadamente sensível.
16.2 Fluxos
A matriz aprovada é a referência; o lab_flows sinaliza web→ledger-db.
"""Lab 22: flag synthetic TRB data flows missing from the approved flow register."""
approved = {("branch-pc","core-api"), ("web","core-api"), ("core-api","ledger-db"), ("jump","ledger-db")}
seen = [("branch-pc","core-api"), ("web","core-api"), ("core-api","ledger-db"), ("web","ledger-db"), ("jump","ledger-db")]
for s, d in seen:
print(f"{s:10} -> {d:10} {'approved' if (s,d) in approved else 'UNAPPROVED'}")
Execute com python3 lab_flows.py. Saída verificada:
branch-pc -> core-api approved
web -> core-api approved
core-api -> ledger-db approved
web -> ledger-db UNAPPROVED
jump -> ledger-db approved
O registro é a declaração de intenção do banco, e o tráfego observado é a evidência do que de fato acontece. O laboratório compara os dois e relata os fluxos vistos, mas nunca aprovados. Um caminho direto da camada web para o banco de dados do razão contorna a API central, onde ficam a autorização e as verificações de entrada; assim, qualquer coisa que comprometa o servidor web poderia alcançar o razão sem essas verificações. O achado registra quando o fluxo foi observado, sua origem e seu destino e o fato de que nenhuma entrada do registro nem ticket de mudança o cobre.
16.3 Falhar fechado
Proxies e o TrackScope negam quando a política está ausente. Um controle que falha fechado bloqueia tráfego ou ações quando não consegue decidir, por exemplo porque seu arquivo de política está ausente, seu banco de dados está inalcançável ou uma regra está malformada. Um controle que falha aberto deixa tudo passar nesses casos, o que é conveniente durante uma indisponibilidade e desastroso se um atacante conseguir provocar a falha. Sam testa esse comportamento com segurança em staging. Ele renomeia o arquivo de política do TrackScope e confirma que a plataforma se recusa a iniciar um teste, em vez de rodar sem verificações de escopo. O teste do proxy funciona da mesma forma: com seu conjunto de regras indisponível, as requisições de saída precisam ser recusadas.
16.4 Conduítes
Regras de firewall com dono. Um conduíte é o caminho aprovado entre duas zonas, formado pelas regras de firewall, portas e protocolos que deixam uma zona falar com outra. Todo conduíte precisa de um dono, a pessoa que consegue explicar por que o caminho existe, aprovar mudanças e decidir se ele ainda é necessário. Regras sem dono se acumulam: uma porta aberta para uma migração anos atrás permanece porque ninguém sabe se removê-la vai quebrar algo. Quando Sam encontra tráfego usando um conduíte, a primeira pergunta não é se a regra o permite, mas quem é o dono da regra, porque só essa pessoa pode dizer se o tráfego é intencional.
16.5 Terceiros
Os processadores precisam de sua própria autorização. O TRB usa empresas externas para códigos únicos por SMS, processamento de cartões e hospedagem em nuvem. Os sistemas delas aparecem nos diagramas de arquitetura do TRB, mas o TRB não é dono deles e não pode autorizar ninguém a testá-los. Testar o serviço de um fornecedor geralmente exige a permissão escrita do fornecedor, sob seus próprios termos, e alguns provedores de nuvem publicam regras sobre o que os clientes podem testar em seu próprio tenant. Sam pode testar como os sistemas do TRB usam um serviço de terceiro, por exemplo se o banco valida as respostas do fornecedor, deixando em paz a infraestrutura do fornecedor, a menos que ele tenha dado seu aval.
16.6 Diagramas
Datados e com dono. Um diagrama de arquitetura é uma afirmação sobre como os sistemas estão conectados num momento específico, e um diagrama sem data convida testadores e auditores a confiar numa imagem que pode ter anos. Todo diagrama do TRB traz uma data, um dono e a versão do registro de fluxos que reflete. Antes de um engajamento, Sam confere que a data do diagrama é posterior à última mudança importante nos sistemas do escopo. Se não for, a primeira tarefa é confirmar o layout atual com o dono. Testar contra um diagrama desatualizado pode significar deixar passar caminhos novos ou, pior, sondar endereços que agora pertencem a algo fora do escopo.
16.7 Detectar mudanças de regras durante um engajamento
Os trechos da matriz recebem hash e são armazenados ao lado das ROE. Se a rede mudar no meio do engajamento, Sam compara as regras vivas com o hash e pausa se divergirem sem um ticket de mudança. O hash fixa o ambiente para o qual a autorização foi escrita. Se as regras mudam durante a janela, o teste pode agora alcançar lugares que o escopo presumia inalcançáveis, ou os resultados podem refletir uma configuração temporária em vez da normal. Pausar dá ao dono do conduíte tempo para confirmar que a mudança foi intencional. Se foi, o escopo é reconferido contra as novas regras. Se não foi, uma mudança inesperada é, ela mesma, algo que o banco precisa saber.
16.8 Contatar os donos dos conduítes
Cada conduíte lista um plantonista. Durante os testes, Sam manda mensagem ao plantonista do conduíte, e não a uma caixa geral de TI, quando as regras se comportam mal. Uma caixa geral é lida por quem estiver livre, talvez horas depois, e essa pessoa pode não conhecer o conduíte nem ter autoridade para mudá-lo. Durante uma janela de testes, os dois atrasos importam. Se uma regra de firewall bloqueia inesperadamente o teste, ou permite inesperadamente algo que não deveria, a pessoa dona desse conduíte pode decidir depressa se pausa, corrige a regra ou continua. O contato do plantão está listado no registro de fluxos ao lado do conduíte, para que os testadores não tenham de descobrir para quem ligar enquanto algo está dando errado.
16.9 Marcar os fluxos que precisam de autorização de terceiros
As matrizes de fluxo incluem uma coluna "precisa de autorização de terceiro?". Linhas com "sim" não podem ser testadas apenas sob as ROE do TRB. A coluna torna visível uma fronteira jurídica no lugar onde os testadores planejam seu trabalho. Um fluxo da API central do TRB para o endpoint do fornecedor de SMS é marcado com "sim". Sam pode observar o que o TRB envia e recebe, mas não pode sondar o endpoint do fornecedor em busca de fraquezas. A coluna é preenchida por quem registra o fluxo, e não pelos testadores, de modo que a decisão é tomada por pessoas que conhecem os contratos. Quando uma linha com "sim" importa para um engajamento, o plano inclui pedir a permissão do fornecedor ou registrar a lacuna no relatório.
16.10 Uma regra temporária sem expiração
Quando o lab_flows mostra web→ledger-db, a equipe de redes alega que a regra é temporária. Sam pede o ticket de mudança e a data de desativação. Nenhum dos dois existe. Temporário sem expiração vira o achado de processo gêmeo do F3. O achado técnico é o caminho aberto. O achado de processo é que uma regra pôde ser acrescentada como temporária sem nenhum mecanismo para removê-la. Corrigir só o primeiro fecharia esta regra e deixaria a próxima regra temporária com a mesma chance de persistir. O achado de processo recomenda que o fluxo de mudanças de firewall exija uma data de expiração para regras temporárias e alerte o dono uma semana antes dela.
16.11 Encaminhar um testador curioso ao programa do fornecedor
A coluna de terceiros com "sim" barrou uma varredura curiosa do fornecedor de SMS. Em vez disso, Sam enviou o link do bug bounty do fornecedor. Fronteiras ainda podem ser úteis. A curiosidade do colega era razoável, já que o endpoint do fornecedor parecia antigo e provavelmente tinha problemas. Varrê-lo a partir da rede do TRB sob as regras do TRB teria sido um teste não autorizado de outra empresa. O bug bounty do fornecedor define o que os pesquisadores podem testar, como e com que proteção jurídica. Segui-lo, com equipamento pessoal e em tempo pessoal, onde o programa permite, manteve o interesse legítimo e deixou o TRB de fora.
16.12 Tornar visíveis as datas de expiração
Os convites de calendário para as datas de desativação incluem o alias do CISO como participante opcional, para dar visibilidade. O convite é criado quando uma regra temporária é aprovada e cai na sua data de expiração. O dono é o participante obrigatório. O gabinete do CISO é opcional, o que significa que não se espera que aja, mas pode ver a lista completa de regras temporárias simplesmente abrindo o calendário. No dia, o dono remove a regra ou a prorroga com uma nova aprovação e uma nova data. Um convite sobre o qual ninguém age fica no calendário compartilhado como um evento passado sem ticket de mudança, o que torna a falha fácil de encontrar.
16.13 Ligar achados técnicos e de processo
Os achados de processo gêmeos se ligam ao F3 por um campo de id relacionado. Os conselhos veem juntas a dívida técnica e a de processo. Sem a ligação, os dois achados viajam separados. O técnico é corrigido rapidamente e some dos relatórios, enquanto o de processo espera num backlog de governança sem conexão visível com nenhuma exposição real. O campo de id relacionado os mantém juntos, de modo que um relatório ao conselho mostra que existiu um caminho aberto grave e por que ele pôde existir. Os revisores não fecham o achado técnico como resolvido na raiz enquanto seu gêmeo de processo ainda está aberto.
16.14 Plantão de arquitetura
O plantão de arquitetura usa um projetor e uma caneta vermelha. Conduítes sem dono são circulados até que um dono apareça no registro. Sam se recusa a agendar testes por conduítes sem dono, mesmo que a regra de firewall exista. A titularidade faz parte da autorização. Um conduíte circulado permanece no diagrama projetado de semana em semana, o que põe uma pressão pública e gentil sobre a equipe dona daquela regra de firewall. Recusar testar por conduítes sem dono não é obstrução. Sem um dono, não há ninguém que possa aceitar o risco do teste, pausá-lo ou explicar resultados inesperados; portanto, falta a precondição para o teste autorizado.
Exemplo resolvido (TRB sintético)
O lab_flows imprime web -> ledger-db UNAPPROVED; Sam abre o F3.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX046 — Par não aprovado. Qual fluxo está UNAPPROVED no laboratório? Rubrica: 3 = web→ledger-db; 2 = parcial; 1 = branch-pc→core-api; 0 = nada.
- EX047 — Falhar fechado. Com a política ausente, o TrackScope deve… Rubrica: 3 = negar os testes; 2 = parcial; 1 = permitir; 0 = nada.
- EX048 — Terceiro. As ROE do TRB sozinhas podem autorizar o teste de um processador de cartões? Rubrica: 3 = não; é preciso a autorização do processador; 2 = não; 1 = sim; 0 = nada.
Síntese
Arquitetura é zonas, fluxos com dono e padrões que falham fechados.
Continue estudando — capítulo 16 de 40
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →