医療機関どうしでデータを送り合う場面は、よく見ます。紹介状の情報をシステム間で渡す、検査結果を連携先に届ける、請求情報を転送する。こういった連携で、「とりあえずファイルを暗号化して、パスワードを別メールで送る」という形が今も残っています。
これをPPAPと呼びます。Passwordつきzipファイルを送り、Passwordを別送し、Angoka(暗号化)して、Protocolと称するやり方です。パスワードを別メールで送ることに、セキュリティ上の意味はほぼありません。同じ経路を2通流れるからです。運用の手間だけ残って、守りにはなっていない。
PPAPが残る理由
「でも相手がPPAPで送ってきます」という声はよく聞きます。慣習として定着していて、変えるには相手との調整が要る。だから自分側だけではどうにもならない、というやつです。
ただ、医療機関間のAPI連携の話になると少し違います。メールで書類を送る話ではなく、システムとシステムが繋がる話です。「誰と繋がっているか」「繋いできた相手は本当に想定の相手か」を機械で確かめ合う仕組みが、最初から作れます。それがmTLSです。
mTLSはmutual TLS（相互TLS認証）の略で、通常のHTTPSが「サーバー側の身元だけを証明書で確かめる」のに対し、「クライアント側も証明書で身元を示す」繋ぎ方です。サーバーとクライアントがお互いに証明書を出し合って確認してから、データのやりとりを始めます。
設計のイメージ
私がこういった連携設計をエンジニアに頼むとき、だいたいこんな形で渡します。
医療機関Aと医療機関BのシステムをAPIで繋ぎたい。ただし接続元が想定の相手かどうかをサーバー側で必ず確かめるようにしたい。
- お互いに証明書を出し合って、相手を確認してから通信する
- 証明書は自分たちで管理する認証局から発行する（外部の認証局に毎回頼まない）
- 証明書の拇印をサーバー側で確認して、知らない証明書からの接続は弾く
- 秘密情報（証明書のパスワードや設定値）は環境変数やVaultに置いて、コードに直書きしない
- 通信ログは記録しておいて、異常なアクセスを後から追えるようにする
- ネットワーク層でも送受信できる相手を絞って、証明書の検証を突破されたときの被害を減らす
ポイントは「証明書を持っているかどうか」だけでなく「その証明書の拇印がリストに載っているか」まで確かめること。証明書が盗まれた場合でも、拇印をリストから外せばすぐ弾けます。
運用で詰まる場所
設計そのものより、こちらのほうが現場で問題になりやすいです。
- 証明書の更新を忘れる（期限切れで突然繋がらなくなる）
- 更新した証明書を相手側に渡すタイミングが合わない（自分は更新したが相手はまだ古い証明書で動いている）
- インストール手順が担当者に伝わっておらず、次の担当者が詰まる
どれも技術的な問題ではなく、引き継ぎと連絡の問題です。私が提案書を作るときは、設計の説明と同じ分量で「証明書の更新スケジュール管理の方法」と「新しい担当者向けの手順書の中身」を一緒に整理します。接続が切れた後で「誰が何をすれば戻るか」が書いてあれば、現場が止まりません。
PPAPとの比較
PPAPとmTLSを並べると、こうなります。
PPAPの流れ
送信側がファイルを暗号化
↓ 同じメール経路でパスワードを別送
受信側がパスワードで復号
※ 「本当に想定の相手か」はどこでも確認されない
mTLSの流れ
接続開始時に相互に証明書を提示
↓ お互いの拇印を確認
確認を通過した接続だけ通信開始
※ 知らない相手の接続はその時点で弾かれる
PPAPで「ファイルを送ったが本当に想定の相手に届いたか」を確かめる手段は、メールのやりとりだけです。mTLSでは、接続の時点で相手の身元を機械が確かめます。後から確認するのではなく、接続前に弾きます。
必要なもの
このやり方を実現するのに要るのは、だいたい3つです。
- APIの入り口を管理できるゲートウェイ（クラウド各社が用意しているAPI管理サービスが使えます）
- 証明書を自分たちで発行・管理する仕組み（プライベート認証局）
- 証明書の有効期限と更新スケジュールを管理する運用ルールと手順書
3番目が一番地味で、一番大事です。証明書の期限が切れると、ある日突然連携が止まります。
PoC/提案段階の話として
この記事に書いたことは、実際にいくつかの医療機関向けに設計検討・提案資料の作成まで進めたものです。稼働中のシステムの話ではなく、「こういう設計で進めることができる」という段階の話として読んでください。
医療機関のシステム担当者や、医療系B2Bのプロダクトを持つ会社で「連携先との認証をどう設計するか詰めている」という方に、少しでも参考になれば十分です。