• Опубликовано: 20 сентября 2026 г.

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

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

Проблема здесь не в MFA. Клиника включила второй фактор как набор галочек, но не спроектировала жизненный цикл доступа: кто владеет учётной записью, какой метод разрешён, что делать при замене телефона, где лежит резерв, как отозвать устройство и кто вправе запустить восстановление.

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

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

MFA — не магический щит, а второй рубеж

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

Актуальное руководство NIST по цифровой идентификации отдельно объясняет устойчивость к фишингу: ручной ввод одноразового кода не связывает подтверждение с конкретной сессией и поэтому сам по себе не считается фишинг-устойчивым. WebAuthn/FIDO2 приводит как пример подхода, где ключ связан с именем проверяющей стороны. CISA также рекомендует организациям стремиться к фишинг-устойчивым методам, а number matching использовать как более сильный промежуточный вариант для push-подтверждений.

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

Сначала найдите аккаунты, которые открывают остальные двери

Не все учётные записи одинаково важны. Потеря доступа к сервису заявок неприятна. Потеря контроля над корпоративной почтой может позволить сбросить пароли к десяткам сервисов. Потеря домена и DNS способна затронуть сайт, почту, подтверждение владения и доверие к коммуникациям.

Первый список обычно включает:

• аккаунт регистратора домена и управление DNS;
• главного администратора корпоративной почты и каталога пользователей;
• облачную инфраструктуру, виртуальные серверы и резервные копии;
• МИС, CRM и интеграционные панели с административными правами;
• сайт, CMS, аналитику, рекламные кабинеты и формы;
• телефонию, номера, маршрутизацию и записи разговоров;
• бухгалтерские, кассовые и банковские контуры — по правилам владельцев этих процессов;
• удалённый доступ и учётные записи подрядчиков.

Отдельно отметьте аккаунты восстановления: почта, на которую приходят ссылки сброса; номер телефона; второй администратор; доверенное устройство. Иногда именно они являются настоящим верхним уровнем, хотя в реестре активов про них забыли.

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

Карта доступа должна отвечать на семь вопросов

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

Карта не должна становиться хранилищем секретов. Она показывает маршрут к контролируемому хранилищу и распределение ответственности. Если документ, открываемый всей регистратурой, содержит резервные коды администратора, удобство уничтожает смысл второго фактора.

Почему общий телефон — хрупкая опора

На первый взгляд общий смартфон кажется удобным: он лежит в клинике, и код доступен смене. Но у такого решения быстро появляются вопросы. Кто знает PIN? Что произойдёт ночью? Можно ли установить на него личное приложение? Кто отвечает за обновления? Как отозвать доступ у сотрудника, не меняя всё устройство? Что делать при поломке или потере?

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

Общий номер иногда остаётся вынужденным временным вариантом. Тогда его нужно назвать временным, ограничить круг сервисов, описать хранение устройства и поставить дату перехода. Иначе исключение незаметно становится архитектурой на годы.

Выбирайте метод по риску, а не по привычке

У клиники редко есть возможность одним днём перевести все системы на аппаратные ключи. Но можно принять лестницу методов.

1. Фишинг-устойчивый метод, если сервис поддерживает passkey, WebAuthn или аппаратный ключ и его можно нормально администрировать.
2. Приложение-аутентификатор с одноразовым кодом, когда более сильный метод недоступен. Оно лучше одного пароля, но код всё ещё можно выманить.
3. Push с number matching и понятным контекстом входа как промежуточный вариант, а не бездумное «разрешить».
4. SMS или email-код — только с пониманием ограничений и защитой самого номера или почты.

Это не рейтинг ради моды. Метод должен соответствовать сервису, устройствам, возможности восстановления и навыкам пользователей. Аппаратный ключ бесполезен, если он один и лежит в ноутбуке, который может исчезнуть вместе с ним. Passkey не решает задачу, если никто не знает, в каком контуре он синхронизируется и как отозвать потерянное устройство.

Начните с администраторов, но не забудьте обычных пользователей

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

После верхнего уровня двигайтесь по последствиям:

• сотрудники с доступом к персональным и медицинским данным;
• бухгалтерия и финансы;
• руководители с правом согласования;
• удалённые пользователи;
• регистратура и колл-центр;
• технические и сервисные аккаунты.

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

Подрядчик не должен входить под директором

Фраза «скиньте код, мы быстро посмотрим» кажется мелочью, пока не возникает инцидент. Если подрядчик использует учётную запись директора, журнал показывает директора. Невозможно понять, кто и зачем изменил настройку, а отзыв доступа требует менять способ входа владельца.

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

Эта логика продолжает тему общего пароля администратора и временного доступа подрядчиков. MFA усиливает идентичность, но не исправляет ситуацию, где одной идентичностью пользуются пять человек.

Резервный способ — часть защиты, а не лазейка

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

Для каждого критичного сервиса проверьте:

• какие каналы восстановления существуют фактически;
• кто контролирует резервную почту и номер;
• можно ли удалить устаревший метод;
• приходят ли уведомления об изменении факторов;
• где хранятся резервные коды;
• можно ли восстановить доступ без единственного человека;
• как подтверждается личность при обращении в поддержку;
• как быстро отзываются потерянные устройства и сессии.

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

Сценарий увольнения важнее идеальной инструкции

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

Маршрут увольнения включает:

1. список именных учётных записей и административных ролей;
2. отзыв аутентификаторов и завершение сессий;
3. замену владельца общих ресурсов без передачи личного аккаунта;
4. проверку резервных контактов;
5. ротацию секретов, которые могли быть известны человеку;
6. сохранение нужных журналов по принятому порядку;
7. контрольный вход нового владельца.

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

Составной сценарий: когда защита есть, а доступа нет

Ниже — иллюстративная реконструкция типовой ситуации, не описание конкретной клиники.

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

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

Исправление началось не с отключения MFA. Владельца организации подтвердили по процедуре сервиса, вернули доступ, создали второго независимого администратора, зарегистрировали два управляемых метода и вынесли аварийный комплект в хранилище с контролируемым доступом. Затем команда нарисовала зависимости: домен восстанавливает почту, почта — другие сервисы, поэтому домен и почта не могут иметь один и тот же единственный резерв.

Главный урок: резервирование — это не количество кодов. Это независимость маршрутов.

Уведомление MFA тоже может стать атакой

Пользователь получает пять push-запросов подряд и нажимает «разрешить», чтобы телефон перестал вибрировать. Такой сценарий называют MFA fatigue. Защита формально включена, но интерфейс приучил человека подтверждать непонятное действие.

Сотрудникам нужен короткий алгоритм:

• не подтверждать запрос, который они не инициировали;
• сообщить в понятный канал безопасности;
• сменить пароль по проверенному адресу, если есть подозрение компрометации;
• завершить другие сессии;
• проверить изменения факторов и правил пересылки почты;
• не диктовать код тому, кто представился поддержкой.

Number matching помогает, когда пользователь видит число в активной сессии и вводит его в приложении, но не заменяет проверку адреса и контекста. Для критичных ролей предпочтительнее фишинг-устойчивый метод, который не полагается только на внимательность человека.

Включайте волнами, а не большим взрывом

Одновременное включение MFA во всех сервисах выглядит решительно, но делает ошибки зависимыми: сотрудники теряют доступ сразу к почте, расписанию и поддержке. Лучше выбрать волну, проверить восстановление и только затем расширять охват.

Практический порядок:

Волна 0 — инвентаризация. Владельцы, администраторы, факторы, резервы, зависимости.

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

Волна 2 — системы с чувствительными данными и удалённым доступом. МИС, CRM, VPN, панели поддержки.

Волна 3 — остальные сотрудники. Обучение, выдача методов, поддержка смен.

Волна 4 — подрядчики и исключения. Убираются общие аккаунты, назначаются сроки, закрываются временные обходы.

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

Подготовьте поддержку до включения

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

Подготовьте одностраничную инструкцию для конкретного сервиса:

• как выглядит правильный адрес входа;
• какой метод используется;
• что пользователь увидит;
• куда обратиться;
• чего поддержка никогда не попросит;
• что делать при потере устройства;
• сколько времени занимает стандартное восстановление;
• когда случай становится инцидентом.

Не включайте в неё реальные секреты и скриншоты с персональными данными. Обучение проводите на тестовой учётной записи. Сотрудник должен один раз самостоятельно выполнить вход и отказать неожиданному запросу.

Что делать, если сервис не поддерживает MFA

Отсутствие второго фактора — не повод делать вид, что риска нет. Зафиксируйте ограничение и компенсирующие меры:

• уникальный длинный пароль в управляемом хранилище;
• ограничение доступа по сети или VPN, если это допустимо и поддерживается;
• минимальные права;
• отдельная учётная запись без совместного использования;
• уведомления о входах и изменениях;
• короткие сессии для административных действий;
• журналирование и регулярный просмотр;
• план замены сервиса или обновления версии.

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

MFA не отменяет управление устройствами и сессиями

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

Поэтому проект включает:

• инвентаризацию управляемых устройств;
• блокировку экрана и шифрование по политике организации;
• обновления;
• возможность отозвать устройство;
• проверку активных сессий;
• ограничения «запомнить устройство» для критичных ролей;
• отдельные профили для администрирования;
• запрет на сохранение секретов в браузере общего компьютера.

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

Метрики, которые не поощряют галочки

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

Добавьте качественные показатели:

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

Проверка восстановления без настоящей аварии

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

1. новый сотрудник регистрирует разрешённый фактор;
2. устройство теряется и отзывается;
3. основной администратор недоступен;
4. резервный владелец проходит процедуру;
5. старые сессии завершаются;
6. уведомления доходят ответственным;
7. журнал позволяет восстановить последовательность.

После этого можно провести контролируемую проверку на реальном сервисе в согласованное окно, с заранее подтверждённым возвратом. Не экспериментируйте на работающей МИС, домене или почте без резервного доступа.

Красные флаги, которые требуют остановиться

• единственный фактор и резерв находятся на одном телефоне;
• второй администратор никогда не входил и не проверял права;
• резервная почта — личный ящик сотрудника;
• коды пересылаются в общий чат;
• подрядчик использует аккаунт директора;
• после увольнения устройство остаётся зарегистрированным;
• сервис позволяет сбросить MFA через слабый контрольный вопрос;
• команда не знает, как завершить все сессии;
• push-запросы подтверждают «чтобы исчезло»;
• реестр содержит секреты в открытом виде;
• никто не может назвать последний успешный тест восстановления.

Каждый флаг не требует немедленно останавливать клинику. Он требует ограничить изменение, назначить владельца и закрыть конкретный разрыв до следующей волны.

План на десять рабочих дней

День 1–2. Соберите верхние аккаунты и зависимости восстановления.

День 3. Назначьте владельца процесса и второго администратора для каждого критичного контура.

День 4. Выберите разрешённые методы и опишите исключения.

День 5. Подготовьте корпоративное хранилище резервов и порядок доступа.

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

День 7. Проверьте обычный вход, отзыв и recovery.

День 8. Обучите первую группу на тестовом сценарии, включая неожиданный push.

День 9. Подключите следующую систему только после исправления замечаний.

День 10. Зафиксируйте исключения, сроки и решение о следующей волне.

Цель десяти дней — не максимальный охват. Цель — один повторяемый шаблон внедрения, который не зависит от памяти конкретного человека.

FAQ

Нужно ли включать MFA на каждой учётной записи?

Стремиться стоит к широкому охвату, но внедрение разумно вести по риску. Сначала защищают домен, почту, облако, резервные копии, администраторов и удалённый доступ; затем остальные роли. Каждый этап включает восстановление.

Какой второй фактор лучший?

Тот, который соответствует риску и корректно управляется. Для критичных аккаунтов предпочтительны фишинг-устойчивые методы вроде WebAuthn/FIDO2, если сервис их поддерживает. Одноразовый код лучше одного пароля, но не является фишинг-устойчивым.

Можно ли использовать личный телефон сотрудника?

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

Где хранить резервные коды?

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

Что делать при потере телефона?

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

Нужны ли два администратора?

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

Что сделать завтра

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

Затем выберите одну строку и ответьте: если основной владелец сегодня недоступен, сможет ли второй человек восстановить управление, не звоня бывшему сотруднику и не прося подрядчика войти под чужим аккаунтом? Если ответ начинается с «наверное», MFA пока только включена, но ещё не управляется.

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

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

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