2448 lines
226 KiB
TeX
2448 lines
226 KiB
TeX
\chapter{Υπόβαθρο} \label{background}
|
||
|
||
\hyphenation{πολλές μελών/οργανισμών ανάπτυξης}
|
||
|
||
\noindent Προκειμένου να κατανοήσουμε πλήρως το πρόβλημα που επιλύει η παρούσα
|
||
εργασία πρέπει να αναλύσουμε μερικές βασικές έννοιες. Αρχικά, θα δούμε τι είναι
|
||
το υπολογιστικό νέφος, τι μας προσφέρει, ποια είναι τα μοντέλα ανάπτυξής του
|
||
και ποια μοντέλα παράδοσης παρέχονται μέσω αυτού. Έπειτα, θα συζητήσουμε την
|
||
έννοια της εικονικοποίησης και τις διάφορες υποκατηγορίες της που
|
||
χρησιμοποιούνται στις μέρες μας. Αμέσως μετά, θα αναλυθούν τα πλεονεκτήματα της
|
||
εικονικοποίησης και θα αναδειχθεί ο λόγος που προτιμάται η εικονικοποίηση του
|
||
λειτουργικού συστήματος (δηλ. η χρήση δοχειοποιημένων περιβαλλόντων). Τέλος, θα
|
||
εμβαθύνουμε στην τεχνολογία δοχείων, θα δούμε διάφορες υλοποιήσεις της και θα
|
||
πραγματοποιήσουμε μια ανάλυση της ασφάλειας του Docker, ως το de facto
|
||
βιομηχανικό πρότυπο για την διαχείριση των δοχείων και των εικόνων τους στα
|
||
πλαίσια δοχειοποιημένων εφαρμογών.
|
||
|
||
\section{Νεφο-υπολογιστική} \label{cloudComputing}
|
||
|
||
Με τον όρο νεφο-υπολογιστική (Cloud Computing), αναφερόμαστε σε ένα μοντέλο
|
||
παράδοσης υπολογιστικών πόρων κατά παραγγελία από μια επιχείρηση προς τους
|
||
καταναλωτές της. Οι υπηρεσίες που προσφέρει ένα υπολογιστικό νέφος χωρίζονται
|
||
σε τρεις κατηγορίες - αυτές οι κατηγορίες αναφέρονται και ως μοντέλα παράδοσης
|
||
του νέφους. Η πρώτη, SaaS (Software as a Service) (Λογισμικό ως Υπηρεσία),
|
||
αναφέρεται στην απομακρυσμένη διάθεση λογισμικού, του οποίου η συμμόρφωση με
|
||
τις λειτουργικές και μη λειτουργικές του ικανότητες που διαφημίζονται προς τους
|
||
πελάτες αποτελεί ευθύνη του παρόχου του. Η κατηγορία PaaS (Platform as a
|
||
Service) (Πλατφόρμα ως Υπηρεσία) ορίζεται ως η διάθεση απομακρυσμένης
|
||
πλατφόρμας με την οποία μια ομάδα έργου μπορεί να αναπτύξει συνεργατικά και να
|
||
εκτελέσει λογισμικό. Τέλος, η κατηγορία IaaS (Infrastructure as a Service)
|
||
μεταφράζεται ως η προσφορά απομακρυσμένων (εικονικών και φυσικών) διακομιστών
|
||
τους οποίους μια επιχείρηση μπορεί να αξιοποιήσει αναλόγως τις ανάγκες της
|
||
(π.χ. ως προς την φιλοξενία κατάλληλων φόρτων εργασίας) ακολουθώντας φυσικά
|
||
τους όρους και προϋποθέσεις του παρόχου. Τα πλεονεκτήματα που παρέχει η
|
||
νεφο-υπολογιστική σε σχέση με την παραδοσιακή μέθοδο διάθεσης υπηρεσιών είναι
|
||
αρκετά αλλά αυτά που ξεχωρίζουν από μεριάς των πελατών είναι η απόλυτη απαλλαγή
|
||
ευθύνης των υποδομών νέφους, η απαράμιλλη ταχύτητα διάθεσης και κλιμάκωσης των
|
||
υπηρεσιών και η εξάλειψη περιττού κόστους λόγω του ευέλικτου μοντέλου χρέωσης
|
||
όπου προσμετρώνται μόνο οι πόροι που χρησιμοποιήθηκαν.
|
||
|
||
Σημαντικό ρόλο στην ευρεία αποδοχή των υπηρεσιών που προσφέρονται μέσω της
|
||
νεφο-υπολογιστικής έχει η ευκολία αλλά και ευελιξία των μεθόδων διάθεσης και
|
||
μετέπειτα διαχείρισής τους. Σε κάθε περίπτωση γίνεται χρήση ενός API
|
||
(Application Programming Interface) (Προγραμματιστική Διεπαφή Εφαρμογής), το
|
||
οποίο είναι προσπελάσιμο έμμεσα μέσω ενός γραφικού περιβάλλοντος (self-service
|
||
portal) ή ενός εργαλείου γραμμής εντολών (command line tool) ή άμεσα με
|
||
προγραμματιστικό τρόπο (π.χ. με τη χρήση SDKs (Software Development Kits) (Κιτ
|
||
Ανάπτυξης Λογισμικού)).
|
||
|
||
\subsection{Ορισμός Νεφο-Υπολογιστικής} \label{cloudComputingDefinition}
|
||
|
||
Σύμφωνα με το \citetitle{mell2011nist} \cite{mell2011nist}, η νεφο-υπολογιστική
|
||
είναι ένα μοντέλο που επιτρέπει την ανά πάσα στιγμή διαδικτυακή πρόσβαση από
|
||
οπουδήποτε σε μια κοινή δεξαμενή ρυθμιζόμενων υπολογιστικών πόρων που μπορούν
|
||
να παρέχονται και να απελευθερώνονται γρήγορα και με ελάχιστη προσπάθεια
|
||
διαχείρισης ή αλληλεπίδρασης με τον πάροχο υπηρεσιών. Στους υπολογιστικούς
|
||
αυτούς πόρους περιλαμβάνονται δίκτυα, διακομιστές, χώρος αποθήκευσης, εφαρμογές
|
||
και υπηρεσίες. Αυτό το μοντέλο νέφους αποτελείται από πέντε βασικά
|
||
χαρακτηριστικά, τρία μοντέλα υπηρεσιών (ή μοντέλα παράδοσης) και τέσσερα
|
||
μοντέλα ανάπτυξης.
|
||
|
||
\subsection{Χαρακτηριστικά} \label{cloucComputingCharacteristics}
|
||
|
||
Τα πέντε βασικά χαρακτηριστικά της νεφο-υπολογιστικής με βάση τους
|
||
\textcite{mell2011nist} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Αυτοεξυπηρέτηση κατά παραγγελία (On-demand Self-service)}:
|
||
|
||
Ένας καταναλωτής μπορεί να προμηθευτεί υπολογιστικούς πόρους, όπως
|
||
αποθηκευτικό χώρο και ισχυρούς επεξεργαστές, κατά απαίτηση δίχως την
|
||
ανάγκη αλληλεπίδρασης με τον αντίστοιχο πάροχο νέφους. Μόλις
|
||
συγκροτηθούν, η χρήση των πόρων αυτών μπορεί να αυτοματοποιηθεί,
|
||
οδηγώντας σε ένα περιβάλλον αυτοεξυπηρέτησης κατ' απαίτηση.
|
||
|
||
\item \textbf{Πανταχού παρούσα πρόσβαση (Ubiquitous Access)}:
|
||
|
||
Οι υπηρεσίες που παρέχονται είναι διαθέσιμες μέσω του διαδικτύου και
|
||
είναι προσβάσιμες μέσω πρότυπων μηχανισμών από ετερογενείς πλατφόρμες
|
||
λεπτών και πυκνών πελατών (thin \& thick clients).
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Πολλαπλή Μίσθωση (Multi-Tenancy)}:
|
||
|
||
Οι υπολογιστικοί πόροι του παρόχου είναι σχεδιασμένοι με τέτοιο τρόπο
|
||
ώστε να μπορούν να εξυπηρετήσουν πολλούς καταναλωτές έκαστος,
|
||
χρησιμοποιώντας ένα μοντέλο πολλαπλής μίσθωσης (multi-tenant model) με
|
||
διαφορετικούς φυσικούς και εικονικούς πόρους που εκχωρούνται και
|
||
ανακατανέμονται ανάλογα με τη ζήτηση των καταναλωτών. Το μοντέλο αυτό
|
||
διακατέχεται και από μια αίσθηση ανεξαρτησίας θέσης διότι ανεξάρτητα
|
||
από το που βρίσκεται ένας τελικός χρήστης μπορεί να χρησιμοποιήσει
|
||
πόρους από οποιοδήποτε κέντρο δεδομένων επιθυμεί. Παραδείγματα πόρων
|
||
που παρέχονται αποτελούν μεταξύ άλλων το εύρος ζώνης δικτύου (network
|
||
bandwidth), ο αποθηκευτικός χώρος και οι εικονικές μηχανές.
|
||
|
||
\item \textbf{Ελαστικότητα (Elasticity)}:
|
||
|
||
Οι υπολογιστικές, δικτυακές και αποθηκευτικές δυνατότητες μπορούν να
|
||
παρέχονται και να απελευθερώνονται ελαστικά (αυτόματα) με σκοπό την
|
||
οριζόντια ή κάθετη κλιμάκωση υπηρεσιών αναλόγως την παρούσα ζήτηση. Από
|
||
την οπτική γωνία του καταναλωτή, οι παρεχόμενες δυνατότητες μοιάζουν
|
||
απεριόριστες και μπορούν να κατανεμηθούν ανά πάσα στιγμή σε οποιαδήποτε
|
||
ποσότητα.
|
||
|
||
\item \textbf{Μετρούμενη υπηρεσία (Measured Service)}:
|
||
|
||
Τα συστήματα νέφους ελέγχουν και βελτιστοποιούν αυτόματα τη χρήση των
|
||
πόρων, αξιοποιώντας δυνατότητες μέτρησης/παρακολούθησης κατάλληλες για
|
||
τον τύπο της υπηρεσίας (π.χ. αποθήκευση, επεξεργασία, εύρος ζώνης). Η
|
||
χρήση των πόρων μπορεί να παρακολουθείται, να ελέγχεται και να
|
||
καταγράφεται, παρέχοντας διαφάνεια τόσο στον πάροχο όσο και στον
|
||
καταναλωτή της υπηρεσίας που χρησιμοποιείται. Η καταγραφόμενη χρήση
|
||
έπειτα χρησιμοποιείται για την χρέωση του καταναλωτή ανάλογα με το
|
||
μοντέλο χρέωσης που σχετίζεται με την χρησιμοποιούμενη υπηρεσία.
|
||
|
||
\end{itemize}
|
||
|
||
\clearpage
|
||
|
||
\subsection{Μοντέλα Υπηρεσιών/Παράδοσης} \label{cloudComputingServiceModels}
|
||
|
||
Τα τρία μοντέλα υπηρεσιών ή παράδοσης της νεφο-υπολογιστικής, όπως αυτά
|
||
αναγράφονται στο \cite{mell2011nist}, είναι τα παρακάτω:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Software as a Service (SaaS) (Λογισμικό ως Υπηρεσία)}:
|
||
|
||
Παρέχεται στον καταναλωτή η δυνατότητα χρήσης εφαρμογών εκτελούμενων σε
|
||
μια υποδομή νέφους, οι οποίες προσφέρονται είτε από τον πάροχο της
|
||
υποδομής είτε από τρίτο μέρος. Οι εφαρμογές αυτές είναι προσβάσιμες,
|
||
από διάφορες συσκευές ικανές να συνδεθούν στο διαδίκτυο, μέσω
|
||
φυλλομετρητή ή προγραμματιστικής διεπαφής. Δεν προσφέρεται έλεγχος ή
|
||
δυνατότητα διαχείρισης της υποκείμενης υποδομής νέφους ή των
|
||
δυνατοτήτων της υπηρεσίας (λογισμικού), με εξαίρεση περιορισμένη
|
||
παραμετροποίηση κάποιων ρυθμίσεων διαμόρφωσης της εφαρμογής. Το μοντέλο
|
||
χρέωσης είθισται να είναι της μορφής μιας σταθερής μηνιαίας ή ετήσιας
|
||
συνδρομής χρησιμοποιώντας βαθμίδες με διαφορετικά επίπεδα παροχής
|
||
υπηρεσιών του λογισμικού \cite{saasPricingModel}.
|
||
|
||
\item \textbf{Platform as a Service (PaaS) (Πλατφόρμα ως Υπηρεσία)}:
|
||
|
||
Παρέχεται η δυνατότητα ανάπτυξης και εκτέλεσης εφαρμογών σε ένα
|
||
κατάλληλο περιβάλλον παρεχόμενο από μια πλατφόρμα που υποστηρίζεται από
|
||
πόρους του υπολογιστικού νέφους. Οι εφαρμογές αυτές αναπτύσσονται από
|
||
τον καταναλωτή μέσω της πλατφόρμας χρησιμοποιώντας ένα ολοκληρωμένο
|
||
περιβάλλον ανάπτυξης και εκτέλεσης αποτελούμενο από runtimes γλωσσών
|
||
προγραμματισμού, βιβλιοθήκες, υπηρεσίες και εργαλεία ανάπτυξης. Ο
|
||
καταναλωτής δεν έχει τον έλεγχο της υποκείμενης υποδομής νέφους, αλλά
|
||
έχει τον έλεγχο των εφαρμογών που εκτελούνται σε αυτήν, των δεδομένων
|
||
τους, καθώς και των ρυθμίσεων διαμόρφωσής τους και του περιβάλλοντος
|
||
ανάπτυξης/εκτέλεσής τους. Συνήθως, τα περιβάλλοντα είναι προκαθορισμένα
|
||
ως προς το περιεχόμενο τους. Όμως, γίνεται προσπάθεια από τους παρόχους
|
||
των υπηρεσιών PaaS να καλύψουν τις ανάγκες όλων των πιθανών ομάδων
|
||
έργων λογισμικού παρέχοντας μια μεγάλη ποικιλία από διαφορετικά
|
||
περιβάλλοντα. Το μοντέλο χρέωσης υπηρεσιών PaaS συνήθως περιλαμβάνει
|
||
μια σταθερή χρέωση ανά χρονική περίοδο για κάθε είδος πόρου που
|
||
χρειάστηκε να χρησιμοποιηθεί από τον πάροχο για την επίτευξη των
|
||
απαιτήσεων της εφαρμογής του καταναλωτή μέσω της παρεχόμενης πλατφόρμας
|
||
\cite{paasPricingModel}. Ουσιαστικά, ο καταναλωτής χρεώνεται με βάση
|
||
την χρήση των πόρων του παρόχου.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Infrastructure as a Service (IaaS) (Υποδομή ως Υπηρεσία)}:
|
||
|
||
Παρέχεται η δυνατότητα χρήσης επεξεργαστικών, αποθηκευτικών, δικτυακών
|
||
και άλλων ειδών υπολογιστικών πόρων. Συνήθως, οι πόροι αυτοί
|
||
συγκροτούνται στην μορφή μιας εικονικής μηχανής, δηλ. ενός
|
||
απογυμνωμένου περιβάλλοντος στο οποίο ο καταναλωτής μπορεί να
|
||
εγκαταστήσει και να εκτελέσει το λογισμικό της επιλογής του,
|
||
συμπεριλαμβανομένων λειτουργικών συστημάτων και εφαρμογών. Ο
|
||
καταναλωτής δεν έχει τον έλεγχο της υποκείμενης υποδομής νέφους, αλλά
|
||
έχει τον έλεγχο των λειτουργικών συστημάτων, του αποθηκευτικού χώρου,
|
||
των περιβαλλόντων ανάπτυξης/εκτέλεσης, των εγκατεστημένων εφαρμογών,
|
||
των δεδομένων τους και των ρυθμίσεων διαμόρφωσής τους. Το μοντέλο
|
||
χρέωσης υπηρεσιών IaaS συνήθως αποτελείται από μια συνεχόμενη χρέωση
|
||
ανά χρονική περίοδο λόγω της ανάθεσης των πόρων στον καταναλωτή, η
|
||
οποία αυξάνεται μετά την υπέρβαση ενός ορίου χρήσης για ορισμένους
|
||
πόρους, όπως το εύρος ζώνης δικτύου.
|
||
|
||
\end{itemize}
|
||
|
||
\subsection{Μοντέλα Ανάπτυξης} \label{cloudComputingDeploymentModels}
|
||
|
||
Τα τέσσερα μοντέλα ανάπτυξης του υπολογιστικού νέφους σύμφωνα με το
|
||
\cite{mell2011nist} και την \citeauthor{cloudDeploymentModels}
|
||
\cite{cloudDeploymentModels} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Ιδιωτικό νέφος (Private Cloud)}:
|
||
|
||
Το ιδιωτικό νέφος είναι αποκλειστικά αφιερωμένο σε έναν μόνο οργανισμό
|
||
αποτελούμενο από πολλαπλούς καταναλωτές (π.χ. επιχειρησιακές μονάδες ή
|
||
τμήματα). Ενδεχομένως να ανήκει, να διαχειρίζεται και να λειτουργεί από
|
||
τον ίδιο τον οργανισμό, από μια τρίτη οντότητα, ή έναν συνδυασμό των
|
||
δύο. Το νέφος αυτό μπορεί να βρίσκεται εντός ή εκτός του οργανισμού
|
||
(π.χ. στην περίπτωση που λειτουργεί από τρίτη οντότητα). Παρέχει πλήρη
|
||
έλεγχο στον τρόπο με τον οποίο μοιράζονται και αποθηκεύονται τα
|
||
δεδομένα και διασφαλίζει την συμμόρφωση με τυχόν κανονισμούς, τους
|
||
οποίους καλείται ένας οργανισμός να ακολουθήσει. Επιπλέον, λόγω της
|
||
αποκλειστικής αφιέρωσής του σε έναν μόνο οργανισμό, εξασφαλίζεται η
|
||
διαθεσιμότητα των δεδομένων κατά παραγγελία, όπως επίσης και η
|
||
αξιοπιστία του για κρίσιμους φόρτους εργασίας. Τέλος, λόγω του πλήρους
|
||
ελέγχου, μπορεί να εγκαθιδρυθεί ένα υψηλό επίπεδο ασφαλείας, υψηλότερο
|
||
σε σχέση με αυτό που μπορεί να επιτευχθεί από άλλα μοντέλα ανάπτυξης
|
||
(νέφους).
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Κοινοτικό νέφος (Community Cloud)}:
|
||
|
||
Είναι διαθέσιμο για μια κοινότητα καταναλωτών ή οργανισμών με κοινές
|
||
ανησυχίες, όπως οι απαιτήσεις ασφαλείας και ζητήματα πολιτικής και
|
||
συμμόρφωσης. Μπορεί να ανήκει, να διαχειρίζεται και να λειτουργεί από
|
||
έναν ή περισσότερους οργανισμούς της κοινότητας, μια τρίτη οντότητα ή
|
||
έναν συνδυασμό των δύο. Το νέφος αυτό μπορεί να βρίσκεται εντός ή εκτός
|
||
των οργανισμών της κοινότητας (εφόσον λειτουργεί από ένα τρίτο μέρος).
|
||
Το κόστος κτήσης, λειτουργίας και συντήρησης του νέφους συνήθως
|
||
διαμοιράζεται μεταξύ των μελών/οργανισμών της κοινότητας. Επιπροσθέτως,
|
||
το νέφος αυτού του είδους είναι προσβάσιμο συνήθως μόνο από τα μέλη της
|
||
κοινότητας. Οπότε, μπορεί να θεωρηθεί ένα ιδιωτικό νέφος, όμως όχι μόνο
|
||
για έναν αλλά για πολλαπλούς οργανισμούς. Το επίπεδο ασφάλειας που
|
||
μπορεί να επιτευχθεί σε αυτό το είδος νέφους είναι υψηλότερο από το
|
||
δημόσιο νέφος και χαμηλότερο από το ιδιωτικό.
|
||
|
||
\item \textbf{Δημόσιο νέφος (Public Cloud)}:
|
||
|
||
Εδώ, το νέφος υποδομής είναι διαθέσιμο για το γενικό κοινό. Μπορεί να
|
||
ανήκει και να διαχειρίζεται από μια επιχείρηση, έναν ακαδημαϊκό ή
|
||
κυβερνητικό οργανισμό ή έναν συνδυασμό των παραπάνω. Λειτουργεί εντός
|
||
των υποδομών του παρόχου νέφους. Το δημόσιο νέφος προσφέρει είτε
|
||
εικονικές μηχανές που εκτελούνται σε (φυσικούς) διακομιστές του παρόχου
|
||
νέφους, των οποίων οι υπολογιστικοί πόροι χρησιμοποιούνται από πολλούς
|
||
καταναλωτές ταυτόχρονα, είτε τους φυσικούς του διακομιστές για
|
||
αποκλειστική χρήση. Αποτελεί το πιο δημοφιλές μοντέλο ανάπτυξης που
|
||
επιλέγουν εταιρείες για παροχή υπηρεσιών, λόγω της απουσίας απαίτησης
|
||
μεγάλου αρχικού κόστους επένδυσης και της ευελιξίας που παρέχεται μέσω
|
||
της αυτοεξυπηρέτησης κατά παραγγελία. Αποτελεί κατάλληλη επιλογή για
|
||
μεγάλους φόρτους εργασίας μικρής διάρκειας λόγω του μοντέλου χρέωσης
|
||
ανά χρήση, ενώ διευκολύνει μια επιχείρηση στην μετέπειτα διαχείριση του
|
||
κόστους με βάση τις προβλέψεις της ζήτησης της υπηρεσίας που αυτή
|
||
προσφέρει και των δυνατοτήτων κλιμάκωσης υπηρεσιών που το νέφος παρέχει
|
||
σε αυτήν. Όμως, το επίπεδο ασφάλειας του δημοσίου νέφους είναι το
|
||
χαμηλότερο σε σχέση με τα άλλα 3 είδη νέφους.
|
||
|
||
\item \textbf{Υβριδικό νέφος (Hybrid Cloud)}:
|
||
|
||
Είναι συνδυασμός δύο ή περισσότερων νεφών (ιδιωτικού, κοινοτικού ή
|
||
δημοσίου) που διατηρούνται ως ξεχωριστές οντότητες αλλά συνδέονται
|
||
μεταξύ τους με πρότυπες ή ιδιόκτητες τεχνολογίες που επιτρέπουν τη
|
||
φορητότητα δεδομένων και εφαρμογών. Η πιο συνηθισμένη μορφή ενός
|
||
υβριδικού νέφους αντιστοιχεί στη χρήση ενός ιδιωτικού νέφους, το οποίο
|
||
μπορεί να αντλεί επιπλέον πόρους από το δημόσιο νέφος, όταν φθάνει στα
|
||
όρια της χωρητικότητάς του.
|
||
|
||
\end{itemize}
|
||
|
||
\section{Εικονικοποίηση} \label{virtualization}
|
||
|
||
Η εικονικοποίηση (virtualization) είναι ένας όρος που χρησιμοποιούμε όταν
|
||
θέλουμε να αναφερθούμε στην αναπαράσταση πόρων σε εικονική μορφή με σκοπό την
|
||
αναδιαμόρφωσή τους ούτως ώστε να ικανοποιούνται οι ανάγκες ενός συστήματος
|
||
(όπως η αύξηση της χρήσης των φυσικών του πόρων). Εφαρμόζεται σε μια πληθώρα
|
||
πόρων, όπως είναι οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα
|
||
δεδομένα. Μπορεί επομένως να χωριστεί σε εικονικοποίηση φυσικών (υπολογιστικών
|
||
ή μη) πόρων ή λογισμικού.
|
||
|
||
Η πιο συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η οποία
|
||
αποτελεί και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να επιτευχθεί,
|
||
απαιτείται η χρήση ενός υπερ-επόπτη. Δηλαδή, ενός λογισμικού υπεύθυνου για την
|
||
κατάτμηση των φυσικών πόρων ενός διακομιστή σε μια ή περισσότερες εικονικές
|
||
αναπαραστάσεις ενός συνόλου αυτών με σκοπό να χρησιμοποιηθούν ως ξεχωριστοί
|
||
εικονικοί διακομιστές (virtual hosts/servers) (οι κοινώς λεγόμενες εικονικές
|
||
μηχανές).
|
||
|
||
Ένας υπερ-επόπτης μπορεί να ανήκει σε δύο αποκλειστικές κατηγορίες. Είτε
|
||
πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης με το
|
||
υλικό, είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον
|
||
υποκείμενο (φυσικό) διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη
|
||
είναι άμεσα εξαρτώμενη από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η
|
||
υψηλή ταχύτητα και απόδοση είναι σημαντικές μη λειτουργικές απαιτήσεις, η άμεση
|
||
πρόσβαση του υπερ-επόπτη τύπου 1 στο υλικό συμβάλλει στην επίτευξη της
|
||
ικανοποίησης αυτών των δύο απαιτήσεων. Από την άλλη, ένας υπερ-επόπτης τύπου 2
|
||
δεν έρχεται σε αντιπαράθεση με το υποκείμενο ΛΣ και επιτρέπει την χρήση
|
||
προγραμμάτων και οδηγών που το ΛΣ αυτό πιθανόν να μην είναι σε θέση να
|
||
εκτελέσει.
|
||
|
||
Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
|
||
επίτευξής της: την πλήρη εικονικοποίηση (full virtualization) και την
|
||
παρα-εικονικοποίηση \cite{abacusFullParaOSVirtualization} (paravirtualization).
|
||
Στην πρώτη περίπτωση το λειτουργικό σύστημα που εκτελείται στον εικονικό
|
||
διακομιστή συμπεριφέρεται όπως θα συμπεριφερόταν σε έναν φυσικό διακομιστή.
|
||
Αυτό συμβαίνει διότι από μεριάς του λειτουργικού συστήματος δεν υπάρχει
|
||
επίγνωση της εικονικοποίησης που έχει λάβει μέρος για να δημιουργηθούν οι
|
||
εικονικοί πόροι στους οποίους στεγάζεται. Η πλήρης εικονικοποίηση μπορεί να
|
||
είναι δύο ειδών: υποβοηθούμενη από το λογισμικό (software-assisted) ή από το
|
||
υλικό (hardware assisted). Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση
|
||
ολόκληρου του υλικού μέσω του υπερ-επόπτη (τύπου 2) που εκτελείται στο ΛΣ. Στο
|
||
δεύτερο είδος, όπου δεν υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του
|
||
εικονικού διακομιστή να κάνει χρήση της φυσικής κεντρικής μονάδας επεξεργασίας
|
||
του διακομιστή φιλοξενίας εάν αυτή το υποστηρίζει
|
||
\cite{geeksforgeeksHardwareAssistedVirtualization}.
|
||
|
||
Στην περίπτωση της παρα-εικονικοποίησης το φιλοξενούμενο λειτουργικό σύστημα
|
||
αναγνωρίζει την ύπαρξη του υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο
|
||
ώστε να μπορούν να επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό
|
||
μειώνει την συμβατότητα σε σχέση με την πλήρη εικονικοποίηση, η άμεση πρόσβαση
|
||
στο υποκείμενο φυσικό υλικό συμβάλλει στην αύξηση της αποδοτικότητας - αυτό
|
||
επιτυγχάνεται κυρίως για ορισμένα είδη πόρων.
|
||
|
||
Σχετικά με την εικονικοποίηση λογισμικού, η πιο συνηθισμένη χρήση της είναι η
|
||
εικονικοποίηση ΛΣ όπου τότε αναφερόμαστε στην δοχειοποίηση. Κατά την
|
||
δοχειοποίηση, ενθυλακώνεται ένα πρόγραμμα εξ ολοκλήρου σε ένα εικονικό
|
||
περιβάλλον που ονομάζεται δοχείο. Έπειτα, το δοχείο αυτό εκτελείται ως
|
||
διεργασία του ΛΣ και μοιράζεται τους υποκείμενους πόρους του συστήματος με τα
|
||
υπόλοιπα δοχεία και τα λοιπά προγράμματα που μπορεί να εκτελούνται στο σύστημα
|
||
αυτό. Περισσότερες λεπτομέρειες για την δοχειοποίηση, αναφέρονται και στην
|
||
Ενότητα \ref{containersAndContainerization}.
|
||
|
||
\clearpage
|
||
|
||
\subsection{Είδη εικονικοποίησης} \label{virtualizationImplementations}
|
||
|
||
Υπάρχουν πολλά είδη εικονικοποίησης. Πέντε βασικά αυτών, όπως αναφέρονται από
|
||
την Red Hat \cite{redhatVirtualization}, συνδυαστικά με τρία ακόμα που
|
||
χρησιμοποιούνται συχνά, είναι τα παρακάτω:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Δεδομένων}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_data_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Δεδομένων \cite{redhatVirtualization}}
|
||
\label{fig:dataVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Η εικονικοποίηση δεδομένων είναι μια προσέγγιση ενσωμάτωσης δεδομένων από
|
||
διαφορετικές πηγές, σε μια ολιστική, λογική προβολή δίχως την ανάγκη της
|
||
φυσικής μετακίνησής τους \cite{dataVirtualization}. Δηλαδή, διασκορπισμένα
|
||
ετερογενή δεδομένα παρεχόμενα από πηγές διαφόρων τοποθεσιών δύναται να
|
||
συσσωματωθούν σε μοναδικά, λογικά τεμάχια μιας ενιαίας εικονικής πηγής. Με
|
||
αυτόν τον τρόπο, οι εταιρείες μπορούν από ένα μόνο μοντέλο διαχείρισης
|
||
δεδομένων να οργανώσουν και να επεξεργαστούν διασκορπισμένες πληροφορίες με
|
||
γνώμονα τις ανάγκες των χρηστών με μεγαλύτερη ευκολία και αποδοτικότητα, χωρίς
|
||
την ανάγκη να γνωρίζουν τεχνικές λεπτομέρειες (όπως γλώσσες πρόσβασης, δομές
|
||
αποθήκευσης κα.). Τομείς οι οποίοι επωφελούνται από την εικονικοποίηση
|
||
δεδομένων είναι η λήψη αποφάσεων, η επιχειρηματική αναλυτική και η αξιολόγηση
|
||
των κινδύνων.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Επιφάνειας Εργασίας}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_desktop_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Επιφάνειας Εργασίας \cite{redhatVirtualization}}
|
||
\label{fig:desktopVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Με την εικονικοποίηση επιφάνειας εργασίας, δίνεται σε έναν κεντρικό διαχειριστή
|
||
η ικανότητα διαμοιρασμού προσομοιωμένων περιβαλλόντων εργασίας σε εκατοντάδες
|
||
φυσικές μηχανές ή συσκευές ταυτοχρόνως. Εν αντιθέσει με τα παραδοσιακά
|
||
περιβάλλοντα εργασίας που χρήζουν εγκατάστασης, διαμόρφωσης και ενημέρωσης σε
|
||
κάθε υπολογιστή, η εικονικοποίηση επιφάνειας εργασίας καθιστά δυνατή τη μαζική
|
||
διαμόρφωση, ενημέρωση και έλεγχο ασφαλείας σε όλα τα εικονικά περιβάλλοντα
|
||
εργασίας που παρέχονται από έναν μόνο διακομιστή. Καθ' αυτόν τον τρόπο, οι
|
||
επιχειρήσεις επιτρέπουν στους χρήστες να μπορούν να εργαστούν από οπουδήποτε
|
||
και με κάθε συσκευή ανεξαρτήτως του είδους ή του λειτουργικού συστήματός τους
|
||
\cite{desktopVirtualization}.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Διακομιστών}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_server_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Διακομιστών \cite{redhatVirtualization}}
|
||
\label{fig:serverVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Οι διακομιστές είναι υπολογιστές σχεδιασμένοι με σκοπό να επεξεργάζονται πολύ
|
||
καλά έναν μεγάλο όγκο συγκεκριμένων διεργασιών, ώστε οι κύριοι υπολογιστές μιας
|
||
επιχείρησης να μπορούν να δίνουν προτεραιότητα σε άλλες εργασίες. Με την
|
||
εικονικοποίηση διακομιστών αναφερόμαστε στην διαδικασία κατά την οποία ένας
|
||
φυσικός διακομιστής χωρίζεται σε πολλούς μικρότερους εικονικούς διακομιστές, με
|
||
απώτερο σκοπό την αποτελεσματικότερη αξιοποίηση των πόρων του. Αυτό είναι
|
||
απαραίτητο διότι προτιμάται για λόγους ευκολίας της διαχείρισής τους, κάθε
|
||
διακομιστής να είναι υπεύθυνος για μια μόνο διεργασία την φορά. Μετά την
|
||
κατάτμησή του, ενώ μπορεί να ακολουθείται η ίδια πρακτική, παύει το φυσικό
|
||
μηχάνημα να μένει με αχρησιμοποίητους πόρους και πρακτικά μπορεί το σύνολο τον
|
||
πόρων του να χρησιμοποιηθεί για την εξυπηρέτηση πολλαπλών λειτουργιών. Ο
|
||
ορισμός της εικονικοποίησης διακομιστών αναλύεται πιο λεπτομερώς και στην
|
||
Ενότητα \ref{virtualizationDefinition}.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Λειτουργικού Συστήματος}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_os_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Λειτουργικού Συστήματος \cite{redhatVirtualization}}
|
||
\label{fig:operatingSystemVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Η εικονικοποίηση λειτουργικού συστήματος είναι κάτι που συμβαίνει στον πυρήνα
|
||
(ΛΣ). Ουσιαστικά, αναφερόμαστε στην διαδικασία της δοχειοποίησης λειτουργικών
|
||
συστημάτων. Κατά την εφαρμογή της, μπορούν να εκτελεστούν ταυτοχρόνως πολλαπλά
|
||
λειτουργικά συστήματα μέσα σε απομονωμένα εικονικά περιβάλλοντα, όπου το κάθε
|
||
ένα από αυτά μοιράζεται τον ίδιο πυρήνα με το λειτουργικό σύστημα φιλοξενίας.
|
||
Μεγαλύτερη ανάλυση της εικονικοποίησης σε επίπεδο λειτουργικού συστήματος
|
||
πραγματοποιείται στην Ενότητα \ref{osVirtualization}.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Λειτουργιών Δικτύου}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_network_function_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Λειτουργιών Δικτύου \cite{redhatVirtualization}}
|
||
\label{fig:networkFunctionVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Η εικονικοποίηση λειτουργιών δικτύου (Network Functions Virtualization - NFV)
|
||
αφορά τον διαχωρισμό των βασικών λειτουργιών ενός δικτύου (όπως ο διαμοιρασμός
|
||
αρχείων, και η διαμόρφωση IP) από το φυσικό υλικό (που συνήθως χρησιμοποιούνταν
|
||
για την εκτέλεσή τους), ώστε να μπορούν να διανεμηθούν σε διάφορα περιβάλλοντα.
|
||
Παραδοσιακά, οι λειτουργίες δικτύου εκτελούνταν σε ιδιόκτητο υλικό
|
||
συγκεκριμένου σκοπού και επομένως ήταν απαραίτητο να πραγματοποιηθεί αγορά,
|
||
ρύθμιση και συντήρηση του κάθε φυσικού εξαρτήματος. Με την αύξηση όμως της
|
||
δημοτικότητας των τεχνολογιών εικονικοποίησης, άρχισε να γίνεται πιο δημοφιλής
|
||
και η πρακτική πακεταρίσματος των λειτουργιών των εξαρτημάτων αυτών σε
|
||
διακομιστές κοινής χρήσης (commodity servers). Το αποτέλεσμα αυτού, ήταν η
|
||
απόκτηση της δυνατότητας εκτέλεσης των λειτουργιών δικτύου μιας επιχείρησης σε
|
||
τυπικούς διακομιστές γενικού σκοπού και κατά προέκταση, η αντικατάσταση κάθε
|
||
ξεχωριστού φυσικού μηχανήματος με ένα αντίστοιχο εικονικό εκτελούμενο μέσα από
|
||
μια εικονική μηχανή \cite{redhatNFV}. Η εικονικοποίηση των λειτουργιών δικτύων
|
||
μειώνει τον αριθμό των φυσικών εξαρτημάτων, όπως οι μεταγωγείς, δρομολογητές,
|
||
διακομιστές, καλώδια και κόμβοι, που απαιτούνται για τη δημιουργία πολλαπλών,
|
||
ανεξάρτητων δικτύων και είναι ιδιαίτερα δημοφιλής στον κλάδο των
|
||
τηλεπικοινωνιών.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Μνήμης}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/VMWARE_Virtualization/vmware_memory_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Μνήμης \cite{vmwareMemoryVirtualization}}
|
||
\label{fig:memoryVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Η εικονικοποίηση μνήμης αποτελεί ένα κομμάτι της ευρύτερης έννοιας της
|
||
εικονικοποίησης πόρων \cite{hostitsmartMemoryVirtualization}. Συγκεκριμένα,
|
||
είναι μια τεχνική κατά την οποία δύναται να διαχειριστούμε με έναν πιο
|
||
αποδοτικό τρόπο την φυσική μνήμη (RAM) που χρησιμοποιείται στα υπολογιστικά μας
|
||
συστήματα. Αυτό συμβαίνει διότι στην βασικότερη μορφή της, η εικονικοποίηση
|
||
μνήμης εμφανίζεται ως εικονική μνήμη ή όπως η μνήμη swap σε διακομιστές και
|
||
σταθμούς εργασίας \cite{petriMemoryVirtualization}. Δηλαδή, ως επιπρόσθετη
|
||
μνήμη την οποία το σύστημα εκλαμβάνει ως πραγματική και μπορεί να την
|
||
χρησιμοποιήσει. Για να επιτευχθεί αυτό, μέσω του υπερ-επόπτη πραγματοποιείται
|
||
αντιστοίχιση σελίδων φυσικής μνήμης του φιλοξενούμενου λειτουργικού συστήματος
|
||
στις σελίδες φυσικής μνήμης της υποκείμενης μηχανής. Καθ' αυτόν τον τρόπο, κάθε
|
||
εικονική μηχανή βλέπει έναν συνεχόμενο χώρο διευθύνσεων μνήμης που δύναται να
|
||
χρησιμοποιήσει \cite{vmwareMemoryVirtualization}. Ως αποτέλεσμα, επιτυγχάνεται
|
||
εν γένει υψηλότερη αξιοποίηση της μνήμης και η δυνατότητα διαμοιρασμού μιας
|
||
κοινής δεξαμενής μνήμης ακόμα και σε κατανεμημένα συστήματα, παρακάμπτοντας
|
||
τους περιορισμούς της φυσικής μνήμης \cite{codingninjasMemoryVirtualization}.
|
||
|
||
\clearpage
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Αποθήκευσης}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/UnixArena_Virtualization/unixarena_storage_virtualization.png}
|
||
\captionof{figure}{Εικονικοποίηση Αποθήκευσης \cite{unixarenaVirtualization}}
|
||
\label{fig:storageVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Ένα ακόμα κομμάτι της ευρύτερης έννοιας της εικονικοποίησης πόρων είναι και η
|
||
εικονικοποίηση αποθήκευσης. Συγκεκριμένα, ο όρος εικονικοποίηση αποθήκευσης
|
||
αναφέρεται στην πρακτική της συγκέντρωσης φυσικού αποθηκευτικού χώρου από
|
||
πολλαπλές συσκευές αποθήκευσης σε μια φαινομενικά ενιαία, εικονική συσκευή
|
||
\cite{ubackupStorageVirtualization}. Παρομοίως με την εικονικοποίηση μνήμης,
|
||
αυτό είναι κάτι που θα επιτρέψει την υψηλότερη αξιοποίηση ενός πόρου.
|
||
Συγκεκριμένα, του αποθηκευτικού χώρου (π.χ. ενός δίσκου). Με την χρήση της
|
||
έρχονται πολλά πλεονεκτήματα. Αρχικά, επιφέρει μεγαλύτερη ευελιξία στον τομέα
|
||
της αποθήκευσης. Επιπλέον, εγγυάται υψηλή διαθεσιμότητα και ευκολία στην
|
||
δημιουργία αντιγράφων ασφαλείας. Χρήσιμη λειτουργία που παρέχεται μέσω της
|
||
εικονικοποίησης αποθήκευσης αποτελεί και η αφαίρεση ή το κρύψιμο ετερογένειας
|
||
αποθηκευτικών συσκευών που εικονικοποιούνται, οι οποίες μπορεί να προέρχονται
|
||
από διαφορετικούς πωλητές ή από τις εφαρμογές που τις διαχειρίζονται. Τέλος,
|
||
προσφέρει έναν ενιαίο τρόπο διαχείρισης των συσκευών μέσω κεντρικοποιημένων
|
||
κονσόλων ή APIs και επομένως, αποτελεί ένα πιο διαχειρίσιμο μοντέλο χώρου
|
||
αποθήκευσης σε σχέση με το παραδοσιακό, όπου κάθε υπολογιστής έχει πρόσβαση
|
||
μονάχα στον δικό του δίσκο.
|
||
|
||
Προκειμένου να γίνει πράξη, απαιτείται αναλόγως την μέθοδο εικονικοποίησης και
|
||
τον τύπο της, είτε να χρησιμοποιηθεί ένας αλγόριθμος για να εντοπίσει δυναμικά
|
||
τα δεδομένα είτε να δημιουργηθεί ένας χάρτης αντιστοίχισής τους χρησιμοποιώντας
|
||
μεταδεδομένα \cite{cloudinfraStorageVirtualization}. Αφότου γίνει αυτό, τα
|
||
δεδομένα πλέον αποθηκεύονται σε ένα αρχείο και οι συστοιχίες δίσκων
|
||
τοποθετούνται μέσα σε μια εικονική δεξαμενή. Έπειτα, κάθε αίτημα ανάγνωσης και
|
||
εγγραφής από τις εφαρμογές φιλτράρεται και δύναται, π.χ. έμμεσα μέσω των
|
||
αντιστοιχιών, η δυνατότητα εύρεσης και αποθήκευσης δεδομένων.
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εικονικοποίηση Εφαρμογών}:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/TutorialsPoint_Virtualization/tutorialspoint_application_virtualization.jpg}
|
||
\captionof{figure}{Εικονικοποίηση Εφαρμογών \cite{tutorialsPointVirtualization}}
|
||
\label{fig:applicationVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\end{itemize}
|
||
|
||
Η εικονικοποίηση εφαρμογών είναι μια τεχνολογία λογισμικού που ενθυλακώνει τα
|
||
προγράμματα από το υποκείμενο λειτουργικό σύστημα στο οποίο εκτελούνται.
|
||
Υπάγεται στην διαδικασία της δοχειοποίησης και επομένως, τα προγράμματα που
|
||
ενθυλακώνονται, συμπεριλαμβανομένων των βιβλιοθηκών και εξαρτήσεών τους,
|
||
παίρνουν την μορφή δοχείων. Στα δοχεία αυτά, εικονικοποιούνται οι απαραίτητοι
|
||
υπολογιστικοί πόροι όπως το λειτουργικό σύστημα, η μνήμη και η κεντρική μονάδα
|
||
επεξεργασίας \cite{geeksforgeeksApplicationVirtualization}, κάνοντας χρήση των
|
||
διαθέσιμων μηχανισμών απομόνωσης του πυρήνα του λειτουργικού συστήματος.
|
||
Περισσότερες λεπτομέρειες για τον τρόπο κατά τον οποίο επιτυγχάνεται αυτό,
|
||
παρουσιάζονται στην Ενότητα \ref{osVirtualization}.
|
||
|
||
\subsection{Ιστορική αναδρομή της εικονικοποίησης} \label{virtualizationHistory}
|
||
|
||
Όπως αναφέρει μια θυγατρική της IBM \cite{redhatVirtualization}, ενώ η
|
||
τεχνολογία εικονικοποίησης χρονολογείται από τη δεκαετία του 1960, δεν
|
||
υιοθετήθηκε ευρέως μέχρι τις αρχές της δεκαετίας του 2000. Οι τεχνολογίες που
|
||
την έκαναν πραγματικότητα, όπως οι υπερ-επόπτες, αναπτύχθηκαν πριν από
|
||
δεκαετίες για να δώσουν σε πολλούς χρήστες ταυτόχρονη πρόσβαση σε υπολογιστές
|
||
που επεξεργαζόντουσαν πολλά δεδομένα ταυτόχρονα. Κάτι ιδιαίτερα δημοφιλές στον
|
||
τομέα των επιχειρήσεων για καθήκοντα ρουτίνας (routine tasks) που έπρεπε να
|
||
εκτελεστούν χιλιάδες φορές και πολύ γρήγορα όπως η μισθοδοσία υπαλλήλων.
|
||
|
||
Ωστόσο, μέσα στις επόμενες δεκαετίες, ήρθαν στο προσκήνιο άλλες λύσεις στο
|
||
πρόβλημα διαμοιρασμού ενός μηχανήματος σε πολλούς χρήστες, μειώνοντας έτσι το
|
||
ενδιαφέρον για την τεχνολογία εικονικοποίησης. Μία από αυτές ήταν ο
|
||
διαμοιρασμός χρόνου (time-sharing), όπου ένας χρήστης μπορούσε να χρησιμοποιεί
|
||
το λειτουργικό σύστημα απομονωμένα από τους υπόλοιπους. Κάτι που οδήγησε στη
|
||
δημιουργία λειτουργικών συστημάτων όπως το UNIX, το οποίο με τη σειρά του
|
||
άνοιξε το δρόμο για την άφιξη του Linux. Καθ' όλη τη διάρκεια αυτή, η
|
||
εικονικοποίηση παρέμεινε σε μεγάλο βαθμό μη διαδεδομένη.
|
||
|
||
Προχωρώντας στη δεκαετία του 1990, οι περισσότερες επιχειρήσεις διέθεταν
|
||
φυσικούς διακομιστές και στοίβες μηχανημάτων ενός προμηθευτή, οι οποίες δεν
|
||
είχαν τη δυνατότητα εκτέλεσης εφαρμογών σε υλικό διαφορετικού προμηθευτή. Καθώς
|
||
οι εταιρείες αναβάθμιζαν τα περιβάλλοντα πληροφορικής τους με λιγότερο
|
||
δαπανηρούς διακομιστές, λειτουργικά συστήματα και εφαρμογές από διάφορους
|
||
προμηθευτές, ήταν υποχρεωμένες να υπολειτουργούν το φυσικό υλικό, αφού κάθε
|
||
διακομιστής μπορούσε συνήθως να εκτελέσει μόνο μια εργασία/εφαρμογή που είχε
|
||
υλοποιηθεί με βάση το υλικό του συγκεκριμένου προμηθευτή (του διακομιστή).
|
||
|
||
Από εκείνο το σημείο και έπειτα, άρχισε να γίνεται εμφανής η ανάγκη της
|
||
εικονικοποίησης και να ανεβαίνει η δημοτικότητά της. Οι εταιρείες μπορούσαν
|
||
πλέον να διαμερίσουν τους διακομιστές τους και να εκτελούν ακόμα και τις
|
||
παλαιές τους εφαρμογές σε πολλούς τύπους και εκδόσεις λειτουργικών συστημάτων.
|
||
Οι διακομιστές άρχισαν να χρησιμοποιούνται πιο αποδοτικά ή και καθόλου (όταν η
|
||
ζήτηση ήταν ελάχιστη), μειώνοντας το απαιτούμενο κόστος αγοράς, εγκατάστασης,
|
||
συντήρησης και ψύξης τους.
|
||
|
||
Η ευρεία εφαρμογή της εικονικοποίησης συνέβαλε στη μείωση του εγκλωβισμού σε
|
||
έναν μόνο προμηθευτή και την κατέστησε το θεμέλιο του υπολογιστικού νέφους.
|
||
Σήμερα είναι τόσο διαδεδομένη σε όλες τις επιχειρήσεις που συχνά απαιτείται
|
||
εξειδικευμένο λογισμικό διαχείρισης των εικονικών πόρων
|
||
\cite{redhatVirtualizationManagement} για να μπορέσει κανείς να παρακολουθεί τα
|
||
δρώμενα μιας επιχείρησης. Πρόκειται για ένα λογισμικό το οποίο διασυνδέεται με
|
||
εικονικά περιβάλλοντα και το υποκείμενο φυσικό υλικό τους με απώτερο σκοπό την
|
||
απλοποίηση της διαχείρισης πόρων, τη βελτίωση της ανάλυσης δεδομένων και τον
|
||
εξορθολογισμό των λειτουργιών τους. Ουσιαστικά, αποτελεί ένα λογισμικό που
|
||
συνδέεται απομακρυσμένα με υπερ-επόπτες, προσφέροντας μια φιλική προς τον χρήση
|
||
διεπαφή και επιπρόσθετες λειτουργίες, όπως η συγκρότηση αναφορών χρήσης, η
|
||
αυτοματοποίηση επιβολής κανόνων και η παρακολούθηση χρήσης εικονικών
|
||
περιβαλλόντων.
|
||
|
||
\subsection{Τι είναι ένας υπερ-επόπτης} \label{hypervisors}
|
||
|
||
Προτού οι υπερ-επόπτες έρθουν στο προσκήνιο, οι περισσότεροι φυσικοί
|
||
υπολογιστές μπορούσαν να εκτελέσουν ένα λειτουργικό σύστημα τη φορά. Αυτό
|
||
συνέβαλε στη σταθερότητα τους μιας και δε χρειαζόταν να διαχειριστούν αιτήματα
|
||
από άλλα λειτουργικά συστήματα. Αυτή η προσέγγιση όμως είχε ένα μειονέκτημα.
|
||
Μεγάλο κομμάτι των πόρων του συστήματος έμενε ανεκμετάλλευτο.
|
||
|
||
Τη λύση σε αυτό το πρόβλημα την έφερε η εισαγωγή των υπερ-εποπτών. Πρόκειται
|
||
για μια στρώση λογισμικού που καθιστά δυνατή την εκτέλεση πολλαπλών
|
||
λειτουργικών συστημάτων, το ένα δίπλα στο άλλο, μοιράζοντας τους ίδιους
|
||
φυσικούς πόρους σε κάθε ένα από αυτά. Η πράξη αυτή ονομάζεται εικονικοποίηση
|
||
και τα στιγμιότυπα των λειτουργικών συστημάτων λέγονται εικονικές μηχανές και
|
||
αντιπροσωπεύουν προσομοιώσεις φυσικών υπολογιστών.
|
||
|
||
Οι υπερ-επόπτες είναι υπεύθυνοι για τη διαχείριση των εικονικών μηχανών
|
||
χωρίζοντάς τις και αναθέτοντας σε κάθε μια ένα κομμάτι της διαθέσιμης
|
||
υπολογιστικής ισχύος, μνήμης και χώρου αποθήκευσης. Αυτή η διαδικασία τις
|
||
αποτρέπει από την αλληλεπίδραση μεταξύ τους. Μάλιστα, στην περίπτωση
|
||
κατάρρευσης μιας εικονικής μηχανής, οι υπόλοιπες παραμένουν ανεπηρέαστες.
|
||
|
||
\subsubsection{Είδη υπερ-εποπτών} \label{hypervisorTypes}
|
||
|
||
Οι υπερ-επόπτες χωρίζονται σε δύο κατηγορίες ανάλογα με το περιβάλλον στο οποίο
|
||
εκτελούνται. Με βάση την \citeauthor{ibmHypervisorDefinition}
|
||
\cite{ibmHypervisorDefinition}, αυτές είναι:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Τύπου 1 (Bare Metal)}:
|
||
|
||
Ένας υπερ-επόπτης τύπου 1 εκτελείται απευθείας στο φυσικό υλικό του
|
||
υποκείμενου υπολογιστή, αλληλεπιδρώντας άμεσα με την κεντρική μονάδα
|
||
επεξεργασίας, τη μνήμη και το φυσικό αποθηκευτικό χώρο. Για το λόγο
|
||
αυτό, οι υπερ-επόπτες τύπου 1 αναφέρονται επίσης ως bare-metal
|
||
υπερ-επόπτες και αντικαθιστούν το λειτουργικό σύστημα του κεντρικού
|
||
υπολογιστή. Η άμεση πρόσβαση στο φυσικό υλικό, τους καθιστά ιδιαίτερα
|
||
αποδοτικούς. Παρ' όλα αυτά, επειδή αντικαθιστούν το ΛΣ, προκειμένου να
|
||
μπορούν να αξιοποιηθούν απομακρυσμένα, συχνά απαιτείται μια ξεχωριστή
|
||
μηχανή στην οποία θα εκτελείται λογισμικό διαχείρισης εικονικών πόρων
|
||
\cite{phoenixnapHypervisors}, μέσω του οποίου προσφέρεται μια διεπαφή
|
||
για τον έλεγχο των εικονικών μηχανών και του υλικού του κεντρικού
|
||
υπολογιστή.
|
||
|
||
\item \textbf{Τύπου 2 (Hosted)}:
|
||
|
||
Ένας υπερ-επόπτης τύπου 2 δεν εκτελείται απευθείας στο υποκείμενο
|
||
υλικό. Αντ' αυτού, εκτελείται ως εφαρμογή σε ένα υπάρχον λειτουργικό
|
||
σύστημα. Η χρήση τους δε συνηθίζεται σε περιβάλλοντα με πολλούς
|
||
διακομιστές λόγω της καθυστέρησης που εισάγεται εξαιτίας της συνεχούς
|
||
επικοινωνίας του με το ΛΣ φιλοξενίας και επειδή το υποκείμενο αυτό ΛΣ
|
||
βάζει σε προτεραιότητα τις δικές του εφαρμογές και λειτουργίες έναντι
|
||
αυτών του υπερ-επόπτη \cite{amazonHypervisors}.
|
||
|
||
\end{itemize}
|
||
|
||
Σε κάθε τύπο υπερ-επόπτη, όταν το φιλοξενούμενο ΛΣ αιτηθεί πρόσβαση στους
|
||
πόρους υπολογισμού, μνήμης και δικτύου του φυσικού υλικού, όλες οι προσβάσεις
|
||
περνάνε πρώτα από αυτόν. Στην περίπτωση όμως υπερ-επόπτη τύπου 2, επειδή
|
||
εκτελείται ως εφαρμογή του ΛΣ φιλοξενίας, οι προσβάσεις αυτές χρειάζεται να
|
||
μεταφραστούν προτού περάσουν στο φιλοξενούμενο ΛΣ και τους υποκείμενους πόρους
|
||
του. Επομένως, σε αντίθεση με τους υπερ-επόπτες τύπου 1 όπου η πρόσβαση γίνεται
|
||
άμεσα, η χρήση υπερ-εποπτών τύπου 2 εισάγει προβλήματα καθυστέρησης που μπορεί
|
||
να επηρεάσουν την απόδοση. Κατά την χρήση υπερ-επόπτη τύπου 2 παρέχεται
|
||
μεγαλύτερη συμβατότητα/γκάμα υλικού διότι αυτό διαχειρίζεται από το υποκείμενο
|
||
ΛΣ φιλοξενίας. Επιπροσθέτως, εισάγεται πιθανός κίνδυνος ασφαλείας εάν ένας
|
||
εισβολέας παραβιάσει το κεντρικό λειτουργικό σύστημα, επειδή θα μπορούσε στη
|
||
συνέχεια να χειραγωγήσει οποιοδήποτε φιλοξενούμενο λειτουργικό σύστημα
|
||
εκτελείται σε αυτό.
|
||
|
||
Από την άλλη μεριά, οι υπερ-επόπτες τύπου 2 είναι καταλληλότεροι για
|
||
μεμονωμένους τελικούς χρήστες υπολογιστών που έχουν την ανάγκη να εκτελέσουν
|
||
πολλαπλά λειτουργικά συστήματα (σε έναν υπολογιστή). Παραδείγματα τέτοιων
|
||
χρηστών είναι μηχανικοί, επαγγελματίες ασφαλείας που αναλύουν κακόβουλο
|
||
λογισμικό και υπάλληλοι επιχειρήσεων που χρειάζονται πρόσβαση σε εφαρμογές που
|
||
είναι διαθέσιμες αποκλειστικά σε διαφορετικές πλατφόρμες λογισμικού από τη δική
|
||
τους. Διατίθενται συχνά πρόσθετες εργαλειοθήκες για τους χρήστες, οι οποίες
|
||
μπορούν να εγκατασταθούν στο υποκείμενο λειτουργικό σύστημα προκειμένου να
|
||
παρέχουν βελτιωμένες συνδέσεις μεταξύ του υποκείμενου λειτουργικού συστήματος
|
||
και εκείνου της εικονικής μηχανής. Οι πρόσθετες δυνατότητες που υποστηρίζονται
|
||
μετά την παραπάνω διαδικασία μπορεί να είναι η αποκοπή και επικόλληση μεταξύ
|
||
των δύο συστημάτων ή η κοινή πρόσβαση στον αποθηκευτικό χώρο. Η τρέχουσα
|
||
προσέγγιση επιτρέπει τη γρήγορη εναλλαγή σε διαφορετικά λειτουργικά συστήματα
|
||
πέραν του ήδη υπάρχοντος, πράγμα που αυξάνει την παραγωγικότητα του τελικού
|
||
χρήστη, αφού μπορεί να έχει πρόσβαση σε εργαλεία που δεν υποστηρίζονται στο
|
||
δικό του (αρχικό/υπάρχον σύστημα).
|
||
|
||
Εξαίρεση στον κανόνα απουσίας λειτουργικού συστήματος αποτελεί η χρήση ενός
|
||
υπερ-επόπτη ανοιχτού κώδικα βασισμένου στο KVM (Kernel-based Virtual Machine),
|
||
που επιτρέπει στο Linux να συμπεριφέρεται ως ένας υπερ-επόπτης. Αυτό συμβαίνει
|
||
διότι το KVM αποτελεί κομμάτι του πυρήνα του Linux από την έκδοση 2.6.20 και
|
||
έπειτα, επιτρέποντάς του να επωφεληθεί από τους διαθέσιμους μηχανισμούς
|
||
απομόνωσης μέσω αυτού. Επομένως, του προσφέρεται η ικανότητα να λάβει
|
||
αποκλειστικούς πόρους από το φυσικό μηχάνημα \cite{kvm}, κάτι που εξαλείφει το
|
||
μειονέκτημα έλλειψης προτεραιότητας των διεργασιών ενός υπερ-επόπτη τύπου 2
|
||
έναντι αυτών του λειτουργικού συστήματος φιλοξενίας.
|
||
|
||
\subsubsection{Χαρακτηριστικά ενός υπερ-επόπτη} \label{hypervisorCharacteristics}
|
||
|
||
Αν και υπάρχουν διαφορετικά είδη υπερ-εποπτών, όλοι έχουν κάποια χαρακτηριστικά
|
||
που πρέπει να λάβει κανείς υπόψιν όταν επιλέγει ποιον θα χρησιμοποιήσει. Μερικά
|
||
σημαντικά αυτών, όπως αναφέρονται από την \citeauthor{ibmHypervisorDefinition}
|
||
\cite{ibmHypervisorDefinition}, είναι:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Απόδοση}:
|
||
|
||
Βασικό χαρακτηριστικό ενός υπερ-επόπτη είναι η απόδοσή του. Αυτή
|
||
διαφέρει από τον ένα υπερ-επόπτη στον άλλο αναλόγως την κατασκευή και
|
||
τον τύπο του. Όμως, εν γένει, οι υπερ-επόπτες τύπου 1 θα πρέπει να
|
||
παρέχουν απόδοση κοντά στην εγγενή λόγω της απουσίας ανάγκης μετάφρασης
|
||
των αιτημάτων του φιλοξενούμενου ΛΣ.
|
||
|
||
\item \textbf{Εργαλεία διαχείρισης}:
|
||
|
||
Η εκτέλεση εικονικών μηχανών δεν αποτελεί το μοναδικό καθήκον ενός
|
||
διαχειριστή κατά τη χρήση ενός υπερ-επόπτη. Απαραίτητες πρόσθετες
|
||
ενέργειες είναι η συντήρηση και η ανάλυσή τους, καθώς και η διαγραφή
|
||
όσων δε χρησιμοποιούνται πλέον. Επομένως, η ύπαρξη εργαλείων που να
|
||
καθιστούν δυνατές αυτές τις ενέργειες αποτελεί σημαντικό παράγοντα κατά
|
||
την επιλογή λογισμικού υπερ-επόπτη.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Οικοσύστημα}:
|
||
|
||
Για τη διαχείριση ενός υπερ-επόπτη σε διάφορες κλίμακες πρέπει να
|
||
υπάρχει καλή τεκμηρίωση και διάφορα εργαλεία διαχείρισης είτε επίσημα
|
||
είτε από την κοινότητα που να επιτρέπουν δυνατότητες, όπως δημιουργία
|
||
αντιγράφων ασφαλείας, ανάλυση χωρητικότητας και διαχείριση εναλλαγής
|
||
εικονικών μηχανών \cite{vmfailover} με αντίγραφά τους σε περιπτώσεις
|
||
σφάλματος του λειτουργικού συστήματος της εκτελούμενης (εικονικής
|
||
μηχανής).
|
||
|
||
\item \textbf{Μεταφορά κατά τη λειτουργία}:
|
||
|
||
Πρέπει να υπάρχει η δυνατότητα μεταφοράς εικονικών μηχανών από έναν
|
||
υπερ-επόπτη σε έναν δεύτερο σε διαφορετική φυσική μηχανή, ιδανικά χωρίς
|
||
την ανάγκη διακοπής της λειτουργίας τους. Ένα χαρακτηριστικό που
|
||
χρησιμεύει τόσο για την αποτροπή αποτυχίας παροχής υπηρεσιών της
|
||
εκάστοτε επιχείρησης όσο και για την εξισορρόπηση του φόρτου εργασίας.
|
||
|
||
\item \textbf{Κόστος}:
|
||
|
||
Το κόστος είναι ένας παράγοντας που πρέπει να ληφθεί υπόψιν κατά την
|
||
επιλογή ενός υπερ-επόπτη. Οι περισσότεροι είναι δωρεάν αλλά υπάρχουν
|
||
και εμπορικές εκδόσεις που προσφέρουν περισσότερες δυνατότητες. Για
|
||
παράδειγμα, μπορεί να προσφέρεται λογισμικό διαχείρισης των λειτουργιών
|
||
τους που να επιτρέπει την εύκολη κλιμάκωση με βάση τις απαιτήσεις της
|
||
επιχείρησης.
|
||
|
||
\end{itemize}
|
||
|
||
\subsubsection{Επιλογή υπερ-επόπτη} \label{hypervisorSelection}
|
||
|
||
Σε κάθε περίπτωση, η ασφάλεια αποτελεί έναν σημαντικό παράγοντα επιλογής
|
||
υπερ-επόπτη διότι στην περίπτωση παραβίασής του, η χειραγώγηση όλων των
|
||
εικονικών μηχανών που αυτός διαχειρίζεται θα μπορεί να πραγματοποιηθεί χωρίς
|
||
μεγάλη δυσκολία.
|
||
|
||
Η επιλογή του τύπου υπερ-επόπτη που θα χρησιμοποιηθεί είναι άμεσα εξαρτώμενη
|
||
από τις ανάγκες του κάθε τελικού χρήση ή επιχείρησης ζυγίζοντας τα
|
||
πλεονεκτήματα και μειονεκτήματα που έρχονται με την κάθε επιλογή. Παραδείγματος
|
||
χάριν, αν η ταχύτητα και η απόδοση θεωρούνται από τον χρήστη χαρακτηριστικά
|
||
υψίστης σημασίας, τότε η επιλογή υπερ-επόπτη τύπου 1 αποτελεί μονόδρομο.
|
||
Επιπλέον, ο μεγαλύτερος βαθμός απομόνωσης που προσφέρουν, παρέχει και
|
||
μεγαλύτερη ασφάλεια. Από την άλλη, αν η προτεραιότητα είναι η ευκολία
|
||
διαχείρισης και η ευελιξία ταχείας εναλλαγής σε διαφορετικά λειτουργικά
|
||
συστήματα, η πιο ταιριαστή επιλογή είναι ένας υπερ-επόπτης τύπου 2.
|
||
|
||
\subsection{Εικονικοποίηση Διακομιστών} \label{virtualizationDefinition}
|
||
|
||
Σύμφωνα με τον ορισμό της Red Hat \cite{redhatVirtualizationDefinition}, η
|
||
εικονικοποίηση είναι μια τεχνολογία που μας επιτρέπει να δημιουργήσουμε
|
||
πολλαπλά εικονικά περιβάλλοντα ή αποκλειστικούς πόρους από ένα μόνο, φυσικό
|
||
σύστημα υλικού. Ένα λογισμικό ονόματι υπερ-επόπτης (hypervisor) συνδέεται στο
|
||
υλικό αυτό\footnote{\textgreek{Απευθείας στην εικονικοποίηση υποβοηθούμενη από
|
||
το υλικό και έμμεσα στην εικονικοποίηση υποβοηθούμενη από το λογισμικό.}} και
|
||
δίνει τη δυνατότητα διαμερισμού ενός συστήματος σε ξεχωριστά, διακριτά και
|
||
ασφαλή περιβάλλοντα, γνωστά και ως εικονικές μηχανές (Virtual Machines - VMs).
|
||
Επομένως, αυτές οι εικονικές μηχανές βασίζονται στην ικανότητα του υπερ-επόπτη
|
||
να διαχωρίζει τους πόρους της μηχανής και να τους κατανέμει κατάλληλα. Οι
|
||
εικονικές μηχανές έχουν τη μορφή ενός ενιαίου αρχείου, πράγμα που καθιστά
|
||
εύκολη τη μεταφορά και ανάγνωσή τους από οποιονδήποτε υπολογιστή αναμένοντας
|
||
τον ίδιο τρόπο λειτουργίας.
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .5\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_architecture.png}
|
||
\captionof{figure}{Υπερ-επόπτης πάνω σε διακομιστές \cite{redhatVirtualization}}
|
||
\label{fig:hypervisorOnServers}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
Το φυσικό υλικό, εξοπλισμένο με έναν υπερ-επόπτη, ονομάζεται ξενιστής (host) ή
|
||
μηχάνημα φιλοξενίας (hosting machine), ενώ οι πολλές εικονικές μηχανές που
|
||
χρησιμοποιούν τους πόρους του είναι οι επισκέπτες (guests) ή αλλιώς τα
|
||
φιλοξενούμενα μηχανήματα (hosted machines). Οι επισκέπτες, αντιμετωπίζουν τους
|
||
υπολογιστικούς πόρους, όπως είναι η κεντρική μονάδα επεξεργασίας, η μνήμη και ο
|
||
αποθηκευτικός χώρος, ως μια δεξαμενή πόρων που μπορεί εύκολα να ανακατανεμηθεί.
|
||
Οι χειριστές (operators) μπορούν να ελέγχουν εικονικά στιγμιότυπα αυτών των
|
||
πόρων, ούτως ώστε να πραγματοποιούν οριζόντια ή κάθετη κλιμάκωση. Δηλαδή είτε
|
||
να δημιουργούν περισσότερες εικονικές μηχανές, είτε να αναδημιουργούν την ίδια
|
||
με επιπλέον πόρους (εφόσον αυτοί δεν έχουν δεσμευτεί από άλλες εικονικές
|
||
μηχανές του ίδιου φυσικού μηχανήματος) όταν αυτό είναι απαραίτητο.
|
||
|
||
Η εικονικοποίηση καθιστά δυνατή τη δημιουργία χρήσιμων υπηρεσιών ΤΠ
|
||
(Τεχνολογίας Πληροφοριών) χρησιμοποιώντας πόρους στους οποίους παραδοσιακά
|
||
μπορούσαμε να έχουμε πρόσβαση μονάχα με την ιδιοκτησία φυσικών μηχανημάτων. Μας
|
||
επιτρέπει να αξιοποιήσουμε όλες τις δυνατότητες ενός φυσικού μηχανήματος
|
||
διανέμοντάς τις σε πολλούς χρήστες και περιβάλλοντα. Με άλλα λόγια,
|
||
υποστηρίζεται η πολλαπλή μίσθωση ανά φυσικό μηχάνημα με τη μορφή εικονικών
|
||
μηχανών καθώς και η αυξημένη χρήση πόρων των φυσικών μηχανών (στα κέντρα
|
||
δεδομένων του νέφους).
|
||
|
||
Με βάση ένα παράδειγμα της Red Hat \cite{redhatVirtualization}, ας φανταστούμε
|
||
πως έχουμε τρεις φυσικούς διακομιστές (servers) (δηλ. φυσικά μηχανήματα), στον
|
||
καθένα από τους οποίους φιλοξενείται ένα συγκεκριμένο συστατικό (component)
|
||
(λογισμικού): ένας διακομιστής ηλεκτρονικού ταχυδρομείου (email server), ένας
|
||
διακομιστής ιστού (web server) και ένας διακομιστής που εκτελεί εσωτερικές
|
||
εταιρικές εφαρμογές κληρονομιάς (οι οποίες σταμάτησαν να διατηρούνται αλλά
|
||
είναι ακόμα λειτουργικές), αντίστοιχα. Στο συγκεκριμένο παράδειγμα κάθε ένας
|
||
από τους (φυσικούς) διακομιστές χρησιμοποιεί μονάχα το 30\% των δυνατοτήτων του
|
||
(ως προς τους πόρους που μπορεί να διαθέσει).
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .9\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage1.png}
|
||
\captionof{figure}{Χρήση διακομιστών χωρίς εικονικοποίηση \cite{redhatVirtualization}}
|
||
\label{fig:virtualizationServerUsage1}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
Παραδοσιακά, αυτή η αρχιτεκτονική, όπου εκτελούνται μεμονωμένες εργασίες έκαστη
|
||
αποκλειστικά σε συγκεκριμένο διακομιστή, ήταν ευκολότερη και πιο αξιόπιστη αλλά
|
||
δεν παύει να είναι και η λιγότερο αποδοτική λύση. Με την άφιξη της τεχνολογίας
|
||
της εικονικοποίησης όμως, είναι πλέον εφικτό να χωριστεί ένας διακομιστής σε
|
||
περισσότερα μέρη, έχοντας δύο ή παραπάνω εικονικές μηχανές με τη χρήση μιας
|
||
φυσικής.
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .9\textwidth]{Figures/RedHat_Virtualization/redhat_virtualization_server_usage2.png}
|
||
\captionof{figure}{Χρήση διακομιστών με εικονικοποίηση \cite{redhatVirtualization}}
|
||
\label{fig:virtualizationServerUsage2}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
Εφόσον ένας διακομιστής χωρίζεται σε δύο ή παραπάνω εικονικά μέρη, μπορεί να
|
||
αυξηθεί ραγδαία η αξιοποίηση των δυνατοτήτων του. Με βάση το προηγούμενο
|
||
παράδειγμα, αν μια εικονική μηχανή λαμβάνει το 30\% των πόρων ενός
|
||
διακομιστή/φυσικού μηχανήματος, τότε ορισμένες από τις προαναφερόμενες
|
||
λειτουργικότητες/συστατικά λογισμικού (παροχής υπηρεσιών ιστού, ηλεκτρονικού
|
||
ταχυδρομείου και εφαρμογών) θα μπορούσαν να εγκατασταθούν στον ίδιο διακομιστή
|
||
με την μορφή εικονικών μηχανών.
|
||
|
||
Αφού η δημιουργία και καταστροφή των εικονικών μηχανών σε ένα μηχάνημα
|
||
πραγματοποιείται δυναμικά ανάλογα με τη ζήτηση, αυτό σημαίνει πως ένας
|
||
διακομιστής μπορεί να συνεχίσει να χρησιμοποιείται για νέους σκοπούς σε σχέση
|
||
με τους αρχικούς ή να αποσυρθεί τελείως σταματώντας την λειτουργία του (switch
|
||
off). Το τελευταίο είναι χρήσιμο κυρίως όταν η ζήτηση σε ένα κέντρο δεδομένων
|
||
είναι μικρή και επομένως υπάρχει οικονομικό συμφέρον (λόγω ενεργειακού κόστους)
|
||
ως προς το κλείσιμο των διακομιστών που δεν απαιτούνται για την κάλυψη της
|
||
παρούσας ζήτησης.
|
||
|
||
\subsubsection{Παρα-εικονικοποίηση} \label{paraVirtualization}
|
||
|
||
Όταν αναφερόμαστε στην εικονικοποίηση συνήθως μιλάμε για την πιο συνηθισμένη
|
||
μορφή της, η οποία είναι η πλήρης εικονικοποίηση. Με την πάροδο του χρόνου και
|
||
την αύξηση της δημοτικότητας της εικονικοποίησης, αναπτύχθηκαν πολλοί
|
||
υπερ-επόπτες που μπορεί να διαφέρουν όχι μόνο στα χαρακτηριστικά τους αλλά και
|
||
στις διάφορες τεχνικές που χρησιμοποιούν για να κάνουν την εικονικοποίηση
|
||
πραγματικότητα. Μια από αυτές ονομάζεται παρα-εικονικοποίηση
|
||
(paravirtualization) \cite{suseParavirtualizationDefinition}.
|
||
|
||
Κάθε εικονική μηχανή απαιτεί ένα συγκεκριμένο ποσοστό χρήσης υπολογιστικών
|
||
πόρων του φυσικού διακομιστή για να εκτελείται. Μέσα σε αυτό το ποσοστό,
|
||
συμπεριλαμβάνεται και η επιβάρυνση που εισάγει η συνεχής μετάφραση εικονικών σε
|
||
φυσικούς πόρους. Έχοντας υπόψιν πως κάθε φυσικός διακομιστής διαθέτει
|
||
πεπερασμένους πόρους, με την πλήρη εικονικοποίηση επιβάλλεται ένα όριο στον
|
||
αριθμό των εικονικών μηχανών που μπορεί αυτός να υποστηρίξει. Επιπροσθέτως,
|
||
προκύπτουν και προβλήματα καθυστέρησης αφού η διαδικασία της μετάφρασης απαιτεί
|
||
κάποιο χρόνο για να διεκπεραιωθεί.
|
||
|
||
Επομένως, η πλήρης εικονικοποίηση περιορίζει σημαντικά τον αριθμό των εικονικών
|
||
μηχανών που δύναται ένας διακομιστής να εκτελέσει παράλληλα, όπως επίσης και τα
|
||
είδη εφαρμογών που μπορούν να εκτελεστούν σε μια εικονική μηχανή (εφόσον η
|
||
ταχύτητα εκτέλεσης τους παίζει σημαντικό ρόλο στην ευχρηστία τους).
|
||
|
||
Η παρα-εικονικοποίηση είναι μια τεχνική εικονικοποίησης που αναπτύχθηκε
|
||
προκειμένου να ξεπεραστούν τα προαναφερόμενα προβλήματα επιδόσεων που έρχονται
|
||
με την χρήση της πλήρους εικονικοποίησης. Κατά την χρήση της, το φιλοξενούμενο
|
||
λειτουργικό σύστημα δεν είναι πλήρως απομονωμένο από το υλικό αλλά απομονώνεται
|
||
μερικώς \cite{serverWatchParavirtualization} και έχει άμεση επικοινωνία με
|
||
αυτό. Υπάρχει δηλαδή επίγνωση της εικονικοποίησης από μεριάς του ΛΣ των
|
||
εικονικών μηχανών και αξιοποίηση της, μέσω της χρήσης υπερ-κλήσεων προς τον
|
||
υπερ-επόπτη. Οι κλήσεις αυτές, επιτρέπουν σε κάθε ΛΣ να ζητάει πόρους κατά
|
||
παραγγελία και να αναθέτει την εκτέλεση διεργασιών του απευθείας στο υλικό. Για
|
||
να μπορέσει να επιτευχθεί αυτό, απαιτείται η τροποποίηση του φιλοξενούμενου
|
||
λειτουργικού συστήματος, η οποία θα του επιτρέπει την υλοποίηση ενός ειδικού
|
||
API, ώστε να μπορεί να κάνει χρήση των υπερ-κλήσεων
|
||
\cite{servermaniaParavirtualization}, ενώ επιβάλλεται να υποστηρίζεται και από
|
||
τον υπερ-επόπτη η κατανόησή τους.
|
||
|
||
Η παρα-εικονικοποίηση παρέχει ορισμένα πλεονεκτήματα συγκριτικά με την πλήρη
|
||
εικονικοποίηση. Καταρχάς, η απόδοση των εικονικών μηχανών είναι συγκρίσιμη με
|
||
αυτή των φυσικών μηχανών, αφού η παρα-εικονικοποίηση δεν επιβάλλει την
|
||
επιβάρυνση της μετάφρασης εικονικών σε φυσικούς πόρους. Επιπροσθέτως, το
|
||
γεγονός πως το φιλοξενούμενο λειτουργικό σύστημα γνωρίζει πως εκτελείται σε
|
||
εικονικό περιβάλλον, του δίνει την δυνατότητα να αποφύγει την χρήση περιττών
|
||
προγραμμάτων που μπορεί να αποτελέσουν ευπαθή σημεία για επιθέσεις, όπως για
|
||
παράδειγμα το BIOS. Επομένως, η χρήση της παρα-εικονικοποίσης παρέχει
|
||
μεγαλύτερη ασφάλεια στο σύστημα. Μερικοί τομείς που επωφελούνται από την
|
||
παρα-εικονικοποίηση είναι η χρήση λογισμικών που επιτρέπουν την ανάκαμψη από
|
||
καταστροφές, την μετανάστευση δεδομένων μεταξύ λειτουργικών συστημάτων
|
||
\cite{insightsForProfessionalsParavirtualization} ή ακόμα και λογισμικά
|
||
ενσωματωμένων συστημάτων αυτοκινήτων \cite{blackberryParavirtualization}.
|
||
|
||
Παρ' όλα τα πλεονεκτήματα που παρέχει η χρήση της παρα-εικονικοποίησης,
|
||
υπάρχουν και μερικά ζητήματα που πρέπει να ληφθούν υπόψιν. Εξαιτίας της ανάγκης
|
||
τροποποίησης του λειτουργικού συστήματος των φιλοξενούμενων λειτουργικών
|
||
συστημάτων, κάτι που δεν είναι πάντοτε εφικτό, αυτά καθίστανται λιγότερο φορητά
|
||
σε σχέση με την πλήρη εικονικοποίηση, αφού τροποποιούνται για την υποστήριξη
|
||
συγκεκριμένου υλικού αντί ενός υπερ-επόπτη \cite{blackberryParavirtualization}.
|
||
Ταυτοχρόνως, η στενή εξάρτηση μεταξύ του υπερ-επόπτη και των φιλοξενούμενων ΛΣ
|
||
μπορεί να διακοπεί από τις ενημερώσεις του λειτουργικού συστήματος
|
||
\cite{insightsForProfessionalsParavirtualization}, κάνοντας την
|
||
παρα-εικονικοποίηση λιγότερο αξιόπιστη.
|
||
|
||
Στο Σχήμα \ref{fig:FullVirtualization}
|
||
\cite{geeksforgeeksParavirtualizationDefinition} παρουσιάζεται η αρχιτεκτονική
|
||
της πλήρους εικονικοποίησης όπου το φιλοξενούμενο λειτουργικό σύστημα (της
|
||
εικονικής μηχανής) επιβάλλεται να περάσει τα αιτήματά του (πρόσβασης πόρων)
|
||
μέσω του υπερ-επόπτη.
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .7\textwidth]{Figures/GeeksForGeeksParavirtualization/Full-Virualization.png}
|
||
\captionof{figure}{Πλήρης εικονικοποίηση \cite{geeksforgeeksParavirtualizationDefinition}}
|
||
\label{fig:FullVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
Αντιθέτως, στο Σχήμα \ref{fig:ParaVirtualization} όπου και φαίνεται η
|
||
αρχιτεκτονική της παρα-εικονικοποίησης, βλέπουμε πως μέσω των υπερ-κλήσεων, όλα
|
||
τα αιτήματα προορίζονται στη στρώση εικονικοποίησης και από εκεί στο κύριο
|
||
σύστημα (χωρίς την ανάγκη κάποιας επεξεργασίας ή μετάφρασης).
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .7\textwidth]{Figures/GeeksForGeeksParavirtualization/Paravirtualization.png}
|
||
\captionof{figure}{Παρα-εικονικοποίηση \cite{geeksforgeeksParavirtualizationDefinition}}
|
||
\label{fig:ParaVirtualization}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\clearpage
|
||
|
||
\noindent Οι διαφορές της πλήρους εικονικοποίησης με την παρα-εικονικοποίηση με
|
||
βάση τον οργανισμό \citeauthor{geeksforgeeksParavirtualizationDefinition}
|
||
\cite{geeksforgeeksParavirtualizationDefinition} είναι οι εξής:
|
||
|
||
\begin{savenotes} % by the package footnote because footfullcite did not work inside a tabular
|
||
\selectfont
|
||
\begin{table}[!ht]
|
||
\caption{Διαφορές πλήρους εικονικοποίησης και παρα-εικονικοποίησης}
|
||
\renewcommand{\arraystretch}{1.5}
|
||
\centering
|
||
\newcolumntype{C}{>{\centering\arraybackslash}m{5.5cm}}
|
||
\textgreek{\begin{tabular}{||c|C|C||}
|
||
\hline
|
||
|
||
Κριτήρια & Πλήρης εικονικοποίηση & Παρα-εικονικοποίηση \\ [0.5ex]
|
||
|
||
\hline\hline
|
||
|
||
Βαθμός απομόνωσης &
|
||
|
||
Πλήρης απομόνωση της εικονικής μηχανής. &
|
||
|
||
Μερική απομόνωση και χρήση API για αμεσότερη επικοινωνία. \\
|
||
|
||
\hline
|
||
|
||
Επίπεδο ασφάλειας &
|
||
|
||
Λιγότερο ασφαλής. &
|
||
|
||
Υπάρχει επίγνωση του εικονικού περιβάλλοντος και δε γίνεται εκκίνηση του BIOS
|
||
\cite{ParavirtualizationSecurity}, πράγμα που την καθιστά ασφαλέστερη. \\
|
||
|
||
\hline
|
||
|
||
Τρόπος λειτουργίας &
|
||
|
||
Χρήση δυαδικής μετάφρασης\footnote{\textgreek{Αυτό ισχύει στην περίπτωση
|
||
εικονικοποίησης υποβοηθούμενη από το λογισμικό.}}. &
|
||
|
||
Χρήση υπερ-κλήσεων κατά την εκτέλεση. \\
|
||
|
||
\hline
|
||
|
||
Απόδοση &
|
||
|
||
Πιο αργές ταχύτητες\footnote{\textgreek{Με βάση την VMware, η απόδοση της
|
||
παρα-εικονικοποίησης είναι καλύτερη υπό ορισμένες περιπτώσεις, ενώ η
|
||
πλήρης εικονικοποίηση με χρήση δυαδικής μετάφρασης παρέχει καλύτερη
|
||
απόδοση από την πρώτη γενιά εικονικοποίησης υποβοηθούμενη από το υλικό.}}
|
||
\cite{ParavirtualizationVmware}. &
|
||
|
||
Γρηγορότερη εκτέλεση. \\
|
||
|
||
\hline
|
||
|
||
Μεταφερσιμότητα &
|
||
|
||
Μεγαλύτερη συμβατότητα και μεταφερσιμότητα. &
|
||
|
||
Λόγω της αρχιτεκτονικής της είναι δυσκολότερη η μεταφορά εικονικών μηχανών (από
|
||
έναν φυσικό διακομιστή σε έναν άλλο) \\
|
||
|
||
\hline
|
||
|
||
Ευκολία χρήσης &
|
||
|
||
Υποστήριξη όλων των συστημάτων χωρίς την απαίτηση τροποποιήσεων. &
|
||
|
||
Απαιτείται τροποποίηση του φιλοξενούμενου λειτουργικού συστήματος για να κάνει
|
||
χρήση υπερ-κλήσεων. \\
|
||
|
||
\hline
|
||
\end{tabular}}
|
||
\label{table:virtualizationTypesDifferences}
|
||
\renewcommand{\arraystretch}{1}
|
||
\end{table}
|
||
\end{savenotes}
|
||
|
||
\subsection{Πλεονεκτήματα της εικονικοποίησης} \label{virtualizationAdvantages}
|
||
|
||
Η εικονικοποίηση προσφέρει πολλά πλεονεκτήματα στις επιχειρήσεις. Τα πιο
|
||
αξιοσημείωτα αυτών με βάση την \citeauthor{ibmVirtualizationDefinition}
|
||
\cite{ibmVirtualizationDefinition} είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Αποδοτικότητα πόρων}:
|
||
|
||
Η χρήση εικονικοποίησης συνεπάγεται την μείωση του αριθμού των φυσικών
|
||
μηχανημάτων που απαιτούνται για την εκτέλεση των εφαρμογών. Αυτό
|
||
συμβαίνει διότι εφόσον ένας φυσικός διακομιστής μπορεί να φιλοξενήσει
|
||
πολλαπλές εικονικές μηχανές, αυτές με την σειρά τους δύναται να
|
||
αντικαταστήσουν άλλους φυσικούς διακομιστές που θα ήταν απαραίτητοι για
|
||
την εκτέλεση διαφορετικών λειτουργιών \cite{mediumVirtualization}. Με
|
||
αυτόν τον τρόπο, εξοικονομείται η ενέργεια που θα απαιτούσε η διάθεση
|
||
των (έξτρα) υπολογιστικών πόρων των φυσικών μηχανημάτων που
|
||
αποσύρθηκαν, ενώ ταυτόχρονα αξιοποιούνται σε μεγαλύτερο βαθμό οι
|
||
υπολογιστικοί πόροι του μηχανήματος που φιλοξενεί τις εικονικές
|
||
μηχανές.
|
||
|
||
\item \textbf{Ευκολότερη διαχείριση}:
|
||
|
||
Αντικαθιστώντας φυσικούς υπολογιστές με προγραμματιστικά καθορισμένες
|
||
εικονικές μηχανές δύναται η χρήση αυτοματοποιημένων ροών διαχειριστικών
|
||
εργασιών. Οι διαχειριστές συστημάτων μπορούν να χρησιμοποιούν εργαλεία
|
||
για τον καθορισμό εικονικών μηχανών χρησιμοποιώντας πρότυπα κατάλληλα
|
||
για την υποδομή κάθε επιχείρησης. Με αυτόν τον τρόπο, η εγκατάσταση και
|
||
η ρύθμιση των εικονικών μηχανών μπορεί να γίνεται επανειλημμένα με
|
||
αυτοματοποιημένο τρόπο δίχως το ρίσκο ανθρώπινου λάθους και γλιτώνοντας
|
||
τον χρόνο εγκατάστασης και ρύθμισής τους χειροκίνητα. Ένας συνδυασμός
|
||
εργαλείων που κάνει αυτή τη διαδικασία πραγματικότητα είναι τα Ansible
|
||
\footfullcite{ansible} και Terraform \footfullcite{terraform}.
|
||
|
||
\item \textbf{Ελάχιστος χρόνος διακοπής λειτουργίας}:
|
||
|
||
Οι καταρρεύσεις λειτουργικών συστημάτων και εφαρμογών μπορεί να
|
||
προκαλέσουν διακοπή λειτουργίας και να διαταράξουν την παραγωγικότητα
|
||
των χρηστών. Οι διαχειριστές έχουν την δυνατότητα εκτέλεσης
|
||
πλεοναζουσών εικονικών μηχανών, με σκοπό την ταχεία εναλλαγή σε αυτές
|
||
στην περίπτωση που προκύψουν προβλήματα στις αρχικές (που έχουν
|
||
διατεθεί). Κάτι τέτοιο, δεν θα ήταν αποδοτικό για την επιχείρηση
|
||
διαθέτοντας αποκλειστικά μη εικονικοποιημένα φυσικά μηχανήματα.
|
||
|
||
\item \textbf{Ταχύτερη παροχή}:
|
||
|
||
Η αγορά, εγκατάσταση και διαμόρφωση του υλικού για κάθε εφαρμογή είναι
|
||
χρονοβόρα. Εφόσον το υλικό είναι ήδη στη θέση του και μπορεί να
|
||
εντοπίζεται και απομακρυσμένα (όπως στην περίπτωση περιβαλλόντων
|
||
νέφους), η παροχή εικονικών μηχανών για την εγκατάσταση και εκτέλεση
|
||
όλων των εφαρμογών είναι σημαντικά ταχύτερη.
|
||
|
||
\end{itemize}
|
||
|
||
\section{Ασφάλεια στην εικονικοποίηση} \label{virtualizationSecurity}
|
||
|
||
Η χρήση της εικονικοποίησης παρέχει αρκετά εγγενή οφέλη ασφαλείας με την μορφή
|
||
μέτρων ανάκαμψης από επιθέσεις. Ένα σημαντικό εξ αυτών, είναι η ικανότητα
|
||
επαναφοράς εικονικών μηχανών που έχουν μολυνθεί με κακόβουλο λογισμικό σε μια
|
||
χρονική περίοδο πριν τη μόλυνση τους. Αυτό επιτυγχάνεται μέσω της δυνατότητας
|
||
δημιουργίας στιγμιοτύπων εικονικών μηχανών \cite{vmSnapshots}, η οποία
|
||
παρέχεται από τον υπερ-επόπτη. Επιπρόσθετα, μπορεί εύκολα να πραγματοποιηθεί
|
||
διαγραφή και αναδημιουργία τους με έναν αυτοματοποιημένο τρόπο, σε περίπτωση
|
||
που η επαναφορά σε προηγούμενη χρονική περίοδο για οποιονδήποτε λόγο δεν είναι
|
||
εφικτή. Αυτή η λύση μπορεί να εφαρμοστεί χωρίς αρνητικές επιπτώσεις εάν τα
|
||
δεδομένα της εικονικής μηχανής είτε δεν μας ενδιαφέρουν, είτε βρίσκονται σε
|
||
διαφορετική τοποθεσία επειδή γίνεται χρήση εικονικοποίησης αποθήκευσης, είτε
|
||
υπάρχουν αντίγραφα ασφαλείας τους. Αυτές οι λειτουργίες είναι αρκετές φορές
|
||
αδύνατο να εφαρμοστούν σε ένα φυσικό μηχάνημα διότι το κακόβουλο λογισμικό
|
||
συχνά μπορεί να είναι βαθιά ριζωμένο στα βασικά συστατικά του συστήματος
|
||
\cite{ibmVirtualizationDefinition}. Επιπλέον, ακόμα και αν το κακόβουλο
|
||
λογισμικό ήταν σε θέση να εξαφανιστεί με μια επαναφορά, κάτι τέτοιο θα
|
||
χρειαζόταν σημαντικά περισσότερο χρόνο για να διεκπεραιωθεί σε ένα φυσικό
|
||
μηχάνημα συγκριτικά με μια εικονική μηχανή.
|
||
|
||
Παρ' όλα αυτά, η εικονικοποίηση δεν είναι απαλλαγμένη από κινδύνους καθώς
|
||
παραβιάζοντας τον υπερ-επόπτη, ένας επιτιθέμενος έχει πρόσβαση σε όλες τις
|
||
εικονικές μηχανές που διαχειρίζονται μέσω αυτού. Επίσης, αυτό είναι δυσκολότερο
|
||
να εντοπιστεί λόγω της ικανότητας του υπερ-επόπτη να επιτρέπει στις εικονικές
|
||
μηχανές τη μεταξύ τους επικοινωνία χωρίς την αλληλεπίδραση με το φυσικό δίκτυο.
|
||
Τέλος, η ακεραιότητα του συστήματος εξαρτάται άμεσα και από τον τύπο του
|
||
υπερ-επόπτη. Αυτό συμβαίνει διότι ειδικότερα για υπερ-επόπτες τύπου 2, υπάρχει
|
||
πολλές φορές η ανάγκη διαμοιρασμού δεδομένων μεταξύ των εικονικών μηχανών και
|
||
του ΛΣ φιλοξενίας. Επομένως, η παραβίαση ενός υπερ-επόπτη τύπου 2 μπορεί
|
||
δυνητικά να οδηγήσει στην εξάπλωση κακόβουλου λογισμικού και να κινδυνεύσει όλο
|
||
το σύστημα \cite{techtargetHypervisorSecurity}.
|
||
|
||
\subsection{Απειλές στην εικονικοποίηση} \label{virtualizationThreats}
|
||
|
||
Όλες οι μορφές εικονικοποίησης είναι ευάλωτες σε επιθέσεις. Όπως αναφέρεται και
|
||
στο \cite{wen2008sevmm} μέσω του \cite{arif2015virtualization}, πολλές φορές δε
|
||
δύναται ο υπερ-επόπτης, το λειτουργικό σύστημα ή ακόμα και η υπηρεσία ελέγχου
|
||
πρόσβασης (Mandatory Access Control) του Linux να ανταπεξέλθουν στις απαιτήσεις
|
||
ασφαλείας όλων των εφαρμογών. Το παράδειγμα που παρουσιάζεται στο
|
||
\cite{arif2015virtualization} αναφέρεται στην εικονικοποίηση χώρου αποθήκευσης
|
||
μέσω δικτύου αλλά πολλές από τις απειλές δεν περιορίζονται μονάχα εκεί.
|
||
|
||
\clearpage
|
||
|
||
\noindent Πολλές από τις απειλές που θα αναφερθούν παρακάτω στο
|
||
\ref{virtualizationThreatsCategorization}, μπορούν να κατηγοριοποιηθούν και ως
|
||
εξής:
|
||
|
||
\begin{table}[!ht]
|
||
\caption{Πηγές απειλών στην εικονικοποίηση}
|
||
\renewcommand{\arraystretch}{1.5}
|
||
\centering
|
||
\newcolumntype{C}{>{\centering\arraybackslash}m{6cm}}
|
||
\textgreek{\begin{tabular}{||C|C||}
|
||
\hline
|
||
|
||
Πηγή απειλής & Περιγραφή \\ [0.5ex]
|
||
|
||
\hline\hline
|
||
|
||
Δίκτυο $\Rightarrow$ Υπερ-επόπτη &
|
||
|
||
Απειλές που προέρχονται από το δίκτυο και στοχεύουν τον υπερ-επόπτη. \\
|
||
|
||
\hline
|
||
|
||
Δίκτυο $\Rightarrow$ Εικονική Μηχανή &
|
||
|
||
Απειλές που προέρχονται από το δίκτυο και στοχεύουν εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
|
||
Υπερ-επόπτη $\Rightarrow$ Εικονική Μηχανή &
|
||
|
||
Απειλές που προέρχονται από τον υπερ-επόπτη και στοχεύουν εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
|
||
Εικονική μηχανή $\Rightarrow$ Εικονική Μηχανή &
|
||
|
||
Απειλές που προέρχονται από εικονικές μηχανές και στοχεύουν άλλες εικονικές
|
||
μηχανές. \\
|
||
|
||
\hline
|
||
|
||
Εικονική μηχανή $\Rightarrow$ Υπερ-επόπτη &
|
||
|
||
Απειλές που προέρχονται από εικονικές μηχανές και στοχεύουν τον υπερ-επόπτη. \\
|
||
|
||
\hline
|
||
|
||
Διαχειριστή $\Rightarrow$ Υπερ-επόπτη &
|
||
|
||
Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν τον
|
||
υπερ-επόπτη. \\
|
||
|
||
\hline
|
||
|
||
Διαχειριστή $\Rightarrow$ Εικονική Μηχανή &
|
||
|
||
Απειλές που προέρχονται από τον διαχειριστή εικονικών μηχανών και στοχεύουν
|
||
εικονικές μηχανές. \\
|
||
|
||
\hline
|
||
\end{tabular}}
|
||
\label{table:virtualizationThreatSources}
|
||
\renewcommand{\arraystretch}{1}
|
||
\end{table}
|
||
|
||
\subsubsection{Απειλές για τον πάροχο νέφους μέσω δικτύου} \label{cloudProviderThreatsOverNetwork}
|
||
|
||
Σήμερα όλο και περισσότερες επιχειρήσεις θα προτιμήσουν να βασιστούν σε έναν
|
||
πάροχο νέφους για την απόκτηση υποδομών προκειμένου να εξυπηρετούν τους
|
||
δυνητικούς πελάτες τους έναντι της παραδοσιακής διαδικασίας αγοράς, ρύθμισης
|
||
και διαχείρισης φυσικών διακομιστών. Η ταχύτερη εκκίνηση παροχής υπηρεσιών, το
|
||
μικρότερο κόστος και η ευκολία διαχείρισης της υποδομής τους, δεν αφήνουν
|
||
περιθώρια αμφιβολίας της ορθότητας αυτής της απόφασης. Για να μπορούν όμως να
|
||
παρέχουν τις υπηρεσίες τους στους τελικούς χρήστες, είναι απαραίτητη η μεταφορά
|
||
δεδομένων από την επιχείρηση προς τον πάροχο νέφους, στις υποδομές του οποίου
|
||
στεγάζονται οι εφαρμογές τους. Όπως αναφέραμε όμως στο
|
||
\ref{cloudComputingSecurity}, εισάγεται έτσι ένα αναγκαίο μοντέλο εμπιστοσύνης
|
||
ανάμεσα στον πάροχο νέφους και τις επιχειρήσεις. Δηλαδή, ταυτόχρονη εμπιστοσύνη
|
||
ως προς την απουσία μη εξουσιοδοτημένης πρόσβασης στα δεδομένα των επιχειρήσεων
|
||
από τον πάροχο και ως προς την ικανότητα του παρόχου να λάβει τα απαραίτητα
|
||
μέτρα ασφαλείας για την προστασία τους από εξωτερικούς κακόβουλους χρήστες.
|
||
|
||
Ένα από τα σημαντικότερα ζητήματα που απασχολεί μια επιχείρηση είναι η
|
||
ασφάλεια. Επιλέγοντας να χρησιμοποιήσουν τις υπηρεσίες ενός παρόχου νέφους,
|
||
όμως, παραχωρούν ουσιαστικά πρόσβαση στον πάροχο αυτό στις εφαρμογές τους και
|
||
στα ευαίσθητα δεδομένα αυτών των εφαρμογών, διότι η ευθύνη προστασίας των
|
||
υποδομών ανήκει στον ιδιοκτήτη των υποδομών αυτών και στην προκειμένη περίπτωση
|
||
αυτός είναι ο πάροχος νέφους. Έτσι, κακόβουλοι εισβολείς θα προσπαθήσουν να
|
||
βρουν τρωτότητες στη διαδικασία παράδοσης των υπηρεσιών του παρόχου, στις
|
||
υπηρεσίες τις ίδιες ή και στις διεπαφές με τις οποίες παρέχονται. Ένας
|
||
συνηθισμένος τρόπος για να γίνει αυτό είναι εκτελώντας επιθέσεις τύπου
|
||
Cross-site scripting (XSS), έγχυσης SQL (SQL injection), χειραγώγησης cookies ή
|
||
εκμετάλλευσης μη ασφαλούς ρύθμισης, θέτοντας έτσι σε κίνδυνο ευαίσθητες
|
||
πληροφορίες και δεδομένα των επιχειρήσεων. Επιπλέον, επειδή όλα τα δίκτυα είναι
|
||
επιρρεπή σε επιθέσεις αν δεν έχουν ληφθεί τα κατάλληλα μέτρα προστασίας, ένας
|
||
πάροχος πρέπει να μπορεί να προστατευτεί από επιθέσεις, όπως η κατασκοπεία
|
||
(surveillance) και διείσδυση δικτύου (network penetration)
|
||
\cite{arif2015virtualization}.
|
||
|
||
\subsubsection{Απειλές για τον πάροχο νέφους μέσω εικονικών μηχανών} \label{cloudProviderAttackOverVMs}
|
||
|
||
Όπως μια επιχείρηση πρέπει να εμπιστεύεται τον πάροχο νέφους ότι θα
|
||
προστατεύσει τα δεδομένα της, έτσι και ο πάροχος πρέπει να εμπιστεύεται την
|
||
επιχείρηση ότι δε θα προσπαθήσει να προκαλέσει ζημιά στις υπηρεσίες του. Αυτό
|
||
μπορεί να πραγματοποιηθεί με την εκτέλεση κακόβουλου λογισμικού στις εικονικές
|
||
μηχανές του παρόχου είτε από την επιχείρηση την ίδια, είτε από έναν επιτιθέμενο
|
||
που παραβίασε τις εικονικές μηχανές της.
|
||
|
||
Ουσιαστικά, κάθε εικονική μηχανή που έχει πρόσβαση στο διαδίκτυο είναι ευάλωτη
|
||
σε απειλές όπως δούρειοι ίπποι (Trojans), ιοί και κακόβουλα λογισμικά που
|
||
μπορεί να εξαπλωθούν στο σύστημα μεταπηδώντας από μια εικονική μηχανή στον
|
||
υπερ-επόπτη και από εκεί είτε να συνεχίσουν στο σύστημα είτε να μολύνουν και
|
||
τις υπόλοιπες εικονικές μηχανές που αυτός διαχειρίζεται. Επομένως, ο πάροχος
|
||
απαιτείται να έχει λάβει τα κατάλληλα μέτρα προστασίας έναντι μολυσμένων ή
|
||
κακόβουλων εικονικών μηχανών.
|
||
|
||
Με βάση την ανάλυση που έγινε στο \cite{virtualizationSecurity}, υπάρχουν
|
||
διάφορες απειλές που εκμεταλλεύονται ευπάθειες των εικονικών μηχανών ή του
|
||
υποκείμενου υπερ-επόπτη τους. Από αυτές, οι πιο συνηθισμένες είναι η επίθεση
|
||
πλευρικού καναλιού (cross VM side channel attack), οι επιθέσεις βάσει
|
||
χρονοπρογραμματιστή (Scheduler based attacks) και οι επιθέσεις που στοχεύουν
|
||
τρωτότητες της διαδικασίας μετανάστευσης και επαναφοράς εικονικών μηχανών (VM
|
||
migration and rollback attacks). Από την άλλη, όσον αφορά τις απειλές από
|
||
εικονικές μηχανές προς τον υπερ-επόπτη, ανάμεσα στις πιο σημαντικές βρίσκονται
|
||
η μεταπήδηση εικονικής μηχανής (VM Hopping) και η απόδραση εικονικής μηχανής
|
||
(VM Escape). Τέλος, μερικές επιπρόσθετες απειλές σύμφωνα με τους
|
||
\citeauthor{Aalam_2021} \cite{Aalam_2021}, είναι η κλοπή εικονικών μηχανών και
|
||
η τροποποίηση του υπερ-επόπτη.
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = \textwidth]{Figures/ThreatsLitchfield/threats.png}
|
||
\captionof{figure}{Απειλές στην εικονικοποίηση \cite{litchfield2016virtualization}}
|
||
\label{fig:virtualizationThreats}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\noindent Ακολουθεί συνοπτική επεξήγηση των παραπάνω απειλών:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Επίθεση πλευρικού καναλιού}:
|
||
|
||
Κατά την επίθεση πλευρικού καναλιού, ο επιτιθέμενος, έχοντας πρόσβαση σε
|
||
μια εικονική μηχανή, προσπαθεί να ανακτήσει πληροφορίες από άλλες εικονικές
|
||
μηχανές του ίδιου φυσικού διακομιστή. Αυτό μπορεί να επιτευχθεί με την
|
||
παρακολούθηση και ανάλυση της χρήσης των πόρων του φυσικού διακομιστή, όπως
|
||
της μνήμης και του επεξεργαστή. Μέσα στις πληροφορίες που μπορεί να
|
||
ανακτηθούν μπορεί να βρίσκονται και ιδιωτικά κλειδιά κρυπτογράφησης, τα
|
||
οποία μπορούν αργότερα να χρησιμοποιηθούν για πραγματοποίηση επιθέσεων
|
||
ενδιάμεσου και παρακολούθησης δικτύου, όπως αναφέρεται στο
|
||
\cite{litchfield2016virtualization} μέσω του \cite{zhang2012crossvmkeys}.
|
||
|
||
\item \textbf{Επίθεση βάσει χρονοπρογραμματιστή}:
|
||
|
||
Σε μια επίθεση βάσει χρονοπρογραμματιστή, ο επιτιθέμενος προσπαθεί να
|
||
επηρεάσει τον χρονοπρογραμματιστή του υπερ-επόπτη προκειμένου να
|
||
καταναλώσει περισσότερο χρόνο επεξεργασίας στον επεξεργαστή του φυσικού
|
||
μηχανήματος, εισάγοντας διεργασίες με μεγαλύτερη προτεραιότητα. Έτσι,
|
||
μπορεί να επιτύχει την αποκλειστική χρήση του επεξεργαστή και να προκαλέσει
|
||
απώλεια απόδοσης στις υπόλοιπες εικονικές μηχανές.
|
||
|
||
\item \textbf{Επιθέσεις κατά της διαδικασίας μετανάστευσης και επαναφοράς}:
|
||
|
||
Στις επιθέσεις που στοχεύουν τη διαδικασία μετανάστευσης και επαναφοράς
|
||
εικονικών μηχανών, ο επιτιθέμενος προσπαθεί να επηρεάσει την
|
||
εμπιστευτικότητα των δεδομένων μιας εικονικής μηχανής. Ανά πάσα στιγμή,
|
||
ένας υπερ-επόπτης μπορεί να δημιουργεί στιγμιότυπα της κατάστασης μιας
|
||
εικονικής μηχανής προκειμένου να συνεχίσει την εκτέλεση σε αυτά, χωρίς να
|
||
το γνωρίζει ο χρήστης. Έτσι, δεδομένου ότι ένα κομμάτι του ιστορικού
|
||
εκτέλεσής της χάνεται, ο επιτιθέμενος προσπαθεί να εκμεταλλευτεί αυτό το
|
||
γεγονός για να αποκτήσει πρόσβαση σε ευαίσθητες πληροφορίες μιας εικονικής
|
||
μηχανής ενός παραβιασμένου υπερ-επόπτη (η οποία δεν εκτελείται επί της
|
||
παρούσης). Μπορεί για παράδειγμα να παρακάμψει κάποιους ελέγχους ασφαλείας
|
||
που κανονικά θα ήταν προγραμματισμένοι για την εκάστοτε εικονική μηχανή, ή
|
||
ακόμα και να αναιρέσει ορισμένες ενημερώσεις ασφαλείας της
|
||
\cite{vmrollbackattack}.
|
||
|
||
\item \textbf{Μεταπήδηση εικονικής μηχανής}:
|
||
|
||
Η μεταπήδηση εικονικής μηχανής, είναι μια μέθοδος επίθεσης κατά την οποία
|
||
ένας επιτιθέμενος, έχοντας παραβιάσει μια εικονική μηχανή μπορεί να
|
||
μεταπηδήσει από εκείνη σε μια άλλη \cite{technopediaVmHopping}. Αυτό
|
||
ευνοείται από το γεγονός ότι πολλές φορές, οι εικονικές μηχανές συνυπάρχουν
|
||
με άλλες στον ίδιο υπολογιστή. Έτσι, ένας επιτιθέμενος μπορεί να
|
||
εκμεταλλευτεί αδυναμίες στην δυνατότητα του υπερ-επόπτη να επιτρέπει την
|
||
πρόσβαση σε μια εικονική μηχανή από μια άλλη. Η επίθεση αυτή βασίζεται στην
|
||
γνώση πληροφοριών, όπως η διεύθυνση IP μιας εικονικής μηχανής. Έπειτα, αφού
|
||
μια εικονική μηχανή παραβιαστεί, δύναται ο επιτιθέμενος να διαχειριστεί την
|
||
ροή της δικτυακής κυκλοφορίας της, να δημιουργήσει άρνηση υπηρεσιών και να
|
||
τροποποιήσει τα αρχεία της, αλλοιώνοντας το αρχείο διαμόρφωσής της.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Απόδραση εικονικής μηχανής}:
|
||
|
||
Στις επιθέσεις απόδρασης εικονικής μηχανής, ένας επιτιθέμενος επιχειρεί
|
||
να χρησιμοποιήσει κακόβουλες εφαρμογές για να αποκτήσει πρόσβαση στον
|
||
υπερ-επόπτη. Αυτό μπορεί να επιτευχθεί με την εκμετάλλευση αδυναμιών
|
||
της απομόνωσης που προσφέρει ο υπερ-επόπτης στις εικονικές μηχανές και
|
||
ως αποτέλεσμα, να μπορέσει να ξεφύγει από τα όρια της εικονικής μηχανής
|
||
και να επηρεάσει όχι μόνο τις υπόλοιπες εικονικές μηχανές αλλά και το
|
||
κύριο σύστημα στο οποίο αυτές στεγάζονται \cite{abusaimeh2020virtual}.
|
||
|
||
\item \textbf{Κλοπή εικονικής μηχανής}:
|
||
|
||
Η κλοπή εικονικών μηχανών επιτυγχάνεται μετά από παραβίαση του υπερ-επόπτη.
|
||
Ένα γεγονός που μπορεί να πραγματοποιηθεί δίχως την ανάγκη φυσικής
|
||
πρόσβασης στο υποκείμενο μηχάνημα. Τα δεδομένα μιας εικονικής μηχανής
|
||
αποθηκεύονται σε έναν εικονικό δίσκο με την μορφή μιας εικόνας μηχανής.
|
||
Αυτό συμβαίνει για να μπορεί ένας υπερ-επόπτης να δημιουργεί αντίγραφα
|
||
ασφαλείας των εικονικών μηχανών και να μπορούν αυτά έπειτα να μεταφερθούν
|
||
σε ένα διαφορετικό φυσικό μηχάνημα. Ένας επιτιθέμενος, έχοντας πρόσβαση
|
||
στον υπερ-επόπτη, μπορεί να αντιγράψει αυτές τις εικόνες εικονικών μηχανών
|
||
στο δικό του μηχάνημα μέσω του διαδικτύου και έχοντας αρκετό χρόνο στην
|
||
διάθεσή του, να καταφέρει αργότερα να ανακτήσει ευαίσθητες πληροφορίες μέσα
|
||
από αυτές.
|
||
|
||
\item \textbf{Τροποποίηση του υπερ-επόπτη}:
|
||
|
||
Η τροποποίηση του υπερ-επόπτη πραγματοποιείται με την χρήση rootkit που
|
||
βασίζονται στις εικονικές μηχανές (VMBR - Virtual Machine Based
|
||
Rootkits). Πρόκειται για ένα κακόβουλο λογισμικό, το οποίο δύσκολα
|
||
ανιχνεύεται. Με την χρήση ενός VMBR μπορεί ένας κακόβουλος χρήστης να
|
||
παραβιάσει το φιλοξενούμενο ΛΣ της εικονικής μηχανής και έπειτα να
|
||
συνεχίσει στην παραβίαση του υπερ-επόπτη ή να παραβιάσει κατευθείαν τον
|
||
υπερ-επόπτη με σκοπό να αποκτήσει απόλυτο έλεγχο του συστήματος στο
|
||
οποίο αυτός εκτελείται.
|
||
|
||
\end{itemize}
|
||
|
||
\clearpage
|
||
|
||
\subsubsection{Κατηγοριοποίηση απειλών στην εικονικοποίηση} \label{virtualizationThreatsCategorization}
|
||
|
||
Οι προαναφερόμενες απειλές σε συνδυασμό με μερικές πιθανές ευπάθειες, έχουν
|
||
κατηγοριοποιηθεί από τους \citeauthor{virtualizationSecurity} στο
|
||
\cite{virtualizationSecurity} ως εξής:
|
||
|
||
\begin{table}[!ht]
|
||
\caption{Κατηγοριοποίηση απειλών και στην εικονικοποίηση}
|
||
\renewcommand{\arraystretch}{1.3}
|
||
\aboverulesep=-0.1ex
|
||
\belowrulesep=-0.1ex
|
||
\centering
|
||
\newcolumntype{C}{>{\centering\arraybackslash}m{7cm}}
|
||
\textgreek{\begin{tabular}{||C|C||}
|
||
\hline
|
||
Κατηγορία & Απειλές/Επιθέσεις και πιθανά ευπαθή σημεία \\ \hline\hline
|
||
\multirow{11}{*}{\hfil Απειλές/Επιθέσεις Δικτύου} & XML Signature Wrapping Attacks \\ \cmidrule(lr){2-2}
|
||
& Flooding Attacks (DDoS) \\ \cmidrule(lr){2-2}
|
||
& Metadata Spoofing Attacks \\ \cmidrule(lr){2-2}
|
||
& Insecure Web Apps \& APIs \\ \cmidrule(lr){2-2}
|
||
& Cross Site Scripting Attacks (XSS) \\ \cmidrule(lr){2-2}
|
||
& Port Scanning \\ \cmidrule(lr){2-2}
|
||
& Botnets \\ \cmidrule(lr){2-2}
|
||
& Spoofing Attacks \\ \cmidrule(lr){2-2}
|
||
& DNS Attacks \\ \cmidrule(lr){2-2}
|
||
& Sniffer Attacks \\ \cmidrule(lr){2-2}
|
||
& Denial of Service (DoS) \\ \hline
|
||
\multirow{9}{*}{\hfil Απειλές/Επιθέσεις για τον Πάροχο} & Sniffing Attacks \\ \cmidrule(lr){2-2}
|
||
& Spoofing Attacks \\ \cmidrule(lr){2-2}
|
||
& Denial of Service (DoS) \\ \cmidrule(lr){2-2}
|
||
& Cross VM Side Channel Attacks \\ \cmidrule(lr){2-2}
|
||
& VM Scheduler Based Attacks \\ \cmidrule(lr){2-2}
|
||
& VM Hopping \\ \cmidrule(lr){2-2}
|
||
& VM Escape \\ \cmidrule(lr){2-2}
|
||
& Dynamic Data Updates \\ \cmidrule(lr){2-2}
|
||
& Data Scavenging \\ \hline
|
||
\multirow{6}{*}{\hfil Απειλές/Επιθέσεις για τις Εφαρμογές} & Malware Injection \\ \cmidrule(lr){2-2}
|
||
& Steganography Attacks \\ \cmidrule(lr){2-2}
|
||
& Web Services Attacks \\ \cmidrule(lr){2-2}
|
||
& Protocol Based Attacks \\ \cmidrule(lr){2-2}
|
||
& Security Misconfigurations \\ \cmidrule(lr){2-2}
|
||
& SQL Injection Attacks \\ \hline
|
||
\end{tabular}}
|
||
\label{table:virtualizationThreatCategories}
|
||
\renewcommand{\arraystretch}{1}
|
||
\end{table}
|
||
|
||
\clearpage
|
||
|
||
\noindent Μια πιο εκτενής κατηγοριοποίηση για την κατηγορία των απειλών σε
|
||
εφαρμογές, πραγματοποιήθηκε από τον οργανισμό
|
||
\citeauthor{enisaSecurityOfVirtualization} στο
|
||
\cite{enisaSecurityOfVirtualization} όπου και απεικονίζεται στο ακόλουθο σχήμα:
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = .91\textwidth]{Figures/Enisa/enisaThreats.jpg}
|
||
\captionof{figure}{Πιθανά σημεία εμφάνισης τρωτοτήτων και οι απειλές που τους αντιστοιχούν \cite{enisaSecurityOfVirtualization}}
|
||
\label{fig:virtualizationThreats.png}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\subsection{Η τριάδα της ασφάλειας} \label{securityTriad}
|
||
|
||
Εν γένει, ο λόγος που μια επιχείρηση ενδιαφέρεται για την ασφάλεια, είναι
|
||
προκειμένου να διασφαλίσει την ακεραιότητα, την εμπιστευτικότητα και τη
|
||
διαθεσιμότητα των περιουσιακών στοιχείων (assets) που μεταφέρει στο νέφος. Αυτά
|
||
τα τρία στοιχεία αποτελούν την τριάδα της ασφάλειας \cite{ciaTriad} και η
|
||
απώλεια οποιουδήποτε από αυτά μπορεί να έχει σοβαρές επιπτώσεις για την
|
||
επιχείρηση. Η σημασία του καθενός, καθώς και γενικές ορθές πρακτικές διατήρησής
|
||
τους περιγράφονται ως εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Ακεραιότητα δεδομένων} \label{dataIntegrity}
|
||
|
||
Η ακεραιότητα των δεδομένων είναι ένα από τα τρία βασικά στοιχεία της
|
||
ασφάλειας, δίχως την οποία οι επιχειρήσεις δε θα μπορούσαν να
|
||
παραμείνουν λειτουργικές. Αναφέρεται στην προστασία των δεδομένων από
|
||
μη εξουσιοδοτημένη αλλοίωση καθ' όλη τη διάρκεια της ύπαρξής τους, είτε
|
||
αυτά βρίσκονται στο στάδιο της μεταφοράς, την επεξεργασίας ή της
|
||
αποθήκευσης. Για κάθε επιχείρηση, απαιτείται μεγάλη προσοχή κατά τον
|
||
σχεδιασμό των βάσεων δεδομένων και της συντήρησής τους σε περιβάλλοντα
|
||
νέφους αλλά και η χρήση ορθών πρακτικών, όπως ο περιοδικός έλεγχος των
|
||
δεδομένων για την ανίχνευση πιθανών αλλοιώσεων και η χρήση μηχανισμών
|
||
αναγνώρισης και αποκατάστασης σφαλμάτων. Επιπρόσθετα, απαιτείται να
|
||
υπάρχει και κατάλληλος έλεγχος πρόσβασης, αφού η πρόσβαση από μη
|
||
εξουσιοδοτημένους φορείς αποτελεί απειλή για την ακεραιότητα των
|
||
δεδομένων.
|
||
|
||
\item \textbf{Εμπιστευτικότητα δεδομένων} \label{dataConfidentiality}
|
||
|
||
Όπως η ακεραιότητα, έτσι και η εμπιστευτικότητα των δεδομένων είναι
|
||
κάτι για το οποίο μια επιχείρηση πρέπει να φροντίσει εκ των προτέρων.
|
||
Αναφέρεται στην προστασία των δεδομένων από μη εξουσιοδοτημένη πρόσβαση
|
||
κατά τη μεταφορά, την αποθήκευση και την επεξεργασία τους. Ένα κενό
|
||
ασφαλείας στην τελική εφαρμογή ενός χρήστη μπορεί να δώσει πρόσβαση σε
|
||
έναν εισβολέα παραβιάζοντας έτσι τις βάσεις δεδομένων της επιχείρησης.
|
||
Επειδή σε ένα περιβάλλον νέφους δεν έχει η ίδια η επιχείρηση πρόσβαση
|
||
στις υποδομές που χρησιμοποιεί, πέρα από μέτρα προστασίας που θα πρέπει
|
||
να λάβει η ίδια, όπως η διασφάλιση ύπαρξης ρυθμίσεων ασφαλείας και
|
||
μηχανισμών περιορισμού πρόσβασης στα δεδομένα της, είναι απαραίτητη και
|
||
η επικοινωνία με τον πάροχο νέφους προκειμένου να διαπιστωθεί ο τρόπος
|
||
εξασφάλισης της εμπιστευτικότητας των δεδομένων από μεριάς του.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Διαθεσιμότητα δεδομένων} \label{dataAvailability}
|
||
|
||
Η διαθεσιμότητα των δεδομένων, που ολοκληρώνει την τριάδα της
|
||
ασφάλειας, είναι το στοιχείο που εξασφαλίζει πως μια επιχείρηση θα
|
||
μπορεί να παρέχει τις υπηρεσίες της στους τελικούς της χρήστες.
|
||
Αναφέρεται στην αποφυγή της διακοπής πρόσβασης στα δεδομένα της
|
||
επιχείρησης από εξουσιοδοτημένους φορείς και εξαρτάται άμεσα από τη
|
||
συνεχή παροχή υπηρεσιών υποδομών προς την επιχείρηση. Η απώλεια της
|
||
διαθεσιμότητας θα είχε ως αποτέλεσμα την διακοπή σημαντικών λειτουργιών
|
||
της επιχείρησης και δυνητικά την μείωση της αξιοπιστίας της. Για να
|
||
μπορέσει να διασφαλιστεί, πρέπει μια επιχείρηση να έχει προβλέψει για
|
||
ένα σχέδιο ανάκτησης εφεδρικών αντιγράφων προς αποφυγή της απώλειας
|
||
σημαντικών δεδομένων της, καθώς και για ένα σχέδιο επαναφοράς των
|
||
διαδικασιών παροχής τους ώστε να μειώσει στο ελάχιστο την οποιαδήποτε
|
||
διάρκεια διακοπής των υπηρεσιών της. Τέλος, πρέπει να υπάρχει
|
||
εμπιστοσύνη προς τον πάροχο νέφους πως δεν θα υπάρξει από μεριάς του
|
||
απρόσμενη διακοπή της λειτουργίας υποδομών που μπορεί να είναι
|
||
απαραίτητες για την επιχείρηση.
|
||
|
||
\end{itemize}
|
||
|
||
\subsection{Μέτρα ασφαλείας} \label{securityMeasures}
|
||
|
||
Προκειμένου να προστατευτεί μια επιχείρηση από τις απειλές που αναφέρθηκαν
|
||
παραπάνω, θα πρέπει αυτή να έχει λάβει τα κατάλληλα μέτρα ασφαλείας. Μερικές
|
||
ορθές πρακτικές με βάση τους οργανισμούς
|
||
\citeauthor{geeksforgeeksVirtualizationSecurityGoodPractices}
|
||
\cite{geeksforgeeksVirtualizationSecurityGoodPractices} και
|
||
\citeauthor{enisaSecurityOfVirtualization} \cite{enisaSecurityOfVirtualization}
|
||
είναι οι παρακάτω:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Συχνή ενημέρωση του υπερ-επόπτη}:
|
||
|
||
Ο υπερ-επόπτης είναι ο πυρήνας του συστήματος εικονικοποίησης και
|
||
επομένως η ασφάλειά του είναι ζωτικής σημασίας. Οι εταιρείες που
|
||
αναπτύσσουν το λογισμικό του, τον ενημερώνουν συχνά για να διορθώσουν
|
||
τυχόν ευπάθειες που έχουν ανακαλυφθεί. Επομένως, οι επιχειρήσεις πρέπει
|
||
να εφαρμόζουν τις ενημερώσεις αυτές το συντομότερο δυνατόν από την
|
||
στιγμή που θα είναι διαθέσιμες.
|
||
|
||
\item \textbf{Περιορισμός πρόσβασης στο διαχειριστικό πάνελ του υπερ-επόπτη}:
|
||
|
||
Η πρόσβαση στον υπερ-επόπτη παρέχει πλήρη έλεγχο στις λειτουργίες του
|
||
και επομένως, πρέπει να περιορίζεται μόνο σε ένα πολύ μικρό αριθμό από
|
||
εξουσιοδοτημένα άτομα. Επιπλέον, οι επιχειρήσεις πρέπει να επιβάλλουν
|
||
την χρήση πολύπλοκων κωδικών πρόσβασης και να τους αλλάζουν τακτικά,
|
||
καθώς και την χρήση αυθεντικοποίησης πολλαπλών παραγόντων.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Έλεγχος των μηχανημάτων που έχουν πρόσβαση στον υπερ-επόπτη}:
|
||
|
||
Οι επιχειρήσεις πρέπει να ελέγχουν συχνά ποια μηχανήματα έχουν πρόσβαση
|
||
στον υπερ-επόπτη και να προσθέτουν ή να αφαιρούν μηχανήματα από την
|
||
σχετική λίστα εξουσιοδότησης. Ο συχνός έλεγχος πρόσβασης θα μπορέσει
|
||
επίσης να αναδείξει προσπάθειες μη εξουσιοδοτημένης πρόσβασης ώστε να
|
||
ληφθούν τα κατάλληλα μέτρα περιορισμού των ατόμων που επιχειρούν να
|
||
εισέλθουν στον υπερ-επόπτη.
|
||
|
||
\item \textbf{Περιορισμός δικτυακής πρόσβασης στο διαχειριστικό πάνελ του υπερ-επόπτη}:
|
||
|
||
Η πρόσβαση στο διαχειριστικό πάνελ του υπερ-επόπτη πρέπει να
|
||
πραγματοποιείται μόνο από ασφαλή δίκτυα. Επομένως, για την επιβολή
|
||
περιορισμών θα πρέπει να γίνεται χρήση αναχωμάτων ασφαλείας και άλλων
|
||
εργαλείων ασφαλείας του δικτύου.
|
||
|
||
\item \textbf{Χρήση κρυπτογράφησης εικονικών μηχανών}:
|
||
|
||
Η κρυπτογράφηση των εικονικών μηχανών προστατεύει τα δεδομένα τους από
|
||
μη εξουσιοδοτημένη πρόσβαση. Επιπλέον, στην περίπτωση κλοπής εικονικής
|
||
μηχανής μετά από παραβίαση του υπερ-επόπτη, ο επιτιθέμενος δεν θα είναι
|
||
σε θέση να αποκτήσει πρόσβαση στα δεδομένα της.
|
||
|
||
\item \textbf{Απομόνωση των εικονικών μηχανών μεταξύ τους}:
|
||
|
||
Ένας υπερ-επόπτης πρέπει να επιτρέπει την αλληλεπίδραση μεταξύ
|
||
εικονικών μηχανών μόνο όταν αυτό είναι απαραίτητο (παραδείγματος χάριν,
|
||
για τον διαμοιρασμό αποθηκευτικού χώρου). Επιβάλλεται να εφαρμοστούν
|
||
πολιτικές που να διαχειρίζονται την φυσική και λογική κατάτμηση πόρων.
|
||
Αυτό θα αποτρέψει την μη εξουσιοδοτημένη πρόσβαση, θα μειώσει τις
|
||
επιθέσεις έγχυσης κώδικα από μια εικονική μηχανή σε μια άλλη, τις
|
||
επιθέσεις πλευρικού καναλιού, καθώς και το ρίσκο επίθεσης τύπου άρνησης
|
||
υπηρεσίας.
|
||
|
||
\item \textbf{Παρακολούθηση των πόρων}:
|
||
|
||
Η δικτυακή κίνηση, η μνήμη και οι διεργασίες των εκτελούμενων εικονικών
|
||
μηχανών πρέπει να παρακολουθούνται διαρκώς προκειμένου να ξεχωρίζουν οι
|
||
εικονικές μηχανές που παρουσιάζουν ασυνήθιστες συμπεριφορές. Αυτό θα
|
||
βοηθήσει στην ορθότερη εκτέλεση υπαρχόντων μηχανισμών ασφαλείας και
|
||
ανίχνευσης εισβολών.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Ορθή διαχείριση στιγμιοτύπων εικονικών μηχανών}:
|
||
|
||
Κάθε στιγμιότυπο μιας εικονικής μηχανής, δύναται να περιέχει ευαίσθητα
|
||
δεδομένα, όπως κωδικοί και προσωπικά δεδομένα χρηστών. Συνεπώς, πρέπει
|
||
αυτά να προστατεύονται κατά την αποθήκευσή τους έναντι μη
|
||
εξουσιοδοτημένης πρόσβασης, τροποποίησης και αντικατάστασης. Αυτό
|
||
περιλαμβάνει την ορθή κρυπτογράφησή τους και την διαγραφή όσων
|
||
στιγμιοτύπων δεν χρειάζονται πλέον.
|
||
|
||
\item \textbf{Ασφάλιση του μηχανήματος φιλοξενίας}:
|
||
|
||
Το μηχάνημα φιλοξενίας αποτελεί ένα από τα πιο σημαντικά σημεία που
|
||
πρέπει να προστατευτούν. Αν ένας εισβολέας καταφέρει να αποκτήσει
|
||
πρόσβαση σε αυτό, θα μπορεί να αποκτήσει πρόσβαση σε όλες τις εικονικές
|
||
μηχανές που αυτό φιλοξενεί. Επομένως, οι επιχειρήσεις πρέπει να εφαρμόζουν
|
||
τακτικά ενημερώσεις λογισμικού, να περιορίζουν την πρόσβαση στο
|
||
μηχάνημα, να εφαρμόζουν πολύπλοκους κωδικούς πρόσβασης και να
|
||
παρακολουθούν την πρόσβαση σε αυτό.
|
||
|
||
\item \textbf{Σκλήρυνση των εικονικών μηχανών}:
|
||
|
||
Οι εικονικές μηχανές πρέπει να σκληρύνουν προκειμένου να περιοριστεί η
|
||
πρόσβαση σε αυτές, διότι πολύ συχνά αποτελούν σημείο εισόδου για την
|
||
εξάπλωση κακόβουλου λογισμικού. Αυτό περιλαμβάνει μεταξύ άλλων την
|
||
απενεργοποίηση υπηρεσιών που δεν χρειάζονται και την εφαρμογή πολιτικών
|
||
πρόσβασης και ασφαλείας.
|
||
|
||
\end{itemize}
|
||
|
||
\section{Δοχεία και δοχειοποίηση (containerization)} \label{containersAndContainerization}
|
||
|
||
Τα δοχεία αποτελούν και αυτά κομμάτι των τεχνολογιών εικονικοποίησης αλλά σε
|
||
επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
|
||
δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
|
||
(containerization). Σε αντίθεση με την εικονικοποίηση διακομιστών που
|
||
αναφέρθηκε στην Ενότητα \ref{virtualizationTechnologiesIntroduction}, για την
|
||
δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
|
||
αναλαμβάνει η μηχανή δοχείων.
|
||
|
||
Τα απαραίτητα συστατικά για την επίτευξη της δοχειοποίησης είναι μια εικόνα
|
||
δοχείου και μια μηχανή δοχείων. Στην εικόνα δοχείου εμπεριέχονται τα συστατικά
|
||
μέρη ενός λογισμικού και οδηγίες συναρμολόγησής του προς ανάγνωση από την
|
||
μηχανή δοχείων. Η συναρμολόγηση αυτή πραγματοποιείται σε στρώσεις. Δηλαδή, για
|
||
να φτάσουμε στο τελικό αποτέλεσμα, κάθε αυτοτελές κομμάτι του λογισμικού
|
||
εισάγεται πάνω από το προηγούμενό του. Από εκεί και πέρα, για την δημιουργία
|
||
δοχείων από τις αντίστοιχες εικόνες τους υπάρχει μια αλληλουχία βημάτων που
|
||
πρέπει να περαιωθεί. Αρχικά, η μηχανή δοχείων θα προσπελάσει την εικόνα δοχείου
|
||
προκειμένου να εξακριβώσει τις προδιαγραφές του. Έπειτα, με την βοήθεια των
|
||
μεθόδων απομόνωσης που έχει στην διάθεσή της μέσω των μηχανισμών
|
||
εικονικοποίησης του πυρήνα του λειτουργικού συστήματος φιλοξενίας, θα
|
||
δημιουργήσει ένα εικονικό περιβάλλον απομονωμένο από το ήδη υπάρχον φυσικό και
|
||
τέλος, θα πραγματοποιήσει εκκίνηση του δοχείου ως διεργασία του συστήματος.
|
||
|
||
Ορισμένα από τα βήματα δημιουργίας των δοχείων περιλαμβάνουν και άλλες
|
||
διαδικασίες για τις οποίες είναι υπεύθυνα συγκεκριμένα προγράμματα με τα οποία
|
||
συνεργάζεται η μηχανή δοχείων. Σε κάθε περίπτωση, θα χρησιμοποιηθεί ένα
|
||
πρόγραμμα για τον ρόλο ενός Container Runtime χαμηλού επιπέδου, όπως είναι το
|
||
runC. Αυτού του είδους τα προγράμματα είναι υπεύθυνα για την επικοινωνία με τον
|
||
πυρήνα του ΛΣ φιλοξενίας ώστε να ξεκινήσουν οι διαδικασίες χαμηλού επιπέδου,
|
||
όπως η ανάθεση χώρων ονομάτων και ομάδων ελέγχου σε δοχεία. Υπάρχουν και
|
||
μηχανές δοχείων χαμηλού επιπέδου έναντι των πιο γνωστών υψηλού επιπέδου όπως το
|
||
Docker, στις οποίες λείπουν ορισμένες λειτουργίες, όπως η απόκτηση εικόνων
|
||
δοχείων από ένα κεντρικό αποθετήριο και ο έλεγχος εγκυρότητας των ρυθμίσεων των
|
||
εικόνων αυτών. Οι μηχανές δοχείων υψηλού επιπέδου είναι ουσιαστικά μια συλλογή
|
||
εργαλείων που διευκολύνουν την δοχειοποίηση απαλλάσσοντας τον χρήστη από την
|
||
ανάγκη της χειροκίνητης εκτέλεσης των βημάτων της
|
||
\cite{sysdigContainerRuntime}. Αυτές αναλαμβάνουν πολλές φορές ονομάζονται και
|
||
Container Runtimes υψηλού επιπέδου \cite{containerRuntime}.
|
||
|
||
\subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}
|
||
|
||
Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux,
|
||
διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
|
||
(λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
|
||
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών,
|
||
καθώς και οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την
|
||
δυνατότητα περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα
|
||
αρχείων. Με την βοήθεια των εργαλείων αυτών, δύναται να πραγματοποιηθεί
|
||
εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος εικονικοποίησης λογισμικού όπου ο
|
||
πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη πολλαπλών απομονωμένων περιβαλλόντων
|
||
\cite{teimouriOsVirtualizationDefinition}, τα οποία έπειτα θα συμπεριφέρονται
|
||
ως ξεχωριστά συστατικά λογισμικού \cite{webopediaOsVirtualizationDefinition}.
|
||
|
||
Μια από τις υποχρεώσεις της μηχανής δοχείων είναι η επικοινωνία με τον πυρήνα
|
||
του λειτουργικού συστήματος φιλοξενίας για να επιτευχθεί αυτή η εικονικοποίηση.
|
||
Ουσιαστικά, η μηχανή δοχείων λειτουργεί ως διαμεσολαβητής των δοχείων για να
|
||
μοιράζονται το ίδιο λειτουργικό σύστημα και κατά προέκταση τους υποκείμενους
|
||
πόρους του μεταξύ τους. Αυτό συμβαίνει διότι αυτή αιτείται από το λειτουργικό
|
||
σύστημα να επιτρέψει την απομόνωση των διεργασιών που εκτελούνται σε χώρους
|
||
ονομάτων και να αναθέσει αποκλειστικούς πόρους συστήματος σε αυτές. Με αυτό τον
|
||
τρόπο, οι διεργασίες είναι ανεξάρτητες μεταξύ τους και απομονωμένες ενώ
|
||
διαμοιράζονται με ασφαλή τρόπο (σε ένα βαθμό) τους πόρους του συστήματος. Ένα
|
||
δοχείο μπορεί να θεωρηθεί πως αντιστοιχεί σε μια τέτοια απομονωμένη διεργασία.
|
||
|
||
Το τελικό επιθυμητό αποτέλεσμα της δοχειοποίησης είναι η δημιουργία ενός
|
||
απομονωμένου περιβάλλοντος (δηλ. το εκτελέσιμο \textquote{δοχείο}) στο οποίο
|
||
πραγματοποιείται η εκτέλεση ενός λογισμικού με βιβλιοθήκες και εξαρτήσεις
|
||
διαφορετικών εκδόσεων συγκριτικά με αυτές που μπορεί να προϋπάρχουν στο
|
||
σύστημα. Το περιβάλλον αυτό είναι υποχρεωμένο να χρησιμοποιήσει ένα υποσύνολο
|
||
των πόρων του συστήματος που του απονεμήθηκε μέσω της μηχανής δοχείων και
|
||
αναμένεται να εκτελείται με την ίδια συμπεριφορά ανεξαρτήτως υποδομής. Τα
|
||
παραπάνω είναι εφικτά και με την χρήση εικονικών μηχανών αλλά με κόστος την
|
||
επιβάρυνση του συστήματος φιλοξενίας λόγω της αδυναμίας διαμοιρασμού των πόρων
|
||
με τον τρόπο που το επιτυγχάνουν τα δοχεία. Το γεγονός ότι κάθε δοχείο
|
||
μοιράζεται τον ίδιο πυρήνα του λειτουργικού συστήματος φιλοξενίας με τα
|
||
υπόλοιπα δοχεία, έχει ως αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για
|
||
εικονικοποίηση μηχανών με σκοπό την στέγαση ενός ολόκληρου ξεχωριστού
|
||
λειτουργικού συστήματος (όπως γίνεται στις εικονικές μηχανές). Επιπλέον, κάθε
|
||
στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα στιγμιότυπο λογισμικού,
|
||
δύναται να χρησιμοποιηθεί ταυτοχρόνως από περισσότερα του ενός δοχεία προς
|
||
αποφυγή διπλής αποθήκευσης \cite{codemotionContainerImages}. Αυτό το
|
||
χαρακτηριστικό συμβάλλει στην εξάλειψη περιττής υπολογιστικής ισχύος. Τέλος,
|
||
κάθε εικόνα δοχείου μπορεί να χρησιμοποιηθεί ως πρότυπο για την δημιουργία μιας
|
||
καινούριας, καθιστώντας έτσι ευκολότερη την επεκτασιμότητα ενός λογισμικού σε
|
||
αντίθεση με τις εικονικές μηχανές, όπου κάθε νέο στιγμιότυπό τους απαιτεί την
|
||
επαναληπτική εκτέλεση των βημάτων δημιουργίας τους.
|
||
|
||
\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 Containers) \footfullcite{LXC}. Το πρώτο
|
||
εργαλείο που χρησιμοποιούσε τεχνολογίες δοχείων για την δημιουργία και εκτέλεση
|
||
πολλαπλών λειτουργικών συστημάτων Linux στο ίδιο μηχάνημα. Χρησιμοποιώντας
|
||
μηχανισμούς που προσέφερε το λειτουργικό σύστημα, επέτρεπε την πλήρη
|
||
εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε αρκετές
|
||
λειτουργίες, όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων. Παρ' όλα
|
||
αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
|
||
εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
|
||
όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||
|
||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
|
||
ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
|
||
του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί ευρέως. Όλα τα
|
||
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
|
||
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
|
||
(Platform as a Service) (Πλατφόρμα ως Υπηρεσία) και μέσω αυτού, παρέχεται μια
|
||
πλατφόρμα με μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση,
|
||
ενημέρωση και διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC,
|
||
το Docker αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την
|
||
δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα,
|
||
τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
|
||
(φιλοξενίας), παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων
|
||
δοχείων, όπως είναι το Docker Hub \footfullcite{dockerhub}, το επίσημο
|
||
αποθετήριο του Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθετήριο
|
||
της Red Hat και οποιοδήποτε άλλο αποθετήριο συμβατό με τις προδιαγραφές που
|
||
έχει ορίσει η ανοικτή δομή διοίκησης OCI (Open Container Initiative)
|
||
\footfullcite{oci}. Μέσω υπηρεσιών αυτού του είδους, οι χρήστες έχουν πρόσβαση
|
||
και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να ολοκληρώσουν
|
||
διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια μηχανή
|
||
δοχείων υψηλού επιπέδου, όλες οι λειτουργίες που θα απαιτούσαν εξειδικευμένες
|
||
γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε απλές εντολές.
|
||
Έτσι, καθίσταται εύκολη η χρήση του Docker για προγραμματιστές κάθε επιπέδου
|
||
και απλοποιείται κατά πολύ την διαδικασία ανάπτυξης και παράδοσης κατανεμημένων
|
||
εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή, έλεγχο εκδόσεων
|
||
(version control) για δοχεία \cite{LXCvsDocker2} και ένα οικοσύστημα γύρω από
|
||
όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει το LXC.
|
||
|
||
\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
|
||
|
||
Ο λόγος που πολλές επιχειρήσεις στρέφονται στην χρήση της δοχειοποίησης είναι
|
||
διότι με την παραδοσιακή μέθοδο ανάπτυξης λογισμικού, υπήρχε πάντα το ρίσκο ένα
|
||
πρόγραμμα που αναπτύχθηκε σε ένα συγκεκριμένο περιβάλλον να μη λειτουργεί με
|
||
τον αναμενόμενο τρόπο κατά τη μεταφορά του σε ένα άλλο, εκτός εάν έχει ελεγχθεί
|
||
ότι υπάρχουν όλες οι εξαρτήσεις που χρειάζεται, στις εκδόσεις που τις
|
||
χρειάζεται. Ακόμα και σε αυτήν την περίπτωση όμως, πέραν του κόπου για τον
|
||
έλεγχο και τον παράγοντα ανθρώπινου λάθους, είναι αρκετά πιθανό ένα άλλο
|
||
πρόγραμμα να χρειάζεται διαφορετικές εκδόσεις των ίδιων εξαρτήσεων. Αυτό
|
||
πρακτικά σήμαινε πως το έτερο αυτό πρόγραμμα θα έπρεπε να στεγαστεί σε
|
||
διαφορετικό διακομιστή, αυξάνοντας το σχετικό κόστος.
|
||
|
||
Τα παραπάνω προβλήματα έρχεται να λύσει η τεχνολογία της δοχειοποίησης, αφού
|
||
αυτή καθιστά δυνατή την συστέγαση δοχείων, δηλ. διαφορετικών προγραμμάτων ή
|
||
συστατικών προγραμμάτων στο ίδιο μηχάνημα (είτε αυτό είναι φυσικό είτε
|
||
εικονικό) και μάλιστα με λιγότερη επιβάρυνση συγκριτικά με την χρήση εικονικών
|
||
μηχανών. Όπως αναφέραμε και στην Ενότητα \ref{containerManagement}, από το 2013
|
||
και έπειτα, η άφιξη του Docker επιτάχυνε κατά πολύ την υιοθέτηση της
|
||
τεχνολογίας αυτής. Σε τέτοιο βαθμό, που σε μια έρευνα της IBM
|
||
\cite{ibmContainerSurvey} βρέθηκε πως το 61\% όσων ξεκίνησαν να χρησιμοποιούν
|
||
δοχεία, το κάνουν στο 50\% ή παραπάνω των εφαρμογών που δημιούργησαν τα
|
||
τελευταία δύο χρόνια, ενώ 64\% αυτών, αναμένουν στο 50\% των υπαρχουσών
|
||
εφαρμογών τους να κάνουν χρήση δοχείων στα επόμενα δύο χρόνια.
|
||
|
||
Ένας ακόμα λόγος που επιτάχυνε την υιοθέτηση της τεχνολογίας της δοχειοποίησης,
|
||
είναι πως τα τελευταία χρόνια έχουν αλλάξει δραματικά και οι μέθοδοι ανάπτυξης
|
||
και παράδοσης εφαρμογών. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο
|
||
καταρράκτη (waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα
|
||
συγκεκριμένο αμετάβλητο σχέδιο ανάπτυξης που καλούνταν να ακολουθήσει μια ομάδα
|
||
ανάπτυξης λογισμικού, έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς
|
||
αλλάζουν συνεχώς, με αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που
|
||
να ανταποκρίνονται τάχιστα στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί
|
||
μεθοδολογίες όπως η Agile \cite{agile} κατά την οποία η ανάπτυξη και η παράδοση
|
||
λογισμικού πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις
|
||
προκειμένου να προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό
|
||
σχεδιασμό. Η μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps
|
||
\cite{devops} όπου οι ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας
|
||
εφαρμογής επικοινωνούν στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και
|
||
παράδοσης λογισμικού. Αυτό επιτυγχάνεται με μια πρακτική του DevOps, το CI/CD
|
||
(Continuous Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής
|
||
Παράδοση) \cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες
|
||
διαδικασίες που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας
|
||
εφαρμογής προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
|
||
εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα τα οποία έπειτα
|
||
παραδίδονται στους πελάτες. Μάλιστα, μπορεί να υποστηρίζεται και η Συνεχής
|
||
Διάταξη (Continuous Deployment - CD) όπου τα εκτελέσιμα πακέτα των εφαρμογών
|
||
διατάσσονται σε περιβάλλοντα παραγωγής και γίνονται άμεσα διαθέσιμα προς
|
||
απομακρυσμένη κατανάλωση από τους πελάτες τους.
|
||
|
||
Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
|
||
και πρακτικών, καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
|
||
εφαρμογών (ή συστατικών (components) εφαρμογής) και την εκτέλεσή τους σε
|
||
οποιαδήποτε πλατφόρμα ή περιβάλλον νέφους. Λόγω των χαρακτηριστικών τους,
|
||
εξαλείφουν τυχόν προβλήματα ασυμβατότητας μεταξύ των περιβαλλόντων εκτέλεσής
|
||
τους και προσφέρουν μεγαλύτερη αποδοτικότητα πόρων διότι μπορεί κανείς να
|
||
εκτελέσει πολλά περισσότερα αντίγραφα ενός προγράμματος για συγκεκριμένη
|
||
ποσότητα πόρων σε σχέση με τον αριθμό που θα μπορούσε να εκτελέσει
|
||
χρησιμοποιώντας εικονικές μηχανές πάνω από αυτούς τους πόρους. Το τελευταίο
|
||
μάλιστα μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την
|
||
κλιμακωσιμότητα. Τα δοχεία επίσης, λόγω της ταχείας διάθεσης και εκτέλεσής
|
||
τους, συμβαδίζουν πλήρως και με τον ρυθμό ανάπτυξης και παράδοσης που
|
||
υποστηρίζουν οι παραπάνω μεθοδολογίες. Τέλος, η ανεξαρτησία των δοχείων μεταξύ
|
||
τους, καθιστά πιο σταθερή την εφαρμογή, αφού σε περίπτωση που κάποιο από αυτά
|
||
αποτύχει, η υπόλοιπη εφαρμογή θα συνεχίσει να λειτουργεί κανονικά, ενώ η
|
||
ανακατασκευή του δοχείου που απέτυχε μπορεί να επιτευχθεί εύκολα και γρήγορα με
|
||
μια απλή τροποποίηση της εκάστοτε εικόνας δοχείου. Έχοντας αυτά υπόψιν, γίνεται
|
||
εμφανής και ο λόγος που τα δοχεία και εν γένει η δοχειοποίηση εφαρμογών είναι η
|
||
προτιμότερη επιλογή για περιπτώσεις ανάπτυξης και παράδοσης εφαρμογών που
|
||
ακολουθούν την αρχιτεκτονική μικρο-υπηρεσιών, καθώς και περιπτώσεις εφαρμογής
|
||
μεθόδων DevOps \cite{applicationContainerization}.
|
||
|
||
\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}, που παρέχουν αυτή την δυνατότητα. Επιπρόσθετα,
|
||
οι πάροχοι υπηρεσιών CaaS έχουν την κατάλληλη τεχνογνωσία για να προστατεύσουν
|
||
τις υπηρεσίες τους, εξασφαλίζοντας ένα υψηλό επίπεδο ασφάλειας για τις
|
||
εφαρμογές που τις χρησιμοποιούν.
|
||
|
||
Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
|
||
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
|
||
επειδή αυτό απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το
|
||
υπόλοιπο σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών
|
||
μέσω της διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
|
||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
|
||
ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και η δυσκολία διαχείρισής
|
||
τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
|
||
έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
|
||
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
|
||
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
|
||
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
|
||
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
|
||
εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται τα οφέλη (π.χ. περισσότερη
|
||
ασφάλεια, ποιότητα και αυξημένη διαθεσιμότητα) χρήσης υπηρεσιών από πολλούς
|
||
παρόχους με γνώμονα τις ανάγκες τους.
|
||
|
||
\subsection{Πλεονεκτήματα δοχείων έναντι εικονικών μηχανών} \label{containerAdvantages}
|
||
|
||
Παρ' όλο που πολλές φορές τα δοχεία συγχέονται με τις εικονικές μηχανές, οι δύο
|
||
αυτές έννοιες έχουν αρκετές διαφορές στην αρχιτεκτονική τους. Στην παραδοσιακή
|
||
εικονικοποίηση είτε αυτή γίνεται στις υπάρχουσες υποδομές μιας επιχείρησης είτε
|
||
σε ένα περιβάλλον νέφους, ένας υπερ-επόπτης πρέπει να χρησιμοποιηθεί για να
|
||
εικονικοποιήσει φυσικό υλικό. Αυτό συμβαίνει διότι μια εικονική μηχανή είναι
|
||
μια πλήρης αναπαράσταση ενός φυσικού διακομιστή. Από την άλλη, ένα δοχείο αντί
|
||
να εικονικοποιήσει το υλικό, εικονικοποιεί το λειτουργικό σύστημα, ή αλλιώς
|
||
εξομοιώνει μονάχα το περιβάλλον εκτέλεσης ενός λογισμικού. Άρα, εάν θεωρηθεί ως
|
||
τελικός στόχος η εκτέλεση ενός λογισμικού απομονωμένο από το υπόλοιπο σύστημα,
|
||
αυτό επιτυγχάνεται με δύο διαφορετικούς τρόπους, αφού οι εικονικές μηχανές και
|
||
τα δοχεία χρησιμοποιούν διαφορετικού είδους εικονικοποίηση. Στην περίπτωση των
|
||
δοχείων δεν έχουμε απομόνωση μηχανών αλλά διεργασιών. Γεγονός που συμβάλλει
|
||
στην αποφυγή της επιβάρυνσης του συστήματος που θα επιβάλλονταν από τις
|
||
διεργασίες του υπερ-επόπτη και της καθυστέρησης που θα υπήρχε για την εκκίνηση
|
||
ενός ολόκληρου λειτουργικού συστήματος. Επιπλέον, η μη χρήση τεχνολογιών
|
||
εικονικοποίησης σε επίπεδο υλικού αυξάνει την μεταφερσιμότητα των δοχείων,
|
||
καθώς σε μια εικόνα δοχείου μπορούν να ορισθούν όλες οι απαραίτητες εξαρτήσεις
|
||
ενός λογισμικού και τα δοχεία μπορούν να αναδημιουργηθούν και να εκτελεστούν σε
|
||
οποιοδήποτε περιβάλλον νέφους είναι ήδη εγκατεστημένη μια μηχανή δοχείων (όπως
|
||
το Docker) όπου μάλιστα η ταχύτητα δημιουργίας τους είναι πολύ πιο γρήγορη σε
|
||
σχέση με αυτή των εικονικών μηχανών λόγω του μικρού μεγέθους και των ελάχιστων
|
||
μη λειτουργικών απαιτήσεών τους.
|
||
|
||
Ένας από τους χαρακτηρισμούς των δοχείων είναι η \textquote{ελαφρότητά} τους σε
|
||
σχέση με μια εικονική μηχανή λόγω της ικανότητάς τους να μοιράζονται τον πυρήνα
|
||
του ίδιου λειτουργικού συστήματος (ΛΣ). Η απαίτηση μιας εικονικής μηχανής να
|
||
χρειάζεται, εικονικό αντίγραφο του υλικού, δικό της ΛΣ και εγκατεστημένα πακέτα
|
||
προς υποστήριξη ενός λογισμικού την καθιστά μεγαλύτερη σε μέγεθος και λιγότερο
|
||
αποδοτική στη χρήση πόρων του συστήματος. Απεναντίας, τα δοχεία περιέχουν
|
||
μονάχα το λογισμικό προς εκτέλεση και τις εξαρτήσεις (βιβλιοθήκες και
|
||
προγράμματα) που χρειάζεται προκειμένου αυτό να είναι λειτουργικό
|
||
\cite{ibmContainerVsVm}. Επομένως, είναι εγγενώς μικρότερα σε μέγεθος και έχουν
|
||
και μικρότερο χρόνο εκκίνησης. Πράγμα που τραβάει το ενδιαφέρον των
|
||
επιχειρήσεων διότι αυτό μεταφράζεται σε υψηλότερη αποδοτικότητα \& βαθμό χρήσης
|
||
των διακομιστών και επομένως μειωμένα κόστη λειτουργίας. Επίσης, τα δοχεία
|
||
κλιμακώνονται αρκετά πιο γρήγορα σε σχέση με τις εικονικές μηχανές,
|
||
επιτρέποντας την αντίδραση σε οποιαδήποτε διακύμανση του φόρτου εργασίας.
|
||
|
||
\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
|
||
στην αρχιτεκτονική της εικονικοποίησης (δεξιά) και των δοχείων (αριστερά).
|
||
|
||
\begin{center}
|
||
\begin{figure}[!ht]
|
||
\centering
|
||
\includegraphics[width = \textwidth]{Figures/ContainersVsVMs/containers-vs-vms.jpg}
|
||
\captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{containersVsVMs}}
|
||
\label{fig:containerVsVm}
|
||
\end{figure}
|
||
\vspace*{-30pt}
|
||
\end{center}
|
||
|
||
\clearpage
|
||
|
||
Η απουσία του εικονικού λειτουργικού υλικού είναι το χαρακτηριστικό που καθιστά
|
||
τα δοχεία γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η
|
||
διαφορά, σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των
|
||
εικονικών μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της
|
||
τάξεως των megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
|
||
\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
|
||
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
|
||
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
|
||
της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
|
||
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
|
||
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
|
||
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
|
||
περισσότερων δοχείων που αντιστοιχούν σε αυτά τα μέρη/μικρο-υπηρεσίες.
|
||
Αντιθέτως, η κλιμάκωση μιας μονολιθικής εφαρμογής θα απαιτούσε την δημιουργία
|
||
πολλαπλών δοχείων μεγάλου μεγέθους ή πολλαπλών εικονικών μηχανών, οδηγώντας σε
|
||
μεγάλη και αχρείαστη σπατάλη πόρων. Λόγω του γεγονότος πως μια εφαρμογή
|
||
αποτελείται από πολλαπλές μικρο-υπηρεσίες, οι οποίες μπορεί να έχουν πολλαπλά
|
||
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
|
||
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
|
||
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
|
||
(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
|
||
Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
|
||
έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
|
||
όπως το Docker Compose \footfullcite{dockerCompose}.
|
||
|
||
Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
|
||
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
|
||
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
|
||
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
|
||
το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.
|
||
|
||
\noindent Τα δοχεία προσφέρουν μια σειρά από πλεονεκτήματα σε σχέση με τις
|
||
παραδοσιακές εικονικές μηχανές. Αυτά, σύμφωνα με την
|
||
\citeauthor{ibmContainerizationDefinition}
|
||
\cite{ibmContainerizationDefinition}, μπορούν να συνοψιστούν ως εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Mεταφερσιμότητα}:
|
||
|
||
Τα δοχεία είναι ανεξάρτητα από το λειτουργικό σύστημα και το περιβάλλον
|
||
εκτέλεσής τους και ως εκ τούτου μπορούν να εκτελεστούν σε οποιαδήποτε
|
||
πλατφόρμα ή περιβάλλον νέφους ομοιόμορφα και με συνέπεια. Εφόσον τα
|
||
κομμάτια ενός προγράμματος μπορούν να ορισθούν σε ένα μονάχα αρχείο
|
||
κειμένου και να κατασκευαστούν με αυτοματοποιημένο τρόπο οπουδήποτε,
|
||
αυτό δίνει στα δοχεία πολύ μεγαλύτερο προβάδισμα στον τομέα της
|
||
μεταφερσιμότητας σε σχέση με τις εικονικές μηχανές.
|
||
|
||
\clearpage
|
||
|
||
\item \textbf{Εύκολη και συνεπής χρήση}:
|
||
|
||
Το Docker Engine ξεκίνησε το βιομηχανικό πρότυπο Docker για τη χρήση
|
||
δοχείων προσφέροντας απλά εργαλεία ανάπτυξης και μια καθολική
|
||
προσέγγιση πακεταρίσματος που λειτουργεί εξίσου καλά σε όλες τις
|
||
πλατφόρμες. Το οικοσύστημα των δοχείων έχει μετατοπιστεί σε μηχανές
|
||
δοχείων που ακολουθούν τα πρότυπα της Open Container Initiative (OCI)
|
||
και οι προγραμματιστές μπορούν εύκολα και γρήγορα να πακετάρουν τις
|
||
εφαρμογές τους ως δοχεία, τα οποία μπορούν να παρέχονται χωρίς την
|
||
έγνοια υποστήριξης πολλών διαφορετικών πλατφορμών.
|
||
|
||
\item \textbf{Ταχύτητα}:
|
||
|
||
Τα δοχεία είναι ελαφρύτερα από τις παραδοσιακές εικονικές μηχανές λόγω
|
||
του διαμοιρασμού του ίδιου ΛΣ και γι' αυτό έχουν μικρότερο χρόνο
|
||
εκκίνησης. Αυτό τα καθιστά ιδανικά για την ανάπτυξη και την εκτέλεση
|
||
εφαρμογών σε περιβάλλοντα νέφους όπου η αποδοτικότητα αξιοποίησης των
|
||
υπολογιστικών πόρων αντανακλάται σε άμεση εξοικονόμηση κόστους.
|
||
|
||
\item \textbf{Απομόνωση σφαλμάτων}:
|
||
|
||
Εφόσον κάθε δοχείο είναι απομονωμένο και λειτουργεί ανεξάρτητα από τα
|
||
υπόλοιπα, η αποτυχία ενός δοχείου στο ίδιο ΛΣ δε θα επηρεάσει τη συνεχή
|
||
λειτουργία των υπόλοιπων δοχείων. Με αυτόν τον τρόπο, οι ομάδες
|
||
ανάπτυξης λογισμικού μπορούν να εντοπίζουν και να διορθώνουν τυχόν
|
||
τεχνικά προβλήματα χωρίς να υπάρχει διακοπή λειτουργίας σε άλλα δοχεία.
|
||
Επιπρόσθετα, ο εντοπισμός του προβλήματος είναι εύκολος διότι εστιάζει
|
||
σε ένα μόνο δοχείο και όχι σε περισσότερα. Αυτό οδηγεί σε πιο γρήγορη
|
||
αποσφαλμάτωση και εν τέλει στην πιο γρήγορη ανάπτυξη και συντήρηση
|
||
προγραμμάτων.
|
||
|
||
\item \textbf{Μέγιστη χρηστικότητα πόρων}:
|
||
|
||
Το γεγονός ότι τα δοχεία μοιράζονται το ίδιο ΛΣ και κοινά κομμάτια μιας
|
||
στρώσης εικόνας δοχείου μπορούν να χρησιμοποιηθούν ξανά για την
|
||
δημιουργία πολλών δοχείων, τα καθιστά αρκετά μικρά σε μέγεθος ώστε να
|
||
είναι δυνατόν να εκτελεστούν πολλά περισσότερα δοχεία σε έναν
|
||
διακομιστή απ' ότι θα μπορούσαν εικονικές μηχανές. Επομένως,
|
||
αξιοποιούνται καλύτερα οι πόροι του συστήματος.
|
||
|
||
\item \textbf{Ευκολία διαχείρισης}:
|
||
|
||
Με την χρήση των δοχείων έχουμε και την δυνατότητα αυτοματοποίησης της
|
||
κλιμάκωσης \& διαχείρισης δοχειοποιημένων εφαρμογών κατά μήκος
|
||
πολλαπλών διακομιστών (εικονικών ή φυσικών) μέσω πλατφορμών
|
||
ενορχήστρωσης δοχείων. Δίχως την υποστήριξη τέτοιου είδους πλατφορμών,
|
||
ο φόρτος διαχείρισης θα ήταν αρκετά υψηλός και η διαχείριση του φόρτου
|
||
εργασίας των δοχειοποιημένων εφαρμογών σε περιβάλλοντα με πολλούς
|
||
διακομιστές θα απαιτούσε ειδικές γνώσεις για να πραγματοποιηθεί.
|
||
Παράλληλα, η διαχείριση των υποκείμενων φυσικών διακομιστών μπορεί να
|
||
αυτοματοποιηθεί μέσω της χρήσης διαχειριζόμενων εκδόσεων των πλατφορμών
|
||
(managed container orchestration platforms) αυτών που προσφέρονται από
|
||
παρόχους νέφους. Επιπρόσθετα, η διαχείριση δοχείων σε ένα μόνο σύστημα
|
||
είναι εξίσου εύκολη και απλή. Οι διαδικασίες ενημέρωσης, εκκίνησης,
|
||
τερματισμού και εν γένει διαχείρισης των δοχείων πραγματοποιούνται με
|
||
απλές εντολές, καθιστώντας την χρήση δοχείων προσιτή σε κάθε επιπέδου
|
||
προγραμματιστή.
|
||
|
||
\item \textbf{Ασφάλεια}:
|
||
|
||
Η απομόνωση των εφαρμογών ως δοχεία, όταν εφαρμόζεται ακολουθώντας
|
||
ορθές πρακτικές, εγγενώς αποτρέπει την εισβολή κακόβουλου λογισμικού
|
||
από το να επηρεάσει τα υπόλοιπα δοχεία ή το σύστημα στο οποίο
|
||
εκτελούνται. Συγκεκριμένα, χρησιμοποιώντας Kernel Security Modules,
|
||
όπως είναι το AppArmor ή το SELinux, μπορούν να ορισθούν άδειες
|
||
ασφαλείας με σκοπό τον περιορισμό του εύρους πρόσβασης του Docker στο
|
||
σύστημα, ενώ με access authorization plugins
|
||
\cite{accessAuthorizationPlugin}, περιορίζεται η πρόσβαση στον δαίμονα
|
||
του Docker. Επιπροσθέτως, πολύ εύκολα μπορεί να περιοριστεί και η
|
||
επικοινωνία μεταξύ δοχείων, καθώς και με το δίκτυο του συστήματος.
|
||
|
||
\end{itemize}
|
||
|
||
\subsection{Διαφορές σε υλοποιήσεις της δοχειοποίησης} \label{containerizationImplementationDifferences}
|
||
|
||
Στην Ενότητα \ref{containersAndContainerization} αναφέραμε την έννοια της
|
||
δοχειοποίησης. Η ραγδαία αύξηση του ενδιαφέροντος και της χρήσης δοχείων
|
||
οδήγησε στην ανάγκη για πρότυπα γύρω από την τεχνολογία αυτή. Έτσι, η Open
|
||
Container Initiative (OCI), η οποία ιδρύθηκε τον Ιούνιο του 2015 από την Docker
|
||
και άλλους ηγέτες του κλάδου, προωθεί κοινά, ανοικτά πρότυπα και προδιαγραφές
|
||
γύρω από την τεχνολογία δοχείων. Εξαιτίας αυτού, η OCI συμβάλλει στη διεύρυνση
|
||
των επιλογών για μηχανές δοχείων ανοιχτού κώδικα και συνεπώς, οι χρήστες δε θα
|
||
είναι εγκλωβισμένοι στην τεχνολογία ενός συγκεκριμένου προμηθευτή. Απεναντίας,
|
||
θα μπορούν να επωφεληθούν από τις πιστοποιημένες από την OCI τεχνολογίες που θα
|
||
τους επιτρέπουν να δημιουργούν εφαρμογές σε δοχεία χρησιμοποιώντας ένα ευρύ
|
||
σύνολο εργαλείων DevOps, τις οποίες θα μπορούν να εκτελούν με τον ίδιο τρόπο σε
|
||
οποιεσδήποτε υποδομές της επιλογής τους.
|
||
|
||
Σήμερα, αν και το Docker αποτελεί μία από τις πιο γνωστές και ευρέως
|
||
χρησιμοποιούμενες μηχανές δοχείων, υπάρχουν πολλές άλλες εναλλακτικές
|
||
υλοποιήσεις. Για παράδειγμα, το Podman \cite{podman} είναι μια γνωστή
|
||
εναλλακτική μηχανή δοχείων ενώ το LXC και το containerd είναι εναλλακτικά
|
||
Container Runtimes - μάλιστα το τελευταίο ήταν για καιρό η προεπιλογή του
|
||
Docker για Container Runtime προτού υιοθετήσει το runC. Οι προαναφερόμενες
|
||
εναλλακτικές υλοποιήσεις μπορεί να έχουν διαφορετικά χαρακτηριστικά και
|
||
προεπιλογές αλλά η υιοθέτηση και η αξιοποίηση των προδιαγραφών της OCI καθώς
|
||
αυτές εξελίσσονται θα διασφαλίσει ότι οι εναλλακτικές αυτές παραμένουν
|
||
ανεξάρτητες από τους προμηθευτές, πιστοποιημένες για να τρέχουν σε πολλαπλά
|
||
λειτουργικά συστήματα και χρησιμοποιήσιμες σε πολλαπλά περιβάλλοντα
|
||
\cite{ibmContainerizationDefinition}.
|
||
|
||
Παρότι οι προδιαγραφές της OCI έχουν ως στόχο να διασφαλίσουν την ομοιόμορφη
|
||
λειτουργία της τεχνολογίας αυτής, υπάρχουν αρκετές διαφορές στην υλοποίηση της.
|
||
Παραδείγματος χάριν, το Podman, ενώ συμμορφώνεται στις προδιαγραφές της OCI
|
||
όπως το Docker, δουλεύει χωρίς δαίμονα από πίσω, πράγμα που επιδιώκει να
|
||
κατευνάσει τις ανησυχίες γύρω από τον τρόπο λειτουργίας του Docker. Αυτό
|
||
συμβαίνει διότι το Docker χρειάζεται διαχειριστικές άδειες για την λειτουργία
|
||
του δαίμονα του, γεγονός που αφήνει το σύστημα ευάλωτο σε επιθέσεις σε
|
||
περίπτωση που αυτός παραβιαστεί. Παρότι και οι δύο αυτές μηχανές δοχείων
|
||
χρησιμοποιούν το runC ως Container Runtime, το Podman χρησιμοποιεί το systemd
|
||
για την διαχείριση των δοχείων του, το οποίο μπορεί να χρησιμοποιηθεί από
|
||
χρήστες χωρίς διαχειριστικές άδειες. Συνεπώς, εξαιτίας του τρόπου λειτουργίας
|
||
του, αν και από το 2021, χάρη στη δουλειά του Akihiro Suda
|
||
\footfullcite{AkihiroSuda}, η αποφυγή χρήσης δαίμονα δεν ισχύει μόνο για αυτό
|
||
πλέον, το Podman δύναται να εκτελεστεί από έναν χρήστη πέραν του
|
||
διαχειριστή/ριζικού (root).
|
||
|
||
Ένα ακόμα εργαλείο που έχει παρόμοια αρχιτεκτονική με το Podman είναι το rkt
|
||
\footfullcite{rkt} το οποίο προσπαθούσε να κρατήσει μια προσέγγιση ασφαλούς
|
||
σχεδιασμού εξ αρχής (Secure-by-design). Μπορούσε να ενσωματώσει χαρακτηριστικά
|
||
ασφαλείας, όπως υποστήριξη SELinux, TPM measurement και εκτέλεση δοχείων σε
|
||
απομονωμένες από το υλικό εικονικές μηχανές. Παρ' όλα αυτά, σύμφωνα με τον
|
||
\citeauthor{dockerAlternatives} \cite{dockerAlternatives}, έπαψε να έχει ενεργή
|
||
ανάπτυξη και επομένως δεν θα συνεχίζει να ανταγωνίζεται παρόμοια εργαλεία στον
|
||
κλάδο των δοχείων.
|
||
|
||
Σχετικά με τα Container Runtimes runC και containerd, το πρώτο είναι ένα
|
||
Container Runtime χαμηλού επιπέδου ενώ το δεύτερο υψηλού επιπέδου.
|
||
Δημιουργήθηκαν και τα δύο από το Docker σε διαφορετικές χρονικές περιόδους. Από
|
||
τις αρχικές του εκδόσεις, το Docker χρησιμοποιούσε το containerd από
|
||
προεπιλογή. Μετέπειτα, αποφάσισε να το καταστήσει ένα αυτόνομο Container
|
||
Runtime και τον ρόλο του πήρε, το runC, προκειμένου να μπορέσουν τα δοχεία του
|
||
Docker να δουλεύουν ευκολότερα σε διαφορετικές πλατφόρμες όπως το Kubernetes
|
||
\cite{containerdRunc}. Επιπροσθέτως, η απόφαση αυτή κατέστησε το Docker πιο
|
||
διαχειρίσιμο διότι πλέον αποτελούνταν από πολλά μικρότερα εργαλεία, όπου το
|
||
καθένα από αυτά είχε συγκεκριμένους ρόλους. Αναλυτικότερα, το containerd πλέον
|
||
είναι υπεύθυνο για την απόκτηση εικόνων δοχείων και την διαχείρισή τους, προτού
|
||
τις μεταβιβάσει στο runC, το οποίο είναι το εργαλείο που θα αλληλεπιδράσει με
|
||
τον πυρήνα του Linux προκειμένου να χρησιμοποιήσει χαρακτηριστικά όπως, οι
|
||
ομάδες ελέγχου (control groups), για να δημιουργήσει δοχεία.
|
||
|
||
\section{Ασφάλεια στο Docker} \label{dockerSecurityMore}
|
||
|
||
Οι εφαρμογές σε δοχεία έχουν ένα εγγενές επίπεδο ασφαλείας, αφού μπορούν να
|
||
εκτελούνται ως απομονωμένες διεργασίες και να λειτουργούν ανεξάρτητα από τα
|
||
υπόλοιπα δοχεία. Αν εξασφαλιζόταν πλήρης απομόνωση, θα μπορούσε να αποτραπεί,
|
||
στην περίπτωση μόλυνσης από κακόβουλο λογισμικό, ο κίνδυνος να επηρεαστούν άλλα
|
||
δοχεία ή το ίδιο το σύστημα. Ωστόσο, η απομόνωση τους δεν είναι πλήρης.
|
||
Επομένως, ενώ ο διαμοιρασμός κομματιών μιας εφαρμογής σε δοχεία βοηθάει στην
|
||
αποδοτικότητα του συστήματος, ανοίγει και ένα παράθυρο ευκαιρίας για επιθέσεις
|
||
λόγω αυτής της τρωτότητας. Το γεγονός, επίσης, πως μοιράζονται τον ίδιο πυρήνα
|
||
σημαίνει πως μια επίθεση με στόχο αυτόν, μπορεί δυνητικά να επηρεάσει όλα τα
|
||
δοχεία.
|
||
|
||
Σχετικά με τις εικόνες δοχείων που αναφέρθηκαν στο
|
||
\ref{virtualizationTechnologiesIntroduction} και το
|
||
\ref{containersAndContainerization}, τα κομμάτια δηλαδή από τα οποία μια
|
||
εφαρμογή σε μορφή δοχείου αποτελείται και αντιστοιχούν σε καλούπια μέσω των
|
||
οποίων παράγονται τα δοχεία της εφαρμογής, η ασφάλεια δεν είναι πάντα
|
||
εγγυημένη. Αυτό είναι κάτι που συμβαίνει διότι ο καθένας έχει την δυνατότητα να
|
||
ανεβάσει μια εικόνα δοχείου προς χρήση από τρίτους. Σε περίπτωση που δεν
|
||
εξετασθεί το περιεχόμενό της μπορεί είτε να περιέχει κακόβουλο λογισμικό, είτε
|
||
να μην ακολουθούνται ορθές πρακτικές ασφαλείας με αποτέλεσμα να μένει το
|
||
σύστημα που την χρησιμοποιεί ευάλωτο σε επιθέσεις. Συνεπώς, πρέπει να ληφθούν
|
||
μέτρα προστασίας όπως η χρήση εικόνων προερχόμενες μόνο από εγκεκριμένες πηγές,
|
||
δηλαδή να υπάρχει εμπιστοσύνη ανάμεσα στον προμηθευτή μιας εικόνας δοχείου και
|
||
τον τελικό χρήστη. Επιπροσθέτως, πριν την χρήση μιας εικόνας δοχείου, πρέπει
|
||
αυτή να εξετάζεται με εργαλεία ανίχνευσης τρωτοτήτων (όπως το Snyk
|
||
\footfullcite{snyk} ή το Trivy \footfullcite{trivy}), καθώς και να έχει
|
||
πραγματοποιηθεί επαρκώς σκλήρυνση του Docker ώστε να μειωθούν οι επιπτώσεις
|
||
κατά την χρήση της εαν περιέχει κακόβουλο λογισμικό.
|
||
|
||
Οι πάροχοι τεχνολογίας δοχείων έχουν αποκτήσει μια προσέγγιση ασφαλούς
|
||
σχεδιασμού ώστε πολλά από τα απαραίτητα μέτρα να είναι ενεργοποιημένα χωρίς την
|
||
απαίτηση επιπρόσθετης αλληλεπίδρασης από τον χρήστη. Πλέον, η μηχανή δοχείων
|
||
υποστηρίζει όλες τις ιδιότητες απομόνωσης που υποστηρίζει και το λειτουργικό
|
||
σύστημα στο οποίο εκτελείται, ενώ άδειες ασφαλείας μπορούν να δοθούν στα δοχεία
|
||
και τον δαίμονα του Docker μέσω του πυρήνα του ΛΣ, με σκοπό τον επιπρόσθετο
|
||
περιορισμό χρήσης πόρων και του εύρους του συστήματος στο οποίο έχει πρόσβαση η
|
||
μηχανή δοχείων \cite{ibmContainerizationDefinition}.
|
||
|
||
\subsection{Μετριασμός επιθέσεων στο Docker με χρήση χώρων ονομάτων} \label{dockerAttackVectorMitigation}
|
||
|
||
Με βάση το μοντέλο που περιγράφει το \cite{reshetova2014security}, όπως
|
||
αναφέρεται στο \cite{bui2015analysis}, έχουμε ένα μηχάνημα στο οποίο
|
||
εκτελούνται διάφορα δοχεία, από τα οποία ένα υποσύνολο έχει τεθεί υπό τον
|
||
έλεγχο ενός κακόβουλου χρήστη. Για να προστατευτούμε από επιθέσεις, όπως άρνηση
|
||
υπηρεσίας και κλιμάκωση δικαιωμάτων, πρέπει να πραγματοποιηθεί απομόνωση των
|
||
διεργασιών, των αρχείων της συσκευής, του IPC, του δικτύου και των πόρων.
|
||
|
||
Αυτά επιτυγχάνονται κατά σειρά με τη χρήση:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Χώρων ονομάτων (namespaces)} όπου οριοθετείται η ορατότητα
|
||
των διεργασιών ανάμεσα στα δοχεία και το σύστημα, όπως επίσης και τα
|
||
δικαιώματά τους.
|
||
|
||
\item \textbf{Mount namespaces}, με τα οποία οι διεργασίες κάθε δοχείου
|
||
βλέπουν με διαφορετικό τρόπο τη διάταξη των αρχείων του συστήματος.
|
||
Όλες οι δράσεις mount, που γίνονται στο εκάστοτε δοχείο, περιορίζονται
|
||
σε αυτό. Επίσης, οριοθετούνται τα δικαιώματα των αρχείων του πυρήνα σε
|
||
μονάχα ανάγνωσης και αποτρέπονται περαιτέρω remountings.
|
||
|
||
\item \textbf{Device Whitelist Controller}, ενός χαρακτηριστικού
|
||
\cite{deviceWhitelistController} των cgroups για περιορισμό
|
||
συσκευών, με τη βοήθεια του οποίου περιορίζεται το σύνολο τον συσκευών
|
||
στις οποίες έχει πρόσβαση ένα δοχείο και το αποτρέπει από το να
|
||
δημιουργήσει καινούριες αναπαραστάσεις συσκευών. Επιπροσθέτως, επειδή
|
||
τα mount γίνονται με τη χρήση της παραμέτρου
|
||
nodev\footnote{\textgreek{Μια παράμετρος της εντολής mount κατά την
|
||
οποία αποτρέπεται η δημιουργία και η πρόσβαση αναπαραστάσεων συσκευών
|
||
που βρίσκονται στον φάκελο /dev.}}, στην περίπτωση που μια αναπαράσταση
|
||
συσκευής είχε δημιουργηθεί σε προηγούμενο χρόνο μέσα στην εικόνα δοχείου που
|
||
χρησιμοποιήθηκε για να κατασκευαστεί το δοχείο, οι διεργασίες του δοχείου αυτού
|
||
δε δύνανται να τη χρησιμοποιήσουν για να επικοινωνήσουν με τον πυρήνα.
|
||
Επιπλέον, επειδή η προεπιλεγμένη συνθήκη είναι να μη δίνονται εκτεταμένα
|
||
προνόμια σε ένα δοχείο, δεν υπάρχει πρόσβαση σε καμία συσκευή παρά μόνο εάν
|
||
γίνει εκτέλεση δοχείου ως χρήστης με ανώτατα δικαιώματα, όπου τότε υπάρχει
|
||
πρόσβαση σε όλες (τις συσκευές).
|
||
|
||
\item \textbf{IPC namespaces} για περιορισμό IPC, δηλαδή της επικοινωνίας
|
||
των διεργασιών μεταξύ τους. Τα IPC namespaces καθιστούν δυνατή τη
|
||
δημιουργία ξεχωριστών συνόλων των διεργασιών που επικοινωνούν μεταξύ
|
||
τους, αλλά όχι με άλλες διεργασίες πέραν του υποσυνόλου.
|
||
|
||
\item \textbf{Network namespaces}. Μία από τις σημαντικότερες απομονώσεις
|
||
είναι αυτή του δικτύου. Χωρίς δικτυακή απομόνωση υπάρχει κίνδυνος
|
||
επιθέσεων, όπως ενδιάμεσου (Man in the middle), ARP, DNS πλαστογράφησης
|
||
(spoofing) και άλλες. Για να απομονωθεί η κίνηση δικτύου που λαμβάνει
|
||
μέρος σε ένα δοχείο από αυτήν των υπολοίπων και του συστήματος πρέπει
|
||
να γίνει χρήση των network namespaces. Κάθε δοχείο θα έχει δικές του
|
||
διευθύνσεις IP, συσκευές και ό,τι χρειάζεται, προκειμένου να γίνεται
|
||
αλληλεπίδραση μεταξύ των δοχείων μέσω της διεπαφής δικτύου του καθενός
|
||
σαν να είναι εξωτερικές οντότητες.
|
||
|
||
\item \textbf{Ομάδες ελέγχου (cgroups)}. Επιβάλλεται η οριοθέτηση των
|
||
υπολογιστικών πόρων προκειμένου να αποφευχθεί μια επίθεση τύπου άρνησης
|
||
υπηρεσίας, όπου μια διεργασία ή ένα σύνολο αυτών προσπαθεί να
|
||
καταναλώσει όλους τους πόρους του συστήματος. Με τη βοήθεια των ομάδων
|
||
ελέγχου, επιτυγχάνεται ο έλεγχος του (μέγιστου) ποσοστού πόρων όπως
|
||
CPU, μνήμης και χωρητικότητας, που μπορεί να έχει κάθε δοχείο στη
|
||
διάθεση του.
|
||
|
||
\end{itemize}
|
||
|
||
Αυτές οι δυνατότητες υποστηρίζονται από το Docker και μπορεί κανείς να τις
|
||
εκμεταλλευτεί για να προστατεύσει το περιβάλλον του από επιθέσεις. Επιπλέον,
|
||
υπάρχει και η δυνατότητα υποστήριξης Kernel Security Modules, όπως τα SELinux
|
||
\cite{selinux} και AppArmor \footfullcite{apparmor} αλλά και του seccomp
|
||
\cite{seccomp} (στην περίπτωση χρήσης LXC), καθώς επίσης και συμβατότητα με
|
||
Linux capabilities (ικανότητες), που θα μπορούσαν να εισάγουν ένα ακόμα επίπεδο
|
||
ασφαλείας, αν χρησιμοποιηθούν σωστά, περιορίζοντας τα δικαιώματα των διεργασιών
|
||
των δοχείων σε μονάχα όσα χρειάζονται. Το Docker παρέχει αρκετά υπάρχοντα μέσα
|
||
άμυνας προκειμένου να προστατευτεί από επιθέσεις ακόμα και χωρίς επιπρόσθετες
|
||
ρυθμίσεις. Παρ' όλα αυτά, οι αρχικές ρυθμίσεις ασφαλείας του είναι πιο
|
||
ελαστικές απ' όσο χρειάζεται προκειμένου να συνεχίζει να λειτουργεί κανονικά
|
||
για όλους τους χρήστες, αφήνοντας έτσι τους διαχειριστές ασφαλείας υπεύθυνους
|
||
να χρησιμοποιήσουν όσες δυνατότητες είναι απαραίτητες προκειμένου να
|
||
ανταπεξέλθουν σε κάθε επίθεση ανάλογα με το περιβάλλον και τις ανάγκες τους.
|
||
|
||
\subsection{Συχνά είδη επιθέσεων σε δοχεία και μέθοδοι πρόληψής τους} \label{commonAttacksAndPrevention}
|
||
|
||
Μερικά είδη επιθέσεων σε δοχεία με τους τρόπους αντιμετώπισής τους, όπως
|
||
αναφέρονται στο \cite{yasrab2018mitigating}, είναι τα εξής:
|
||
|
||
\begin{itemize}
|
||
|
||
\item \textbf{Εκμεταλλεύσεις πυρήνα (Kernel Exploits)}:
|
||
|
||
Ο πυρήνας είναι υπεύθυνος για τη διαχείριση των λειτουργιών και
|
||
διεργασιών των δοχείων. Λόγω του διαμοιρασμού του πυρήνα του συστήματος
|
||
με κάθε δοχείο το οποίο εκτελείται σε αυτό, εάν οποιοδήποτε από αυτά
|
||
τεθεί υπό τον έλεγχο ενός κακόβουλου χρήστη, αυτός μπορεί δυνητικά να
|
||
πάρει τον έλεγχο του συστήματος και όλων των δοχείων αυτού. Ορισμένοι
|
||
τρόποι με τους οποίους αυτό έχει επιτευχθεί στο παρελθόν, ήταν μέσω
|
||
εκμετάλλευσης μιας ευπάθειας των ομάδων ελέγχου \cite{kernexpcgroup}
|
||
και μέσω μιας ευπάθειας ονόματι \textquote{Dirty Pipe}
|
||
\cite{dirtyPipe}. Η μέθοδος αντιμετώπισης που προτείνεται είναι η χρήση
|
||
SELinux ή AppArmor κατά την εκτέλεση δοχείων σε συνδυασμό με
|
||
εκμετάλλευση των user namespaces. Επιπλέον, συνιστάται να μην
|
||
εκτελούνται εφαρμογές με δικαιώματα διαχειριστικού λογαριασμού μέσα σε
|
||
δοχεία. Υπάρχουν και άλλα μέτρα προστασίας που μπορεί να παρθούν αλλά
|
||
πιθανόν να μην είναι εφικτά διότι ενδέχεται να πηγαίνουν ενάντια στις
|
||
λειτουργίες του εκάστοτε δοχείου. Αυτά είναι, να τεθεί το σύστημα του
|
||
σε επίπεδο πρόσβασης που επιτρέπει μόνο την ανάγνωση των αρχείων, να
|
||
απενεργοποιηθεί η επικοινωνία μεταξύ δοχείων και να αποφευχθεί η
|
||
εγκατάσταση περιττών προγραμμάτων σε αυτά.
|
||
|
||
\item \textbf{Άρνηση υπηρεσίας}:
|
||
|
||
Μια από τις πιο συνηθισμένες επιθέσεις σε πόρους διαθέσιμους μέσω
|
||
δικτύου είναι η άρνηση υπηρεσίας. Κατά τη διάρκεια μιας τέτοιας
|
||
επίθεσης, μια διεργασία ή ένα σύνολο διεργασιών επιχειρεί να
|
||
καταναλώσει όλους τους πόρους του συστήματος προκειμένου να μην μπορεί
|
||
να εξυπηρετήσει άλλους χρήστες. Αυτό μπορεί να συμβεί εάν ένα δοχείο
|
||
βρεθεί υπό τον έλεγχο ενός επιτιθέμενου και επιχειρήσει να διεκδικήσει
|
||
πόρους που κανονικά δε χρειάζεται. Για να ανταπεξέλθει ένα σύστημα σε
|
||
μια επίθεση άρνησης υπηρεσίας, πρέπει να γίνει χρήση των δυνατοτήτων
|
||
που αναφέραμε στο \ref{dockerAttackVectorMitigation} με σκοπό τον
|
||
αυστηρότερο έλεγχο διαμοιρασμού των πόρων του συστήματος. Με τον
|
||
καθορισμό μέγιστων διαθέσιμων πόρων για κάθε δοχείο εξ αρχής, δεν
|
||
υπάρχει κίνδυνος να προσπαθήσει κάποιο δοχείο να διεκδικήσει
|
||
περισσότερους από αυτούς που μπορούν να του ανατεθούν.
|
||
|
||
\item \textbf{Αποδράσεις Δοχείων (Container Breakouts)}:
|
||
|
||
Σε τέτοιου είδους επιθέσεις, ένας επιτιθέμενος προσπαθεί αφότου
|
||
απέκτησε πρόσβαση σε ένα δοχείο, να καταφέρει μέσω αυτού να έχει
|
||
πρόσβαση στα αρχεία του κύριου συστήματος. Αυτό μπορεί να συμβεί με τη
|
||
χρήση της συνάρτησης \textquote{open\_by\_handle\_at()} που απαιτεί
|
||
δικαιώματα διαχειριστικού λογαριασμού μέσα από το δοχείο, προκειμένου
|
||
να κάνει κλήση της ικανότητας (capability)
|
||
\textquote{CAP\_DAC\_READ\_SEARCH} στην οποία είχε πρόσβαση εξ αρχής
|
||
\cite{yasrab2018mitigating}. Σύμφωνα με το Docker, η μόνη έκδοσή του
|
||
που μπορούσε να επηρεαστεί από αυτή την ευπάθεια ήταν η 0.11 και στην
|
||
επόμενη διορθώθηκε. Για την πρόληψη μελλοντικών μεθόδων διεκπεραίωσης
|
||
τέτοιου είδους επίθεσης, συνιστάται να τίθενται τα δοχεία και οι
|
||
αποθηκευτικοί τους χώροι σε κατάσταση μονάχα ανάγνωσης, να αποφεύγεται
|
||
η χρήση διαχειριστικού λογαριασμού μέσα τα δοχεία, καθώς και να
|
||
αποφεύγεται η χρήση της παραμέτρου \textquote{privileged}.
|
||
|
||
\item \textbf{Δηλητηριασμένες εικόνες δοχείων}:
|
||
|
||
Οι εικόνες δοχείων μπορεί να περιέχουν κακόβουλο λογισμικό ή λογισμικό
|
||
για το οποίο έχουν βρεθεί (πλέον) ευπάθειες. Ο τωρινός τρόπος ελέγχου
|
||
εγκυρότητάς τους βασίζεται μονάχα στην παρουσία ενός υπογεγραμμένου
|
||
manifest αλλά δε γίνεται ποτέ αυθεντικοποίηση του αθροίσματος ελέγχου
|
||
(checksum) της κάθε εικόνας από το σύστημα. Αυτό αφήνει ανοιχτό το
|
||
ενδεχόμενο ένας επιτιθέμενος να διαδώσει οποιαδήποτε εικόνα μαζί με το
|
||
υπογεγραμμένο manifest της. Επιβάλλεται λοιπόν, οι χρήστες να
|
||
κατεβάζουν εικόνες από εγκεκριμένους προμηθευτές και επιπρόσθετα να τις
|
||
ελέγχουν με κατάλληλα εργαλεία ανίχνευσης τρωτοτήτων προτού τις
|
||
χρησιμοποιήσουν. Τέλος, πρέπει οι ίδιοι να ελέγχουν το checksum ώστε να
|
||
εξακριβώνεται πριν την χρήση αν είναι όντως η εικόνα που ζητήθηκε.
|
||
|
||
\item \textbf{Απόκτηση μυστικών κωδικών/κλειδιών}:
|
||
|
||
Η απόκτηση επιχειρησιακών ή προσωπικών μυστικών ελλοχεύει πολλούς
|
||
κινδύνους για μια επιχείρηση. Σε περίπτωση που κάτι τέτοιο συμβεί, ένας
|
||
επιτιθέμενος μπορεί να έχει πρόσβαση σε βάσεις δεδομένων ή άλλα
|
||
κομμάτια του συστήματος απειλώντας έτσι την ακεραιότητα, την
|
||
εμπιστευτικότητα και διαθεσιμότητα των δεδομένων. Προκειμένου να
|
||
αποφευχθεί η εισβολή σε κάποιο δοχείο που θα προκαλούσε την απόκτηση
|
||
τέτοιων μυστικών, καθίσταται επιτακτική η χρήση δοχείων σε κατάσταση
|
||
ανάγνωσης και όχι εγγραφής αλλά και η αποφυγή χρήσης μεταβλητών για την
|
||
αποθήκευση κωδικών. Χρήσιμη επίσης θα ήταν και η εσκεμμένη παράλειψη
|
||
της παραμέτρου \textquote{privileged}.
|
||
|
||
\item \textbf{Ενδιάμεσου (Man-in-the-Middle - MitM)}:
|
||
|
||
Σε μια τέτοια επίθεση ένας κακόβουλος χρήστης προσπαθεί να μπει ανάμεσα
|
||
στην επικοινωνία δύο οντοτήτων με σκοπό να αλλοιώσει, να υποκλέψει ή να
|
||
παρακολουθεί πληροφορίες. Με βάση το CVE-2020-13401 που αναφέρεται στο
|
||
\cite{dockermitm}, μετά από παραβίαση ενός δοχείου, εάν αυτό εκτελείται
|
||
με την ικανότητα \textquote{CAP\_NET\_RAW}, τότε μπορεί ένας
|
||
επιτιθέμενος να δημιουργήσει διαφημίσεις δρομολογητών IPv6 και κατά
|
||
συνέπεια, να παραποιήσει εξωτερικούς κεντρικούς υπολογιστές IPv6, ώστε
|
||
να αποκτήσει ευαίσθητες πληροφορίες ή να προκαλέσει άρνηση παροχής
|
||
υπηρεσιών. Το καλύτερο αντίμετρο αυτής της επίθεσης είναι η απομόνωση
|
||
δικτύου. Πρέπει να γίνει ρύθμιση των δοχείων με τέτοιο τρόπο ώστε αυτά
|
||
να μην έχουν πρόσβαση στη δικτυακή επικοινωνία του κύριου μηχανήματος ή
|
||
άλλων δοχείων. Αυτά επιτυγχάνονται με χρήση network namespaces, καθώς
|
||
και με την ορθότερη ρύθμιση των API που χρησιμοποιεί το Docker για την
|
||
επικοινωνία μέσω δικτύου. Τέλος, πρέπει να χρησιμοποιούνται ασφαλή
|
||
πρωτόκολλα επικοινωνίας με αμφίδρομη αυθεντικοποίηση.
|
||
|
||
\item \textbf{Πλαστογράφηση ARP (ARP spoofing)}:
|
||
|
||
Σε μια επίθεση πλαστογράφησης Address Resource Protocol (ARP), ο
|
||
επιτιθέμενος επιχειρεί να στείλει ψεύτικα ARP μηνύματα σε ένα δίκτυο
|
||
τοπικής περιοχής (Local Area Network - LAN). Με αυτόν τον τρόπο, είναι
|
||
πιθανό να προσποιηθεί πως η συσκευή του είναι μια από τις συσκευές της
|
||
επιχείρησης, αφού πλέον η MAC διεύθυνσή του, αντιστοιχεί στην MAC μιας
|
||
συσκευής της οποίας η IP αναγνωρίζεται από το σύστημα \cite{arpdocker}.
|
||
Επομένως, το σύστημα της επιχείρησης, θα συμπεριφέρεται στην συσκευή
|
||
του επιτιθέμενου με τον ίδιο τρόπο που θα συμπεριφερόταν στην αυθεντική
|
||
συσκευή. Δηλαδή, στέλνοντας σε αυτόν όλα τα πακέτα και τα δεδομένα που
|
||
προορίζονταν για εκείνη. Το Docker χρησιμοποιεί το ARP για να κάνει την
|
||
αντιστοίχιση IPv4 σε MAC διευθύνσεις, οι οποίες χρησιμοποιούνται από
|
||
την εικονική γέφυρα δικτύου για να διανέμουν σωστά τα πλαίσια (frames)
|
||
Ethernet, καθώς δεν υπάρχει φίλτρο για τα πακέτα ARP και επομένως
|
||
κανένας μηχανισμός άμυνας. Γι' αυτό τον λόγο ένα δοχείο μπορεί να
|
||
προσποιηθεί ότι είναι ένα άλλο ή ακόμα και το κύριο μηχάνημα. Ακόμα και
|
||
χωρίς την παραβίαση ενός δοχείου, αλλά έχοντας πρόσβαση στο τοπικό
|
||
δίκτυο, υπάρχει κίνδυνος ο επιτιθέμενος να υποκλέψει μυστικά της
|
||
επιχείρησης ή των τελικών χρηστών της υπηρεσίας που η επιχείρηση
|
||
προσφέρει. Ένας από τους τρόπους αποφυγής μιας τέτοιας επίθεσης, είναι
|
||
η εκτέλεση δοχείων δίχως την ικανότητα \textquote{NET\_RAW}, αφού έτσι
|
||
τα προγράμματα μέσα σε ένα δοχείο δε θα μπορούν να δημιουργήσουν
|
||
PF\_PACKET sockets και θα ήταν αδύνατη η διεκπεραίωση της επίθεσης.
|
||
Βέβαια, αυτή η μέθοδος έχει και μειονεκτήματα διότι αυτή η ικανότητα
|
||
μπορεί να ήταν άκρως απαραίτητη για την ορθή λειτουργία της υπηρεσίας.
|
||
Επομένως, μια εναλλακτική μέθοδος προστασίας είναι η χρήση
|
||
\textquote{ebtables} για φιλτράρισμα πλαισίων Ethernet, ούτως ώστε ARP
|
||
πακέτα με λάθος πρωτόκολλο αποστολέα ή διεύθυνση υλικού να ανιχνεύονται
|
||
εγκαίρως και να απορρίπτονται.
|
||
|
||
\end{itemize}
|