Парольный менеджер, passkey и двухфакторная защита: как собрать систему доступа

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

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

Система начинается с корня доверия

Корень доверия — то, через что восстанавливаются остальные аккаунты. Обычно это разблокировка устройства, номер телефона, основная почта и менеджер паролей. Иногда к ним добавляются корпоративный SSO, аппаратный ключ или администратор домена. Запишите эти элементы на отдельном листе инвентаря, но не записывайте в него сами пароли, recovery-коды и полные секретные ключи. Реестр должен отвечать на вопрос «где и как восстановить», а не становиться новой утечкой.

• Устройство: кто контролирует его, как оно блокируется, получает ли обновления и что произойдёт при потере.

• Основная почта: какие адрес и номер участвуют в восстановлении, включён ли сильный второй фактор, нет ли неизвестной пересылки.

• Менеджер: как защищён вход, где официальный recovery flow, можно ли безопасно экспортировать данные при смене поставщика.

• Резерв: где находится независимый recovery-код или второй ключ и кто имеет право им воспользоваться.

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

Как выбирать менеджер без рейтинга брендов

Менеджер паролей хранит множество ценных секретов и поэтому требует более строгого выбора, чем обычное приложение. Сравнивайте не рекламные заявления, а проверяемые свойства. Поставщик должен ясно объяснять модель шифрования, поддерживаемые платформы, способ восстановления, доступ к экспорту, реакцию на потерю устройства и правила для семейного или командного доступа. Заявление «zero knowledge» само по себе недостаточно без технического описания и актуального аудита конкретной реализации.

Создайте master secret, который не использовался нигде больше. Сохраните recovery material отдельно от устройства с менеджером. Если сервис допускает второй аппаратный ключ, зарегистрируйте его и положите в другое контролируемое место. Не фотографируйте recovery-коды в галерею, автоматически синхронизируемую тем же аккаунтом: такая копия разделяет один failure domain с основной системой.

Пароль, passkey и MFA решают разные задачи

Уникальный длинный пароль защищает от переноса утечки одного сервиса на другой, но остаётся секретом, который можно ввести на поддельном сайте. Одноразовый код добавляет второй шаг, однако код тоже можно выманить и немедленно использовать. Passkey на базе WebAuthn использует закрытый ключ и credential, связанный с конкретным relying party. Именно эта привязка, а не внешний вид страницы, даёт устойчивость к поддельному домену.

Это не означает, что passkey «неуязвим». Кража разблокированного устройства, вредоносное ПО, похищенная сессия, ошибочно подтверждённое действие и слабый recovery flow остаются отдельными угрозами. Синхронизируемый passkey может быть доступен на других устройствах экосистемы, device-bound credential — нет; точное поведение зависит от платформы и сервиса. До удаления пароля выясните, как войти при потере устройства и можно ли зарегистрировать независимый резерв.

Практический приоритет такой: для почты, менеджера, финансовых, административных и рабочих аккаунтов выбирайте phishing-resistant метод, если он действительно доступен и восстановление проверено. Если нет — включите наиболее сильный поддерживаемый второй фактор. Код из приложения или даже SMS как временный слой лучше отсутствия MFA, но не называйте их равными passkey или аппаратному ключу. Заодно научитесь проверять признаки фишинга: не все каналы и операции защищены WebAuthn.

Пошаговая схема миграции аккаунтов

Создайте таблицу миграции. Одна строка — один аккаунт, а не один пароль. Минимальные поля: приоритет, сервис, текущий способ входа, целевой способ, резервный фактор, официальный recovery path, дата контрольного входа и статус неизвестных сессий. Секреты и recovery-коды в таблицу не помещайте. Статус может быть INVENTORY, READY, MIGRATED, RECOVERY_TESTED или BLOCKED с причиной.

В волне 0 обновите устройство, проверьте блокировку экрана и создайте независимое место для recovery. В волне 1 не импортируйте сразу весь браузерный архив: сначала перенесите почту и сам менеджер, выйдите и вернитесь на втором устройстве. Экспортный файл после переноса удалите штатным способом и убедитесь, что он не остался в Downloads, корзине и облачной синхронизации.

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

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

Как провести репетицию потери устройства

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

• Второе устройство получает доступ только после вашей локальной проверки и сильного фактора.

• Резервный ключ или код читается и соответствует нужному аккаунту, но сам код не копируется в журнал теста.

• Уведомление о новом входе приходит по контролируемому каналу.

• Список устройств, passkey и сессий понятен; неизвестные элементы можно отозвать.

• Официальная инструкция восстановления сохранена без секретов и доступна вне основного устройства.

Запишите результат: дата, проверенный аккаунт, устройство, пройденные шаги и проблема. Не записывайте пароль, код или закрытый ключ. Если recovery не прошёл, верните статус строки в BLOCKED, восстановите прежний подтверждённый доступ и разберитесь с официальной поддержкой. Не продолжайте массовую миграцию, пока корневой аккаунт остаётся хрупким.

Ограничения и практический следующий шаг

Технические рекомендации NIST, CISA и NCSC полезны как модель угроз, но не задают российские юридические обязанности и не подтверждают безопасность конкретного продукта. Перед использованием менеджера в команде проверьте договор, место хранения данных, роли, offboarding и поддержку. Для shared accounts по возможности перейдите на индивидуальные учётные записи; если сервис этого не умеет, явно назначьте владельца и порядок смены доступа.

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

Что читать дальше

• проверять признаки фишинга

• план действий после компрометации

• перенести систему доступа на команду