Salassa pidettävien järjestelmien toipuminen: varmuuskopiointi, COOP, eheys

Salassa pidettävät puolustustietojärjestelmät pettävät. Laitteistot pettävät. Tilat menettävät virran. Kiristysohjelmatoimijat luotaavat hyvinkin puolustettujen verkkojen reunoja. Kysymys ei ole siitä, onko tehtäväkriittinen salassa pidettävä järjestelmä koskaan poissa käytöstä – vaan siitä, onko organisaatiolla testattu, toteutettavissa oleva suunnitelma sen palauttamiseksi siinä ajassa, jonka tehtävä voi sietää. Salassa pidettävien järjestelmien katastrofitoipuminen ei ole pienennetty versio kaupallisesta IT-DR:stä; se on oma erillinen tieteenalansa, jota muovaavat akkreditointirajoitukset, tietojen lokeroinnin vaatimukset sekä se toiminnallinen tosiasia, että nopeinta palautusta eniten tarvitsevat järjestelmät ovat ne, joiden palautusmenettelyt ovat vaikeimmat toteuttaa.

Tämä artikkeli käsittelee salassa pidettävien järjestelmien DR:n neljää tukipilaria: varmuuskopiointiarkkitehtuuria luokitusrajojen sisällä, toiminnan jatkuvuussuunnittelun (COOP) integrointia, kryptografista eheyden tarkistusta ja testattuja palautusmenettelyjä. Se käsittelee erityisrajoituksia, jotka tekevät salassa pidettävästä DR:stä vaikeampaa kuin tavanomaisesta IT-DR:stä – sekä yleisimmät virheet, jotka jättävät ohjelmat varmuuskopioiden varaan, joita ei voida laillisesti tai teknisesti palauttaa tarpeen tullen.

Miksi salassa pidettävä DR on erilaista

Tavanomainen IT-katastrofitoipuminen optimoi nopeutta ja kustannuksia. Vallitseva kaupallinen lähestymistapa – pilvessä isännöity varmuuskopiointi automaattisella vikasietoisella vaihdolla – ei ole useimpien salassa pidettävien järjestelmien käytettävissä. Salassa pidettävää DR:ää muovaavat rajoitukset ovat:

Akkreditointirajat. Salassa pidettävä järjestelmä toimii toimintalupauksen (ATO) alaisena, joka on myönnetty tietylle kokoonpanolle tietyssä akkreditoidussa ympäristössä. Varmuuskopio, joka voidaan palauttaa vain akkreditoimattomaan ympäristöön, on toiminnallisesti hyödytön. DR-arkkitehtuuri on suunniteltava siten, että palautusympäristö – ei vain tuotantoympäristö – kantaa oikean akkreditoinnin, turvavalvonnat ja henkilöstön pääsyvaltuudet ennen katastrofia, ei sen jälkeen.

Fyysisen median käsittely. Salassa pidettävän datan varmuuskopiomedia luokitellaan samalle tasolle kuin sen sisältämä data. Nauhat, asemat ja irrotettava tallennus on merkittävä, säilytettävä, kuljetettava ja tuhottava niiden sisältämän datan luokitusohjeiden mukaisesti. DR-suunnitelmien, jotka olettavat, että varmuuskopiomedia voidaan kuljettaa kuriirilla toimipisteen ulkopuoliseen tilaan lyhyellä varoitusajalla, on otettava huomioon turvallisen kuljetuksen logistiikka – joka SECRET-tasolla ja sitä korkeammalla voi vaatia aseistetun saattueen ja erityisiä ajoneuvovaatimuksia.

Riippuvuus salausavaimista. Salassa pidettävät varmuuskopiot ovat salattuja. Salattu varmuuskopio on täysin lukukelvoton ilman oikeita salauksenpurkuavaimia – riippumatta siitä, kuinka nopeasti palautusinfrastruktuuri tulee saataville. DR-tarkoituksiin tehtävä avaintenhallinta on suunniteltava erilliseksi työvirraksi: missä avaimet säilytetään, kenellä on valtuutettu pääsy, miten ne palautetaan, jos ensisijainen avaintenhallintajärjestelmä on itse osa katastrofia, ja kuinka kauan avainten palautus kestää?

Enklaavien välinen eristys. Organisaatiot, jotka käyttävät useita luokitusenklaaveja – SECRET, TS/SCI tai kansalliset vastineet – eivät voi yhdistää varmuuskopiointi-infrastruktuuria niiden välillä. Jokainen enklaavi vaatii oman fyysisesti erillisen varmuuskopiopinonsa. Yhdistetyt varmuuskopiojärjestelmät luovat vaatimustenmukaisuusrikkomuksia ja mahdollisia peiteltyjä kanavia, vaikka itse varmuuskopiodata olisi salattua.

Varmuuskopiointiarkkitehtuuri luokitusrajojen sisällä

Salassa pidettävän järjestelmän varmuuskopiointiarkkitehtuurin lähtökohta on liiketoimintavaikutusten analyysi (BIA), joka yhdistää tehtävätoiminnot niitä tukeviin järjestelmiin ja määrittää kullekin palautusaikatavoitteet (RTO) ja palautuspistetavoitteet (RPO). Tehtävän kannalta olennaisille C2-järjestelmille alle neljän tunnin RTO:t ja alle viidentoista minuutin RPO:t ovat yleisiä vaatimuksia – saavutettavissa vain hot- tai warm standby -replikoinnilla, ei kylmällä varmuuskopioinnilla. Hallinnollisille ja logistisille järjestelmille 24–72 tunnin RTO:t ja 24 tunnin RPO:t ovat tyypillisempiä ja tukevat yksinkertaisempia nauha- tai levyvarmuuskopiointilähestymistapoja.

Hot standbya vaativan järjestelmän salassa pidettävässä varmuuskopiointiarkkitehtuurissa on kolme kerrosta:

1. Synkroninen tai lähes synkroninen replikointi. Kriittinen tila – tietokannan transaktiolokit, kokoonpano, kryptografinen materiaali – replikoidaan toissijaiselle solmulle saman akkreditoidun tilan sisällä tai samaan sijaintiin sijoitettuun akkreditoituun tilaan omistetulla turvallisella yhteenliitännällä. Replikoinnin viive määrää käytännön RPO:n alarajan; synkroninen replikointi saavuttaa lähes nollan RPO:n kirjoitusviiveen kustannuksella.

2. Aikataulutettu varmuuskopiointi akkreditoituun offline-tallennukseen. Päivittäiset tai useammat täydet ja inkrementaaliset varmuuskopiot omistetulle varmuuskopiomedialle, joka säilytetään akkreditoidun tilan turvallisessa tallennuksessa. Tämä kerros suojaa loogiselta vioittumiselta – kiristysohjelmat, vahingossa tapahtuva poisto, tietokannan vioittuminen – jonka replikointi levittää toissijaiselle solmulle.

3. Toimipisteen ulkopuolinen kopio toisessa akkreditoidussa tilassa. Varmuuskopioiden määräaikainen (viikoittainen tai kuukausittainen) siirto fyysisesti erilliseen akkreditoituun tilaan, jolla on vastaavat turvavalvonnat. Tämä kerros suojaa tilan fyysiseltä menetykseltä – tulipalo, tulva, fyysinen hyökkäys. Järjestelmissä, joiden kaksi akkreditoitua tilaa ovat maantieteellisesti erillään, tämä siirto on tyypillisesti valtuutetun kuriirin suorittama fyysinen median kuljetus.

Ilmaeristetyissä (air-gapped) järjestelmissä verkkopohjainen replikointi ei ole käytettävissä. Kaikki varmuuskopiotoiminnot ovat fyysisiä – kirjoitukset paikalliselle medialle, manuaalinen vahvistus ja fyysinen kuljetus toimipisteen ulkopuolisille kopioille. Fyysisen kuljetuksen aika on nimenomaisesti sisällytettävä RTO-laskelmaan, koska "varmuuskopio on olemassa" ja "varmuuskopio on palautettavissa vaaditulla sijainnilla" ovat erotettu logistisella vaiheella, joka voi kestää tunneista päiviin mukana olevista tiloista riippuen.

Varmuuskopioiden salaus ja avaintenhallinta

Jokainen varmuuskopiojoukko on salattava levossa käyttäen enklaavin hyväksymää kryptografista algoritmia – AES-256 on perustaso useimmille kansallisille turvajärjestelmille. Varmuuskopiodatan salausavaimia on hallittava erillään itse varmuuskopiodatasta: avain, joka tallennetaan suojaamansa varmuuskopion viereen, ei tarjoa mitään suojaa vastustajaa vastaan, joka saa pääsyn varmuuskopiomediaan. Vakioarkkitehtuuri käyttää omistettua laitteistoturvamoduulia (HSM) akkreditoidun tilan sisällä varmuuskopioiden salausavainten säilyttämiseen, avaimen talletuksella (escrow) toiseen HSM:ään toimipisteen ulkopuolisessa tilassa.

Avainten palautusta on harjoiteltava osana DR-harjoituksia. DR-suunnitelma, joka ei ole koskaan testannut palautusta varmuuskopiosta avainten palautusmenettelyä käyttäen – vain varmuuskopiosta käyttäen avaimia, jotka ovat edelleen saatavilla ensisijaisessa tilassa – ei ole testannut skenaariota, jonka se eniten tarvitsee kattaa.

COOP-integraatio: teknisestä DR:stä tehtävän jatkuvuuteen

Tekninen DR-suunnitelma vastaa kysymykseen: miten palautamme nämä järjestelmät? Toiminnan jatkuvuussuunnitelma (COOP) vastaa laajempaan kysymykseen: miten jatkamme tehtävän kannalta olennaisia toimintoja minkä tahansa häiriön aikana ja sen jälkeen? NIST SP 800-34 (Contingency Planning Guide for Federal Information Systems) tarjoaa arvovaltaisen kehyksen Yhdysvaltain hallinnon ohjelmille; Natolla on vastaavat INFOSEC-ohjeet salassa pidettäville Nato-järjestelmille.

COOP määrittää olennaiset toiminnot, jotka on ylläpidettävä – ne, joiden keskeytys haittaisi suoraan tehtävää – ja priorisoi ne nimenomaisesti. Kaikki järjestelmän toiminnot eivät ole yhtä olennaisia. S2-tiedustelutiedon fuusiokyky voi olla olennainen häiriön ensimmäisellä tunnilla; sitä syöttävät raportointi- ja arkistointitoiminnot voivat sietää 48 tunnin katkoksen. Näiden priorisointipäätösten tekeminen ennen katastrofia on ratkaisevaa, koska niiden tekeminen toiminnallisen paineen alla järjestelmien ollessa alhaalla tuottaa huonompia tuloksia.

Jotta COOP olisi toteutettavissa, se vaatii nimetyt varahenkilöt jokaiselle palautusprosessin avainroolille. Ensisijaisella järjestelmänvalvojalla, tietojärjestelmän turvallisuusvastaavalla (ISSO) ja median säilyttäjällä on kaikilla nimetyt varahenkilöt, jotka on koulutettu, valtuutettu ja joilla on ajantasaiset pääsyoikeudet. DR-suunnitelma, joka riippuu tiettyjen yksilöiden saatavuudesta, ei ole suunnitelma – se on toive. Organisaatiot epäonnistuvat säännöllisesti palautusharjoituksissa, koska ainoa tietyn menettelyn tunteva henkilö on poissa harjoituspäivänä.

COOP käsittelee myös varatilojen toimintaa. Jos ensisijainen tila on katastrofi, missä henkilöstö työskentelee? Missä salassa pidettävät järjestelmät toimivat palautusjakson aikana? Näihin kysymyksiin on vastattava etukäteen, varatilat nimettyinä, varustettuina ja akkreditoituina – ei tunnistettuna mahdollisuuksina, joita tutkitaan tapahtuman jälkeen.

Kryptografinen eheyden tarkistus

Varmuuskopio, joka on vioittunut – joko tallennusmedian vian, varmuuskopiointiagentin ohjelmistovirheen tai tahallisen peukaloinnin vuoksi – ei voi palauttaa järjestelmää. Salassa pidettäville järjestelmille havaitsematon vioittuminen on erityisen vaarallista: palautus, joka näyttää onnistuvan mutta tuottaa hienovaraisesti virheellisen järjestelmätilan, on vaikeampi havaita ja korjata kuin ilmeinen vika.

Salassa pidettävien varmuuskopioiden eheyden tarkistuksen vähimmäistaso on jokaisen varmuuskopiojoukon SHA-256-tiivistäminen heti luonnin jälkeen, tiivisteiden tallentamisella erilliseen, vain lisäystä sallivaan auditointilokiin. Tiiviste on vahvistettava ennen jokaista palautustoimintoa – ei vain verrattuna tallennettuun arvoon, vaan laskettava uudelleen varmuuskopiomedialta ja verrattava. Tämä havaitsee median heikkenemisen, tallennusjärjestelmän virheet ja peukaloinnin.

Tiivisteen vahvistus on välttämätöntä mutta ei riittävää. Ainoa täydellinen eheystesti on palautusharjoitus: liitä varmuuskopio eristettyyn palautusympäristöön, käynnistä järjestelmä ja varmista, että sovellukset käynnistyvät ja data on yhtenäistä. Tämä tavoittaa ongelmat, joita tiivistäminen ei voi: varmuuskopiojoukot, jotka ovat kryptografisesti ehjiä mutta loogisesti epäyhtenäisiä (kesken transaktion otettu tietokannan varmuuskopio, tiedostojärjestelmän varmuuskopio rikkoutuneilla kovilla linkeillä, sovelluksen varmuuskopio, josta puuttuu vaadittu ulkoinen riippuvuus). Korkeimman kriittisyyden järjestelmille palautusharjoitusten tulisi olla neljännesvuosittaisia; kaikille salassa pidettäville järjestelmille vuosittainen on vähimmäishyväksyttävä tahti.

Palautuksen runbookit ja harjoitustahti

Palautuksen runbook on vaiheittainen menettelyasiakirja, joka määrittää jokaisen toimen, joka tarvitaan järjestelmän palauttamiseen varmuuskopiosta toiminnalliseen tilaan. Salassa pidettäville järjestelmille runbookin on katettava: median nouto turvallisesta tallennuksesta (mukaan lukien hallussapitoketjun dokumentointi), salauksenpurkuavainten palautus, fyysisen laitteiston valmistelu ja vahvistus, käyttöjärjestelmän ja perusohjelmiston palautus, sovellusten palautus ja kokoonpanon vahvistus, palautuksen jälkeinen turvavalvontojen vahvistus (sen vahvistaminen, että luokitusmerkinnät, pääsynvalvonnat ja auditointilokitus toimivat oikein) sekä ISSO:n hyväksyntä ennen järjestelmän palauttamista tuotantokäyttöön.

Turvavalvontojen vahvistusvaihe ansaitsee erityishuomion. Palautettu järjestelmä, joka on teknisesti toiminnassa mutta on menettänyt auditointilokituskokoonpanonsa tai palannut kovennusta edeltävään perustasoon, ei ole valmis salassa pidettävään käyttöön. Palautuksen jälkeisen tarkistuslistan on vahvistettava jokainen ATO:n vaatima turvavalvonta, ei vain toiminnallista toimivuutta. Tämä vahvistus vie aikaa – tyypillisesti yhdestä kolmeen tuntia hyvin dokumentoidulle järjestelmälle – ja se on sisällytettävä RTO-laskelmaan, ei käsiteltävä palautuksen jälkeisenä hallinnollisena tehtävänä, joka tapahtuu kellon pysähtymisen jälkeen.

Konttipohjaisille sotilastyökuormille palautusmenettelyjen on käsiteltävä sekä taustainfrastruktuuria (Kubernetes-klusteri ja solmukokoonpano) että sovelluskerrosta. Pysyvien levyniteiden datan palauttaminen palauttamatta oikeaa klusterikokoonpanoa ja turvakäytäntöjä tuottaa järjestelmän, joka käynnistyy mutta ei toimi akkreditoidun mukaisesti. Konttipohjaisten järjestelmien runbookien tulisi määrittää palautustoimintojen tarkka järjestys – ensin klusteri-infrastruktuuri, sitten pysyvä tallennus, sitten sovelluksen käyttöönotto – ja sisältää erityiset vahvistuskomennot jokaiselle vaiheelle.

Vuosittaiset täydet palautusharjoitukset ovat ATO:n ylläpidon vähimmäisvaatimus useimmissa akkreditointikehyksissä. Paras käytäntö tehtävän kannalta olennaisille järjestelmille on puolivuosittainen harjoitus, pöytäharjoituksilla (tabletop) vuorottelevina vuosineljänneksinä tiimin valmiuden ylläpitämiseksi ilman live-palautuksen täyttä resurssikustannusta. Harjoitustulokset on dokumentoitava: todellisuudessa saavutetut RTO ja RPO, poikkeamat runbookista, kohdatut ongelmat ja niiden ratkaisu sekä kaikki toimenpidekohdat, jotka on korjattava ennen seuraavaa harjoitusta.

Yleiset epäonnistumismallit

Organisaatiot, jotka ovat kokeneet salassa pidettäviä DR-epäonnistumisia, liittävät ne useimmiten johonkin neljästä mallista:

Akkreditointivaje. Palautusympäristö on nimetty, mutta sen ATO vanhenee, koska sitä ei koskaan käytetä tuotannossa eikä sitä sisällytetä jatkuvan valvonnan ohjelmaan. Palautushetkellä havaittuna vaje vaatii hätäakkreditointiprosessin, joka kestää päivistä viikkoihin – kaukana mistä tahansa kohtuullisesta RTO:sta.

Avainten säilytyksen epäonnistuminen. Varmuuskopioiden salausavaimet ovat pienen valtuutettujen yksilöiden joukon hallussa. Kun katastrofi iskee, nämä yksilöt eivät ole käytettävissä (he saattavat itse olla häiriön uhreja). Avainten talletusmenettelyt ovat olemassa paperilla mutta niitä ei ole koskaan harjoiteltu, ja talletussijaintiin osoittautuu liittyvän byrokraattinen pääsyvaatimus, jota ei voida täyttää nopeasti hätäolosuhteissa.

Testaamaton runbook. Palautuksen runbook kirjoitettiin, kun järjestelmä otettiin alun perin käyttöön, eikä sitä ole päivitetty järjestelmän kehittyessä. Kahden vuoden korjausten, kokoonpanomuutosten ja sovelluspäivitysten jälkeen runbook viittaa järjestelmäversioihin ja menettelyihin, jotka eivät enää vastaa todellista järjestelmää. Ensimmäinen kerta, kun runbookia harjoitellaan, on todellisen katastrofin aikana.

Logistiikkavaje. Ilmaeristetyissä tai maantieteellisesti hajautetuissa järjestelmissä aikaa, joka tarvitaan varmuuskopiomedian fyysiseen kuljettamiseen toimipisteen ulkopuolisesta tallennuksesta palautustilaan, ei ole sisällytetty RTO-laskelmaan. Ohjelma uskoo, että sillä on neljän tunnin RTO; todellinen RTO on neljä tuntia plus kaksitoista tuntia kuriirikuljetusta – kyky, joka on olemassa paperilla mutta ei käytännössä.