О резервном копировании не говорит только ленивый, но мало кто следует рекомендациям специалистов. Производителям электроники приходится брать заботу о пользователях в свои руки. И если с резервным копированием данных с компьютера всё более-менее понятно, то как обстоят дела на мобильном фронте? Как с этой задачей справляются смартфоны, планшеты и прочие, более экзотические устройства под управлением Apple iOS, Google (и не-Google) Android, мобильных и стационарных сборок Microsoft Windows и BlackBerry 10? Как извлечь данные, куда сохранить, как восстановить, как обеспечить безопасность и как расшифровать зашифрованную информацию – об этом мы расскажем в новом цикле публикаций.

Начнём с устройств Apple под управлением iOS.

Резервные копии: Apple iOS

Пользователям «яблочной» продукции повезло: компания тщательно продумала и прекрасно реализовала систему резервного копирования и восстановления данных, которая не требует от пользователя никаких усилий. При настройке нового устройства достаточно согласиться (не снимать галочку, которая уже выбрана по умолчанию) с тем, что данные будут автоматически сохраняться в «облако». Об остальном система позаботится самостоятельно.

Действительно так просто? Для обычного пользователя – да. А мы попробуем посмотреть чуть глубже. И сразу же обнаружим, что на самом-то деле механизмов резервного копирования целых два (а то и три, если учитывать разницу между зашифрованными и незашифрованными копиями). Но – по порядку.

Резервные копии – это просто!

Начиная с iOS 5, пользователи устройств под управлением iOS получили возможность автоматического сохранения данных устройства в «облако». В старых версиях iOS эту возможность нужно было активировать вручную, но в последних версиях iOS она стала предлагаться в качестве опции «по умолчанию». Начиная с iOS 9, «облачные» копии хранятся уже не в iCloud, а в более универсальном iCloud Drive.

К слову, бесплатно в iCloud доступно всего 5 ГБ, которых, тем не менее, хватает для хранения настроек устройств и данных приложений даже устройств с 64 ГБ на борту. Здесь необходимо отметить, что ни в облачные, ни в локальные резервные копии не попадают исполняемые файлы приложений. Именно поэтому после восстановления из резервной копии устройство будет скачивать и устанавливать все приложения, данные которых были в резервной копии. Для тех же пользователей, которые хотят сохранять в «облаке» много фотографий и видеороликов, Apple предлагает варианты платной подписки.

Включить «облачное» резервное копирование можно во время активации аппарата или в любое время в настройках устройства (Settings -> iCloud -> Backup).

После активации настройки резервного копирования в «облако» происходит следующее. Как только пользователь пришёл домой, на работу или в любое другое место, в котором телефон подключается к сети Wi-Fi, и поставил на устройство на зарядку, iPhone, iPad или iPod Touch автоматически соединяется с «облаком». Через некоторое время (обычно – через час) начинается процесс резервного копирования: устройство передаёт в iCloud накопленные за день инкрементные изменения. Разумеется, если копирование происходит впервые, то в «облако» закачиваются все данные – процесс небыстрый и потребляющий заметное количество трафика.

Процесс резервного копирования происходит не чаще, чем раз в сутки. При необходимости его можно осуществить и вручную, выполнив команду «Back Up Now».

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

Что делать, если свежую резервную копию создать всё же необходимо? Полиция имеет возможность получить ордер, связаться с Apple и потребовать блокировать все запросы на удалённое управление устройством. Только после этого можно подключать устройство к сети и создавать резервную копию.

В целях расследования можно настроить точку доступа с такими же SSID и паролем, как у подозреваемого. Антенна вводится внутрь изолированного пакета, в котором лежит устройство, и iPhone или iPad самостоятельно создаст свежую копию данных, которую с помощью Elcomsoft Phone Breaker можно извлечь с серверов Apple.

Важный момент: разблокировать аппарат при этом нет никакой необходимости – не нужен ни пароль, ни отпечаток пальца. (В скобках ещё раз заметим, что для того, чтобы данная схема сработала, устройство должно быть разблокирован хотя бы один раз после «холодного» старта, иначе пароль от Wi-Fi останется зашифрованным и телефон не сделает попытки соединиться с сетью).

Собственно, именно об этом способе извлечения данных напомнила сама компания Apple во время судебного процесса против ФБР, связанного с требованием разблокировать iPhone 5c террориста Фарука из Сан-Бернардино. К сожалению, способ не сработал: криминалисты инструктировали владельцев устройства (Департамент здравоохранения) сбросить пароль от iCloud, после чего iPhone 5c не смог авторизоваться в «облаке» и создать резервную копию.

Вернёмся к штатному сценарию использования. Как обстоят дела с восстановлением данных из резервной копии? Это тоже просто. Непосредственно в процессе активации нового (или старого, после сброса настроек) устройства можно выбрать, из какой резервной копии восстанавливать данные. Причём ни модель, ни версия операционной системы большой роли не играют: на новый iPad можно восстановить данные из старого iPhone и наоборот. Работает это всё действительно очень удобно. Если пользователь поехал в отпуск и потерял телефон, то достаточно зайти в ближайший Apple Store, активировать новый iPhone – и все настройки, приложения, контакты, журналы звонков, фотографии и даже обои и расположение иконок – всё восстановится само по себе «по воздуху». А вот если пользователь предпочтёт взамен утраченного iPhone телефон на другой ОС, то подобного сервиса, разумеется, не будет.

«Облачные» резервные копии – это безопасно?

Вопросительный знак в заголовке – не зря. Безопасность «облачных» резервных копий iOS – под большим вопросом, ответ на который, впрочем, вполне однозначный.

Итак, первое и главное: «облачные» резервные копии шифруются. Второе и не менее главное: ключ шифрования хранится рядом с зашифрованными данными, и извлечь его с помощью Elcomsoft Phone Breaker не составляет никакой проблемы. Шифрование, таким образом, защищает данные только в момент их передачи между устройством и сервером, а вот дальше… дальше ни у Apple, ни у эксперта-криминалиста не возникнет проблем с доступом к данным.

А что насчёт злоумышленников? Тут несколько сложнее, ведь для доступа к «облачной» копии потребуется как минимум узнать Apple ID и пароль пользователя. Впрочем, небольшой фишинг или социальный инжиниринг – и пароль от Apple ID в распоряжении преступника. Далее – дело техники: ставим Elcomsoft Phone Breaker, вводим Apple ID и пароль – и данные пользователя у нас в кармане.

И действительно, именно этот способ был использован для воровства фотографий знаменитостей (в 2014 году – у многих кинозвёзд, а до того – у Дмитрия Медведева).

Данная ситуация не устроила Apple, и компания в спешном порядке разработала механизм двухфакторной аутентификации (на тот момент – так называемый метод Two-Step Verification, который в настоящее время практически полностью заменён более безопасным методом под оригинальным названием Two-Factor Authentication), который существенно осложнял доступ злоумышленникам, получившим доступ к паролю от учётной записи Apple ID. При активации этого механизма для доступа к резервной копии iCloud требовалось ввести не только логин и пароль, но и одноразовый код, который можно было получить на доверенное устройство через push или в виде SMS на доверенный телефонный номер.

Введение дополнительного шага аутентификации существенно осложнило жизнь злоумышленников. Социальный инжиниринг усложнился: теперь требовалось не только узнать у жертвы собственно пароль, но и каким-то образом заставить её сообщить одноразовый код. Впрочем, злоумышленники справились и с этим, в качестве инструмента использовав взломанную версию Elcomsoft Phone Breaker:

Если же злоумышленник получал доступ к компьютеру пользователя, то у него появлялся шанс и вовсе пройти мимо всей и всякой защиты – логинов, паролей и кодов. Достаточно было всего лишь извлечь двоичный маркер аутентификации с компьютера, на котором была установлена (и активирована) программа iCloud for Windows. Дальнейшее – дело техники: маркер вводится в Elcomsoft Phone Breaker, резервные копии скачиваются, а логин, пароль и одноразовый код – не нужны.

Извлечение маркера аутентификации:

Использование маркера аутентификации для скачивания данных из iCloud:

Как на это отреагировали в Apple? Довольно оперативно: срок жизни маркера аутентификации iCloud уменьшили с нескольких месяцев до считанных часов. Правда, есть тонкость: в iOS 9, как мы уже писали, резервные копии сохраняются не в iCloud, а в iCloud Drive, для которого маркеры аутентификации и поныне действуют очень и очень долго.

А как обстоят дела с паролями сайтов, социальных сетей и учётных записей? Здесь всё не так однозначно. Если восстанавливаться из «облачной» резервной копии на то же самое устройство, то всё будет в порядке: устройство восстановится и заработает как ни в чём не бывало. Если же восстанавливается другое устройство, то ситуация будет в точности такая, как с локальным бэкапом без пароля: все пароли из keychain (включая пароли от Wi-Fi, почты, социальных сетей и т.п.) восстановлены не будут. И не только они. Многие приложения хранят данные в keychain с опцией «this device only» — «только на этом устройстве». В первую очередь это относится к утилитам хранения паролей, различным программам для хранения документов и т.п.

Разумеется, существует так называемый iCloud Keychain, который позволяет синхронизировать пароли с новым устройством, восстановленным из «облачной» резервной копии, но в саму резервную копию он не попадает.

Безопасность – это удобно?

Представим ситуацию. Пользователь активировал двухфакторную аутентификацию. Поехал в отпуск. Старый iPhone (он же – доверенное устройство, он же – носитель SIM-карты с доверенным телефонным номером, на который можно получить SMS c кодом) утрачен. Пользователь приходит в Apple Store, покупает новый iPhone и пытается его активировать. Вводит Apple ID, потом пароль… а потом с него требуют одноразовый код, получить который пользователю некуда и не на что.

Дальнейшее будет зависеть от того, какой именно вид двухфакторной аутентификации был использован: старый Two-Step Verification (2SV) или новый Two-Factor Authentication (2FA). В первом случае пользователю придётся использовать код восстановления доступа (Recovery Key), который он, возможно, заранее распечатал и сохранил в безопасном месте. Во втором – пройти процедуру восстановления доступа через автоматизированный сервис Apple, причём процедура может занять до нескольких дней в зависимости от ситуации. В качестве альтернативы — подождать, пока возвращения домой и восстановления SIM-карты с доверенным номером для получения кода через SMS. И так неудобно, и эдак. В целом же ситуация такова, что безопасность требует жертв.

Впрочем, для пресловутых кинозвёзд такая ситуация вряд ли составит проблему, ведь новую SIM-карту с собственным телефонным номером в США можно получить и активировать за минуты буквально на каждом углу. Таким образом, с точки зрения Apple проблема – решена.

А если без «облака»?

Как мы выяснили, «облачные» резервные копии, несомненно, удобны, но могут быть не вполне безопасны. И если вопрос безопасности перевешивает удобство использования, но резервную копию данных иметь всё-таки хочется, то можно воспользоваться альтернативным методом резервного копирования непосредственно на компьютер через iTunes.

Настроить резервное копирование через iTunes можно в самом приложении Apple iTunes:

Как мы видим, вполне возможно сделать так, чтобы резервная копия создавалась автоматически каждый раз, когда iPhone или iPad подключается к компьютеру. Да, это не так удобно, как «облачное» копирование, зато гораздо более безопасно. Или нет? Попробуем разобраться.

Резервные копии в iTunes: с паролем или без?

Обратим внимание на скриншот выше, а именно – на настройку «Encrypt iPhone backup». Если активировать эту настройку и указать пароль (кстати, он никак не связан с кодом блокировки устройства и паролем от Apple ID, поэтому может быть сколь угодно длинным и сложным – вводить его на самом устройстве не потребуется никогда), то все вновь создаваемые резервные копии будут шифроваться с использованием этого пароля. Более того, если забыть этот пароль, то сбросить или изменить его будет невозможно без полного сброса устройства (при этом восстановить его из зашифрованной резервной копии, не указав правильный пароль, также не получится).

С технической точки зрения шифрование в iOS реализовано образцово. Вся информация шифруется непосредственно в самом устройстве, а наружу выдаётся уже зашифрованный поток данных. iTunes в данном случае всего лишь выдаёт команду на создание резервной копии, принимает зашифрованный поток данных и сохраняет его в файл. На месте iTunes могла бы быть любая другая программа (например, Elcomsoft iOS Forensic Toolkit, работающий в режиме логического извлечения данных); при этом данные всё равно остались бы зашифрованными.

Выходит, с шифрованием всё хорошо? Можно установить пароль и забыть о проблемах с безопасностью? Есть только два момента, которые омрачают безоблачную картину безопасных резервных копий. Момент первый: пароль можно попробовать взломать.

Есть и второй момент, который вступает в некоторое противоречие со здравым смыслом. Если резервная копия зашифрована паролем, то почти все данные из keychain (а это пароли от учётных записей и веб-сайтов, данные утилит Health, HomeKit и многие другие) будут также зашифрованы тем же самым паролем, а не безопасным аппаратным ключом устройства. С одной стороны, это позволяет восстановить резервную копию на новое устройство и автоматически получить доступ ко всем сохранённым паролям и учётным записям. С другой – если пароль от резервной копии удастся взломать, то эти данные станут доступны злоумышленнику.

А если пароль не указывать? Тогда данные приложений, фотографии и прочая информация зашифрованы не будут. А вот данные из keychain – наоборот, будут зашифрованы стойким аппаратным ключом, взломать который на данном этапе развития технологий не представляется возможным. Обратная сторона медали: штатными средствами восстановить данные из keychain можно будет только на то же самое устройство, с которого они были скопированы.

«Штатными средствами»? Действительно, и на этот замок есть свой ключ, однако достать его – очень и очень трудно и далеко не всегда возможно. Скажем только, что ключ этот (назовём его «securityd») можно извлечь только из устройств, не оборудованных системой безопасности Secure Enclave, и только в том случае, если на устройство установлен jailbreak. Короче говоря, извлечь securityd для расшифровки keychain из незащищённой паролем резервной копии можно из iPhone 5c и более старых, iPad mini (но даже не mini 2) и оригинальных iPad 1-4, основанных на 32-битных процессорах.

К слову о фотографиях

Фотографии знаменитостей – это всегда интересно! Вот только сегодня в «облачные» резервные копии они попадают уже не всегда. Если включить iCloud Photo Library, то фотографии на аппарате остаются, но ни в локальный, ни в «облачный» бэкап не попадают. Тем не менее, фотографии всё равно сохраняются в «облаке» — только отдельно от остальных данных, и извлекать их нужно уже совсем другим, более простым способом. Для их извлечения можно воспользоваться Elcomsoft Phone Breaker, который автоматически скачает фотографии из iCloud Photo Library, включая даже те снимки, которые пользователь недавно удалил.

Использование iCloud Photo Library вполне укладывается в логику Apple: пользователь избавляется от дублирования данных и получает доступ к фотографиям с любого зарегистрированного устройства. Вот только украсть фотографии стало значительно проще.

Исследуем iCloud: как это устроено

Для пользователя iCloud – это просто и удобно. А как это устроено изнутри, и как можно добраться до «облачных» данных? Можно установить iCloud for Windows или зайти в «облако» с iPhone или iPad. Можно просмотреть список резервных копий и увидеть их размер. Но на этом возможности заканчиваются. Скачать резервную копию не получится, для этого просто не предусмотрен готовый механизм. Чтобы скачать собственный бэкап, придётся понять, как организованы хранение и защита данных.

iCloud – интересная динамическая система распределённого хранения данных, завязанная на Apple ID пользователя и работающая на основе Google Protocol Buffers. Сами файлы разбиты на отдельные блоки (chunks), которые распределены между двумя независимыми «облачными» провайдерами – Amazon S3 и Microsoft Azure. Что интересно, в последнее время мы наблюдаем эпизодическое использование и третьего «облачного» провайдера, которым стал… Google. Именно так: Apple использует сервисы Amazon, Google и Microsoft в качестве back end для хранения «облачных» резервных копий iCloud! А вот российские «облачные» провайдеры, такие как… ну, какие-нибудь российские, — Apple для хранения «облачных» резервных копий пока не использует. Зато добавляются дата-центры AT&T в США.

Мы провели исследование, попытавшись выявить закономерность в распределении блоков данных между провайдерами. Хотелось найти ответ на вопрос, действительно ли данные распределяются равномерно (то есть часть данных – на одном сервере, часть на другом) или же используется схема зеркалирования данных для повышения надежности. С большой долей уверенности можно говорить об использовании подхода зеркалирования: если блок данных не удаётся скачать, к примеру, из облака Azure, то этот же блок автоматически запрашивается с сервера Amazon или Google.

На следующем уровне абстракции устанавливаются соответствия между файлами и блоками данных. На серверах Apple формируются запросы в «облачные» хранилища Amazon и Microsoft для каждого блока. Ключи шифрования при этом генерируются для каждого блока (chunk) по отдельности.

Вот как это выглядит в схематическом виде:

Вот как это реализовано внутри. Аутентификация в «облако» выполняется в следующем формате.

Запрос:

https://setup.icloud.com/setup/authenticate/$APPLE_ID$,

Authorization:Basic <authentication data>
Данные аутентификации для <authentication data> вычисляются как mime64 (AppleID:password)
Результат: mmeAuthToken, dsPrsID

Вот пример такого запроса:

GET /setup/authenticate/$APPLE_ID$ HTTP/1.1
Host: setup.icloud.com
Accept: */*
User-Agent: iCloud.exe (unknown version) CFNetwork/520.2.6
X-Mme-Client-Info: <PC> <Windows; 6.1.7601/SP1.0; W> <com.apple.AOSKit/88>
Accept-Language: en-US
Authorization: Basic cXR0LnRld3RAaWNtb3VkLmNvbTqRd2VydHkxMjM0NQ==

Для получения маркера аутентификации для дальнейшей работы используем такой запрос:

https://setup.icloud.com/setup/get_account_settings
Authorization:Basic <authentication data>
authentication data = mime64 (dsPrsID:mmeAuthToken)
результат: mmeAuthToken (обрати внимание, это уже второй маркер аутентификации!)

Получим список бэкапов, доступных на сервере для данной учётной записи:

https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)
Authorization: <authentication data>
authentication data = mime64 (dsPrsID:mmeAuthToken)
результат: список идентификаторов резервных копий (backupudid)

Для каждой резервной копии запрашиваем ключи шифрования:

https://p11-mobilebackup.icloud.com/mbs/2005111682/(backupudid)/getKeys

Далее нам потребуется ещё три запроса. Первый запрос возвращает список версий (для каждой резервной копии в «облаке» сохраняется целых три последних версии):

HTTPS GET
https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)/(backupudid)/(snapshotid)/listFiles?offset=(offset)&limit=(limit)

Далее получаем маркеры аутентификации для каждого файла:
HTTPS POST
https://p11-mobilebackup.icloud.com/mbs/(dsPrsID)/(backupudid)/(snapshotid)/getFiles

После чего получаем список ссылок (URL), по которым будут доступны для скачивания отдельные блоки:

HTTPS POST
https://p11-content.icloud.com/(dsPrsID)/authorizeGet

Дальше нам нужно извлечь данные, скачав все блоки.

Пример запроса для блока данных, сохранённых в Windows Azure:

http://msbnx000004.blob.core.windows.net:80/cnt/g6YMJKQBPxQruxQAr30C?sp=r
&sr=b&byterange=154-31457433&se=2013-06-07T10:14Z&
st=2013-06-07T09:19Z&sig=0EdHy75gGHCee%2BjKePZBqz8xbWxpTxaYyASwFXVx2%2Fg%3D

Здесь ‘se’ – время авторизации в iCloud (маркеры действительны в течение часа)

А вот пример для блока из Amazon AWS:

http://us-std-00001.s3-external-1.amazonaws.com/I9rh20QBPX4jizMAr3vY?
x-clientrequest-id=739A222D-0FF5-44DD-A8FF-2A0EB6F49816&
Expires=1371208272&byterange=25556011-25556262&
AWSAccessKeyId=AKIAIWWR33ECHKPC2LUA&
Signature=PxAdegw0PLyBn7GWZCnu0bhi3Xo%3D

В «облаке» обычно хранится три последних бэкапа. Когда создаётся новый, какое-то время в «облаке» висит четыре последних версии (а иногда и больше), но потом их число снова сокращается до заветной цифры «три». Хранятся резервные копии инкрементально. Самый первый бэкап обычно полный, следующий существенно меньше, самый новый еще меньше. Извлечь самую старую копию легче всего; следующий – чуть сложнее, т.к. нужно скачать и вторую часть тоже, а потом «применить» изменения. Для получения самого свежего бэкапа процедуру приходится проделывать дважды.

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

Что значит «для большей части»? Дело в том, что далеко не все данные из «облачной» резервной копии могут быть расшифрованы. Часть данных шифруется с помощью ключей из OTA (over-the-air) backup keybag, большинство из которых может быть расшифровано только на том самом устройстве, с которого была сделана резервная копия (с помощью ключа 0x835 «securityd», который, напомним, вычисляется ядром системы в момент загрузки устройства).

Здесь есть интересный момент. С одной стороны, обычным пользователям без jailbreak этот ключ недоступен. С другой – неизвестно, сохраняет ли Apple этот ключ в «облаке». Чисто теоретически это было возможно сделать на 32-разрядных платформах с iOS 7. Начиная с iOS 8 и устройств, оборудованных Secure Enclave (а это – все 64-разрядные iPhone и iPad) извлечь этот ключ из устройства не представляется возможным даже при наличии jailbreak, в том числе – если верить заявлениям компании – даже для самой Apple.

Анализ iCloud: история

Впервые данные из iCloud нам удалось расшифровать в 2012 году, ещё во времена iOS 5, с помощью атаки «man in the middle» с подменой сертификата. Для расшифровки использовался iPhone 4S. Последовательность действий была такой (всё описанное относится только к iOS 7 и старше; более свежих версиях возможность подмены сертификата закрыли):

1. На телефон устанавливается jailbreak
2. Из репозитария Cydia устанавливается Open SSH, с помощью которого извлекается keychain (файл keychain-2.db)
3. Телефон был сброшен к заводским настройкам, а сервис Find My iPhone – деактивирован: [Settings] | [iCloud] | [Delete Account] | [Delete from My iPhone] и далее — [Settings] | [General] | [Reset] | [Reset All Settings]
4. Аппарат перезагружен.

В результате получено «чистое» устройство с установленным jailbreak, сброшенное к заводским установкам. Далее была выполнена следующая последовательность:

1. Во время активации телефона указана сеть Wi-Fi и прокси-сервер
2. В файле keychain корневой сертификат заменяется на наш собственный (для этого потребуется ключ 0x835 и собственно файл keychain, который мы извлекли ранее)
3. Теперь все коммуникации между телефоном и серверами Apple шифруются с помощью подменённого сертификата; становится возможным сниффинг трафика.

Что такое ключ 0x835, он же «securityd»? Это криптографический ключ, который используется исключительно для защиты keychain. Он вычисляется ядром системы во время загрузки, и хранится в оперативной памяти устройства. Извлечь его можно только из загруженного устройства с установленным jailbreak, и только из устройств, не оборудованных Secure Enclave.

key835 = AES(UID, bytes(«01010101010101010101010101010101»))

Удастся ли повторить эту последовательность сегодня? Возможно – если в распоряжении исследователя есть старое устройство, работающее под управлением iOS 7. В iOS 8 возможность подмены сертификата закрыли, а из современных устройств не получится извлечь ключ 0x835.

Что нового в iOS 9, 10, 11?

iOS 8 не принесла больших изменений в механизм резервного копирования, а вот в iOS 9 всё поменялось. Теперь резервные копии сохраняются не в классический iCloud, а в новый iCloud Drive. Что это меняет? С точки зрения пользователя – ничего. С точки зрения разработчиков – новые ссылки для скачивания и несколько изменённый механизм авторизации.

Важный с точки зрения криминалистов момент: срок действия маркеров аутентификации iCloud Drive не зависит от времени жизни маркеров для логина в iCloud. До недавнего времени маркеры действовали без ограничений. На сегодняшний день в Apple установили 12-часовой жизненный цикл для маркеров для доступа к резервным копиям. С помощью тех же самых маркеров синхронизированные данные (фотографии из iCloud Photo Library, календари, заметки и многое другое) можно извлекать без ограничений по времени.

Наши рекомендации

Мы разобрали основные варианты резервного копирования и ознакомились с потенциальными проблемами их использования, в том числе с вопросами безопасности. Значит ли это, что от резервных копий стоит отказаться? С нашей точки зрения – нет. Сэкономленное время и удобство, на наш взгляд, заметно важнее. Оптимальной стратегией с нашей точки зрения будет активировать «облачные» резервные копии и позволить системе регулярно сохранять данные. А чтобы не оказаться в один момент «у разбитого корыта», стоит время от времени (хотя бы раз в месяц) создавать и локальные копии данных через iTunes, причём с достаточно длинным, но легко запоминаемым (и трудно угадываемым) паролем. Альтернативный вариант – установить длинный и сложный пароль, сохранить его на физическом носителе (распечатать на бумаге) и хранить в безопасном месте – например, в сейфе. Такой пароль невозможно будет угадать, восстановить или украсть, взломав компьютер.

А если включать двухфакторную аутентификацию 2SV или 2FA, то в первом случае бережно хранить (хоть с паспортом вместе) Recovery Key, во втором – как минимум привязать к учётной записи кредитную карту (что делают далеко не все). Ещё желательно добавить дополнительный номер для SMS-верификации, что позволит в случае непредвиденной ситуации получить одноразовый код на другую SIM-карту.

Заключение

Сегодня мы ознакомились с реализацией системы резервного копирования, спроектированной и реализованной на самом высоком уровне. В Apple серьёзно подошли к вопросу и попытались нащупать баланс между удобством и безопасностью. С нашей точки зрения им это удалось, особенно если сравнить с решениями конкурентов. А как обстоят дела в самой распространённой мобильной ОС – Google Android? Об этом мы напишем в следующем выпуске.