В декабре 2022 года Apple объявила о новых мощных средствах защиты данных. Из трех объявленных средств защиты, iMessage Contact Key Verification относится к Сообщениям, следовательно, выходит за рамки этого поста.
Поговорим о двух других.
Ключи Безопасности для Apple ID не имеют прямого влияния на Tact и его данные, но косвенно являются отличным способом повысить безопасность вашей учетной записи пользователя. Поскольку Tact использует вашу учетную запись iCloud, которая, в свою очередь, использует ваш Apple ID, рассмотрите возможность использования аппаратного ключа безопасности для дополнительной защиты.
Расширенная Защита Данных (ADP) для iCloud — самая интригующая из трех, и в оставшейся части этого поста будет обсуждаться, как она может повысить безопасность ваших данных в Tact и других приложениях на основе CloudKit.
Многобукв для Tact: ваши приватные(*закрытые) чаты Tact будут зашифрованы сквозным шифрованием, если все участники чата включили ADP в своих учетных записях.
Многобукв для любого приложения CloudKit: ваши записи в iCloud будут зашифрованы сквозным шифрованием при соблюдении определенных условий. Проверить часть из которых с вашей стороны у вас нет возможности.
Основы безопасности iCloud
Раньше в CloudKit безопасность данных сторонних приложений была загадкой. У Apple был ряд документов по безопасности платформы, но не было ясной и понятной политики или руководства.
С этим объявлением о защите данных Apple недавно опубликовала ряд документов, в которых более подробно обсуждается безопасность iCloud, в том числе безопасность сторонних приложений CloudKit:
Обзор безопасности iCloud
Обзор безопасности данных iCloud
В первом довольно четко указано, что все данные в iCloud, включая приложения Apple и сторонние приложения, теперь подпадают под одну из двух политик.
Стандартная защита данных (настройка по умолчанию): данные пользователя iCloud зашифрованы, ключи шифрования защищены в центрах обработки данных Apple, и Apple может помочь с восстановлением данных и учетной записи.
Расширенная защита данных для iCloud: дополнительный параметр, обеспечивающий самый высокий уровень безопасности облачных данных Apple. Если пользователь решает включить расширенную защиту данных, исключительный доступ к ключам шифрования для большей части своих данных iCloud сохраняют его доверенные устройства, тем самым защищая их (данные) с помощью сквозного шифрования.
В двух словах, данные в обоих случаях шифруются как при передаче, так и при хранении в центрах обработки данных iCloud. В первом случае у Apple есть доступ к ключам. Во втором случае их нет, а идет сквозное шифрование данных при соблюдении определенных условий.
Хранение зашифрованных данных в CloudKit
Если вы используете CloudKit для хранения данных вашего приложения в iCloud, вам необходимо обратить внимание на API encryptedValues в CKRecord. Это ваша единственная точка входа для хранения и получения зашифрованных значений, которые могут быть зашифрованы сквозным шифрованием с помощью Advanced Data Protection.
Есть три категории данных, о которых стоит подумать.
CKAsset-записи уже всегда зашифрованы.
CKReference-поля никогда не шифруются, так как серверу необходим доступ к ним для определения отношений между записями.
Для всех других типов данных: они шифруются, если для работы с ними вы используете API encryptedValues, а не устанавливаете их непосредственно в CKRecord.
При шифровании вы теряете некоторые функции. Как говорится в документации:
CloudKit не поддерживает индексы для зашифрованных полей. Не включайте зашифрованные поля в свои предикаты или дескрипторы сортировки при выборке записей с помощью CKQuery и CKQueryOperation.
Это довольно очевидно, но упомянуть стоит. Поскольку сервер больше не имеет доступа к содержимому полей, вы явно не сможете использовать их, чтобы делать запросы, поиск или сортировку.
Совместное использование
Совместное использование влияет на ADP и сквозное шифрование. В обзоре безопасности данных говорится:
Совместная работа iWork, функция «Общие альбомы» в программе «Фото» и совместное использование контента с «любым, у кого есть ссылка» не поддерживают Advanced Data Protection. Когда вы используете эти функции, ключи шифрования для общего контента безопасно загружаются в центры обработки данных Apple, чтобы iCloud мог облегчить совместную работу в режиме реального времени или обмен данными через Интернет.
Не совсем понятно, что означает «любой, у кого есть ссылка» для приложений CloudKit и CKShare. Я предполагаю, это означает, что publicPermission в CKShare является чем-то отличным от none: так и есть, раз любой может получить доступ к общей записи, просто открыв ее общий URL, даже если он предназначен только для чтения.
Когда ADP и сквозное шифрование применяются к значениям записи CloudKit?
Давайте теперь соберем все воедино и спросим: когда к данным в CKRecord применяется сквозное шифрование? Насколько я могу судить, должны быть соблюдены эти три условия.
Вы используете encryptedValues API и CKAsset для хранения данных, которые вы хотите защитить.
Если запись принадлежит к общей иерархии записей, publicPermission в CKShare, которое управляет общим доступом, имеет значение none.
У текущего пользователя, а в случае общей записи также и у всех остальных пользователей, в их учетной записи iCloud включен ADP.
Как разработчик, вы можете контролировать условия 1 и 2. Но вот в чем дело: во время выполнения рабочего цикла вашего приложения у вас нет способа узнать, выполнено ли условие 3. У вас нет возможности узнать, включен ли ADP для текущего пользователя или других участников CKShare в их учетной записи или нет.
Если бы у вас был способ проверить условие 3, вы могли бы отобразить красивый значок или что-то еще в своем приложении рядом с соответствующей CKRecord, чтобы указать, что все условия для сквозного шифрования были выполнены, а пользователь мог считать, что эти данные защищены. Но нет никакого способа это сделать, и не похоже на то, что такой способ появится в ближайшее время.
Мне было интересно сделать это для Tact, поэтому на недавней сессии Ask Apple я задал этот вопрос. И получил довольно четкий ответ:
Apple не предоставляет API для [проверки того, включен ли ADP у данного пользователя], потому что мы не хотим раскрывать выбор учетной записи пользователя другим пользователям.
Это вполне логично. Я полностью за то, чтобы не раскрывать выбор учетных записей пользователей. В то же время я думаю, что это обоснованная необходимость - предоставить пользователям уверенность в том, защищено ли что-то сквозным шифрованием, т.к. при выборе это может дать им понимание, какой информацией они готовы поделиться. Эти две цели (защита выбора учетных записей пользователей и информирование всех участников о том, применяется ли ADP к данной CKRecord) в настоящее время противоречат друг другу, и ясно, какую из них выбрала Apple. Я (и, полагаю, Apple тоже) не могу представить себе дизайн системы, который удовлетворял бы обеим целям. Пока так, как есть.
Вывод
Люди, интересующиеся Tact, иногда спрашивают меня о сквозном шифровании. До сих пор мне приходилось говорить, что у Tact его просто нет. Теперь я могу сказать, что он есть, если соблюдены вышеуказанные условия.
Любой протокол безопасности, включая сквозное шифрование, сложно реализовать правильно. У меня есть бесконечная уверенность в возможности Apple, чем в своей собственной, - делать это успешно. Я надеюсь, что они будут продолжать проводить независимые анализы и аудиты безопасности, что является общепринятой отраслевой практикой для таких систем, чтобы предоставить пользователям и разработчикам дополнительную уверенность в их реализации.
Поскольку у вас, как разработчика, нет доступа к выбору учетных записей пользователей, у вас нет возможности окончательно проинформировать своих пользователей о том, применяется ли ADP к данным, которые они хранят в вашей системе. Лучшее, что вы можете сделать сегодня, — это завершить свою часть уравнения, используя encryptedValues и CKAssets, и рассказать своим пользователям о включении ADP в их учетную запись, если они решат это сделать.
