По мере того как в облаке хранится всё больше ценных данных, их надёжная защита становится всё важнее. Строгие меры безопасности вокруг облачных служб данных, таких как iCloud, выгодны всем: конечным пользователям, поставщикам облачных услуг вроде Apple и платформам экосистемы вроде Reincubate.
Механизмы защиты этих данных бывают разными, и у Apple хороший опыт их внедрения. В этой статье рассматриваются некоторые приёмы, которые используют они и команда Reincubate.
Хранить меньше — если возможно
Во-первых, лучше хранить меньше, чем больше. Есть примеры, когда данные вообще никогда не хранятся в iCloud: например, данные распознавания лиц из Фото не хранятся в медиатеке iCloud, а кэшируются локально. Так же обрабатываются данные Apple HealthKit, HomeKit и TouchID, а также данные распознавания лица для экрана блокировки Android. Конечно, это часто компромисс между удобством и ценностью синхронизации этих данных между устройствами. Некоторые системы применяют частичный подход. Например, iMessage хранит в облаке ограниченный объём содержимого, но рассчитывает, что остальные данные синхронизируются напрямую между устройствами.
Защищённые системы обмена сообщениями, такие как Telegram или WhatsApp, выбирают совершенно иной подход. Поскольку на их серверах не хранится никаких данных (или хотя бы почти никаких), в любую резервную копию устройства нужно включить богатый набор данных, чтобы пользователь мог осмысленно создавать резервные копии и восстанавливать данные. В некотором смысле, чтобы сохранить безопасность, разработчики этих приложений умывают руки и оставляют управление данными конечному пользователю, который может хранить резервные копии устройств локально или в облаке.
Так что есть две крайности: можно сопоставить WhatsApp — где в облаке почти ничего нет, а всё находится в резервной копии, — и Facebook Messenger, который не хранит ничего в резервной копии устройства, потому что всё доступно в облаке, и так должно быть, чтобы Facebook мог предоставлять веб-интерфейс.
Единственно правильного решения здесь нет, но об этом стоит подумать: использование приложения, которое хранит эти данные, требует, чтобы его разработчик безопасно ими управлял, причём пользователи часто остаются в неведении о том, что и как хранится. Использование приложения, которое не хранит данные централизованно, означает, что конечный пользователь должен сам отвечать за безопасность своих резервных копий — если только он не оставляет их храниться в облаке своей платформы, как в случае резервных копий iCloud и резервных копий устройств Google на Android 7.0+.
Интересно, что, как показано на диаграмме ниже, некоторые разработчики приложений занимают обе крайние позиции. Приложение Snapchat хранит почти все данные в облаке, тогда как физическое продолжение приложения — Spectacles — хранит все данные локально на устройстве.
Разные подходы к защите данных приложений
Хотя Snapchat Spectacles не получили широкого распространения, они довольно небезопасны: если удерживать кнопку «snap» семь секунд, хакер может подключить их к новому телефону и получить любые незашифрованные снэпы, которые законный владелец на них сохранил. Это резко контрастирует с принципами безопасности, принятыми для Apple Watch.
Надёжное шифрование
Это подводит нас ко второму ключевому приёму: надёжному шифрованию, в идеале с неполным хранением ключей. Если данные сочтены слишком чувствительными, чтобы создавать их резервную копию, доступную после уничтожения или замены устройства, можно применять другие приёмы. Требуя использования конкретного устройства, функция Facebook «Secret Conversations» использует аппаратные идентификаторы для шифрования содержимого. Если устройство потеряно, содержимое практически невозможно восстановить.
Некоторые системы применяют похожий приём: создаётся токен, привязанный к устройству, чтобы одновременно получать доступ к содержимому могло лишь ограниченное число устройств. Snapchat и WhatsApp используют разные его варианты. При входе в Snapchat на устройстве создаётся токен, который делят между собой серверы Snapchat и устройство. Если тот же пользователь входит на другом устройстве, создаётся новый токен, заменяющий прежний в облаке, и первое устройство вынужденно выходит из системы, так как не может расшифровывать входящие сообщения. У этого приёма есть очевидная уязвимость в небезопасных системах: токен можно скопировать и использовать в другом месте. Если нужен аргумент, почему использовать Android с root-доступом или iOS-устройство с джейлбрейком — ужасная идея, то вот он, и он же объясняет, почему веб-клиент для Snapchat вряд ли появится в ближайшее время.
Одно дело — потенциально потерять секретные сообщения Facebook, но некоторые данные одновременно очень чувствительны и очень ценны для владельца. Это кажется нелогичным, но если личная ценность данных достаточно велика, их часто хранят так, чтобы существовало много возможных способов расшифровать или восстановить их. Это обменивает безопасность на меньшую непрактичность. Например, с учётными записями iCloud и Google связано множество данных, включая — в обоих случаях — ту или иную форму распределённой облачной связки ключей, в которой хранятся все пароли пользователя. Более того, поскольку Google продвигает свои учётные записи как механизм аутентификации на других сайтах через OAuth, безвозвратная потеря доступа к таким учётным записям стала бы горькой пилюлей.
Поскольку эти учётные записи считаются слишком ценными, чтобы легко рисковать их окончательной потерей, применяется промежуточное решение: данные хранятся в облаке, но зашифрованы токеном или паролем, который хранит только пользователь и который нигде не сохраняется. Поэтому, например, при входе в только что установленный браузер Google Chrome пароли, хранящиеся в облаке, недоступны, пока в браузере не введён дополнительный пароль синхронизации.
Разделение бремени шифрования
Тим Кук из Apple — человек серьёзный и принципиально правый в вопросах безопасности — подтвердил приверженность этому приёму всего год назад:
For many years, we have used encryption to protect our customers’ personal data because we believe it’s the only way to keep their information safe. We have even put that data out of our own reach, because we believe the contents of your iPhone are none of our business.
— Tim Cook in “A Message to Our Customers”
Помимо прочего, это помогает поставщикам облачных услуг не раскрывать государственным органам полные данные пользователей. Если их обязывает предоставить данные судебный ордер, они могут сделать это, не раскрывая данные пользователя напрямую: для дальнейшей расшифровки нужен ключ, который есть только у конечного пользователя.
Иногда, как в случае многофакторной аутентификации (MFA), двухфакторной аутентификации (2FA) или двухэтапной проверки (2SV), это означает, что дополнительный ключ можно отправить только на определённое устройство или сгенерировать только на нём. Банки и VPN часто используют физические считыватели карт или защищённые генераторы начальных значений — формы генераторов одноразовых паролей по времени (OTP или TOTP). И Google, и Apple предлагают простую MFA на основе SMS, а также полноценные системы 2FA: у Google это HOTP/OATH, а у Apple — собственная разработка.
Когда у служб безопасности или правоохранительных органов есть эти зашифрованные данные, но нет пользовательского ключа для их расшифровки, они могут попытаться подобрать его перебором на мощных машинах, проверяя данные на автоматически подбираемых паролях. Здесь у Apple iOS огромное преимущество перед Google Android: поскольку Apple жёстко контролирует оборудование своих устройств, она может разрабатывать приёмы шифрования, которые быстро выполняет только её оборудование, а другие устройства, например настольные компьютеры, — медленно. Когда Reincubate стала первой компанией в мире, поддержавшей расшифровку данных из 10.2, значение имело не только то, что компания первой поняла, как работает 10.2, — мы первыми масштабировали быструю расшифровку по хитрому приёму Apple. Поскольку каждая попытка расшифровки занимает на обычном оборудовании несколько секунд, перебор становится нецелесообразным для хакеров и правоохранительных органов.
Безопасность через неясность
Было бы неправильно рассматривать эти приёмы и не затронуть тот, в котором Apple особенно сильна: безопасность через неясность. Не публикуя открытые API, подробную документацию и даже не рассказывая много об этих системах, компания может не привлекать внимание хакеров к потенциальным векторам атак. Долгое время главным аргументом против неясности было то, что раскрытие информации и открытый исходный код ведут к более высокой безопасности, но это было до 2014 года, когда выяснилось, что OpenSSL — критически важная библиотека безопасности с открытым исходным кодом, которой пользуется практически всё, — была и почти всегда оставалась принципиально небезопасной.
Свяжитесь с нами, если хотите изучить способы работы с данными приложений или облака или если вам интересно лучше понять динамику разных подходов.
