FortiGate VPN MFA: τοπικό token, RADIUS ή SAML;

Η πύλη, ένα backend RADIUS ή ένας πάροχος SAML μπορούν να επαληθεύσουν τον παράγοντα, και καθένα αποτυγχάνει διαφορετικά. Ταιριάξτε υπηρεσία, πελάτη και διαδρομή αποκατάστασης.

Κάθε σχεδιασμός FortiGate VPN MFA απαντά πρώτα σε μία ερώτηση: ποιος επαληθεύει τον δεύτερο παράγοντα; Η ίδια η πύλη μπορεί να το κάνει με τοπικό token ή κωδικό μέσω email, ένα backend RADIUS μπορεί να το επιβάλει και να επιστρέψει πρόκληση, ή ένας πάροχος ταυτότητας SAML μπορεί να αναλάβει όλη την τελετή σε έναν περιηγητή. Καθένα από αυτά παράγει διαφορετική ακολουθία σύνδεσης, διαφορετική υπογραφή αποτυχίας και διαφορετική διαδικασία αποκατάστασης, και η αντιγραφή ενός μπλοκ εντολών μεταξύ τους παράγει διαμόρφωση που φαίνεται εύλογη και δεν επαληθεύει κανέναν. Αυτό είναι άρθρο μηχανισμού: τι κάνει πραγματικά κάθε σχεδιασμός κατά τη σύνδεση και πού σπάει.

Η τελετή σύνδεσης καθορίζει ποιος κατέχει τον παράγοντα

Στους δύο πρώτους σχεδιασμούς, το FortiGate είναι το μέρος που εμπιστεύεται. Συλλέγει τα διαπιστευτήρια, αποφασίζει αν απαιτείται δεύτερος παράγοντας και τον επαληθεύει τοπικά ή ζητώντας πρόκληση. Στον τρίτο σχεδιασμό η πύλη παύει να είναι επαληθευτής και γίνεται αναμεταδότης: ανακατευθύνει τον πελάτη στον πάροχο ταυτότητας, λαμβάνει ισχυρισμό και αντιστοιχίζει τη βεβαιωμένη ταυτότητα σε χρήστη και ομάδα. Στον σχεδιασμό RADIUS βρίσκεται ανάμεσα, οδηγώντας ανταλλαγή αιτήματος-απόκρισης με ένα backend που κρατά την πολιτική.

Αυτή η διαφορά καθορίζει ποια στοιχεία μπορείτε να συλλέξετε. Όταν η πύλη επαληθεύει, η δική της έξοδος αποσφαλμάτωσης σας λέει τι συνέβη. Όταν επαληθεύει πάροχος ταυτότητας, η πύλη γνωρίζει μόνο ότι έφτασε ένας ισχυρισμός, και η απάντηση στο «απαιτούνταν πράγματι MFA» βρίσκεται στα αρχεία καταγραφής του παρόχου, όχι του τείχους προστασίας. Η ανάγνωση του λάθους αρχείου είναι ο πιο συνηθισμένος τρόπος να διαγνώσετε λανθασμένα μια ανάπτυξη που συμπεριφέρεται ακριβώς όπως σχεδιάστηκε. Και η ίδια η υπηρεσία περιορίζει την τελετή: Το FortiOS 7.6.3 αφαιρεί τη λειτουργία σήραγγας SSL VPN υπέρ του IPsec, ενώ η λειτουργία web συνεχίζεται ως Agentless VPN σε υποστηριζόμενα μοντέλα, οπότε μια τελετή που αποδείχθηκε σε μία υπηρεσία δεν είναι αυτόματα διαθέσιμη σε άλλη.

Τοπική επαλήθευση: token και κωδικοί μέσω email

Οι παράγοντες που διαχειρίζεται το FortiGate συνδέονται με το αντικείμενο χρήστη. Ένα FortiToken ή μια τεκμηριωμένη ενσωμάτωση token απαιτεί εγγραφή, την υποστηριζόμενη τελετή επαλήθευσης, αδειοδότηση όπου ισχύει και διαδικασία αντικατάστασης. Ένας κωδικός μέσω email απαιτεί λειτουργική διαδρομή SMTP και γραμματοκιβώτιο στο οποίο ο χρήστης μπορεί να φτάσει πριν υπάρξει η σήραγγα, μια εξάρτηση που δεν έχει καμία σχέση με την κρυπτογραφία και τα έχει όλα με το αν μπορεί κάποιος να συνδεθεί.

config user local
    edit "jdoe"
        set type password
        set two-factor fortitoken
        set fortitoken FTKMOB1234567890
    next
end

Η παράδοση email είναι μέρος της διαθεσιμότητας της επαλήθευσης ταυτότητας. Ένα γραμματοκιβώτιο προσβάσιμο μόνο μέσω VPN δημιουργεί βρόχο που δεν λύνεται για κανέναν, και η καθυστέρηση παράδοσης, η εγκυρότητα του κωδικού και το χρονικό όριο απομακρυσμένης επαλήθευσης είναι τρεις ξεχωριστοί περιορισμοί. Η αύξηση του ενός δεν επιδιορθώνει ένα μη προσβάσιμο γραμματοκιβώτιο, και ένας σχεδιασμός που δεν δοκίμασε ποτέ τον βρόχο θα τον ανακαλύψει στην πρώτη επαναφορά κωδικού μετά από διακοπές.

Οι απαιτήσεις διασφάλισης ανήκουν επίσης εδώ, πριν από την επιλογή προϊόντος. Το NIST SP 800-63B θεωρεί το email απαράδεκτο για επαλήθευση εκτός ζώνης, οπότε μια ανάπτυξη που ισχυρίζεται συμμόρφωση δεν μπορεί να χρησιμοποιήσει κωδικό μέσω email ως δεύτερο παράγοντα, όσο βολικό κι αν είναι. Η ύπαρξη μιας λειτουργίας στη συσκευή δεν δηλώνει ότι η λειτουργία ικανοποιεί ένα δεδομένο πρότυπο.

RADIUS: η πύλη ρωτά, το backend αποφασίζει

Με το RADIUS, το FortiGate στέλνει τα διαπιστευτήρια σε ένα backend που κατέχει την πολιτική παραγόντων. Η ανταλλαγή μπορεί να είναι απλή αποδοχή ή απόρριψη, ή μπορεί να περιλαμβάνει πρόκληση στην οποία ο πελάτης πρέπει να απαντήσει, που σημαίνει ότι και η υπηρεσία VPN και ο πελάτης πρέπει να υποστηρίζουν αυτή τη μορφή πρόκλησης. Ένα backend που επιβάλλει έγκριση push και ένας πελάτης που ξέρει μόνο να προσθέτει εξαψήφιο κωδικό σε κωδικό πρόσβασης δεν θα συναντηθούν στη μέση.

config user radius
    edit "corp-radius"
        set server "10.10.20.15"
        set secret ENCXXXXXXXX
        set secondary-server "10.10.20.16"
    next
end
diagnose test authserver radius corp-radius pap jdoe <password>

Δοκιμάστε το backend ανεξάρτητα πριν κατηγορήσετε τη σήραγγα. Αν η δοκιμή authserver πετύχει και η σύνδεση VPN όχι, η διαφορά είναι στη διαχείριση της πρόκλησης και όχι στα διαπιστευτήρια, και η αποσφαλμάτωση του δαίμονα επαλήθευσης της πύλης είναι το σημείο όπου αυτό φαίνεται:

diagnose debug application fnbamd -1
diagnose debug enable

SAML: ο περιηγητής φεύγει από την πύλη

Σε σχεδιασμό SAML ο πελάτης ανακατευθύνεται στον πάροχο ταυτότητας, επαληθεύεται εκεί και επιστρέφει με ισχυρισμό που η πύλη επικυρώνει έναντι σχέσης εμπιστοσύνης και αντιστοίχισης ομάδων. Η πύλη δεν βλέπει ποτέ τον κωδικό πρόσβασης ή τον δεύτερο παράγοντα, που είναι ταυτόχρονα βελτίωση ασφάλειας και λειτουργική επιπλοκή: η αποτυχία συμβαίνει τώρα σε συνεδρία περιηγητή που το τείχος προστασίας δεν μπορεί να επιθεωρήσει.

Η αποδοχή ενός ισχυρισμού δεν αποδεικνύει ότι ο πάροχος απαίτησε MFA για εκείνη τη σύνδεση. Μια πολιτική παρόχου που εφαρμόζει MFA σε ορισμένες εφαρμογές και όχι σε άλλες θα παράγει ακριβώς τη σύνδεση που ζητήσατε και καμία από τη διασφάλιση που υποθέσατε. Ελέγξτε την πολιτική του παρόχου για τη συγκεκριμένη εφαρμογή και ελέγξτε ότι η αντιστοίχιση των ισχυρισμών ομάδας στις ομάδες FortiGate εξακολουθεί να ταιριάζει μετά από οποιαδήποτε μετονομασία σε οποιαδήποτε πλευρά.

Η υποστήριξη πελάτη έχει εδώ μεγαλύτερη σημασία από οπουδήποτε αλλού. Ορισμένοι πελάτες VPN χειρίζονται εγγενώς τη μετάβαση στον περιηγητή, άλλοι ανοίγουν τον περιηγητή του συστήματος, και πελάτες χωρίς περιβάλλον ή πελάτες γραμμής εντολών μπορεί να μην ολοκληρώσουν καθόλου τη ροή. Δοκιμάστε με τον πελάτη που πραγματικά εκτελούν οι χρήστες, στις πλατφόρμες που πραγματικά χρησιμοποιούν, πριν δημοσιεύσετε το προφίλ.

Η αποκατάσταση είναι μέρος του μηχανισμού

Κάθε σχεδιασμός παραπάνω έχει μια εξάρτηση που μπορεί να αποτύχει για έναν χρήστη τη φορά: μη προσβάσιμο γραμματοκιβώτιο, χαμένο token, backend που απορρίπτει πρόκληση, κλειδωμένος λογαριασμός παρόχου ταυτότητας. Αποφασίστε τώρα ποιος μπορεί να αποκαταστήσει την πρόσβαση, με ποια υποστηριζόμενη διαδικασία και με ποια επαλήθευση του ατόμου που τη ζητά. Ένας λογαριασμός τοπικού διαχειριστή έκτακτης ανάγκης, κρατημένος χωριστά από τη διαδρομή VPN, είναι ένας έλεγχος· και μια ανεξήγητη παράκαμψη μόνο με κωδικό πρόσβασης είναι περιστατικό που περιμένει να ανακαλυφθεί.

Στη συνέχεια δοκιμάστε τρεις συνδέσεις πριν την ανάπτυξη: την κανονική, έναν απορριφθέντα ή ληγμένο παράγοντα και την εγκεκριμένη αποκατάσταση χαμένου authenticator. Καταγράψτε σε ποιο αρχείο εμφανίζεται καθεμία. Αυτή η καταγραφή μετατρέπει το «το MFA είναι ενεργό» σε σχεδιασμό που μπορεί να λειτουργήσει κάποιος άλλος.

Σχετικά άρθρα