1318 lines
106 KiB
TeX
1318 lines
106 KiB
TeX
\chapter{Υπόβαθρο} \label{background}
|
||
|
||
Προκειμένου να κατανοήσουμε πλήρως το πρόβλημα που επιλύει η παρούσα εργασία
|
||
πρέπει να αναλύσουμε μερικές βασικές έννοιες. Σε πρώτη φάση θα δούμε παρακάτω
|
||
τι είναι το υπολογιστικό νέφος, τι μας προσφέρει και ποια μοντέλα παράδοσης
|
||
παρέχονται μέσω αυτού. Έπειτα θα μιλήσουμε για την έννοια της εικονικοποίησης
|
||
και τις διάφορες υποκατηγορίες της που χρησιμοποιούνται στις μέρες μας. Αμέσως
|
||
μετά, θα αναλυθούν τα πλεονεκτήματα της και θα μπορέσουμε να εντοπίσουμε τον
|
||
λόγο που προτιμάται η αρχιτεκτονική δοχείων. Τέλος, θα εμβαθύνουμε στην
|
||
τεχνολογία δοχείων, θα δούμε διάφορες υλοποιήσεις της και θα πραγματοποιήσουμε
|
||
μια ανάλυση της ασφάλειας του \textlatin{Docker}.
|
||
|
||
\section{\textlatin{Cloud Computing Definition}} \label{cloudComputingDefinition}
|
||
|
||
Σύμφωνα με το \cite{mell2011nist} το \textlatin{Cloud Computing} είναι ένα
|
||
μοντέλο που επιτρέπει την ανά πάσα στιγμή διαδικτυακή πρόσβαση σε μια κοινή
|
||
δεξαμενή ρυθμιζόμενων υπολογιστικών πόρων που μπορούν να παρέχονται και να
|
||
απελευθερώνονται γρήγορα και με ελάχιστη προσπάθεια διαχείρισης ή
|
||
αλληλεπίδρασης με τον πάροχο υπηρεσιών. Στους υπολογιστικούς αυτούς πόρους
|
||
περιλαμβάνονται δίκτυα, διακομιστές, χώρος αποθήκευσης, εφαρμογές και
|
||
υπηρεσίες. Αυτό το μοντέλο νέφους αποτελείται από πέντε βασικά χαρακτηριστικά,
|
||
τρία μοντέλα υπηρεσιών και τέσσερα μοντέλα παράδοσης.
|
||
|
||
\pagebreak
|
||
|
||
\subsection{Χαρακτηριστικά} \label{cloucComputingCharacteristics}
|
||
|
||
Τα πέντε βασικά χαρακτηριστικά του \textlatin{Cloud Computing} με βάση τον
|
||
\textlatin{\citeauthor{mell2011nist}} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Αυτοεξυπηρέτηση κατά παραγγελία}:
|
||
|
||
Ένας καταναλωτής μπορεί να προμηθευτεί υπολογιστικούς πόρους όπως
|
||
αποθηκευτικό χώρο δικτύου και χρόνο χρήσης ισχυρών επεξεργαστών δίχως
|
||
την απαίτηση ανθρώπινης αλληλεπίδρασης με κάθε πάροχο υπηρεσιών.
|
||
|
||
\item \textbf{Ευρεία διαδικτυακή πρόσβαση}:
|
||
|
||
Οι υπηρεσίες που παρέχονται είναι διαθέσιμες μέσω του διαδικτύου και
|
||
είναι προσβάσιμες από οποιαδήποτε συσκευή διαθέτει πρόσβαση σε αυτό
|
||
είτε μέσω γραφικού περιβάλλοντος είτε μέσω ειδικά σχεδιασμένων
|
||
\textlatin{API}.
|
||
|
||
\item \textbf{Οργανωμένη συγκέντρωση πόρων}:
|
||
|
||
Οι υπολογιστικοί πόροι του παρόχου είναι σχεδιασμένοι με τέτοιο τρόπο
|
||
ώστε να μπορούν να εξυπηρετήσουν πολλούς καταναλωτές χρησιμοποιώντας
|
||
ένα \textlatin{multi-tenant} μοντέλο με διαφορετικούς φυσικούς και
|
||
εικονικούς πόρους που εκχωρούνται και ανακατανέμονται ανάλογα με τη
|
||
ζήτηση των καταναλωτών. Το μοντέλο αυτό διακατέχεται από μια αίσθηση
|
||
ανεξαρτησίας θέσης διότι είθισται να μην υπάρχει έλεγχος ή ακριβής
|
||
γνώση της τοποθεσίας τους αλλά δίδεται πολλές φορές η δυνατότητα
|
||
καθορισμού της χώρας ή περιοχής τους εάν το επιθυμεί ο χρήστης.
|
||
Παραδείγματα πόρων που παρέχονται αποτελούν μεταξύ άλλων το εύρος ζώνης
|
||
δικτύου, η διαθέσιμη μνήμη και ο αριθμός επεξεργαστών.
|
||
|
||
\item \textbf{Ταχεία ευελιξία}:
|
||
|
||
Οι δυνατότητες μπορούν να παρέχονται και να απελευθερώνονται ελαστικά
|
||
και σε ορισμένες περιπτώσεις αυτόματα, με σκοπό την οριζόντια ή κάθετη
|
||
κλιμάκωση υπηρεσιών αναλόγως την παρούσα ζήτηση. Από την οπτική γωνία
|
||
του καταναλωτή, οι παρεχόμενες δυνατότητες μοιάζουν απεριόριστες και
|
||
μπορούν να κατανεμηθούν ανά πάσα στιγμή σε οποιαδήποτε ποσότητα.
|
||
|
||
\item \textbf{Μετρούμενη υπηρεσία}:
|
||
|
||
Τα συστήματα νέφους ελέγχουν και βελτιστοποιούν αυτόματα τη χρήση των
|
||
πόρων αξιοποιώντας δυνατότητες μέτρησης κατάλληλες για τον τύπο της
|
||
υπηρεσίας (π.χ, αποθήκευση, επεξεργασία, εύρος ζώνης και λογαριασμοί
|
||
ενεργών χρηστών). Η χρήση των πόρων μπορεί να παρακολουθείται, να
|
||
ελέγχεται και να αναγράφεται, παρέχοντας διαφάνεια τόσο στον πάροχο όσο
|
||
και στον καταναλωτή της υπηρεσίας που χρησιμοποιείται.
|
||
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\subsection{Μοντέλα Υπηρεσιών} \label{cloudComputingServiceModels}
|
||
|
||
Τα τρία μοντέλα υπηρεσιών του \textlatin{Cloud Computing} όπως αναγράφονται στο
|
||
\textlatin{\citealt{mell2011nist}} είναι τα παρακάτω:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{\textlatin{Software as a Service (SaaS)}}:
|
||
|
||
Η δυνατότητα που παρέχεται στον καταναλωτή είναι η χρήση εφαρμογών
|
||
εκτελούμενες σε μια υποδομή νέφους. Οι εφαρμογές αυτές είναι
|
||
προσβάσιμες από διάφορες συσκευές ικανές να συνδεθούν στο διαδίκτυο
|
||
ή μέσω διεπαφής προγράμματος. Δεν προσφέρεται έλεγχος ή δυνατότητα
|
||
διαχείρισης της υποκείμενης υποδομής νέφους ή των δυνατοτήτων της
|
||
υπηρεσίας, με εξαίρεση περιορισμένη χρήση συγκεκριμένων
|
||
ρυθμίσεων διαμόρφωσης της εφαρμογής.
|
||
|
||
\item \textbf{\textlatin{Platform as a Service (PaaS)}}:
|
||
|
||
Η παρεχόμενη δυνατότητα είναι η χρήση ή η ανάπτυξη εφαρμογών σε μια
|
||
υποδομή νέφους. Οι εφαρμογές αυτές μπορεί να δημιουργήθηκαν ή να
|
||
αποκτήθηκαν από τον καταναλωτή και έχουν κατασκευαστεί χρησιμοποιώντας
|
||
γλώσσες προγραμματισμού, βιβλιοθήκες, υπηρεσίες και εργαλεία που
|
||
υποστηρίζονται από τον πάροχο. Ο καταναλωτής δεν έχει τον έλεγχο της
|
||
υποκείμενης υποδομής νέφους, αλλά έχει τον έλεγχο των εφαρμογών που
|
||
εκτελούνται σε αυτήν, καθώς και των ρυθμίσεων διαμόρφωσης τους και του
|
||
περιβάλλοντος εκτέλεσης τους.
|
||
|
||
\item \textbf{\textlatin{Infrastructure as a Service (IaaS)}}:
|
||
|
||
Η παρεχόμενη δυνατότητα είναι η χρήση επεξεργαστικών, αποθηκευτικών,
|
||
δικτυακών και άλλων υπολογιστικών πόρων όπου ο καταναλωτής μπορεί να
|
||
εκτελέσει και να εγκαταστήσει λογισμικό της επιλογής του,
|
||
συμπεριλαμβανομένων λειτουργικών συστημάτων και εφαρμογών. Ο
|
||
καταναλωτής δεν έχει τον έλεγχο της υποκείμενης υποδομής νέφους, αλλά
|
||
έχει τον έλεγχο των λειτουργικών συστημάτων, του αποθηκευτικού χώρου,
|
||
των εγκατεστημένων εφαρμογών και των ρυθμίσεων διαμόρφωσης τους.
|
||
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\subsection{Μοντέλα Παράδοσης} \label{cloudComputingDeploymentModels}
|
||
|
||
Τα τέσσερα μοντέλα παράδοσης του υπολογιστικού νέφους είναι με βάση τον
|
||
\textlatin{\citet{mell2011nist}}:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Ιδιωτικό νέφος}:
|
||
|
||
Το νέφος υποδομής είναι αποκλειστικά αφιερωμένο σε έναν μόνο οργανισμό
|
||
αποτελούμενο από πολλαπλούς καταναλωτές (π.χ. επιχειρησιακές μονάδες).
|
||
Ενδεχομένως να ανήκει, να διαχειρίζεται και να λειτουργεί από τον
|
||
οργανισμό, από μια τρίτη οντότητα, ή έναν συνδυασμό των δύο και μπορεί
|
||
να βρίσκεται εντός ή εκτός του οργανισμού.
|
||
|
||
\item \textbf{Κοινό νέφος}:
|
||
|
||
Είναι διαθέσιμο για μια ευρύτερη κοινότητα καταναλωτών ή οργανισμών με
|
||
κοινές ανησυχίες όπως οι απαιτήσεις ασφαλείας και ζητήματα πολιτικής
|
||
και συμμόρφωσης. Μπορεί να ανήκει, να διαχειρίζεται και να λειτουργεί
|
||
από έναν ή περισσότερους οργανισμούς της κοινότητας, μια τρίτη οντότητα
|
||
ή έναν συνδυασμό των δύο και να βρίσκεται εντός ή εκτός του οργανισμού.
|
||
|
||
\item \textbf{Δημόσιο νέφος}:
|
||
|
||
Εδώ, το νέφος υποδομής είναι διαθέσιμο για το γενικό κοινό. Μπορεί να
|
||
ανήκει και να διαχειρίζεται από μια επιχείρηση, έναν ακαδημαϊκό ή
|
||
κυβερνητικό οργανισμό ή έναν συνδυασμό των παραπάνω. Λειτουργεί εντός
|
||
των υποδομών του παρόχου νέφους.
|
||
|
||
\item \textbf{Υβριδικό νέφος}:
|
||
|
||
Είναι συνδυασμός δύο ή περισσότερων νεφών (ιδιωτικού, κοινού ή
|
||
δημοσίου) που διατηρούνται ως ξεχωριστές οντότητες αλλά συνδέονται
|
||
μεταξύ τους με τεχνολογίες που επιτρέπουν τη μεταφορά δεδομένων και
|
||
εφαρμογών.
|
||
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\section{\textlatin{Virtualization Definition}} \label{virtualizationDefinition}
|
||
|
||
Σύμφωνα με τον ορισμό της \textlatin{Red Hat}
|
||
\cite{redhatVirtualizationDefinition}, η εικονικοποίηση είναι μια τεχνολογία
|
||
που μας επιτρέπει να δημιουργήσουμε πολλαπλά εικονικά περιβάλλοντα ή
|
||
αποκλειστικούς πόρους από ένα μόνο, φυσικό σύστημα υλικού. Ένα λογισμικό
|
||
ονόματι \textlatin{hypervisor} συνδέεται απευθείας στο υλικό αυτό και δίνει τη
|
||
δυνατότητα διαμερισμού ενός συστήματος σε ξεχωριστά, διακριτά και ασφαλή
|
||
περιβάλλοντα, γνωστά και ως εικονικές μηχανές (\textlatin{VM}). Αυτές οι
|
||
εικονικές μηχανές βασίζονται στην ικανότητα του \textlatin{hypervisor} να
|
||
διαχωρίζει τους πόρους της μηχανής από το υλικό και να τους κατανέμει
|
||
κατάλληλα.
|
||
|
||
Το φυσικό υλικό, εξοπλισμένο με έναν \textlatin{hypervisor}, ονομάζεται
|
||
\textlatin{host}, ενώ τα πολλά \textlatin{VM} που χρησιμοποιούν τους πόρους του
|
||
είναι οι \textlatin{guests}. Αυτοί, αντιμετωπίζουν τους υπολογιστικούς πόρους
|
||
όπως είναι η κεντρική μονάδα επεξεργασίας, η μνήμη και ο αποθηκευτικός χώρος,
|
||
ως μια δεξαμενή πόρων που μπορεί εύκολα να ανακατανεμηθεί. Οι χειριστές μπορούν
|
||
να ελέγχουν εικονικά στιγμιότυπα της μνήμης, της κεντρικής μονάδας επεξεργασίας
|
||
και άλλων πόρων, ούτως ώστε οι \textlatin{guest} να λαμβάνουν τους πόρους που
|
||
χρειάζονται όταν είναι απαραίτητο.
|
||
|
||
Η εικονικοποίηση καθιστά δυνατή τη δημιουργία χρήσιμων υπηρεσιών ΤΠ
|
||
χρησιμοποιώντας πόρους στους οποίους παραδοσιακά μπορούσαμε να έχουμε πρόσβαση
|
||
μονάχα με την ιδιοκτησία φυσικών μηχανημάτων. Μας επιτρέπει να αξιοποιήσουμε
|
||
όλες τις δυνατότητες ενός φυσικού μηχανήματος διανέμοντας τις σε πολλούς
|
||
χρήστες και περιβάλλοντα.
|
||
|
||
\pagebreak
|
||
|
||
Ας φανταστούμε πως έχουμε τρεις διακομιστές, στον καθένα από τους οποίους έχει
|
||
ανατεθεί ένας συγκεκριμένος σκοπός. Ένας διακομιστής ηλεκτρονικού ταχυδρομείου,
|
||
ένας διακομιστής ιστού και ένας που εκτελεί εσωτερικές εταιρικές εφαρμογές οι
|
||
οποίες σταμάτησαν να διατηρούνται αλλά είναι ακόμα λειτουργικές. Στο
|
||
συγκεκριμένο παράδειγμα κάθε ένας από τους διακομιστές χρησιμοποιεί το μονάχα
|
||
το 30\% των δυνατοτήτων του.
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage1.png}
|
||
\captionof{figure}{Χρήση διακομιστών χωρίς εικονικοποίηση}
|
||
\label{fig:virtualizationServerUsage1}
|
||
\end{center}
|
||
|
||
Παραδοσιακά, αυτή η αρχιτεκτονική όπου εκτελούνται μεμονωμένες εργασίες σε
|
||
μεμονωμένους διακομιστές ήταν ευκολότερη και πιο αξιόπιστη αλλά δεν παύει να
|
||
μην είναι η πιο αποδοτική λύση. Με την άφιξη της τεχνολογίας της
|
||
εικονικοποίησης όμως ήταν πλέον εφικτό να χωριστεί ένας διακομιστής σε
|
||
περισσότερα κομμάτια έχοντας πλέον δύο εικονικά μηχανήματα με τη χρήση ενός
|
||
φυσικού.
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage2.png}
|
||
\captionof{figure}{Χρήση διακομιστών με εικονικοποίηση}
|
||
\label{fig:virtualizationServerUsage2}
|
||
\end{center}
|
||
|
||
Ο χωρισμός των διακομιστών σε μικρότερους μπορεί να πραγματοποιηθεί
|
||
περισσότερες από μια φορές αυξάνοντας την αξιοποίηση των δυνατοτήτων τους,
|
||
παραδείγματος χάριν από 30\% σε 60\% και έπειτα σε 90\% αφήνοντας μας με
|
||
διακομιστές που είτε μπορούν μετά να χρησιμοποιηθούν για νέους σκοπούς είτε να
|
||
αποσυρθούν μειώνοντας έτσι και το κόστος λειτουργίας και συντήρησης τους.
|
||
|
||
\pagebreak
|
||
|
||
\section{Ιστορική αναδρομή της εικονικοποίησης} \label{virtualizationHistory}
|
||
|
||
Ενώ η τεχνολογία εικονικοποίησης χρονολογείται από τη δεκαετία του 1960, δεν
|
||
υιοθετήθηκε ευρέως μέχρι τις αρχές της δεκαετίας του 2000. Οι τεχνολογίες που
|
||
την έκαναν πραγματικότητα όπως οι \textlatin{hypervisors} αναπτύχθηκαν πριν από
|
||
δεκαετίες για να δώσουν σε πολλούς χρήστες ταυτόχρονη πρόσβαση σε υπολογιστές
|
||
που επεξεργαζόντουσαν πολλά δεδομένα ταυτόχρονα. Κάτι ιδιαίτερα δημοφιλές στον
|
||
τομέα των επιχειρήσεων για καθήκοντα ρουτίνας που έπρεπε να εκτελεστούν
|
||
χιλιάδες φορές πολύ γρήγορα όπως η μισθοδοσία υπαλλήλων.
|
||
|
||
Ωστόσο, μέσα στις επόμενες δεκαετίες, ήρθαν στο προσκήνιο άλλες λύσεις στο
|
||
πρόβλημα διαμοιρασμού ενός μηχανήματος σε πολλούς χρήστες, μειώνοντας έτσι το
|
||
ενδιαφέρον για την τεχνολογία εικονικοποίησης. Μία από αυτές ήταν ο διαμοιρασμός
|
||
χρόνου (\textlatin{time-sharing}) όπου ένας χρήστης μπορούσε να χρησιμοποιεί το
|
||
λειτουργικό σύστημα απομονωμένα από του υπόλοιπους. Κάτι που οδήγησε στη
|
||
δημιουργία λειτουργικών συστημάτων όπως το \textlatin{UNIX} το οποίο με τη
|
||
σειρά του άνοιξε δρόμο για την άφιξη του \textlatin{Linux}. Καθ'' όλη τη
|
||
διάρκεια αυτή, η εικονικοποίηση παρέμεινε σε μεγάλο βαθμό μη διαδεδομένη.
|
||
|
||
Προχωρώντας στη δεκαετία του 1990, οι περισσότερες επιχειρήσεις διέθεταν
|
||
φυσικούς διακομιστές και στοίβες μηχανημάτων ενός προμηθευτή, οι οποίες δεν
|
||
είχαν τη δυνατότητα εκτέλεσης παλαιών εφαρμογών σε υλικό διαφορετικού
|
||
προμηθευτή. Καθώς οι εταιρείες αναβάθμιζαν τα περιβάλλοντα πληροφορικής τους με
|
||
λιγότερο δαπανηρούς διακομιστές, λειτουργικά συστήματα και εφαρμογές από
|
||
διάφορους προμηθευτές, ήταν υποχρεωμένες να υπολειτουργούν το φυσικό υλικό αφού
|
||
κάθε διακομιστής μπορούσε να εκτελέσει μόνο μια εργασία που αφορούσε
|
||
συγκεκριμένο προμηθευτή.
|
||
|
||
Από εκείνο το σημείο και έπειτα άρχισε να γίνεται εμφανής η ανάγκη της
|
||
εικονικοποίησης και να ανεβαίνει η δημοτικότητα της. Οι εταιρείες μπορούσαν
|
||
πλέον να διαμερίσουν τους διακομιστές τους και να εκτελούν παλαιές εφαρμογές σε
|
||
πολλούς τύπους και εκδόσεις λειτουργικών συστημάτων. Οι διακομιστές άρχισαν να
|
||
χρησιμοποιούνται πιο αποδοτικά ή και καθόλου μειώνοντας το απαιτούμενο κόστος
|
||
αγοράς, εγκατάστασης, συντήρησης και ψύξης τους.
|
||
|
||
Η ευρεία εφαρμογή της εικονικοποίησης συνέβαλε στη μείωση του εγκλωβισμού σε
|
||
έναν μόνο προμηθευτή και την κατέστησε το θεμέλιο του υπολογιστικού νέφους.
|
||
Σήμερα είναι τόσο διαδεδομένη σε όλες τις επιχειρήσεις που συχνά απαιτείται
|
||
εξειδικευμένο λογισμικό διαχείρισης των εικονικών πόρων για να μπορέσει κανείς
|
||
να παρακολουθεί τα δρώμενα της επιχείρησής.
|
||
|
||
\section{Τι είναι ένας \textlatin{hypervisor}} \label{hypervisors}
|
||
|
||
Προτού έρθουν στο προσκήνιο, οι περισσότεροι φυσικοί υπολογιστές μπορούσαν να
|
||
εκτελέσουν ένα λειτουργικό σύστημα τη φορά. Αυτό συνέβαλε στη σταθερότητα τους
|
||
μιας και δε χρειαζόταν να διαχειριστούν αιτήματα από άλλα λειτουργικά συστήματα
|
||
αλλά αυτή η προσέγγιση είχε ένα μειονέκτημα. Μεγάλο κομμάτι των πόρων του
|
||
συστήματος έμενε ανεκμετάλλευτο.
|
||
|
||
Τη λύση σε αυτό το πρόβλημα την έφερε η εισαγωγή των \textlatin{hypervisors}.
|
||
Πρόκειται για μια στρώση λογισμικού που καθιστά δυνατή την εκτέλεση πολλαπλών
|
||
λειτουργικών συστημάτων το ένα δίπλα στο άλλο μοιράζοντας τους ίδιους φυσικούς
|
||
πόρους σε κάθε ένα από αυτά. Η πράξη αυτή ονομάζεται εικονικοποίηση και τα
|
||
στιγμιότυπα των λειτουργικών συστημάτων λέγονται εικονικές μηχανές οι οποίες
|
||
αντιπροσωπεύουν προσομοιώσεις φυσικών υπολογιστών.
|
||
|
||
Οι \textlatin{hypervisors} είναι υπεύθυνοι για τη διαχείριση των εικονικών
|
||
μηχανών χωρίζοντας τις και αναθέτοντας σε κάθε μια ένα κομμάτι της διαθέσιμης
|
||
υπολογιστικής ισχύος, μνήμης και χώρου αποθήκευσης. Αυτή η διαδικασία τις
|
||
αποτρέπει από την αλληλεπίδραση μεταξύ τους και στην περίπτωση κατάρρευσης μιας
|
||
εικονικής μηχανής, οι υπόλοιπες παραμένουν ανεπηρέαστες.
|
||
|
||
\pagebreak
|
||
|
||
\section{Είδη \textlatin{hypervisor}} \label{hypervisorTypes}
|
||
|
||
Οι \textlatin{hypervisors} χωρίζονται σε δύο κατηγορίες ανάλογα με το
|
||
περιβάλλον στο οποίο εκτελούνται. Αυτές είναι:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{\textlatin{Type 1 (Bare Metal)}}:
|
||
|
||
Ένας \textlatin{hypervisor} τύπου 1 εκτελείται απευθείας στο φυσικό
|
||
υλικό του υποκείμενου υπολογιστή, αλληλεπιδρώντας άμεσα με την κεντρική
|
||
μονάδα επεξεργασίας, τη μνήμη και το φυσικό αποθηκευτικό χώρο. Για το
|
||
λόγο αυτό, οι \textlatin{hypervisors} τύπου 1 αναφέρονται επίσης ως
|
||
\textlatin{bare-metal hypervisors} και αντικαθιστούν το λειτουργικό
|
||
σύστημα του κεντρικού υπολογιστή. Η άμεση πρόσβαση στο φυσικό υλικό
|
||
τους καθιστά ιδιαίτερα αποδοτικούς. Συχνά απαιτείται μια ξεχωριστή
|
||
μηχανή διαχείρισης για τον έλεγχο των εικονικών μηχανών και του υλικού
|
||
του κεντρικού υπολογιστή.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{\textlatin{Type 2 (Hosted)}}:
|
||
|
||
Ένας \textlatin{hypervisor} τύπου 2 δεν εκτελείται απευθείας στο
|
||
υποκείμενο υλικό. Αντ'' αυτού, εκτελείται ως εφαρμογή σε ένα υπάρχον
|
||
λειτουργικό σύστημα. Η χρήση τους δε συνηθίζεται σε περιβάλλοντα με
|
||
πολλούς διακομιστές. Αντίθετα, είναι καταλληλότεροι για μεμονωμένους
|
||
τελικούς χρήστες υπολογιστών που έχουν την ανάγκη να εκτελέσουν
|
||
πολλαπλά λειτουργικά συστήματα. Μερικοί από αυτούς είναι μηχανικοί,
|
||
επαγγελματίες ασφαλείας που αναλύουν κακόβουλο λογισμικό και υπάλληλοι
|
||
επιχειρήσεων που χρειάζονται πρόσβαση σε εφαρμογές που είναι διαθέσιμες
|
||
αποκλειστικά σε διαφορετικές πλατφόρμες λογισμικού από τη δική τους.
|
||
|
||
Διατίθενται συχνά πρόσθετες εργαλειοθήκες για τους χρήστες οι οποίες
|
||
μπορούν να εγκατασταθούν στο λειτουργικό σύστημα προκειμένου να
|
||
παρέχουν βελτιωμένες συνδέσεις μεταξύ του υποκείμενου λειτουργικού
|
||
συστήματος και εκείνου της εικονικής μηχανής. Οι πρόσθετες δυνατότητες
|
||
που υποστηρίζονται μετά την παραπάνω διαδικασία μπορεί να είναι η
|
||
αποκοπή και επικόλληση μεταξύ των δύο συστημάτων ή η κοινή πρόσβαση
|
||
στον αποθηκευτικό χώρο.
|
||
|
||
Επιτρέπει τη γρήγορη εναλλαγή σε διαφορετικά λειτουργικά συστήματα
|
||
πέραν του ήδη υπάρχοντος, πράγμα που αυξάνει την παραγωγικότητα του
|
||
τελικού χρήστη, αφού μπορεί να έχει πρόσβαση σε εργαλεία που δεν
|
||
υποστηρίζονται στο δικό του.
|
||
|
||
Εξαιτίας της αρχιτεκτονικής τους, οι \textlatin{hypervisors} τύπου 2
|
||
εισάγουν προβλήματα καθυστέρησης που μπορεί να επηρεάσουν την απόδοση
|
||
διότι η πρόσβαση στους πόρους υπολογισμού, μνήμης και δικτύου
|
||
πραγματοποιείται μέσω του κεντρικού λειτουργικού συστήματος.
|
||
|
||
Επιπροσθέτως, εισάγει πιθανούς κινδύνους ασφάλειας εάν ένας εισβολέας
|
||
παραβιάσει το κεντρικό λειτουργικό σύστημα, επειδή θα μπορούσε στη
|
||
συνέχεια να χειραγωγήσει οποιοδήποτε φιλοξενούμενο λειτουργικό σύστημα
|
||
που εκτελείται σε αυτόν.
|
||
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\section{Χαρακτηριστικά των \textlatin{hypervisor}} \label{hypervisorCharacteristics}
|
||
|
||
Αν και υπάρχουν διαφορετικά είδη \textlatin{hypervisor}, όλοι έχουν κάποια
|
||
χαρακτηριστικά που πρέπει να λάβει κανείς υπόψιν όταν επιλέγει ποιον θα
|
||
χρησιμοποιήσει. Μερικά σημαντικά αυτών είναι:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Απόδοση}:
|
||
|
||
Βασικό χαρακτηριστικό ενός \textlatin{hypervisor} είναι η απόδοση του.
|
||
Διαφέρει από τον ένα στον άλλο αναλόγως την κατασκευή και τον τύπο του.
|
||
Οι \textlatin{bare-metal hypervisors} θα πρέπει να παρέχουν απόδοση
|
||
κοντά στην εγγενή.
|
||
|
||
\item \textbf{Οικοσύστημα}:
|
||
|
||
Για τη διαχείριση \textlatin{hypervisor} σε διάφορες κλίμακες πρέπει να
|
||
υπάρχει καλή τεκμηρίωση και διάφορα εργαλεία είτε επίσημα είτε από την
|
||
κοινότητα που να επιτρέπουν δυνατότητες όπως δημιουργία αντιγράφων
|
||
ασφαλείας, ανάλυση χωρητικότητας και διαχείριση εναλλαγής εικονικών
|
||
μηχανών σε περιπτώσεις σφάλματος του λειτουργικού συστήματος της
|
||
εκτελούμενης.
|
||
|
||
\item \textbf{Εργαλεία διαχείρισης}:
|
||
|
||
Η εκτέλεση εικονικών μηχανών δεν αποτελεί το μοναδικό καθήκον ενός
|
||
διαχειριστή κατά τη χρήση ενός \textlatin{hypervisor}. Απαραίτητες
|
||
πρόσθετες ενέργειες είναι η συντήρηση και η ανάλυση τους, καθώς και ο
|
||
καθαρισμός όσων δε χρησιμοποιούνται πλέον. Επομένως, η ύπαρξη εργαλείων
|
||
που να καθιστούν δυνατές αυτές τις ενέργειες αποτελεί σημαντικό
|
||
παράγοντα κατά την επιλογή λογισμικού \textlatin{hypervisor}.
|
||
|
||
\item \textbf{Μεταφορά κατά τη λειτουργία}:
|
||
|
||
Πρέπει να υπάρχει η δυνατότητα μεταφοράς εικονικών μηχανών από έναν
|
||
\textlatin{hypervisor} σε έναν δεύτερο σε διαφορετική φυσική μηχανή
|
||
χωρίς την ανάγκη διακοπής της λειτουργίας τους. Ένα χαρακτηριστικό που
|
||
χρησιμεύει τόσο για την ανατροπή αποτυχίας όσο και για την εξισορρόπηση
|
||
του φόρτου εργασίας.
|
||
|
||
\item \textbf{Κόστος}:
|
||
|
||
Το κόστος είναι ένας παράγοντας που πρέπει να ληφθεί υπόψιν κατά την
|
||
επιλογή ενός \textlatin{hypervisor}. Οι περισσότεροι είναι δωρεάν αλλά
|
||
υπάρχουν και εμπορικές εκδόσεις που προσφέρουν περισσότερες
|
||
δυνατότητες. Όπως επίσης και ύπαρξη ή μη, λογισμικού διαχείρισης τους
|
||
που να επιτρέπει την εύκολη κλιμάκωση με βάση τις απαιτήσεις της
|
||
επιχείρησης.
|
||
|
||
\end{itemize}
|
||
|
||
\section {Τρόπος λειτουργίας της εικονικοποίησης} \label{virtualizationOperation}
|
||
|
||
Για να πραγματοποιηθεί η εικονικοποίηση, χρειαζόμαστε έναν
|
||
\textlatin{hypervisor}. Δηλαδή ενός λογισμικό που διαχωρίζει τους φυσικούς
|
||
πόρους από τα εικονικά περιβάλλοντα, τα οποία τους χρειάζονται. Ένας
|
||
\textlatin{hypervisor} μπορεί να τοποθετηθεί πάνω σε ένα λειτουργικό σύστημα ή
|
||
να εγκατασταθεί απευθείας στο υλικό. Κάτι που κάνουν οι περισσότερες
|
||
επιχειρήσεις για λόγους αποδοτικότητας αφού θα βρίσκεται μια στρώση πιο κοντά
|
||
στο υλικό το οποίο θα διαχειρίζεται. Η δουλειά ενός \textlatin{hypervisor}
|
||
είναι ουσιαστικά να πάρουν τους φυσικούς μας πόρους και να τους χωρίσουν με
|
||
τέτοιο τρόπο ώστε να μπορούν να χρησιμοποιηθούν από τα εικονικά μας
|
||
περιβάλλοντα.
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_architecture.png}
|
||
\captionof{figure}{\textlatin{hypervisor} πάνω σε διακομιστές}
|
||
\label{fig:hypervisorOnServers}
|
||
\end{center}
|
||
|
||
Μετά τη δημιουργία μιας εικονικής μηχανής, οι χρήστες αλληλεπιδρούν με αυτήν
|
||
όπως θα αλληλεπιδρούσαν με μια φυσική. Οι εικονικές μηχανές έχουν τη μορφή ενός
|
||
ενιαίου αρχείου, πράγμα που καθιστά εύκολη τη μεταφορά και ανάγνωση τους από
|
||
οποιονδήποτε υπολογιστή αναμένοντας τον ίδιο τρόπο λειτουργίας. Κατά την
|
||
εκτέλεση του εικονικού περιβάλλοντος, όταν ένας χρήστης ή ένα πρόγραμμα εκδώσει
|
||
μία εντολή που απαιτεί περισσότερους πόρους από τους διαθέσιμους του, ο
|
||
\textlatin{hypervisor} αναμεταδίδει το αίτημα αυτό στο φυσικό σύστημα και
|
||
μπορεί να διαθέσει τους απαραίτητους για την εκτέλεση πόρους. Όλα αυτά
|
||
συμβαίνουν με σχεδόν εγγενή ταχύτητα, ιδίως αν αποστέλλεται μέσω ενός
|
||
\textlatin{hypervisor} ανοιχτού κώδικα βασισμένου στο \textlatin{KVM}, το
|
||
\textlatin{(Kernel-based Virtual Machine)} που επιτρέπει στο \textlatin{Linux}
|
||
να συμπεριφέρεται ως ένας \textlatin{hypervisor}.
|
||
|
||
\pagebreak
|
||
|
||
\section{Τύποι εικονικοποίησης} \label{virtualizationTypes}
|
||
|
||
Υπάρχουν πολλοί τύποι εικονικοποίησης. Πέντε βασικοί αυτών είναι οι παρακάτω:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{\textlatin{Data Virtualization}}:
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_data_virtualization.png}
|
||
\captionof{figure}{\textlatin{Data Virtualization}}
|
||
\label{fig:dataVirtualization}
|
||
\end{center}
|
||
|
||
Διασκορπισμένα δεδομένα μπορούν να ενοποιηθούν σε μια ενιαία πηγή. Με
|
||
την εικονικοποίηση δεδομένων, οι εταιρείες μπορούν να οργανώσουν και να
|
||
επεξεργαστούν διασκορπισμένες πληροφορίες με γνώμονα τις ανάγκες των
|
||
χρηστών με μεγαλύτερη ευκολία και αποδοτικότητα. Τομείς οι οποίοι
|
||
επωφελούνται από την εικονικοποίηση δεδομένων είναι η λήψη αποφάσεων, η
|
||
επιχειρηματική αναλυτική και η αξιολόγηση των κινδύνων.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{\textlatin{Desktop Virtualization}}:
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_desktop_virtualization.png}
|
||
\captionof{figure}{\textlatin{Desktop Virtualization}}
|
||
\label{fig:desktopVirtualization}
|
||
\end{center}
|
||
|
||
Επιτρέπει σε έναν κεντρικό διαχειριστή να μοιράζει προσομοιωμένα
|
||
περιβάλλοντα εργασίας σε εκατοντάδες φυσικές μηχανές ταυτοχρόνως. Εν
|
||
αντιθέσει με τα παραδοσιακά περιβάλλοντα εργασίας που χρήζουν
|
||
εγκατάστασης, διαμόρφωσης και ενημέρωσης σε κάθε υπολογιστή, η
|
||
εικονικοποίηση επιφάνειας εργασίας καθιστά δυνατή τη μαζική διαμόρφωση,
|
||
ενημέρωση και έλεγχο ασφαλείας σε όλα τα εικονικά περιβάλλοντα
|
||
εργασίας.
|
||
|
||
\item \textbf{\textlatin{Server Virtualization}}:
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_server_virtualization.png}
|
||
\captionof{figure}{\textlatin{Server Virtualization}}
|
||
\label{fig:serverVirtualization}
|
||
\end{center}
|
||
|
||
Οι διακομιστές είναι υπολογιστές σχεδιασμένοι με σκοπό να
|
||
επεξεργάζονται πολύ καλά έναν μεγάλο όγκο συγκεκριμένων εργασιών, ώστε
|
||
οι κύριοι υπολογιστές να μπορούν να δίνουν προτεραιότητα σε άλλες
|
||
εργασίες. Η εικονικοποίηση ενός διακομιστή του επιτρέπει να εκτελεί
|
||
περισσότερες λειτουργίες από αυτές που σχεδιάστηκε αρχικά να
|
||
πραγματοποιεί. Για την επίτευξη αυτού απαιτείται η κατάτμησή του με
|
||
τέτοιο τρόπο ώστε οι πόροι του να μπορούν να χρησιμοποιηθούν για την
|
||
εξυπηρέτηση πολλαπλών λειτουργιών.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{\textlatin{Operating System Virtualization}}:
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_os_virtualization.png}
|
||
\captionof{figure}{\textlatin{Operating System Virtualization}}
|
||
\label{fig:operatingSystemVirtualization}
|
||
\end{center}
|
||
|
||
Η εικονικοποίηση λειτουργικού συστήματος είναι κάτι που συμβαίνει στον
|
||
πυρήνα. Αποτελεί έναν χρήσιμο τρόπο εκτέλεσης \textlatin{Linux} και
|
||
\textlatin{Windows} συστημάτων στο ίδιο μηχάνημα. Πολλές επιχειρήσεις
|
||
προωθούν τα εικονικά λειτουργικά συστήματα σε υπολογιστές, προκειμένου
|
||
να μειωθεί το κόστος μηχανημάτων, να αυξηθεί η ασφάλεια και να μειωθεί
|
||
ο χρόνος συντήρησης τους.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{\textlatin{Network Function Virtualization}}:
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_network_function_virtualization.png}
|
||
\captionof{figure}{\textlatin{Network Function Virtualization}}
|
||
\label{fig:networkFunctionVirtualization}
|
||
\end{center}
|
||
|
||
Η εικονικοποίηση λειτουργιών δικτύου (\textlatin{NFV}) διαχωρίζει τις
|
||
βασικές λειτουργίες ενός δικτύου (όπως ο διαμοιρασμός αρχείων, και η
|
||
διαμόρφωση \textlatin{IP}), ώστε να μπορούν να διανεμηθούν σε διάφορα
|
||
περιβάλλοντα. Από τη στιγμή που οι λειτουργίες λογισμικού είναι
|
||
ανεξάρτητες από τα φυσικά μηχανήματα στα οποία εκτελούνται,
|
||
συγκεκριμένες λειτουργίες μπορούν να πακεταριστούν μαζί σε ένα νέο
|
||
δίκτυο και να ανατεθούν σε ένα ξεχωριστό περιβάλλον. Η εικονικοποίηση
|
||
των δικτύων μειώνει τον αριθμό των φυσικών εξαρτημάτων όπως οι
|
||
μεταγωγείς, δρομολογητές, διακομιστές, καλώδια και κόμβοι που
|
||
απαιτούνται για τη δημιουργία πολλαπλών, ανεξάρτητων δικτύων και είναι
|
||
ιδιαίτερα δημοφιλής στον κλάδο των τηλεπικοινωνιών.
|
||
|
||
\end{itemize}
|
||
|
||
\pagebreak
|
||
|
||
\section{Πλεονεκτήματα της εικονικοποίησης} \label{virtualizationAdvantages}
|
||
|
||
Η εικονικοποίηση προσφέρει πολλά πλεονεκτήματα στις επιχειρήσεις. Τα πιο
|
||
αξιοσημείωτα αυτών με βάση την
|
||
\textlatin{\citeauthor{ibmVirtualizationDefinition}} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Αποδοτικότητα πόρων}:
|
||
|
||
Προτού η εικονικοποίηση γίνει δημοφιλής, κάθε διακομιστής εφαρμογής
|
||
απαιτούσε τη δική του αποκλειστική μονάδα κεντρικής επεξεργασίας. Το
|
||
προσωπικό της επιχείρησης έπρεπε να αγοράσει και να ρυθμίσει έναν
|
||
ξεχωριστό διακομιστή για κάθε εφαρμογή που έπρεπε να εκτελέσει. Η
|
||
προτιμώμενη αρχιτεκτονική για λόγους αξιοπιστίας ήταν να υπάρχει μια
|
||
εφαρμογή και ένα μόνο λειτουργικό σύστημα για κάθε υπολογιστή. Αυτό
|
||
είχε ως αποτέλεσμα την υποχρησιμοποίηση κάθε διακομιστή. Η λύση ήρθε με
|
||
τη μορφή της εικονικοποίησης διακομιστών η οποία επέτρεπε την εκτέλεση
|
||
πολλαπλών εφαρμογών σε έναν φυσικό υπολογιστή δίχως την ελάττωση της
|
||
αξιοπιστίας.
|
||
|
||
\item \textbf{Ευκολότερη διαχείριση}:
|
||
|
||
Αντικαθιστώντας φυσικούς υπολογιστές με προγραμματιστικά καθορισμένες
|
||
εικονικές μηχανές δύναται η χρήση αυτοματοποιημένων ροών διαχείρισης
|
||
εργασιών. Οι διαχειριστές συστημάτων μπορούν να χρησιμοποιούν εργαλεία
|
||
για τον καθορισμό εικονικών μηχανών χρησιμοποιώντας πρότυπα κατάλληλα
|
||
για την υποδομή κάθε επιχείρησης. Με αυτόν τον τρόπο η εγκατάσταση και
|
||
η ρύθμισή τους μπορεί να γίνεται επανειλημμένα δίχως το ρίσκο
|
||
ανθρώπινου λάθους και γλιτώνοντας τον χρόνο εγκατάστασης και ρύθμισης
|
||
τους χειροκίνητα. Ένας συνδυασμός εργαλείων που κάνει αυτή τη
|
||
διαδικασία πραγματικότητα είναι τα \textlatin{Ansible} \cite{ansible}
|
||
και \textlatin{Terraform} \cite{terraform}.
|
||
|
||
\item \textbf{Ελάχιστος χρόνος διακοπής λειτουργίας}:
|
||
|
||
Οι καταρρεύσεις λειτουργικών συστημάτων και εφαρμογών μπορεί να
|
||
προκαλέσουν διακοπή λειτουργίας και να διαταράξουν την παραγωγικότητα
|
||
των χρηστών. Οι διαχειριστές μπορεί να έχουν πλεονάζουσες εικονικές
|
||
μηχανές και να πραγματοποιούν εναλλαγή σε αυτές εάν εμφανιστούν
|
||
προβλήματα, κάτι που δε θα ήταν αποδοτικό για την επιχείρηση
|
||
διαθέτοντας μονάχα φυσικούς διακομιστές.
|
||
|
||
\item \textbf{Ταχύτερη παροχή}:
|
||
|
||
Η αγορά, εγκατάσταση και διαμόρφωση του υλικού για κάθε εφαρμογή είναι
|
||
χρονοβόρα. Εφόσον το υλικό είναι ήδη στη θέση του, η παροχή εικονικών
|
||
μηχανών για την εκτέλεση όλων των εφαρμογών είναι σημαντικά ταχύτερη.
|
||
|
||
\end{itemize}
|
||
|
||
\section{Τεχνολογίες εικονικοποίησης} \label{virtualizationTechnologies}
|
||
|
||
Όταν αναφερόμαστε στην εικονικοποίηση συνήθως μιλάμε για την πιο συνηθισμένη
|
||
μορφή της η οποία είναι η πλήρης εικονικοποίηση. Με την πάροδο του χρόνου και
|
||
την αύξηση της δημοτικότητας της εικονικοποίησης αναπτύχθηκαν πολλοί
|
||
\textlatin{hypervisors} που μπορεί να διαφέρουν όχι μόνο στα χαρακτηριστικά
|
||
τους αλλά και στις διάφορες τεχνικές που χρησιμοποιούν για να κάνουν την
|
||
εικονικοποίηση πραγματικότητα. Μια από αυτές ονομάζεται
|
||
\textlatin{para-virtualization}.
|
||
|
||
\subsection{\textlatin{Para-virtualization}} \label{paraVirtualization}
|
||
|
||
Η \textlatin{para-virtualization} \cite{suseParavirtualizationDefinition} είναι
|
||
μια τεχνική εικονικοποίησης που αναπτύχθηκε προκειμένου να ξεπεραστούν ορισμένα
|
||
προβλήματα επιδόσεων που εισάγει η πλήρης εικονικοποίηση λόγω της συνεχούς
|
||
μετάφρασης φυσικών και εικονικών πόρων. Εξαιτίας αυτού, περιορίζεται σημαντικά
|
||
ο αριθμός εικονικών μηχανών που μπορεί να υποστηρίξει ένας διακομιστής και τα
|
||
είδη εφαρμογών που μπορούν να εκτελεστούν σε μια εικονική μηχανή. Πρόκειται για
|
||
μια κατηγορία εικονικοποίησης της κεντρικής μονάδας επεξεργασίας
|
||
\cite{geeksforgeeksParavirtualizationDefinition} κατά την οποία, δύναται το
|
||
λειτουργικό σύστημα να επικοινωνεί άμεσα με τον \textlatin{hypervisor} με σκοπό
|
||
τη διεξαγωγή δραστηριοτήτων που θα ήταν χρονοβόρες για τον διαχειριστή
|
||
εικονικών μηχανών, κάνοντας χρήση ειδικών εντολών ονόματι
|
||
\textlatin{hypercalls} για τη διαχείριση αιτημάτων κατά τον χρόνο εκτέλεσης.
|
||
Προκειμένου να επιτευχθεί αυτό, τα λειτουργικά συστήματα χρειάζονται μια μικρή
|
||
τροποποίηση η οποία επιτρέπει την υλοποίηση ενός ειδικού \textlatin{API} μέσω
|
||
του οποίου θα πραγματοποιείται η ανταλλαγή \textlatin{hypercall} ανάμεσα σε
|
||
αυτά και τον \textlatin{hypervisor}. Οι \textlatin{hypervisors} που το
|
||
υποστηρίζουν αυτό απαιτούν την υποστήριξη του λειτουργικού συστήματος και τη
|
||
χρήση ειδικών προγραμμάτων οδήγησης τα οποία είναι πλέον ενσωματωμένα στον
|
||
πυρήνα του \textlatin{Linux}. Κάνοντας χρήση της τεχνικής αυτής, το λειτουργικό
|
||
σύστημα της εικονικής μηχανής δεν είναι πλήρως απομονωμένο αλλά απομονώνεται
|
||
μερικώς από το υλικό και το επίπεδο εικονικοποίησης.
|
||
|
||
\pagebreak
|
||
|
||
Στην εικόνα \ref{fig:FullVirtualization} παρουσιάζεται η αρχιτεκτονική της
|
||
πλήρους εικονικοποίησης όπου το λειτουργικό σύστημα της εικονικής μηχανής
|
||
επιβάλλεται να περάσει τα αιτήματα του μέσω του διαχειριστή εικονικών μηχανών.
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/GeeksForGeeksParavirtualization/Full-Virualization.png}
|
||
\captionof{figure}{\textlatin{Full Virtualization}}
|
||
\label{fig:FullVirtualization}
|
||
\end{center}
|
||
|
||
Αντιθέτως, στην εικόνα \ref{fig:ParaVirtualization} όπου και απεικονίζεται η
|
||
αρχιτεκτονική της τεχνικής \textlatin{para-virtualization}, βλέπουμε πως μέσω
|
||
των \textlatin{hypercall} όλα τα αιτήματα προορίζονται στη στρώση
|
||
εικονικοποίησης και από εκεί στο κύριο σύστημα.
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .5\textwidth]{Figures/GeeksForGeeksParavirtualization/Paravirtualization.png}
|
||
\captionof{figure}{\textlatin{Para Virtualization}}
|
||
\label{fig:ParaVirtualization}
|
||
\end{center}
|
||
|
||
\pagebreak
|
||
|
||
Οι διαφορές της πλήρους εικονικοποίησης με την \textlatin{para-virtualization} είναι οι εξής:
|
||
|
||
\begin{table}[h!]
|
||
\renewcommand{\arraystretch}{1.5}
|
||
\centering
|
||
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
|
||
\begin{tabular}{||c|C|C||}
|
||
\hline
|
||
|
||
Νούμερο & Πλήρης εικονικοποίηση & \textlatin{Paravirtualization} \\ [0.5ex]
|
||
|
||
\hline\hline
|
||
|
||
1 &
|
||
|
||
Πλήρης απομόνωση της εικονικής μηχανής. &
|
||
|
||
Μερική απομόνωση και χρήση \textlatin{API} για αμεσότερη επικοινωνία. \\
|
||
|
||
\hline
|
||
|
||
2 &
|
||
|
||
Λιγότερο ασφαλής. &
|
||
|
||
Υπάρχει επίγνωση του εικονικού περιβάλλοντος και δε γίνεται εκκίνηση του
|
||
\textlatin{BIOS} \cite{ParavirtualizationSecurity}, πράγμα που την καθιστά
|
||
ασφαλέστερη. \\
|
||
|
||
\hline
|
||
|
||
3 &
|
||
|
||
Χρήση δυαδικής μετάφρασης. &
|
||
|
||
Χρήση \textlatin{hypercall} κατά την εκτέλεση. \\
|
||
|
||
\hline
|
||
|
||
4 &
|
||
|
||
Πιο αργές ταχύτητες. &
|
||
|
||
Γρηγορότερη εκτέλεση. \\
|
||
|
||
\hline
|
||
|
||
5 &
|
||
|
||
Μεγαλύτερη συμβατότητα και φορητότητα. &
|
||
|
||
Λόγω της αρχιτεκτονικής της είναι δυσκολότερη η μεταφορά εικονικών μηχανών. \\
|
||
|
||
\hline
|
||
|
||
6 &
|
||
|
||
Υποστήριξη όλων των συστημάτων χωρίς την απαίτηση τροποποιήσεων. &
|
||
|
||
Απαιτείται τροποποίηση του λειτουργικού συστήματος της εικονικής μηχανής για να
|
||
κάνει χρήση \textlatin{hypercalls}. \\
|
||
|
||
\hline
|
||
\end{tabular}
|
||
\caption{Διαφορές πλήρους εικονικοποίησης και παρα-εικονικοποίησης}
|
||
\label{table:virtualizationTechniquesDifference}
|
||
\renewcommand{\arraystretch}{1}
|
||
\end{table}
|
||
|
||
\section{Ασφάλεια στην εικονικοποίηση} \label{virtualizationSecurity}
|
||
|
||
Η χρήση της εικονικοποίησης παρέχει αρκετά εγγενή οφέλη ασφαλείας. Ένα
|
||
σημαντικό αυτών είναι η ικανότητα επαναφοράς εικονικών μηχανών που έχουν
|
||
μολυνθεί με κακόβουλο λογισμικό σε μια χρονική περίοδο πριν τη μόλυνση τους και
|
||
η δυνατότητα διαγραφής και αναδημιουργίας τους με έναν αυτοματοποιημένο τρόπο
|
||
σε περίπτωση που η επαναφορά για οποιονδήποτε λόγο δεν είναι εφικτή. Κάτι το
|
||
οποίο είναι αρκετές φορές αδύνατο να συμβεί με ένα φυσικό μηχάνημα διότι το
|
||
κακόβουλο λογισμικό συχνά μπορεί να είναι βαθιά ριζωμένο στα βασικά συστατικά
|
||
του συστήματος.
|
||
|
||
Παρ'' όλα αυτά η εικονικοποίηση δεν είναι απαλλαγμένη από κινδύνους καθώς
|
||
παραβιάζοντας τον \textlatin{hypervisor}, ένας επιτιθέμενος έχει πρόσβαση σε
|
||
όλες τις εικονικές μηχανές που διαχειρίζονται μέσω αυτού και είναι δυσκολότερο
|
||
να εντοπιστεί λόγω της ικανότητας του \textlatin{hypervisor} να επιτρέπει στις
|
||
εικονικές μηχανές τη μεταξύ τους επικοινωνία χωρίς την αλληλεπίδραση με το
|
||
φυσικό δίκτυο. Επιπροσθέτως, η ακεραιότητα ενός \textlatin{hypervisor}
|
||
εξαρτάται άμεσα και από τον τύπου του αφού στην κατηγορία \textlatin{hosted
|
||
hypervisor} αρκεί να παραβιαστεί το λειτουργικό σύστημα στο οποίο εκτελείται.
|
||
|
||
\subsection{Απειλές στην εικονικοποίηση} \label{virtualizationThreats}
|
||
|
||
Όλες οι μορφές εικονικοποίησης είναι ευάλωτες σε επιθέσεις. Όπως αναφέρεται και
|
||
στο \cite{wen2008sevmm} μέσω του \cite{arif2015virtualization}, πολλές φορές δε
|
||
δύναται ο διαχειριστής εικονικών μηχανών, το λειτουργικό σύστημα ή ακόμα και το
|
||
\textlatin{Mandatory Access Control} του \textlatin{Linux} να ανταπεξέλθουν
|
||
στις απαιτήσεις ασφαλείας όλων των εφαρμογών. Το παράδειγμα που παρουσιάζεται
|
||
στο \cite{arif2015virtualization} αναφέρεται στην εικονικοποίηση χώρου
|
||
αποθήκευσης μέσω δικτύου αλλά πολλές από τις απειλές δεν περιορίζονται μονάχα
|
||
εκεί. Ουσιαστικά κάθε εικονική μηχανή που έχει πρόσβαση στο διαδίκτυο είναι
|
||
ευάλωτη σε απειλές όπως \textlatin{Trojans}, ιούς και κακόβουλα λογισμικά που
|
||
μπορεί να μεταφερθούν από έναν \textlatin{hypervisor} σε κάθε εικονική μηχανή.
|
||
|
||
Πολλές από τις απειλές που θα αναφερθούν παρακάτω μπορούν να συνοψιστούν και ως εξής:
|
||
|
||
\begin{table}[h!]
|
||
\renewcommand{\arraystretch}{1.5}
|
||
\centering
|
||
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
|
||
\begin{tabular}{||C|C||}
|
||
\hline
|
||
|
||
Πηγή απειλής & Περιγραφή \\ [0.5ex]
|
||
|
||
\hline\hline
|
||
|
||
\textlatin{NW $\Rightarrow$ VMM} &
|
||
|
||
Απειλές που προέρχονται από το δίκτυο και στοχεύουν τον \textlatin{hypervisor}.
|
||
\\
|
||
|
||
\hline
|
||
|
||
\textlatin{NW $\Rightarrow$ VM} &
|
||
|
||
Απειλές που προέρχονται από το δίκτυο και στοχεύουν τις εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
|
||
\textlatin{VMM $\Rightarrow$ VM} &
|
||
|
||
Απειλές που προέρχονται από τον \textlatin{hypervisor} και στοχεύουν τις
|
||
εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
|
||
\textlatin{VM $\Rightarrow$ VM} &
|
||
|
||
Απειλές που προέρχονται από τις εικονικές μηχανές και στοχεύουν άλλες εικονικές
|
||
μηχανές. \\
|
||
|
||
\hline
|
||
|
||
\textlatin{Admin $\Rightarrow$ VMM} &
|
||
|
||
Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν τον
|
||
\textlatin{hypervisor}. \\
|
||
|
||
\hline
|
||
|
||
\textlatin{Admin $\Rightarrow$ VM} &
|
||
|
||
Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν τις
|
||
εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
\end{tabular}
|
||
\caption{Απειλές στην εικονικοποίηση}
|
||
\label{table:virtualizationThreats}
|
||
\renewcommand{\arraystretch}{1}
|
||
\end{table}
|
||
|
||
\pagebreak
|
||
|
||
\subsubsection{Επιθέσεις στον πάροχο νέφους} \label{cloudProviderAttack}
|
||
|
||
Τη σήμερον ημέρα όλο και περισσότερες επιχειρήσεις θα προτιμήσουν να βασιστούν
|
||
σε έναν πάροχο νέφους για την απόκτηση υποδομών προκειμένου να ξεκινήσουν να
|
||
εξυπηρετούν τους δυνητικούς πελάτες τους έναντι της παραδοσιακής διαδικασίας
|
||
αγοράς, ρύθμισης και διαχείρισης φυσικών διακομιστών. Η ταχύτερη εκκίνηση
|
||
παροχής υπηρεσιών και η ευκολία διαχείρισης της υποδομής τους, δεν αφήνουν
|
||
περιθώρια αμφιβολίας της ορθότητας αυτής της απόφασης. Όπως αναφέραμε όμως στο
|
||
\ref{cloudComputingSecurity}, εισάγεται έτσι ένα αναγκαίο μοντέλο εμπιστοσύνης
|
||
ανάμεσα στον πάροχο νέφους και τις επιχειρήσεις.
|
||
|
||
Ένα από τα σημαντικότερα ζητήματα που απασχολεί μια επιχείρηση είναι η
|
||
ασφάλεια. Επιλέγοντας να χρησιμοποιήσουν τις υπηρεσίες ενός παρόχου νέφους όμως
|
||
παραχωρούν ουσιαστικά πρόσβαση στις εφαρμογές τους και στα ευαίσθητα δεδομένα
|
||
αυτών διότι η ευθύνη προστασίας των υποδομών ανήκει στον ιδιοκτήτη τους και
|
||
στην προκειμένη περίπτωση αυτός είναι ο πάροχος νέφους. Έτσι κακόβουλοι
|
||
εισβολείς θα προσπαθήσουν να βρουν ατασθαλίες στη διαδικασία παράδοσης των
|
||
υπηρεσιών του παρόχου εκτελώντας επιθέσεις τύπου \textlatin{Cross site
|
||
scripting, SQL injection}, χειραγώγηση \textlatin{cookies} ή εκμετάλλευση μη
|
||
ασφαλούς ρύθμισης, θέτοντας έτσι σε κίνδυνο ευαίσθητες πληροφορίες και δεδομένα
|
||
των επιχειρήσεων.
|
||
|
||
\subsubsection{Επιθέσεις μέσω του δικτύου} \label{attackOverNetwork}
|
||
|
||
Για να μπορούν οι επιχειρήσεις να παρέχουν τις υπηρεσίες τους στους τελικούς
|
||
χρήστες είναι απαραίτητη η μεταφορά δεδομένων από την επιχείρηση προς τον
|
||
πάροχο νέφους στου οποίου τις υποδομές στεγάζονται οι εφαρμογές τους. Όλα τα
|
||
δίκτυα όμως είναι επιρρεπή σε επιθέσεις αν δεν έχουν ληφθεί τα κατάλληλα μέτρα
|
||
προστασίας. Στις επιθέσεις αυτές περιλαμβάνονται η κατασκοπεία και διείσδυση
|
||
δικτύου και η εκμετάλλευση αδυναμιών του. Αυτές οι επιθέσεις όμως συνήθως
|
||
καταπολεμούνται με χρήση κρυπτογραφημένης σύνδεσης κατά τη μεταφορά δεδομένων.
|
||
|
||
\subsubsection{Ακεραιότητα δεδομένων} \label{dataIntegrity}
|
||
|
||
Η ακεραιότητα των δεδομένων αποτελεί είναι ένα από τα τρία βασικά στοιχεία της
|
||
ασφάλειας \cite{ciaTriad} δίχως την οποία οι επιχειρήσεις δε θα μπορούσαν να
|
||
παραμείνουν λειτουργικές. Απαιτείται μεγάλη προσοχή κατά τον σχεδιασμό των
|
||
βάσεων δεδομένων και της συντήρησης τους σε περιβάλλοντα νέφους αλλά και η
|
||
χρήση ορθών πρακτικών όπως ένα σχέδιο επαναφοράς εφεδρικών αντιγράφων
|
||
προκειμένου να μην υπάρξει απώλεια σημαντικών δεδομένων της επιχείρησης.
|
||
|
||
\subsubsection{Εμπιστευτικότητα δεδομένων} \label{dataConfidentiality}
|
||
|
||
Όπως η ακεραιότητα, έτσι και η εμπιστευτικότητα των δεδομένων είναι κάτι για το
|
||
οποίο μια επιχείρηση πρέπει να φροντίσει εκ των προτέρων. Ένα κενό ασφαλείας
|
||
στην τελική εφαρμογή ενός χρήστη μπορεί να δώσει πρόσβαση σε έναν εισβολέα
|
||
παραβιάζοντας έτσι τις βάσεις δεδομένων της επιχείρησης. Επειδή σε ένα
|
||
περιβάλλον νέφους δεν έχει η ίδια η επιχείρηση πρόσβαση στις υποδομές που
|
||
χρησιμοποιεί, είναι απαραίτητη η επικοινωνία με τον πάροχο νέφους προκειμένου
|
||
να διαπιστωθεί ο τρόπος εξασφάλισης της εμπιστευτικότητας των δεδομένων από
|
||
μεριάς του.
|
||
|
||
\subsubsection{Διαθεσιμότητα δεδομένων} \label{dataAvailability}
|
||
|
||
Η διαθεσιμότητα των δεδομένων που είναι και το τελευταίο στοιχείο της ασφάλειας
|
||
εξαρτάται άμεσα από τη συνεχή παροχή υποδομών προς την επιχείρηση. Είναι
|
||
απαραίτητη λοιπόν η εμπιστοσύνη προς τον πάροχο νέφους και γι'' αυτό τον λόγο
|
||
είθισται να επιλέγουν οι επιχειρήσεις μεγάλα ονόματα στον κλάδο της
|
||
υπολογιστικής νέφους. Ένας διαχειριστής εικονικών μηχανών έχει τον πλήρη έλεγχο
|
||
της λειτουργίας τους και το ίδιο ισχύει και για τον πάροχο νέφους μέσω του
|
||
οποίου έχει πρόσβαση ο διαχειριστής. Όλες οι ιδέες περί προστασίας και
|
||
ασφάλειας των εικονικών μηχανών λειτουργούν υπό την προϋπόθεση ότι υπάρχει
|
||
εμπιστοσύνη προς τον πάροχο. Είναι λοιπόν απαραίτητη όχι μόνο η έρευνα για
|
||
καλύτερη προστασία εικονικών περιβαλλόντων αλλά και για την ορθότερη επιλογή
|
||
παρόχου νέφους.
|
||
|
||
\section{\textlatin{Containerization}} \label{containerizationDefinition}
|
||
|
||
Πέραν της πλήρους εικονικοποίησης και της παρα-εικονικοποίησης, εδώ και αρκετά
|
||
χρόνια πολλές επιχειρήσεις στρέφονται σε τεχνολογίες που χρησιμοποιούν
|
||
\textlatin{containerization}. Με βάση την
|
||
\textlatin{\citeauthor{ibmContainerizationDefinition}}, πρόκειται για το
|
||
πακετάρισμα λογισμικού μονάχα με τις βιβλιοθήκες και τις εξαρτήσεις που
|
||
χρειάζεται για να εκτελεστεί δημιουργώντας ένα εκτελέσιμο ````δοχείο'''' που
|
||
πάντοτε θα εκτελείται με την ίδια συμπεριφορά ανεξαρτήτως υποδομής. Με την
|
||
παραδοσιακή μέθοδο ανάπτυξης λογισμικού υπήρχε πάντα το ρίσκο το πρόγραμμα που
|
||
αναπτύχθηκε σε ένα συγκεκριμένο περιβάλλον να μη λειτουργεί με τον αναμενόμενο
|
||
τρόπο κατά τη μεταφορά του σε ένα άλλο, εκτός εάν έχει ελεγχθεί ότι υπάρχουν
|
||
όλες οι εξαρτήσεις που χρειάζεται στις εκδόσεις που τις χρειάζεται. Ακόμα και
|
||
σε αυτήν την περίπτωση όμως, πέραν του κόπου για τον έλεγχο είναι αρκετά πιθανό
|
||
ένα δεύτερο πρόγραμμα να χρειάζεται διαφορετικές εκδόσεις ίδιων εξαρτήσεων.
|
||
|
||
Τα προβλήματα αυτά έρχεται να λύσει η τεχνολογία \textlatin{containerization}.
|
||
Όπως αναφέραμε στο \ref{dockerOrigins}, από το 2013 και έπειτα η άφιξη του
|
||
\textlatin{Docker} επιτάχυνε κατά πολύ την υιοθέτηση της τεχνολογίας αυτής. Σε
|
||
τέτοιο βαθμό που σε μια έρευνα της \textlatin{IBM} \cite{ibmContainerSurvey}
|
||
βρέθηκε πως το 61\% όσων ξεκίνησαν να χρησιμοποιούν δοχεία, το κάνουν στο 50\%
|
||
ή παραπάνω των εφαρμογών που δημιούργησαν τα τελευταία δύο χρόνια, ενώ 64\%
|
||
αυτών αναμένουν 50\% των υπαρχουσών εφαρμογών τους να κάνουν χρήση δοχείων στα
|
||
επόμενα δύο χρόνια.
|
||
|
||
Ένας από τους χαρακτηρισμούς των δοχείων είναι η ````ελαφρότητα'''' τους σε
|
||
σχέση με μια εικονική μηχανή λόγω της ικανότητας τους να μοιράζονται τον πυρήνα
|
||
του συστήματος. Η απαίτηση μιας εικονικής μηχανής να χρειάζεται να έχει δικό
|
||
της πυρήνα, την καθιστά μεγαλύτερη σε μέγεθος και λιγότερο αποδοτική στη χρήση
|
||
πόρων του συστήματος. Τα δοχεία είναι εγγενώς μικρότερα σε μέγεθος και έχουν
|
||
και μικρότερο χρόνο εκκίνησης. Πράγμα που τραβάει το ενδιαφέρον των
|
||
επιχειρήσεων διότι μεταφράζεται σε υψηλότερη αποδοτικότητα διακομιστών και
|
||
επομένως μειωμένα κόστη λειτουργίας.
|
||
|
||
\subsection{\textlatin{Application containerization}} \label{applicationContainerization}
|
||
|
||
Τα δοχεία ενθυλακώνουν μια εφαρμογή ως ένα αυτόνομο πακέτο που περιέχει τον
|
||
κώδικα, τις βιβλιοθήκες και τις εξαρτήσεις που χρειάζεται για να εκτελεστεί. Οι
|
||
εφαρμογές σε δοχεία θεωρούνται απομονωμένες με την έννοια ότι δεν έχουν ανάγκη
|
||
ένα αντίγραφο του λειτουργικού συστήματος αλλά αντ'' αυτού ένα
|
||
\textlatin{runtime engine} στο κύριο μηχάνημα που λειτουργεί ως διαμεσολαβητής
|
||
των δοχείων για να μοιράζονται το λειτουργικό σύστημα μεταξύ τους. Κοινές
|
||
βιβλιοθήκες ή εκτελέσιμα αρχεία μπορούν επίσης να μοιραστούν μεταξύ πολλών
|
||
δοχείων, συμβάλλοντας έτσι στην εξάλειψη περιττής υπολογιστικής ισχύος
|
||
καθιστώντας τα δοχεία μικρά στον χώρο που καταλαμβάνουν, γρήγορα στην εκκίνηση
|
||
και ικανά να εκτελεστούν σε οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους.
|
||
|
||
\pagebreak
|
||
|
||
\subsection{Πλεονεκτήματα \textlatin{containerization}} \label{containerizationAdvantages}
|
||
|
||
Τα δοχεία προσφέρουν μια σειρά από πλεονεκτήματα σε σχέση με τις παραδοσιακές
|
||
εικονικές μηχανές. Αυτά είναι μεταξύ άλλων τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Φορητότητα}:
|
||
|
||
Τα δοχεία είναι ανεξάρτητα από το λειτουργικό σύστημα και το περιβάλλον
|
||
εκτέλεσης τους και ως εκ τούτου μπορούν να εκτελεστούν σε οποιαδήποτε
|
||
πλατφόρμα ή περιβάλλον νέφους ομοιόμορφα και με συνέπεια. Το γεγονός
|
||
ότι τα κομμάτια ενός προγράμματος μπορούν να ορισθούν σε ένα μονάχα
|
||
αρχείο κειμένου και να κατασκευαστούν με αυτοματοποιημένο τρόπο
|
||
οπουδήποτε τους δίνει πολύ μεγαλύτερο προβάδισμα στον τομέα της
|
||
φορητότητας σε σχέση με τις εικονικές μηχανές.
|
||
|
||
\item \textbf{\textlatin{Agility}}:
|
||
|
||
Το \textlatin{Docker Engine} ξεκίνησε το βιομηχανικό πρότυπο για τη
|
||
χρήση δοχείων προσφέροντας απλά εργαλεία ανάπτυξης και μια καθολική
|
||
προσέγγιση πακεταρίσματος που λειτουργεί εξίσου καλά σε όλες τις
|
||
πλατφόρμες. Το οικοσύστημα των δοχείων έχει μετατοπιστεί σε μηχανές που
|
||
διαχειρίζεται η \textlatin{Open Container Initiative (OCI)} και οι
|
||
προγραμματιστές μπορούν εύκολα και γρήγορα να πακετάρουν τις εφαρμογές
|
||
τους ως δοχεία τα οποία μπορούν να προσφέρουν χωρίς την έγνοια
|
||
υποστήριξης πολλών διαφορετικών πλατφορμών.
|
||
|
||
\item \textbf{Ταχύτητα}:
|
||
|
||
Τα δοχεία είναι ελαφρύτερα από τις παραδοσιακές εικονικές μηχανές λόγω
|
||
του διαμοιρασμού του πυρήνα και γι'' αυτό έχουν μικρότερο χρόνο
|
||
εκκίνησης. Αυτό τα καθιστά ιδανικά για την ανάπτυξη και την εκτέλεση
|
||
εφαρμογών σε περιβάλλοντα νέφους όπου η αποδοτικότητα αξιοποίησης των
|
||
υπολογιστικών πόρων αντανακλάται σε άμεση εξοικονόμηση κόστους.
|
||
|
||
\item \textbf{Απομόνωση σφαλμάτων}:
|
||
|
||
Εφόσον κάθε δοχείο είναι απομονωμένο και λειτουργεί ανεξάρτητα από τα
|
||
υπόλοιπα, η αποτυχία του ενός δε θα επηρεάσει τη συνεχή λειτουργία των
|
||
υπολοίπων. Οι ομάδες ανάπτυξης λογισμικού μπορούν να εντοπίζουν και να
|
||
διορθώνουν τυχόν τεχνικά προβλήματα χωρίς να υπάρχει διακοπή
|
||
λειτουργίας σε άλλα δοχεία.
|
||
|
||
\item \textbf{Αποδοτικότητα}:
|
||
|
||
Το γεγονός ότι τα δοχεία μοιράζονται τον ίδιο πυρήνα και κοινά κομμάτια
|
||
άλλων δοχείων του συστήματος τα καθιστά αρκετά μικρά σε μέγεθος ώστε να
|
||
είναι δυνατόν να εκτελεστούν πολλά περισσότερα δοχεία απ'' ότι θα
|
||
μπορούσαν εικονικές μηχανές. Επομένως, αξιοποιούνται καλύτερα οι πόροι
|
||
του συστήματος.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{Ευκολία διαχείρισης}:
|
||
|
||
Τα δοχεία σε ένα σύστημα είναι εύκολα διαχειρίσιμα με απλές εντολές. Η
|
||
διαδικασία ενημέρωσης, εκκίνησης και τερματισμού τους μεταξύ άλλων
|
||
είναι γρήγορη και απλή. Ακόμα και για μια επιχείρηση με πολλούς
|
||
διακομιστές που θα έπρεπε να τα κάνει αυτά χειροκίνητα, υπάρχουν
|
||
πλατφόρμες ενορχήστρωσης δοχείων που πέραν αυτών των λειτουργιών
|
||
βοηθάνε και στην κλιμάκωση και διαχείριση του φόρτου εργασίας μεταξύ
|
||
δοχείων.
|
||
|
||
\item \textbf{Ασφάλεια}:
|
||
|
||
Η απομόνωση των εφαρμογών ως δοχεία εγγενώς αποτρέπει την εισβολή
|
||
κακόβουλου λογισμικού από το να επηρεάσει τα υπόλοιπα δοχεία ή το
|
||
σύστημα στο οποίο εκτελούνται. Επιπροσθέτως, άδειες ασφαλείας μπορούν
|
||
να ορισθούν με σκοπό τον αυτόματο αποκλεισμό ανεπιθύμητων στοιχείων από
|
||
τα δοχεία και τον περιορισμό επικοινωνίας μεταξύ δοχείων ή κομματιών
|
||
του συστήματος.
|
||
|
||
\end{itemize}
|
||
|
||
\subsection{Τύποι \textlatin{containerization}} \label{containerizationTypes}
|
||
|
||
Στην παράγραφο \ref{containerizationDefinition} αναφέραμε την έννοια
|
||
\textlatin{containerization}. Η ραγδαία αύξηση του ενδιαφέροντος και της χρήσης
|
||
δοχείων οδήγησε στην ανάγκη για πρότυπα γύρω από την τεχνολογία αυτή. Η
|
||
\textlatin{Open Container Initiative (OCI)} η οποία ιδρύθηκε τον Ιούνιο του
|
||
2015 από την \textlatin{Docker} και άλλους ηγέτες του κλάδου, προωθεί κοινά,
|
||
ανοικτά πρότυπα και προδιαγραφές γύρω από την τεχνολογία δοχείων. Εξαιτίας
|
||
αυτού, η \textlatin{OCI} συμβάλλει στη διεύρυνση των επιλογών για μηχανές
|
||
ανοιχτού κώδικα. Οι χρήστες δε θα είναι εγκλωβισμένοι στην τεχνολογία ενός
|
||
συγκεκριμένου προμηθευτή, αλλά θα μπορούν να επωφεληθούν από τις πιστοποιημένες
|
||
από την \textlatin{OCI} τεχνολογίες που θα τους επιτρέπουν να δημιουργούν
|
||
εφαρμογές σε δοχεία χρησιμοποιώντας ένα ευρύ σύνολο εργαλείων
|
||
\textlatin{DevOps} και να τις εκτελούν με τον ίδιο τρόπο σε οποιεσδήποτε
|
||
υποδομές της επιλογής τους.
|
||
|
||
Σήμερα αν και το \textlatin{Docker} αποτελεί μία από τις πιο γνωστές και ευρέως
|
||
χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες υλοποιήσεις.
|
||
Εναλλακτικές όπως το \textlatin{podman, LXC} και το \textlatin{containerd} που
|
||
ήταν για καιρό η προεπιλογή του \textlatin{Docker} για \textlatin{container
|
||
runtime} προτού υιοθετήσει το \textlatin{runC} μπορεί να έχουν διαφορετικά
|
||
χαρακτηριστικά και προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση των
|
||
προδιαγραφών της \textlatin{OCI} καθώς αυτές εξελίσσονται θα διασφαλίσει ότι οι
|
||
εναλλακτικές αυτές παραμένουν ανεξάρτητες από τους προμηθευτές, πιστοποιημένες
|
||
για να τρέχουν σε πολλαπλά λειτουργικά συστήματα και χρησιμοποιήσιμες σε
|
||
πολλαπλά περιβάλλοντα.
|
||
|
||
\subsection{Μερικές διαφορές σε υλοποιήσεις \textlatin{containerization}} \label{containerizationDifferences}
|
||
|
||
Παρότι οι προδιαγραφές της \textlatin{OCI} έχουν ως στόχο να διασφαλίσουν την
|
||
ομοιόμορφη λειτουργία της τεχνολογίας αυτής, υπάρχουν αρκετές διαφορές στην
|
||
υλοποίηση. Παραδείγματος χάριν, το \textlatin{podman} ενώ όπως το
|
||
\textlatin{Docker} συμμορφώνεται στις προδιαγραφές της \textlatin{OCI},
|
||
δουλεύει χωρίς δαίμονα από πίσω, πράγμα που επιδιώκει να κατευνάσει τις
|
||
ανησυχίες γύρω από τον τρόπο λειτουργίας του \textlatin{Docker}. Εξαιτίας του
|
||
τρόπου λειτουργίας του αν και από το 2021 χάρη στη δουλειά του
|
||
\textlatin{Akihiro Suda} \cite{AkihiroSuda} δεν ισχύει μόνο για αυτό πλεόν, το
|
||
\textlatin{podman} δύναται να εκτελεστεί από έναν χρήστη πέραν του
|
||
\textlatin{root}.
|
||
|
||
Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το \textlatin{podman}
|
||
είναι το \textlatin{rkt} το οποίο προσπαθούσε να κρατήσει μια προσέγγιση
|
||
ασφαλούς σχεδιασμού εξαρχής (\textlatin{Secure-by-design}). Μπορούσε να
|
||
ενσωματώσει χαρακτηριστικά ασφαλείας όπως υποστήριξη \textlatin{SELinux, TMP
|
||
measurement} και εκτέλεση δοχείων σε απομονωμένες από το υλικό εικονικές
|
||
μηχανές. Παρ'' όλα αυτά, σύμφωνα με το \cite{dockerAlternatives} έπαψε να έχει
|
||
ενεργή ανάπτυξη και επομένως δεν θα συνεχίζει να ανταγωνίζεται παρόμοια
|
||
εργαλεία στον κλάδο των δοχείων.
|
||
|
||
\subsection{Δοχεία έναντι εικονικών μηχανών} \label{containersVsVms}
|
||
|
||
Παρ'' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι
|
||
δύο αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην
|
||
παραδοσιακή εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μια
|
||
επιχείρησης είτε σε ένα περιβάλλον νέφους, ένας \textlatin{hypervisor} πρέπει
|
||
να χρησιμοποιηθεί για να εικονικοποιήσει φυσικό υλικό. Κάθε εικονική μηχανή
|
||
έχει ένα λειτουργικό σύστημα και ένα εικονικό αντίγραφο του υλικού που απαιτεί
|
||
για να εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της.
|
||
Από την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
|
||
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
|
||
βιβλιοθήκες και τις εξαρτήσεις της.
|
||
|
||
Η εικόνα \ref{fig:containerVsVm} παρουσιάζει τη διαφορά των δύο αρχιτεκτονικών
|
||
|
||
\begin{center}
|
||
\includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||
\captionof{figure}{\textlatin{Virtualization Vs Containers}}
|
||
\label{fig:containerVsVm}
|
||
\end{center}
|
||
|
||
Η απουσία του εικονικού λειτουργικού υλικού είναι που τα καθιστά γρήγορα,
|
||
φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά, σύμφωνα με
|
||
τη \textlatin{Red Hat} \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
|
||
μηχανών μετράται της τάξεως των \textlatin{gigabyte} ενώ των δοχείων μένουν στα
|
||
\textlatin{megabyte}. Πολλές φορές όπως αναφέρεται και στο
|
||
\cite{ibmContainerVsVm}, τα δοχεία χρησιμοποιούνται για εφαρμογές
|
||
αρχιτεκτονικής \textlatin{microservices} όπου κάθε ξεχωριστό κομμάτι
|
||
αντιπροσωπεύει μια λειτουργία της εφαρμογής και είναι ευκολότερη η κλιμάκωση
|
||
μιας υπηρεσίας απ'' ότι θα ήταν με μια \textlatin{monolithic} αρχιτεκτονική.
|
||
Εκεί λόγω μεγέθους και πλήθους τους συνήθως απαιτείται η χρήση πλατφόρμας
|
||
ενορχήστρωσης δοχείων όπως το \textlatin{Kubernetes}, το \textlatin{Docker
|
||
Swarm} ή άλλα για αποδοτικότερη διαχείριση.
|
||
|
||
Το μόνο μειονέκτημα τους, το οποίο δεν επηρεάζει κατά πολύ τη χρήση τους, είναι
|
||
το γεγονός ότι δοχεία που δημιουργήθηκαν για να εκτελούν προγράμματα που
|
||
απαιτούν την ύπαρξη του λειτουργικού συστήματος \textlatin{Windows} δε μπορούν
|
||
να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του \textlatin{Linux}.
|
||
|
||
\subsection{Ασφάλεια στο \textlatin{Docker}} \label{dockerSecurityMore}
|
||
|
||
Οι εφαρμογές σε δοχεία έχουν ένα εγγενές επίπεδο ασφαλείας αφού μπορούν να
|
||
εκτελούνται ως απομονωμένες διεργασίες και να λειτουργούν ανεξάρτητα από τα
|
||
υπόλοιπα δοχεία. Με πλήρη απομόνωση θα μπορούσε να αποτραπεί στην περίπτωση
|
||
μόλυνσης από κακόβουλο λογισμικό, ο κίνδυνος να επηρεαστούν άλλα δοχεία ή το
|
||
ίδιο το σύστημα. Ωστόσο, η απομόνωση τους δεν είναι πλήρης. Ο διαμοιρασμός
|
||
κομματιών μιας εφαρμογής σε δοχείο βοηθάει στην αποδοτικότητα του συστήματος
|
||
αλλά ανοίγει και ένα παράθυρο ευκαιρίας για επιθέσεις. Το γεγονός επίσης πως
|
||
μοιράζονται τον ίδιο πυρήνα σημαίνει πως μια επίθεση με στόχο αυτόν, μπορεί
|
||
δυνητικά να επηρεάσει όλα τα δοχεία.
|
||
|
||
Σχετικά με τις εικόνες δοχείων, τα κομμάτια δηλαδή από τα οποία μια εφαρμογή σε
|
||
μορφή δοχείου αποτελείται, η ασφάλεια δεν είναι πάντα εγγυημένη. Πρέπει να
|
||
ληφθούν μέτρα προστασίας όπως η χρήση εικόνων προερχόμενες μόνο από
|
||
εγκεκριμένες πηγές, κάτι που εισάγει ένα μοντέλο εμπιστοσύνης αυτή τη φορά
|
||
ανάμεσα στον προμηθευτή της και τον τελικό χρήστη. Οι πάροχοι τεχνολογίας
|
||
δοχείων έχουν αποκτήσει μια προσέγγιση ασφαλούς σχεδιασμού ώστε πολλά από τα
|
||
απαραίτητα μέτρα να είναι ενεργοποιημένα χωρίς την απαίτηση επιπρόσθετης
|
||
αλληλεπίδρασης από τον χρήστη. Πλέον η μηχανή δοχείων υποστηρίζει όλες τις
|
||
ιδιότητες απομόνωσης που υποστηρίζει και το λειτουργικό σύστημα στο οποίο
|
||
εκτελείται και άδειες ασφαλείας μπορούν να δοθούν με σκοπό τον επιπρόσθετο
|
||
περιορισμό χρήσης πόρων και το εύρος του συστήματος στο οποίο έχει πρόσβαση η
|
||
μηχανή δοχείων.
|
||
|
||
\subsubsection{\textlatin{Docker Attack Vector Mitigation Using Namespaces}} \label{dockerAttackVectorMitigation}
|
||
|
||
Με βάση το μοντέλο που περιγράφει το \cite{reshetova2014security} όπως
|
||
αναφέρεται στο \cite{bui2015analysis} όπου έχουμε ένα μηχάνημα στο οποίο
|
||
εκτελούνται διάφορα δοχεία, από τα οποία ένα υποσύνολο έχει τεθεί υπό τον
|
||
έλεγχο ενός κακόβουλου χρήστη. Για να προστατευτούμε από επιθέσεις, όπως άρνηση
|
||
υπηρεσίας και κλιμάκωση δικαιωμάτων πρέπει να πραγματοποιηθεί απομόνωση των
|
||
διεργασιών, αρχείων, της συσκευής, του \textlatin{IPC}, δικτύου και τέλος, των
|
||
πόρων.
|
||
|
||
Αυτά επιτυγχάνονται κατά σειρά με τη χρήση
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{\textlatin{namespaces}} όπου οριοθετείται η ορατότητα των
|
||
διεργασιών ανάμεσα στα δοχεία και το σύστημα όπως επίσης, τα δικαιώματά
|
||
τους.
|
||
|
||
\item \textbf{\textlatin{mount namespaces}}, με τα οποία οι διεργασίες κάθε
|
||
δοχείου βλέπουν διαφορετικά τη διάταξη των αρχείων του συστήματος. Όλες
|
||
οι δράσεις \textlatin{mount}, που γίνονται στο εκάστοτε δοχείο,
|
||
περιορίζονται σε αυτό όπως επίσης, οριοθετούνται τα δικαιώματα των
|
||
αρχείων του πυρήνα σε μονάχα ανάγνωσης και αποτρέπονται περαιτέρω
|
||
\textlatin{remountings}.
|
||
|
||
\item \textbf{\textlatin{Device Whitelist Controller}}, ενός
|
||
χαρακτηριστικού των \textlatin{cgroups} για περιορισμό συσκευών, που
|
||
αναφέρεται στο \cite{deviceWhitelistController} με τη βοήθεια του
|
||
οποίου περιορίζεται το σύνολο τον συσκευών στις οποίες έχει πρόσβαση
|
||
ένα δοχείο και το αποτρέπει από το να δημιουργήσει καινούριες
|
||
αναπαραστάσεις συσκευών. Επιπροσθέτως επειδή τα \textlatin{mount}
|
||
γίνονται με τη χρήση του \textlatin{nodev}, στην περίπτωση που μια
|
||
αναπαράσταση συσκευής είχε δημιουργηθεί σε προηγούμενο χρόνο του
|
||
στιγμιότυπου που χρησιμοποιήθηκε για να κατασκευαστεί το δοχείο, οι
|
||
διεργασίες του δε δύνανται να τη χρησιμοποιήσουν για να επικοινωνήσουν
|
||
με τον πυρήνα. Επιπλέον, επειδή η προεπιλεγμένη συνθήκη είναι να μη
|
||
δίνονται εκτεταμένα προνόμια σε ένα δοχείο, δεν υπάρχει πρόσβαση σε
|
||
καμία συσκευή παρά μόνο εάν γίνει εκτέλεση δοχείου ως χρήστης με
|
||
ανώτατα δικαιώματα όπου υπάρχει πρόσβαση σε όλες.
|
||
|
||
\item \textbf{\textlatin{IPC namespaces}} για περιορισμό \textlatin{IPC},
|
||
δηλαδή της επικοινωνίας των διεργασιών μεταξύ τους. Τα \textlatin{IPC
|
||
namespaces} καθιστούν δυνατή τη δημιουργία ξεχωριστών συνόλων των
|
||
διεργασιών, που επικοινωνούν μεταξύ τους αλλά όχι με άλλες διεργασίες
|
||
πέραν του υποσυνόλου.
|
||
|
||
\item \textbf{\textlatin{network namespaces}}. Μία από τις σημαντικότερες
|
||
απομονώσεις είναι αυτή του δικτύου. Χωρίς δικτυακή απομόνωση υπάρχει
|
||
κίνδυνος επιθέσεων όπως \textlatin{Man in the middle}, \textlatin{ARP,
|
||
DNS spoofing} και άλλες. Για να απομονωθεί η κίνηση δικτύου που
|
||
λαμβάνει μέρος σε ένα δοχείο από αυτήν των υπολοίπων και του συστήματος
|
||
πρέπει να γίνει χρήση των \textlatin{network namespaces}. Κάθε δοχείο
|
||
θα έχει δικές του διευθύνσεις \textlatin{IP}, συσκευές και ό,τι
|
||
χρειάζεται, προκειμένου να γίνεται αλληλεπίδραση μεταξύ των δοχείων
|
||
μέσω της διεπαφής δικτύου του καθενός σαν να είναι εξωτερικές
|
||
οντότητες.
|
||
|
||
\item \textbf{\textlatin{cgroup}}. Έπιβάλλεται η οριοθέτηση των
|
||
υπολογιστικών πόρων προκειμένου να αποφευχθεί μια επίθεση τύπου άρνησης
|
||
υπηρεσίας όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί να
|
||
καταναλώσει όλους τους πόρους του συστήματος. Με τη βοήθεια των
|
||
\textlatin{cgroup}, επιτυγχάνεται ο έλεγχος του ποσοστού πόρων όπως
|
||
\textlatin{CPU}, μνήμη, και χωρητικότητα που μπορεί να έχει κάθε δοχείο
|
||
στη διάθεση του.
|
||
|
||
\end{itemize}
|
||
|
||
Αυτές οι δυνατότητες υποστηρίζονται από το \textlatin{Docker} και μπορεί κανείς
|
||
να τις εκμεταλλευτεί για να προστατεύσει το περιβάλλον του από επιθέσεις.
|
||
Επιπλέον, υπάρχει και η δυνατότητα υποστήριξης \textlatin{Kernel Security
|
||
Modules} όπως \textlatin{SELinux} και \textlatin{Apparmor} αλλά και του
|
||
\textlatin{Seccomp} (στην περίπτωση χρήσης \textlatin{LXC}) όπως επίσης και
|
||
συμβατότητα με \textlatin{Linux capabilities} που θα μπορούσαν να εισάγουν ένα
|
||
ακόμα επίπεδο ασφαλείας αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα
|
||
των διεργασιών των δοχείων σε μονάχα όσα χρειάζονται. Το \textlatin{Docker}
|
||
παρέχει αρκετά υπάρχοντα μέσα άμυνας προκειμένου να προστατευτεί από επιθέσεις
|
||
ακόμα και χωρίς επιπρόσθετες ρυθμίσεις. Παρ'' όλα αυτά οι αρχικές ρυθμίσεις
|
||
ασφαλείας είναι πιο ελαστικές απ'' όσο χρειάζεται προκειμένου να συνεχίζει να
|
||
λειτουργεί κανονικά για όλους τους χρήστες, αφήνοντας έτσι τους διαχειριστές
|
||
ασφαλείας υπεύθυνους να χρησιμοποιήσουν όσες δυνατότητες είναι απαραίτητες
|
||
προκειμένου να ανταπεξέλθουν σε κάθε επίθεση ανάλογα το περιβάλλον και τις
|
||
ανάγκες τους.
|
||
|
||
\subsection{Συχνά είδη επιθέσεων σε δοχεία και μέθοδοι πρόληψης} \label{commonAttacksAndPrevention}
|
||
|
||
Μερικά είδη επιθέσεων και οι τρόποι αντιμετώπισης όπως αναφέρονται στο
|
||
\cite{yasrab2018mitigating} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{\textlatin{Kerner Exploits}}:
|
||
|
||
Ο πυρήνας είναι υπεύθυνος για τη διαχείριση των λειτουργιών και
|
||
διεργασιών των δοχείων. Λόγω του διαμοιρασμού του πυρήνα του συστήματος
|
||
με κάθε δοχείο το οποίο εκτελείται σε αυτό, εάν οποιοδήποτε από αυτά
|
||
τεθεί υπό τον έλεγχο ενός κακόβουλου χρήστη μπορεί δυνητικά να πάρει
|
||
τον έλεγχο του συστήματος και όλων των δοχείων αυτού. Ο τρόπος
|
||
αντιμετώπισης που προτείνεται είναι η χρήση \textlatin{SELinux} ή
|
||
\textlatin{Apparmor} κατά την εκτέλεση δοχείων σε συνδυασμό με
|
||
εκμετάλλευση των \textlatin{user namespaces}. Επιπλέον, συνίσταται να
|
||
μην εκτελούνται εφαρμογές με δικαιώματα διαχειριστικού λογαριασμού.
|
||
Μερικά ακόμα μέτρα προστασίας που μπορεί να παρθούν αλλά πιθανά να μην
|
||
είναι εφικτά γιατί ενδεχομένως να πηγαίνουν ενάντια στις λειτουργίες
|
||
του εκάστοτε δοχείου, είναι να τεθεί το σύστημα του σε επίπεδο
|
||
πρόσβασης που επιτρέπει μόνο την ανάγνωση των αρχείων, να
|
||
απενεργοποιηθεί η επικοινωνία μεταξύ δοχείων και να αποφευχθεί η
|
||
εγκατάσταση περιττών προγραμμάτων σε αυτά.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{Άρνηση υπηρεσίας}:
|
||
|
||
Μια από τις πιο συνηθισμένες επιθέσεις σε πόρους διαθέσιμους μέσω
|
||
δικτύου. Κατά τη διάρκεια μιας τέτοιας επίθεσης, μια διεργασία ή ένα
|
||
σύνολο διεργασιών επιχειρεί να καταναλώσει όλους τους πόρους του
|
||
συστήματος προκειμένου να μην μπορεί να εξυπηρετήσει άλλους χρήστες.
|
||
Αυτό μπορεί να συμβεί εάν ένα δοχείο βρεθεί υπό τον έλεγχο ενός
|
||
επιτιθέμενου και επιχειρήσει να διεκδικήσει πόρους που κανονικά δε
|
||
χρειάζεται. Για να ανταπεξέλθει ένα σύστημα σε μια επίθεση άρνησης
|
||
υπηρεσίας πρέπει να γίνει χρήση των δυνατοτήτων που αναφέραμε στο
|
||
\ref{dockerAttackVectorMitigation} με σκοπό τον αυστηρότερο έλεγχο
|
||
διαμοιρασμού των πόρων του συστήματος. Με τον ορισμό διαθέσιμων πόρων
|
||
για κάθε δοχείο εξαρχής δεν υπάρχει κίνδυνος να προσπαθήσει κανένα να
|
||
διεκδικήσει περισσότερους.
|
||
|
||
\item \textbf{\textlatin{Container Breakouts}}:
|
||
|
||
Σε τέτοιου είδους επιθέσεις ένας επιτιθέμενος προσπαθεί αφού απέκτησε
|
||
πρόσβαση σε ένα δοχείο, να αποκτήσει και μέσω αυτού στα αρχεία του
|
||
κύριου συστήματος. Αυτό μπορούσε να συμβεί με τη χρήση μιας συνάρτησης
|
||
που απαιτούσε δικαιώματα διαχειριστικού λογαριασμού μέσα από το δοχείο
|
||
προκειμένου να κάνει κλήση ενός \textlatin{capability} στο οποίο είχε
|
||
πρόσβαση εξαρχής. Σύμφωνα με το \textlatin{Docker} η μόνη έκδοση που
|
||
είχε αυτή την ευπάθεια ήταν η 0.11 και στην επόμενη διορθώθηκε. Για την
|
||
πρόληψη μελλοντικών μεθόδων διεκπεραίωσης τέτοιου είδους επίθεσης
|
||
συνίσταται να τίθενται τα δοχεία και οι αποθηκευτικοί τους χώροι σε
|
||
κατάσταση μονάχα ανάγνωσης όπως επίσης και να αποφεύγεται η χρήση της
|
||
παραμέτρου \textlatin{privileged}.
|
||
|
||
\item \textbf{Δηλητηριασμένες εικόνες δοχείων}:
|
||
|
||
Οι εικόνες δοχείων μπορεί να περιέχουν κακόβουλο λογισμικό ή λογισμικό
|
||
για το οποίο έχουν βρεθεί πλέον ευπάθειες. Ο τωρινός τρόπος ελέγχου
|
||
εγκυρότητας τους βασίζεται μονάχα στην παρουσία ενός υπογεγραμμένου
|
||
\textlatin{manifest} αλλά δε γίνεται ποτέ αυθεντικοποίηση του
|
||
\textlatin{checksum} της κάθε εικόνας. Αυτό αφήνει ανοιχτό το
|
||
ενδεχόμενο ένας επιτιθέμενος να διαδώσει οποιαδήποτε εικόνα μαζί με το
|
||
υπογεγραμμένο \textlatin{manifest} της. Επιβάλλεται οι χρήστες να
|
||
κατεβάζουν εικόνες από εγκεκριμένους προμηθευτές ή ακόμα και να τις
|
||
ελέγχουν με κατάλληλα εργαλεία προτού τις χρησιμοποιήσουν.
|
||
|
||
\pagebreak
|
||
|
||
\item \textbf{Απόκτηση μυστικών κωδικών/κλειδιών}:
|
||
|
||
Η απόκτηση επιχειρησιακών ή προσωπικών μυστικών ελοχεύει πολλούς
|
||
κινδύνους για μια επιχείρηση. Σε περίπτωση που κάτι τέτοιο συμβεί ένας
|
||
επιτιθέμενος μπορεί να έχει πρόσβαση σε βάσεις δεδομένων ή άλλα
|
||
κομμάτια του συστήματος απειλώντας έτσι την ακεραιότητα, την
|
||
εμπιστευτικότητα και διαθεσιμότητα των δεδομένων. Προκειμένου να
|
||
αποφευχθεί μια εισβολή σε κάποιο δοχείο που θα προκαλούσε την απόκτηση
|
||
τέτοιων μυστικών, καθίστατο επιτακτική η χρήση δοχείων σε κατάσταση
|
||
ανάγνωσης και όχι εγγραφής αλλά και η αποφυγή χρήσης μεταβλητών για την
|
||
αποθήκευση κωδικών. Χρήσιμη επίσης θα ήταν και η εσκεμμένη παράλειψη
|
||
της παραμέτρου \textlatin{privileged}.
|
||
|
||
\item \textbf{\textlatin{Man-in-the-Middle (MitM)}}:
|
||
|
||
Σε μια τέτοια επίθεση ένας κακόβουλος χρήστης προσπαθεί να μπει ανάμεσα
|
||
στην επικοινωνία δύο οντοτήτων με σκοπό να αλλοιώσει, να υποκλέψει ή να
|
||
παρακολουθεί πληροφορίες. Το καλύτερο αντίμετρο είναι η απομόνωση
|
||
δικτύου. Πρέπει να γίνει ρύθμιση των δοχείων με τέτοιο τρόπο ώστε να
|
||
μην έχουν πρόσβαση στη δικτυακή επικοινωνία του κύριου μηχανήματος ή
|
||
άλλων δοχείων.
|
||
|
||
\item \textbf{\textlatin{ARP spoofing}}:
|
||
|
||
Σε μια \textlatin{Address Resource Protocol spoofing} επίθεση, ο
|
||
επιτιθέμενος επιχειρεί να \mbox{στείλει} ψεύτικα \textlatin{ARP}
|
||
μηνύματα σε ένα \textlatin{LAN}. Είναι πιθανό να προσποιηθεί πως η
|
||
συσκευή του είναι μια από τις συσκευές της επιχείρησης αλλάζοντας τη
|
||
\textlatin{MAC} διεύθυνση του στην \textlatin{IP} μιας συσκευής που το
|
||
σύστημα αναγνωρίζει. Επομένως, θα του συμπεριφέρεται όπως θα έκανε
|
||
κανονικά. Στέλνοντας σε αυτόν όλα τα πακέτα και τα δεδομένα που
|
||
προορίζονταν για την αληθινή συσκευή. Το \textlatin{Docker}
|
||
χρησιμοποιεί το \textlatin{ARP} για να κάνει την αντιστοίχιση
|
||
\textlatin{IPv4} σε \textlatin{MAC} διευθύνσεις οι οποίες
|
||
χρησιμοποιούνται από την εικονική γέφυρα δικτύου για να διανέμουν σωστά
|
||
τα \textlatin{Ethernet frames} αφού δεν υπάρχει φίλτρο για τα πακέτα
|
||
\textlatin{ARP} και επομένως κανένας μηχανισμός άμυνας. Γι'' αυτό τον
|
||
λόγο τα δοχεία μπορούν να προσποιηθούν ότι είναι άλλα δοχεία ή ακόμα
|
||
και το κύριο σύστημα. Στην περίπτωση παραβίασης ενός δοχείου υπάρχει
|
||
κίνδυνος ο επιτιθέμενος να υποκλέψει μυστικά της επιχείρησης ή των
|
||
τελικών χρηστών της υπηρεσίας που προσφέρει. Ένας από τους τρόπους για
|
||
την αποφυγή τέτοιας επίθεσης είναι η εκτέλεση δοχείων δίχως το
|
||
\textlatin{NET\_RAW capability} αφού έτσι τα προγράμματα μέσα στο
|
||
δοχείο δε θα μπορούν να δημιουργήσουν \textlatin{PF\_PACKET sockets}
|
||
και θα ήταν αδύνατη η διεκπεραίωση της επίθεσης. Βέβαια, αυτή η μέθοδος
|
||
έχει μειονεκτήματα αφού μπορεί αυτό το \textlatin{capability} να ήταν
|
||
άκρως απαραίτητο για την ορθή λειτουργία της υπηρεσίας. Επομένως, μια
|
||
ακόμα μέθοδος είναι η χρήση ````\textlatin{ebtables}'''' για
|
||
φιλτράρισμα \textlatin{Ethernet frames} ούτως ώστε \textlatin{ARP}
|
||
πακέτα με λάθος πρωτόκολλο αποστολέα ή διεύθυνση \textlatin{MAC} να
|
||
ανιχνεύονται εγκαίρως και να απορρίπτονται.
|
||
|
||
\end{itemize}
|