トピック4.2 — IDとアクセスの管理

医療・ケアでは、誰が患者の記録を見て、何を行えるかを制御することは、ITの日常的な雑務ではなく、臨床安全、守秘、公的信頼を左右する、最前線の決定要因です。

医療・ケアにおいてなぜ重要か#

あらゆる臨床上の判断は、臨床家の目の前の記録が、正しい記録であり、正しい患者のものであり、正しい人によって到達されたという想定の上に成り立っています。IDとアクセスの管理（IAM）は、その三つの想定を真にする仕組みです。機能していれば、救急隊員は間に合うようにアレルギーを見て、セーフガーディングのメモは必要な人にだけ届き、監査証跡は「誰が、なぜこの記録を見たのか」という問いに答えられます。失敗すれば、誤った名前で開かれた記録によって患者が害を受け、職員が親族や有名人を覗き見し、デジタルの取り組み全体への信頼が損なわれます。

医療・ケアは、三つの点で、通常の企業の場合より利害を高めます。第一に、データは人が生涯に作り出す最も機微なものの一つ、つまり精神保健、性の健康、物質使用、ジェンダーアイデンティティ、セーフガーディングの懸念であるため、守秘の侵害は不便ではなく、持続的な害です。第二に、職員は流動的で、ローテーションし、複数の組織にまたがります。研修医は数か月ごとに異動し、派遣や臨時の職員は1回のシフトのために到着し、統合ケアでは、地域看護師が正当に病院の記録を必要とすることがあります。第三に、注意義務は摩擦に容赦がありません。蘇生の場で、午前3時にあまりに遅いアクセス制御は、それ自体が安全上のハザードです。したがって、このセクターでのIAMは、データを締め付けることと、適切な人を素早く入れることの間の、絶え間ない交渉です。

本トピックは、トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティで扱う、より広い義務の下にある、アクセス制御の深さを扱います。あのトピックが、英国一般データ保護規則、Data Security and Protection Toolkit、守秘義務という法的・組織的な枠組みを定めるのに対し、本トピックは、身元を証明し、仕事をするのに必要な最小限のアクセスを付与するという、具体的な仕組みについてです。

中核概念#

IDとアクセスの管理は、適切な個人が、適切なときに、適切な資源への適切なアクセスを持ち、それを後から証明できるようにする、規律と技術の集合です。それは、曖昧にしやすく失うと危険な区別、つまり認証と認可の違いの上に成り立っています。

認証は「あなたは、名乗るとおりの人か」に答えます。要素によって証明されます。知っているもの（パスワードやPIN）、持っているもの（スマートカード、電話、ハードウェアトークン）、あなた自身であるもの（指紋や顔）。認可は、別の問いに答えます。「あなたが誰かわかったので、何を見て、何をしてよいのか」。専門医と受付の両方が完全にうまく認証できても、記録の非常に異なる部分に対して認可されています。この二つを混同すると、身元は強く確認するが、そのあと全員にすべてを見せるシステムになります。

医療・ケアでの認可は、通常、ロールベースのアクセス制御（RBAC）として組織されます。権限は、「救急部門の看護師」「一般診療医」「医療秘書」といったロールに付き、人は、権利を一つずつ付与されるのではなく、ロールを持つことで権限を引き継ぎます。RBACは、最小権限の原則によって統べられます。各人、そして各システムアカウントは、仕事に必要な最小限のアクセスを持ち、それ以上は持つべきではありません。最小権限は、偶発的な誤りと、侵害されたアカウントの影響範囲の両方を制限します。

現代の認証は、「身元を証明する」ステップを多要素認証（MFA）で強化し、盗まれたパスワードだけでは十分でないよう、二つ以上の要素を組み合わせます。それは、一つの認証済みセッションが、繰り返しのログインなしに多くのアプリケーションへのアクセスを与えるシングルサインオン（SSO）によって、摩擦を減らします。臨床家が1時間に十数のシステムを行き来しなければならないときの、本物の安全上の利点です。組織の境界をまたぐSSOは、フェデレーテッドIDに依拠します。ある組織が、ユーザーの認証情報を保持しなくても、別の組織がそのユーザーを信頼できるよう、保証します。

フェデレーションと現代の認証の配管は、オープン標準の上に築かれています。OAuthは、パスワードを渡さずに、アプリケーションに代理で行動させる、委任された認可の標準です。OpenID Connectは、OAuthの上に認証を重ね、アプリケーションがユーザーが誰かを知れるようにし、より古いXMLベースのSecurity Assertion Markup Language（SAML）は、企業のSSOのために同様の役割を果たします。IDのライフサイクル、つまり人が入職し、異動し、退職するときのアクセスの付与、変更、取り消しは、一般にジョイナー/ムーバー/リーバー（JML）と呼ばれるプロビジョニングのプロセスによって扱われます。

戦略的な進む方向は、ゼロトラストアーキテクチャです。どのユーザーや端末も、単にネットワークの内側にいるからといって信頼できるとは限らないという想定です。すべての要求は、堅牢化された境界に頼るのではなく、端末の健全性、場所、データの機微さといった文脈に照らして、認証され、認可され、確認されます。職員がクリニック、自宅、救急車、パートナーの拠点から働くセクターでは、境界は事実上溶解しており、ゼロトラストは、それへの誠実な対応の名前です。

ベストプラクティス#

1. 認証と認可を、別々の設計判断として扱う。 最初に、あるシステムで身元をどれだけ強く証明しなければならないかを決め、別に、そのあと各ロールが何をできるかを、どれだけ細かく制御しなければならないかを決めます。全員に完全なアクセスを与えるシステムでの強力なログインは偽りの安心であり、弱いパスワードの背後のきめ細かな権限も、同じく空虚です。あらゆる臨床システムについて、両方の決定を明示的に文書化し、データの機微さやユーザー集団が変わったときに見直してください。

2. ロールベースのアクセス制御を、実際の臨床のロールを映したものにし、きれいに保つ。 ロールを、組織図やサプライヤーの既定の構成の気まぐれではなく、ケアが実際にどう提供されるかを軸に設計し、各ロールを、必要な最小限の記録と機能に対応づけます。時間とともに、RBACは「ロールの爆発」へと劣化し、何百もの重なり合うロールが蓄積して、そのどれが何を付与するのか、誰も言えなくなります。定期的なロールの合理化を予定し、あらゆるアクセス要求を新しい特注ロールを作って解決する誘惑に抵抗してください。

3. 最小権限を、人にも、機械のアカウントにも同じように適用する。 最小権限は、臨床家には日常的に適用されても、しばしば最も広いアクセスを持つ、サービスアカウント、連携エンジン、報告ツールには忘れられます。ダッシュボードのためにデータを引く自動のインターフェースは、書き込みのアクセスや識別可能な自由記述をめったに必要としないのに、しばしばそれを得ます。人間でないIDを一覧化し、範囲を絞り、予定に沿って認証情報をローテーションしてください。

4. リモートおよび特権のアクセスにはMFAを義務づけ、その場に合った要素を選ぶ。 信頼された端末の外から患者データに届くあらゆるものについて、パスワードだけではもはや擁護できず、MFAは、NHSのシステム全体でいまや基本的な期待です。臨床の環境に耐える要素を選んでください。特権とリモートのアクセスにはフィッシング耐性のあるハードウェアトークンやプラットフォーム認証器を、電波が悪く電話が共有される病棟でのSMSコードには注意を。セキュリティ上の利益を、蘇生の最中の臨床家が、二つ目の要素を手探りできないという現実と比較してください。

5. シングルサインオンを使って、職員を危険な回避策へ押しやる摩擦を取り除く。 職員が十のシステムに別々にログインしなければならないとき、パスワードを付箋に書き、スマートカードを共有し、セッションを開いたままにし、そのどれもが安全と守秘のリスクです。よく実装されたSSOは、理想的には共有の臨床ワークステーションでの「タップイン、タップアウト」の近接バッジと組み合わされ、セキュリティを改善し、臨床家に時間を返します。SSOを、単なる便宜ではなく患者安全の介入として扱い、取り除いたログイン時間を測定してください。

6. 動いているものを壊さずに、スマートカードを超えてNHSのIDを近代化する。 NHS Care Identity Service（旧Care Identity Service、さらにその前の、スマートカードを軸に築かれたRegistration Authorityの制度）は、NHSの職員を認証し、Spineのような国のシステムへのアクセスを駆動します。国の方向性は、いまや現代的で標準に基づく認証、つまりMFAとOpenID Connectを伴うCIS2へ向かっており、故障し、共有され、ケアを妨げる物理的なスマートカードとカードリーダーへの依存を減らします。移行を意図的に計画してください。スマートカードのモデルが持つ、アシュアランスと登録の厳密さを保ちながら、現代的なトークンの柔軟性を採用します。

7. ジョイナー/ムーバー/リーバーを、管理され監査可能なプロセスとして運営する。特にリーバーを。 医療・ケアで最もありふれた深刻なIAMの失敗は、その人の必要より長く生き残るアカウントです。異動した研修医、去った派遣看護師、アクセスが取り消されなかった契約者。権威ある情報源（通常は電子職員記録）からのプロビジョニングを自動化し、役割の開始、変更、終了が、定義された短い時間内に対応するアクセスの変更を引き起こすようにします。リーバーと、調査対象の職員の当日中の取り消しを、願望ではなく、厳格な要件として扱います。

8. アクセスを定期的に再認証し、マネージャーに責任を持たせる。 初日には適切だったアクセスは、人々がチームを変え、もう必要のない権利を蓄積するにつれてドリフトします。「特権のクリープ」です。責任あるマネージャーやシステムの所有者が、各人が各権利をまだ必要としているかを積極的に確認する、定期的なアクセスレビュー（再認証）を行い、沈黙は、保持ではなく削除を既定とします。マネージャーが解釈できない生の権限コードではなく、平易な臨床のロールの言葉で提示することで、レビューを意味のあるものにしてください。

9. 特権アクセスを、それ自体のカテゴリーとして統治する。 管理者、データベースの所有者、インフラのエンジニアは、あらゆる記録を読み取りまたは改変でき、それを守るまさにその統制を無効にできるため、そのアクセスには、通常のユーザーより強い扱いが必要です。特権アクセス管理を実装します。管理者のIDを日常のアカウントから分離し、昇格した権利を、常設ではなく、ジャストインタイムで期限付きで付与し、独立したレビューのために特権セッションを記録します。サプライヤーや「ブレークグラス」アカウントが、恒久的で監視されないマスターキーになってはなりません。

10. あらゆるアクセスの決定を監査可能にし、監査を実際に読む。 あとからレビューできないアクセス制御は、半分しか統制ではありません。「誰が、いつ、どんな根拠でこの記録にアクセスしたか」に答えられることが、守秘の調査と患者安全の両方を支えます。包括的で改ざん検知可能な監査ログを設定し、そして決定的に、自分自身の照会、同僚やVIPの照会、異常なアクセス量へのアラートを含む、積極的な監査に資源を割り当てます。誰も調べない監査証跡は、誰も抑止しません。

11. 緊急事態に対応でき、不正が捉えられるよう、ブレークグラスのアクセスを設計する。 臨床家は、通常は認可されていない記録を、正当に必要とすることがあります。意識のない患者、組織をまたぐ緊急事態。必要な理由、即時のフラグ付け、事後の必須のレビューを伴って緊急アクセスを付与する、明示的な「ブレークグラス」の経路を用意し、職員にルールと患者のどちらかを選ばせないようにします。目標は、安全な緊急の行動を簡単にし、正当化されない行動を見えるようにすることです。

12. ゼロトラストを方向として採用し、現実的に順序づける。 「信頼されたネットワーク、内側は開放」から、あらゆる要求を、ID、端末の健全性、文脈に照らして検証する方向へ移行し、企業のLAN上の侵害されたノートパソコンが、もはや自動的に信頼されないようにします。これは、強力なID、端末のコンプライアンス、条件付きアクセス、マイクロセグメンテーションを通じた複数年の旅路であり、購入するプロダクトではありません。基本（MFA、最小権限、きれいなJML）の後に順序づけ、トピック4.0 — 技術アーキテクチャ、クラウド、レガシーシステムの環境の作業と整合させます。

チームで話し合うための問い#

1. アクセスの摩擦と臨床安全を、どこで意図的にトレードオフにしているか。そして、そのバランスを誰が決めたのか。 ログイン、第二の要素、認可のステップが一つ増えるごとに、守秘は守られますが、緊急時にはそれ自体が安全上のリスクである数秒のコストがかかります。この問いは、チームに、セキュリティの統制がケアを遅らせうる具体的な場所、つまり蘇生のログイン、共有の病棟のワークステーション、時間外のシステムを名指しさせ、現在のバランスが、臨床とセキュリティ双方の結果を理解する人々によって選ばれたのか、サプライヤーの設定を既定にしただけなのかを問わせます。緊張を正直に議論してください。締めすぎた統制は、それが対処するリスクより悪い、付箋のパスワードや共有のスマートカードを駆り立て、緩すぎるものは、覗き見と侵害を招きます。悪いバランスの具体的なシグナルを探します。認証情報を共有する職員、開いたままのセッション、日常的に使われるブレークグラス。良い答えは、各トレードオフの所有者を特定し、それが設定されたとき、臨床家がその場にいたことを示し、想定ではなく、測定されたログイン時間と回避策の率を指し示します。ロール、システム、脅威が変わるなかで、バランスを見直すことにもコミットします。

2. リーバーやムーバーが、適切なアクセスを、適切な時間枠で、毎回失うことに、どれだけ自信があるか。 必要より長く生き残るアカウントは、典型的なIAMの失敗であり、ローテーションし、複数の組織にまたがる医療職員では、リスクは切実です。この問いは、ジョイナー/ムーバー/リーバーが、権威ある情報源から駆動される、信頼できる自動化されたプロセスなのか、誰かが忙しいときに静かに失敗する、手動のメールの集まりなのかを探ります。難しいケースを議論してください。トラスト間を異動する研修医、1回のシフトの派遣看護師、契約者、調査中に停止された職員。それぞれにとって「適切な時間枠」が何を意味するかを考えます。停止については当日の取り消しは譲れませんが、通常の内部異動ではもう少し緩いかもしれません。良い答えは、意図ではなくエビデンスを示せます。直近のリーバー監査の結果、発見して閉じた休眠アカウントの数、誰かが去ってからそのアクセスが終わるまでの時間。ギャップについて誠実であり、それを解消する責任者を挙げます。

3. 記録に何かがあったとき、誰が何をしたかを実際に再構築できるか。そして、インシデントが促さなくても、悪用に気づけるか。 監査は、守秘と安全を事後に実効あるものにする統制ですが、ログが完全で、保護され、本当にレビューされる場合にのみ機能します。この問いは、チームがしばしば混同する二つのこと、つまり苦情が届いたときに事後的に調査する能力と、誰かが苦情を言う前に積極的に悪用を検知する能力を、切り分けます。ログが実際に何を捉えているか、改変されうるか、どれだけ保持されるか、そしてより難しい問いとして、インシデントがないときに誰がそれを見るかを探ってください。現実的な脅威を考えます。家族、同僚、著名人を調べる職員、大規模に記録を抜き出す侵害されたアカウント。良い答えは、監査が、休眠したアーカイブではなく、アラートを伴う積極的な機能として資源を与えられていることを示し、組織が検知して対処した、実際の悪用の例を挙げられます。また、監査を公正さに結びつけ、レビューが特定の職員集団を不釣り合いに狙わないようにします。

4. 臨床家が、通常は認可されていない記録を正当に必要とするとき、私たちのブレークグラスの経路は、安全な行動を簡単にし、正当化されない行動を見えるようにしているか。 医療・ケアが通常の企業ITと異なるのは、まさに、ルールが、目の前の患者のために、時には譲らなければならないからです。意識のない搬入、組織をまたぐ緊急事態、不慣れな担当を受け持つ時間外の臨床家。この問いは、緊急時のアクセスが、明示的で、理由のある、フラグの付く経路として設計されているのか、職員が、アクセスの方針と患者の福祉のどちらかを選ぶよう静かに強いられているのかを問います。両端の失敗モードを探ってください。臨床家が避けて認証情報を共有するほど煩雑なブレークグラスの経路か、摩擦がなくレビューされないために日常の入り口になり、RBACを完全に空洞化させるもの。誰がブレークグラスの事象を、どれだけ速くレビューするか、そのうちどれだけの割合が正当化されないと判明するかを議論します。ゼロに近い率は、統制がきれいなのではなく、使われていないことを意味するかもしれません。良い答えは、臨床家が取る正確なステップ、理由の記録、記録の所属組織への即時のフラグ、ループを閉じる事後のレビューを説明でき、緊急事態が本当に満たされ、不正が本当に捉えられることを示せます。ブレークグラスの件数が、より深い認可のギャップを示唆する方向に推移していないかについても誠実です。

5. 特権アクセスと人間でないアクセスを、臨床家と同じくらい厳格に統治しているか。それとも、本当のリスクがそこにあるのではないか。 患者データを守る統制は、それ自体が誰かによって管理されており、管理者、データベースの所有者、連携エンジン、報告アカウントは、あらゆる記録を読み取りまたは改変でき、ほかの全員を制約するまさにその安全装置を切れることがよくあります。この問いは、最小権限の規律が最も飛ばしやすいアクセスを、光の下に引きずり出します。常設の管理者アカウント、サプライヤーのリモートサポートのログイン、全能の権利を持つサービスアカウント、必要のなかった識別可能な自由記述を静かに引き出している自動のインターフェース。管理者のIDが日常のアカウントから分離されているか、昇格がジャストインタイムで期限付きなのか恒久なのか、特権セッションが記録され独立してレビューされているかを議論してください。特に人間でないものの環境を考えます。各サービスアカウントを誰が所有し、認証情報が最後にローテーションされたのはいつか、誰かが今日それらを列挙できるか。良い答えは、特権アクセスを、名前のある所有者、ジャストインタイムの昇格のエビデンス、機械のIDの本物のインベントリを伴う、それ自体のカテゴリーとして扱い、臨床家に適用された基本が、当然バックオフィスもカバーするという想定ではありません。サプライヤーについて、そして恒久的で監視されないマスターキーになったあらゆるアカウントについて、率直です。

6. 私たちのIDのどれだけが、制御できない当事者に依存しているか。そして、その依存について意図的か。 現代の医療・ケアのIDは、設計上フェデレーテッドです。共有記録は各パートナー組織の主張を信頼し、NHS Care Identity ServiceやCIS2のような国のサービスが職員を保証し、NHS loginが市民を保証します。つまり、アクセス制御の強さは、頼るIDプロバイダーと、互いを結びつける標準と同じだけのものにすぎません。この問いは、チームに、信頼がどこで委任されているかを描くよう求めます。どの組織がどのユーザーを認証しているか、パートナーのジョイナー/ムーバー/リーバーのプロセスが失敗したら何が起きるか、別の雇用主の職員が去ったとき、フェデレーテッドなログインがどう取り消されるか。スマートカードから、標準に基づく認証（MFAとOpenID Connectを伴うCIS2）への、進行中の移行と、国の方向を採用することと、午前3時に地域のワークフローを機能させ続けることとの緊張を比較考量してください。レジリエンスの観点も考えます。国のIDサービスが利用できないとき、臨床家は必要な記録に安全にたどり着けるか、それともフェデレーションが単一障害点になるか。良い答えは、チームが、誰のアシュアランスに頼っているかを正確に知り、組織をまたぐ取り消しとインシデントをどう扱うかに合意し、現代のNHS認証への移行を、それに引きずられるのではなく、意図的に順序づけていることを示します。まだフェデレーションできない環境の部分と、そのあいだそれがどう橋渡しされているかについて、現実的です。

実践例：医療・ケアの事例#

Meadowvale統合ケアシステムは、病院、コミュニティ、精神保健、一般診療、成人社会的ケアの職員が、一人ひとりの統一されたビューを見られるよう、共有ケア記録を導入しています。ディスカバリーの早い段階で、プログラムは、本当のリスクが記録の構築ではなく、そこへのアクセスの制御であることに気づきます。5つの組織にまたがる単一のビューは、適切な臨床家が適切な情報を見るという安全上の利益と、誤った人が機微なものを見るという害の両方を増幅するのです。

チームは、アクセス制御を第一級の設計の流れにします。「地域看護師」「認定精神保健専門職」「介護施設の管理者」といった臨床の言葉で表現されたロールのモデルに合意し、各ロールを必要な最小限のデータに対応づけ、精神保健と性の健康の記録には、より厳格で、別個に認可されたアクセスを課します。認証はフェデレーテッドです。各パートナー組織が、自組織の職員を、NHS Care Identity Serviceか地域のIDプロバイダーを通じてOpenID Connectで認証し、共有記録は、自前の認証情報を発行するのではなく、それらの主張を信頼します。そのため、管理すべき新しいパスワードはなく、ジョイナー/ムーバー/リーバーは、権威ある職員の記録がある、雇用する組織に留まります。

救急隊員や時間外の臨床家が、通常は認可されていない記録を必要とすることがあるため、チームは、明示的なブレークグラスの経路を構築します。緊急アクセスは、理由を入力すると付与され、記録の所属組織に即座にフラグが立ち、48時間以内にレビューされます。彼らは、ブレークグラスの事象をレビューし、自分自身の照会とフラグ付きの個人の照会へのアラートを運用し、四半期ごとにICSの取締役会に報告する、小さな共同の情報ガバナンスと監査の機能を立ち上げます。

稼働から6か月後、アラートが、ある介護コーディネーターが、自分の担当に積極的な関与のない人の記録を繰り返し開いていることにフラグを立てます。監査の機能が調査し、アクセスが専門職としてではなく私的なものであったと突き止め、雇用する組織が懲戒処分を取ります。患者安全のインシデントは起きず、侵害は積極的に捉えられ、そして統制が機能することが示されたため、共有記録への国民の信頼は保たれました。取締役会は、同じ監査能力が、いまや、Data Security and Protection Toolkitの提出のエビデンスにもなっていることに注目します（トピック1.7 — 情報ガバナンス、データ保護、サイバーセキュリティ参照）。

セクター別の視点#

スタートアップ#

たとえば遠隔モニタリングのアプリを作る、小さなデジタルヘルス企業には、レガシーがないという利点があります。最初の日から現代の認証、MFA、標準に基づくフェデレーションを採用し、自前のIDシステムを発明するのではなく、市民向けのNHS loginと臨床家向けのCIS2と連携できます。危険は、規律を追い越す速さです。ハードコードされた管理者の認証情報、共有の「創業者」スーパーユーザーのアカウント、全能のアクセスを持つサービスアカウント、そして「全員がお互いを知っている」ために存在しないリーバーのプロセス。最小権限と監査は、10人のときは間接費に感じられますが、100人になると取り返しのつかない技術的負債になります。現実的な手は、IDをマネージドサービスとして購入し、最初のコミットからMFAとRBACを徹底し、NHSへのあらゆる導入について、DTAC（Digital Technology Assessment Criteria）の要件を最低限の基準として扱うことです。

小規模事業者#

確立した小規模の提供者、つまり一般診療所、地域薬局、介護施設、訪問介護事業所、単独拠点のクリニック、収益前の段階を過ぎた小規模なヘルステックのサプライヤーは、大きなトラストと同じ守秘とアクセス制御の義務を負いながら、名簿に実際の患者がおり、職員は数人で、それを満たす専任のIT能力はほとんどありません。ここでの実務上のリスクは特殊なものではありません。受付の共有ログイン、モニターに貼られた臨床システムのパスワード、新しいものを登録するのに時間がかかりすぎるため同僚のスマートカードを渡された臨時職員、そして誰もその仕事を所有していないために無効化されないリーバーのアカウント。現実的な道は、購入するシステムにすでに組み込まれているID機能に頼ることです。MFAと個人ごとのアカウントを徹底し、サプライヤーの監査ログを有効にし、自前の認証情報ではなくNHS CIS2とNHS loginを使い、手作業で行う診療所マネージャーであっても、一人の責任者を名指しした、簡単なジョイナー/ムーバー/リーバーの手順を書き留めます。最小権限と当日のリーバーの取り消しは、10人の職員でも1万人でも同じように重要です。違いは、ここでは、専任のIDチームではなく、プロセスと設定で達成しなければならないことです。

大企業#

大規模なNHSトラストやICSは、年代がまったく異なる数十の臨床システムを運用し、それぞれが独自のIDモデルを持ち、その中心的な課題は、規模での連携とライフサイクルです。スマートカード、SSO、「タップイン、タップアウト」のワークフロー、電子職員記録からの信頼できるJMLのパイプラインは、ここでは、どの単一の巧妙な統制より重要です。失敗モードは量の失敗だからです。何千もの休眠アカウント、ロールの爆発、レビューする余力が誰にもない監査ログ。環境に触れる管理者とサプライヤーの数を考えると、特権アクセス管理は重要です。進展は、ロールを合理化し、システム間でフェデレーションし、常設の監査機能に資源を割り当てるID戦略から来るのであり、各アプリケーションに付け足された個別の解決策からではありません。

政府#

NHS Englandのような国の機関は、システム全体の共有インフラとしてIDを運営します。職員向けのNHS Care Identity ServiceとCIS2、市民向けのNHS login、何百もの組織が互いを信頼できるようにする標準とアシュアランスの制度。その決定が、進む方向、つまりスマートカードから現代の認証への移行、OpenID Connectの採用、ゼロトラストへの推進を定め、その説明責任は、セキュリティと公平なアクセスの両方について、議会と国民に対するものです。緊張は、中央の標準化と地域の柔軟性の間にあります。厳格に義務づけすぎれば地域のワークフローを壊し、緩すぎれば、フェデレーションは一貫性のなさへと崩れます。したがって、政府のレンズは、相互運用可能な標準を設定し（トピック4.3 — 相互運用性とデータ標準参照）、信頼できる共有サービスを提供し、あらゆるトラストを細かく管理せずにコンプライアンスを保証することにあります。

よくある失敗パターン#

• 孤児になった休眠アカウント。 JMLが手動の通知に頼るため、リーバー、異動した職員、古い契約者が、有効なアクセスを保持する。対策は、権威ある情報源からの自動のデプロビジョニングと、定期的な休眠アカウントの一掃。
• ロールの爆発と特権のクリープ。 RBACが何百もの重なり合うロールに劣化し、個人がもう使わない権利を蓄積する。対策は、定期的な再認証と予定されたロールの合理化。
• 認証情報の共有と共有ワークステーション。 遅いログインと扱いにくいスマートカードが、職員にカードを共有させ、セッションを開いたままにさせる。職員にきちんと振る舞うよう促すのではなく、SSO、近接バッジ、素早い切り替えで根本原因に対処する。
• 常設の特権アクセス。 管理者とサプライヤーが、統制自体を無効にできる、恒久的な全能のアカウントを保持する。ジャストインタイムで期限付きの、記録される昇格へ移行する。
• 飾りとしての監査。 ログは収集されるが決してレビューされず、悪用は事後的にしか見つからない。自分自身とVIPの照会へのアラートを伴う、積極的な監査に資源を割り当てる。
• 抜け穴としてのブレークグラス。 緊急アクセスは存在するが監視されず、最も抵抗の少ない日常の経路になる。理由を求め、すべての使用にフラグを立て、事後にレビューする。
• MFAの芝居。 MFAは有効だが、弱くフィッシング可能な要素上にある、あるいは最も忙しい特権ユーザーには免除される。リスクが最も高いところでは、フィッシング耐性のある要素を優先する。

成熟度モデル#

チェックリスト#

• 認証の強さと認可の範囲が、あらゆる臨床システムについて、別々に決定され文書化されている。
• すべてのリモートおよび特権アクセスに、臨床の場に適した要素を使って、MFAが徹底されている。
• ログインの摩擦と認証情報の共有を取り除くため、シングルサインオンと素早いワークステーションの切り替えが導入されている。
• ロールモデルが臨床の言葉で表現され、最小権限に対応づけられ、予定に沿って合理化されている。
• ジョイナー/ムーバー/リーバーが、権威ある職員の情報源から自動化され、リーバーと停止の当日の取り消しがある。
• 責任あるマネージャーによる、定期的なアクセスの再認証が行われ、確認されないアクセスは削除が既定になっている。
• 特権アクセスが、別個のカテゴリーとして管理されている：分離されたID、ジャストインタイムの昇格、セッション記録。
• 人間でないアカウントと連携アカウントが一覧化され、最小権限に絞られ、認証情報がローテーションされている。
• 包括的で改ざん検知可能な監査ログがあり、自分自身、同僚、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) — Zero Trust Architecture Design Principles
• National Cyber Security Centre (NCSC) — 多要素認証とID/アクセス管理のガイダンス
• 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
• 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/