OpenCyber Academy
Curso rápido · Capítulo 3 · Português
Código do curso: OCA-005Capítulo 03: OCA-005-C003

Capítulo 3 — Governança, riscos e compliance de segurança: sistemas, dados e dependências

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 03 publicada. Mapa, exemplo, EX055.

flowchart TD
  N0["3.1 De serviços a componentes"]
  N1["3.2 Como ler o mapa de dependências"]
  N2["Laboratório — Mapa de dependências e donos da Norths"]
  N3["3.3 Os dados e para onde eles vão"]
  N4["3.4 Dependências fora da organização"]
  N5["3.5 Do mapa aos cenários e às evidências"]
  N6["Conceitos — a listagem conta nomes, não entrega uma"]
  N7["Fluxo de decisão — três perguntas, três linhas difer"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX055"]

Desenho lógico

flowchart LR
  N0["3.1 De serviços a componentes"]
  N1["3.2 Como ler o mapa de dependências"]
  N2["Laboratório — Mapa de dependências e donos da Norths"]
  N3["3.3 Os dados e para onde eles vão"]
  N4["3.4 Dependências fora da organização"]
  N5["3.5 Do mapa aos cenários e às evidências"]
  N6["Conceitos — a listagem conta nomes, não entrega uma"]
  N7["Fluxo de decisão — três perguntas, três linhas difer"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX055"]

[3.1 De serviços a componentes]
    |
    v
[3.2 Como ler o mapa de dependências]
    |
    v
[Laboratório — Mapa de dependências e donos da Norths]
    |
    v
[3.3 Os dados e para onde eles vão]
    |
    v
[3.4 Dependências fora da organização]
    |
    v
[3.5 Do mapa aos cenários e às evidências]
    |
    v
[Conceitos — a listagem conta nomes, não entrega uma]
    |
    v
[Fluxo de decisão — três perguntas, três linhas difer]
    |
    v
[Exemplo resolvido] --> [Exercício EX055]

Objetivos de aprendizagem

Você vai (1) mapear os sistemas e os dados por trás de cada serviço prioritário; (2) encontrar dependências compartilhadas e componentes sem dono; (3) transformar o mapa em cenários de risco e pedidos de evidência.

3.1 De serviços a componentes

O capítulo 1 pediu à Northstar que nomeasse seus serviços antes de escolher produtos. O passo seguinte é listar do que cada serviço depende. O portal de agendamento precisa de um web host, do banco de dados de agendamento, do provedor de identidade que autentica a equipe e de um relay de e-mail que envia as confirmações. A gestão de casos precisa de seu próprio banco de dados, do provedor de identidade e de um armazenamento de arquivos para documentos. A escala de voluntários é uma planilha compartilhada que também usa o provedor de identidade e o relay de e-mail para lembretes. Escrever essas listas com os donos dos serviços é rápido e costuma surpreendê-los, porque poucas pessoas enxergam a cadeia inteira por trás de um serviço que usam todos os dias.

3.2 Como ler o mapa de dependências

O laboratório transforma as listas em um pequeno mapa. O provedor de identidade sustenta os três serviços, de modo que uma falha ou um comprometimento ali afetaria tudo de uma só vez. O relay de e-mail sustenta dois serviços, mas não tem dono. A planilha da escala também não tem dono. Todos os demais componentes têm. Esses dois fatos mudam as prioridades do capítulo 1. Um teste de restauração do banco de dados de agendamento continua valioso, mas, se a equipe não conseguir se autenticar, uma restauração perfeita não reabrirá o portal. Por isso o mapa acrescenta o provedor de identidade ao escopo do exercício de restauração e acrescenta a definição de donos para o relay de e-mail e para a escala à lista de decisões do diretor de operações.

Laboratório — Mapa de dependências e donos da Northstar

"""Northstar dependency map: which services each component supports, and unowned components."""
deps = {"appointment portal": ["web host", "scheduling database", "identity provider", "email relay"],
        "case management": ["case database", "identity provider", "file storage"],
        "volunteer roster": ["roster spreadsheet", "identity provider", "email relay"]}
owners = {"web host": "IT", "scheduling database": "IT", "identity provider": "IT", "case database": "Casework",
          "file storage": "IT", "email relay": None, "roster spreadsheet": None}
use = {}
for s, cs in deps.items():
    for c in cs: use.setdefault(c, []).append(s)
for c, ss in sorted(use.items(), key=lambda x: -len(x[1])):
    print(f"{c}: supports {len(ss)} service(s); owner {owners[c] or 'NONE'}")
print("shared by all three:", [c for c, ss in use.items() if len(ss) == 3])

Execute com python3 lab_deps.py. Saída verificada:

identity provider: supports 3 service(s); owner IT
email relay: supports 2 service(s); owner NONE
web host: supports 1 service(s); owner IT
scheduling database: supports 1 service(s); owner IT
case database: supports 1 service(s); owner Casework
file storage: supports 1 service(s); owner IT
roster spreadsheet: supports 1 service(s); owner NONE
shared by all three: ['identity provider']

3.3 Os dados e para onde eles vão

Sistemas guardam dados, e dados criam obrigações. O banco de dados de agendamento da Northstar guarda nomes de clientes, dados de contato e motivos das consultas, alguns dos quais podem revelar problemas de saúde ou dificuldades financeiras. A gestão de casos guarda anotações detalhadas dos casos. A escala guarda os dados de contato dos voluntários. Para cada um, a equipe registra que dados existem, por que são mantidos, quem pode vê-los, para onde vão as cópias e por quanto tempo são retidos. Ela descobre que as confirmações de consulta enviadas pelo relay de e-mail incluem o motivo da consulta, o que é mais do que os clientes precisam receber por e-mail. Reduzir esse conteúdo é uma mudança barata que diminui o risco de privacidade sem afetar o serviço.

3.4 Dependências fora da organização

Vários componentes são operados por fornecedores: o web host, o provedor de identidade e o relay de e-mail. A Northstar não pode inspecionar o funcionamento interno deles, mas pode perguntar que garantias oferecem, ler seus termos sobre indisponibilidades e tratamento de dados e verificar se consegue exportar seus dados caso precise sair. O NIST CSF 2.0 situa a gestão de riscos da cadeia de suprimentos dentro da função Govern, o que corresponde à situação da Northstar: o conselho não precisa de detalhes técnicos, mas precisa saber quais serviços dependem de fornecedores e se alguém os verificou. A equipe registra cada fornecedor, o serviço que ele sustenta, as evidências disponíveis e a data da última revisão.

3.5 Do mapa aos cenários e às evidências

O mapa produz cenários mais precisos no formato do capítulo 1. Se o provedor de identidade ficar indisponível, a equipe não consegue acessar nenhum serviço, e a Northstar não testou uma forma alternativa de autenticação. Se o relay de e-mail sem dono estiver mal configurado, confirmações de consulta podem chegar às pessoas erradas, e ninguém revisa suas configurações. Se a planilha da escala estiver compartilhada de forma ampla demais, os dados de contato dos voluntários podem ficar expostos, e o acesso nunca foi revisado. Cada cenário nomeia um pedido de evidência: o histórico de status e as opções de contingência do provedor de identidade, a configuração do relay e a lista de compartilhamento da escala. Pedidos de evidência mantêm a estratégia honesta, porque mostram quais crenças foram verificadas e quais ainda são premissas.

Exemplo resolvido

A Northstar lista os componentes por trás de três serviços, descobre que o provedor de identidade é compartilhado pelos três e que há dois componentes sem dono, retira os motivos das consultas dos e-mails e escreve três cenários sustentados por evidências.

Caso sintético. Todos os sistemas, fornecedores e dados da Northstar são fictícios; o NIST CSF 2.0 e o NIST Privacy Framework são reais.

Erros e limites

Mapas omitem ferramentas informais usadas pela equipe. As garantias dos fornecedores variam de escopo. Um componente compartilhado pode ter redundância oculta que o mapa não mostra.

Conceitos — a listagem conta nomes, não entrega uma chave

O programa do laboratório monta um dicionário de apoios. Cada componente reúne os serviços que o citam. A ordenação usa o negativo do comprimento dessa coleção, então o apoio mais largo imprime primeiro. Um campo de dono vazio imprime um marcador em vez de uma célula em branco. A linha final conserva um componente só quando a coleção dele contém todos os serviços. Nenhum desses passos lê o escopo assinado, então uma linha impressa não é uma chave.

Tabela da aula; deslize para ver todas as colunas →

Fato impresso O que o produz Decisão que ele sustenta Decisão com a qual não se troca
Provedor de identidade, contagem 3, dono IT O comprimento da coleção é 3 Acrescentá-lo ao exercício de restauração, porque quem não consegue entrar ainda não reabre o portal A decisão de dono ausente
Relay de e-mail, contagem 2, dono NONE Um dono vazio imprime NONE Levar a definição de dono à lista de decisões do diretor de operações. Não reconfigurar o relay O fato de um componente sustentar os três serviços
Planilha da escala, contagem 1, dono NONE A mesma impressão de dono vazio A mesma lista de decisões. Não reconfigurar a planilha Um motivo para editar o relay antes de existir um dono
Banco de casos, contagem 1, dono Casework A linha está na listagem Conservar a linha para a dependência compartilhada de identidade continuar visível Permissão para abrir ou investigar esse banco

O primeiro escopo assinado ainda exclui a gestão de casos até o próximo trimestre. Conservar a linha não move essa exclusão.

Fluxo de decisão — três perguntas, três linhas diferentes

flowchart TD
  A["Uma linha da listagem de dependências"] --> B{"Qual pergunta está sendo feita?"}
  B -->|Quem sustenta todos os serviços| C["O comprimento da coleção é 3"]
  C --> D["O provedor de identidade entra no exercício de restauração"]
  B -->|Quem não tem dono| E["O dono impresso é NONE"]
  E --> F["Relay de e-mail e escala vão para a lista do diretor"]
  F --> G["Não reconfigure nenhum dos dois ainda"]
  B -->|Esta linha pode ser aberta| H{"O componente está no primeiro escopo assinado?"}
  H -->|Banco de casos, não| I["Conserve a linha. Não abra o banco"]
  H -->|Cadeia do portal, sim| J["A linha continua sem ser permissão"]

Exemplo resolvido — a linha do banco de casos não é uma chave

A engenheira vê o banco de casos na listagem verificada e estende a mão para uma exportação. A linha está ali para o apoio do provedor de identidade a todos os serviços continuar visível, inclusive um serviço fora do primeiro escopo. Ela deixa esse banco fechado. Nenhuma conta suspeita foi encontrada, então não há nada novo a comunicar ao dono; a linha, sozinha, não é um incidente. Em separado, o marcador NONE no relay de e-mail e na planilha da escala é o fato do dono ausente. Os dois nomes vão para a lista de decisões do diretor de operações. Ela não reconfigura o relay e não edita a planilha. O apoio do provedor de identidade aos três serviços é o motivo de esse componente entrar no exercício de restauração, e ela não troca esse motivo pelas linhas NONE.

Caso sintético. Nenhuma conta suspeita de gestão de casos aparece aqui. A linha é só a listagem impressa, e a ordem da listagem é a ordenação verificada.

Aplicar

Exercícios

Síntese

Um mapa de dependências transforma serviços nomeados em componentes compartilhados, donos, obrigações sobre dados, verificações de fornecedores e cenários apoiados em evidências.