Πρόσβαση από VPN σε VLAN: φτιάξτε πρώτα τον πίνακα, μετά τους κανόνες
Ρόλοι στη μία πλευρά, υπηρεσίες στην άλλη. Πέντε έλεγχοι μετατρέπουν έναν ασαφή σχεδιασμό πρόσβασης από VPN σε VLAN σε έναν πίνακα που μπορεί να υλοποιήσει ο υπεύθυνος του τείχους προστασίας.
Ξεκινήστε από τον πίνακα, όχι από τη σύνταξη του τείχους προστασίας. Έναν πίνακα με ρόλους στη μία πλευρά και υπηρεσίες στην άλλη μπορεί να τον ελέγξει ο υπεύθυνος μιας εφαρμογής, να τον συζητήσει ο υπεύθυνος ασφάλειας και να τον υλοποιήσει όποιος κρατά την πύλη. Αυτός ο έλεγχος είναι φθηνότερος από την αποσφαλμάτωση κανόνων για τους οποίους δεν συμφώνησε κανείς.
Μία ώρα γραφής γλιτώνει αργότερα μία εβδομάδα αρχαιολογίας κανόνων. Ο σχεδιασμός μιλά για το ποιος φτάνει σε ποια υπηρεσία, και αυτό είναι το κομμάτι που επιβιώνει από μια επαναρίθμηση.
Βήμα 1: ονομάστε τους ρόλους πριν από τα δίκτυα
Ξεκινήστε από τους ανθρώπους, όχι από τον μεταγωγέα. Γράψτε κάθε ομάδα που συνδέεται απομακρυσμένα και τη μία πρόταση που περιγράφει τι κάνει αυτή η ομάδα, όπως προσωπικό αποθήκης που διαβάζει επίπεδα αποθέματος ή έναν εργολάβο που συντηρεί μία ενσωμάτωση. Αν δύο ομάδες θα έπαιρναν ίδια πρόσβαση, για αυτόν τον σκοπό είναι ένας ρόλος.
Σταματήστε εδώ αν ένας ρόλος υπάρχει μόνο εξαιτίας ενός οργανογράμματος. Ένας ρόλος χωρίς ξεχωριστή ανάγκη υπηρεσίας γίνεται μια σειρά από πανομοιότυπα κελιά, και οι πανομοιότυπες σειρές δελεάζουν κάποιον να παραχωρήσει αργότερα ένα ολόκληρο υποδίκτυο για ευκολία. Χωρίστε με βάση το τι κάνουν οι άνθρωποι, όχι με βάση το ποιος υπογράφει τα έξοδά τους. Έξι ρόλοι είναι συνήθως πάρα πολλοί για ένα μικρό γραφείο και τρεις είναι συχνά το σωστό.
Βήμα 2: μετατρέψτε κάθε κελί σε δήλωση υπηρεσίας
Ένα κελί που λέει «Εφαρμογές» δεν είναι ελέγξιμο. Ένα κελί που λέει «HTTPS στον κεντρικό υπολογιστή ERP στη θύρα 443, από τη δεξαμενή προσωπικού» είναι. Αντικαταστήστε κάθε όνομα δικτύου με προορισμό, πρωτόκολλο και θύρα και μετά προσθέστε την εξάρτηση χωρίς την οποία η υπηρεσία δεν λειτουργεί, όπως τον εσωτερικό μεταφραστή ή τον πάροχο ταυτότητας.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Η στήλη κατεύθυνσης πιάνει τα πιο ακριβά λάθη. Η άδεια στο προσωπικό να ανοίγει μια εφαρμογή δεν συνεπάγεται άδεια στους διακομιστές εφαρμογών να ανοίγουν συνδέσεις πίσω στους φορητούς του προσωπικού, και ένας κανόνας με κατάσταση που επιτρέπει την πρώτη κατεύθυνση συχνά διαβάζεται ως άδεια για τη δεύτερη.
Βήμα 3: αποφασίστε πού η ταυτότητα γίνεται πολιτική
Κάποιος πρέπει να μετατρέψει μια πιστοποιημένη συνεδρία σε ρόλο που μπορεί να επιβάλει η πύλη. Οι υποστηριζόμενες επιλογές περιλαμβάνουν πολιτική ομάδας που παρέχεται από το σύστημα πιστοποίησης, αξιόπιστα χαρακτηριστικά συνεδρίας ή ξεχωριστές δεξαμενές διευθύνσεων ανά ρόλο. Και οι τρεις λειτουργούν· μια ετικέτα που στέλνει ο πελάτης δεν λειτουργεί. Διαλέξτε τον μηχανισμό που τεκμηριώνει η πύλη σας, όχι αυτόν που περιγράφει μια ανάρτηση σε φόρουμ.
Η εκχώρηση μιας διεύθυνσης που απλώς μοιάζει να ανήκει σε VLAN είναι η ίδια μη απάντηση με άλλο κοστούμι. Ο οδηγός της Netgate για τους κανόνες τείχους προστασίας του OpenVPN κάνει τον διαχωρισμό σαφή: το να επιτρέψετε να σηκωθεί το τούνελ είναι διαφορετική απόφαση από το να επιτρέψετε την κίνηση μέσα από αυτό.
Γράψτε ποιον μηχανισμό επιλέξατε και πού έχει ρυθμιστεί. Όταν αλλάζει ένας ρόλος, αυτή η σημείωση είναι η διαφορά ανάμεσα σε μία επεξεργασία και σε ένα κυνήγι μέσα από τρεις διεπαφές. Λέει επίσης σε έναν ελεγκτή πού να κοιτάξει πρώτα.
Βήμα 4: προσέξτε τη διεύθυνση προέλευσης που βλέπει ο προορισμός
Η πολιτική προώθησης πρέπει να ταιριάζει με την πραγματική προέλευση στο όριο. Αν η πύλη μεταφράζει τους πελάτες VPN στη δική της διεύθυνση, κάθε τείχος προστασίας πιο κάτω βλέπει μία προέλευση και χάνει τη δυνατότητα να αποφασίζει ανά ρόλο. Αν διατηρεί τη διεύθυνση του πελάτη, η διαδρομή επιστροφής πρέπει να υπάρχει για αυτή τη δεξαμενή.
Δοκιμάστε και τις δύο κατευθύνσεις πριν γράψετε τους τελικούς κανόνες και μετά καταγράψτε την παρατηρούμενη προέλευση δίπλα σε κάθε κελί. Τρέξτε τον ίδιο έλεγχο από δύο διαφορετικούς ρόλους και συγκρίνετε το αποτέλεσμα. Αν και οι δύο δείχνουν τη διεύθυνση της πύλης, η διάκριση ρόλων έχει ήδη χαθεί. Ένας πίνακας που υποθέτει διατηρημένες διευθύνσεις ενώ η πύλη κάνει μετάφραση προέλευσης αποτυγχάνει στο πρώτο ACL πιο κάτω.
Βήμα 5: δοκιμάστε κάθε κελί πριν το παραδώσετε
Μετατρέψτε κάθε επιτρεπόμενο κελί σε μία αντιπροσωπευτική λειτουργία και κάθε απαγορευμένο κελί σε μια αρνητική περίπτωση. Τρέξτε και τις δύο από έναν πελάτη στον πραγματικό ρόλο, όχι από την κονσόλα της πύλης, γιατί η κονσόλα παρακάμπτει τη διαδρομή που δοκιμάζετε.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Μια αρνητική περίπτωση που συνδέεται είναι εύρημα, όχι σύμπτωση, και ανήκει στον πίνακα ως αποτυχημένο κελί μέχρι να διορθωθεί ο κανόνας. Κρατήστε τις εντολές δοκιμής δίπλα στον πίνακα ώστε ο επόμενος ελεγκτής να τις ξανατρέξει αντί να ξαναχτίσει το σκεπτικό.
Ο ολοκληρωμένος πίνακας ζει περισσότερο από την πύλη για την οποία γράφτηκε. Οι κανόνες αλλάζουν με το firmware και τον προμηθευτή, ενώ η σειρά που λέει ότι ένας εργολάβος φτάνει σε μία υπηρεσία έργου παραμένει αληθινή μέχρι να αλλάξει αυτή η εργασία.