医療データとAWS RDS

Last updated at 2026-10-16Posted at 2026-10-16

はじめに

医学生エンジニアとしてスタートアップで働いています。

この記事は自分の備忘録として書いたもので、内容は個人の見解です。所属組織を代表するものではなく、法的助言でもありません。できる限り一次資料を確認していますが、誤りや古い情報が含まれている可能性があります。法令やガイドラインは改訂されるため、導入時には必ず最新版の原文を確認し、必要に応じて医療情報・個人情報保護に詳しい専門家へ相談してください。

主に参照するのは、次の文書です。

そもそも医療情報の保存にAWSを用いていいのか

この段落ではRDSだけではなくAWS全体の話も含めています。

医療情報を保存するシステムで満たすべき条件

結論から書くと、AWS RDSは医療情報を保存するDBの基盤として利用できます。ただし、RDSを使うだけで医療情報システムの安全管理ガイドラインに適合するわけではありません。

RDSや周辺のAWSサービスが提供するのは、保存時の暗号化、バックアップ機能、データセンターの物理的な安全管理、国内リージョンの選択といったインフラ層の機能です。

一方、診療記録の真正性（誰がいつ確定・更新したか）、患者単位のアクセス記録、必要な期間の監査ログ保管、患者単位のデータ出力などは、アプリケーションやデータベースのスキーマ、運用手順を含めて設計する必要があります。

また、AWSの機能で技術的に対応できる項目であっても、それだけでガイドラインの要求を満たしたとは限りません。医療機関とサービス事業者の責任分界、リスク評価、契約内容、実際の運用まで含めて確認することが重要です。

DBに直接効いてくるのは、厚労省ガイドラインの「システム運用編」と2省ガイドラインです。残りの資料は、個人情報保護法上の位置づけと周辺の論点を補っています。

資料	発行	この記事での主な論点
医療情報システムの安全管理に関するガイドライン第7.0版（システム運用編・企画管理編・保守委託機関編）	厚生労働省（令和8年6月）	真正性、アクセスログ、バックアップ、二要素認証、外部保存
医療情報を取り扱う情報システム・サービスの提供事業者における安全管理ガイドライン第2.0版	総務省・経済産業省（令和7年3月）	事業者側の義務、ログの保存期間、契約終了時の返却
個人情報の保護に関する法律についてのガイドライン（通則編）	個人情報保護委員会	技術的安全管理措置、漏えい等報告
同（外国にある第三者への提供編）	個人情報保護委員会	外資クラウドの位置づけ
医療・介護関係事業者における個人情報の適切な取扱いのためのガイダンスと同Q&A	個人情報保護委員会・厚生労働省	医療分野の安全管理措置、外国事業者への保存委託
オンライン診療についてと受診施設向けチェックリスト	厚生労働省	患者データを蓄積する場合の要件

AWS側の情報は、AWSパートナーによる「医療情報システム向けAWS利用リファレンス」と、第7.0版の改定点をAWS設計の観点で整理した解説記事を参考にしました。

インフラ層の要件はRDSと周辺のAWSサービスでおおむね満たせます。一方、記録の中身に関わる要件はほぼすべて自前で作る必要があります。

要件	主な根拠	RDSで対応できるか	自前で必要なこと
真正性（確定・更新履歴・代行入力）	システム運用編 14.⑨	できない	スキーマ設計
アクセスログ（誰がどの患者の何を操作したか）	システム運用編 17.①	DBレベルのみ	アプリ層の監査ログ
医療情報へのアクセス証跡の改ざん防止と、法定保存年限を踏まえた保管	システム運用編 17.②、2省GL	一部のみ	S3 Object Lockへの長期保管
信頼できる時刻	システム運用編 17.③	できる	アプリも統一
保存時・通信時の暗号化	システム運用編 13	できる（KMS・TLS）	RDSのSSL/TLS接続を強制する
多世代・書込不可・複数方式のバックアップ	システム運用編 11.①、18	一部のみ	AWS Backup Vault Lock、別アカウント保管、論理バックアップの併用
国内法の及ぶ範囲での保管	企画管理編、保守委託機関編	できる（東京・大阪）	SCPでリージョン制限、国外法の評価
サーバ管理者の二要素認証	システム運用編 14.⑤	できる（OSはAWS管理）	DB接続経路をMFA付きに限定
鍵の保管（FIPS 140-3 レベル1相当以上）	システム運用編 15	できる（KMS）	なし
標準形式での入出力、マスタ変更の影響排除	システム運用編 5.①②	できない	アプリ設計
患者単位の速やかな検索・出力	医療・介護ガイダンス	できない	インデックスと出力機能
破棄と契約終了時の返却	システム運用編 7、2省GL	一部のみ	全件エクスポートと証跡を残す手順

RDSは顧客がOSに触れないマネージドサービスです。そのため、サーバOSの二要素認証やパッチ適用はAWS側の責任範囲に入り、オンプレミスより有利な点です。

国内保管と、国外法・個人情報保護法の整理

東京(大阪)リージョンを選べば国内保管の条件は満たせます。ただし、それだけでは説明が足りない点が2つあります。

国外法の適用可能性
監督義務の扱い

国外法の適用可能性
企画管理編は、外部保存の委託先を選ぶときの確認事項として、機器の設置場所（地域・国）とは別に「委託先事業者に対する国外法の適用可能性」を挙げています。

契約面では、AWSは日本の医療機関にとって説明しやすい状態になっています。2022年2月以降、日本国内のアカウントの契約当事者はAmazon Web Services, Inc.からアマゾンウェブサービスジャパン合同会社に切り替わっています（AWS Japan FAQ）。このとき、AWSカスタマーアグリーメント上の準拠法は日本法、管轄裁判所は東京地方裁判所になります。

ただし、契約の準拠法が日本法であることと、国外法の適用可能性は別の論点です。準拠法は、AWSとの契約をどの国の法律で解釈するかという話にすぎません。親会社が米国企業である以上、米国の法令に基づくデータ開示要求が及びうるかは、契約の準拠法とは無関係に残ります。そのため、「契約当事者は日本法人で、準拠法は日本法・管轄は東京地裁」という点を示したうえで、親会社が米国企業であることのリスク評価を医療機関向けの説明資料に添えるのが正確です。

なお、選定基準となる認証の一つにISMAPが明記されており、AWSはこれを満たしています（AWS ISMAP対象サービス一覧）。

監督義務の扱い
2省ガイドラインでは、クラウド事業者が個人データを取り扱わない契約で、アクセス制御も適切なら、個人情報保護法上の「提供」には当たらず、法25条の監督義務は生じないと整理されています。ただし同じ箇所で、医療機関はガイドラインに従ってクラウド事業者を適切に監督する必要があるとも書かれています。法律上の義務はなくても、ガイドライン上の監督は求められるということです。

外国にある第三者への提供編では、外国法人でも日本国内で事業を行っている拠点は「外国にある第三者」に当たらないとされています。そのため、通常のRDS利用でこの編の同意手続きが問題になることは少ないはずです。注意すべきは、患者データが東京・大阪以外のリージョンや生成AIなどの他サービスに流れる構成です。その場合は外的環境の把握（通則編10-7）が必要になります。

オンライン診療と契約終了時の論点

オンライン診療の機能を作る場合は、オンライン診療に関する制度や指針も確認する必要があります。
特に、オンライン診療受診施設を利用する仕組みでは、オンライン診療受診施設向けのチェックリストが参考になります。これはオンライン診療受診施設を対象とする文書であり、すべてのオンライン診療サービスに一律に適用されるものではありません。

契約終了時の扱いも、設計の初期から考えておくべき論点です。2省ガイドラインは、契約終了時にあらかじめ合意した手順で情報を返却・移管・破棄し、その証跡を残すことを事業者に求めています。DBの全データを標準形式または変換しやすい形式でエクスポートできる仕組みは、最初から用意しておく必要があります。

破棄についても、システム運用編は注意を促しています。DBのように情報同士が関連している場合、一部だけを不適切に消すと他の情報が使えなくなるリスクがあります。RDSでは、スナップショットやバックアップまで含めて消えたことを示す手順を用意します。CMKを使っている場合は、KMS鍵の削除を組み合わせることもできます。AWS所有キーやAWSマネージドキーは利用者が削除できないため、この方法は使えません。

次の段落からRDSの細かいところの設定を見ていきましょう。

1. ネットワーク：DBを外部から隔離する

DBに到達できる経路を最小限にし、その経路を「誰が・いつ・どこから」使ったか後から説明できる状態にするのが、このセクションの目的です。システム運用編13は、原則として経路や接続先が管理された「セキュアなネットワーク」を使うことを求めています。

配置と経路

RDSはプライベートサブネットに配置し、PubliclyAccessible も false にする（サブネットとは別の設定なので両方を確認する）
DB用サブネットには、インターネット向けのデフォルトルートを設定しない。セキュリティグループのアウトバウンドルールも、必要な通信に限定する
DBポートへの接続は、アプリケーションのセキュリティグループと、承認済みの管理経路など必要最小限の接続元からだけ許可する
SSM、KMS、S3、CloudWatch Logsなどを利用するアプリケーションサーバや管理用インスタンスでは、必要に応じてVPCエンドポイントを設け、インターネットを経由しない通信経路を構成する。なお、RDSのサービス内部で行われる通信まで、自社VPCのエンドポイント経由になるわけではない
可用性のため、Multi-AZ配置を有効にする（DBサブネットグループを複数AZにするだけでは冗長化されない）
本番・ステージング・開発はAWSアカウントごと分け、開発環境に本番の患者データを持ち込まない

最後の点はシステム運用編10.①にも関係します。保守や動作確認で個人情報を含むデータを使った場合は、作業後の確実な消去と報告が求められています。

通信の暗号化

VPCの中だから平文で良い、とはなりません。システム運用編13.3は、クラウド事業者内部の通信についても十分な安全対策を求めています。

DB側で、暗号化されていない接続を受け付けない設定にする（PostgreSQLは rds.force_ssl、MySQLは require_secure_transport）
アプリ側では、通信を暗号化するだけでなく、RDSのCA証明書を使って、接続先が本物のDBサーバかどうかも検証する（PostgreSQLでは sslmode=verify-full）
TLSのバージョンは、システム運用編13.⑥にならい1.3を基本とし、対応できない場合も1.2以上に限定する（PostgreSQLは ssl_min_protocol_version で下限を指定できる）

管理者の接続

管理者の接続は、承認済みの踏み台またはAWS Systems Manager（Session Manager）経由に限定します。DBへ直接接続できる管理者も最小限にします。

システム運用編14.⑤は、医療情報を格納するサーバへのアクセスに二要素認証を求めています。RDSは顧客がOSに触れないため、実際にはDBへ到達する経路を二要素認証で守る形になります。同編では、別ドメインの踏み台に接続を限定し、踏み台のログイン時に二要素認証を行う方法が代替措置として認められています。その前提条件は次の3つです。

踏み台にログインするユーザーに管理者権限を与えない
OSのセキュリティアップデートを十分に行う
サーバ群と踏み台で共通のパスワードを使わない

Session Managerを使う場合は、次のように設定します。

接続用のIAMロールの引き受けにMFAを必須にする
アイドル時のセッションタイムアウトを設定する（システム運用編表10-1）
必要な利用者だけにSession Managerの利用を許可する
CloudTrailなどを使い、接続したIAM主体やセッションの開始・終了を追跡できるようにする
通常のシェルセッションでは、必要に応じてセッション内容を暗号化してS3やCloudWatch Logsへ保存する

ここで注意したいのは、Session Managerを使えばDBの操作内容まで記録できるわけではないことです。

AWSの公式ドキュメントによると、Session ManagerのポートフォワーディングやSSH接続では、セッション内容のログを取得できません。
例えば、Session Managerのポートフォワーディングを使ってRDSに接続した場合、接続したIAM主体やセッションの開始・終了を追跡できても、その接続で実行したSQLをSession Managerのログから確認することはできません。
そのため、管理者によるDBへの直接アクセスについては、接続経路の認証・記録とは別に、DB側の監査ログや作業申請・作業記録を用意する必要があります。

DBユーザーについては、マスターユーザーを日常の作業に使わず、作業者ごとに個別のDBユーザーを発行します。システム運用編10.1は、DBMSの出荷時の管理者IDを使わず、保守担当者ごとにIDを設けて作業者を特定できるようにすることを求めています。同10.③も、保守要員には専用アカウントを使わせ、アクセスした個人情報と作業内容を記録することを求めています。パスワードの管理には、IAMデータベース認証やSecrets Managerのローテーションが使えます。

SSM Session Managerを使ってRDSにアクセスする場合でも、それだけで「誰がどの患者の情報を見たか」が分かるわけではありません。AWSのIAMユーザー、SSMセッション、DBユーザー、アプリケーション上の利用者を対応付けられるようにしておきます。アプリ経由のアクセスは、後述するアプリ層の監査ログで追跡します。

設定ミスと異常の検知

「避ける」だけでなく、崩れたときに気づける状態にしておきます。システム運用編14.2は、クラウドの設定が意図せず変更されたことを検知できる措置を求めています。

AWS Configのマネージドルール（rds-instance-public-access-checkなど）で、RDSのPubliclyAccessibleが有効になっていないかを検知する
セキュリティグループの過剰な公開については、別のAWS Configルールやカスタムルールなどで検知する。rds-instance-public-access-checkだけでは、DBポートの全開放まで確認できない
VPC Flow Logs で、DBサブネットへの通信を記録する。ただし、SQLの内容や患者単位のアクセスを記録するものではない
GuardDuty の RDS Protection で、不審なログイン試行を検知する（対応エンジンは事前に確認する）

オンライン診療受診施設向けチェックリストでも、IDS/IPSの設置などによる不正アクセス防止措置が遵守事項になっています。上記の仕組みは、その説明材料になります。

インシデント時に遮断できる設計

システム運用編18は、サイバー攻撃を受けた場合に、外部ネットワークの一時切断や、攻撃を受けた機器の隔離を求めています。11.①(5)でも、被害拡大を防ぐための論理的・物理的なネットワーク分離が求められています。

そのため、すべての通信を拒否する隔離用セキュリティグループを用意しておきます。あわせて、それに差し替える手順と権限者をあらかじめ決めておきます。

2. 暗号化：保存時・通信時・鍵の管理

保存時の暗号化

ストレージの暗号化は必ず有効にします。ただし、RDSとAuroraでは仕様が異なります。

RDSでは、暗号化されていない既存のDBインスタンスに対して、直接ストレージ暗号化を有効にすることはできません。暗号化するには、スナップショットを取得し、暗号化したコピーから復元するなどの対応が必要です（AWS公式：RDSの暗号化）。

一方、Auroraでは2026年2月18日以降に作成された新しいDBクラスターは、デフォルトでAWS所有キーによって暗号化されます。 既存のクラスターの暗号化状態は自動的には変更されません。また、暗号化されたクラスターの鍵を直接変更することはできず、別の鍵を使う場合はスナップショットからの復元やBlue/Greenデプロイメントなどによる移行が必要です（AWS公式：Auroraの暗号化）。

暗号化されたDBでは、スナップショットや自動バックアップも暗号化されます。Auroraではクラスター内のDBインスタンスやログも暗号化の対象です。

鍵の管理にはAWS KMSが利用されます。AWS KMSでは、FIPS 140-3 Security Level 3の認証を受けたHSM（ハードウェアセキュリティモジュール）が使用されています（AWS公式：KMS）。

なお、システム運用編15.1でも、共通鍵や秘密鍵を格納する機器についてFIPS 140-3 レベル1相当以上への対応が示されています。ただし、これは電子署名・タイムスタンプに関する節の記述であり、AWS KMSを使用すれば医療情報システム全体がガイドラインに適合するという意味ではありません。

Auroraで使用する暗号鍵には、主に次の3種類があります。

AWS所有キー（AWS owned key）： AWSが所有・管理する鍵。2026年2月以降のAuroraでは標準で利用され、ユーザー側で鍵の管理をする必要がない
AWSマネージドキー（AWS managed key）： AWS KMS上でAWSが管理する鍵。ユーザーのアカウントから確認できるが、鍵ポリシーなどの変更はできない
カスタマー管理キー（CMK）： ユーザー自身がAWS KMSで管理する鍵。鍵ポリシーや利用権限を細かく制御できる

公式ドキュメントでは、Auroraについて、シンプルに運用する場合はデフォルトのAWS所有キーを、鍵の制御が必要な場合はカスタマー管理キーを推奨しています。

CMKを検討するのは、次のような場合です。

バックアップを別のAWSアカウントに隔離したい： AWSマネージドキーで暗号化されたスナップショットは、他アカウントに共有できない。Auroraのデフォルトで使われるAWS所有キーも利用者側で共有設定ができないため、別アカウントへのコピーにはカスタマー管理キーが必要になる。DBの鍵は作成後に直接変更できないため、4. バックアップで説明しているように別アカウントへバックアップを隔離する予定があるなら、クラスター作成時にCMKを選んでおく（AWS公式：暗号化されたスナップショットの共有）
鍵を使える人を細かく制御したい： キーポリシーを使って、鍵の管理者と利用者を分離できる
契約終了時のデータ破棄を管理したい： 鍵を削除することで、その鍵に依存する暗号化データを復号できなくする方法もある。ただし、DB本体やバックアップへの影響が大きく、他の保存先に残るデータまで削除されるわけではないため、慎重な運用が必要になる

なお、別リージョンへのバックアップコピーと別アカウントへのコピーは異なる操作です。対応可否や鍵の要件は、暗号化方式とバックアップ手段によって変わるため、利用する構成で確認します（AWS公式：AWS Backupの暗号化）。

また、同じアカウント内でも、AWS BackupのVault Lockをコンプライアンスモードで使用すれば、猶予期間の終了後はルートユーザーを含め、保持期間内のバックアップを削除できなくなります。ただし、保持期間の設定を誤ると後から変更できなくなるため注意が必要です（AWS公式：AWS Backup Vault Lock）。

CMKを使う場合は、次も決めます。

鍵を管理する人と、データを読む人を分ける
CloudTrailによる鍵の操作記録を、どこにどれだけ保存するか
鍵のローテーション方法
鍵を無効化・削除したときの影響
復元先のアカウント・リージョンでも必要な鍵を利用できるようにすること

「CMKを使えば安全」ではありません。鍵の管理を誤ると、漏えいだけでなく復旧不能の原因にもなります。

通信時の暗号化

保存時だけでなく、アプリケーションとDBの間の通信も暗号化します。

Aurora PostgreSQLでは、DBクラスターパラメータグループでrds.force_ssl=1を設定することで、暗号化されていない接続を拒否できます。Aurora PostgreSQL 17以降ではデフォルトで有効ですが、16以前ではデフォルトで無効のため、設定を確認する必要があります（AWS公式：Aurora PostgreSQLのSSL/TLS）。

システム運用編13.⑥では、オープンなネットワーク上で所定のTLS接続を利用する場合、TLS1.3以上を基本とし、対応が困難な場合にはTLS1.2も認めています。これはオープンなネットワークに関する規定ですが、VPC内部のDB通信についてもTLS1.3を優先し、必要に応じてTLS1.2以上に制限する設計がよいと考えます。

アプリケーション側では、通信を暗号化するだけでなく、接続先が正しいDBサーバであることを証明書で検証します。

また、RDSのCA証明書には有効期限があるため、証明書の更新手順も運用に組み込んでおきます。AWSがDBサーバ証明書を自動更新する場合でも、アプリケーション側の信頼済みCA証明書を適切に管理する必要があります（AWS公式：RDSのSSL/TLS証明書）。

暗号化はアクセス制御の代わりではない

保存時暗号化は、アプリケーション経由の漏えいを防ぎません。アプリケーションに復号後のデータを読む権限があれば、SQLインジェクション、過剰なAPI権限、認証不備による漏えいは起こり得ます。

これは漏えい時の報告義務にも関係します。個人情報保護法のガイドライン（通則編）3-5-3では、要配慮個人情報を含む個人データが漏えいした場合は個人情報保護委員会への報告が必要ですが、「高度な暗号化」が施されたデータは例外になります。診療情報は要配慮個人情報なので、件数にかかわらずこの規定の対象です（医療・介護関係事業者ガイダンス）。しかし、アプリやDBの認証情報を経由して漏れた場合、出ていくのは復号済みのデータです。保存時暗号化をしているから報告不要、とはならないケースが多いと考えておくべきです。

3. ログ：診療の経緯を説明できる最小限の記録

ログについてはとりすぎても良くないし、ガイドラインで定められているものは一定期間は保存しておく必要があります。また、ログと言ってもいろいろな種類のログがあるので一概には説明しきれませんが、この段落ではRDS周りのログについて解説します。

SQL全文を常時ログに残す設計は採用しません。SQLには患者氏名、病名、自由記述、検索条件などが含まれる可能性があるためです。

これは、SQLログが法令上禁止されているという意味ではありません。SQLログを残す必要がある場合は、それ自体を医療情報として管理し、保存期間、アクセス制御、暗号化、監査を設計する必要があります。システム運用編17.1も、アクセスログはそれ自体に個人情報が含まれうるため、保護が必須だとしています。

ログは役割ごとに3層に分けます。

層	何を記録するか	主な手段
アプリケーション	誰が、どの患者の、何を、なぜ操作したか	アプリの監査ログ
データベース	接続・切断、管理者の直接操作、DDL・権限変更	`log_connections` / `log_disconnections`、pgaudit
AWS	誰がインフラや鍵を操作したか、どこから通信したか	CloudTrail、SSMセッションログ、VPC Flow Logs

アプリケーションの監査ログ

誰がどの患者の記録を閲覧・操作したかは、RDSのログでは分かりません。アプリはコネクションプールで共通のDBユーザーを使うため、DBから見えるのはアプリの接続だけだからです。システム運用編17.①が求める「操作した医療情報が特定できる記録」は、アプリケーション側の監査ログで残し、DBとは別の場所（CloudWatch Logs 経由で Object Lock 付きのS3など）に保管します。監査ログの項目や設計は、別の記事で扱います。

データベースのログ

DBの接続・切断ログは、不審な接続を調査するために使います。一方、誰がどの患者の記録を閲覧したかは、アプリケーションの監査ログで追います。

ただし、管理者がDBに直接接続して行った操作は記録が必要です。システム運用編10.③は、保守要員がアクセスした個人情報と作業内容を記録するよう求めています。pgauditで記録対象をDDL・権限変更と管理者ロールの操作に絞ることで、アプリケーションのSQL全文を残さずに、保守作業の監査証跡を確保できます。ただし、保守要員がアクセスした個人情報まで特定できるかは、ログの記録内容を確認する必要があります。

全文ログを止めていても、患者情報がDBのログに混入することはあります。PostgreSQLは、エラーを起こしたSQL文や、バインドパラメータの値をログに出すことがあるためです。log_min_error_statement、log_parameter_max_length_on_error、log_min_duration_statement などの設定を確認し、実際に出力されたログを定期的にサンプリングして確かめます。（こんなこと言いだすとキリがないと思います。なのでログは実運用とともに必要があれば制限を増やしていくと言った運用になると思います。）

RDSのログをDBの外へ出す

RDSのログは、そのままではDBインスタンスのローカルにしか残りません。保持期間も使用者側で決めることができ、既定で3日、最大でも7日程度です。2省ガイドラインが求める「法定保存年限以上」（診療録なら5年以上）には到底足りないため、CloudWatch Logs へエクスポートし、そこから長期保管先へ送ります。

簡単に保存しておいた方がいいログかどうか以下に示しておきます。

ログ	「医療情報へのアクセスの記録」か	保存期間の考え方
アプリの監査ログ（誰がどの患者を見たか）	該当する（本命）	原則5年以上
管理者がDBに直接入った操作の記録（pgaudit）	該当しうる（保守要員が個人情報にアクセスした記録）	アプリの監査ログと同じ扱いが無難
接続・切断、エラー、パフォーマンスのログ	基本的に該当しない	不審な接続の調査やインシデント対応に必要な期間を自社で決める
CloudTrail、VPC Flow Logs など	該当しない	不審な接続の調査やインシデント対応に必要な期間を自社で決める

CloudWatch Logs は、検知と直近の調査に使う場所と位置づけます。長期保管は、サブスクリプションフィルタと Data Firehose でログ保管用アカウントのS3へ送り、そちらで行います。

RDS/Auroraのログについて、次の管理を決めます。

改ざん防止： 保管先のS3で Object Lock（コンプライアンスモード）を有効にする。ログ保管用のAWSアカウントを本番と分けると、本番アカウントやDBの管理者権限が奪われてもログは消されない
ログへのアクセス制御： CloudWatch Logs のロググループとS3の読み取り権限を、監査担当者などに限定する。DBの管理者と、ログを読める人は分ける
保持期間： 2省ガイドラインにならい、S3側で5年以上を目安にする。CloudWatch Logs 側は検知に必要な期間だけにして、コストと閲覧範囲を抑える
時刻： RDSのログは既定でUTCで記録される。log_timezone を変えず、アプリの監査ログもUTCにそろえると、両者を突き合わせやすい（システム運用編17.③）
患者情報の混入： DBのログ以外にも経路がある。Database Insights は、上位のSQLとして実行文を表示するため、検索条件などの値が見える可能性がある。有効にする場合は、閲覧できるIAM権限を絞る
監査時の検索性： S3に送ったログを、Athenaでクラスタ名・DBユーザー・期間から検索できるようにしておく
期限到来後の削除： Object Lockの保持期間を最低保存期間に合わせ、期限が来たものはS3のライフサイクルルールで削除する

ログを見る仕組み

ログは取るだけでは意味がありません。システム運用編17.1は、全てのログを目視するのではなく、システムでの監視や閾値によるスクリーニングを経たログを定期的に確認し、緊急時にはアラートを出すことを求めています。

RDS/Auroraまわりでは、次のような検知ルールを用意します。
検知ルールもつければつけるだけいいというわけではなく、検知の閾値の設定も含め、実運用と照らし合わせながら必要となるものだけ設定してください。

DBのログ（CloudWatch Logs のメトリクスフィルタ）

認証失敗が短時間に続いた（password authentication failed）
アプリ用以外のDBユーザーで接続があった（log_connections の出力から判定）
pgauditに、DDLやロール・権限の変更が記録された

AWS API（CloudTrail と EventBridge）

PubliclyAccessible の変更、セキュリティグループの変更
パラメータグループの変更（rds.force_ssl や監査ログの設定）
スナップショットの共有設定の変更（ModifyDBSnapshotAttribute）や、想定外のアカウント・リージョンへのコピー
DBの削除、削除保護の解除、KMS鍵の無効化・削除予約

その他

GuardDuty の RDS Protection が、不審なログインを検知した
RDSイベント（フェイルオーバー、ストレージ不足など）が発生した

4. バックアップ：復旧と法定保存は別物

バックアップの目的は、障害や事故、攻撃からシステムを復旧することです。一方、診療録の法定保存の目的は、保存期間のあいだ、必要なときに記録を提供できることです。電子保存では、記録が真正性・見読性・保存性を保っていることが求められます。

診療録の保存期間は、医師法第24条第2項で5年間と定められています。保険診療では、保険医療機関及び保険医療養担当規則第9条が、診療録を五年間保存するよう求めています。期間の起点は記録ごとに異なります。そのため、「バックアップを5年保持する」という設定を採用しても、それはバックアップの保持期間の設計です。診療録の法定保存を満たしたことにはなりません。
なお、医師法の「5年間」は最低限の保存期間で、5年を過ぎたら削除しなければならないという意味ではありません。保存期間が終わった後に消すかどうかは、医療機関が判断します。患者から消去を求められた場合も、請求の相手は医療機関で、保存義務のある期間中はすぐには消せません。サービス事業者は、医療機関の指示や契約で決めたルールに従って削除を実行できる仕組みを用意しておきます。

ガイドラインが求めるバックアップ

システム運用編18では、サイバー攻撃への備えとして、重要なファイルのバックアップを複数世代・複数方式で確保することが遵守事項として示されています。

また、解説部分では、特に一定規模以上の病院や地域で重要な機能を持つ医療機関について、バックアップをネットワークから分離して保管することや、世代管理を行うことの重要性が説明されています。

日次でバックアップする場合には、少なくとも3世代を保持し、3世代目以降の古い世代を書き込み不可の状態にすることなどが例示されています。

ただし、具体的なバックアップ構成は、医療機関の規模、システムの重要度、必要な復旧時間、想定するリスクなどによって異なります。

この記事では、ランサムウェアによるバックアップの破壊や、誤操作からの復旧を考慮し、RDSの自動バックアップに加えて、別アカウントへの隔離と論理バックアップを組み合わせる構成を紹介します。

RDS/Auroraで用意するもの

RDSの自動バックアップだけでは、上の条件を満たせません。自動バックアップは保持期間が最大35日で、本番と同じアカウントに置かれます。アカウントの管理者権限を奪われると、バックアップごと削除されるおそれがあります。

そこで、役割の違う3つを組み合わせます。

手段	役割	保持期間の例
RDSの自動バックアップ（ポイントインタイムリカバリ）	誤操作や障害から、直前の時点へ戻す	14〜35日
AWS Backup（別アカウント・別リージョンへのコピー、Vault Lock）	攻撃者に消されない世代を確保する	毎日取ったものは35日間、毎週取ったものは12週間、毎月取ったものは12か月間残す
論理バックアップ（`pg_dump` など）	物理スナップショットとは異なる方法でデータを保全し、PostgreSQL環境への移行や復旧に利用する	毎週取ったものは12週間、毎月取ったものは12か月間残す

AWS Backup の保持期間は、「取る頻度ごとに、残す期間を変える」という考え方です。古いバックアップほど間引いて残します。

たとえば今日が10月11日なら、戻せる時点は次のようになります。

どこまでさかのぼるか	戻せる時点
直近35日間（9月6日〜今日）	どの日にでも戻せる
約3か月前まで（7月中旬〜9月上旬）	毎週日曜の時点に戻せる
1年前まで（昨年11月〜7月）	毎月1日の時点に戻せる

最近のトラブル（誤操作など）では、細かい時点に戻したくなります。一方、何か月も前の時点に戻す必要があるのは、長く潜伏していた攻撃に後から気づいた場合くらいです。そのため、古いバックアップは粗い間隔で十分です。この方式なら、手元に残るバックアップは約60個で、毎日の分を1年間残す（365個）よりコストを抑えつつ、1年前までさかのぼれます。

日次のバックアップを35日分残しているので、システム運用編18が求める「少なくとも3世代」も十分に満たします。ただし、バックアップは診療録の法定保存の手段ではありません。長く残すほど、削除したデータが完全に消えるまでの期間も延びるので、最長でも1年程度にとどめています。数字は一例なので、コスト、医療機関との契約に合わせて調整してください。

あわせて、次も設定します。

削除保護
DB削除時に自動バックアップを残す設定
削除時の最終スナップショットの取得

なお、バックアップを取得できていても、実際に必要な時間内で復元できるとは限りません。

そのため、RTO（目標復旧時間）とRPO（目標復旧時点）を決め、復元テストによって達成できるかを確認します。また、別アカウントへバックアップを保管する場合は、復旧先から暗号鍵を利用できるか、必要なIAM権限があるかについても確認が必要です。

さらに、AWS Backupによるスナップショットとpg_dumpを併用する場合でも、両方が同じ権限や認証情報に依存していれば、攻撃によって同時に失われる可能性があります。保存方式だけでなく、保存先や管理権限の独立性も考慮して設計します。

5. 削除：退会、論理削除、法定保存を分ける

患者がサービスを退会したからといって、診療録を直ちに全削除できるとは限りません。一方で、必要がなくなったデータを無期限に残すことも適切ではありません。

誰が削除を決めるか

「医療機関から委託を受けて取り扱う」構成では、診療録を保存する義務を負うのは医療機関側です。
医師法第24条第2項では診療録について5年間の保存義務が定められています。また、保険医療機関については、保険医療機関及び保険医療養担当規則第9条により、診療録をその完結の日から5年間保存することが求められています。

なお、診療録の「完結の日」は、単に個々の記録が作成された日とは限りません。保存期間の起点や完結の判断は、医療機関の業務や適用される法令に応じて整理する必要があります。

そのため、患者がサービスを退会しても、サービス事業者の判断だけで診療録を削除することはできません。

退会で行うのは、アカウントの停止です。診療録は医療機関のために保存を続け、保存期間が終わるか、契約終了時に返却・移管するまで管理します。

通則編3-4-1は、利用する必要がなくなった個人データを遅滞なく消去するよう努めることを求めています。同時に、法令で保存期間が定められている場合は除くとしています。また、ここでいう「消去」には、データの削除だけでなく、特定の個人を識別できないようにすることも含まれます。

削除の状態を分ける

状態	意味	主に使う場面
非表示	通常画面から見えない	誤登録の取り下げなど
論理削除	削除フラグを付け、通常処理から除外	退会したアカウント、診療録以外のデータ
アーカイブ	通常の業務DBから分離し、閲覧・出力はできる	保存期間中で、日常業務では使わない診療録
物理削除	DBから行を消す	保存期間が終わった記録
バックアップ期限到来	バックアップの世代からも消える	物理削除の後、最後のバックアップが期限切れになった時点

保存期間を適切に管理するには、記録の種類、適用される保存義務、保存期間の起点となる日付を判断できるようにする必要があります。診療録では、個々の記録の作成日と診療録の完結の日が必ずしも一致しないため、医療機関側の判断に基づいて保存期間を管理できる設計が必要です。

RDSで「消えた」と言えるまで

論理削除は、個人情報保護法上の「消去」と同じではありません。データが残っている場所を、DB本体、履歴テーブル、オブジェクトストレージ、ログ、スナップショット、バックアップに分けて確認します。
RDS/Auroraでは、DELETEを実行しても、そのデータが保存されていた物理領域や過去のバックアップから即座に消えるわけではありません。

特にPostgreSQLでは、DELETEによって行が通常の検索対象から除外されても、ストレージ上の領域が直ちに完全消去されるわけではありません。VACUUMも、物理ストレージ上のすべてのデータを安全に消去したことを証明する機能ではありません。

そのため、この記事では次のように管理します。

本番DBからの削除：保存義務や契約上の要件を確認したうえで、削除対象のデータを本番DBから削除する。これを通常のアプリケーションから利用できない状態への移行として管理する
バックアップからの削除：自動バックアップ、手動スナップショット、別アカウント・別リージョンのコピー、論理バックアップなど、データが残る保存先を把握し、それぞれ定められた保持期間の終了に従って削除する
復元時の対応：過去のバックアップから復元すると、削除済みのデータが再び現れる可能性があるため、削除履歴を確認して必要な削除を再適用する

ここで重要なのは、削除履歴を復元対象のDBとは独立して管理することです。

例えば、10月5日に患者情報を削除したあと、10月1日のバックアップへ復元すると、DB内に保存されていた10月5日の削除履歴も失われる可能性があります。

そのため、削除対象の識別子や削除日時などの情報を、別の保護された保存先に記録するか、独立した変更履歴から再構成できるようにしておきます。

復元後は必要な削除を再適用し、確認が完了するまで、復元した環境を通常の利用者や外部連携先へ公開しないようにします。

なお、バックアップの保持期間が1年間であっても、手動スナップショットやログ、エクスポートファイルなどに別のコピーが存在する場合、それらのデータが1年以内にすべて消えるとは限りません。

そのため、データの保存先と保持期間を把握し、実際に消去が完了する条件を契約や運用手順で明確にしておく必要があります。

まとめ

ここまで、AWS RDSで医療情報を扱うときの論点を見てきました。

医療情報システムの安全管理では、すべての高度なセキュリティ機能を最初から導入する必要があるわけではありません。ただし、法令やガイドラインの遵守事項、リスク評価、医療機関との契約などに基づいて必要と判断した安全管理措置は、本番稼働前に確保しておく必要があります。

この記事では、特に「最初に決めておかないと後から変更しにくいこと」を中心にまとめました。

最初に決めておきたいのは、次のことです。

DBをプライベートサブネットに置き、パブリックアクセスを無効にする： ネットワークは最初から閉じておく
保存時の暗号化と鍵の管理方法を決める： RDSとAuroraでは暗号化の仕様が異なり、構築後に鍵の変更が容易ではない場合がある
アプリケーションで「誰が・いつ・どの患者の情報を操作したか」を記録する： 記録していない過去のアクセスは、後からさかのぼれない
ログに患者の氏名や診療内容を不必要に含めない： 必要な監査証跡は確保しつつ、ログ自体が新たな漏えいリスクにならないようにする
バックアップの保存先と復旧手順を決める： バックアップの取得だけでなく、実際に復元できることまで確認する

一方で、検知ルールの閾値や監視の効率化、コストを考慮したログ管理などは、必要な安全性を確保したうえで継続的に改善していくことができます。

医療情報を扱うシステムに「これで完成」というゴールはありません。ガイドラインも改訂され、サービスも成長し、扱うデータも変化していきます。

だからこそ、最初に必要な土台を整え、その後もリスク評価と運用改善を続けていくことが重要だと考えています。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up