Это копия сообщения из моего linked.in, потому что там неудобно читать.
Итак, хотя никто этого не просил, предлагаю свой вариант, как не допустить утечки, подобной #Yandex. На заметку не только #DeliveryClub, но вообще всем (вот такой я самонадеянный и с распухшим эго).
В чём проблема не только Яндекса, но 99,99999% фирм (и снова привет, кое-какой менеджер из кое-какой фирмы, ага) - они полагаются на то, что доступ к БД строго ограничен, а сотрудники - доверенные лица. Это, прошу прощения, говно. Никогда, никогда, НИКОГДА нельзя рассчитывать, что даже самый проверенный человек не станет "предателем".
Вообще, у вас ещё после Сноудена в голове должно было щёлкнуть, что эта схема просто нерабочая. При том, что я поддерживаю Сноудена и то, что он сделал, но будь я его работодателем, у меня была бы иная позиция.
Итак, нарушитель - это сотрудник компании с доступом к БД. От этого нарушителя и отталкиваемся. Предлагаемый мной подход будет защищать от этой модели, но не защитит от нарушитеЛЕЙ, которые целенаправленно будут менять работу сервера и принимать MR друг друга в мастер, когда цель этих мёрджей будет в сливе данных.
Что требуется
- Курьер должен знать номер заказа, количество позиций заказа и адрес доставки + комментарии к доставке. Но не имени, ни телефона
- Сервер должен знать телефон курьера, номер и точный состав заказа и ваш телефон. Но ни вашего адреса, ни имени.
Уже здесь видно, что имя не нужно никому, не так ли? Это первый очевидный косяк - зачем вы вообще хранили имя?!
- Администратор БД не должен получить доступ к номеру телефона, но должен получить к номеру заказа и данным курьера
Как это сделать
Это общий подход и его можно модифицировать в деталях. Также я не оговариваю алгоритмы шифрования, длины ключей и всё такое. Это ПОДХОД. Но оговорю, что все ключи - уникальны для одного заказа, а не один на все заказы и что ключи хранятся отдельно от данных (впрочем, это очевидно).
- Клиентское приложение сообщает, что будет формировать заказ
- Сервер присылает клиентскому приложению свой ключ
- Клиентское приложение в ответ даёт свой ключ серверу
- Оба они генерируют общий секрет
- Клиентское приложение отправляет заказ на сервер, зашифрованный общим секретом и в ответ получает номер заказа
На этом этапе сервер знает состав заказа и его номер
- Сервер связывается с рестораном и создаёт с ним пару ключей с общим секретом
- Сервер сообщает ресторану состав заказа, пошифрованный на этом секрете, а также номер заказа
- Сервер связывается с курьером и создаёт с ним пару ключей с общим секретом
- Сервер сообщает курьеру номер заказа, ресторан и количество позиций заказа, но не его состав
На
этом этапе ресторан знает номер заказа и его состав. При чём нумерация
заказов для ресторана лучше пусть вообще не совпадает с номером клиента.
Тогда утечка связки "номер у пользователя" и "состав" не позволит
связать этот заказ с рестораном для типовых заказов. Потому что "бургер и
кола" - слишком общий заказ
Курьер
знает номер заказа, с точки зрения ресторана, дабы его забрать. И знает
количество позиций, но не состав заказа. Для него это просто коробки
- И курьер, и ресторан, оба сообщают серверу, что заказ забрали
- Сервер сообщает приложению пользователя о том, что курьер в пути
- Приложения клиента и курьера, оба, отправляют на сервер ключи и тот пересылает их им обоим. Сам сервер, разумеется, ключей не сохраняет.
Здесь первое узкое место и здесь возможен ТОЛЬКО целенаправленный саботаж - все разработчики сервиса должны будут друг друга покрывать, дабы сделать мёрдж в мастер, который заставит сервак сохранять ключи
- Приложения курьера и клиента создают общий секрет
- Клиент сообщает серверу свой физический адрес, пошифрованный секретом из пункта выше
- Сервер не может его прочитать, т.к. у него нет секрета курьера и клиента. Он просто перешлёт некий блоб курьеру
- Приложение курьера дешифрует данные и может прочитать адрес
- Клиент, на общем с сервером секрете, шифрует номер телефона и сообщает его серверу
- Для общения в чате с клиентом курьер использует их общий секрет. Сервер не знает об их переписке. В случае разбирательств клинет покажет скриншоты. А если всё хорошо, нефига читать чужие сообщения
- Для телефонного звонка курьер звонит из приложения, а сервер проксирует звонок через себя. Верно и обратное - клиент к курьеру
Итак,
сейчас сервер знает номер телефона, номер заказа, состав заказа, телефон
курьера и телефон клиента. Не знает имени и адреса.
Курьер знает адрес, номер заказа, количество позиций заказа. Не знает состав заказа, имени и телефона клиента.
Клиент
знает номер заказа, состав. Не знает имени курьера, телефона курьера.
Курьеры тоже люди и нефига их ФИО раскидывать туда-сюда.
- Курьер доставляет заказ и сообщает об этом серверу
- Курьерское приложение уничтожает секрет пользователя и его адрес
(который прочесть без секрета всё равно нельзя). Больше курьер не может
общаться с пользователем никак. Любая связь только через Яндекс. И ЭТО
ОЧЕНЬ ВАЖНО. Потому что таксисты любят писать после выполнения заказа
девушкам. А иногда любят угрожать
- Клиент подтверждает получение заказа. Его приложение уничтожает секрет с курьером
- Сервер получает 2 подтверждения доставки
- Сервер уничтожает адрес пользователя и его номер телефона. Но сохраняет
состав заказа и общий секрет на некоторый срок. Этот срок - это срок
возможного обжалования заказа. Скажем, 24 часа
На этом этапе у
курьера нет ничего о пользователе и заказе. Наверное, только номер,
чтобы, если что, ТП Яндекса могла сказать "была жалоба по заказу 210". У
курьера остаётся общий с сервером секрет, чтобы номер заказа и
количество позиций можно было считывать в установленные 24 часа
У
сервера есть общий с курьером секрет и секрет общий с клиентом.
Остаётся инфа о составе заказа и его номер, остаётся инфа о связи с
рестораном. Это нужно для разбирательств ошибок. У сервера нет адреса
клиента, имени и телефона
У
клиента остаётся состав заказа, номер и общий с сервером ключ. Теперь
жалобы он подписывает этим же ключом, дабы сервер мог удостовериться,
что это реально тот же заказ, ведь он и жалоба на одном ключе.
Через 24 часа у клиента вытирается общий секрет. Он продолжает видеть свой заказ и номер, но уже не может пожаловаться.
Сервер
также вытирает общий ключ с клиентом, а также уничтожает оставшиеся
данные с заказом. Ну или не уничтожает, потому что это БД и дорого.
Прочесть их нельзя из-за вытертого ключа.
Конечный результат
- Никто никогда не знает имени
- Курьер никогда не знает телефон и не может писать в личку после выполнения работы
- Админ не может сдамить данные за полгода на сервере
- Сиюминутный SELECT * FROM DOSTAVKA содержит минимальную информацию и
каждый заказ пошифрован на своём ключе, который живёт в другой таблице.
Это будет просто шифрованный мусор
Если Яндекс, или Деливери, или
кто угодно возьмёт в работу эту схему (не в этом виде, а подгонит под
свои запросы, конечно), назовите её "схема Мячина". Я про это никогда не
узнаю, никто у вас не будет знает, кто такой Мячин. Но я буду про себя
думать, что кому-то когда-то смог помочь.
