主题 4.2 — 身份与访问管理

在医疗与照护领域,控制谁能对一份患者记录看到什么、做什么,不是一项 IT 内务工作,而是临床安全、保密性与公众信任的第一线决定因素。

为什么这在医疗与照护领域很重要#

每一项临床决策都建立在一个假设之上:摆在临床医生面前的记录是正确的记录,属于正确的患者,并且是由正确的人访问的。身份与访问管理(IAM)是让这三个假设成真的机制。当它奏效时,一位护理人员能及时看到一种过敏史,一份保障工作方面的笔记只会抵达需要它的人,一条审计轨迹能回答"谁查看了这份记录、为什么?"这个问题。当它失效时,患者会因为在错误名字下被打开的记录而受到伤害,员工会窥探亲属或名人的信息,对整个数字化事业的信心也会被侵蚀。

医疗与照护领域在三个方面把利害关系提升到了普通企业情境之上。第一,数据是一个人一生中所产生的最敏感的数据之一——精神健康、性健康、药物使用、性别认同、保障工作方面的关切——因此一次保密性违规不是一次不便,而是一种持久的伤害。第二,劳动力是流动的、轮换的、跨多个机构的:初级医生每隔几个月轮换一次,代理与临时员工只为一个班次而来,而整合照护意味着一位社区护士可能合法地需要一份医院记录。第三,照护义务对摩擦毫不留情:一个在凌晨三点复苏抢救中过慢的访问控制,本身就是一项安全隐患。因此,这个领域的 IAM 是在锁定数据与让正确的人快速进入之间的一场持续谈判。

本主题处理的是坐落在主题 1.7——信息治理、数据保护与网络安全所涵盖的更广泛职责之下的访问控制深度。那个主题设定了法律与组织框架——英国通用数据保护条例、数据安全与保护工具包、保密义务——本主题则关乎证明身份、并授予完成工作所需最小访问权限的具体机制。

核心概念#

身份与访问管理是确保正确的个人在正确的时间对正确的资源拥有正确访问权限、并且这一点事后能够被证明的学科与一套技术。它建立在一个容易被模糊、丢失了却很危险的区别之上:身份验证与授权之间的区别。

身份验证回答的是"你是你所声称的那个人吗?"它通过若干因素来证明:你知道的东西(一个密码或 PIN)、你拥有的东西(一张智能卡、一部手机、一个硬件令牌),以及你本身的特征(一个指纹或面容)。授权回答的是一个不同的问题——"既然我们知道了你是谁,你被允许看到什么、做什么?"一位顾问医生与一位前台接待员可能都能完美地通过身份验证,但他们被授权访问的记录部分截然不同。把两者混为一谈,会导致系统严格核验身份、然后却让所有人看到所有东西。

医疗与照护领域的授权通常被组织为基于角色的访问控制(RBAC),权限附加在角色上——"急诊科护士"、"全科医生"、"医疗秘书"——人们通过持有一个角色来继承权限,而不是一项一项地被授予权利。RBAC 由最小权限原则来治理:每个人、每一个系统账户,都应当持有完成工作所需的最小访问权限,不多不少。最小权限既限制了意外错误,也限制了一个被攻破账户的波及范围。

现代身份验证通过多因素身份验证(MFA)来强化"证明你是谁"这一步,结合两个或以上因素,这样单凭一个被盗的密码就不够用了。它通过单点登录(SSO)来减少摩擦,即一次经过身份验证的会话就能授予对许多应用的访问权限,而无需反复登录——当一位临床医生必须在一小时内在十几个系统之间切换时,这是一项真正的安全效益。跨机构边界的 SSO 依赖于联合身份:一个机构为一位用户担保,这样另一个机构就能信任他们,而不必持有他们的凭证。

联合与现代身份验证的基础管道建立在开放标准之上。OAuth 是一种委托授权标准——让一个应用能够代表你行事,而无需交出你的密码。OpenID Connect 在 OAuth 之上叠加了身份验证,让一个应用能够知道用户是谁,而更老旧的、基于 XML 的安全断言标记语言(SAML)为企业级 SSO 完成类似的工作。一个身份的生命周期——随着人们加入、变动与离开而授予、变更并撤销访问权限——由配置流程来处理,通常被称为入职/变动/离职(JML)。

战略方向是零信任架构:假设没有哪个用户或设备仅仅因为身处网络内部就是可信的。每一次请求都要经过身份验证、授权,并对照情境(设备健康状况、位置、数据的敏感程度)进行检查,而不是依赖一个被强化的边界。在一个员工从诊所、家中、救护车与合作方场所工作的行业里,边界已经实际上消失了,零信任正是对这一现实的诚实回应。

最佳实践#

1. 把身份验证与授权当作独立的设计决策来对待。 首先决定对于一个给定系统,你必须以多强的力度证明身份,然后分别决定你必须以多精细的粒度来控制每个角色随后能做什么。一个让所有人都拥有完全访问权限的系统上的强力登录,是一种虚假的安心感,而一个薄弱密码之后的细粒度权限同样是空洞的。为每一个临床系统明确地记录这两个决策,并在数据敏感度或用户群体发生变化时重新审视它们。

2. 让基于角色的访问控制反映真实的临床角色,然后保持它的整洁。 围绕照护实际是如何交付的、而不是围绕组织架构图或一个供应商默认配置的心血来潮来设计角色,并把每一个角色映射到它所需的最小记录与功能。随着时间推移,RBAC 会腐化为"角色爆炸",数百个重叠的角色累积起来,没有人能说清任何一个角色授予了什么。安排定期的角色合理化,并抵制用创造一个新的定制角色来解决每一次访问请求的诱惑。

3. 对人与机器账户同等地应用最小权限。 最小权限常规地被应用于临床医生,却对服务账户、集成引擎与报表工具被遗忘,而这些往往持有最广泛的访问权限。一个为仪表盘提取数据的自动化接口很少需要写入权限或可识别的自由文本,却常常被授予了这些权限。清点非人类身份,收窄它们的范围,并按计划轮换它们的凭证。

4. 为远程与特权访问强制要求多因素身份验证,并选择适合环境的因素。 单凭密码对任何从受信任设备之外触及患者数据的东西而言都已经站不住脚,MFA 如今是 NHS 系统的基线期望。选择能在临床环境中存活的因素:为特权与远程访问使用抗网络钓鱼的硬件令牌或平台身份验证器,并对信号差、手机被共用的病房中的短信验证码保持警惕。权衡安全收益与一位正在进行复苏抢救的临床医生无法摸索第二因素这一现实。

5. 使用单点登录来消除那种把员工推向不安全变通方案的摩擦。 当员工必须分别登录十个系统时,他们会把密码写在便利贴上,共享智能卡,并让会话保持开启——每一种都是安全与保密风险。实施良好的 SSO,理想情况下与共享临床工作站上的"刷卡进出"接近传感器结合,既能提升安全性,也能把时间还给临床医生。把 SSO 当作一项患者安全干预、而不仅仅是一种便利来对待,并衡量你所消除的登录时间。

6. 让 NHS 身份超越智能卡进行现代化,而不破坏正在起作用的东西。 NHS 照护身份服务(前身为照护身份服务,更早以前是建立在智能卡之上的注册机构制度)对 NHS 员工进行身份验证,驱动对诸如 Spine 这样国家系统的访问。国家方向如今是走向现代化的、基于标准的身份验证——带有 MFA 与 OpenID Connect 的 CIS2——减少对会失效、被共享或阻碍照护的物理智能卡与读卡器的依赖。刻意地规划你的迁移:在采纳现代令牌灵活性的同时,保留智能卡模式的保证与注册严谨性。

7. 把入职/变动/离职当作一个受控的、可审计的流程来运行——尤其是离职。 医疗与照护领域最常见的单一严重 IAM 失败,是一个比人对它的需求存活得更久的账户:轮换出去的初级医生、离职的代理护士、访问权限从未被撤销的承包商。从一个权威来源(通常是电子员工记录)自动化配置,这样开始、变更与结束一个角色,就能在一个明确定义的短窗口内触发相应的访问变更。把离职人员与被调查员工的当日撤销当作一项硬性要求、而不是一种愿景来对待。

8. 定期重新认证访问权限,并让经理对此负责。 在第一天恰当的访问权限,会随着人们变换团队而漂移,积累起他们不再需要的权利——"权限蔓延"。运行定期的访问审查(重新认证),让负责的经理或系统负责人主动确认每个人是否仍然需要每一项权利,沉默默认导致移除、而不是保留。用平实的临床角色语言、而不是任何经理都无法解读的原始权限代码来呈现这次审查,让它变得有意义。

9. 把特权访问当作一个独立的类别来治理。 管理员、数据库所有者与基础设施工程师能够读取或修改任何记录,并能禁用保护它的管控措施本身,因此他们的访问需要比普通用户更强的处理。实施特权访问管理:把管理员身份与日常账户分开,按需即时地、限时地授予提升权限、而不是让其常设,并记录特权会话以供独立审查。绝不能让一个供应商或一个"应急破窗"账户变成一把永久的、未受监控的万能钥匙。

10. 让每一个访问决策都可被审计,并真正去阅读审计记录。 一个事后无法被审查的访问控制,只是半项管控;能够回答"谁访问了这份记录、何时访问、依据什么理由?"的能力,同时支撑着保密性调查与患者安全。配置全面的、防篡改的审计日志,至关重要的是,为主动审计配置资源,包括针对自我查询、对同事或知名人士的查询,以及异常访问量的告警。一份没有人检查的审计轨迹震慑不了任何人。

11. 设计应急破窗访问,让紧急情况得到服务、滥用得到捕获。 临床医生有时确实合法地需要一份他们通常无权查看的记录——一位失去意识的患者、一次跨机构的紧急情况。提供一条明确的"应急破窗"路径,以要求提供理由、立即标记,以及强制性的事后审查来授予紧急访问,而不是迫使员工在规则与患者之间做出选择。目标是让安全的紧急行动变得容易,让没有正当理由的行动变得可见。

12. 把零信任当作一个方向来采纳,并务实地排定其顺序。 从"可信网络,内部开放"转向针对身份、设备健康状况与情境验证每一次请求,这样企业局域网上一台被攻破的笔记本电脑就不再被自动信任。这是一段贯穿强身份、设备合规、条件访问与微分段的多年旅程——而不是一个你购买的产品。把它排在基础事项(MFA、最小权限、干净的 JML)之后,并与主题 4.0——技术架构、云与遗留系统中的资产工作保持一致。

与团队讨论的问题#

1. 我们在哪些地方刻意地权衡了访问摩擦与临床安全?这个平衡是谁决定的? 每一次额外的登录、第二因素,或授权步骤都保护了保密性,却在紧急情况下花费了本身就是一项安全风险的几秒钟。这个问题迫使团队说出安全管控可能延误照护的具体地方——复苏抢救的登录、共享的病房工作站、非工作时间系统——并追问当前的平衡是由既理解临床、又理解安全后果的人所选择的,还是默认采用了供应商的设置。诚实地讨论这种张力:一个过于严格的管控会驱使便利贴密码与共享智能卡,这比它所应对的风险更糟糕,而一个过于宽松的管控则会招致窥探与泄露。寻找糟糕平衡的具体信号——员工共享凭证、会话开着不关、应急破窗被常规使用。一个好的答案会指出谁拥有每一项取舍,展示临床医生在它被设定时在场,并指出经过衡量的登录时间与变通做法比率,而不是假设。它还会承诺随着角色、系统与威胁的变化重新审视这个平衡。

2. 我们对一位离职者或变动者每次都在正确的时间范围内失去正确访问权限有多大信心? 一个比它的需求存活得更久的账户,是经典的 IAM 失败,在一个轮换的、跨多机构的医疗劳动力中,这种风险是尖锐的。这个问题探究的是入职/变动/离职是否是一个可靠的、自动化的、由权威来源驱动的流程,还是一组在有人忙碌时会悄悄失败的手动邮件。讨论那些困难的案例:在信托机构之间轮换的初级医生、只值一个班次的代理护士、承包商,以及被停职等待调查的员工。考虑对每一种情况而言,"正确的时间范围"意味着什么——当日撤销对停职是不容商量的,但对常规内部变动可能更宽松。一个好的答案能够指出证据、而不是意图:上一次离职审计的结果、发现并关闭的休眠账户数量,以及某人离职与其访问权限终止之间的时间间隔。它对缺口保持诚实,并说出谁负责关闭它们。

3. 当一份记录出了问题时,我们能否真正重建谁做了什么——如果没有一起事故来提醒我们,我们会注意到滥用吗? 审计是让保密性与安全性能够在事后被强制执行的管控措施,但它只有在日志完整、受保护,并真正被审查时才有效。这个问题区分了一个团队常常混为一谈的两件事:当一起投诉到来时被动地调查的能力,以及在任何人投诉之前主动侦测滥用的能力。探索你的日志实际上捕捉了什么,它们能否被修改,保留多久,以及——更难的问题——在没有事故时谁会去查看它们。考虑现实的威胁:一名员工查询一位家庭成员、一位同事,或一位公众人物;一个被攻破的账户大规模泄露记录。一个好的答案会展示审计是被资源配置为一项主动职能、配有告警,而不是一份休眠的档案,并能引用一个机构曾经侦测并采取行动的真实滥用案例。它还会把审计与公平性联系起来,确保审查不会不成比例地针对特定的员工群体。

4. 当一位临床医生合法地需要一份他们通常无权查看的记录时,我们的应急破窗路径是否让安全的行动变得容易、让没有正当理由的行动变得可见? 医疗与照护领域与普通企业 IT 的不同之处,恰恰在于规则有时必须向眼前的患者让步——一位失去意识送来的患者、一次跨机构的紧急情况、一位覆盖陌生病例负荷的非工作时间临床医生。这个问题追问紧急访问是否被设计为一条明确的、有理由的、被标记的路径,还是员工被悄悄地迫在访问政策与患者福祉之间做出选择。探究两端的失败模式:一条繁琐到临床医生避开它、转而共享凭证的应急破窗路径,或一条无摩擦、未经审查到成为常规入口、彻底掏空 RBAC 的路径。讨论谁审查应急破窗事件、多快审查,以及有多大比例最终被证明没有正当理由——一个接近零的比率可能意味着这项管控未被使用、而不是干净。一个好的答案能够描述一位临床医生所采取的确切步骤、理由捕捉、向记录所属机构的立即标记,以及闭合这个循环的事后审查,并能展示紧急情况确实得到了服务、滥用确实被捕获。它对应急破窗的使用量是否呈现出暗示更深层授权缺口的趋势保持诚实。

5. 我们对特权与非人类访问的治理,是否与我们对临床医生的治理同样严格——还是那里正是真正的暴露所在? 保护患者数据的管控措施本身是由某人管理的,管理员、数据库所有者、集成引擎与报表账户,常常能够读取或修改任何记录,并关闭约束着其他所有人的正是那些保障措施。这个问题把最小权限纪律最容易忽视的访问拖到了光天化日之下:常设的管理员账户、供应商的远程支持登录、拥有上帝模式权利的服务账户,以及一个悄悄提取它从未需要过的可识别自由文本的自动化接口。讨论管理员身份是否与日常账户分开,提升权限是即时且限时的、还是永久的,以及特权会话是否被记录并独立审查。特别考虑非人类的资产——谁拥有每一个服务账户,它的凭证上一次被轮换是什么时候,今天是否有人能够把它们全部列举出来。一个好的答案会把特权访问当作一个独立的类别来对待,有具名的负责人、即时提升的证据,以及一份真实的机器身份清单,而不是假设应用于临床医生的基础事项也必然覆盖了后台。它对供应商,以及任何已经变成永久、未受监控万能钥匙的账户保持坦率。

6. 我们的身份有多大程度依赖于我们掌控之外的各方?我们对这种依赖是否刻意? 现代医疗与照护身份在设计上是联合的——一份共享记录信任每个合作机构的断言,诸如 NHS 照护身份服务与 CIS2 这样的国家服务为员工担保,NHS login 为市民担保——这意味着你访问控制的强度,永远只能与你所依赖的身份提供商、以及把你们绑定在一起的标准一样强。这个问题要求团队绘制出信任被委托到哪里:哪些机构为哪些用户提供身份验证,当一个合作方的入职/变动/离职流程失败时会发生什么,以及当另一个雇主的员工离职时,一次联合登录如何被撤销。权衡正在进行中的从智能卡向基于标准的身份验证(带 MFA 与 OpenID Connect 的 CIS2)的迁移,以及采纳国家方向与保持本地工作流程在凌晨三点依然正常运作之间的张力。也要考虑韧性角度:如果一项国家身份服务不可用,临床医生是否依然能够安全地触及他们所需的记录,还是联合会变成一个单点故障。一个好的答案会展示团队确切地知道自己依赖的是谁的保证,已经商定了跨机构的撤销与事故如何处理,并正在刻意地、而不是被动地排定向现代 NHS 身份验证迁移的顺序。它对资产中尚不能联合的部分、以及在此期间如何被桥接保持现实。

实践中:一个医疗与照护案例#

Meadowvale 整合照护系统正在推出一份共享照护记录,让医院、社区、精神健康、全科诊所与成人社会照护的员工能够看到每个人统一的视图。在探索阶段早期,该项目意识到它真正的风险不是构建这份记录,而是控制对它的访问:一个横跨五个机构的单一视图,既放大了正确临床医生看到正确信息的安全效益,也放大了错误的人看到敏感信息的伤害。

团队把访问控制当作一条头等的设计线。他们商定了一个用临床语言表达的角色模型——"社区护士"、"经批准的精神健康专业人员"、"养老院经理"——并把每个角色映射到它所需的最小数据,精神健康与性健康记录受到更严格的、单独授权的访问约束。身份验证是联合的:每个合作机构通过 NHS 照护身份服务或其本地身份提供商、使用 OpenID Connect 对自己的员工进行身份验证,共享记录信任这些断言,而不是发放自己的凭证,因此没有新的密码需要管理,入职/变动/离职保留在拥有权威员工记录的雇主机构那里。

因为一位护理人员或一位非工作时间临床医生有时会需要一份他们通常无权查看的记录,团队构建了一条明确的应急破窗路径:紧急访问在输入一个理由后被授予,立即标记给记录所属机构,并在 48 小时内接受审查。他们组建了一个小型的联合信息治理与审计职能,审查应急破窗事件,为自我查询与被标记个人的查询运行告警,并每季度向 ICS 董事会报告。

上线六个月后,一条告警标记出一位护理协调员反复打开一个与其病例负荷没有当前关联的人的记录。审计职能展开调查,发现这次访问是个人性质的、而不是专业性质的,雇主机构采取了纪律处分。没有发生患者安全事故,这次违规被主动捕获——而且,因为这些管控措施被证明是有效的,公众对这份共享记录的信心得以保持。董事会指出,同样的审计能力如今也充当了其数据安全与保护工具包提交材料的证据(见主题 1.7——信息治理、数据保护与网络安全)。

行业视角#

初创企业#

一家小型数字医疗公司,比如正在构建一款远程监测应用,拥有没有遗留系统的优势:它能够从第一天起就采用现代身份验证、MFA 与基于标准的联合,与面向市民的 NHS login 及面向临床医生的 CIS2 集成,而不是发明自己的身份系统。危险在于速度超过了纪律——硬编码的管理员凭证、一个共享的"创始人"超级用户账户、拥有上帝模式访问权限的服务账户,以及因为"每个人都认识每个人"而没有离职流程。在十个人的规模上,最小权限与审计感觉像是开销,但在一百人的规模上会变成无法挽回的技术债。务实的做法是把身份识别当作一项托管服务来购买,从第一次提交起就强制执行 MFA 与 RBAC,并把 DTAC(数字技术评估标准)要求当作任何 NHS 部署的最低门槛来对待。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院、一家居家照护机构、一家单一场所的诊所,或一家已过预收入阶段的小型健康科技供应商——承担着与大型信托机构同样的保密性与访问控制职责,却有真实的在册患者、寥寥数名员工,几乎没有专门的 IT 能力来满足它们。这里现实的风险并不异乎寻常:是前台共享的登录账户、贴在显示器上的临床系统密码、因为注册一张新智能卡太费时间而被给予一位同事智能卡的临时医生,以及一个从未被禁用的账户、因为没有人负责这项工作而离职的员工。务实的路径是依靠他们所购买系统中已经内建的身份识别功能——强制执行 MFA 与逐人账户,打开供应商的审计日志功能,使用 NHS CIS2 与 NHS login,而不是自制凭证——并写下一份简单的入职/变动/离职常规流程,指定一位负责人,即使这个人是手动执行的执业经理。最小权限与当日离职撤销在十名员工与一万名员工那里同样重要;区别在于,这里必须靠流程与配置来实现,而不是靠一支专职的身份团队。

大型企业#

一家大型 NHS 信托机构或 ICS 运行着数十个年代差异巨大的临床系统,每一个都有自己的身份模型,它的核心挑战是规模化的集成与生命周期管理。智能卡、SSO、"刷卡进出"工作流程,以及一条源自电子员工记录的可靠 JML 管线,在这里比任何单一的巧妙管控更重要,因为失败模式是规模性的:数千个休眠账户、角色爆炸,以及没有人有能力审查的审计日志。鉴于接触这片资产的管理员与供应商数量众多,特权访问管理至关重要。进展来自一个合理化角色、跨系统联合,并为一项常设审计职能提供资源的身份战略——而不是附加在每个应用上的点状解决方案。

政府机构#

一个国家机构,如 NHS England,把身份识别当作整个系统的共享基础设施来运营:面向员工的 NHS 照护身份服务与 CIS2,面向市民的 NHS login,以及让数百个机构能够相互信任的标准与保证制度。它的决策设定了演进方向——从智能卡转向现代身份验证、采纳 OpenID Connect、推动零信任——它对议会与公众在安全性与公平接入两方面负有问责。张力在于中央标准化与地方灵活性之间的矛盾:强制得太僵化,你会破坏本地工作流程;强制得太松散,联合就会崩溃为不一致。因此,政府的视角是关于制定可互操作的标准(见主题 4.3——互操作性与数据标准)、提供可信赖的共享服务,以及保证合规性,而不必对每一家信托机构进行微观管理。

常见失败模式#

• 孤儿式与休眠账户。 离职者、轮换员工与旧承包商保留着活跃的访问权限,因为 JML 依赖手动通知。解药是从一个权威来源自动化取消配置,加上定期的休眠账户排查。
• 角色爆炸与权限蔓延。 RBAC 腐化为数百个重叠的角色,个人累积着他们不再使用的权利。用定期的重新认证与按计划的角色合理化来对抗。
• 凭证共享与共享工作站。 缓慢的登录与笨拙的智能卡驱使员工共享卡片并让会话保持开启。用 SSO、接近感应徽章,与快速切换来解决根本原因,而不是劝告员工规范行为。
• 常设的特权访问。 管理员与供应商持有能够禁用管控措施本身的永久上帝模式账户。转向即时的、限时的、有记录的提升。
• 审计沦为装饰。 日志被收集却从未被审查,导致滥用只能被动地被发现。为主动审计配置资源,对自我查询与知名人士查询设置告警。
• 应急破窗变成一个漏洞。 紧急访问存在,却未受监控,变成了阻力最小的常规路径。要求一个理由,标记每一次使用,并事后审查。
• MFA 的表演。 MFA 被启用,却使用薄弱、易受网络钓鱼的因素,或对最繁忙的特权用户被豁免。在风险最高的地方优先选择抗网络钓鱼的因素。

成熟度模型#

检查清单#

• 每个临床系统的身份验证强度与授权范围都被单独决定并记录。
• 所有远程与特权访问都强制执行 MFA,使用适合临床环境的因素。
• 部署了单点登录与快速工作站切换,以消除登录摩擦与凭证共享。
• 角色模型用临床语言表达,映射到最小权限,并按计划被合理化。
• 入职/变动/离职从一个权威员工来源自动化,离职与停职实现当日撤销。
• 由负责任的经理运行定期的访问重新认证,未经确认的访问默认被移除。
• 特权访问被当作一个独立类别来管理:独立身份、即时提升、会话记录。
• 非人类与集成账户被清点、被限定为最小权限,并轮换凭证。
• 部署了全面的、防篡改的审计日志,对自我、同事与知名人士查询设有主动告警。
• 应急破窗紧急访问被设计为要求提供理由、立即标记,并事后审查。
• 从智能卡向现代 NHS 身份验证(CIS2 / OpenID Connect)的迁移已被规划并排定顺序。
• 零信任路线图已被商定,并与技术架构战略保持一致。

关键来源#

• NHS England ——NHS 照护身份服务与照护身份服务 2(CIS2)指导
• NHS England ——数据安全与保护工具包
• 国家网络安全中心(NCSC)——零信任架构设计原则
• 国家网络安全中心(NCSC)——多因素身份验证与身份/访问管理指导
• NIST ——特别出版物 800-207,零信任架构
• NIST ——特别出版物 800-63,数字身份指南
• NHS England / NHS login ——市民身份核验服务文档
• DTAC ——医疗与社会照护的数字技术评估标准
• Caldicott 原则与普通法保密义务(英国)

参考文献#

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/