Can someone review this commit, please ?
This commit is contained in:
@@ -3,71 +3,91 @@
|
||||
\lhead{\textgreek{Συντομογραφίες}} % Set the left side page header to "Abbreviations"
|
||||
\listofsymbols{ll} % Include a list of Abbreviations (a table of two columns)
|
||||
{
|
||||
\textbf{IaaS} & \textbf{I}nfrastructure \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{PaaS} & \textbf{P}latform \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{SaaS} & \textbf{S}oftware \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{AWS} & \textbf{A}mazon \textbf{W}eb \textbf{S}ervices \\
|
||||
\textbf{GCE} & \textbf{G}oogle \textbf{C}ompute \textbf{E}ngine \\
|
||||
\textbf{OWASP} & \textbf{O}pen \textbf{W}eb \textbf{A}pplication \textbf{S}ecurity \textbf{P}roject \\
|
||||
\textbf{EC2} & \textbf{E}lastic \textbf{C}ompute \textbf{C}loud \\
|
||||
\textbf{IAM} & \textbf{I}dentity and \textbf{A}ccess \textbf{M}anagement \\
|
||||
\textbf{IaC} & \textbf{I}nfrastructure \textbf{a}s \textbf{C}ode \\
|
||||
\textbf{AMI} & \textbf{A}mazon \textbf{M}achine \textbf{I}mage \\
|
||||
\textbf{API} & \textbf{A}pplication \textbf{P}rogramming \textbf{I}nterface \\
|
||||
\textbf{SDK} & \textbf{S}oftware \textbf{D}evelopment \textbf{K}it \\
|
||||
\textbf{OS} & \textbf{O}perating \textbf{S}ystem \\
|
||||
\textbf{AppArmor} & \textbf{App}lication \textbf{Armor} \\
|
||||
\textbf{ARP} & \textbf{A}ddress \textbf{R}esolution \textbf{P}rotocol \\
|
||||
\textbf{ATT\&CK} & \textbf{A}dversarial \textbf{T}actics, \textbf{T}echniques \textbf{\&} \textbf{C}ommon \textbf{K}nowledge \\
|
||||
\textbf{AWS} & \textbf{A}mazon \textbf{W}eb \textbf{S}ervices \\
|
||||
|
||||
\textbf{BIOS} & \textbf{B}asic \textbf{I}nput/\textbf{O}utput \textbf{S}ystem \\
|
||||
\textbf{UEFI} & \textbf{U}nified \textbf{E}xtensible \textbf{F}irmware \textbf{I}nterface \\
|
||||
\textbf{MAC} & \textbf{M}andatory \textbf{A}ccess \textbf{C}ontrol \\
|
||||
\textbf{MAC} & \textbf{M}edium \textbf{A}ccess \textbf{C}ontrol \\
|
||||
\textbf{XSS} & \textbf{C}ross \textbf{S}ite \textbf{S}cripting \\
|
||||
\textbf{cgroups} & \textbf{c}ontrol \textbf{groups} \\
|
||||
\textbf{CI/CD} & \textbf{C}ontinuous \textbf{I}ntegration / \textbf{C}ontinuous \textbf{D}elivery \\
|
||||
\textbf{DevOps} & \textbf{Dev}elopment \textbf{Op}eration\textbf{s} \\
|
||||
\textbf{LXC} & \textbf{L}inu\textbf{x} \textbf{C}ontainers \\
|
||||
\textbf{OCI} & \textbf{O}pen \textbf{C}ontainer \textbf{I}nitiative \\
|
||||
\textbf{TPM} & \textbf{T}rusted \textbf{P}latform \textbf{M}odule \\
|
||||
\textbf{VM} & \textbf{V}irtual \textbf{M}achine \\
|
||||
\textbf{VBS} & \textbf{V}irtualization-\textbf{B}ased \textbf{S}ecurity \\
|
||||
\textbf{KVM} & \textbf{K}ernel-based \textbf{V}irtual \textbf{M}achine \\
|
||||
\textbf{VMM} & \textbf{V}irtual \textbf{M}achine \textbf{M}onitor \\
|
||||
\textbf{NFV} & \textbf{N}etwork \textbf{F}unction \textbf{V}irtualization \\
|
||||
\textbf{IPC} & \textbf{I}nter \textbf{P}rocess \textbf{C}ommunication \\
|
||||
\textbf{Vuls} & \textbf{VUL}nerability \textbf{S}canner \\
|
||||
\textbf{LUNAR} & \textbf{L}ockdown \textbf{UN}ix \textbf{A}uditing and \textbf{R}eporting \\
|
||||
\textbf{CVE} & \textbf{C}ommon \textbf{V}ulnerabilities and \textbf{E}xposures \\
|
||||
\textbf{CVRF} & \textbf{C}ommon \textbf{V}ulnerability \textbf{R}eporting \textbf{F}ramework \\
|
||||
\textbf{NVD} & \textbf{N}ational \textbf{V}ulnerability \textbf{D}atabase \\
|
||||
\textbf{CVSS} & \textbf{C}ommon \textbf{V}ulnerability \textbf{S}coring \textbf{S}ystem \\
|
||||
\textbf{CPE} & \textbf{C}ommon \textbf{P}latform \textbf{E}numeration \\
|
||||
\textbf{CWE} & \textbf{C}ommon \textbf{W}eakness \textbf{E}numeration \\
|
||||
\textbf{NIST} & \textbf{N}ational \textbf{I}nstitute of \textbf{S}tandards and \textbf{T}echnology \\
|
||||
\textbf{OVAL} & \textbf{O}pen \textbf{V}ulnerability and \textbf{A}ssessment \textbf{L}anguage \\
|
||||
\textbf{CISA} & \textbf{C}ybersecurity \& \textbf{I}nfrastructure \textbf{S}ecurity \textbf{A}gency \\
|
||||
\textbf{CERT} & \textbf{C}omputer \textbf{E}mergency \textbf{R}esponse \textbf{T}eam \\
|
||||
|
||||
\textbf{CAPEC} & \textbf{C}ommon \textbf{A}ttack \textbf{P}attern \textbf{E}numeration and \textbf{C}lassification \\
|
||||
\textbf{CCE} & \textbf{C}ommon \textbf{C}onfiguration \textbf{E}numeration \\
|
||||
\textbf{ATT\&CK} & \textbf{A}dversarial \textbf{T}actics, \textbf{T}echniques \textbf{\&} \textbf{C}ommon \textbf{K}nowledge \\
|
||||
\textbf{PoC} & \textbf{P}roof \textbf{o}f \textbf{C}oncept \\
|
||||
\textbf{SSH} & \textbf{S}ecure \textbf{SH}ell \\
|
||||
\textbf{AMI} & \textbf{A}mazon \textbf{M}achine \textbf{I}mage \\
|
||||
\textbf{GiB} & \textbf{Gi}bi\textbf{B}yte \\
|
||||
\textbf{EBS} & \textbf{E}lastic \textbf{B}lock \textbf{S}tore \\
|
||||
\textbf{GHz} & \textbf{G}iga\textbf{H}ert\textbf{z} \\
|
||||
\textbf{Gbps} & \textbf{G}iga\textbf{b}its \textbf{p}er \textbf{s}econd \\
|
||||
\textbf{CERT} & \textbf{C}omputer \textbf{E}mergency \textbf{R}esponse \textbf{T}eam \\
|
||||
\textbf{cgroups} & \textbf{c}ontrol \textbf{groups} \\
|
||||
\textbf{CI/CD} & \textbf{C}ontinuous \textbf{I}ntegration / \textbf{C}ontinuous \textbf{D}elivery \\
|
||||
\textbf{CIS} & \textbf{C}enter for \textbf{I}nternet \textbf{S}ecurity \\
|
||||
\textbf{ARP} & \textbf{A}ddress \textbf{R}esolution \textbf{P}rotocol \\
|
||||
\textbf{DNS} & \textbf{D}omain \textbf{N}ame \textbf{S}ystem \\
|
||||
\textbf{MitM} & \textbf{M}an-\textbf{i}n-\textbf{t}he-\textbf{M}iddle \\
|
||||
\textbf{CISA} & \textbf{C}ybersecurity \& \textbf{I}nfrastructure \textbf{S}ecurity \textbf{A}gency \\
|
||||
\textbf{CPE} & \textbf{C}ommon \textbf{P}latform \textbf{E}numeration \\
|
||||
\textbf{CPU} & \textbf{C}entral \textbf{P}rocessing \textbf{U}nit \\
|
||||
\textbf{SELinux} & \textbf{S}ecurity-\textbf{E}nhanced \textbf{Linux} \\
|
||||
\textbf{SecComp} & \textbf{Sec}ure \textbf{Comp}uting \\
|
||||
\textbf{AppArmor} & \textbf{App}lication \textbf{Armor} \\
|
||||
\textbf{CVE} & \textbf{C}ommon \textbf{V}ulnerabilities and \textbf{E}xposures \\
|
||||
\textbf{CVSS} & \textbf{C}ommon \textbf{V}ulnerability \textbf{S}coring \textbf{S}ystem \\
|
||||
\textbf{CVRF} & \textbf{C}ommon \textbf{V}ulnerability \textbf{R}eporting \textbf{F}ramework \\
|
||||
\textbf{CWE} & \textbf{C}ommon \textbf{W}eakness \textbf{E}numeration \\
|
||||
|
||||
\textbf{DevOps} & \textbf{Dev}elopment \textbf{Op}eration\textbf{s} \\
|
||||
\textbf{DNS} & \textbf{D}omain \textbf{N}ame \textbf{S}ystem \\
|
||||
|
||||
\textbf{EBS} & \textbf{E}lastic \textbf{B}lock \textbf{S}tore \\
|
||||
\textbf{EC2} & \textbf{E}lastic \textbf{C}ompute \textbf{C}loud \\
|
||||
|
||||
\textbf{Gbps} & \textbf{G}iga\textbf{b}its \textbf{p}er \textbf{s}econd \\
|
||||
\textbf{GCE} & \textbf{G}oogle \textbf{C}ompute \textbf{E}ngine \\
|
||||
\textbf{GHz} & \textbf{G}iga\textbf{H}ert\textbf{z} \\
|
||||
\textbf{GiB} & \textbf{Gi}bi\textbf{B}yte \\
|
||||
|
||||
\textbf{IaaS} & \textbf{I}nfrastructure \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{IAM} & \textbf{I}dentity and \textbf{A}ccess \textbf{M}anagement \\
|
||||
\textbf{IaC} & \textbf{I}nfrastructure \textbf{a}s \textbf{C}ode \\
|
||||
\textbf{IP} & \textbf{I}nternet \textbf{P}rotocol \\
|
||||
\textbf{IPC} & \textbf{I}nter \textbf{P}rocess \textbf{C}ommunication \\
|
||||
\textbf{IPv4} & \textbf{I}nternet \textbf{P}rotocol \textbf{v}ersion \textbf{4} \\
|
||||
|
||||
\textbf{KVM} & \textbf{K}ernel-based \textbf{V}irtual \textbf{M}achine \\
|
||||
|
||||
\textbf{LAN} & \textbf{L}ocal \textbf{A}rea \textbf{N}etwork \\
|
||||
\textbf{LUNAR} & \textbf{L}ockdown \textbf{UN}ix \textbf{A}uditing and \textbf{R}eporting \\
|
||||
\textbf{LXC} & \textbf{L}inu\textbf{x} \textbf{C}ontainers \\
|
||||
|
||||
\textbf{MAC} & \textbf{M}andatory \textbf{A}ccess \textbf{C}ontrol \\
|
||||
\textbf{MAC} & \textbf{M}edium \textbf{A}ccess \textbf{C}ontrol \\
|
||||
\textbf{MitM} & \textbf{M}an-\textbf{i}n-\textbf{t}he-\textbf{M}iddle \\
|
||||
|
||||
\textbf{NFV} & \textbf{N}etwork \textbf{F}unction \textbf{V}irtualization \\
|
||||
\textbf{NIST} & \textbf{N}ational \textbf{I}nstitute of \textbf{S}tandards and \textbf{T}echnology \\
|
||||
\textbf{NVD} & \textbf{N}ational \textbf{V}ulnerability \textbf{D}atabase \\
|
||||
|
||||
\textbf{OCI} & \textbf{O}pen \textbf{C}ontainer \textbf{I}nitiative \\
|
||||
\textbf{OS} & \textbf{O}perating \textbf{S}ystem \\
|
||||
\textbf{OVAL} & \textbf{O}pen \textbf{V}ulnerability and \textbf{A}ssessment \textbf{L}anguage \\
|
||||
\textbf{OWASP} & \textbf{O}pen \textbf{W}eb \textbf{A}pplication \textbf{S}ecurity \textbf{P}roject \\
|
||||
|
||||
\textbf{PaaS} & \textbf{P}latform \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{PoC} & \textbf{P}roof \textbf{o}f \textbf{C}oncept \\
|
||||
|
||||
\textbf{RAM} & \textbf{R}andom \textbf{A}ccess \textbf{M}emory \\
|
||||
|
||||
\textbf{SaaS} & \textbf{S}oftware \textbf{a}s \textbf{a} \textbf{S}ervice \\
|
||||
\textbf{SDK} & \textbf{S}oftware \textbf{D}evelopment \textbf{K}it \\
|
||||
\textbf{SecComp} & \textbf{Sec}ure \textbf{Comp}uting \\
|
||||
\textbf{SecDep} & \textbf{Sec}ure \textbf{Dep}loyment \\
|
||||
\textbf{SELinux} & \textbf{S}ecurity-\textbf{E}nhanced \textbf{Linux} \\
|
||||
\textbf{SSH} & \textbf{S}ecure \textbf{SH}ell \\
|
||||
|
||||
\textbf{TPM} & \textbf{T}rusted \textbf{P}latform \textbf{M}odule \\
|
||||
|
||||
\textbf{UEFI} & \textbf{U}nified \textbf{E}xtensible \textbf{F}irmware \textbf{I}nterface \\
|
||||
|
||||
\textbf{VBS} & \textbf{V}irtualization-\textbf{B}ased \textbf{S}ecurity \\
|
||||
\textbf{VM} & \textbf{V}irtual \textbf{M}achine \\
|
||||
\textbf{VMM} & \textbf{V}irtual \textbf{M}achine \textbf{M}onitor \\
|
||||
\textbf{Vuls} & \textbf{VUL}nerability \textbf{S}canner \\
|
||||
|
||||
\textbf{XSS} & \textbf{C}ross \textbf{S}ite \textbf{S}cripting \\
|
||||
|
||||
\textbf{ΛΣ} & \textbf{Λ}ειτουργικό \textbf{Σ}ύστημα \\
|
||||
\textbf{ΤΠ} & \textbf{Τ}εχνολογίες \textbf{Π}ληροφορικής \\
|
||||
\textbf{ΤΠ} & \textbf{Τ}εχνολογίες \textbf{Π}ληροφοριών \\
|
||||
}
|
||||
|
||||
\lhead{}
|
||||
|
||||
@@ -6,27 +6,27 @@
|
||||
\hyphenation{αυτές νέφος}
|
||||
|
||||
\noindent Τη σημερινή εποχή, όλο και περισσότερος κόσμος βασίζεται πλέον σε
|
||||
υπηρεσίες τύπου IaaS έναντι των παραδοσιακών επιτόπιων υποδομών για την παροχή
|
||||
υπολογιστικής υποστήριξης σε εφαρμογές, υπηρεσίες και επιχειρησιακές
|
||||
διαδικασίες. Αυτό συμβαίνει διότι κατ' αυτό τον τρόπο μειώνονται τα έξοδα ενός
|
||||
οργανισμού ή μιας επιχείρησης εφόσον δεν υπάρχει ανάγκη δαπάνης/επένδυσης για
|
||||
την αγορά εξοπλισμού και το λειτουργικό κόστος χρήσης υπηρεσιών IaaS βασίζεται
|
||||
σε ευέλικτα μοντέλα χρέωσης με βάση την χρήση (των πόρων υποδομής που
|
||||
προσφέρονται). Επιπλέον, είναι δυνατή η κλιμάκωση της προσφερόμενης
|
||||
απομακρυσμένης υποδομής ανάλογα με τις ανάγκες του οργανισμού και του τρέχοντος
|
||||
φόρτου εργασίας των υπηρεσιών και εφαρμογών προς υποστήριξη. Με αυτόν τον
|
||||
τρόπο, μεταβιβάζεται η ευθύνη της διάθεσης και συντήρησης του εξοπλισμού σε
|
||||
τρίτους ενώ ταυτόχρονα εισάγεται ένα καινούριο μοντέλο εμπιστοσύνης ανάμεσα
|
||||
στον χρήστη/οργανισμό και τον πάροχο νέφους. Η αύξηση ενδιαφέροντος από τις
|
||||
επιχειρήσεις προς τις τεχνολογίες εικονικοποίησης, οι οποίες αποτελούν τα
|
||||
θεμέλια των υπηρεσιών IaaS, αλλά και η ραγδαία άνοδος της δημοτικότητας των
|
||||
τεχνολογιών δοχείων (containers) όπως είναι το Docker, άρχισαν με την σειρά
|
||||
τους να ενισχύουν την υιοθέτηση της αρχιτεκτονικής μικρο-υπηρεσιών για την
|
||||
ανάπτυξη εφαρμογών. Μιας αρχιτεκτονικής που βασίζεται τόσο στις τεχνολογίες
|
||||
εικονικοποίησης για την στέγαση των εφαρμογών σε υποδομές νέφους όσο και στις
|
||||
τεχνολογίες δοχείων για την διαμέριση των λειτουργιών τους σε ένα σύνολο από
|
||||
συστατικά/δοχεία, προσφέροντας ένα κατάλληλο επίπεδο απόδοσης και
|
||||
κλιμακωσιμότητας \footfullcite{awsMicroservices}. Ωστόσο, οι εφαρμογές αυτές
|
||||
υπηρεσίες τύπου IaaS (Infrastructure-as-a-Service) έναντι των παραδοσιακών
|
||||
επιτόπιων υποδομών για την παροχή υπολογιστικής υποστήριξης σε εφαρμογές,
|
||||
υπηρεσίες και επιχειρησιακές διαδικασίες. Αυτό συμβαίνει διότι κατ' αυτό τον
|
||||
τρόπο μειώνονται τα έξοδα ενός οργανισμού ή μιας επιχείρησης εφόσον δεν υπάρχει
|
||||
ανάγκη δαπάνης/επένδυσης για την αγορά εξοπλισμού και το λειτουργικό κόστος
|
||||
χρήσης υπηρεσιών IaaS βασίζεται σε ευέλικτα μοντέλα χρέωσης με βάση την χρήση
|
||||
(των πόρων υποδομής που προσφέρονται). Επιπλέον, είναι δυνατή η κλιμάκωση της
|
||||
προσφερόμενης απομακρυσμένης υποδομής ανάλογα με τις ανάγκες του οργανισμού και
|
||||
του τρέχοντος φόρτου εργασίας των υπηρεσιών και εφαρμογών προς υποστήριξη. Με
|
||||
αυτόν τον τρόπο, μεταβιβάζεται η ευθύνη της διάθεσης και συντήρησης του
|
||||
εξοπλισμού σε τρίτους ενώ ταυτόχρονα εισάγεται ένα καινούριο μοντέλο
|
||||
εμπιστοσύνης ανάμεσα στον χρήστη/οργανισμό και τον πάροχο νέφους. Η αύξηση
|
||||
ενδιαφέροντος από τις επιχειρήσεις προς τις τεχνολογίες εικονικοποίησης, οι
|
||||
οποίες αποτελούν τα θεμέλια των υπηρεσιών IaaS, αλλά και η ραγδαία άνοδος της
|
||||
δημοτικότητας των τεχνολογιών δοχείων (containers) όπως είναι το Docker,
|
||||
άρχισαν με την σειρά τους να ενισχύουν την υιοθέτηση της αρχιτεκτονικής
|
||||
μικρο-υπηρεσιών για την ανάπτυξη εφαρμογών. Μιας αρχιτεκτονικής που βασίζεται
|
||||
τόσο στις τεχνολογίες εικονικοποίησης για την στέγαση των εφαρμογών σε υποδομές
|
||||
νέφους όσο και στις τεχνολογίες δοχείων για την διαμέριση των λειτουργιών τους
|
||||
σε ένα σύνολο από συστατικά/δοχεία, προσφέροντας ένα κατάλληλο επίπεδο απόδοσης
|
||||
και κλιμακωσιμότητας \cite{awsMicroservices}. Ωστόσο, οι εφαρμογές αυτές
|
||||
παραμένουν άμεσα ευεπηρέαστες σε ζητήματα ασφάλειας που μπορεί να αφορούν το
|
||||
ίδιο το νέφος ή/και τις τεχνολογίες στις οποίες στηρίζεται.
|
||||
|
||||
@@ -34,7 +34,7 @@
|
||||
|
||||
Στην παρούσα εργασία θα αναλύσουμε πρώτα τα ζητήματα ασφαλείας που αφορούν το
|
||||
νέφος και ειδικότερα αυτά που αφορούν τις τεχνολογίες εικονικοποίησης και
|
||||
δοχείων. Έπειτα, θα αναλύσουμε πως μπορεί να γίνει χρήση αυτών των 2
|
||||
δοχείων. Έπειτα, θα αναλύσουμε πως μπορεί να γίνει χρήση αυτών των δύο
|
||||
τεχνολογιών με περισσότερη ασφάλεια. Όμως, ο σκοπός της εργασίας προχωρά πέρα
|
||||
από αυτό και μεταβαίνει σε ένα πρακτικό επίπεδο, προτείνοντας τη λύση ενός
|
||||
εργαλείου που υλοποιεί την προτεινόμενη, ασφαλή χρήση των τεχνολογιών αυτών.
|
||||
@@ -51,7 +51,7 @@
|
||||
των λειτουργικών συστημάτων.
|
||||
|
||||
\vskip 60pt
|
||||
\noindent \textbf{Λέξεις κλειδιά:} Νέφος, Ασφάλεια, Εικονικοποίηση, Δοχεία, Μικρο-υπηρεσίες, Αυτοματοποίηση
|
||||
\noindent \textbf{Λέξεις κλειδιά:} Νέφος, Ασφάλεια, Εικονικοποίηση, Εικονικές Μηχανές, Δοχεία, Μηχανή Δοχείων, Μικρο-υπηρεσίες, Αυτοματοποίηση, Σκλήρυνση
|
||||
|
||||
}
|
||||
|
||||
|
||||
@@ -2,16 +2,17 @@
|
||||
% skip indentation just for this paragraph
|
||||
\textenglish{
|
||||
|
||||
\noindent Today, more and more people rely on IaaS services over traditional
|
||||
on-premise infrastructure to provide computational support to applications,
|
||||
services and business processes. That happens because in this way, the costs of
|
||||
an organization or business are reduced, since there is no need for an upfront
|
||||
investment on the purchase of equipment. Also, the operational cost of using
|
||||
IaaS services is based on flexible billing models according to the usage (of
|
||||
the offered infrastructure resources). In addition, it is possible to scale the
|
||||
offered remote infrastructure, depending on the needs of the organization and
|
||||
the current workload of the services and applications to be supported. In this
|
||||
way, the responsibility for the equipment and its maintenance is transferred to
|
||||
\noindent Today, more and more people rely on IaaS
|
||||
(Infrastructure-as-a-Service) services over a traditional on-premise
|
||||
infrastructure to provide computational support to applications, services and
|
||||
business processes. This is due to the fact that the costs of an organization
|
||||
or business are reduced, since there is no need for an upfront investment on
|
||||
the purchase of equipment. Also, the operational cost of using IaaS services is
|
||||
based on flexible billing models according to the usage (of the offered
|
||||
infrastructure resources). In addition, it is possible to scale the offered
|
||||
remote infrastructure, depending on the needs of the organization and the
|
||||
current workload of the services and applications to be supported. In this way,
|
||||
the responsibility for the equipment and its maintenance is transferred to
|
||||
third parties, while at the same time a new trust model is introduced between
|
||||
the user/organization and the cloud provider. The increased interest shown by
|
||||
enterprises when in comes to virtualization technologies (which are a key
|
||||
@@ -21,9 +22,9 @@ adoption of the microservices architecture for application development. An
|
||||
architecture based on virtualization technologies for hosting applications in
|
||||
cloud infrastructures and container technologies for partitioning their
|
||||
functions into a set of containers and thus, providing an appropriate level of
|
||||
performance and scalability \footfullcite{awsMicroservices}. However, the
|
||||
applications in question remain vulnerable to security issues that may be tied
|
||||
to the cloud and/or the technologies on which it is based on.
|
||||
performance and scalability \cite{awsMicroservices}. However, such applications
|
||||
remain vulnerable to security issues that may be tied to the cloud and/or the
|
||||
technologies on which it is based.
|
||||
|
||||
}
|
||||
|
||||
@@ -31,19 +32,19 @@ to the cloud and/or the technologies on which it is based on.
|
||||
|
||||
\textenglish{
|
||||
|
||||
In this paper we will first analyze the security issues related to the cloud
|
||||
In this thesis we will first analyze the security issues related to the cloud
|
||||
and in particular, those related to virtualization and container technologies.
|
||||
Then, we will analyze how these 2 technologies can be used in a more secure
|
||||
manner. However, the purpose of this paper goes beyond that and moves to a more
|
||||
practical level by proposing the solution of a tool that can implement the
|
||||
Then, we will analyze how these two technologies can be used in a more secure
|
||||
manner. However, the purpose of this thesis goes beyond that and moves to a
|
||||
more practical level by proposing the solution of a tool that can implement the
|
||||
proposed safe use of these technologies. In particular, this tool can not only
|
||||
create virtual machines across multiple cloud providers but also harden them in
|
||||
an automated manner. In addition to that, it is capable of installing the
|
||||
Docker container engine on these virtual machines, which it can also harden.
|
||||
The main goal of this work is to make it easier for an organization to install
|
||||
and configure in an automated manner a secure, distributed environment for the
|
||||
an automated manner. In addition, it is capable of installing the Docker
|
||||
container engine on these virtual machines, which it can also harden. The main
|
||||
goal of this work is to make it easier for an organization to install and
|
||||
configure in an automated manner a secure, distributed environment for the
|
||||
deployment and operation of a microservices application. This automation lies
|
||||
in the correct configuration of the tool, which does not require any special
|
||||
in the correct configuration of our tool, which does not require any special
|
||||
knowledge on technical or security issues in regard to infrastructure and
|
||||
operating systems.
|
||||
|
||||
@@ -52,7 +53,7 @@ operating systems.
|
||||
\vskip 60pt
|
||||
|
||||
\textenglish{
|
||||
\noindent \textbf{Keywords:} Cloud, Security, Virtualization, Containers, Micro-services, Automation
|
||||
\noindent \textbf{Keywords:} Cloud, Security, Virtualization, Virtual Machines, Containers, Container Engine, Micro-services, Automation, Hardening
|
||||
}
|
||||
|
||||
}
|
||||
|
||||
@@ -1187,3 +1187,17 @@
|
||||
url = {https://github.com/doxygen/doxygen},
|
||||
urldate = {2024-01-05},
|
||||
}
|
||||
|
||||
@online{mysql,
|
||||
title = {MySQL},
|
||||
author = {Oracle},
|
||||
url = {https://www.mysql.com/},
|
||||
urldate = {2024-01-05},
|
||||
}
|
||||
|
||||
@online{nginx,
|
||||
title = {NGINX},
|
||||
author = {NGINX},
|
||||
url = {https://nginx.org/en/},
|
||||
urldate = {2024-01-05},
|
||||
}
|
||||
|
||||
@@ -1,10 +1,12 @@
|
||||
\chapter{Εισαγωγή} \label{introduction}
|
||||
|
||||
\hyphenation{πολλαπλών}
|
||||
|
||||
\noindent Παραδοσιακά, όταν ένας χρήστης/εταιρεία επιθυμούσε να διαθέτει μια
|
||||
υπηρεσία στο ευρύ κοινό θα έπρεπε να επενδύσει ένα κατάλληλο κεφάλαιο για την
|
||||
αγορά εξοπλισμού. Σε περίπτωση που η υπηρεσία αυτή τύγχανε ευρείας αποδοχής,
|
||||
καθίστατο επιτακτική η ανάγκη της επέκτασης του υφιστάμενου εξοπλισμού αλλά και
|
||||
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεις δεδομένων
|
||||
της εγκατάστασης όλων των αναγκαίων πόρων λογισμικού (βάσεων δεδομένων
|
||||
(Databases), λογισμικό της υπηρεσίας, αρχείων ρυθμίσεων, κ.λπ.) στα νέα
|
||||
κομμάτια εξοπλισμού που αγοράσθηκαν. Η παραπάνω διαδικασία απαιτούσε επιπλέον
|
||||
κεφάλαιο και αρκετές εργατοώρες προκειμένου να γίνει πράξη. Επιπρόσθετα, η
|
||||
@@ -15,31 +17,33 @@
|
||||
όταν η Amazon, ψάχνοντας τρόπους να κλιμακώσει τις υπηρεσίες που προσέφερε στον
|
||||
τομέα του ηλεκτρονικού εμπορίου (e-commerce), δημιούργησε την θυγατρική της,
|
||||
AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρεσίες
|
||||
νεφο-υπολογιστικής και συγκεκριμένα, την EC2 (Elastic Compute Cloud), μια
|
||||
υπηρεσία τύπου IaaS (Infrastructure as a Service). Πρόκειται για την πρώτη
|
||||
υπηρεσία ενοικίασης υπολογιστικών πόρων προς αξιοποίηση από οργανισμούς και
|
||||
επιχειρήσεις προκειμένου να επιταχυνθεί η διαδικασία διάθεσης των δικών τους
|
||||
υπηρεσιών. Αυτό το μοντέλο λειτουργίας παρέχει πολλά πλεονεκτήματα, όπως το
|
||||
μικρότερο κόστος εκκίνησης διάθεσης υπηρεσιών, η διευκόλυνση κλιμάκωσής τους
|
||||
(είτε οριζόντιας όπου μοιράζεται ο φόρτος εργασίας σε παραπάνω διακομιστές είτε
|
||||
κάθετης κατά την οποία ένας διακομιστής αναβαθμίζεται με ισχυρότερες
|
||||
προδιαγραφές \footfullcite{cloudzeroScalability}) και η απαλλαγή ευθύνης
|
||||
σχετικά με την συνεχή λειτουργία του εξοπλισμού στον οποίο στεγάζονται.
|
||||
νεφο-υπολογιστικής (Cloud Computing Services) και συγκεκριμένα, την EC2
|
||||
(Elastic Compute Cloud), μια υπηρεσία τύπου IaaS (Infrastructure as a Service)
|
||||
(Υποδομή ως Υπηρεσία). Πρόκειται για την πρώτη υπηρεσία ενοικίασης
|
||||
υπολογιστικών πόρων προς αξιοποίηση από οργανισμούς και επιχειρήσεις
|
||||
προκειμένου να επιταχυνθεί η διαδικασία διάθεσης των δικών τους υπηρεσιών. Αυτό
|
||||
το μοντέλο λειτουργίας παρέχει πολλά πλεονεκτήματα, όπως το μικρότερο κόστος
|
||||
εκκίνησης διάθεσης υπηρεσιών, η διευκόλυνση κλιμάκωσής τους (είτε οριζόντιας
|
||||
όπου μοιράζεται ο φόρτος εργασίας σε παραπάνω διακομιστές είτε κάθετης κατά την
|
||||
οποία ένας διακομιστής αναβαθμίζεται με ισχυρότερες προδιαγραφές
|
||||
\cite{cloudzeroScalability}) και η απαλλαγή ευθύνης σχετικά με την συνεχή
|
||||
λειτουργία του εξοπλισμού στον οποίο στεγάζονται.
|
||||
|
||||
Λόγω της ευρείας αποδοχής της και των πολλών πλεονεκτημάτων που παρέχει, πολλές
|
||||
άλλες εταιρείες, όπως η Google, IBM και Microsoft, άρχισαν να προσφέρουν και
|
||||
αυτές υπηρεσίες ιδίου τύπου. Σήμερα, ο μέσος καταναλωτής έχει στην διάθεση του
|
||||
μια πληθώρα εταιρειών που προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα
|
||||
μερικές από αυτές, όπως η Linode, Vultr και Digital Ocean, προσφέρουν ως την
|
||||
κύρια υπηρεσία τους τη δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με
|
||||
τη μορφή ενοικίασης εικονικών μηχανών.
|
||||
Λόγω της ευρείας αποδοχής των υπηρεσιών IaaS της AWS και των πολλών
|
||||
πλεονεκτημάτων που αυτές παρέχουν, πολλές άλλες εταιρείες, όπως η Google, IBM
|
||||
και Microsoft, άρχισαν να προσφέρουν και αυτές υπηρεσίες του ίδιου τύπου.
|
||||
Σήμερα, ο μέσος καταναλωτής έχει στην διάθεση του μια πληθώρα εταιρειών που
|
||||
προσφέρουν υπηρεσίες νεφο-υπολογιστικής και μάλιστα μερικές από αυτές, όπως η
|
||||
Linode, Vultr και Digital Ocean, προσφέρουν ως την κύρια υπηρεσία τους τη
|
||||
δυνατότητα διάθεσης υπολογιστικών πόρων στους χρήστες με τη μορφή ενοικίασης
|
||||
εικονικών μηχανών (Virtual Machines).
|
||||
|
||||
\section{Ασφάλεια Περιβαλλόντων Νέφους} \label{cloudComputingSecurity}
|
||||
|
||||
Η ασφάλεια των περιβαλλόντων νέφους είναι ένα θέμα που απασχολεί πολύ τους
|
||||
χρήστες και ακόμα περισσότερο τις επιχειρήσεις που βασίζονται σε υπηρεσίες
|
||||
νεφο-υπολογιστικής για την διάθεση των δικών τους υπηρεσιών. Η επίτευξη της
|
||||
εξαρτάται από 3 βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
|
||||
εξαρτάται από τρεις βασικούς παράγοντες. Ο πρώτος είναι η ασφάλεια των υποδομών
|
||||
νέφους, όπου στην περίπτωση χρήσης υπηρεσιών IaaS υπεύθυνος είναι ο πάροχος
|
||||
νέφους. Ο δεύτερος παράγοντας είναι η ασφάλεια των τεχνολογιών εικονικοποίησης
|
||||
που χρησιμοποιούνται, όπου υπεύθυνος είναι εν μέρει ο πάροχος για τις
|
||||
@@ -47,29 +51,28 @@ AWS (Amazon Web Services). Η AWS άρχισε να προσφέρει υπηρ
|
||||
(εικονικούς) διακομιστές του και ο τελικός χρήστης εφόσον προβεί στην χρήση
|
||||
δοχείων. Ο τρίτος και τελευταίος παράγοντας είναι οι ενέργειες στις οποίες
|
||||
οφείλει να προβεί ο χρήστης προκειμένου να διατηρήσει ή να ενισχύσει την
|
||||
ασφάλεια σύμφωνα με τις ανάγκες του.
|
||||
ασφάλεια της υπηρεσίας του (που θα φιλοξενείται από μια υποδομή νέφους) σύμφωνα
|
||||
με τις ανάγκες του.
|
||||
|
||||
Όταν επιλέξει ένας χρήστης να δημιουργήσει εικονικές μηχανές μέσω μιας από τις
|
||||
πλατφόρμες IaaS, προς διευκόλυνσή του η διαδικασία γίνεται και μέσω γραφικού
|
||||
περιβάλλοντος της μορφής Point and Click. Στις εικονικές μηχανές που
|
||||
διαθέσιμες πλατφόρμες IaaS, προς διευκόλυνσή του η διαδικασία γίνεται και μέσω
|
||||
γραφικού περιβάλλοντος της μορφής Point and Click. Στις εικονικές μηχανές που
|
||||
προσφέρονται, τις περισσότερες φορές διατίθενται διάφορες διανομές λειτουργικού
|
||||
συστήματος Linux, οι οποίες ενδέχεται να έχουν εγκατεστημένα και ρυθμισμένα εκ
|
||||
των προτέρων διάφορα λογισμικά, όπως το σύστημα διαχείρισης βάσεων δεδομένων
|
||||
MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τρόπο, η διαδικασία
|
||||
δημιουργίας εικονικής μηχανής είναι αρκετά εύκολη για τον χρήστη, ο οποίος δεν
|
||||
χρειάζεται να έχει ειδικές γνώσεις στο υλικό για να το πετύχει αυτό. Στην
|
||||
προκειμένη περίπτωση, ενώ υπήρχε μηδενική δυσκολία για την απόκτηση εικονικής
|
||||
μηχανής εξοπλισμένης με λειτουργικό σύστημα και πιθανότατα απαραίτητα προς
|
||||
χρήση προγράμματα, η ασφάλειά της δεν είναι πάντοτε εγγυημένη. Πολλά από τα
|
||||
προγράμματα που θα χρησιμοποιήσει ο χρήστης δεν παρέχουν εξ αρχής
|
||||
ενεργοποιημένες τις παραμέτρους ασφαλείας που μπορεί να υποστηρίζουν διότι δεν
|
||||
δύναται να υπάρχει μια ασφαλής ρύθμιση που να καλύπτει όλα τα πιθανά σενάρια
|
||||
χρήσης. Επιπλέον, η ρύθμιση των παραμέτρων ασφαλείας είναι μια διαδικασία που
|
||||
απαιτεί εξειδικευμένες γνώσεις και είναι αρκετά εύκολο όχι μόνο να παραλειφθεί
|
||||
αλλά και να γίνει λανθασμένα λόγω έλλειψης οικειότητας με τα εργαλεία που έχει
|
||||
στην διάθεση του ο χρήστης.
|
||||
|
||||
\clearpage
|
||||
MySQL \footfullcite{mysql} και το διακομιστή ιστού Nginx \footfullcite{nginx}.
|
||||
Με αυτό τον τρόπο, η διαδικασία δημιουργίας εικονικής μηχανής είναι αρκετά
|
||||
εύκολη για τον χρήστη, ο οποίος δεν χρειάζεται να έχει ειδικές γνώσεις στο
|
||||
υλικό για να το πετύχει αυτό. Στην προκειμένη περίπτωση, ενώ υπάρχει μηδενική
|
||||
δυσκολία για την απόκτηση εικονικής μηχανής εξοπλισμένης με λειτουργικό σύστημα
|
||||
και πιθανότατα απαραίτητα προς χρήση προγράμματα, η ασφάλειά της δεν είναι
|
||||
πάντοτε εγγυημένη. Πολλά από τα προγράμματα που θα χρησιμοποιήσει ο χρήστης δεν
|
||||
παρέχουν εξ αρχής ενεργοποιημένες τις παραμέτρους ασφαλείας που μπορεί να
|
||||
υποστηρίζουν διότι δεν δύναται να υπάρχει μια ασφαλής ρύθμιση που να καλύπτει
|
||||
όλα τα πιθανά σενάρια χρήσης. Επιπλέον, η ρύθμιση των παραμέτρων ασφαλείας
|
||||
είναι μια διαδικασία που απαιτεί εξειδικευμένες γνώσεις και είναι αρκετά εύκολο
|
||||
όχι μόνο να παραλειφθεί αλλά και να γίνει λανθασμένα λόγω έλλειψης οικειότητας
|
||||
με τα εργαλεία που έχει στην διάθεση του ο χρήστης.
|
||||
|
||||
Όπως αναφέρεται και στο \citealt{balduzzi2012security}, υπάρχουν υπηρεσίες IaaS
|
||||
που προσφέρουν διανομές λειτουργικού συστήματος Linux με εγκατεστημένα και
|
||||
@@ -81,125 +84,74 @@ MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τ
|
||||
ευαίσθητων προσωπικών δεδομένων. Στην περίπτωση που και ο πάροχος νέφους έχει
|
||||
παραλείψει να εφαρμόσει τις απαραίτητες ενημερώσεις ασφαλείας στις τεχνολογίες
|
||||
εικονικοποίησης που χρησιμοποιεί, είναι πιθανό κάποιο από τα προγράμματα αυτά
|
||||
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking
|
||||
\footfullcite{Hyperjacking} και να αποκτήσει έλεγχο του υπερ-επόπτη με
|
||||
αποτέλεσμα να είναι σε θέση να προκαλέσει ζημιές είτε σε διαφορετικές εικονικές
|
||||
μηχανές είτε στον (φυσικό) διακομιστή στον οποίο εκτελείται.
|
||||
να μπορέσει να πραγματοποιήσει μια επίθεση hyperjacking \cite{Hyperjacking} και
|
||||
να αποκτήσει έλεγχο του υπερ-επόπτη με αποτέλεσμα να είναι σε θέση να
|
||||
προκαλέσει ζημιές είτε σε διαφορετικές εικονικές μηχανές είτε στον (φυσικό)
|
||||
διακομιστή στον οποίο εκτελείται.
|
||||
|
||||
\section{Εικονικοποίηση και τεχνολογίες υλοποίησης της} \label{virtualizationTechnologiesIntroduction}
|
||||
\section{Εικονικοποίηση και τεχνολογίες υλοποίησής της} \label{virtualizationTechnologiesIntroduction}
|
||||
|
||||
Η εικονικοποίηση είναι ένας όρος που χρησιμοποιούμε όταν θέλουμε να αναφερθούμε
|
||||
στην αναπαράσταση πόρων σε εικονική μορφή με σκοπό την αναδιαμόρφωσή τους ούτως
|
||||
ώστε να ικανοποιούνται οι ανάγκες ενός συστήματος. Εφαρμόζεται σε μια πληθώρα
|
||||
πόρων όπως οι διακομιστές, το λειτουργικό σύστημα, ακόμα και τα δεδομένα. Η πιο
|
||||
συνηθισμένη χρήση εικονικοποίησης είναι αυτή των διακομιστών η οποία αποτελεί
|
||||
και τον πυλώνα της νεφο-υπολογιστικής. Προκειμένου να επιτευχθεί, απαιτείται η
|
||||
χρήση ενός υπερ-επόπτη. Ένα λογισμικό υπεύθυνο για την κατάτμηση των φυσικών
|
||||
πόρων ενός διακομιστή σε μια ή περισσότερες εικονικές αναπαραστάσεις ενός
|
||||
συνόλου αυτών με σκοπό να χρησιμοποιηθούν ως ξεχωριστοί διακομιστές.
|
||||
Η εικονικοποίηση αποτελεί μια τεχνολογία που επιτρέπει την διαμέριση πόρων ενός
|
||||
φυσικού μηχανήματος σε πολλά μικρότερα υποσύνολα αυτών. Με αυτόν τον τρόπο,
|
||||
καθίσταται ευκολότερη η διαχείρισή τους και αυξάνεται η απόδοση του υποκείμενου
|
||||
υλικού, αφού μπορεί να χρησιμοποιείται στο έπακρον. Υπάρχουν πολλά είδη
|
||||
εικονικοποίησης που αναλύονται πιο λεπτομερώς στο
|
||||
\ref{virtualizationImplementations} αλλά οι δύο βασικότερες υλοποιήσεις της
|
||||
είναι η εικονικοποίηση διακομιστών και λειτουργικών συστημάτων (δοχειοποίηση).
|
||||
|
||||
Για έναν υπερ-επόπτη υπάρχουν δύο κατηγορίες στις οποίες μπορεί να ανήκει. Είτε
|
||||
πρόκειται για υπερ-επόπτη τύπου 1 στην περίπτωση απευθείας πρόσβασης με το
|
||||
υλικό, είτε τύπου 2 εάν υπάρχει ήδη λειτουργικό σύστημα εγκατεστημένο στον
|
||||
υποκείμενο διακομιστή προς κατάτμηση. Η επιλογή τύπου υπερ-επόπτη είναι άμεσα
|
||||
εξαρτώμενη από τις ανάγκες του κάθε χρήστη. Στην περίπτωση που η ταχύτητα και η
|
||||
απόδοση είναι υψίστης σημασίας, η άμεση πρόσβαση του υπερ-επόπτη τύπου 1 στο
|
||||
υλικό συμβάλλει στην επίτευξη της διατήρησης των δύο αυτών προδιαγραφών σε
|
||||
κατάλληλες τιμές. Από την άλλη, ένας υπερ-επόπτης τύπου 2 δεν έρχεται σε
|
||||
αντιπαράθεση με το υποκείμενο ΛΣ και επιτρέπει την χρήση προγραμμάτων που το ΛΣ
|
||||
πιθανόν να μην είναι σε θέση να εκτελέσει.
|
||||
Στην εικονικοποίηση διακομιστών, ένας φυσικός διακομιστής χωρίζει με την
|
||||
βοήθεια ενός υπερ-επόπτη τους πόρους του όπως τη μνήμη, τον αποθηκευτικό χώρο
|
||||
και τον επεξεργαστή του σε πολλά μικρότερα εικονικά μηχανήματα. Κάθε εικονικό
|
||||
μηχάνημα μπορεί να εκτελεί διαφορετικό λειτουργικό σύστημα και να έχει
|
||||
διαφορετικές ρυθμίσεις από τα υπόλοιπα. Η διάθεση ενός εικονικού μηχανήματος
|
||||
δεν περιορίζεται μονάχα σε τοπικούς υπολογιστές και έτσι πολλές φορές
|
||||
συνηθίζεται η ενοικίαση τέτοιων μηχανημάτων προκειμένου να μπορέσουν να
|
||||
χρησιμοποιηθούν από τρίτα πρόσωπα για την επίτευξη των δικών τους διεργασιών.
|
||||
|
||||
\clearpage
|
||||
Η δοχειοποίηση αποτελεί μια ειδική περίπτωση εικονικοποίησης όπου αντί για το
|
||||
υλικό, εικονικοποιείται το λειτουργικό σύστημα. Αυτό, καθιστά την δοχειοποίηση
|
||||
πιο αποδοτική από την εικονικοποίηση διακομιστών καθώς δεν χρειάζεται να
|
||||
εκτελεστεί ένας υπερ-επόπτης για την διαχείριση υπολογιστικών πόρων. Επιπλέον,
|
||||
η δοχειοποίηση επιτρέπει την εκτέλεση περισσότερων εικονικών περιβαλλόντων στον
|
||||
ίδιο φυσικό διακομιστή και έτσι, η απόδοση του υλικού αυξάνεται ακόμα
|
||||
περισσότερο. Συνήθως χρησιμοποιείται για την διάθεση προγραμμάτων στο ευρύ
|
||||
κοινό, τα οποία ακολουθούν την αρχιτεκτονική μικρο-υπηρεσιών (microservices)
|
||||
και επειδή περιέχουν όλες τις απαραίτητες βιβλιοθήκες για την εκτέλεσή τους,
|
||||
χωρίς να βασίζονται στο υποκείμενο νέφος στο οποίο στεγάζονται, αποτελούν
|
||||
αρκετά δημοφιλή επιλογή τεχνολογίας διάθεσης υπηρεσιών.
|
||||
|
||||
Η εικονικοποίηση διακομιστών χωρίζεται σε δύο κατηγορίες βάσει της μεθόδου
|
||||
επίτευξης της. Την πλήρη εικονικοποίηση και την παρα-εικονικοποίηση
|
||||
\footfullcite{abacusFullParaOSVirtualization}. Στην πρώτη περίπτωση το
|
||||
λειτουργικό σύστημα που εκτελείται στον εικονικό διακομιστή συμπεριφέρεται όπως
|
||||
θα συμπεριφερόταν σε έναν φυσικό διακομιστή. Αυτό συμβαίνει διότι από μεριάς
|
||||
του λειτουργικού συστήματος δεν υπάρχει επίγνωση της εικονικοποίησης που έχει
|
||||
λάβει μέρος για να δημιουργηθούν οι εικονικοί πόροι στους οποίους στεγάζεται. Η
|
||||
πλήρης εικονικοποίηση μπορεί να είναι δύο ειδών. Υποβοηθούμενη από το λογισμικό
|
||||
ή από το υλικό. Στο πρώτο είδος, πραγματοποιείται εικονικοποίηση ολόκληρου του
|
||||
υλικού μέσω του υπερ-επόπτη που εκτελείται στο ΛΣ ενώ στο δεύτερο όπου δεν
|
||||
υπάρχει ΛΣ, δύναται το λειτουργικό σύστημα του εικονικού διακομιστή να κάνει
|
||||
χρήση της φυσικής κεντρικής μονάδας επεξεργασίας του διακομιστή φιλοξενίας εάν
|
||||
αυτή το υποστηρίζει \footfullcite{geeksforgeeksHardwareAssistedVirtualization}.
|
||||
Στην περίπτωση της παρα-εικονικοποίησης το λειτουργικό σύστημα αναγνωρίζει την
|
||||
ύπαρξη του υπερ-επόπτη και απαιτείται η τροποποίηση και των δύο ώστε να μπορούν
|
||||
να επικοινωνούν με χρήση υπερ-κλήσεων. Αν και το γεγονός αυτό μειώνει την
|
||||
συμβατότητα σε σχέση με την πλήρη εικονικοποίηση, η άμεση επικοινωνία του
|
||||
λειτουργικού συστήματος με τον υπερ-επόπτη συμβάλλει στην αύξηση της
|
||||
αποδοτικότητας.
|
||||
Τα δοχεία είναι ένα προϊόν της δοχειοποίησης και αποτελούν το αποτέλεσμα της
|
||||
εικονικοποίησης σε επίπεδο λειτουργικού συστήματος. Με την βοήθεια του
|
||||
λειτουργικού συστήματος, δημιουργούνται εικονικά περιβάλλοντα στα οποία μπορούν
|
||||
αυτά να εκτελεστούν. Ουσιαστικά, μια μηχανή δοχείων αιτείται από το λειτουργικό
|
||||
σύστημα την διάθεση ενός εικονικού περιβάλλοντος για την εκτέλεση των
|
||||
διεργασιών ενός προγράμματος. Το πρόγραμμα αυτό, καθώς και όλες οι βιβλιοθήκες
|
||||
που χρειάζεται, καθορίζονται σε μια εικόνα δοχείου (container image) την οποία
|
||||
η μηχανή δοχείων θα πρέπει να ανακτήσει, να αποθηκεύσει και με βάση αυτήν να
|
||||
δημιουργήσει το αντιστοιχούμενο δοχείο που αυτή περιγράφει.
|
||||
|
||||
\section{Εισαγωγή στα δοχεία και τον τρόπο λειτουργίας τους} \label{containerTechnologies}
|
||||
|
||||
Τα δοχεία αποτελούν και αυτά κομμάτι των τεχνολογιών εικονικοποίησης αλλά σε
|
||||
επίπεδο λειτουργικού συστήματος. Κατά την περιγραφή της διαδικασίας δημιουργίας
|
||||
δοχείων δεν χρησιμοποιείται πλέον ο όρος εικονικοποίηση αλλά δοχειοποίηση
|
||||
(containerization). Σε αντίθεση με τις τεχνολογίες εικονικοποίησης που
|
||||
αναφέρθηκαν στο \ref{virtualizationTechnologiesIntroduction}, για την
|
||||
δοχειοποίηση δεν είναι αναγκαία η ύπαρξη υπερ-επόπτη αλλά έναν παρόμοιο ρόλο
|
||||
παίρνει η μηχανή δοχείων. Επιπλέον, ενώ οι εικονικές μηχανές καταλήγουν να
|
||||
περιέχουν εικονικό αντίγραφο του υλικού, δικό τους λειτουργικό σύστημα και
|
||||
εγκατεστημένα πακέτα προς υποστήριξη ενός λογισμικού, τα δοχεία αποτελούνται
|
||||
μονάχα από το λογισμικό προς εκτέλεση και τις εξαρτήσεις που χρειάζεται
|
||||
προκειμένου να είναι λειτουργικό.
|
||||
|
||||
\clearpage
|
||||
|
||||
Τα απαραίτητα συστατικά για την επίτευξη της δοχειοποίησης είναι μια εικόνα
|
||||
δοχείου και μια μηχανή δοχείων. Στην εικόνα δοχείου εμπεριέχονται τα συστατικά
|
||||
μέρη ενός λογισμικού και οδηγίες συναρμολόγησής του προς ανάγνωση από την
|
||||
μηχανή δοχείων. Από εκεί και πέρα, για την δημιουργία δοχείων υπάρχει μια
|
||||
αλληλουχία βημάτων που πρέπει να έρθει εις πέρας. Αρχικά, η μηχανή δοχείων θα
|
||||
προσπελάσει την εικόνα δοχείου προκειμένου να εξακριβώσει τις προδιαγραφές του.
|
||||
Έπειτα, με την βοήθεια των μεθόδων απομόνωσης που έχει στην διάθεση της μέσω
|
||||
των μηχανισμών εικονικοποίησης του πυρήνα του λειτουργικού συστήματος
|
||||
φιλοξενίας, θα δημιουργήσει ένα εικονικό περιβάλλον απομονωμένο από το φυσικό
|
||||
ήδη υπάρχον και τέλος, θα πραγματοποιήσει εκκίνηση του δοχείου ως διεργασία του
|
||||
συστήματος.
|
||||
|
||||
Ορισμένα από αυτά τα βήματα περιλαμβάνουν και άλλες διαδικασίες για τις οποίες
|
||||
είναι υπεύθυνα συγκεκριμένα προγράμματα με τα οποία συνεργάζεται η μηχανή
|
||||
δοχείων. Υπάρχουν και μηχανές δοχείων χαμηλού επιπέδου έναντι των πιο γνωστών
|
||||
υψηλού επιπέδου όπως το Docker, στις οποίες λείπουν λειτουργίες όπως η απόκτηση
|
||||
εικόνων δοχείων από ένα κεντρικό αποθετήριο και ο έλεγχος εγκυρότητας των
|
||||
ρυθμίσεων των εικόνων αυτών. Οι μηχανές δοχείων υψηλού επιπέδου είναι
|
||||
ουσιαστικά μια συλλογή εργαλείων που διευκολύνουν την δοχειοποίηση
|
||||
απαλλάσσοντας τον χρήστη από την ανάγκη της χειροκίνητης εκτέλεσης των βημάτων
|
||||
της \footfullcite{sysdigContainerRuntime}.
|
||||
|
||||
Το τελικό επιθυμητό αποτέλεσμα είναι η δημιουργία ενός απομονωμένου
|
||||
περιβάλλοντος στο οποίο πραγματοποιείται η εκτέλεση ενός λογισμικού με
|
||||
βιβλιοθήκες και εξαρτήσεις διαφορετικών εκδόσεων συγκριτικά με αυτές που μπορεί
|
||||
να προϋπάρχουν στο σύστημα. Το περιβάλλον αυτό είναι υποχρεωμένο να
|
||||
χρησιμοποιήσει ένα υποσύνολο των πόρων του συστήματος που του απονεμήθηκε μέσω
|
||||
της μηχανής δοχείων. Τα παραπάνω είναι εφικτά και με την χρήση εικονικών
|
||||
μηχανών αλλά με κόστος την επιβάρυνση του συστήματος φιλοξενίας λόγω της
|
||||
αδυναμίας διαμοιρασμού των πόρων με τον τρόπο που το επιτυγχάνουν τα δοχεία.
|
||||
Κάθε δοχείο μοιράζεται τον πυρήνα του λειτουργικού συστήματος φιλοξενίας με τα
|
||||
υπόλοιπα και κάθε στρώση μιας εικόνας δοχείου αντιστοιχουμένη σε ένα
|
||||
στιγμιότυπο λογισμικού, δύναται να χρησιμοποιηθεί ταυτοχρόνως από περισσότερα
|
||||
του ενός δοχεία προς αποφυγή διπλής αποθήκευσης
|
||||
\footfullcite{codemotionContainerImages}. Επιπλέον, κάθε εικόνα δοχείου δύναται
|
||||
να χρησιμοποιηθεί ως πρότυπο για την δημιουργία μιας καινούριας, καθιστώντας
|
||||
έτσι ευκολότερη την επεκτασιμότητα ενός λογισμικού σε αντίθεση με τις εικονικές
|
||||
μηχανές όπου κάθε νέο στιγμιότυπό τους απαιτεί την επαναληπτική εκτέλεση των
|
||||
βημάτων δημιουργίας τους.
|
||||
Τα δοχεία αποτελούν μια ελαφρύτερη εναλλακτική λύση σε σύγκριση με τις
|
||||
εικονικές μηχανές και είθισται να προτιμώνται για την ανάπτυξη και διάθεση
|
||||
εφαρμογών. Αυτό οφείλεται στο γεγονός ότι η μεταφορά και αναδημιουργία τους
|
||||
μπορεί να πραγματοποιηθεί σε κάθε περιβάλλον και νέφος, καθώς και στο γεγονός
|
||||
ότι απαιτούν λιγότερους πόρους σε σχέση με τις εικονικές μηχανές διότι οι
|
||||
υποκείμενοι πόροι του συστήματος μπορούν να μοιραστούν μεταξύ των διαφορετικών
|
||||
δοχείων.
|
||||
|
||||
\subsection{Μηχανές δοχείων και εικονικοποίηση σε επίπεδο ΛΣ} \label{osVirtualization}
|
||||
|
||||
Πολλά λειτουργικά συστήματα, ειδικά αυτά που κάνουν χρήση του πυρήνα Linux
|
||||
διαθέτουν μηχανισμούς απομόνωσης διεργασιών και δυνατότητες εικονικοποίησης
|
||||
(λειτουργικού συστήματος), όπως είναι οι ομάδες ελέγχου (control groups) με τις
|
||||
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών και
|
||||
οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την δυνατότητα
|
||||
περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα αρχείων. Με την
|
||||
βοήθεια των εργαλείων που έχουν στην διάθεσή τους, δύναται να πραγματοποιηθεί
|
||||
εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος εικονικοποίησης διακομιστών όπου ο
|
||||
πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη πολλαπλών απομονωμένων περιβαλλόντων
|
||||
\footfullcite{teimouriOsVirtualizationDefinition}, τα οποία συμπεριφέρονται ως
|
||||
ξεχωριστοί διακομιστές \footfullcite{webopediaOsVirtualizationDefinition}.
|
||||
οποίες μπορεί να επιτευχθεί ο περιορισμός πόρων σε ένα υποσύνολο διεργασιών,
|
||||
καθώς και οι χώροι ονομάτων χρηστών (user namespaces) που προσφέρουν την
|
||||
δυνατότητα περιορισμού των δικαιωμάτων που έχει μια διεργασία στο σύστημα
|
||||
αρχείων. Με την βοήθεια των εργαλείων που έχουν οι μηχανές δοχείων στην διάθεσή
|
||||
τους, δύναται να πραγματοποιηθεί εικονικοποίηση σε επίπεδο ΛΣ. Μια μέθοδος
|
||||
εικονικοποίησης διακομιστών όπου ο πυρήνας ενός ΛΣ επιτρέπει την ύπαρξη
|
||||
πολλαπλών απομονωμένων περιβαλλόντων \cite{teimouriOsVirtualizationDefinition},
|
||||
τα οποία συμπεριφέρονται ως ξεχωριστοί διακομιστές
|
||||
\cite{webopediaOsVirtualizationDefinition}.
|
||||
|
||||
Μια από τις υποχρεώσεις της μηχανής δοχείων είναι η επικοινωνία με τον πυρήνα
|
||||
του λειτουργικού συστήματος φιλοξενίας για να επιτευχθεί αυτή η εικονικοποίηση.
|
||||
@@ -235,32 +187,32 @@ MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τ
|
||||
εκτελεστεί μαζί με μια εφαρμογή, τις βιβλιοθήκες και τις εξαρτήσεις της. Από
|
||||
την άλλη, ένα δοχείο αντί να εικονικοποιήσει το υλικό, εικονικοποιεί το
|
||||
λειτουργικό σύστημα ούτως ώστε κάθε δοχείο να περιέχει μόνο την εφαρμογή, τις
|
||||
βιβλιοθήκες και τις εξαρτήσεις της \footfullcite{ibmContainerVsVm}.
|
||||
βιβλιοθήκες και τις εξαρτήσεις της \cite{ibmContainerVsVm}.
|
||||
|
||||
Το σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα στην
|
||||
αρχιτεκτονική της εικονικοποίησης και των δοχείων:
|
||||
\clearpage
|
||||
|
||||
\noindent Το Σχήμα \ref{fig:containerVsVm} παρουσιάζει τις διαφορές ανάμεσα
|
||||
στην αρχιτεκτονική της εικονικοποίησης και των δοχείων.
|
||||
|
||||
\begin{center}
|
||||
\begin{figure}[!ht]
|
||||
\centering
|
||||
\includegraphics[width = .8\textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||||
\includegraphics[width = \textwidth]{Figures/RedHat_Virtualization/virtualization-vs-containers_transparent.png}
|
||||
\captionof{figure}{Χρήση εικονικοποίησης έναντι δοχείων \cite{redhatVirtualizationDefinition}}
|
||||
\label{fig:containerVsVm}
|
||||
\end{figure}
|
||||
\vspace*{-30pt}
|
||||
\end{center}
|
||||
|
||||
\clearpage
|
||||
|
||||
Η απουσία του εικονικού λειτουργικού υλικού είναι που καθιστά τα δοχεία
|
||||
γρήγορα, φορητά και μικρότερα σε μέγεθος. Για να γίνει πιο εμφανής η διαφορά,
|
||||
σύμφωνα με τη Red Hat \footfullcite{redhatContainerVsVm}, το μέγεθος των
|
||||
εικονικών μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της
|
||||
τάξεως των megabyte. Πολλές φορές, όπως αναφέρεται και στο
|
||||
\cite{ibmContainerVsVm} \footfullcite{ibmContainerVsVm}, τα δοχεία
|
||||
σύμφωνα με τη Red Hat \cite{redhatContainerVsVm}, το μέγεθος των εικονικών
|
||||
μηχανών είναι της τάξεως των gigabyte ενώ των δοχείων είναι της τάξεως των
|
||||
megabyte. Πολλές φορές, όπως αναφέρεται και σε μια δημοσίευση
|
||||
\cite{ibmContainerVsVm} της \citeauthor{ibmContainerVsVm}, τα δοχεία
|
||||
χρησιμοποιούνται για εφαρμογές αρχιτεκτονικής μικρο-υπηρεσιών (microservices),
|
||||
όπου κάθε ξεχωριστό κομμάτι (δηλ. μικρο-υπηρεσία) αντιπροσωπεύει ένα συστατικό
|
||||
της εφαρμογής που παίρνει την μορφή δοχείου. Με αυτόν τον τρόπο, είναι
|
||||
της εφαρμογής που παίρνει την μορφή ενός δοχείου. Με αυτόν τον τρόπο, είναι
|
||||
ευκολότερη η κλιμάκωση μιας εφαρμογής απ' ότι θα ήταν με μια μονολιθική
|
||||
αρχιτεκτονική. Αυτό συμβαίνει διότι μπορεί να κλιμακώνεται μόνο το μέρος ή τα
|
||||
μέρη της που έχουν αύξηση του φόρτου εργασίας τους, μέσω της χρήσης
|
||||
@@ -272,15 +224,18 @@ MySQL και το διακομιστή ιστού Nginx. Με αυτό τον τ
|
||||
στιγμιότυπα (δηλ. μεγάλο αριθμό δοχείων) ανά πάσα χρονική στιγμή, απαιτείται η
|
||||
χρήση μιας πλατφόρμας ενορχήστρωσης δοχείων για την αυτοματοποίηση της
|
||||
εγκατάστασης, εκτέλεσης και κλιμάκωσης της εφαρμογής κατά μήκος πολλαπλών πόρων
|
||||
(δηλ. εικονικών ή φυσικών μηχανών) όπως είναι το Kubernetes ή το Docker Swarm.
|
||||
(δηλ. εικονικών ή φυσικών μηχανών), όπως είναι το Kubernetes ή το Docker Swarm.
|
||||
Από την άλλη, αν είναι επιθυμητή η ενορχήστρωση των δοχείων μιας εφαρμογής σε
|
||||
έναν πόρο (φυσικό ή εικονικό μηχάνημα), τότε είναι δυνατή η χρήση εργαλείων
|
||||
όπως το Docker Compose.
|
||||
|
||||
Το μόνο μειονέκτημα της τεχνολογίας των δοχείων, το οποίο δεν επηρεάζει κατά
|
||||
πολύ τη χρήση τους, είναι το γεγονός ότι δοχεία που δημιουργήθηκαν για να
|
||||
εκτελούν προγράμματα που απαιτούν την ύπαρξη του λειτουργικού συστήματος
|
||||
Windows δε μπορούν να εκτελεστούν σε ένα περιβάλλον με τον πυρήνα του Linux και
|
||||
το ίδιο ισχύει και αντιστρόφως \footfullcite{containerOSlimitations}.
|
||||
το ίδιο ισχύει και αντιστρόφως \cite{containerOSlimitations}.
|
||||
|
||||
Εν γένει τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
|
||||
Εν γένει, τα βασικότερα πλεονεκτήματα των δοχείων σε σχέση με τις εικονικές
|
||||
μηχανές είναι ο διαμοιρασμός του πυρήνα του λειτουργικού συστήματος φιλοξενίας
|
||||
και η μεταφερσιμότητα τους. Το γεγονός ότι μοιράζονται τον ίδιο πυρήνα έχει ως
|
||||
αποτέλεσμα να μην χρειάζεται να απονεμηθούν πόροι για εικονικοποίηση μηχανών με
|
||||
@@ -297,20 +252,19 @@ Docker) όπου μάλιστα η ταχύτητα δημιουργίας το
|
||||
και Container (δοχείο) αν και είναι διαφορετικοί. Παρ' όλα αυτά, η ιδέα της
|
||||
δημιουργίας απομονωμένων περιβαλλόντων εκτέλεσης λογισμικού υπήρχε προτού βγει
|
||||
το Docker στην αγορά. Ιστορικά, οι πρώτες τεχνολογίες περί δοχείων έκαναν την
|
||||
είσοδο τους από το 1979, όταν εισήχθη το chroot \footfullcite{chrootCommand}
|
||||
στην έβδομη έκδοση του Unix \footfullcite{containerHistory}. Πρόκειται για μια
|
||||
εντολή που περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα
|
||||
συγκεκριμένο φάκελο ο οποίος ορίζεται ως ο καινούριος διαχειριστικός (root). Ο
|
||||
κύριος σκοπός του chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην
|
||||
περίπτωση εκμετάλλευσης μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν
|
||||
ανεπηρέαστα τα μέρη του συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση.
|
||||
Εκείνη την εποχή αυτό ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό
|
||||
αυξάνονταν και υπήρχε η ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από
|
||||
κατασκευής του, το chroot δεν περιόριζε έναν χρήστη ή μια διεργασία με
|
||||
διαχειριστικά δικαιώματα \footfullcite{chrootRestrictions}. Μερικά χρόνια
|
||||
αργότερα, το 2004 δημιουργήθηκαν και ενσωματώθηκαν στον πυρήνα του Linux οι
|
||||
ομάδες ελέγχου με την βοήθεια των οποίων ήταν πλέον δυνατή η απομόνωση πόρων
|
||||
του συστήματος σε ένα υποσύνολο διεργασιών.
|
||||
είσοδο τους από το 1979, όταν εισήχθη το chroot \cite{chrootCommand} στην
|
||||
έβδομη έκδοση του Unix \cite{containerHistory}. Πρόκειται για μια εντολή που
|
||||
περιορίζει την πρόσβαση αρχείων που διαθέτει μια εφαρμογή, σε ένα συγκεκριμένο
|
||||
φάκελο, ο οποίος ορίζεται ως ο καινούριος αρχικός (root). Ο κύριος σκοπός του
|
||||
chroot ήταν η ενίσχυση της ασφάλειας ούτως ώστε στην περίπτωση εκμετάλλευσης
|
||||
μιας εσωτερικής ευπάθειας της εφαρμογής, να παραμένουν ανεπηρέαστα τα μέρη του
|
||||
συστήματος εκτός του φακέλου στον οποίο είχε πρόσβαση. Εκείνη την εποχή αυτό
|
||||
ήταν αρκετό, αλλά οι απαιτήσεις ασφαλείας με τον καιρό αυξάνονταν και υπήρχε η
|
||||
ανάγκη διαφορετικών μεθόδων απομόνωσης μιας και από κατασκευής του, το chroot
|
||||
δεν περιόριζε έναν χρήστη ή μια διεργασία με διαχειριστικά δικαιώματα
|
||||
\cite{chrootRestrictions}. Μερικά χρόνια αργότερα, το 2004 δημιουργήθηκαν και
|
||||
ενσωματώθηκαν στον πυρήνα του Linux οι ομάδες ελέγχου με την βοήθεια των οποίων
|
||||
ήταν πλέον δυνατή η απομόνωση πόρων του συστήματος σε ένα υποσύνολο διεργασιών.
|
||||
|
||||
Αυτές οι τεχνολογίες σήμαναν της έναρξη της ιδέας της δοχειοποίησης και έτσι το
|
||||
2008 ήρθε στο προσκήνιο το LXC (Linux Container Technology) \footfullcite{LXC}.
|
||||
@@ -320,58 +274,57 @@ Docker) όπου μάλιστα η ταχύτητα δημιουργίας το
|
||||
εικονικοποίηση ενός στιγμιότυπου Linux σε μορφή δοχείου και παρείχε αρκετές
|
||||
λειτουργίες όπως η δημιουργία, η εκκίνηση και η διαγραφή LXC δοχείων. Παρ' όλα
|
||||
αυτά, επικεντρωνόταν στην δοχειοποίηση λειτουργικών συστημάτων και όχι
|
||||
εφαρμογών \footfullcite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την
|
||||
χρήση του όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||||
εφαρμογών \cite{LXCvsDocker}, καθιστώντας δύσκολη και περίπλοκη την χρήση του
|
||||
όταν η κύρια ανάγκη ήταν η απομόνωση εφαρμογών.
|
||||
|
||||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων τα οποία χρησιμοποιούνται
|
||||
Ενώ λοιπόν προϋπήρχαν εργαλεία διαχείρισης δοχείων, τα οποία χρησιμοποιούνται
|
||||
ακόμα και στις μέρες μας, λόγω του συνδυασμού της δυσκολίας στην χρήση τους και
|
||||
του εξειδικευμένου σκοπού ύπαρξής τους δεν είχαν υιοθετηθεί αρκετά. Όλα τα
|
||||
παραπάνω οδήγησαν στην δημιουργία του Docker το 2013, με την έλευση του οποίου
|
||||
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων
|
||||
PaaS, παρέχοντας μια πλατφόρμα με μηχανισμούς για συναρμολόγηση, θέση σε
|
||||
λειτουργία, εκτέλεση, ενημέρωση και διαχείριση προγραμμάτων σε μορφή δοχείων.
|
||||
Σε αντίθεση με το LXC, αποτελεί μια μηχανή δοχείων υψηλού επιπέδου με κύριο
|
||||
στόχο την δοχειοποίηση εφαρμογών. Εκτός από τον διαχωρισμό ανάμεσα στον πηγαίο
|
||||
κώδικα, τις βιβλιοθήκες και εξαρτήσεις ενός λογισμικού από το κύριο σύστημα
|
||||
(φιλοξενίας) παρέχει και δυνατότητες επικοινωνίας με αποθετήρια εικόνων δοχείωv
|
||||
όπως είναι το Docker Hub \footfullcite{dockerhub}, το επίσημο αποθετήριο του
|
||||
Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή
|
||||
οποιοδήποτε άλλο αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI
|
||||
(Open Container Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι
|
||||
χρήστες έχουν πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους
|
||||
επιτρέπουν να ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής.
|
||||
Επιπλέον, όντας μια μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα
|
||||
απαιτούσαν εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν
|
||||
συμπυκνωθεί σε απλές εντολές καθιστώντας έτσι εύκολη την χρήση του για
|
||||
προγραμματιστές κάθε επιπέδου και απλοποιώντας κατά πολύ την διαδικασία
|
||||
ανάπτυξης και παράδοσης κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς
|
||||
τον χρήστη διεπαφή, έλεγχο εκδόσεων (version control) για δοχεία
|
||||
\footfullcite{LXCvsDocker2} και ένα οικοσύστημα γύρω από όλα αυτά, είναι
|
||||
εμφανής ο λόγος που κατάφερε να επισκιάσει το LXC.
|
||||
|
||||
\clearpage
|
||||
η τεχνολογία των δοχείων εκτοξεύτηκε. Το Docker είναι ένα σύνολο προϊόντων PaaS
|
||||
(Platform-as-a-Service) (Πλατφόρμα ως Υπηρεσία), παρέχοντας μια πλατφόρμα με
|
||||
μηχανισμούς για συναρμολόγηση, θέση σε λειτουργία, εκτέλεση, ενημέρωση και
|
||||
διαχείριση προγραμμάτων σε μορφή δοχείων. Σε αντίθεση με το LXC, αποτελεί μια
|
||||
μηχανή δοχείων υψηλού επιπέδου με κύριο στόχο την δοχειοποίηση εφαρμογών. Εκτός
|
||||
από τον διαχωρισμό ανάμεσα στον πηγαίο κώδικα, τις βιβλιοθήκες και εξαρτήσεις
|
||||
ενός λογισμικού από το κύριο σύστημα (φιλοξενίας), παρέχει και δυνατότητες
|
||||
επικοινωνίας με αποθετήρια εικόνων δοχείωv, όπως είναι το Docker Hub
|
||||
\footfullcite{dockerhub}, το επίσημο αποθετήριο του Docker, το Quay
|
||||
\footfullcite{quay}, ένα εναλλακτικό αποθετήριο της Red Hat ή οποιοδήποτε άλλο
|
||||
αποθετήριο συμβατό με τις προδιαγραφές που έχει ορίσει η OCI (Open Container
|
||||
Initiative) \footfullcite{oci}. Μέσω τέτοιων υπηρεσιών, οι χρήστες έχουν
|
||||
πρόσβαση και διαμοιράζονται χιλιάδες εικόνες δοχείων που τους επιτρέπουν να
|
||||
ολοκληρώσουν διάφορα μέρη μιας υπάρχουσας ή νέας εφαρμογής. Επιπλέον, όντας μια
|
||||
μηχανή δοχείων υψηλού επιπέδου όλες οι λειτουργίες που θα απαιτούσαν
|
||||
εξειδικευμένες γνώσεις προκειμένου να πραγματοποιηθούν, έχουν συμπυκνωθεί σε
|
||||
απλές εντολές καθιστώντας έτσι εύκολη την χρήση του για προγραμματιστές κάθε
|
||||
επιπέδου και απλοποιώντας κατά πολύ την διαδικασία ανάπτυξης και παράδοσης
|
||||
κατανεμημένων εφαρμογών. Προσφέροντας μια φιλική προς τον χρήστη διεπαφή,
|
||||
έλεγχο εκδόσεων (version control) για δοχεία \cite{LXCvsDocker2} και ένα
|
||||
οικοσύστημα γύρω από όλα αυτά, είναι εμφανής ο λόγος που κατάφερε να επισκιάσει
|
||||
το LXC.
|
||||
|
||||
\subsection{Χρήση δοχείων στην ανάπτυξη και παράδοση εφαρμογών} \label{containerUsage}
|
||||
|
||||
Οι μέθοδοι ανάπτυξης και παράδοσης εφαρμογών έχουν αλλάξει δραματικά τα
|
||||
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους όπως το μοντέλο καταρράκτη
|
||||
(waterfall) \footfullcite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
|
||||
τελευταία χρόνια. Από τις παραδοσιακές μεθόδους, όπως το μοντέλο καταρράκτη
|
||||
(waterfall) \cite{waterfall} βάσει του οποίου υπήρχε ένα συγκεκριμένο
|
||||
αμετάβλητο σχέδιο που καλούνταν να ακολουθήσει μια ομάδα ανάπτυξης λογισμικού,
|
||||
έχουμε φτάσει σε μια εποχή όπου οι απαιτήσεις της αγοράς αλλάζουν συνεχώς, με
|
||||
αποτέλεσμα να υπάρχει ανάγκη για καινούριες μεθόδους που να ανταποκρίνονται
|
||||
στις αλλαγές αυτές. Έτσι, έχουν δημιουργηθεί μεθοδολογίες όπως η Agile
|
||||
\footfullcite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
|
||||
\cite{agile} κατά την οποία η ανάπτυξη και η παράδοση λογισμικού
|
||||
πραγματοποιείται σε πολλές μικρές και ευμετάβλητες φάσεις προκειμένου να
|
||||
προσαρμόζεται στις αλλαγές που ενδέχεται να υπάρξουν στον αρχικό σχεδιασμό. Η
|
||||
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \footfullcite{devops}
|
||||
όπου οι ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής
|
||||
επικοινωνούν στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης
|
||||
λογισμικού. Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD
|
||||
(Continuous Integration/Continuous Delivery) \footfullcite{cicd}. Κατά το
|
||||
μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες που εκτελούνται κατά
|
||||
την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής προκειμένου να
|
||||
πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να εντοπίζονται σφάλματα και
|
||||
να παράγονται εκτελέσιμα πακέτα.
|
||||
μεθοδολογία αυτή συνεργάζεται με πρακτικές όπως το DevOps \cite{devops} όπου οι
|
||||
ομάδες υπεύθυνες για την ανάπτυξη και λειτουργία μιας εφαρμογής επικοινωνούν
|
||||
στενά με σκοπό να υπάρχει μια συνεχής ροή παραγωγής και παράδοσης λογισμικού.
|
||||
Αυτό επιτυγχάνεται με μια υποκατηγορία του DevOps, το CI/CD (Continuous
|
||||
Integration/Continuous Delivery) (Συνεχής Ενοποίηση/Συνεχής Παράδοση)
|
||||
\cite{cicd}. Κατά το μοντέλο αυτό, δημιουργούνται αυτοματοποιημένες διαδικασίες
|
||||
που εκτελούνται κατά την διάρκεια της ανάπτυξης και παράδοσης μιας εφαρμογής
|
||||
προκειμένου να πραγματοποιείται έλεγχος της ποιότητας του κώδικα, να
|
||||
εντοπίζονται σφάλματα και να παράγονται εκτελέσιμα πακέτα.
|
||||
|
||||
Τα δοχεία αποτελούν ιδανική επιλογή για την εφαρμογή των παραπάνω μεθοδολογιών
|
||||
και πρακτικών καθώς επιτρέπουν το γρήγορο και αποτελεσματικό πακετάρισμα
|
||||
@@ -384,19 +337,13 @@ Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθε
|
||||
μειώνει ιδιαίτερα το κόστος λειτουργίας και αυξάνει την κλιμακωσιμότητα.
|
||||
Επιπλέον, λόγω της ταχείας διάθεσης και εκτέλεσής τους, συμβαδίζουν πλήρως με
|
||||
τον ρυθμό ανάπτυξης και παράδοσης που υποστηρίζουν οι παραπάνω μεθοδολογίες.
|
||||
|
||||
Έχοντας αυτά υπόψιν, γίνεται εμφανής και ο λόγος που τα δοχεία είναι η
|
||||
προτιμότερη επιλογή για την ανάπτυξη και παράδοση εφαρμογών που ακολουθούν την
|
||||
αρχιτεκτονική μικρο-υπηρεσιών. Σε αυτήν την περίπτωση, η εφαρμογή αποτελείται
|
||||
από πολλά δοχεία όπου το κάθε ένα από αυτά είναι υπεύθυνο για μια συγκεκριμένη
|
||||
λειτουργία της (μικρο-υπηρεσία). Τα δοχεία αυτά είναι ανεξάρτητα μεταξύ τους
|
||||
και κατά την ανάγκη κλιμάκωσης μιας συγκεκριμένης λειτουργίας της εφαρμογής
|
||||
αυτό μπορεί να επιτευχθεί δίχως την περιττή κλιμάκωση όλων των υπολοίπων.
|
||||
Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ τους, καθιστά πιο σταθερή την
|
||||
εφαρμογή αφού σε περίπτωση που κάποιο από αυτά αποτύχει, η υπόλοιπη εφαρμογή θα
|
||||
συνεχίσει να λειτουργεί κανονικά και η ανακατασκευή του δοχείου που απέτυχε
|
||||
μπορεί να επιτευχθεί εύκολα και γρήγορα με μια απλή τροποποίηση της εκάστοτε
|
||||
εικόνας δοχείου.
|
||||
αρχιτεκτονική μικρο-υπηρεσιών. Επιπρόσθετα, η ανεξαρτησία των δοχείων μεταξύ
|
||||
τους, καθιστά πιο σταθερή την εφαρμογή αφού σε περίπτωση που κάποιο από αυτά
|
||||
αποτύχει, η υπόλοιπη εφαρμογή θα συνεχίσει να λειτουργεί κανονικά και η
|
||||
ανακατασκευή του δοχείου που απέτυχε μπορεί να επιτευχθεί εύκολα και γρήγορα με
|
||||
μια απλή τροποποίηση της εκάστοτε εικόνας δοχείου.
|
||||
|
||||
\subsection{Χρήσεις του Docker στο νέφος} \label{dockerInCloudComputing}
|
||||
|
||||
@@ -404,30 +351,27 @@ Docker, το Quay \footfullcite{quay}, ένα εναλλακτικό αποθε
|
||||
τόσο για επιχειρήσεις που λειτουργούν αποκλειστικά με ενοικιαζόμενους
|
||||
υπολογιστικούς πόρους όσο και για αυτές που επιλέγουν να λειτουργούν με έναν
|
||||
συνδυασμό ενοικιαζόμενων και ιδιόκτητων φυσικών εγκαταστάσεων. Υπάρχουν δύο
|
||||
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι, η
|
||||
βασικές περιπτώσεις χρήσης του Docker στο νέφος. Συγκεκριμένα αυτές είναι: η
|
||||
εγκατάσταση δοχείων σε εικονικές μηχανές και η εγκατάσταση δοχείων έμμεσα σε
|
||||
πόρους χωρίς την ανάγκη δημιουργίας εικονικής μηχανής. Η δεύτερη περίπτωση
|
||||
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS (Container as a Service) όπως η
|
||||
ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
\footfullcite{caas} των υπηρεσιών IaaS (Infrastructure as a Service) όπου ένας
|
||||
πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
|
||||
χρήσης εντάσσεται στην κατηγορία υπηρεσιών CaaS \cite{caas} (Container as a
|
||||
Service), όπως η ECS (Elastic Container Service) της Amazon. Μια υπηρεσία όπου
|
||||
ένας πάροχος νέφους αντί να παρέχει πρόσβαση σε υπολογιστικούς πόρους γενικού
|
||||
σκοπού, παρέχει μια ευέλικτη υποδομή έτοιμη για την εκτέλεση δοχείων
|
||||
\footfullcite{caasVsIaas}.
|
||||
\cite{caasVsIaas}.
|
||||
|
||||
\clearpage
|
||||
|
||||
Από τις δύο αυτές επιλογές, η πιο δημοφιλής είναι η πρώτη καθώς προσφέρει μια
|
||||
ευελιξία ως προς την διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι
|
||||
χρήστες έχουν την δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές
|
||||
ασφαλείας που μπορεί να έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν
|
||||
επιπλέον λογισμικό παρακολούθησης και ελέγχου ποιότητας των δοχείων και να
|
||||
προσαρμόσουν το περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η
|
||||
ύπαρξη μιας επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου
|
||||
συστήματος αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο
|
||||
βρεθεί σε κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την
|
||||
περιορισμένη έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη
|
||||
την ανίχνευση και απομόνωση των προβλημάτων ασφαλείας όπως επίσης και την
|
||||
αποκατάσταση τους.
|
||||
Από τις δύο αυτές επιλογές, η πρώτη προσφέρει μια ευελιξία ως προς την
|
||||
διαμόρφωση του περιβάλλοντος εκτέλεσης των δοχείων. Οι χρήστες έχουν την
|
||||
δυνατότητα να ακολουθήσουν ορισμένες ορθές πρακτικές ασφαλείας που μπορεί να
|
||||
έχουν θεσπιστεί στην εταιρεία τους, να εγκαταστήσουν επιπλέον λογισμικό
|
||||
παρακολούθησης και ελέγχου ποιότητας των δοχείων και να προσαρμόσουν το
|
||||
περιβάλλον εκτέλεσης των δοχείων στις ανάγκες τους. Επιπλέον, η ύπαρξη μιας
|
||||
επιπλέον στρώσης απομόνωσης μεταξύ των δοχείων και του κύριου συστήματος
|
||||
αποτελεί ένα επιπρόσθετο εμπόδιο σε περιπτώσεις που ένα δοχείο βρεθεί σε
|
||||
κατάσταση παραβίασης. Το Docker επιτρέποντας μέσω των δοχείων την περιορισμένη
|
||||
έκθεση των πόρων του συστήματος στον έξω κόσμο, καθιστά ευκολότερη την
|
||||
ανίχνευση και απομόνωση των προβλημάτων ασφαλείας, όπως επίσης και την
|
||||
αποκατάστασή τους.
|
||||
|
||||
Από την άλλη, η δεύτερη περίπτωση χρήσης επιτρέπει στους χρήστες να
|
||||
επικεντρωθούν στην ανάπτυξη των δοχειοποιημένων εφαρμογών και να αφήσουν την
|
||||
@@ -436,36 +380,34 @@ ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
ή δεν είναι σε θέση να διαθέσουν τον απαιτούμενο χρόνο για αυτό. Η χρήση
|
||||
υπηρεσιών CaaS αυτομάτως εξασφαλίζει στους χρήστες τα πλεονεκτήματα των
|
||||
υπηρεσιών IaaS όπως η κλιμάκωση, η αντοχή σε αποτυχίες και η ευελιξία, ενώ
|
||||
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων όπως η ταχεία διάθεση και
|
||||
απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση. Συγκεκριμένα,
|
||||
μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες ενορχήστρωσης δοχείων
|
||||
\footfullcite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου στησίματος πλατφορμών
|
||||
όπως το Kubernetes \footfullcite{kubernetes} και το Docker Swarm
|
||||
\footfullcite{dockerSwarm}.
|
||||
|
||||
\clearpage
|
||||
ταυτόχρονα προσφέρει και τα πλεονεκτήματα των δοχείων, όπως η ταχεία διάθεση
|
||||
και απόσυρσή τους αλλά και η υψηλή τους απόδοση κατά την εκτέλεση.
|
||||
Συγκεκριμένα, μέσω των υπηρεσιών CaaS, οι χρήστες διαθέτουν δυνατότητες
|
||||
ενορχήστρωσης δοχείων \cite{howCaasWorks} χωρίς την ανάγκη χειροκίνητου
|
||||
στησίματος πλατφορμών αυτού του είδους όπως είναι το Kubernetes
|
||||
\cite{kubernetes} και το Docker Swarm \cite{dockerSwarm}.
|
||||
|
||||
Σε κάθε περίπτωση, λόγω των πλεονεκτημάτων που παρέχει η χρήση δοχείων, είναι
|
||||
πολύ συνήθης η θέση σε λειτουργία, εφαρμογών μέσω Docker σε περιβάλλοντα νέφους
|
||||
επειδή απομονώνει τις αναγκαίες βιβλιοθήκες και εξαρτήσεις τους από το υπόλοιπο
|
||||
σύστημα και επιτρέπει την αποδοτικότερη διαχείριση των εφαρμογών αυτών μέσω της
|
||||
διεπαφής του με εντολές για εκκίνηση, επιτήρηση πόρων, παύση και άλλες
|
||||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον ανάπτυξης
|
||||
όπως μη συμβατές εκδόσεις προγραμμάτων και δυσκολία διαχείρισής τους
|
||||
εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει έναν
|
||||
συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||||
λειτουργίες. Τα προβλήματα που μπορεί να προέκυπταν σε ένα περιβάλλον
|
||||
ανάπτυξης, όπως μη συμβατές εκδόσεις προγραμμάτων και δυσκολία διαχείρισής
|
||||
τους, εξαλείφονται με την χρήση δοχείων αφήνοντας το Docker να εγκαθιδρύσει
|
||||
έναν συστημικό τρόπο διανομής και ελέγχου εφαρμογών. Επιπροσθέτως, καθιστά πολύ
|
||||
εύκολη τη μεταφορά τους σε οποιοδήποτε μηχάνημα (εφόσον αυτό υποστηρίζει την
|
||||
εκτέλεση της μηχανής δοχείων του Docker) ή ακόμα και νέφος, θέτοντας το
|
||||
κορυφαία επιλογή για επιχειρήσεις που επιλέγουν να ακολουθήσουν την στρατηγική
|
||||
πολλαπλών νεφών (multi-cloud computing) κατά την κατασκευή εφαρμογών. Δηλαδή να
|
||||
μην βασίζονται αποκλειστικά σε έναν πάροχο νέφους για όλες τις λειτουργίες μιας
|
||||
εφαρμογής \footfullcite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς
|
||||
παρόχους με βάση τις ανάγκες τους.
|
||||
εφαρμογής \cite{multiCloud} αλλά να εκμεταλλεύονται οφέλη από πολλούς παρόχους
|
||||
με βάση τις ανάγκες τους.
|
||||
|
||||
\section{Ασφάλεια του συστήματος κατά τη χρήση του Docker} \label{dockerSecurity}
|
||||
|
||||
Μία από τις πιο σημαντικές προκλήσεις των επιχειρήσεων κατά την διάθεση
|
||||
υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά κατά την
|
||||
υπηρεσιών είναι η επίτευξη και διατήρηση της ασφάλειας. Παραδοσιακά, κατά την
|
||||
επιλογή χρήσης τεχνολογιών εικονικοποίησης, ανάμεσα στις επιλογές
|
||||
εικονικοποίησης υλικού και εικονικοποίησης ΛΣ είθισται να προτιμάται η δεύτερη.
|
||||
Μια λογική απόφαση εάν αναλογιστεί κανείς τα πλεονεκτήματα που προσφέρει τόσο
|
||||
@@ -474,49 +416,48 @@ ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
αυτά, η επιλογή αυτή είναι και λιγότερο ασφαλής στην περίπτωση που αφεθεί στις
|
||||
αρχικές ρυθμίσεις.
|
||||
|
||||
\clearpage
|
||||
|
||||
Για τον λόγο αυτό, εάν η μέγιστη δυνατή απόδοση δεν είναι μια από τις κύριες
|
||||
προτεραιότητες της επιχείρησης, προκειμένου να αυξηθεί η ασφάλεια του
|
||||
συστήματος διατηρώντας τα πλεονεκτήματα του Docker όσον αφορά την
|
||||
μεταφερσιμότητα και την απαλλαγή από τις εξαρτήσεις του εκάστοτε προγράμματος
|
||||
ακόμα και χωρίς την περαιτέρω διαμόρφωση των ρυθμίσεών του, η προτεινόμενη
|
||||
χρήση είναι η εκτέλεσή του μέσω μιας εικονικής μηχανής. Η στρώση απομόνωσης
|
||||
μέσω της εικονικοποίησης υλικού ανάμεσα στα προγράμματα και το μηχάνημα στο
|
||||
οποίο εκτελούνται αποτελεί ένα παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας
|
||||
επιτιθέμενος για να προκαλέσει ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα
|
||||
να περάσει από τον εικονικό πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, ο
|
||||
συνδυασμός με την αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο
|
||||
απομόνωσης εφόσον στην προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα
|
||||
του συστήματος αφορά το φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
|
||||
χρήση είναι η εκτέλεσή του μέσω μιας εικονικής μηχανής. Σε περιπτώσεις
|
||||
ιδιόκτητης υποδομής, η στρώση απομόνωσης μέσω της εικονικοποίησης υλικού
|
||||
ανάμεσα στα προγράμματα και το μηχάνημα στο οποίο εκτελούνται αποτελεί ένα
|
||||
παραπάνω εμπόδιο που θα πρέπει να ξεπεράσει ένας επιτιθέμενος για να προκαλέσει
|
||||
ζημιές στο κύριο σύστημα, αφού θα πρέπει πρώτα να περάσει από τον εικονικό
|
||||
πυρήνα και έπειτα από τον υπερ-επόπτη. Παράλληλα, ο συνδυασμός με την
|
||||
αρχιτεκτονική δοχείων παρέχει ένα επιπρόσθετο επίπεδο απομόνωσης εφόσον στην
|
||||
προκειμένη περίπτωση η άμεση επικοινωνία με τον πυρήνα του συστήματος αφορά το
|
||||
φιλοξενούμενο ΛΣ και όχι το κύριο σύστημα.
|
||||
|
||||
Παρ' όλα αυτά, υπάρχουν περιπτώσεις όπου η απόδοση του συστήματος δεν δύναται
|
||||
να θυσιαστεί για χάρη της ασφάλειας. Σε αυτές τις περιπτώσεις, επιβάλλεται η
|
||||
τροποποίηση των ρυθμίσεων και του τρόπου λειτουργίας του Docker ώστε να
|
||||
μπορέσει να επιτευχθεί μια ικανοποιητική ισορροπία μεταξύ της ασφάλειας και της
|
||||
απόδοσης του συστήματος. Με βάση μια έρευνα που πραγματοποιήθηκε από την IBM
|
||||
σχετικά με την ασφάλεια των δοχείων \footfullcite{containerSecurity}, βρέθηκε
|
||||
πως ένα ορθώς ασφαλισμένο δοχείο μπορεί να παρέχει το ίδιο επίπεδο ασφάλειας με
|
||||
μια εικονική μηχανή ή ακόμα και μεγαλύτερο. Συγκεκριμένα, στην έρευνα αυτή
|
||||
σχετικά με την ασφάλεια των δοχείων \cite{containerSecurity}, βρέθηκε πως ένα
|
||||
ορθώς ασφαλισμένο δοχείο μπορεί να παρέχει το ίδιο επίπεδο ασφάλειας με μια
|
||||
εικονική μηχανή ή ακόμα και μεγαλύτερο. Συγκεκριμένα, στην έρευνα αυτή
|
||||
αναφέρεται πως προκειμένου να ποσοτικοποιηθεί η ασφάλεια των δοχείων θα πρέπει
|
||||
να ληφθεί υπόψιν το ποσοστό των υποδομών που βρίσκεται υπό την ευθύνη του
|
||||
χρήστη και να θεωρηθεί δεδομένο πως οι πάροχοι νέφους θα ακολουθήσουν όλες τις
|
||||
ορθές πρακτικές ασφαλείας για να προστατεύσουν το κομμάτι των υποδομών που τους
|
||||
αντιστοιχεί. Σε αυτήν την περίπτωση, εάν ο χρήστης χρησιμοποιεί υπηρεσίες CaaS,
|
||||
τότε είναι υπεύθυνος για περίπου το ίδιο ποσοστό υποδομών με τον πάροχο και
|
||||
επωφελείται άμεσα από τις προσπάθειες ασφάλισης του παρόχου για το ποσοστό του.
|
||||
Επομένως, συμπεραίνεται πως από την οπτική γωνία του τελικού χρήστη είναι πιο
|
||||
ασφαλές να χρησιμοποιήσει τεχνολογίες εικονικοποίησης ΛΣ μέσω ενός παρόχου
|
||||
νέφους για την παροχή των υπηρεσιών του
|
||||
\footfullcite{containerSecurityExplained}.
|
||||
τότε είναι υπεύθυνος για την ασφάλιση πολύ μικρότερου ποσοστού επιφάνειας
|
||||
επίθεσης συγκριτικά με τον πάροχο και επωφελείται άμεσα από τις προσπάθειες
|
||||
ασφάλισης του παρόχου για το ποσοστό του. Επομένως, συμπεραίνεται πως από την
|
||||
οπτική γωνία του τελικού χρήστη είναι πιο ασφαλές να χρησιμοποιήσει τεχνολογίες
|
||||
εικονικοποίησης ΛΣ μέσω ενός παρόχου νέφους για την παροχή των υπηρεσιών του
|
||||
\cite{containerSecurityExplained}.
|
||||
|
||||
\subsection{Πλεονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityAdvatnages}
|
||||
|
||||
Με τη χρήση της αρχιτεκτονικής δοχείων και ειδικότερα του Docker, έρχονται
|
||||
αρκετά εγγενή οφέλη ασφαλείας \footfullcite{dockerInherentSecurity}. Ένα βασικό
|
||||
όφελος αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν την
|
||||
ακριβή κατανόηση του κώδικα που εκτελείται μέσα σε αυτά, σε αντίθεση με την
|
||||
περίπτωση χρήσης αποκλειστικά εικονικών μηχανών. Επιπρόσθετα, κατά την εμφάνιση
|
||||
αρκετά εγγενή οφέλη ασφαλείας \cite{dockerInherentSecurity}. Ένα βασικό όφελος
|
||||
αποτελεί η διαφάνεια. Λόγω της φύσης τους, τα δοχεία επιτρέπουν την ακριβή
|
||||
κατανόηση του κώδικα που εκτελείται μέσα σε αυτά, σε αντίθεση με την περίπτωση
|
||||
χρήσης αποκλειστικά εικονικών μηχανών. Επιπρόσθετα, κατά την εμφάνιση
|
||||
προβλημάτων σε μία υπηρεσία με αρχιτεκτονική μικρο-υπηρεσιών που κάνει χρήση
|
||||
δοχείων, είναι διακριτή η διευκόλυνση στον εντοπισμό της πηγής τους.
|
||||
|
||||
@@ -540,27 +481,26 @@ ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
θα μπορούσαν να επιφέρουν τυχόν ενημερώσεις των εξαρτήσεων της εφαρμογής χωρίς
|
||||
την ταυτόχρονη ενημέρωση της εφαρμογής της ίδιας.
|
||||
|
||||
\clearpage
|
||||
|
||||
\subsection{Μειονεκτήματα ασφαλείας με τη χρήση του Docker} \label{dockerSecurityDisadvantages}
|
||||
|
||||
Παρ' όλα τα προαναφερόμενα πλεονεκτήματα του Docker όπως η δυνατότητα απαλλαγής
|
||||
από εξαρτήσεις του εκάστοτε συστήματος και η ευελιξία διαχείρισης των δοχείων
|
||||
του, αυτό υπόκειται σε αρκετές ατασθαλίες σε σχέση με την ασφάλεια. Οι πιο
|
||||
Παρ' όλα τα προαναφερόμενα πλεονεκτήματα του Docker, όπως η δυνατότητα
|
||||
απαλλαγής από εξαρτήσεις του εκάστοτε συστήματος και η ευελιξία διαχείρισης των
|
||||
δοχείων του, αυτό εμφανίζει αρκετές τρωτότητες σε σχέση με την ασφάλεια. Οι πιο
|
||||
αξιοσημείωτες από αυτές είναι η ανάγκη εκτέλεσης του Docker με διαχειριστικά
|
||||
δικαιώματα και η αρχικά ελαστικότερη απ' ό,τι χρειάζεται απομόνωσή του από τον
|
||||
πυρήνα του συστήματος. Ο άμεσος αντίκτυπος των παραπάνω είναι πως τα δοχεία
|
||||
είναι πιο ευάλωτα από άλλες τεχνολογίες σε επιθέσεις τύπου άρνησης υπηρεσιών
|
||||
και σε επιθέσεις που εκμεταλλεύονται ευπάθειες του πυρήνα με σκοπό να ξεφύγουν
|
||||
από το δοχείο και να αποκτήσουν πρόσβαση στο κύριο σύστημα (Container Escape
|
||||
\footfullcite{containerEscapeTechniques}).
|
||||
από το δοχείο και να αποκτήσουν πρόσβαση στο κύριο σύστημα μέσω αυτού
|
||||
(Container Escape \cite{containerEscapeTechniques}).
|
||||
|
||||
Το γεγονός που αυξάνει τον κίνδυνο κατά την διάρκεια μιας επίθεσης τύπου
|
||||
άρνησης υπηρεσιών είναι πως σε αντίθεση με μια εικονική μηχανή όπου επιλέγεται
|
||||
άρνησης υπηρεσιών είναι πως σε αντίθεση με μια εικονική μηχανή, όπου επιλέγεται
|
||||
το εύρος πρόσβασης στους πόρους του συστήματος κατά τη δημιουργία της, η αρχική
|
||||
ρύθμιση του Docker επιτρέπει στα δοχεία να χρησιμοποιήσουν το ίδιο ποσοστό
|
||||
πόρων με το κύριο σύστημα, δηλαδή δεν υπάρχουν περιορισμοί. Επομένως, εάν ένα
|
||||
δοχείο βρεθεί υπό τον έλεγχο ενός επιτιθέμενου, αυτό μπορεί δυνητικά να
|
||||
πόρων με το κύριο σύστημα, δηλαδή δεν υπάρχουν περιορισμοί. Επομένως,
|
||||
ανεξαρτήτως του αν ένα δοχείο βρεθεί υπό τον έλεγχο ενός επιτιθέμενου ή αυτός
|
||||
απλά κατευθύνει πολλά αιτήματα προς αυτό εξωτερικά, αυτό μπορεί δυνητικά να
|
||||
εμποδίσει την εκτέλεση άλλων δοχείων ή ακόμα και την εκτέλεση άλλων εφαρμογών
|
||||
που εκτελούνται στο σύστημα.
|
||||
|
||||
@@ -570,12 +510,9 @@ ECS (Elastic Container Service) της Amazon. Μια υποκατηγορία
|
||||
απευθείας επικοινωνίας τους με τον πυρήνα του συστήματος, τα δοχεία είναι άμεσα
|
||||
ευεπηρέαστα από ευπάθειες του πυρήνα. Συνεπώς, ένας επιτιθέμενος που στοχεύει
|
||||
ένα δοχείο μπορεί να εκμεταλλευτεί μια ευπάθεια του πυρήνα προκειμένου να
|
||||
αποκτήσει πρόσβαση στο κύριο σύστημα και εφόσον η εκτέλεση του Docker γίνεται
|
||||
με διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape
|
||||
θα έχει διαχειριστικά δικαιώματα και ο ίδιος
|
||||
\footfullcite{containerEscapeRepercussions}.
|
||||
|
||||
\clearpage
|
||||
αποκτήσει πρόσβαση στο κύριο σύστημα - εφόσον η εκτέλεση του Docker γίνεται με
|
||||
διαχειριστικά δικαιώματα, μετά από μια επιτυχημένη επίθεση Container Escape θα
|
||||
έχει διαχειριστικά δικαιώματα και ο ίδιος \cite{containerEscapeRepercussions}.
|
||||
|
||||
\subsection{Ξεπερνώντας τα μειονεκτήματα ασφαλείας του Docker} \label{overcomingDockerDisadvantages}
|
||||
|
||||
@@ -585,54 +522,71 @@ AppArmor ή κανόνων SELinux προκειμένου να απομονωθ
|
||||
σύστημα. Στην πραγματικότητα, αυτές οι πρακτικές λαμβάνουν υπόψιν τους κυρίως
|
||||
τα δοχεία και όχι τη μηχανή δοχείων καθ' αυτού. Γι' αυτό τον λόγο, πολλές φορές
|
||||
πρέπει να ακολουθούνται και καλύτερες πρακτικές κατά τη λειτουργία/χρήση του
|
||||
Docker, όπως η αποφυγή χρήσης του διαχειριστικού λογαριασμού (σε διεργασίες)
|
||||
όσον αφορά τα δοχεία και η αποφυγή λήψης δοχείων από μη έμπιστες πηγές. Υπάρχει
|
||||
επομένως ανάγκη δημιουργίας ενός εργαλείου που αυτοματοποιημένα μπορεί να
|
||||
δημιουργεί ασφαλή εικονικοποιημένα περιβάλλοντα, καθώς και να εγκαθιστά σε
|
||||
αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας του Docker και των δοχείων
|
||||
του, μια σκληρυμένη έκδοση του Docker.
|
||||
Docker, όπως η σκλήρυνσή του, η αποφυγή χρήσης του διαχειριστικού λογαριασμού
|
||||
(σε διεργασίες) όσον αφορά τα δοχεία και η αποφυγή λήψης δοχείων από μη
|
||||
έμπιστες πηγές. Υπάρχει επομένως ανάγκη δημιουργίας ενός εργαλείου που
|
||||
αυτοματοποιημένα μπορεί να δημιουργεί ασφαλή εικονικοποιημένα περιβάλλοντα,
|
||||
καθώς και να εγκαθιστά σε αυτά, με βάση τις προαναφερόμενες οδηγίες προστασίας
|
||||
του Docker και των δοχείων του, μια σκληρυμένη έκδοση του Docker.
|
||||
|
||||
Με τη χρήση του εργαλείου SecDep που θα περιγράψουμε παρακάτω στο κεφάλαιο
|
||||
Με τη χρήση του εργαλείου SecDep που αναπτύχθηκε στα πλαίσια της παρούσας
|
||||
διπλωματικής εργασίας, το οποίο θα περιγράψουμε παρακάτω στο Κεφάλαιο
|
||||
\ref{installationANDShowcase}, θα επιτευχθεί η ασφάλιση του Docker και του
|
||||
συστήματος με αυτοματοποιημένο τρόπο ακολουθώντας ορθές πρακτικές,
|
||||
χρησιμοποιώντας ένα ασφαλέστερο από το αρχικό Container Runtime και εκτελώντας
|
||||
το Docker εξ ολοκλήρου χωρίς την ανάγκη διαχειριστικών δικαιωμάτων. Το εργαλείο
|
||||
αυτό επικοινωνεί με πολλούς παρόχους νέφους στέλνοντας τους παραμέτρους για τις
|
||||
προδιαγραφές εικονικών μηχανών προκειμένου να μπορέσουν να δημιουργηθούν
|
||||
αυτόματα, επιτρέποντας έτσι την δημιουργία πολλαπλών ασφαλών περιβαλλόντων ώστε
|
||||
να μπορεί ένας χρήστης να εγκαθιστά εκεί τα δοχεία της εφαρμογής του. Η
|
||||
αυτό εστιάζει στην χρήση εικονικοποιημένων περιβαλλόντων, μιας και παρέχουν
|
||||
περισσότερα επίπεδα προς διείσδυση για έναν επιτιθέμενο, εμποδίζοντάς τον στην
|
||||
επίτευξη του στόχου αυτού. Επικοινωνεί με πολλούς παρόχους νέφους στέλνοντάς
|
||||
τους παραμέτρους για τις προδιαγραφές εικονικών μηχανών προκειμένου να
|
||||
μπορέσουν να δημιουργηθούν αυτόματα. Με αυτόν τον τρόπο, επιτρέπει την
|
||||
δημιουργία πολλαπλών ασφαλών περιβαλλόντων ώστε να μπορεί ένας χρήστης να
|
||||
εγκαθιστά εκεί τα δοχεία της εφαρμογής του. Με την εφαρμογή των κατάλληλων
|
||||
μέτρων και πρακτικών ασφαλείας σε κάθε επίπεδο, τα περιβάλλοντα αυτά
|
||||
σκληρύνονται, μικραίνοντας με αυτό τον τρόπο την πιθανότητα διείσδυσης. Η
|
||||
σκλήρυνση του ΛΣ επιτυγχάνεται με την εκτέλεση πολλών βημάτων στα οποία μεταξύ
|
||||
άλλων περιλαμβάνεται η σκλήρυνση του SSH, ο εντοπισμός, η εγκατάσταση, η
|
||||
ρύθμιση και η ενεργοποίηση του κατάλληλου προγράμματος για ανάχωμα ασφαλείας
|
||||
και για παροχή MAC (Mandatory Access Control) και η δημιουργία και ενεργοποίηση
|
||||
περιοδικά εκτελέσιμων προγραμμάτων για την ενημέρωση του συστήματος και το
|
||||
άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η απεξάρτηση από τον διαχειριστικό
|
||||
λογαριασμό επιτυγχάνεται χάρη στη δουλειά του Akihiro Suda πάνω στο rootlesskit
|
||||
\footfullcite{AkihiroSuda}, επιτρέποντας έτσι την χρήση ενός πλαστού
|
||||
διαχειριστικού λογαριασμού προκειμένου να μπορέσει η μηχανή δοχείων να
|
||||
εκτελεστεί υπό την κυριότητα οποιουδήποτε χρήστη του συστήματος. Τέλος, η
|
||||
αντικατάσταση του αρχικού Container Runtime με το αντίστοιχο του gVisor
|
||||
\footfullcite{gVisor}, εισάγει ένα πιο συμπαγές τείχος προστασίας απέναντι σε
|
||||
συνηθισμένες επιθέσεις κατά των δοχείων, καθιστώντας το σύστημα μας πιο ασφαλές
|
||||
συγκριτικά με τις αρχικές/προκαθορισμένες ρυθμίσεις.
|
||||
ρύθμιση και η ενεργοποίηση των κατάλληλων για την εκάστοτε διανομή,
|
||||
προγραμμάτων για ανάχωμα ασφαλείας και για παροχή MAC (Mandatory Access
|
||||
Control) και η δημιουργία και ενεργοποίηση περιοδικά εκτελέσιμων προγραμμάτων
|
||||
για την ενημέρωση του συστήματος και το άνοιγμα/κλείσιμο θυρών προγραμμάτων. Η
|
||||
απεξάρτηση από τον διαχειριστικό λογαριασμό επιτυγχάνεται χάρη στη δουλειά του
|
||||
Akihiro Suda πάνω στο rootlesskit \footfullcite{AkihiroSuda}, επιτρέποντας έτσι
|
||||
την χρήση ενός πλαστού διαχειριστικού λογαριασμού προκειμένου να μπορέσει η
|
||||
μηχανή δοχείων να εκτελεστεί υπό την κυριότητα οποιουδήποτε χρήστη του
|
||||
συστήματος. Τέλος, η αντικατάσταση του αρχικού Container Runtime με το
|
||||
αντίστοιχο του gVisor \footfullcite{gVisor}, εισάγει ένα πιο συμπαγές τείχος
|
||||
προστασίας απέναντι σε συνηθισμένες επιθέσεις κατά των δοχείων, καθιστώντας το
|
||||
σύστημα μας πιο ασφαλές συγκριτικά με τις αρχικές/προκαθορισμένες ρυθμίσεις.
|
||||
|
||||
Η χρήση του εργαλείου έρχεται με πολλά πλεονεκτήματα για τον χρήστη. Κατ'
|
||||
αρχήν, το εργαλείο είναι εύκολο στη χρήση και στην εγκατάσταση, καθώς παρέχει
|
||||
πλούσια τεκμηρίωση και οδηγίες εγκατάστασης στο αποθετήριό του. Απαιτούνται
|
||||
ελάχιστες γνώσεις στον τομέα των τεχνολογιών νέφους από τον χρήστη. Επιπλέον,
|
||||
είναι ευέλικτο και επεκτάσιμο διότι αποτελείται από δύο εκτελέσιμα προγράμματα
|
||||
τα οποία μπορεί κάθε χρήστης να τροποποιήσει και να προσθέσει τις δικές του
|
||||
λειτουργίες. Τέλος, οι παράμετροι του είναι εύκολα κατανοητές και προσαρμόσιμες
|
||||
στις ανάγκες του χρήστη. Επομένως, το εργαλείο αυτό αποτελεί ένα κατάλληλο μέσο
|
||||
για την δημιουργία, διαχείριση και ασφάλιση περιβαλλόντων εφαρμογών που
|
||||
εκτελούνται σε δοχεία.
|
||||
|
||||
\clearpage
|
||||
|
||||
\section{Δομή Εργασίας} \label{structure}
|
||||
|
||||
Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο κεφάλαιο \ref{background} θα
|
||||
μελετήσουμε τον όρο νεφο-υπολογιστική, θα αναλύσουμε τις διάφορες τεχνολογίες
|
||||
εικονικοποίησης και θα εμβαθύνουμε στην τεχνολογία των δοχείων με επίκεντρο την
|
||||
ασφάλεια του Docker. Στο επόμενο κεφάλαιο (δηλαδή το \ref{relevantWork}), θα
|
||||
δούμε εργασίες σχετικές με την παρούσα και θα πραγματοποιηθεί ανάλυση και
|
||||
σύγκριση αυτών με την προτεινόμενη εργασία της διπλωματικής. Αμέσως μετά, στο
|
||||
κεφάλαιο \ref{projectDevelopment}, αναφερόμαστε στην ανάπτυξη του προτεινόμενου
|
||||
εργαλείου και τα παράγωγά της (απαιτήσεις, σχεδιαστικά μοντέλα, κώδικα
|
||||
υλοποίησης κα.). Προχωρώντας στο κεφάλαιο \ref{installationANDShowcase}, θα
|
||||
αναφερθούμε στις οδηγίες εγκατάστασης και λειτουργίας του εργαλείου με βάση
|
||||
στοχευμένα σενάρια χρήσης. Έπειτα, στο κεφάλαιο \ref{experimentationANDresults}
|
||||
αποτιμάται η αποδοτικότητα του εργαλείου κατά την πραγματική χρήση του
|
||||
προκειμένου να εξετασθεί με πρακτικό τρόπο η ικανότητα εξασφάλισης των στόχων
|
||||
του. Τέλος, στο κεφάλαιο \ref{conclusions}, αναφέρονται δυνητικές επεκτάσεις
|
||||
και βελτιώσεις του προτεινόμενου εργαλείου προκειμένου αυτό να μπορέσει να
|
||||
πάρει μια θέση στην αγορά.
|
||||
Η υπόλοιπη δομή της αναφοράς είναι η εξής. Στο Κεφάλαιο \ref{background}, θα
|
||||
αναλύσουμε τις διάφορες τεχνολογίες εικονικοποίησης και θα εμβαθύνουμε στην
|
||||
τεχνολογία των δοχείων με επίκεντρο την ασφάλεια του Docker. Στο επόμενο
|
||||
κεφάλαιο (δηλαδή το \ref{relevantWork}), θα δούμε εργασίες σχετικές με την
|
||||
παρούσα και θα πραγματοποιηθεί ανάλυση και σύγκριση αυτών με την προτεινόμενη
|
||||
εργασία της διπλωματικής. Αμέσως μετά, στο Κεφάλαιο \ref{projectDevelopment},
|
||||
αναφερόμαστε στην διαδικασία ανάπτυξης του προτεινόμενου εργαλείου και τα
|
||||
παράγωγά της (απαιτήσεις, σχεδιαστικά μοντέλα, κώδικας υλοποίησης κα.).
|
||||
Προχωρώντας στο Κεφάλαιο \ref{installationANDShowcase}, θα αναφερθούμε στις
|
||||
οδηγίες εγκατάστασης και λειτουργίας του εργαλείου με βάση στοχευμένα σενάρια
|
||||
χρήσης. Έπειτα, στο Κεφάλαιο \ref{experimentationANDresults} αποτιμάται η
|
||||
αποδοτικότητα του εργαλείου κατά την πραγματική χρήση του προκειμένου να
|
||||
εξετασθεί με πρακτικό τρόπο η ικανότητα εξασφάλισης των στόχων του. Τέλος, στο
|
||||
Κεφάλαιο \ref{conclusions}, αναφέρονται δυνητικές επεκτάσεις και βελτιώσεις του
|
||||
προτεινόμενου εργαλείου προκειμένου αυτό να μπορέσει να πάρει μια θέση στην
|
||||
αγορά.
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -41,11 +41,11 @@
|
||||
|
||||
\item \textbf{Ευκολία κατά την χρήση}:
|
||||
|
||||
Το εργαλείο πρέπει να μπορεί να χρησιμοποιηθεί εύκολα από έναν χρήστη
|
||||
που έχει χρησιμοποιήσει στο παρελθόν εργαλεία γραμμής εντολών. Οι
|
||||
παράμετροί του πρέπει να ακολουθούν ένα μοτίβο που θα διευκολύνει την
|
||||
κατανόηση της λειτουργίας τους και τον συνδυασμό τους για ένα επιθυμητό
|
||||
αποτέλεσμα.
|
||||
Το εργαλείο πρέπει να μπορεί να χρησιμοποιηθεί εύκολα από έναν χρήστη
|
||||
που έχει χρησιμοποιήσει στο παρελθόν εργαλεία γραμμής εντολών. Οι
|
||||
παράμετροί του πρέπει να ακολουθούν ένα μοτίβο που θα διευκολύνει την
|
||||
κατανόηση της λειτουργίας τους και τον συνδυασμό τους για ένα επιθυμητό
|
||||
αποτέλεσμα.
|
||||
|
||||
\item \textbf{Υποστήριξη μεγάλων ονομάτων στον κλάδο}:
|
||||
|
||||
@@ -55,8 +55,8 @@
|
||||
|
||||
\item \textbf{Ευκολία στην επέκταση}:
|
||||
|
||||
Το εργαλείο πρέπει να είναι εύκολο στην επέκτασή του, ώστε να μπορεί να
|
||||
αυτοματοποιηθεί περισσότερο η διαδικασία δημιουργίας εικονικών μηχανών.
|
||||
Το εργαλείο πρέπει να είναι εύκολο στην επέκτασή του, ώστε να μπορεί να
|
||||
αυτοματοποιηθεί περισσότερο η διαδικασία δημιουργίας εικονικών μηχανών.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -107,21 +107,21 @@
|
||||
|
||||
\item \textbf{Σύγκριση με Terraform}:
|
||||
|
||||
Χρειάζεται την δημιουργία ενός αρχείου πριν την χρήση του και κάθε
|
||||
αλλαγή απαιτεί την τροποποίηση του αρχείου αυτού. Αυτό το καθιστά
|
||||
λιγότερο ευέλικτο σε σχέση με άλλα εργαλεία. Είναι σχετικά εύκολο στην
|
||||
χρήση όπως τα υπόλοιπα και δύναται να χρησιμοποιήσει τα νέφη όλων των
|
||||
μεγάλων παρόχων. Παρ' όλα αυτά δεν αποτελεί εργαλείο που μπορεί να
|
||||
επεκταθεί εύκολα καθώς ο τρόπος λειτουργίας του το καθιστά αυτοτελές.
|
||||
Χρειάζεται την δημιουργία ενός αρχείου πριν την χρήση του και κάθε
|
||||
αλλαγή απαιτεί την τροποποίηση του αρχείου αυτού. Αυτό το καθιστά
|
||||
λιγότερο ευέλικτο σε σχέση με άλλα εργαλεία. Είναι σχετικά εύκολο στην
|
||||
χρήση όπως τα υπόλοιπα και δύναται να χρησιμοποιήσει τα νέφη όλων των
|
||||
μεγάλων παρόχων. Παρ' όλα αυτά δεν αποτελεί εργαλείο που μπορεί να
|
||||
επεκταθεί εύκολα καθώς ο τρόπος λειτουργίας του το καθιστά αυτοτελές.
|
||||
|
||||
\item \textbf{Σύγκριση με Libcloud CLI}:
|
||||
|
||||
Το δεύτερο πιο πρόσφατο εργαλείο που κάνει χρήση της βιβλιοθήκης
|
||||
libcloud μετά από αυτό που προτείνει η διπλωματική εργασία. Είναι
|
||||
αρκετά ευέλικτο και εύκολο στην χρήση, παρ' όλα αυτά πλέον υποστηρίζει
|
||||
μονάχα έναν πάροχο νέφους, ο οποίος δεν αποτελεί δημοφιλή επιλογή
|
||||
γενικότερα. Θα μπορούσε να επεκταθεί η λειτουργικότητά του αλλά έχει να
|
||||
ανανεωθεί από το 2018.
|
||||
Το δεύτερο πιο πρόσφατο εργαλείο που κάνει χρήση της βιβλιοθήκης
|
||||
libcloud μετά από αυτό που προτείνει η διπλωματική εργασία. Είναι
|
||||
αρκετά ευέλικτο και εύκολο στην χρήση, παρ' όλα αυτά πλέον υποστηρίζει
|
||||
μονάχα έναν πάροχο νέφους, ο οποίος δεν αποτελεί δημοφιλή επιλογή
|
||||
γενικότερα. Θα μπορούσε να επεκταθεί η λειτουργικότητά του αλλά έχει να
|
||||
ανανεωθεί από το 2018.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -172,20 +172,20 @@
|
||||
|
||||
\item \textbf{JShielder} \footfullcite{jshielder}:
|
||||
|
||||
Το JShielder είναι ένα εργαλείο ανοιχτού κώδικα που αναπτύχθηκε από τον
|
||||
Jason Soto με σκοπό την αυτοματοποίηση σκλήρυνσης λειτουργικών
|
||||
συστημάτων Linux. Ο πηγαίος κώδικάς του βρίσκεται στο GitHub και ο
|
||||
τρόπος λειτουργίας του είναι η εκτέλεσή του ως χρήστης με διαχειριστικά
|
||||
δικαιώματα στο σύστημα.
|
||||
Το JShielder είναι ένα εργαλείο ανοιχτού κώδικα που αναπτύχθηκε από τον
|
||||
Jason Soto με σκοπό την αυτοματοποίηση σκλήρυνσης λειτουργικών
|
||||
συστημάτων Linux. Ο πηγαίος κώδικάς του βρίσκεται στο GitHub και ο
|
||||
τρόπος λειτουργίας του είναι η εκτέλεσή του ως χρήστης με διαχειριστικά
|
||||
δικαιώματα στο σύστημα.
|
||||
|
||||
\clearpage
|
||||
|
||||
\item \textbf{nixarmor} \footfullcite{nixarmor}:
|
||||
|
||||
Ένα εργαλείο ανοιχτού κώδικα που στεγάζεται στο GitHub και αναπτύχθηκε
|
||||
από τον Emir Ozer. Περιέχει διαφορετικά εκτελέσιμα αρχεία για την
|
||||
σκλήρυνση διάφορων διανομών Linux, τα οποία μπορούν να εκτελεστούν ως
|
||||
αυτόνομα προγράμματα από τον χρήστη.
|
||||
Ένα εργαλείο ανοιχτού κώδικα που στεγάζεται στο GitHub και αναπτύχθηκε
|
||||
από τον Emir Ozer. Περιέχει διαφορετικά εκτελέσιμα αρχεία για την
|
||||
σκλήρυνση διάφορων διανομών Linux, τα οποία μπορούν να εκτελεστούν ως
|
||||
αυτόνομα προγράμματα από τον χρήστη.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -198,26 +198,26 @@
|
||||
|
||||
\item \textbf{Σύγκριση με JShielder}:
|
||||
|
||||
Το JShielder παρέχει ένα ικανοποιητικό εύρος σκλήρυνσης του συστήματος
|
||||
και η ευκολία στην χρήση του το καθιστά ένα εργαλείο που μπορεί να
|
||||
χρησιμοποιηθεί από έναν χρήστη με μικρή εμπειρία στον κλάδο. Παρ' όλα
|
||||
αυτά, δεν υποστηρίζει πολλές διανομές και οι εκδόσεις των διανομών που
|
||||
υποστηρίζονται μέσω αυτού είναι αρκετό καιρό ξεπερασμένες. Θα μπορούσε
|
||||
να βελτιωθεί με μια ανανέωση του πηγαίου του κώδικα αλλά η ανάπτυξή του
|
||||
φαίνεται να έχει σταματήσει το 2019.
|
||||
Το JShielder παρέχει ένα ικανοποιητικό εύρος σκλήρυνσης του συστήματος
|
||||
και η ευκολία στην χρήση του το καθιστά ένα εργαλείο που μπορεί να
|
||||
χρησιμοποιηθεί από έναν χρήστη με μικρή εμπειρία στον κλάδο. Παρ' όλα
|
||||
αυτά, δεν υποστηρίζει πολλές διανομές και οι εκδόσεις των διανομών που
|
||||
υποστηρίζονται μέσω αυτού είναι αρκετό καιρό ξεπερασμένες. Θα μπορούσε
|
||||
να βελτιωθεί με μια ανανέωση του πηγαίου του κώδικα αλλά η ανάπτυξή του
|
||||
φαίνεται να έχει σταματήσει το 2019.
|
||||
|
||||
\item \textbf{Σύγκριση με το nixarmor}:
|
||||
|
||||
Σε αντίθεση με το JShielder, το nixarmor για να χρησιμοποιηθεί με τον
|
||||
ίδιο τρόπο που χρησιμοποιούνται τα υπόλοιπα εργαλεία θα πρέπει να
|
||||
επεκταθεί με την προσθήκη κώδικα που να του επιτρέπει να ξεχωρίζει ποιο
|
||||
είναι το κατάλληλο εκτελέσιμο για την κάθε διανομή. Στην αντίθετη
|
||||
περίπτωση, πάλι η χρήση του είναι εύκολη διότι ο χρήστης μπορεί να
|
||||
επιλέξει και να εκτελέσει χειροκίνητα ένα από τα εκτελέσιμα αρχεία που
|
||||
περιέχει. Η σκλήρυνση που παρέχει καλύπτει πολλούς τομείς μιας διανομής
|
||||
και μπορεί εύκολα να προστεθούν επιπλέον συναρτήσεις στον κώδικά του.
|
||||
Παρ' όλα αυτά, η ανάπτυξή του έχει παύσει από το 2015 και οι
|
||||
υποστηριζόμενες διανομές του έχουν περιοριστεί σε μονάχα 4.
|
||||
Σε αντίθεση με το JShielder, το nixarmor για να χρησιμοποιηθεί με τον
|
||||
ίδιο τρόπο που χρησιμοποιούνται τα υπόλοιπα εργαλεία θα πρέπει να
|
||||
επεκταθεί με την προσθήκη κώδικα που να του επιτρέπει να ξεχωρίζει ποιο
|
||||
είναι το κατάλληλο εκτελέσιμο για την κάθε διανομή. Στην αντίθετη
|
||||
περίπτωση, πάλι η χρήση του είναι εύκολη διότι ο χρήστης μπορεί να
|
||||
επιλέξει και να εκτελέσει χειροκίνητα ένα από τα εκτελέσιμα αρχεία που
|
||||
περιέχει. Η σκλήρυνση που παρέχει καλύπτει πολλούς τομείς μιας διανομής
|
||||
και μπορεί εύκολα να προστεθούν επιπλέον συναρτήσεις στον κώδικά του.
|
||||
Παρ' όλα αυτά, η ανάπτυξή του έχει παύσει από το 2015 και οι
|
||||
υποστηριζόμενες διανομές του έχουν περιοριστεί σε μονάχα 4.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -226,7 +226,7 @@
|
||||
Συγκριτικά με τα παραπάνω εργαλεία, το harden υποστηρίζει την ικανότητα
|
||||
αναγνώρισης της διανομής στην οποία εκτελείται και μπορεί δυναμικά να αλλοιώσει
|
||||
την συμπεριφορά του αναλόγως. Οι υποστηριζόμενες διανομές είναι 6 και οι
|
||||
λειτουργίες του αν και σύμφωνα με τα αποτελέσματα του κεφαλαίου
|
||||
λειτουργίες του αν και σύμφωνα με τα αποτελέσματα του Κεφαλαίου
|
||||
\ref{experimentationANDresults} είναι ικανοποιητικές, θα μπορούσαν εύκολα να
|
||||
επεκταθούν με την προσθήκη νέων συναρτήσεων. Επιπλέον, αυτό το ένα εκτελέσιμο,
|
||||
παράγει κατά την εκτέλεσή του δύο ακόμα, τα οποία θα εκτελούνται περιοδικά με
|
||||
|
||||
@@ -9,7 +9,7 @@
|
||||
\section{Αποφάσεις που πάρθηκαν κατά την ανάπτυξη} \label{developmentDecisions}
|
||||
|
||||
Κατά την ανάπτυξη του συστήματος, προκειμένου να επιτευχθούν οι στόχοι που
|
||||
θέσαμε στην ενότητα \ref{overcomingDockerDisadvantages} και συγκεκριμένα για
|
||||
θέσαμε στην Ενότητα \ref{overcomingDockerDisadvantages} και συγκεκριμένα για
|
||||
την επικοινωνία με διάφορους παρόχους νέφους, επιλέχθηκε να γίνει χρήση της
|
||||
βιβλιοθήκης libcloud \footfullcite{libcloud}. Μια από τις δύο επιλογές
|
||||
βιβλιοθηκών της Apache \footfullcite{apache} για την επικοινωνία με παρόχους
|
||||
@@ -37,14 +37,14 @@ libcloud αποτελεί μια προσπάθεια δημιουργίας ε
|
||||
παρούσα διπλωματική εργασία, χρειάζεται να γίνει χρήση των λειτουργιών
|
||||
\textquote{Compute} της βιβλιοθήκης. Στην αρχική σελίδα της, αναφέρεται
|
||||
υποστήριξη για πάνω από 50 παρόχους. Κατά την σελίδα τεκμηρίωσης
|
||||
\footfullcite{libcloudProviders} για τις λειτουργίες \textquote{Compute},
|
||||
αναφέρονται 48 πάροχοι σε έναν πίνακα ο οποίος αναγράφει την υποστήριξη ή
|
||||
απουσία αυτής, διάφορων συναρτήσεων εικονικών μηχανών. Στις συναρτήσεις αυτές
|
||||
περιλαμβάνονται η δημιουργία εικονικών μηχανών, η εκκίνηση, η παύση, η διαγραφή
|
||||
τους και εν γένει όσες λειτουργίες είναι απαραίτητες για την ολοκληρωμένη
|
||||
λειτουργία του εργαλείου. Από αυτούς τους 48 παρόχους, οι 25 υποστηρίζουν και
|
||||
τις 9 συναρτήσεις. Ωστόσο, από αυτούς τους 25 έπρεπε να αφαιρεθούν οι 20 για
|
||||
λόγους όπως η μη ύπαρξη τεκμηρίωσης χρήσης από την libcloud, η μη συνέχιση της
|
||||
\cite{libcloudProviders} για τις λειτουργίες \textquote{Compute}, αναφέρονται
|
||||
48 πάροχοι σε έναν πίνακα ο οποίος αναγράφει την υποστήριξη ή απουσία αυτής,
|
||||
διάφορων συναρτήσεων εικονικών μηχανών. Στις συναρτήσεις αυτές περιλαμβάνονται
|
||||
η δημιουργία εικονικών μηχανών, η εκκίνηση, η παύση, η διαγραφή τους και εν
|
||||
γένει όσες λειτουργίες είναι απαραίτητες για την ολοκληρωμένη λειτουργία του
|
||||
εργαλείου. Από αυτούς τους 48 παρόχους, οι 25 υποστηρίζουν και τις 9
|
||||
συναρτήσεις. Ωστόσο, από αυτούς τους 25 έπρεπε να αφαιρεθούν οι 20 για λόγους
|
||||
όπως η μη ύπαρξη τεκμηρίωσης χρήσης από την libcloud, η μη συνέχιση της
|
||||
λειτουργίας τους, η έλλειψη πληροφοριών τιμής ή δοκιμαστικής περιόδου για τις
|
||||
υπηρεσίες τους και η αδυναμία δημιουργίας λογαριασμού στην επίσημη σελίδα τους.
|
||||
Επομένως, υπάρχουν εν τέλει 5 πάροχοι νέφους που δύναται να χρησιμοποιηθούν
|
||||
@@ -90,7 +90,7 @@ Python, πάρθηκε επίσης η απόφαση για την υποστή
|
||||
\multicolumn{1}{|c|}{} & CentOS \footfullcite{centos} & 7, 8, 9 & 8.4, 8.5 & Όλες \\ \cline{2-5}
|
||||
\multicolumn{1}{|c|}{} & Fedora \footfullcite{fedora} & 37 & 36, 37 & Όλες \\ \cline{2-5}
|
||||
\multicolumn{1}{|c|}{} & Red Hat Enterprise Linux \footfullcite{redhat} & 7.9, 8.6, 9 & 8.6, 9.1 & Όλες \\ \cline{2-5}
|
||||
\multicolumn{1}{|c|}{} & openSUSE Leap \footfullcite{opensuse} & 15.3, 15.4 & 15.3 15.4 & Όλες \\ \hline
|
||||
\multicolumn{1}{|c|}{} & openSUSE Leap \footfullcite{opensuse} & 15.3, 15.4 & 15.3, 15.4 & Όλες \\ \hline
|
||||
\end{tabular}}
|
||||
\label{table:supportedDistributions}
|
||||
\renewcommand{\arraystretch}{1}
|
||||
@@ -197,8 +197,8 @@ Python, πάρθηκε επίσης η απόφαση για την υποστή
|
||||
την λειτουργία σύνδεσης μέσω SSH}
|
||||
|
||||
\item \textbf{Το εργαλείο πρέπει να υποστηρίζει την αρχικοποίηση μονάχα
|
||||
ενός παρόχου δίχως την συμπλήρωση κενών πεδίων για τους υπόλοιπους από
|
||||
τον χρήστη}
|
||||
ενός παρόχου δίχως την συμπλήρωση κενών πεδίων για τους υπόλοιπους
|
||||
από τον χρήστη}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -210,33 +210,32 @@ Python, πάρθηκε επίσης η απόφαση για την υποστή
|
||||
που έχει χρησιμοποιήσει προγράμματα γραμμής εντολών στο παρελθόν}
|
||||
|
||||
\item \textbf{Το εργαλείο πρέπει να δημιουργεί ξεχωριστό αρχείο για τις
|
||||
ρυθμίσεις του στον ίδιο φάκελο που βρίσκεται και το εκτελέσιμο αρχείο του}
|
||||
ρυθμίσεις του στον ίδιο φάκελο που βρίσκεται και το εκτελέσιμο αρχείο
|
||||
του}
|
||||
|
||||
\item \textbf{Το εργαλείο πρέπει να κρατάει αρχείο των διευθύνσεων
|
||||
IP των εικονικών μηχανών που δημιουργεί ώστε να μπορούν να
|
||||
διαμορφωθούν περαιτέρω εάν ο χρήστης επιθυμεί να
|
||||
χρησιμοποιήσει άλλα προγράμματα όπως το Ansible}
|
||||
\item \textbf{Το εργαλείο πρέπει να κρατάει αρχείο των διευθύνσεων IP των
|
||||
εικονικών μηχανών που δημιουργεί ώστε να μπορούν να διαμορφωθούν
|
||||
περαιτέρω εάν ο χρήστης επιθυμεί να χρησιμοποιήσει άλλα προγράμματα
|
||||
όπως το Ansible}
|
||||
|
||||
\item \textbf{Το εργαλείο πρέπει να διαθέτει ένα μοτίβο εντολών που να
|
||||
μπορεί ο χρήστης να καταλαβαίνει και να διαμορφώνει ανάλογα με τις
|
||||
ανάγκες του}
|
||||
ανάγκες του}
|
||||
|
||||
\item \textbf{Το εργαλείο πρέπει να δημιουργεί κλειδιά SSH σε
|
||||
περίπτωση που δεν υπάρχουν, στον ίδιο φάκελο με το εκτελέσιμο
|
||||
αρχείο του}
|
||||
\item \textbf{Το εργαλείο πρέπει να δημιουργεί κλειδιά SSH σε περίπτωση που
|
||||
δεν υπάρχουν, στον ίδιο φάκελο με το εκτελέσιμο αρχείο του}
|
||||
|
||||
\item \textbf{Το δεύτερο εκτελέσιμο αρχείο του εργαλείου πρέπει να
|
||||
εγκαθιστά και να σκληραίνει και το Docker πέρα από το
|
||||
λειτουργικό σύστημα}
|
||||
εγκαθιστά και να σκληραίνει και το Docker πέρα από το λειτουργικό
|
||||
σύστημα}
|
||||
|
||||
\item \textbf{Το δεύτερο εκτελέσιμο αρχείο του εργαλείου πρέπει να
|
||||
δημιουργεί στην εικονική μηχανή δύο επιπλέον εκτελέσιμα
|
||||
αρχεία για περιοδική ενημέρωση των πακέτων και κλείσιμο
|
||||
αχρησιμοποίητων θυρών}
|
||||
δημιουργεί στην εικονική μηχανή δύο επιπλέον εκτελέσιμα αρχεία για
|
||||
περιοδική ενημέρωση των πακέτων και κλείσιμο αχρησιμοποίητων θυρών}
|
||||
|
||||
\item \textbf{Το δεύτερο εκτελέσιμο αρχείο του εργαλείου πρέπει να
|
||||
εγκαθιστά προγράμματα για την περαιτέρω σκλήρυνση του Docker και την
|
||||
διευκόλυνση του χρήστη κατά την εγκατάσταση δοχείων}
|
||||
διευκόλυνση του χρήστη κατά την εγκατάσταση δοχείων}
|
||||
|
||||
\end{itemize}
|
||||
|
||||
@@ -248,11 +247,11 @@ Python, πάρθηκε επίσης η απόφαση για την υποστή
|
||||
\section{Διαγραμματική Μοντελοποίηση} \label{designModels}
|
||||
|
||||
Οι παραπάνω απαιτήσεις και ο τρόπος λειτουργίας του εργαλείου, μεταφράζονται
|
||||
καλύτερα στον χρήστη μέσω ενός σχεδιαγράμματος περίπτωσης χρήσης. Το σχήμα
|
||||
καλύτερα στον χρήστη μέσω ενός σχεδιαγράμματος περίπτωσης χρήσης. Το Σχήμα
|
||||
\ref{fig:useCaseDiagram} δημιουργήθηκε με την βοήθεια του εργαλείου
|
||||
\textquote{yuml} \footfullcite{yuml}. Επιπλέον, με το εργαλείο
|
||||
\textquote{mermaid} \footfullcite{mermaid}, δημιουργήθηκε ένα διάγραμμα ροής
|
||||
για το SecDep που απεικονίζεται στο σχήμα \ref{fig:flowchartDiagram}. Το
|
||||
για το SecDep που απεικονίζεται στο Σχήμα \ref{fig:flowchartDiagram}. Το
|
||||
διάγραμμα ροής, απεικονίζει την ροή των εντολών που μπορεί να επιλεγούν από τον
|
||||
χρήστη κατά την εκτέλεση του προγράμματος.
|
||||
|
||||
@@ -290,7 +289,7 @@ Python, πάρθηκε επίσης η απόφαση για την υποστή
|
||||
να ζητήσει πληροφορίες για διαθέσιμους πόρους όπως οι εικονικές του μηχανές ή
|
||||
τα συστατικά που έχει στην διάθεσή του για την δημιουργία τους όπως οι
|
||||
διανομές, τα μεγέθη και οι τοποθεσίες τους. Αυτή η αλληλεπίδραση μεταξύ του
|
||||
χρήστη και του παρόχου νέφους, απεικονίζεται στο σχήμα
|
||||
χρήστη και του παρόχου νέφους, απεικονίζεται στο Σχήμα
|
||||
\ref{fig:sequenceDiagram}, το οποίο δημιουργήθηκε με το εργαλείο
|
||||
\textquote{mermaid}.
|
||||
|
||||
@@ -311,7 +310,7 @@ Mε το \textquote{code2flow} \footfullcite{code2flow} δημιουργήθηκ
|
||||
διάγραμμα που απεικονίζει τις κλήσεις συναρτήσεων που γίνονται κατά την
|
||||
εκτέλεση του αρχείου secdep.py. Παράλληλα, το ίδιο αποτέλεσμα επιτεύχθηκε για
|
||||
το αρχείο harden με την βοήθεια του \textquote{callGraph}
|
||||
\footfullcite{callGraph}. Τα παραπάνω απεικονίζονται στα σχήματα
|
||||
\footfullcite{callGraph}. Τα παραπάνω απεικονίζονται στα Σχήματα
|
||||
\ref{fig:secdepFunctionCallDiagram} και \ref{fig:hardenFunctionCallDiagram}
|
||||
αντίστοιχα.
|
||||
|
||||
@@ -372,7 +371,7 @@ pydeps -T png --cluster --include-missing --max-bacon=1 --noshow --reverse --ran
|
||||
\section{Αρχιτεκτονική Εργαλείου} \label{architecture}
|
||||
|
||||
Οι διαθέσιμες συναρτήσεις και μεταβλητές του secdep.py, απεικονίζονται στα
|
||||
σχήματα \ref{fig:secdepFunctions} και \ref{fig:secdepVariables} αντίστοιχα. Η
|
||||
Σχήματα \ref{fig:secdepFunctions} και \ref{fig:secdepVariables} αντίστοιχα. Η
|
||||
δημιουργία τους πραγματοποιήθηκε με το εργαλείο \textquote{doxygen}
|
||||
\footfullcite{doxygen}.
|
||||
|
||||
@@ -425,8 +424,8 @@ Docker. Το harden, εκτελείται μόνο στις εικονικές
|
||||
\item \textbf{image}
|
||||
|
||||
\item \textbf{confirm}: Για επιβεβαίωση της δημιουργίας της
|
||||
εικονικής μηχανής χωρίς να χρειαστεί χειροκίνητη επιβεβαίωση από
|
||||
τον χρήστη.
|
||||
εικονικής μηχανής χωρίς να χρειαστεί χειροκίνητη επιβεβαίωση
|
||||
από τον χρήστη.
|
||||
|
||||
\item \textbf{deploy}: Για την εκτέλεση του harden.
|
||||
|
||||
@@ -435,7 +434,8 @@ Docker. Το harden, εκτελείται μόνο στις εικονικές
|
||||
\item \textbf{node\_action}:
|
||||
|
||||
Η συνάρτηση \textquote{node\_action}, είναι αυτή που εκτελεί τις
|
||||
ενέργειες πάνω στις εικονικές μηχανές. Στις ενέργειες αυτές περιλαμβάνονται:
|
||||
ενέργειες πάνω στις εικονικές μηχανές. Στις ενέργειες αυτές
|
||||
περιλαμβάνονται:
|
||||
|
||||
\begin{itemize}
|
||||
|
||||
|
||||
@@ -41,7 +41,7 @@ git clone https://git.konsthol.eu/konsthol/SecDep.git
|
||||
\subsection{Εγκατάσταση των απαιτούμενων εξαρτήσεων}
|
||||
|
||||
Μετά την ολοκλήρωση της εγκατάστασης του πηγαίου κώδικα του SecDep, αφού ο
|
||||
χρήστης μεταβεί στον φάκελο με τα περιεχόμενα που απεικονίζονται στο σχήμα
|
||||
χρήστης μεταβεί στον φάκελο με τα περιεχόμενα που απεικονίζονται στο Σχήμα
|
||||
\ref{fig:secdep_install_without_git}, επιβάλλεται να γίνει χρήση του
|
||||
προγράμματος pip \footfullcite{pip} για την εγκατάσταση των βιβλιοθηκών που
|
||||
απαιτούνται για την λειτουργία του εργαλείου. Αυτό επιτυγχάνεται με την
|
||||
|
||||
@@ -32,8 +32,8 @@ Lynis και το LUNAR.
|
||||
|
||||
\item \textbf{Το NVD (National Vulnerability Database)}
|
||||
|
||||
\item \textbf{Τα αρχεία ορισμού OVAL (Open Vulnerability and Assessment Language)}
|
||||
που διατίθενται από τις διανομές Linux
|
||||
\item \textbf{Τα αρχεία ορισμού OVAL (Open Vulnerability and Assessment
|
||||
Language)} που διατίθενται από τις διανομές Linux
|
||||
|
||||
\item \textbf{Συμβουλευτικές πηγές ασφαλείας}
|
||||
|
||||
@@ -85,15 +85,15 @@ Lynis και το LUNAR.
|
||||
|
||||
\item \textbf{Εκτεταμένη σάρωση}:
|
||||
|
||||
Στο δεύτερο επίπεδο αξιολόγησης, το Vuls χρειάζεται να συνδεθεί ως ένας
|
||||
χρήστης ικανός να εκτελέσει εντολές διαχειριστικού επιπέδου. Η σάρωση
|
||||
που πραγματοποιείται είναι πιο εκτεταμένη και περιλαμβάνει ελέγχους που
|
||||
απαιτούν την ύπαρξη πακέτων λογισμικού στον απομακρυσμένο διακομιστή
|
||||
όπως τα lsof, debian-goodies και reboot-notifier.
|
||||
Στο δεύτερο επίπεδο αξιολόγησης, το Vuls χρειάζεται να συνδεθεί ως ένας
|
||||
χρήστης ικανός να εκτελέσει εντολές διαχειριστικού επιπέδου. Η σάρωση
|
||||
που πραγματοποιείται είναι πιο εκτεταμένη και περιλαμβάνει ελέγχους που
|
||||
απαιτούν την ύπαρξη πακέτων λογισμικού στον απομακρυσμένο διακομιστή
|
||||
όπως τα lsof, debian-goodies και reboot-notifier.
|
||||
|
||||
\end{itemize}
|
||||
|
||||
Στο σχήμα \ref{fig:vuls-architecture}, όπως αυτό πάρθηκε από την επίσημη
|
||||
Στο Σχήμα \ref{fig:vuls-architecture}, όπως αυτό πάρθηκε από την επίσημη
|
||||
ιστοσελίδα του εργαλείου, απεικονίζεται η αρχιτεκτονική του Vuls κατά την
|
||||
διαδικασία σάρωσης απομακρυσμένου διακομιστή.
|
||||
|
||||
@@ -109,7 +109,7 @@ Lynis και το LUNAR.
|
||||
|
||||
\clearpage
|
||||
|
||||
Στο σχήμα \ref{fig:vulsScan}, το οποίο παρομοίως αποκτήθηκε από την επίσημη
|
||||
Στο Σχήμα \ref{fig:vulsScan}, το οποίο παρομοίως αποκτήθηκε από την επίσημη
|
||||
σελίδα του, απεικονίζεται η διαδικασία που ακολουθείται κατά την εκτέλεση της
|
||||
σάρωσης ενός συστήματος.
|
||||
|
||||
@@ -137,7 +137,7 @@ Lynis και το LUNAR.
|
||||
εύκολα σε κάθε σύστημα Linux διότι πρόκειται για ένα απλό εκτελέσιμο αρχείο
|
||||
bash.
|
||||
|
||||
Στο σχήμα \ref{fig:lynisScan} απεικονίζεται ένα κομμάτι της αναφοράς που
|
||||
Στο Σχήμα \ref{fig:lynisScan} απεικονίζεται ένα κομμάτι της αναφοράς που
|
||||
επιστρέφει.
|
||||
|
||||
\begin{center}
|
||||
@@ -669,7 +669,7 @@ cd lunar
|
||||
διακομιστές μας, ο διακομιστής secdepawsHardened, σχετικά με τα CVEs που
|
||||
εντοπίστηκαν, έχει ασφαλιστεί κατά 26.615\%. Επιπροσθέτως, με βάση τα γραφήματα
|
||||
που παρήχθησαν από το VulsRepo, μπορούμε να διακρίνουμε μια άμεση πτώση των
|
||||
ευπαθειών με βάση την κατηγορία σοβαρότητας τους στο σχήμα
|
||||
ευπαθειών με βάση την κατηγορία σοβαρότητάς τους στο Σχήμα
|
||||
\ref{fig:vuls-cvss-severity-table}.
|
||||
|
||||
\begin{center}
|
||||
@@ -786,7 +786,7 @@ cat lynis.log | grep -i index | sed 's/^ *//g' | cut -d' ' -f4
|
||||
\end{savenotes}
|
||||
|
||||
H αύξηση ασφάλειας του διακομιστή ανέρχεται στο 9.23077\% και απεικονίζεται
|
||||
γραφικά στο σχήμα \ref{fig:lynis-security-index}.
|
||||
γραφικά στο Σχήμα \ref{fig:lynis-security-index}.
|
||||
|
||||
\begin{center}
|
||||
\begin{figure}[!ht]
|
||||
@@ -844,7 +844,7 @@ cat lunar.log | grep -i "warnings:" | awk '{print $2}'
|
||||
\end{table}
|
||||
\end{savenotes}
|
||||
|
||||
Από τον πίνακα \ref{table:lunar-warnings-table} διαπιστώνεται πως έχουμε
|
||||
Από τον Πίνακα \ref{table:lunar-warnings-table} διαπιστώνεται πως έχουμε
|
||||
2.25564\% αύξηση της ασφάλειας, το οποίο απεικονίζεται και ως εξής:
|
||||
|
||||
\begin{center}
|
||||
|
||||
@@ -25,7 +25,7 @@
|
||||
|
||||
\section{Συμπεράσματα}
|
||||
|
||||
Με βάση τα αποτελέσματα των πειραμάτων που πραγματοποιήθηκαν στο κεφάλαιο
|
||||
Με βάση τα αποτελέσματα των πειραμάτων που πραγματοποιήθηκαν στο Κεφάλαιο
|
||||
\ref{experimentationANDresults}, μπορούμε να συμπεράνουμε ότι το εργαλείο
|
||||
SecDep, είναι ικανό να δημιουργήσει εικονικές μηχανές που έχουν σκληρύνει σε
|
||||
ικανοποιητικό βαθμό, χωρίς περαιτέρω παρέμβαση από τον χρήστη. Μπορεί λοιπόν να
|
||||
@@ -68,4 +68,4 @@ Docker, θα μπορούσε και αυτό να επεκταθεί, προσ
|
||||
διαδικασία σκλήρυνσης. Τα αποτελέσματα είναι ήδη αρκετά ικανοποιητικά, ωστόσο
|
||||
πάντα υπάρχουν περιθώρια βελτίωσης.
|
||||
|
||||
\clearpage
|
||||
\clearpage % Needed to reset header
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω συμβουλευτεί την δημοσιευμένη δουλειά
|
||||
τρίτων, αυτό αποδίδεται ορθώς.
|
||||
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω παραθέσει από δουλειά τρίτων, η πηγή
|
||||
\item[\tiny{$\blacksquare$}] Όπου έχω παραθέσει δουλειά τρίτων, η πηγή
|
||||
δίνεται πάντα. Με εξαίρεση αυτές τις παραθέσεις, αυτή η διπλωματική
|
||||
εργασία είναι εξ ολοκλήρου προσωπική μου δουλειά.
|
||||
|
||||
@@ -43,7 +43,7 @@
|
||||
% Ημερομηνία:\\
|
||||
% \rule[1em]{25em}{0.5pt} % This prints a line to write the date
|
||||
|
||||
% \small\noindent Αυτή η διπλωματική εργασία είναι διαθέσιμη υπό το: \\
|
||||
\small\noindent Αυτή η διπλωματική εργασία είναι διαθέσιμη υπό το: \\
|
||||
\small\textbf{Αναφορά Δημιουργού - Μη Εμπορική Χρήση - Παρόμοια Διανομή 4.0 Διεθνές}
|
||||
|
||||
\begin{center}
|
||||
|
||||
@@ -32,6 +32,8 @@
|
||||
\usepackage{textcomp}
|
||||
% Make landscape pages display as landscape
|
||||
\usepackage{pdflscape}
|
||||
% Better paragraph break in new pages
|
||||
\usepackage[defaultlines=4,all]{nowidow}
|
||||
|
||||
% Select alternative section titles (Better chapter, section and subsection titles)
|
||||
\usepackage{titlesec}
|
||||
|
||||
Reference in New Issue
Block a user