Ονομάζομαι Denis Rozhkov, είμαι επικεφαλής ανάπτυξης λογισμικού στην εταιρεία Gazinformservice, στην ομάδα προϊόντων . Η νομοθεσία και οι εταιρικοί κανονισμοί επιβάλλουν ορισμένες απαιτήσεις για την ασφάλεια της αποθήκευσης δεδομένων. Κανείς δεν θέλει τρίτα μέρη να αποκτήσουν πρόσβαση σε εμπιστευτικές πληροφορίες, επομένως τα ακόλουθα ζητήματα είναι σημαντικά για κάθε έργο: αναγνώριση και έλεγχος ταυτότητας, διαχείριση πρόσβασης στα δεδομένα, διασφάλιση της ακεραιότητας των πληροφοριών στο σύστημα, καταγραφή συμβάντων ασφαλείας. Επομένως, θέλω να μιλήσω για μερικά ενδιαφέροντα σημεία σχετικά με την ασφάλεια DBMS.
Το άρθρο ετοιμάστηκε με βάση μια ομιλία στο διοργάνωσε . Αν δεν θέλετε να διαβάσετε, μπορείτε να παρακολουθήσετε:
Το άρθρο θα έχει τρία μέρη:
- Πώς να ασφαλίσετε τις συνδέσεις.
- Τι είναι ο έλεγχος ενεργειών και πώς να καταγράψετε τι συμβαίνει στην πλευρά της βάσης δεδομένων και να συνδεθείτε σε αυτήν.
- Πώς να προστατεύσετε δεδομένα στην ίδια τη βάση δεδομένων και ποιες τεχνολογίες είναι διαθέσιμες για αυτό.
Τρία στοιχεία της ασφάλειας DBMS: προστασία σύνδεσης, έλεγχος δραστηριότητας και προστασία δεδομένων
Διασφάλιση των συνδέσεών σας
Μπορείτε να συνδεθείτε στη βάση δεδομένων είτε άμεσα είτε έμμεσα μέσω διαδικτυακών εφαρμογών. Κατά κανόνα, ο επιχειρηματικός χρήστης, δηλαδή το άτομο που εργάζεται με το DBMS, αλληλεπιδρά μαζί του έμμεσα.
Πριν μιλήσετε για την προστασία των συνδέσεων, πρέπει να απαντήσετε σε σημαντικές ερωτήσεις που καθορίζουν πώς θα δομηθούν τα μέτρα ασφαλείας:
- Είναι ένας επαγγελματικός χρήστης ισοδύναμος με έναν χρήστη DBMS;
- εάν η πρόσβαση σε δεδομένα DBMS παρέχεται μόνο μέσω ενός API που ελέγχετε ή εάν γίνεται απευθείας πρόσβαση σε πίνακες.
- εάν το DBMS έχει εκχωρηθεί σε ένα ξεχωριστό προστατευμένο τμήμα, ποιος αλληλεπιδρά με αυτό και πώς.
- εάν χρησιμοποιούνται επίπεδα συγκέντρωσης/διαμεσολάβησης και ενδιάμεσα επίπεδα, τα οποία μπορούν να αλλάξουν πληροφορίες σχετικά με τον τρόπο δημιουργίας της σύνδεσης και το ποιος χρησιμοποιεί τη βάση δεδομένων.
Τώρα ας δούμε ποια εργαλεία μπορούν να χρησιμοποιηθούν για την ασφάλεια των συνδέσεων:
- Χρησιμοποιήστε λύσεις κλάσης τείχους προστασίας βάσης δεδομένων. Ένα πρόσθετο επίπεδο προστασίας θα αυξήσει, τουλάχιστον, τη διαφάνεια του τι συμβαίνει στο DBMS και το μέγιστο θα μπορείτε να παρέχετε πρόσθετη προστασία δεδομένων.
- Χρησιμοποιήστε πολιτικές κωδικών πρόσβασης. Η χρήση τους εξαρτάται από τον τρόπο κατασκευής της αρχιτεκτονικής σας. Σε κάθε περίπτωση, ένας κωδικός πρόσβασης στο αρχείο διαμόρφωσης μιας web εφαρμογής που συνδέεται με το DBMS δεν αρκεί για προστασία. Υπάρχει μια σειρά από εργαλεία DBMS που σας επιτρέπουν να ελέγχετε ότι ο χρήστης και ο κωδικός πρόσβασης απαιτούν ενημέρωση.
Μπορείτε να διαβάσετε περισσότερα σχετικά με τις λειτουργίες αξιολόγησης χρηστών , μπορείτε επίσης να μάθετε για τους Αξιολογητές ευπάθειας MS SQL .
- Εμπλουτίστε το πλαίσιο της συνεδρίας με τις απαραίτητες πληροφορίες. Εάν η περίοδος λειτουργίας είναι αδιαφανής, δεν καταλαβαίνετε ποιος εργάζεται στο DBMS στο πλαίσιο του, μπορείτε, στο πλαίσιο της λειτουργίας που εκτελείται, να προσθέσετε πληροφορίες σχετικά με το ποιος κάνει τι και γιατί. Αυτές οι πληροφορίες φαίνονται στον έλεγχο.
- Διαμορφώστε το SSL εάν δεν έχετε διαχωρισμό δικτύου μεταξύ του DBMS και των τελικών χρηστών· δεν βρίσκεται σε ξεχωριστό VLAN. Σε τέτοιες περιπτώσεις, είναι επιτακτική η προστασία του καναλιού μεταξύ του καταναλωτή και του ίδιου του DBMS. Τα εργαλεία ασφαλείας είναι επίσης διαθέσιμα σε ανοιχτό κώδικα.
Πώς θα επηρεάσει αυτό την απόδοση του DBMS;
Ας δούμε το παράδειγμα της PostgreSQL για να δούμε πώς το SSL επηρεάζει το φόρτο της CPU, αυξάνει τους χρονισμούς και μειώνει το TPS και αν θα καταναλώσει πάρα πολλούς πόρους εάν το ενεργοποιήσετε.
Η φόρτωση του PostgreSQL χρησιμοποιώντας το pgbench είναι ένα απλό πρόγραμμα για την εκτέλεση δοκιμών απόδοσης. Εκτελεί μια μεμονωμένη ακολουθία εντολών επανειλημμένα, πιθανώς σε παράλληλες συνεδρίες βάσης δεδομένων, και στη συνέχεια υπολογίζει το μέσο ποσοστό συναλλαγής.
Δοκιμή 1 χωρίς SSL και με χρήση SSL — η σύνδεση δημιουργείται για κάθε συναλλαγή:
pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"vs
pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Δοκιμή 2 χωρίς SSL και με χρήση SSL — όλες οι συναλλαγές εκτελούνται σε μία σύνδεση:
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"vs
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Αλλες ρυθμίσεις:
scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000Αποτελέσματα δοκιμών:
ΟΧΙ SSL
SSL
Δημιουργείται σύνδεση για κάθε συναλλαγή
μέσος όρος καθυστέρησης
ms 171.915
ms 187.695
tps συμπεριλαμβανομένης της δημιουργίας συνδέσεων
58.168112
53.278062
tps εξαιρουμένης της δημιουργίας συνδέσεων
64.084546
58.725846
CPU
24%
28%
Όλες οι συναλλαγές εκτελούνται σε μία σύνδεση
μέσος όρος καθυστέρησης
ms 6.722
ms 6.342
tps συμπεριλαμβανομένης της δημιουργίας συνδέσεων
1587.657278
1576.792883
tps εξαιρουμένης της δημιουργίας συνδέσεων
1588.380574
1577.694766
CPU
17%
21%
Σε ελαφρά φορτία, η επίδραση του SSL είναι συγκρίσιμη με το σφάλμα μέτρησης. Εάν ο όγκος των δεδομένων που μεταφέρονται είναι πολύ μεγάλος, η κατάσταση μπορεί να είναι διαφορετική. Εάν δημιουργήσουμε μία σύνδεση ανά συναλλαγή (αυτό είναι σπάνιο, συνήθως η σύνδεση είναι κοινή μεταξύ των χρηστών), έχετε μεγάλο αριθμό συνδέσεων/αποσυνδέσεων, ο αντίκτυπος μπορεί να είναι λίγο μεγαλύτερος. Δηλαδή, μπορεί να υπάρχουν κίνδυνοι μειωμένης απόδοσης, ωστόσο, η διαφορά δεν είναι τόσο μεγάλη ώστε να μην χρησιμοποιείται προστασία.
Λάβετε υπόψη ότι υπάρχει μεγάλη διαφορά εάν συγκρίνετε τους τρόπους λειτουργίας: εργάζεστε στην ίδια περίοδο λειτουργίας ή σε διαφορετικές. Αυτό είναι κατανοητό: δαπανώνται πόροι για τη δημιουργία κάθε σύνδεσης.
Είχαμε μια περίπτωση που συνδέσαμε το Zabbix σε λειτουργία εμπιστοσύνης, δηλαδή το md5 δεν ήταν τσεκαρισμένο, δεν χρειαζόταν έλεγχος ταυτότητας. Στη συνέχεια, ο πελάτης ζήτησε να ενεργοποιηθεί η λειτουργία ελέγχου ταυτότητας md5. Αυτό φόρτωσε πολύ τη CPU και η απόδοση έπεσε. Αρχίσαμε να αναζητούμε τρόπους βελτιστοποίησης. Μία από τις πιθανές λύσεις στο πρόβλημα είναι να εφαρμόσετε έναν περιορισμό δικτύου, να δημιουργήσετε ξεχωριστά VLAN για το DBMS, να προσθέσετε ρυθμίσεις για να καταστεί σαφές ποιος συνδέεται από πού και να καταργήσετε τον έλεγχο ταυτότητας. Μπορείτε επίσης να βελτιστοποιήσετε τις ρυθμίσεις ελέγχου ταυτότητας για να μειώσετε το κόστος κατά την ενεργοποίηση του ελέγχου ταυτότητας , αλλά γενικά η χρήση διαφορετικών μεθόδων ελέγχου ταυτότητας επηρεάζει την απόδοση και απαιτεί τη συνεκτίμηση αυτών των παραγόντων κατά το σχεδιασμό της υπολογιστικής ισχύος των διακομιστών (hardware) για το DBMS.
Συμπέρασμα: σε πολλές λύσεις, ακόμη και μικρές αποχρώσεις στον έλεγχο ταυτότητας μπορούν να επηρεάσουν πολύ το έργο και είναι κακό όταν αυτό γίνεται σαφές μόνο όταν εφαρμόζεται στην παραγωγή.
Έλεγχος δράσης
Ο έλεγχος μπορεί να είναι όχι μόνο DBMS. Ο έλεγχος αφορά τη λήψη πληροφοριών σχετικά με το τι συμβαίνει σε διαφορετικούς τομείς. Αυτό μπορεί να είναι είτε ένα τείχος προστασίας βάσης δεδομένων είτε το λειτουργικό σύστημα στο οποίο είναι χτισμένο το DBMS.
Στα DBMS εμπορικού επιπέδου Enterprise όλα είναι καλά με τον έλεγχο, αλλά σε ανοιχτό κώδικα - όχι πάντα. Δείτε τι έχει η PostgreSQL:
- προεπιλεγμένη σύνδεση - ενσωματωμένη καταγραφή.
- επεκτάσεις: pgaudit - εάν η προεπιλεγμένη καταγραφή δεν είναι αρκετή για εσάς, μπορείτε να χρησιμοποιήσετε ξεχωριστές ρυθμίσεις που λύνουν ορισμένα προβλήματα.
Προσθήκη στην αναφορά στο βίντεο:
"Η καταγραφή βασικών δηλώσεων μπορεί να παρέχεται από μια τυπική εγκατάσταση καταγραφής με log_statement = όλα.
Αυτό είναι αποδεκτό για παρακολούθηση και άλλες χρήσεις, αλλά δεν παρέχει το επίπεδο λεπτομέρειας που συνήθως απαιτείται για τον έλεγχο.
Δεν αρκεί να έχουμε μια λίστα με όλες τις λειτουργίες που εκτελούνται στη βάση δεδομένων.
Θα πρέπει επίσης να είναι δυνατό να βρεθούν συγκεκριμένες δηλώσεις που ενδιαφέρουν τον ελεγκτή.
Η τυπική καταγραφή δείχνει τι ζήτησε ο χρήστης, ενώ το pgAudit εστιάζει στις λεπτομέρειες του τι συνέβη όταν η βάση δεδομένων εκτέλεσε το ερώτημα.
Για παράδειγμα, ο ελεγκτής μπορεί να θέλει να επαληθεύσει ότι ένας συγκεκριμένος πίνακας δημιουργήθηκε μέσα σε ένα τεκμηριωμένο παράθυρο συντήρησης.
Αυτό μπορεί να φαίνεται σαν μια απλή εργασία με βασικό έλεγχο και grep, αλλά τι θα γινόταν αν σας παρουσιαζόταν κάτι τέτοιο (εσκεμμένα μπερδεμένο) παράδειγμα:
DO$$
ΑΡΧΙΖΟΥΝ
ΕΚΤΕΛΕΣΤΕ «ΔΗΜΙΟΥΡΓΙΑ ΠΙΝΑΚΑ εισαγωγής» || 'ant_table(id int)';
ΤΕΛΟΣ$$;
Η τυπική καταγραφή θα σας δώσει αυτό:
LOG: δήλωση: DO $$
ΑΡΧΙΖΟΥΝ
ΕΚΤΕΛΕΣΤΕ «ΔΗΜΙΟΥΡΓΙΑ ΠΙΝΑΚΑ εισαγωγής» || 'ant_table(id int)';
ΤΕΛΟΣ$$;
Φαίνεται ότι η εύρεση του πίνακα ενδιαφέροντος μπορεί να απαιτεί κάποιες γνώσεις κώδικα σε περιπτώσεις όπου οι πίνακες δημιουργούνται δυναμικά.
Αυτό δεν είναι ιδανικό, καθώς θα ήταν προτιμότερο να κάνετε απλώς αναζήτηση με βάση το όνομα του πίνακα.
Εδώ είναι χρήσιμο το pgAudit.
Για την ίδια είσοδο, θα παράγει αυτήν την έξοδο στο αρχείο καταγραφής:
ΕΛΕΓΧΟΣ: SESSION,33,1,FUNCTION,DO,,"DO $$
ΑΡΧΙΖΟΥΝ
ΕΚΤΕΛΕΣΤΕ «ΔΗΜΙΟΥΡΓΙΑ ΠΙΝΑΚΑ εισαγωγής» || 'ant_table(id int)';
ΤΕΛΟΣ$$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (ID INT)
Δεν καταγράφεται μόνο το μπλοκ DO, αλλά και το πλήρες κείμενο του CREATE TABLE με τύπο δήλωσης, τύπο αντικειμένου και πλήρες όνομα, διευκολύνοντας την αναζήτηση.
Κατά την καταγραφή των δηλώσεων SELECT και DML, το pgAudit μπορεί να ρυθμιστεί ώστε να καταγράφει μια ξεχωριστή καταχώρηση για κάθε σχέση που αναφέρεται στη δήλωση.
Δεν απαιτείται ανάλυση για την εύρεση όλων των εντολών που αγγίζουν έναν συγκεκριμένο πίνακα() ».
Πώς θα επηρεάσει αυτό την απόδοση του DBMS;
Ας εκτελέσουμε δοκιμές με ενεργοποιημένο τον πλήρη έλεγχο και ας δούμε τι συμβαίνει με την απόδοση PostgreSQL. Ας ενεργοποιήσουμε τη μέγιστη καταγραφή βάσης δεδομένων για όλες τις παραμέτρους.
Δεν αλλάζουμε σχεδόν τίποτα στο αρχείο διαμόρφωσης, το πιο σημαντικό είναι να ενεργοποιήσετε τη λειτουργία εντοπισμού σφαλμάτων5 για να λάβετε τις μέγιστες πληροφορίες.
postgresql.conf
log_destination = 'stderr'
logging_collector = ενεργό
log_truncate_on_rotation = ενεργό
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = εντοπισμός σφαλμάτων 5
log_min_error_statement = εντοπισμός σφαλμάτων 5
log_min_duration_statement = 0
debug_print_parse = ενεργό
debug_print_rewritten = ενεργό
debug_print_plan = ενεργό
debug_pretty_print = ενεργό
log_checkpoints = ενεργό
log_connections = ενεργό
log_disconnections = ενεργό
log_duration = ενεργό
log_hostname = ενεργό
log_lock_wait = ενεργό
log_replication_commands = ενεργό
log_temp_files = 0
log_timezone = 'Ευρώπη/Μόσχα'
Σε ένα PostgreSQL DBMS με παραμέτρους 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, πραγματοποιούμε τρεις δοκιμές φόρτωσης χρησιμοποιώντας τις εντολές:
$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmarkΑποτελέσματα δοκιμής:
Χωρίς υλοτομία
Με υλοτομία
Συνολικός χρόνος πλήρωσης της βάσης δεδομένων
43,74 sec
53,23 sec
RAM
24%
40%
CPU
72%
91%
Δοκιμή 1 (50 συνδέσεις)
Αριθμός συναλλαγών σε 10 λεπτά
74169
32445
Συναλλαγές/δευτ
123
54
Μέση καθυστέρηση
405 ms
925 ms
Δοκιμή 2 (150 συνδέσεις με 100 πιθανές)
Αριθμός συναλλαγών σε 10 λεπτά
81727
31429
Συναλλαγές/δευτ
136
52
Μέση καθυστέρηση
550 ms
1432 ms
Σχετικά με τα μεγέθη
Μέγεθος DB
2251 MB
2262 MB
Μέγεθος αρχείου καταγραφής βάσης δεδομένων
0 MB
4587 MB
Κατώτατη γραμμή: ένας πλήρης έλεγχος δεν είναι πολύ καλός. Τα δεδομένα από τον έλεγχο θα είναι τόσο μεγάλα όσο τα δεδομένα στην ίδια τη βάση δεδομένων, ή ακόμα περισσότερα. Η ποσότητα της καταγραφής που δημιουργείται κατά την εργασία με ένα DBMS είναι ένα κοινό πρόβλημα στην παραγωγή.
Ας δούμε και άλλες παραμέτρους:
- Η ταχύτητα δεν αλλάζει πολύ: χωρίς καταγραφή - 43,74 δευτερόλεπτα, με καταγραφή - 53,23 δευτερόλεπτα.
- Η απόδοση της μνήμης RAM και της CPU θα υποφέρει, καθώς πρέπει να δημιουργήσετε ένα αρχείο ελέγχου. Αυτό φαίνεται και στην παραγωγικότητα.
Καθώς ο αριθμός των συνδέσεων αυξάνεται, φυσικά, η απόδοση θα επιδεινωθεί ελαφρώς.
Σε εταιρείες με έλεγχο είναι ακόμη πιο δύσκολο:
- υπάρχουν πολλά δεδομένα?
- ο έλεγχος απαιτείται όχι μόνο μέσω του syslog στο SIEM, αλλά και στα αρχεία: εάν συμβεί κάτι με το syslog, πρέπει να υπάρχει ένα αρχείο κοντά στη βάση δεδομένων στην οποία αποθηκεύονται τα δεδομένα.
- για τον έλεγχο χρειάζεται ξεχωριστό ράφι για να μην σπαταλάτε σε δίσκους I/O, μιας και πιάνει πολύ χώρο.
- Συμβαίνει ότι οι υπάλληλοι της ασφάλειας πληροφοριών χρειάζονται τα πρότυπα GOST παντού, απαιτούν ταυτοποίηση του κράτους.
Περιορισμός πρόσβασης σε δεδομένα
Ας δούμε τις τεχνολογίες που χρησιμοποιούνται για την προστασία των δεδομένων και την πρόσβαση σε αυτά σε εμπορικά DBMS και ανοιχτού κώδικα.
Τι μπορείτε να χρησιμοποιήσετε γενικά:
- Κρυπτογράφηση και συσκότιση διαδικασιών και λειτουργιών (Wrapping) - δηλαδή ξεχωριστά εργαλεία και βοηθητικά προγράμματα που κάνουν τον αναγνώσιμο κώδικα μη αναγνώσιμο. Είναι αλήθεια, τότε δεν μπορεί ούτε να αλλάξει ούτε να ανακατασκευαστεί ξανά. Αυτή η προσέγγιση μερικές φορές απαιτείται τουλάχιστον από την πλευρά του DBMS - η λογική των περιορισμών άδειας χρήσης ή η λογική εξουσιοδότησης κρυπτογραφείται ακριβώς σε επίπεδο διαδικασίας και λειτουργίας.
- Ο περιορισμός της ορατότητας των δεδομένων κατά σειρές (RLS) είναι όταν διαφορετικοί χρήστες βλέπουν έναν πίνακα, αλλά μια διαφορετική σύνθεση σειρών σε αυτόν, δηλαδή, κάτι δεν μπορεί να εμφανιστεί σε κάποιον σε επίπεδο γραμμής.
- Η επεξεργασία των εμφανιζόμενων δεδομένων (Μάσκα) είναι όταν οι χρήστες σε μια στήλη του πίνακα βλέπουν είτε δεδομένα είτε μόνο αστερίσκους, δηλαδή για ορισμένους χρήστες οι πληροφορίες θα είναι κλειστές. Η τεχνολογία καθορίζει ποιος χρήστης εμφανίζεται με βάση το επίπεδο πρόσβασής του.
- Ασφάλεια DBA/Application Ο έλεγχος πρόσβασης DBA/DBA αφορά μάλλον τον περιορισμό της πρόσβασης στο ίδιο το DBMS, δηλαδή, οι υπάλληλοι ασφάλειας πληροφοριών μπορούν να διαχωριστούν από τους διαχειριστές βάσεων δεδομένων και τους διαχειριστές εφαρμογών. Υπάρχουν λίγες τέτοιες τεχνολογίες σε ανοιχτό κώδικα, αλλά υπάρχουν πολλές σε εμπορικά DBMS. Χρειάζονται όταν υπάρχουν πολλοί χρήστες με πρόσβαση στους ίδιους τους διακομιστές.
- Περιορισμός της πρόσβασης σε αρχεία σε επίπεδο συστήματος αρχείων. Μπορείτε να εκχωρήσετε δικαιώματα και δικαιώματα πρόσβασης σε καταλόγους, ώστε κάθε διαχειριστής να έχει πρόσβαση μόνο στα απαραίτητα δεδομένα.
- Υποχρεωτική πρόσβαση και εκκαθάριση μνήμης - αυτές οι τεχνολογίες χρησιμοποιούνται σπάνια.
- Η κρυπτογράφηση από άκρο σε άκρο απευθείας από το DBMS είναι κρυπτογράφηση από την πλευρά του πελάτη με διαχείριση κλειδιών από την πλευρά του διακομιστή.
- Κρυπτογράφηση δεδομένων. Για παράδειγμα, η κρυπτογράφηση στήλης είναι όταν χρησιμοποιείτε έναν μηχανισμό που κρυπτογραφεί μια στήλη της βάσης δεδομένων.
Πώς επηρεάζει αυτό την απόδοση του DBMS;
Ας δούμε το παράδειγμα της στήλης κρυπτογράφησης στο PostgreSQL. Υπάρχει μια μονάδα pgcrypto, σας επιτρέπει να αποθηκεύετε επιλεγμένα πεδία σε κρυπτογραφημένη μορφή. Αυτό είναι χρήσιμο όταν μόνο ορισμένα δεδομένα είναι πολύτιμα. Για την ανάγνωση των κρυπτογραφημένων πεδίων, ο πελάτης μεταδίδει ένα κλειδί αποκρυπτογράφησης, ο διακομιστής αποκρυπτογραφεί τα δεδομένα και τα επιστρέφει στον πελάτη. Χωρίς το κλειδί, κανείς δεν μπορεί να κάνει τίποτα με τα δεδομένα σας.
Ας δοκιμάσουμε με το pgcrypto. Ας δημιουργήσουμε έναν πίνακα με κρυπτογραφημένα δεδομένα και κανονικά δεδομένα. Παρακάτω είναι οι εντολές για τη δημιουργία πινάκων, στην πρώτη γραμμή υπάρχει μια χρήσιμη εντολή - δημιουργία της ίδιας της επέκτασης με εγγραφή DBMS:
CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));Στη συνέχεια, ας προσπαθήσουμε να δημιουργήσουμε ένα δείγμα δεδομένων από κάθε πίνακα και να δούμε τους χρονισμούς εκτέλεσης.
Επιλογή από πίνακα χωρίς λειτουργία κρυπτογράφησης:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtΤο χρονόμετρο είναι ενεργοποιημένο.
id | κείμενο1 | κείμενο2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 γραμμές)
Χρόνος: 1,386 ms
Επιλογή από πίνακα με λειτουργία κρυπτογράφησης:
psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txtΤο χρονόμετρο είναι ενεργοποιημένο.
id | αποκρυπτογράφηση | αποκρυπτογράφηση
——+—————+—————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 γραμμές)
Χρόνος: 50,203 ms
Αποτελέσματα δοκιμών:
Χωρίς κρυπτογράφηση
Pgcrypto (αποκρυπτογράφηση)
Δείγμα 1000 σειρών
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Η κρυπτογράφηση έχει μεγάλο αντίκτυπο στην απόδοση. Μπορεί να φανεί ότι ο συγχρονισμός έχει αυξηθεί, καθώς οι λειτουργίες αποκρυπτογράφησης κρυπτογραφημένων δεδομένων (και η αποκρυπτογράφηση είναι συνήθως ακόμα τυλιγμένη στη λογική σας) απαιτούν σημαντικούς πόρους. Δηλαδή, η ιδέα της κρυπτογράφησης όλων των στηλών που περιέχουν ορισμένα δεδομένα είναι γεμάτη με μείωση της απόδοσης.
Ωστόσο, η κρυπτογράφηση δεν είναι μια ασημένια κουκκίδα που λύνει όλα τα προβλήματα. Τα αποκρυπτογραφημένα δεδομένα και το κλειδί αποκρυπτογράφησης κατά τη διαδικασία αποκρυπτογράφησης και μετάδοσης των δεδομένων βρίσκονται στον διακομιστή. Επομένως, τα κλειδιά μπορούν να υποκλαπούν από κάποιον που έχει πλήρη πρόσβαση στον διακομιστή της βάσης δεδομένων, όπως ένας διαχειριστής συστήματος.
Όταν υπάρχει ένα κλειδί για ολόκληρη τη στήλη για όλους τους χρήστες (ακόμη και αν όχι για όλους, αλλά για πελάτες ενός περιορισμένου συνόλου), αυτό δεν είναι πάντα καλό και σωστό. Αυτός είναι ο λόγος για τον οποίο άρχισαν να κάνουν κρυπτογράφηση από άκρο σε άκρο, στο DBMS άρχισαν να εξετάζουν επιλογές για κρυπτογράφηση δεδομένων από την πλευρά του πελάτη και του διακομιστή και εμφανίστηκαν οι ίδιες αποθήκες κλειδιών - ξεχωριστά προϊόντα που παρέχουν διαχείριση κλειδιών στο DBMS πλευρά.
Λειτουργίες ασφαλείας σε εμπορικά και ανοιχτού κώδικα DBMS
Λειτουργίες
Τύπος
Πολιτική κωδικού πρόσβασης
Έλεγχος
Προστασία του πηγαίου κώδικα διαδικασιών και λειτουργιών
RLS
κρυπτογράφηση
μαντείο
εμπορικός
+
+
+
+
+
MsSql
εμπορικός
+
+
+
+
+
εμπορικός
+
+
+
+
επεκτάσεις
PostgreSQL
Δωρεάν
επεκτάσεις
επεκτάσεις
-
+
επεκτάσεις
MongoDb
Δωρεάν
-
+
-
-
Διατίθεται μόνο στο MongoDB Enterprise
Ο πίνακας απέχει πολύ από το να είναι ολοκληρωμένος, αλλά η κατάσταση είναι η εξής: στα εμπορικά προϊόντα, τα προβλήματα ασφάλειας έχουν λυθεί εδώ και πολύ καιρό, στον ανοιχτό κώδικα, κατά κανόνα, χρησιμοποιούνται κάποιο είδος πρόσθετων για ασφάλεια, λείπουν πολλές λειτουργίες , μερικές φορές πρέπει να προσθέσετε κάτι. Για παράδειγμα, πολιτικές κωδικών πρόσβασης - Η PostgreSQL έχει πολλές διαφορετικές επεκτάσεις (, , , , ), οι οποίες εφαρμόζουν πολιτικές κωδικών πρόσβασης, αλλά, κατά τη γνώμη μου, καμία από αυτές δεν καλύπτει όλες τις ανάγκες του εγχώριου εταιρικού τμήματος.
Τι να κάνετε αν δεν έχετε ό,τι χρειάζεστε πουθενά? Για παράδειγμα, θέλετε να χρησιμοποιήσετε ένα συγκεκριμένο DBMS που δεν έχει τις λειτουργίες που απαιτεί ο πελάτης.
Στη συνέχεια, μπορείτε να χρησιμοποιήσετε λύσεις τρίτων που λειτουργούν με διαφορετικά DBMS, για παράδειγμα, Crypto DB ή Garda DB. Αν μιλάμε για λύσεις από το εγχώριο τμήμα, τότε γνωρίζουν για GOST καλύτερα από ό, τι σε ανοιχτό κώδικα.
Η δεύτερη επιλογή είναι να γράψετε μόνοι σας αυτό που χρειάζεστε, να εφαρμόσετε πρόσβαση σε δεδομένα και κρυπτογράφηση στην εφαρμογή σε επίπεδο διαδικασίας. Είναι αλήθεια ότι θα είναι πιο δύσκολο με το GOST. Αλλά γενικά, μπορείτε να αποκρύψετε τα δεδομένα όπως χρειάζεται, να τα βάλετε σε ένα DBMS, στη συνέχεια να τα ανακτήσετε και να τα αποκρυπτογραφήσετε όπως χρειάζεται, ακριβώς στο επίπεδο της εφαρμογής. Ταυτόχρονα, σκεφτείτε αμέσως πώς θα προστατέψετε αυτούς τους αλγόριθμους στην εφαρμογή. Κατά τη γνώμη μας, αυτό πρέπει να γίνει σε επίπεδο DBMS, γιατί θα λειτουργήσει πιο γρήγορα.
Αυτή η έκθεση παρουσιάστηκε για πρώτη φορά στο από τη Mail.ru Cloud Solutions. Κοίταάλλες παραστάσεις και εγγραφείτε σε ανακοινώσεις εκδηλώσεων στο Telegram .
Τι άλλο να διαβάσετε για το θέμα:
- .
- .
Πηγή: www.habr.com