Sähköpostin todennuksen jatkuvuuden suunnittelu alkaa liiketoimintavaikutuksista, ei yleisestä lupauksesta korkeasta käytettävyydestä. Tunnista virrat, joiden on jatkuttava, todisteet, joita organisaatiolla on varaa menettää, ja ihmiset, jotka voivat palauttaa jokaisen riippuvuuden. Raportoinnin ja todennuksen hallinta saattaa vaatia erilaisia palautustavoitteita kuin tapahtumalähetys.
Aseta tavoitteet toiminnon mukaan
Käytä liiketoimintavaikutusanalyysiä erottaaksesi viivästynyt uutiskirje epäonnistuneesta tilinpalautusviestistä. NIST SP 800-34 Rev. 1 tarjoaa yleiset puitteet valmiussuunnittelulle, toipumisstrategioille, testaukselle ja ylläpidolle. Se ei määrää sähköpostikohtaisia palautusaikoja. Yrityksen on valittava nämä tavoitteet vaikuttavuuden ja toteutettavuuden perusteella.
Määritä palautusaikatavoite määritetyn resurssin tai toiminnon suurimmaksi hyväksyttäväksi epäkäytettävyydeksi, ennen kuin sen vaikutus liiketoimintaan muuttuu mahdottomaksi. Määritä palautuspisteen tavoite häiriötä edeltäväksi pisteeksi, johon tietojen on oltava palautettavissa, mikä kuvastaa siedettyä tietojen menetystä. Ilmoita kellon aloitus, laajuus ja hyväksyttävä huonontunut tila. Raportoiva RPO ei kuvaa toimituskatkoksia; DNS palautuskohde ei takaa, että jokainen rekursiivinen välimuisti on lähentynyt.
Säilytä riippumattomat palautustulot
Säilytä hyväksyttyjä kopioita vakuutusasiakirjoista, valitsin kartoituksia, palvelun omistajuutta, konfigurointihistoriaa ja raporttien vientiä käytettävissä olevan hallintaliittymän ulkopuolelle. Erottele julkiset määritykset tunnistetiedoista ja käytä hyväksyttyä salausprosessia palautuskäyttöön. Varmista, että valtuutetut varmuuskopiointioperaattorit voivat noutaa ohjeet turvautumatta samaan virheelliseen identiteettiin tai tilipolkuun.
Kartoita riippuvuudet DNS -isännöinnin, allekirjoituksen, välitysten, raporttien keräämisen ja järjestelmänvalvojan käyttöoikeuksien välillä. Vaihtoehtoinen hallintapaneeli samalla tilillä voi epäonnistua alkuperäisen kanssa. Vaihtoehtoinen lähettäjä on hyödyllinen vain, jos sovellus voi käyttää sitä ja sen identiteetti on määritetty ja testattu. Älä rinnasta toimittajasopimusta suoritettavaan vikasietopolkuun.
Laske esimerkki SLA:n keksimisen sijaan
Hypoteettinen jatkuvuuslaskentataulukko olettaa raportoinnin palautustavoitteeksi neljä tuntia ja yhden tunnin tietojen menetyksen tavoitteeksi. Häiriö alkaa klo 12.00 UTC; viimeisin palautettavissa oleva vienti on 11:30 ja palvelu palautetaan klo 14:00. Käsin laskettu palautumisaika on kaksi tuntia ja vienti-ikäaltistus on 30 minuuttia oletettujen numeeristen tavoitteiden sisällä, jos vienti on ainoa palautettavissa oleva syöttö ja ilmoitettu hyväksyttävä toiminto todella palautetaan. Toinen tapaus palautuu klo 17.00 klo 10.00 viennistä, jolloin palautumisaika on viisi tuntia ja vienti-ikäaltistus kaksi tuntia. Nämä luvut ylittävät molemmat oletetut tavoitteet, elleivät muut palautettavissa olevat syöttötiedot muuta tietojen menetyksen arviointia.
Nämä ovat käsin tehtyjä aikaleimalaskelmia kuvitteellisista tapahtumista, ei suoritettuja testejä, mitattua palveluntarjoajan suorituskykyä tai suositeltuja yleistavoitteita. Korvaa ajat havaituilla harjoitustietueilla. Arvioi, säilytettiinkö välin aikana saapuneet raakasyötteet muualla ja voidaanko ne toistaa. Jos he voivat, todellinen kadonneiden tietojen aikaväli voi poiketa viimeisimmän koontinäytön viennin iästä. Tallenna perusta sen sijaan, että raportoisit houkuttelevan luvun ilman sen populaatiota.
Harjoittele ja noudata suunnitelmaa
Suorita ensin pöytälevy ja sitten valtuutettu tekninen harjoitus turvallisessa ympäristössä. Sisällytä ensisijaisen operaattorin menetys, hallintaoikeudet ja viivästynyt raporttisyöte. Kirjaa ylös, kuka tekee palautuspäätöksen, mitkä tiedot puuttuvat ja mitä varmuuskopiointioperaattori voi todella suorittaa. Tarkista viestien tulokset ja raportoi jatkuvuus erikseen.
Tarkista suunnitelma toimittajan, toimialueen, hakemuksen tai henkilöstön muutosten jälkeen. Säilytä poikkeusten omistajat ja uusintatestauspäivät. Lopeta harjoitus vasta, kun vioilla on toimia ja määräaikoja; onnistunut keskustelu ei ole todiste teknisestä kunnostuksesta. Kerro yritykselle tuettu palautuskyky ja sen rajat. Älä esitä paikallista laskentataulukkoa palvelutason takuuna.