Шифрування електронної пошти: TLS, наскрізне шифрування та GDPR

Електронні листи часто порівнюють із листівкою: кожен, хто підслуховує по дорозі, бачить усе. Чи так це насправді, визначає шифрування електронної пошти. У статті описано, що дають транспортне та наскрізне шифрування, що про них сказали суди й наглядові органи та яка технологія на практиці вирішує справу.

У статті враховано судові рішення, технології та вимоги великих поштових провайдерів станом на кінець жовтня 2026 року.

Структура статті повторює шлях листа. Спочатку йдуть правовий стандарт і поняття, потім судова практика та позиція наглядових органів. Далі йдеться про технологію: транспортне шифрування, перевірку заголовка листа, захист від підроблених відправників і наскрізні методи, як-от S/MIME та OpenPGP. Наприкінці наведено підказку, яке шифрування підходить до якого типу листів.

Шифрування електронної пошти та GDPR: який стандарт застосовується

Персональні дані необхідно обробляти так, щоб вони були захищені від несанкціонованого доступу. Це передбачає ст. 5(1)(f) GDPR. Згідно з пунктом 2, контролер також має вміти це довести. Як саме має виглядати захист, регулює ст. 32 GDPR: слід вживати заходів відповідно до сучасного рівня техніки, співмірних ризику. Конкретний метод норма не встановлює. Шифрування названо там лише як можливий захід.

Особливі категорії даних, як-от дані про здоров'я, підпадають під ст. 9 GDPR. Там потреба в захисті від початку вища. Проте й на перший погляд безневинні листи містять персональні дані: достатньо вже адреси відправника з реальним іменем.

Правову ситуацію 2026 року можна підсумувати так: загального обов'язку наскрізного шифрування для кожного листа немає. Так само немає і загального дозволу на незашифровані листи. Вирішальними є ризик для постраждалих осіб і те, що можна вимагати з огляду на сучасний рівень техніки. Тому той, хто надсилає персональні дані електронною поштою, потребує обґрунтованого рішення, яке за потреби можна пред'явити.

Транспортне шифрування, наскрізне шифрування та підпис: чітке розмежування

У повсякденні змішують три речі, які роблять різне.

Транспортне шифрування захищає з'єднання між двома станціями. Воно працює на основі TLS (Transport Layer Security), наступника SSL. На кожній ділянці вміст передається в зашифрованому вигляді. На самому поштовому сервері він, навпаки, лежить відкритим текстом, адже сервер має обробити й зберегти лист.

Наскрізне шифрування (E2E) шифрує вміст уже в поштовій програмі відправника. Розшифрувати його може лише отримувач. Сервери посередині бачать лише дані, з якими нічого не можуть зробити. Для цього закріпилися S/MIME та OpenPGP.

Підпис є чимось іншим: він нічого не шифрує, а підтверджує, від кого походить лист і що його не змінено по дорозі. Під час обміну ключами він відіграє важливу роль, бо відкриті ключі здебільшого передають через підписані листи.

Обидва методи мають спільне обмеження: тема, відправник і отримувач, як правило, залишаються читабельними. Рекомендації Конференції із захисту даних (DSK) зазначають, що й ці обставини комунікації можуть потребувати захисту.

Судова практика щодо шифрування електронної пошти: коли вистачає транспортного шифрування

Суди кілька разів розглядали це питання в останні роки з уявно суперечливими результатами. При уважному погляді рішення йдуть однією лінією: що більша можлива шкода, то вищі вимоги.

Найстарша справа в цьому ряду датується 2020 роком. Адміністративний суд Майнца 17.12.2020 (справа № 1 K 778/19.MZ) вирішував, чи може адвокат надсилати клієнтам листи лише з транспортним шифруванням. Рішення розглянуто за ст. 32 і ст. 5 GDPR. У резолютивному принципі сказано, що для електронного листування адвокатів достатньо транспортного шифрування. Наскрізне шифрування за цим рішенням потрібне лише при підвищеному ризику в окремому випадку.

Також часто цитують, хоча й з обмеженнями щодо застосовності, ухвалу Федерального суду ФРН від 22.03.2021 (AnwZ (Brfg) 2/20). Вона стосується спеціальної електронної адвокатської скриньки. Її архітектура безпеки ґрунтується на власних апаратних модулях безпеки. Права на наскрізне шифрування там немає. На звичайні електронні листи це навряд чи можна перенести.

Справа Вищого земельного суду Карлсруе показує лінію ділового обігу. Хакер захопив поштову скриньку автодилера й надіслав покупцеві підроблений рахунок з іншим номером рахунку. Покупець заплатив на хибний рахунок. Суд 27.07.2023 (справа № 19 U 83/22) вирішив, що необхідні заходи захисту визначаються обґрунтованими очікуваннями безпеки ділових партнерів. Оплата шахраю не звільнила покупця від зобов'язання, і він мусив заплатити вдруге. Земельний суд Мосбаха як перша інстанція вирішив ще інакше.

Вищий земельний суд Шлезвіга у грудні 2024 року дійшов іншого результату. Тут також ішлося про підроблений рахунок, цього разу щодо споживача, на суму близько 15 000 євро. Згідно з пресрелізом суду, рахунок слід було надіслати з наскрізним шифруванням, оскільки хакерська атака є передбачуваним ризиком. Клієнт міг протиставити вимозі про оплату вимогу про відшкодування шкоди й не мусив платити вдруге. Суд допустив касацію, проте за його пресрелізом рішення все одно набуло законної сили. Оцінку цих рішень, зокрема рішення Адміністративного суду Дюссельдорфа від 02.04.2026 (29 K 7351/23), наведено в статті Заходи безпеки при надсиланні електронних листів.

Як це узгоджується? Вирішальними є, схоже, потреба в захисті та потенціал шкоди. Між підприємствами суди досі радше приймали стандартні заходи. Там, де споживач переказує велику суму на рахунок, який йому повідомив лише незахищений лист, вимагають більшого. Назва методу при цьому другорядна. Важливо, щоб захід справді знижував конкретний ризик. Відкритим, наприклад, залишається питання, чи достатньо згоди отримувача на слабше шифрування. Надійного рішення з цього приводу досі немає.

Рекомендації DSK і BSI: стандарт наглядових органів

Конференція незалежних органів нагляду за захистом даних (DSK) 27.05.2021 ухвалила рекомендації «Заходи захисту персональних даних при передаванні електронною поштою», редакція від 16.06.2021. Баварія проголосувала проти. Документ доступний публічно і чітко розмежовує випадки.

При звичайному ризику рекомендації вимагають обов'язкового транспортного шифрування за технічною настановою BSI TR-03108-1. При високому ризику контролери, як правило, мають застосовувати наскрізне шифрування та кваліфіковане транспортне шифрування, наприклад із DANE або DNSSEC. Професійна таємниця вважається ознакою високого ризику, яку слід перевіряти в кожному окремому випадку.

Штрафи за незашифровані листи трапляються рідко, наглядові органи діють менше санкціями, ніж документами на кшталт цього. Як критерій рекомендації проте мають вагу: у суперечках про підроблені рахунки обговорювали, чи можна залучати вказівки наглядових органів. Вищий земельний суд Карлсруе вважав їх у тій справі нерелевантними. Рекомендації не є обов'язковими. Проте той, хто відступає від них, має вміти це обґрунтувати.

BSI у TR-03108 описує безпечне передавання електронної пошти для провайдерів, зокрема сертифікацію. Для операторів поштових серверів це технічна планка. Додатково існує рекомендація TR-03182 щодо автентифікації електронної пошти.

Правильне транспортне шифрування: TLS 1.3, порт 465, MTA-STS і DANE

Поштові програми й сервери використовують кілька протоколів. SMTP (Simple Mail Transfer Protocol) застосовується з 1982 року й передає листи. ESMTP є розширеним варіантом. Скорочення в заголовку листа показують, що відбувалося на відповідній ділянці: ESMTPS означає, що погоджено TLS. ESMTPSA додатково означає, що відправник пройшов автентифікацію за іменем користувача й паролем.

Погодження відбувається двома шляхами. При неявному TLS з'єднання від початку зашифроване. Для надсилання пошти з програми за RFC 8314 передбачено порт 465, для отримання: IMAP через порт 993 або POP3 через порт 995. При STARTTLS з'єднання починається без шифрування, і лише потім обидві сторони домовляються про перехід. Цей крок можуть порушити зловмисники. Дослідження «Why TLS is better without STARTTLS» (USENIX Security 2021) описує атаки з пониженням рівня захисту та ін'єкцією. Тому неявний TLS вважається кращим вибором, навіть якщо порт 587 зі STARTTLS у багатьох місцях і далі пропонують паралельно.

Щодо версій: TLS 1.0 і 1.1 офіційно визнано застарілими з RFC 8996 (березень 2021). TLS 1.2 є нижньою межею, TLS 1.3 є метою, так само й у технічній настанові BSI TR-02102-2.

Проблема залишається між серверами. Там шифрування зазвичай працює через STARTTLS і часто є лише опортуністичним: якщо не вдається, з'єднання повертається до незашифрованого. Багато поштових серверів пропонують режим, який відхиляє доставлення, якщо TLS не встановлено. Це також, як правило, відбувається через STARTTLS і не є неявним TLS.

Дві методики закривають цю прогалину:

• MTA-STS (RFC 8461): домен отримувача публікує політику, що TLS із дійсним сертифікатом є обов'язковим. Сервери-відправники її дотримуються. DNSSEC не потрібен. Існують режими testing і enforce. Звіти про проблеми надає TLS-RPT.
• DANE: у DNS через запис TLSA визначається, який сертифікат використовує сервер отримувача. Для цього потрібен DNSSEC. DANE гарантує автентичність сервера отримувача проти пониження рівня захисту й атаки «людина посередині».

За даними Microsoft, для Exchange Online вхідний SMTP з DANE загальнодоступний з 22.10.2024, але за замовчуванням вимкнений. MTA-STS підтримується згідно з документацією Microsoft. Чи публікує власний домен такі політики, можна перевірити онлайн-інструментами, докладніше в наступному розділі.

Перевірка шифрування: читання заголовка листа й тестування сервера отримувача

Чи лист справді прийшов зашифрованим, видно із заголовка листа. У класичних версіях Outlook достатньо двічі клацнути лист, потім Файл, Властивості, поле «Заголовки інтернету». У новому Outlook і веб-пошті шлях інший. Меню змінюється залежно від версії, тому варто заглянути в довідку відповідної програми.

У заголовках цікаві рядки Received. Кожен сервер, що передає лист далі, додає один. Сучасні сервери вносять туди версію протоколу й метод, наприклад TLSv1.3 і TLS_AES_256_GCM_SHA384. Наведений нижче уривок відтворено, замість справжніх адрес використано заповнювачі.

Проте заголовок не є суцільним доказом у розумінні ст. 5(2). Він підтверджує лише ті ділянки, на яких сервер додав рядок. Де задіяні пересилання або шлюзи, залишається прогалина. Як елемент документації він усе ж придатний.

Перед надсиланням можна перевірити, що вміє сервер отримувача. CheckTLS опитує можливості без надсилання листа й показує, зокрема, чи пропонується TLS і чи існує запис TLSA для DANE. Результат «no TLSA» типовий для багатьох доменів. Сервіс internet.nl перевіряє STARTTLS, DANE, а також SPF, DKIM і DMARC. MTA-STS, згідно з документацією, в оцінку не входить.

При негативному результаті TLS допомагає повідомлення отримувачу. Як альтернативу можна розглянути портал або зашифроване вкладення, про що докладніше нижче. Для власного вебсайту й його заходів захисту перевірка вебсайтів на відповідність GDPR дає першу орієнтацію. Перевірки безпеки доменів, зокрема автентифікації електронної пошти, можна знайти в Web Security Checks.

SPF, DKIM і DMARC: захист від підроблених відправників

Шифрування захищає від прочитання, а не від підробки. Саме про це йшлося в справах про рахунки: зловмисник надсилає лист, що виглядає як від справжнього відправника, або використовує захоплену скриньку. Проти підроблених відправників допомагають три методики, що діють разом.

Тиск на впровадження останнім часом спричинили великі провайдери. Google і Yahoo з 01.02.2024 вимагають від усіх відправників, зокрема, SPF або DKIM, TLS і низького рівня спаму. Хто надсилає понад 5 000 листів на день на адреси Gmail, потребує SPF, DKIM і щонайменше політики DMARC. Microsoft запровадила схожі вимоги для відправників великих обсягів на Outlook.com, Hotmail і Live з 05.05.2025. Правила докладно викладено в документації Google.

Рекомендації DSK передбачають, що при отриманні перевіряються DKIM і DMARC. Тут окреслюється розвиток, повз який контролерам краще не проходити. Додаткові відомості про підроблені повідомлення дає стаття Електронна пошта, фішинг і достовірність електронних повідомлень. Про поводження з невідомими відправниками й вкладеннями є окрема стаття.

Наскрізне шифрування з S/MIME та OpenPGP: стан 2026 року

Хто хоче або мусить вийти за межі транспортного шифрування, має два усталені методи. Обидва шифрують вміст у поштовій програмі. Обидва потребують ключів, якими слід обмінятися заздалегідь. Рекомендації DSK називають наскрізне шифрування «найрішучішим захистом», бо воно захищає й дані у стані спокою.

S/MIME

S/MIME працює із сертифікатами, які видає центр сертифікації. Їх можна безпосередньо використовувати в Outlook, Apple Mail та багатьох інших програмах. Відкритий ключ отримувача відправник зазвичай отримує через підписаний лист, з якого можна взяти сертифікат.

У сертифікатах з 2021 року багато змінилося. Колишні класи від 1 до 4 застаріли. З 01.09.2023 діють Baseline Requirements форуму CA/Browser із чотирма типами, що розрізняються обсягом перевірки: Mailbox-, Organization-, Sponsor- та Individual-validated. Актуальний стан вимог публікує сам форум.

OpenPGP

OpenPGP працює без центрального центру сертифікації. Кожен створює власну пару ключів. Автентичність перевіряють за відбитками або засвідченням третіх осіб. DSK прямо наголошує, що саме лише розміщення ключа на сервері ключів не свідчить про його автентичність. Практичним є Web Key Directory, через який домен сам надає свої ключі. Вступ до підписування пропонує стаття Як підписувати й надсилати листи з PGP.

Стандарт змінився: RFC 9580 (липень 2024) замінює RFC 4880. Він приносить нові формати ключів, сучасні методи, як-от X25519 і Ed25519, та автентифіковане шифрування. Поряд із цим проєкт GnuPG підтримує з LibrePGP відмінну лінію. Це ускладнює ситуацію. Thunderbird використовує власну бібліотеку RNP замість GnuPG, а Mozilla документує проблеми з ключами, що мають ознаки, яких RNP не підтримує. Отже, ключі не завжди безперешкодно переходять між програмами.

Практика з Outlook і Thunderbird

На практиці часто видно різницю між роботою з одним і кількома обліковими записами. Плагін GpgOL із пакета Gpg4win можна налаштувати в Outlook, і він працює з одним обліковим записом. При кількох облікових записах, навпаки, при кожному надсиланні з'являється запит, а співвіднесення ключів може збитися. Для середовищ із багатьма обліковими записами це перешкода.

Нині доступна версія Gpg4win 5.1.1 (опублікована 23.09.2026), як показує сторінка проєкту. GpgOL працює в класичному Outlook. Чи й коли він підтримуватиме новий Outlook, за повідомленням на форумі GnuPG невідомо. У Thunderbird OpenPGP вбудовано з версії 78, додаткова програма не потрібна. Налаштування виконується в параметрах облікового запису в розділі «Наскрізне шифрування». Хто користується лише одним обліковим записом, швидко досягає мети.

BSI у грудні 2025 року дослідило дванадцять безкоштовних поштових програм. Згідно з пресрелізом, програми відрізняються підтримкою наскрізного шифрування. Функції безпеки часто не активні з коробки.

Побічним аспектом є атака Efail 2018 року. Вона використовувала активний HTML-вміст у листах, щоб передавати розшифровані тексти назовні. Як протидію розглядають актуальні програми та вимкнене відображення HTML у зашифрованих листах. Пояснення пропонує сторінка efail.de. Паніка недоречна, але приклад показує, що навіть добра криптографія може зазнати невдачі через реалізацію.

Портали, шлюзи й шифрування Microsoft як альтернативи

Найбільша перешкода для наскрізного шифрування — обмін ключами з кожним співрозмовником. Тому багато організацій покладаються на рішення, де зусилля лежать на відправнику.

• Шифрування на шлюзі: сервер у компанії бере на себе S/MIME або PGP. Захист тоді сягає шлюзу отримувача. У поштовій скриньці лист, залежно від налаштування, лежить розшифрованим. Питання довіри переходить до оператора шлюзу.
• Портал: лист містить лише повідомлення. Забирають повідомлення в браузері після входу. Рекомендації DSK також називають вебпортал шляхом комунікації з постраждалими особами.
• Microsoft Purview Message Encryption: можна використовувати в новому Outlook за відповідної ліцензії. Отримувачі поза Microsoft отримують інструкцію з відкриття. У тому самому повідомленні її не можна поєднати з S/MIME.
• Вкладення, захищене паролем: архів з AES-256, створений, наприклад, за допомогою 7-Zip, править за конверт. Пароль передають іншим каналом, наприклад телефоном (розрив носія). SMS як канал є спірним і його слід використовувати лише з обмеженнями.

Хто експлуатує шлюз або портал у постачальника послуг, зазвичай укладає для цього договір про обробку даних за ст. 28 GDPR. Ризики, пов'язані з Microsoft 365 для самого облікового запису, описує стаття про token spraying.

Оцінка тверезо-практична: хто уникає керування ключами, отримує з порталом або шлюзом практичний компроміс. Він поступається справжньому наскрізному шифруванню, але значно кращий за лист відкритим текстом із чутливим вмістом.

Постквантова криптографія в електронній пошті: що важливо вже сьогодні

Наскрізне шифрування має властивість, яку часто не помічають: досконалої прямої секретності (Perfect Forward Secrecy) у ньому за замовчуванням немає. DSK пише про це, що перехоплені листи можна зберігати й розшифрувати пізніше, якщо приватний ключ буде розкрито. З майбутніми квантовими комп'ютерами цей сценарій міг би настати й без втрати ключа.

Стандартизація триває. З RFC 9936 (березень 2026) існує стандарт для ML-KEM у CMS, основа для S/MIME. Для TLS 1.3 BSI TR-02102-2 передбачає гібридні методи, що поєднують класичні й постквантові. Для повсякдення з цього не випливає жодного примусу діяти. Проте хто надсилає вміст, який має лишатися конфіденційним і через 15 років, повинен тримати тему в полі зору.

Помилкове надсилання, витік даних і факс: межі шифрування

Недолік транспортного шифрування діє й донині: при хибній адресі отримувача воно не допомагає. Лист потрапляє зашифрованим на хибний сервер і лежить там відкритим текстом. При наскрізному шифруванні інакше, якщо лист адресовано передбаченому отримувачу. DSK прямо називає індивідуальну адресацію заходом.

Тому має значення організаційна частина. До неї належать вимкнене автозаповнення для чутливих отримувачів, принцип чотирьох очей для делікатного вмісту й перевірка адреси перед надсиланням. Чи слід повідомляти про помилкове надсилання як про витік даних, залежить від ризику й належить до окремої процедури.

Телефакс також фігурує в цій дискусії. Уповноважений із захисту даних і свободи інформації землі Бремен порівняв факс на сторінці з рекомендаціями з незашифрованими листами. Вищий адміністративний суд Нижньої Саксонії в Люнебурзі в ухвалі 2020 року (11 LA 104/19) вважав для особливо чутливих даних необхідною перевірку в окремому випадку.

Яке шифрування для якого листа: підказка для вибору

З рішень і настанов можна вивести практичне правило. Що вищі потенціал шкоди й потреба в конфіденційності, то радше слід розглядати наскрізне шифрування або портал. Для рахунків додатково діє: зміну банківських реквізитів підтверджують другим каналом, наприклад телефоном.

Таблиця слугує орієнтиром і не є юридичною консультацією. Оцінка ризику лежить на контролері й має бути задокументована. Допомагає коротка перевірка: яка найгірша реалістична шкода для постраждалих осіб? Наскільки вона ймовірна? Який захід помітно її знижує?

Висновок

Транспортне шифрування є обов'язковою програмою й при звичайному ризику за DSK та судовою практикою здебільшого достатнє, якщо його налаштовано послідовно й відповідно до сучасного рівня техніки. Сюди належать TLS 1.2 або краще 1.3, неявний TLS у поштовій програмі, а також MTA-STS чи DANE на стороні сервера. При високому ризику очікують наскрізного шифрування або рівноцінного рішення.

Шифрування електронної пошти лишається темою, що потребує зважування. Керування ключами виснажливе, портали є прагматичним компромісом, а проти шахрайства SPF, DKIM, DMARC і другий канал для платіжних даних допомагають щонайменше так само, як і криптографія.