Varukoopiate taastetest, mis tasub teha enne lunavara rünnakut

Enne kui lunavara teie varukoopiaid proovile paneb, tehke ise läbi kolm kontrolli: kas keegi saab neid kustutada, kas varastatud administraatorikonto pääseb neile ligi ja kui kaua päris taastamine aega võtab võrreldes sellega, mida ettevõte taluda suudab.

NCSC juhend pahavara ja lunavara rünnakute leevendamiseks on otsekohene. Ajakohased varukoopiad on lunavararünnakust taastumise kõige tõhusam viis, lunavara võtab need aktiivselt sihikule, et maksmise tõenäosust suurendada, ning ründajad on enne rünnaku käivitamist kopeeritud faile hävitanud või taastamist häirinud. Seega testige varukoopiaid nii, nagu seda teeks ründaja.

Test 1: proovige oma varukoopia kustutada

Siinsed näited põhinevad Amazon S3 Object Lockil. Muude lahenduste puhul leidke oma varundustootest samaväärne muutumatuse (immutability) või säilitustähtaja lukk. Kontrollige, et see on sisse lülitatud, milline on säilitusperiood ja kes saab seda lühendada või eemaldada. Seejärel proovige teha jäävkustutamist tavakasutajana, oma kõige privilegeeritumama varundusadministraatorina ja kontoga, mille ründaja võiks tõenäoliselt üle võtta. Pange kirja, kellel see õnnestub.

S3 puhul töötage proovikorvis (scratch bucket). Object Lock töötab ainult korvides, kus on S3 Versioning sisse lülitatud, nii et kontrollige see kõigepealt üle. Kasutage governance-režiimi, mida AWS kirjeldab kui võimalust säilitusseadeid testida enne compliance-režiimi säilitusperioodi loomist.

Ärge kunagi rakendage proovikorvis compliance-režiimi. Compliance-režiimis ei saa säilitusrežiimi muuta ega perioodi lühendada ning ainus viis compliance-lukuga objekti enneaegselt kustutada on kustutada seotud AWS-i konto.

Tehke need katsed nii konsooli kaudu kui ka API või CLI kaudu ning võrrelge tulemusi:

Teine rida ei ole tõrge: lukustatud versioon jääb alles, sest säilitusperioodid ei takista uute versioonide või delete markerite loomist. Kolmas rida on see, mis peaks muret tekitama. S3 konsool lisab vaikimisi päise x-amz-bypass-governance-retention:true, mistõttu saab igaüks, kellel on see õigus, governance-lukuga objektid mõne klikiga kustutada.

Seejärel saatke sama jäävkustutamise päring samalt kasutajalt API või CLI kaudu ilma selle päiseta. AWS nõuab seda päist igas päringus, mis governance-režiimi tühistab, seega peaks tulemuseks olema Access Denied. Kui kustutamine õnnestub, kontrollige korvi säilitusrežiimi ja objektiversiooni lukuseadeid.

Seejärel auditeerige, kes saab luku tühistada

Tehke nimekiri kõigist põhimõtetest (principal), mille poliitikad lubavad s3:BypassGovernanceRetention, sh rollid, grupid ja inline-poliitikad. Tehke sama õiguse s3:PutObjectLegalHold kohta: legal holdil puudub aegumistähtaeg ja iga kasutaja, kellel on see õigus, saab hoidmisi vabalt seada ja eemaldada.

Eemaldage mõlemad õigused kontodelt, mille ründaja võiks tõenäoliselt üle võtta. Andmete puhul, mida te kaotada ei tohi, kaaluge compliance-režiimi koos teadlikult valitud säilitusperioodiga.

Test 2: proovige varukoopiale ligi pääseda valede volitustega

Muutumatu salvestus ei aita, kui ründaja kontrollib seda haldavat konsooli. Proovige varundusekonsooli ja salvestusse sisse logida domeeniadministraatori, backup operator'i konto ja pilve IAM-kasutajaga ning kontrollige, kas igaüks neist saab andmeid kustutada või säilitusseadeid muuta.

NCSC juhend soovitab varunduskontode jaoks järgmisi kaitsemeetmeid:

• Privileged Access Workstations ja riistvaralised tulemüürid, mis jõustavad IP allow listing'u.
• MFA, kusjuures MFA-meetod ei ole paigaldatud seadmesse, millega varukoopiaid hallatakse.
• Privileged Access Management, nii et administraatorid ei pääse väärtuslikele varundussüsteemidele otse ligi.

Varukoopia-kettad ja USB-pulgad ei tohi olla püsivalt teie võrku ühendatud ning varundustooteid tuleb paigata. Pilveteenuse puhul veenduge, et eelmised versioonid on kohese kustutamise eest kaitstud ja et saate neile taastada, sest teenused sünkroniseerivad sageli kohe pärast seda, kui teie failid on asendatud krüpteeritud koopiatega.

Test 3: taastage midagi, sekundikell käes

Valige süsteem, mida ettevõte hakkaks ühe päeva jooksul taga igatsema, ja taastage see varukoopiast puhtasse isoleeritud keskkonda, et taastatud nakkus ei pääseks tootmissüsteemidesse. Pange kirja kulunud aeg, kes mida tegi ja iga koht, kus keegi pidi otsima parooli, litsentsivõtit või dokumenti, mis asub serverites, mida te taastate.

Kui taastamine katkeb poole peal, pange kirja samm, kulunud aeg, põhjus ja lahendus, seejärel alustage sellest sammust uuesti ja logige ülejäänud aeg eraldi. Hoidke sammud käikude vahel identsed, et tulemused oleksid võrreldavad.

Enne taastamist ühendage varukoopiad ainult teadaolevalt puhaste seadmetega ja skaneerige need enne failide taastamist pahavara suhtes. Lunavara võib olla varukoopiatesse jõudnud enne, kui see avastati, seega ei pruugi puhtana tunduv taastepunkt puhas olla.

Võrrelge mõõdetud aega sellega, mida ettevõtte sõnul on võimalik taluda. Küsige see number süsteemi omanikult enne testi, et te ei kohandaks eesmärki tulemuse järgi. Lunavarajärgne täielik taastamine, kui see on üldse võimalik, võib võtta mitu nädalat, seega käsitlege ühe süsteemi taastamisaega alampiirina.

Töötage paberil läbi, mis juhtub, kui nii kohapealsed süsteemid kui ka pilve varundusserverid on kasutuskõlbmatud ja te peate süsteemid taastama offline-varukoopiatest, ning kuidas hoiate kriitilised äriteenused töös. Kontrollige, et käsiraamatud, kontrollnimekirjad ja kontaktandmed asuvad kuskil, kuhu pääsete ligi ilma oma arvutisüsteemideta. Meie intsidentidele reageerimise teenus hõlmab seda laadi harjutusi, kui soovite välist pilku.

Kust alustada

1. Valige üks ärikriitiline süsteem ja küsige selle omanikult, kui kaua see võib maas olla. Kirjutage number esmalt üles.
2. Looge S3 proovikorv, kus on versioonihaldus ja Object Lock governance-režiimis, mitte kunagi compliance-režiimis. Proovige teha jäävkustutamist ja lihtkustutamist ning pange vastused kirja.
3. Korrake jäävkustutamist kasutajana, kellel on s3:BypassGovernanceRetention, nii konsoolist kui ka API või CLI kaudu ilma möödaviigu päiseta. Seejärel tehke nimekiri kõigist selle õiguse ja s3:PutObjectLegalHold omajatest ning eemaldage õigus neilt, kes seda ei vaja.
4. Proovige varundusekonsooli sisse logida domeeniadministraatori, backup operator'i ja pilve IAM-kasutajaga. Kui mõni sisselogimine õnnestus, planeerige MFA eraldi seadmes ja IP allow listing. Veenduge, et olemas on offline-koopia, mis ei ole püsivalt ühendatud ja millest on varem taastatud.
5. Taastage valitud süsteem skaneeritud varukoopiast isoleeritud keskkonda, mõõtes iga sammu aega, ja võrrelge tulemust sammus 1 saadud numbriga.
6. Parandage suurim lünk ja korrake teste alati, kui varunduse ülesehitus muutub.