Коли посередині нікого немає
Шифрування того, що проходить через сервер, захищає вміст. Відсутність сервера посередині усуває це питання. Це не одне й те саме.
Дві людини, одна розмова
Коли двоє людей розмовляють віч-на-віч у кімнаті, ніхто інший не повинен обіцяти, що нічого не чув. Він не чув, бо його там не було. Коли двоє людей передають аркуш паперу з рук в руки, ніхто посередині не повинен клястися, що не читав його. Посередині нікого немає.
Більшість речей у повсякденному житті працюють саме так. Ми не підписуємо угоди про конфіденційність із повітрям, яке передає наш голос, або з папером, який ми тримаємо. Конфіденційність розмови не спирається на обіцянку посередника, тому що посередника немає. Це одна з найсильніших існуючих форм приватності: не тому, що хтось або щось поводиться добре, а тому, що цього когось або чогось немає.
Коли розмова переноситься в цифровий канал, це змінюється за замовчуванням. Звичайна модель така: двоє людей підключаються до сервера, сервер отримує повідомлення, шифрує його або зберігає в зашифрованому вигляді і доставляє одержувачу. Сервер знаходиться посередині. Сервер може бути чесним. Він може бути перевіреним. Він може працювати у сприятливій юрисдикції та за суворої політики конфіденційності. Усе це може бути правдою. Але сервер знаходиться посередині.
Різниця між шифруванням і незбиранням (друга частина)
У попередній статті цієї ж серії ми стверджували, що шифрування вмісту і незбирання метаданих — це не одне й те саме. Є ще один крок, який слід чітко сформулювати: шифрування того, що проходить через сервер, і відсутність сервера — це також не одне й те саме.
Перша модель — сервер посередині, контент зашифрований — захищає контент від оператора сервера, його обслуговуючого персоналу, від зовнішнього зловмисника, який може зламати систему. І це важливо. Але це не усуває сервер: він все ще там, обробляє метадані, піддається судовим запитам, правовому втручанню, політичному тиску або порушенню безпеки. Зрештою, це все ще точка, яка вимагає довіри до когось.
Друга модель, без сервера між двома кінцевими точками, не захищає зашифрований контент краще: якщо криптографія надійна, контент захищений в обох випадках. Змінюється саме питання: «що буде з сервером?» втрачає сенс, тому що немає сервера, про який можна було б запитати.
Довіра, відсутність і різниця між ними
Довіра може бути виправданою. Чесні компанії існують. Суворі аудитори існують. Сприятливі для користувача закони існують. Серйозні сервіси, які скрупульозно дотримуються всього вищезазначеного, існують. Довіра, коли вона надається оператору, який на неї заслуговує, не є поганим рішенням.
Але довіра, хоч би якою міцною вона була, залишається довірою. Це соціальне рішення, а не технічне. Компанія може змінити власника, в юрисдикції може змінитися уряд, завтра може надійти судовий ордер, наступного місяця може бути виявлена нова вразливість. Нічого з цього не відбувається через злий умисел: це відбувається, тому що оператор існує, а все, що існує, підвладне непередбачуваності світу.
Відсутність оператора не піддається цим самим обставинам. Судовий наказ не може вимагати даних від сервера, якого не існує. Зловмисник не може зламати сервер, якого не існує. Зміна в політики компанії не може вплинути на дані, яких ця компанія ніколи не мала. Ключова фраза проста: дані, яких не існує, неможливо втратити.
Про законний аргумент на боці сервера
Той, хто пропонує послугу професійного обміну повідомленнями з сервером посередині, зазвичай наводить три цілком слушні аргументи. По-перше, що сервер необхідний для гарантування доставки, коли одержувач перебуває в офлайні. По-друге, що шифрування вмісту надійне і тому оператор не може його прочитати. По-третє, що сервіс відповідає європей законодавству і що дані захищені законом.
Усі три аргументи вірні. Жоден з них не змінює суті справи. Це правда, що сервер дозволяє зберігати повідомлення для відкладеної доставки; також правда, що відкладена доставка може бути вирішена іншим шляхом, за допомогою протоколів прямого зв'язку між пристроями, вдосконаленими протягом десятиліть і діючими сьогодні. Це правда, що шифрування вмісту в транзиті є надійним у серйозних сервісах. І це правда, що європейське законодавство захищає користувачів більше, ніж у багатьох інших місцях.
Питання не в тому, чи є послуги з сервером посередині законними, ні в тому, чи є вони безпечними, ні в тому, чи захищають вони вміст. Вони можуть бути такими, є законними і зазвичай безпечними. Питання полягає в тому, що наявність сервера посередині — це архітектурний вибір, а не технічна необхідність. І кожен вибір має наслідки. Архітектура з сервером посередині неминуче створює суб'єкта, якому потрібно довіряти. Архітектура без сервера посередині — ні.
Що каже закон і що робить архітектура
Загальний регламент про захист даних (RGPD) не вимагає конкретної архітектурної моделі. Він вимагає результатів: мінімізації даних, обмеженої мети, захисту на стадії проектування та за замовчуванням, здатності продемонструвати відповідність. Сервіс із сервером посередині може відповідати всім цим вимогам. Сервіс без сервера посередині відповідає багатьом з них конструктивно, а не декларативно. Абсолютна мінімізація — не збирати нічого, що не є суворо необхідним для доставки повідомлення, — є тривіальною, коли немає сервера, який міг би щось збирати.
Для неконфіденційного повсякденного використання архітектура із сервером є цілком розумною, і довіра до серйозного оператора є прийнятним рішенням. Для інших цілей — тих, що пов'язані з регульованою професійною таємницею, деонтологічною відповідальністю, особливо чутливою інформацією — відсутність точки довіри є не розкішшю, а структурною перевагою.
Непотрібний свідок
Повернення до початкової кімнати допомагає закріпити ідею. Те, що ніхто не підслухав розмову, не залежить від того, що свідок поводився добре: це залежить від того, що свідка не було. Проміжний сервер може бути чесним, перевіреним, відповідати кожній статті GDPR, і все ж залишатися саме свідком. Для тих, хто має справу з професійною таємницею, дійсно важливе питання полягає не в тому, чи заслуговує цей свідок на довіру: а в тому, чи взагалі була потреба в його присутності в кімнаті.
Відповідь у більшості сучасних професійних сервісів обміну повідомленнями полягає в тому, що потреби не було — і тим не менш він там був.
Ця стаття завершує початковий цикл Cuadernos Lacre. Після розмови про шифрування, метадані та професійну таємницю ми доповнюємо архітектурну картину: шифрування вмісту і відсутність сервера посередині — це різні речі. Обидві можуть бути законними; лише одна усуває точку довіри.
Джерела та додаткова література
- Saltzer, J. H.; Reed, D. P.; Clark, D. D. — End-to-end arguments in system design, ACM TOCS, 1984. Основоположний текст принципу, згідно з яким гарантії системи повинні реалізовуватися на кінцях, а не в проміжному каналі.
- Регламент (ЄС) 2016/679, ст. 25 — захист даних на стадії проектування та за замовчуванням.
- Регламент (ЄС) 2016/679, ст. 5.1.c — принцип мінімізації даних.
- Schneier, B. — Data and Goliath: the hidden battles to collect your data and control your world (2015), W. W. Norton. Розділи про архітектури, які мінімізують збір даних за своєю конструкцією.