Γιατί να προστατεύεις έναν κωδικό πρόσβασης, αν μπορείς να τον καταργήσεις;

Το πρόβλημα που έχουμε συνηθίσει να θεωρούμε φυσιολογικό

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

Έχουμε συνηθίσει τόσο πολύ αυτή τη δομή, ώστε σχεδόν πάψαμε να αναρωτιόμαστε: είναι απαραίτητο να λειτουργούν όλα ακριβώς έτσι;

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

Τι γίνεται όμως όταν τα έργα γίνουν δέκα, είκοσι ή τριάντα;

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

Κατά συνέπεια, το καθένα χρειάζεται έναν μηχανισμό διαχειριστικής πρόσβασης.

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

Λειτουργούσε.

Κάποια στιγμή, όμως, αναρωτήθηκα: γιατί να πρέπει να αποθηκεύω τόσους πολλούς κωδικούς διαχειριστή; Γιατί πρέπει να προστατεύω όχι μόνο τους διακομιστές, αλλά και τα ίδια τα μέσα πρόσβασης σε αυτούς;

Και μήπως μπορώ να απαλλαγώ από αυτή την ανάγκη;

Κατέληξα σε μια σκέψη που αργότερα έγινε η βάση της λύσης μου:

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

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

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

Όχι απλώς να κρύψω τη φόρμα σύνδεσης.

Ούτε να αλλάξω τη διεύθυνση.

Ούτε να αντικαταστήσω τον κωδικό με έναν ακόμη πιο σύνθετο κωδικό.

Αλλά να καταργήσω την ίδια την ανάγκη για μια μόνιμα διαθέσιμη σύνδεση με κωδικό πρόσβασης.

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

Αυτό που άλλαξε είναι ο τρόπος απόκτησης πρόσβασης σε αυτές.

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

Αντί γι' αυτό, χρησιμοποιώ το δικό μου σύστημα ταυτοποίησης και διαχείρισης πρόσβασης, το MeldID.

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

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

Το δικαίωμα αυτό πρέπει να παραχωρείται ξεχωριστά.

Πρόσβαση που δεν υπήρχε πριν από ένα λεπτό

Αυτή είναι, ίσως, η πιο ενδιαφέρουσα πτυχή όλης της ιδέας.

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

Αποφάσισα να αλλάξω αυτή την αρχή.

Αντί για μόνιμα διαπιστευτήρια διαχειριστή, υπάρχει μια προσωρινή δυνατότητα έναρξης της διαδικασίας σύνδεσης.

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

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

Αυτό είναι καθοριστικό.

Ας υποθέσουμε ότι κάποιος αποκτά με κάποιον τρόπο τον σύνδεσμο. Σε ένα συνηθισμένο σύστημα που βασίζεται αποκλειστικά στη μυστικότητα της διεύθυνσης, μια τέτοια διαρροή θα μπορούσε να αποτελέσει σοβαρό πρόβλημα.

Στο δικό μου μοντέλο, ο σύνδεσμος απλώς επιτρέπει την έναρξη της διαδικασίας επιβεβαίωσης.

Για να συνεχιστεί η διαδικασία, απαιτείται ξεχωριστή έγκριση μέσω μιας έμπιστης κινητής συσκευής MeldID.

Χωρίς την αντίστοιχη επιβεβαίωση, δεν δημιουργείται διαχειριστική συνεδρία.

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

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

Το τηλέφωνο γίνεται εργαλείο διαχείρισης της πρόσβασης

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

Χρησιμοποιείται για την επιβεβαίωση ενεργειών που σχετίζονται με τη διαχειριστική πρόσβαση.

Όταν θέλω να ανοίξω τον πίνακα διαχείρισης, το σύστημα ζητά επιβεβαίωση μέσω του MeldID.

Βλέπω το σχετικό αίτημα στην έμπιστη συσκευή μου και εγκρίνω την ενέργεια.

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

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

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

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

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

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

Μετά από αυτό, παύει να αποτελεί ενεργό μέσο εξουσιοδότησης για τις αντίστοιχες ενέργειες.

Ένα σύστημα — πολλά ανεξάρτητα έργα

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

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

Κάθε υπηρεσία DigiMeld έπρεπε να συνεχίσει να διαχειρίζεται τη δική της λογική, τις ρυθμίσεις, τους χρήστες και τα δεδομένα της.

Γι' αυτό διαχώρισα τις δύο λειτουργίες.

Το MeldID είναι υπεύθυνο για την ταυτοποίηση και την παραχώρηση διαχειριστικής πρόσβασης.

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

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

Επιπλέον, τα δικαιώματα παραχωρούνται ξεχωριστά.

Ο διαχειριστής ενός έργου δεν αποκτά αυτόματα πρόσβαση στα υπόλοιπα απλώς και μόνο επειδή έχει λογαριασμό MeldID.

Για κάθε τομέα διαχείρισης μπορεί να οριστεί ξεχωριστός κύκλος εξουσιοδοτημένων χρηστών.

Παράλληλα, τα δικαιώματα των απλών χρηστών και τα διαχειριστικά προνόμια παραμένουν διαχωρισμένα.

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

Γιατί προτιμώ την προσωρινή από τη μόνιμη πρόσβαση

Υπάρχει και μια ακόμη αρχή που ενσωμάτωσα συνειδητά στο σύστημα.

Η διαχειριστική πρόσβαση δεν πρέπει να διαρκεί επ' αόριστον.

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

Για να συνεχιστεί η εργασία μετά τη λήξη της, απαιτείται νέα διαδικασία επιβεβαίωσης.

Έτσι, μια αυθεντικοποίηση που έγινε κάποτε δεν μετατρέπεται σε μόνιμα ενεργό δικαίωμα.

Ο χρονικός περιορισμός, όμως, δεν αρκεί από μόνος του.

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

Γι' αυτό το MeldID προβλέπει κεντρική ανάκληση των διαχειριστικών αδειών.

Όταν ανακαλείται μια άδεια, τα συνδεδεμένα έργα λαμβάνουν το αντίστοιχο συμβάν και ακυρώνουν τις σχετικές διαχειριστικές συνεδρίες.

Έτσι, η διαχείριση της πρόσβασης δεν τελειώνει τη στιγμή που ο χρήστης συνδέεται επιτυχώς.

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

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

Τι άλλαξε στην καθημερινή εργασία;

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

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

Αντί γι' αυτό, διαχειρίζομαι τις άδειες μέσω ενός ενιαίου μηχανισμού.

Επιλέγω το έργο που χρειάζομαι, επιβεβαιώνω την πρόσβαση και εργάζομαι.

Όταν δεν χρειάζομαι πλέον διαχειριστική πρόσβαση, μπορώ να την ανακαλέσω.

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

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

Φυσικά, αυτό δεν σημαίνει ότι έχουν εξαφανιστεί όλοι οι κίνδυνοι ασφαλείας.

Οι προσωρινές άδειες, οι έμπιστες συσκευές, οι συνεδρίες διακομιστή και η κεντρική υποδομή χρειάζονται επίσης προστασία.

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

Και αυτός ήταν ένας από τους αρχικούς μου στόχους.

Μα δεν υπάρχουν ήδη τέτοιες τεχνολογίες;

Φυσικά και υπάρχουν.

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

Τέτοιες προσεγγίσεις συναντώνται σε συστήματα Identity and Access Management, Privileged Access Management και στις έννοιες Zero Trust.

Δεν ισχυρίζομαι ότι εφηύρα αυτές τις αρχές.

Ο δικός μου στόχος ήταν διαφορετικός.

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

Τελικά, συνδύασα αρκετές γνωστές προσεγγίσεις σε μία αρχιτεκτονική που ανταποκρίνεται στις απαιτήσεις μου.

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

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

Το MeldID δεν προορίζεται μόνο για πίνακες διαχείρισης

Εδώ αξίζει να διευκρινιστεί κάτι ξεχωριστά.

Το MeldID δεν δημιουργήθηκε αποκλειστικά ως εργαλείο για τη δική μου διαχειριστική πρόσβαση.

Παρέχει επίσης στους προγραμματιστές ένα SDK για την ενσωμάτωση μηχανισμών ταυτοποίησης και επιβεβαίωσης σύνδεσης στις δικές τους εφαρμογές.

Και αυτό το SDK διατίθεται δωρεάν.

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

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

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

Αυτό συμβάλλει στη μείωση του κινδύνου μη εξουσιοδοτημένης πρόσβασης σε περίπτωση παραβίασης των διαπιστευτηρίων.

Είναι σημαντικό να διακρίνουμε αυτή τη δυνατότητα του MeldID, που είναι διαθέσιμη σε όλους, από το μοντέλο διαχειριστικής πρόσβασης που ανέπτυξα για τα έργα DigiMeld.

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

Η ασφάλεια δεν αφορά μόνο την προστασία όσων ήδη υπάρχουν

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

Συχνά προσπαθούμε να προστατεύσουμε κάτι που υπάρχει για ιστορικούς λόγους.

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

Μερικές φορές αυτό είναι πράγματι απαραίτητο.

Άλλες φορές, όμως, είναι χρησιμότερο να θέσουμε ένα διαφορετικό ερώτημα:

Είναι απαραίτητο ο ίδιος ο μηχανισμός που προστατεύουμε να εξακολουθεί να υπάρχει στην παλιά του μορφή;

Στη δική μου περίπτωση, η απάντηση ήταν αρνητική.

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

Χρειαζόμουν τη δυνατότητα να αποκτώ με ασφάλεια διαχειριστικά δικαιώματα ακριβώς όταν είναι απαραίτητα.

Πρόκειται για δύο διαφορετικά ζητήματα.

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

Όχι το τέλος, αλλά η κατεύθυνση που επιλέχθηκε

Σήμερα, αυτή η αρχιτεκτονική χρησιμοποιείται ήδη σε μεγάλο μέρος του οικοσυστήματος DigiMeld.

Τα έργα που απομένουν μεταφέρονται σταδιακά στο νέο μοντέλο διαχειριστικής πρόσβασης.

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

Ορισμένα στοιχεία της διεπαφής και οι κανόνες διαχείρισης των συνεδριών ενδέχεται να αλλάξουν.

Η βασική ιδέα, όμως, έχει ήδη καθοριστεί.

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

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

Οι οργανισμοί έχουν διαφορετικές απαιτήσεις, υποδομές, μοντέλα απειλών και τρόπους διαχείρισης.

Αυτό που είναι βολικό και δικαιολογημένο για το οικοσύστημα DigiMeld δεν είναι απαραίτητα η βέλτιστη επιλογή για κάποιον άλλο προγραμματιστή.

Ωστόσο, η ίδια η αρχή της προσωρινής παραχώρησης δικαιωμάτων αξίζει την προσοχή μας.

Αντί επιλόγου

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

Ούτε επειδή θέλω να παρουσιάσω ένα ακόμη σύστημα ως απολύτως ασφαλές.

Απόλυτη ασφάλεια δεν υπάρχει.

Απλώς θεωρώ ενδιαφέρον τον τρόπο με τον οποίο τίθεται το ίδιο το ερώτημα.

Αντί να προστατεύουμε ασταμάτητα μια μόνιμη διαχειριστική είσοδο, μπορούμε να επανεξετάσουμε αν είναι απαραίτητο να υπάρχει.

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

Αντί να υπάρχει αυτόματη εμπιστοσύνη μετά την πρώτη αυθεντικοποίηση, μπορούμε να επιβεβαιώνουμε την παραχώρηση συγκεκριμένων δικαιωμάτων.

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

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

Δεν ισχυρίζομαι ότι αυτή η προσέγγιση αποκλείει την πιθανότητα παραβίασης.

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

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

Αυτή ακριβώς η σκέψη σηματοδότησε για μένα την αρχή της ιστορίας του MeldID Admin Gateway.