Capítulo 12 — Infraestrutura crítica e segurança setorial: fluxos de dados
Mapa da aula
Aula 12 publicada. Mapa, exemplo, EX034.
flowchart TD
N0["12.1 O registro"]
N1["12.2 Classes de dados"]
N2["12.3 Verificar o registro"]
N3["12.4 Fluxos novos precisam de revisão antes de começ"]
N4["12.6 Atividade prática: conferência do registro"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX034"]
Desenho lógico
flowchart LR
N0["12.1 O registro"]
N1["12.2 Classes de dados"]
N2["12.3 Verificar o registro"]
N3["12.4 Fluxos novos precisam de revisão antes de começ"]
N4["12.6 Atividade prática: conferência do registro"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX034"]
[12.1 O registro]
|
v
[12.2 Classes de dados]
|
v
[12.3 Verificar o registro]
|
v
[12.4 Fluxos novos precisam de revisão antes de começ]
|
v
[12.6 Atividade prática: conferência do registro]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX034]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- manter um registro de fluxos de dados que anota, para cada fluxo, a sua origem, destino, classe de dados, proteção e retenção;
- classificar os dados num serviço crítico: telemetria operacional, configuração, dados pessoais e vinculados a pacientes, logs de segurança;
- verificar o registro contra o que os sistemas de fato enviam e guardam;
- reconhecer quando um fluxo novo precisa de revisão de privacidade, contratual ou de safety antes de começar.
O Capítulo 2 comparou os fluxos de rede com os conduítes declarados. Um conduíte diz que um caminho é permitido; um registro de fluxos de dados diz quais dados viajam por ele, como são protegidos e por quanto tempo são guardados na outra ponta. Nos serviços compartilhados, a segunda pergunta costuma ser a que põe uma organização em apuros, porque os dados sobrevivem ao motivo pelo qual foram coletados.
12.1 O registro
Cada entrada no registro do LANTERN anota: identificador; origem e destino (sistemas, não apenas endereços); classe de dados; se o fluxo é cifrado em trânsito; por quanto tempo o destino guarda os dados; a finalidade; o responsável; e, para dados pessoais, a base legal registrada pelo responsável pelos dados. O registro é um documento que as pessoas leem num incidente ("o que saiu do gateway do hospital?") e numa solicitação de privacidade ("para onde vão os dados da bomba deste paciente?").
A DF5 é uma entrada-modelo: gateway clínico para a Halden Cloud, vinculada a pacientes, cifrada, 30 dias registrados.
12.2 Classes de dados
Para um implementador, quatro classes cobrem a maior parte de um serviço crítico compartilhado:
- Telemetria operacional — leituras e estados (níveis, vazões, cloro). Em geral não é pessoal, mas é crítica para a integridade e às vezes sensível em conjunto (revela como a rede funciona).
- Dados de configuração e de engenharia — programas dos controladores, diagramas de rede, setpoints, configuração do relay. Altamente sensíveis: são um mapa para um atacante.
- Dados pessoais e vinculados a pacientes — qualquer coisa sobre uma pessoa identificável. No hospital, os logs de eventos das bombas de infusão ligados a uma enfermaria e a um horário podem identificar um paciente. A lei de proteção de dados se aplica; na UE, o GDPR (Regulamento (UE) 2016/679) exige, entre outros princípios, que os dados pessoais não sejam guardados por mais tempo do que o necessário para a sua finalidade.
- Logs de segurança — autenticação, fluxos, alertas. Muitas vezes contêm dados pessoais (nomes de usuário, endereços) e precisam ser protegidos e retidos de acordo com a política.
O Privacy Framework do NIST oferece uma estrutura para gerenciar o risco de privacidade junto com o risco de cibersegurança (NIST Privacy Framework).
12.3 Verificar o registro
Os registros se deterioram como os inventários. Verifique-os amostrando o que de fato acontece: quais sistemas enviam para quais (fluxos), que classe de dados há nos conteúdos (amostragem de metadados pelo responsável pelos dados, e não lendo prontuários de pacientes), se o transporte é cifrado e por quanto tempo o destino de fato guarda os dados (as suas configurações de retenção e a idade dos seus registros mais antigos). As diferenças caem em tipos conhecidos: fluxos não registrados; fluxos que enviam uma classe diferente da registrada; cifração registrada, mas ausente; retenção mais longa que a registrada.
12.4 Fluxos novos precisam de revisão antes de começar
A maioria dos problemas de fluxos de dados começa com um pedido razoável: um fornecedor quer telemetria para diagnóstico remoto; uma equipe de relatórios quer uma cópia dos eventos do gateway clínico. Antes que um fluxo desses comece, a entrada do registro é escrita e revisada — pelo responsável pelos dados, pela segurança (proteção e conduíte) e, quando há dados pessoais envolvidos, pela função de privacidade. Se ele transportar dados de controle ou de configuração, aplica-se a regra de arquitetura do Capítulo 8.
O pedido da Kell por telemetria horária dos relays é o caso de Fallowmere: a entrada precisa ser escrita e revisada antes que a primeira hora seja enviada.
12.5 Exemplo resolvido: registro versus realidade (sintético)
O Laboratório 12 compara cinco entradas do registro com sete fluxos observados. Quatro fluxos registrados coincidem. Três diferenças importam:
- DF5 — gateway clínico para a Halden Cloud — guarda dados vinculados a pacientes por 400 dias, contra os 30 registrados. O fluxo está registrado e cifrado, mas a retenção no destino não coincide. Essa é uma questão de privacidade e de contrato; o responsável pelos dados do hospital precisa ser informado, e a configuração de retenção da Halden, conferida contra o contrato.
- Um fluxo não registrado do historiador para um sistema de suporte do fornecedor, em texto claro. Ele transporta telemetria — não pessoal, mas operacionalmente sensível — sem cifração e sem que ninguém o tenha aprovado.
- Um fluxo não registrado do gateway clínico para o servidor de relatórios, transportando dados vinculados a pacientes. Cifrado, mas ninguém o aprovou, e o servidor de relatórios fica na zona corporativa usada pela equipe de água.
O terceiro é o mais grave, apesar de cifrado: dados vinculados a pacientes chegaram a um sistema e a um público sem finalidade registrada. A cifração em trânsito protege o percurso, e não o destino.
12.6 Atividade prática: conferência do registro
Laboratório 12 (salve como lab12.py, execute com python3 lab12.py):
# Lab 12 - checking a data-flow register against what the service actually sends (offline, standard library only)
# Synthetic: Fallowmere shared services. Each register entry: id, source, destination, data class, encrypted, retention days.
register = [
("DF1", "PS-*", "RLY-01", "telemetry", False, 0),
("DF2", "RLY-01", "HIST-01", "telemetry", True, 730),
("DF3", "HIST-01", "REPORTS", "telemetry-aggregate", True, 365),
("DF4", "WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("DF5", "CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 30),
]
observed = [ # source, destination, data class seen by sampling payload metadata, tls?, stored days at destination
("PS-04", "RLY-01", "telemetry", False, 0), ("RLY-01", "HIST-01", "telemetry", True, 730),
("HIST-01", "REPORTS", "telemetry-aggregate", True, 365), ("WARD-PUMPS", "CLIN-GW", "patient-linked", True, 30),
("CLIN-GW", "HALDEN-CLOUD", "patient-linked", True, 400), ("HIST-01", "VENDOR-SUPPORT", "telemetry", False, None),
("CLIN-GW", "REPORTS", "patient-linked", True, 365),
]
sensitive = {"patient-linked"}
def match(src, dst):
for r in register:
if (r[1] == src or (r[1].endswith("*") and src.startswith(r[1][:-1]))) and r[2] == dst:
return r
for src, dst, cls, enc, keep in observed:
r = match(src, dst)
if r is None:
sev = "HIGH" if cls in sensitive else "MED"
print(f"{sev:<4} unregistered flow {src}->{dst} ({cls}, encrypted={enc})")
continue
issues = []
if r[3] != cls: issues.append(f"class {cls} != registered {r[3]}")
if r[4] and not enc: issues.append("registered encrypted but sent clear")
if keep is not None and keep > r[5]: issues.append(f"kept {keep} d > registered {r[5]} d")
print(f"{'OK ' if not issues else 'HIGH' if cls in sensitive else 'MED '} {r[0]} {src}->{dst} {'; '.join(issues)}")
Saída esperada (Python 3.13.5):
OK DF1 PS-04->RLY-01
OK DF2 RLY-01->HIST-01
OK DF3 HIST-01->REPORTS
OK DF4 WARD-PUMPS->CLIN-GW
HIGH DF5 CLIN-GW->HALDEN-CLOUD kept 400 d > registered 30 d
MED unregistered flow HIST-01->VENDOR-SUPPORT (telemetry, encrypted=False)
HIGH unregistered flow CLIN-GW->REPORTS (patient-linked, encrypted=True)
A saída reproduz as três diferenças acima. Antes de agir, decida quem recebe cada uma: a retenção de 400 dias da DF5 vai para o responsável pelos dados do hospital e para quem detém o contrato com a Halden; o fluxo em texto claro do historiador para o sistema de suporte do fornecedor vai para o responsável pelos dados da Água e para a FSTS Security; e o fluxo não registrado de dados vinculados a pacientes para o servidor de relatórios vai primeiro para a função de privacidade do hospital, porque um público da zona corporativa pode já ter visto os dados.
12.7 Erros comuns e limites
- Registrar caminhos (conduítes), mas não classes de dados e retenção.
- Presumir que "cifrado" significa "aceitável".
- Tratar a telemetria operacional como inofensiva porque não é pessoal.
- Verificar as classes de dados lendo você mesmo os dados pessoais, em vez de pedir ao responsável pelos dados que amostre os metadados.
- Deixar um fluxo de fornecedor ou de relatórios começar antes que a entrada seja revisada.
O registro mostra o que é conhecido; os fluxos que saem por rotas inesperadas (mídias removíveis, o laptop de um fornecedor) precisam de outros controles.
O fluxo não registrado do gateway clínico para o servidor de relatórios é o segundo erro em ação: cifrado, e ainda assim inaceitável.
Exercícios — capítulo 12
EX034 — Faça a triagem das diferenças. Objetivo: priorizar as constatações de fluxos de dados. Entradas: a saída do Laboratório 12. Restrições: uma ação e um responsável por constatação. Etapas: (1) ordene as três constatações; (2) dê a primeira ação e o responsável; (3) diga qual precisa ser relatada a alguém fora da FSTS. Evidência esperada: tabela. Rubrica: 3 = CLIN-GW→REPORTS em primeiro lugar (dados vinculados a pacientes não aprovados num público errado: interromper o fluxo com o acordo do responsável pelos dados do hospital, avaliar), retenção da DF5 em segundo (responsável pelos dados do hospital e contrato com a Halden), texto claro para o suporte do fornecedor em terceiro (interromper ou cifrar, registrar); reconhece que a necessidade de notificação externa é decisão do responsável pelos dados e da função de privacidade; 2 = ordenação defensável, responsáveis vagos; 1 = ordena apenas pela cifração; 0 = nada.
EX035 — Escreva uma entrada do registro. Objetivo: especificar um fluxo novo antes que ele comece. Entradas: a Kell Instruments pede telemetria horária da PS-09 para diagnóstico remoto. Restrições: todos os campos do Capítulo 12 ("O registro"); inclua o conduíte e a proteção. Etapas: escreva a entrada e liste quem precisa aprová-la. Evidência esperada: entrada e aprovadores. Rubrica: 3 = origem/destino específicos (exportação do relay ou do historiador, e não a RTU diretamente), classe de dados telemetria operacional, transporte cifrado, campos e frequência mínimos, retenção limitada e contratual, finalidade, responsável, aprovações do responsável pelos dados da Água e da segurança da FSTS, com uma data de expiração; 2 = um campo fraco; 1 = "enviar dados à Kell"; 0 = nada.
EX036 — Estenda a conferência. Objetivo: acrescentar uma verificação à ferramenta. Entradas: Laboratório 12. Restrições: apenas a biblioteca padrão. Etapas: (1) acrescente uma verificação que sinalize qualquer fluxo de dados patient-linked cujo destino não esteja numa lista aprovada {"CLIN-GW", "HALDEN-CLOUD"}, mesmo que registrado; (2) registre ("DF6", "CLIN-GW", "REPORTS", "patient-linked", True, 365) e execute de novo; (3) explique por que o registro, por si só, não deveria tornar esse fluxo aceitável. Evidência esperada: código, saída, explicação. Rubrica: 3 = fluxo para REPORTS ainda sinalizado depois do registro; explicação de que o registro anota decisões, e um fluxo registrado para um público não aprovado é uma má decisão a revisar, e não um resultado limpo; 2 = o código funciona, explicação rasa; 1 = não executado; 0 = nada.
Síntese do capítulo
Um registro de fluxos de dados anota quais dados viajam para onde, como são protegidos e por quanto tempo são guardados. Classifique os dados — telemetria, configuração, pessoais e vinculados a pacientes, logs de segurança — e verifique o registro contra o que os sistemas de fato enviam e retêm. A cifração protege o percurso, e não o destino. Os fluxos novos são revisados antes de começar, pelo responsável pelos dados, pela segurança e, quando há dados pessoais envolvidos, pela função de privacidade.
Continue estudando — capítulo 12 de 30
← Capítulo 11 · Índice de capítulos do curso · Capítulo 13 →
Siga para a próxima lição escrita.