Общий пароль администратора почти никогда не появляется как сознательная политика. В день открытия клиники создают одну учётную запись, записывают пароль на листке и передают смене. Потом добавляется второй филиал, удалённый бухгалтер, специалист по рекламе, подрядчик по МИС и новый управляющий. Листок исчезает, а пароль продолжает жить — уже в браузерах, чатах и памяти людей, которых никто не перечислит.
Снаружи всё выглядит удобно. Любой администратор может сесть за свободный компьютер. Никто не ждёт выдачи доступа. Если сотрудник забыл пароль, коллега знает его наизусть. Но эта простота оплачена одной неприятной неопределённостью: система видит имя «administrator», а клиника не знает, какой человек действительно выполнил действие.
Проблема становится заметной после ошибки, увольнения или подозрительного входа. Кто изменил расписание? Кто выгрузил список? Кто дал доступ подрядчику? Можно ли поменять пароль, не остановив две смены? Если ответы зависят от опроса сотрудников, общий пароль уже стал операционным долгом.
Эта статья не предлагает за один вечер запретить все старые входы. Резкий переход способен оставить регистратуру без МИС в начале смены. Задача другая: превратить доступ из устной традиции в управляемый маршрут, где каждому человеку выдана своя роль, сильная проверка входа не мешает работе, а исключения заранее предусмотрены.
Общая учётная запись скрывает не только нарушителя, но и обычную ошибку
Разговор об идентификации часто сводят к поиску виноватого. На практике персональная учётная запись нужна прежде всего для восстановления контекста. Сотрудник мог неумышленно изменить фильтр, перенести запись или выбрать не тот филиал. Если действие связано с человеком и временем, проблему можно спокойно разобрать и улучшить инструкцию.
Под общим именем все действия выглядят одинаково. Руководителю остаются догадки: кто работал за компьютером, не подменял ли коллегу, не сохранился ли сеанс с прошлой смены. Даже хороший журнал теряет ценность, когда идентификатор не соответствует реальному пользователю.
Это влияет и на обучение. Нельзя понять, кому трудно работать с новой функцией и где сотрудник регулярно возвращается к ручному обходу. Персонализация доступа — не надзор ради надзора, а возможность отделить сбой процесса от единичной ошибки.
«Но у нас одна стойка» — не аргумент за один пароль
Один физический компьютер может обслуживать несколько персональных пользователей. Сотруднику не обязательно иметь отдельное устройство; ему нужна собственная идентичность в важных системах. В начале смены он входит под своим именем, в конце — завершает сеанс или блокирует рабочее место.
Если переключение пользователей занимает слишком много времени, это повод улучшить способ входа, а не отказаться от различимости. Возможны быстрые сценарии с менеджером паролей, аппаратным ключом, приложением-аутентификатором или иной поддерживаемой системой. Выбор зависит от конкретной МИС, домена, рабочих мест и политики клиники.
Нужно различать вход в Windows и вход в прикладную систему. Персональная учётная запись на компьютере не гарантирует, что внутри МИС сотрудники не используют общий профиль. И наоборот. Карта доступа должна охватывать оба слоя и внешние кабинеты.
Инвентаризация начинается не с людей, а с систем
Если попросить список сотрудников, вы не увидите сервисные учётные записи, интеграции и старые кабинеты подрядчиков. Поэтому сначала составляют перечень систем, где действие может повлиять на пациентов, деньги, данные или доступность.
Обычно туда входят МИС, телефония, электронная почта, CRM, кассовое решение, сайт и домен, облачные диски, PACS, видеонаблюдение, сетевое оборудование, удалённый доступ, учёт рекламы и кабинеты поставщиков. В конкретной клинике список будет другим.
Для каждой системы фиксируют:
- адрес входа и владельца договора;
- административные и обычные роли;
- способ восстановления доступа;
- привязанный телефон и почту;
- наличие MFA;
- активных пользователей и подрядчиков;
- сервисные интеграции;
- место хранения аварийных данных;
- ответственного за периодический пересмотр.
Не включайте в такую таблицу сами пароли. Инвентаризация должна показать владение и маршрут, а секреты хранят в предназначенном для этого защищённом инструменте.
Персональная запись не означает одинаковые права для всех
Самая простая ошибка миграции — создать каждому своё имя, но скопировать права общего администратора. Прослеживаемость станет лучше, однако любой пользователь по-прежнему сможет менять критические настройки.
Роль должна соответствовать работе. Регистратору нужны расписание, карточка обращения и предусмотренные операции с записью. Старшему администратору могут быть нужны отчёты смены и управление отдельными справочниками. IT-специалисту — технические настройки, но не обязательно медицинское содержание. Подрядчику — временный доступ к конкретному компоненту.
Принцип минимальных полномочий не требует выдать настолько мало прав, что работа остановится. Он требует убрать функции, которые человек не использует в обычной роли, и отдельно описать повышение доступа для редких задач.
Лучший тест роли — не список галочек, а сценарии смены. Может ли сотрудник записать пациента, перенести визит, оформить предусмотренную оплату, закрыть рабочий день и передать исключение старшему? Если нет, роль непрактична. Если он может менять глобальные настройки и выгружать всё без рабочей необходимости, роль слишком широка.
MFA защищает вход, но не исправляет общую идентичность
Двухфакторная или многофакторная проверка добавляет второй независимый признак. Она полезна против украденного или угаданного пароля, но не делает общую учётную запись персональной.
Если код приходит на один телефон, лежащий в ящике регистратуры, система по-прежнему не знает, кто вошёл. Более того, устройство становится новой общей точкой отказа. Если оно разрядилось, потерялось или осталось у ушедшего руководителя, доступ остановится.
Поэтому порядок обычно такой: определить владельцев, создать персональные записи и роли, затем подключать подходящий фактор. Для некоторых систем эти шаги идут вместе, но смысл остаётся тем же.
Подробная очередность подключения разобрана в статье где включать MFA в клинике сначала, чтобы не устроить хаос. Здесь важно одно: MFA — часть системы доступа, а не наклейка на старый общий пароль.
Второй фактор должен учитывать реальную смену
Хороший способ подтверждения входа не заставляет сотрудника использовать личный телефон без заранее согласованных правил. Не каждый человек готов устанавливать рабочее приложение на личное устройство, а клиника не должна строить критический процесс на молчаливом предположении.
В зависимости от возможностей системы можно использовать корпоративные устройства, аппаратные ключи, приложения-аутентификаторы, сертификаты или другие методы. SMS иногда остаётся единственным доступным вариантом, но у него есть ограничения, которые нужно учитывать.
Важно предусмотреть замену телефона, потерю ключа, отсутствие связи, отпуск и новую смену. Восстановление не должно сводиться к звонку знакомому подрядчику: нужен проверяемый маршрут с подтверждением личности и уведомлением владельца системы.
Перед массовым включением протестируйте фактор на одной некритичной роли и одном резервном рабочем месте. Отдельно проверьте ночную смену и момент, когда ответственный руководитель недоступен.
Запасные коды нельзя приклеивать к монитору
Система может выдавать резервные коды или иной аварийный способ. Если хранить их рядом с компьютером, второй фактор фактически исчезает. Если их знает только один человек, клиника рискует остаться без доступа.
Аварийные данные хранят в защищённом месте с ограниченным доступом и журналом использования. Это может быть корпоративный менеджер секретов или иной принятый клиникой механизм. Важно, чтобы существовали минимум два уполномоченных владельца процесса, но не весь персонал.
После использования аварийный код заменяют, а событие разбирают. Цель не наказать сотрудника, а понять, почему обычный вход не сработал: потерян фактор, сломано устройство, неверно организована смена или роль не готова.
Раз в оговорённый период проводят учебное восстановление без раскрытия секретов в чате. Если уполномоченные люди не могут найти инструкцию и получить доступ в допустимое время, запасной сценарий существует только на бумаге.
Подрядчик не должен входить под именем директора
Удалённому специалисту часто дают самый простой доступ — логин владельца и пароль из сообщения. Он решает задачу, браузер сохраняет сеанс, а клиника забывает о выданном секрете. Через месяц никто не уверен, остался ли доступ активным.
Для подрядчика нужна отдельная идентичность или контролируемый временный сеанс. Указывают цель, систему, срок, допустимые действия и сотрудника клиники, который принимает результат. После завершения доступ отзывают и проверяют созданные учётные записи, ключи и интеграции.
Если поставщик настаивает на общем административном пароле, попросите показать, как он обеспечивает различимость своих инженеров и отзыв полномочий. Ответ должен быть техническим и организационным, а не «у нас все надёжные».
Постоянный сервисный аккаунт иногда необходим. Тогда он не принадлежит конкретному сотруднику подрядчика: его использование контролируется системой, секрет регулярно меняется, вход ограничен по условиям, а журнал доступен клинике.
Сервисная учётная запись — не запасной логин сотрудника
Интеграции, роботы и фоновые задачи могут работать от специальных учётных записей. Их нельзя смешивать с человеческими. Если сервисный пароль знают администраторы и используют для входа, любое действие снова становится неразличимым, а смена секрета рискует остановить интеграцию.
Для сервисной записи фиксируют назначение, владельца, зависимые системы, срок и способ ротации секрета. Интерактивный вход запрещают там, где это возможно. Права ограничивают конкретной функцией.
Перед изменением пароля нужно знать, где он используется. Иначе безопасная операция неожиданно отключит обмен данными. Карта зависимостей важнее частой ротации вслепую.
Если назначение сервисной записи никто не может объяснить, её не блокируют резко в рабочее время. Сначала проверяют журналы, конфигурацию и тестовый контур, затем составляют план отключения с возможностью возврата.
Увольнение показывает качество системы доступа
В спокойный день кажется, что пароль можно поменять позднее. В последний день сотрудника выясняется, сколько систем связано с его телефоном, почтой и личным браузером. Чем больше общих записей, тем шире последствия одной ротации.
Персональные учётные записи позволяют закрыть конкретного человека, не заставляя всю клинику заново входить во все кабинеты. Но только если активы действительно оформлены на организацию, а восстановление не привязано к личному номеру.
Процесс увольнения должен включать не только МИС. Проверяют почту, телефонию, CRM, удалённый доступ, домен, облака, рекламу, мессенджеры, физические ключи и устройства. Отдельный маршрут дан в статье врач ушёл из клиники: как закрыть доступы и не потерять рабочий процесс.
Не нужно ждать увольнения. Те же действия применимы при переводе, длительном отпуске и изменении обязанностей. Право, которое когда-то было нужно, не должно оставаться навсегда.
Передача смены не требует передачи пароля
Администраторы часто объясняют общий логин непрерывностью: вечерняя смена должна продолжить работу с тем же расписанием. Но состояние процесса и личность пользователя — разные вещи.
Запись пациента, очередь задач и статус звонка должны храниться в системе, а не в незакрытом сеансе прошлого сотрудника. Новая смена входит под своим именем и видит разрешённый общий рабочий контекст.
Если после выхода одного пользователя другой теряет незавершённые задачи, проблема находится в организации процесса или возможностях системы. Её не стоит скрывать общей учётной записью. Создайте очередь смены, статусы и правило передачи.
Передача должна отвечать на три вопроса: что не завершено, кто теперь владелец и когда требуется следующий шаг. Пароль среди этих данных не нужен.
Автоматическая блокировка должна быть разумной
Слишком короткий тайм-аут раздражает регистратуру и провоцирует обходы: пароль пишут рядом, сеансы не закрывают, а подтверждение передают коллегам. Слишком длинный оставляет рабочее место доступным после ухода сотрудника.
Настройку выбирают по месту и риску. Компьютер в проходной зоне требует более быстрой блокировки, чем закрытый кабинет с контролируемым доступом. При этом повторный вход должен быть достаточно удобным, чтобы сотрудники не боролись с политикой.
Полезно наблюдать за пилотом. Если персонал массово подпирает клавишу предметом или просит отключить блокировку, не надо считать это только недисциплинированностью. Возможно, выбранный способ входа не соответствует рабочему ритму.
Изменение тайм-аута проверяют вместе с медицинскими и административными сценариями, чтобы незавершённая операция не терялась и не переходила следующему пользователю без статуса.
Журналирование должно отвечать на полезные вопросы
Хранить журналы «на всякий случай» недостаточно. Нужно заранее определить, какие события действительно нужны: вход и неуспешная попытка, изменение роли, массовая выгрузка, создание пользователя, смена критической настройки, выдача удалённого доступа.
Журнал должен иметь корректное время, понятные идентификаторы и ограниченный доступ. Если системы используют разные часы, сопоставить события после инцидента трудно. Синхронизация времени становится частью расследуемости.
Не следует превращать журнал в инструмент постоянного чтения медицинского содержания. Цель — видеть факт и контекст административного действия в необходимом объёме. Конкретные требования определяют владельцы безопасности, системы и процессов клиники.
Сам журнал тоже нужно защищать от незаметного изменения и установить разумный срок хранения. Бесконечное накопление без сценария использования создаёт расходы и новые риски.
Общий пароль делает расследование дороже
Представим, что ночью выполнена необычная выгрузка. Система показывает вход «admin». Пароль знали регистраторы, управляющий, бывший подрядчик и сотрудник бухгалтерии. Браузер на одном компьютере сохранял сеанс.
Команда тратит время не на оценку события, а на восстановление круга доступа. Приходится менять пароль всем, проверять устройства и обзванивать людей. Даже если выяснится, что выгрузка была рабочей, неопределённость уже создала простой.
При персональных идентичностях вопрос сужается: какая запись использована, откуда, с каким фактором, какие права были активны и кто согласовал действие. Это не гарантирует отсутствие инцидента, но позволяет быстрее принять пропорциональное решение.
План действий при подозрении на утечку должен существовать заранее. Смежные роли и первые шаги разобраны в статье что подготовить клинике до инцидента с данными.
MFA не спасёт заражённое рабочее место
Второй фактор защищает этап входа. Он не гарантирует безопасность уже открытого сеанса, не исправляет вредоносное расширение браузера и не мешает сотруднику добровольно подтвердить чужой запрос.
Поэтому MFA сочетают с обновлениями, защитой рабочих мест, ограничением прав, резервированием и обучением распознавать подозрительные запросы. Для критических систем полезны уведомления о новом устройстве и необычном входе, если поставщик их поддерживает.
Отдельно отрабатывают сценарий, когда пользователь получил неожиданный запрос подтверждения. Правильное действие — отклонить его и сообщить ответственному, а не нажать «разрешить», чтобы уведомление исчезло.
При шифровании инфраструктуры задача уже шире доступа. Нужен самостоятельный маршрут изоляции и восстановления; он описан в статье план первых 48 часов при ransomware в клинике.
Сеть и доступы должны поддерживать друг друга
Персональная запись не поможет, если любой гостевой ноутбук видит административный интерфейс. И наоборот, сегментация сети не различит сотрудников, использующих один пароль.
Для важных систем ограничивают не только пользователя, но и допустимый маршрут подключения. Удалённый доступ проходит через контролируемую точку, гостевые устройства отделены, а медицинское оборудование не находится в одном широком сегменте с посетителями.
Это не означает, что нужно одновременно перестраивать всю инфраструктуру. Начните с самого чувствительного административного интерфейса и проверьте, откуда он доступен. Связь сетевых сегментов и ролей разобрана в материале почему гостевой Wi‑Fi не должен видеть МИС и оборудование.
Если вход возможен из интернета, MFA особенно важна, но также нужны обновления, мониторинг и ограничения поставщика. Один защитный слой не должен становиться оправданием для отсутствия остальных.
Домен и корпоративная почта — особые точки контроля
Потеря административного доступа к домену или почте может позволить сбрасывать пароли других систем. Поэтому эти активы не стоит оформлять на личный адрес сотрудника или единственный телефон подрядчика.
У организации должны быть понятный владелец, резервные контакты и проверенная процедура восстановления. Административные роли отделяют от повседневной почты; ими не пользуются для чтения писем и случайных сайтов.
После ухода ответственного важно менять не только пароль, но и телефоны, резервные адреса, ключи API, доверенные устройства и делегированные роли. Скрытая привязка обнаруживается именно при восстановлении, когда времени меньше всего.
Практический маршрут возврата контроля разобран в статье владелец домена клиники ушёл: как не потерять сайт.
Иллюстративный сценарий перехода без остановки регистратуры
Представим составную ситуацию. В клинике две смены администраторов, одна МИС и общий логин. Пароль знают восемь сотрудников и удалённый специалист. Руководитель решает включить MFA в пятницу вечером и привязать вход к своему телефону.
В понедельник он на встрече, код не приходит вовремя, очередь растёт. Сотрудники просят отключить защиту. Технически MFA работает, но проект провален организационно.
Теперь другой маршрут. Сначала составляют список пользователей и пяти основных сценариев. Создают персональные записи для одной смены, проверяют права на тестовых данных, готовят резервный вход и инструкцию. Второй фактор подключают к корпоративному механизму, доступному конкретным сотрудникам. Старый общий профиль временно оставляют только как контролируемый аварийный и запрещают обычное использование.
Неделю сравнивают работу, исправляют роли, затем подключают вторую смену. После успешной проверки общий профиль блокируют, а не удаляют бесследно: сохраняют историю и документируют решение. Клиника получает защиту без утреннего эксперимента на пациентах.
Пошаговая миграция от общего пароля
Практичный переход можно разделить на этапы.
- Выберите одну систему. Начните с важной, но управляемой, а не со всех кабинетов сразу.
- Составьте список функций. Опишите работу регистратора, старшего смены, руководителя, IT и подрядчика.
- Проверьте владельца. Убедитесь, что договор, почта восстановления и телефон принадлежат организации.
- Создайте персональные записи. Не копируйте автоматически полный административный профиль.
- Настройте роли. Проверьте типовые и неудобные сценарии на синтетических данных.
- Подготовьте MFA. Выберите фактор, восстановление и резерв для смены.
- Запустите пилот. Одна группа работает персонально, общий доступ остаётся под наблюдением.
- Разберите исключения. Исправьте недостающие права и непонятные шаги.
- Закройте обычное использование общего профиля. Сохраните только обоснованный аварийный маршрут, если он действительно нужен.
- Повторите проверку. Через несколько недель сверите активных пользователей, подрядчиков и журналы.
Такой порядок медленнее одного объявления, но быстрее восстановления после неудачного массового переключения.
Что измерять в пилоте
Не оценивайте успех количеством включённых аккаунтов. Смотрите, сохранилась ли работа и появилась ли различимость.
Полезные показатели:
- доля входов под персональными именами;
- число обращений из-за недостаточных прав;
- время начала смены;
- количество использований аварийного доступа;
- активные записи уволенных и подрядчиков;
- подтверждённые подозрительные запросы MFA;
- действия, которые всё ещё невозможно связать с человеком.
Показатели интерпретируют, а не превращают в соревнование. Рост обращений в первую неделю может быть нормальным: система впервые показывает старые неясные роли. Важно, уменьшается ли он после корректировок.
Красные флаги, которые видны без аудита
Система доступа требует внимания, если:
- пароль написан рядом с компьютером;
- код MFA приходит одному руководителю для всех смен;
- подрядчик входит под именем директора;
- бывший сотрудник остаётся контактом восстановления;
- журнал показывает только «admin»;
- у всех пользователей одинаковые максимальные права;
- сервисную запись используют люди;
- отключение общего профиля ломает интеграцию;
- никто не проверял аварийный вход;
- домен и почта оформлены на личный адрес.
Не нужно исправлять все пункты за ночь. Выберите тот, где один человек или один секрет открывает больше всего критических систем.
Частые вопросы руководителя клиники
Нужно ли каждому администратору отдельное рабочее место?
Нет. Несколько сотрудников могут пользоваться одним компьютером, но входить в важные системы под персональными учётными записями.
Можно ли оставить общий логин только для ночной смены?
Это сохраняет ту же неопределённость именно в период меньшего контроля. Лучше создать персональные записи и предусмотреть удобный способ подтверждения входа ночью.
Что делать, если МИС не поддерживает нормальные роли?
Зафиксировать ограничение, запросить возможности у поставщика и компенсировать риск на других слоях: доступ к рабочему месту, отдельные записи, журнал, сетевые ограничения. Не выдавать ограничение за норму.
Обязательно ли использовать личные телефоны для MFA?
Нет. Возможны корпоративные устройства, аппаратные ключи и другие поддерживаемые методы. Выбор должен учитывать сменность, восстановление и согласованные правила использования устройств.
Нужна ли смена пароля каждые несколько недель?
Политика зависит от системы и модели угроз. Бессмысленная частая смена может породить предсказуемые варианты и записи на бумаге. Важнее уникальность, защита секрета, MFA, отзыв при событиях и отсутствие общего использования.
Можно ли совсем удалить аварийную учётную запись?
Иногда да, иногда система требует резервного администратора. Решение принимают после проверки восстановления. Если запись остаётся, её защищают, ограничивают и контролируют использование.
Что сделать завтра
Выберите одну критическую систему и не меняйте в ней пароль. Сначала выпишите всех людей и сервисы, которые могут войти, а затем отдельно — тех, кто должен иметь такую возможность по работе.
Сравните списки. Найдите одного бывшего сотрудника, подрядчика или общий профиль, для которого нет ясного владельца. Проверьте адрес и телефон восстановления. После этого подготовьте безопасный план изменения с тестом и возвратом, а не блокируйте доступ вслепую.
Сильная система доступа незаметна в обычную смену и очень заметна в сложный день. Она не заставляет угадывать, кто работал, не держит клинику на телефоне одного человека и не превращает увольнение в массовую смену паролей.
Материал носит информационный характер и не заменяет юридическую экспертизу, аудит информационной безопасности или требования поставщика конкретной системы. Не передавайте реальные пароли, токены, персональные данные и рабочие выгрузки в тестовый контур.
