Capítulo 22 — Arquitetura e engenharia de segurança: dados e dependências
Mapa da aula
Aula 22 publicada. Mapa, exemplo, EX064.
flowchart TD
N0["22.1 Classificar os dados"]
N1["22.2 Mapear as dependências"]
N2["Laboratório — Contagem das funções afetadas por cada"]
N3["22.3 Pontos únicos de falha"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX064"]
Desenho lógico
flowchart LR
N0["22.1 Classificar os dados"]
N1["22.2 Mapear as dependências"]
N2["Laboratório — Contagem das funções afetadas por cada"]
N3["22.3 Pontos únicos de falha"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX064"]
[22.1 Classificar os dados]
|
v
[22.2 Mapear as dependências]
|
v
[Laboratório — Contagem das funções afetadas por cada]
|
v
[22.3 Pontos únicos de falha]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX064]
Objetivos de aprendizagem
Você vai (1) classificar os dados da Fernway; (2) mapear as dependências de fornecedores e serviços; (3) identificar pontos únicos de falha.
22.1 Classificar os dados
Lucas propõe três classes de dados para a Fernway: públicos, como as descrições de produtos; internos, como os níveis de estoque e as escalas; e confidenciais, como os dados dos associados, os registros dos funcionários e os contratos com fornecedores. Cada classe tem regras de manuseio para armazenamento, compartilhamento e descarte. Ele mantém o esquema pequeno porque a equipe precisa aplicá-lo sem manuais de treinamento. Ele rotula os principais repositórios de dados com sua classe e descobre que uma pasta do drive compartilhado chamada "misc" guarda registros confidenciais de funcionários ao lado de imagens públicas de marketing, o que significa que qualquer pessoa com acesso de marketing pode ler os dados da folha de pagamento.
22.2 Mapear as dependências
Lucas lista todos os serviços externos dos quais a Fernway depende: hospedagem, pagamentos, e-mail, entregas, identidade, contabilidade e o feed de preços do fornecedor. Para cada um, registra os dados compartilhados, o responsável pelo contrato, se o fornecedor tem compromissos de segurança e o que acontece se o serviço falhar. O laboratório abaixo modela as dependências como um grafo e conta quantas funções de negócio cada serviço sustenta. A identidade e a hospedagem sustentam, cada uma, todas as funções online, então sua falha pararia quase tudo de uma vez, enquanto o feed de preços afeta só as atualizações de preços.
Laboratório — Contagem das funções afetadas por cada dependência
# Count business functions depending on each service (synthetic map).
deps = {"online sales": ["hosting", "identity", "payment", "email"],
"click-and-collect": ["hosting", "identity", "email"],
"delivery tracking": ["hosting", "identity", "delivery"],
"member accounts": ["hosting", "identity", "email"],
"pricing updates": ["hosting", "identity", "price feed"],
"month-end accounts": ["accounting"]}
count = {}
for f, svcs in deps.items():
for s in svcs: count[s] = count.get(s, 0) + 1
for s, n in sorted(count.items(), key=lambda x: (-x[1], x[0])): print(f"{s:11} supports {n} function(s)")
Execute com python3 lab_deps.py. Saída verificada:
hosting supports 5 function(s)
identity supports 5 function(s)
email supports 3 function(s)
accounting supports 1 function(s)
delivery supports 1 function(s)
payment supports 1 function(s)
price feed supports 1 function(s)
22.3 Pontos únicos de falha
A contagem de dependências mostra onde a resiliência mais importa. Lucas recomenda um procedimento manual de contingência documentado para a identidade, como uma conta break-glass lacrada, e a confirmação de que o plano do provedor de hospedagem inclui a recuperação numa segunda região. Para o provedor de pagamentos, ele indica um compromisso contratual em vez de redundância técnica, já que um segundo provedor de pagamentos custaria mais do que o risco justifica. Ele explica que nem todo ponto único de falha precisa ser eliminado; alguns são aceitos conscientemente, com um plano de recuperação e um responsável que acompanha o fornecedor.
Exemplo resolvido
Lucas define três classes de dados, encontra registros confidenciais numa pasta misturada, mapeia sete dependências e as ordena pelas funções afetadas.
Caso sintético. Os dados, os serviços e as contagens são sintéticos.
Erros e limites
Os mapas de dependências deixam de fora as quartas partes, os fornecedores dos fornecedores. As classificações derivam sem revisão periódica.
Exercícios
-
EX064 — Pasta misturada. O que havia de errado com a pasta misc? Rubrica: 3 = registros confidenciais de funcionários ao lado de imagens públicas, legíveis pelo marketing;; 2 = classes misturadas;; 1 = vago;; 0 = nenhuma.
-
EX065 — Dependência mais ampla. Que serviços sustentaram mais funções no laboratório? Rubrica: 3 = identidade e hospedagem, 5 funções cada;; 2 = identidade;; 1 = feed de preços;; 0 = nenhuma.
-
EX066 — Aceitar uma dependência. Por que manter um único provedor de pagamentos? Rubrica: 3 = um segundo custaria mais do que o risco; coberto por contrato e um plano;; 2 = custo;; 1 = precisa eliminar;; 0 = nenhuma.
Síntese
Classificar os dados e contar as dependências mostra para onde deve ir o esforço de proteção e de resiliência.
Continue estudando — aula 22 (capítulo 22 de 40)
← Capítulo 21 · Índice das aulas · Capítulo 23 →
Continue para a próxima aula já escrita.