Het incidentbeoordelingsproces

Een belangrijk onderdeel van een incidentbeoordeling is de constructie van een gedeelde, nauwkeurige chronologie die de niet-lineaire aard van een incident weerspiegelt.

Door niet-lineair te bedoelen, bedoelen we dat incidenten bijna nooit alleen maar "dit ding gebeurt, en dan gebeurde dat, toen merkten we het op, toen deden we iets, en dan zijn we klaar." Mensen komen binnen en buiten, verschillende mensen merken dingen op en proberen verschillende dingen uit; sommige werken, andere niet. En als meerdere mensen tegelijkertijd werken, kunnen deze dingen ook tegelijkertijd gebeuren, dus het is iets ingewikkelder.

Als u een dergelijke tijdlijn wilt maken, zelfs een complexe, is er altijd een belangrijke eerste stap: de gegevens verzamelen.

De gegevens verzamelen

Voordat u een incidentbeoordeling kunt uitvoeren, moet u eerst gegevens verzamelen. In het bijzonder moet u zoveel mogelijk gesprekken en context (zowel technisch als niet technisch) rondom de gebeurtenis verzamelen, zodat u alle cruciale gegevens in de gebeurtenis kunt gebruiken. Het gesprek dat tussen teamleden plaatsvond tijdens de storing of het incident, zal een van uw meest uitgebreide informatiebronnen zijn.

U zou ook gegevens moeten verzamelen van uw bewakingssysteem en andere bronnen waar de betrokken personen context uit hebben gehaald. Welke informatie kregen ze van uw systemen toen het incident aan de gang was?

En ten slotte zou het nuttig zijn om, indien mogelijk, een beter beeld te krijgen van wat er vóór en tijdens het incident is gewijzigd, omdat wijzigingen vaak factoren bijdragen wanneer een incident optreedt.

We kunnen dit proces als drie afzonderlijke onderdelen bekijken:

• Verzamel het gesprek: In andere modules in dit leertraject hebben we vermeld dat het belangrijk is om een specifieke plek te maken waar mensen tijdens een incident kunnen communiceren. Tijdens het incident delen mensen idealiter wat heeft gewerkt en wat is mislukt, wat ze aarzelen om te proberen, wat ze in het verleden hebben geprobeerd. Dit gesprek tussen mensen tijdens het doorlopen en oplossen van het probleem is uw beste bron van leren.
• Bepaal de context: de personen in een incident ontvangen signalen van verschillende plaatsen. Eén primaire plaats is uw bewakingssysteem. We hebben het belang besproken van een solide bewakingssysteem in een eerdere module in dit leertraject. In het ideale geval moeten we het bewakingssysteem kunnen bekijken om een momentopname van een bepaald tijdstip te maken voor de periode rond of gerelateerd aan het incident.
• Zoek de wijzigingen: U kunt dit doen via activiteiten- en auditlogboeken.

Azure hulpprogramma's om de gegevens te verzamelen

Azure biedt een aantal hulpprogramma's die u kunnen helpen bij dit proces:

Azure DevOps voor het opslaan van metagegevens over het incident

In een eerdere module in dit leertraject hebben we het gebruik van Azure Boards in de Azure DevOps suite besproken als één plek om alle informatie over een incident te verzamelen vanaf het eerste antwoord. Het helpt ons met vragen over wanneer een incident voor het eerst werd gedeclareerd, wie er op oproep was, wie aan het incident was toegewezen, enzovoort. U kunt de Azure DevOps Wiki ook gebruiken als gecentraliseerde manier om een deel van de informatie op te halen over zowel het incident zelf als het gesprek dat tijdens het incident is opgetreden.

Microsoft Graph API voor het extraheren van het gesprek

Microsoft Graph API biedt een programmatische manier om het gesprek op te halen dat is verzameld in het Teams-kanaal dat is gewijd aan dit specifieke incident. De opgehaalde gegevens omvatten tijdstempels, auteurschap, bewerkingen, antwoorden en sommige systeemberichten, die allemaal kunnen helpen bij het samenstellen van een chronologie.

Een eenvoudige manier om aan de slag te gaan met Microsoft Graph-API is het gebruik van de Microsoft Graph Explorer. Microsoft Graph Explorer is een webgebaseerde API-browser waarmee u API-aanroepen kunt kiezen uit een Voorbeeldquery's-paneel en ze interactief kunt uitproberen.

Voordat u de query's uitvoert, moet u ervoor zorgen dat de gebruiker of app die u gebruikt de machtigingen en toestemming heeft die vereist zijn voor de toegangsmodus die u hebt gekozen. In gedelegeerde scenario's gebruikt het weergeven van gekoppelde teams Team.ReadBasic.All, het weergeven van kanalen Channel.ReadBasic.All, en het lezen van kanaalberichten vereist ChannelMessage.Read.All. Als u de workflow later automatiseert met alleen-app-toegang, gebruik dan GET /users/{id | user-principal-name}/joinedTeams in plaats van de alias alleen-gemachtigd /me/joinedTeams, waarbij u de Team.ReadBasic.All toepassingsmachtiging gebruikt. Voor de kanaalspecifieke leesstappen zijn de minst bevoegde app-only opties ChannelSettings.Read.Group voor het weergeven van kanalen en ChannelMessage.Read.Group voor het lezen van berichten, beide met resourcespecifieke toestemming.

We doorlopen een reeks api-aanroepen van Microsoft Graph v1.0 'Microsoft Teams' om het gesprek op te halen. (Kanaalberichten zijn enkele jaren geleden verplaatst van bèta naar v1.0, zodat de bèta-eindpunten niet meer nodig zijn voor dit scenario.) Bij elke stap kiezen we een query, voeren we de query uit en selecteren we de informatie in het antwoord dat ons helpt bij de volgende stap. Vervolgens gebruiken we deze informatie om de volgende aanvraag te maken. We voeren bijvoorbeeld eerst een query uit op een lijst met team-id's om de teams weer te geven waarvan we deel uitmaken. We kiezen het antwoord dat we nodig hebben en voegen deze id in de volgende query-URL in om een lijst met kanalen in dat team op te halen.

Hier volgen onze stappen, weergegeven als Microsoft Graph v1.0-eindpunten:

1. GET /me/joinedTeams (om de team-id te vinden van het team dat we gebruiken in een gedelegeerd scenario) of GET /users/{id | user-principal-name}/joinedTeams (om hetzelfde te doen in een app-scenario).
2. GET /teams/{team-id}/channels (om de kanaal-id te vinden van het kanaal dat we voor dat incident hebben gebruikt).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (om de gestructureerde conversatie op te halen).
4. Volg @odata.nextLink en replies@odata.nextLink indien nodig, of bel GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies om door grotere threads te bladeren.

Als u een gedeeld kanaal hebt gebruikt, ziet u dat de joinedTeams API het hostteam niet retourneert voor een gedeeld kanaal waarvan de gebruiker rechtstreeks lid is. Deze kanttekening is van toepassing of u belt GET /me/joinedTeams of GET /users/{id | user-principal-name}/joinedTeams. In dat geval begint u met de bekende team- en kanaal-id's of gebruikt u de bijbehorende team-API's om het hostteam te vinden.

In Graph Explorer kunt u deze URL's rechtstreeks invoeren of de overeenkomende opties kiezen uit het ingebouwde voorbeelden van query's paneel onder Microsoft Teams.

Als we later een programma willen maken om elk van deze stappen uit te voeren (en inderdaad doen), is er een optie voor codefragmenten in het aanvraagvenster met voorbeeldcode voor die query in een aantal verschillende programmeertalen.

Afhankelijk van hoe uw team Teams gebruikt, kan de berichtengeschiedenis ook systeemberichten bevatten die helpen uitleggen wanneer leden zijn toegevoegd of verwijderd. Als u echter een gezaghebbende audittrail van kanaallidmaatschap of toegangswijzigingen nodig hebt, kunt u deze gegevens aanvullen met Microsoft 365 auditlogboeken.

Dashboards en werkmappen voor contextweergave

Azure dashboards en Azure Monitor werkmappen kunnen beide helpen bij het reconstrueren van de context die operators tijdens een incident hebben gezien. Dashboards zijn handig voor in één oogopslag operationeel overzicht van Azure services. Werkmappen zijn meestal beter geschikt voor incidentanalyse, omdat ze uitgebreidere query's, parameters, drilldowns en verhaaltekst naast grafieken ondersteunen.

Als u al een dashboard of werkmap hebt die de juiste signalen vastlegt, stelt u het tijdsbereik in op de periode rond het incident en gebruikt u deze om te reconstrueren wat mensen op dat moment hebben gezien. Dit kan met name handig zijn bij het correleren van metrische gegevens, logboeken en waarschuwingen over verschillende resources.

Gedeelde dashboards zijn Azure resources en kunnen nog steeds worden geëxporteerd als JSON vanuit de portal. Dit export-/importpad is handig als u een dashboard wilt versieren of templatiseren. Voor de meeste scenario's voor onderzoek na incidenten zijn werkmappen echter het flexibelere hulpprogramma, omdat u visualisaties, KQL-query's en verklarende tekst in één artefact kunt combineren.

Activiteitenlogboeken, resourcelogboeken en Log Analytics voor wijzigingsverkenning

Een Log Analytics werkruimte kan gegevens uit veel bronnen bevatten, waaronder Azure activiteitenlogboek, Azure resourcelogboeken en servicespecifieke diagnostische gegevens. Maak eerst een nieuwe Log Analytics werkruimte. Open vervolgens in de Azure-portal Monitor → Activiteitenlogboek en selecteer Activiteitenlogboeken exporteren boven aan het deelvenster. Hiermee opent u een diagnostische instelling waarmee u het activiteitenlogboek voor een Azure-abonnement naar uw werkruimte kunt verzenden.

In korte tijd kunt u Kusto Query Language (KQL) gebruiken om gedetailleerde informatie op te halen over wijzigingen die in dat abonnement hebben plaatsgevonden sinds u de gegevensbron hebt verbonden.

In de volgende query ziet u bijvoorbeeld informatie over resources die zijn gewijzigd of verwijderd. We kunnen het tijdsbereik in de logboekervaring instellen om nauwkeuriger in te gaan op de periode kort voor het 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

Deze query is handig voor wijzigingen in het beheervlak, maar onthoud wat deze niet weergeeft. AzureActivity legt besturingsvlakbewerkingen vast, zoals acties voor maken, bijwerken, verwijderen en beleid. Het legt geen wijzigingen op gegevensvlak of toepassingsniveau vast in een service. Als u deze wilt onderzoeken, koppelt u deze query aan Azure resourcelogboeken, servicespecifieke auditlogboeken, implementatiegeschiedenis en CI/CD- of broncodebeheerrecords.

Een snelle opmerking: wanneer u het Azure activiteitenlogboek exporteert, begint de informatie vanaf dat moment naar de Log Analytics werkruimte te stromen. U kunt die werkruimte niet met terugwerkende kracht opvragen voor gebeurtenissen die plaatsvonden voordat u de verbinding hebt gemaakt.

Deze hulpprogramma's moeten u een goed begin kunnen geven met het verzamelen van informatie die nodig is voor een chronologische beoordeling in een incidentbeoordeling. Voordat u meteen een beoordeling van het incident ingaat, willen we u waarschuwen voor enkele veelvoorkomende valkuilen. Dat is het onderwerp van onze volgende eenheid.