Ένα εταιρικό email μπορεί να περιέχει συμβάσεις, οικονομικά στοιχεία, πληροφορίες πελατών, προσωπικά δεδομένα ή άλλες εμπιστευτικές πληροφορίες. Το γεγονός όμως ότι ένα μήνυμα αποστέλλεται από έναν σύγχρονο email provider δεν σημαίνει ότι όλες οι μορφές κρυπτογράφησης προστατεύουν το ίδιο πράγμα.
Το Email Encryption μπορεί να αναφέρεται σε διαφορετικούς μηχανισμούς. Το TLS προστατεύει τη σύνδεση κατά τη μεταφορά ενός email μεταξύ συστημάτων, ενώ τεχνολογίες όπως το S/MIME μπορούν να εφαρμόσουν κρυπτογραφική προστασία στο ίδιο το περιεχόμενο του μηνύματος.
Για μια επιχείρηση, το σημαντικό είναι να καταλάβει από ποιον κίνδυνο θέλει να προστατεύσει το email και να επιλέξει το κατάλληλο επίπεδο προστασίας.
Τι σημαίνει κρυπτογράφηση Email;
Ο όρος μπορεί να περιγράφει περισσότερα από ένα επίπεδα προστασίας.
Στην πράξη πρέπει να ξεχωρίζουμε τουλάχιστον δύο διαφορετικές περιπτώσεις:
- Encryption in transit: προστατεύεται η δικτυακή σύνδεση μέσω της οποίας μεταφέρεται το email.
- Message-level encryption: εφαρμόζεται κρυπτογραφική προστασία στο ίδιο το μήνυμα ή στο περιεχόμενό του.
Η διάκριση είναι σημαντική επειδή ένα μήνυμα μπορεί να μεταδοθεί μέσω κρυπτογραφημένης σύνδεσης και στη συνέχεια να βρίσκεται σε mail systems ή mailboxes σε μορφή που μπορεί να επεξεργαστεί η αντίστοιχη υπηρεσία.
Τι είναι το TLS στο Email;
Το TLS — Transport Layer Security δημιουργεί κρυπτογραφημένο κανάλι επικοινωνίας μεταξύ συστημάτων.
Στο email χρησιμοποιείται, μεταξύ άλλων, κατά την SMTP επικοινωνία μεταξύ mail servers. Με το STARTTLS, δύο SMTP systems μπορούν να διαπραγματευτούν τη χρήση TLS πριν συνεχιστεί η μεταφορά του μηνύματος.
Αυτό μειώνει τον κίνδυνο παθητικής υποκλοπής της SMTP κίνησης κατά τη συγκεκριμένη σύνδεση.
Το TLS είναι End-to-End Encryption;
Όχι. Η χρήση TLS για SMTP transport δεν πρέπει να παρουσιάζεται ως end-to-end encryption του email.
Το TLS προστατεύει ένα transport connection. Ένα email όμως μπορεί να περάσει από περισσότερα συστήματα κατά τη διαδρομή του και τελικά να αποθηκευτεί στο mailbox του παραλήπτη.
Επομένως η ύπαρξη TLS κατά τη μεταφορά δεν σημαίνει από μόνη της ότι μόνο ο αρχικός αποστολέας και ο τελικός παραλήπτης μπορούν να έχουν πρόσβαση στο περιεχόμενο του μηνύματος.
Τι είναι το Opportunistic TLS;
Το SMTP σχεδιάστηκε σε εποχή όπου η κρυπτογράφηση δεν αποτελούσε υποχρεωτικό μέρος κάθε παράδοσης email. Το STARTTLS πρόσθεσε τη δυνατότητα αναβάθμισης μιας SMTP σύνδεσης σε TLS.
Σε ένα opportunistic μοντέλο, ένας sending mail server επιχειρεί να χρησιμοποιήσει TLS όταν ο receiving server το προσφέρει.
Η προσέγγιση αυτή αυξάνει σημαντικά την προστασία της καθημερινής email κίνησης, αλλά από μόνη της δεν εξαλείφει κάθε downgrade ή interception scenario. Αυτός είναι ένας από τους λόγους για τους οποίους δημιουργήθηκαν πρόσθετοι μηχανισμοί πολιτικής για SMTP TLS.
Τι είναι το MTA-STS;
Το MTA-STS — SMTP MTA Strict Transport Security επιτρέπει σε ένα email domain να δηλώσει ότι υποστηρίζει ασφαλείς SMTP συνδέσεις μέσω TLS και να δημοσιεύσει policy για το πώς πρέπει να αντιμετωπίζεται η παράδοση προς τους mail servers του.
Σύμφωνα με το RFC 8461, η πολιτική μπορεί να χρησιμοποιηθεί ώστε sending SMTP servers που την υποστηρίζουν να μην παραδίδουν το μήνυμα όταν οι απαιτήσεις TLS και certificate validation της policy δεν ικανοποιούνται.
Το MTA-STS βοηθά επομένως στην ενίσχυση της προστασίας του SMTP transport.
Δεν κρυπτογραφεί όμως end-to-end το περιεχόμενο του μηνύματος και δεν πρέπει να συγχέεται με S/MIME ή άλλες μορφές message-level protection.
Τι είναι το S/MIME;
Το S/MIME — Secure/Multipurpose Internet Mail Extensions είναι πρότυπο για την εφαρμογή cryptographic security services σε MIME email.
Το RFC 8551 ορίζει το S/MIME 4.0 και διαχωρίζει δύο ιδιαίτερα σημαντικές λειτουργίες:
- Encryption: παρέχει confidentiality του περιεχομένου.
- Digital signatures: παρέχουν authentication του αποστολέα, message integrity και proof of origin σύμφωνα με το μοντέλο του S/MIME.
Η κρυπτογράφηση και η ψηφιακή υπογραφή είναι διαφορετικές λειτουργίες. Ένα μήνυμα μπορεί, ανάλογα με την υλοποίηση και την ανάγκη, να υπογράφεται, να κρυπτογραφείται ή να χρησιμοποιεί συνδυασμό των δύο.
Πώς λειτουργεί η κρυπτογράφηση S/MIME;
Σε απλοποιημένη μορφή, για να στείλει κάποιος κρυπτογραφημένο S/MIME μήνυμα σε έναν παραλήπτη χρειάζεται πρόσβαση στο κατάλληλο public key του παραλήπτη.
Το RFC 8551 ορίζει ότι για το EnvelopedData, ο sender χρειάζεται public key για κάθε intended recipient ώστε να διανεμηθεί με ασφάλεια το κλειδί που χρησιμοποιείται για την προστασία του περιεχομένου.
Ο παραλήπτης χρησιμοποιεί το αντίστοιχο private-key material για την αποκρυπτογράφηση.
Αυτό δημιουργεί μια σημαντική επιχειρησιακή απαίτηση: το S/MIME δεν είναι απλώς ένα checkbox. Χρειάζεται σωστή διαχείριση certificates, public keys και private keys.
TLS και S/MIME: Ποια είναι η βασική διαφορά;
Η απλούστερη διάκριση είναι:
- TLS: προστατεύει τη σύνδεση μέσω της οποίας ταξιδεύει το email.
- S/MIME encryption: προστατεύει κρυπτογραφικά το ίδιο το MIME message για τους προβλεπόμενους παραλήπτες.
Δεν είναι επομένως ανταγωνιστικές τεχνολογίες που απαιτούν να επιλέξουμε υποχρεωτικά τη μία ή την άλλη.
Ένα S/MIME-encrypted μήνυμα μπορεί παράλληλα να μεταφέρεται μέσω TLS. Στην περίπτωση αυτή υπάρχουν διαφορετικά επίπεδα προστασίας για διαφορετικά σημεία της διαδρομής.
Πότε αρκεί η προστασία μέσω TLS;
Δεν υπάρχει μία απάντηση για κάθε επιχείρηση και κάθε μήνυμα.
Για συνηθισμένη εταιρική επικοινωνία, η ασφαλής μεταφορά μέσω σωστά διαμορφωμένων σύγχρονων email services μπορεί να αποτελεί σημαντικό μέρος της προστασίας.
Η απόφαση όμως πρέπει να βασίζεται στην ευαισθησία των πληροφοριών, στο ποιος πρέπει να μπορεί να τις διαβάσει, στους εμπλεκόμενους mail systems και σε τυχόν επιχειρηματικές, συμβατικές ή κανονιστικές απαιτήσεις.
Αν το requirement είναι απλώς να μην μεταδίδεται SMTP traffic σε μη προστατευμένο channel, τότε το πρόβλημα αφορά κυρίως transport security.
Αν το requirement είναι ισχυρότερο — για παράδειγμα το περιεχόμενο να είναι κρυπτογραφημένο για συγκεκριμένους παραλήπτες ανεξάρτητα από το SMTP transport — τότε χρειάζεται να εξεταστεί message-level protection.
Πότε μπορεί να χρειάζεται S/MIME;
Το S/MIME μπορεί να αξιολογηθεί όταν η επιχείρηση χρειάζεται cryptographic confidentiality ή digital signatures σε επίπεδο μηνύματος και μπορεί να υποστηρίξει την απαιτούμενη certificate infrastructure.
Ενδεικτικά use cases μπορεί να περιλαμβάνουν:
- ανταλλαγή ιδιαίτερα ευαίσθητων πληροφοριών μεταξύ συγκεκριμένων χρηστών ή οργανισμών,
- περιβάλλοντα όπου υπάρχει καθορισμένη απαίτηση για message-level encryption,
- επικοινωνία όπου απαιτούνται ψηφιακές υπογραφές για authentication και integrity,
- οργανισμούς που διαθέτουν ήδη κατάλληλο PKI και διαδικασίες certificate management.
Αυτό δεν σημαίνει ότι κάθε εμπιστευτικό email πρέπει υποχρεωτικά να χρησιμοποιεί S/MIME. Η κατάλληλη λύση εξαρτάται από το threat model, τις απαιτήσεις και την υπάρχουσα υποδομή.
Γιατί το Certificate Management είναι κρίσιμο;
Το S/MIME εξαρτάται από cryptographic keys και certificates. Αυτό σημαίνει ότι η επιχείρηση χρειάζεται διαδικασίες για ολόκληρο τον κύκλο ζωής τους.
Πρέπει να εξετάζονται θέματα όπως:
- πώς εκδίδονται certificates στους σωστούς χρήστες,
- πώς επιβεβαιώνεται ότι ένα public key ανήκει στον προβλεπόμενο παραλήπτη,
- πώς προστατεύονται τα private keys,
- τι συμβαίνει όταν ένα certificate λήξει ή αντικατασταθεί,
- τι συμβαίνει όταν ένας εργαζόμενος αποχωρήσει,
- πώς ανακαλείται ένα certificate όταν υπάρχει λόγος να μην θεωρείται πλέον έγκυρο,
- πώς αντιμετωπίζεται η ανάγκη πρόσβασης σε παλαιότερα κρυπτογραφημένα εταιρικά μηνύματα.
Ένα encryption deployment χωρίς key-lifecycle planning μπορεί να δημιουργήσει τόσο security όσο και business-continuity προβλήματα.
Τι γίνεται αν χαθεί το Private Key;
Αυτό είναι διαφορετικό πρόβλημα από το να ξεχάσει κάποιος ένα password.
Αν τα δεδομένα έχουν κρυπτογραφηθεί για συγκεκριμένο cryptographic key και το απαραίτητο private-key material χαθεί χωρίς κατάλληλο recovery mechanism, η επιχείρηση μπορεί να μην μπορεί να αποκρυπτογραφήσει παλαιότερο περιεχόμενο.
Για αυτό, πριν από ευρεία εφαρμογή message-level encryption, πρέπει να υπάρχει σαφής στρατηγική για key protection, recovery και business continuity σύμφωνα με τις ανάγκες του οργανισμού.
Digital Signature δεν σημαίνει Encryption
Ένα συχνό λάθος είναι να αντιμετωπίζονται η ψηφιακή υπογραφή και η κρυπτογράφηση ως το ίδιο πράγμα.
Στο S/MIME, η digital signature μπορεί να βοηθήσει τον παραλήπτη να επαληθεύσει τον signer και να διαπιστώσει αν το υπογεγραμμένο περιεχόμενο έχει αλλοιωθεί.
Η υπογραφή όμως δεν κάνει από μόνη της το περιεχόμενο μυστικό. Για confidentiality απαιτείται encryption.
Αντίστοιχα, ένα encrypted μήνυμα δεν πρέπει αυτομάτως να θεωρείται digitally signed. Οι δύο ιδιότητες πρέπει να αξιολογούνται ξεχωριστά.
Email Encryption δεν είναι SPF, DKIM ή DMARC
Οι τεχνολογίες αυτές λύνουν διαφορετικά προβλήματα.
Τα SPF, DKIM και DMARC σχετίζονται με email authentication και την αντιμετώπιση συγκεκριμένων μορφών domain spoofing. Δεν αποτελούν μηχανισμούς κρυπτογράφησης του περιεχομένου ενός email.
Μια επιχείρηση μπορεί επομένως να χρειάζεται τόσο σωστό email authentication όσο και κατάλληλη transport ή message-level protection.
Για το authentication layer δείτε τον οδηγό της DataShield για SPF, DKIM και DMARC για προστασία από spoofing.
Email Encryption δεν σταματά το Phishing ή το Malware
Η κρυπτογράφηση προστατεύει συγκεκριμένες ιδιότητες των δεδομένων και της επικοινωνίας. Δεν αποτελεί γενικό anti-phishing ή anti-malware control.
Ένα κακόβουλο email μπορεί να μεταδοθεί μέσω απολύτως έγκυρης TLS σύνδεσης. Αντίστοιχα, η ύπαρξη encryption δεν αποδεικνύει ότι το περιεχόμενο είναι ασφαλές.
Για αυτό το email environment εξακολουθεί να χρειάζεται controls για malicious attachments, URLs, impersonation, spam και άλλες απειλές.
Δείτε επίσης πώς λειτουργεί ένα Email Security Gateway για εταιρικό email.
Τι συμβαίνει αν παραβιαστεί ο λογαριασμός του χρήστη;
Η κρυπτογράφηση δεν πρέπει να αντιμετωπίζεται ως προστασία από κάθε μορφή account compromise.
Αν ένας attacker αποκτήσει πρόσβαση σε ενεργό mailbox, endpoint ή session με τα δικαιώματα του νόμιμου χρήστη, μπορεί σε ορισμένα σενάρια να αποκτήσει πρόσβαση σε πληροφορίες που το σύστημα αποκρυπτογραφεί κανονικά για τον συγκεκριμένο χρήστη.
Για αυτό το email encryption πρέπει να λειτουργεί μαζί με:
- ισχυρό authentication,
- MFA ή phishing-resistant authentication όπου είναι κατάλληλο,
- endpoint security,
- least privilege,
- monitoring και incident response.
Πρέπει να κρυπτογραφούνται όλα τα Email;
Η απάντηση εξαρτάται από το είδος της κρυπτογράφησης.
Η χρήση ασφαλούς transport encryption είναι διαφορετικό ζήτημα από την εφαρμογή message-level encryption σε κάθε μήνυμα.
Η καθολική εφαρμογή ισχυρών message-level restrictions χωρίς αξιολόγηση μπορεί να δημιουργήσει προβλήματα interoperability, certificate management, archiving, recovery και καθημερινής χρήσης.
Μια πιο πρακτική προσέγγιση είναι η επιχείρηση να γνωρίζει ποια δεδομένα είναι πραγματικά ευαίσθητα και ποιο protection requirement αντιστοιχεί σε κάθε περίπτωση.
Η ταξινόμηση των πληροφοριών μπορεί να αποτελέσει τη βάση αυτής της απόφασης.
Δείτε τον οδηγό της DataShield για το Data Classification και την προστασία εταιρικών δεδομένων.
Πρακτικό μοντέλο απόφασης για μια ΜΜΕ
Πριν επιλέξει τεχνολογία, μια επιχείρηση μπορεί να ξεκινήσει από τέσσερις ερωτήσεις:
- Τι πληροφορίες στέλνουμε; Είναι δημόσιες, εσωτερικές, εμπιστευτικές ή ιδιαίτερα ευαίσθητες;
- Από ποιον κίνδυνο θέλουμε να προστατευτούμε; Από υποκλοπή κατά τη μεταφορά, από πρόσβαση ενδιάμεσων συστημάτων ή από μη εξουσιοδοτημένη ανάγνωση από διαφορετικό recipient;
- Ποιος πρέπει να μπορεί να διαβάσει το μήνυμα; Αρκεί η ασφαλής παράδοση στον οργανισμό του παραλήπτη ή απαιτείται cryptographic protection για συγκεκριμένους recipients;
- Μπορούμε να διαχειριστούμε τη λύση; Υπάρχουν διαδικασίες για certificates, keys, recovery, offboarding και support;
Οι απαντήσεις βοηθούν να ξεχωρίσει η πραγματική security απαίτηση από την αόριστη απαίτηση «να είναι τα email κρυπτογραφημένα».
Checklist για Email Encryption
- Γνωρίζουμε αν οι εταιρικοί mail systems χρησιμοποιούν TLS για SMTP transport;
- Γνωρίζουμε τι συμβαίνει όταν δεν μπορεί να δημιουργηθεί η αναμενόμενη ασφαλής σύνδεση;
- Υπάρχει απαίτηση για αυστηρότερη transport-security policy μεταξύ mail systems;
- Έχουμε ξεχωρίσει transport encryption από message-level encryption;
- Έχουμε εντοπίσει ποια δεδομένα χρειάζονται ισχυρότερη προστασία;
- Υπάρχει πραγματικό requirement για S/MIME encryption ή digital signatures;
- Μπορούν οι αποστολείς να αποκτήσουν και να επαληθεύσουν τα κατάλληλα recipient certificates;
- Προστατεύονται τα private keys;
- Υπάρχει διαδικασία certificate renewal και revocation;
- Έχει σχεδιαστεί recovery για παλαιότερα κρυπτογραφημένα εταιρικά μηνύματα;
- Έχει δοκιμαστεί η επικοινωνία με εξωτερικούς συνεργάτες;
- Έχουν αξιολογηθεί archiving, eDiscovery ή άλλες επιχειρησιακές απαιτήσεις που ισχύουν στο συγκεκριμένο περιβάλλον;
Συχνά λάθη
«Έχουμε TLS, άρα έχουμε End-to-End Encryption»
Το TLS προστατεύει το transport channel. Δεν αποτελεί από μόνο του end-to-end encryption του περιεχομένου.
«Έχουμε SPF και DKIM, άρα το Email είναι κρυπτογραφημένο»
SPF, DKIM και DMARC εξυπηρετούν διαφορετικό σκοπό και δεν κρυπτογραφούν το περιεχόμενο του μηνύματος.
«Το S/MIME είναι απλώς μια ρύθμιση στο Email Client»
Η αξιόπιστη επιχειρηματική χρήση απαιτεί certificate και key lifecycle management, όχι μόνο ενεργοποίηση μιας επιλογής στο interface.
«Digital Signature και Encryption είναι το ίδιο»
Η υπογραφή εξυπηρετεί authentication και integrity. Η encryption λειτουργία εξυπηρετεί confidentiality. Μπορούν να χρησιμοποιούνται μαζί, αλλά παραμένουν διαφορετικές λειτουργίες.
«Αν το Email είναι κρυπτογραφημένο, είναι ασφαλές»
Ένα μήνυμα μπορεί να είναι κρυπτογραφημένο και ταυτόχρονα κακόβουλο. Επίσης ένας παραβιασμένος λογαριασμός ή endpoint μπορεί να δημιουργήσει κινδύνους που δεν αντιμετωπίζονται μόνο με encryption.
Πώς μπορεί να βοηθήσει η DataShield
Η σωστή προστασία εταιρικού email ξεκινά από τις πραγματικές απαιτήσεις της επιχείρησης και όχι από την ενεργοποίηση όσο το δυνατόν περισσότερων security features.
Η DataShield μπορεί να αξιολογήσει την υπάρχουσα email υποδομή, τις ανάγκες προστασίας ευαίσθητων πληροφοριών και τα υπόλοιπα email-security controls και να βοηθήσει στον σχεδιασμό κατάλληλης προσέγγισης για transport security, authentication και προστασία ευαίσθητης επικοινωνίας.
Συμπέρασμα
Δεν υπάρχει μία τεχνολογία που να καλύπτει κάθε έννοια του «κρυπτογραφημένου email».
Το TLS προστατεύει τη σύνδεση κατά τη μεταφορά. Το MTA-STS μπορεί να ενισχύσει την πολιτική TLS για SMTP delivery. Το S/MIME μπορεί να παρέχει confidentiality σε επίπεδο μηνύματος και, μέσω digital signatures, authentication και integrity.
Η σωστή επιλογή εξαρτάται από το ποια δεδομένα αποστέλλονται, ποιος πρέπει να μπορεί να τα διαβάσει, ποιο threat model αντιμετωπίζει η επιχείρηση και αν μπορεί να υποστηρίξει με ασφάλεια τη διαχείριση certificates και keys.
