Τι θα συμβεί αν αύριο το πρωί ο βασικός server, το ERP, τα εταιρικά αρχεία ή μια κρίσιμη cloud υπηρεσία δεν είναι διαθέσιμα;
Ένα Disaster Recovery Plan (DRP) οργανώνει τον τρόπο με τον οποίο μια επιχείρηση θα αποκαταστήσει κρίσιμα πληροφοριακά συστήματα, εφαρμογές, υποδομές και δεδομένα μετά από μια σοβαρή διακοπή.
Δεν είναι απλώς ένα backup plan. Πρέπει να απαντά σε πρακτικές ερωτήσεις: τι επαναφέρουμε πρώτο, πόσο γρήγορα πρέπει να επανέλθει, πόσα δεδομένα μπορούμε να χάσουμε, ποιος εκτελεί κάθε ενέργεια και πώς γνωρίζουμε ότι η διαδικασία λειτουργεί πραγματικά;
Disaster Recovery, Business Continuity και Incident Response
Οι τρεις έννοιες συνδέονται, αλλά δεν είναι ίδιες.
Business Continuity εξετάζει πώς θα συνεχιστούν ή θα αποκατασταθούν οι κρίσιμες επιχειρησιακές λειτουργίες μετά από μια σοβαρή διακοπή.
Disaster Recovery επικεντρώνεται περισσότερο στην τεχνική αποκατάσταση των πληροφοριακών συστημάτων, εφαρμογών, υποδομών και δεδομένων που υποστηρίζουν αυτές τις λειτουργίες.
Incident Response αφορά την οργανωμένη αντιμετώπιση ενός κυβερνοπεριστατικού, όπως την αξιολόγηση, το containment, τη διερεύνηση, την eradication και το ασφαλές recovery.
Σε ένα ransomware incident μπορεί να χρειάζονται και τα τρία: Incident Response για την αντιμετώπιση της επίθεσης, Disaster Recovery για την τεχνική αποκατάσταση και Business Continuity για τη διατήρηση των σημαντικότερων επιχειρησιακών λειτουργιών.
1. Προσδιορίστε τι πρέπει πραγματικά να ανακτηθεί
Ένα DRP δεν πρέπει να ξεκινά με μια γενική λίστα servers. Πρέπει πρώτα να γνωρίζετε ποιες τεχνολογικές υπηρεσίες υποστηρίζουν κρίσιμες επιχειρησιακές λειτουργίες.
Καταγράψτε, ανάλογα με το περιβάλλον:
- servers και virtual machines,
- ERP, CRM και άλλες κρίσιμες εφαρμογές,
- databases,
- file services και κρίσιμα δεδομένα,
- identity και authentication services,
- network infrastructure και Internet connectivity,
- cloud και SaaS υπηρεσίες,
- backup και recovery infrastructure.
Δεν έχουν όλα τα συστήματα την ίδια προτεραιότητα. Το DRP πρέπει να επικεντρώνει τους διαθέσιμους πόρους εκεί όπου η διακοπή δημιουργεί τη μεγαλύτερη επιχειρησιακή επίπτωση.
2. Χρησιμοποιήστε Business Impact Analysis
Το Business Impact Analysis (BIA) βοηθά να συνδεθούν οι επιχειρησιακές ανάγκες με τις τεχνικές προτεραιότητες recovery.
Για κάθε κρίσιμη υπηρεσία εξετάστε:
- ποια επιχειρησιακή λειτουργία υποστηρίζει,
- τι συμβαίνει αν παραμείνει εκτός λειτουργίας,
- πόσο γρήγορα αυξάνεται η επίπτωση της διακοπής,
- ποια άλλα συστήματα απαιτούνται για να λειτουργήσει,
- ποια δεδομένα χρειάζεται,
- ποιοι εργαζόμενοι ή εξωτερικοί συνεργάτες απαιτούνται για την αποκατάσταση.
Το αποτέλεσμα του BIA πρέπει να χρησιμοποιείται για να καθορίζεται η σειρά και οι απαιτήσεις ανάκαμψης.
3. Καθορίστε Recovery Time Objective (RTO)
Το Recovery Time Objective (RTO) είναι ο στόχος για τον χρόνο μέσα στον οποίο μια λειτουργία ή ένα σύστημα πρέπει να μπορεί να αποκατασταθεί μετά από διακοπή.
Δεν υπάρχει ένα σωστό RTO για όλες τις υπηρεσίες.
Ένα σύστημα που μπορεί να παραμείνει εκτός λειτουργίας για μία ημέρα χωρίς σοβαρή επίπτωση έχει διαφορετικές απαιτήσεις από μια υπηρεσία που υποστηρίζει άμεσα τις καθημερινές συναλλαγές της επιχείρησης.
Το RTO πρέπει να προκύπτει από τις επιχειρησιακές απαιτήσεις και να είναι τεχνικά εφικτό με την επιλεγμένη recovery architecture.
4. Καθορίστε Recovery Point Objective (RPO)
Το Recovery Point Objective (RPO) σχετίζεται με το σημείο στον χρόνο στο οποίο πρέπει να μπορούν να επανέλθουν τα δεδομένα μετά από μια διακοπή και επομένως με το πόση απώλεια πρόσφατων δεδομένων μπορεί να είναι αποδεκτή.
Αν μια κρίσιμη εφαρμογή δημιουργεί συνεχώς νέες συναλλαγές, οι απαιτήσεις της μπορεί να είναι πολύ διαφορετικές από ένα σύστημα του οποίου τα δεδομένα αλλάζουν σπάνια.
Το RPO πρέπει να επηρεάζει τη συχνότητα και την τεχνολογία προστασίας των δεδομένων. Δεν έχει νόημα να ορίζεται ένας φιλόδοξος RPO αν η πραγματική backup ή replication διαδικασία δεν μπορεί να τον υποστηρίξει.
5. Καταγράψτε τις εξαρτήσεις
Ένα από τα συχνότερα προβλήματα στο Disaster Recovery είναι ότι ένα σύστημα αποκαθίσταται τεχνικά αλλά εξακολουθεί να μην μπορεί να λειτουργήσει επειδή λείπει κάποια dependency.
Μια εφαρμογή μπορεί να εξαρτάται από:
- database server,
- identity provider ή directory service,
- DNS,
- network connectivity,
- certificates ή secrets,
- storage,
- άλλη εσωτερική εφαρμογή,
- cloud ή τρίτη υπηρεσία.
Για αυτό το DRP πρέπει να καταγράφει όχι μόνο τι θα επανέλθει, αλλά και με ποια σειρά.
6. Επιλέξτε Recovery Strategy
Αφού καθοριστούν οι απαιτήσεις, χρειάζεται συγκεκριμένη τεχνική στρατηγική για κάθε κρίσιμη υπηρεσία.
Ανάλογα με το περιβάλλον, μπορεί να χρησιμοποιούνται:
- restore από backups,
- rebuild συστημάτων από γνωστή ασφαλή configuration,
- replication δεδομένων ή υπηρεσιών,
- alternate infrastructure,
- cloud-native recovery capabilities,
- αντικατάσταση εξοπλισμού,
- συνδυασμός περισσότερων τεχνικών.
Η κατάλληλη επιλογή εξαρτάται από RTO, RPO, κόστος, τεχνική πολυπλοκότητα και επίπεδο κινδύνου.
Δεν χρειάζεται κάθε μικρή επιχείρηση την ακριβότερη ή πιο σύνθετη αρχιτεκτονική. Χρειάζεται όμως recovery strategy που μπορεί πραγματικά να καλύψει τις απαιτήσεις της.
7. Backup δεν σημαίνει Disaster Recovery
Τα backups είναι συχνά κρίσιμο στοιχείο του Disaster Recovery, αλλά ένα επιτυχημένο backup job δεν αποτελεί από μόνο του DRP.
Ένα ολοκληρωμένο σχέδιο πρέπει επίσης να γνωρίζει:
- ποια δεδομένα και configurations προστατεύονται,
- πού βρίσκονται τα recovery copies,
- ποιος έχει δικαίωμα πρόσβασης σε αυτά,
- ποια έκδοση πρέπει να χρησιμοποιηθεί για restore,
- με ποια σειρά επανέρχονται οι υπηρεσίες,
- πώς επιβεβαιώνεται ότι το restored σύστημα λειτουργεί σωστά.
Για cyber incidents είναι ιδιαίτερα σημαντικό τα κρίσιμα backups να προστατεύονται από μη εξουσιοδοτημένη αλλαγή ή διαγραφή και να υπάρχουν recovery copies που δεν είναι εύκολα προσβάσιμα από ένα παραβιασμένο production environment.
8. Δοκιμάστε πραγματικά το Restore
Η ύπαρξη backup δεν αποδεικνύει ότι το recovery θα λειτουργήσει.
Οι δοκιμές πρέπει να επιβεβαιώνουν ότι:
- τα απαραίτητα δεδομένα μπορούν πράγματι να ανακτηθούν,
- τα backups είναι διαθέσιμα και κατάλληλα για restore,
- η ομάδα γνωρίζει τη διαδικασία,
- οι εξαρτήσεις έχουν καταγραφεί σωστά,
- η αποκατεστημένη υπηρεσία λειτουργεί όπως αναμένεται.
Για κρίσιμες υπηρεσίες χρειάζεται να εξετάζεται ολόκληρη η διαδικασία recovery και όχι μόνο η ανάκτηση ενός μεμονωμένου αρχείου.
9. Προστατεύστε το Recovery Environment
Σε ένα cyber incident υπάρχει κίνδυνος να επαναφέρετε ένα σύστημα σε περιβάλλον που παραμένει παραβιασμένο ή να χρησιμοποιήσετε recovery data που έχουν ήδη επηρεαστεί.
Για αυτό, πριν από την επιστροφή μιας κρίσιμης υπηρεσίας σε παραγωγική λειτουργία, πρέπει να υπάρχει επαρκής έλεγχος ότι:
- έχει αντιμετωπιστεί η σχετική ενεργή απειλή,
- έχουν διορθωθεί οι γνωστές αιτίες της παραβίασης όπου είναι δυνατό,
- τα credentials και access paths που επηρεάστηκαν έχουν αντιμετωπιστεί,
- η recovery source θεωρείται κατάλληλη για χρήση,
- το restored σύστημα έχει τις απαραίτητες security updates και configuration.
Σε αυτή την περίπτωση το Disaster Recovery πρέπει να συντονίζεται στενά με το Incident Response.
10. Καταγράψτε συγκεκριμένα Recovery Procedures
Το DRP πρέπει να είναι αρκετά συγκεκριμένο ώστε να μπορεί να χρησιμοποιηθεί σε πραγματική διακοπή.
Για κάθε κρίσιμη υπηρεσία είναι χρήσιμο να καταγράφονται:
- ο υπεύθυνος recovery,
- οι απαιτούμενες προσβάσεις και εργαλεία,
- οι βασικές dependencies,
- η σειρά των ενεργειών,
- τα recovery sources,
- τα validation checks μετά το restore,
- τα escalation contacts αν η διαδικασία αποτύχει.
Οι οδηγίες πρέπει να είναι διαθέσιμες ακόμη και αν το σύστημα στο οποίο συνήθως αποθηκεύονται τα έγγραφα δεν λειτουργεί.
11. Καθορίστε ρόλους και ευθύνες
Σε μια πραγματική διακοπή δεν πρέπει να χάνεται χρόνος για να αποφασιστεί ποιος έχει την ευθύνη.
Το σχέδιο πρέπει να καθορίζει:
- ποιος ενεργοποιεί το DRP,
- ποιος συντονίζει την τεχνική αποκατάσταση,
- ποιος εγκρίνει σημαντικές αποφάσεις,
- ποιος επικοινωνεί με cloud, telecom ή άλλους providers,
- ποιος ενημερώνει τη διοίκηση για την πρόοδο και τα προβλήματα.
Σε μικρές επιχειρήσεις ένα άτομο μπορεί να έχει περισσότερους από έναν ρόλους. Αυτό κάνει ακόμη σημαντικότερη την ύπαρξη σαφούς τεκμηρίωσης και εναλλακτικών contacts.
12. Προβλέψτε την εξάρτηση από εξωτερικούς Providers
Μια επιχείρηση μπορεί να βασίζεται σε MSP, cloud provider, software vendor, Internet provider ή άλλο τρίτο μέρος για την αποκατάσταση κρίσιμης υπηρεσίας.
Το DRP πρέπει να γνωρίζει:
- ποιος provider υποστηρίζει κάθε κρίσιμη υπηρεσία,
- πώς ανοίγει emergency support request,
- ποια στοιχεία ή εξουσιοδοτήσεις μπορεί να χρειαστούν,
- ποιοι περιορισμοί ή dependencies βρίσκονται εκτός του άμεσου ελέγχου της επιχείρησης.
Μην θεωρείτε ότι το «είναι στο cloud» σημαίνει αυτόματα ότι κάθε πιθανό recovery scenario έχει ήδη καλυφθεί από τον provider.
13. Δοκιμάστε ολόκληρο το Disaster Recovery Plan
Ένα DRP που δεν έχει δοκιμαστεί παραμένει σε μεγάλο βαθμό θεωρητικό.
Οι ασκήσεις μπορούν να ξεκινήσουν απλά και να γίνουν πιο απαιτητικές ανάλογα με την κρισιμότητα και τις δυνατότητες της επιχείρησης.
Παραδείγματα περιλαμβάνουν:
- tabletop exercise με υποθετική απώλεια κρίσιμου συστήματος,
- restore συγκεκριμένων δεδομένων,
- recovery μιας εφαρμογής σε ελεγχόμενο περιβάλλον,
- δοκιμή επικοινωνίας με κρίσιμους providers,
- πιο ολοκληρωμένη άσκηση recovery για σημαντική υπηρεσία.
Η δοκιμή πρέπει να καταγράφει τι λειτούργησε, τι απέτυχε, πόσο χρόνο χρειάστηκε και ποιες διορθώσεις απαιτούνται.
14. Ελέγξτε αν οι πραγματικοί χρόνοι καλύπτουν τα RTO
Ένας στόχος recovery έχει αξία μόνο αν η επιχείρηση μπορεί να τον πετύχει στην πράξη.
Αν μια δοκιμή δείξει ότι μια υπηρεσία χρειάζεται σημαντικά περισσότερο χρόνο από το καθορισμένο RTO, υπάρχουν δύο βασικές επιλογές: να βελτιωθεί η recovery capability ή να επανεξεταστεί ο στόχος μαζί με την επιχείρηση.
Το ίδιο ισχύει για το RPO: η πραγματική προστασία και συχνότητα των δεδομένων πρέπει να είναι συμβατή με τον αποδεκτό στόχο απώλειας δεδομένων.
15. Ενημερώνετε το DRP όταν αλλάζει η υποδομή
Ένα Disaster Recovery Plan μπορεί να γίνει άχρηστο αν συνεχίζει να αναφέρεται σε παλιούς servers, λογαριασμούς, εφαρμογές ή υπευθύνους.
Επανεξετάστε το μετά από:
- σημαντικές αλλαγές υποδομής,
- μεταφορά υπηρεσιών στο cloud,
- αλλαγές σε κρίσιμους providers,
- νέα ή καταργημένα συστήματα,
- αλλαγές προσωπικού και ρόλων,
- recovery tests,
- πραγματικά incidents ή outages.
Τα lessons learned πρέπει να μετατρέπονται σε συγκεκριμένες αλλαγές του plan και της recovery architecture.
Disaster Recovery Checklist για ΜΜΕ
- Έχουμε καταγράψει τα κρίσιμα συστήματα και τις εφαρμογές.
- Οι recovery priorities βασίζονται σε επιχειρησιακή επίπτωση.
- Έχουμε καταγράψει dependencies μεταξύ κρίσιμων υπηρεσιών.
- Υπάρχουν κατάλληλα RTO και RPO όπου απαιτούνται.
- Η recovery strategy μπορεί τεχνικά να υποστηρίξει αυτούς τους στόχους.
- Τα κρίσιμα backups προστατεύονται και δοκιμάζονται.
- Υπάρχουν σαφείς restore και recovery procedures.
- Οι υπεύθυνοι και τα escalation contacts είναι γνωστά.
- Έχουν καταγραφεί οι κρίσιμοι εξωτερικοί providers.
- Το DRP είναι διαθέσιμο ακόμη και σε σοβαρό IT outage.
- Έχουμε πραγματοποιήσει πραγματική recovery άσκηση.
- Μετράμε αν οι πραγματικοί χρόνοι recovery καλύπτουν τους στόχους.
- Το σχέδιο ενημερώνεται μετά από αλλαγές, tests και incidents.
Ένα DRP πρέπει να μπορεί να εκτελεστεί, όχι απλώς να υπάρχει
Η αξία ενός Disaster Recovery Plan δεν βρίσκεται στον αριθμό των σελίδων του αλλά στο αν μπορεί να χρησιμοποιηθεί όταν τα κρίσιμα συστήματα δεν λειτουργούν.
Ένα χρήσιμο DRP συνδέει τις επιχειρησιακές προτεραιότητες με συγκεκριμένους recovery στόχους, τεχνικές διαδικασίες, υπευθύνους και δοκιμασμένες δυνατότητες αποκατάστασης.
Τα backups είναι σημαντικό μέρος αυτής της διαδικασίας, αλλά η πραγματική ανθεκτικότητα προκύπτει όταν η επιχείρηση γνωρίζει τι πρέπει να επαναφέρει, από πού, με ποια σειρά, από ποιον και μέσα σε ποιον στόχο χρόνου.
Πώς μπορεί να βοηθήσει η DataShield.gr;
Η DataShield.gr μπορεί να αξιολογήσει την τεχνική ετοιμότητα μιας επιχείρησης για Disaster Recovery, εξετάζοντας κρίσιμα συστήματα και dependencies, backup και restore διαδικασίες, recovery priorities και βασικά σημεία του υπάρχοντος DR plan.
Οι κατάλληλες recovery στρατηγικές εξαρτώνται από την υποδομή, τα δεδομένα, τις επιχειρησιακές απαιτήσεις και τους αποδεκτούς χρόνους διακοπής κάθε οργανισμού.
Επικοινωνήστε με τη DataShield.gr για μια αρχική αξιολόγηση της δυνατότητας ανάκαμψης των κρίσιμων IT υπηρεσιών της επιχείρησής σας.
