O processo de revisão pós-incidente

Uma parte fundamental de uma revisão pós-incidente é a construção de uma cronologia compartilhada e precisa que reflita a natureza não linear de um incidente.

Por não-linear, queremos dizer que os incidentes quase nunca são apenas "esta coisa acontece, e então isso aconteceu, então nós percebemos, então nós fizemos algo, e então estamos prontos". As pessoas entram e saem, pessoas diferentes notam e tentam coisas diferentes; alguns funcionam, outros não. E se várias pessoas estão trabalhando ao mesmo tempo, essas coisas também podem acontecer ao mesmo tempo, então é um pouco mais complicado.

Para criar uma linha do tempo como esta, mesmo que complexa, há sempre um primeiro passo importante: reunir os dados.

Reunir os dados

Antes de realizar uma revisão pós-incidente, você precisa primeiro coletar dados. Especificamente, precisa de recolher o máximo possível da conversa e do contexto (técnico e não técnico) em torno do evento para poder usar todos os dados cruciais que ele contém. A conversa entre os membros da equipe que aconteceu durante a interrupção ou incidente será uma das suas fontes mais ricas de informação.

Também deve reunir dados do seu sistema de monitorização e de outros locais dos quais as pessoas envolvidas no incidente obtiveram contexto. Que informações eles estavam recebendo de seus sistemas quando o incidente estava acontecendo?

E, finalmente, se possível, seria útil ter uma melhor perceção do que mudou antes e durante o incidente, porque as mudanças são frequentemente fatores contribuintes quando um incidente ocorre.

Podemos olhar para este processo como três partes separadas:

• Colete a conversa: Em outros módulos deste caminho de aprendizagem, mencionamos que é importante criar um lugar específico para as pessoas se comunicarem durante um incidente. Durante o incidente, o ideal é que as pessoas compartilhem o que funcionou e o que falhou, o que hesitam em tentar, o que tentaram no passado. Esta conversa entre as pessoas à medida que trabalham e resolvem o problema é a sua melhor fonte de aprendizagem.
• Determine o contexto: As pessoas em um incidente estão recebendo sinais de vários lugares. Um lugar principal é o seu sistema de monitoramento. Discutimos a importância de ter um sistema de monitoramento sólido em um módulo anterior neste caminho de aprendizagem. Idealmente, deveríamos ser capazes de olhar para o sistema de monitorização para construir um instantâneo de um ponto no tempo para o período de tempo ao redor ou relacionado ao incidente.
• Encontre as alterações: você pode fazer isso por meio de logs de atividade e auditoria.

Ferramentas do Azure para ajudar a recolher os dados

O Azure oferece várias ferramentas que podem ajudar neste processo:

Azure DevOps para armazenar metadados sobre o incidente

Num módulo anterior deste percurso de aprendizagem, discutimos a utilização do Azure Boards na suíte Azure DevOps como um único local para recolher toda a informação sobre um incidente a partir da resposta inicial. Isso nos ajuda com perguntas sobre quando um incidente foi declarado pela primeira vez, quem estava de plantão, quem foi designado para o incidente e assim por diante. Também pode usar a Wiki do Azure DevOps como uma forma centralizada de recolher algumas das informações tanto sobre o incidente em si como sobre a conversa que ocorreu durante o incidente.

Microsoft Graph API para extrair a conversa

A Microsoft Graph API fornece uma forma programática de recuperar a conversa recolhida no canal Teams dedicada a este incidente específico. Os dados recolhidos incluem carimbos de data, autoria, edições, respostas e algumas mensagens do sistema, todos os quais podem ajudar na construção de uma cronologia.

Uma forma fácil de começar com a API do Microsoft Graph é usar o Microsoft Graph Explorer. Microsoft Graph Explorer é um navegador de APIs baseado na web que lhe permite escolher chamadas de API a partir de um painel Sample queries e experimentá-las de forma interativa.

Antes de executares as consultas, certifica-te de que o utilizador ou aplicação que estás a usar tem as permissões e o consentimento necessários para o modo de acesso que escolheste. Em cenários delegados, listar equipas juntadas usa Team.ReadBasic.All, listar canais usa Channel.ReadBasic.All, e ler mensagens de canal requer ChannelMessage.Read.All. Se mais tarde automatizares o fluxo de trabalho com acesso somente pela aplicação, usa GET /users/{id | user-principal-name}/joinedTeams em vez do alias apenas delegado /me/joinedTeams, usando a permissão da aplicação Team.ReadBasic.All. Para as etapas de leitura específicas de cada canal, as opções menos privilegiadas, apenas para a aplicação, são ChannelSettings.Read.Group para listar canais e ChannelMessage.Read.Group para ler mensagens, ambas com consentimento específico para cada recurso.

Vamos passar por um conjunto de chamadas API "Microsoft Teams" do Microsoft Graph v1.0 para recuperar a conversa. (As mensagens de canal passaram da beta para a v1.0 há vários anos, pelo que os endpoints beta já não são necessários para este cenário.) Em cada etapa, escolhemos uma consulta, executamos a consulta e depois selecionamos a informação da resposta que nos ajuda no passo seguinte. Em seguida, usamos essas informações para construir a próxima solicitação. Por exemplo, primeiro consultamos uma lista de IDs de equipas para mostrar as equipas de que fazemos parte. Escolhemos aquele de que precisamos da resposta e inserimos esse ID na URL seguinte de consulta para obter uma lista de canais nessa equipa.

Aqui estão as nossas etapas, mostradas como os endpoints do Microsoft Graph v1.0:

1. GET /me/joinedTeams (para encontrar o ID da equipa que usamos num cenário delegado) ou GET /users/{id | user-principal-name}/joinedTeams (para fazer o mesmo num cenário apenas de aplicação).
2. GET /teams/{team-id}/channels (para encontrar o ID do canal que usámos nesse incidente).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (para recuperar a conversa encadeada).
4. Segue @odata.nextLink e replies@odata.nextLink conforme necessário, ou contacta GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies para navegar por tópicos maiores.

Se usou um canal partilhado, note que a joinedTeams API não devolve a equipa anfitriã para um canal partilhado do qual o utilizador é membro direto. Esta ressalva aplica-se quer chame GET /me/joinedTeams ou GET /users/{id | user-principal-name}/joinedTeams. Nesse caso, comece pelos identificadores conhecidos da equipa e do canal ou use as APIs associadas para localizar a equipa anfitriã.

No Explorador de Grafos, pode inserir estes URLs diretamente ou escolher as entradas equivalentes do painel incorporado Sample queries sob Microsoft Teams.

Se mais tarde quiséssemos construir um programa para executar cada uma dessas etapas (e de fato fazemos), há um trechos de código opção na janela de solicitação que apresenta código de exemplo para essa consulta em várias linguagens de programação diferentes.

Dependendo de como a sua equipa usa o Teams, o histórico de mensagens pode também conter mensagens do sistema que ajudam a explicar quando membros foram adicionados ou removidos. No entanto, se precisar de um registo de auditoria autoritativo sobre a pertença ao canal ou alterações de acesso, complemente estes dados com registos de auditoria do Microsoft 365.

Painéis de controlo e cadernos de trabalho para visualização de contexto

Os dashboards do Azure e os workbooks do Azure Monitor podem ambos ajudar a reconstruir o contexto que os operadores viram durante um incidente. Os dashboards são úteis para uma visão operacional rápida dos serviços Azure. Os cadernos de exercícios são geralmente mais adequados para análise de incidentes porque suportam consultas mais detalhadas, parâmetros, análises detalhadas e texto narrativo juntamente com gráficos.

Se já tiver um painel ou livro que captura os sinais certos, defina o intervalo temporal para o período em torno do incidente e use-o para reconstruir o que as pessoas viram à época. Isto pode ser especialmente útil ao correlacionar métricas, registos e alertas em vários recursos.

Dashboards partilhados são recursos do Azure e ainda podem ser exportados como JSON a partir do portal. Esse caminho de exportação/importação é útil quando se quer versionar ou templastizar um dashboard. No entanto, para a maioria dos cenários de investigação pós-incidente, os cadernos de exercícios são a ferramenta mais flexível porque permitem combinar visualizações, consultas KQL e texto explicativo num único artefacto.

Registos de atividade, registos de recursos e Log Analytics para exploração de alterações

Um espaço de trabalho Log Analytics pode receber dados de várias fontes, incluindo o Azure Activity log, Azure resource logs e diagnósticos específicos de serviços. Primeiro, crie um novo espaço de trabalho de Log Analytics. Depois, no portal Azure, abra Monitor → registo de atividade e selecione Exportar registos de atividade no topo do painel. Isto abre uma definição de diagnóstico que permite enviar o registo de atividade de uma subscrição do Azure para o seu espaço de trabalho.

Em pouco tempo, pode usar a Kusto Query Language (KQL) para obter informações detalhadas sobre alterações que ocorreram nessa subscrição desde que ligou a fonte de dados.

Por exemplo, a consulta seguinte mostra informações sobre recursos que foram alterados ou eliminados. Podemos definir o intervalo de tempo na experiência dos Logs para focar mais precisamente no período pouco antes do incidente.

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc

Esta consulta é útil para alterações no plano de gestão, mas lembre-se do que não mostra. AzureActivity captura operações no plano de controlo, como criar, atualizar, eliminar e ações de políticas. Não capta alterações ao nível do plano de dados ou da aplicação dentro de um serviço. Para investigar isso, combine esta consulta com registos de recursos do Azure, registos de auditoria específicos de serviço, histórico de implementação e registos de CI/CD ou controlo de versão.

Uma nota rápida: ao exportar o registo de atividade do Azure, a informação começa a fluir para o espaço de trabalho do Log Analytics a partir desse momento. Não poderá consultar esse espaço de trabalho retroativamente para eventos que ocorreram antes de fazer a ligação.

Essas ferramentas devem ser capazes de lhe dar um bom começo na coleta de informações necessárias para uma cronologia a ser usada em uma revisão pós-incidente. Antes de mergulhar em uma revisão pós-incidente, gostaríamos de alertá-lo sobre algumas armadilhas comuns. Esse é o assunto da nossa próxima unidade.