Пару лет назад я потерял доступ к аккаунту Facebook. Второй фактор был основан на SMS с кодом. Я логинился, ждал, пробовал на следующий день — ничего. Стало понятно: сообщения от Facebook на мой российский номер больше не приходят. Если бы мне тогда было очень надо, восстановить доступ было можно — поддержка предлагала прислать селфи с паспортом. Я тогда решил, что это того не стоит. Это был не самый важный для меня сервис.
Но ситуация заставляет ощутить, насколько незащищенными мы можем оказаться в нашей зависимости от цифровой экосистемы. Ведь почти все процессы повседневности так или иначе уже завязаны на цифровые решения: работа, личные дела, финансы, здоровье, коммуникации, поездки, спорт, развлечения. И когда хотя бы один из сервисов прекращает работу, для нас перестает работать не столько приложение или сайт, сколько реальный процесс, который на нем основан.
В этой статье я попробую разобраться, как сделать свою цифровую инфраструктуру устойчивее, не превращая её поддержку в отдельный проект.
Под цифровой устойчивостью я понимаю способность поддерживать цифровую основу своих реальных процессов. И имеет она две опоры.
-
Безопасность. Это про ограничение несанкционированного доступа. Риски: доступ к данным, действия от моего имени, угон аккаунта и потеря связанных с ним данных.
-
Зависимость от поставщика. Это про то, насколько я могу полагаться на сервис. Риски: технические сбои, внезапное изменение условий доступа, закрытие продукта.
В корпоративной среде этими опорами занимаются специально обученные люди. Они планируют разграничение доступа, учитывают угрозы, считают риски со стороны провайдера и так далее. Под это выделены бюджеты, налажены процессы, есть ответственность. Риски для компании вполне осязаемы — деньги и репутация.
В частной жизни, если честно, мы об этом не сильно задумываемся. Безопасность неплохо покрывается рекомендациями самих сервисов: уникальный пароль, мультифактор, резервный способ входа. А популярные сервисы достаточно стабильны, поэтому более вероятной причиной переезда на другой сервис будет появление нового, более удобного конкурента.
В последние годы добавился еще один фактор риска в вопросах зависимости от поставщика. Внешний по отношению к паре клиент-сервис регулятор. Причем в каждой юрисдикции регулятор свой, со своими правилами. История с Facebook как раз про это: сам сервис в одной юрисдикции, мобильный провайдер — в другой. Фрагментация интернета по регуляторным зонам заставляет нас брать ответственность за свою цифровую устойчивость на себя.
1. Цепочка зависимостей
Я ее представляю так.
РЕАЛЬНЫЙ ПРОЦЕСС ↓ ЦИФРОВОЙ СЕРВИС ↓ ДОСТУП ↓ ДАННЫЕ
Цепочка может оборваться на любом из трёх звеньев:
-
сервис стал недоступен;
-
потерян доступ;
-
потеряны данные.
Это и есть основные сценарии, в которых нам предстоит восстанавливаться. Цель во всех случаях одна — вернуть функциональность реального процесса.
2. Сценарии
2.1. Сервис недоступен
В этом случае прежнюю цифровую основу процесса уже не вернуть — её приходится пересоздавать на другом сервисе.
Для этого понадобится заранее сохранённая копия данных в переносимом формате. Без неё — или с данными, которые сможет прочитать только прежний сервис, — новый инструмент окажется пустым и процесс придётся собирать с нуля.
Формула:
восстановленный процесс = новый сервис + сохраненные данные
2.2. Потерян доступ
Сервис продолжает работать, аккаунт и данные существуют, но войти не получается.
Сначала нужно попытаться вернуть доступ к тому же аккаунту: через резервный способ входа или процедуру восстановления. Если это удалось, процесс возвращается целиком.
Но доступ можно и не вернуть — аккаунт так и останется закрытым для владельца. Тогда придётся создать новый аккаунт и восстановить состояние из копии данных.
Формула на случай неудачи восстановления доступа:
восстановленный процесс = новый аккаунт + сохраненные данные
2.3. Потеряны данные
Сервис доступен и вход работает, но данные удалены или повреждены.
Здесь нужна заранее подготовленная копия данных, на основании которой можно вернуть состояние.
Формула:
восстановленный процесс = старый аккаунт + сохраненные данные
Во всех сценариях сохранённые данные служат последней запасной опорой. Они не всегда нужны для восстановления: при потере доступа сначала можно вернуть прежний аккаунт. Но если доступ окончательно утрачен, аккаунт удалён или исчез сам сервис, продолжить процесс без копии данных уже не получится.
3. Практические принципы
После такой схемы может показаться, что следующий шаг — провести полный аудит цифровой жизни: выписать все процессы, найти все сервисы, построить карту зависимостей и заранее придумать план миграции.
На практике это слишком сложно, да и не нужно. Во-первых, человек не держит в голове полный список своих процессов и связанных с ними сервисов. Они формировались годами, постепенно прорастая в жизнь. Во-вторых, заранее проектировать будущую миграцию бессмысленно. Через несколько лет цифровой ландшафт скорее всего значительно изменится: появятся новые сервисы, старые исчезнут, условия поменяются.
Начать можно с того, что уже есть.
Менеджер паролей — это не только хранилище секретов. Это готовый список цифровых сервисов, которыми вы пользуетесь. Достаточно открыть список и пройти его последовательно. Заодно почистить мусор.
Дальше работа идет по списку.
-
Порядок в доступах. Во всех ценных аккаунтах провести ревизию раздела «безопасность аккаунта»: пароль, мультифактор, процедура восстановления.
-
Сохранность данных. Для важных сервисов понять, что произойдёт, если аккаунт станет недоступен. Есть ли возможность сделать экспорт данных в переносимом формате.
-
Проверка восстановления. Попробовать из этих данных вернуть функцию: в том же сервисе, проверить переносимость формата.
4. Что я делал
Когда передо мной оказался список сервисов из менеджера паролей, в нём было больше сотни аккаунтов из разных юрисдикций. Просто идти по списку и в каждом аккаунте «наводить порядок» в вопросах безопасности по рекомендациям разработчиков? Казалось, что этого недостаточно.
Аккаунты существуют не по отдельности. Они связаны резервными почтами, телефонами и процедурами восстановления. Эти связи образуют собственную инфраструктуру доверия. Если один из узлов этой инфраструктуры выпадет, вопрос безопасности встанет уже для всего подмножества зависимостей.
4.1. Наводим порядок в доступах
Ясность в отношении конкретных действий пришла, когда я начал смотреть на список аккаунтов как на граф зависимостей. Список получился такой.
-
Найти корни в системе зависимостей. Корень — это аккаунт, который может использоваться для восстановления других сервисов, но сам при этом не должен опираться на другой аккаунт. Его последняя опора существует отдельно — резервные коды или другой секрет, сохранённый независимо.
-
Убрать циклические зависимости. Если аккаунт A восстанавливается через B, а B через A, это не две независимые точки восстановления, а замкнутый круг.
-
Разделить контуры по юрисдикции. Если восстановление одного контура проходит через другой, будет то, что у меня случилось с 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 удалит мой аккаунт, остальные сервисы не исчезнут вместе с ним, но окажутся под угрозой. Где-то помогут живые сессии, где-то получится сменить почту без подтверждения старой, а где-то восстановление уже окажется невозможно. Если это произойдёт, придётся создавать новый корень и постепенно перепривязывать к нему всё, что удалось сохранить.
Можно было бы заранее сделать диверсификацию корней. Но, как и любое усложнение, это имеет свою цену: дополнительные аккаунты, секреты, процедуры восстановления. Поэтому для меня на сегодняшний день баланс остаётся на стороне одного корня в каждой юрисдикции.
В конечном счёте задача не в том, чтобы построить систему без единой точки отказа — таких систем не существует. Важно другое: знать свои точки зависимости, понимать масштаб последствий и иметь путь восстановления. Устойчивость начинается там, где катастрофа превращается в обозримый и посильный список задач.
ссылка на оригинал статьи https://habr.com/ru/articles/1063012/