Схема Мячина. Об утечке Яндекса и других

    Это копия сообщения из моего linked.in, потому что там неудобно читать.

    Итак, хотя никто этого не просил, предлагаю свой вариант, как не допустить утечки, подобной #Yandex. На заметку не только #DeliveryClub, но вообще всем (вот такой я самонадеянный и с распухшим эго).

    В чём проблема не только Яндекса, но 99,99999% фирм (и снова привет, кое-какой менеджер из кое-какой фирмы, ага) - они полагаются на то, что доступ к БД строго ограничен, а сотрудники - доверенные лица. Это, прошу прощения, говно. Никогда, никогда, НИКОГДА нельзя рассчитывать, что даже самый проверенный человек не станет "предателем".

    Вообще, у вас ещё после Сноудена в голове должно было щёлкнуть, что эта схема просто нерабочая. При том, что я поддерживаю Сноудена и то, что он сделал, но будь я его работодателем, у меня была бы иная позиция.

    Итак, нарушитель - это сотрудник компании с доступом к БД. От этого нарушителя и отталкиваемся. Предлагаемый мной подход будет защищать от этой модели, но не защитит от нарушитеЛЕЙ, которые целенаправленно будут менять работу сервера и принимать MR друг друга в мастер, когда цель этих мёрджей будет в сливе данных.

Что требуется

1. Курьер должен знать номер заказа, количество позиций заказа и адрес доставки + комментарии к доставке. Но не имени, ни телефона
2. Сервер должен знать телефон курьера, номер и точный состав заказа и ваш телефон. Но ни вашего адреса, ни имени.
   
   Уже здесь видно, что имя не нужно никому, не так ли? Это первый очевидный косяк - зачем вы вообще хранили имя?!
   
   
3. Администратор БД не должен получить доступ к номеру телефона, но должен получить к номеру заказа и данным курьера

Как это сделать

    Это общий подход и его можно модифицировать в деталях. Также я не оговариваю алгоритмы шифрования, длины ключей и всё такое. Это ПОДХОД. Но оговорю, что все ключи - уникальны для одного заказа, а не один на все заказы и что ключи хранятся отдельно от данных (впрочем, это очевидно).

1. Клиентское приложение сообщает, что будет формировать заказ
2. Сервер присылает клиентскому приложению свой ключ
3. Клиентское приложение в ответ даёт свой ключ серверу
4. Оба они генерируют общий секрет
5. Клиентское приложение отправляет заказ на сервер, зашифрованный общим секретом и в ответ получает номер заказа
   
   На этом этапе сервер знает состав заказа и его номер
   
   
6. Сервер связывается с рестораном и создаёт с ним пару ключей с общим секретом 
7. Сервер сообщает ресторану состав заказа, пошифрованный на этом секрете, а также номер заказа 
8. Сервер связывается с курьером и создаёт с ним пару ключей с общим секретом 
9. Сервер сообщает курьеру номер заказа, ресторан и количество позиций заказа, но не его состав
   
   На этом этапе ресторан знает номер заказа и его состав. При чём нумерация заказов для ресторана лучше пусть вообще не совпадает с номером клиента. Тогда утечка связки "номер у пользователя" и "состав" не позволит связать этот заказ с рестораном для типовых заказов. Потому что "бургер и кола" - слишком общий заказ
   
   Курьер знает номер заказа, с точки зрения ресторана, дабы его забрать. И знает количество позиций, но не состав заказа. Для него это просто коробки
   
   
10. И курьер, и ресторан, оба сообщают серверу, что заказ забрали
11. Сервер сообщает приложению пользователя о том, что курьер в пути
12. Приложения клиента и курьера, оба, отправляют на сервер ключи и тот пересылает их им обоим. Сам сервер, разумеется, ключей не сохраняет.
    
    Здесь первое узкое место и здесь возможен ТОЛЬКО целенаправленный саботаж - все разработчики сервиса должны будут друг друга покрывать, дабы сделать мёрдж в мастер, который заставит сервак сохранять ключи
    
    
13. Приложения курьера и клиента создают общий секрет
14. Клиент сообщает серверу свой физический адрес, пошифрованный секретом из пункта выше
    
15. Сервер не может его прочитать, т.к. у него нет секрета курьера и клиента. Он просто перешлёт некий блоб курьеру
16. Приложение курьера дешифрует данные и может прочитать адрес
17. Клиент, на общем с сервером секрете, шифрует номер телефона и сообщает его серверу
18. Для общения в чате с клиентом курьер использует их общий секрет. Сервер не знает об их переписке. В случае разбирательств клинет покажет скриншоты. А если всё хорошо, нефига читать чужие сообщения
19. Для телефонного звонка курьер звонит из приложения, а сервер проксирует звонок через себя. Верно и обратное - клиент к курьеру
    
    Итак, сейчас сервер знает номер телефона, номер заказа, состав заказа, телефон курьера и телефон клиента. Не знает имени и адреса.
    
    Курьер знает адрес, номер заказа, количество позиций заказа. Не знает состав заказа, имени и телефона клиента.
    
    Клиент знает номер заказа, состав. Не знает имени курьера, телефона курьера. Курьеры тоже люди и нефига их ФИО раскидывать туда-сюда.
    
    
20. Курьер доставляет заказ и сообщает об этом серверу 
21. Курьерское приложение уничтожает секрет пользователя и его адрес (который прочесть без секрета всё равно нельзя). Больше курьер не может общаться с пользователем никак. Любая связь только через Яндекс. И ЭТО ОЧЕНЬ ВАЖНО. Потому что таксисты любят писать после выполнения заказа девушкам. А иногда любят угрожать 
22. Клиент подтверждает получение заказа. Его приложение уничтожает секрет с курьером 
23. Сервер получает 2 подтверждения доставки 
24. Сервер уничтожает адрес пользователя и его номер телефона. Но сохраняет состав заказа и общий секрет на некоторый срок. Этот срок - это срок возможного обжалования заказа. Скажем, 24 часа
    

   На этом этапе у курьера нет ничего о пользователе и заказе. Наверное, только номер, чтобы, если что, ТП Яндекса могла сказать "была жалоба по заказу 210". У курьера остаётся общий с сервером секрет, чтобы номер заказа и количество позиций можно было считывать в установленные 24 часа

    У сервера есть общий с курьером секрет и секрет общий с клиентом. Остаётся инфа о составе заказа и его номер, остаётся инфа о связи с рестораном. Это нужно для разбирательств ошибок. У сервера нет адреса клиента, имени и телефона

    У клиента остаётся состав заказа, номер и общий с сервером ключ. Теперь жалобы он подписывает этим же ключом, дабы сервер мог удостовериться, что это реально тот же заказ, ведь он и жалоба на одном ключе.

    Через 24 часа у клиента вытирается общий секрет. Он продолжает видеть свой заказ и номер, но уже не может пожаловаться.

    Сервер также вытирает общий ключ с клиентом, а также уничтожает оставшиеся данные с заказом. Ну или не уничтожает, потому что это БД и дорого. Прочесть их нельзя из-за вытертого ключа.

Конечный результат

1. Никто никогда не знает имени
2. Курьер никогда не знает телефон и не может писать в личку после выполнения работы
3. Админ не может сдамить данные за полгода на сервере
4. Сиюминутный SELECT * FROM DOSTAVKA содержит минимальную информацию и каждый заказ пошифрован на своём ключе, который живёт в другой таблице. Это будет просто шифрованный мусор

    Если Яндекс, или Деливери, или кто угодно возьмёт в работу эту схему (не в этом виде, а подгонит под свои запросы, конечно), назовите её "схема Мячина". Я про это никогда не узнаю, никто у вас не будет знает, кто такой Мячин. Но я буду про себя думать, что кому-то когда-то смог помочь.