Granskningsprocessen efter incidenten

En viktig del av en granskning efter incident är byggandet av en delad, korrekt kronologi som återspeglar incidentens icke-linjära karaktär.

Med icke-linjär menar vi att incidenter nästan aldrig bara är "det här händer, och sedan hände det där, sedan märkte vi, sedan gjorde vi något, och sedan är vi klara." Människor kommer in och ut, olika människor märker och provar olika saker; vissa fungerar, andra inte. Och om flera personer arbetar samtidigt kan dessa saker hända samtidigt också, så det är lite mer komplicerat.

För att skapa en tidslinje som den här, även en komplex, finns det alltid ett viktigt första steg: samla in data.

Samla in data

Innan du kan utföra en granskning efter incident måste du först samla in data. Mer specifikt behöver du samla in så mycket av konversationen och kontexten (både tekniska och icke-tekniska) som omger händelsen så att du kan använda alla viktiga data som finns i den. Konversationen mellan teammedlemmar som inträffade under avbrottet eller incidenten kommer att vara en av dina rikaste informationskällor.

Du bör också samla in data från ditt övervakningssystem och andra platser där de personer som var inblandade i incidenten drog kontext. Vilken information fick de från dina system när incidenten pågick?

Och slutligen, om möjligt, skulle det vara bra för dig att få en bättre bild av vad som ändrades före och under incidenten, eftersom ändringar ofta bidrar till faktorer när en incident inträffar.

Vi kan se den här processen som tre separata delar:

• Samla in konversationen: I andra moduler i den här utbildningsvägen har vi nämnt att det är viktigt att skapa en specifik plats där personer kan kommunicera under en incident. Under incidenten delar människor helst vad som fungerade och vad som misslyckades, vad de tvekar att prova, vad de har provat tidigare. Den här konversationen mellan människor när de arbetar igenom och löser problemet är din bästa utbildningskälla.
• Fastställa kontexten: Personerna i en incident tar emot signaler från olika platser. En primär plats är ditt övervakningssystem. Vi har diskuterat vikten av att ha ett stabilt övervakningssystem i en tidigare modul i den här utbildningsvägen. Helst bör vi kunna titta på övervakningssystemet för att skapa en punktvis ögonblicksbild för tidsperioden runt eller relaterad till incidenten.
• Hitta ändringarna: Du kan göra detta via aktivitets- och granskningsloggar.

Azure verktyg för att samla in data

Azure erbjuder ett antal verktyg som kan hjälpa dig med den här processen:

Azure DevOps för att lagra metadata om incidenten

I en tidigare modul i den här utbildningsvägen diskuterade vi att använda Azure-tavlor i den Azure DevOps sviten som en plats för att samla in all information om en incident med början från det första svaret. Det hjälper oss med frågor om när en incident först deklarerades, vem som var jour, vem som tilldelades incidenten och så vidare och så vidare. Du kan också använda Azure DevOps Wiki som ett centraliserat sätt att hämta information om både själva incidenten och konversationen som inträffade under incidenten.

Microsoft Graph API för att extrahera konversationen

Microsoft Graph API tillhandahåller ett programmatiskt sätt att hämta konversationen som samlades in i Teams-kanalen som ägnas åt den här specifika incidenten. De data som hämtas innehåller tidsstämplar, redigeringar, svar och vissa systemmeddelanden, som alla kan vara till hjälp när du skapar en kronologi.

Ett enkelt sätt att komma igång med Microsoft Graph API är att använda Microsoft Graph Explorer. Microsoft Graph Explorer är en webbaserad API-webbläsare där du kan välja API-anrop från en Exempelfrågor panel och prova dem interaktivt.

Innan du kör frågorna kontrollerar du att den användare eller app som du använder har de behörigheter och medgivande som krävs för det åtkomstläge som du har valt. Vid delegerade scenarier används Team.ReadBasic.All för att lista anslutna team, Channel.ReadBasic.All för att lista kanaler, och ChannelMessage.Read.All för att läsa kanalmeddelanden. Om du senare automatiserar arbetsflödet med endast appåtkomst använder GET /users/{id | user-principal-name}/joinedTeams du i stället för det delegerade /me/joinedTeams aliaset med hjälp av programbehörigheten Team.ReadBasic.All . För kanalspecifika lässteg är ChannelSettings.Read.Group de minst privilegierade appalternativen för att visa kanaler och ChannelMessage.Read.Group för att läsa meddelanden, båda med resursspecifikt medgivande.

Vi går igenom en uppsättning Microsoft Graph v1.0"Microsoft Teams"-API-anrop för att hämta konversationen. (Kanalmeddelanden flyttades från beta till v1.0 för flera år sedan, så betaslutpunkterna krävs inte längre för det här scenariot.) Varje steg på vägen väljer vi en fråga, kör frågan och väljer sedan informationen från svaret som hjälper oss med nästa steg. Sedan använder vi den här informationen för att skapa nästa begäran. Först hämtar vi en lista med team-ID:n för att visa de team som vi ingår i. Vi väljer den vi behöver från svaret och infogar det här ID:t i nästa fråge-URL för att hämta en lista över kanaler i teamet.

Här är våra steg som visas som Microsoft Graph v1.0-slutpunkter:

1. GET /me/joinedTeams (för att hitta team-ID:t för teamet som vi använder i ett delegerat scenario) eller GET /users/{id | user-principal-name}/joinedTeams (för att göra samma sak i ett scenario med endast appar).
2. GET /teams/{team-id}/channels (för att hitta kanal-ID:t för den kanal som vi använde för incidenten).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (för att hämta den trådade konversationen).
4. Följ @odata.nextLink och replies@odata.nextLink vid behov, eller kontakta GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies för att bläddra genom större trådar.

Om du använde en delad kanal kan du notera att API:et joinedTeams inte returnerar värdteamet för en delad kanal som användaren är direkt medlem i. Det här förbehållet gäller oavsett om du anropar GET /me/joinedTeams eller GET /users/{id | user-principal-name}/joinedTeams. I så fall startar du från kända team- och kanalidentifierare eller använder de associerade team-API:erna för att hitta värdteamet.

I Graph Explorer kan du antingen ange dessa URL:er direkt eller välja motsvarande poster från den inbyggda Exempelfrågor panelen under Microsoft Teams.

Om vi senare vill skapa ett program för att utföra vart och ett av dessa steg (och det gör vi) finns det ett kodfragment alternativ i begärandefönstret som visar exempelkod för den frågan på ett antal olika programmeringsspråk.

Beroende på hur ditt team använder Teams kan meddelandehistoriken även innehålla systemmeddelanden som förklarar när medlemmar lades till eller togs bort. Men om du behöver ett auktoritativt spårningsspår för kanalmedlemskap eller åtkomständringar kompletterar du dessa data med Microsoft 365 granskningsloggar.

Instrumentpaneler och arbetsböcker för kontextvisning

Azure instrumentpaneler och Azure Monitor arbetsböcker kan båda hjälpa till att rekonstruera kontexten som operatörerna såg under en incident. Instrumentpaneler är användbara för snabb driftöversikt över Azure tjänster. Arbetsböcker passar vanligtvis bättre för incidentanalys eftersom de stöder rikare frågor, parametrar, detaljgranskningar och narrativ text tillsammans med diagram.

Om du redan har en instrumentpanel eller arbetsbok som samlar in rätt signaler anger du dess tidsintervall till perioden runt incidenten och använder den för att rekonstruera vad personer såg vid den tidpunkten. Detta kan vara särskilt användbart när du korrelerar mått, loggar och aviseringar mellan flera resurser.

Delade instrumentpaneler är Azure resurser och kan fortfarande exporteras som JSON från portalen. Den export-/importsökvägen är användbar när du vill version eller malla en instrumentpanel. Men för de flesta scenarier efter incidentundersökningar är arbetsböcker det mer flexibla verktyget eftersom de låter dig kombinera visualiseringar, KQL-frågor och förklarande text i en enda artefakt.

Aktivitetsloggar, resursloggar och Log Analytics för ändringsutforskning

En Log Analytics arbetsyta kan ta in data från många källor, till exempel Azure aktivitetslogg, Azure resursloggar och tjänstspecifik diagnostik. Skapa först en ny Log Analytics arbetsyta. Öppna sedan Monitor → Activity log i Azure-portalen och välj Exportera aktivitetsloggar överst i fönstret. Då öppnas en diagnostikinställning som gör att du kan skicka aktivitetsloggen för en Azure prenumeration till din arbetsyta.

På kort tid kan du använda Kusto Query Language (KQL) för att hämta detaljerad information om ändringar som har gjorts i prenumerationen sedan du anslöt datakällan.

Följande fråga visar till exempel information om resurser som har ändrats eller tagits bort. Vi kan ange tidsintervallet i loggupplevelsen så att det blir mer exakt när det gäller perioden strax före incidenten.

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

Den här frågan är användbar för ändringar på hanteringsplanet, men kom ihåg vad den inte visar. AzureActivity registrerar kontrollplansoperationer som att skapa, uppdatera, ta bort och policyåtgärder. Den samlar inte in dataplans- eller programnivåändringar i en tjänst. Om du vill undersöka dem kopplar du den här frågan med Azure resursloggar, tjänstspecifika granskningsloggar, distributionshistorik och CI/CD- eller källkontrollposter.

En snabbkommentar: När du exporterar Azure aktivitetsloggen börjar informationen flöda till Log Analytics arbetsyta från den tidpunkten framåt. Du kommer inte att kunna göra förfrågningar i arbetsytan retroaktivt efter händelser som ägde rum innan du gjorde anslutningen.

De här verktygen bör kunna ge dig en bra start på insamlingen av information som krävs för att en kronologi ska kunna användas i en granskning efter incident. Innan du går in på en genomgång efter en incident, vill vi varna dig för några vanliga fallgropar. Det är ämnet för vår nästa lektion.