Απόρριψη αιτήματος MFA στο VPN: τι πρέπει να κάνει ο πελάτης
Ένα απορριφθέν αίτημα MFA είναι αποτυχημένη σύνδεση, όχι βρόχος επαναλήψεων. Προσδιορίστε το αίτημα, κρατήστε την αποτυχία ορατή και καταγράψτε τι θα ζητήσει η υποστήριξη.
Ένα απορριφθέν αίτημα MFA μοιάζει με πρόβλημα δικτύου και δεν είναι. Ο διακομιστής ζήτησε δεύτερο παράγοντα, ο παράγοντας επέστρεψε αρνητικός ή δεν έφτασε ποτέ, και η συνεδρία απορρίφθηκε πριν υπάρξει κανένα τούνελ. Το τι συμβαίνει μετά είναι ζήτημα συμπεριφοράς του πελάτη: να εμφανίσει την αποτυχία και να αφήσει τον χρήστη να ξεκινήσει μια καθαρή προσπάθεια, ή να επαναλαμβάνει με τρόπους που παράγουν περισσότερα αιτήματα και τελικά ενεργοποιούν την προστασία λογαριασμού. Ο δεύτερος δρόμος είναι το πώς ένας λάθος πληκτρολογημένος κωδικός γίνεται κλειδωμένος λογαριασμός.
Ελέγξτε ποιο αίτημα απέτυχε
Ξεκινήστε προσδιορίζοντας ποιο αίτημα απέτυχε. Μια ειδοποίηση push, ένας κωδικός TOTP, μια δήλωση FIDO και μια ροή SAML αποτυγχάνουν το καθένα διαφορετικά, και ο πελάτης συνήθως ξέρει ποιο ζήτησε. Μια άρνηση, μια ληγμένη πρόκληση και μια αποτυχία παράδοσης που δεν έφτασε ποτέ στη συσκευή καταλήγουν όλα στο ίδιο γενικό σφάλμα, οπότε η κατάσταση του ίδιου του πελάτη είναι συχνά το μόνο μέρος όπου η διαφορά επιβιώνει.
Αξίζει να καταγράφεται αυτή η κατάσταση με ακρίβεια. Καταγράψτε το αναγνωριστικό πρόκλησης ή την αναφορά συναλλαγής, τον τύπο παράγοντα, τη χρονική σφραγίδα και το αποτέλεσμα, αλλά ποτέ τον κωδικό ή τη δήλωση. Το αναγνωριστικό πρόκλησης είναι αυτό που επιτρέπει σε έναν διαχειριστή να βρει το συμβάν στην πλευρά του παρόχου ταυτότητας· χωρίς αυτό, η συζήτηση με την υποστήριξη ξεκινά με «κάποια στιγμή την τελευταία ώρα» και συνήθως τελειώνει εκεί. Αντιμετωπίστε το ως διαγνωστικά μεταδεδομένα, όχι ως μυστικό.
Επαναλάβετε μία φορά, σκόπιμα, με νέα πρόκληση
Μια επανάληψη πρέπει να είναι νέα προσπάθεια με νέα πρόκληση, όχι αναπαραγωγή της παλιάς. Όταν ο πελάτης επαναχρησιμοποιεί την προηγούμενη πρόκληση, ο πάροχος ταυτότητας είτε την απορρίπτει ως παρωχημένη είτε, το χειρότερο, δέχεται μια έγκριση που προοριζόταν για την προηγούμενη προσπάθεια. Ζητήστε νέα πρόκληση, δείξτε την και αφήστε τον χρήστη να ενεργήσει σε αυτή που είναι τώρα στην οθόνη.
Δύο προσπάθειες με μια σύντομη παύση ανάμεσά τους είναι λογική προεπιλογή· ένας απεριόριστος βρόχος δεν είναι. Αν η δεύτερη προσπάθεια αποτύχει με τον ίδιο τρόπο, σταματήστε και αναφέρετε αντί να συνεχίσετε.
Τι δεν πρέπει να κάνει ο πελάτης
Ο πελάτης δεν πρέπει να κάνει αρκετά πράγματα που φαίνονται χρήσιμα και δεν είναι. Δεν πρέπει να συνεχίζει να στέλνει ειδοποιήσεις push μέχρι κάποιος να πατήσει «έγκριση», γιατί αυτό εκπαιδεύει τους χρήστες να εγκρίνουν αιτήματα που δεν ξεκίνησαν, και είναι ακριβώς η συμπεριφορά στην οποία βασίζονται τα κιτ phishing. Δεν πρέπει να υποχωρήσει σε ασθενέστερο παράγοντα επειδή απέτυχε ο ισχυρός, και δεν πρέπει να απενεργοποιήσει τον έλεγχο ταυτότητας διακομιστή για να περάσει ένα παράπονο πιστοποιητικού που εμφανίστηκε ταυτόχρονα. Καθεμία από αυτές τις τρεις συντομεύσεις μετατρέπει μια αποτυχία ελέγχου ταυτότητας σε περιστατικό ασφαλείας.
Δεν πρέπει επίσης να καταπιεί σιωπηλά την αποτυχία. Ένας πελάτης που κλείνει τη σύνδεση και δείχνει έναν δείκτη φόρτωσης αφήνει τον χρήστη χωρίς ιδέα αν πρέπει να επαναλάβει, να περιμένει ή να καλέσει την υποστήριξη. Εμφανίστε την αποτυχία με τον τύπο παράγοντα και έναν σύντομο κωδικό, κρατήστε το μήνυμα χωρίς μυστικά και κάντε την ενέργεια επανάληψης ρητή αντί για αυτόματη.
Αν το αίτημα δεν το ξεκίνησε το άτομο στο πληκτρολόγιο, η σωστή ενέργεια είναι να το αφήσετε απορριφθέν και να το αναφέρετε μέσω της επαληθευμένης διαδρομής υποστήριξης. Το να εγκρίνετε ένα αίτημα για να σταματήσει ο θόρυβος είναι το μοτίβο αποτυχίας, όχι η διόρθωση.
Τι να καταγράψετε για την υποστήριξη
Για την υποστήριξη, το χρήσιμο αρχείο είναι μικρό. Η κατά προσέγγιση ώρα με τη ζώνη ώρας, ο λογαριασμός, ο πελάτης και η έκδοση, ο τύπος παράγοντα και η μη μυστική κατάσταση κάθε προσπάθειας: ζητήθηκε, απορρίφθηκε, έληξε, εγκρίθηκε αλλά απορρίφθηκε από πολιτική.
Κρατήστε και τα ρολόγια πελάτη και διακομιστή υπόψη. Το TOTP είναι έλεγχος χρονικού παραθύρου, οπότε μια συσκευή με μετατοπισμένο ρολόι παράγει κωδικούς που φαίνονται έγκυροι και αποτυγχάνουν κάθε φορά, και ένας πελάτης που αναφέρει μη έγκυρο κωδικό χωρίς να σημειώνει τη μετατόπιση στέλνει ανθρώπους να επαναφέρουν διαπιστευτήρια που ποτέ δεν ήταν λάθος. Ένας χρήστης του οποίου η σύνδεση αποτυγχάνει επανειλημμένα θα πρέπει να ελέγξει την υποστηριζόμενη έκδοση πελάτη, την κατάσταση εγγραφής και τη τεκμηριωμένη ροή ανάκτησης πριν δημιουργήσει περισσότερα αιτήματα.
Η διαδρομή ανάκτησης αξίζει την ίδια φροντίδα με τη διαδρομή σύνδεσης. Μια ροή για χαμένη συσκευή υπάρχει ακριβώς για να μην γίνεται η απόρριψη άδεια παράκαμψης του ελέγχου ταυτότητας, και ο πελάτης θα πρέπει να παραπέμπει στη τεκμηριωμένη διαδικασία του οργανισμού αντί να επινοεί δική του.
Ο κανόνας πάνω στον οποίο πρέπει να χτιστεί είναι ότι η απόρριψη είναι αποτέλεσμα, όχι εμπόδιο. Αναφέρετέ την μία φορά, καθαρά, με αρκετό πλαίσιο για δράση, και αφήστε την επόμενη προσπάθεια να είναι νέα. Οι οδηγίες της CISA για MFA ανθεκτικό στο phishing εξηγούν γιατί το μοτίβο «ρώτα μέχρι την έγκριση» είναι επικίνδυνο εξαρχής, και είναι η αναφορά που αξίζει να επικαλεστεί κανείς όταν κάποιος προτείνει βρόχο επαναλήψεων. Ό,τι προσθέτει ο πελάτης μετά από μια απόρριψη θα πρέπει να κάνει την επόμενη απόφαση ευκολότερη για έναν άνθρωπο, όχι να αφαιρεί την απόφαση από αυτόν.