ბევრ კომპანიაში მონაცემთა დაცვის საკითხზე პირველი პასუხია:
„Backup გვაქვს.“
ეს კარგია – მაგრამ არასაკმარისი.
Backup პირველ რიგში არის მონაცემების აღდგენის მექანიზმი. ის გეხმარებათ უკვე მომხდარი ინციდენტის შემდეგ დაკარგული ან დაზიანებული მონაცემების დაბრუნებაში.
კიბერუსაფრთხოება კი გაცილებით ფართო პროცესია. მისი მიზანია შეამციროს იმის ალბათობა, რომ თავდამსხმელმა საერთოდ მიიღოს წვდომა თქვენს სისტემებზე, მომხმარებლების ანგარიშებზე, სერვერებზე და მონაცემებზე.
სწორედ ამიტომ:
Backup ≠ უსაფრთხოება.
უფრო სწორი ფორმულაა:
Cybersecurity + Secure Backup + Tested Recovery = ბიზნესის რეალური მდგრადობა.
CISA რეკომენდაციას აძლევს ორგანიზაციებს კრიტიკული მონაცემების Backup შეინახონ offline და დაშიფრულ გარემოში და რეგულარულად შეამოწმონ როგორც Backup-ის მთლიანობა, ისე აღდგენის შესაძლებლობა. ამის ერთ-ერთი მიზეზია ის, რომ ransomware-ის ნაწილი აქტიურად ცდილობს ქსელში ხელმისაწვდომი Backup-ების აღმოჩენას, წაშლას ან დაშიფვრას.
რატომ ვერ ცვლის Backup კიბერუსაფრთხოებას?
წარმოიდგინეთ კომპანია, რომელსაც ყოველ ღამე ავტომატურად ეშვება Backup.
ერთი შეხედვით ყველაფერი სწორად არის მოწყობილი.
მაგრამ თანამშრომლის ანგარიში phishing შეტევის შედეგად კომპრომეტირდა. თავდამსხმელი იღებს სისტემაზე წვდომას, მოძრაობს კომპანიის ქსელში, იპარავს მომხმარებლების მონაცემებს და ბოლოს შიფრავს სერვერებს.
ამ შემთხვევაში Backup შეიძლება დაგეხმაროთ სერვერის აღდგენაში.
მაგრამ Backup ვერ გააუქმებს იმ ფაქტს, რომ თავდამსხმელს უკვე ჰქონდა წვდომა სისტემაზე.
ვერ დააბრუნებს უკვე მოპარულ მონაცემებს.
ვერ შეცვლის კომპრომეტირებულ პაროლებს.
ვერ დახურავს დაუცველ სერვერს.
ვერ შეაჩერებს იმავე თავდამსხმელს ხელახლა დაბრუნებისგან.
თანამედროვე ransomware შეტევები ხშირად მხოლოდ მონაცემების დაშიფვრით აღარ შემოიფარგლება. CISA-ს მიერ აღწერილ ინციდენტებში თავდამსხმელები მონაცემებს ჯერ სისტემიდან იღებენ და შემდეგ შიფრავენ ე.წ. double extortion მოდელი. ამიტომ Backup შეიძლება დაგეხმაროთ availability-ის, ანუ მონაცემების ხელმისაწვდომობის აღდგენაში, მაგრამ ვერ უზრუნველყოფს მონაცემების confidentiality-ს ან მთლიან კიბერუსაფრთხოებას.
კიდევ ერთი პრობლემა: რა მოხდება, თუ ransomware Backup-მდეც მივიდა?
ერთ-ერთი ყველაზე გავრცელებული შეცდომაა Backup-ის შენახვა იმავე გარემოში, სადაც ძირითადი მონაცემები ინახება.
მაგალითად:
სამუშაო კომპიუტერები დაკავშირებულია ცენტრალურ სერვერთან.
სერვერი დაკავშირებულია NAS მოწყობილობასთან.
NAS-ზე ინახება Backup.
ყველა მათგანის ადმინისტრირებისთვის კი ერთი და იგივე ან ერთმანეთთან დაკავშირებული credentials გამოიყენება.
თუ თავდამსხმელი საკმარისად მაღალი დონის წვდომას მიიღებს, შესაძლოა ძირითადი მონაცემების გარდა Backup-იც წაშალოს ან დაშიფროს.
FTC რეკომენდაციას აძლევს ბიზნესებს Backup შეინახონ ქსელისგან განცალკევებით და Backup-ისთვის გამოიყენონ ცალკე credentials. CISA ასევე რეკომენდაციას უწევს offline, encrypted და, შესაძლებლობის შემთხვევაში, immutable Backup-ს.
სწორედ ამიტომ ერთი NAS, ერთი VPS snapshot ან ერთი Cloud Drive ავტომატურად სრული Backup სტრატეგია არ არის.
Cloud-ში შენახული ფაილი ყოველთვის Backup არ არის
აქ კიდევ ერთი მნიშვნელოვანი განსხვავებაა:
Cloud Storage / Sync და Cloud Backup ერთი და იგივე არ არის.
Google Drive, OneDrive, Dropbox და სხვა სინქრონიზაციის სისტემები ძალიან სასარგებლოა ყოველდღიური მუშაობისთვის, მაგრამ მათი ძირითადი დანიშნულება ხშირად ფაილების ხელმისაწვდომობა და სინქრონიზაციაა.
თუ ფაილის წაშლა ან ცვლილება ავტომატურად სინქრონიზდება სხვა მოწყობილობებზე, შეცდომა ან მავნე ცვლილებაც შეიძლება გავრცელდეს.
ამიტომ ბიზნესისთვის სასურველია Cloud გარემოში გამოყენებული იყოს ისეთი მექანიზმებიც, როგორიცაა:
versioning, retention, independent backup, delete protection და immutable/object lock storage.
CISA კონკრეტულად ურჩევს ორგანიზაციებს Cloud საცავებში გამოიყენონ delete protection ან object lock და, სადაც შესაძლებელია, version control, რათა შესაძლებელი იყოს ფაილის წინა ვერსიის აღდგენა შემთხვევითი ან მავნე ცვლილების შემდეგ.
Cloud ინფრასტრუქტურაში ასევე მნიშვნელოვანია shared responsibility model-ის გაგება: Cloud პროვაიდერის ინფრასტრუქტურის საიმედოობა ავტომატურად არ ნიშნავს, რომ თქვენი კონკრეტული მონაცემების Backup სტრატეგიაც სწორად არის აწყობილი.
რა არის 3-2-1 Backup სტრატეგია?
Backup არქიტექტურის ერთ-ერთი ყველაზე ცნობილი მიდგომაა 3-2-1 პრინციპი.
იდეა მარტივია:
- გქონდეთ მონაცემების მინიმუმ 3 ასლი სამუშაო მონაცემები და მინიმუმ ორი Backup;
- მონაცემები ინახებოდეს მინიმუმ 2 განსხვავებულ ტიპის საცავზე ან გარემოში;
- მინიმუმ 1 ასლი მდებარეობდეს ძირითადი ინფრასტრუქტურისგან განცალკევებით off-site ან offline გარემოში.
CISA-ს მიერ გამოქვეყნებულ რეკომენდაციებშიც 3-2-1 მიდგომა წარმოდგენილია ransomware-ისგან აღდგენის ერთ-ერთ პრაქტიკულ სტრატეგიად.
მაგალითად, მცირე ან საშუალო ბიზნესისთვის ეს შეიძლება გამოიყურებოდეს ასე:
Primary: კომპანიის სერვერი ან Cloud ინფრასტრუქტურა.
Backup #1 – Online: დამოუკიდებელი Cloud Backup Storage.
Backup #2 – Offline/Off-site: დაშიფრული გარე დისკი ან სხვა საცავი, რომელიც მუდმივად არ არის დაკავშირებული კომპანიის ქსელთან.
ამგვარად ერთი ინციდენტის შედეგად სამივე ასლის ერთდროულად დაკარგვის ალბათობა მნიშვნელოვნად მცირდება.
რატომ გვჭირდება ერთდროულად Online და Offline Backup?
ორივე განსხვავებულ ამოცანას ასრულებს.
Online Backup – სწრაფი აღდგენისთვის
Online Backup მუდმივად ან პერიოდულად ხელმისაწვდომია ავტომატიზებული სისტემისთვის.
მისი მთავარი უპირატესობა არის სისწრაფე.
თუ თანამშრომელმა შემთხვევით წაშალა ფაილი, სერვერზე მოხდა ტექნიკური პრობლემა ან ბოლო ვერსიის დაბრუნება გახდა საჭირო, Online Backup-იდან Restore ხშირ შემთხვევაში სწრაფად შეიძლება განხორციელდეს.
მაგრამ რადგან ეს საცავი ინტერნეტით ან ქსელით ხელმისაწვდომია, მისი დაცვაც აუცილებელია.
საჭიროა დამოუკიდებელი ადმინისტრაციული ანგარიში, MFA, მინიმალური უფლებები, დაშიფვრა, მონიტორინგი, versioning და შესაძლებლობის შემთხვევაში immutable retention.
Offline Backup – ბოლო დაცვის ფენა
Offline Backup ქსელთან მუდმივად დაკავშირებული არ არის.
მაგალითად, გარე დისკი გამოიყენება Backup-ის შესაქმნელად და დასრულების შემდეგ მოწყობილობა ითიშება და უსაფრთხო ადგილზე ინახება.
CISA პირდაპირ რეკომენდაციას აძლევს მომხმარებლებს გარე Backup Drive არ დატოვონ მუდმივად კომპიუტერთან დაკავშირებული, რადგან ransomware-ს შესაძლოა მასზეც მიუწვდებოდეს ხელი.
Offline Backup განსაკუთრებით მნიშვნელოვანია იმ სცენარში, როდესაც თავდამსხმელი უკვე ადმინისტრატორის დონეზე აკონტროლებს კომპანიის ინფრასტრუქტურას.
Off-site და Offline ერთი და იგივე არ არის
ეს ორი ტერმინიც ხშირად ერთმანეთში ერევა.
Off-site Backup ნიშნავს, რომ მონაცემის ასლი სხვა ფიზიკურ ან ლოგიკურ ლოკაციაშია მოთავსებული.
მაგალითად, თქვენი მთავარი სერვერი თბილისშია, Backup კი სხვა Datacenter-ში ან Cloud პროვაიდერთან ინახება.
Offline Backup ნიშნავს, რომ საცავი აქტიურად დაკავშირებული არ არის ქსელთან.
Backup შეიძლება ერთდროულად იყოს offline და off-site, რაც მაღალი კრიტიკულობის მონაცემებისთვის განსაკუთრებით ძლიერი კომბინაციაა.
FTC ასევე აღნიშნავს, რომ Backup-ის ადგილმდებარეობის შერჩევას ყურადღება უნდა მიექცეს: იმავე ოფისში შენახულმა ასლმა შესაძლოა ვერ დაგიცვათ ხანძრის, დატბორვის, ქურდობის ან სხვა ფიზიკური ინციდენტის შემთხვევაში.
Backup-ის არსებობა საკმარისი არ არის Restore უნდა მუშაობდეს
ერთ-ერთი ყველაზე სახიფათო ფრაზაა:
„Backup წარმატებით დასრულდა.“
ამ შეტყობინებას მხოლოდ ის შეუძლია დაგიდასტუროთ, რომ Backup პროგრამამ პროცესი წარმატებულად მონიშნა.
ის ჯერ კიდევ არ პასუხობს ყველაზე მნიშვნელოვან კითხვას:
შეგიძლიათ მონაცემების რეალურად აღდგენა?
Backup შეიძლება არსებობდეს, მაგრამ იყოს დაზიანებული.
შეიძლება მნიშვნელოვანი მონაცემთა ბაზა საერთოდ არ შედიოდეს Backup-ში.
შეიძლება encryption key დაკარგული იყოს.
შეიძლება Restore-ის დროს საჭირო credentials აღარ არსებობდეს.
შეიძლება სერვერის სრული Backup გაქვთ, მაგრამ ახალი ინფრასტრუქტურისთვის საჭირო configuration, secrets, applications ან dependencies არ იყოს შენახული.
NIST-ის Backup რეკომენდაციების ერთ-ერთი ძირითადი პრინციპია არა მხოლოდ Backup-ის შექმნა, არამედ მისი maintenance და testing. 2026 წელს გამოქვეყნებული NIST SP 1339-იც ხაზს უსვამს Backup-ების რეგულარულ შექმნას, ტესტირებას და recovery exercises-ის დროს მათ გადამოწმებას.
სხვა სიტყვებით:
Backup, რომელიც არასდროს დაგიტესტავთ, მხოლოდ ვარაუდია.
რა უნდა მოწმდებოდეს Restore Test-ის დროს?
სწორი Restore Test მხოლოდ იმის შემოწმება არ არის, გაიხსნა თუ არა ZIP ფაილი.
უნდა დადასტურდეს, რომ მონაცემების რეალურად დაბრუნება შესაძლებელია დამოუკიდებელ ან სუფთა გარემოში.
მაგალითად, თუ ბიზნესს WordPress, CRM, ERP ან სხვა Web Application აქვს, მხოლოდ ფაილების Backup ხშირად საკმარისი არ იქნება.
შესაძლოა საჭირო იყოს:
Database
Application files
Uploads / documents
Configuration
Environment settings
DNS ინფორმაცია
SSL/TLS configuration
Server configuration
Application dependencies
Recovery credentials
და სხვა კომპონენტები.
NIST ხაზს უსვამს იმასაც, რომ აღდგენილი მონაცემები უნდა იყოს არა მხოლოდ ხელმისაწვდომი, არამედ ზუსტი, სრული და malware-ისგან თავისუფალი.
სწორედ ამიტომ Restore პროცედურა წინასწარ უნდა იყოს დოკუმენტირებული.
RPO და RTO – ორი კითხვა, რომელიც ყველა ბიზნესმა უნდა დასვას
Backup-ის სიხშირე შემთხვევით არ უნდა შეირჩეს.
ამისთვის IT და Business Continuity პრაქტიკაში გამოიყენება ორი მნიშვნელოვანი მაჩვენებელი.
RPO – Recovery Point Objective
RPO პასუხობს კითხვას:
რამდენი მონაცემის დაკარგვა შეგვიძლია მივიღოთ?
თუ Backup დღეში ერთხელ კეთდება და ავარია Backup-ის შექმნიდან 23 საათის შემდეგ მოხდა, შესაძლოა თითქმის ერთი დღის მონაცემები დაიკარგოს.
თუ კომპანიისთვის ერთი დღის შეკვეთების, ტრანზაქციების ან მომხმარებლის ინფორმაციის დაკარგვა მიუღებელია, Backup უფრო ხშირად უნდა შეიქმნას.
NIST RPO-ს განსაზღვრავს როგორც იმ დროის წერტილს, რომელამდეც ორგანიზაციას მონაცემების უკან დაბრუნება უნდა შეეძლოს ბოლო ხელმისაწვდომი Backup-ის მიხედვით.
RTO – Recovery Time Objective
RTO პასუხობს სხვა კითხვას:
რამდენ ხანში უნდა დაბრუნდეს სისტემა მუშაობაში?
Backup შეიძლება იდეალური იყოს, მაგრამ თუ მისი Restore 48 საათს მოითხოვს და ბიზნესს მაქსიმუმ ოთხსაათიანი შეფერხების ატანა შეუძლია, არქიტექტურა მოთხოვნას ვერ აკმაყოფილებს.
NIST-ის მიხედვით, RTO განსაზღვრავს მაქსიმალურ მისაღებ პერიოდს, რომლის განმავლობაშიც კონკრეტული IT რესურსი შეიძლება მიუწვდომელი იყოს ბიზნესისთვის მიუღებელი ზიანის გარეშე.
ამიტომ Backup სტრატეგია ტექნიკური საკითხი კი არა, ბიზნეს გადაწყვეტილებაცაა.
Backup თვითონაც უნდა იყოს დაცული
Backup ხშირად შეიცავს კომპანიის ყველაზე მნიშვნელოვან ინფორმაციას.
CRM-ის მომხმარებლები.
ფინანსური დოკუმენტები.
თანამშრომლების ინფორმაცია.
Database-ები.
კონტრაქტები.
Email.
პროექტები.
ზოგჯერ credentials და configuration files-იც.
ამიტომ Backup Storage-ზე წვდომის მოპოვება თავდამსხმელისთვის ისეთივე ღირებულია, როგორც Production Server-ზე წვდომა.
ეფექტური Backup არქიტექტურა შესაბამისად უნდა მოიცავდეს:
Encryption at rest – მონაცემი დაშიფრული უნდა იყოს საცავში.
Encryption in transit – Backup-ის გადაცემაც დაცული არხით უნდა ხდებოდეს.
MFA – განსაკუთრებით ადმინისტრაციულ ანგარიშებზე.
Separate Credentials – Backup სისტემისთვის სასურველია Production გარემოსგან დამოუკიდებელი ანგარიშები.
Least Privilege – მომხმარებელს და სერვისს მხოლოდ ის წვდომა უნდა ჰქონდეს, რაც რეალურად სჭირდება.
Immutability / Object Lock – განსაზღვრული პერიოდის განმავლობაში Backup-ის ცვლილების ან წაშლის შეზღუდვა.
Logging & Alerts – Backup-ის წაშლის, შეცვლის ან უჩვეულო ადმინისტრაციული მოქმედების გამოვლენა.
Versioning – მონაცემის რამდენიმე ისტორიული ვერსიის შენახვა.
FTC ბიზნესებს ასევე ურჩევს sensitive ინფორმაციისა და Backup media-ს დაშიფვრას, ძლიერი authentication-ის გამოყენებას და MFA-ს დანერგვას.
Immutable Backup – რატომ გახდა ის განსაკუთრებით მნიშვნელოვანი?
Immutable ნიშნავს მონაცემს, რომლის შეცვლა ან წაშლა განსაზღვრული პერიოდის განმავლობაში შეუძლებელია ან მკაცრად არის შეზღუდული.
მაგალითად, ორგანიზაციას შეიძლება ჰქონდეს ყოველდღიური Backup, რომელიც 30 დღის განმავლობაში ვერ შეიცვლება.
თუ თავდამსხმელი ადმინისტრატორის ანგარიშს დაეუფლა და Production მონაცემები დაშიფრა, მისი შემდეგი ნაბიჯი ხშირად Backup-ის განადგურების მცდელობაა.
თუ Backup ჩვეულებრივი writable storage-ია, ეს შეიძლება შესაძლებელი გახდეს.
Immutable Storage დამატებით ბარიერს ქმნის.
CISA რეკომენდაციას აძლევს ორგანიზაციებს გამოიყენონ immutable Backup და Cloud Storage-ის შემთხვევაში delete protection ან object lock, სადაც ეს ტექნიკურად შესაძლებელია.
თუმცა immutable Backup არ ნიშნავს, რომ უსაფრთხოების სხვა კონტროლები აღარ არის საჭირო. არასწორი retention policy, credential compromise ან configuration error კვლავ პრობლემად რჩება.
Backup ვერ ჩაანაცვლებს Endpoint, Network და Account Security-ს
ძლიერი Backup არქიტექტურა მხოლოდ ერთ ფენას წარმოადგენს.
ბიზნესის მონაცემების რეალური დაცვა ასევე მოითხოვს სისტემებისა და პროგრამული უზრუნველყოფის დროულ განახლებას, MFA-ს, endpoint protection-ს, წვდომების კონტროლს, ქსელის სეგმენტაციას, vulnerability management-ს, logging-სა და monitoring-ს, phishing-ის წინააღმდეგ თანამშრომლების მომზადებას და Incident Response Plan-ს.
FTC სწორედ ასეთ მრავალფენიან მიდგომას ურჩევს მცირე ბიზნესებს software updates, data backups, encryption, MFA, access control, თანამშრომლების ტრენინგი და წინასწარ მომზადებული incident response/recovery გეგმები ერთმანეთის შემცვლელი კი არა, ერთმანეთის შემავსებელი კონტროლებია.
Backup გეხმარებათ მაშინ, როდესაც დაცვამ ვერ შეაჩერა ინციდენტი.
Security Controls კი ამცირებს იმის ალბათობას, რომ Backup-ის გამოყენება საერთოდ დაგჭირდეთ.
რა უნდა ჰქონდეს ბიზნესს მინიმუმ?
მცირე და საშუალო ბიზნესისთვის პრაქტიკული მინიმალური მოდელი შეიძლება იყოს:
- ავტომატური, რეგულარული Backup კრიტიკული სისტემებისთვის;
- მინიმუმ ორი დამატებითი ასლი 3-2-1 მიდგომით;
- დამოუკიდებელი Cloud/Off-site Backup;
- Offline ან Immutable Backup კრიტიკული მონაცემებისთვის;
- Backup Storage-ის დაშიფვრა;
- ცალკე Backup Credentials და MFA;
- Versioning და შესაბამისი Retention Policy;
- Backup Job Monitoring და წარუმატებლობაზე Alert;
- პერიოდული Restore Test;
- დოკუმენტირებული RPO და RTO;
- Incident Response და Disaster Recovery პროცედურა;
- კრიტიკული სისტემების, მონაცემებისა და აღდგენის პრიორიტეტების წინასწარი განსაზღვრა.
ყველა ბიზნესისთვის ერთი და იგივე Backup Frequency ან Retention Period სწორი ვერ იქნება. ეს უნდა განისაზღვროს მონაცემების მნიშვნელობის, ცვლილების სიხშირის, კანონით განსაზღვრული მოთხოვნების და ბიზნესის მიერ მისაღები downtime-ის მიხედვით.
Backup Monitoring – ვინ ამოწმებს, რომ Backup რეალურად შესრულდა?
Automation სასარგებლოა, მაგრამ „ავტომატურად მუშაობს“ და „კონტროლი აღარ სჭირდება“ ერთი და იგივე არ არის.
Backup Job შეიძლება კვირების განმავლობაში ვარდებოდეს storage-ის შევსების, authentication error-ის, API ცვლილების, დაკარგული permission-ის ან სხვა ტექნიკური პრობლემის გამო.
თუ ეს მხოლოდ ინციდენტის დროს აღმოაჩინეთ, უკვე გვიანია.
ამიტომ ორგანიზაციას უნდა ჰქონდეს მონიტორინგი, რომელიც ამოწმებს არა მხოლოდ იმას, დაიწყო თუ არა Backup, არამედ:
დასრულდა თუ არა წარმატებით;
რამდენი მონაცემი შეინახა;
როდის შესრულდა ბოლო წარმატებული Backup;
არის თუ არა Storage საკმარისი;
ხომ არ შეიცვალა მოულოდნელად Backup Size;
მუშაობს თუ არა retention;
და წარმატებით სრულდება თუ არა Restore Test.
Backup-ის პასუხისმგებელი პირიც წინასწარ უნდა იყოს განსაზღვრული.
Disaster Recovery Plan – Backup-ის შემდეგ რა ხდება?
სერიოზული ინციდენტის დროს მხოლოდ Backup-ის მისამართის ცოდნა საკმარისი არ არის.
უნდა არსებობდეს პასუხი კითხვებზე:
რომელი სისტემა აღდგება პირველი?
სად შეიქმნება ახალი სერვერი?
ვინ მართავს DNS-ს?
ვის აქვს საჭირო credentials?
როგორ ვადგენთ, რომ Backup ინფიცირებული არ არის?
როგორ იზოლირდება ახალი გარემო ძველისგან?
როდის შეიძლება მომხმარებლების ხელახლა დაშვება სისტემაში?
როგორ ვადასტურებთ Database-ის მთლიანობას?
ვის უნდა ეცნობოს ინციდენტის შესახებ?
NIST contingency planning-ს აღწერს როგორც კოორდინირებულ სტრატეგიას, რომელიც მოიცავს გეგმებს, პროცედურებსა და ტექნიკურ ზომებს სისტემების, ოპერაციებისა და მონაცემების აღსადგენად შეფერხების შემდეგ.
CISA კი ransomware-ის შემდეგ რეკომენდაციას აძლევს ორგანიზაციებს Restore დაიწყონ ცნობილი სუფთა, offline და encrypted Backup-იდან და განსაკუთრებული ყურადღება მიაქციონ იმას, რომ აღდგენის პროცესში სუფთა სისტემა ხელახლა არ დაინფიცირდეს.
ერთი მარტივი სცენარი
წარმოვიდგინოთ კომპანია, რომლის:
ვებსაიტი და CRM Cloud Server-ზე მუშაობს;
ფაილები ყოველდღიურად Cloud Storage-ზე ინახება;
მონაცემთა ბაზა ყოველ რამდენიმე საათში Backupდება;
ყოველდღიური Backup-ის კიდევ ერთი ასლი დამოუკიდებელ Storage Provider-ში იგზავნება;
კრიტიკული Backup Immutable რეჟიმში ინახება;
პერიოდულად იქმნება Offline ასლიც;
ყველა Backup encrypted არის;
Backup ადმინისტრაციისთვის Production-ისგან დამოუკიდებელი ანგარიში და MFA გამოიყენება;
ხოლო კომპანია პერიოდულად აკეთებს Restore Test-ს.
თუ Production Server გაფუჭდა, Online Backup საშუალებას იძლევა სწრაფად აღდგეს სისტემა.
თუ Production და Online გარემო ერთდროულად კომპრომეტირდა, Immutable ან Offline Backup რჩება როგორც დამატებითი დაცვის ფენა.
სწორედ ეს არის resilience.
არა ერთი Backup ფაილი არამედ აღდგენის რამდენიმე დამოუკიდებელი გზა.
ხშირად დასმული კითხვები
Backup არის თუ არა კიბერუსაფრთხოება?
Backup კიბერუსაფრთხოების მნიშვნელოვანი ნაწილია, მაგრამ თავისთავად უსაფრთხოების სრულ სისტემას არ წარმოადგენს. ის ძირითადად Recovery-ს ემსახურება, ხოლო თავდასხმის პრევენციას სხვა კონტროლები MFA, patching, access control, endpoint security, monitoring და სხვა მექანიზმები უზრუნველყოფს.
საკმარისია Cloud Backup?
Cloud Backup ძლიერი კომპონენტია, მაგრამ ერთადერთი ასლის შენახვა ერთ Cloud ანგარიშში დამატებით რისკს ქმნის. კრიტიკული მონაცემებისთვის სასურველია დამოუკიდებელი ან offline/immutable დამატებითი ასლის არსებობაც.
რამდენი Backup უნდა ჰქონდეს კომპანიას?
ერთ-ერთი ფართოდ გამოყენებული მიდგომაა 3-2-1 პრინციპი: მონაცემების სამი ასლი, ორი განსხვავებული ტიპის გარემო და მინიმუმ ერთი off-site ან offline ასლი.
რატომ არ უნდა იყოს External Drive მუდმივად დაკავშირებული?
რადგან კომპრომეტირებულ კომპიუტერს ან ransomware-ს შესაძლოა დაკავშირებულ დისკზეც ჰქონდეს წვდომა და Backup წაშალოს ან დააზიანოს. CISA ამიტომ ურჩევს მომხმარებლებს გარე Backup Drive აქტიური Backup-ის დასრულების შემდეგ გათიშონ.
რამდენად ხშირად უნდა შემოწმდეს Backup?
უნივერსალური სიხშირე არ არსებობს. Test Frequency უნდა შეესაბამებოდეს მონაცემების კრიტიკულობას, RPO/RTO მოთხოვნებსა და ცვლილებების სიხშირეს. მთავარი პრინციპია, რომ Restore Test იყოს რეგულარული და დოკუმენტირებული. NIST და CISA ორივე ხაზს უსვამენ რეგულარული ტესტირების მნიშვნელობას.
რას ნიშნავს წარმატებული Backup?
წარმატებული Backup ნიშნავს არა მხოლოდ ფაილის შექმნას, არამედ იმასაც, რომ ასლი სრულყოფილია, დაცულია, საჭირო მომენტში ხელმისაწვდომია და მისგან სისტემის წარმატებით აღდგენა შესაძლებელია.
დასკვნა: არ იკითხოთ მხოლოდ „გვაქვს თუ არა Backup?“
სწორი შეკითხვებია:
სად ინახება ჩვენი Backup?
შეუძლია თუ არა თავდამსხმელს მასზე იმავე ანგარიშით წვდომა?
გვაქვს თუ არა დამოუკიდებელი Online და Offline/Immutable ასლები?
დაშიფრულია თუ არა მონაცემები?
მუშაობს თუ არა MFA?
როდის ჩავატარეთ ბოლო Restore Test?
რამდენი მონაცემის დაკარგვის უფლება გვაქვს, ანუ რა არის ჩვენი RPO?
რამდენ ხანში შეგვიძლია სისტემის აღდგენა, ანუ რა არის ჩვენი RTO?
და თუ ხვალ მთელი ძირითადი ინფრასტრუქტურა მიუწვდომელი გახდება ვიცით ზუსტად, რა უნდა გავაკეთოთ?
თუ ამ კითხვებზე პასუხი არ არსებობს, მხოლოდ იმის ცოდნა, რომ „Backup სადღაც კეთდება“, ბიზნესის უსაფრთხოებისთვის საკმარისი არ არის.
თანამედროვე მონაცემთა დაცვა უნდა აერთიანებდეს პრევენციას, დაცვას, მონიტორინგს, Backup-ს, იზოლაციას, ტესტირებას და წინასწარ დაგეგმილ აღდგენას.
სწორედ მაშინ იქცევა Backup უბრალო ფაილის ასლიდან რეალურ Business Continuity და Disaster Recovery სისტემად.
