Jaettu MSP-eskalaatiomalli on hyödyllinen vain, kun se on tarkoitettu ihmisille, jotka voivat toimia asianomaisen asiakkaan puolesta. Analyytikko saattaa tunnistaa todennusvirheen, mutta hänellä ei ole lupaa muuttaa liiketoimintakriittistä lähettäjää. Määritä raja tutkinnan, eristämisen ja muutoksen hyväksynnän välillä, ennen kuin tapahtuma pakottaa kiireen päätöksen.
Anna päätöksiä tarrojen sijaan
Selvitä jokaisen asiakkaan kohdalla, kuka hyväksyy lähettäjän valtuutuksen, DNS muutokset, täytäntöönpanokäytännöt, hätäpalautuksen ja tietojen paljastamisen. Nimeä tekniset ja yritysten omistajat sekä varajäsenet. Tallenna vahvistetut kontaktireitit ja peittoajat. Yleinen merkintä, kuten "asiakas-IT", ei riitä, kun kukaan ei voi vastata palkanlaskennan epäonnistumisen aikana.
Erottele todisteiden tarkastusoikeus muutoksen hyväksymisviranomaisesta. OWASP:n lupaohjeet tukee tarkan toiminnan ja laajuuden tarkistamista sen sijaan, että luottaisi laajaan todennettuun tilaan. Nämä säädöt koskevat MSP-henkilöstöä, asiakkaiden ylläpitäjiä ja automaatioidentiteettejä. Hätätyö vaatii edelleen määritellyn apurahan; kiireellisyys ei luo rajatonta valtaa.
Määritä kello ja varatoiminto
Ilmoita, milloin vastauskello alkaa, mikä on kuittaus ja milloin eskalaatio tapahtuu. Erottele katetut palveluminuutit kuluneesta kalenteriajasta. Nimeä aikavyöhyke ja lomasäännöt. Kuittaus sanoo, että vastuullinen henkilö on sitoutunut; se ei tarkoita diagnoosia tai palauttamista.
Dokumentoi, mitä tapahtuu, jos ensisijainen hyväksyjä ei ole käytettävissä. Varajäsen voi hyväksyä määritetyssä laajuudessa, tai ryhmä voi säilyttää todisteet ja jättää ehdotetun muutoksen odotustilaan. Älä tulkitse hiljaisuutta hyväksynnäksi, ellei nimenomaisesti sovittu toimintatapa todella salli kyseistä toimintaa. Säilytä politiikkaa ja päätöksiä koskevat todisteet.
Reititä kolme hypoteettista tapahtumaa eri tavalla
Tuntematon lähettäjä tarvitsee todisteet tekijän osoittamisesta ennen uutta valtuutusta. Laskutusreitti, jossa havaitaan todennusvirhe, tarvitsee palvelun omistajan ja laajennetun muutoksen hyväksyjän arvioimaan ehdotetun korjauksen. Epäilty vuokralaisten välinen vientiyritys vaatii tietoturvatarkistuksen ja mahdollisen valtuutetun suojauksen, ei automaattista sijoittamista DNS korjausjonoon. Nämä ovat hypoteettisia triagepäätöksiä, eivät todellisia tapauksia tai ilmoituksia.
Nimeä jokaisessa tapauksessa vahvistettu ensisijainen yhteyshenkilö, vaihtoehtoinen henkilö, sallittu toiminnan laajuus ja seuraavaksi tarvittavat todisteet. Jos laskutuksen hyväksyjä ei ole tavoitettavissa ja vaihtoehtoisella edustajalla ei ole valtuuksia kohdeverkkotunnukseen, pidä muutos odotustilassa ja laajenna aukkoa. Älä hiljaa pidä vasteaikatavoitetta tai liiketoiminnan kiireellisyyttä luvana suorittaa. Tämä esimerkki ei sisällä sopimukseen perustuvaa kelloa, asiakaslupaa tai suoritettua kentän vahvistusta.
Säilytä päätökset ja tarkista ne
Säilytä tarkka ehdotus, hyväksyntätunnus, aikaleima, toteutuskuitti ja vahvistustulos yhdessä. RFC 9989's linjaus malli auttaa määrittämään, mitä onnistuneen todennuksen korjauksen on osoitettava. Ennätys pelkkä haku on heikompi kuin viestitason tulos kyseisestä sovelluksesta. Tallenna jäännösvirheet sen sijaan, että julistaisi tapahtuman päättyneeksi, kun vain helpoin lähettäjä toimii.
Tarkista yhteystiedot henkilökunnan vaihtumisen jälkeen ja käytä reittiä tekemättä luvattomia tuotantomuutoksia. Eskalointiharjoituksen tulee paljastaa tavoittamattomat kontaktit, epäselvät auktoriteetit ja puuttuva kattavuus. Päivitä runbook ja hanki asianmukainen asiakkaan hyväksyntä ennen kuin luotat muuttuneisiin vastuisiin. Tuloksena pitäisi olla paineen alaisena toimiva päätöspolku, ei nimihakemisto.