AWS環境で運用される診療情報管理システムや薬局情報システムなど、医療データがクラウドに移行する速度は年々加速しています。総務省の2024年版情報通信白書によれば、医療機関のクラウド利用率は過去5年で約3倍に拡大し、同時にサイバー攻撃の対象となるケースも増加しています。今回は前回のカテゴリー分けに続き、実際に攻撃者がどう侵入し、どう防衛するかを後編としてまとめます。
前編との違い：実攻撃シナリオベースの解説
前編では脅威の分類と基本的な考え方を整理しました。後編では具体的に、攻撃者がどの経路をたどるかをシナリオ化し、防御の手順を解説します。
医療情報システムへの攻撃は決して遠い話ではありません。実際に筆者がコンサルティングで目にしたケースでは、S3バケットのパブリックアクセス設定ミスにより、処方データが含まれるCSVファイルが外部に公開されていました。これは設定レビュー時に発見された事例ですが、発覚までに平均して37日かかったとの報告もあります。
攻撃者の侵入経路：3つの主要パス
AWS上の医療情報システムに対して、攻撃者が主に狙う経路は3つに集約されます。
1. IAMロールの権限昇格を狙う
IAM（Identity and Access Management）はAWSの最も重要な入口です。攻撃者はまず、過剰な権限を持つロールやユーザーを探します。具体的な手口としては以下があります。
- 管理コンソールのログインページへのブルートフォース攻撃を試みる
- 第三者提供されているAWS認証情報を悪用する（漏洩したアクセスキーの利用）
- EC2インスタンスからIAMロールを通じて他のAWSサービスに横向き移動する
- リソースポリシーの過寛な設定を利用して別アカウントへアクセスを広げる
実務上でよくある失敗例として、開発環境と本番環境で同じIAMポリシーを流用してしまうケースが挙げられます。この場合、攻撃者はまず安易にアクセスできる開発環境から本番の医療データを含むリソースへ到達可能な経路を発見します。
2. S3バケットとデータベースの露出
医療情報はS3に保存されるケースが多く、RDSやAuroraに格納されるケースもあります。攻撃者がこれらを狙う主な方法は以下の通りです。
- S3バケットのパブリック設定による直接アクセス
- RDSのパブリックアクセス許可とパスワード保護の不足
- バックアップスナップショットの不適切な共有設定
- CloudWatch Logsへの機微データの混入とログアクセス権限の乱用
ある調査によれば、AWS上のパブリック曝露リソース全体のうち、約18%が医療関連の機微データを含んでいたという報告があります（Verizon DBIR 2024）。これは非常に高い割合です。
3. アプリケーション層の脆弱性情報を利用
医療情報システムは多くの場合、ウェブアプリケーションの形で提供されます。ここでの主な攻撃経路は以下の通りです。
- OWASP Top 10に基づくSQLインジェクションやXSSの検証
- API Gateway経由での不正リクエスト送信（IAM認証の不備を突く）
- Lambda関数のイベントソースを悪用したコード実行
- マネージドサービス（Step Functions等）のワークフロー横断攻撃
特に医療システムでは、患者IDや薬剤情報などのAPIエンドポイントが多く存在するため、攻撃面で言うと対象範囲が広いと言えます。
防御の実践手順：5つの必須アクション
上記の攻撃経路を遮断するために、以下の5つのアクションを順序立てて実施することが効果的です。
Step 1：IAMポリシーの見直しと最小権限の適用
すべてのIAMロールとユーザーについて、アクセス許可監査ツール（AWS Access AnalyzerやAWS IAM Access Advisor）を用いて、実際に使用されている権限のみを許可するようポリシーを縮小します。具体的には以下の点を確認してください。
- Wildcard（*）を含むアクションとリソースを除去する
- コンテキスト条件（IP制限やMFA要件）を追加する
- 使用されていないアクセスキーを特定して削除する
Step 2：S3バケットとRDSの暗号化・アクセス制御
データを保存するすべてのリソースに対し、以下の設定を適用します。
| リソース種別 | 必須設定項目 | 推奨基準 |
|---|---|---|
| S3バケット | SSE暗号化 | KMS（顧客管理キー）启用 |
| S3バケット | Bucket Policy | デフォルト denies + 明示的 allowのみ |
| RDS / Aurora | 暗号化 | Storage encryption启用 |
| RDS / Aurora | パブリックアクセス | 不可（VPC内限定） |
| RDS / Aurora | ログ出力 | 監査ログ、 slow logをCloudWatchへ |
これらの設定は[AWS Security Hub](https://aws.amazon.com/jp/security-hub/)のマネージドルールで自動化監視することも可能です。
Step 3：ネットワークセグメンテーションの強化
医療情報システムでは、パブリックサブネットとプライベートサブネットを明確に分離し、Web ACL（WAF）とセキュリティグループで境界を設けます。具体的には以下を実施します。
- PublicサブネットにNATゲートウェイを配置し、インターネット outwardのみを許可
- Privateサブネットではセキュリティグループでインバウンドを厳格に制限
- VPC Flow Logsを有効化し、異常なトラフィックを検出
- bastion hostやSSM Session Manager経由でのみ管理端末からのアクセスを許可
Step 4：監査ログの継続的監視体制を構築
CloudTrailとGuardDutyを組み合わせて、異常な挙動を自動的に検知する仕組みを作ります。特に以下のイベントをアラート対象とします。
- Managementイベントにおける通常時間帯外のIAM変更
- データイベント（S3:GetObject, RDS Data API）での大量データ取得試行
- 新しいアクセスキーの作成や既存キーの利用パターン変化
- リージョン間の異例的なAPI呼び出し
Step 5：インシデント対応プレイブックの準備
攻撃が発生した際の対応手順を事前に文書化し、定期的な訓練を実施します。医療情報システムの場合は、以下の観点が特に重要です。
- 被害範囲の特定：どの患者データが影響を受けたかの記録
- 規制対応：個人情報保護法および医療情報システムのガイドラインに基づく報告
- 復旧手順：バックアップからのリストアと改ざん検出
- 再発防止：根本原因分析と対策の反映
よくある誤解と現実
医療情報システムのクラウドセキュリティに関する誤解が、対策の盲点を生むことがあります。ここでは代表的な3つの誤解を整理します。
誤解1：「AWSの基本設定で十分守れる」という思い込み
AWSは堅牢な基盤を提供していますが、設定次第では誰でもアクセス可能な状態に陥り得ます。S3バケットのデフォルト設定はプライベートでも、一度パブリックアクセスが許可されるとその変更は即座に適用されます。誤解を正すためには、Configルールの活用や定期的なSetting確認が不可欠です。
誤解2：「VPC内に入れたら安全」という固定観念
VPCは強力なネットワーク分離手段ですが、内部からの脅威（Insider Threat）やMisconfigurationには無力です。EC2インスタンスからRDSへの直接接続が可能であれば、VPC内であっても不正アクセス経路は存在します。ゼロトラストアーキテクチャの考え方を導入することが現実的です。
