Procesul de revizuire post-incident

O parte importantă a unei reexaminări post-incident este construirea unei cronologii partajate, exacte, care reflectă natura neliniară a unui incident.

Prin neliniar, ne referim că incidentele sunt aproape niciodată doar "acest lucru se întâmplă, apoi s-a întâmplat, apoi am observat, apoi am făcut ceva, apoi am terminat." Oamenii intră și ies, observă persoane diferite și încearcă lucruri diferite; unele de lucru, unele nu. Iar dacă mai multe persoane lucrează în același timp, aceste lucruri se pot întâmpla și în același timp, deci este puțin mai complicat.

Pentru a crea o cronologie ca aceasta, chiar și una complexă, există întotdeauna un prim pas important: strângeți datele.

Colectarea datelor

Înainte de a putea efectua o revizuire post-incident, trebuie mai întâi să colectați date. Mai exact, trebuie să aduni cât mai mult din conversația și contextul (atât tehnic, cât și non-tehnic) din jurul evenimentului, astfel încât să poți folosi toate datele cruciale conținute în acesta. Conversația dintre membrii echipei care a avut loc în timpul defecțiunii sau incidentului va fi una dintre cele mai bogate surse de informații.

De asemenea, ar trebui să colectați date din sistemul de monitorizare și din alte locuri în care persoanele implicate în incident au atras contextul. Ce informații au primit de la sistemele dvs. atunci când se întâmplă incidentul?

Și, în final, dacă este posibil, ar fi util să obțineți o imagine mai clară a ceea ce s-a schimbat înainte și în timpul incidentului, deoarece schimbările sunt adesea factori care contribuie atunci când un incident are loc.

Putem analiza acest proces ca trei părți separate:

• Colectați conversația: În alte module din această cale de învățare, am menționat că este important să sculptați un anumit loc în care persoanele să comunice în timpul unui incident. În timpul incidentului, în mod ideal oamenii sunt partajarea ceea ce a funcționat și ceea ce nu a reușit, ceea ce sunt ezitant să încerce, ceea ce au încercat în trecut. Această conversație între persoane pe măsură ce lucrează și rezolvă problema este cea mai bună sursă de învățare.
• Determinați contextul: persoanele dintr-un incident primesc semnale din diverse locuri. Un singur loc principal este sistemul dvs. de monitorizare. Am discutat importanța de a avea un sistem solid de monitorizare într-un modul anterior în această cale de învățare. În mod ideal, ar trebui să putem analiza sistemul de monitorizare pentru a construi un instantaneu punct în timp pentru perioada de timp aproximativă sau legată de incident.
• Găsiți modificările: Puteți face acest lucru prin intermediul jurnalelor de activitate și de auditare.

Unelte Azure pentru a ajuta la colectarea datelor

Azure oferă o serie de instrumente care pot ajuta în acest proces:

Azure DevOps for holding metadata about the incident

Într-un modul anterior din această cale de învățare, am discutat despre utilizarea Azure Boards în suita Azure DevOps ca un singur loc pentru colectarea tuturor informațiilor despre un incident începând cu răspunsul inițial. Ne ajută să aflăm întrebări despre momentul când a fost declarat primul incident, cine a fost apelat, cine a fost desemnat incidentului și așa mai departe. Poți folosi, de asemenea, Azure DevOps Wiki ca o modalitate centralizată de a prelua unele informații atât despre incidentul în sine, cât și despre conversația care a avut loc în timpul incidentului.

Microsoft Graph API pentru extragerea conversației

Microsoft Graph API oferă o modalitate programatică de a recupera conversația colectată în canalul Teams dedicat acestui incident specific. Datele recuperate includ timestamp-uri, autoriat, editări, răspunsuri și unele mesaje de sistem, toate acestea putând ajuta la construirea unei cronologii.

O modalitate simplă de a începe cu API-ul Microsoft Graph este să folosești Microsoft Graph Explorer. Microsoft Graph Explorer este un browser API bazat pe web care îți permite să alegi apeluri API dintr-un panou Sample interogări și să le încerci interactiv.

Înainte să rulezi interogările, asigură-te că utilizatorul sau aplicația pe care o folosești are permisiunile și consimțământul necesare pentru modul de acces ales. În scenariile delegate, listarea echipelor alăturate folosește Team.ReadBasic.All, listarea canalelor utilizează Channel.ReadBasic.All, iar citirea mesajelor canalului necesită ChannelMessage.Read.All. Dacă ulterior automatizezi fluxul de lucru cu acces doar în aplicație, folosește GET /users/{id | user-principal-name}/joinedTeams în loc de aliasul doar /me/joinedTeams delegat, folosind permisiunea Team.ReadBasic.All aplicației. Pentru pașii de citire specifici fiecărui canal, cele mai puțin privilegiate opțiuni doar pentru aplicație sunt ChannelSettings.Read.Group pentru listarea canalelor și ChannelMessage.Read.Group pentru citirea mesajelor, ambele cu consimțământul specific resursei.

Vom parcurge un set de apeluri API Microsoft Graph v1.0 "Microsoft Teams" pentru a recupera conversația. (Mesajele canalului au trecut de la beta la v1.0 acum câțiva ani, astfel încât punctele beta nu mai sunt necesare pentru acest scenariu.) La fiecare pas, vom alege o interogare, vom rula interogarea și apoi vom selecta informațiile din răspuns care ne ajută la pasul următor. Apoi utilizăm aceste informații pentru a construi următoarea solicitare. De exemplu, mai întâi interogăm o listă de ID-uri de echipă pentru a arăta echipele din care facem parte. Alegem-l pe cel de care avem nevoie din răspuns și introducem acest ID în următorul URL al interogării pentru a obține o listă de canale din echipa respectivă.

Iată pașii noștri, arătați ca endpoint-uri Microsoft Graph v1.0:

1. GET /me/joinedTeams (pentru a găsi ID-ul echipei folosite într-un scenariu delegat) sau GET /users/{id | user-principal-name}/joinedTeams (pentru a face același lucru într-un scenariu doar pentru aplicație).
2. GET /teams/{team-id}/channels (pentru a găsi ID-ul canalului pe care l-am folosit pentru acel incident).
3. GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies (pentru a recupera conversația firească).
4. Urmărește @odata.nextLink și replies@odata.nextLink când este nevoie sau sună GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies la pagină prin fire mai mari.

Dacă ai folosit un canal partajat, reține că joinedTeams API-ul nu returnează echipa gazdă pentru un canal comun din care utilizatorul este membru direct. Această mențiune se aplică indiferent dacă apelați GET /me/joinedTeams sau GET /users/{id | user-principal-name}/joinedTeams. În acest caz, începe de la identificatorii cunoscuți ai echipei și canalului sau folosește API-urile echipei asociate pentru a localiza echipa gazdă.

În Graph Explorer, poți introduce direct aceste URL-uri sau poți alege intrările echivalente din panoul integrat Sample interogări din Microsoft Teams.

Dacă mai târziu am vrut să construim un program pentru a efectua fiecare dintre acești pași (și într-adevăr o facem), există o opțiune de fragmente de cod în fereastra de solicitare care prezintă un cod eșantion pentru acea interogare într-un număr de limbi de programare diferite.

În funcție de modul în care echipa ta folosește Teams, istoricul mesajelor poate conține și mesaje de sistem care ajută la explicarea momentului în care membrii au fost adăugați sau eliminați. Totuși, dacă ai nevoie de o urmă de audit autorizată a apartenenței la canal sau a modificărilor de acces, completează aceste date cu jurnalele de audit Microsoft 365.

Tablouri de bord și caiete de lucru pentru afișarea contextului

Dashboard-urile Azure și Azure Monitor pot ajuta la reconstruirea contextului pe care operatorii l-au observat în timpul unui incident. Tablourile de bord sunt utile pentru o prezentare operațională rapidă a serviciilor Azure. Caietele de lucru sunt de obicei mai potrivite pentru analiza incidentelor deoarece suportă interogări mai detaliate, parametri, detalii și text narativ alături de grafice.

Dacă ai deja un tablou de bord sau un caiet de lucru care surprinde semnalele corecte, setează intervalul de timp la perioada incidentului și folosește-l pentru a reconstrui ce au văzut oamenii la momentul respectiv. Acest lucru poate fi deosebit de util atunci când corelezi metrici, jurnalele și alertele din mai multe resurse.

Dashboard-urile partajate sunt resurse Azure și pot fi exportate în continuare ca JSON din portal. Acea cale de export/import este utilă când vrei să versiuni sau să templatizezi un dashboard. Totuși, pentru majoritatea scenariilor de investigație post-incident, caietele de lucru sunt instrumentul mai flexibil deoarece îți permit să combini vizualizări, interogări KQL și text explicativ într-un singur artefact.

Jurnale de activitate, jurnale de resurse și Log Analytics pentru explorarea modificărilor

Un spațiu de lucru Log Analytics poate prelua date din multe surse, inclusiv Azure Activity log, Azure resource logs și diagnostice specifice serviciilor. Mai întâi, creează un nou spațiu de lucru Log Analytics. Apoi, în portalul Azure, deschide Monitorizează → jurnal de activitate și selectează Export Activity Logs în partea de sus a panoului. Aceasta deschide o setare de diagnosticare care îți permite să trimiți jurnalul de activitate pentru un abonament Azure către spațiul tău de lucru.

În scurt timp, poți folosi Kusto Query Language (KQL) pentru a obține informații detaliate despre modificările care au avut loc în acel abonament de când ai conectat sursa de date.

De exemplu, următoarea interogare arată informații despre resurse care s-au schimbat sau au fost șterse. Putem seta intervalul de timp din experiența Logs pentru a ne concentra mai precis pe perioada imediat anterioară incidentului.

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

Această interogare este utilă pentru schimbările planului de management, dar amintește-ți ce nu arată. AzureActivity capturează operațiunile planului de control precum crearea, actualizarea, ștergerea și acțiunile de politici. Nu surprinde schimbările la nivel de plan de date sau la nivel de aplicație în cadrul unui serviciu. Pentru a investiga aceste aspecte, asociați această interogare cu jurnalele de resurse Azure, jurnalele de audit specifice serviciului, istoricul implementării și înregistrările CI/CD sau de control sursă.

O notă rapidă: când exporti jurnalul de activitate Azure, informațiile încep să curgă în spațiul de lucru Log Analytics din acel moment înainte. Nu vei putea interoga acel spațiu de lucru retroactiv pentru evenimentele care au avut loc înainte să faci conexiunea.

Aceste instrumente ar trebui să vă poată oferi un bun început cu privire la colectarea informațiilor necesare pentru o cronologie de utilizat într-o revizuire post-incident. Înainte de a intra într-o recenzie post-incident, am dori să vă avertizăm despre câteva capcane comune. Asta e subiectul următoarei unități.