Η πολλαπλή επαλήθευση, συχνά γνωστή ως MFA, είναι ένας δεύτερος έλεγχος πέρα από έναν κωδικό πρόσβασης: ένας κωδικός από μια εφαρμογή, ένα SMS ή ένα φυσικό κλειδί. Το ερώτημα εάν αυτό είναι υποχρεωτικό για ένα λογισμικοβιομηχανία δεν μπορεί να απαντηθεί με ένα απλό ναι ή όχι, διότι η Οδηγία NIS2 δεν καθορίζει κανένα συγκεκριμένο τεχνικό μέσο. Το άρθρο 21 υποχρεώνει τους φορείς που υπόκεινται στην υποχρέωση επιμέλειας να λαμβάνουν κατάλληλα μέτρα για την ασφάλεια της πρόσβασης και την πολλαπλή ταυτοποίηση, και οι εποπτικές αρχές εξετάζουν που είναι ο κίνδυνος μεγαλύτερος.
Για ένα λογισμικοβιομηχανία, αυτά είναι στην πράξη δύο εντελώς διαφορετικές περιοχές: η γραμμή ανάπτυξης με την οποία εργάζεστε εσείς, και το λογισμικό που παρέχετε στους πελάτες. Και οι δύο απαιτούν δικής τους αξιολόγηση, και αυτή η αξιολόγηση δεν είναι το ίδιο αυστηρή παντού.
Δύο περιοχές όπου η πολλαπλή επαλήθευση παίζει ρόλο
Η πρώτη περιοχή είναι εσωτερική: το περιβάλλον στο οποίο εργάζονται οι προγραμματιστές σας. Πηγαίος κώδικας, η γραμμή ανάπτυξης, κονσόλες cloud και τα συστήματα με τα οποία αναπτύσσετε σε παραγωγή. Η δεύτερη περιοχή είναι στο ίδιο το προϊόν: εάν το λογισμικό που δημιουργείτε ή παρέχετε έχει μια οθόνη σύνδεσης, η πολλαπλή επαλήθευση είναι επίσης θέμα εκεί, τόσο για τους δικούς σας χρήστες όσο και για τους τελικούς χρήστες του πελάτη σας. Ένας κατάλογος ερωτήσεων ασφάλειας από έναν πελάτη ζητάει σχεδόν πάντα και τα δύο, συχνά σε ξεχωριστές ερωτήσεις που διατυπώνονται ελαφρώς διαφορετικά από ό,τι θα περιμένατε.
Στην πρόσβαση στη γραμμή ανάπτυξής σας
Εδώ είναι η ισχυρότερη προσδοκία. Ποιος μπορεί να έχει πρόσβαση στον πηγαίο κώδικα, ποιος μπορεί να αναπτύσσει σε παραγωγή, και ποιος έχει δικαιώματα διαχειριστή στο περιβάλλον cloud, δημιουργεί το μεγαλύτερο κίνδυνο εάν ένας κωδικός πρόσβασης μόνο κλαπεί ή επανάληφθεί. Για αυτούς τους λογαριασμούς, η πολλαπλή επαλήθευση θεωρείται βασικό μέτρο σε σχεδόν κάθε πλαίσιο ασφάλειας, και είναι επίσης το πρώτο που περιμένουν οι εποπτικές αρχές και οι πελάτες. Διαχείριση εκδόσεων, η ίδια η γραμμή ανάπτυξης, και ιδιαίτερα κάθε λογαριασμός με δικαιώματα για την ανάπτυξη κώδικα σε παραγωγή, θα πρέπει στην πράξη χωρίς εξαίρεση να προστατεύονται με ένα δεύτερο βήμα.
Αυτό περιλαμβάνει επίσης ένα βήμα προς τα πίσω για το ποιος στην πραγματικότητα χρειάζεται ακόμα αυτή την πρόσβαση. Ένα αρχείο στο οποίο αναφέρεται ανά σύστημα ποιος επιτρέπεται και γιατί, κάνει ευκολότερο να απαντηθεί σε αυτή την ερώτηση σε έναν κατάλογο ερωτήσεων με μια συγκεκριμένη απάντηση αντί για μια υπόθεση. πώς η διαχείριση πρόσβασης και η πολλαπλή επαλήθευση εξηγούνται ανά θέμα δίνει ένα σημείο εκκίνησης για αυτό.
Στο λογισμικό που παρέχετε
Το δεύτερο επίπεδο είναι το ίδιο το λογισμικό. Εάν το προϊόν σας έχει μια λειτουργία σύνδεσης, η ερώτηση εάν προσφέρετε πολλαπλή επαλήθευση σχεδόν πάντα επιστρέφει σε έναν κατάλογο ερωτήσεων ασφάλειας, και μερικές φορές ακόμα και ως ρήτρα σύμβασης. Αυτή είναι μια διαφορετική αξιολόγηση από ό,τι στη δική σας γραμμή ανάπτυξης: εδώ δεν θα πρόκειται για το τι χρησιμοποιείτε εσείς, αλλά για το τι παρέχετε στον πελάτη σας. Ένας πελάτης που υπόκειται και ο ίδιος στην υποχρέωση επιμέλειας, πρέπει σύμφωνα με το άρθρο 21 να αξιολογήσει επίσης την αλυσίδα του, και η ερώτηση εάν το προϊόν σας υποστηρίζει ισχυρή ταυτοποίηση είναι μέρος αυτού.
Η απάντηση δεν χρειάζεται να είναι ότι είναι υποχρεωτικό να είναι ενεργοποιημένο παντού. Συχνά αρκεί να δείξετε ότι η δυνατότητα υπάρχει, ότι οι χρήστες ενθαρρύνονται να την χρησιμοποιήσουν, και ότι έχετε ένα σχέδιο για την επέκτασή της όπου ο κίνδυνος το δικαιολογεί.
Πού είναι λιγότερο προφανές
Δεν χρειάζονται όλοι οι λογαριασμοί ή όλα τα περιβάλλοντα το ίδιο επίπεδο ασφάλειας. Ένα περιβάλλον δοκιμών χωρίς πραγματικά δεδομένα πελατών, ένα εσωτερικό σύστημα τεκμηρίωσης με μόνο δικαιώματα ανάγνωσης, ή ένα απομονωμένο εργαλείο που χρησιμοποιείται περιστασιακά από έναν προγραμματιστή, παρουσιάζουν διαφορετικούς κινδύνους από ένα λογαριασμό με πρόσβαση στην παραγωγή. Η υποχρέωση διαχείρισης κινδύνων απαιτεί μέτρα που ταιριάζουν στους κινδύνους, όχι την εφαρμογή ενός ενιαίου αυστηρού πρωτοκόλλου παντού. Οι εποπτικές αρχές αξιολογούν αυτό το θέμα με βάση την αναλογικότητα, και αυτό σημαίνει ότι μια τεκμηριωμένη απόφαση να μην εφαρμοστεί πολυπλή επαλήθευση σε κάποιο σημείο μπορεί να είναι εξίσου σημαντικό μέρος ενός δοσιέ όπως τα σημεία όπου εφαρμόζεται.
Η τεκμηρίωση είναι εδώ η πιο σημαντική λέξη. Μια απόφαση χωρίς εξήγηση φαίνεται σε μια λίστα ερωτήσεων γρήγορα ως παράλειψη, ενώ η ίδια απόφαση με μια σύντομη αιτιολόγηση είναι συχνά ακριβώς η απάντηση που αναζητά ένας εργοδότης.
Τι σημαίνει αυτό για τη συζήτηση με έναν εργοδότη
Ένας εργοδότης που στέλνει μια λίστα ερωτήσεων συνήθως δεν θέλει να ξέρει αν συμμορφώνεστε σε κάθε λέξη, αλλά αν ξέρετε πού βρίσκονται οι κίνδυνοί σας και αν τους αντιμετωπίζετε σωστά. Για την πολυπλή επαλήθευση αυτό σημαίνει: να μπορείτε να δείξετε τι υπάρχει στη γραμμή ανάπτυξης, τι υπάρχει στο προϊόν, και γιατί τα υπόλοιπα είναι διαρρυθμισμένα διαφορετικά. Αυτός που έχει καταγράψει αυτό ανά σύστημα με κατάσταση και υπεύθυνο, δεν χρειάζεται να ψάξει ξανά την ερώτηση τη στιγμή που η επόμενη λίστα ερωτήσεων φτάνει.
Το αν και πώς αυτό εξελίσσεται ακριβώς για τον οργανισμό σας εξαρτάται από τον ρόλο σας στην εφοδιαστική αλυσίδα και από το τι ζητούν συγκεκριμένα οι πελάτες σας· σε περίπτωση αμφιβολίας, συμβουλευθείτε το κείμενο της ίδιας της οδηγίας ή έναν σύμβουλο. Αν θέλετε πρώτα να ξέρετε πού βρίσκεστε, το δωρεάν έλεγχος σε μερικές ερωτήσεις δίνει μια πρώτη ένδειξη, και μια εξήγηση για το πού προέρχονται οι πληροφορίες δείχνει πώς προκύπτει αυτή η ένδειξη.
Αν θέλετε να διαβάσετε ευρύτερα πώς αυτό το θέμα σχετίζεται με τα άλλα μέτρα της υποχρέωσης διαχείρισης κινδύνων, θα το βρείτε σε την επισκόπηση των θεμάτων ανά περίστασηΤο quick-scan και η βάση γνώσης είναι ελεύθερα προσβάσιμα, χωρίς να χρειάζεται να δημιουργήσετε λογαριασμό.