ゼロトラストを3省2ガイドラインの要求事項に落とす— 医療SaaSの事業者が実装すべき7項目（認証・都度認可・ログ・パッチ・バックアップ・鍵・委託先接続）【CTO・PdM向け】

1. ガイドラインに「ゼロトラスト」という遵守事項はない

「病院はゼロトラストを求めている」と言われても、何を作ればよいかは分かりません。まず、ガイドラインがゼロトラストをどう書いているかを原文で確認します。

厚生労働省「医療情報システムの安全管理に関するガイドライン」第7.0版で、ゼロトラストを説明しているのはシステム運用編 13.2「不正な通信の検知や遮断、監視」（p.32）です。

例えば VPN 装置による境界での対策を過信しており、内部に侵入された際の横断的侵害（水平展開）への対策が不足していたことで、サイバー攻撃の被害が拡大した例も複数存在する。（厚生労働省 ガイドライン第7.0版 システム運用編 13.2）

同じ節の表13-2は、ゼロトラスト思考を「オープンではない環境とオープンな環境のいずれにおいても、情報資産へのアクセスについては、不正なものが含まれうることを前提に、全てを検証対象とする」と説明しています。

一方で、同じ節は次のようにも書いています。

• 振る舞い検知のような仕組みは「現時点では費用や管理に対する負担が大きい」とされ、導入は「リスク分析の結果を踏まえて判断することが望ましい」
• 境界防御を採用する場合でも、トラフィックの監視など多層防御が必要

つまり、ゼロトラストは「この製品を入れれば満たす」項目ではなく、考え方として示されています。具体的な要求は、認証・権限・ログ・脆弱性・バックアップ・暗号・保守接続の各節に分かれて書かれています。医療機関の担当者が事業者に確認するのも、保守委託機関編【別紙】の SDS 項目（「アクセスログ機能があるか」「二要素を組み合わせた認証が可能か」など）の単位です。

そこで本記事では、「アクセスのたびに、誰が・何に・どの経路で触るかを検証し、記録する」というゼロトラストの考え方に沿って、事業者が実装する内容を7項目に束ねました。

2. 7項目の一覧

以下、項目ごとに「ガイドラインが求めること」「実装の例」「落としやすい点」の順に書きます。実装の例は、HealthLegal が支援に使う AWS サーバレス構成（Cognito・API Gateway・Lambda・DynamoDB・S3）の設定値です。

3. 認証 —— 二要素認証の期限と、パスワードの桁数

ガイドラインが求めること（システム運用編 14.1.1）

• 令和9年度時点（令和9年4月1日時点）で稼働していることが想定される医療情報システムを今後導入・更新する場合、原則として二要素認証を採用する。間に合わない場合は、令和9年度以降の直近のシステム更改・新規導入までを経過措置とする
• 二要素認証の要否は表14-1で、クライアント端末はアプリケーション、サーバは OS で「要」。「OS で一要素、アプリケーションで一要素のような認証は許容されない」
• パスワードは、二要素認証を採用している場合は8桁以上（PIN は4桁以上）で英数字の混在。二要素認証を採用していない場合は13桁以上
• 「いずれの場合においても、パスワードの定期的な変更は不要とする」

SDS では No.17.1（二要素を組み合わせた認証が可能か）と No.17.1.2（セキュリティデバイスが使えない場合の代替手段が規定されているか）で確認されます。No.17.1 は、次期システム更改までに二要素認証とみなせる措置に対応する予定であれば「はい」を選べる書き方です。

実装の例

• Cognito のユーザープールで MFA を必須（REQUIRED）にし、第2要素は認証アプリ（TOTP）。初回ログインで初期パスワードの変更と認証アプリの登録を続けて求める
• パスワードは12文字以上・大文字・小文字・数字・記号を必須にし、直近5世代の再利用を拒否する。よく使われる語・メールアドレスや氏名を含むものも拒否し、画面と API で同じ判定をする
• 認証アプリを失った利用者の本人確認と再登録の手順を、アクセス管理規程に書く（No.17.1.2 の根拠になる）
• 利用者の登録は管理者の招待だけにし、自己登録を閉じる

落としやすい点

• 二要素認証を「任意」にすると、パスワードの基準が13桁に上がります。 二要素認証を必須にした上での「12文字以上」は8桁以上の基準を満たしますが、登録していない利用者が残る構成では、その利用者は「二要素認証を採用していない場合」に当たります。段階的に導入するなら、移行期間だけ13桁以上を求めるか、移行の期限を規程に書いておく必要があります
• サーバ OS の二要素認証は、マネージドサービスだけで組んだ構成なら、事業者が OS にログインする経路そのものがありません。その場合は、OS の管理がクラウド事業者の責任範囲にあることと、データベースへ直接触れる経路（管理コンソール・CLI）をどう認証しているか（9章）を、構成図とあわせて説明できるようにしておきます
• 定期的なパスワード変更を強制している製品は、第7.0版では「不要」とされた運用を利用者に課していることになります

4. 都度認可 —— 「内側だから許可」をやめる

ガイドラインが求めること

• 情報の区分ごと、利用者や利用者グループごとに利用権限を規定し、付与する権限は必要最小限にする（14.2）
• クラウドサービスの設定（ポリシー）が意図せず変わり、アクセス権限が変わるリスクがあるため、意図せぬ設定の変更を検知できる措置を講じる。特に自動的に検知できることが重要（14.2）
• API 連携では、利用するユーザ・アプリケーション・デバイスの範囲の限定、責任分界とアクセスポリシー、ログ管理を明確にした上での認証・認可の実装が想定される（14.1.2）

SDS では No.17（アクセス管理機能があるか）と No.17.2（職種・担当別アクセス管理機能があるか）です。

実装の例

• API Gateway の JWT オーソライザーが、呼び出しのたびにトークンの署名・有効期限・発行者を検証する。Lambda はトークンの中の医療機関 ID とロールだけを使って認可し、リクエスト本文に書かれた医療機関 ID は信用しない
• データのキーの先頭に医療機関 ID を置き、他の医療機関のデータに届かない設計にする
• ロールは「運営者」「医療機関の管理者」「監査担当」「利用者」に分け、運営者のロールには業務データの閲覧権限を持たせない
• 医療機関 ID とロールは利用者が自分で書き換えられない属性にし、サーバ側だけが付与する
• アクセストークンの有効期限は60分。サインアウトや利用停止のときは、リフレッシュトークンを全端末で失効させる
• IAM・KMS・ログ・認証基盤の設定変更は CloudTrail で検知して通知する（14.2 の「意図せぬ設定の変更」）

落としやすい点

• 失効させても、発行済みのアクセストークンは期限まで有効です。「無効化すれば即座に全操作が止まる」と書かず、最長60分の残りがあることを SDS の備考に書いておきます
• 職種別の細かい権限（医師・看護師・事務など）は、基盤ではなく業務アプリ側の設計です。基盤のロールだけで No.17.2 に「はい」と答えるときは、職種別の権限をどこで設計しているかも示します

5. ログ —— 全アクセスを残し、改ざんさせず、見せる

ガイドラインが求めること（システム運用編 17.1）

• 「特に個人情報を含む資源については、全てのアクセスログを収集し、定期的にその内容をチェックして不正利用がないことを確認しなければならない」。目視で全件を見ることではなく、閾値を使ったスクリーニング後の確認を想定
• ログへのアクセス制限や、不当な削除／改ざん／追加等を防止する対策
• 記録する時刻の精度と、管理対象の全てのシステムでの同期
• アクセスログを分析し、緊急時にアラートを発する仕組み
• 管理を委託している場合は、事業者との間でログの管理方法や提供等を明確に取り決める

SDS では No.17.3 / 17.4（アクセスログ機能があるか）、No.17.3.2（アクセスログへのアクセス制限があるか）、No.18（時刻情報の正確性を担保しているか）です。

実装の例

• 誰が・いつ・何をしたかの監査ログを1イベント1行で書き込み専用の表に記録し、S3 Object Lock（本番は Compliance モード）に既定3年保管する。Compliance モードでは管理者も削除・短縮できない。保存年数はパラメータで変えられ、規程の年数と一致させる
• 業務データの閲覧（data.read）も記録する。記録が漏れやすいのは更新より閲覧のほうです
• 医療機関の管理者・監査担当が、自施設の監査ログを画面で検索できるようにし、その閲覧自体も記録する
• 短時間にログイン失敗が重なった利用者を管理者に通知する（17.1 の「緊急時にアラート」）
• 時刻は AWS の時刻同期（Amazon Time Sync Service）に統一する
• 実行ログ（CloudWatch Logs）にはメールアドレス・氏名・パスワード・トークンを出さず、本番では1年保持する

落としやすい点

• ガイドラインは「アクセスログ」そのものの保護を求めています。ログに患者の情報を書き込んでしまうと、ログの保護対象が広がります。ログに残すのは識別子だけにしておくと、保管と開示が楽になります
• 「医療機関がログを見られるか」は、17.1 の「事業者との間でログの管理方法や提供等に関して明確に取り決め」に直結します。画面で見られない場合は、提供の手順と期限を SLA に書いておきます

6. パッチ —— 更新の責任を、契約に書ける構成にする

ガイドラインが求めること

• 脆弱性に関する情報を常に収集し、脆弱性への対応を速やかに行う。EOS（サポート終了）の機器やファームウェアが攻撃の起点になる事案が多いと明記（システム運用編 8.2）
• 導入時・保守時に、事業者に SBOM（ソフトウェア部品表）の提供、またはこれに基づく安全性の確認を求める（同）
• 保守委託機関編（医療機関向けの編）は、医療情報システムは可能な限りクラウドサービスを選定し、ソフトウェアアップデート等の保守管理を事業者に委託すること、委託先との契約に「サーバのセキュリティアップデートを含む保守責任が事業者にあること」を含むと確認することを、遵守項目に挙げています（2章 7③・5④）

SDS では No.19（不正ソフトウェア混入を確認しているか）、No.96（利用ソフトウェアや媒体の管理を行っているか）です。

実装の例

• OS を持つサーバを置かず、Lambda・DynamoDB・Cognito・S3 などのマネージドサービスで構成する。OS とミドルウェアの更新はクラウド事業者の責任範囲になり、事業者が更新するのはアプリのランタイムと依存ライブラリに絞られる
• 依存ライブラリの既知の脆弱性は Dependabot で通知し、悪性パッケージの混入は OSV-Scanner で毎週と依存の変更時に確認する
• 依存ライブラリの一覧と診断結果を CI の成果物として保管し、SBOM の求めに出せるようにしておく
• 変更は版管理と CI/CD で行い、手動の変更は緊急時に限る

落としやすい点

• 保守委託機関編の遵守項目は、医療機関が「サーバのセキュリティアップデートを含む保守責任が事業者にある」と契約で確認できることを前提にしています。構成上は更新を引き受けていても、SLA や約款に書いていなければ、医療機関は確認できません
• 医療機関側の端末・ネットワーク機器の脆弱性対応は医療機関の責任です（保守委託機関編 2章 10⑤）。どこからが医療機関の責任かを、責任分界の表で示しておきます

7. バックアップ —— 数世代・複数方式・書き込み不可

ガイドラインが求めること

• 重要なファイルは数世代バックアップを複数の方式で確保し、その一部はマルウェアの混入による影響が波及しない手段で管理する。バックアップからの復元手順を整備する（システム運用編 11 遵守事項①(6)）
• バックアップの外部保存を委託している場合は、対象、頻度、復旧できる世代、方法、保存場所等を確認し、SLA 等で明らかにする（12.2）
• 一定規模以上の病院や地域で重要な機能を果たす医療機関等では、バックアップの記録媒体をネットワークから切り離して保管することが「強く求められる」。日次なら少なくとも3世代を保持し、少なくとも3世代目以降は書き込み不可にする。方式は外部ストレージ・リムーバブルメディア・NAS・クラウドサービスなどから2つ以上を選ぶことが想定される（18.1）

SDS では No.58.1 / 58.2（バックアップを複数世代・複数方式で実施しているか）、No.58.3（バックアップ復元手段が整備されているか）、No.100（データ破損時にバックアップから戻せるか）です。

実装の例

• DynamoDB のポイントインタイムリカバリ（PITR）で、35日間の任意の時点に復元できるようにする。本番の表は削除保護をかけ、スタックを消してもデータを残す
• 監査ログは S3 の版管理と Object Lock（Compliance モード）で、誰も改変・削除できない状態で保存する
• 復旧手順書（構成要素ごとの手順と判断フロー）を用意し、実際に復元を試した記録を残す
• 復旧後は、監査ログと業務データの時刻を突き合わせて、復旧時点以降の操作を医療機関と確認する

落としやすい点

• 「バックアップがある」と「戻せる」は別です。No.58.3 は復元手段の整備を問うため、一度も復元を試していない状態で「はい」とは答えにくいです
• PITR と S3 の版管理は、どちらも同じ AWS アカウントの中にあります。顧客が18.1 の「一定規模以上の病院」に当たる場合や、アカウント自体の乗っ取りを想定する場合は、別アカウントへの複製など、2つ目の方式をどこに置くかを案件ごとに決めておきます
• 18.1 は、数世代前のバックアップにもマルウェアが及んでいる可能性に触れ、復旧手順を BCP として定めるよう書いています。「どの時点に戻すか」の判断を誰がするかも、BCP に書いておきます

8. 鍵 —— 通信と保存の暗号化、鍵の管理

ガイドラインが求めること

• 利用するネットワークの回線、または送信する医療情報に暗号化措置を講じ、なりすまし・盗聴・改ざん・侵入・妨害に対策する（システム運用編 13.3）
• クラウドサービスとの間の経路は TLS の設定を適切に行う。ただしクラウド事業者内部の通信は暗号化されないため、医療機関はクラウド事業者内部で用いる通信についても十分な安全性対策を求める（13.3.1）
• 電子署名・タイムスタンプの文脈で、共通鍵・秘密鍵を格納する機器・媒体は FIPS 140-3 レベル1相当以上（15.1）

SDS では No.64（改ざん防止対策）、No.65（盗聴防止対策）、No.66（なりすまし対策）、No.67（送信元と送信先の相手確認）です。

実装の例

• 通信はすべて HTTPS（TLS 1.2 以上）。S3 は TLS 以外の接続を拒否する
• 保存データは DynamoDB・S3 とも常時暗号化（AES-256）。鍵の利用の監査や削除の統制が必要な場合は、KMS のカスタマー管理キー（年次の自動ローテーション、鍵の利用を CloudTrail に記録、削除は待機期間つき）を使う
• 相手確認は、サーバ側が公的認証局の証明書、利用者側が署名を検証したトークンと二要素認証で行う
• API キーや外部サービスの資格情報は Secrets Manager / SSM パラメータストアに置き、Lambda の環境変数に平文で置かない

落としやすい点

• 「暗号化しています」だけでは、13.3.1 の「クラウド事業者内部の通信」への問いに答えられません。どのサービス間を、誰の責任で、どう守っているかを、クラウド事業者の公表資料（責任共有モデル・第三者評価報告書）とあわせて説明します
• 鍵を格納する機器の暗号モジュールの認証状況は、クラウド事業者の公表資料で確認できます。自社で確認した資料名と日付を残しておくと、質問に早く答えられます

9. 委託先接続 —— 保守の経路を「裏口」にしない

ガイドラインが求めること

• リモートメンテナンスは「正規のルートを装って侵入できる絶好の裏口」となり得る（システム運用編 10.2）。表10-1は、リスクごとに次の対策を挙げています（各リスクの中で選択して対応）
  • 認証・アクセス管理: OS の二要素認証、特権 ID 権限の厳格管理（管理者共通アカウントの禁止等）、アクセス経路の制限、セッション・タイム・アウト
  • 通信経路: 暗号化、RDP・VNC などを直接インターネットに開放しない、リモートアクセス用ゲートウェイの利用
  • 人的・運用: ログの定期的レビュー、外部委託者用アカウントの管理、契約上の責任管理
• VPN 機器等の更新が困難な場合は、クラウド型 VPN や自動アップデートに対応した製品の選定が望ましい（18.1）
• 保守委託機関編は、医療機関に「接続サービスのセキュリティ確保の範囲を事業者に確認する」ことを求めています（2章 8③）

SDS では No.39（改造・保守アカウントを作業員専用で運用しているか）、No.40（改造・保守作業の記録を提供できるか）、No.48（リモート保守時にアクセスログを収集するか）です。

実装の例

• 常設の VPN・リモートデスクトップを置かず、院内のネットワークにも接続しない。保守はすべて AWS 上の環境への操作で行う
• 保守の経路は2つに限る。CI/CD（GitHub Actions から OIDC で一時的な認証情報を受け取る）と、二要素認証つきの IAM Identity Center の個人アカウント。長期のアクセスキーや共用アカウントは作らない
• 作業用の権限は作業の期間に限って付与する
• 保守の操作は CloudTrail に記録され、手動の操作を伴う保守の後は、翌営業日までに操作ログを確認して予定外の操作が無いことを記録する
• 保守作業者がコンソールや CLI から保存データを直接取得した場合も、S3 のデータイベントで記録する

落としやすい点

• 院内システムへのリモートメンテナンスを行わない構成なら、No.48 は「対象外」になります。ただ「対象外」と答えるときは、どの経路で保守しているかを同時に説明しないと、医療機関は 8③ の確認ができません
• 保守の記録（No.40）は、「ログがある」だけでなく「医療機関に提供できる」ことを問われます。提供の手順を運用管理規程と SLA に書いておきます

10. ゼロトラストでも「できないこと」を書く

7項目を実装しても、全てを検証できるわけではありません。たとえば上の構成では、次のことはできません。

• 利用者の振る舞いの検知（通常と異なるアクセスを検知して止める仕組み）は標準では持っていません。ガイドライン 13.2 も、費用と管理の負担が大きいため「リスク分析の結果を踏まえて判断」としています
• 発行済みのアクセストークンは、失効の操作をしても最長60分は有効です
• 医療機関側の端末とネットワークの安全は、医療機関の運用に依存します

医療機関に渡す SDS で「いいえ」や「対象外」を隠すと、審査で覆されたときに信頼を一度に失います。限界を同じ強さで書いておくほうが、結果として採用が早くなります。

11. まとめ —— 「ゼロトラスト対応」ではなく、7項目と項番で説明する

• ガイドライン第7.0版はゼロトラストを考え方として説明していて、遵守事項は認証・権限・ログ・脆弱性・バックアップ・暗号・保守接続の各節に分かれています。
• 医療機関は SDS の項番で確認します。事業者は「ゼロトラストに対応しています」と書くより、7項目それぞれについて、どの節のどの要求を、どの実装と文書で満たしているかを示すほうが伝わります。
• 数字で効くのは、二要素認証（令和9年4月1日）、パスワードの桁数（二要素ありで8桁・なしで13桁）、バックアップの3世代と書き込み不可の3つです。
• 実装と同じくらい、SLA・規程に書くことが重要です。更新の責任、ログの提供、バックアップの世代と保存場所、保守の経路は、契約や規程に書いて初めて医療機関が確認できます。

閉域網を前提にした「境界で守る」設計が、なぜ事例で破られてきたかは、医療機関サイバーインシデント年表で一次資料ごとに整理しています。

• 第7.0版の改定点の全体は、第7.0版の改定まとめにあります。
• 医療機関に出す文書の全体像は、3省2ガイドライン・SDS対応で必要になる成果物の一覧で整理しています。
• 7項目を同じ項番で設計書・SDS・SLA にそろえる支援は、/3m2g/で内容を公開しています。