Talitluspidevus: tõendage taastamise tee

Taasteplaan muutub usutavaks siis, kui meeskond suudab näidata, kuidas kriitiline teenus taastub, millises järjekorras ja milliste ressurssidega. Varukoopia on üks selle plaani sisenditest; see ei tõenda kogu taastamisvõimekust.

CTO jaoks on praktiline küsimus see, kas taastamine toimib ka siis, kui tavapärased tööeeldused ei kehti. Kas teine insener suudab protseduuri läbi viia? Kas meeskond saab mandaadid kätte ilma tootmiskeskkonna identiteediteenuseta? Kas ärikasutajad saavad pärast taristu taastamist tehingu lõpule viia?

Käsitlege talitluspidevust projekteeritud võimekusena: määratlege vastuvõetavad tulemused, tuvastage sõltuvused, looge taastamisprotseduurid, harjutage neid ja säilitage tõendid toimunu kohta. Tulemuseks on tõendatud taastamise tee, mille piirangud on teada ja mille nõrkused on parandamiseks määratud.

Tehke kindlaks kohustus ja tegevuspiir

NIS2 artikkel 21 hõlmab küberturvalisuse riskijuhtimismeetmete hulgas talitluspidevust, näiteks varukoopiate haldust ja avariitaastet, ning kriisijuhtimist. Samuti käsitleb see poliitikaid ja protseduure nende meetmete tõhususe hindamiseks. Artikkel 20 hõlmab juhtkonna kinnitust ja järelevalvet.

NIS2 on direktiiv, mida rakendatakse riigisisese õiguse kaudu. Kohaldatavus sõltub sektorist, suurusest, teenusest ja hõlmamisreeglitest; konkreetsed kohustused määravad kohaldatavad riigisisesed ja sektorinõuded. Ärge käsitlege üldist talitluspidevuse malli täieliku õigusliku hinnanguna.

Tegevuslikult eristage nelja omavahel seotud tegevust:

• Talitluspidevus: oluliste ärifunktsioonide toimimas hoidmine, vajaduse korral vähendatud mahus.
• Varukoopiate haldus: andmete ja vajaliku konfiguratsiooni kaitstud, taastatavate koopiate säilitamine.
• Avariitaaste: tehniliste süsteemide taastamine ja nende toetatava teenuse valideerimine.
• Kriisijuhtimine: otsuste, ressursside, kommunikatsiooni ja eskaleerimise koordineerimine.

Teenus võib jätkuda käsitsi tehtava töö kaudu, samal ajal kui selle süsteemid jäävad kättesaamatuks. Vastupidi võivad serverid töötada, samal ajal kui ärifunktsioon jääb kasutuskõlbmatuks. Määratlege nii tehnilised kui ka ärilised vastuvõtukriteeriumid.

Alustage ühest kriitilisest teenusest ja kindlaksmääratud stsenaariumi piirist. Taastamine juhuslikust kustutamisest erineb taastamisest pärast haldusmandaatide kompromiteerimist. Salvestage, milliseid olukordi plaan hõlmab, millised vajavad eraldi protseduure ja kes aktsepteerib allesjääva lünga.

Liikuge tagasi äriteenusest lähtudes

Äritegevuse mõjuanalüüs ehk BIA määrab, mida katkestus tähendab, enne kui insenerid valivad taastamislahenduse. Küsitlege teenuse omanikku ja inimesi, kes tööd tegelikult teevad. Küsige, mis juhtub tunni, tööpäeva ja pikema katkestuse järel: tegemata tehingud, ohtlikud toimingud, lepingurikkumised, kahju klientidele või kuhjuv mahajäämus.

Dokumenteerige minimaalne vastuvõetav töötase. Kliendiportaal võib vajada tellimuste esitamist ja tellimuste oleku vaatamist enne aruandlusfunktsioonide naasmist. Tootmistegevus võib vajada ajakava ja ohutusteavet enne haldusfunktsioone.

Lahenduse kujundamist juhivad kolm mõõdet:

Need on omavahel seotud, kuid erinevad. RTO peaks jätma talutava katkestusaja piires ruumi äriliseks valideerimiseks ja tegevuse taastamiseks. RPO kirjeldab vastuvõetavat andmekadu; see ei ole veel üks seisakuaja eesmärk.

Leppige ajaarvestuse algus selgesõnaliselt kokku. Kui üks meeskond mõõdab RTO-d intsidendi väljakuulutamisest ja teine teenuse katkemisest, on esitatud tulemused eksitavad. Salvestage avastamise ja aktiveerimise aeg eraldi ka siis, kui kokkulepitud taastemõõdik algab hiljem.

Äriomanikud kinnitavad nõutava tulemuse; insenerid tõendavad, kas lahendus suudab selle saavutada. Kui kulud, töötajate arv või tarnijate piirangud muudavad eesmärgi ebarealistlikuks, esitage valikud: investeerida kiiremasse taastamisse, võtta kasutusele vähendatud tegevus, muuta eesmärki vastutava kinnitusega või aktsepteerida risk. Ärge asendage ärinõuet vaikides sellega, mida praegune varundussüsteem juhtumisi saavutab.

Kaardistage sõltuvused, mis võivad taastamist takistada

Kliendiportaali puhul võib andmebaasi taastamine jätta teenuse siiski kasutuskõlbmatuks, kui identiteediteenus, DNS või juurutusmandaadid ei ole kättesaadavad. Looge sõltuvuskaart äritehingust väljapoole, mitte serverite inventarist sissepoole.

Kaasake rakendused ja andmebaasid, aga ka võrgud, identiteedipakkujad, sertifikaaditeenused, saladused, krüptovõtmed, juurutusartefaktid, seire, välised integratsioonid, inimesed ja tarnijate tugi. Salvestage, kus iga sõltuvust käitatakse, kes suudab selle taastada ja mis peab olemas olema enne taastamise algust.

Otsige eriti ringsõltuvusi. Paroolihoidla võib vajada identiteediplatvormi, samal ajal kui selle platvormi taastamine nõuab hoidlas talletatud mandaate. Taastejuhend võib asuda koostööteenuses, mis on ise kättesaamatu. Lahendage sellised ringid kontrollitud hädajuurdepääsu ja sõltumatult kättesaadavate juhiste abil; testige mõlemat, selle asemel et eeldada nende toimimist.

Taastamise järjekord on sõltuvusgraaf, mitte tingimata universaalne jada võrk–andmebaas–rakendus. Mõningaid ülesandeid saab teha paralleelselt. Teistel on väravad, näiteks puhta halduskeskkonna kinnitamine enne, kui taastatud töökoormused sellega ühendatakse.

Tarnijate puhul eristage lubadusi tegevuskorraldusest. Tehke kindlaks tugikontaktid, eskaleerimisteed, kliendipoolsed kohustused, ekspordivõimalused, taastekohustused ja see, kuidas te katkestuse ajal uuendusi saate. Tarnija taasteeesmärk ei määra automaatselt teie teenuse otsast lõpuni eesmärki. Modelleerige, mis juhtub, kui tarnija on oodatust kauem kättesaamatu.

Kujundage varundus taastamise, mitte töö lõpetamise järgi

Edukas varundustöö näitab, et protsess lõppes. See ei tõenda, et salvestati õiged andmed, et võtmed on endiselt kättesaadavad või et rakendus suudab taastatud olekut kasutada.

Koostage iga kriitilise süsteemi jaoks varunduse spetsifikatsioon:

• Kaasatud andmestikud, konfiguratsioon, artefaktid ja selgesõnalised välistused.
• Varundusmeetod, ajakava, taastepunkti oodatav vanus ja säilitamine.
• Salvestuskohad ja sõltuvused kontodest, piirkondadest või rajatistest.
• Haldusjuurdepääs, krüpteerimine, võtmete taastamine ja kustutamiskontrollid.
• Seire vastutus, tõrgete eskaleerimine ja taastamisjuhised.
• Taastetesti ulatus, vastuvõtukriteeriumid ja säilitatud tulemused.

Levinud 3-2-1 lähenemisviis, mida mõnikord laiendatakse võrguühenduseta või muutumatu koopia ja kontrollimisega, on praktiline kujundusheuristika, mitte universaalne NIS2 valem. Hinnake, kas koopiatel on tõesti erinevad tõrkeviisid. Mitu koopiat, mida hallatakse ühe kompromiteeritud administraatorikonto kaudu, võivad pakkuda tahtliku kustutamise vastu vähe kaitset.

Ka võrguühenduseta ja muutumatud koopiad on erinevad. Võrguühenduseta salvestus on lahti ühendatud; muutumatu salvestus piirab muutmist või kustutamist kindlaksmääratud kontrollide alusel. Uurige, kes saab muuta säilitamist, hävitada võtmeid, sulgeda konto või muuta juurdepääsupoliitikaid. Vältige sildi enda käsitlemist kaitse tõendina.

Sobitage mehhanism andmetega

Tehingupõhise andmebaasi puhul ei pruugi hetktõmmiste sagedus üksi RPO-d täita. Vajalikud võivad olla logide salvestamine, rakendusega kooskõlas olevad varukoopiad ja ajapunktipõhine taastamine. Valideerige, kas mitme süsteemi vahel jaotatud tehinguid saab taastada ühtsesse olekusse.

Replikatsioon võib katkestust vähendada, kuid see võib replitseerida ka andmete rikkumist või pahatahtlikke muudatusi. See ei asenda säilitatud taastepunkte. Samamoodi ei pruugi SaaS-teenuse kättesaadavuskohustus hõlmata taastamist kliendipoolsest kustutamisest või konto kompromiteerimisest; kontrollige tegelikke taastamise ja ekspordi korraldusi.

Kaasake krüptovõtmed ja konfiguratsioon, mida on vaja taastatud andmete tõlgendamiseks. Kaitske taastematerjali vajaduse korral eraldi, kontrollitud juurdepääsu ja testitud kättesaamise teega. Krüpteerimine ja võtmehaldus peaks hõlmama nii taastamist kui ka tavapärast tegevust.

Säilitamine peab arvestama hilinenud avastamisega: uusim koopia võib juba probleemi sisaldada. Vanema puhta punkti valimine võib suurendada andmekadu üle RPO. Dokumenteerige see kompromiss ja vajalik kooskõlastustöö, selle asemel et nimetada iga lõpetatud taastamist eduks.

Kirjutage tegevusjuhendid, mida teine insener suudab täita

Kasulik taastamise tegevusjuhend määrab eeltingimused, toimingud, oodatavad väljundid, tõrkeharud ja vastuvõtukontrollid. See peaks olema piisavalt konkreetne, et volitatud asendaja saaks seda järgida, ilma et peaks surve all arhitektuuri uuesti välja mõtlema.

Alustage aktiveerimistingimustest ja ohutuspiiridest. Kes kinnitab taastamise? Kus see toimub? Millised võrgud peavad jääma isoleerituks? Millised tootmismuudatused on õppuse ajal keelatud? Kui kahtlustatakse pahatahtlikku tegevust, säilitage asjakohased tõendid ja koordineerige ohjeldamist enne taastatud süsteemide uuesti ühendamist.

Iga samm peaks sisaldama:

Viidake keskkonnapõhiste käskude puhul kontrollitud protseduuridele. Hoidke saladused tegevusjuhendist endast väljas, kuid selgitage, kuidas volitatud reageerijad need katkestuse ajal kätte saavad.

Mõõtke ettevalmistust, edastamist, taastamist, konfigureerimist, valideerimist ja üleandmist eraldi. Kiire andmete taastamine võib siiski RTO-st mööda minna, sest taristu ettevalmistamine või ärilised kontrollid võtavad oodatust kauem aega.

Küberintsidendist taastamisel võib usaldusväärsetest artefaktidest uuesti ülesehitamine olla turvalisem kui tervete masinate taastamine. Valideerige privilegeeritud kontod, vahetage vajaduse korral paljastunud mandaadid ja kontrollige enne väljalaset püsivuse mehhanismide olemasolu. Need otsused peaksid olema protseduuris selgesõnalised harud.

Lõpetage teenustaseme kontrollidega: autentimine, esinduslik tehing, integratsioonide käitumine, seire ja kooskõlastamine. Tehniline juht salvestab lõpetamise; äriomanik aktsepteerib kokkulepitud töötaseme. Lisage kontrollitud naasmine ajutistest korraldustest koos vastutusega järjekorda jäänud töö ja topeltkirjete lahendamise eest.

Hoidke äri taastamise ajal töös

Alternatiivsetel tegevusviisidel on vaja oma võimsus- ja ohutuspiire. „Kasutage tabelarvutust“ ei ole plaan, kui keegi ei ole kindlaks määranud juurdepääsu, välju, volitusi, salvestuse kaitset ja hilisemat kooskõlastamist.

Häiritud tellimisteenuse puhul võib ajutine protsess võtta kinnitatud kanali kaudu vastu piiratud liiki tellimusi, väljastada unikaalseid viitenumbreid ja lükata maksete töötlemise edasi. Salvestage, kes tellimusi kinnitab, kuidas topeltkirjeid välditakse, kuidas kliendiandmeid kaitstakse ja millal ajutine lahendus peab lõppema.

Hinnake, kas vähendatud tegevus annab tegelikult piisavalt aega. Käsitsi töötlemine võib väikest mahtu toetada, kuid tavapärase töökoormuse all kokku variseda. Testige esinduslikku nõudlust ja tuvastage prioriteetsed kliendid või tehingud kokkulepitud äriliste kriteeriumide alusel.

Planeerige ka inimesi ja töökohti. Taastamine võib ebaõnnestuda, sest ainus kvalifitseeritud operaator ei ole kättesaadav, varukohas puudub ühendus või reageerijad ei saa pikaajalise intsidendi ajal ohutult töötada. Määrake asendajad, üleandmisnõuded ja töötajate korraldus, selle asemel et tugineda üksikisikute vastupidavusele.

Andke kriisimeeskonnale selged otsustusõigused

Eraldage intsidendi koordineerimine praktilisest taastamisest, et tehniline juht ei peaks samal ajal süsteeme taastama, kulusid kinnitama ja igale huvirühmale vastama.

Määrake põhi- ja asendusrollid kriisi koordineerimiseks, tehniliseks taastamiseks, äritegevuseks, juhtkonna otsusteks, kommunikatsiooniks ning õiguslikuks või vastavushindamiseks. Salvestage aktiveerimislävendid, kontaktiviisid, otsustusõigused ja eskaleerimistingimused. Praktilised eelvolitused võivad hõlmata erakorralise toe ostmist, alternatiivset taristut ja ohtlike teenuste peatamist juhtkonna kinnitatud piirides.

Valmistage ette kommunikatsioonimallid töötajatele, klientidele, tarnijatele ja asutustele. Igaüks neist peaks eristama teadaolevaid fakte hinnangutest, kirjeldama mõjutatud teenuseid, andma praegused juhised ja märkima järgmise uuenduse aja. Testige alternatiivset kanalit olukorraks, kus ettevõtte e-post ja vestlusplatvorm ei ole kättesaadavad. Tagage, et reageerijad pääseksid kontaktandmetele turvaliselt ligi väljaspool tavapäraseid süsteeme.

Teavitamiskohustuse hindamine peab toimuma taastamisega paralleelselt. Kohaldamisalasse kuuluvate oluliste intsidentide korral kehtestab NIS2 artikkel 23 24 tunni jooksul esitatava varajase hoiatuse, 72 tunni jooksul esitatava intsidendi teate ja üldjuhul lõpparuande ühe kuu jooksul pärast teadet. Kontrollige kohaldatavaid riigisiseseid ja sektorireegleid, lävendeid, adressaate ja protseduure. Mitte iga katkestus ei ole automaatselt teavitamiskohustuslik.

Määrake keegi jälgima teadasaamise aega ja teavitamisotsuseid; ärge oodake kohustuste hindamisega täieliku taastamiseni. Kui kaasatud on isikuandmed, hinnake eraldi GDPR-i rikkumisest teavitamise nõudeid vastavalt organisatsiooni rollile ja riskile üksikisikutele.

Kontrollige erinevaid väiteid erinevate testidega

Valige õppuse tüüp selle järgi, mida peate tõendama:

Määrake sagedus praktilise, riskipõhise otsusena, lähtudes kohaldatavatest nõuetest, teenuse kriitilisusest, muudatuste tempost ja varasematest leidudest. Ärge eeldage, et universaalne kord kvartalis või kord aastas toimuv test täidab iga kohustuse. Käivitage lisatestid pärast olulisi arhitektuuri-, tarnija-, juurdepääsu- või personalimuudatusi.

Kinnitage enne testimist stsenaarium, eesmärgid, ohutuskontrollid, osalejad, peatamistingimused ja edukriteeriumid. Eelistage võimaluse korral isoleeritud keskkondi. Takistage testisõnumite, maksete või klienditeavituste jõudmist päris tegevusse.

Kasutage realistlikke piiranguid: puuduv spetsialist, kättesaamatud identiteediteenused, vanem puhas varukoopia või hilinenud tarnija tugi. Vältige vaikimisi selliste mandaatide ja taristu pakkumist, mida intsidendi ajal ei oleks.

Salvestage stsenaarium, osalejad, algus- ja lõppaeg, sammude ajad, tegelikud tulemused ja kõrvalekalded. Salvestage saadud abi ja otseteed. Kui test jättis välja DNS-muudatused, tootmismahus andmed või välised integratsioonid, öelge seda. Piiritletud tulemus on kasulikum kui ülepaisutatud „läbitud“.

Läbitöötatud näide: kliendiportaali taastamise tee tõendamine

Vaatleme illustratiivset portaali, mis toetab tellimuste esitamist. Järgmised eesmärgid ja ajad on eeldused, mitte tööstusharu võrdlusnäitajad ega tootelubadused.

Äri lepib kokku nelja tunni RTO ja 15 minuti RPO. Taastamine tähendab, et kliendid saavad autentida, tellimuse esitada ja selle olekut näha; aruandlus võib naasta hiljem. Stsenaarium eeldab, et tootmistaristu ja tavalised administraatorimandaadid ei ole kättesaadavad, kuid eraldi kontrollitav varukoopia on endiselt ligipääsetav.

Meeskond eelarvestab tee järgmiselt:

See jätab nelja tunni eesmärgi suhtes vaid 20 minutit varu. Kuna mitu ülesannet jagavad üht taasteinseneri, ei eelda meeskond, et neid saab teha samaaegselt.

Õppuse ajal kulub juurutusmandaatide saamiseks 55 minutit lisaaega: dokumenteeritud juurdepääsutee sõltub kättesaamatust identiteedipakkujast. Teenus läbib oma funktsionaalsed kontrollid 275 minuti järel ja ületab RTO. Selle viimane taastatav tehing on 12 minutit enne katkestust, mis täidab selle stsenaariumi eeldatava RPO.

Tulemus ei ole üldine „läbitud“. Juurdepääsu omanik loob kontrollitud sõltumatu kättesaamise tee, tegevusjuhendit uuendatakse ja asendusinsener testib seda uuesti. Järgmine integreeritud õppus peab kogu ajakulu uuesti kontrollima. Äriomanik vaatab ka üle, kas allesjäänud ajavaru on vähem soodsates tingimustes piisav.

Säilitage tõendid ja kõrvaldage nõrkused

Hoidke terviklikku tõendikogumit: kinnitatud BIA, teenuse piir ja sõltuvused, varunduse spetsifikatsioon, taastamise tegevusjuhendid, kriisirollid ja kontaktid, alternatiivse tegevuse protseduurid ja õppuste kirjed. Säilitage versioonid, et ülevaatajad näeksid, millist plaani tegelikult testiti.

Salvestage iga olulise nõrkuse kohta mõjutatud teenus, täheldatud tulemus, äriline tagajärg, omanik, tähtaeg, parandus ja kontrollimise meetod. Ülesande lõpetamine ei ole sama mis paranduse tõendamine. Testige mõjutatud samm uuesti ja, kui sõltuvused muutusid, ka laiem taastamise tee. Eskaleerige tähtaja ületanud tegevused ja eesmärkide lüngad vastutavale otsustajale.

Modelleerige Secanis kriitiline teenus koos seda toetavate süsteemide ja teenuseosutajatega, siduge õppuste tõendid nõuete või kontrollimeetmetega, mida need toetavad, ja muutke lüngad omanikuga ülesanneteks. Hoidke ülevaatajate kommentaarid ja inimeste kinnitused otsuste juures. Dokumenteeritud töövoog toetab seda tõendikonteksti; tehnilise taastamise peab siiski läbi viima ja valideerima vastutav meeskond.

Alustage ühest kriitilisest teenusest. Leppige kokku, mida taastamine tähendab, käige selle sõltuvustee läbi koos asendusoperaatoriga ja ajastage piiritletud taasteõppus. Kasutage mõõdetud tulemust plaani uuendamiseks, mitte lihtsalt õppuse lõpetatuks märkimiseks.