Пару лет назад я потерял доступ к аккаунту Facebook. Второй фактор был основан на SMS, а сообщения от Facebook на мой российский номер перестали доходить. Можно было восстановить доступ через поддержку — прислать селфи с паспортом. Но я тогда засомневался, стоит ли оно того.

В случае с Facebook потеря была не слишком критичной. Но сам случай заставляет задуматься: уже почти вся наша повседневность так или иначе завязана на цифровые сервисы. Стоит хотя бы одному из них стать недоступным, для нас перестает работать не столько приложение или сайт, сколько реальный процесс, который на нем основан.

В этой статье я попробую разобраться, как сделать свою цифровую инфраструктуру устойчивее, не превращая ее поддержку во вторую работу.

Под цифровой устойчивостью я понимаю способность поддерживать цифровую основу своих реальных процессов. У нее есть две стороны.

1. Безопасность. Это про ограничение несанкционированного доступа. Риски: доступ к данным, действия от моего имени, угон аккаунта и потеря связанных с ним данных.

2. Зависимость от поставщика. Это про то, насколько я могу полагаться на сервис. Риски: технические сбои, внезапное изменение условий доступа, закрытие продукта.

В корпоративной среде всем этим занимаются специально обученные люди. Они разграничивают доступы, учитывают угрозы, считают риски со стороны провайдера. Под это выделены бюджеты, налажены процессы, есть ответственность. Риски для компании вполне осязаемы — деньги и репутация.

В частной жизни, если честно, мы об этом не сильно задумываемся. Безопасность неплохо покрывается рекомендациями самих сервисов: уникальный пароль, мультифактор, резервный способ входа. А популярные сервисы достаточно стабильны, поэтому самой вероятной причиной переезда на другой сервис будет появление нового, более удобного конкурента.

В последние годы добавился еще один фактор риска в вопросах зависимости от поставщика. Внешний по отношению к паре клиент-сервис регулятор. Причем в каждой юрисдикции регулятор свой, со своими правилами. История с Facebook как раз про это: сам сервис в одной юрисдикции, мобильный провайдер — в другой. Фрагментация интернета по регуляторным зонам заставляет нас брать ответственность за свою цифровую устойчивость на себя.

1. Цепочка зависимостей

Я ее представляю так.

РЕАЛЬНЫЙ ПРОЦЕСС
      ↓
 ЦИФРОВОЙ СЕРВИС
      ↓
    ДОСТУП
      ↓
    ДАННЫЕ

Цепочка может оборваться на любом из трех звеньев:

1. сервис стал недоступен;

2. потерян доступ к аккаунту;

3. потеряны данные.

Это и есть основные сценарии, в которых нам предстоит восстанавливаться. Цель во всех случаях одна — вернуть функциональность реального процесса.

2. Сценарии

2.1. Сервис недоступен

В этом случае прежнюю цифровую основу процесса уже не вернуть — ее приходится пересоздавать на другом сервисе.

Для этого понадобится заранее сохраненная копия данных в переносимом формате. Без нее новый инструмент окажется пустым и процесс придется собирать с нуля.

Формула:

восстановленный процесс = новый сервис + сохраненные данные

2.2. Потерян доступ

Сервис продолжает работать, аккаунт и данные существуют, но войти не получается.

Сначала нужно попытаться вернуть доступ к тому же аккаунту: через резервный способ входа или процедуру восстановления. Если это удалось, процесс возвращается целиком. Но доступ можно и не вернуть — аккаунт так и останется закрытым для владельца. Тогда придется создать новый аккаунт и восстановить состояние из копии данных.

Формула на случай неудачи восстановления доступа:

восстановленный процесс = новый аккаунт + сохраненные данные

2.3. Потеряны данные

Сервис доступен и вход работает, но данные удалены или повреждены.

Здесь нужна заранее подготовленная копия данных, на основании которой можно вернуть состояние.

Формула:

восстановленный процесс = старый аккаунт + сохраненные данные

Во всех сценариях сохраненные данные служат последней опорой. Они не всегда нужны для восстановления: при потере доступа сначала можно вернуть прежний аккаунт. Но если доступ окончательно утрачен или исчез сам сервис, продолжить процесс без копии данных уже не получится.

3. Практические принципы

После такой схемы может показаться, что следующий шаг — провести полный аудит цифровой жизни: выписать все процессы, найти все сервисы, построить карту зависимостей и заранее придумать план миграции.

На практике это слишком сложно, да и не нужно. Во-первых, человек не держит в голове полный список своих процессов и связанных с ними сервисов. Они прорастали в нашу жизнь годами. Во-вторых, заранее проектировать будущую миграцию бессмысленно. Через несколько лет цифровой ландшафт скорее всего значительно изменится: появятся новые сервисы, старые исчезнут.

Начать можно с того, что уже есть.

Менеджер паролей — это не только хранилище секретов. Это готовый список цифровых сервисов, которыми вы пользуетесь. Достаточно открыть список и пройти его последовательно. Заодно почистить мусор.

Дальше идем по списку.

1. Порядок в доступах. Во всех ценных аккаунтах провести ревизию раздела "безопасность аккаунта": пароль, мультифактор, процедура восстановления.

2. Сохранность данных. Для важных сервисов понять, что произойдет, если аккаунт станет недоступен. Есть ли возможность сделать экспорт данных в переносимом формате.

3. Проверка восстановления. Попробовать из этих данных вернуть функцию: в том же сервисе, проверить переносимость формата.

4. Что я делал

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

Аккаунты связаны процедурами восстановления. Эти связи образуют собственную инфраструктуру доверия. Если один аккаунт выпадет, это затронет все завязанное на него подмножество.

4.1. Наводим порядок в доступах

Конкретные действия стали понятны, когда я посмотрел на аккаунты как на граф зависимостей. Получился такой список задач.

1. Найти корни в системе зависимостей. Корень — это аккаунт, который может использоваться для восстановления других сервисов, но сам при этом не должен опираться на другой аккаунт. Его последняя опора существует отдельно — резервные коды или другой секрет, сохраненный независимо.

2. Убрать циклические зависимости. Если аккаунт A восстанавливается через B, а B через A, это не две независимые точки восстановления, а замкнутый круг.

3. Разделить контуры по юрисдикции. Если восстановление одного контура проходит через другой, будет то, что у меня случилось с Facebook.

Сначала определил два контура: российский и внешний.

В российском контуре центральным узлом стал Яндекс. Здесь ситуация не очень каноничная: последняя точка восстановления находится не в секрете на физическом носителе, а в процедуре подтверждения личности через саппорт.

Во внешнем контуре корнем стал Google. Я отвязал от него российский номер телефона как второй фактор и Яндекс-почту как резервный адрес. Теперь восстановление Google не зависит от российского контура, а последняя опора находится в резервных кодах, сохраненных отдельно от любых других сервисов.

После этого я прошелся по остальным аккаунтам. Во всех значимых сервисах, где это было возможно, убрал зависимость от SMS и перевел второй фактор на TOTP-коды. Это особенно критично для внешнего контура, если у вас есть только российский номер.

Отдельно можно выделить почты, которые я исторически использовал для второстепенных регистраций: Rambler и Proton. Они не являются основой для восстановления критичных аккаунтов, а обслуживают свой уровень менее важных сервисов. Сами при этом опираются на корни своих контуров.

Получились такие 2 дерева:

	 российский контур             внешний контур          

  дейтинг  ...  дискаунтеры   файлопомойки  ...  форумы
          \   /                         \   /      
    Хабр  Rambler  VK         Facebook  Proton  GitHub   
       \    │     /                  \    │    /
        \   │    /                    \   │   /
          ЯНДЕКС                        GOOGLE
            │                             │
   подтверждение личности           резервные коды
      через саппорт                 физический мир      

4.2. Сохраняем данные

Я выделяю несколько типов данных по тому, откуда они берутся и как их готовить к бэкапу.

4.2.1. Источник данных у меня

В этом случае данные уже находятся под моим контролем. Например: фотоархив, документы, прочие файлы. Про личный архив я уже писал отдельно в статье «Личный архив: сбор, бэкап, таймлайн фотографий». Здесь задача понятная: обеспечить независимые копии, которые переживут поломку устройства, случайное удаление или физическую потерю.

Отдельный случай — данные, где важна история изменений. Например, исходный код, конфиги и заметки, для которых есть системы контроля версий. Там есть механизм зеркалирования.

4.2.2. Источник данных в сервисе

В этом случае данные существуют только внутри чужого сервиса. Например: контакты, задачи в менеджере задач, календарь, почта, документы в облачных редакторах, настройки сервисов.

Для таких данных важно иметь экспорт в переносимом формате. Не нужно заранее выбирать замену каждому сервису. Главное — сохранить возможность забрать свои данные и продолжить работу в другом месте.

Это, кстати, становится одним из критериев выбора новых и аудита старых сервисов: насколько легко из них забрать свои данные.

4.2.3. Секреты доступов

Есть еще один особый класс данных: то, что не является содержимым процессов, но на чем держится вся цифровая инфраструктура. Это: данные менеджера паролей, секреты TOTP-аутентификации, резервные коды.

Здесь есть нюанс: инструменты безопасности сами могут стать новой зависимостью.

Например, TOTP-аутентификатор выглядит просто как приложение для генерации кодов. Но настоящие данные находятся не в приложении, а в секретах, на основе которых эти коды создаются. Если эти секреты хранятся только внутри облака конкретного аутентификатора, появляется новый поставщик, от которого зависит доступ к другим сервисам.

Когда я это понял, я стал выбирать аутентификатор, у которого TOTP-секреты под моим контролем и есть экспорт-импорт. Я выбрал Ente Auth.

Секреты доступов у меня — это отдельный шифрованный архив, в котором:

• экспорт менеджера паролей;

• TOTP-секреты;

• резервные коды.

Ключ к архиву — мастер-пароль — хранится отдельно от самого архива и записан на бумаге.

4.2.4 Схема целиком

Данные копируются в два облачных хранилища разных контуров и на офлайн-накопитель. При этом способ подготовки зависит от типа данных: локальные данные резервируются напрямую, данные из сервисов сначала экспортируются, а секреты доступов собираются в отдельный зашифрованный архив. Для синхронизации я использую rclone, который упоминал в прошлой статье.

                        ДАННЫЕ

        ┌──────────────────┬──────────────────┐
        │                  │                  │

 Источник у меня    Источник в сервисе   Секреты доступа

    фотоархив           задачи          менеджер паролей
     заметки           календарь          TOTP-секреты
       код               почта            recovery-коды
    документы           контакты

        │                   │                  │
        |
        |                экспорт         зашифрованная
        |                сервиса             копия
	    |                           (мастер-пароль на бумаге)

        └───────────────────┴──────────────────┘
                            │

            ┌───────────────┼───────────────┐
            │               │               │

         облако 1        облако 2        офлайн-
         контур A        контур B      накопитель

4.3 Проверка восстановления

Последний шаг — проверить не только наличие копий, но и саму возможность восстановления.

Разные типы данных проверяются по-разному.

Для данных, которые хранятся локально, достаточно убедиться, что резервные копии существуют и файлы из них открываются.

Для данных из сервисов важно проверить, что экспорт действительно содержит нужную информацию и находится в переносимом формате. В идеале — один раз попробовать импортировать его в тестовую среду, чтобы убедиться, что этот путь реально работает.

Для секретов доступа нужно проверить, что мастер-пароль работает, а из архива можно получить необходимые данные для восстановления.

Для ключевых аккаунтов стоит отдельно пройти путь восстановления: "забыл пароль". Не обязательно реально сбрасывать пароль — важно убедиться, что цепочка восстановления понятна и приводит к ожидаемой рутине.

5. Где остановиться

Полностью убрать зависимости невозможно. Более того, после всей этой работы в системе все равно останутся крупные узлы, потеря которых вызовет проблемы.

Google — пример такого узла во внешнем контуре. На нем держится значительная часть дерева аккаунтов, за исключением экосистемы Apple. Если я потеряю доступ к Google, цепочка восстановления остальных аккаунтов окажется нарушена. Где-то помогут активные сессии, где-то удастся сменить почту без подтверждения старой, а где-то доступ уже будет не вернуть. Тогда придется создавать новый корень и постепенно перепривязывать к нему все, что удалось сохранить.

Можно было бы заранее сделать диверсификацию корней. Но, как и любое усложнение, это имеет свою цену: дополнительные аккаунты и процедуры их восстановления. Поэтому для меня на сегодняшний день баланс остается на стороне одного корня в каждой юрисдикции.

В конечном счете задача не в том, чтобы построить систему без единой точки отказа. Реалистичнее честно зафиксировать свои зависимости и иметь план восстановления. Так потенциальная катастрофа превращается в обозримый и посильный список задач.