Πίνακας κατανομής ευθυνών στο cloud για ISO, NIS2 και DORA
Ο COO μιας fintech καλεί τον CISO στις 07:15 ένα πρωί Δευτέρας.
Ένας Ευρωπαίος τραπεζικός πελάτης ζητά τεκμήρια ότι η πλατφόρμα SaaS της εταιρείας μπορεί να καλύψει τις απαιτήσεις του DORA για τον κίνδυνο τρίτων παρόχων ΤΠΕ. Η ομάδα πωλήσεων έχει ήδη στείλει το γνώριμο πακέτο ασφάλειας προμηθευτή: πιστοποιητικό ISO, σύνοψη διοίκησης από δοκιμή διείσδυσης, πιστοποιητικό κυβερνοασφάλισης, ειδοποίηση απορρήτου και αναφορά διασφάλισης παρόχου υπηρεσιών cloud.
Η τράπεζα επανέρχεται με πιο συγκεκριμένο ερώτημα:
«Δείξτε μας ποιος είναι υπεύθυνος για κάθε έλεγχο στο περιβάλλον cloud σας. Εσείς, ο πάροχος υπηρεσιών cloud, ο πάροχος διαχειριζόμενης βάσης δεδομένων, ο πάροχος ταυτότητας, ο προμηθευτής καταγραφής και τυχόν υπεργολάβοι επεξεργασίας. Έπειτα δείξτε τα τεκμήρια.»
Αργότερα το ίδιο πρωί, ο CISO έχει συνεδρίαση με το Διοικητικό Συμβούλιο. Ο CEO θα θέσει το ίδιο ερώτημα σε επιχειρηματική γλώσσα: «Είμαστε βέβαιοι ότι αυτή η πλατφόρμα είναι ασφαλής και ποιος είναι υπεύθυνος αν κάτι πάει στραβά;»
Εκεί ακριβώς σταματούν πολλά προγράμματα συμμόρφωσης στο cloud.
Ο οργανισμός μπορεί να διαθέτει ισχυρό πάροχο υπηρεσιών cloud, καλά εργαλεία, εύλογες πολιτικές και Μητρώο Κινδύνων. Όταν όμως καλείται να αποδείξει τα όρια ευθύνης, τα τεκμήρια είναι διάσπαρτα. Οι Προμήθειες έχουν τις συμβάσεις. Το Νομικό Τμήμα έχει τη Συμφωνία Επεξεργασίας Δεδομένων. Η Μηχανική έχει τα διαγράμματα αρχιτεκτονικής. Η Ασφάλεια έχει αρχεία καταγραφής και ρυθμίσεις cloud. Η Ιδιωτικότητα έχει τον κατάλογο υπεργολάβων επεξεργασίας. Η Συμμόρφωση έχει τη Δήλωση Εφαρμοσιμότητας. Κανείς δεν έχει ένα ελεγχόμενο τεκμήριο που να λέει, έλεγχο προς έλεγχο, τι κάνει ο πάροχος, τι πρέπει να ρυθμίσει ο πελάτης, ποιος υπεργολάβος επεξεργασίας εμπλέκεται, ποια ρήτρα καθιστά την υποχρέωση εφαρμόσιμη και ποια τεκμήρια πρέπει να αναμένει ένας ελεγκτής.
Αυτό το τεκμήριο είναι ο πίνακας κατανομής ευθυνών στο cloud.
Όχι η γενική διαφάνεια ενός hyperscaler που λέει ότι ο πάροχος ασφαλίζει το cloud και ο πελάτης ασφαλίζει ό,τι βρίσκεται μέσα στο cloud. Ένας πραγματικός πίνακας κατανομής ευθυνών στο cloud για ISO/IEC 27001:2022, NIS2, DORA και GDPR είναι αρχείο διακυβέρνησης. Αντέχει σε δέουσα επιμέλεια πελάτη, έλεγχο ISO, ανασκόπηση DORA, αμφισβήτηση λογοδοσίας GDPR και διερεύνηση περιστατικού.
Γιατί η κατανομή ευθυνών στο cloud γίνεται ζήτημα ελέγχου
Το μοντέλο κοινής ευθύνης συνήθως παρουσιάζεται ως τεχνικό όριο. Στο IaaS, ο πάροχος διαχειρίζεται τις φυσικές εγκαταστάσεις, το υλικό, την εικονικοποίηση και τη βασική υποδομή. Ο πελάτης διαχειρίζεται ταυτότητες, δεδομένα, φόρτους εργασίας, κανόνες δικτύου, επιλογές κρυπτογράφησης και ρυθμίσεις παραμέτρων. Στο SaaS, ο πάροχος αναλαμβάνει περισσότερη λειτουργική ευθύνη, αλλά ο πελάτης εξακολουθεί να είναι υπεύθυνος για την πρόσβαση χρηστών, τη διακυβέρνηση δεδομένων, τη νομική βάση, τις ρυθμίσεις παραμέτρων, τις προσδοκίες παρακολούθησης και την κλιμάκωση περιστατικών.
Η εξήγηση αυτή είναι χρήσιμη, αλλά ελλιπής.
Οι ελεγκτές, οι ρυθμιστικές αρχές και οι εταιρικοί πελάτες ρωτούν κάτι περισσότερο από το «ποιος λειτουργεί τον έλεγχο;». Θέλουν να γνωρίζουν:
- Ποιος λογοδοτεί για τον κίνδυνο;
- Ποια συμβατική ρήτρα καθιστά αυτή τη λογοδοσία εφαρμόσιμη;
- Ποια πολιτική απαιτεί τον έλεγχο;
- Ποια υπηρεσία cloud, πλατφόρμα SaaS ή υπεργολάβος επεξεργασίας βρίσκεται εντός πεδίου εφαρμογής;
- Ποια τεκμήρια αποδεικνύουν ότι ο έλεγχος λειτούργησε κατά την περίοδο ανασκόπησης;
- Ποια απαίτηση πλαισίου καλύπτουν τα τεκμήρια;
- Τι συμβαίνει αν ο πάροχος αλλάξει την υπηρεσία, την τοποθεσία, τον υπεργολάβο ή την κατάσταση των ελέγχων του;
Το ISO/IEC 27001:2022 ISO/IEC 27001:2022 το καθιστά ζήτημα συστήματος διαχείρισης. Οι ρήτρες 4.1 έως 4.4 απαιτούν από τον οργανισμό να κατανοεί εσωτερικά και εξωτερικά ζητήματα, ενδιαφερόμενα μέρη, νομικές και συμβατικές υποχρεώσεις, το πεδίο εφαρμογής του ISMS, διεπαφές και εξαρτήσεις. Οι ρήτρες 6.1.1 έως 6.1.3 απαιτούν αξιολόγηση κινδύνων, αντιμετώπιση κινδύνων, έγκριση από τον ιδιοκτήτη κινδύνου, αποδοχή υπολειπόμενου κινδύνου και Δήλωση Εφαρμοσιμότητας. Η ρήτρα 8.1 απαιτεί επιχειρησιακό σχεδιασμό και έλεγχο, συμπεριλαμβανομένου του ελέγχου εξωτερικά παρεχόμενων διεργασιών, προϊόντων και υπηρεσιών που σχετίζονται με το ISMS.
Με απλά λόγια, αν ένας πάροχος υπηρεσιών cloud, προμηθευτής SaaS ή υπεργολάβος επεξεργασίας υποστηρίζει επιχειρησιακή διαδικασία εντός πεδίου εφαρμογής, δεν μπορεί να βρίσκεται εκτός ISMS. Πρέπει να είναι ορατός στο πεδίο εφαρμογής, στον κίνδυνο, στην αντιμετώπιση, στον συμβατικό έλεγχο και στα τεκμήρια.
Το NIS2 αυξάνει τις απαιτήσεις. Το Article 21 απαιτεί από τις ουσιώδεις και σημαντικές οντότητες να εφαρμόζουν κατάλληλα και αναλογικά τεχνικά, λειτουργικά και οργανωτικά μέτρα, συμπεριλαμβανομένων της ανάλυσης κινδύνων, του χειρισμού περιστατικών, της συνέχειας, της ασφάλειας εφοδιαστικής αλυσίδας, της ασφαλούς απόκτησης, της ασφαλούς ανάπτυξης, της διαχείρισης ευπαθειών, της αξιολόγησης αποτελεσματικότητας, της κυβερνοϋγιεινής, της κρυπτογραφίας, της ασφάλειας ανθρώπινου δυναμικού, του ελέγχου πρόσβασης, της διαχείρισης περιουσιακών στοιχείων και της πολυπαραγοντικής αυθεντικοποίησης ή της συνεχούς αυθεντικοποίησης, όπου ενδείκνυται. Το Article 20 αναθέτει την ευθύνη διακυβέρνησης στα όργανα διοίκησης.
Το DORA είναι ακόμη πιο σαφές για τις χρηματοοικονομικές οντότητες. Εφαρμόζεται από τις 17 Ιανουαρίου 2025 και απαιτεί από τις χρηματοοικονομικές οντότητες να διαχειρίζονται τον κίνδυνο ΤΠΕ, την αναφορά μειζόνων περιστατικών σχετιζόμενων με ΤΠΕ, τις δοκιμές ψηφιακής επιχειρησιακής ανθεκτικότητας και τον κίνδυνο τρίτων παρόχων ΤΠΕ. Τα Articles 28 to 30 απαιτούν διαχείριση κινδύνου τρίτων παρόχων ΤΠΕ, προκαταρκτική αξιολόγηση κινδύνου συγκέντρωσης, συμβατικές δικλίδες ασφαλείας, δικαιώματα ελέγχου και πρόσβασης, ορατότητα υπεργολαβικής ανάθεσης, δικαιώματα καταγγελίας και στρατηγικές εξόδου.
Ο GDPR προσθέτει τη δοκιμή λογοδοσίας. Το Article 5 απαιτεί τα δεδομένα προσωπικού χαρακτήρα να υποβάλλονται σε επεξεργασία με ακεραιότητα και εμπιστευτικότητα, και το Article 5(2) απαιτεί από τον υπεύθυνο επεξεργασίας να είναι σε θέση να αποδεικνύει τη συμμόρφωση. Το Article 28 διέπει τις συμβάσεις με εκτελούντες την επεξεργασία και τους υπεργολάβους επεξεργασίας. Το Article 32 απαιτεί ασφάλεια της επεξεργασίας. Τα Articles 33 and 34 απαιτούν κοινοποίηση παραβίασης δεδομένων προσωπικού χαρακτήρα, όπου εφαρμόζεται.
Ο πίνακας κατανομής ευθυνών στο cloud γίνεται η γέφυρα μεταξύ αυτών των υποχρεώσεων.
Ο ορισμός της Clarysec: τεκμήριο διακυβέρνησης, όχι διάγραμμα
Στις αναθέσεις της Clarysec, ο πίνακας κατανομής ευθυνών στο cloud είναι ελεγχόμενο αρχείο του ISMS που συνδέει υπηρεσίες cloud, προμηθευτές, υπεργολάβους επεξεργασίας, ελέγχους, πολιτικές, συμβατικές υποχρεώσεις, τεκμήρια και προσδοκίες ελέγχου.
Η πιο ισχυρή εξήγηση εμφανίζεται στο Zenith Blueprint Zenith Blueprint, στη φάση Controls in Action, Step 23:
«Οι πάροχοι υπηρεσιών cloud ασφαλίζουν την υποδομή, αλλά εσείς παραμένετε υπόλογοι για τα δεδομένα σας, τις ρυθμίσεις παραμέτρων σας, τις πολιτικές πρόσβασής σας και την ετοιμότητα απόκρισής σας σε περιστατικά.»
Το ίδιο βήμα εξηγεί ότι η χρήση υπηρεσιών cloud πρέπει να αντιμετωπίζεται ως μέρος του ISMS, συμπεριλαμβανομένης της ταξινόμησης των υπηρεσιών cloud, της κατανόησης των δεδομένων που υποβάλλονται σε επεξεργασία ή αποθηκεύονται, της αξιολόγησης παρόχου, των συμβατικών ρητρών και της διαχείρισης αλλαγών υπηρεσιών. Αυτό μετατρέπει την κοινή ευθύνη από έννοια σε ιχνηλάσιμη δομή ελέγχων.
Το Zenith Controls Zenith Controls αντιμετωπίζει τους ελέγχους του ISO/IEC 27001:2022 Annex A και την καθοδήγηση ISO/IEC 27002:2022 5.20, 5.21 και 5.23 ως κεντρικούς άξονες:
- 5.20, Αντιμετώπιση της ασφάλειας πληροφοριών στις συμφωνίες με προμηθευτές.
- 5.21, Διαχείριση της ασφάλειας πληροφοριών στην εφοδιαστική αλυσίδα ΤΠΕ.
- 5.23, Ασφάλεια πληροφοριών για τη χρήση υπηρεσιών cloud.
Αυτά δεν είναι απομονωμένα στοιχεία λίστας ελέγχου. Ορίζουν τη ραχοκοκαλιά του πίνακα.
| Ερώτημα πίνακα | Άξονας ISO/IEC 27001:2022 Annex A | Πρακτική σημασία |
|---|---|---|
| Σε τι πρέπει να δεσμευτεί συμβατικά ο προμηθευτής; | 5.20 | Η ασφάλεια, η εμπιστευτικότητα, τα δικαιώματα ελέγχου, η αναφορά περιστατικών, η υπεργολαβική ανάθεση και η καταγγελία σύμβασης πρέπει να είναι εφαρμόσιμα. |
| Πώς ελέγχουμε τον πάροχο του παρόχου; | 5.21 | Ο κίνδυνος της εφοδιαστικής αλυσίδας ΤΠΕ και των κατάντη εξαρτήσεων πρέπει να αναγνωρίζεται, να αξιολογείται, να παρακολουθείται και να μετακυλίεται. |
| Πώς διέπουμε την επιλογή, τη χρήση και την έξοδο από υπηρεσίες cloud; | 5.23 | Οι ευθύνες στο cloud, οι ρυθμίσεις παραμέτρων, τα τεκμήρια, η καταγραφή, η τοποθεσία δεδομένων και η έξοδος πρέπει να διαχειρίζονται σε όλο τον κύκλο ζωής. |
Υποστηρικτικά πρότυπα μπορούν να ενισχύσουν τον πίνακα. Το ISO/IEC 27017 βοηθά με πρακτικές ασφάλειας ειδικές για το cloud. Τα ISO/IEC 27018 και ISO/IEC 27701 υποστηρίζουν τη διακυβέρνηση δεδομένων προσωπικού χαρακτήρα και ιδιωτικότητας. Το ISO/IEC 27005 υποστηρίζει την αξιολόγηση κινδύνων. Το ISO 22301 υποστηρίζει τη συνέχεια και την ανθεκτικότητα. Το ISO/IEC 27035 υποστηρίζει τη διαχείριση περιστατικών. Το ISO/IEC 20000-1 μπορεί να βοηθήσει όπου οι υπηρεσίες cloud αποτελούν μέρος παροχής διαχειριζόμενων υπηρεσιών.
Ο ελάχιστος βιώσιμος πίνακας κατανομής ευθυνών
Ένας ώριμος πίνακας δεν ξεκινά με 200 γραμμές. Ξεκινά με τις υπηρεσίες cloud που έχουν τη μεγαλύτερη σημασία.
Για μια SaaS, fintech ή ρυθμιζόμενη SME, η Clarysec συνήθως ξεκινά με:
- Περιβάλλον παραγωγής στο cloud με πρόσβαση πελατών.
- Πάροχο ταυτότητας.
- Διαχειριζόμενη βάση δεδομένων ή υπηρεσία αποθήκευσης.
- Πλατφόρμα καταγραφής, παρακολούθησης και SIEM.
- SaaS πληρωμών, KYC, analytics ή υποστήριξης πελατών.
- Υπηρεσία αντιγράφων ασφαλείας και ανάκαμψης από καταστροφή.
- Πάροχο διαχειριζόμενων υπηρεσιών ή πάροχο διαχειριζόμενων υπηρεσιών ασφάλειας.
- Υπεργολάβους επεξεργασίας που προσπελαύνουν, αποθηκεύουν ή επεξεργάζονται δεδομένα πελατών.
Ο πρώτος πίνακας πρέπει να περιλαμβάνει τις ακόλουθες στήλες.
| Στήλη | Γιατί έχει σημασία |
|---|---|
| Υπηρεσία ή περιοχή ελέγχου | Προσδιορίζει την ακριβή υπηρεσία cloud, προϊόν SaaS ή υποδιεργασία εντός πεδίου εφαρμογής. |
| Δεδομένα και επιχειρησιακή λειτουργία | Συνδέει την υπηρεσία με δεδομένα προσωπικού χαρακτήρα, κρίσιμες υπηρεσίες, χρηματοοικονομικές λειτουργίες ή ουσιώδεις λειτουργίες. |
| Ιδιοκτήτης ευθύνης | Ορίζει πάροχο, πελάτη, κοινή ευθύνη, υπεργολάβο επεξεργασίας ή εσωτερικό Υπεύθυνο Ελέγχου. |
| Υποχρέωση πελάτη | Δείχνει τι πρέπει να ρυθμίσει, να εγκρίνει, να παρακολουθεί ή να τεκμηριώνει ο οργανισμός σας. |
| Υποχρέωση παρόχου | Δείχνει τι πρέπει να παρέχει ο πάροχος cloud ή SaaS μέσω σύμβασης, διασφάλισης ή δυνατότητας πλατφόρμας. |
| Εξάρτηση από υπεργολάβο επεξεργασίας | Ιχνηλατεί κατάντη παρόχους που μπορεί να επηρεάσουν την ασφάλεια, την ιδιωτικότητα, τη συνέχεια ή την τοποθεσία δεδομένων. |
| Έλεγχος ISO/IEC 27001:2022 Annex A | Συνδέει τη γραμμή με τη Δήλωση Εφαρμοσιμότητας και την αιτιολόγηση του ελέγχου. |
| Αντιστοίχιση NIS2, DORA, GDPR, NIST CSF ή COBIT 2019 | Δείχνει τη διασύνδεση με πολλαπλά πλαίσια συμμόρφωσης χωρίς διπλασιασμό ελέγχων. |
| Τεκμήρια | Ορίζει αποδείξεις έτοιμες για έλεγχο. |
| Συχνότητα ανασκόπησης | Ορίζει τον ρυθμό παρακολούθησης, ιδίως για κρίσιμους ή υψηλού κινδύνου προμηθευτές. |
Μια πρακτική γραμμή για την καταγραφή θα μπορούσε να μοιάζει ως εξής.
| Υπηρεσία ή περιοχή ελέγχου | Ιδιοκτήτης ευθύνης | Υποχρέωση πελάτη | Υποχρέωση παρόχου | Εξάρτηση από υπεργολάβο επεξεργασίας | Έλεγχοι και πλαίσια | Τεκμήρια |
|---|---|---|---|---|---|---|
| Καταγραφή ελέγχου στο περιβάλλον παραγωγής cloud | Κοινή | Ενεργοποίηση αρχείων καταγραφής ελέγχου, ορισμός διατήρησης, περιορισμός πρόσβασης, ανασκόπηση ειδοποιήσεων και δοκιμή ανάκτησης | Παροχή δυνατότητας καταγραφής, συμβάντων πλατφόρμας, επιλογών διατήρησης και δεσμεύσεων διαθεσιμότητας | Προμηθευτής καταγραφής ή SIEM, αν τα αρχεία καταγραφής εξάγονται | ISO/IEC 27001:2022 Annex A 5.20, 5.23, 8.15, 8.16; NIS2 Article 21; DORA Articles 6, 8, 10, 17; αποτελέσματα Detect και Govern του NIST CSF 2.0 | Πρότυπο καταγραφής, εξαγωγή ρύθμισης παραμέτρων cloud, δείγματα αρχείων καταγραφής, ειδοποιήσεις SIEM, ανασκόπηση πρόσβασης, συμβατική ρήτρα παρόχου, τεκμήρια διατήρησης |
Αυτή η γραμμή δεν είναι απλώς τεκμηρίωση. Λέει στην Ασφάλεια τι να ρυθμίσει, στις Προμήθειες ποια συμβατική γλώσσα να ελέγξουν, στην Ιδιωτικότητα ποια ροή δεδομένων να καταγράψει και στους ελεγκτές ποια τεκμήρια να ζητήσουν.
Θεμέλιο πολιτικής: μετατροπή του πίνακα σε εφαρμόσιμη απαίτηση
Ένας πίνακας κατανομής ευθυνών στο cloud χωρίς στήριξη σε πολιτική είναι απλώς ένα υπολογιστικό φύλλο. Οι πολιτικές της Clarysec τον καθιστούν εφαρμόσιμο.
Για SMEs, η Cloud Usage Policy - SME Cloud Usage Policy - SME, ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα 5.3 απαιτεί:
«Το Μητρώο Υπηρεσιών Cloud πρέπει να τηρείται από τον πάροχο ΤΠ ή τον GM. Πρέπει να καταγράφει:»
Η ίδια πολιτική SME, ρήτρα 5.2.3, συνδέει τη διακυβέρνηση υπηρεσιών cloud με τον κίνδυνο ιδιωτικότητας και τοποθεσίας:
«Η τοποθεσία δεδομένων και οι πρακτικές ιδιωτικότητας συμμορφώνονται με τις εφαρμοστέες νομικές απαιτήσεις (π.χ. GDPR)»
Για εταιρικά περιβάλλοντα, η Cloud Usage Policy Cloud Usage Policy, ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα 5.1 ορίζει:
«Ο οργανισμός πρέπει να τηρεί κεντρικοποιημένο Μητρώο Υπηρεσιών Cloud, με ιδιοκτήτη τον CISO, το οποίο περιέχει:»
Η ρήτρα 5.4 καθιστά στη συνέχεια τις ευθύνες στο cloud συμβατικά εφαρμόσιμες:
«Όλες οι συμβάσεις CSP (Cloud Service Provider) πρέπει να περιλαμβάνουν εφαρμόσιμες διατάξεις για:»
Η διακυβέρνηση προμηθευτών επεκτείνει τον πίνακα πέρα από τον άμεσο πάροχο. Η Third-Party and Supplier Security Policy - SME Third-Party and Supplier Security Policy - SME, ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα 5.3.5 απαιτεί:
«Περιορισμούς στην περαιτέρω υπεργολαβική ανάθεση χωρίς έγκριση»
Η ίδια πολιτική SME για προμηθευτές, ενότητα «Απαιτήσεις εφαρμογής της πολιτικής», ρήτρα 6.3.1 προσθέτει την περιοδική ανασκόπηση:
«Οι κρίσιμοι ή υψηλού κινδύνου προμηθευτές πρέπει να ανασκοπούνται τουλάχιστον ετησίως. Η ανασκόπηση πρέπει να επαληθεύει:»
Σε επίπεδο επιχείρησης, η Third party and supplier security policy Third party and supplier security policy, ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα 5.3 ορίζει:
«Οι συμβάσεις με προμηθευτές πρέπει να περιλαμβάνουν:»
Για δεδομένα προσωπικού χαρακτήρα, η Data Protection and Privacy Policy Data Protection and Privacy Policy, ενότητα «Εφαρμογή και συμμόρφωση», ρήτρα 8.5.1 απαιτεί:
«Οι συμβάσεις με εκτελούντες την επεξεργασία πρέπει να περιλαμβάνουν:»
Για ορατότητα εξαρτήσεων, η Supplier Dependency Risk Management Policy Supplier Dependency Risk Management Policy, ρήτρα 6.5.4 απαιτεί:
«Αξιοποίηση της σχέσης με τον προμηθευτή για τη λήψη ενημερώσεων σχετικά με υπεργολάβους ή εξαρτήσεις εφοδιαστικής αλυσίδας ένα επίπεδο κατάντη, όπου θα μπορούσαν να μας επηρεάσουν (για παράδειγμα, αν ένας κρίσιμος προμηθευτής λογισμικού βασίζεται σε μεγάλο βαθμό σε βιβλιοθήκη τρίτου μέρους, αυτό πρέπει να καταγράφεται).»
Για τα αρχεία καταγραφής, η Logging and Monitoring Policy - SME Logging and Monitoring Policy - SME, ενότητα «Απαιτήσεις διακυβέρνησης», ρήτρα 5.5.1.3 παρέχει συγκεκριμένη συμβατική απαίτηση:
«Οι συμβάσεις πρέπει να απαιτούν από τους παρόχους να διατηρούν αρχεία καταγραφής για τουλάχιστον 12 μήνες και να παρέχουν πρόσβαση κατόπιν αιτήματος»
Μαζί, αυτές οι πολιτικές καθιστούν τον πίνακα απαιτούμενο αρχείο διακυβέρνησης που υποστηρίζει την έγκριση προμηθευτών, την ένταξη υπηρεσιών cloud, τη λογοδοσία ιδιωτικότητας, την ετήσια ανασκόπηση και τα ελεγκτικά τεκμήρια.
Αντιστοίχιση του πίνακα σε ISO/IEC 27001:2022, NIS2, DORA και GDPR
Το κλασικό λάθος είναι η δημιουργία τεσσάρων ξεχωριστών βιβλίων εργασίας συμμόρφωσης. Ένας έλεγχος μπορεί να καλύπτει πολλές υποχρεώσεις, εφόσον η ευθύνη και τα τεκμήρια είναι ιχνηλάσιμα.
| Περιοχή ελέγχου | ISO/IEC 27001:2022 Annex A | Τεκμήρια παρόχου | Τεκμήρια πελάτη | Αντιστοίχιση με πλαίσια |
|---|---|---|---|---|
| Συμφωνίες προμηθευτών | 5.20 | Σύμβαση, παράρτημα ασφάλειας, DPA, αναφορά διασφάλισης, δέσμευση ειδοποίησης περιστατικού | Αξιολόγηση κινδύνου προμηθευτή, κατάλογος ελέγχου ανασκόπησης σύμβασης, αρχείο έγκρισης | NIS2 Article 21; DORA Article 30; GDPR Article 28; NIST CSF 2.0 GV.SC |
| Εφοδιαστική αλυσίδα ΤΠΕ | 5.21 | Κατάλογος υπεργολάβων επεξεργασίας, όροι υπεργολαβικής ανάθεσης, κατάντη διασφάλιση, ειδοποιήσεις αλλαγών | Μητρώο εξαρτήσεων, ανασκόπηση συγκέντρωσης, ετήσια ανασκόπηση προμηθευτών | NIS2 Article 21; DORA Articles 28 and 29; στόχοι διακυβέρνησης προμηθευτών COBIT 2019 |
| Χρήση υπηρεσιών cloud | 5.23 | Τεκμηρίωση υπηρεσίας, επιλογές τοποθεσίας δεδομένων, εργαλεία εξαγωγής, υποστήριξη διαγραφής | Μητρώο cloud, πρότυπα ρυθμίσεων, σχέδιο εξόδου, ανασκόπηση υπηρεσίας | DORA Articles 6, 8, 28 and 30; GDPR Articles 5, 28 and 32 |
| Ταυτότητα και πρόσβαση | 5.15, 5.16, 5.18 | Δυνατότητα IAM, επιλογές MFA, διαχειριστικοί έλεγχοι, συμβάντα ελέγχου πλατφόρμας | Εφαρμογή MFA, ελάχιστο προνόμιο, ανασκοπήσεις δικαιωμάτων πρόσβασης, αρχεία εισόδου-μετακίνησης-αποχώρησης χρηστών | NIS2 Article 21(2)(i); DORA Article 9; GDPR Article 32 |
| Καταγραφή και παρακολούθηση | 8.15, 8.16 | Αρχεία καταγραφής πλατφόρμας, audit APIs, επιλογές διατήρησης, ειδοποιήσεις υπηρεσίας | Τροφοδότηση SIEM, ανασκοπήσεις ειδοποιήσεων, ρυθμίσεις διατήρησης αρχείων καταγραφής, περιορισμοί πρόσβασης | NIS2 Article 21; DORA Articles 10 and 17; GDPR Article 32 |
| Διαχείριση περιστατικών | 5.24, 5.25, 5.26, 5.27 | Ειδοποιήσεις περιστατικών παρόχου, αιτήματα υποστήριξης, αναφορές ανάλυσης βασικής αιτίας | Playbook περιστατικών, τεκμήρια αρχικής αξιολόγησης, αξιολόγηση ρυθμιστικής υποχρέωσης, διδάγματα που αντλήθηκαν | NIS2 Article 23; DORA Articles 17, 18 and 19; GDPR Articles 33 and 34 |
| Συνέχεια και έξοδος | 5.29, 5.30, 5.23 | Δεσμεύσεις διαθεσιμότητας, εργαλεία εξαγωγής, πιστοποιητικό διαγραφής, υποστήριξη ανάκαμψης | Δοκιμές αντιγράφων ασφαλείας, ασκήσεις ανάκαμψης, δοκιμή εξόδου, ανάκληση πρόσβασης | DORA Articles 11, 24, 28 and 30; NIS2 Article 21; GDPR Article 28 |
Το ISO/IEC 27001:2022 παρέχει τη μηχανή του ISMS: πλαίσιο, ενδιαφερόμενα μέρη, πεδίο εφαρμογής, ηγεσία, αντιμετώπιση κινδύνων, στόχους, επιχειρησιακό έλεγχο, αξιολόγηση απόδοσης και βελτίωση. Το Annex A παρέχει την πρακτική δομή ελέγχων.
Το NIS2 Article 21 αντιστοιχίζεται φυσικά στον ίδιο πίνακα μέσω της ασφάλειας εφοδιαστικής αλυσίδας, του χειρισμού περιστατικών, της συνέχειας, του ελέγχου πρόσβασης, της διαχείρισης περιουσιακών στοιχείων και της ασφαλούς απόκτησης. Το Article 20 καθιστά τον πίνακα σχετικό με το Διοικητικό Συμβούλιο, επειδή τα όργανα διοίκησης πρέπει να εγκρίνουν και να εποπτεύουν τα μέτρα διαχείρισης κινδύνων κυβερνοασφάλειας.
Το DORA μετατρέπει τον πίνακα σε εργαλείο διαχείρισης κινδύνου τρίτων παρόχων ΤΠΕ. Τα Articles 5, 6 and 8 απαιτούν διακυβέρνηση, τεκμηριωμένη διαχείριση κινδύνων ΤΠΕ και αναγνώριση περιουσιακών στοιχείων, λειτουργιών και εξαρτήσεων. Τα Articles 17 to 19 απαιτούν ανίχνευση περιστατικών, ταξινόμηση, κλιμάκωση, επικοινωνία και αναφορά. Τα Articles 28 to 30 απαιτούν διαχείριση κινδύνων τρίτων μερών, ανάλυση κινδύνου συγκέντρωσης, συμβατικές ρήτρες, ελέγχους υπεργολαβικής ανάθεσης, δικαιώματα ελέγχου, δικαιώματα καταγγελίας και στρατηγικές εξόδου.
Ο GDPR προσθέτει την οπτική των δεδομένων προσωπικού χαρακτήρα. Κάθε γραμμή υπηρεσίας cloud πρέπει να προσδιορίζει αν υποβάλλονται σε επεξεργασία δεδομένα προσωπικού χαρακτήρα, αν ο πάροχος είναι εκτελών την επεξεργασία ή υπεργολάβος επεξεργασίας, αν η τοποθεσία δεδομένων έχει σημασία και ποια σύμβαση ή τεκμήρια DPA υπάρχουν.
Το NIST CSF 2.0 βοηθά στην επικοινωνία του ίδιου πίνακα σε γλώσσα αποτελεσμάτων. Η λειτουργία GOVERN καλύπτει οργανωτικό πλαίσιο, νομικές και κανονιστικές απαιτήσεις, εξαρτήσεις, διαχείριση κινδύνων, ρόλους, πολιτικές και εποπτεία. Τα αποτελέσματα GV.SC είναι ιδιαίτερα χρήσιμα για τον κυβερνοκίνδυνο προμηθευτών, συμπεριλαμβανομένων ρόλων προμηθευτών, κρισιμότητας, συμβατικών απαιτήσεων, δέουσας επιμέλειας, παρακολούθησης, συντονισμού περιστατικών και σχεδιασμού καταγγελίας.
Το COBIT 2019 προσθέτει οπτική διασφάλισης και διακυβέρνησης. Εξετάζει αν η λογοδοσία, οι πρακτικές διαχείρισης, η ιδιοκτησία, η παρακολούθηση και η αποκατάσταση ζητημάτων είναι επαναλαμβανόμενες και τεκμηριωμένες.
Δημιουργία του πίνακα από το μητρώο έως την απόδειξη
Φανταστείτε μια εταιρεία SaaS που χρησιμοποιεί πλατφόρμα IaaS hyperscale, διαχειριζόμενη βάση δεδομένων, τρίτο πάροχο ταυτότητας, πλατφόρμα SaaS υποστήριξης πελατών και εξωτερικό SIEM. Η ροή υλοποίησης είναι απλή.
Βήμα 1: Ξεκινήστε με το Μητρώο Υπηρεσιών Cloud
Χρησιμοποιήστε την Cloud Usage Policy ή την Cloud Usage Policy - SME ως έναυσμα. Καταγράψτε κάθε υπηρεσία cloud, ιδιοκτήτη, σκοπό, κατηγορίες δεδομένων, τοποθεσία, επιχειρησιακή λειτουργία, βαθμίδα προμηθευτή, ιδιοκτήτη σύμβασης και ημερομηνία ανασκόπησης.
Αν η υπηρεσία αποθηκεύει αρχεία πελατών, αρχεία καταγραφής αυθεντικοποίησης ή αιτήματα υποστήριξης, χαρακτηρίστε την ως σχετική με την ιδιωτικότητα. Αν υποστηρίζει διαθεσιμότητα παραγωγής, χαρακτηρίστε την ως επιχειρησιακά κρίσιμη. Αν υποστηρίζει κρίσιμη ή σημαντική λειτουργία χρηματοοικονομικού πελάτη, χαρακτηρίστε την ως σχετική με DORA.
Βήμα 2: Προσθέστε τομείς κοινής ευθύνης
Για κάθε υπηρεσία, ορίστε ευθύνες σε βασικούς τομείς.
| Τομέας | Τυπική ευθύνη παρόχου | Τυπική ευθύνη πελάτη | Τυπικό ερώτημα για υπεργολάβο επεξεργασίας |
|---|---|---|---|
| Φυσική ασφάλεια και ασφάλεια υποδομής | Εγκαταστάσεις, υλικό, περιβαλλοντικοί έλεγχοι, ανθεκτικότητα πλατφόρμας | Ανασκόπηση αναφορών διασφάλισης και συμβατικών δεσμεύσεων | Βασίζεται ο πάροχος σε κέντρο δεδομένων, CDN ή υπεργολάβο επεξεργασίας φιλοξενίας; |
| Ταυτότητα και πρόσβαση | Δυνατότητα IAM πλατφόρμας, χαρακτηριστικά διαχειριστικής ασφάλειας, υποστήριξη ομοσπονδιοποίησης | MFA, σχεδιασμός ρόλων, αρχή ελάχιστων προνομίων, ανασκοπήσεις εισόδου-μετακίνησης-αποχώρησης χρηστών | Έχει μεσίτης ταυτότητας ή προμηθευτής υποστήριξης πρόσβαση σε λογαριασμούς; |
| Προστασία δεδομένων | Επιλογές κρυπτογράφησης, επιλογές τοποθεσίας δεδομένων, δυνατότητες αντιγράφων ασφαλείας | Ταξινόμηση, ρύθμιση παραμέτρων κρυπτογράφησης, διατήρηση, νομική βάση | Αποθηκεύει ή προσπελαύνει οποιοσδήποτε υπεργολάβος επεξεργασίας δεδομένα προσωπικού χαρακτήρα; |
| Καταγραφή και παρακολούθηση | Παραγωγή συμβάντων, audit APIs, τηλεμετρία πλατφόρμας | Ενεργοποίηση αρχείων καταγραφής, εξαγωγή σε SIEM, ανασκόπηση ειδοποιήσεων, διατήρηση τεκμηρίων | Επεξεργάζεται ο πάροχος SIEM ή MDR αρχεία καταγραφής που περιέχουν δεδομένα προσωπικού χαρακτήρα; |
| Απόκριση σε περιστατικά | Ανίχνευση από τον πάροχο, ειδοποιήσεις περιστατικών πλατφόρμας, κλιμάκωση υποστήριξης | Εσωτερική αρχική αξιολόγηση, ειδοποιήσεις προς ρυθμιστικές αρχές και πελάτες, διατήρηση τεκμηρίων | Μπορούν κατάντη περιστατικά να καθυστερήσουν την ειδοποίηση ή την ανάλυση βασικής αιτίας; |
| Συνέχεια και έξοδος | Δεσμεύσεις διαθεσιμότητας πλατφόρμας, εργαλεία εξαγωγής, υποστήριξη διαγραφής | Στόχοι ανάκαμψης, δοκιμές αντιγράφων ασφαλείας, σχέδιο εξόδου, επιστροφή ή καταστροφή δεδομένων | Υπάρχουν περιορισμοί ανάκαμψης από υπεργολαβικά ανατεθειμένες υπηρεσίες ή τοποθεσίες; |
Βήμα 3: Συνδέστε τους ελέγχους με τον κίνδυνο και τη Δήλωση Εφαρμοσιμότητας
Το Zenith Blueprint, φάση Risk Management, Step 13, εξηγεί την απαίτηση ιχνηλασιμότητας:
«Διασταυρώστε τους κανονισμούς: Αν ορισμένοι έλεγχοι εφαρμόζονται ειδικά για συμμόρφωση με GDPR, NIS2 ή DORA, μπορείτε να το σημειώσετε είτε στο Μητρώο Κινδύνων (ως μέρος της αιτιολόγησης αντικτύπου κινδύνου) είτε στις σημειώσεις της SoA.»
Για παράδειγμα, ο κίνδυνος «μη εξουσιοδοτημένη πρόσβαση σε δεδομένα παραγωγής πελατών μέσω εσφαλμένης ρύθμισης παραμέτρων cloud» μπορεί να αντιστοιχιστεί σε έλεγχο πρόσβασης, χρήση υπηρεσιών cloud, καταγραφή, κρυπτογραφία, διαχείριση ευπαθειών και συμφωνίες προμηθευτών. Η SoA μπορεί να παραπέμπει σε ISO/IEC 27001:2022 Annex A 5.15, 5.16, 5.20, 5.23, 8.8, 8.15, 8.16 και 8.24, με σημειώσεις για GDPR Article 32, NIS2 Article 21 και διαχείριση κινδύνων ΤΠΕ DORA, όπου εφαρμόζεται.
Βήμα 4: Συνδέστε τεκμήρια πριν από την περίοδο ελέγχου
Τα τεκμήρια πρέπει να σχεδιάζονται μέσα στον πίνακα, όχι να συλλέγονται υπό πίεση.
| Γραμμή πίνακα | Τεκμήρια προς διατήρηση |
|---|---|
| Δέουσα επιμέλεια παρόχου υπηρεσιών cloud | Αξιολόγηση προμηθευτή, ερωτηματολόγιο ασφάλειας, αναφορά διασφάλισης, πιστοποιήσεις, διαβάθμιση κινδύνου, αρχείο έγκρισης |
| Συμβατικές δεσμεύσεις ασφάλειας | MSA, DPA, παράρτημα ασφάλειας, δικαιώματα ελέγχου, ρήτρα υπεργολαβικής ανάθεσης, ρήτρα ειδοποίησης περιστατικού, όροι τοποθεσίας δεδομένων |
| Ευθύνη ρύθμισης παραμέτρων πελάτη | Εξαγωγή ρύθμισης παραμέτρων cloud, πολιτική IAM, αναφορά MFA, ρυθμίσεις κρυπτογράφησης, κανόνες δικτύου, αιτήματα αλλαγών |
| Καταγραφή και παρακολούθηση | Ρυθμίσεις διατήρησης αρχείων καταγραφής, δείγματα αρχείων καταγραφής ελέγχου, απόδειξη τροφοδότησης SIEM, αρχεία ανασκόπησης ειδοποιήσεων, αιτήματα κλιμάκωσης |
| Ιχνηλασιμότητα υπεργολάβων επεξεργασίας | Κατάλογος υπεργολάβων επεξεργασίας παρόχου, αρχείο έγκρισης, αποτύπωση ροής δεδομένων, σημειώσεις ετήσιας ανασκόπησης, ειδοποίηση αλλαγών |
| Έξοδος και ανάκαμψη | Αποτελέσματα δοκιμών αντιγράφων ασφαλείας, δοκιμή εξαγωγής δεδομένων, πιστοποιητικό διαγραφής, σχέδιο εξόδου, αναφορά άσκησης ανάκαμψης |
Ο κατάλογος τεκμηρίων μετατρέπει την ευθύνη σε απόδειξη. Βοηθά επίσης τις εμπορικές ομάδες να απαντούν ταχύτερα στη δέουσα επιμέλεια εταιρικών πελατών, επειδή μπορούν να παρουσιάζουν όχι μόνο πιστοποιήσεις, αλλά και ιδιοκτησία ελέγχων και λειτουργικά τεκμήρια.
Υπεργολάβοι επεξεργασίας: το τυφλό σημείο στους περισσότερους πίνακες
Οι υπεργολάβοι επεξεργασίας είναι το σημείο όπου η κοινή ευθύνη γίνεται πραγματικός κίνδυνος εφοδιαστικής αλυσίδας.
Ένας πάροχος SaaS μπορεί να είναι ο εκτελών την επεξεργασία σας βάσει GDPR. Αυτός ο πάροχος μπορεί να βασίζεται σε πάροχο φιλοξενίας cloud, CDN, υπηρεσία analytics, πλατφόρμα υποστήριξης, υπηρεσία αποστολής ηλεκτρονικού ταχυδρομείου, διαχειριζόμενη βάση δεδομένων, πάροχο παρατηρησιμότητας και εκτελούντα την επεξεργασία πληρωμών. Κάποιοι μπορεί να έχουν πρόσβαση σε δεδομένα προσωπικού χαρακτήρα. Κάποιοι μπορεί να υποστηρίζουν κρίσιμη παροχή υπηρεσιών χωρίς να βλέπουν άμεσα δεδομένα. Κάποιοι μπορεί να βρίσκονται εκτός ΕΕ. Κάποιοι μπορεί να μπορούν να αντικατασταθούν. Άλλοι μπορεί να δημιουργούν κίνδυνο συγκέντρωσης.
Το DORA Article 29 απαιτεί αξιολόγηση κινδύνου συγκέντρωσης για κρίσιμες ή σημαντικές υπηρεσίες ΤΠΕ, συμπεριλαμβανομένων της δυνατότητας υποκατάστασης, πολλαπλών ρυθμίσεων με τον ίδιο ή συνδεδεμένους παρόχους, αλυσίδων υπεργολαβικής ανάθεσης, υπεργολάβων τρίτων χωρών, δικαίου αφερεγγυότητας, περιορισμών ανάκτησης δεδομένων και δυνατότητας εφαρμογής της προστασίας δεδομένων της Ένωσης. Το DORA Article 30 απαιτεί συμβατικές διατάξεις σχετικά με όρους υπεργολαβικής ανάθεσης, τοποθεσίες, επεξεργασία και αποθήκευση δεδομένων, πρόσβαση και ανάκτηση, συνδρομή σε περιστατικά, συνεργασία με αρχές, δικαιώματα ελέγχου, καταγγελία και έξοδο.
Το NIS2 Article 21 απαιτεί αντίστοιχα ασφάλεια εφοδιαστικής αλυσίδας για άμεσους προμηθευτές και παρόχους υπηρεσιών, καθώς και εξέταση ευπαθειών ειδικών ανά προμηθευτή, πρακτικών κυβερνοασφάλειας προμηθευτών και διαδικασιών ασφαλούς ανάπτυξης.
Γι’ αυτό η Clarysec αντιμετωπίζει τη χαρτογράφηση υπεργολάβων επεξεργασίας ως απαιτούμενη επέκταση της διακυβέρνησης προμηθευτών, όχι ως απλό κατάλογο ιδιωτικότητας. Το μητρώο υπεργολάβων επεξεργασίας πρέπει να δείχνει ποιος προμηθευτής χρησιμοποιεί τον υπεργολάβο επεξεργασίας, ποια υπηρεσία εξαρτάται από αυτόν, αν υποβάλλονται σε επεξεργασία δεδομένα προσωπικού χαρακτήρα, αν υποστηρίζει κρίσιμη λειτουργία, την περιοχή επεξεργασίας όπου είναι σχετικό, τις μετακυλιόμενες υποχρεώσεις, δικαιώματα έγκρισης ή αντίρρησης, διαθέσιμη διασφάλιση, μέθοδο παρακολούθησης και επιλογή εξόδου.
Το Zenith Blueprint, στη φάση Controls in Action, Step 23 ορίζει:
«Για κάθε κρίσιμο προμηθευτή, προσδιορίστε αν χρησιμοποιεί υπεργολάβους (υπεργολάβους επεξεργασίας) που μπορεί να έχουν πρόσβαση στα δεδομένα ή στα συστήματά σας. Τεκμηριώστε πώς οι απαιτήσεις ασφάλειας πληροφοριών σας μετακυλίονται σε αυτά τα μέρη, είτε μέσω των συμβατικών όρων του προμηθευτή σας είτε μέσω δικών σας άμεσων ρητρών.»
Αυτό είναι το επίπεδο απόδειξης που αναμένουν οι ελεγκτές όταν ρωτούν αν οι ευθύνες στο cloud ελέγχονται κατάντη.
Πώς οι ελεγκτές δοκιμάζουν τον ίδιο πίνακα
Ένας ισχυρός πίνακας κατανομής ευθυνών στο cloud αντέχει σε πολλαπλά στυλ ελέγχου, επειδή είναι δομημένος γύρω από την ιδιοκτησία, την εφαρμοσιμότητα και τα τεκμήρια.
| Οπτική ελέγχου | Τι θα δοκιμάσει ο ελεγκτής | Τεκμήρια που θα αναμένει |
|---|---|---|
| Ελεγκτής ISO/IEC 27001:2022 | Πεδίο εφαρμογής ISMS, ενδιαφερόμενα μέρη, αξιολόγηση κινδύνων, εφαρμοσιμότητα SoA, έλεγχοι προμηθευτών, χρήση υπηρεσιών cloud, λειτουργικά τεκμήρια και συνεχής βελτίωση | Πεδίο εφαρμογής ISMS, Μητρώο Κινδύνων, SoA, μητρώο προμηθευτών, μητρώο cloud, συμβάσεις, αρχεία ανασκόπησης, ευρήματα εσωτερικού ελέγχου, διορθωτικές ενέργειες |
| Ανασκοπητής ετοιμότητας NIS2 | Έγκριση διοίκησης, κάλυψη ελέγχων Article 21, ασφάλεια εφοδιαστικής αλυσίδας, χειρισμός περιστατικών, συνέχεια, πρόσβαση, διαχείριση περιουσιακών στοιχείων και αξιολόγηση αποτελεσματικότητας | Αναφορές προς το Διοικητικό Συμβούλιο, εγκρίσεις πολιτικών, ανασκοπήσεις κινδύνου προμηθευτών, playbooks περιστατικών, δοκιμές συνέχειας, τεκμήρια MFA, αρχεία ευπαθειών και καταγραφής |
| Αξιολογητής DORA | Διακυβέρνηση ΤΠΕ, πλαίσιο κινδύνων ΤΠΕ, αποθετήριο περιουσιακών στοιχείων και εξαρτήσεων, κρίσιμες ρυθμίσεις τρίτων παρόχων ΤΠΕ, συμβατικές ρήτρες, κίνδυνος συγκέντρωσης, δοκιμές και στρατηγική εξόδου | Πλαίσιο κινδύνων ΤΠΕ, μητρώο υπηρεσιών ΤΠΕ, αξιολόγηση κρισιμότητας, συμβάσεις, δικαιώματα ελέγχου, αρχεία περιστατικών, δοκιμές ανθεκτικότητας, δοκιμές εξόδου, ανάλυση υπεργολαβικής ανάθεσης |
| Ανασκοπητής GDPR | Ρόλοι υπεύθυνου επεξεργασίας και εκτελούντος την επεξεργασία, σκοποί επεξεργασίας δεδομένων, ακεραιότητα και εμπιστευτικότητα, ετοιμότητα για παραβίαση, συμβάσεις εκτελούντων την επεξεργασία και διαφάνεια υπεργολάβων επεξεργασίας | Αρχείο επεξεργασίας, DPA, κατάλογος υπεργολάβων επεξεργασίας, αποτύπωση ροής δεδομένων, μέτρα ασφάλειας, διαδικασία παραβίασης, τεκμήρια διατήρησης και διαγραφής |
| Αξιολογητής NIST CSF | Αποτελέσματα GOVERN, κυβερνοκίνδυνος προμηθευτών, αποθετήριο περιουσιακών στοιχείων, έλεγχος πρόσβασης, ασφάλεια δεδομένων, παρακολούθηση, απόκριση και ανάκαμψη | Τρέχον και στοχευόμενο προφίλ, διαδικασία κινδύνου προμηθευτών, αποθετήριο περιουσιακών στοιχείων, αναφορές πρόσβασης, αρχεία παρακολούθησης, ασκήσεις περιστατικών, απόδειξη ανάκαμψης |
| Ελεγκτής COBIT 2019 ή ISACA | Λογοδοσία διακυβέρνησης, πρακτικές διαχείρισης, ιδιοκτησία ελέγχων, παρακολούθηση απόδοσης, διαχείριση ζητημάτων και ιχνηλασιμότητα διασφάλισης | RACI, πρακτικά διακυβέρνησης, εξαιρέσεις πολιτικών, KPIs, κάρτες αξιολόγησης προμηθευτών, αρχεία ζητημάτων, αποτελέσματα ανασκόπησης της Διοίκησης |
Ο πίνακας δεν είναι ο τελικός στόχος. Είναι ο χάρτης που χρησιμοποιούν οι ελεγκτές για να δοκιμάσουν αν το σύστημα διακυβέρνησης είναι πραγματικό.
Ένας ελεγκτής ISO μπορεί να επιλέξει έναν υψηλού αντικτύπου κίνδυνο πρόσβασης στο cloud και να τον ιχνηλατήσει από το Μητρώο Κινδύνων στη SoA, έπειτα στις ανασκοπήσεις δικαιωμάτων πρόσβασης, στα τεκμήρια MFA και στις ειδοποιήσεις παρακολούθησης. Ένας αξιολογητής DORA μπορεί να επιλέξει έναν κρίσιμο πάροχο ΤΠΕ και να ζητήσει τη δοκιμή εξόδου, την ανάλυση υπεργολαβικής ανάθεσης και τα συμβατικά δικαιώματα ελέγχου. Ένας ανασκοπητής GDPR μπορεί να εστιάσει στη διαγραφή, στην τοποθεσία δεδομένων, στην κοινοποίηση παραβίασης και στη διαφάνεια υπεργολάβων επεξεργασίας.
Συνήθη μοτίβα αστοχίας
Οι πιο συχνές αστοχίες κατανομής ευθυνών δεν είναι εξεζητημένες.
Πρώτον, οι οργανισμοί βασίζονται σε αναφορές διασφάλισης παρόχων χωρίς να τις αντιστοιχίζουν στις ευθύνες πελατών. Ένας πάροχος υπηρεσιών cloud μπορεί να αποδείξει φυσική ασφάλεια, ανθεκτικότητα υποδομής και ελέγχους πλατφόρμας, αλλά όχι αν ο κάδος αποθήκευσής σας ήταν ιδιωτικός, οι ρόλοι IAM τηρούσαν την αρχή ελάχιστων προνομίων ή τα αρχεία καταγραφής ήταν ενεργοποιημένα.
Δεύτερον, οι συμβάσεις περιέχουν γενική γλώσσα ασφάλειας αλλά όχι χρονοδιαγράμματα περιστατικών, δικαιώματα πρόσβασης σε αρχεία καταγραφής, δικαιώματα ελέγχου, περιορισμούς υπεργολαβικής ανάθεσης, διατάξεις επιστροφής δεδομένων ή υποστήριξη εξόδου. Το Zenith Blueprint, στη φάση Controls in Action, Step 23 επισημαίνει τυπικές περιοχές συμφωνιών προμηθευτών όπως εμπιστευτικότητα, έλεγχος πρόσβασης, τεχνικά και οργανωτικά μέτρα, χρονοδιαγράμματα περιστατικών, δικαίωμα ελέγχου, έλεγχοι υπεργολάβων και διατάξεις λήξης σύμβασης.
Τρίτον, οι υπεργολάβοι επεξεργασίας καταγράφονται για σκοπούς ιδιωτικότητας αλλά δεν συνδέονται με κίνδυνο ασφάλειας, συνέχειας ή συγκέντρωσης. Ένας κατάντη πάροχος παρατηρησιμότητας ή υποστήριξης μπορεί να μην εμφανίζεται ποτέ στο Μητρώο Κινδύνων, παρότι η διακοπή ή η παραβίασή του θα μπορούσε να επηρεάσει την παροχή υπηρεσιών σε πελάτες.
Τέταρτον, η SoA λέει ότι ένας έλεγχος είναι εφαρμόσιμος, αλλά κανείς δεν μπορεί να προσκομίσει λειτουργικά τεκμήρια. Η καταγραφή στο cloud μπορεί να έχει χαρακτηριστεί ως υλοποιημένη, αλλά ο οργανισμός δεν μπορεί να αποδείξει ρυθμίσεις διατήρησης, ανασκοπήσεις δικαιωμάτων πρόσβασης, χειρισμό ειδοποιήσεων ή δεσμεύσεις πρόσβασης σε αρχεία καταγραφής παρόχου.
Πέμπτον, τα σχέδια απόκρισης σε περιστατικά δεν αντικατοπτρίζουν την εξάρτηση από τον πάροχο. Αν ο πάροχος κοινοποιήσει ένα περιστατικό πλατφόρμας, ποιος αξιολογεί τον αντίκτυπο στους πελάτες; Ποιος καθορίζει αν απαιτείται ειδοποίηση βάσει NIS2, DORA ή GDPR; Ποιος επικοινωνεί με τους επηρεαζόμενους πελάτες; Τι γίνεται αν η βασική αιτία βρίσκεται σε υπεργολάβο επεξεργασίας;
Λογοδοσία διοίκησης: γιατί πρέπει να ενδιαφέρει το Διοικητικό Συμβούλιο
Το NIS2 Article 20 απαιτεί από τα όργανα διοίκησης να εγκρίνουν τα μέτρα διαχείρισης κινδύνων κυβερνοασφάλειας, να εποπτεύουν την υλοποίηση και να λαμβάνουν εκπαίδευση. Το DORA Article 5 απαιτεί από το όργανο διοίκησης να ορίζει, να εγκρίνει, να εποπτεύει και να είναι υπεύθυνο για τις ρυθμίσεις διαχείρισης κινδύνων ΤΠΕ, συμπεριλαμβανομένων πολιτικών τρίτων παρόχων ΤΠΕ, σχεδίων συνέχειας και ανάκαμψης, σχεδίων ελέγχων, εκπαίδευσης και διαύλων αναφοράς.
Αυτό αλλάζει τον σκοπό του πίνακα. Δεν είναι πλέον μόνο φύλλο εργασίας ασφάλειας. Γίνεται τεκμήριο ότι η διοίκηση γνωρίζει:
- Ποιες υπηρεσίες cloud υποστηρίζουν κρίσιμες λειτουργίες.
- Ποια τρίτα μέρη και ποιοι υπεργολάβοι επεξεργασίας είναι ουσιώδεις.
- Ποιες υποχρεώσεις εφαρμόζονται βάσει συμβάσεων πελατών, GDPR, NIS2 και DORA.
- Ποιες ευθύνες παραμένουν στον οργανισμό.
- Ποιες δεσμεύσεις παρόχων είναι συμβατικά εφαρμόσιμες.
- Ποια κενά απαιτούν χρηματοδότηση, αποκατάσταση ή αποδοχή κινδύνου.
Για SMEs, η αναλογικότητα έχει σημασία. Μια μικρότερη οντότητα δεν χρειάζεται βαριά γραφειοκρατία, αλλά εξακολουθεί να χρειάζεται τεκμηρίωση, παρακολούθηση, ανθεκτικά συστήματα, ανίχνευση πηγών κινδύνου ΤΠΕ, αναγνώριση βασικών εξαρτήσεων από τρίτους, μέτρα συνέχειας, δοκιμές, διδάγματα που αντλήθηκαν και περιοδική ανασκόπηση όπου εμπίπτει στο πεδίο εφαρμογής.
Ο πίνακας είναι ένα από τα πιο αποδοτικά αναλογικά εργαλεία, επειδή ενοποιεί υποχρεώσεις αντί να τις πολλαπλασιάζει.
Sprint 30 ημερών για να καταστήσετε το μοντέλο cloud έτοιμο για έλεγχο
Αν δεν μπορείτε να απαντήσετε ποιος είναι υπεύθυνος για κάθε έλεγχο στο cloud, ποια τεκμήρια το αποδεικνύουν και ποιος υπεργολάβος επεξεργασίας θα μπορούσε να τον επηρεάσει, το μοντέλο κοινής ευθύνης σας παραμένει διάγραμμα, όχι τεκμήριο διακυβέρνησης.
Ένα πρακτικό sprint 30 ημερών έχει ως εξής:
- Δημιουργήστε ή επικαιροποιήστε το Μητρώο Υπηρεσιών Cloud χρησιμοποιώντας την Cloud Usage Policy ή την Cloud Usage Policy - SME.
- Προσδιορίστε κρίσιμες υπηρεσίες, επεξεργασία δεδομένων προσωπικού χαρακτήρα, συστήματα με πρόσβαση πελατών και συνάφεια με DORA ή NIS2.
- Δημιουργήστε τον πρώτο πίνακα γύρω από τους ελέγχους ISO/IEC 27001:2022 Annex A 5.20, 5.21 και 5.23 χρησιμοποιώντας το Zenith Controls.
- Συνδέστε κάθε γραμμή με το Μητρώο Κινδύνων και τη Δήλωση Εφαρμοσιμότητας χρησιμοποιώντας το Step 13 του Zenith Blueprint.
- Επικυρώστε ρήτρες προμηθευτών και εκτελούντων την επεξεργασία χρησιμοποιώντας τις Third party and supplier security policy, Third-Party and Supplier Security Policy - SME και Data Protection and Privacy Policy.
- Προσθέστε διατήρηση αρχείων καταγραφής, κλιμάκωση περιστατικών, έγκριση υπεργολάβων επεξεργασίας, δικαιώματα ελέγχου και τεκμήρια εξόδου.
- Ανασκοπείτε τους κρίσιμους προμηθευτές ετησίως, καθώς και μετά από σημαντικές αλλαγές, περιστατικά, νέους υπεργολάβους επεξεργασίας ή ευρήματα ελέγχου.
Ο στόχος είναι απλός. Όταν ο πελάτης, ο ελεγκτής, η ρυθμιστική αρχή ή το Διοικητικό Συμβούλιο ρωτήσει «ποιος είναι υπεύθυνος για αυτόν τον έλεγχο;», δεν αναζητάτε την απάντηση σε συμβάσεις, αιτήματα και φακέλους. Ανοίγετε τον πίνακα, δείχνετε τον ιδιοκτήτη, δείχνετε τη ρήτρα, δείχνετε τα τεκμήρια και δείχνετε τη διαδρομή προς τα κατάντη μέρη.
Η Clarysec μπορεί να σας βοηθήσει να μετατρέψετε τα πακέτα διασφάλισης παρόχων υπηρεσιών cloud σε ενοποιημένο πίνακα κατανομής ευθυνών για ελέγχους ISO/IEC 27001:2022, ετοιμότητα NIS2, κίνδυνο τρίτων παρόχων ΤΠΕ DORA, λογοδοσία GDPR και δέουσα επιμέλεια εταιρικών πελατών.
Ξεκινήστε με το μητρώο. Δημιουργήστε τον πίνακα. Συνδέστε τα τεκμήρια. Έπειτα χρησιμοποιήστε τον ως απόδειξη έτοιμη για το Διοικητικό Συμβούλιο ότι ο κίνδυνος στο cloud δεν ανατίθεται εξωτερικά· διέπεται.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
