## Capítulo 3 — Cibersegurança: sistemas, dados e dependências ### Objetivos de aprendizagem Ao final deste capítulo, você deve ser capaz de: 1. Fixar um limite útil para um modelo pequeno de serviço e nomear as pessoas, os processos, os depósitos e os serviços externos. 2. Rastrear um tipo de informação da criação ao uso, à cópia e ao descarte, sem presumir que toda cópia está atual. 3. Distinguir um fluxo de dados de uma dependência e marcar onde uma mudança de autoridade ou de confiança merece uma pergunta. 4. Declarar quais partes de um diagrama são fatos fornecidos, premissas do exercício ou perguntas sem resposta. 5. Produzir um modelo pequeno e uma lista de lacunas de evidência só a partir de registros sintéticos. ### 3.1 Um modelo responde a uma pergunta; não é o serviço O primeiro capítulo nomeou o serviço de reserva de salas da Harbor Library. O segundo limitou a prática a registros inventados. Agora podemos fazer uma pergunta mais precisa: **Uma pessoa do balcão conseguiria tomar uma decisão correta sobre a sala enquanto a visão ao vivo das reservas está indisponível?** Um modelo útil contém as partes necessárias para responder a essa pergunta. Não precisa retratar cada dispositivo que a biblioteca possui. Uma **fronteira de serviço** diz o que o modelo cobre. Nesta aula, inclui o pedido de reserva de um morador, a visão de reserva, um depósito de reservas, uma visão da equipe e a impressão alternativa da equipe. A lista de anúncios de eventos é um conjunto de dados separado; cabe num inventário mais amplo da biblioteca, mas está fora do caminho da decisão de reserva que vamos rastrear. Essa exclusão é deliberada, não uma afirmação de que a lista de contatos não tem necessidades de segurança. O [CSF 2.0 do NIST](https://doi.org/10.6028/NIST.CSWP.29) coloca, na categoria de gestão de ativos (`ID.AM`), inventários de hardware, software e serviços, representações de fluxos de rede autorizados, serviços de fornecedores, priorização de ativos e tipos de dados designados. O framework descreve resultados; não prescreve o diagrama deste curso nem prova que a Harbor Library tenha qualquer implementação particular. Uma organização confirmaria o modelo com responsáveis e registros aprovados. O exercício de iniciante usa premissas declaradas para que o raciocínio possa ser conferido sem descoberta ao vivo. A [folha de consulta de modelagem de ameaças da OWASP](https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) recomenda mostrar entidades externas, processos, depósitos de dados, fluxos e fronteiras de confiança ao modelar um sistema. Tomamos esses rótulos simples emprestados para entender o serviço. A ordenação de ameaças e o teste de aplicação ficam mais adiante no percurso de aprendizagem. Por agora, o trabalho é entender que informação se move, quem depende dela e onde o nosso conhecimento termina. ### 3.2 Nomeie as partes e os responsáveis Uma **entidade externa** é uma pessoa ou um sistema fora do processo modelado que interage com ele. Um **processo** aceita informação e executa uma tarefa. Um **depósito de dados** retém informação. Um **fluxo de dados** é o movimento entre eles. Esses rótulos descrevem papéis num modelo, não uma arquitetura de produto verificada. Uma aplicação real poderia combinar vários papéis; um papel poderia estar espalhado por vários serviços. | Parte modelada | Papel na aula | Quem confirmaria isso numa revisão real? | Evidência atual | |---|---|---|---| | Morador | Pede uma sala e recebe uma decisão | Responsável pelo serviço e responsável pelo processo voltado ao usuário | Descrição do caso fictício | | Visão de reserva | Recebe um pedido e mostra informação de reserva | Responsável pela aplicação | Premissa de ensino; nenhum software foi examinado | | Depósito de reservas | Guarda o estado atual da reserva para o exercício | Responsável pela aplicação ou pelos dados | Só linhas sintéticas de reserva | | Visão da equipe | Permite que a equipe autorizada consulte a agenda | Responsável pelo serviço e liderança da equipe | Premissa de ensino | | Agenda impressa | Instantâneo usado durante a interrupção do exercício de mesa | Liderança do balcão | Impressão inventada das 09:00 no capítulo 2 | | Contatos de eventos | Informação separada, usada para anúncios | Responsável pelos dados | Descrição fictícia do serviço; fora deste fluxo | A coluna “responsável” é um caminho de verificação, não uma afirmação de que uma única pessoa nomeada detém toda responsabilidade. Se a visão da equipe na verdade lê de outro depósito, o modelo tem de mudar. Se a impressão em papel é produzida a cada hora, e não uma vez por manhã, o risco de desatualização também muda. Um diagrama deve ser revisto quando a evidência discorda dele. ### 3.3 Siga a informação, inclusive as cópias Comece pelos dados necessários para a decisão. No nosso exercício sintético, uma reserva tem um identificador inventado, sala, horário de início, horário de criação e status. Uma reserva confirmada está representada no depósito de reservas. Uma visão da equipe pode exibir esse estado. Uma impressão contém um **instantâneo** feito num horário determinado; não recebe automaticamente mudanças posteriores. Esta é uma propriedade temporal da cópia em papel, não uma vulnerabilidade de software. Rastreie cada representação de modo explícito: | Representação | Por que existe | Quando está atual para este exercício | Pergunta antes de confiar nela | |---|---|---|---| | Linha sintética de reserva | Descreve uma reserva para a aula | No `created_time` declarado | O status está confirmado ou apenas pedido? | | Visão da agenda da equipe | Apoiaria uma decisão de sala ao vivo | Desconhecido enquanto o exercício diz que a visão está indisponível | Que fonte a alimenta, e quando essa fonte foi atualizada? | | Agenda impressa das 09:00 | Fornece uma referência offline | Contém as reservas conhecidas às 09:00 sob a premissa declarada de instantâneo | Reservas posteriores foram acrescentadas, alteradas ou canceladas? | | Fila de pedidos pendentes | Registra uma decisão não verificada durante o exercício | Tão atual quanto as anotações de quem trabalha, mas **não** é confirmação autoritativa de reserva | Quem a reconcilia depois que o serviço volta? | A lista de contatos de eventos tem um propósito diferente da lista de reservas. Não presuma que uma pessoa que pode ver uma reserva de sala também pode exportar contatos de eventos. Do mesmo modo, uma cópia de segurança é um recurso potencial de recuperação, não automaticamente uma visão atual de reservas. Num inventário real, um responsável deveria identificar tipos de dados, locais, finalidade, acesso e regras de retenção e descarte segundo as políticas da organização. Neste exercício, registramos só os campos necessários para a pergunta de ensino e não inventamos identificadores pessoais. A distinção entre **fonte de verdade** e **cópia** ajuda a evitar um erro fácil. Um registro autoritativo atual é aquele que o responsável pelo serviço designa para uma decisão particular, sujeito à integridade e à disponibilidade reais. Uma cópia impressa ainda pode ser útil durante uma interrupção, mas o carimbo de tempo limita o que ela pode estabelecer. “A impressão existe” não implica “a impressão reflete todas as reservas.” “Um trabalho de cópia de segurança terminou” não implica “a equipe pode usar a cópia de segurança com segurança como agenda ao vivo.” Cada afirmação precisa de evidência separada. ### 3.4 Desenhe um fluxo e marque as fronteiras O que segue é uma **alternativa em texto** a um diagrama. É pequeno de propósito. As setas indicam movimento proposto de informação, e os colchetes nomeiam papéis. Elas não afirmam que uma aplicação real da Harbor Library tenha esta arquitetura. ```text [Morador] --pedido de reserva--> [Visão de reserva] --escrita proposta--> [Depósito de reservas] ^ | | | resultado da reserva leitura proposta +------------------------------+ | v [Membro da equipe] --acesso e consulta--> [Visão da equipe] <--------------+ | instantâneo das 09:00 v [Agenda impressa] ``` A primeira seta cruza uma fronteira entre um morador e um serviço que decide se um pedido é válido. O acesso e a consulta da equipe cruzam uma fronteira diferente, porque quem trabalha pode ter autoridade para ver ou alterar informação que um morador não pode. A agenda impressa sai de um processo digital e vira uma cópia física; o manuseio e a atualidade precisam de procedimentos humanos. Uma **fronteira de confiança** marca uma mudança de premissas ou de autoridade que deve ser examinada. Não é, por si, evidência de que autenticação, autorização, cifragem ou registro de eventos está presente ou ausente. Para cada seta, faça três perguntas de iniciante: **O que se move? Quem pode causar ou ler esse movimento? Que evidência mostraria que a regra pretendida é seguida?** Para o pedido do morador, as respostas poderiam ser “sala e horário”, “um morador pode pedir uma sala disponível” e “um teste aprovado pelo responsável com reservas sintéticas, mais uma especificação de aplicação revisada”. São verificações possíveis, não fatos estabelecidos pelo nosso exercício em papel. Não use este diagrama como permissão para enviar pedidos de teste a um site público. Se um serviço de mensagens de terceiro envia confirmações, acrescente-o como serviço externo só depois de confirmar que ele é de fato usado. Então pergunte que dados ele recebe, pelo que o fornecedor é responsável e se o serviço ainda consegue decidir uma reserva se a mensagem atrasar. Este é um exemplo de **dependência condicional**: a resposta pode diferir entre “uma reserva pode ser gravada” e “um morador recebe a confirmação”. Manter esses resultados separados evita tratar toda interrupção de fornecedor como uma interrupção completa das reservas. ### 3.5 Dependências mudam com o resultado Uma dependência é necessária para um resultado particular sob condições particulares. No caminho ao vivo proposto, a visão de reserva pode depender de um depósito de reservas. Durante a interrupção do exercício de mesa, a equipe pode, em vez disso, depender da última fonte alternativa aprovada e de uma regra para pedidos pendentes. Um componente pode ser importante sem ser o único modo de continuar funcionando. Não chame o depósito de reservas de “ponto único de falha” a menos que o responsável tenha confirmado que não há alternativa adequada e tenha definido o que falha significa. Para revisar uma dependência, escreva uma frase condicional: “Se **X** está indisponível, **Y** não pode ser concluído dentro do tempo **Z** usando a alternativa aprovada.” O caso fictício não fornece uma meta de recuperação `Z`, então deixe isso como pergunta para o responsável pelo serviço. Separe os efeitos sobre moradores, equipe e assinantes de eventos. Uma interrupção da visão do balcão não prova que a página de um morador está fora do ar; o registro do capítulo 1 limitou de modo específico a interrupção observada ao balcão. O modelo de serviço também precisa de uma regra de atualização. Uma mudança no fluxo de reserva, na agenda de impressão ou na fonte aprovada pode invalidar esta página. Uma entrada pequena de inventário deve, portanto, registrar a data do modelo, o autor ou o responsável, o escopo, a evidência, as perguntas abertas e o gatilho de revisão. Um diagrama arrumado sem data de revisão pode enganar um leitor mais do que um diagrama tosco com rótulos claros de incerteza. ### 3.6 Laboratório guiado: uma decisão a partir de um instantâneo desatualizado Use as linhas **sintéticas** introduzidas no capítulo 2: ```csv booking_id,room,start_time,created_time,status SYN-001,Room 2,14:00,08:20,confirmed SYN-002,Room 2,15:00,10:05,confirmed ``` Só neste laboratório, presuma que uma impressão das 09:00 é um instantâneo fixo, inclui `SYN-001` e não pode incluir `SYN-002`, porque essa reserva foi criada às 10:05. A visão do balcão está indisponível das 11:30 às 11:50. Às 11:42 alguém pergunta se a Sala 2 está livre às 15:00. Nenhuma rede e nenhum dado real são usados. 1. Copie as seis partes modeladas da seção 3.2 para o papel ou para uma tabela Markdown. Circule a agenda impressa como uma cópia. 2. Rastreie `SYN-002` da criação às 10:05 até o depósito de reservas no modelo *hipotético*. Desenhe um ponto de interrogação em qualquer passo não verificado, inclusive se a visão da equipe normalmente o mostraria. 3. Compare o horário da consulta, o horário da impressão e o horário da reserva. A impressão não pode responder à pergunta de disponibilidade das 15:00 sob a premissa declarada de instantâneo. Não transforme essa conclusão numa afirmação sobre um serviço real. 4. Use a regra alternativa do capítulo 2: marque o pedido como **pendente**, registre o motivo e busque uma fonte atual aprovada ou o responsável. Não prometa a sala só com o papel antigo. 5. Escreva um relatório de três linhas: fato observado no exercício, decisão e limitação. Uma resposta modelo é: “A impressão sintética das 09:00 omitiu uma reserva criada às 10:05. No exercício de mesa, quem atendia marcou o pedido das 15:00 como pendente em vez de confirmá-lo. O exercício não inspecionou um depósito real de reservas nem estabeleceu como a biblioteca real trata interrupções.” O artefato esperado é um modelo pequeno mais este relatório. O resultado não é “descobrimos uma violação”. O resultado é uma decisão defensável diante de informação limitada. Se o responsável mais tarde fornecer uma agenda de papel horária verificada ou uma réplica offline aprovada, repita a análise com essa evidência; não preserve a conclusão original só porque ela apareceu num diagrama. ### 3.7 Um registro de modelo revisável Use este modelo Markdown para um modelo de serviço. Ele é curto de propósito, para que outra pessoa possa contestá-lo: ```text Decisão que o modelo apoia: Serviço e pessoas afetadas: Dentro do escopo / fora do escopo: Entidades, processos e depósitos: Tipos de dados e seus propósitos: Fluxos e fronteiras: Dependências e premissas da alternativa: Fatos fornecidos: Premissas do exercício: Perguntas abertas e a quem perguntar: Última revisão / gatilho de atualização: ``` Na Harbor Library, “reserva criada às 10:05” é um fato sintético fornecido; “a agenda impressa é um instantâneo fixo das 09:00” é uma premissa do exercício; “que fonte a equipe pode usar durante uma interrupção real” é uma pergunta aberta. Essas categorias devem permanecer visíveis no artefato final. Quem escreve “o sistema não tem recuperação” porque este capítulo não mencionou uma confundiu **evidência ausente** com **evidência de ausência**. Erros comuns incluem desenhar uma arquitetura detalhada a partir de uma narrativa curta, tratar cada linha como uma conexão de rede verificada, omitir cópias físicas, confundir uma dependência com uma falha e deixar um modelo inalterado depois que informação nova chega. O remédio é modesto: mantenha o modelo ligado a uma decisão, rotule a incerteza, pergunte ao responsável e revise o registro quando um fato muda. O capítulo 4 usará este modelo limitado para discutir ameaças plausíveis e modos comuns de falha sem afirmar que qualquer um deles ocorreu. ### Resumo do capítulo 3 Modele as pessoas, os processos, os depósitos e a informação necessários para uma decisão definida de serviço. Trate as cópias de dados e os seus carimbos de tempo de modo explícito. Um fluxo mostra movimento proposto; uma fronteira de confiança provoca uma pergunta sobre autoridade; uma dependência só importa em relação a um resultado declarado. Marque fatos fornecidos, premissas e perguntas sem resposta para que o modelo continue útil quando a evidência mudar. ### Exercícios do capítulo 3 Use o modelo e os registros inventados acima; não teste um serviço ao vivo. As resoluções aparecem no apêndice final. ### EX011 — Fronteira e componentes - **Objetivo:** Definir um modelo de serviço que responda a uma pergunta específica sem inventar detalhes de implementação. - **Entrada:** A pergunta de decisão na seção 3.1 e as seis partes modeladas na seção 3.2. - **Condição segura:** Use só o caso fictício; não inspecione um serviço real de biblioteca. - **Passos:** (1) Escreva a pergunta de decisão. (2) Nomeie quatro partes necessárias para respondê-la e classifique cada uma como entidade, processo, depósito ou cópia. (3) Nomeie um conjunto de dados relacionado que esteja fora deste caminho de decisão e explique por quê. (4) Marque uma premissa arquitetural não verificada. - **Evidência esperada:** Uma declaração de escopo e uma tabela de componentes com quatro linhas e uma pergunta aberta. - *Rubrica:* 3 = pergunta limitada à decisão de reserva, papéis adequados, exclusão fundamentada dos contatos de eventos e um rótulo visível de incerteza;; 2 = a pergunta e os papéis estão certos, mas a exclusão ou a incerteza fica implícita;; 1 = um diagrama de rede muito detalhado e sem sustentação não atende ao objetivo;; 0 = nenhuma. ### EX012 — Rastreie o instantâneo - **Objetivo:** Distinguir o horário de uma cópia de dados do horário de uma mudança posterior. - **Entrada:** As duas linhas CSV da seção 3.6, uma impressão fixa das 09:00 e a pergunta sobre a sala às 11:42. - **Condição segura:** Trabalhe só com estes horários e identificadores inventados. - **Passos:** (1) Ponha os quatro horários relevantes em ordem. (2) Liste quais identificadores de reserva a impressão pode incluir sob a premissa de instantâneo. (3) Declare o que a impressão não pode estabelecer às 11:42. (4) Registre a próxima ação defensável de quem atende. - **Evidência esperada:** Uma linha do tempo curta e uma nota de decisão com a premissa. - *Rubrica:* 3 = `SYN-001` na impressão, `SYN-002` ausente, premissa explícita de instantâneo e decisão pendente ou confirmada pelo responsável, em vez de uma promessa sem apoio;; 2 = os identificadores estão certos, mas a premissa de instantâneo fica implícita;; 1 = promete a sala a partir da impressão das 09:00;; 0 = nenhuma. ### EX013 — Fluxo versus dependência - **Objetivo:** Separar o movimento de informação de uma condição exigida para um resultado. - **Entrada:** O diagrama em texto da seção 3.4 e os dois resultados “gravar uma reserva” e “enviar uma confirmação”. - **Condição segura:** Trate o fornecedor opcional de mensagens como hipotético; não contate um fornecedor nem envie mensagens. - **Passos:** (1) Nomeie dois fluxos mostrados no diagrama. (2) Escreva uma dependência condicional para cada resultado. (3) Explique se um atraso de mensagem prova, necessariamente, que a reserva não foi gravada. (4) Nomeie o fato que um responsável precisa confirmar. - **Evidência esperada:** Dois fluxos rotulados, duas frases condicionais e uma pergunta de verificação. - *Rubrica:* 3 = distingue um caminho de dados proposto de uma condição exigida pelo serviço e não afirma o fornecedor ou a implementação não confirmados;; 2 = os fluxos estão certos, mas a frase condicional falta;; 1 = afirma uma implementação ou um fornecedor não observado;; 0 = nenhuma. ### EX014 — Perguntas de fronteira - **Objetivo:** Usar uma fronteira de confiança como convite à verificação, e não como prova de um controle. - **Entrada:** As setas de morador para visão de reserva e de equipe para visão da equipe na seção 3.4. - **Condição segura:** Isto é uma revisão em papel; não teste contas nem envie pedidos a um serviço ao vivo. - **Passos:** Para cada seta, escreva (1) que informação ou ação a cruza, (2) quem deveria ter permissão para iniciá-la no cenário fictício, (3) uma pergunta de controle para o responsável e (4) um tipo de evidência autorizada que poderia responder a essa pergunta. - **Evidência esperada:** Uma tabela de duas linhas que separa a permissão esperada da prova observada. - *Rubrica:* 3 = autoridade distinta de morador e de equipe, perguntas específicas ao responsável e a afirmação de que o diagrama sozinho não verifica implementação alguma;; 2 = as duas fronteiras aparecem, mas a pergunta ao responsável fica genérica;; 1 = trata a seta como prova de que um controle existe;; 0 = nenhuma. ### EX015 — Revise quando um fato muda - **Objetivo:** Atualizar um modelo sem se agarrar a uma conclusão anterior. - **Entrada:** Um *novo relato fictício do responsável* diz que o balcão recebe uma agenda offline aprovada, atualizada às 11:40 e contendo `SYN-002`. A exatidão ainda não foi testada. - **Condição segura:** Não busque nem copie reservas reais; raciocine a partir deste relato inventado adicional. - **Passos:** (1) Identifique qual conclusão anterior fica enfraquecida. (2) Acrescente a agenda offline relatada como uma representação separada. (3) Especifique uma verificação sintética segura do carimbo de tempo e do conteúdo. (4) Declare a decisão se a verificação passar e se falhar, e anote uma limitação que permanece. - **Evidência esperada:** Uma nota de modelo revista, com relato, teste, decisões de cada ramo e limitação. - *Rubrica:* 3 = trata a informação nova como relato, não como fato observado de modo independente; muda de modo condicional a conclusão de que só existe o papel das 09:00; mantém a decisão de quem atende dentro da regra alternativa aprovada;; 2 = separa o relato do fato, mas a decisão condicional fica incompleta;; 1 = trata o relato das 11:40 como fato já verificado ou defende o diagrama antigo;; 0 = nenhuma. ### Continue estudando — capítulo 03 de 20 [← Capítulo 02](#ch-02) · [Índice de capítulos](../SUBJECTS.md) · [Capítulo 04 →](#ch-04) Continue para a próxima aula escrita. ## Worked answers ### EX011 — Resolução A pergunta de decisão é se uma pessoa do balcão pode tomar uma decisão correta sobre a sala enquanto a visão ao vivo está indisponível. O morador é uma entidade externa; a visão de reserva e a visão da equipe são processos; o depósito de reservas é um depósito; a agenda impressa é uma cópia física. Quaisquer quatro desses papéis, explicados de modo correto, satisfazem a tabela. A lista de contatos de eventos está fora do caminho de reserva rastreado porque a finalidade são os anúncios, embora continue relevante para um inventário de informação mais amplo. Uma pergunta aberta é se a visão da equipe lê o mesmo depósito mostrado no diagrama. Um bom modelo diz “leitura proposta” até o responsável confirmar. ### EX012 — Resolução Às 08:20, `SYN-001` é criada; às 09:00, a impressão fixa é feita; às 10:05, `SYN-002` é criada; às 11:42, chega a pergunta sobre a sala. Sob a premissa declarada de instantâneo, a impressão pode mostrar `SYN-001`, mas não `SYN-002`. Não pode estabelecer que a Sala 2 está livre às 15:00. Quem atende marca o pedido como pendente e pede uma fonte atual aprovada ou o responsável. Se alguém diz que a impressão poderia se atualizar sozinha, precisa contestar de modo explícito a premissa do exercício; não pode usar em silêncio um cenário diferente. ### EX013 — Resolução Dois fluxos no modelo proposto são o pedido de reserva de um morador até a visão de reserva e uma escrita proposta da visão de reserva até o depósito de reservas. Para gravar uma reserva neste caminho hipotético, o processo de reserva precisaria de um modo de persistir uma decisão válida; se o depósito retratado é o mecanismo real permanece não verificado. Para enviar uma confirmação por um fornecedor hipotético, esse fornecedor precisaria receber os dados exigidos de aviso e aceitar a tarefa de entrega. Uma mensagem atrasada não prova, por si, uma reserva que falhou. Pergunte ao responsável se as confirmações são enviadas por um serviço externo e se gravar e enviar mensagem estão acoplados. Outras respostas são aceitáveis quando declaram um resultado, uma dependência e uma incerteza, em vez de afirmar uma implementação não observada. ### EX014 — Resolução Fronteira do morador: um pedido de sala e horário entra na visão de reserva; um morador pode pedir uma sala disponível, mas não deve ganhar poderes da equipe. Pergunte ao responsável como os pedidos são validados e o que um teste sintético aprovado ou uma revisão de desenho mostra. Fronteira da equipe: uma pessoa autenticada consulta uma visão da equipe e pode ver ou alterar informação segundo um papel definido. Pergunte quais papéis podem fazer mudanças e se uma matriz de papéis aprovada e um teste revisado sustentam essa regra. As setas localizam perguntas; não mostram que verificações de acesso existem ou funcionam. Uma afirmação de que cifragem ou autenticação multifator está presente só a partir deste desenho falha a exigência de evidência. ### EX015 — Resolução A conclusão anterior, de que só uma agenda de papel desatualizada das 09:00 está disponível, fica enfraquecida pelo relato novo do responsável. Acrescente “agenda offline aprovada e relatada, atualizada às 11:40” como uma cópia separada; marque a autoridade e a atualidade como **relatadas, não verificadas**. Num ensaio em papel, dê a quem atende uma folha sintética das 11:40 e confira que o carimbo de tempo é 11:40 e que ela inclui `SYN-002`. Se o responsável confirma isto como fonte atual aprovada e a conferência passa, quem atende pode usá-la segundo o procedimento aprovado; se a conferência falha, mantenha o pedido pendente. Uma limitação que permanece é que uma única conferência sintética não estabelece com que confiabilidade a agenda offline real se atualiza. O modelo correto muda de modo condicional, em vez de defender o diagrama antigo.