Parhauster a Gwellhau: Yr Adfer Heb Neb yn ei Brofi

Mae pob dangosfwrdd cadwopi yn dangos marciau gwyrdd. Cwblhawyd swyddi, polisi cadw yn cael ei fodloni, storfa yn cael ei ddefnyddio fel y disgwylir. Nid yw unrhyw un o hynny yn dweud wrthych a allwch chi ddod â rheolwr parth yn ôl o fetel noeth mewn llai na phedair awr yn ystod digwyddiad gwirioneddol. Y bwlch rhwng "llwyddodd y cefnwp" a "llwyddodd yr adfer" yw lle mae'r rhan fwyaf o gynlluniau parhad yn methu'n dawel.

Pam mae'r marciad yn dweud celwydd

Mae meddalwedd cadwopi yn adrodd llwyddiant pan fydd yn gorffen ysgrifennu bytes i nod. Nid yw'n gwybod a yw'r bytes hynny yn ddefnyddiol. Gall cefnwp SQL Server gwblhau'n lân ac yn dal i fod yn adferadwy oherwydd bod cadwyn y log trafodion wedi torri tri diwrnod yn gynharach ac nid oedd neb wedi sylwi. Gall llungopiau VM edrych yn iawn yn y consol tra'n bod y sgrifennydd VSS tanodol wedi methu'n dawel y tu mewn i'r OS yr arlwydd, gan gynhyrchu delwedd gyson-crash (nid app-gyson).

Mae gweithredwyr ransomware yn gwybod hyn. Grwpiau sy'n rhedeg palysgrifau Conti-ddull mewn digwyddiadau blaenorol wedi targedu seilwaith cadwopi'n fwriadol — dileu copïau cysgod gyda vssadmin delete shadows /all /quiet, analluogi storeysau Veeam, amgryptio targedau cadwopi seiliedig ar NAS oedd yn cyrraeddadwy dros SMB. Os yw eich cadwopïau'n byw ar yr un segment rhwydwaith â chynhyrchiad gyda chyswllt parth sy'n gallu cyffwrdd â nhw, maent yn darged, nid rhwyd diogelwch.

Adeiladu llawlyfr adfer, nid polisi cadwopi

Mae angen i gynllun parhauster fod â chyfarwyddiadau adfer cam wrth gam wedi'u ysgrifennu ar gyfer rhywun nad yw'r person sy'n ei wneud yn arferol. Ysgrifennwch i lawr:

• Trefn adfer union (rheolwyr parth a DNS yn gyntaf, yna apiau craidd, yna popeth arall)
• Lle mae cyswllt ar gyfer y consol cadwopi os yw eich cloffa prif air hefyd i lawr
• Y gorchymyn adfer penodol neu lwybr consol, nid "defnyddiwch Veeam i adfer y VM"
• Hyd disgwyliedig fesul system, yn seiliedig ar brofion mesuredig gwirioneddol, nid rhifau marchnata gwerthwr

Ar gyfer Veeam Backup & Replication, mae hynny'n golygu dogfennu'r camau gwirioneddol: agorwch y consol, ewch at Backups > Disk, cliciwch ar ddde ar y pwynt adfer, dewiswch Instant VM Recovery neu Full VM Restore yn dibynnu ar senario, a dewis yr allwydd targed gyda digon o allu rhydd. Os yw eich prif ddull croesi hefyd wedi'i gymryd yn ôl, mae angen ail ddull, parhaus ynysu eisoes wedi'i nodi ac wedi'i drwyddedu.

Profi adferion ar amserlen, nid ar ddau awr

Dewiswch dro. Bob mis, adferir un system feidrwol i VLAN ynysig a gwiriwch ei fod yn cychwyn, yn dilysu, ac yn gwasanaethu data yn gywir. Bob chwarter, rhedwch brawf llawn-gwmpas: adferch eich rheolwr parth, eich gweinydd ffeil, a'ch prif gronfa ddata i seilwaith ynysu, yna gadewch i rywun y tu allan i'r tîm cadwopi geisio mewn a thynnu adroddiad.

Ar gyfer cronfeydd data, peidiwch â dim ond adfer y ffeil .bak — gwiriwch hi:

RESTORE VERIFYONLY FROM DISK = 'D:\\Backups\\prod_2024.bak'

Yna yn wir adferch hi i achos prawf ac rhedeg DBCC CHECKDB yn ei erbyn. Gall cefnwp sy'n pasio VERIFYONLY dal i gynnwys llygiad rhesymegol na ddangosir ond pan fyddwch yn ymholi iddo.

Ar gyfer systemau Linux gan ddefnyddio rhywbeth fel Bacula neu restic, profwch y llwybr adfer gwirioneddol:

restic restore latest --target /tmp/restore-test --repo /mnt/backup-repo

Yna gwahanu'r ffeiliau config adferedig yn erbyn cynhyrchiad i gadarnhau nad aeth dim yn dawel i lawr.

Copïau newid-amhosibl a'r rheol 3-2-1-1

Mae'r rheol glasurol 3-2-1 (tri chopïau, dwy fath o gyfrwng, un oddi cartref) angen diweddariad ar gyfer yr oes ransomware: 3-2-1-1, lle mae'r "1" ychwanegol yn gopïau newid-amhosibl neu awyr-gaeedig. Object lock ar storio S3-cyfartal (Wasabi, Backblaze B2, neu AWS S3 gyda Object Lock wedi'i alluogi) atal dileu neu addasu am ffenestr cadw diffiniedig, hyd yn oed gan gyfrif gyda chyswllt gweinyddu. Ffurfweddwch hi gyda:

aws s3api put-object-lock-configuration \
  --bucket backup-vault \
  --object-lock-configuration '{"ObjectLockEnabled":"Enabled","Rule":{"DefaultRetention":{"Mode":"COMPLIANCE","Days":30}}}'

Mod COMPLIANCE yn golygu neb, gan gynnwys y cyfrif gwreiddyn, gall rocio'r cadw neu dileu gwrthrychau'n gynnar. Mae hynny'n bwysig pan mae'r ymosodwr yn admin parth.

Mesur RTO a RPO gyda rhifau go iawn, nid dyfaliadau

Mae Recovery Time Objective a Recovery Point Objective yn swnio fel ymarferion papur hyd nes y bydd gweithredwr yn gofyn "faint o ddata yr ydym yn ei golli a faint o amser yr ydym i lawr." Amser eich tri phrawf adfer diwethaf. Os yw eich targed RPO yn awr ond dim ond pob chwe rhediad eich swydd cadwopi, mae gennych bwlch dogfennedig, ac mae'n well ffeindio'r bwlch hwnnw mewn ymarfer bwrdd nag yn ystod digwyddiad amgryptio gwirioneddol am 2 y.h. ar ddydd Sadwrn.

Rhedeg y prawf, ysgrifennwch i lawr yr amser cloc gwirioneddol, a'i gymharu â'r hyn y darostyngwyd gennych yn y ddogfen adferiad niweidiol. Y gwahaniaeth rhwng y ddau rifau hynny yw gwir gyflwr eich cynllun parhad.

Ar gyfer rhagor ar galedwch systemau rydych chi'n eu diogelu ac adeiladu llawfocau ymateb digwyddiad, gwiriwch yr is-adranau Blue Team a Digital Forensics cysylltiedig ar Korra Studio.