Low On Caffeine, Please Forgive Coding Style
This commit is contained in:
@@ -4,14 +4,14 @@
|
||||
|
||||
\noindent Παραδοσιακά, όταν ένας χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
|
||||
υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
|
||||
αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας αποδοχής,
|
||||
καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
|
||||
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεων δεδομένων
|
||||
(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
|
||||
κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
|
||||
κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
|
||||
λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα σημαντικό
|
||||
κόστος.
|
||||
αγορά σχετικού εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας
|
||||
αποδοχής, καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου
|
||||
εξοπλισμού αλλά και της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού
|
||||
(βάσεων δεδομένων (Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων,
|
||||
κ.λπ.) στα νέα κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία
|
||||
απαιτούσε επιπλέον κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη.
|
||||
Επιπρόσθετα, η λειτουργία του εξοπλισμού και η συντήρησή του είχε κι αυτή ένα
|
||||
σημαντικό κόστος.
|
||||
|
||||
Στις αρχές του 2000 ο τρόπος διεξαγωγής της παραπάνω διαδικασίας άλλαξε ριζικά
|
||||
όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
|
||||
@@ -36,22 +36,23 @@ AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρ
|
||||
προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα μερικές από αυτές, όπως η
|
||||
Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια υπηρεσία τους τη
|
||||
δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με τη μορφή ενοικίασης
|
||||
εικονικών μηχανών (Virtual Machines).
|
||||
εικονικών μηχανών (Virtual Machines - VMs).
|
||||
|
||||
\section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}
|
||||
|
||||
Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
|
||||
χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
|
||||
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξή της
|
||||
εξαρτάται από τρεις βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
|
||||
νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
|
||||
νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
|
||||
που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
|
||||
τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους απομακρυσμένους
|
||||
(εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον προβεί στην χρήση
|
||||
δοχείων. Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες
|
||||
οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
|
||||
ασφάλεια της υπηρεσίας του (που θα φιλοξενείται από μια υποδομή νέφους) σύμφωνα
|
||||
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη
|
||||
κατάλληλου επιπέδου ασφάλειας εξαρτάται από τρεις βασικούς παράγοντες. Ο πρώτος
|
||||
είναι η ασφάλεια των υποδομών νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS
|
||||
υπεύθυνος είναι ο πάροχος νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των
|
||||
τεχνολογιών εικονικοποίησης που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει
|
||||
ο πάροχος για τις τεχνολογίες που επέλεξε προκειμένου να διαθέσει τους
|
||||
απομακρυσμένους (εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον
|
||||
προβεί στην χρήση τεχνολογιών δοχείων (containers) (δηλ. ένα είδος τεχνολογίας
|
||||
εικονικοποίησης). Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις
|
||||
οποίες οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
|
||||
ασφάλεια της υπηρεσίας του (που θα φιλοξενείται σε μια υποδομή νέφους) σύμφωνα
|
||||
με τις ανάγκες του.
|
||||
|
||||
Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
|
||||
@@ -60,7 +61,7 @@ Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια
|
||||
προσφέρονται, τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
|
||||
συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
|
||||
των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
|
||||
MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \footfullcite{nginx}.
|
||||
MySQL \footfullcite{mysql} και ο διακομιστής ιστού nginx \footfullcite{nginx}.
|
||||
Με αυτό τον τρόπο, η διαδικασία δημιουργίας εικονικής μηχανής είναι αρκετά
|
||||
εύκολη για τον χρήστη, ο οποίος δεν χρειάζεται να έχει ειδικές γνώσεις στο
|
||||
υλικό για να το πετύχει αυτό. Στην προκειμένη περίπτωση, ενώ υπάρχει μηδενική
|
||||
@@ -76,7 +77,7 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
|
||||
|
||||
Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
|
||||
που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
|
||||
ρυθμισμένα εκ τω προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
|
||||
ρυθμισμένα εκ των προτέρων προγράμματα από τρίτους. Σε ορισμένες περιπτώσεις
|
||||
όπου υπάρχει τυφλή εμπιστοσύνη προς την ορθότητα των ρυθμίσεων αυτών σε
|
||||
συνδυασμό με έλλειψη γνώσης των εργαλείων, ενδέχεται λόγω ανθρώπινου λάθους ή
|
||||
στοχευμένα, να μένει ο τελικός χρήστης ευάλωτος σε ρίσκα ασφαλείας, όπως μη
|
||||
@@ -85,9 +86,10 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
|
||||
παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
|
||||
εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
|
||||
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking \cite{Hyperjacking} και
|
||||
να αποκτήσει έλεγχο του υπερ-επόπτη με αποτέλεσμα να είναι σε θέση να
|
||||
προκαλέσει ζημιές είτε σε διαφορετικές εικονικές μηχανές είτε στον (φυσικό)
|
||||
διακομιστή στον οποίο εκτελείται.
|
||||
να αποκτήσει έλεγχο του υπερ-επόπτη (hypervisor) με αποτέλεσμα να είναι σε θέση
|
||||
να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές μηχανές που ελέγχονται από
|
||||
τον υπερ-επόπτη είτε στον (φυσικό) διακομιστή (host machine ή απλώς host) στον
|
||||
οποίο αυτός εκτελείται.
|
||||
|
||||
\section{Εικονικοποίηση και τεχνολογίες υλοποίησής της} \label{virtualizationTechnologiesIntroduction}
|
||||
|
||||
@@ -99,36 +101,31 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
|
||||
\ref{virtualizationImplementations} αλλά οι δύο βασικότερες υλοποιήσεις της
|
||||
είναι η εικονικοποίηση διακομιστών και λειτουργικών συστημάτων (δοχειοποίηση).
|
||||
|
||||
Στην εικονικοποίηση διακομιστών, ένας φυσικός διακομιστής χωρίζει με την
|
||||
βοήθεια ενός υπερ-επόπτη τους πόρους του, όπως η μνήμη, ο αποθηκευτικός χώρος
|
||||
και ο επεξεργαστής του, σε πολλά μικρότερα εικονικά μηχανήματα. Κάθε εικονικό
|
||||
μηχάνημα μπορεί να εκτελεί διαφορετικό λειτουργικό σύστημα και να έχει
|
||||
διαφορετικές ρυθμίσεις από τα υπόλοιπα. Η διάθεση ενός εικονικού μηχανήματος
|
||||
δεν περιορίζεται μονάχα σε τοπικούς υπολογιστές και έτσι πολλές φορές
|
||||
συνηθίζεται η ενοικίαση τέτοιων μηχανημάτων προκειμένου να μπορέσουν να
|
||||
χρησιμοποιηθούν από τρίτα πρόσωπα για την επίτευξη των δικών τους διεργασιών.
|
||||
Στην εικονικοποίηση διακομιστών (host virtualization), ένας φυσικός διακομιστής
|
||||
χωρίζει με την βοήθεια ενός υπερ-επόπτη τους πόρους του, όπως είναι η μνήμη, ο
|
||||
αποθηκευτικός χώρος και ο επεξεργαστής του, σε πολλές μικρότερες εικονικές
|
||||
μηχανές. Κάθε εικονική μηχανή μπορεί να εκτελεί διαφορετικό λειτουργικό σύστημα
|
||||
και να έχει διαφορετικές ρυθμίσεις από τις υπόλοιπες. Η διάθεση μιας εικονικής
|
||||
μηχανής δεν περιορίζεται μονάχα σε τοπικούς υπολογιστές και έτσι πολλές φορές
|
||||
συνηθίζεται η ενοικίαση τέτοιων μηχανών (σε περιβάλλοντα νέφους) προκειμένου να
|
||||
μπορέσουν να χρησιμοποιηθούν από τρίτα πρόσωπα για την επίτευξη των δικών τους
|
||||
διαδικασιών.
|
||||
|
||||
Η δοχειοποίηση αποτελεί μια ειδική περίπτωση εικονικοποίησης όπου αντί για το
|
||||
υλικό, εικονικοποιείται το λειτουργικό σύστημα. Αυτό, καθιστά την δοχειοποίηση
|
||||
πιο αποδοτική από την εικονικοποίηση διακομιστών, καθώς δεν χρειάζεται να
|
||||
εκτελεστεί ένας υπερ-επόπτης για την διαχείριση υπολογιστικών πόρων. Επιπλέον,
|
||||
η δοχειοποίηση επιτρέπει την εκτέλεση περισσότερων εικονικών περιβαλλόντων στον
|
||||
ίδιο φυσικό διακομιστή και έτσι, η απόδοση του υλικού αυξάνεται ακόμα
|
||||
περισσότερο. Συνήθως χρησιμοποιείται για την διάθεση προγραμμάτων στο ευρύ
|
||||
κοινό, τα οποία ακολουθούν την αρχιτεκτονική μικρο-υπηρεσιών (microservices)
|
||||
και λόγω του ότι τα παράγωγά της περιέχουν όλες τις απαραίτητες βιβλιοθήκες για
|
||||
την εκτέλεσή τους, χωρίς να βασίζονται στο υποκείμενο νέφος στο οποίο
|
||||
στεγάζονται, αποτελούν αρκετά δημοφιλή επιλογή τεχνολογίας διάθεσης υπηρεσιών.
|
||||
|
||||
Τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το αποτέλεσμα της
|
||||
εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την βοήθεια του
|
||||
λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα οποία μπορούν
|
||||
αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από το λειτουργικό
|
||||
σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την εκτέλεση των
|
||||
διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι βιβλιοθήκες
|
||||
που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container image) την οποία
|
||||
η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και με βάση αυτήν να
|
||||
δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει.
|
||||
Κατά την δοχειοποίηση (containerization), μιας ειδικής περίπτωσης
|
||||
εικονικοποίησης, αντί για το υλικό, εικονικοποιείται το λειτουργικό σύστημα.
|
||||
Επομένως, τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το
|
||||
αποτέλεσμα της εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την
|
||||
βοήθεια του λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα
|
||||
οποία μπορούν αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από
|
||||
το λειτουργικό σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την
|
||||
εκτέλεση των διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι
|
||||
βιβλιοθήκες που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container
|
||||
image), την οποία η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και
|
||||
με βάση αυτήν να δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει. Η
|
||||
πιο συνηθισμένη υλοποίηση της δοχειοποίησης είναι η δοχειοποίηση εφαρμογών μέσω
|
||||
της μηχανής δοχείων Docker. Αυτό συμβαίνει διότι μέσω της πλατφόρμας που αυτό
|
||||
παρέχει, η διαχείριση και χρήση δοχείων επιτυγχάνεται εύκολα από ομάδες
|
||||
ανάπτυξης λογισμικού κάθε επιπέδου.
|
||||
|
||||
Η δοχειοποίηση αποτελεί μια ελαφρύτερη εναλλακτική λύση σε σύγκριση με την
|
||||
εικονικοποίηση και είθισται να προτιμάται για την ανάπτυξη και διάθεση
|
||||
@@ -136,251 +133,19 @@ MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \fo
|
||||
δοχείων μπορεί να πραγματοποιηθεί σε κάθε περιβάλλον και νέφος, καθώς και στο
|
||||
γεγονός ότι αυτά απαιτούν λιγότερους πόρους σε σχέση με τις εικονικές μηχανές,
|
||||
αφού οι υποκείμενοι πόροι του συστήματος μπορούν να μοιραστούν μεταξύ των
|
||||
διαφορετικών δοχείων.
|
||||
διαφορετικών δοχείων. Αυτό, καθιστά την δοχειοποίηση πιο αποδοτική από την
|
||||
εικονικοποίηση διακομιστών, καθώς δεν χρειάζεται να εκτελεστεί ένας
|
||||
υπερ-επόπτης για την διαχείριση υπολογιστικών πόρων. Επιπλέον, η δοχειοποίηση
|
||||
επιτρέπει την εκτέλεση περισσότερων εικονικών περιβαλλόντων στον ίδιο φυσικό
|
||||
διακομιστή και έτσι, η απόδοση του υλικού αυξάνεται ακόμα περισσότερο. Συνήθως
|
||||
χρησιμοποιείται για την διάθεση εφαρμογών στο ευρύ κοινό, οι οποίες ακολουθούν
|
||||
την αρχιτεκτονική μικρο-υπηρεσιών (microservices). Δηλαδή, της διαμέρισης των
|
||||
λειτουργιών τους σε δοχεία. Λόγω του ότι τα παράγωγα της δοχειοποίησης
|
||||
περιέχουν όλες τις απαραίτητες βιβλιοθήκες για την εκτέλεσή τους, χωρίς να
|
||||
βασίζονται στο υποκείμενο νέφος στο οποίο στεγάζονται, η δοχειοποίηση αποτελεί
|
||||
αρκετά δημοφιλή επιλογή τεχνολογίας διάθεσης υπηρεσιών.
|
||||
|
||||
\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
|
||||
|
||||
Ενώ μια εικονική μηχανή είναι μια πλήρης αναπαράσταση ενός φυσικού διακομιστή,
|
||||
ένα δοχείο εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Αυτό
|
||||
σημαίνει πως εάν θεωρηθεί ως τελικός στόχος η εκτέλεση ενός λογισμικού
|
||||
απομονωμένο από το υπόλοιπο σύστημα, αυτό επιτυγχάνεται με δύο διαφορετικούς
|
||||
τρόπους, αφού οι εικονικές μηχανές και τα δοχεία χρησιμοποιούν διαφορετικού
|
||||
είδους εικονικοποίηση. Στην περίπτωση των δοχείων δεν έχουμε απομόνωση μηχανών
|
||||
αλλά διεργασιών. Γεγονός που συμβάλλει στην αποφυγή της επιβάρυνσης του
|
||||
συστήματος που θα επιβάλλονταν από τις διεργασίες του υπερ-επόπτη και της
|
||||
καθυστέρησης που θα υπήρχε για την εκκίνηση ενός ολόκληρου λειτουργικού
|
||||
συστήματος. Επιπλέον, η μη χρήση τεχνολογιών εικονικοποίησης σε επίπεδο υλικού
|
||||
αυξάνει την μεταφερσιμότητα των δοχείων αφού σε μια εικόνα δοχείου μπορούν να
|
||||
ορισθούν όλες οι απαραίτητες εξαρτήσεις ενός λογισμικού και να αναδημιουργηθούν
|
||||
σε οποιοδήποτε περιβάλλον νέφους.
|
||||
|
||||
Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
|
||||
αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
|
||||
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
|
||||
σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
|
||||
εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή έχει ένα δικό της
|
||||
λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί για να
|
||||
εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
|
||||
την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
|
||||
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
|
||||
βιβλιοθήκες και τις εξαρτήσεις της \cite{ibmContainerVsVm}.
|
||||
|
||||
\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
|
||||
στην αρχιτεκτονική της εικονικοποίησης και των δοχείων.
|
||||
|
||||
\begin{center}
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width = \textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||||
\captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
|
||||
\label{fig:containerVsVm}
|
||||
\end{figure}
|
||||
\vspace*{-30pt}
|
||||
\end{center}
|
||||
|
||||
Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
|
||||
γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
|
||||
σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
|
||||
μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
|
||||
megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
|
||||
\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
|
||||
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
|
||||
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
|
||||
της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
|
||||
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
|
||||
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
|
||||
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
|
||||
περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
|
||||
Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
|
||||
πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
|
||||
μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
|
||||
αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
|
||||
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
|
||||
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
|
||||
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
|
||||
(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
|
||||
Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
|
||||
έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
|
||||
όπως το Docker Compose.
|
||||
|
||||
Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
|
||||
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
|
||||
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
|
||||
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
|
||||
το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.
|
||||
|
||||
Εν γένει, τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
|
||||
μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
|
||||
και η μεταφερσιμότητά τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
|
||||
αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
|
||||
σκοπό την στέγαση ενός ολόκληρου ξεχωριστού λειτουργικού συστήματος (όπως
|
||||
γίνεται στις εικονικές μηχανές). Επιπλέον, τα δοχεία μπορούν να εκτελεστούν σε
|
||||
οποιοδήποτε περιβάλλον είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως το
|
||||
Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
|
||||
σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
|
||||
μη λειτουργικών απαιτήσεών τους.
|
||||
|
||||
\subsection{Εργαλεία διαχείρισης δοχείων και έλευση του Docker} \label{containerManagement}
|
||||
|
||||
Στις μέρες μας, η δημοτικότητα του Docker έχει συνταυτίσει τους όρους Docker
|
||||
και Container (δοχείο) αν και είναι διαφορετικοί. Παρ' όλα αυτά, η ιδέα της
|
||||
δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
|
||||
το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
|
||||
είσοδό τους από το 1979, όταν εισήχθη το chroot \cite{chrootCommand} στην
|
||||
έβδομη έκδοση του Unix \cite{containerHistory}. Πρόκειται για μια εντολή που
|
||||
περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα συγκεκριμένο
|
||||
φάκελο, ο οποίος ορίζεται ως ο καινούριος αρχικός (root). Ο κύριος σκοπός του
|
||||
chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην περίπτωση εκμετάλλευσης
|
||||
μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν ανεπηρέαστα τα μέρη του
|
||||
συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση. Εκείνη την εποχή αυτό
|
||||
ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό αυξάνονταν και υπήρχε η
|
||||
ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από κατασκευής του, το chroot
|
||||
δεν περιόριζε έναν χρήστη ή μια διεργασία με διαχειριστικά δικαιώματα
|
||||
\cite{chrootRestrictions}. Μερικά χρόνια αργότερα, το 2004 δημιουργήθηκαν και
|
||||
ενσωματώθηκαν στον πυρήνα του Linux οι ομάδες ελέγχου, με την βοήθεια των
|
||||
οποίων ήταν πλέον δυνατή η απομόνωση πόρων του συστήματος σε ένα υποσύνολο
|
||||
διεργασιών.
|
||||
|
||||
Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
|
||||
2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
|
||||
Το πρώτο εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και
|
||||
εκτέλεση πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα.
|
||||
Χρησιμοποιώντας μηχανισμούς που προσέφερε το λειτουργικό σύστημα, επέτρεπε
|
||||
πλήρη εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε
|
||||
αρκετές λειτουργίες όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων.
|
||||
Παρ' όλα αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
|
||||
εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
|
||||
όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||||
|
||||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
|
||||
ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
|
||||
του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
|
||||
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
|
||||
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
|
||||
(Platform-as-a-Service) (Πλατφόρμα ως Υπηρεσία) και παρέχει μια πλατφόρμα με
|
||||
μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση, ενημέρωση και
|
||||
διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC, αποτελεί μια
|
||||
μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την δοχειοποίηση εφαρμογών. Εκτός
|
||||
από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα, τις βιβλιοθήκες και εξαρτήσεις
|
||||
ενός λογισμικού από το κύριο σύστημα (φιλοξενίας), παρέχει και δυνατότητες
|
||||
επικοινωνίας με αποθετήρια εικόνων δοχείωv, όπως είναι το Docker Hub
|
||||
\footfullcite{dockerhub}, το επίσημο αποθετήριο του Docker, το Quay
|
||||
\footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή οποιοδήποτε άλλο
|
||||
αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI (Open Container
|
||||
Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι χρήστες έχουν
|
||||
πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να
|
||||
ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια
|
||||
μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα απαιτούσαν
|
||||
εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε
|
||||
απλές εντολές, καθιστώντας έτσι εύκολη την χρήση του για προγραμματιστές κάθε
|
||||
επιπέδου και απλοποιώντας κατά πολύ την διαδικασία ανάπτυξης και παράδοσης
|
||||
κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή,
|
||||
έλεγχο εκδόσεων (version control) για δοχεία \cite{LXCvsDocker2} και ένα
|
||||
οικοσύστημα γύρω από όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει
|
||||
το LXC.
|
||||
|
||||
\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
|
||||
|
||||
Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
|
||||
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο καταρράκτη
|
||||
(waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
|
||||
αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
|
||||
έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
|
||||
αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
|
||||
στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
|
||||
\cite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
|
||||
πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
|
||||
προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
|
||||
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \cite{devops} όπου οι
|
||||
ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής επικοινωνούν
|
||||
στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης λογισμικού.
|
||||
Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD (Continuous
|
||||
Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής Παράδοση)
|
||||
\cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες
|
||||
που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής
|
||||
προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
|
||||
εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα τα οποία μετά μπορούν
|
||||
απευθείας να διατίθενται στο κοινό (continuous deployment).
|
||||
|
||||
Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
|
||||
και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
|
||||
εφαρμογών και την εκτέλεσή τους σε οποιοδήποτε περιβάλλον. Λόγω των
|
||||
χαρακτηριστικών τους, εξαλείφουν τυχόν προβλήματα ασυμβατότητας μεταξύ των
|
||||
περιβαλλόντων εκτέλεσής τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων αφού
|
||||
μπορεί κανείς να εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για
|
||||
συγκεκριμένη ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
|
||||
χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους. Γεγονός που
|
||||
μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα.
|
||||
Επιπλέον, λόγω της ταχείας διάθεσης και εκτέλεσής τους, συμβαδίζουν πλήρως με
|
||||
τον ρυθμό ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
|
||||
Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
|
||||
προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
|
||||
αρχιτεκτονική μικρο-υπηρεσιών. Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ
|
||||
τους, καθιστά πιο σταθερή την εφαρμογή αφού σε περίπτωση που κάποιο από αυτά
|
||||
αποτύχει, η υπόλοιπη εφαρμογή θα συνεχίσει να λειτουργεί κανονικά και η
|
||||
ανακατασκευή του δοχείου που απέτυχε μπορεί να επιτευχθεί εύκολα και γρήγορα με
|
||||
μια απλή τροποποίηση της εκάστοτε εικόνας δοχείου.
|
||||
|
||||
\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
|
||||
|
||||
Οι δυνατότητες που προσφέρει το Docker το καθιστούν την καταλληλότερη επιλογή
|
||||
τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
|
||||
υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
|
||||
συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
|
||||
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι: η
|
||||
εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
|
||||
πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
|
||||
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS \cite{caas} (Container as a
|
||||
Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπηρεσία όπου
|
||||
ένας πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
|
||||
σκοπού, παρέχει μια ευέλικτη υποδομή, έτοιμη για την εκτέλεση δοχείων
|
||||
\cite{caasVsIaas}.
|
||||
|
||||
Από τις δύο αυτές επιλογές, η πρώτη προσφέρει μια ευελιξία ως προς την
|
||||
διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι χρήστες έχουν την
|
||||
δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές ασφαλείας που μπορεί να
|
||||
έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν επιπλέον λογισμικό
|
||||
παρακολούθησης και ελέγχου ποιότητας των δοχείων και να προσαρμόσουν το
|
||||
περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η ύπαρξη μιας
|
||||
επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου συστήματος
|
||||
αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο βρεθεί σε
|
||||
κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την περιορισμένη
|
||||
έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη την
|
||||
ανίχνευση και απομόνωση των προβλημάτων ασφαλείας, καθώς επίσης και την
|
||||
αποκατάστασή τους.
|
||||
|
||||
Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
|
||||
επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
|
||||
διαχείριση της υποδομής στον πάροχο νέφους. Αυτό είναι ιδιαίτερα χρήσιμο σε
|
||||
περιπτώσεις που οι χρήστες δεν έχουν την απαραίτητη εμπειρία σε αυτόν τον τομέα
|
||||
ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
|
||||
υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
|
||||
υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
|
||||
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων, όπως η ταχεία διάθεση
|
||||
και απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση.
|
||||
Συγκεκριμένα, μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες
|
||||
ενορχήστρωσης δοχείων \cite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου
|
||||
στησίματος πλατφορμών όπως το Kubernetes \cite{kubernetes} και το Docker Swarm
|
||||
\cite{dockerSwarm}, που παρέχουν αυτή την δυνατότητα.
|
||||
|
||||
Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
|
||||
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
|
||||
επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
|
||||
σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
|
||||
διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
|
||||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
|
||||
ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και η δυσκολία διαχείρισής
|
||||
τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
|
||||
έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||||
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
|
||||
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
|
||||
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
|
||||
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
|
||||
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
|
||||
εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς παρόχους
|
||||
με βάση τις ανάγκες τους.
|
||||
|
||||
\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
|
||||
\section{Ασφάλεια συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
|
||||
|
||||
Μία από τις πιο σημαντικές προκλήσεις των επιχειρήσεων κατά την διάθεση
|
||||
υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά, κατά την
|
||||
@@ -393,8 +158,8 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
αρχικές ρυθμίσεις.
|
||||
|
||||
Για τον λόγο αυτό, εάν η μέγιστη δυνατή απόδοση δεν είναι μια από τις κύριες
|
||||
προτεραιότητες της επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
|
||||
συστήματος διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
|
||||
προτεραιότητες μιας επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
|
||||
συστήματός της, διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
|
||||
μεταφερσιμότητα και την απαλλαγή από τις εξαρτήσεις του εκάστοτε προγράμματος
|
||||
ακόμα και χωρίς την περαιτέρω διαμόρφωση των ρυθμίσεών του, η προτεινόμενη
|
||||
χρήση είναι η εκτέλεσή του μέσω μιας εικονικής μηχανής. Σε περιπτώσεις
|
||||
@@ -402,10 +167,13 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
ανάμεσα στα προγράμματα και το μηχάνημα στο οποίο εκτελούνται αποτελεί ένα
|
||||
παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας επιτιθέμενος για να προκαλέσει
|
||||
ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα να περάσει από τον εικονικό
|
||||
πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, ο συνδυασμός με την
|
||||
αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο απομόνωσης εφόσον στην
|
||||
προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα του συστήματος αφορά το
|
||||
φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
|
||||
πυρήνα (πυρήνα ΛΣ της εικονικής μηχανής) και έπειτα από τον υπερ-επόπτη.
|
||||
Παράλληλα, ο συνδυασμός με την αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο
|
||||
επίπεδο απομόνωσης εφόσον στην προκειμένη περίπτωση η άμεση επικοινωνία με τον
|
||||
πυρήνα του συστήματος αφορά το φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
|
||||
Συνεπώς, ένας επιτιθέμενος πρέπει να πραγματοποιήσει δύο αποδράσεις. Μια από
|
||||
την μηχανή ενορχήστρωσης δοχείων ή περιβάλλον δοχειοποίησης και έπειτα μια
|
||||
επιπλέον από το εικονικοποιημένο περιβάλλον.
|
||||
|
||||
Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
|
||||
να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
|
||||
@@ -419,11 +187,13 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
|
||||
χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
|
||||
ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
|
||||
αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
|
||||
τότε είναι υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας
|
||||
επίθεσης συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες
|
||||
ασφάλισης του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την
|
||||
οπτική γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
|
||||
αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS
|
||||
(Container-as-a-Service) κατά τις οποίες ο πάροχος νέφους προσφέρει υποδομές
|
||||
προσαρμοσμένες συγκεκριμένα για την εκτέλεση δοχείων, τότε αυτός είναι
|
||||
υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας επίθεσης
|
||||
συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες ασφάλισης
|
||||
του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την οπτική
|
||||
γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
|
||||
εικονικοποίησης ΛΣ μέσω ενός παρόχου νέφους για την παροχή των υπηρεσιών του
|
||||
\cite{containerSecurityExplained}.
|
||||
|
||||
@@ -438,20 +208,20 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.
|
||||
|
||||
Ένα εξίσου σημαντικό όφελος αποτελεί το επιπρόσθετο επίπεδο ασφάλειας που
|
||||
παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρύνει το ΛΣ
|
||||
παρέχεται. Σε περιβάλλον εικονικής μηχανής θα πρέπει να σκληρυνθεί το ΛΣ
|
||||
φιλοξενίας (αν υπάρχει), ο υπερ-επόπτης, το φιλοξενούμενο ΛΣ και η εκτελούμενη
|
||||
υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρύνει το ΛΣ που φιλοξενεί τη
|
||||
υπηρεσία. Σε περιβάλλον δοχείου, πρέπει να σκληρυνθεί το ΛΣ που φιλοξενεί τη
|
||||
μηχανή δοχείων, η μηχανή δοχείων και η υπηρεσία. Πράγμα που σημαίνει πως σε ένα
|
||||
εικονικό περιβάλλον, με την χρήση του Docker έχουμε επιπρόσθετα επίπεδα που
|
||||
χρειάζονται σκλήρυνση. Συνεπώς, σε εικονικά περιβάλλοντα, η χρήση δοχείων
|
||||
έρχεται με την σκλήρυνση ενός επιπλέον συστατικού, της μηχανής δοχείων, οπότε
|
||||
προσφέρει καλύτερο επίπεδο ασφάλειας.
|
||||
αυτή προσφέρει καλύτερο επίπεδο ασφάλειας.
|
||||
|
||||
Δύο ακόμα σημαντικά πλεονεκτήματα είναι η ευκολία εφαρμογής ενημερώσεων
|
||||
ασφαλείας στα δοχεία και η σταθερότητα του περιβάλλοντος που προσφέρεται μέσω
|
||||
αυτών στις εφαρμογές. Ειδικότερα, η ενημέρωση ενός δοχείου είναι μια διαδικασία
|
||||
δύο μόνο εντολών, ενώ το προσφερόμενο περιβάλλον είναι σταθερό με την λογική
|
||||
πως η μηχανή δοχείων παρέχει ένα επίπεδο πάνω από το ΛΣ, κι επομένως το
|
||||
πως η μηχανή δοχείων παρέχει ένα επίπεδο πάνω από το ΛΣ, και επομένως το
|
||||
περιβάλλον αυτό δεν είναι ξεχωριστά ευμετάβλητο από την εκάστοτε εφαρμογή που
|
||||
εκτελείται μέσα σε αυτό. Άρα, δεν κινδυνεύει από νέα προβλήματα ασφαλείας που
|
||||
θα μπορούσαν να επιφέρουν τυχόν ενημερώσεις των εξαρτήσεων της εφαρμογής χωρίς
|
||||
@@ -481,7 +251,7 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
που εκτελούνται στο σύστημα.
|
||||
|
||||
Σχετικά με τις επιθέσεις που αποσκοπούν στην απόκτηση πρόσβασης στο κύριο
|
||||
σύστημα μέσω του δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
|
||||
σύστημα μέσω ενός δοχείου, ο κίνδυνος οφείλεται στον τρόπο λειτουργίας των
|
||||
δοχείων σε συνδυασμό με τις αρχικές ρυθμίσεις ασφαλείας του Docker. Λόγω της
|
||||
απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
|
||||
ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
|
||||
@@ -490,7 +260,7 @@ Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπ
|
||||
διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape θα
|
||||
έχει διαχειριστικά δικαιώματα και ο ίδιος \cite{containerEscapeRepercussions}.
|
||||
|
||||
\subsection{Ξεπερνώντας τα μειονεκτήματα ασφαλείας του Docker} \label{overcomingDockerDisadvantages}
|
||||
\section{Συνεισφορά Διπλωματικής} \label{overcomingDockerDisadvantages}
|
||||
|
||||
Οι πιο συνήθεις τρόποι αντιμετώπισης της ανεπαρκούς προκαθορισμένης ασφάλειας
|
||||
του Docker (δηλ. της ελαστικής απομόνωσης) είναι η ρύθμιση καλύτερων προφίλ
|
||||
@@ -505,17 +275,18 @@ Docker, όπως η σκλήρυνσή του, η αποφυγή χρήσης τ
|
||||
καθώς και να εγκαθιστά σε αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας
|
||||
του Docker και των δοχείων του, μια σκληρυμένη έκδοση του Docker.
|
||||
|
||||
Με τη χρήση του εργαλείου SecDep που αναπτύχθηκε στα πλαίσια της παρούσας
|
||||
διπλωματικής εργασίας, το οποίο θα περιγράψουμε παρακάτω στο Κεφάλαιο
|
||||
\ref{installationANDShowcase}, θα επιτευχθεί η ασφάλιση του Docker και του
|
||||
συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές,
|
||||
χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας
|
||||
το Docker εξ ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο
|
||||
αυτό εστιάζει στην χρήση εικονικοποιημένων περιβαλλόντων, μιας και παρέχουν
|
||||
Η ανάγκη αυτή ικανοποιήθηκε με την ανάπτυξη του εργαλείου SecDep (Secure
|
||||
Deployment) που αναπτύχθηκε στα πλαίσια της παρούσας διπλωματικής εργασίας, το
|
||||
οποίο θα περιγράψουμε παρακάτω στο Κεφάλαιο \ref{installationANDShowcase}. Με
|
||||
την χρήση του, θα επιτευχθεί η ασφάλιση του Docker και του συστήματος με
|
||||
αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές, χρησιμοποιώντας ένα
|
||||
ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας το Docker εξ
|
||||
ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο αυτό
|
||||
εστιάζει στην χρήση εικονικοποιημένων περιβαλλόντων, μιας και παρέχουν
|
||||
περισσότερα επίπεδα προς διείσδυση για έναν επιτιθέμενο, εμποδίζοντάς τον στην
|
||||
επίτευξη του στόχου αυτού. Επικοινωνεί με πολλούς παρόχους νέφους στέλνοντάς
|
||||
τους παραμέτρους για τις προδιαγραφές εικονικών μηχανών προκειμένου να
|
||||
μπορέσουν να δημιουργηθούν αυτόματα. Με αυτόν τον τρόπο, επιτρέπει την
|
||||
μπορέσουν αυτές να δημιουργηθούν αυτόματα. Με αυτόν τον τρόπο, επιτρέπει την
|
||||
δημιουργία πολλαπλών ασφαλών περιβαλλόντων ώστε να μπορεί ένας χρήστης να
|
||||
εγκαθιστά εκεί τα δοχεία της εφαρμογής του. Με την εφαρμογή των κατάλληλων
|
||||
μέτρων και πρακτικών ασφαλείας σε κάθε επίπεδο, τα περιβάλλοντα αυτά
|
||||
@@ -523,7 +294,7 @@ Docker, όπως η σκλήρυνσή του, η αποφυγή χρήσης τ
|
||||
επιτυγχάνεται με την εκτέλεση πολλών βημάτων στα οποία μεταξύ άλλων
|
||||
περιλαμβάνεται η σκλήρυνση του SSH, ο εντοπισμός, η εγκατάσταση, η ρύθμιση και
|
||||
η ενεργοποίηση των κατάλληλων για την εκάστοτε διανομή, προγραμμάτων για
|
||||
ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access Control) και η
|
||||
ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access Control) καθώς και η
|
||||
δημιουργία και ενεργοποίηση περιοδικά εκτελέσιμων προγραμμάτων για την
|
||||
ενημέρωση του συστήματος και το άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η
|
||||
απεξάρτηση από τον διαχειριστικό λογαριασμό επιτυγχάνεται χάρη στη δουλειά του
|
||||
@@ -540,21 +311,20 @@ Akihiro Suda πάνω στο rootlesskit \footfullcite{AkihiroSuda}, επιτρ
|
||||
πλούσια τεκμηρίωση και οδηγίες εγκατάστασης στο αποθετήριό του, ενώ οι γνώσεις
|
||||
που απαιτούνται στον τομέα των τεχνολογιών νέφους για την χρήση του είναι
|
||||
ελάχιστες. Επιπλέον, είναι ευέλικτο και επεκτάσιμο διότι αποτελείται από δύο
|
||||
εκτελέσιμα προγράμματα τα οποία μπορεί κάθε χρήστης να τροποποιήσει ώστε να
|
||||
εκτελέσιμα προγράμματα, τα οποία μπορεί κάθε χρήστης να τροποποιήσει ώστε να
|
||||
προσθέσει τις δικές του λειτουργίες αν το επιθυμεί. Τέλος, οι παράμετροι του
|
||||
είναι εύκολα κατανοητές και προσαρμόσιμες στις ανάγκες του χρήστη. Επομένως, το
|
||||
εργαλείο αυτό αποτελεί ένα κατάλληλο μέσο για την δημιουργία, διαχείριση και
|
||||
ασφάλιση περιβαλλόντων εφαρμογών που εκτελούνται σε δοχεία.
|
||||
|
||||
\clearpage
|
||||
ασφάλιση περιβαλλόντων δοχειοποιημένων εφαρμογών (containerized applications),
|
||||
δηλ. εφαρμογών που παίρνουν την μορφή δοχείων.
|
||||
|
||||
\section{Δομή Εργασίας} \label{structure}
|
||||
|
||||
Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο Κεφάλαιο \ref{background}, θα
|
||||
αναλύσουμε τις έννοιες της νεφο-υπολογιστικής και εικονικοποίησης, τις διάφορες
|
||||
τεχνολογίες εικονικοποίησης και θα εμβαθύνουμε στην τεχνολογία των δοχείων με
|
||||
επίκεντρο την ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το
|
||||
\ref{relevantWork}), θα δούμε εργασίες σχετικές με την παρούσα και θα
|
||||
επίκεντρο την ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το Κεφάλαιο
|
||||
\ref{relevantWork}), θα παρουσιάσουμε εργασίες σχετικές με την παρούσα και θα
|
||||
πραγματοποιηθεί ανάλυση και σύγκριση αυτών με την προτεινόμενη εργασία της
|
||||
διπλωματικής. Αμέσως μετά, στο Κεφάλαιο \ref{projectDevelopment}, αναφερόμαστε
|
||||
στην διαδικασία ανάπτυξης του προτεινόμενου εργαλείου και τα παράγωγά της
|
||||
|
||||
Reference in New Issue
Block a user