医療情報システムの安全管理に関するガイドライン第7.0版の改定ポイントをAWSアーキテクチャの観点で整理してみた
いわさです。
先日、さっぽろ医療IT勉強会 #2 で「医療情報システムの安全管理に関するガイドライン第7.0版」の改定ポイントについて登壇しました。
登壇ではガイドライン改定の内容についてざっと確認した形でしたが、本記事ではこれを AWS クラウド上で医療情報システムを設計・運用する前提でどう落とし込むかという観点で整理してみます。
「医療情報システムの安全管理に関するガイドライン」は、医療機関等が医療情報システムを安全に管理・運用するためのセキュリティ要件をまとめた厚生労働省のガイドラインです。
e-文書法や個人情報保護法等への対応を目的として平成17年3月に第1版が策定され、以降の制度動向や技術の進展に合わせて改定されてきました。
先日、第7.0版が策定されました。
なお、今回の改定の背景として、経産省・総務省が策定する「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」（いわゆる2省ガイドライン）も令和7年3月に第2.0版へ改定されています[1]。
こちらはクラウドサービス事業者側が遵守すべき事項を定めたガイドラインなので、AWS 上で医療情報システムを提供する事業者は両方を押さえておく必要があります。
6.0版から7.0版への改定で、AWS アーキテクチャの設計に影響しそうなポイントがいくつかあったので整理してみます。
今回こちらを確認してみたので紹介します。
改定ポイントの概要
今回の改定で AWS 設計に影響しそうな主要な変更点は以下の4つです。
- 保守委託機関編が新設された。事業者としてセキュリティアップデートの適用状況を証跡として見せられる状態にする必要がある
- パスワード定期変更が「不要」と明記された。代わりに使い回し禁止とアカウントロックが追加
- サプライチェーンリスクへの対応が明示的に要求された。CI/CD パイプラインへの脆弱性スキャンゲート組み込みが重要になる
- 二要素認証の適用ポイントが明確化された。クライアント端末はアプリケーションログイン時、サーバは OS ログイン時と整理された
以降、それぞれについて AWS での設計への影響を見ていきます。
保守委託機関編の新設
第7.0版の最も大きな構成変更は「保守委託機関編」の新設です。
セキュリティ人材が不足している小規模医療機関を想定して、すべてのサーバの保守を事業者に委託している医療機関は保守委託機関編を遵守すれば他の編も遵守とみなすという枠組みが整理されました。
改定の詳細は登壇資料を参照いただければと思いますが、SaaS 型医療情報システムを提供する事業者の立場で見ると、以下の確認・要求を受ける側になります。
- 契約に「サーバのセキュリティアップデートを含む保守責任が事業者にあること」を明記する
- 外部保存の委託先として ISMAP 等の認証を取得していることが選定条件になる[2]
- MDS/SDS の提出を求められる[3]
- 情報機器等が「国内法の適用及び執行の及ぶ範囲にあること」を確実にする
セキュリティアップデートの証跡
事業者として「セキュリティアップデートを確実に適用している」ことを医療機関に示す必要があります。
7.0版で保守委託機関編が新設されたことにより、「証跡としてレポートできるか」が問われるようになりました。
具体的な対応策としては以下が考えられます。
- Systems Manager Patch Manager でパッチコンプライアンスを管理し、適用状況をレポートする
- ECS on Fargate や Lambda を使ったサーバーレス構成にして、OS パッチ管理の責任を AWS 側に寄せる
- ECR イメージのスキャン（Inspector 統合）を CI/CD パイプラインに組み込む
- Security Hub のコンプライアンスステータスを定期レポートとして医療機関に提供する
リージョン選定
保守委託機関編5.③に「情報機器等が、国内法の適用及び執行の及ぶ範囲にあることを確実にすること」と明記されています。
6.0版の企画管理編でも外部保存の文脈で類似の記載はありましたが、7.0版では独立項目として明記され、表現も強化されました。
AWS の東京リージョン（ap-northeast-1）と大阪リージョン（ap-northeast-3）は日本国内にあるため、この要件を満たします。
SCP で aws:RequestedRegion 条件を使って東京・大阪以外へのリソース作成を制限するのが定番のアプローチです[4]。
CloudFront 等のグローバルサービスを使う場合、エッジロケーションを経由するトラフィックが「国内法の適用及び執行の及ぶ範囲」に該当するかは議論が分かれそうです。
保守的に解釈する場合は CloudFront を経由させず ALB 直接公開とする選択肢もあります。今後の Q&A 等で解釈が示される可能性もあるので注視しておきたいところです。
パスワード定期変更の廃止
今回の改定で、パスワードの定期変更は「不要」と明記されました。
代わりに使い回しの禁止とアカウントロックの導入が追記されています。
個人的に、パスワード定期変更の廃止は嬉しいですね。
使い回し禁止
Amazon Cognito にはパスワード再利用防止機能があります。以前こちらの記事で紹介しています。
Essentials plan 以上で利用可能な高度なセキュリティ機能を有効化し、パスワードポリシーから設定します。
IAM ユーザーについても、マネジメントコンソールのアカウント設定から「パスワードの再利用を禁止（過去1〜24個）」を設定できます[5]。
アカウントロック
「一定回数の認証失敗でログイン試行を一定時間不能にする仕組み」については、Cognito のデフォルト動作として存在します。
公式ドキュメントによると、5回連続でパスワード認証に失敗すると1秒間ロックされ、以降は失敗ごとにロック時間が倍増し最大約15分になるとのこと。
After five failed sign-in attempts with a user's password, regardless of whether those are requested with unauthenticated or IAM-authorized API operations, Amazon Cognito locks out your user for one second. The lockout duration then doubles after each additional one failed attempt, up to a maximum of approximately 15 minutes.
ガイドラインの「一定時間ログイン試行が不能となる仕組み」という要件は Cognito のデフォルト動作で満たせる範囲だと思います。
ただし「管理者がロック解除するまで永続的にロック」を期待している場合は認識ズレが生じるので、より厳密な制御が必要な場合は Pre Authentication Lambda トリガーで独自のロック機構を実装するか、脅威保護機能（Plus plan）のアダプティブ認証を検討する形になります[7]。
サプライチェーンリスクへの対応
NCO（国家サイバー統括室）の安全基準等策定指針の改定を受けて、サプライチェーンリスクへの対応が7.0版で明示的に追記されました。
NCO 安全基準等策定指針は政府機関等のサイバーセキュリティ対策の基準を定めるもので、厚労省ガイドラインはこれとの整合が図られています。
6.0版でも脆弱性対策については触れられていましたが、7.0版ではサプライチェーン全体を管理対象として明示的に要求するレベルに引き上げられました。
パッチ適用のリードタイム短縮が重要視されているようです。
AWS での対応
医療情報システムで使うライブラリやコンテナイメージもサプライチェーンの一部として管理対象になります。
- Amazon Inspector で EC2・ECR・Lambda の脆弱性を継続的にスキャンする。Inspector は SBOM のエクスポート機能も持っているので MDS/SDS 対応にも活用できる
- ECR のイメージスキャンを CI/CD パイプラインに組み込み、脆弱なイメージのデプロイをブロックする
- ECS on Fargate + Blue/Green デプロイで、コンテナイメージの差し替えを迅速にロールアウトできる構成にする
- サーバーレス構成（Lambda、Fargate）を採用して OS 層のパッチ責任を AWS に寄せる
CI/CD に脆弱性スキャンのゲートを組み込む設計が「あると良い」から「やるべき」に引き上げられた印象です。
二要素認証の適用ポイント明確化
6.0版では「令和9年度時点で稼働するシステムには二要素認証又はこれに相当する対応」と遵守事項に記載されていましたが、適用レイヤーが不明確でした。
7.0版ではこれが表14-1で整理され、クライアント端末はアプリケーションログイン時、サーバは OS ログイン時に MFA が必要と明確化されました。
エンドユーザー認証
Amazon Cognito で MFA を必須（MFAConfiguration: ON）に設定し、TOTP や SMS を第二要素として提供します。
FIDO2/WebAuthn が使えるならフィッシング耐性が高くなるので検討の余地ありです。
サーバへのアクセス
EC2 への SSH/RDP は SSM Session Manager 経由に限定し、IAM ロールの AssumeRole に MFA 条件（aws:MultiFactorAuthPresent）を付けるのが基本的な対応になります。
マネジメントコンソールへのアクセスは IAM Identity Center の MFA 強制を設定します。
代替措置
サーバ OS への二要素認証が難しい場合の代替として、7.0版では以下2パターンが認められています。
- 別ドメインに設置した踏み台端末からの接続のみに限定し、踏み台端末の OS ログイン時に MFA を実装する
- 踏み台端末に EDR 機能を具備し、外部からの接続は VPN 経由に限定する（踏み台の OS には MFA 不要）
2つ目のパターンは SSM Session Manager + VPN 構成に EDR を組み合わせることで、MFA 実装が困難なレガシーシステムでも対応可能な道筋が示されています。
さいごに
本日は「医療情報システムの安全管理に関するガイドライン第7.0版」の改定内容を AWS アーキテクチャ設計の観点で整理してみました。
保守委託機関編の新設が今回の最も大きな変化だと感じます。
事業者側は MDS/SDS の提出やセキュリティアップデートの責任範囲を契約レベルで明確にし、証跡として見せられる状態にする必要が出てきました。
Patch Manager や Inspector、Security Hub などの「状態を可視化するサービス」をレポーティングの仕組みとして整備しておくのが重要です。
パスワード定期変更の廃止は現場の実態に合った合理的な方向で、Cognito の既存機能でおおむね対応可能な状態になっています。
サプライチェーンリスクの明示化と二要素認証の適用ポイント明確化は、既存の AWS 環境を見直す良いタイミングになりそうです。
なお、生成 AI やデータ主権に関する論点はパブリックコメントで意見が寄せられていたようですが、今回の7.0版ではガイドライン本体への記載は見送りとなったみたいです。今後の改定で取り上げられる可能性もあるので、引き続き注目しています。
