医療情報システム安全管理ガイドライン第7.0版を読み解く（２）

第２回
医療ガイドライン7.0版対応二要素認証はどこまで必要か

第1回では、「医療情報システムの安全管理に関するガイドライン第7.0版」（以下、本ガイドライン）の改定ポイントと、医療機関に求められる対応を整理しました。第2回となる今回は、その中でも特に注目度の高い「二要素認証」を取り上げます。

「二要素認証は導入が難しい」「既にICカードを使っているから大丈夫」——そう考えている医療機関ほど、今回の改定で見直しが必要になっている可能性があります。第7.0版では、二要素認証の対象範囲・実装場所・認められる例外が明確化され、「導入していること」だけでなく「どこに、どう実装しているかを説明できること」が問われる内容となりました。

本記事の結論は次の通りです。

クライアント端末は、アプリログイン時の二要素認証が必要です。
サーバは、OSログイン時の二要素認証が必要です。
クライアント端末は、OSログイン時に二要素認証を行い、その認証情報をSSO等でアプリの資格情報と連携するパターンも認められます。
現状調査と対応計画策定が必要です。

当社の二要素認証ソリューション「ARCACLAVIS NEXT」「ARCACLAVIS Ways」は、いずれも院内閉域網での利用を想定した製品です。詳しくは第3回（近日公開予定）で解説します。

はじめに

2026年6月、厚生労働省は「医療情報システムの安全管理に関するガイドライン第7.0版」を公表しました。医療機関を標的としたサイバー攻撃が後を絶たない中、攻撃者が最初に狙うのはログイン情報です。ID・パスワードが漏えいすれば、閉域網で構築された院内システムであっても、正規の利用者になりすましてアクセスされてしまいます。

そのため本ガイドラインでは、令和3年度版以降、継続的に二要素認証の実装を促してきました。第7.0版は、これまで「方向性」の提示にとどまっていた部分を、「どの対象に」「どこで」「どのように」実装するかまで具体化した改定です。

二要素認証とは
「知識情報（パスワード等）」「所持情報（ICカード・セキュリティキー等）」「生体情報（指紋・顔等）」のうち、性質の異なる2つの要素を組み合わせて本人を確認する認証方式です。パスワード+ICカード、パスワード+指紋認証、パスワード+ワンタイムパスワードなどが代表例です。パスワードとPINの組み合わせなど、同一の性質の要素を2つ重ねる方法は二要素認証とは認められません。

第7.0版における二要素認証の位置づけ

本ガイドラインの「システム運用編」第14章「認証・認可に関する安全管理措置」の遵守事項⑤には、次のように記載されています。

【遵守事項⑤】（要旨）
令和9年度（令和9年4月1日時点）で稼働していることが想定される医療情報システムを、今後、新規導入又は機器の入替等を伴うシステム更改をするに際しては、二要素認証を採用、又はこれに相当する対応を行うこと。なお技術的な理由等により令和9年度までの対応が困難な場合には、令和9年度以降、直近の次期の医療情報システムの更新までを期限とする。

（出典：厚生労働省「医療情報システムの安全管理に関するガイドライン第7.0版」）

ここで重要なのは、適用の起点が「令和9年4月1日時点で稼働しているシステムのすべて」ではなく、「今後、新規導入・更改するタイミング」である点です。すぐに全システムを作り直すことは求められていません。しかし同時に、「経過措置があるから対応しなくてよい」のでもありません。次期更新までに対応計画を明文化し、説明できる状態にしておくことが条件になっています。

また、システムの新規導入・更新の際には、二要素認証に対応しているアプリケーション・サービスを選定することが医療機関側の責務として求められます。ベンダー任せにせず、調達要件に盛り込む必要がある点は第1回で触れた通りです。

更に、対応方式の選定にあたっては、認証方式とネットワーク環境の相性にも注意が必要です。医療情報システムは、セキュリティ確保のためインターネットから切り離された院内閉域網で運用されているのが一般的です。一方で、クラウド上でID・認証情報を管理する一般的なクラウド型認証サービスは、認証のたびにインターネット経由でクラウドと通信することを前提としており、閉域網環境ではそのまま利用できないケースがあります。このため医療機関では、院内に認証基盤を持ち、閉域網内で認証が完結する方式（ICカード認証、生体認証、ワンタイムパスワード等）を選定することが現実的な対応となります。こうした閉域網環境を前提とする二要素認証ソリューションが、第3回（近日公開予定）で解説するARCACLAVISシリーズです。

閉域網にも対応した二要素認証『ARCACLAVIS NEXT』

『ARCACLAVIS NEXT』製品ページ

対象範囲の明確化：クライアント端末とサーバ、それぞれの場所

第7.0版の最大のポイントは、二要素認証の対象と実装場所が表として明確化されたことです（表14-1「医療情報システムにおける二要素認証の要否」）。

対象	アプリケーション	ミドルウェア	OS
クライアント端末	要	―	―
サーバ	―	―	要

つまり、次のように整理されます。

クライアント端末：電子カルテ等のアプリケーションのログイン時に二要素認証を実装する。
サーバ：OSのログイン時に二要素認証を実装する。

サーバが対象に含まれた理由は、サーバではアプリケーションを介さずにデータベースへアクセスできるためです。アプリ側のログインを強化しても、OSの入り口が単一要素のままでは意味がありません。OSのログイン時に対策を施すことが合理的とされています。

許容されないパターンに注意

ガイドラインの注釈では、次の点も明記されています。

認証した情報をアプリケーションの資格情報等と連携し、適切な権限付与が可能な場合は、OSやミドルウェアでの二要素認証を許容する。ただし、「OSで一要素、アプリケーションで一要素」のような認証は許容されない。

これは見落としやすい論点です。例えば「PCのOSログインはパスワード、電子カルテのログインはICカード」——一見、それぞれで追加認証をしているように見えても、単一のログイン行為が1つの要素しか使っていないため、二要素認証とは認められません。

◯ 適合の例：電子カルテのログイン時に「パスワード+ICカード」で認証する／OSログイン時に二要素認証を行い、その認証情報をSSO等でアプリの資格情報と連携する

✕ 不適合の例：OSログインはパスワードのみ、アプリログインはICカードのみ、といった「別々の場所で別々の一要素認証」

既に何らかの認証強化を実施している医療機関こそ、「その二要素認証は本ガイドラインの定義に合致しているか」を一度点検する価値があります。

医療情報システム安全管理ガイドライン第7.0版
対応をご検討の方へ

こんな課題はありませんか？

電子カルテがガイドライン7.0版に適合しているかわからない
サーバOSの二要素認証をどう実装すればよいかわからない
閉域網で利用できる認証方式を検討したい

病院・医療セキュリティ対策「Ryobi-MediSec」

医療機関向けセキュリティサービス『Ryobi-MediSec』

パスワード要件との関係：二要素認証の有無で要件が変わる

二要素認証を取り上げる際に見落とされがちなのが、パスワード要件との連動です。第7.0版では、二要素認証を採用しているかどうかで求められるパスワードの桁数が変わります。

状況	パスワード要件
二要素認証を採用している場合	8桁以上（PINであれば4桁以上）。英数字を混在させる（大文字・小文字の区別は問わない）。
二要素認証を採用していない場合	13桁以上。英数字を混在させる。システムの仕様上13桁以上を設定できない場合は、設定可能な最大桁数を設定し、直近のシステム更改・新規導入時に必ず対応する。

また、パスワード運用については次の点が第7.0版で強化・変更されています。

使い回しの禁止：異なる医療情報システム間でのパスワードの使い回しを行わないこと（遵守事項⑥(2)）。
アカウントロック：一定回数認証に失敗した場合、以降一定時間ログイン試行が不能となる仕組みを講じること（遵守事項⑥(6)）。
定期変更要件の廃止：いずれの場合においても、パスワードの定期的な変更は不要とされた。形式的な定期変更ではなく、漏えい時に速やかに変更する実効的な運用へと転換。

なお、二要素認証の導入により利便性が下がることを懸念する声もありますが、逆に「13桁以上の複雑なパスワードの暗記・入力」から解放される側面もあります。セキュリティ強度と現場負担はトレードオフではなく、認証方式の設計次第で両立できます。

経過措置とスケジュール：ベンダー選定が対応成否を分ける

第7.0版の経過措置は次のように整理できます。

状況	取扱い
令和9年度までの技術的対応が困難な場合	令和9年度以降、直近の次期システムの更新までを期限とする経過措置
暫定運用（二要素認証未導入の期間）	パスワードを13桁以上（英数字混在）で運用

ここで注意すべきは、経過措置は「いつまでも未対応でよい」ことを意味しない点です。直近の更改までの間は、

いつ・どのシステム更新で二要素認証を実装するのかという対応計画の明文化
暫定措置（13桁以上のパスワード等）によるリスク低減の実施
立入検査等で計画と実施状況を説明できる証跡の保管

が求められます。特にベンダー側が二要素認証に未対応の場合、医療機関は「次期更新のタイミングで対応済みのアプリケーション・サービスを選定すること」が求められるため、更改の調達時期（2〜3年前から始まる要件定義・ベンダー選定）から対応計画を逆算しておく必要があります。令和9年度以降の更改で初めて要件を伝えても、開発・改修のリードタイムに間に合わない恐れがあります。

医療機関・ベンダーの確認ポイント

二要素認証対応を進めるための実践的なステップは次の通りです。

STEP 1：対象の棚卸し

クライアント端末（病棟・外来・受付・事務の共用端末を含む）とサーバの台帳を整備し、それぞれのログイン方式（アプリ単位／OS単位）と現状の認証方式を一覧化します。立入検査チェックリストの項目にも対応する工程です。

STEP 2：現行実装の適合性確認

既に導入している認証強化が、本ガイドラインの定義上「二要素認証」として認められるかを確認します。「OS一要素+アプリ一要素」になっていないか、生体認証・ICカード・ワンタイムパスワードの組み合わせが同一ログイン行為の中で成立しているかを点検します。

STEP 3：方式の選定と例外措置の判断

サーバOSの二要素認証が困難な場合は、踏み台サーバによる代替措置（①または②）の適用を検討します。閉域網（インターネット非接続環境）で運用する電子カルテ網では、認証方式がオフラインで動作するかどうかも選定の重要な判断材料になります。

STEP 4：対応計画の明文化とベンダーへの確認

未対応部分については、次期更新の時期とあわせて対応計画を文書化します。あわせてベンダーに対し、

ガイドライン第7.0版への対応状況（アプリログイン時の二要素認証対応の有無）
リモート保守接続（VPN等）の認証強化状況
サーバOS・ミドルウェア側の対応方針と責任分界

を確認し、回答を記録として残しておくことが、説明責任を果たす上で有効です。

多くの医療機関では、電子カルテ側の対応状況だけでなく、ベンダー保守接続、サーバOSログイン、閉域網環境で利用可能な認証方式まで含めて検討する必要があります。認証製品の選定を行う前に、まずは自院の現状整理と更改計画の確認を推奨します。

まとめ

第7.0版における二要素認証は、「導入の有無」を問うものから、「どこに・どう実装しているか、そして導入できない場合にどう説明するか」を問うものへと変わりました。

適用の起点は令和9年4月1日時点で稼働が想定されるシステムの新規導入・更改時。未対応部分は直近の更新までが経過措置の期限。
対象はクライアント端末（アプリのログイン時）とサーバ（OSのログイン時）。「OSで一要素、アプリで一要素」は認められない。
サーバOSは踏み台サーバによる代替措置（①②）が認められる。リモート保守経路の認証強化もセットで確認する。
二要素認証の有無でパスワード要件が変わる（8桁以上／13桁以上）。定期変更是議は廃止、使い回し禁止とアカウントロックは新たに求められる。
「対応しない」ことを選ぶなら、計画と暫定措置を説明できる状態が最低条件。

二要素認証は、今回の改定の中で最も実装インパクトが大きい領域です。しかし、更改の計画に組み込みさえすれば、段階的な対応は十分可能です。自院の立ち位置とベンダーの対応状況を早期に確認し、計画に落とし込むことが何よりの近道です。

次回（第3回）は、ガイドライン第7.0版への対応を支援するARCACLAVISによる二要素認証ソリューションについて解説予定です。

両備システムズが支援できること

病院・医療機関特有のセキュリティリスクに対応するために、平時の診断・対策から、運用監視、教育、緊急時対応までを一体で支援します。

見える化する

アセスメント・セキュリティリスク診断

ガイドラインチェック、VPN機器診断、サイバー攻撃リスク可視化などにより、現状把握と改善優先順位の整理を支援。

アセスメント・セキュリティリスク診断「セキュリティ診断サービス」

守る

EDR・二要素認証

エンドポイント対策、不正通信対策、二要素認証を通じて、院内システムへの侵入や被害拡大を抑止。

監視する

医療機関の規模に応じたSOCサービス

外部専門チームによる監視・分析・通報支援により、院内の人材不足を補完。

SOCサービス「セキュリティ監視サービス（EDR）」

備える・対応する

教育・保険・インシデント対応

職員教育、バックアップ、緊急時の専任SE対応まで、平時から有事までをカバー。

セキュリティ特集