Подрядчик попросил доступ: как клинике не потерять контроль над МИС, PACS и сервером

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

В клинике доступ — это не техническая мелочь. Это доступ к МИС, PACS, серверу, рабочим местам, снимкам, документам и персональным данным. Если его не контролировать, потом при инциденте вы будете собирать хронологию по чатам, памяти администратора и фразе "ну вроде Вася подключался". Поверьте, я видел этот спектакль слишком много раз.

Работа с персональными данными в медицине упирается в 152-ФЗ “О персональных данных” и ответственность по ст. 13.11 КоАП РФ. Это не юридическая консультация, но практический вывод простой: клиника должна понимать, кто имеет доступ к данным и какие меры контроля реально работают.

Ловушка №1: общий логин для подрядчика

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

Кереметь-Бастион как раз про это: защищенный контур доступа, роли, журналы, контроль подключений, внешние носители и evidence. VPN, MFA и JIT-временные права — отдельные approval-gated этапы внедрения, а не обещание “включили кнопку и закон закрыт”.

Ловушка №2: безопасность есть в документах, но нет в evidence

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

Кереметь-ЩИТ дополняет Бастион: endpoint-состояние, события безопасности, обновления, внешние носители, подозрительная активность и отчеты. Это не гарантия отсутствия инцидентов. Это способ видеть риски и не искать доказательства вручную по всей клинике.

Антикейс: доступ забыли отключить

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

Чек-лист доступа подрядчика

Перед тем как дать доступ, проверьте:

1. Кто именно подключается: ФИО, организация, задача. 2. Куда нужен доступ: сервер, МИС, PACS, рабочая станция, сетевое оборудование. 3. На какой срок: дата начала и дата отключения. 4. Какие действия разрешены. 5. Ведется ли журнал действий. 6. Есть ли контроль внешних носителей. 7. Кто принимает результат работ. 8. Кто отключает доступ после завершения. 9. Где хранится evidence по подключению. 10. Что делать, если после подключения начались сбои.

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

Если хотите понять, где у вас сейчас висят лишние доступы, начните с Red Team тестирования или бесплатного IT-аудита. Мы не обещаем “нулевой риск”. Мы помогаем убрать очевидный хаос и собрать доказательную базу.

Какие evidence-события нужны руководителю

Директору клиники не нужен поток технических логов. Ему нужна понятная картина: кто подключался, когда, к какой системе, зачем, что изменил и был ли доступ отключен после работ. Это и есть нормальный перевод с языка ИБ на язык управления. Без такой картины любой инцидент превращается в эмоциональный спор: "мы не знаем, но вроде ничего страшного".

Минимальный набор evidence:

- выдача доступа подрядчику; - срок действия доступа; - подтверждение личности и роли; - подключение к серверу, МИС, PACS или рабочему месту; - административные действия; - подключение внешних носителей; - массовое копирование или выгрузка файлов; - отключение доступа после завершения работ; - отчет по подозрительным событиям.

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

Бастион и ЩИТ сильны именно в связке: один отвечает за управляемый доступ и действия, второй помогает видеть состояние рабочих мест, события и evidence. Для клиники это переход от "верим подрядчику" к "видим процесс".

Доступ подрядчика: временный, понятный, отзываемый

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

Хорошая схема доступа не мешает работе подрядчика. Она делает её управляемой. У доступа есть задача, срок, ответственный, минимально достаточные права, журнал действий и процедура отзыва. Если нужна аварийная работа, это тоже фиксируется. Если подрядчик завершил проект, доступ не должен оставаться «на всякий случай».

Почему постоянные доступы опасны для владельца

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

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

Как объяснить это команде без паранойи

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

Жизненный цикл доступа: от заявки до закрытия

Заявка на доступ должна начинаться с задачи, а не с просьбы «скиньте пароль». Что нужно сделать, в какой системе, в какое время, с какими правами и кто внутри клиники подтверждает работу. Такой порядок занимает несколько минут, но экономит часы, если после изменений что-то пошло не так.

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

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

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

Закрытие доступа — обязательная часть проекта. Если подрядчик закончил настройку, права должны быть отозваны или снижены. Если проект переходит в сопровождение, нужен новый статус, срок и ответственный. Старые доступы «на всякий случай» со временем становятся самым неприятным наследием.

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

Документы доступа без лишней бюрократии

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

Отдельно стоит фиксировать доступы к системам с разным уровнем риска. Сайт, телефония, сервер, МИС, PACS, касса и рекламные кабинеты не равны между собой. Ошибка в каждом контуре имеет разные последствия. Поэтому один общий пароль на всё — самый слабый и самый неудобный вариант.

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

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

Вопросы и ответы

С чего начать по теме «Подрядчик попросил доступ: как клинике не потерять контроль над МИС, PACS и сервером»?

Если подрядчику нужен доступ к МИС, серверу, сайту или PACS, лучше сначала описать роли, сроки, журнал действий и ответственных, а уже потом открывать технический канал.

Нужны ли реальные данные пациентов для первичной оценки?

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

Можно ли заранее обещать финансовый или медицинский результат?

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

Как понять, что статья подходит именно моей клинике?

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

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

Если подрядчику нужен доступ к МИС, серверу, сайту или PACS, лучше сначала описать роли, сроки, журнал действий и ответственных, а уже потом открывать технический канал.