Εν ολίγοις: Μια σύμβαση με πάροχο IT δεν πρέπει να αναφέρει την ασφάλεια απλώς in passing, αλλά να τη ρυθμίζει συγκεκριμένα: ποιος ενημερώνει ποια στοιχεία, σε ποια προθεσμία και με ποια απόδειξη, πώς ενημερώνεστε για κρίσιμες ευπάθειες, ποιος συμμετέχει σε περίπτωση περιστατικού, πώς διατηρούνται τα logs και διαχειρίζονται οι προσβάσεις και τι συμβαίνει κατά την έξοδο. Αυτή η σελίδα δίνει γενικές υποδείξεις και δεν αποτελεί νομική συμβουλή· τις συμβάσεις τις ελέγχει δικηγόρος.
Το ερώτημα που έθεσε το PHP2Shell: ποιος είναι αρμόδιος;
Στις 21/10/2026 στις 16:00 ώρα Γερμανίας το έργο PHP δημοσίευσε τα patches. Η BSI (Ομοσπονδιακή Υπηρεσία Ασφάλειας Πληροφοριών της Γερμανίας) συνέστησε άμεση ενημέρωση ή, όπου δεν ήταν δυνατή, προσωρινή αποσύνδεση των διακομιστών ιστού από το δίκτυο. Σε πολλές επιχειρήσεις δεν άρχισε μετά η δουλειά, αλλά η αναζήτηση της αρμοδιότητας. Το πρακτορείο παρέπεμπε στον πάροχο φιλοξενίας, ο πάροχος στη σύμβαση, και στη σύμβαση έγραφε «συντήρηση κατά προσπάθεια».
Τέτοια κενά στη σύμβαση δεν είναι μεμονωμένη περίπτωση. Πολλές συμβάσεις με πρακτορεία και παρόχους συνήφθησαν όταν επρόκειτο για την κατασκευή ενός ιστοτόπου και όχι για την ασφαλή λειτουργία του επί χρόνια. Μια κρίσιμη ευπάθεια στο runtime της PHP, που δεν αφορά ούτε το CMS ούτε τον κώδικα της εφαρμογής, πέφτει τότε εύκολα ανάμεσα σε όλους.
Τι πρέπει να ρυθμίζει μια σύμβαση παρόχου IT για την ασφάλεια
Η παρακάτω επισκόπηση αναφέρει τα σημεία που έχουν αποδειχθεί σημαντικά στην πράξη. Δεν αντικαθιστά τον νομικό έλεγχο, βοηθά όμως να εντοπίσετε κενά στην υπάρχουσα σύμβαση.
| Σημείο ρύθμισης | Τι πρέπει να καταγράφεται | Σχέση με το PHP2Shell |
|---|---|---|
| Εύρος παροχής | Ποια επίπεδα φροντίζονται: λειτουργικό σύστημα, runtime PHP, διακομιστής ιστού, CMS, πρόσθετα, δικός κώδικας | Το runtime PHP έλειπε συχνά από την απαρίθμηση |
| Προθεσμίες ενημερώσεων | διαβαθμισμένες ανάλογα με τη σοβαρότητα, με ρύθμιση εξαίρεσης για έκτακτες ανάγκες | κρίσιμη ευπάθεια με CVSS v4.0 9.2 |
| Επανεκκίνηση και απόδειξη | Οι ενημερώσεις θεωρούνται ολοκληρωμένες μόνο μετά την επανεκκίνηση όλων των διεργασιών, με γραπτή απόδειξη | μόνο τα νέα αρχεία δεν κλείνουν την ευπάθεια |
| Πληροφόρηση | ενεργή ειδοποίηση για κρίσιμες ευπάθειες, με εκτίμηση και σχέδιο | πολλοί πελάτες έπρεπε να ρωτήσουν οι ίδιοι |
| Συμμετοχή σε περιστατικά | υποστήριξη σε ανάλυση, διατήρηση, αποκατάσταση, πρόσωπα επικοινωνίας | αναζήτηση ιχνών μετά το patch |
| Logs | είδος, διατήρηση, παράδοση κατόπιν αιτήματος | ο ειδικός Τύπος συνέστησε να φυλαχτούν logs από τις 20/10 |
| Προσβάσεις | προσωπικοί λογαριασμοί, σύνδεση δύο παραγόντων, λίστα όλων των προσβάσεων | ποιος είχε στην πραγματικότητα πρόσβαση; |
| Υπεργολάβοι | ποιος συμμετέχει επιπλέον, ενημέρωση σε περίπτωση αλλαγής | ο πάροχος του παρόχου |
| Τέλος ζωής λογισμικού | έγκαιρη υπόδειξη πριν από το τέλος υποστήριξης, σχέδιο μετάβασης | η PHP 8.2 λήγει στις 31/12/2026 |
| Έξοδος | παράδοση δεδομένων, τεκμηρίωσης και προσβάσεων, ανάκληση δικαιωμάτων | αλλαγή παρόχου μετά από περιστατικό |
Προθεσμίες και αποδείξεις: τα σημεία που μετρούν περισσότερο
Οι προθεσμίες είναι ο πυρήνας. Μια διατύπωση όπως «άμεσα» δεν βοηθά σε περίπτωση ανάγκης. Συμφωνήστε προθεσμίες χωριστά ανά σοβαρότητα και ορίστε με τι μετριέται η σοβαρότητα, για παράδειγμα με την κατάταξη από τον κατασκευαστή ή τη BSI. Για έκτακτες καταστάσεις πρέπει να ισχύει μια ρύθμιση έκτακτης ανάγκης: ποιος είναι προσβάσιμος, ποιος αποφασίζει αν ένα σύστημα αποσυνδέεται προσωρινά από το δίκτυο και πώς χρεώνεται η πρόσθετη προσπάθεια.
Εξίσου σημαντική είναι η απόδειξη. Στο PHP2Shell ο αριθμός έκδοσης που εμφανιζόταν έλεγε συχνά λίγα, επειδή οι διανομές και οι πάροχοι φιλοξενίας εγκαθιστούν διορθώσεις ως backport. Μια αξιόπιστη απόδειξη αναφέρει το επίπεδο του πακέτου, τη χρονική στιγμή της εγκατάστασης και την επανεκκίνηση όλων των διεργασιών PHP. Ποια στοιχεία μετρούν ακριβώς, περιγράφει το Πώς ρωτάτε τον πάροχο φιλοξενίας για την κατάσταση των patches. Συμπεριλάβετε αυτά τα στοιχεία ως υποχρεωτικό περιεχόμενο στη σύμβαση.
Ζητήστε από τον πάροχο έναν πίνακα εργασιών για τη σύμβαση: μία γραμμή ανά στοιχείο, μία στήλη ανά εργασία, σε κάθε κελί ένα όνομα. Τα κενά γίνονται τότε αμέσως αντιληπτά, πολύ πριν έρθει η επόμενη ειδοποίηση.
Προσβάσεις, υπεργολάβοι και έξοδος
Οι πάροχοι χρειάζονται προσβάσεις, και αυτές ακριβώς είναι συχνός δρόμος επίθεσης. Ρυθμίστε ότι κάθε άτομο παίρνει δικό του λογαριασμό, ότι η σύνδεση δύο παραγόντων είναι υποχρεωτική όπου η τεχνολογία το επιτρέπει και ότι μπορείτε ανά πάσα στιγμή να ζητήσετε μια τρέχουσα λίστα όλων των προσβάσεων. Οι εργαζόμενοι του παρόχου που αποχωρούν πρέπει να αφαιρούνται έγκαιρα από όλα τα συστήματα.
Αν ο πάροχος εργάζεται ο ίδιος με συνεργάτες, για παράδειγμα ένα κέντρο δεδομένων ή μια εξειδικευμένη ομάδα δικανικής ανάλυσης, πρέπει να το γνωρίζετε. Αν ένας από αυτούς τους συνεργάτες επεξεργάζεται προσωπικά δεδομένα, προστίθενται υποχρεώσεις προστασίας δεδομένων. Περισσότερα στο άρθρο Εκτέλεση της επεξεργασίας όταν πάροχοι έχουν πρόσβαση σε διακομιστές.
Η έξοδος είναι αυτό που ξεχνιέται συχνότερα κατά τη σύναψη της σύμβασης. Καταγράψτε ότι στη λήξη της σύμβασης παραδίδονται πλήρως δεδομένα, διαμόρφωση, τεκμηρίωση και στοιχεία πρόσβασης, ανακαλούνται όλες οι προσβάσεις του παρόχου και αυτό επιβεβαιώνεται γραπτά. Ιδίως μετά από ένα περιστατικό, μια οργανωμένη αλλαγή είναι αλλιώς δύσκολη.
Έλεγχος των υπαρχουσών συμβάσεων: πώς προχωράτε
Δεν χρειάζεται να επαναδιαπραγματευτείτε όλες τις συμβάσεις. Μια πραγματιστική διαδικασία αρκεί για την αρχή:
- Συγκεντρώστε όλες τις συμβάσεις με πρακτορεία, παρόχους φιλοξενίας και παρόχους IT που αφορούν ιστότοπους ή διακομιστές.
- Συγκρίνετε κάθε σύμβαση με τον παραπάνω πίνακα και σημειώστε τα ανοιχτά σημεία.
- Θέστε γραπτά στον πάροχο τα σημαντικότερα κενά, ξεκινώντας από το εύρος παροχής, τις προθεσμίες και την απόδειξη.
- Καταγράψτε τα αποτελέσματα ως συμπληρωματική συμφωνία και αναθέστε τον νομικό έλεγχο.
- Μεταφέρετε τον πίνακα εργασιών στο σχέδιο έκτακτης ανάγκης.
Για τη διοίκηση αυτό το βήμα είναι και θέμα επιμέλειας. Όποιος ρυθμίζει σαφώς τις αρμοδιότητες και τεκμηριώνει τις αποφάσεις, βρίσκεται σε καλύτερη θέση αν τεθούν αργότερα ερωτήματα. Το υπόβαθρο προσφέρει το Ευθύνη της διοίκησης για ευπάθειες ασφαλείας IT. Την τυπική κατανομή εργασιών σε διακομιστές με υπηρεσία διαχείρισης περιγράφει το Managed Server: διευκρίνιση της ευθύνης.
Πώς βοηθά συγκεκριμένα η PHP SOS;
- Διαβάζουμε τις υπάρχουσες συμβάσεις και τις περιγραφές παροχών σας από τεχνική σκοπιά και επισημαίνουμε ποια στοιχεία και εργασίες λείπουν.
- Συντάσσουμε έναν πίνακα εργασιών για όλους τους ιστότοπους και διακομιστές, που μπορείτε να συντονίσετε με τους παρόχους σας.
- Διατυπώνουμε τις τεχνικές απαιτήσεις για προθεσμίες, αποδείξεις και κανάλια αναφοράς, που μπορεί να ενσωματώσει ο δικηγόρος σας στη σύμβαση.
- Όπου κανείς δεν είναι αρμόδιος, αναλαμβάνουμε οι ίδιοι τις εργασίες μέσω μιας σύμβασης συντήρησης ασφαλείας με σαφώς περιγραμμένο εύρος.
Συμπέρασμα: Μια καλή σύμβαση δεν εμποδίζει μια ευπάθεια ασφαλείας, εμποδίζει όμως να χαθεί χρόνος σε περίπτωση ανάγκης με το ερώτημα της αρμοδιότητας. Αυτή η σελίδα είναι γενική πληροφόρηση και όχι νομική συμβουλή.
Συχνές ερωτήσεις
Πρέπει ένας πάροχος IT να εγκαθιστά ενημερώσεις ασφαλείας χωρίς ανάθεση;
Εξαρτάται από τη σύμβαση. Χωρίς σαφή ρύθμιση είναι συχνά αμφισβητήσιμο αν οι ενημερώσεις ανήκουν στην οφειλόμενη παροχή. Γι' αυτό η σύμβαση πρέπει να αναφέρει ρητά ποιος ενημερώνει ποια στοιχεία και σε ποια προθεσμία. Για τη νομική αξιολόγηση σε κάθε περίπτωση αρμόδιος είναι ένας δικηγόρος.
Χρειάζομαι επιπλέον μια σύμβαση εκτελούντος την επεξεργασία (AVV);
Αν ο πάροχος επεξεργάζεται για λογαριασμό σας προσωπικά δεδομένα ή μπορεί να έχει πρόσβαση σε αυτά, χρειάζεται κατά κανόνα σύμβαση εκτέλεσης της επεξεργασίας σύμφωνα με το άρθρο 28 του ΓΚΠΔ. Δεν αντικαθιστά τη σύμβαση παροχής, αλλά τη συμπληρώνει. Διευκρινίστε το με τον υπεύθυνο προστασίας δεδομένων σας.
Ποιες προθεσμίες για ενημερώσεις ασφαλείας είναι συνηθισμένες;
Σταθερές τιμές δεν υπάρχουν. Λογική είναι μια διαβάθμιση ανάλογα με τη σοβαρότητα, για παράδειγμα χωριστές προθεσμίες για κρίσιμες, υψηλές και λοιπές ευπάθειες. Σημασία έχει οι προθεσμίες να αναγράφονται γραπτά και να περιέχουν μια ρύθμιση εξαίρεσης για έκτακτες ανάγκες όπως το PHP2Shell.
Τι συμβαίνει με τις προσβάσεις όταν λήγει η σύμβαση;
Αυτό πρέπει να το ρυθμίζει η σύμβαση: επιστροφή ή διαγραφή δεδομένων, παράδοση στοιχείων πρόσβασης και τεκμηρίωσης, ανάκληση όλων των προσβάσεων του παρόχου και επιβεβαίωση γι' αυτό.