Пару лет назад я потерял доступ к аккаунту Facebook. Второй фактор был основан на SMS, а сообщения от Facebook на мой российский номер перестали доходить. Можно было восстановить доступ через поддержку — прислать селфи с паспортом. Но я тогда засомневался, стоит ли оно того.
В случае с Facebook потеря была не слишком критичной. Но сам случай заставляет задуматься: уже почти вся наша повседневность так или иначе завязана на цифровые сервисы. Стоит хотя бы одному из них стать недоступным, для нас перестает работать не столько приложение или сайт, сколько реальный процесс, который на нем основан.
В этой статье я попробую разобраться, как сделать свою цифровую инфраструктуру устойчивее.
Для начала определимся с самим понятием. Под цифровой устойчивостью я понимаю способность поддерживать цифровую основу своих реальных процессов. У нее есть две стороны.
Безопасность. Это про ограничение несанкционированного доступа. Риски: доступ к данным, действия от моего имени, угон аккаунта и потеря связанных с ним данных.
Зависимость от поставщика. Это про то, насколько я могу полагаться на сервис. Риски: технические сбои, внезапное изменение условий доступа, закрытие продукта.
В корпоративной среде всем этим занимаются специально обученные люди. Они разграничивают доступы, учитывают угрозы, считают риски со стороны провайдера. Под это выделены бюджеты, налажены процессы, есть ответственность. Риски для компании вполне осязаемы — деньги и репутация.
В частной жизни, если честно, мы об этом не сильно задумываемся. Безопасность неплохо покрывается рекомендациями самих сервисов: уникальный пароль, мультифактор, резервный способ входа. А популярные сервисы достаточно стабильны, поэтому самой вероятной причиной переезда на другой сервис будет появление нового, более удобного конкурента.
В последние годы добавился еще один фактор риска в вопросах зависимости от поставщика. Внешний по отношению к паре клиент-сервис регулятор. Причем в каждой юрисдикции регулятор свой, со своими правилами. История с Facebook как раз про это: сам сервис в одной юрисдикции, мобильный провайдер — в другой. Фрагментация интернета по регуляторным зонам заставляет нас брать ответственность за свою цифровую устойчивость на себя.
1. Цепочка зависимостей
Я ее представляю так.
РЕАЛЬНЫЙ ПРОЦЕСС ↓ ЦИФРОВОЙ СЕРВИС ↓ ДОСТУП ↓ ДАННЫЕ
Цепочка может оборваться на любом из трех звеньев:
сервис стал недоступен;
потерян доступ к аккаунту;
потеряны данные.
Это и есть основные сценарии, в которых нам предстоит восстанавливаться. Цель во всех случаях одна — вернуть функциональность реального процесса.
2. Сценарии
2.1. Сервис больше недоступен
В этом случае прежнюю цифровую основу процесса уже не вернуть — ее приходится пересоздавать на другом сервисе.
Для меня этот риск вполне конкретен. Я уже много лет в экосистеме Apple. Mac и iPhone завязаны на инфраструктуру одного поставщика. Если доступ к ней будет ограничен, значительная часть моей цифровой среды может стать недоступна сразу на обоих устройствах. На самом деле именно осознание этого факта и побудило меня заняться, наконец, вопросами цифровой устойчивости.
Для восстановления понадобится заранее сохраненная копия данных в переносимом формате. Без нее новый инструмент окажется пустым и процесс придется собирать с нуля.
Формула:
восстановленный процесс = новый сервис + сохраненные данные
2.2. Потерян доступ
Сервис продолжает работать, аккаунт и данные существуют, но войти не получается.
Сначала нужно попытаться вернуть доступ к тому же аккаунту: через резервный способ входа или процедуру восстановления. Если это удалось, процесс возвращается целиком. Но доступ можно и не вернуть — аккаунт так и останется закрытым для владельца. Тогда придется создать новый аккаунт и восстановить состояние из копии данных.
Формула на случай неудачи восстановления доступа:
восстановленный процесс = новый аккаунт + сохраненные данные
2.3. Потеряны данные
Сервис доступен и вход работает, но данные удалены или повреждены.
Здесь нужна заранее подготовленная копия данных, на основании которой можно вернуть состояние.
Формула:
восстановленный процесс = старый аккаунт + сохраненные данные
Во всех сценариях сохраненные данные служат последней опорой. Они не всегда нужны для восстановления: при потере доступа сначала можно вернуть прежний аккаунт. Но если доступ окончательно утрачен или исчез сам сервис, продолжить процесс без копии данных уже не получится.
3. Практические принципы
После такой схемы может показаться, что следующий шаг — провести полный аудит цифровой жизни: выписать все процессы, найти все сервисы, построить карту зависимостей и заранее придумать план миграции.
На практике это не стоит затраченных усилий. Во-первых, человек не держит в голове полный список своих процессов и связанных с ними сервисов. Они прорастали в нашу жизнь годами. Во-вторых, заранее проектировать будущую миграцию бессмысленно. Через несколько лет цифровой ландшафт, скорее всего, значительно изменится: появятся новые сервисы, старые исчезнут.
Начать можно с того, что уже есть.
Менеджер паролей — это не только хранилище секретов. Это готовый список цифровых сервисов, которыми вы пользуетесь. Дальше идем по списку.
Порядок в доступах. Во всех ценных аккаунтах провести ревизию раздела "безопасность аккаунта": пароль, мультифактор, процедура восстановления. При этом нужно учитывать, что на уровне восстановления аккаунты зависят друг от друга.
Сохранность данных. Для важных сервисов нужно понять, где находится источник данных, что произойдет при потере аккаунта или самого сервиса и можно ли заранее подготовить независимую копию в переносимом формате.
Проверка восстановления. Убедиться, что подготовленные способы восстановления действительно работают.
4. Наводим порядок в доступах
Когда передо мной оказался список сервисов из менеджера паролей, в нем было больше сотни аккаунтов из разных юрисдикций. Аккаунты связаны процедурами восстановления. Эти связи образуют собственную инфраструктуру доверия. Если один аккаунт выпадет, это затронет все завязанное на него подмножество.
Дальше я решал три задачи.
Найти корни в системе зависимостей. Корень — это аккаунт, через который восстанавливаются другие сервисы и у которого способ восстановления не зависит от других аккаунтов.
Убрать циклические зависимости. Если аккаунт A восстанавливается через B, а B через A, это не две независимые точки восстановления, а замкнутый круг.
Разделить контуры по юрисдикции. Если восстановление одного контура проходит через другой, будет то, что у меня случилось с Facebook.
Сначала определил два контура: российский и внешний.
В российском контуре центральным узлом стал Яндекс. Здесь ситуация не очень каноничная: последняя точка восстановления находится не в секрете на физическом носителе, а в процедуре подтверждения личности через саппорт.
Во внешнем контуре корнем стал Google. Я отвязал от него российский номер телефона как второй фактор и Яндекс-почту как резервный адрес. Теперь восстановление Google не зависит от российского контура, а последняя опора находится в резервных кодах, сохраненных отдельно от любых других сервисов.
После этого я прошелся по остальным аккаунтам. Во всех значимых сервисах, где это было возможно, убрал зависимость от SMS и перевел второй фактор на TOTP-коды. Это особенно критично для внешнего контура, если у вас есть только российский номер.
Отдельно можно выделить почты, которые я исторически использовал для второстепенных регистраций: Rambler и Proton. Они не являются основой для восстановления критичных аккаунтов, а обслуживают свой уровень менее важных сервисов. Сами при этом опираются на корни своих контуров.
Получились такие два дерева:
российский контур внешний контур дейтинг ... дискаунтеры файлопомойки ... форумы │ │ │ │ │ │ └──────┴───────┘ └──────┴───────┘ │ │ Хабр Rambler VK Facebook Proton GitHub \ │ / \ │ / \ │ / \ │ / ЯНДЕКС GOOGLE │ │ подтверждение личности резервные коды через саппорт физический мир
Кроме них во внешнем контуре есть еще одно дерево — экосистема Apple со своим корнем. На нем держатся устройства и сервисы Apple. При включенном Recovery Key восстановление опирается либо на уже доверенное устройство, либо на сохраненный вне экосистемы Recovery Key вместе с доступом к доверенному номеру телефона.
сервисы Apple │ APPLE │ ┌───────────┴───────────┐ │ │ доверенное устройство Recovery Key + доверенный номер телефона
При этом сторонние сервисы я исторически завязывал не на Apple, а на Google. Объективного архитектурного преимущества здесь нет: оба аккаунта принадлежат IT-гигантам и могут использоваться как корни для других сервисов. Просто Google я воспринимаю как более самостоятельный аккаунт, а Apple — как часть инфраструктуры устройств
5. Сохраняем данные
После того как порядок в доступах наведен, нужно сохранить сами данные так, чтобы потеря одного сервиса, устройства или юрисдикции не привела к потере копий.
В моей схеме резервные копии хранятся в трех разных местах:
в облаке внешнего контура;
в облаке российского контура;
на зашифрованном офлайн-накопителе.
Я выделяю несколько типов данных по тому, откуда они берутся и как их готовить к бэкапу.
5.1. Источник данных у меня
В этом случае данные уже находятся под моим контролем. Например:
фотоархив;
документы;
исходный код;
заметки.
Про личный архив я уже писал отдельно в статье «Личный архив: сбор, бэкап, таймлайн фотографий». Здесь задача понятная: обеспечить несколько копий, которые переживут поломку устройства, случайное удаление или физическую потерю.
Отдельный случай — данные, для которых важна история изменений. Например, исходный код, конфиги и заметки. Для них система контроля версий сохраняет историю, а отдельный удаленный репозиторий или другая независимая копия защищает от потери самого хранилища.
5.2. Источник данных в сервисе
В этом случае актуальная исходная версия данных находится внутри чужого сервиса. Например:
контакты;
задачи в таск-трекере;
календарь;
почта;
документы в облачных редакторах.
Для таких данных важно иметь экспорт в переносимом формате. Не нужно заранее выбирать замену каждому сервису. Главное — сохранить возможность забрать свои данные и продолжить работу в другом месте.
Это, кстати, становится одним из критериев выбора новых и аудита старых сервисов: насколько легко из них забрать свои данные.
При этом сам факт наличия экспорта еще не означает полной переносимости. Экспорт может не сохранять историю, связи, права доступа или другие возможности исходного сервиса. Поэтому важно проверять не только наличие кнопки "Экспорт", но и содержимое полученного файла.
5.3. Секреты доступа
Есть еще один особый класс данных: то, что не является содержимым процессов, но обеспечивает доступ ко всей цифровой инфраструктуре. Это пароли, TOTP-секреты, коды восстановления.
Здесь есть нюанс: инструменты безопасности сами могут стать новой зависимостью.
Например, TOTP-аутентификатор выглядит просто как приложение для генерации кодов. Но настоящие данные находятся не в приложении, а в секретах, на основе которых эти коды создаются. Если секреты хранятся только внутри одного приложения или сервиса, его потеря может закрыть доступ сразу ко множеству аккаунтов.
Поэтому секреты доступа у меня собраны отдельно:
экспорт менеджера паролей;
TOTP-секреты;
коды восстановления.
Они хранятся в зашифрованном архиве секретов. Сам архив включается в резервную копию и вместе с остальными данными попадает в три хранилища.
Способ хранения зависит от роли секрета в восстановлении. Пароли обычных сервисов достаточно хранить в менеджере и его резервном экспорте. Корневые пароли и коды восстановления дополнительно дублируются на бумаге. А секреты, необходимые для открытия устройства, офлайн-накопителя и самого архива, должны быть доступны вообще без цифровых хранилищ — на бумаге и, по возможности, в памяти.
Получается следующая схема:
Секрет | Менеджер паролей | Архив секретов | Бумага дома | Память |
|---|---|---|---|---|
Пароли обычных сервисов | ✓ | ✓ | ||
Пароли корневых аккаунтов | ✓ | ✓ | ✓ | |
TOTP-секреты | ✓ | |||
Коды восстановления обычных сервисов | ✓ | |||
Коды восстановления корневых аккаунтов | ✓ | ✓ | ||
Пароли и пин-коды устройств | ✓ | ✓ | ||
Пароль зашифрованного офлайн-накопителя | ✓ | ✓ | ||
Пароль архива секретов | ✓ | ✓ | ||
Пароль менеджера паролей (отдельный от экосистемы Google/Apple) | ✓ | ✓ |
5.4. Схема целиком
Данные копируются в два облачных хранилища разных контуров и на офлайн-накопитель. При этом способ подготовки зависит от типа данных: локальные данные резервируются напрямую, данные из сервисов сначала экспортируются, а секреты доступа собираются в отдельный зашифрованный архив.
Для копирования данных из источника в облака и офлайн-накопитель я использую rclone, который упоминал в прошлой статье.
ДАННЫЕ ┌──────────────────┬──────────────────┐ │ │ │ Источник у меня Источник в сервисе Секреты доступа фотоархив задачи экспорт менеджера паролей заметки календарь TOTP-секреты код почта коды восстановления документы контакты │ │ │ │ экспорт зашифрованный │ сервиса архив │ │ │ └──────────────────┴──────────────────┘ │ ┌───────────────┼────────────────┐ │ │ │ облако облако зашифрованный внешнего российского офлайн- контура контура накопитель
6. Принципы генерации паролей
По моим наблюдениям, с паролями люди поступают по-разному. Кто-то генерирует для каждого сервиса случайную последовательность и полностью полагается на менеджер паролей. Кто-то держит в голове несколько собственных принципов: знакомая основа, название сервиса, цифры и специальные символы. Пароли получаются разными, но при необходимости их можно заново вывести из той же логики.
У второго подхода есть вполне практическая мотивация. Например, на рабочем компьютере не хочется открывать личный менеджер паролей: рабочая машина контролируется не только вами, и в случае ее компрометации под угрозой окажется сразу все хранилище. В идеале рабочую и личную цифровую среду лучше разделять.
На самом деле эти два подхода не противоречат друг другу. Они решают разные задачи. Для большинства сервисов пароль не нужно помнить или восстанавливать из собственной логики: достаточно, чтобы менеджер создал и сохранил его. Человекопонятная форма нужна только тем секретам, которые приходится вводить без менеджера. Так у меня получилось два принципа генерации.
Пароли при доступном менеджере:
пароли от обычных сервисов;
пароли от корневых аккаунтов — Яндекса, Google и Apple.
Для каждого аккаунта менеджер создает отдельную случайную последовательность, например:
w7a&JE9+agLl4$kQ2nXp
Такой пароль не требуется помнить или уметь заново выводить из какой-либо логики. Корневые пароли генерируются точно так же, но дополнительно сохраняются в архиве секретов и на бумаге: хранить пароль Apple-аккаунта только внутри экосистемы Apple, а пароль Google-аккаунта только в Google Password Manager было бы замкнутым кругом.
Пароли, доступные без менеджера:
пароль устройства;
мастер-пароль менеджера;
пароль архива секретов;
пароль зашифрованного офлайн-накопителя.
Для них лучше подходят длинные парольные фразы из нескольких случайных, не связанных между собой слов, например:
grass-river-chair-cloud-dog
Основную стойкость здесь дают длина и непредсказуемость, а не обязательная заглавная буква, цифра и специальный символ. Слова должны действительно выбираться случайно: придуманная человеком осмысленная фраза или цитата предсказуемее.
Пароль устройства используется регулярно, поэтому его приходится помнить. Если менеджер паролей не встроен в экосистему устройства, то же относится и к его мастер-паролю. Пароли архива секретов и зашифрованного офлайн-накопителя используются реже, поэтому дополнительно записаны на бумаге, но в моей схеме я также держу их в памяти.
Таким образом, собственную логику генерации для каждого сервиса я не использую. Пароли сервисов создает менеджер, а для небольшого числа секретов, которые должны быть доступны без него, используются случайные парольные фразы.
7. Passkeys
У искушенного читателя после разговоров о том, как генерировать пароли, может начать подгорать: "Мы все еще обсуждаем пароли в 2026 году?" В последние годы индустрия активно движется в сторону passkeys — новой модели аутентификации.
У passkeys есть два основных преимущества: безопасность и удобство.
С точки зрения безопасности passkey похож на случайно сгенерированный пароль: для каждого сервиса создается отдельный секрет. Но в отличие от обычного пароля этот секрет никогда не нужно вводить в форму и вообще передавать сервису. Вместо этого хранилище ключей использует его для подтверждения входа криптографической операцией. Поэтому пользователь не может случайно отдать секрет фишинговому сайту.
С точки зрения пользователя кажется, что теперь не используется второй фактор. Но технически второй фактор заменяется на доказательство владения ключом. Само использование ключа на устройстве подтверждается кодом этого устройства или биометрией.
При этом passkeys не являются каким-то особым секретом, который существует только внутри телефона. Как и пароли, они хранятся, синхронизируются между устройствами и могут быть экспортированы для резервного копирования.
Однако passkeys пока поддерживают далеко не все сервисы, поэтому я все еще использую привычную схему: уникальный пароль + второй фактор.
8. Проверка восстановления
Последний шаг — один раз проверить, что собранная схема действительно работает. Речь не о том, чтобы повторять эту процедуру после каждого бэкапа. Достаточно пройти основные пути восстановления при первоначальной настройке, а затем возвращаться к проверке только после заметных изменений: смены сервиса, менеджера паролей, формата экспорта или схемы хранения.
Для локальных данных можно восстановить одну выбранную папку отдельно от оригинала и открыть несколько файлов.
Для данных из сервисов — проверить содержимое экспорта и, если возможно, один раз попробовать импортировать его в тестовую среду.
Для секретов доступа — открыть архив по независимо сохраненному паролю, импортировать экспорт менеджера в чистый профиль и убедиться, что сохраненные TOTP-секреты позволяют заново получить рабочие коды.
Для ключевых аккаунтов стоит один раз пройти путь "Забыл пароль". Не обязательно действительно менять пароль — важно убедиться, что цепочка восстановления понятна и все необходимые способы доступа находятся под рукой. Если для проверки использовался одноразовый код восстановления, его нужно заменить новым.
9. Где остановиться
Полностью убрать зависимости невозможно. Более того, после всей этой работы в системе все равно останутся крупные узлы, потеря которых вызовет проблемы.
Google — пример такого узла во внешнем контуре. На нем держится значительная часть дерева аккаунтов, за исключением экосистемы Apple. Если я потеряю доступ к Google, цепочка восстановления остальных аккаунтов окажется нарушена. Где-то помогут активные сессии, где-то удастся сменить почту без подтверждения старой, а где-то доступ уже будет не вернуть. Тогда придется создавать новый корень и постепенно перепривязывать к нему все, что удалось сохранить.
Можно было бы заранее сделать диверсификацию корней. Но, как и любое усложнение, это имеет свою цену: дополнительные аккаунты и процедуры их восстановления. Поэтому для меня на сегодняшний день баланс остается на стороне одного основного корня в каждом контуре: Яндекса в российском и Google во внешнем. Отдельно от этого существует Apple-аккаунт, на котором держится собственная экосистема Apple.
В конечном счете задача не в том, чтобы построить систему без единой точки отказа. Реалистичнее честно зафиксировать свои зависимости и иметь план восстановления. Так потенциальная катастрофа превращается в обозримый и посильный список задач.
