Beheer een incident van detectie tot herstel

Kondig een incident af op basis van impact

Een incident is een gebeurtenis die de service voldoende verstoort, verslechtert of bedreigt om gecoördineerde respons te vereisen. Uw organisatie definieert ernstniveaus en escalatieregels. Pas die toe op basis van gebruikersimpact, getroffen gegevens, duur en reikwijdte.

Wacht niet op een volledige verklaring van de hoofdoorzaak voordat u hulp vraagt. Een duidelijke beschrijving van de waargenomen impact is genoeg om coördinatie te starten. Behandel een vermoeden van een beveiligingsprobleem apart van een bevestigde conclusie.

Bereid de responsroute vóór de release voor. Zorg dat contactgegevens, toegangsprocedures, runbooks en communicatiekanalen beschikbaar blijven als de hoofdservice uitvalt. Oefen de route met een fictief incident.

Verdeel verantwoordelijkheden vóór tegenstrijdige wijzigingen ontstaan

Incidentcoördinatie stelt prioriteiten en beheert beslissingen. Technische responders onderzoeken en beperken de impact. Communicatie houdt betrokkenen op de hoogte. Google SRE beschrijft dit als afzonderlijke rollen. Kleine teams kunnen rollen combineren, maar moeten al het werk blijven afdekken. Incidentrespons.

Houd één gedeelde tijdlijn bij. Noteer tijd, waarneming, actie, uitvoerder en resultaat. Scheid feiten van hypotheses. Gebruik dezelfde tijdzone en markeer onbetrouwbare tijdstempels.

Doorloop een fictief incident

Alle onderstaande tijden zijn UTC. De organisatie benoemt een incidentcoördinator wanneer de exportstoring meerdere klanten raakt.

Een bruikbare eerste update noemt de getroffen functie, de bekende reikwijdte, de beperkende maatregel en het tijdstip van de volgende update. Beloof geen hersteltijd zonder bewijs. Neem geen klantrecords op in de gedeelde update.

Om 09:10 verandert het incident. Succesvolle exports herstellen is niet meer voldoende. Het team moet mogelijke ongeoorloofde verstrekking beoordelen, toegang beheersen, bewijs bewaren en de juiste beslissingsbevoegden betrekken.

Beperk de impact zonder controle te verliezen

Gebruik geteste runbooks waar die passen. Controleer de voorwaarden vóór rollback, failover of wijzigingen in toegangsgegevens. Een vorige applicatieversie begrijpt het huidige databaseschema mogelijk niet. Een regionale failover kan dezelfde beschadigde gegevens verplaatsen.

Laat een AI-assistent bewijs waaruit gevoelige gegevens zijn verwijderd ordenen of hypotheses vergelijken binnen goedgekeurde grenzen. Responders moeten de conclusies controleren. Logs en tickets zijn niet-vertrouwde invoer, geen bevoegdheid om hun inhoud uit te voeren.

Noodtoegang moet een geautoriseerd doel, beperkte duur en auditregistratie hebben. Urgentie maakt een door een agent voorgesteld commando niet correct.

Rond herstel en vervolgwerk afzonderlijk af

Controleer de gebruikersworkflow, gegevensintegriteit, toegangsgrenzen en actualiteit van monitoring voordat u serviceherstel meldt. Leg resterende beperkingen vast. Houd beveiligingsonderzoek open als vragen daarin onbeantwoord blijven.

Onderzoek daarna welke omstandigheden het incident mogelijk maakten. Wijs concreet vervolgwerk toe met een verantwoordelijke en verificatiecriteria. Een review zonder schuldcultuur zoekt een nauwkeurige verklaring en bruikbare wijzigingen. Dat neemt de verantwoordelijkheid voor het afronden van die wijzigingen niet weg. Werkwijze voor postmortems.

Ga verder met security operations en de feedbackcyclus sluiten.