Ο βασικός οδηγός για την ασφάλεια του MongoDB

Ο David Murphy χρησιμεύει ως διαχειριστής πρακτικών για το MongoDB στο Percona, ένας πάροχος λύσεων και υπηρεσιών MySQL και MongoDB κατηγορίας επιχειρήσεων.

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

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

Είναι ασφαλές το λογισμικό βάσης δεδομένων MongoDB; Πληροί αυτά τα πρότυπα; Η σύντομη απάντηση: Ναι είναι, και ναι! Είναι απλώς θέμα γνώσης του τρόπου ρύθμισης, διαμόρφωσης και εργασίας με τη συγκεκριμένη εγκατάσταση.

Σε αυτό το άρθρο, θα ασχοληθώ με την ασφάλεια του MongoDB. Το MongoDB είναι ασφαλές στη χρήση - εάν ξέρετε τι να ψάξετε και πώς να το διαμορφώσετε.

Πρώτα απ 'όλα, πώς οι άνθρωποι πηγαίνουν στραβά με την ασφάλεια του MongoDB; Υπάρχουν αρκετοί βασικοί τομείς που ανεβάζουν τους χρήστες όσον αφορά την ασφάλεια του MongoDB:

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

Το MongoDB έχει πέντε βασικούς τομείς ασφαλείας:

• Αυθεντικοποίηση. Ο έλεγχος ταυτότητας LDAP συγκεντρώνει στοιχεία στον κατάλογο της εταιρείας σας.
• Εξουσιοδότηση. Η εξουσιοδότηση καθορίζει τους ελέγχους πρόσβασης βάσει ρόλων που παρέχει η βάση δεδομένων.
• Κρυπτογράφηση. Η κρυπτογράφηση μπορεί να χωριστεί σε At-Rest και In-Transit. Η κρυπτογράφηση είναι κρίσιμη για την ασφάλεια του MongoDB.
• Έλεγχος. Ο έλεγχος αναφέρεται στην ικανότητα να βλέπει ποιος έκανε τι στη βάση δεδομένων.
• Διακυβέρνηση. Η διακυβέρνηση αναφέρεται στην επικύρωση εγγράφων και στον έλεγχο ευαίσθητων δεδομένων (όπως αριθμός λογαριασμού, κωδικός πρόσβασης, αριθμός κοινωνικής ασφάλισης ή ημερομηνία γέννησης). Αυτό αναφέρεται τόσο στη γνώση της αποθήκευσης ευαίσθητων δεδομένων όσο και στην αποτροπή της εισαγωγής ευαίσθητων δεδομένων στο σύστημα.

Έλεγχος ταυτότητας LDAP

Το MongoDB έχει ενσωματωμένους ρόλους χρήστη και τους απενεργοποιεί από προεπιλογή. Ωστόσο, χάνει στοιχεία όπως η πολυπλοκότητα του κωδικού πρόσβασης, η εναλλαγή βάσει ηλικίας και ο συγκεντρωτισμός και ο προσδιορισμός των ρόλων του χρήστη έναντι των λειτουργιών υπηρεσίας Αυτά είναι απαραίτητα για την έγκριση κανονισμών όπως η συμμόρφωση με το PCI DSS. Για παράδειγμα, το PCI DSS απαγορεύει τη χρήση παλαιών κωδικών πρόσβασης και κωδικών πρόσβασης που είναι εύκολο να σπάσει και απαιτεί αλλαγές στην πρόσβαση χρήστη κάθε φορά που αλλάζει η κατάσταση (για παράδειγμα, όταν ο χρήστης εγκαταλείπει τμήμα ή εταιρεία)

Ευτυχώς, το LDAP μπορεί να χρησιμοποιηθεί για την κάλυψη πολλών από αυτά τα κενά. Πολλοί σύνδεσμοι επιτρέπουν τη χρήση συστημάτων Windows Active Directory (AD) για συνομιλία με το LDAP.

Σημείωση: Η υποστήριξη LDAP είναι διαθέσιμη μόνο στο MongoDB Enterprise. Δεν είναι στην έκδοση της Κοινότητας. Είναι διαθέσιμο σε άλλες εκδόσεις ανοιχτού κώδικα του MongoDB, όπως Percona Server για MongoDB.

Το MongoDB 3.2 αποθηκεύει τους χρήστες σε LDAP, αλλά όχι ρόλους (αυτοί αποθηκεύονται επί του παρόντος σε μεμονωμένους υπολογιστές). Το MongoDB 3.4 Enterprise πρέπει να εισαγάγει τη δυνατότητα αποθήκευσης ρόλων στο LDAP για κεντρική πρόσβαση. (Θα συζητήσουμε αργότερα τους ρόλους.)

Περόνα

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

Το LDAP στο Mongo είναι πραγματικά εύκολο. Το MongoDB έχει μια ειδική εντολή για να του πει να ελέγξει την εξωτερική βάση δεδομένων LDAP: $ εξωτερικά.

Μερικές άλλες προειδοποιήσεις για τη χρήση LDAP:

• Δημιουργήστε έναν χρήστη με .createUser όπως θα κάνατε κανονικά, αλλά φροντίστε να πάτε με ετικέτες πόρων db / collection.
• Επιπλέον, ο έλεγχος ταυτότητας LDAP απαιτεί δύο ακόμη πεδία:
  • μηχανισμός: "PLAIN"
  • digestPassword: false

Προσαρμοσμένοι ρόλοι

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

Οι πέντε κύριοι ενσωματωμένοι ρόλοι MongoDB που πρέπει να γνωρίζετε:

• ανάγνωση:
  • Πρόσβαση μόνο για ανάγνωση, που συνήθως παρέχεται στους περισσότερους χρήστες
• διαβάζω γράφω:
  • διαβάζω γράφω Η πρόσβαση επιτρέπει την επεξεργασία δεδομένων
  • διαβάζω γράφω περιλαμβάνει ανάγνωση
• dbOwner:
  • Περιλαμβάνει διαβάζω γράφω, dbAdmin, userAdmin (για τη βάση δεδομένων). userAdmin σημαίνει προσθήκη ή κατάργηση χρηστών, παραχώρηση δικαιωμάτων σε χρήστες και δημιουργία ρόλων. Αυτά τα δικαιώματα εκχωρούνται μόνο στον συγκεκριμένο διακομιστή βάσης δεδομένων.
• dbAdminAnyDatabase:
  • Δημιουργεί dbAdmin σε όλες τις βάσεις δεδομένων, αλλά δεν επιτρέπει τη διαχείριση των χρηστών (για παράδειγμα, για τη δημιουργία ή κατάργηση χρηστών). Μπορείτε να δημιουργήσετε ευρετήρια, συμπυκνώσεις κλήσεων και άλλα. Αυτό δεν παρέχει πρόσβαση θραύσης.
• ρίζα:
  • Πρόκειται για υπερχρήστη, αλλά με όρια
  • Μπορεί να κάνει τα περισσότερα πράγματα, αλλά όχι όλα:
    • Δεν είναι δυνατή η αλλαγή της συλλογής συστήματος
    • Ορισμένες εντολές εξακολουθούν να μην είναι διαθέσιμες σε αυτόν τον ρόλο, ανάλογα με την έκδοση. Για παράδειγμα, ο ρόλος MongoDB 3.2 δεν σας επιτρέπει να αλλάξετε το μέγεθος oplog ή προφίλer και ο ρόλος MongoDB 3.4 δεν σας επιτρέπει να διαβάσετε τις τρέχουσες προβολές.

Βάσεις δεδομένων και συλλογές μπαλαντέρ

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

Αυτό είναι επικίνδυνο.

Όταν χρησιμοποιείτε μπαλαντέρ, δίνετε πολλά ειδικά προνόμια και θα πρέπει να γνωρίζετε ότι ανοίγετε πιθανές οδούς επίθεσης:

• readWriteAnyDatabase είναι επακρώς ευρεία και εκθέτει ονόματα χρηστών και ρόλους σε μια πιθανή επίθεση μέσω του χρήστη της εφαρμογής
• Η χρήση μπαλαντέρ σημαίνει ότι δεν θα περιορίσετε συγκεκριμένες εφαρμογές σε συγκεκριμένες βάσεις δεδομένων
• Η μπαλαντέρ σας εμποδίζει να χρησιμοποιείτε πολλαπλές λειτουργίες με πολλές βάσεις δεδομένων
• Δεν παρέχεται αυτόματα πρόσβαση σε νέες βάσεις δεδομένων

Δημιουργία προσαρμοσμένου ρόλου

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

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

• db. Καθορίζει μια βάση δεδομένων. Μπορείτε να χρησιμοποιήσετε μια συμβολοσειρά για ένα όνομα ή "" για "οποιοδήποτε" (χωρίς μπαλαντέρ).
• συλλογή. Καθορίζει μια συλλογή εγγράφων. Μπορείτε να χρησιμοποιήσετε μια συμβολοσειρά για ένα όνομα ή "" για "οποιοδήποτε" (χωρίς μπαλαντέρ).
• σύμπλεγμα. Καθορίζει ένα θραυσμένο σύμπλεγμα ή άλλους πόρους μεταδεδομένων. Είναι μια τιμή Boolean του true / false.
• anyResource. Καθορίζει την πρόσβαση σε οτιδήποτε, οπουδήποτε. Είναι μια τιμή Boolean του true / false.

Οποιοσδήποτε ρόλος μπορεί να κληρονομήσει τις ιδιότητες ενός άλλου ρόλου. Υπάρχει ένας πίνακας που ονομάζεται "ρόλοι" και μπορείτε να αποθέσετε έναν νέο ρόλο στον πίνακα. Θα κληρονομήσει τις ιδιότητες του καθορισμένου ρόλου.

Χρήση createRole για να προσθέσετε έναν ρόλο στον πίνακα.

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

Χρησιμοποιήστε το grantPrivilegesToRole εντολή για να προσθέσετε νέους πόρους σε έναν υπάρχοντα ρόλο.

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

db = db.geSiblingDB ("διαχειριστής");

db.createRole ({

ρόλος: "superRoot",

προνόμια: [{

πόρος: {anyResource: true},

δράσεις: [‘anyAction’]

     }]     

ρόλοι: []

});

db.createUser ({

χρήστης: "comanyDBA",

pwd: "EWqeeFpUt9 * 8zq",

ρόλοι: ["superRoot"]

})

Αυτές οι εντολές δημιουργούν έναν νέο ρόλο στη βάση δεδομένων geSiblingDB που ονομάζεται superRoot και εκχωρήστε σε αυτόν τον ρόλο οποιονδήποτε πόρο και οποιαδήποτε ενέργεια. Στη συνέχεια, δημιουργούμε έναν νέο χρήστη στην ίδια βάση δεδομένων που ονομάζεται εταιρείαDBA (με κωδικό πρόσβασης) και εκχωρήστε το νέο superRoot ρόλος.

Χρησιμοποιώντας SSL για όλα τα πράγματα

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

Υπάρχουν δύο πολύ καλοί λόγοι για να χρησιμοποιήσετε το SSL για να διασφαλίσετε το MongoDB: το απόρρητο και τον έλεγχο ταυτότητας. Χωρίς SSL, η πρόσβαση στα δεδομένα σας, η αντιγραφή και η χρήση τους για παράνομους ή επιβλαβείς σκοπούς. Με έλεγχο ταυτότητας, έχετε δευτερεύον επίπεδο ασφάλειας. Η υποδομή ιδιωτικού κλειδιού (PKI) της SSL εγγυάται ότι μόνο οι χρήστες με το σωστό πιστοποιητικό CA μπορούν να έχουν πρόσβαση στο MongoDB.

Το MongoDB είχε υποστήριξη SSL για μεγάλο χρονικό διάστημα, αλλά έχει βελτιώσει δραματικά την υποστήριξη SSL στις τελευταίες εκδόσεις. Προηγουμένως, εάν θέλετε να χρησιμοποιήσετε το SSL, έπρεπε να το κατεβάσετε και να το μεταγλωττίσετε μη αυτόματα με την έκδοση της κοινότητας MongoDB. Από το MongoDB 3.0, το SSL καταρτίζεται από προεπιλογή με το λογισμικό.

Οι παλαιότερες εκδόσεις του MongoDB δεν είχαν επίσης έγκυρο έλεγχο κεντρικού υπολογιστή. Η επικύρωση κεντρικού υπολογιστή ήταν απλώς μια σημαία που θα μπορούσατε να ελέγξετε στο αρχείο διαμόρφωσης που ικανοποίησε ένα αίτημα SSL από μια σύνδεση.

Οι τελευταίες εκδόσεις του SSL στο MongoDB περιλαμβάνουν τις ακόλουθες βασικές δυνατότητες:

• Έλεγχοι για έγκυρους κεντρικούς υπολογιστές (προαιρετικά)
• Δυνατότητα να δείξετε ένα συγκεκριμένο αρχείο .key για χρήση
• Προσαρμοσμένη αρχή έκδοσης πιστοποιητικών (CA) για αυτο-υπογεγραμμένα πιστοποιητικά ή εναλλακτικούς υπογράφοντες
• allowSSL, προτιμώ SSL, απαιτείταιSSL λειτουργίες, οι οποίες σας επιτρέπουν να επιλέξετε μια λεπτομέρεια για τη χρήση SSL (από λιγότερο ασφαλή έως πιο ασφαλή)

SSL: Χρήση προσαρμοσμένης ΑΠ

Οι νεότερες εκδόσεις του SSL στο MongoDB σάς επιτρέπουν να χρησιμοποιείτε μια προσαρμοσμένη CA. Ενώ αυτό σας δίνει ευελιξία στον καθορισμό του τρόπου με τον οποίο θέλετε να εργαστείτε με SSL, συνοδεύεται από προειδοποιήσεις. Εάν απλώς προσπαθείτε να εξασφαλίσετε τη σύνδεση, ενδέχεται να μπείτε στον πειρασμό να επιλέξετε sslAllowInvalidCertficates. Ωστόσο, αυτή είναι γενικά μια κακή ιδέα για μερικούς λόγους:

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

Για να το διορθώσετε, απλώς ορίστε net.ssl.CAFileκαι το MongoDB θα χρησιμοποιήσει και τα δυο το κλειδί και το αρχείο CA (πρέπει να το κάνετε αυτό στον πελάτη).

Η χρήση SSL, ωστόσο, έχει ένα γνωστό μειονέκτημα: απόδοση. Σίγουρα θα χάσετε κάποια απόδοση όταν χρησιμοποιείτε SSL.

Κρυπτογράφηση δίσκου

Τα δεδομένα είναι είτε «σε διαμετακόμιση» είτε «σε κατάσταση ηρεμίας». Μπορείτε να κρυπτογραφήσετε ένα ή και τα δύο στο MongoDB. Συζητήσαμε την κρυπτογράφηση δεδομένων υπό διαμετακόμιση (SSL). Τώρα ας δούμε τα δεδομένα σε ηρεμία.

Τα δεδομένα σε κατάσταση ηρεμίας είναι δεδομένα που αποθηκεύονται στο δίσκο. Η κρυπτογράφηση Data-at-rest συνήθως αναφέρεται σε δεδομένα που αποθηκεύονται σε κρυπτογραφημένη τοποθεσία αποθήκευσης. Αυτό γίνεται για την αποφυγή κλοπής με φυσικά μέσα και τη δημιουργία αντιγράφων ασφαλείας που αποθηκεύονται με τρόπο που δεν διαβάζεται εύκολα από τρίτους. Υπάρχουν πρακτικά όρια σε αυτό. Το μεγαλύτερο είναι να εμπιστεύεστε τους διαχειριστές του συστήματός σας - και υποθέτοντας ότι ένας εισβολέας δεν έχει αποκτήσει πρόσβαση διαχειριστή στο σύστημα.

Αυτό δεν είναι ένα μοναδικό ζήτημα για το MongoDB. Τα προληπτικά μέτρα που χρησιμοποιούνται σε άλλα συστήματα λειτουργούν επίσης εδώ. Μπορεί να περιλαμβάνουν εργαλεία κρυπτογράφησης όπως LUKS και cryptfs ή ακόμα πιο ασφαλείς μεθόδους, όπως υπογραφή κλειδιών κρυπτογράφησης με LDAP, έξυπνες κάρτες και διακριτικά τύπου RSA.

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

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

• Κρυπτογράφηση ολόκληρου του τόμου
• Κρυπτογράφηση μόνο των αρχείων βάσης δεδομένων
• Κρυπτογράφηση στην εφαρμογή

Το πρώτο στοιχείο μπορεί να επιλυθεί με κρυπτογράφηση δίσκου στο σύστημα αρχείων. Είναι εύκολο να ρυθμιστεί χρησιμοποιώντας LUKS και dm-crypt. Απαιτούνται μόνο η πρώτη και η δεύτερη επιλογή για συμμόρφωση με PCI DSS και άλλες απαιτήσεις πιστοποίησης.

Έλεγχος

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

Ο έλεγχος σάς επιτρέπει να παρακολουθείτε πλήρως τις ενέργειες ενός εισβολέα στο περιβάλλον σας.

Σημείωση: Ο έλεγχος είναι διαθέσιμος μόνο στο MongoDB Enterprise. Δεν είναι στην έκδοση της Κοινότητας. Είναι διαθέσιμο σε ορισμένες άλλες εκδόσεις ανοιχτού κώδικα του MongoDB, όπως Percona Server για MongoDB.