Πώς να αποκτήσετε τον έλεγχο της υποδομής του δικτύου σας. Κεφάλαιο τρίτο. Ασφάλεια δικτύου. Μέρος πρώτο

Αυτό το άρθρο είναι το τρίτο από μια σειρά άρθρων «Πώς να πάρετε τον έλεγχο της υποδομής δικτύου σας». Μπορείτε να βρείτε τα περιεχόμενα όλων των άρθρων της σειράς και τους συνδέσμους εδώ.

Πώς να αποκτήσετε τον έλεγχο της υποδομής του δικτύου σας. Κεφάλαιο τρίτο. Ασφάλεια δικτύου. Μέρος πρώτο

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

Φυσικά, ο σχεδιασμός ασφαλείας είναι οργανικά ενσωματωμένος στη συνολική αρχιτεκτονική και οι λύσεις ασφαλείας που χρησιμοποιούνται επηρεάζουν την επεκτασιμότητα, την αξιοπιστία, τη διαχειρισιμότητα, ... της δικτυακής υποδομής, τα οποία πρέπει επίσης να ληφθούν υπόψη.

Να θυμίσω όμως ότι τώρα δεν μιλάμε για δημιουργία δικτύου. Σύμφωνα με το δικό μας αρχικές συνθήκες Έχουμε ήδη επιλέξει τον σχεδιασμό, επιλέξαμε τον εξοπλισμό και δημιουργήσαμε την υποδομή και σε αυτό το στάδιο, αν είναι δυνατόν, θα πρέπει να «ζήσουμε» και να βρούμε λύσεις στο πλαίσιο της προσέγγισης που επιλέχθηκε προηγουμένως.

Το καθήκον μας τώρα είναι να εντοπίσουμε τους κινδύνους που σχετίζονται με την ασφάλεια σε επίπεδο δικτύου και να τους μειώσουμε σε λογικό επίπεδο.

Έλεγχος ασφάλειας δικτύου

Εάν ο οργανισμός σας έχει εφαρμόσει διαδικασίες ISO 27k, τότε οι έλεγχοι ασφαλείας και οι αλλαγές δικτύου θα πρέπει να ταιριάζουν άψογα στις συνολικές διαδικασίες αυτής της προσέγγισης. Αλλά αυτά τα πρότυπα εξακολουθούν να μην αφορούν συγκεκριμένες λύσεις, ούτε ρύθμιση παραμέτρων, ούτε σχεδίαση... Δεν υπάρχουν σαφείς συμβουλές, δεν υπαγορεύουν πρότυπα λεπτομερώς πώς θα πρέπει να είναι το δίκτυό σας, αυτή είναι η πολυπλοκότητα και η ομορφιά αυτής της εργασίας.

Θα επισημάνω αρκετούς πιθανούς ελέγχους ασφάλειας δικτύου:

  • έλεγχος διαμόρφωσης εξοπλισμού (σκλήρυνση)
  • έλεγχος σχεδιασμού ασφάλειας
  • έλεγχος πρόσβασης
  • έλεγχος διαδικασίας

Έλεγχος διαμόρφωσης εξοπλισμού (σκλήρυνση)

Φαίνεται ότι στις περισσότερες περιπτώσεις αυτό είναι το καλύτερο σημείο εκκίνησης για τον έλεγχο και τη βελτίωση της ασφάλειας του δικτύου σας. IMHO, αυτή είναι μια καλή επίδειξη του νόμου του Pareto (20% της προσπάθειας παράγει το 80% του αποτελέσματος και το υπόλοιπο 80% της προσπάθειας παράγει μόνο το 20% του αποτελέσματος).

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

Μπορείτε επίσης συχνά να βρείτε ένα ερωτηματολόγιο (ή να δημιουργήσετε ένα μόνοι σας) με βάση αυτές τις συστάσεις, το οποίο θα σας βοηθήσει να προσδιορίσετε πόσο καλά η διαμόρφωση του εξοπλισμού σας συμμορφώνεται με αυτές τις «βέλτιστες πρακτικές» και, σύμφωνα με το αποτέλεσμα, να κάνετε αλλαγές στο δίκτυό σας . Αυτό θα σας επιτρέψει να μειώσετε σημαντικά τους κινδύνους ασφαλείας πολύ εύκολα, σχεδόν χωρίς κόστος.

Πολλά παραδείγματα για ορισμένα λειτουργικά συστήματα Cisco.

Cisco IOS Configuration Hardening
Cisco IOS-XR Configuration Hardening
Cisco NX-OS Configuration Hardening
Λίστα ελέγχου ασφαλείας βασικής γραμμής Cisco

Με βάση αυτά τα έγγραφα, μπορεί να δημιουργηθεί μια λίστα απαιτήσεων διαμόρφωσης για κάθε τύπο εξοπλισμού. Για παράδειγμα, για ένα Cisco N7K VDC, αυτές οι απαιτήσεις μπορεί να μοιάζουν έτσι.

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

Έλεγχος σχεδιασμού ασφάλειας

Συνήθως, ένα εταιρικό δίκτυο περιέχει τα ακόλουθα τμήματα με τη μία ή την άλλη μορφή:

  • DC (Δημόσιες υπηρεσίες DMZ και Κέντρο δεδομένων Intranet)
  • Πρόσβαση στο Διαδίκτυο
  • VPN απομακρυσμένης πρόσβασης
  • WAN άκρη
  • Υποκατάστημα
  • Πανεπιστημιούπολη (Γραφείο)
  • πυρήνας

Τίτλοι που λαμβάνονται από Cisco SAFE μοντέλο, αλλά δεν είναι απαραίτητο, φυσικά, να επισυναφθεί ακριβώς σε αυτά τα ονόματα και σε αυτό το μοντέλο. Ωστόσο, θέλω να μιλήσω για την ουσία και να μην κολλήσω σε τυπικότητες.

Για καθένα από αυτά τα τμήματα, οι απαιτήσεις ασφάλειας, οι κίνδυνοι και, κατά συνέπεια, οι λύσεις θα είναι διαφορετικές.

Ας δούμε καθένα από αυτά ξεχωριστά για τα προβλήματα που μπορεί να αντιμετωπίσετε από την άποψη του σχεδιασμού ασφάλειας. Φυσικά, επαναλαμβάνω ξανά ότι σε καμία περίπτωση αυτό το άρθρο δεν προσποιείται ότι είναι πλήρες, κάτι που δεν είναι εύκολο (αν όχι αδύνατο) να επιτευχθεί σε αυτό το πραγματικά βαθύ και πολύπλευρο θέμα, αλλά αντανακλά την προσωπική μου εμπειρία.

Δεν υπάρχει τέλεια λύση (τουλάχιστον όχι ακόμα). Είναι πάντα ένας συμβιβασμός. Αλλά είναι σημαντικό η απόφαση για τη χρήση μιας ή άλλης προσέγγισης να λαμβάνεται συνειδητά, με κατανόηση τόσο των θετικών όσο και των αρνητικών της.

Κέντρο δεδομένων

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

Είναι απαραίτητο ή όχι ένα τείχος προστασίας;

Φαίνεται ότι η απάντηση είναι προφανής, αλλά όλα δεν είναι τόσο ξεκάθαρα όσο μπορεί να φαίνονται. Και η επιλογή σας μπορεί να επηρεαστεί όχι μόνο τιμή.

Παράδειγμα 1. Καθυστερήσεις.

Εάν η χαμηλή καθυστέρηση είναι βασική απαίτηση μεταξύ ορισμένων τμημάτων δικτύου, κάτι που ισχύει, για παράδειγμα, στην περίπτωση ανταλλαγής, τότε δεν θα μπορούμε να χρησιμοποιήσουμε τείχη προστασίας μεταξύ αυτών των τμημάτων. Είναι δύσκολο να βρείτε μελέτες σχετικά με τον λανθάνοντα χρόνο στα τείχη προστασίας, αλλά λίγα μοντέλα διακόπτη μπορούν να παρέχουν καθυστέρηση μικρότερη ή της τάξης του 1 mksec, οπότε πιστεύω ότι αν τα μικροδευτερόλεπτα είναι σημαντικά για εσάς, τότε τα τείχη προστασίας δεν είναι για εσάς.

Παράδειγμα 2. Εκτέλεση.

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

Παράδειγμα 3. Αξιοπιστία.

Τα τείχη προστασίας, ειδικά τα σύγχρονα NGFW (Next-Generation FW) είναι πολύπλοκες συσκευές. Είναι πολύ πιο περίπλοκοι από τους διακόπτες L3/L2. Παρέχουν μεγάλο αριθμό υπηρεσιών και επιλογών διαμόρφωσης, επομένως δεν προκαλεί έκπληξη το γεγονός ότι η αξιοπιστία τους είναι πολύ χαμηλότερη. Εάν η συνέχεια της υπηρεσίας είναι κρίσιμης σημασίας για το δίκτυο, τότε ίσως χρειαστεί να επιλέξετε τι θα οδηγήσει σε καλύτερη διαθεσιμότητα - ασφάλεια με ένα τείχος προστασίας ή την απλότητα ενός δικτύου που βασίζεται σε διακόπτες (ή διάφορα είδη υφασμάτων) χρησιμοποιώντας κανονικά ACL.

Στην περίπτωση των παραπάνω παραδειγμάτων, πιθανότατα (ως συνήθως) θα πρέπει να βρείτε έναν συμβιβασμό. Δείτε τις παρακάτω λύσεις:

  • εάν αποφασίσετε να μην χρησιμοποιήσετε τείχη προστασίας μέσα στο κέντρο δεδομένων, τότε πρέπει να σκεφτείτε πώς να περιορίσετε την πρόσβαση γύρω από την περίμετρο όσο το δυνατόν περισσότερο. Για παράδειγμα, μπορείτε να ανοίξετε μόνο τις απαραίτητες θύρες από το Διαδίκτυο (για την κίνηση πελατών) και πρόσβαση διαχειριστή στο κέντρο δεδομένων μόνο από κεντρικούς υπολογιστές jump. Στους κεντρικούς υπολογιστές jump, πραγματοποιήστε όλους τους απαραίτητους ελέγχους (έλεγχος ταυτότητας/εξουσιοδότηση, προστασία από ιούς, καταγραφή, ...)
  • μπορείτε να χρησιμοποιήσετε μια λογική κατάτμηση του δικτύου του κέντρου δεδομένων σε τμήματα, παρόμοια με το σχήμα που περιγράφεται στο PSEFABRIC παράδειγμα p002. Σε αυτήν την περίπτωση, η δρομολόγηση πρέπει να διαμορφωθεί με τέτοιο τρόπο ώστε η κυκλοφορία ευαίσθητη σε καθυστέρηση ή υψηλής έντασης να πηγαίνει «εντός» ενός τμήματος (στην περίπτωση του p002, VRF) και να μην περνά μέσα από το τείχος προστασίας. Η κυκλοφορία μεταξύ διαφορετικών τμημάτων θα συνεχίσει να διέρχεται από το τείχος προστασίας. Μπορείτε επίσης να χρησιμοποιήσετε τη διαρροή διαδρομής μεταξύ των VRF για να αποφύγετε την ανακατεύθυνση της κυκλοφορίας μέσω του τείχους προστασίας
  • Μπορείτε επίσης να χρησιμοποιήσετε ένα τείχος προστασίας σε διαφανή λειτουργία και μόνο για εκείνα τα VLAN όπου αυτοί οι παράγοντες (λανθάνουσα κατάσταση/απόδοση) δεν είναι σημαντικοί. Αλλά πρέπει να μελετήσετε προσεκτικά τους περιορισμούς που σχετίζονται με τη χρήση αυτού του mod για κάθε προμηθευτή
  • μπορεί να θέλετε να εξετάσετε το ενδεχόμενο να χρησιμοποιήσετε μια αρχιτεκτονική αλυσίδας υπηρεσιών. Αυτό θα επιτρέψει μόνο την απαραίτητη κίνηση να περάσει μέσα από το τείχος προστασίας. Φαίνεται ωραίο στη θεωρία, αλλά δεν έχω δει ποτέ αυτή τη λύση στην παραγωγή. Δοκιμάσαμε την αλυσίδα σέρβις για το Cisco ACI/Juniper SRX/F5 LTM πριν από περίπου 3 χρόνια, αλλά εκείνη την εποχή αυτή η λύση μας φαινόταν «ακατέργαστη».

Επίπεδο προστασίας

Τώρα πρέπει να απαντήσετε στην ερώτηση ποια εργαλεία θέλετε να χρησιμοποιήσετε για να φιλτράρετε την κυκλοφορία. Ακολουθούν μερικά από τα χαρακτηριστικά που υπάρχουν συνήθως στο NGFW (για παράδειγμα, εδώ):

  • τείχος προστασίας κατάστασης (προεπιλογή)
  • τείχος προστασίας εφαρμογών
  • πρόληψη απειλών (antivirus, anti-spyware και ευπάθεια)
  • Φιλτράρισμα URL
  • φιλτράρισμα δεδομένων (φιλτράρισμα περιεχομένου)
  • αποκλεισμός αρχείων (αποκλεισμός τύπων αρχείων)
  • dos προστασία

Και δεν είναι όλα ξεκάθαρα. Φαίνεται ότι όσο υψηλότερο είναι το επίπεδο προστασίας, τόσο το καλύτερο. Αλλά πρέπει επίσης να το λάβετε υπόψη σας

  • Όσο περισσότερες από τις παραπάνω λειτουργίες του τείχους προστασίας χρησιμοποιείτε, τόσο πιο ακριβό θα είναι φυσικά (άδειες, πρόσθετες μονάδες)
  • η χρήση ορισμένων αλγορίθμων μπορεί να μειώσει σημαντικά την απόδοση του τείχους προστασίας και επίσης να αυξήσει τις καθυστερήσεις, βλ. εδώ
  • Όπως κάθε περίπλοκη λύση, η χρήση πολύπλοκων μεθόδων προστασίας μπορεί να μειώσει την αξιοπιστία της λύσης σας, για παράδειγμα, όταν χρησιμοποιούσα το τείχος προστασίας εφαρμογών, αντιμετώπισα αποκλεισμό ορισμένων πολύ τυπικών εφαρμογών εργασίας (dns, smb)

Όπως πάντα, πρέπει να βρείτε την καλύτερη λύση για το δίκτυό σας.

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

Επομένως, σε κρίσιμα τμήματα, μια καλή λύση μπορεί να είναι η χρήση προσφορών από διαφορετικές εταιρείες. Για παράδειγμα, μπορείτε να ενεργοποιήσετε την προστασία από ιούς στο τείχος προστασίας, αλλά και να χρησιμοποιήσετε προστασία προστασίας από ιούς (από άλλο κατασκευαστή) τοπικά στους κεντρικούς υπολογιστές.

Κατάτμηση

Μιλάμε για τη λογική κατάτμηση του δικτύου των κέντρων δεδομένων. Για παράδειγμα, η κατάτμηση σε VLAN και υποδίκτυα είναι επίσης λογική κατάτμηση, αλλά δεν θα την εξετάσουμε λόγω της προφανείας της. Ενδιαφέρουσα τμηματοποίηση λαμβάνοντας υπόψη οντότητες όπως ζώνες ασφαλείας FW, VRF (και τα ανάλογα τους σε σχέση με διάφορους προμηθευτές), λογικές συσκευές (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Δίνεται ένα παράδειγμα τέτοιας λογικής τμηματοποίησης και του σχεδιασμού των κέντρων δεδομένων σε ζήτηση p002 του έργου PSEFABRIC.

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

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

Συχνά η τμηματοποίηση βασίζεται μόνο σε ζώνες ασφαλείας FW. Τότε πρέπει να απαντήσετε στις ακόλουθες ερωτήσεις:

  • ποιες ζώνες ασφαλείας χρειάζεστε
  • ποιο επίπεδο προστασίας θέλετε να εφαρμόσετε σε καθεμία από αυτές τις ζώνες
  • θα επιτρέπεται η κυκλοφορία εντός ζώνης από προεπιλογή;
  • Εάν όχι, ποιες πολιτικές φιλτραρίσματος κυκλοφορίας θα εφαρμόζονται σε κάθε ζώνη
  • ποιες πολιτικές φιλτραρίσματος κυκλοφορίας θα εφαρμοστούν για κάθε ζεύγος ζωνών (πηγή/προορισμός)

TCAM

Ένα κοινό πρόβλημα είναι η ανεπαρκής TCAM (Ternary Content Addressable Memory), τόσο για δρομολόγηση όσο και για προσβάσεις. IMHO, αυτό είναι ένα από τα πιο σημαντικά ζητήματα κατά την επιλογή εξοπλισμού, επομένως πρέπει να αντιμετωπίσετε αυτό το ζήτημα με τον κατάλληλο βαθμό προσοχής.

Παράδειγμα 1. Πίνακας προώθησης TCAM.

Ας ρίξουμε μια ματιά στο Πάλο Άλτο 7κ τείχος προστασίας
Βλέπουμε ότι μέγεθος πίνακα προώθησης IPv4* = 32K
Επιπλέον, αυτός ο αριθμός διαδρομών είναι κοινός για όλα τα VSYS.

Ας υποθέσουμε ότι σύμφωνα με το σχέδιό σας αποφασίζετε να χρησιμοποιήσετε 4 VSYS.
Κάθε ένα από αυτά τα VSYS συνδέεται μέσω BGP σε δύο MPLS PE του cloud που χρησιμοποιείτε ως BB. Έτσι, 4 VSYS ανταλλάσσουν όλες τις συγκεκριμένες διαδρομές μεταξύ τους και έχουν έναν πίνακα προώθησης με περίπου τα ίδια σύνολα διαδρομών (αλλά διαφορετικά NH). Επειδή κάθε VSYS έχει 2 συνεδρίες BGP (με τις ίδιες ρυθμίσεις), στη συνέχεια, κάθε διαδρομή που λαμβάνεται μέσω MPLS έχει 2 NH και, κατά συνέπεια, 2 καταχωρήσεις FIB στον Πίνακα προώθησης. Εάν υποθέσουμε ότι αυτό είναι το μόνο τείχος προστασίας στο κέντρο δεδομένων και πρέπει να γνωρίζει όλες τις διαδρομές, τότε αυτό θα σημαίνει ότι ο συνολικός αριθμός διαδρομών στο κέντρο δεδομένων μας δεν μπορεί να είναι μεγαλύτερος από 32K/(4 * 2) = 4K.

Τώρα, αν υποθέσουμε ότι έχουμε 2 κέντρα δεδομένων (με την ίδια σχεδίαση) και θέλουμε να χρησιμοποιήσουμε VLAN «τεντωμένα» μεταξύ κέντρων δεδομένων (για παράδειγμα, για vMotion), τότε για να λύσουμε το πρόβλημα δρομολόγησης, πρέπει να χρησιμοποιήσουμε διαδρομές κεντρικού υπολογιστή . Αλλά αυτό σημαίνει ότι για 2 κέντρα δεδομένων δεν θα έχουμε περισσότερους από 4096 πιθανούς κεντρικούς υπολογιστές και, φυσικά, αυτό μπορεί να μην είναι αρκετό.

Παράδειγμα 2. ACL TCAM.

Εάν σκοπεύετε να φιλτράρετε την κυκλοφορία σε διακόπτες L3 (ή άλλες λύσεις που χρησιμοποιούν διακόπτες L3, για παράδειγμα, Cisco ACI), τότε όταν επιλέγετε εξοπλισμό θα πρέπει να δώσετε προσοχή στο TCAM ACL.

Ας υποθέσουμε ότι θέλετε να ελέγξετε την πρόσβαση στις διεπαφές SVI του Cisco Catalyst 4500. Στη συνέχεια, όπως φαίνεται από του παρόντος άρθρου, για να ελέγξετε την εξερχόμενη (καθώς και την εισερχόμενη) κίνηση στις διεπαφές, μπορείτε να χρησιμοποιήσετε μόνο 4096 γραμμές TCAM. Το οποίο όταν χρησιμοποιείτε το TCAM3 θα σας δώσει περίπου 4000 χιλιάδες ACE (γραμμές ACL).

Εάν αντιμετωπίζετε το πρόβλημα της ανεπαρκούς TCAM, τότε, πρώτα απ 'όλα, φυσικά, πρέπει να εξετάσετε τη δυνατότητα βελτιστοποίησης. Έτσι, σε περίπτωση προβλήματος με το μέγεθος του πίνακα προώθησης, πρέπει να εξετάσετε τη δυνατότητα συγκέντρωσης διαδρομών. Σε περίπτωση προβλήματος με το μέγεθος TCAM για προσβάσεις, προσβάσεις ελέγχου, κατάργηση παλιών και επικαλυπτόμενων εγγραφών και, πιθανώς, αναθεώρηση της διαδικασίας ανοίγματος προσβάσεων (θα συζητηθεί λεπτομερώς στο κεφάλαιο για τις προσβάσεις ελέγχου).

Μεγάλη διαθεσιμότητα

Το ερώτημα είναι: πρέπει να χρησιμοποιήσω το HA για τείχη προστασίας ή να εγκαταστήσω δύο ανεξάρτητα κουτιά "παράλληλα" και, εάν ένα από αυτά αποτύχει, να δρομολογήσω την κυκλοφορία μέσω του δεύτερου;

Φαίνεται ότι η απάντηση είναι προφανής - χρησιμοποιήστε HA. Ο λόγος για τον οποίο εξακολουθεί να τίθεται αυτό το ερώτημα είναι ότι, δυστυχώς, τα θεωρητικά και διαφημιστικά 99 και αρκετά δεκαδικά ποσοστά προσβασιμότητας στην πράξη αποδεικνύονται κάθε άλλο παρά ρόδινα. Το HA είναι λογικά πολύ περίπλοκο πράγμα, και σε διαφορετικό εξοπλισμό, και με διαφορετικούς προμηθευτές (δεν υπήρχαν εξαιρέσεις), εντοπίσαμε προβλήματα και σφάλματα και στάσεις σέρβις.

Εάν χρησιμοποιείτε HA, θα έχετε την ευκαιρία να απενεργοποιήσετε μεμονωμένους κόμβους, να κάνετε εναλλαγή μεταξύ τους χωρίς διακοπή της υπηρεσίας, κάτι που είναι σημαντικό, για παράδειγμα, όταν κάνετε αναβαθμίσεις, αλλά ταυτόχρονα έχετε πολύ μηδενική πιθανότητα και οι δύο κόμβοι θα σπάσει ταυτόχρονα, και επίσης ότι την επόμενη η αναβάθμιση δεν θα πάει τόσο ομαλά όσο υπόσχεται ο πωλητής (αυτό το πρόβλημα μπορεί να αποφευχθεί εάν έχετε την ευκαιρία να δοκιμάσετε την αναβάθμιση σε εργαστηριακό εξοπλισμό).

Εάν δεν χρησιμοποιείτε HA, τότε από την άποψη της διπλής αποτυχίας οι κίνδυνοι σας είναι πολύ χαμηλότεροι (αφού έχετε 2 ανεξάρτητα firewalls), αλλά επειδή... οι περίοδοι λειτουργίας δεν συγχρονίζονται, οπότε κάθε φορά που κάνετε εναλλαγή μεταξύ αυτών των τείχη προστασίας θα χάνετε επισκεψιμότητα. Μπορείτε, φυσικά, να χρησιμοποιήσετε το τείχος προστασίας χωρίς κατάσταση, αλλά τότε χάνεται σε μεγάλο βαθμό το νόημα της χρήσης τείχους προστασίας.

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

Διαχειρισιμότητα

Κατ' αρχήν, το HA αφορά επίσης τη δυνατότητα ελέγχου. Αντί να διαμορφώσετε 2 κουτιά ξεχωριστά και να αντιμετωπίσετε το πρόβλημα της διατήρησης των διαμορφώσεων σε συγχρονισμό, τα διαχειρίζεστε σαν να είχατε μία συσκευή.

Αλλά ίσως έχετε πολλά κέντρα δεδομένων και πολλά τείχη προστασίας, τότε αυτό το ερώτημα προκύπτει σε ένα νέο επίπεδο. Και το ερώτημα δεν αφορά μόνο τη διαμόρφωση, αλλά και σχετικά

  • διαμορφώσεις αντιγράφων ασφαλείας
  • ενημερώσεις
  • αναβαθμίσεις
  • παρακολούθηση
  • ξύλευση

Και όλα αυτά μπορούν να λυθούν με κεντρικά συστήματα διαχείρισης.

Έτσι, για παράδειγμα, εάν χρησιμοποιείτε τείχη προστασίας Palo Alto, τότε Άποψη είναι μια τέτοια λύση.

Συνεχίζεται.

Πηγή: www.habr.com

Προσθέστε ένα σχόλιο