Факторы защиты данных приложений и облачных вычислений
С увеличением количества ценных данных, хранящихся в облаке, тем более важно, что они надежно защищены. Сильные меры безопасности в отношении облачных сервисов данных, таких как iCloud, приносят пользу всем: конечным пользователям, поставщикам облачных услуг, таким как Apple, и экосистемным платформам, таким как Reincubate.
Механизмы защиты этих данных принимают различные формы, и Apple успешно использует их для реализации. В этой статье рассматривается ряд методов, которые они - и команда из Reincubate - использовали.
Храните меньше - если возможно
Во-первых, хранение меньше, а не больше окупается. Есть примеры этого, когда данные никогда не сохранялись в iCloud, например, когда данные распознавания лиц из фотографий не хранятся в библиотеке фотографий iCloud, а вместо этого кэшируются локально. Артефакты данных от Apple HealthKit, HomeKit и TouchID обрабатываются аналогично, как и данные распознавания лиц на экране блокировки Android. Конечно, это часто компромисс между удобством и ценностью синхронизации этих данных между устройствами. Некоторые системы используют частичный подход. Например, iMessage хранит ограниченный объем контента в облаке, но использует другие данные, которые напрямую синхронизируются между устройствами.
Системы безопасного обмена сообщениями, такие как Telegram или WhatsApp, используют совершенно другой подход. Поскольку никакие данные (или, по крайней мере, не очень) хранятся на их серверах, богатый набор данных должен быть включен в любую резервную копию устройства, чтобы пользователь мог иметь возможность полноценно выполнять резервное копирование и восстановление. Таким образом, для обеспечения безопасности поставщики приложений отмывают руки от управления этими данными и предоставляют их конечному пользователю, который может выбрать резервное копирование своих устройств локально или в облаке.
Таким образом, существует две крайности, и одна может противопоставить WhatsApp - с небольшим количеством в облаке и всем в резервной копии - с Facebook Messenger, который ничего не хранит в резервной копии устройства, поскольку он легко доступен в облаке, и должен Facebook, чтобы предоставить свой веб-интерфейс.
Здесь нет правильного решения, но стоит задуматься: для использования приложения, в котором хранятся эти данные, требуется, чтобы поставщик приложения управлял ими безопасно, часто пользователи не знают, что и как хранится. Использование приложения, которое не хранит данные централизованно, означает, что конечный пользователь должен взять на себя ответственность за безопасность своих собственных данных резервного копирования - если только он не оставит их для хранения в облаке своей платформы, как в случае с iCloud Backups и Google Android 7.0+ резервное копирование устройства.
Интересно, что, как и в приведенном ниже графике, некоторые производители приложений занимают обе крайности этой позиции. Приложение Snapchat хранит почти все свои данные в облаке, тогда как физическое расширение приложения - Spectacles - хранит все свои данные локально на устройстве.
Хотя Spectacles не получили широкого распространения, они совершенно небезопасны: удерживая кнопку «snap» в течение семи секунд, хакер может связать их с новым телефоном и получить любые незашифрованные снимки, которые были сохранены на них законным владельцем. Это резко контрастирует с принципами безопасности, принятыми для Apple Watch.
Сильное шифрование
Это подводит нас ко второму критическому методу: надежному шифрованию , в идеале с неполным хранением ключей. Если данные считаются слишком конфиденциальными для резервного копирования таким образом, чтобы к ним можно было получить доступ в случае разрушения или замены устройства, существуют другие методы, которые можно использовать. Требуя использования определенного устройства, функция « Секретные беседы » Facebook использует аппаратные идентификаторы для шифрования контента. Если устройство потеряно, контент становится практически безвозвратным.
В некоторых системах используется аналогичный метод, в котором можно создать токен для конкретного устройства, чтобы гарантировать, что только ограниченное количество устройств может одновременно получать доступ к контенту. Snapchat и WhatsApp используют разные варианты этого. При входе в Snapchat на устройстве, токен создается и используется совместно серверами Snapchat и устройством. Если один и тот же пользователь входит в систему на другом устройстве, будет создан новый токен, который заменит то, что было в облаке ранее, и вынудит первое устройство выйти из системы, поскольку оно не сможет расшифровать любые входящие сообщения. Существует очевидная уязвимость к этой технике при использовании в незащищенных системах, которая заключается в том, что токен может быть скопирован и использован в другом месте. Если нужен был аргумент о том, почему использование рутованного устройства Android или взломанного iOS - это ужасная идея, и это также объясняет, почему вряд ли в ближайшее время появится веб-клиент для Snapchat.
Потерять секретные сообщения Facebook потенциально одно, но некоторые данные очень чувствительны и очень ценны для их владельца. Это кажется нелогичным, но если личная ценность данных достаточно велика, они часто хранятся таким образом, что существует много потенциальных способов ее расшифровки или восстановления. Это обменивает безопасность с уменьшенной непрактичностью. Например, существует масса данных, связанных с учетными записями iCloud и Google, включая - в обоих случаях - некоторую форму распределенной облачной цепочки для ключей, в которой хранятся все пароли пользователя. Кроме того, продвижение Google своих учетных записей в качестве механизма аутентификации на других сайтах с OAuth означает, что безвозвратная потеря доступа к таким учетным записям будет горькой пилюлей.
Учитывая, что эти учетные записи считаются слишком ценными, чтобы с готовностью рисковать их постоянной потерей, используется промежуточное решение, когда данные хранятся в облаке, но зашифрованы токеном или паролем, который хранится только у пользователя и который не сохраняется. Вот почему, например, при входе в новую установку браузера Google Chrome облачные пароли недоступны, пока в браузер не будет введен дополнительный пароль синхронизации.
Распределение бремени шифрования
Тим Кук из Apple, который серьезно и принципиально прав в вопросах безопасности, подтвердил свою веру в эту технику только в прошлом году:
В течение многих лет мы использовали шифрование для защиты личных данных наших клиентов, потому что мы считаем, что это единственный способ сохранить их информацию в безопасности. Мы даже поставили эти данные за пределы нашей досягаемости, потому что считаем, что содержимое вашего iPhone не является нашим делом.
- Тим Кук в « Послании нашим клиентам »
Помимо всего прочего, это может помочь облачным провайдерам избежать раскрытия полных пользовательских данных правительственным субъектам. Если они вынуждены предоставить его с помощью ордера, они могут сделать это без непосредственного раскрытия данных пользователя, поскольку данные требуют дальнейшей расшифровки, что может быть сделано только с помощью ключа, который есть только у конечного пользователя.
Иногда, как в случае с многофакторной аутентификацией (MFA), двухфакторной аутентификацией (2FA) или двухэтапной проверкой (2SV), это означает, что дополнительный ключ может быть отправлен или сгенерирован только конкретным устройством. Банки и виртуальные частные сети часто используют устройства считывания физических карт или безопасные начальные генераторы , которые являются формами генераторов одноразовых паролей, основанных на времени (OTP или TOTP). И Google, и Apple предлагают простые MFA на основе SMS, а также полнофункциональные 2FA-системы, причем Google использует HOTP / OATH, а Apple является собственностью Apple .
Когда у силовых или правоохранительных органов (LEA) есть эти зашифрованные данные, но нет ключа конечного пользователя для их расшифровки, они могут попытаться перехватить их, используя мощные машины для проверки данных на соответствие автоматически угаданным паролям. IOS от Apple имеет здесь огромное преимущество перед Android от Google: поскольку Apple жестко контролирует оборудование на своих устройствах, они могут разрабатывать методы шифрования, которые могут быстро выполнять только их устройства, а другие устройства, такие как настольные компьютеры, работают медленно. Когда Reincubate стала первой в мире компанией, поддерживающей дешифрование данных из 10.2 , важно было не только то, что компания первой поняла, как работает 10.2, но и то, что мы были первыми, кто начал масштабировать быструю расшифровку хитрой техники Apple. Поскольку каждая попытка дешифрования на обычном оборудовании занимала несколько секунд , для хакеров или LEA было непрактично использовать грубую силу.
Безопасность через неизвестность
Было бы бесполезно пересмотреть эти методы, не рассмотрев одну из тех, в которых Apple особенно хороша: безопасность через неизвестность. Не публикуя общедоступные API-интерфейсы, подробную документацию и даже не передавая много информации об этих системах, компания может избежать предупреждения хакеров о возможных направлениях атак. Долгое время аргумент против неясности заключался в том, что раскрытие информации и Open Source приводили к лучшим результатам в области безопасности, но это было до открытия в 2014 году того, что OpenSSL - критическая библиотека безопасности с открытым исходным кодом, которую использует практически все, - была и почти всегда была принципиально небезопасной .
Пожалуйста, свяжитесь с нами, если вы хотите изучить способы работы с приложениями или облачными данными, или если вы хотите лучше понять динамику различных подходов.
