医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 2

日本の医療情報システムでは、 3 省 2 ガイドライン ( 厚生労働省が定めた「医療情報システムの安全管理に関するガイドライン」、総務省・経済産業省が定めた「医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン」の総称 ) に即したシステムを構築する必要があります。

前回の医療情報ガイドラインをクラウド上で実践する – ネットワーク編 Part 1 では、AWS の責任共有モデルに触れ、どのように医療機関等のお客様が運用の負担を軽減できるかについて紹介しました。また、医療機関等とクラウドをセキュアに接続する方法として専用線的接続や IPsec VPN を利用した拠点間接続のネットワーク構成について解説しました。

Part 2 では、拠点間接続と比較し導入が容易な、オープンなネットワークで HTTPS を利用した接続を AWS で実現する構成について解説します。ユースケースとしては、HL7 FHIR API や DICOMweb 等の標準規格を利用した医療機関等からのデータ収集基盤へのアクセスなどが考えられます。その他にも地域医療連携システムなど、多くの医療機関との連携が必要な場面において導入ハードルの低さのメリットが活かされると考えられます。

厚生労働省ガイドラインのシステム運用編 [Control] の「13. ネットワークに関する安全管理措置」では、遵守事項の⑥でオープンなネットワークにおいて、VPN を利用せず HTTPS を利用する場合の対策について以下のように述べられています。

⑥ オープンなネットワークにおいて、IPsec による VPN 接続等を利用せず HTTPS を利用する場合、TLS のプロトコルバージョンを TLS1.3 以上に限定した上で、クライアント証明書を利用した TLS クライアント認証を実施すること。ただしシステム・サービス等の対応が困難な場合には TLS1.2 の設定によることも可能とする。その際、TLS の設定はサーバ/クライアントともに「TLS 暗号設定ガイドライン 3.0.1 版」に規定される最も安全性水準の高い「高セキュリティ型」に準じた適切な設定を行うこと。なお、SSL-VPN は利用する具体的な方法によっては偽サーバへの対策が不十分なものが含まれるため、使用する場合には適切な手法の選択及び必要な対策を行うこと。また、ソフトウェア型の IPsec 又は TLS1.2 以上により接続する場合、セッション間の回り込み（正規のルートではないクローズドセッションへのアクセス）等による攻撃への適切な対策を実施すること。

医療情報システムの安全管理に関するガイドライン第 6.0 版システム運用編 [Control] 13. ネットワークに関する安全管理措置より抜粋

オープンなネットワークを利用する際には、 TLS による通信の暗号化と TLS 相互認証 (mutual TLS: mTLS) の実施が明記されています。TLS のプロトコルバージョンを TLS 1.3 以上に限定した上で mTLS を実施すること、TLS 1.3 に制限できない場合は IPA (独立行政法人情報処理推進機構)の発行している TLS 暗号設定ガイドライン 3.0.1 版の「高セキュリティ型」に準ずることを求めています。 TLS 暗号設定ガイドラインでは、5 章で高セキュリティ型の要求設定をまとめられています。医療情報に関わるシステム担当者はこれらのガイドラインを確認しつつ、システムを設計していく必要があります。

ここからは AWS 上で mTLS を利用したインターネットアクセスの実現方法の例を紹介いたします。

mTLS を利用したクライアント認証

本ブログでは、mTLS を利用したクライアント認証の実現方法として Amazon API Gateway を利用した実装パターンと、Application Load Balancer (ALB) を利用した実装パターンについてご紹介します。API Gateway は API の作成、管理、保護、監視などを簡単に行うことができるマネージド型のサービスです。ALB はアプリケーション HTTP トラフィック、HTTP 通信、Web 通信、Web サービスのロードバランシングサービスになります。

API Gateway を利用した実装パターン

オープンなネットワークを利用する際に、システムのバックエンドの API を構築し、API のエンドポイントに対して医療機関等から通信を行うケースを考えます。

Amazon API Gateway は、AWS のマネージドサービスであり、シンプルな方法で RESTful API や WebSocket API を作成、デプロイ、管理するためのプラットフォームです。API Gateway を使用することでクライアントアプリケーションとバックエンドのサービスを接続し、効率的に API を作成および公開することができます。API Gateway では RESTful API として REST API と HTTP API を提供しており、どちらも mTLS 機能が利用できます。

以下は、クライアント証明書発行から API Gateway を用いた mTLS によるアクセスまでの流れを示しています

クライアント証明書は AWS Private CA や独自のプライベート CA、サードパーティの認証局の発行する証明書が利用可能です。

Amazon S3 に .pem ファイル拡張子が付いたテキストファイルである信頼ストア (トラストストア) をアップロードし、カスタムドメインの設定でトラストストアまでの S3 のパスを指定することで、API にアクセスする際の証明書の検証が可能になります。また、S3 バケットに証明書失効リスト (CRL) をアップロードし Lambda オーソライザーを実装することでクライアント証明書の失効チェックを行うことも可能です。詳細は、 How to implement client certificate revocation list checks at scale with API Gateway をご確認ください。

API Gateway では、カスタムドメインを作成し mTLS を要求する API エンドポイントが作成可能です。 API 作成時に発行されるデフォルトエンドポイント (xxxx.execute-api.<region>.amazonaws.com) については無効化することで、アクセス時に mTLS での接続を強制することが可能です。
詳細は、Introducing mutual TLS authentication for Amazon API Gateway と、開発者ドキュメントの REST API の相互 TLS 認証の設定や HTTP API の相互 TLS 認証の設定をご確認ください。

医療情報ガイドラインに準じた構成を実現するためには TLS のバージョンを制限することも必要です。API Gateway では、セキュリティポリシーと呼ばれる事前定義済みの最小 TLS バージョンと暗号スイートの組み合わせをご利用いただけます。TLS 1.2 セキュリティポリシーを選択した場合、セキュリティポリシーは TLS 1.2 および TLS 1.3 トラフィックを受け入れ、TLS 1.0 トラフィックを拒否します。詳細は、API Gateway でカスタムドメインのセキュリティポリシーを選択するをご確認ください。

Application Load Balancer を利用した実装パターン

次に、ALB を利用するパターンを考えます。

Application Load Balancer (ALB) は AWS のマネージドロードバランサーサービスの 1 つであり、ALB は、受信したトラフィックを複数のアベイラビリティーゾーンの複数のターゲット (EC2 インスタンス、コンテナ、IP アドレスなど) に自動的に分散し、アプリケーションの可用性を向上させることのできるソリューションです。ALB は第 7 層であるアプリケーションレイヤーで機能します。

2023 年 11 月にALB における mTLS 機能がサポートされたため、マネージドサービスを利用して厚生労働省の要件に準拠したネットワークの構成をとることができるようになりました。

以下は、クライアント証明書発行から ALB を用いた mTLS によるアクセスまでの流れを示しています。

2023 年 11 月に発表された ALB における mTLS のクライアント証明書の処理方式には、信頼ストア (トラストストア) 方式とパススルー方式の 2 つの方式が存在します。 (※ クライアント証明書は X.509 v1 はサポート対象外であり、X.509 v3 を利用してください。)

トラストストア方式では、ALB がクライアント認証の機能を担い、クライアントと ALB 間で mTLS の通信を行います。こちらの方式では、トラストストア機能により、AWS Private CA またはその他のサードパーティ CA によって生成されたルート証明書や中間証明書を含む CA バンドルを信頼するソースとしてアップロードして、クライアント証明書を検証できます。トラストストアには、CA、信頼できる証明書、およびオプションで証明書失効リスト (CRL) が含まれ、ロードバランサーはトラストストアを使用してクライアントとの相互認証 (mTLS) を行います。

パススルー方式では、クライアントから受信したすべてのクライアント証明書チェーンを、HTTP ヘッダー (x-amzn-mtls-clientcert ヘッダ) を使用してバックエンドアプリケーションに送信します。mTLS 対応の ALB は、ハンドシェイクでクライアント証明書を取得し、TLS 接続を確立して、HTTP ヘッダーで取得したものをターゲットアプリケーションに送信します。そのため、アプリケーションは、クライアントを認証するためにクライアント証明書チェーンを検証する必要があります。利用例としては、OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens (RFC8705) のように、クライアント証明書を紐付けたアクセストークンの発行など、アプリケーション側でクライアント証明書を利用する場合などが挙げられます。

ALB では、TLS 1.3 をサポートしています。ALB のセキュリティポリシーを利用することで、ワークロードを安全に保ちながら、アプリケーションサーバーのパフォーマンスの最適化を実現できます。また、 TLS 1.3 のみに利用を制御するセキュリティポリシーである ELBSecurityPolicy-TLS13-1-3-2021-06 もお選びいただくことが可能です。詳細は、Application Load Balancer 用の HTTPS リスナーを作成するをご確認ください。

その他の実装パターン：
ALB の mTLS 機能の登場以前から mTLS を利用して EC2 へアクセスを行う際は、NLB (Netwok Load Balancer)の TCP リスナーを利用し EC2 インスタンス内の実装で TLS を終端する方式が利用されていました。NLB は、AWS のマネージドロードバランサーサービスの 1 つです。NLB は、トラフィックを受信し、負荷分散してバックエンドのターゲットグループに配信する役割を担います。第 4 層であるトランスポートレイヤーで機能し、高いスループットと低レイテンシの要件を満たすように設計されています。システムの要件に応じてこれらの実装パターンもご検討ください。

まとめ

オープンなネットワークで設計する際は、医療機関等における導入が簡便な点がメリットとして享受できますが、一方で、クライアント証明書の配布方法や、証明書の有効期限の管理など、ハイブリッド接続と同等のセキュリティを担保するための運用設計についても考えることが重要となります。また、 AWS の提供する Web Application Firewall のサービスである、AWS WAF によるコンテンツへのアクセスを制御などと組み合わせて利用しセキュリティを高めることも重要となります。本日ご紹介した API Gateway と ALB はどちらも WAF に対応したサービスとなっております。ぜひ併せてご活用ください。

本ブログでは、オープンなネットワークで HTTPS で医療機関等から AWS への接続を実現するための構成例についてご紹介しました。API Gateway や ALB では mTLS を利用したクライアント認証を構築することが可能となります。本ブログが、読者の皆様のガイドライン対応の一助となれば幸いです。

本ブログシリーズの各種リンクはこちら。

著者について

Yohei Katayama

AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

Hiroaki Yoshimura

AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は料理をしたり、美味しいご飯を求めて都内を歩いています。

Amazon Web Services ブログ