Στο παρόν άρθρο θα εξετάσουμε αναλυτικά τι είναι τα microservices και γιατί η ασφάλεια τους είναι βαρύνουσας σημασίας, και πως παίζει καθοριστικό ρόλο στις επιχειρησιακές ικανότητες.
Τι είναι microservices
Στον κόσμο των microservices, ο στόχος είναι να έχετε ένα λογισμικό που να εκτελεί ένα σαφώς καθορισμένο σύνολο εργασιών. Τα microservices είναι εφαρμογές λογισμικού που είναι αυτοτελείς. Είναι μικρές, ανεξάρτητα αναπτυσσόμενες αρθρωτές υπηρεσίες που εκτελούν μια μοναδική διαδικασία και επικοινωνούν μέσω ενός σαφώς καθορισμένου, ελαφρού μηχανισμού που εξυπηρετεί έναν συγκεκριμένο στόχο.
Συνήθως, καθορίζονται σαφή όρια όσον αφορά το τι μπορεί ή δεν μπορεί να κάνει το microservice σας. Η μετάβαση στο microservice απαιτεί όχι μόνο μια αλλαγή στην αρχιτεκτονική, αλλά και μια σταθερή βάση εμπιστοσύνης μεταξύ των διαφορετικών ομάδων που συνεργάζονται για την ανάπτυξη αυτών των microservices.
Η οικοδόμηση αυτής της εμπιστοσύνης τους δίνει τα εχέγγυα που χρειάζονται για να υπάρξει μία άρτια διαθεσιμότητα των υπηρεσιών και κατ’ επέκταση να τηρηθεί η συμφωνημένη σύμβαση παροχής υπηρεσιών για τα πρότυπα API.
Χωρίς υψηλό επίπεδο εμπιστοσύνης μεταξύ των ομάδων προγραμματιστών, πιθανόν να προκληθεί ένα χάος, εμποδίζοντας την ομαλότητα. και κάπως έτσι θα παραμείνει στάσιμη η ανάπτυξη του λογισμικού σας. Για παράδειγμα αν μια ομάδα δημιουργεί ότι θέλει ή αλλάξει την API χωρίς να ειδοποιήσει τον υπόλοιπο οργανισμό θα ακολουθήσει ένας πανικός . Σε αυτήν την κατάσταση αναστάτωσης, η λειτουργικότητα θα σπάσει, και η ανάπτυξη του λογισμικού σας θα σταματήσει.
Ενώ η εμπιστοσύνη είναι εξαιρετικά σημαντική για την ανάπτυξη microservices, ο σωστός προγραμματισμός για πιθανά ζητήματα ασφάλειας είναι ακόμη πιο κρίσιμος. Δυστυχώς, τα θέματα ασφάλειας παραβλέπονται συχνά κατά τη διαδικασία μετάβασης στα microservices. Οι συνέπειες των αδυναμιών ασφαλείας μπορεί να είναι καταστροφικές για την εταιρεία σας.
Για παράδειγμα, ας πούμε ότι αναπτύσσετε ένα microservice που δέχεται είσοδο από έναν χρήστη και μεταβιβάζει αυτή την είσοδο σε μια βάση δεδομένων τύπου backend. Εάν η υπηρεσία σας δεν είναι ασφαλής και η είσοδος δεν έχει επικυρωθεί, οι χάκερς θα είναι σε θέση να εισάγουν κακόβουλο κώδικα στο σύστημα και να μειώσουν δραστικά την ασφάλεια της υπηρεσία σας ή ακόμη χειρότερα, να θέσουν σε κίνδυνο ολόκληρο το σύστημά σας.
Η πληθώρα microservices ανεβάζει το επίπεδο πολυπλοκότητας
Καθώς αυξάνεται το φάσμα των υπηρεσιών και των εφαρμογών σας, ασφαλώς, είναι πιθανόν να υποθέσουμε ότι ο αριθμός των διαθέσιμων microservices θα αυξηθεί επίσης. Καθώς αυξάνεται ο αριθμός των επιλογών, όλο και περισσότερα ζητήματα ασφαλείας εμφανίζονται στο διάβα μας. Σε αυτό το άρθρο, θα εξετάσουμε ορισμένα από τα θέματα και τις πιθανές λύσεις που θα πρέπει να λάβετε υπόψη πριν η επιχείρησή σας κάνει στροφή προς τη χρήση των microservices.
Επαναχρησιμοποίηση κώδικα
Η χρήση του κοινόχρηστου κώδικα και των βιβλιοθηκών μπορεί να σας βοηθήσει να ξεκινήσετε την μετακίνησή σας στα microservices γρηγορότερα, αλλά μπορεί και να καταστεί ταυτόχρονα δίκοπο μαχαίρι με αρνητικές συνέπειες. Εάν επιλέξετε να δανειστείτε και να χρησιμοποιήσετε μια λύση ανοιχτού κώδικα και σκοπεύετε να το λειτουργείτε και εκτός του διαδικτύου, σίγουρα θα επωμιστείτε και τις ελλείψεις του.
Από τη μια πλευρά, η επαναχρησιμοποίηση της τυποποιημένης τεχνολογίας του κλάδου μπορεί να είναι καλό, αφού έχει ήδη δοκιμαστεί και χρησιμοποιηθεί σε ολόκληρο το φάσμα του και μάλιστα από πολύ κόσμο. Από την άλλη πλευρά, η ευρεία χρήση της τυποποιημένης τεχνολογίας μπορεί να είναι προβληματική. Αν για παράδειγμα υπάρξουν επιφανειακές ευπάθειες και τρωτά σημεία, η εταιρεία σας, όπως και άλλες εταιρείες που χρησιμοποιούν την τεχνολογία θα χρειαστεί να εφαρμόσουν επείγουσες επιδιορθώσεις για να μετριάσουν τα κρίσιμα ελαττώματα σε όλες τις εφαρμογές σας. Φανταστείτε πώς θα ήταν να εγκαταστήσετε και πάλι όλες τις υπηρεσίες σας εξαιτίας ενός νέου πακέτου ασφαλείας ή να διορθώσετε τους διακομιστές με μια εντελώς νέα δυαδική μορφή. Ένα τέτοιο σενάριο ακούγεται σαν εφιάλτης, έτσι δεν είναι;
Για να κατανοήσετε πλήρως το παράδειγμα θα σας αναφέρω το περιβόητο σφάλμα Heartbleed . Όταν το σφάλμα ανακαλύφθηκε τον Απρίλιο του 2014, περίπου το 66% των εξυπηρετητών ιστού του διαδικτύου χρειάστηκε να διορθωθούν, επειδή το λογισμικό που περιλάμβανε τις ευάλωτες βιβλιοθήκες χρησιμοποιήθηκε σχεδόν σε όλους τους διακομιστές ιστού του κόσμου. Αυτή η καταστροφή απαιτούσε την επαφή και την επανεκκίνηση εκατοντάδων χιλιάδων εξυπηρετητών σε πολύ σύντομο χρονικό διάστημα.
Αν τυχαίνει να έχετε μικρό αριθμό διακομιστών, οι λύσεις που αφορούν την ανάπτυξη όλων των μέσων ή την επιδιόρθωση με ένα νέο δυαδικό θα είναι εφικτές, είτε με το χέρι, είτε με ένα βασικό ποσό δέσμης ενεργειών. Αλλά εαν εξετάσετε το ζήτημα προσεκτικά, θα διαπιστώσετε πως αυτά δεν είναι πλέον βιώσιμες επιλογές για την επίλυση του προβλήματός σας. Σε αυτές τις περιπτώσεις κλιμάκωσης, πρέπει να έχετε ήδη μια δοκιμασμένη μέθοδο ενορχηστρώσεως για να εκτελέσετε γρήγορα μαζικές λειτουργίες για να ανακουφίσετε τα προβλήματα.
Άρνηση εξυπηρέτησης
Δυστυχώς δεν είναι εύκολο να διασφαλίσετε ότι όλες οι εφαρμογές σας θα είναι ασφαλείς, και μάλιστα η διαχείριση πολλών υπηρεσιών ταυτόχρονα που έχουν πολλαπλές πύλες εισόδου έχει ως αρνητικό πρόσημο να ανεβάζει το βαθμό δυσκολίας στη διαχείριση τους. Καθώς αυξάνεται ο αριθμός των υπηρεσιών, μεγεθύνεται και το μέγεθος αυτού του ζητήματος.
Η σωστή διαχείριση των ομάδων ασφαλείας θα σας βοηθήσει να διασφαλίσετε ότι θα παραμείνουν εκτεθειμένες μόνο κάποιες θύρες και μάλιστα αυτές που θα έχετε επιλέξει εσείς για λειτουργικούς λόγους. Κάτι τέτοιο μπορεί να σας βοηθήσει να εξοικονομήσετε χρόνο, κόπο και χρήμα σε περίπτωση που οι εφαρμογές σας δεχθούν επίθεση από χάκερς και αν ω μη γένοιτο εγκατασταθεί κάποιο κακόβουλο λογισμικό στο προϊόν σας.
Η εγκατάσταση ενός τείχους προστασίας ή μιας εναλλακτικής λύσης μπροστά από το σύστημά σας μπορεί να διορθώσει ένα τέτοιο πρόβλημα διασφαλίζοντας ότι μόνο η κατάλληλη κυκλοφορία φτάνει στην μπροστινή πόρτα της εφαρμογής σας και ότι δεν περιέχει κακόβουλους κώδικες ή απειλές.
Κυκλοφορία μεταξύ των microservices.
Κάθε microservice μεταδίδει πληροφορίες από το ένα στο άλλο. Όταν η κυκλοφορία είναι σε κάποιο διαχωρισμένο τμήμα του δικού σας δικτύου, θα ήταν είναι ασφαλές να υποθέσουμε ότι ο κίνδυνος ύπαρξης υποκλοπής μειώνεται, αφού συνήθως βρίσκεστε πίσω από ένα ισχυρό εταιρικό τείχος προστασίας, το οποίο σας κάνει λιγότερο επιρρεπείς σε επιθέσεις.
Όταν μετακομίζετε τις υπηρεσίες, τις εφαρμογές και τα λογισμικά σας στο σύννεφο, αυτή η υπόθεση δεν ισχύει πλέον. Η κυκλοφορία ανάμεσα στα microservices σας θα πρέπει να κρυπτογραφείται στο σύννεφο. Αυτό σημαίνει ότι εκτός από τα microservices που χειρίζονται κρυπτογραφημένη επισκεψιμότητα, θα πρέπει επίσης να διασφαλίσουν ότι η απόδοση των υποκείμενων εφαρμογών σας δεν υποφέρει εξαιτίας της πρόσθετης εργασίας που πρέπει να κάνουν με την κρυπτογράφηση των πληροφοριών.
Υπάρχουν ορισμένες μέθοδοι που μπορείτε να χρησιμοποιήσετε για να μετριάσετε αυτό το πρόβλημα. Μία τέτοια λύση είναι η δημιουργία ενός Virtual Private Cloud (VPC), το οποίο θα σας επιτρέψει να διαχωρίσετε το φόρτο εργασίας σας στο σύννεφο, χωρίς να επιτρέψετε σε έναν κακόβουλο εισβολέα να εισέλθει στο σύστημά σας και κατά συνέπεια να προκαλέσει ανυπολόγιστη ζημιά. Ωστόσο, αυτό δεν είναι μια αλάνθαστη λύση και εξακολουθεί να έχει πολλά τρωτά σημεία, τα οποία εύκολα μπορούν να τα εκμεταλλευτούν οι χάκερς. Μια άλλη επιλογή είναι η εκφόρτωση της κρυπτογράφησης σε μια εξωτερική υπηρεσία (π.χ. μια υπηρεσία εξισορρόπησης φορτίου) που θα επιτρέψει την προστασία της κυκλοφορίας με ελάχιστη διακοπή ή αλλαγές στο τρέχον σας σύστημα.
Μυστική κοινή χρήση
Για να βεβαιωθείτε ότι τα microservices σας δεν είναι ανοικτά προς όλο τον κόσμο, προτείνουμε να προσθέσετε έλεγχο ταυτότητας μεταξύ των υπηρεσιών του συστήματός σας. Με αυτόν τον τρόπο θα διασφαλιστεί ότι μόνο τα σωστά κομμάτια επιτρέπεται να μιλούν μεταξύ τους και θα πρέπει να χρησιμοποιούν τα κατάλληλα διαπιστευτήρια για να το πράξουν.
Η ενσωμάτωση αυτών των μυστικών διεργασιών στις εφαρμογές σας είναι μια πολύ κακή ιδέα. Οι βέλτιστες πρακτικές για τη σύγχρονη αρχιτεκτονική συνιστούν έντονα να μην αποθηκεύονται τα διαπιστευτήρια στους διακομιστές σας. Φυσικά, αυτό αναδεικνύει το ερώτημα πώς θα επιτρέψετε στις εφαρμογές να επαληθεύσουν την ταυτότητα μεταξύ τους και των υπηρεσιών τρίτων εάν τα διαπιστευτήρια δεν μπορούν να αποθηκευτούν τοπικά;
Υπάρχουν μερικοί τρόποι αντιμετώπισης αυτού του προβλήματος. Μια στρατηγική είναι να χρησιμοποιήσετε εργαλεία τρίτων ή εργαλεία και υπηρεσίες που είναι ήδη διαθέσιμα από τους περισσότερους παρόχους cloud. Η ιδέα είναι πολύ απλή. Όταν ξεκινάτε ένα αίτημα ελέγχου ταυτότητας, ζητάτε από μια άλλη υπηρεσία να ζητήσει ένα προσωρινό σύνολο διαπιστευτηρίων εκ μέρους σας, το οποίο σας επιτρέπει να έχετε πρόσβαση για ορισμένο χρονικό διάστημα. Αυτό επιλύει το ζήτημα της μακροζωίας των διαπιστευτηρίων διότι λήγει μετά από ένα ορισμένο χρονικό διάστημα, με τελικό αποτέλεσμα να μην υπάρχουν διαπιστευτήρια που να ενσωματώνονται στην ίδια την υπηρεσία.
Ασφάλεια σε όλους τους τομείς
Είναι πολύ απίθανο οι κατασκευαστές των microservices να ανήκουν στην ίδια ομάδα. Έχει νόημα η κάθε ομάδα να αναπτύξει και να δοκιμάσει το δική της microservice (ή το σύνολο εξ αυτών). Ως εκ τούτου, η ευθύνη για την εξασφάλιση της υπηρεσίας δεν μπορεί να ανήκει αποκλειστικά σε μια ενιαία ομάδα και οργάνωση ασφάλειας της παραδοσιακής επιχείρησης – πρέπει να βρίσκεται σε όλες τις ομάδες που παράγουν το λογισμικό.
Για να διασφαλίσετε ότι η εταιρεία σας θα προστατεύεται από εξωτερικούς επιτιθέμενους, συνιστούμε να εξετάσετε κάποιο είδος συνεργασίας μεταξύ της παραδοσιακής ομάδας OPSEC και των προγραμματιστών. Η σύναψη μιας τέτοιας εταιρικής σχέσης θα βοηθήσει τους συμμετέχοντες να συνεργαστούν ώστε το λογισμικό που παράγουν να είναι ασφαλές από προεπιλογή και να ελέγχεται συνεχώς για συμμόρφωση με μια βασική γραμμή των απαιτήσεων ασφάλειας. Όταν η ευθύνη ανήκει σε όλες τις ομάδες που δημιουργούν την υπηρεσία, το επίπεδο εμπλοκής και ευαισθητοποίησής τους θα αυξηθεί σίγουρα.
Αλλαγές κώδικα
Το τελευταίο θέμα που θα εξετάσουμε είναι ο κύκλος ζωής του microservice. Κανείς δεν γράφει λογισμικό που είναι 100% τέλειο για πρώτη φορά – πάντα θα υπάρχουν κάποια σφάλματα που θα διορθωθούν πριν το λογισμικό τρέξει τόσο αποτελεσματικά, όσο υποτίθεται ότι θα το κάνει. Για παράδειγμα, η βάση της μεθοδολογίας Agile επαναλαμβάνεται συνεχώς, παρέχοντας μόνο το ελάχιστο βιώσιμο προϊόν και βελτιώνοντας καθώς προχωράτε με το έργο.
Όταν ασχολείστε με το microservice, μπορεί να υπάρξουν πολλές αλλαγές σε καθημερινή βάση. Όταν αναβαθμίζετε την αίτησή σας αλλάζοντας ή προσθέτοντας λειτουργίες, θα πρέπει να διασφαλίσετε ότι ο κωδικός σας (τουλάχιστον) είναι ο ίδιος όπως και πριν, αν όχι ακόμα καλύτερος. Αυτό απαιτεί τη σάρωση του προστιθέμενου κώδικα για ευπάθειες και αδυναμίες πριν από την ανάπτυξη του κώδικα. Θα πρέπει να συνδέσετε αυτό στις συνεχείς διαδικασίες ενσωμάτωσης, έτσι ώστε να γίνει αυτό ως μέρος της διαδικασίας απελευθέρωσής σας.
Περίληψη
Η διατήρηση ενός ασφαλούς συστήματος είναι συνήθως ένα αποθαρρυντικό έργο και με τη στροφή προς τα microservices υπάρχει ένας επιπλέον φορέας απειλής, ο οποίος πρέπει να αντιμετωπιστεί. Κάθε τέτοιου είδους υπηρεσία έχει τα αντίστοιχα αδύνατα σημεία της, τα οποία πρέπει να ασφαλιστούν, να σκληρυνθούν και να παρακολουθούνται συνεχώς για τυχόν ευπάθειες.
Το εύρος αυτού του έργου δεν πρέπει να υποτιμάται, καθώς η χρήση της αρχιτεκτονικής των microservices αυξάνεται, τα θέματα ασφάλειας γίνονται πιο σημαντικά και επείγοντα. Για να προστατεύσετε τον εαυτό σας και την εταιρεία σας, θα πρέπει να αντιμετωπίσετε αυτά τα θέματα ασφάλειας με ιδιαίτερη προσοχή. Σας συνιστούμε να χρησιμοποιήσετε τις προτάσεις που αναφέρθηκαν σε αυτό το άρθρο για να σας βοηθήσουν στη διαδικασία εξασφάλισης των microservices σας.