Тема 4.2 — Управление идентификацией и доступом

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

Почему это важно в здравоохранении и уходе#

Каждое клиническое решение опирается на допущение, что запись перед клиницистом — нужная запись, принадлежит нужному пациенту и открыта нужным человеком. Управление идентификацией и доступом (IAM) — механизм, делающий эти три допущения истинными. Когда он работает, парамедик вовремя видит аллергию, заметка о защите доходит только до тех, кому нужна, а след аудита может ответить на вопрос «кто смотрел эту запись и зачем?». Когда он отказывает, пациентам вредят записи, открытые под чужим именем, персонал сует нос в записи родственников или знаменитостей, а доверие ко всему цифровому предприятию разрушается.

Здравоохранение и уход поднимают ставки выше обычного корпоративного случая тремя способами. Во-первых, данные — одни из самых чувствительных, которые человек когда-либо порождает (психическое здоровье, сексуальное здоровье, употребление веществ, гендерная идентичность, проблемы защиты), поэтому нарушение конфиденциальности — не неудобство, а долговременный вред. Во-вторых, персонал мобилен, ротационен и многоорганизационен: младшие врачи ротируются каждые несколько месяцев, персонал агентств и локумы приходят на одну смену, а интегрированный уход означает, что участковой медсестре может законно понадобиться больничная запись. В-третьих, обязанность заботы не прощает трения: контроль доступа, слишком медленный в 3 часа ночи в реанимации, сам является опасностью для безопасности. IAM в этом секторе поэтому — постоянные переговоры между блокировкой данных и быстрым допуском нужного человека.

Эта тема касается глубины контроля доступа, лежащей под более широкими обязанностями, рассмотренными в теме 1.7 — Управление информацией, защита данных и кибербезопасность. Там, где та тема задаёт правовую и организационную рамку (UK General Data Protection Regulation, Data Security and Protection Toolkit, обязанность конфиденциальности), эта — о конкретной механике подтверждения идентичности и предоставления наименьшего доступа, необходимого для работы.

Ключевые понятия#

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

Аутентификация отвечает на вопрос «вы тот, за кого себя выдаёте?». Она доказывается факторами: то, что вы знаете (пароль или PIN), то, что у вас есть (смарт-карта, телефон, аппаратный токен), и то, что вы есть (отпечаток пальца или лицо). Авторизация отвечает на другой вопрос: «теперь, когда мы знаем, кто вы, что вам разрешено видеть и делать?». Консультант и регистратор могут оба прекрасно аутентифицироваться, но авторизованы они на очень разные части записи. Путаница между двумя ведёт к системам, строго проверяющим идентичность и затем позволяющим всем видеть всё.

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

Современная аутентификация усиливает шаг «докажите, кто вы», с помощью многофакторной аутентификации (MFA), сочетающей два или более факторов, чтобы украденного пароля было недостаточно. Она снижает трение с помощью единого входа (SSO), где одна аутентифицированная сессия даёт доступ ко многим приложениям без повторных входов: подлинная польза для безопасности, когда клиницисту нужно переключаться между десятком систем за час. SSO через организационные границы опирается на федеративную идентичность: одна организация ручается за пользователя, чтобы другая могла ему доверять, не держа его учётных данных.

«Сантехника» федерации и современной аутентификации построена на открытых стандартах. OAuth — стандарт делегированной авторизации: позволяет приложению действовать от вашего имени, не передавая ваш пароль. OpenID Connect надстраивает аутентификацию над OAuth, чтобы приложение могло узнать, кто пользователь, а более старый основанный на XML Security Assertion Markup Language (SAML) выполняет схожую работу для корпоративного SSO. Жизненный цикл идентичности (предоставление, изменение и отзыв доступа, когда люди приходят, перемещаются и уходят) обрабатывается процессами предоставления доступа (provisioning), обычно называемыми «пришедшие/перемещённые/ушедшие» (joiners/movers/leavers, JML).

Стратегическое направление движения — архитектура нулевого доверия (zero trust): допущение, что ни один пользователь или устройство не заслуживают доверия лишь потому, что находятся внутри сети. Каждый запрос аутентифицируется, авторизуется и проверяется относительно контекста (состояние устройства, местоположение, чувствительность данных), а не полагается на укреплённый периметр. В секторе, где персонал работает из клиник, домов, скорых и площадок партнёров, периметр фактически растворился, и нулевое доверие называет честный ответ на это.

Лучшие практики#

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

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

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

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

5. Используйте единый вход, чтобы убрать трение, толкающее персонал к небезопасным обходным путям. Когда персоналу приходится входить в десять систем отдельно, он пишет пароли на стикерах, делит смарт-карты и оставляет сессии открытыми, и каждое из этого — риск безопасности и конфиденциальности. Хорошо реализованный SSO, в идеале сочетаемый со бейджами близости «приложи — отложи» (tap in, tap out) на общих клинических рабочих станциях, и улучшает безопасность, и возвращает клиницистам время. Рассматривайте SSO как вмешательство по безопасности пациентов, а не просто удобство, и измеряйте время входа, которое убираете.

6. Модернизируйте идентичность NHS за пределы смарт-карты, не ломая то, что работает. NHS Care Identity Service (прежде Care Identity Service, а до того режим Registration Authority, построенный на смарт-картах) аутентифицирует персонал NHS и управляет доступом к национальным системам, таким как Spine. Национальное направление теперь — к современной, основанной на стандартах аутентификации (CIS2 с MFA и OpenID Connect), снижающей зависимость от физических смарт-карт и считывателей, которые отказывают, передаются или блокируют уход. Планируйте миграцию осознанно: сохраняйте строгость гарантий и регистрации модели смарт-карт, принимая гибкость современных токенов.

7. Ведите «пришедшие/перемещённые/ушедшие» как контролируемый, проверяемый процесс, особенно «ушедшие». Самый частый серьёзный сбой IAM в здравоохранении и уходе — учётная запись, пережившая потребность человека в ней: ротированный младший врач, ушедшая медсестра агентства, подрядчик, чей доступ так и не отозвали. Автоматизируйте предоставление доступа из авторитетного источника (обычно электронной записи персонала), чтобы начало, изменение и конец роли запускали соответствующее изменение доступа в определённое короткое окно. Считайте отзыв в тот же день для ушедших и для персонала под расследованием жёстким требованием, а не стремлением.

8. Регулярно пересертифицируйте доступ и делайте менеджеров ответственными за это. Доступ, уместный в первый день, дрейфует, когда люди меняют команды и накапливают права, которые им больше не нужны: «ползучие привилегии». Проводите периодические пересмотры доступа (пересертификацию), в которых ответственный менеджер или владелец системы активно подтверждает, что каждому человеку всё ещё нужно каждое право, а молчание по умолчанию означает удаление, а не сохранение. Сделайте пересмотр осмысленным, представляя его на простом языке клинических ролей, а не сырыми кодами разрешений, которые ни один менеджер не может интерпретировать.

9. Управляйте привилегированным доступом как отдельной категорией. Администраторы, владельцы баз данных и инженеры инфраструктуры могут читать или изменять любую запись и отключать сами контроли, защищающие её, поэтому их доступу нужно более сильное обращение, чем обычным пользователям. Внедрите управление привилегированным доступом: разделяйте идентичности администратора и повседневные учётные записи, предоставляйте повышенные права «точно вовремя» (just-in-time) и ограниченными по времени, а не постоянными, и записывайте привилегированные сессии для независимого пересмотра. Никогда не позволяйте поставщику или учётной записи «разбей стекло» стать постоянным, неконтролируемым мастер-ключом.

10. Делайте каждое решение о доступе проверяемым и действительно читайте аудит. Контроль доступа, который нельзя пересмотреть потом, — лишь половина контроля; способность ответить «кто обращался к этой записи, когда и на каком основании?» лежит в основе и расследований конфиденциальности, и безопасности пациентов. Настройте полное, защищённое от подделки журналирование аудита и, что решающе важно, обеспечьте ресурсами проактивный аудит, включая оповещения о самопросмотрах, просмотрах коллег или VIP и необычных объёмах доступа. След аудита, который никто не изучает, никого не сдерживает.

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

12. Примите нулевое доверие как направление и упорядочьте его прагматично. Двигайтесь от «доверенной сети, открытой внутри» к проверке каждого запроса относительно идентичности, состояния устройства и контекста, чтобы скомпрометированный ноутбук в корпоративной LAN больше не был автоматически доверенным. Это многолетний путь через сильную идентичность, соответствие устройств, условный доступ и микросегментацию, а не продукт, который можно купить. Упорядочьте его после основ (MFA, наименьшие привилегии, чистый JML) и согласуйте с работой над парком в теме 4.0 — Техническая архитектура, облако и унаследованные системы.

Вопросы для обсуждения с командой#

1. Где мы сознательно обмениваем трение доступа на клиническую безопасность и кто решил баланс? Каждый дополнительный вход, второй фактор или шаг авторизации защищает конфиденциальность, но стоит секунд, которые в чрезвычайной ситуации сами являются риском безопасности. Этот вопрос заставляет команду назвать конкретные места, где контроли безопасности могли бы задержать уход (вход в реанимации, общая рабочая станция отделения, система вне рабочего времени), и спросить, был ли нынешний баланс выбран людьми, понимающими и клинические, и последствия для безопасности, или оставлен по умолчанию настройкой поставщика. Обсудите напряжение честно: чрезмерно жёсткий контроль порождает пароли на стикерах и общие смарт-карты, хуже риска, который он решает, а чрезмерно мягкий приглашает любопытство и нарушения. Ищите конкретные сигналы плохого баланса: персонал делится учётными данными, сессии остаются открытыми, «разбей стекло» используется рутинно. Хороший ответ определяет, кто владеет каждым компромиссом, показывает, что клиницисты были в комнате, когда он устанавливался, и указывает на измеренное время входа и долю обходных путей, а не на допущения. Он также обязуется пересматривать баланс по мере изменения ролей, систем и угроз.

2. Насколько мы уверены, что уходящий или перемещающийся сотрудник теряет нужный доступ, в нужное время, каждый раз? Учётная запись, пережившая свою потребность, — классический сбой IAM, а в ротационном, многоорганизационном персонале здравоохранения риск острый. Этот вопрос проверяет, является ли JML надёжным, автоматизированным процессом, управляемым из авторитетного источника, или набором ручных писем, тихо дающих сбой, когда кто-то занят. Обсудите трудные случаи: младший врач, ротирующийся между трастами, медсестра агентства на одну смену, подрядчик, сотрудник, отстранённый на время расследования. Подумайте, что значит «нужное время» для каждого: отзыв в тот же день не обсуждается для отстранения, но может быть мягче для рутинного внутреннего перемещения. Хороший ответ может указать на доказательства, а не намерения: результаты последнего аудита уходящих, число найденных и закрытых спящих учётных записей, время между уходом человека и окончанием его доступа. Он честен в отношении пробелов и называет, кто отвечает за их закрытие.

3. Когда что-то идёт не так с записью, можем ли мы на самом деле восстановить, кто что сделал, и заметили бы мы злоупотребление без инцидента, подталкивающего нас? Аудит — контроль, делающий конфиденциальность и безопасность обеспечиваемыми постфактум, но он работает, только если журналы полны, защищены и действительно просматриваются. Этот вопрос разделяет две вещи, которые команда часто смешивает: способность расследовать реактивно, когда приходит жалоба, и способность обнаруживать злоупотребление проактивно, до того как кто-либо пожалуется. Изучите, что ваши журналы на самом деле фиксируют, можно ли их изменить, как долго они хранятся и, что труднее, кто смотрит на них, когда нет инцидента. Подумайте о реалистичных угрозах: сотрудник, ищущий члена семьи, коллегу или публичную фигуру; скомпрометированная учётная запись, выкачивающая записи в масштабе. Хороший ответ показывает, что аудит обеспечен ресурсами как активная функция с оповещением, а не спящий архив, и может привести реальный пример злоупотребления, которое организация обнаружила и по которому действовала. Он также связывает аудит со справедливостью, обеспечивая, чтобы пересмотры непропорционально не нацеливались на определённые группы персонала.

4. Когда клиницисту законно нужна запись, которую ему рутинно не разрешено видеть, делает ли наш путь «разбей стекло» безопасное действие лёгким, а неоправданное видимым? Здравоохранение и уход отличаются от обычных корпоративных ИТ именно потому, что правилам порой приходится уступать пациенту перед вами: поступивший без сознания, межорганизационная чрезвычайная ситуация, клиницист вне рабочего времени, покрывающий незнакомую нагрузку. Этот вопрос спрашивает, спроектирован ли экстренный доступ как явный, обоснованный, помеченный путь или персонал тихо вынужден выбирать между политикой доступа и благополучием пациента. Проверьте сбои на обоих концах: путь «разбей стекло», настолько громоздкий, что клиницисты избегают его и делятся учётными данными, или настолько беспроблемный и непросматриваемый, что становится рутинным способом входа и целиком выхолащивает RBAC. Обсудите, кто пересматривает события «разбей стекло», как быстро и какая доля оказывается неоправданной: показатель, близкий к нулю, может означать, что контроль не используется, а не что он чист. Хороший ответ может описать точные шаги клинициста, фиксацию причины, немедленную пометку домашней организации записи и пересмотр постфактум, замыкающий цикл, и показать, что чрезвычайные ситуации действительно обслуживаются, а злоупотребления действительно ловятся. Он честен в том, не движутся ли объёмы «разбей стекло» в направлении, указывающем на более глубокий пробел авторизации.

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

6. Какая часть нашей идентичности зависит от сторон вне нашего контроля и осознанны ли мы в отношении этой зависимости? Современная идентичность в здравоохранении и уходе федеративна по замыслу: общая карта доверяет утверждениям каждой партнёрской организации, национальные службы вроде NHS Care Identity Service и CIS2 ручаются за персонал, а NHS login ручается за граждан, что означает, что сила вашего контроля доступа всегда лишь настолько хороша, насколько хороши поставщики идентичности, на которые вы полагаетесь, и стандарты, связывающие вас вместе. Этот вопрос просит команду нанести на карту, где делегировано доверие: какие организации аутентифицируют каких пользователей, что происходит, когда у партнёра сбоит процесс JML, и как отзывается федеративный вход, когда уходит сотрудник другого работодателя. Взвесьте миграцию, идущую от смарт-карт к аутентификации на основе стандартов (CIS2 с MFA и OpenID Connect), и напряжение между принятием национального направления и сохранением работоспособности местных рабочих процессов в 3 часа ночи. Подумайте и об устойчивости: если национальная служба идентификации недоступна, могут ли клиницисты всё же безопасно достичь нужных записей или федерация становится единой точкой отказа. Хороший ответ показывает, что команда точно знает, на чьи гарантии она опирается, согласовала, как обрабатываются межорганизационный отзыв и инциденты, и упорядочивает свой переход на современную аутентификацию NHS осознанно, а не увлекается им. Он реалистичен в отношении частей парка, которые пока не могут федерироваться, и того, как они соединяются тем временем.

На практике: пример из здравоохранения и ухода#

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

Команда делает контроль доступа первоклассным потоком проектирования. Они согласуют ролевую модель, выраженную клиническим языком: «участковая медсестра», «утверждённый специалист по психическому здоровью», «управляющий домом престарелых», и сопоставляют каждую роль с наименьшими данными, которые ей нужны, причём записи психического и сексуального здоровья подпадают под более строгий, отдельно авторизуемый доступ. Аутентификация федеративна: каждая партнёрская организация аутентифицирует собственный персонал через NHS Care Identity Service или своего местного поставщика идентичности по OpenID Connect, а общая карта доверяет этим утверждениям, а не выдаёт собственные учётные данные, так что нового пароля для управления нет, а JML остаётся у нанимающей организации, где живёт авторитетная запись персонала.

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

Через шесть месяцев после запуска оповещение помечает координатора ухода, неоднократно открывающего запись человека, не имеющего активного отношения к его нагрузке. Функция аудита расследует, выясняет, что доступ был личным, а не профессиональным, и нанимающая организация принимает дисциплинарные меры. Инцидента безопасности пациентов не произошло, нарушение поймано проактивно, и, поскольку контроли наглядно сработали, общественное доверие к общей карте сохранилось. Совет отмечает, что та же возможность аудита теперь служит и доказательством для его представления в Data Security and Protection Toolkit (см. тему 1.7 — Управление информацией, защита данных и кибербезопасность).

Отраслевые перспективы#

Стартап#

Небольшая компания цифрового здравоохранения, создающая, скажем, приложение дистанционного мониторинга, имеет преимущество отсутствия унаследованного груза: она может принять современную аутентификацию, MFA и федерацию на основе стандартов с первого дня и интегрироваться с NHS login для граждан и CIS2 для клиницистов, а не изобретать собственную систему идентификации. Опасность — скорость, опережающая дисциплину: жёстко прописанные учётные данные администратора, общая учётная запись суперпользователя «основателя», служебные учётные записи с правами бога и отсутствие процесса для уходящих, потому что «все знают друг друга». Наименьшие привилегии и аудит кажутся накладными расходами при десяти людях, но становятся невосстановимым техническим долгом при ста. Прагматичный ход — купить идентификацию как управляемую услугу, обеспечить MFA и RBAC с первого коммита и считать требования DTAC (Digital Technology Assessment Criteria) минимальной планкой для любого внедрения в NHS.

Малый бизнес#

Устоявшийся небольшой поставщик (практика врача общей практики, общественная аптека, дом престарелых, агентство ухода на дому, клиника в одном месте или небольшой поставщик health-tech, миновавший стадию без выручки) несёт те же обязанности по конфиденциальности и контролю доступа, что и крупный траст, но с реальными пациентами в списках, горсткой персонала и малой или нулевой выделенной ИТ-мощностью, чтобы их выполнять. Практический риск здесь не экзотический: это общий логин на стойке регистрации, пароль клинической системы, приклеенный скотчем к монитору, локум, получивший смарт-карту коллеги, потому что регистрация новой занимает слишком долго, и ушедший сотрудник, чья учётная запись так и не отключена, потому что никто не владеет этой работой. Прагматичный путь — опираться на функции идентификации, уже встроенные в покупаемые системы: обеспечить MFA и персональные учётные записи, включить журналирование аудита поставщика и использовать NHS CIS2 и NHS login, а не доморощенные учётные данные, и записать простой порядок «пришедшие/перемещённые/ушедшие», называющий одного ответственного, даже если им будет управляющий практикой, делающий это вручную. Наименьшие привилегии и отзыв в день ухода значат столько же при десяти сотрудниках, сколько при десяти тысячах; разница в том, что здесь они должны достигаться процессом и конфигурацией, а не выделенной командой идентификации.

Крупная организация#

Крупный траст NHS или ICS ведёт десятки клинических систем чрезвычайно разного возраста, у каждой своя модель идентификации, и его центральный вызов — интеграция и жизненный цикл в масштабе. Смарт-карты, SSO, рабочие процессы «приложи — отложи» и надёжный конвейер JML из электронной записи персонала важнее здесь любого отдельного хитрого контроля, потому что виды сбоев — сбои объёма: тысячи спящих учётных записей, взрыв ролей и журналы аудита, которые никто не в состоянии просмотреть. Управление привилегированным доступом критично при числе администраторов и поставщиков, касающихся парка. Прогресс идёт от стратегии идентификации, рационализирующей роли, федерирующей по системам и обеспечивающей ресурсами постоянную функцию аудита, а не от точечных решений, навешенных на каждое приложение.

Государство#

Национальный орган вроде NHS England ведёт идентификацию как общую инфраструктуру для всей системы: NHS Care Identity Service и CIS2 для персонала, NHS login для граждан и стандарты и режимы гарантий, позволяющие сотням организаций доверять друг другу. Его решения задают направление движения (переход от смарт-карт к современной аутентификации, принятие OpenID Connect, движение к нулевому доверию), а его подотчётность перед парламентом и общественностью — и за безопасность, и за равноправный доступ. Напряжение между центральной стандартизацией и местной гибкостью: предпишите слишком жёстко, и вы сломаете местные рабочие процессы, предпишите слишком мягко, и федерация рухнет в несогласованность. Государственная линза поэтому — о задании интероперабельных стандартов (см. тему 4.3 — Интероперабельность и стандарты данных), предоставлении надёжных общих услуг и обеспечении соответствия без микроуправления каждым трастом.

Типичные способы сбоя#

• Осиротевшие и спящие учётные записи. Уходящие, ротированный персонал и старые подрядчики сохраняют действующий доступ, потому что JML опирается на ручное уведомление. Исправление — автоматическое лишение доступа из авторитетного источника плюс регулярные проверки спящих учётных записей.
• Взрыв ролей и ползучие привилегии. RBAC распадается в сотни пересекающихся ролей, а люди накапливают права, которыми больше не пользуются. Противодействуйте периодической пересертификацией и плановой рационализацией ролей.
• Передача учётных данных и общие рабочие станции. Медленные входы и неуклюжие смарт-карты толкают персонал делить карты и оставлять сессии открытыми. Устраняйте первопричину через SSO, бейджи близости и быстрое переключение, а не призывами вести себя правильно.
• Постоянный привилегированный доступ. Администраторы и поставщики держат постоянные учётные записи с правами бога, способные отключить сами контроли. Переходите к повышению «точно вовремя», ограниченному по времени, записываемому.
• Аудит как украшение. Журналы собираются, но никогда не просматриваются, так что злоупотребления находят только реактивно. Обеспечьте ресурсами проактивный аудит с оповещением о самопросмотрах и просмотрах VIP.
• «Разбей стекло» как лазейка. Экстренный доступ существует, но не контролируется, поэтому становится рутинным путём наименьшего сопротивления. Требуйте причину, помечайте каждое использование и пересматривайте постфактум.
• Театр MFA. MFA включена, но на слабых, поддающихся фишингу факторах, или отменена для самых занятых привилегированных пользователей. Предпочитайте устойчивые к фишингу факторы там, где риск наибольший.

Модель зрелости#

Контрольный список#

• Сила аутентификации и объём авторизации определены и задокументированы отдельно для каждой клинической системы.
• MFA обеспечена для всего удалённого и привилегированного доступа, с факторами, подходящими клинической обстановке.
• Единый вход и быстрое переключение рабочих станций развёрнуты, чтобы убрать трение входа и передачу учётных данных.
• Ролевая модель выражена клиническим языком, сопоставлена с наименьшими привилегиями и рационализируется по графику.
• «Пришедшие/перемещённые/ушедшие» автоматизированы из авторитетного источника персонала, с отзывом в тот же день для ушедших и отстранённых.
• Периодическая пересертификация доступа проводится ответственными менеджерами, с удалением по умолчанию для неподтверждённого доступа.
• Привилегированный доступ управляется как отдельная категория: раздельные идентичности, повышение «точно вовремя», запись сессий.
• Нечеловеческие и интеграционные учётные записи инвентаризированы, сужены до наименьших привилегий, а их учётные данные меняются.
• Полное, защищённое от подделки журналирование аудита на месте, с проактивным оповещением о самопросмотрах, просмотрах коллег и VIP.
• Экстренный доступ «разбей стекло» спроектирован с обязательной причиной, немедленной пометкой и пересмотром постфактум.
• Миграция от смарт-карт к современной аутентификации NHS (CIS2 / OpenID Connect) спланирована и упорядочена.
• Дорожная карта нулевого доверия согласована и совмещена со стратегией технической архитектуры.

Ключевые источники#

• NHS England — руководство по NHS Care Identity Service и Care Identity Service 2 (CIS2)
• NHS England — Data Security and Protection Toolkit
• National Cyber Security Centre (NCSC) — принципы проектирования архитектуры нулевого доверия
• National Cyber Security Centre (NCSC) — руководство по многофакторной аутентификации и управлению идентификацией/доступом
• NIST — Special Publication 800-207, Zero Trust Architecture
• NIST — Special Publication 800-63, Digital Identity Guidelines
• NHS England / NHS login — документация службы проверки идентичности граждан
• DTAC — Digital Technology Assessment Criteria для здравоохранения и социального ухода
• Принципы Калдикотта и обязанность конфиденциальности по общему праву (Великобритания)

Ссылки#

1. Identity management (identity and access management) — Wikipedia — https://en.wikipedia.org/wiki/Identity_management
2. Authentication — Wikipedia — https://en.wikipedia.org/wiki/Authentication
3. Authorization — Wikipedia — https://en.wikipedia.org/wiki/Authorization
4. Role-based access control — Wikipedia — https://en.wikipedia.org/wiki/Role-based_access_control
5. Principle of least privilege — Wikipedia — https://en.wikipedia.org/wiki/Principle_of_least_privilege
6. Multi-factor authentication — Wikipedia — https://en.wikipedia.org/wiki/Multi-factor_authentication
7. Single sign-on — Wikipedia — https://en.wikipedia.org/wiki/Single_sign-on
8. Federated identity — Wikipedia — https://en.wikipedia.org/wiki/Federated_identity
9. OAuth — Wikipedia — https://en.wikipedia.org/wiki/OAuth
10. OpenID (and OpenID Connect) — Wikipedia — https://en.wikipedia.org/wiki/OpenID
11. Security Assertion Markup Language (SAML) — Wikipedia — https://en.wikipedia.org/wiki/Security_Assertion_Markup_Language
12. Provisioning (technology) — Wikipedia — https://en.wikipedia.org/wiki/Provisioning_(technology)
13. Zero trust architecture — Wikipedia — https://en.wikipedia.org/wiki/Zero_trust_architecture
14. NHS Care Identity Service 2 (CIS2) — NHS England — https://digital.nhs.uk/services/care-identity-service
15. Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. Zero Trust Architecture Design Principles — National Cyber Security Centre — https://www.ncsc.gov.uk/collection/zero-trust-architecture
17. Special Publication 800-207: Zero Trust Architecture — National Institute of Standards and Technology (NIST) — https://csrc.nist.gov/pubs/sp/800/207/final
18. Special Publication 800-63: Digital Identity Guidelines — National Institute of Standards and Technology (NIST) — https://pages.nist.gov/800-63-3/
19. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
20. NHS login — NHS England — https://www.nhs.uk/nhs-services/online-services/nhs-login/