Как стать автором
Обновить

Сквозное шифрование в облаках. Уязвимости — во всех сервисах

Время на прочтение3 мин
Количество просмотров6.1K
Всего голосов 6: ↑6 и ↓0+9
Комментарии12

Комментарии 12

ещё можно Duplicati

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

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

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

А если речь о том, что проанализированный софт используется какими-то публичными облаками, - так ему не надо никаких уязвимостей содержать, злонамеренный администратор публичного облака что угодно изменит/перехватит/подменит/пр. сам.

Ну т.е. в целом на определённые мысли всё это навело, что мне в своём Seafile ещё надо бы помониторить дополнительно, - но ничего такого катастрофического, чтобы говорить, что прямо всё сломано, я не увидел.

По-моему это не про частные хранилища. Пробежал по ссылкам - вижу опцию self-hosting у Nextcloud, и у Seafile конечно открытый код можно у себя хостить. У остальных кажется только в их облаке, а если есть открытый код - то только клиентов.

Мне как раз из всего списка были знакомы Nextcloud и Seafile, последний сам использую. Глянул, да, другие действительно - публичные облака. Тогда вообще не понимаю, ни зачем совершенно разные решения сваливать в одну кучу, ни как оценивались сценарии атак для публичных облаков, серверная часть которых для нас - чёрный ящик.

В любом случае, использование публичного облака - это вопрос доверия и оценки регуляторных рисков в большей степени, чем технических. Если не нужны функции общего доступа, делегирования, централизованного бекапа и восстановления и т.п. - можно шифровать локально (не средствами ПО публичного облака, а сторонними программами). Если нужны - или селф-хостим всё это счастье, или выбираем по принципу "компанию X вряд ли взломают, они точно не будут рисковать своей репутацией ради такой мелочёвки как я, и в текущей политической ситуации вряд ли выдадут данные по запросам из той страны, где я веду деятельность" - и надеемся, что угадали :)

Так смысл правильного сквозного шифрования - оно позволяет пользоваться публичным облаком, не доверяя ему. Мне должно быть плевать что у них за серверная часть, и какие там риски (кроме конечно потери данных) - клиентское шифрование не должно давать серверу, чтобы там не происходило, узнать много больше чем самая общая метадата - примерные объемы файлов, число пользователей и так далее, или подделать файлы.

Как в мессенжерах с e2e, никто не выкладывает серверную часть, но валидация клиентской части позволяет проверить, что может а что не может сделать сервер.

Статья годная - как раз сделали валидацию клиентской части, нашли интересные и часто не тривиальные проблемы.

При оперсорсной клиентской части - ещё допустим, но и то там нужен очень нетривиальный анализ всех исходников (и уверенность, что бинарники, которые 99,999% пользователей скачают готовые, а не будут собирать сами, собраны из тех самых исходников).

Но я так понимаю, у публичных облаков из перечня исследованных и клиентские программы закрытые. И как бы они там хитроумно ни реализовывали E2EE, что в этом толку, если где-то параллельно приватный ключик пользователя утекает на сервер (не обязательно прямо всегда, а, скажем, только при получении от сервера запроса - так что анализом трафика тоже не выявить).

А если мы предполагаем, что со стороны сервера до наших E2E-зашифрованных данных хотят недобросовестно дотянуться - то очевидно, что такому недобросовестному, и при этом закрытому публичному облаку проще именно такой бэкдор и внедрить, чем извращаться с подменой данных, брутфорсом слабых шифров и т.п. по схемам, описанным в статье. К тому же, именно к такому решению его с определённой степенью настойчивости могут подталкивать регулирующие органы соответствующей юрисдикции...

и взрослые вроде люди... зачем разбирать сказки?

галочка на UI - это просто галочка. шифруйте сами локально. только так.

Они все шифруют локально. Они все делают при этом ошибки, раскрывающие часть информации и/или позволяющие серверу подменить часть информации (несмотря не шифрование).

Речь о том, что шифровать локально надо не средствами ПО облачного провайдера, а сторонним ПО (в первом же комменте предложили вариант, но их много, скажем у rclone есть бэкенд crypt, который можно в цепочку перед любым облаком поставить).

Но тогда теряются все возможности по общему доступу и централизованному администрированию, выше в комменте написал подробнее.

Не вижу двух пунктов:

  • Seafile в режиме когда мы доверяем админу (потому что он - свой, вариант с установкой на своем сервере) но при этом не доверяем провайдеру и прочим. Нафиг (да вообщем то и Nextcloud) использовать как публичное облачное решение? Уж лучше Dropbox (ну или яндекс диск если прям нужно импортозамещенное решение) :)

  • Proton Drive

Зарегистрируйтесь на Хабре, чтобы оставить комментарий