# Αλλαγή παρόχου φιλοξενίας μετά από περιστατικό ασφαλείας: τι να προσέξετε;

> Αλλαγή παρόχου φιλοξενίας μετά από περιστατικό ασφαλείας: σωστή σειρά, διασφάλιση αποδεικτικών, μεταφορά μόνο ελεγμένων δεδομένων και έλεγχος του νέου παρόχου.

Πηγή: https://phpsos.de/el/blog/hoster-wechseln-nach-vorfall/  
Ημερομηνία: 25/10/2026  
Πάροχος: PHP SOS, Επείγουσα βοήθεια PHP και ασφάλεια διακομιστών. Άμεση βοήθεια μέσω WhatsApp: https://wa.me/491736494914?text=%CE%93%CE%B5%CE%B9%CE%B1%20%CF%83%CE%B1%CF%82%2C%20PHP%20SOS%2C%20%CF%87%CF%81%CE%B5%CE%B9%CE%B1%CE%B6%CF%8C%CE%BC%CE%B1%CF%83%CF%84%CE%B5%20%CE%B2%CE%BF%CE%AE%CE%B8%CE%B5%CE%B9%CE%B1%20%CE%BC%CE%B5%20%CF%84%CE%BF%CE%BD%20%CE%B4%CE%B9%CE%B1%CE%BA%CE%BF%CE%BC%CE%B9%CF%83%CF%84%CE%AE%20PHP%20%CE%BC%CE%B1%CF%82.%20%CE%95%CF%84%CE%B1%CE%B9%CF%81%CE%B5%CE%AF%CE%B1%3A%20%E2%80%A6%20%CE%99%CF%83%CF%84%CF%8C%CF%84%CE%BF%CF%80%CE%BF%CF%82%3A%20%E2%80%A6

**Εν ολίγοις:** Όποιος θέλει να αλλάξει πάροχο φιλοξενίας μετά από περιστατικό ασφαλείας, πρέπει πρώτα να διασφαλίσει αποδεικτικά στοιχεία και να διευκρινίσει το περιστατικό, έπειτα να μεταφέρει μόνο ελεγμένα δεδομένα σε ένα σύστημα που στήθηκε εκ νέου και μόνο μετά να λύσει την παλιά σύμβαση. Τον νέο πάροχο τον επιλέγετε με κριτήρια ασφάλειας: αποδείξιμες διαδικασίες patch, διαχωρισμός των πελατών, πρόσβαση σε logs, αντίγραφα ασφαλείας και σαφείς υπεύθυνοι επικοινωνίας. Η αλλαγή παρόχου έχει νόημα όταν λείπουν η εμπιστοσύνη ή οι υπηρεσίες, δεν υποκαθιστά όμως τον καθαρισμό.

## Όταν χάνεται η εμπιστοσύνη

Μετά το PHP2Shell πολλές επιχειρήσεις βιώνουν για πρώτη φορά τον πάροχο φιλοξενίας τους υπό πίεση. Ορισμένες έλαβαν γρήγορα σαφή ενημέρωση για το επίπεδο του patch. Άλλες περίμεναν ημέρες για απάντηση, έλαβαν μόνο γενικές διατυπώσεις ή διαπίστωσαν ότι ο ιστότοπός τους έτρεχε σε παρωχημένη έκδοση PHP. Αν προστεθεί και ένα περιστατικό, η επιθυμία για αλλαγή είναι κατανοητή.

Η αλλαγή παρόχου όμως δεν είναι βήμα της διαχείρισης του περιστατικού, αλλά της νέας τοποθέτησης μετά απ' αυτό. Όποιος την κάνει με λάθος σειρά, στη χειρότερη περίπτωση μεταφέρει μαζί τον επιτιθέμενο και χάνει ταυτόχρονα τα ίχνη που δείχνουν τι συνέβη.

## Η σωστή σειρά στην αλλαγή

1. **Διασφαλίστε τα ίχνη όσο υπάρχουν.** Τα logs, τα αρχεία και η βάση δεδομένων του παλιού συστήματος ανήκουν σε ένα αντίγραφο ασφαλείας πριν διαγραφεί ή καταγγελθεί οτιδήποτε. Ζητήστε ρητά από τον παλιό πάροχο τα logs πρόσβασης και σφαλμάτων από τις 20 Οκτωβρίου 2026 και τη διάρκεια διατήρησής τους. Πώς προχωράτε, περιγράφει το άρθρο [Διασφάλιση αποδεικτικών πριν από την επανεγκατάσταση](https://phpsos.de/el/blog/beweise-sichern-vor-neuinstallation/).
2. **Οριοθετήστε το περιστατικό.** Ποια συστήματα επηρεάζονται, ποιες προσβάσεις χρησιμοποιήθηκαν, ποια δεδομένα ήταν προσβάσιμα; Από αυτά εξαρτώνται οι υποχρεώσεις γνωστοποίησης και το τι επιτρέπεται να μεταφέρετε.
3. **Ελέγξτε τις υποχρεώσεις γνωστοποίησης.** Αν ενδέχεται να θίγονται δεδομένα προσωπικού χαρακτήρα, η προθεσμία για πιθανή γνωστοποίηση σύμφωνα με τον ΓΚΠΔ ξεκινά με τη γνώση του περιστατικού και όχι με τη μετακόμιση. Το υπόβαθρο θα βρείτε στο [Υποχρέωση γνωστοποίησης ΓΚΠΔ: 72 ώρες](https://phpsos.de/el/compliance/dsgvo-meldepflicht-72-stunden/).
4. **Στήστε το νέο σύστημα καθαρά.** Υποστηριζόμενη έκδοση PHP, τρέχοντα πακέτα, θωρακισμένη διαμόρφωση, πριν μεταφερθεί το πρώτο αρχείο.
5. **Μεταφέρετε μόνο ό,τι έχει ελεγχθεί.** Κώδικας από καθαρή πηγή, βάση δεδομένων και πολυμέσα μετά από έλεγχο.
6. **Αλλάξτε όλα τα διαπιστευτήρια πρόσβασης.** Βάση δεδομένων, λογαριασμοί διαχειριστή, SSH, FTP, κλειδιά API, ακόμη και όσα βρίσκονται σε αρχεία διαμόρφωσης.
7. **Αλλάξτε και παρακολουθήστε.** Αλλαγή DNS και κατόπιν, για ένα διάστημα, στενότερη παρακολούθηση.
8. **Τερματίστε την παλιά σύμβαση.** Μόνο όταν τα logs και τα αντίγραφα ασφαλείας έχουν διασφαλιστεί και η νέα λειτουργία τρέχει σταθερά.

> **Σημαντικό:**
> Μην καταγγείλετε την παλιά σύμβαση πριν έχετε στα χέρια σας τα logs και τα αντίγραφα ασφαλείας. Με τη λήξη της σύμβασης μπορεί να διαγραφούν στον πάροχο δεδομένα που χρειάζεστε για ασφαλιστές, αρχές ή τη δική σας διερεύνηση.

## Τι δεν πρέπει να πάρετε μαζί

Θα ήταν βολικό να αντιγράψετε απλώς ολόκληρο τον κατάλογο ιστού ή μια εικόνα του διακομιστή. Αυτό ακριβώς είναι επικίνδυνο μετά από περιστατικό. Τα webshells μεταμφιέζονται σε αθώα αρχεία, οι κερκόπορτες κρύβονται σε αρχεία διαμόρφωσης όπως το `.htaccess` ή το `.user.ini` και ο παρεισφρήσας κώδικας μπορεί να βρίσκεται σε περιεχόμενο της βάσης δεδομένων.

Μεταφέρετε γι' αυτό τον κώδικα της εφαρμογής από καθαρή πηγή, για παράδειγμα από το πακέτο του κατασκευαστή στην κατάλληλη έκδοση ή από το σύστημα ελέγχου εκδόσεων. Τα πολυμέσα τα παίρνετε χωρίς εκτελέσιμα αρχεία, τη βάση δεδομένων μετά από έλεγχο για ύποπτο περιεχόμενο και νέους λογαριασμούς διαχειριστή. Όσα βρέθηκαν στο παλιό σύστημα βοηθούν σε αυτόν τον έλεγχο.

Σκεφτείτε και ό,τι βρίσκεται δίπλα στον ιστότοπο στον παλιό πάροχο. Γραμματοκιβώτια email, εγγραφές DNS, πιστοποιητικά και προωθήσεις ξεχνιούνται εύκολα στη μετακόμιση. Μειώστε τη διάρκεια ισχύος των εγγραφών DNS λίγες ημέρες πριν από την αλλαγή, ώστε η μεταβολή να φτάσει γρήγορα στους επισκέπτες. Αν μετακομίζουν και τα email, προγραμματίστε χωριστά την αλλαγή των γραμματοκιβωτίων, γιατί και εκεί μπορεί μετά από περιστατικό να έχουν θιγεί διαπιστευτήρια.

## Επιλογή του νέου παρόχου με κριτήριο την ασφάλεια

Η τιμή και ο χώρος αποθήκευσης αναγράφονται σε κάθε προσφορά. Τις καθοριστικές ερωτήσεις ασφάλειας πρέπει συνήθως να τις θέσετε μόνοι σας. Η παρακάτω λίστα βοηθά στη σύγκριση:

| Κριτήριο | Ερώτηση προς τον πάροχο | Γιατί μετράει |
|---|---|---|
| Διαδικασία patch | Πώς και σε ποιο πλαίσιο εφαρμόζονται οι ενημερώσεις ασφαλείας PHP και γίνεται επανεκκίνηση; | Το PHP2Shell έδειξε πόσο σημαντική είναι μια αποδείξιμη διαδικασία |
| Τεκμήριο | Λαμβάνω κατόπιν αιτήματος γραπτή επιβεβαίωση για το επίπεδο του patch; | Βάση για τη δική σας τεκμηρίωση |
| Εκδόσεις PHP | Ποιοι κλάδοι προσφέρονται και για πόσο ακόμη; | Οι παλιοί κλάδοι χωρίς ενημερώσεις αποτελούν μόνιμο κίνδυνο |
| Διαχωρισμός | Τρέχει κάθε ιστότοπος με δικό του χρήστη και δική του διεργασία PHP; | Περιορίζει τη ζημιά όταν δέχεται επίθεση ένας γείτονας |
| Logs | Έχω πρόσβαση σε logs πρόσβασης και σφαλμάτων και για πόσο διατηρούνται; | Χωρίς logs δεν υπάρχει διερεύνηση |
| Αντίγραφα ασφαλείας | Πόσο συχνά, για πόσο, χωριστά από τον διακομιστή ιστού, με δοκιμή επαναφοράς; | Επαναφορά μετά από περιστατικό |
| Επαφή έκτακτης ανάγκης | Πώς φτάνω σε εξειδικευμένο πρόσωπο σε περίπτωση περιστατικού; | Ο χρόνος είναι ο σπανιότερος παράγοντας στην έκτακτη ανάγκη |
| Επεξεργασία κατ' εντολή | Υπάρχει σύμβαση σύμφωνα με τον ΓΚΠΔ και κατάλογος υποεκτελούντων την επεξεργασία; | Υποχρέωση στα δεδομένα προσωπικού χαρακτήρα |

Υπόδειγμα για την ερώτηση σχετικά με το επίπεδο του patch προσφέρει ο οδηγός [Ρωτήστε τον πάροχο φιλοξενίας για την κατάσταση του patch](https://phpsos.de/el/ratgeber/hoster-patch-status-erfragen/). Ενδείκνυται και για τη σύγκριση παρόχων πριν από τη σύναψη σύμβασης.

## Είναι ένα άλλο μοντέλο λειτουργίας η καλύτερη απάντηση;

Μερικές φορές το πρόβλημα βρίσκεται λιγότερο στον πάροχο και περισσότερο στο μοντέλο λειτουργίας. Όποιος λειτουργεί δικό του διακομιστή χωρίς τακτική συντήρηση, συνήθως είναι καλύτερα με μια καλά επιτηρούμενη προσφορά Managed. Αντίστροφα, μια επιχείρηση με δική της πληροφορική μπορεί να κερδίσει περισσότερο έλεγχο στους χρόνους των patch, αν διαχειρίζεται μόνη της. Τη στάθμιση περιγράφει το άρθρο [Managed Hosting ή δικός σας διακομιστής;](https://phpsos.de/el/blog/managed-oder-eigener-server/).

Ανεξάρτητα από το μοντέλο ισχύει: καταγράψτε γραπτά την κατανομή των καθηκόντων. Ποιος εφαρμόζει τις ενημερώσεις PHP, ποιος κάνει επανεκκίνηση, ποιος ελέγχει την εφαρμογή, ποιος επικοινωνεί με ποιον στην έκτακτη ανάγκη; Στο PHP2Shell πολλές καθυστερήσεις προέκυψαν ακριβώς σε αυτό το σημείο, επειδή κάθε πλευρά πίστευε ότι η άλλη φροντίζει.

## Πώς βοηθά συγκεκριμένα η PHP SOS;

- Διασφαλίζουμε logs και δεδομένα του παλιού συστήματος και διευκρινίζουμε τι συνέβη στο περιστατικό.
- Χτίζουμε το νέο σύστημα θωρακισμένο και μεταφέρουμε μόνο ελεγμένο περιεχόμενο από καθαρές πηγές.
- Ελέγχουμε προσφορές νέων παρόχων με βάση τα κριτήρια ασφάλειας και θέτουμε τις σωστές ερωτήσεις.
- Σε περιστατικό που βρίσκεται σε εξέλιξη εργαζόμαστε στο πλαίσιο της [αντιμετώπισης περιστατικών (Incident Response)](https://phpsos.de/el/leistungen/incident-response/), μέχρι το περιστατικό να κλείσει και να τεκμηριωθεί.


## Συχνές ερωτήσεις

**Πρέπει μετά από hack να αλλάξω αμέσως πάροχο φιλοξενίας;**  
Όχι αμέσως. Πρώτα πρέπει να διασφαλιστούν τα ίχνη, να οριοθετηθεί το περιστατικό και να διευκρινιστεί η αιτία. Μια βιαστική μετακόμιση μπορεί να μεταφέρει τον κακόβουλο κώδικα και να καταστρέψει αποδεικτικά στοιχεία στον παλιό πάροχο.

**Έφταιγε ο πάροχος φιλοξενίας, αν ο ιστότοπός μου δέχτηκε επίθεση μέσω PHP2Shell;**  
Αυτό εξαρτάται από τη σύμβαση και από τον χρόνο. Στο shared hosting για τις ενημερώσεις PHP είναι συνήθως υπεύθυνος ο πάροχος, στους δικούς σας διακομιστές ο διαχειριστής. Τα patches κυκλοφόρησαν στις 21 Οκτωβρίου 2026· το αν και πότε εφαρμόστηκαν μπορεί να διευκρινιστεί μόνο με αποδεικτικά. Για ζητήματα ευθύνης συμβουλευτείτε δικηγόρο.

**Ποια δεδομένα επιτρέπεται να μεταφέρω στον νέο πάροχο;**  
Μόνο ελεγμένο περιεχόμενο: βάση δεδομένων μετά από έλεγχο για παρεισφρήσαντα κώδικα, πολυμέσα χωρίς εκτελέσιμα αρχεία και κώδικα από καθαρή πηγή, όπως το πακέτο του κατασκευαστή ή το σύστημα ελέγχου εκδόσεων. Πλήρεις εικόνες διακομιστή ή καταλόγους ιστού από το παραβιασμένο σύστημα δεν πρέπει να τους μεταφέρετε χωρίς έλεγχο.

**Πρέπει μετά από περιστατικό να εμπλέξω την προστασία δεδομένων;**  
Αν ενδέχεται να θίγονται δεδομένα προσωπικού χαρακτήρα, μπορεί να υπάρχει υποχρέωση γνωστοποίησης σύμφωνα με τον ΓΚΠΔ, κατά κανόνα εντός 72 ωρών. Στον νέο πάροχο χρειάζεστε επιπλέον σύμβαση εκτέλεσης επεξεργασίας. Διευκρινίστε το με τον υπεύθυνο προστασίας δεδομένων· αυτό δεν αποτελεί νομική συμβουλή.

## Πηγές

- [BSI IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)
- [Άρθρο 33 ΓΚΠΔ: γνωστοποίηση στην εποπτική αρχή](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [php.net: ανακοινώσεις ασφαλείας](https://www.php.net/)