Autoridade, delegação e ensaio antes do incidente

Semana 1, dia 4. Percorra o ensino e o marco resolvido antes de tentar os exercícios indicados. Compare o seu artefato com a resolução final só depois.

1.3 Papéis e autoridade de decisão

Uma organização pequena pode atribuir vários papéis a uma pessoa, mas as decisões permanecem distintas:

Tabela da aula; deslize para ver todas as colunas →

O analista não deve desligar um serviço só porque um painel parece incomum. O responsável pelo serviço não pode decidir que os logs são irrelevantes porque o serviço parece disponível. O líder do incidente reúne donos e evidência, registra a decisão e a revisita quando os fatos mudam.

Um registro de decisão útil contém um carimbo de tempo, a situação atual, as opções disponíveis, a ação escolhida, a pessoa que a aprovou, a evidência que a sustenta, os efeitos esperados e uma hora de revisão. Registre também opções rejeitadas quando elas explicam um compromisso importante. Um registro breve feito durante o incidente é mais confiável do que uma história reconstruída semanas depois.

Separe recomendação, aprovação, execução e verificação

Uma pessoa pode desempenhar mais de um papel numa equipe pequena, mas quatro verbos devem permanecer visíveis no registro do caso. O analista recomenda uma ação e cita observações. Uma pessoa responsável aprova o escopo e o compromisso. Um operador executa a mudança limitada. Um revisor verifica se a mudança alcançou o objetivo e registra qualquer dano. Nenhum desses verbos pode ser inferido com segurança só a partir de um cargo. O NIST SP 800-61 Rev. 3, seções 2.2–2.3 discute papéis distribuídos de resposta e a necessidade de autoridades e procedimentos documentados; o registro de quatro verbos abaixo é o dispositivo de ensino da OpenCyber Academy para tornar essas autoridades observáveis.

Tabela da aula; deslize para ver todas as colunas →

Essas atribuições são regras fictícias de exercício. Não são uma alegação sobre a autoridade legal de qualquer organização real nem uma instrução para desconectar um sistema de produção. Uma aprovação útil diz mais do que “pode seguir”: nomeia o alvo, a ação, a duração, a interrupção esperada, a evidência a preservar, o gatilho de reversão e a próxima revisão. Se uma ação urgente é necessária, mas o aprovador designado não pode ser alcançado, o líder da resposta segue a política aprovada de escalada da organização; quem estuda não deve inventar autoridade a partir do silêncio.

Considere uma recomendação de restringir desk-a depois de R1–R5. O analista pode declarar um benefício plausível: edições adicionais não autorizadas poderiam parar. O analista também precisa declarar um custo plausível: a equipe da recepção poderia perder o acesso num período movimentado. Nem o benefício nem o custo estão medidos ainda. Um registro de decisão que diz “conta comprometida; desabilitar imediatamente” esconde tanto a incerteza quanto a autoridade. Um registro provisório melhor é: “Às 09:05 UTC, preservar os registros fornecidos e buscar a confirmação do responsável pelo treinamento até 09:15; se aparecer uma edição nova e inexplicada de reserva, reconvocar o líder do incidente, o responsável pelo serviço e o administrador de identidade para uma restrição aprovada.” O horário e o limiar aqui pertencem a este caso sintético, não a uma política universal de resposta.

1.3a Ensaiar a autoridade antes de um incidente

1.3a.1 De conhecer um cargo a provar uma rota utilizável de decisão

Um plano de resposta pode dizer corretamente que o responsável pelo serviço aprova uma interrupção e o líder do incidente aprova uma coleta limitada. Essa afirmação é necessária, mas não basta para saber que uma decisão futura pode ser executada de forma lícita e segura. E se o responsável principal mudou de cargo no mês passado? E se o substituto listado pode autorizar uma pausa pequena de reserva de sala, mas não uma exportação de dados de frequentadores sem relação? E se a rota de aprovação funciona no horário de expediente, mas ninguém testou o canal de contato designado? E se a delegação foi revogada ou a data passou?

Uma equipe de resposta a incidentes deve descobrir tais lacunas antes de um evento real forçar uma escolha difícil. A pergunta de preparação não é “Uma pessoa aparece num organograma?”. É “Um revisor consegue reconstruir um caminho exato e atualmente válido, de um pedido nomeado até o decisor e o custodiante responsáveis, com escopo explícito e um resultado seguro quando o caminho falha?”

A seção 1.3 distingue recomendação, aprovação, execução e verificação. AR1 pede aos estudantes que ensaiem se esses estágios são alcançáveis por meio dos registros atuais de autoridade. Um ensaio bem-sucedido antes do incidente demonstra apenas que as regras simuladas de roteamento e verificação foram aplicadas corretamente para uma versão e um horário declarados. Não pré-aprova ações posteriores nem estabelece que uma pessoa real respondeu a uma mensagem real.

O NIST SP 800-61 Revision 3 coloca o planejamento e a coordenação de resposta a incidentes dentro da gestão de risco do Cybersecurity Framework 2.0. O NIST SP 800-84 trata do desenho, da condução e da avaliação de testes e exercícios de planos de TI. O registro versionado de autoridade e o procedimento de validação desenvolvidos aqui são técnicas educacionais originais para explorar essas preocupações documentadas, não formulários prescritos pelo NIST.

1.3a.2 Um nome de papel não é prova de que uma pessoa particular detém autoridade

Um mapa de serviço pode nomear “responsável pelo serviço”, “administrador de identidade”, “custodiante da aplicação” e “líder do incidente”. Cada rótulo descreve responsabilidade, mas o rótulo sozinho não estabelece qual pessoa ocupa o papel agora, quais ações específicas ela pode aprovar, nem se um substituto listado pode assinar em nome do titular.

Um papel é uma categoria de responsabilidade. Uma nomeação associa esse papel a uma identidade organizacional verificada por um tempo declarado. Uma delegação dá um subconjunto definido de autoridade a outra pessoa ou papel, sob termos explícitos. Um custodiante administra um objeto ou uma fonte e pode executar um pedido autorizado, mas não é automaticamente dono da decisão de risco de negócio. Um solicitante pode explicar por que a evidência é necessária; ser o solicitante não é o mesmo que conceder o pedido.

Antes de um incidente, um revisor deve conseguir localizar o registro governado e autoritativo de cada nomeação e delegação, junto com o emissor, o estado de aprovação, a versão e o período de validade. Numa organização real, esse registro pode depender de situação empregatícia, grupos de gestão de identidade, delegações formais ou outros sistemas governados. O exercício da OpenCyber Academy não assume nenhuma implementação particular.

Um nome digitado numa planilha é evidência mais fraca do que uma nomeação atual, revista pelo responsável e sustentada pelo processo autoritativo da organização. Uma entrada de lista de contatos pode continuar útil depois que uma pessoa deixa um papel, mas deixa de ser fonte válida de decisão, a menos que o sistema de governança diga o contrário. Se o revisor não consegue estabelecer a nomeação, o resultado correto é reter a ação e escalar, não tratar a familiaridade com o nome da pessoa como prova de autoridade.

1.3a.3 Estabeleça um registro versionado com perguntas explícitas de aceitação

Um registro de prontidão de autoridade útil precisa de mais do que colunas de nome e telefone. Precisa dizer a um revisor independente se a rota proposta de decisão é válida para a operação em consideração. No mínimo, deve identificar:

Tabela da aula; deslize para ver todas as colunas →

O próprio registro também precisa de proveniência. Um arquivo chamado latest-authority.xlsx não é evidência adequada de ser o mais recente. Um identificador de mudança, um emissor responsável, uma revisão registrada e uma transição de versão devem tornar possível determinar se uma cópia local está obsoleta. O leitor deve saber qual sistema é autoritativo e como resolver um conflito entre duas cópias.

Um registro pode ser uma tabela em papel para o exercício introdutório. A habilidade ensinada é validar um conjunto explícito de alegações, não escolher uma base de dados ou um fornecedor de tíquetes em particular. Os campos são escolhas fictícias de desenho instrucional; nenhuma fonte NIST é apresentada como exigindo este esquema exato.

1.3a.4 O escopo pertence à delegação, não apenas ao pedido original

Suponha que o responsável pelo serviço pode autorizar uma pausa temporária de uma rota de escrita de reserva da equipe. Um substituto pode receber autoridade delegada para aquela pausa específica, por um período curto. Essa delegação não permite automaticamente ao substituto aprovar uma restauração de base de produção, desabilitar toda conta, recuperar registros do boletim de frequentadores ou estender a pausa indefinidamente.

O pedido precisa, portanto, ser comparado com a operação permitida e o escopo de objetos no registro. O mesmo substituto nomeado pode ter autoridade diferente para coleta de evidência e para um controle disruptivo de serviço. Um delegado aprovado para uma operação deve ser rejeitado para outra, a menos que um registro válido separado a cubra.

A peça AR1 usa duas atividades deliberadamente estreitas. Primeiro, um pedido para revisar uma seleção sintética de auditoria de treinamento contendo só TR-01 ou TR-02 exige a decisão do líder fictício do incidente e um custodiante designado de auditoria. Segundo, um pedido para preparar uma pausa de escrita da equipe exige os papéis fictícios de decisão do líder do incidente e do responsável pelo serviço; um substituto documentado pode preencher o papel de responsável pelo serviço só para essa classe estreita de pausa.

Isto é um ensaio de validade da rota, não a execução de qualquer das ações. A saída REHEARSAL_PATH_VALID_NOT_EXECUTED nunca significa “auditoria coletada” nem “pausa de escrita aplicada”. Num incidente real, a equipe ainda precisaria de uma decisão atual de negócio, de autorização de coleta ou de mudança, de recibo do operador, de verificação técnica e das salvaguardas aplicáveis de privacidade.

A verificação de escopo deve falhar fechada. Se o pedido inclui um objeto sem relação, o verificador não deve ignorar em silêncio esse objeto e aprovar o resto como se o pedido original estivesse inalterado. Deve devolver uma condição de retenção e exigir um pedido corrigido de forma explícita.

1.3a.5 Períodos de validade e expiração são controles operacionais de segurança

A autoridade de um substituto pode ser válida só por um intervalo especificado. Um revisor precisa conhecer tanto o início efetivo quanto o último instante válido, e deve usar uma base de tempo consistente. No modelo de ensino AR1, a delegação vigora das 13:00 até antes das 14:30 UTC na data fictícia do ensaio. Uma verificação às 14:15 pode satisfazer a condição de tempo; uma verificação às 14:31 não pode.

A regra estrita importa: uma delegação antes válida não é válida indefinidamente. O fato de uma pessoa ter aprovado algo ontem não lhe concede o mesmo escopo hoje. Um registro também pode expirar como um todo. Um delegado não pode ser tratado como atual sob uma edição que o processo de governança já não aceita, só porque a data individual da delegação parece recente.

O exercício deve distinguir expiração de revogação. Expiração significa que o intervalo de validade delegada decorreu. Revogação significa que uma decisão governada retirou a delegação antes do fim nominal. Qualquer das duas deve bloquear a confiança no substituto para a operação afetada.

Se um carimbo de tempo falta ou não pode ser comparado, não selecione o valor que faz o teste passar. O estado apropriado é tempo ou autoridade não verificados, sujeito a revisão. O script AR1 assume carimbos com consciência de UTC e rejeita dois casos explícitos de expiração; não substitui autenticar relógios em registros organizacionais reais.

Uma expiração que se aproxima também pode ser um gatilho de manutenção de prontidão. A equipe deve revisar delegações críticas antes dos prazos, identificar o próximo responsável aprovado e ensaiar a rota atualizada. Isso impede que uma lista de contatos se torne um ponto único e silencioso de falha.

1.3a.6 O dono, o aprovador e o custodiante podem ser pessoas diferentes

Um pedido pode ser válido no propósito de negócio e ainda ser encaminhado ao custodiante errado. Por exemplo, um responsável pelo serviço pode aprovar uma interrupção limitada enquanto um operador da aplicação é o único papel permitido a aplicá-la. Um líder do incidente pode aprovar um pedido estreito de evidência enquanto o custodiante da aplicação recupera os registros. Um coletor pode não estar autorizado a aprovar coleta ampliada só porque possui acesso técnico.

O registro deve modelar tanto quem pode decidir quanto quem pode executar a tarefa aprovada, como verificações separadas. Um aprovador válido com um executor inválido não é uma rota válida de execução. Por outro lado, um executor válido sem aprovação válida não deve executar a ação.

No AR1, o pedido imaginário de auditoria de treinamento nomeia um custodiante de auditoria; o pedido de pausa de escrita da equipe nomeia um operador da aplicação. Trocar os dois produz um resultado de custodiante errado mesmo quando o escopo pedido e os campos de aprovador estão corretos no resto.

Isto não pretende impor um requisito de toda a organização de que cada papel de equipe pequena seja ocupado por um humano distinto. O livro já explica que organizações pequenas podem combinar papéis. O requisito relevante é que as decisões lógicas e a evidência de cada estágio permaneçam distinguíveis. Uma única pessoa que ocupa vários papéis documentados ainda precisa exercer cada papel dentro da autoridade aplicável.

Quando o mesmo indivíduo proporia, aprovaria e executaria uma mudança de alto impacto, a organização pode exigir revisão independente adicional segundo a governança real. AR1 não cria tal requisito nem concede exceções. Ensina a registrar a pergunta de política sem resolução, em vez de inventar uma regra de separação de deveres.

1.3a.7 Use uma rota registrada de confirmação, não uma resposta não verificada

Conhecer o papel correto não basta se o pedido chega por um canal não confiável ou não registrado. Uma mensagem de uma conta que exibe um nome familiar pode não autenticar a pessoa nem o papel atual. Um indicador de entrega bem-sucedida de e-mail não estabelece autoridade de decisão.

Um ensaio de prontidão de autoridade deve especificar como o solicitante pode verificar uma resposta por uma rota obtida de forma independente do registro aprovado. Um conceito comum é um retorno de chamada ou um canal organizacional confiável de confirmação. O método concreto numa implantação real depende dos controles de identidade, da política de comunicações e do modelo de ameaça da organização.

O script AR1 representa este requisito complexo pelo campo literal registered-callback e por um sinalizador booleano de confirmação. São asserções de brinquedo fornecidas pelo exercício. Não são prova de identidade, desafio secreto, assinatura criptográfica, telefonema real nem consentimento.

A pergunta anterior ao incidente é: o plano nomeia uma rota testada que permitiria a um revisor distinguir um aprovador válido de um impostor ou de um contato obsoleto? Um processo que diz “envie um e-mail ao responsável”, mas não tem procedimento para verificar uma instrução surpreendente ou de alto impacto, permanece incompleto.

Um ensaio negativo deve fornecer de propósito um canal de mensagem não registrado e confirmar que a ação proposta é retida. Outro deve reter a confirmação mesmo quando o nome e a rota coincidem. Em nenhum dos casos a equipe pode interpretar o silêncio como aprovação.

Este conceito difere do laboratório DEL4 do módulo 4 da edição inglesa, que não está neste manuscrito e testa entrega de mensagem, reconhecimento de versão e leitura de volta durante coordenação simulada de incidente. AR1 testa a confiança anterior ao incidente no próprio caminho de autoridade, antes de qualquer ação de incidente ser selecionada.

1.3a.8 Um recibo de aprovação precisa identificar a decisão limitada

Um revisor fictício pode receber uma resposta que diz “aprovado”. Essa palavra, sozinha, é insuficiente se não identifica o pedido, o alvo e o escopo, o papel do respondente, a versão aplicável do registro e se a aprovação permanece atual. Uma aprovação pode ser genuína para uma tarefa e irrelevante para outra.

Um recibo planejado útil identifica o identificador do pedido, a decisão, a operação, os objetos, o papel e a identidade de quem aprova, a rota de confirmação, a hora, as restrições, a expiração ou a condição de revisão, e a versão do registro que governa. A organização real pode usar um processo estabelecido de tíquete ou de mudança; este capítulo não prescreve um sistema novo de produção.

AR1 usa um marcador pequeno SIM-RECEIPT para representar a presença de um recibo fictício de aprovação. Se o marcador está ausente, o validador de brinquedo devolve HOLD_APPROVAL_MISSING. A presença desse marcador não autentica o aprovador nem autoriza uma ação real; apenas permite a quem estuda praticar a verificação de que um recibo distinto faz parte da rota planejada.

Este é um limite epistêmico importante. Software pode conferir se campos existem e se valores cabem numa regra. Não pode estabelecer automaticamente que uma pessoa real autorizou de forma consciente uma interrupção de serviço, a menos que os processos organizacionais circundantes de identidade e de decisão forneçam essa evidência.

Durante um ensaio, rotule explicitamente o resultado como caminho simulado válido, não executado. Isso evita o modo de falha em que um “exercício bem-sucedido” é copiado para um tíquete real de incidente e confundido com uma aprovação real.

1.3a.9 Dois exemplos contrastantes completos: uma delegação válida e um substituto inseguro

Exemplo correto — rota limitada, atual e confirmada num ensaio anterior ao incidente.

Na data inventada de ensaio 2026-09-15 às 14:15 UTC, a versão do registro é AR-3 e está dentro do intervalo declarado de validade. Um pedido de prática concerne só a operação fictícia pause_staff_writes do recurso staff-write-route. O líder simulado do incidente lead-sim tem um recibo separado de decisão. O responsável nomeado pelo serviço owner-sim emitiu uma delegação documentada e não revogada, permitindo a alternate-sim preencher o papel de aprovação do responsável pelo serviço só para esta operação e este objeto, com vigência das 13:00 até antes das 14:30 UTC. O papel executor designado é app-operator-sim.

Ambas as aprovações fictícias têm recibos de treinamento com escopo e confirmações pela rota registered-callback declarada no registro. O validador devolve REHEARSAL_PATH_VALID_NOT_EXECUTED. A interpretação correta é: as condições especificadas de roteamento passaram no exercício isolado. Nenhuma pausa de produção foi aprovada, executada ou verificada; nenhuma identidade de pessoa real foi autenticada por este script.

Um pacote adequado a uma revisão anterior ao incidente, com duas pessoas, preservaria a versão do registro, o escopo e a expiração do delegado, os campos simulados de aprovação, o operador esperado, a hora da verificação, as condições de parada e o resultado. O revisor que recebe o pacote poderia reproduzir a decisão e identificar qual evidência uma implementação real precisaria.

Exemplo incorreto — um substituto plausível, mas expirado e não verificado.

Às 14:31 UTC, numa execução artificial diferente, o intervalo permitido do mesmo delegado terminou. Suponha que alguém copia o nome antigo do responsável de uma lista de contatos, acrescenta um pedido que afeta objetos sem relação de reserva ou de boletim, e o envia por uma conta de conversa não registrada dizendo que o assunto é urgente. O pedido não é válido só porque o substituto antes detinha uma delegação relevante ou porque o canal está disponível.

A primeira rejeição aplicável pode ser delegação expirada ou escopo excedido, conforme o que o validador confere primeiro. Um revisor real deve registrar todos os defeitos descobertos no trabalho de correção do caso, não interpretar uma saída de programa como aprovação de tudo o que ela não mencionou. A equipe não deve fabricar uma delegação nova nem permitir que o custodiante aja com base nesse pedido.

A resposta correta é reter a coleta ou a mudança de serviço, identificar a rota responsável de escalada de governança ou de liderança do incidente, obter um registro atual ou um aprovador designado por canais autorizados, e registrar a decisão sem resolução. Escalada é uma tentativa de obter autoridade, não uma forma alternativa de autoridade.

Estes dois exemplos não são eventos do incidente R1–R8 e não devem ser inseridos na linha do tempo das 09:05.

1.3a.10 Um caminho seguro de escalada não concede permissão

Um caminho de contato de emergência pode ser necessário quando o aprovador ordinário ou o substituto não pode ser validado. Mas a palavra “escalar” é muitas vezes mal usada no sentido de “encontrar qualquer pessoa sênior o bastante para dizer sim”. Essa abordagem mina a razão de registrar delegações e autoridade limitada.

Um procedimento válido de escalada especifica quem recebe a decisão bloqueada, qual informação pode ser revelada, qual papel verifica a nomeação atual, como obter ou esclarecer autorização, e o que o operador técnico não deve fazer enquanto a decisão está sem resolução.

Para um pedido de coleta cuja aprovação falta, o analista pode continuar avaliando registros já fornecidos e autorizados sob o escopo permitido. Isso não autoriza acesso a um sistema novo. Para uma mudança potencialmente disruptiva sem rota verificada do responsável pelo serviço, o coordenador pode documentar riscos e pedir uma decisão válida; não autoriza execução com base só na urgência.

AR1 inclui SAFE_ESCALATION. A saída é ESCALATE_HOLD_DELEGATION_EXPIRED: uma escalada é pedida enquanto a ação original permanece retida. Isto é deliberadamente diferente de REHEARSAL_PATH_VALID_NOT_EXECUTED.

Um programa mais forte do mundo real poderia ter um mecanismo documentado à parte de autorização de emergência. Se assim for, o escopo, os pré-requisitos, o aprovador responsável e a verificação precisariam ser testados como outra regra de autoridade explicitamente versionada. AR1 nem assume nem inventa tal mecanismo.

Isto difere da repetição F1 do módulo 4 da edição inglesa, ausente deste arquivo, em que um aprovador fica indisponível durante uma resposta fictícia. O exercício atual testa, em vez disso, se o registro anterior ao incidente e o processo de alternativa estão prontos e atuais, bem antes de qualquer incidente da série R começar.

1.3a.11 Um registro precisa ser testado contra controles negativos

Uma lista de contatos pode parecer correta no caminho mais fácil e falhar quando uma pessoa sai, uma delegação expira ou um pedido muda de escopo. Um teste significativo de prontidão precisa, portanto, de controles positivos e negativos.

O controle positivo pergunta se os aprovadores corretos, o escopo, a versão, o custodiante, os recibos e os sinalizadores de confirmação produzem uma aprovação limitada de prontidão. Outro controle positivo testa o delegado especificamente documentado dentro da janela válida de tempo. Essas verificações demonstram só a lógica do registro simulado.

Os controles negativos mudam de propósito uma propriedade de cada vez: substituir o aprovador pela pessoa errada, ampliar os objetos pedidos, omitir o recibo de aprovação, usar uma versão desatualizada do registro, mudar o custodiante, usar um canal de confirmação não aprovado, suprimir a confirmação, revogar um delegado, ou avançar a hora do teste além da expiração. Cada um deve produzir um motivo distinto de retenção.

Por que insistir nisto? Se o verificador aceita todo teste, pode não estar impondo nenhuma restrição real. Se rejeita até pedidos válidos, a organização poderia ser incapaz de agir com eficiência quando um incidente real exige uma decisão. A qualidade de um controle de prontidão depende dos dois tipos de comportamento.

O laboratório produz um código primário de rejeição, para reprodutibilidade. Numa revisão real, outros defeitos podem coexistir. Os revisores devem evitar declarar que todos os campos não relatados eram válidos só porque o verificador parou na primeira falha.

Um controle negativo não cria um incidente. Mudar a data de um recibo de treinamento para simular expiração não significa que a delegação real de alguém expirou.

1.3a.12 Deriva de versão e cópias paralelas

Registros de autoridade mudam com frequência quando empregados rodam, serviços passam de equipe ou contatos de emergência são atualizados. Um ensaio anterior ao incidente deve incluir uma verificação de consistência de versão. O solicitante, o papel aprovador e o custodiante devem ter um modo confiável de determinar que estão usando a mesma edição atual do registro.

No AR1, a versão AR-3 é a edição sintética atual. Um pedido copiado que ainda se refere a AR-2 falha com HOLD_STALE_REGISTER. O programa não tenta inferir que a edição mais antiga ainda possa estar “perto o bastante”.

Há um intervalo separado de validade do registro inteiro. A edição de exemplo só é aceita de 1º de setembro até antes de 1º de outubro de 2026. Uma verificação em 2 de outubro devolve HOLD_REGISTER_OUT_OF_DATE mesmo quando o conteúdo, no resto, se parece com um pedido válido.

Essas verificações respondem a perguntas diferentes. Um descompasso de versão significa que o pedido não se apoia na edição atual designada; a expiração do registro significa que o período declarado de confiança da edição passou. Um delegado individual também pode expirar enquanto o próprio registro permanece válido. Um teste de qualidade distingue os três, em vez de chamar todos de “erro de contato”.

Se duas cópias remotas discordam, nenhum título de planilha nem valor em cache local deve vencer só porque é conveniente. O dono de governança da organização precisa de uma fonte autoritativa definida e de um caminho de correção. O líder da resposta deve reter qualquer ação cuja autoridade não possa ser resolvida com segurança.

1.3a.13 Prova de identidade e prova de autoridade são independentes

Quem liga pode ser genuinamente a pessoa que afirma ser e ainda carecer de autoridade para uma coleta ou uma interrupção particulares. Por outro lado, uma entrada de diretório pode listar corretamente um papel que agora pertence a outra pessoa. O exercício deve, portanto, distinguir confiança de identidade de confiança de escopo de decisão.

Um método aprovado de retorno pode ajudar a validar quem está respondendo, assumindo que a organização real o implementa de forma adequada. Não estabelece que a delegação do respondente cobre todos os objetos. Uma delegação versionada pode estabelecer o escopo documentado, mas não prova que uma mensagem particular foi enviada pelo delegado listado. As duas verificações importam.

As cadeias literais do AR1 não são autenticação. O campo confirmed=True é fornecido pelo instrutor como premissa de entrada; nenhum desafio-resposta, token de acesso, assinatura ou telefonema real é executado. O script não pode verificar o quadro de empregados, números reais de telefone nem aprovações organizacionais atuais.

Um estudante introdutório deve ser capaz de dizer: “O campo sintético de identidade coincidiu com o delegado esperado e a rota sintética foi declarada confirmada; num ambiente real eu precisaria de confirmação autenticada e de um registro autoritativo e atual de delegação antes de confiar em qualquer dos dois.” Isso é mais defensável do que alegar que o código autenticou um humano.

O revisor também precisa evitar usar o registro como permissão para reunir registros de identidade sem relação. Autoridade para aprovar um pedido de auditoria de reserva não é um direito ilimitado de investigar toda pessoa associada ao serviço.

1.3a.14 Artefatos de ensaio e evidência de encerramento

Um ensaio útil anterior ao incidente deixa para trás mais do que uma captura de tela de aprovação. O pacote de evidência deve identificar a versão testada do registro, a operação simulada, o escopo de objetos afetados, a hora da verificação, os papéis primário e alternativo de decisão, o custodiante designado, o requisito da rota de confirmação, a entrada da peça, o estado esperado e o estado real.

Deve registrar à parte que o exercício usou identidades e recibos fictícios, que nenhuma ação de produção ocorreu e que o programa não autenticou nenhuma fonte real. Um revisor independente deve conseguir executar de novo o mesmo script e entender por que cada caso negativo foi retido.

Um tíquete de correção pode ser aberto se um ensaio encontra um substituto desatualizado ou ausente, um escopo ambíguo, nenhum canal aprovado de confirmação, períodos de delegação sobrepostos, ou um responsável sem caminho definido de retorno. Um tíquete não se encerra só por atualizar uma página de contatos. O teste de encerramento deve repetir os casos positivos e negativos relevantes sob uma versão revista do registro e reter o resultado.

Por exemplo, uma correção de delegação obsoleta poderia exigir: um administrador nomeado do registro, um registro atual datado, um sucessor documentado, uma operação e uma expiração explicitamente limitadas, uma rota confirmada de retorno e um teste independente no qual o delegado antigo expirado é rejeitado enquanto a rota designada atual passa. Isso é uma melhoria mensurável de capacidade.

O avaliador do treinamento deve evitar atribuir uma porcentagem de “correção da autoridade organizacional” com base nos casos de brinquedo. Um teste sintético pequeno valida só as peças especificadas.

1.3a.15 Como usar esta preparação sem contaminar a Rodada A

O incidente canônico da Harbor Library começa com R1–R8, não com o ensaio AR1. A tabela da série R relata uma entrada, acesso ao painel, mudanças de reserva, um relato de frequentador, treinamento agendado, conclusão de um trabalho de cópia e um resumo de rede com detalhe de destino ausente. Não contém o quadro do AR1, datas de emissão de delegação, recibos de aprovação nem rotas de confirmação.

Quem responde às 09:05 pode usar a prática geral aprendida com AR1: confirmar o responsável adequado, o escopo e a aprovação antes de ampliar a coleta ou restringir o serviço. Mas não pode afirmar “o responsável já aprovou porque o AR1 passou”, nem incluir o pessoal inventado do ensaio como atores reais da Harbor Library.

O próprio caso do capítulo 01 autoriza uma análise limitada de sala dos registros sintéticos fornecidos, e só isso. Toda coleta adicional de evidência e toda mudança de controle semelhante à de produção permanecem propostas, a menos que o caso fictício forneça explicitamente uma aprovação e um resultado posteriores. AR1 não acrescenta tal resultado.

Numa organização futura, a validação de autoridade antes do incidente reduz um tipo de incerteza; não elimina a necessidade de uma decisão contemporânea no momento da resposta. O sucesso de um ensaio anterior pode sustentar confiança no procedimento e ainda exigir verificações atuais de nomeação, escopo específico do caso, aprovação e recibos de execução.

Esta é a distinção-chave em relação a D1 (a fonte proposta de evidência existe e funciona?), BSL1 (o serviço atende a um invariante de negócio aprovado?), PATH1 (quais funções dependem de quais componentes?) e F1 (o que acontece quando um aprovador fica indisponível durante um incidente?). AR1 avalia o caminho governado de permissão na preparação, antes de qualquer dessas ações ser necessária. F1 pertence a material posterior da edição inglesa e não está neste manuscrito.

1.3a.16 Síntese da seção

Um mapa de autoridade não está completo só porque os nomes dos papéis são sensatos. Uma equipe deve conseguir determinar se a versão atual do registro é válida, se a pessoa correta ou o delegado documentado pode aprovar uma operação e um escopo de objetos exatos, se o custodiante designado é apropriado, se a decisão foi confirmada por uma rota aprovada, e se uma condição ausente ou inválida interrompe o pedido.

Um caminho simulado válido não deve se tornar uma aprovação real. Um caminho inválido deve levar a uma retenção documentada e a uma escalada segura, não à substituição silenciosa por uma pessoa que soa sênior. O estudante que consegue fazer essas distinções está mais bem preparado para coordenar sob pressão sem tratar a urgência como autorização.

A peça Python a seguir fornece um conjunto reproduzível de verificações positivas e negativas de autoridade. Devolve de propósito nenhuma ação executada de produção em todo cenário.

1.3b Laboratório offline AR1 — autoridade versionada e verificações de delegação

Classificação: Laboratório inteiramente fictício, anterior ao incidente, executado contra um registro inventado. Não é um incidente, um diretório real de empregados, uma aprovação organizacional, um retorno autenticado, evidência da série R nem a repetição F1 durante o incidente.

Objetivo de aprendizagem: Conferir operação pedida e escopo de objetos, versão atual do registro, aprovador nomeado ou delegado válido, custodiante, recibo, rota de confirmação e expiração antes de permitir até uma aprovação simulada de caminho de prontidão. Demonstrar que a escalada retém o pedido inseguro em vez de autorizá-lo.

Ambiente: só a biblioteca padrão do Python 3. Tudo corre em memória. Sem arquivos, rede, contas, telefonia, aplicações de conversa, credenciais, operações privilegiadas ou dados pessoais.

Peça: O registro artificial de autoridade é AR-3, declarado válido de 1º de setembro até antes de 1º de outubro de 2026. O delegado separado alternate-sim pode preencher o papel de responsável pelo serviço só para a operação de treinamento pause_staff_writes em staff-write-route, das 13:00 até antes das 14:30 UTC em 15 de setembro, salvo se revogado. O exemplo de auditoria de treinamento concerne só TR-01 e TR-02. As identidades literais são apelidos de papel e não correspondem a humanos reais.

Programa reproduzível

from datetime import datetime
from copy import deepcopy

def utc(s):
    return datetime.fromisoformat(s.replace("Z", "+00:00"))

REGISTRY = {
    "version": "AR-3",
    "valid_from": utc("2026-09-01T00:00Z"),
    "valid_until": utc("2026-10-01T00:00Z"),
    "approver": {
        "incident_lead": "lead-sim",
        "service_owner": "owner-sim",
    },
    "delegation": {
        "delegate": "alternate-sim",
        "role": "service_owner",
        "operations": {"pause_staff_writes"},
        "scope": {"staff-write-route"},
        "valid_from": utc("2026-09-15T13:00Z"),
        "valid_until": utc("2026-09-15T14:30Z"),
        "revoked": False,
    },
    "custodians": {
        "training-audit": "audit-custodian-sim",
        "staff-write-route": "app-operator-sim",
    },
}

RULES = {
    "collect_training_audit": {
        "resource": "training-audit",
        "allowed": {"TR-01", "TR-02"},
        "roles": ("incident_lead",),
    },
    "pause_staff_writes": {
        "resource": "staff-write-route",
        "allowed": {"staff-write-route"},
        "roles": ("incident_lead", "service_owner"),
    },
}

def approval(principal, receipt="SIM-RECEIPT",
             route="registered-callback", confirmed=True):
    return {
        "principal": principal,
        "receipt": receipt,
        "route": route,
        "confirmed": confirmed,
    }

BASE = {
    "version": "AR-3",
    "as_of": utc("2026-09-15T14:15Z"),
    "operation": "collect_training_audit",
    "resource": "training-audit",
    "objects": {"TR-01"},
    "executor": "audit-custodian-sim",
    "approvals": {"incident_lead": approval("lead-sim")},
    "escalate": False,
}

PAUSE = {
    **deepcopy(BASE),
    "operation": "pause_staff_writes",
    "resource": "staff-write-route",
    "objects": {"staff-write-route"},
    "executor": "app-operator-sim",
    "approvals": {
        "incident_lead": approval("lead-sim"),
        "service_owner": approval("alternate-sim"),
    },
}

def evaluate(c, registry=REGISTRY):
    reason = None
    if c["version"] != registry["version"]:
        reason = "STALE_REGISTER"
    elif not (registry["valid_from"] <= c["as_of"]
              < registry["valid_until"]):
        reason = "REGISTER_OUT_OF_DATE"
    elif c["operation"] not in RULES:
        reason = "UNKNOWN_OPERATION"
    else:
        rule = RULES[c["operation"]]
        if not c["objects"]:
            reason = "EMPTY_SCOPE"
        elif (c["resource"] != rule["resource"]
                or not c["objects"].issubset(rule["allowed"])):
            reason = "SCOPE_EXCEEDED"
        elif c["executor"] != registry["custodians"][c["resource"]]:
            reason = "WRONG_CUSTODIAN"
        else:
            for role in rule["roles"]:
                item = c["approvals"].get(role)
                if item is None or not item.get("receipt"):
                    reason = "APPROVAL_MISSING"
                    break

                if item["principal"] != registry["approver"][role]:
                    delegate = registry["delegation"]
                    if (item["principal"] != delegate["delegate"]
                            or role != delegate["role"]
                            or c["operation"] not in delegate["operations"]
                            or not c["objects"].issubset(delegate["scope"])):
                        reason = "WRONG_APPROVER"
                        break
                    if delegate["revoked"]:
                        reason = "DELEGATION_REVOKED"
                        break
                    if not (delegate["valid_from"] <= c["as_of"]
                            < delegate["valid_until"]):
                        reason = "DELEGATION_EXPIRED"
                        break

                if item["route"] != "registered-callback":
                    reason = "UNAPPROVED_CHANNEL"
                    break
                if not item["confirmed"]:
                    reason = "CONFIRMATION_MISSING"
                    break

    if reason is None:
        return "REHEARSAL_PATH_VALID_NOT_EXECUTED"
    if c["escalate"]:
        return "ESCALATE_HOLD_" + reason
    return "HOLD_" + reason

CASES = [
    ("VALID_AUDIT", BASE),
    ("VALID_DELEGATED_PAUSE", PAUSE),
    ("EXPIRED_DELEGATE",
     {**PAUSE, "as_of": utc("2026-09-15T14:31Z")}),
    ("WRONG_PERSON",
     {**PAUSE, "approvals": {
         **PAUSE["approvals"],
         "service_owner": approval("visitor-sim")}}),
    ("EXCESS_SCOPE",
     {**BASE, "objects": {"TR-01", "newsletter-sim"}}),
    ("EMPTY_OBJECTS",
     {**BASE, "objects": set()}),
    ("APPROVAL_ABSENT",
     {**PAUSE, "approvals": {
         "incident_lead": approval("lead-sim")}}),
    ("STALE_VERSION", {**BASE, "version": "AR-2"}),
    ("WRONG_CUSTODIAN",
     {**BASE, "executor": "app-operator-sim"}),
    ("BAD_CHANNEL",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", route="unregistered-chat")}}),
    ("NO_CONFIRMATION",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", confirmed=False)}}),
    ("REVOKED_DELEGATE", PAUSE, {
        **REGISTRY,
        "delegation": {**REGISTRY["delegation"], "revoked": True},
    }),
    ("EXPIRED_REGISTER",
     {**BASE, "as_of": utc("2026-10-02T14:15Z")}),
    ("MISSING_RECEIPT",
     {**BASE, "approvals": {
         "incident_lead": approval(
             "lead-sim", receipt="")}}),
    ("SAFE_ESCALATION",
     {**PAUSE,
      "as_of": utc("2026-09-15T14:31Z"),
      "escalate": True}),
]

for name, case, *overrides in CASES:
    registry = overrides[0] if overrides else REGISTRY
    print(name, evaluate(case, registry))

assert evaluate(BASE) == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
assert evaluate({**BASE, "objects": set()}) == "HOLD_EMPTY_SCOPE"
assert evaluate(CASES[11][1], CASES[11][2]) == "HOLD_DELEGATION_REVOKED"
assert (evaluate(CASES[-1][1])
        == "ESCALATE_HOLD_DELEGATION_EXPIRED")

Verificação de aprovação presa ao pedido (ensaio suplementar AR1)

O programa AR1 existente modela corretamente o sinalizador de revogação do registro governado, o escopo não vazio de objetos, delegados válidos, o custodiante permitido e o canal aprovado de confirmação. Os quinze resultados publicados se reproduzem corretamente. Contudo, a função central evaluate testa se um item simulado de aprovação existe; não testa se o registro da decisão emissora prende esse item ao identificador específico do pedido, à operação, à fonte e ao conjunto de objetos.

Por exemplo, a proposta original BASE pede TR-01 e inclui um recibo fictício genérico chamado SIM-RECEIPT. Se o pedido é mudado para outro objeto de resto permitido, TR-02, enquanto o mesmo recibo é reutilizado, a função original devolve REHEARSAL_PATH_VALID_NOT_EXECUTED. Esta é uma limitação reproduzível do validador de brinquedo. Não é evidência de que uma organização real aprovou o segundo objeto.

A lição de governança anterior ao incidente não deve chamar esse segundo pedido de aprovado. O registro simulado de aprovação precisa estar associado a um identificador estável de pedido e à operação, ao recurso, aos objetos e ao papel aprovados. A verificação suplementar seguinte introduz um registro fictício do lado do emissor, pequeno e independente, que o solicitante não pode redefinir em silêncio dentro do cartão avaliado. Não fornece autenticação real de identidade, assinatura digital nem permissão válida de produção.

Listagem suplementar AR1 em Python 3 — rode depois do programa AR1 completo já existente

# These are invented issuer-side approval records for the classroom.
# The original AR1 program must have been executed first, so BASE,
# PAUSE, RULES, REGISTRY and evaluate are already defined.
SIMULATED_ISSUED_APPROVALS = {
    ("TRAIN-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "collect_training_audit", "training-audit",
        frozenset({"TR-01"})
    ),
    ("PAUSE-001", "incident_lead"): (
        "lead-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
    ("PAUSE-001", "service_owner"): (
        "alternate-sim", "SIM-RECEIPT",
        "pause_staff_writes", "staff-write-route",
        frozenset({"staff-write-route"})
    ),
}

def evaluate_with_approval_binding(card):
    preliminary = evaluate(card)
    if preliminary != "REHEARSAL_PATH_VALID_NOT_EXECUTED":
        return preliminary

    for role in RULES[card["operation"]]["roles"]:
        item = card["approvals"][role]
        presented = (
            item["principal"], item["receipt"],
            card["operation"], card["resource"],
            frozenset(card["objects"])
        )
        issued = SIMULATED_ISSUED_APPROVALS.get(
            (card.get("request_id"), role)
        )
        if presented != issued:
            return "HOLD_RECEIPT_SCOPE_MISMATCH"
    return preliminary

valid_audit = {**BASE, "request_id": "TRAIN-001"}
valid_pause = {**PAUSE, "request_id": "PAUSE-001"}

reused_receipt = {
    **valid_audit, "objects": {"TR-02"}
}
wrong_reference = {
    **valid_audit, "request_id": "PAUSE-001"
}

for name, card in (
    ("REQUEST_SCOPED_TR01", valid_audit),
    ("REQUEST_SCOPED_PAUSE", valid_pause),
    ("REUSED_RECEIPT_TR02", reused_receipt),
    ("REUSED_REQUEST_ID", wrong_reference),
):
    print(name, evaluate_with_approval_binding(card))

assert (
    evaluate_with_approval_binding(valid_audit)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(valid_pause)
    == "REHEARSAL_PATH_VALID_NOT_EXECUTED"
)
assert (
    evaluate_with_approval_binding(reused_receipt)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)
assert (
    evaluate_with_approval_binding(wrong_reference)
    == "HOLD_RECEIPT_SCOPE_MISMATCH"
)

Antes de rodar qualquer dos programas, preveja quais caminhos passam, quais são retidos e se a escalada muda a autoridade. Rode primeiro a listagem original e compare a transcrição de 15 linhas com a resolução AR1. Em seguida, rode a listagem suplementar na mesma sessão Python e compare as quatro linhas adicionais com a resolução presa ao pedido. Explique por que TR-02 passa na verificação original de roteamento, mas falha na verificação separada de vínculo da aprovação. Em particular, o registro, não o pedido, controla a revogação; um conjunto vazio de objetos não é um pedido limitado válido.

Unidade de revisão da semana 1, número 4 — Uma cadeia não é uma confirmação

Objetivo e mecanismo

Explique por que uma verificação de tipo pertence antes da avaliação de autoridade, e por que não deve substituir a própria avaliação de autoridade.

O AR1 original lê if not item["confirmed"]. Sob as regras documentadas de valor de verdade do Python, uma cadeia não vazia é verdadeira. Em consequência, os caracteres "false" não se comportam como o booleano False. Converter essa cadeia com bool() não corrige o significado. Do mesmo modo, testes de igualdade sozinhos podem borrar valores booleanos e inteiros; este portão de ensino exige de propósito o tipo booleano exato.

O defeito não é que o teste original confirmed=False do AR1 estivesse errado: essa linha de base ainda produz uma retenção. O contraexemplo adicional usa um tipo diferente. Na fonte revista, o pedido de resto válido com confirmed="false" passa tanto na função original de roteamento quanto na verificação posterior de recibo preso ao pedido. A verificação de recibo protege a associação do pedido, não a interpretação do campo booleano. Dois controles úteis podem, portanto, coexistir com uma fronteira de entrada não testada.

Esta demonstração concerne só o validador de brinquedo. O sinalizador original de confirmação já era uma premissa simulada, não um retorno real nem uma prova de identidade. O portão novo de tipo impede uma categoria de interpretação não pretendida; não pode tornar o sinalizador fornecido um fato autenticado.

Preserve verificações separadas

Mantenha estas perguntas em ordem: o campo é interpretável sob este contrato; a confirmação de fato diz verdadeiro; o papel atual e a delegação cobrem o pedido exato; o recibo está preso a esse pedido; e que prova do mundo real seria exigida antes de confiar em qualquer dessas premissas?

O invólucro proposto confere a forma do contêiner de aprovação e os tipos booleanos exatos de confirmação, escalada e do sinalizador de revogação do registro atual. Em seguida chama o avaliador existente preso ao recibo, retendo as verificações originais de papel, custodiante, escopo e tempo. Isto deliberadamente não é um validador completo de esquema: campos sem relação ausentes, carimbos malformados, objetos personalizados arbitrários e autenticidade permanecem fora da cobertura alegada.

Não mapeie todo texto inesperado para falso. Um descompasso de esquema e uma confirmação negativa explícita são achados diferentes. Não escale automaticamente uma entrada malformada porque uma cadeia acontece de ser verdadeira. O resultado seguro é uma retenção visível de entrada e um pedido de um registro corretamente tipado e sustentado pela fonte.

Extensão reproduzível do AR1

Rode o programa AR1 original e a listagem de aprovação presa ao pedido numa sessão nova. A extensão abaixo não edita BASE, PAUSE nem as aprovações aninhadas; os exemplos alterados usam cópias independentes. Preveja oito linhas novas de saída. Preste atenção particular ao extremo exato das 14:30: o fim do delegado é exclusivo no contrato original.

# Run after AR1 AND its request-bound approval listing, in the same session.
# This adds a narrow type gate. It is not a full request-schema validator.
def w1_evaluate_typed(card):
    if type(card) is not dict or type(card.get("approvals")) is not dict:
        return "HOLD_INPUT_APPROVAL_SHAPE"
    if type(card.get("escalate")) is not bool:
        return "HOLD_INPUT_ESCALATE_TYPE"
    if type(REGISTRY["delegation"].get("revoked")) is not bool:
        return "HOLD_INPUT_REVOCATION_TYPE"
    for item in card["approvals"].values():
        if type(item) is not dict or type(item.get("confirmed")) is not bool:
            return "HOLD_INPUT_CONFIRMATION_TYPE"
    # Do not replace the role/scope/time/receipt checks with the type check.
    return evaluate_with_approval_binding(card)

w1_text_false = deepcopy(valid_audit)
w1_text_false["approvals"]["incident_lead"]["confirmed"] = "false"
w1_real_false = deepcopy(valid_audit)
w1_real_false["approvals"]["incident_lead"]["confirmed"] = False
print("W1_ORIGINAL_TEXT_FALSE", evaluate_with_approval_binding(w1_text_false))
print("W1_TYPED_TEXT_FALSE", w1_evaluate_typed(w1_text_false))
print("W1_TYPED_REAL_FALSE", w1_evaluate_typed(w1_real_false))
print("W1_TYPED_VALID", w1_evaluate_typed(valid_audit))
print("W1_TYPED_REUSED_RECEIPT", w1_evaluate_typed(reused_receipt))
for clock in ("13:00", "14:29", "14:30"):
    card = {**valid_pause, "as_of": utc("2026-09-15T" + clock + "Z")}
    print("W1_DELEGATE_" + clock, w1_evaluate_typed(card))

Prática suplementar W1-R4

Objetivo: distinguir rejeição de entrada, não confirmação explícita, rejeição de escopo do pedido e expiração de delegação. Entradas: as regras originais do AR1, os recibos sintéticos emitidos e as oito chamadas acima. Artefato exigido: oito linhas de saída; uma comparação de quatro linhas entre texto falso, booleano falso, verdadeiro válido e recibo reutilizado; mais uma verificação de delegação em três horários, 13:00, 14:29 e 14:30. Explique por que passar no portão novo de tipo não é uma aprovação nova.

Restrições: não acrescente credenciais reais nem detalhes de retorno; mantenha inalterado o vínculo do recibo emitido; use o intervalo semiaberto original do delegado; preserve as quatro linhas de responsabilidade do EX006 e o registro de três linhas de lacunas do EX013 mais o tíquete. Avaliação: um ponto para cada um: a distinção de tipo, a retenção explícita de falso, o vínculo preservado do recibo, o limite exato de expiração e a recusa de alegar autorização real. Resolução.

Rubrica: 3 = cinco pontos da fonte: distinção de tipo, retenção de falso explícito, vínculo do recibo, limite exato de expiração e recusa de autorização real;; 2 = a maior parte desses pontos, com uma omissão de limite;; 1 = responde, mas omite fonte, limite ou trata uma cadeia como confirmação;; 0 = nenhum.

Síntese da revisão

Um booleano corretamente tipado é um campo utilizável, não consentimento autenticado. Um recibo preso ao pedido e um portão de tipo tratam de modos diferentes de falha; nenhum substitui o outro.

1.3c Ensaio de prontidão AR1 com dois papéis

Objetivo: Antes de um incidente simulado, verificar que uma segunda pessoa consegue reconstruir a rota correta de autoridade a partir do registro atual e do pacote de pedido, identificar uma delegação expirada ou fora de escopo, e escolher uma escalada segura sem pedir ao autor do pacote que invente uma aprovação ausente.

Papéis: Administrador do registro / autor do pacote e revisor independente de prontidão. Um facilitador pode observar, mas não muda os resultados declarados depois de ver a primeira resposta do revisor.

Únicos dados permitidos: O registro artificial AR1, o pedido sintético e os recibos simulados. Nenhum detalhe real de empregado, diretório de empresa, telefone, credencial ou serviço pode ser usado.

Fase 1 — O autor congela o pacote

O administrador prepara AR1-packet-v1 e registra:

1. Identificador do registro, versão, papel emissor, intervalo de vigência e estado da fonte.
2. Operação de treinamento e conjunto permitido de objetos.
3. Papel primário de aprovação e delegado nomeado, inclusive emissor, escopo da operação, validade e estado de revogação.
4. Custodiante ou operador executor da tarefa selecionada.
5. Rota declarada e registrada de confirmação, e o que uma confirmação real teria de estabelecer.
6. Um identificador simulado de pedido, a hora selecionada, a operação pedida e os objetos nomeados.
7. A saída segura esperada se o caminho primário ou alternativo não puder ser verificado.
8. A afirmação explícita “só revisão de treinamento; nenhum incidente atual nem autorização de produção.”

O pacote precisa ser congelado antes de o revisor começar. Um campo ausente permanece ausente; o autor não pode reparar o registro em silêncio depois de conhecer a objeção do revisor.

Fase 2 — O revisor reconstrói de forma independente

Dê ao revisor um cenário válido claramente rotulado e um cenário de delegado expirado, nessa ordem. Sem ajuda do autor do pacote, o revisor precisa identificar: a edição atual do registro; os papéis corretos de aprovação; se o delegado nomeado ainda é válido para o pedido exato; o custodiante correto; a rota aprovada de confirmação; se todos os recibos simulados exigidos estão presentes; e a decisão de reter ou escalar se qualquer condição falha.

O revisor entrega AR1-review-v1 com uma tabela pequena campo a campo e um parágrafo que explica o próximo passo seguro. Um revisor que diz “a pessoa é familiar, portanto aja imediatamente” falha mesmo que identifique corretamente o contato.

O revisor pode consultar o registro congelado e o pedido, mas não pode perguntar ao autor se uma delegação ausente “provavelmente existe”. Se um campo necessário à autorização está ausente, a resposta correta é desconhecido/retenção, com um pedido de fonte autoritativa.

Fase 3 — Preservar e julgar

Congele a primeira resposta. Compare a decisão com os campos da fonte e com a saída do código. Registre cada discrepância como campo ausente do pacote, interpretação incorreta ou pergunta sem resolução de fonte ou de autoridade. Não apague a primeira entrega quando evidência corrigida se torna disponível.

Um acompanhamento AR1-packet-v2 pode substituir uma delegação expirada por um registro fictício recém-aprovado, mas essa versão nova precisa dos próprios testes de validade e de confirmação. A segunda tentativa não é prova de que o primeiro pacote era adequado.

Regras de aceitação e de falha

Uma aprovação limitada exige que o revisor identifique a versão correta, o serviço, a operação e o escopo, a delegação válida ou inválida, o custodiante, o requisito de confirmação e a condição segura de retenção ou escalada, sem alegar execução. Uma falha crítica ocorre se o revisor aceita um substituto expirado ou revogado, a pessoa errada, objetos não autorizados, um recibo de decisão ausente ou um canal não verificado como permissão para prosseguir. Uma falha corrigível inclui uma referência de versão ausente ou um ponteiro de pacote pouco claro que deixa o revisor incapaz de determinar a autoridade; o pedido atual permanece retido até a correção.

Isto é um ensaio de preparação. O desempenho não diz o que aconteceu no incidente R1–R8 da Harbor Library. Mede um procedimento pequeno e versionado de verificação de autoridade, não a confiabilidade real do quadro de emergência de uma organização real.

Marco resolvido

Um substituto nomeado numa lista antiga de contatos não pode aprovar uma coleta nova só pelo cargo. Compare a versão atual do registro, o escopo de objetos, a expiração e o caminho registrado de confirmação; se um falha, registre a aprovação como pendente e escale pela rota designada.

Prática — Aula 04

EX006 — Atribuição de papéis

Objetivo: tornar visíveis recomendação, aprovação, execução e verificação. Entradas: os papéis fictícios da seção 1.3, R7 e o escopo de sala. Saída: uma tabela de responsabilidade de quatro linhas para uma possível interrupção de reservas, a preservação de R1–R5, a coordenação da próxima revisão e um teste contido de restauração. Nomeie o dono da tarefa, quem a aprova sob as regras do exercício e o que verificaria a conclusão. Distinga planejar um teste de restauração de tê-lo executado. Uma nota 2 não delega uma decisão de interrupção ao analista nem trata R7 como restauração testada.

Tarefa suplementar PATH1 (depois do artefato exigido):

Requisito adicional: Mantenha a matriz original de papéis com quatro linhas. Para a possível interrupção de reservas, distinga um procedimento aprovado de recepção manual de pedidos da aceitação real de reserva; nomeie o responsável pelo serviço da decisão hipotética de modo degradado, o custodiante da central para os recibos e o revisor que autorizaria a reconciliação.

Tarefa suplementar AR1 (depois do artefato exigido):

Verificação adicional: Preserve a tabela original de responsabilidade com quatro linhas. Para as linhas de preservação de evidência e de possível interrupção de reservas, acrescente uma referência curta a onde uma nomeação atual de responsável ou delegado e uma atribuição de custodiante seriam conferidas antes de se confiar nelas. Declare qual aprovação permanece pendente se um substituto está expirado, e que evidência verificaria que um operador autorizado de fato executou uma ação posterior.

Critério de crédito completo: O analista, o líder do incidente, o responsável pelo serviço, o custodiante ou operador e o revisor retêm responsabilidades lógicas distintas. Uma listagem publicada de diretório não basta para provar um delegado válido, e um ensaio positivo não é uma coleta executada nem uma mudança de serviço.

Resolução: EX006 no apêndice final.

Rubrica: 3 = nota 2 da fonte: quatro linhas com papéis distintos, interrupção não delegada ao analista, R7 distinto de restauração testada, e ensaio positivo distinto de execução;; 2 = as quatro linhas existem, mas um papel decide fora da autoridade do exercício;; 1 = responde à pergunta, mas omite fonte, limite, autoridade ou trata R7 como teste feito;; 0 = nenhum.

EX013 — Lacuna de prontidão

Objetivo: transformar uma fraqueza do exercício numa mudança mensurável de preparação. Entradas: o mapa de serviço, a tabela de autoridade, R7–R8 e o ateliê da seção 1.8. Saída: um registro de lacunas com três linhas, com capacidade ausente, consequência e dono; depois um tíquete de melhoria com justificativa de prioridade, mudança específica, prazo e um ensaio de aprovação ou falha. Uma nota 2 nomeia um teste que de fato demonstraria a mudança, como um ensaio de decisão do responsável e do substituto ou um ensaio contido de restauração, em vez de apenas publicar uma página de política.

Extensão: O tíquete de melhoria precisa incluir um ensaio falseável com critério de aprovação e de falha. Um ensaio de autoridade alternativa pode testar um aprovador primário indisponível; tíquetes defensáveis alternativos podem testar recuperação de log ou recuperação isolada.

Para crédito completo: Apenas escrever ou publicar uma política não satisfaz um exercício que pede a quem estuda que demonstre uma capacidade.

Tarefa suplementar AR1 (depois do artefato exigido):

Verificação adicional: Retenha o registro de lacunas com três linhas mais um tíquete de melhoria. Onde o registro de responsável ou substituto é identificado como lacuna, exija uma revisão versionada do registro de autoridade e um ensaio negativo de prontidão que confira delegado expirado, aprovador errado ou escopo excessivo. Defina o administrador responsável do registro, a evidência de conclusão e uma regra de falha ou reabertura. Não duplique a repetição F1 durante o incidente, que pertence a material posterior e não está neste manuscrito.

Critério de crédito completo: O tíquete não pode encerrar só porque uma lista de contatos foi editada. Precisa demonstrar, sob uma versão simulada congelada, que um caminho válido passa e que rotas inválidas permanecem bloqueadas, com as entradas originais e o resultado independente preservados.

Resolução: EX013 no apêndice final.

Rubrica: 3 = nota 2 da fonte: três lacunas com dono, tíquete com teste que demonstra a mudança, e encerramento que não se reduz a editar uma lista de contatos;; 2 = o registro e o tíquete existem, mas o teste não é falseável;; 1 = responde à pergunta, mas omite fonte, limite, dono ou publica só uma página de política;; 0 = nenhum.