Ασφαλές logging: καταγραφή σφαλμάτων χωρίς διαρροή δεδομένων

Εν ολίγοις: Το logging στην PHP με γνώμονα την προστασία δεδομένων σημαίνει: καταγράφετε πλήρως τα συμβάντα που αφορούν την ασφάλεια, δεν γράφετε όμως ποτέ στο log κωδικούς, tokens, αναγνωριστικά συνεδρίας και ευαίσθητα δεδομένα πελατών. Τα σφάλματα ανήκουν στο αρχείο καταγραφής και όχι στην οθόνη, τα logs βρίσκονται εκτός του webroot και προστατεύονται από αλλοίωση. Πόσο διατηρούνται τα logs, το αποφασίζετε συνειδητά μαζί με τον υπεύθυνο προστασίας δεδομένων.

Ανάμεσα στη διατήρηση ιχνών και τη διαρροή δεδομένων

Μετά το PHP2Shell τα ειδικά μέσα συνέστησαν να διατηρούνται τα logs του διακομιστή ιστού από τις 20/10/2026. Όποιος ήθελε να το εφαρμόσει, διαπίστωνε συχνά δύο πράγματα. Ή τα logs είχαν περιστραφεί και διαγραφεί προ πολλού. Ή περιείχαν πράγματα που δεν έπρεπε ποτέ να βρίσκονται εκεί: πλήρεις εισόδους φορμών, κωδικούς από αποτυχημένες συνδέσεις, κλειδιά API σε URL.

Και τα δύο είναι πρόβλημα. Χωρίς logs ένα περιστατικό δύσκολα ανασυνθέτεται. Με υπερβολικό περιεχόμενο το ίδιο το log γίνεται στόχος, γιατί όποιος αποκτά πρόσβαση στον διακομιστή το διαβάζει με ευχαρίστηση. Το καλό logging βρίσκεται ανάμεσα: αρκετό για την αναζήτηση ιχνών, όσο το δυνατόν λιγότερα προστατευτέα δεδομένα.

Τι πρέπει να καταγράφει μια εφαρμογή PHP

Το OWASP Logging Cheat Sheet αναφέρει συμβάντα που μετρούν για την ασφάλεια και την ιχνηλασιμότητα. Για τυπικές εφαρμογές PHP συνοψίζονται ως εξής:

Κάθε εγγραφή πρέπει να απαντά στα ερωτήματα πότε, πού, ποιος και τι: χρονοσήμανση, εφαρμογή και host, διεύθυνση προέλευσης, αναγνωριστικό χρήστη, είδος συμβάντος και αποτέλεσμα. Ονόματα ή διευθύνσεις email μπορούν συχνά να αποκρυφτούν ή να αντικατασταθούν από ένα εσωτερικό αναγνωριστικό, χωρίς να χαθεί η χρησιμότητα.

Δύο πηγές ανεπιθύμητων δεδομένων στο log παραβλέπονται συχνά. Η πρώτη είναι τα URL: αν ένα token, ένα κλειδί επαναφοράς κωδικού ή μια διεύθυνση email βρίσκεται στο query string, καταλήγει αυτόματα στο access log του διακομιστή ιστού, στα logs του proxy και στο ιστορικό του browser. Τέτοιες τιμές ανήκουν στο σώμα του αιτήματος ή σε μια κεφαλίδα και όχι στη διεύθυνση. Η δεύτερη πηγή είναι η λειτουργία debug. Frameworks και πρόσθετα γράφουν σε λειτουργία debug συχνά πλήρη αιτήματα, ερωτήματα βάσης δεδομένων και μεταβλητές περιβάλλοντος. Αν αυτή η λειτουργία μείνει ενεργή μετά από μια αναζήτηση σφαλμάτων, αναπτύσσεται απαρατήρητα ένα αρχείο με ακριβώς τις πληροφορίες που αναζητά ένας επιτιθέμενος. Ελέγξτε μετά από κάθε αναζήτηση σφαλμάτων αν οι έξοδοι debug έχουν απενεργοποιηθεί ξανά, και διαγράψτε τα αρχεία που δημιουργήθηκαν.

Logging στην PHP: οι βασικές ρυθμίσεις

Το πρώτο επίπεδο είναι η ίδια η PHP. Στην παραγωγή τα σφάλματα πρέπει να καταγράφονται αλλά να μην εμφανίζονται. Το log βρίσκεται εκτός του webroot, ώστε να μην είναι προσβάσιμο μέσω URL.

; php.ini ή pool FPM για παραγωγή
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/log/php/app-error.log

Γιατί τα ορατά σφάλματα είναι επικίνδυνα, περιγράφει το Απενεργοποίηση των εξόδων σφαλμάτων στην παραγωγή. Πώς σχετίζονται τα σφάλματα και οι εξαιρέσεις (exceptions) στην PHP, εξηγεί το Σφάλματα και εξαιρέσεις στην PHP.

Το δεύτερο επίπεδο είναι η εφαρμογή. Πολλά frameworks χρησιμοποιούν γι' αυτό μια βιβλιοθήκη σύμφωνα με το πρότυπο PSR-3 της PHP-FIG, που καθορίζει μια ενιαία διεπαφή logger. Σημασία δεν έχει η βιβλιοθήκη, αλλά η πειθαρχία: επιλέξτε συνειδητά τα δεδομένα πλαισίου, αντί να γράφετε ολόκληρα αιτήματα ή αντικείμενα στο log.

<?php
// εξουδετέρωση και απόκρυψη εισόδων πριν από το logging
function logSicher(string $text): string {
    return mb_substr(str_replace(["\r", "\n"], ' ', $text), 0, 200);
}

function maskiereMail(string $mail): string {
    [$name, $domain] = array_pad(explode('@', $mail, 2), 2, '');
    return mb_substr($name, 0, 1) . '***@' . $domain;
}

$logger->warning('Anmeldung fehlgeschlagen', [
    'benutzer' => maskiereMail(logSicher($_POST['email'] ?? '')),
    'ip'       => $_SERVER['REMOTE_ADDR'] ?? '',
    // ποτέ: 'passwort' => $_POST['passwort']
]);

Log injection και αλλοιωμένες εγγραφές

Αν μια εφαρμογή γράφει εισόδους αφιλτράριστες στο log, ένας επιτιθέμενος μπορεί με αλλαγές γραμμής να δημιουργήσει πλαστές εγγραφές. Αυτό μπερδεύει την ανάλυση και μπορεί να κρύψει ίχνη. Το OWASP Cheat Sheet συνιστά δομημένες μορφές όπως το JSON, την αφαίρεση ή κωδικοποίηση των αλλαγών γραμμής και έναν περιορισμό μήκους για εισόδους στο log.

Εξίσου σημαντική είναι η προστασία των ίδιων των logs:

1. Αποθήκευση εκτός του webroot και με δικαιώματα που ο χρήστης του διακομιστή ιστού χρειάζεται για εγγραφή, αλλά όχι για διαγραφή παλιών αρχείων.
2. Αντίγραφο σε δεύτερο σύστημα, για παράδειγμα μέσω syslog πάνω από κρυπτογραφημένη σύνδεση. Όποιος καταλαμβάνει τον διακομιστή, δεν πρέπει να μπορεί να διαγράψει απλώς τα ίχνη.
3. Περιορισμός της πρόσβασης ανάγνωσης και καταγραφή της ίδιας. Τα logs περιέχουν σχεδόν πάντα προσωπικά δεδομένα.
4. Εντοπισμός διακοπής: Αν το log μείνει ξαφνικά κενό, αυτό είναι προειδοποιητικό σημάδι.
5. Συγχρονισμός ώρας: Όλοι οι διακομιστές παίρνουν την ώρα από την ίδια πηγή και γράφουν μια σαφή ζώνη ώρας στο log. Αλλιώς οι εγγραφές του διακομιστή ιστού, της PHP και της βάσης δεδομένων δύσκολα συναρμολογούνται μετά από ένα περιστατικό σε μια χρονολογική γραμμή.

Διατήρηση και προστασία δεδομένων: αποφασίστε συνειδητά

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

Ορίστε γι' αυτό μια προθεσμία ανά είδος log, καταγράψτε την αιτιολόγηση και συντονίστε και τα δύο με τον υπεύθυνο προστασίας δεδομένων σας. Για μια τρέχουσα διερεύνηση μπορεί να χρειαστεί να φυλαχτούν logs πέρα από την κανονική προθεσμία. Αυτό πρέπει τότε επίσης να τεκμηριώνεται. Αυτή η σελίδα είναι γενική πληροφόρηση και όχι νομική συμβουλή· για συγκεκριμένα ερωτήματα βοηθούν ο υπεύθυνος προστασίας δεδομένων και ο δικηγόρος. Πώς αξιολογείτε logs μετά από μια επίθεση, δείχνει το Ανάλυση των αρχείων καταγραφής του διακομιστή ιστού μετά από επίθεση.

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

• Ελέγχουμε τα υπάρχοντα logs σας για κωδικούς, tokens και άλλα δεδομένα που δεν ανήκουν εκεί.
• Ρυθμίζουμε την PHP και την εφαρμογή ώστε τα σφάλματα να καταγράφονται αλλά να μην εμφανίζονται.
• Στήνουμε ένα προστατευμένο αντίγραφο των logs σε ξεχωριστό σύστημα.
• Μέσω της παρακολούθησης ασφαλείας αξιολογούμε διαρκώς εγγραφές σχετικές με την ασφάλεια και αναφέρουμε κατανοητά ό,τι είναι ασυνήθιστο.

Συμπέρασμα: Τα καλά logs είναι λιτά ως προς το περιεχόμενο και γενναιόδωρα ως προς την προστασία. Όποιος ορίζει σήμερα τι καταγράφεται και τι ποτέ, έχει σε περίπτωση ανάγκης αξιοποιήσιμα ίχνη και όχι μια πρόσθετη διαρροή δεδομένων.

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

Πηγές

• OWASP: Logging Cheat Sheet
• PHP-FIG: πρότυπα PSR
• Εγχειρίδιο της PHP
• OWASP Top 10