Tukuyin kung ano ang kasama sa “website”
Magsimula sa imbentaryo ng serbisyo. Para sa bawat site, portal, tindahan, o kampanya, itala ang business owner, technical owner, hosting account, control ng domain at DNS, repository, mga store ng content at media, integrasyon, at mahahalagang kredensyal. Markahan kung ano ang maaaring mabuo muli mula sa version control at ano ang naglalaman ng unique na mga rekord.
Isama ang konfigurasyon nang may layunin: mga redirect, CDN o firewall settings, naka-schedule na jobs, template, at mga infrastructure-as-code na file. Huwag kopyahin ang live secrets sa pangkalahatang manifest; ituro sa halip sa inaprubahang secrets system at emergency-access process. Ipinapakita ng dokumentasyon ng WordPress ang karaniwang puwang: karaniwang kailangan ng site ang parehong mga file at isang hiwalay na database.
Tukuyin ang pinakamaliit na ligtas na bersyon na makapagbibigay ng mahahalagang impormasyon o transaksyon.
Bigyan ang magkatugmang database, file, media, at eksport ng konfigurasyon ng isang timestamp o version label.
Itakda ang dalas at retention mula sa pagtanggap ng negosyo
Pumili ng dalas ayon sa rate at halaga ng pagbabago. Isulat ang RPO sa payak na wika, pagkatapos siyasatin na bawat unique na store ay nakukunan nang sapat na madalas. Ang nightly file copy ay hindi makakatugon sa apat-na-oras na RPO para sa mabilis magbago na database.
Itakda ang RTO nang hiwalay. Isama ang pag-apruba, malinis na infrastructure, restorasyon, validation, pagbabago sa traffic, at internal na komunikasyon. Sukatin ito sa drill sa halip na umasa sa claim ng vendor. Panatilihin ang mas matanda pang mga punto nang sapat na matagal para marating bago ang isang error o naantalang pagtuklas, at repasuhin ang retention kasama ang privacy, records, o legal na espesyalista kapag nangangailangan ang data.
Ihambing ang pagitan ng kumpletong recovery points sa RPO ng bawat serbisyo.
Siguruhing ang awtorisadong tao ay makakakita ng mas lumang aprubadong restore point.
Ihiwalay at protektahan ang mga kopya ng pagbawi
Gumamit ng maraming kopya sa iba't ibang lokasyon o serbisyo upang ang isang account, lokal na pangyayari, o pagkakamali ay hindi mag-alis ng bawat opsyon. Inirerekomenda ng CISA ang regular na automated backups, isang off-site copy, encryption, at offline copies. Nagpapayo ang NCSC laban sa mga permanently connected backup device at inirerekomenda ang higit sa isang solusyon o lokasyon ng backup.
Protektahan ang backup administration gamit ang least privilege, multi-factor authentication kapag sinusuportahan, magkakahiwalay na admin account, at regular na review ng access. Gumamit ng deletion protection, version history, o immutable storage lamang pagkatapos maunawaan ang gastusin at pag-uugali sa recovery. I-encrypt ang naka-store na data at subukan ang custody ng mga susi. Ang encryption na walang maabot na susi ay hindi magagamit; ang malawakang ibinahaging access ay nagpapahina sa bawat kopya.
Dapat magkaroon ang kopya ng makabuluhang ibang failure mode kumpara sa production.
Itala kung sino ang makakabasa, makakabago, makakabura, at makaka-restore ng backups; alisin ang luma o hindi na ginagamit na access.
Isulat ang runbook ng pagbawi at magtalaga ng awtoridad
Ang runbook ay ang nasubok na pamamaraan ng pagbawi. Panatilihin ang isang kopya na maabot kahit wala ang apektadong site, production identity provider, o normal na chat system. Isama ang mga contact at alternates, awtoridad, prayoridad ng sistema, lokasyon ng backup, mga prerekwisito, pagkakasunod-sunod ng restore, validation checks, at mga stop condition.
Pangalanan ang isang accountable recovery owner at alternatibo para sa bawat kritikal na serbisyo. Tukuyin kung sino ang nag-aapruba ng production restoration, pagbabago sa DNS, at business-data validation. Kung may payment-card data, sensitibong personal na data, o nare-regulate na rekord, kumuha ng kwalipikadong security, privacy, legal, at kung naaangkop PCI review bago magpasiya kung ano ang iibahin, ipapaalam, o ire-restore.
Itala ang napiling restore point, taong nag-apruba, mga sistemang na-touched, resulta ng validation, at mga eksepsiyon.
Idokumento ang kontroladong emergency access; huwag umasa sa device o memorya ng isang empleyado lamang.
Mag-restore nang ligtas pagkatapos ng pinaghihinalaang kompromiso
Huwag awtomatikong i-overwrite ang production gamit ang pinakabagong kopya kapag posibleng may hindi-awtorisadong access, malware, o kahina-hinalang pagbura. Sundin ang incident process, tasahin kung aling account at backup ang maaaring naapektuhan, pumili ng punto mula sa ebidensya, at buuin o ihiwalay ang recovery environment bago ito i-reconnect.
Ipinapayo ng CISA ang pagbawi ayon sa prayoridad ng kritikal na serbisyo at nagbabala laban sa muling pag-infect ng malilinis na sistema. Nirerekomenda ng NCSC ang pagkokonekta ng backups lamang sa kilalang-malilinis na device at pag-scan bago i-restore. Pinapababa ng mga hakbang na ito ang panganib, ngunit hindi ginagarantiyahan ang kalinisan. I-escalate sa kwalipikadong incident-response na tulong kapag kailangan ang imbestigasyon, pagpapanatili ng ebidensya, o tungkulin sa pag-notify.
I-restore ang may pinakamataas na prayoridad na serbisyo sa malinis na infrastructure, i-validate ito, at pagkatapos ay ipagpatuloy ayon sa dependency order.
Suriin ang user journeys, data, jobs, integrasyon, administration, logging, at bagong backup coverage.
Gamitin ang mga drill bilang katibayan at input sa remediasyon
Magsagawa ng partial restores, isolated full rebuilds, dependency-loss exercises, o tabletop decisions ayon sa panganib. Magsimula sa isang ligtas at makahulugang test at dagdagan ang realismo habang tumatagal. Inirerekomenda ng CISA ang full at partial restore tests; nirerekomenda ng NCSC ang mga exercise para linawin ang mga papel, responsibilidad ng third party, at prayoridad.
Sukatin ang edad ng recovery point laban sa RPO at ang lumipas na oras ng pagbawi laban sa RTO. I-record ang set identifier, mga kalahok, resulta ng validation, mga nabigong hakbang, at isang may-ari para sa bawat pag-aayos. Muling subukan pagkatapos isara ang mga puwang at pagkatapos ng materyal na pagbabago sa platform, identity, database, o provider. Maaaring mag-organisa ang SIU ng proaktibong preventive remediation na ito; hindi ito isang backup system o live monitoring service.
Panatilihin ang maikling rekord kung ano ang na-restore, saan, ano ang pumasa, ano ang nabigo, at sino ang tumanggap nito.
Ulitin ang naka-target na testing pagkatapos ng materyal na pagbabago sa arkitektura o supplier.