Processus de révision post-incident
- 7 minutes
Une partie clé d’un examen post-incident est la construction d’une chronologie partagée et précise qui reflète la nature non linéaire d’un incident.
Par nonlinéaire, nous entendons que les incidents ne suivent presque jamais un enchaînement simple du type « cette chose arrive, puis ça, ensuite nous le remarquons, nous intervenons, et voilà c'est fini. » Les personnes interviennent à différents moments, différentes personnes remarquent les incidents et essaient diverses approches ; certaines fonctionnent, d'autres non. Et si plusieurs personnes travaillent en même temps, ces choses peuvent se produire en même temps, donc c’est un peu plus compliqué.
Pour créer une chronologie comme celle-ci, même complexe, il existe toujours une première étape importante : collecter les données.
Collecter les données
Avant de pouvoir effectuer une révision post-incident, vous devez d’abord collecter des données. Plus précisément, vous devez collecter autant de conversation et de contexte (technique et non technique) autour de l’événement que vous pouvez pour pouvoir utiliser toutes les données cruciales contenues dans celui-ci. La conversation entre les membres de l'équipe qui a eu lieu lors de la panne ou de l'incident sera l'une de vos sources d'information les plus riches.
Vous devez également collecter des données à partir de votre système de surveillance et d’autres endroits où les personnes impliquées dans l’incident ont dessiné le contexte. Quelles informations recevaient-elles de vos systèmes lorsque l’incident se passait ?
Enfin, si possible, il serait utile de mieux comprendre ce qui a changé avant et pendant l'incident, car les changements sont souvent des facteurs contribuant à un incident.
Nous pouvons examiner ce processus comme trois parties distinctes :
- Collectez la conversation : dans d’autres modules de ce parcours d’apprentissage, nous avons mentionné qu’il est important d’extraire un endroit spécifique pour que les personnes communiquent pendant un incident. Pendant l’incident, dans l’idéal, les gens partagent ce qui a fonctionné et ce qui a échoué, ce qu’ils hésitent à essayer, ce qu’ils ont essayé par le passé. Cette conversation entre les personnes qui travaillent et résolvent le problème est votre meilleure source d’apprentissage.
- Déterminer le contexte : les personnes d’un incident reçoivent des signaux provenant de différents endroits. Un des principaux lieux est votre système de surveillance. Nous avons discuté de l’importance d’avoir un système de surveillance solide dans un module précédent dans ce parcours d’apprentissage. Dans l'idéal, nous devrions pouvoir examiner le système de surveillance pour créer un instantané temporel pour la période liée à l'incident.
- Recherchez les modifications : vous pouvez effectuer cette opération par le biais des journaux d’activité et d’audit.
Azure outils pour aider à collecter les données
Azure offre un certain nombre d’outils qui peuvent vous aider à ce processus :
Azure DevOps pour contenir les métadonnées relatives à l’incident
Dans un module précédent de ce parcours d’apprentissage, nous avons discuté de l’utilisation de Azure Boards dans la suite Azure DevOps comme un seul endroit pour collecter toutes les informations relatives à un incident à partir de la réponse initiale. Il nous aide à nous poser des questions sur le moment où un incident a été déclaré, qui était à l’appel, qui a été affecté à l’incident, et ainsi de suite. Vous pouvez également utiliser le wiki Azure DevOps comme moyen centralisé d’extraire certaines informations sur l’incident lui-même et la conversation qui s’est produite pendant l’incident.
Microsoft Graph API pour extraire la conversation
Microsoft Graph API fournit un moyen programmatique de récupérer la conversation qui a été collectée à l’intérieur du canal Teams consacré à cet incident spécifique. Les données récupérées incluent les horodatages, la création, les modifications, les réponses et certains messages système, qui peuvent tous vous aider lors de la construction d’une chronologie.
Un moyen simple de bien démarrer avec l’API Microsoft Graph consiste à utiliser l’Explorateur Microsoft Graph. Microsoft Graph Explorer est un navigateur d’API web qui vous permet de choisir des appels d’API à partir d’une requête Sample et de les essayer de manière interactive.
Avant d’exécuter les requêtes, vérifiez que l’utilisateur ou l’application que vous utilisez dispose des autorisations et du consentement requis pour le mode d’accès que vous avez choisi. Dans les scénarios délégués, répertorier les équipes jointes utilise Team.ReadBasic.All, répertorier les canaux utilise Channel.ReadBasic.Allet lire les messages de canal nécessite ChannelMessage.Read.All. Si vous automatisez ultérieurement le flux de travail avec un accès à l’application uniquement, utilisez GET /users/{id | user-principal-name}/joinedTeams plutôt que l’alias délégué uniquement /me/joinedTeams , à l’aide de l’autorisation Team.ReadBasic.All d’application. Pour les étapes de lecture spécifiques au canal, les options applicatives avec le moins de privilèges sont ChannelSettings.Read.Group pour répertorier les canaux et ChannelMessage.Read.Group pour lire les messages, toutes deux avec un consentement spécifique à la ressource.
Nous allons parcourir un ensemble d'appels d'API Microsoft Graph v1.0 « Microsoft Teams » pour récupérer la conversation. (Les messages de canal sont passés de la version bêta à la version 1.0 il y a plusieurs années, donc les points de terminaison bêta ne sont plus nécessaires pour ce scénario.) À chaque étape, nous allons choisir une requête, exécuter la requête, puis sélectionner dans la réponse les informations pertinentes pour l’étape suivante. Nous utilisons ensuite ces informations pour construire la requête suivante. Par exemple, nous interrogeons d’abord une liste d’ID d’équipe pour afficher les équipes dont nous faisons partie. Nous choisissons celui dont nous avons besoin dans la réponse et insérons cet ID dans l’URL de requête suivante pour obtenir la liste des canaux de cette équipe.
Voici nos étapes, présentées comme points de terminaison Microsoft Graph v1.0 :
-
GET /me/joinedTeams(pour rechercher l’ID d’équipe de l’équipe que nous utilisons dans un scénario délégué) ouGET /users/{id | user-principal-name}/joinedTeams(pour effectuer la même opération dans un scénario d’application uniquement). -
GET /teams/{team-id}/channels(pour rechercher l’ID de canal du canal que nous avons utilisé pour cet incident). -
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies(pour récupérer le fil de conversation). - Suivez
@odata.nextLinketreplies@odata.nextLinksi nécessaire, ou appelezGET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/repliespour naviguer à travers des fils plus volumineux.
Si vous avez utilisé un canal partagé, notez que l’API joinedTeams ne retourne pas l’équipe hôte pour un canal partagé dont l’utilisateur est membre direct. Cette mise en garde s’applique si vous appelez GET /me/joinedTeams ou GET /users/{id | user-principal-name}/joinedTeams. Dans ce cas, commencez à partir de l’équipe connue et des identificateurs de canal ou utilisez les API d’équipe associées pour localiser l’équipe hôte.
Dans l’Explorateur Graph, vous pouvez entrer ces URL directement ou sélectionner les entrées équivalentes à partir des requêtes intégrées Sample sous Microsoft Teams.
Si nous voulions plus tard construire un programme pour effectuer chacune de ces étapes (et en effet, nous le faisons), il existe une option d’extraits de code dans la fenêtre de requête qui présente un exemple de code pour cette requête dans un certain nombre de langages de programmation différents.
Selon la façon dont votre équipe utilise Teams, l’historique des messages peut également contenir des messages système qui vous aident à expliquer quand les membres ont été ajoutés ou supprimés. Toutefois, si vous avez besoin d'un audit autorisé de l'appartenance aux canaux ou des modifications d'accès, complétez ces données avec les journaux d’audit de Microsoft 365.
Tableaux de bord et classeurs pour l’affichage contextuel
Les tableaux de bord Azure et les cahiers de travail Azure Monitor peuvent tous les deux aider à reconstruire le contexte que les opérateurs ont vu lors d'un incident. Les tableaux de bord sont utiles pour une vue d’ensemble opérationnelle en un clin d’œil sur les services Azure. Les classeurs sont généralement mieux adaptés à l’analyse des incidents, car ils prennent en charge des requêtes, des paramètres, des explorations et du texte de narration plus riches en même temps que des graphiques.
Si vous disposez déjà d’un tableau de bord ou d’un classeur qui capture les signaux appropriés, définissez son intervalle de temps sur la période autour de l’incident et utilisez-le pour reconstruire ce que les personnes ont vu à l’heure. Cela peut être particulièrement utile lors de la corrélation des mesures, des journaux et des alertes entre plusieurs ressources.
Les tableaux de bord partagés sont Azure ressources et peuvent toujours être exportés en tant que JSON à partir du portail. Ce chemin d’exportation/importation est utile lorsque vous souhaitez mettre en version ou templater un tableau de bord. Toutefois, pour la plupart des scénarios d’investigation après incident, les classeurs sont l’outil plus flexible, car ils vous permettent de combiner des visualisations, des requêtes KQL et du texte explicatif dans un seul artefact.
Journaux d’activité, journaux de ressources et Log Analytics pour l’exploration des modifications
Un espace de travail Log Analytics peut ingérer des données provenant de nombreuses sources, notamment le journal d'activité Azure, les journaux de ressources Azure, et les diagnostics spécifiques au service. Tout d’abord, créez un espace de travail Log Analytics. Ensuite, dans le portail Azure, ouvrez Monitor → Journal d’activité puis sélectionnez Exporter les journaux d’activité en haut du volet. Cela ouvre un paramètre de diagnostic qui vous permet d’envoyer le journal d’activité d’un abonnement Azure à votre espace de travail.
Dans un court délai, vous pouvez utiliser kusto Query Language (KQL) pour récupérer des informations détaillées sur les modifications qui ont eu lieu dans cet abonnement depuis que vous avez connecté la source de données.
Par exemple, la requête suivante montre des informations sur les ressources qui ont changé ou ont été supprimées. Nous pouvons définir l’intervalle de temps dans l’interface des journaux afin de cibler plus précisément la période juste avant l’incident.
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
Cette requête est utile pour les modifications du plan de gestion, mais n’oubliez pas ce qu’elle n’affiche pas.
AzureActivity capture les opérations de plan de contrôle telles que la création, la mise à jour, la suppression et les actions de stratégie. Elle ne capture pas les modifications apportées au plan de données ou au niveau de l’application à l’intérieur d’un service. Pour les examiner, associez cette requête à Azure journaux de ressources, aux journaux d’audit spécifiques au service, à l’historique de déploiement et aux enregistrements CI/CD ou de contrôle de code source.
Une remarque rapide : lorsque vous exportez le journal d’activité Azure, les informations commencent à affluer dans l’espace de travail Log Analytics à partir de ce moment. Vous ne pourrez pas interroger cet espace de travail de manière rétroactive pour les événements qui ont eu lieu avant d’établir la connexion.
Ces outils doivent être en mesure de vous donner un bon début sur la collecte d’informations nécessaires à une chronologie à utiliser dans un examen post-incident. Avant de vous plonger directement dans une révision post-incident, nous aimerions vous avertir de certains pièges courants. C’est le sujet de notre prochaine unité.