第12章 ケーススタディ
AWS
AUTION EYE
トラブルシューティング
12.1 DNS許可漏れ事例
状況
A病院でSmart Assistの導入作業中、テスト通信で接続に失敗した。
症状
curl -v https://smartassist.example.com/health
* Could not resolve host: smartassist.example.com
切り分けの過程
| ステップ | 実施内容 | 結果 |
|---|---|---|
| 1 | ping デフォルトGW | 成功 |
| 2 | nslookup smartassist.example.com | 失敗 (NXDOMAIN) |
| 3 | nslookup smartassist.example.com 8.8.8.8 | 失敗 (タイムアウト) |
| 4 | nslookup google.com | 失敗 (NXDOMAIN) |
| 5 | ping 院内DNSサーバIP | 成功 |
原因
院内DNSサーバは稼働していたが、外部DNSへのフォワーディング（UDP 53番ポート）がファイアウォールで許可されていなかった。ファイアウォール許可申請でHTTPS（443/tcp）のみ申請し、DNS（53/udp）の許可を漏らしていた。
解決策
ファイアウォールで院内DNSサーバから外部DNSサーバ（または上位DNSフォワーダ）への53/udp通信を許可した。
教訓
- HTTPS通信だけでなく、DNS解決に必要な通信経路も含めて申請する
- ヒアリング時に「院内DNSから外部FQDNを解決できるか」を確認しておく
- テスト通信はDNS解決から順を追って確認する
この事例のようなDNS許可漏れは、FW許可申請時のチェックリストで防げます。申請書を出す前に、以下を確認してください：
- HTTPS 443/tcp ― Smart Assist PC → 宛先FQDN
- DNS 53/udp ― 院内DNSサーバ → 外部DNS（フォワーダ先）
- NTP 123/udp ― Smart Assist PC → NTPサーバ（時刻同期用）
- セキュリティ更新 ― Smart Assist PC → McAfee/Windows Update のFQDN群
特にDNSの53/udpは「院内DNSがすでに外部名を解決できる状態」なら不要ですが、事前に nslookup smartassist.example.com を試して確認しておくのがベスト。申請前にこの1コマンドを実行するだけで、このケーススタディの事態は100%防げます。
12.2 プロキシ誤設定事例
状況
B病院でSmart Assistの導入後、一部の時間帯で通信が断続的に失敗する事象が報告された。
症状
curl -v --proxy http://proxy.hospital-b.local:8080 https://smartassist.example.com/health
* Connection timed out after 30000 milliseconds
ただし、成功する場合もあり、再現性が不安定だった。
切り分けの過程
| ステップ | 実施内容 | 結果 |
|---|---|---|
| 1 | DNS解決 | 成功 |
| 2 | ping proxy.hospital-b.local | 成功 |
| 3 | プロキシポート疎通確認 | 成功 |
| 4 | プロキシ経由でのcurl | 断続的に失敗 |
| 5 | プロキシを経由しないcurl | 常に成功 |
| 6 | プロキシのログ確認 | 認証エラーが散発的に記録されていた |
原因
B病院のプロキシは認証プロキシ（NTLM認証）であった。Smart Assist PCの設定では認証情報が環境変数に設定されていたが、NTLM認証セッションのタイムアウトにより、定期的に再認証が必要になっていた。Smart Assistクライアントが再認証に対応していなかった。
解決策
病院IT担当者と協議し、以下の対応を実施した。
- Smart Assist PCのIPアドレスをプロキシの認証除外リストに追加
- プロキシでの通信許可は、宛先FQDNのホワイトリストで制御
教訓
- プロキシの認証方式と、Smart Assistクライアントの認証対応を事前に確認する
- 断続的な障害はタイムアウトやセッション管理の問題を疑う
- 認証プロキシ環境では、サービスアカウントまたは認証除外の検討が必要
12.3 セキュリティレビューで止まった例
状況
C病院でSmart Assistの導入を提案したところ、セキュリティレビューで差し止められ、導入が3か月間停滞した。
レビューで指摘された事項
| # | 指摘事項 | 深刻度 |
|---|---|---|
| 1 | 「通信は双方向か」への回答が不明確 | 高 |
| 2 | 送信データの一覧が不完全 | 高 |
| 3 | クラウド上でのデータ保持期間が未回答 | 中 |
| 4 | 障害時に検査業務が完全停止するかの説明がない | 中 |
| 5 | 適用される規制・ガイドラインへの準拠状況が不明 | 高 |
何が問題だったか
- 指摘1: エンジニアが「結果が返ってくるので双方向です」と回答してしまった。正確には「Outbound Only（レスポンスはセッション応答）」と説明すべきだった。
- 指摘2: 送信データの説明で「画像を送ります」としか書かず、「患者情報は含まれない」という明確な否定がなかった。
- 指摘3: データ保持ポリシーを事前に確認していなかった。
- 指摘4: Smart Assist停止時も確定データは通常通りLISに送られることを説明していなかった。
- 指摘5: 適用される規制（日本: 3省2ガイドライン、米国: HIPAA、EU: GDPR）への準拠状況を整理した資料を準備していなかった。
どのように解決したか
| 指摘 | 対応 |
|---|---|
| 1 | 通信シーケンス図を作成し、Outbound Onlyであることを技術的に説明 |
| 2 | 送信データの一覧表を作成（含む/含まないを明記） |
| 3 | クラウド運用チームからデータ保持ポリシーを入手し提出 |
| 4 | 障害時影響分析書を作成し、検査業務の継続性を説明 |
| 5 | 適用される規制（3省2ガイドライン / HIPAA / GDPR）の各要件に対する準拠状況一覧表を作成 |
教訓
- セキュリティレビューで聞かれることは予測可能（第3章 3.5参照）
- 「聞かれてから調べる」ではなく「聞かれる前に資料を用意する」
- 「双方向通信」という表現は使わない ― 正確に「Outbound Onlyのセッション応答」と説明する
- 否定の明示（「含まれない」）は肯定の説明と同じくらい重要
12.4 SSLインスペクションで通信不能
状況
D病院でSmart Assistの導入テストを実施したところ、HTTPS接続が証明書エラーで失敗した。
症状
curl -v https://smartassist.example.com/health
* SSL certificate problem: unable to get local issuer certificate
切り分けの過程
| ステップ | 実施内容 | 結果 |
|---|---|---|
| 1 | DNS解決 | 成功 |
| 2 | ポート443疎通 | 成功 |
| 3 | curlでHTTPS接続 | SSL証明書エラー |
| 4 | 証明書の発行者確認 | issuer: CN=D-Hospital-Proxy-CA |
| 5 | 病院IT担当者に確認 | 「プロキシでSSLインスペクションを行っている」 |
原因
D病院では、セキュリティ対策としてすべてのHTTPS通信に対してSSLインスペクションを行っていた。プロキシがSmart Assistサーバとの間でTLS接続を確立し、Smart Assist PCに対してはプロキシ独自のCA証明書で署名した証明書を提示していた。
Smart Assist PCの信頼されたルート証明書ストアに病院プロキシのCA証明書が含まれていなかったため、証明書の検証に失敗した。
解決策
病院IT担当者と協議した結果、以下の対応を実施した。
対処法A（採用）: SSLインスペクション除外
- Smart Assistの宛先FQDN（
smartassist.example.com）をSSLインスペクションの除外リストに追加 - Smart Assist PCはAWSの正規のサーバ証明書を直接検証するようになり、エラーが解消
対処法B（不採用）: プロキシCA証明書のインストール
- 不採用の理由: Smart Assistアプリケーションが独自の証明書ストアを使用しており、OS側の証明書ストアだけでは不十分だった
教訓
- ヒアリング時にSSLインスペクションの有無を必ず確認する
- 証明書エラーが出たら、まず発行者（issuer）を確認する
- SSLインスペクション除外が最もシンプルで確実な対処法
- 除外申請は「どのFQDNを除外するか」を明確にして依頼する
「SSLインスペクションを除外してほしい」と病院IT担当者にお願いすると、高確率で抵抗されます。「セキュリティポリシーで全HTTPS通信をインスペクションすることになっている」と言われるんですよね。
そこで使える交渉術が「代替手段の提示」です：
- 「通信先はAWS上の自社管理環境のみで、WAFとGuardDutyで保護されています」（通信先の安全性）
- 「TLS 1.2で暗号化されており、中間者攻撃のリスクはインスペクションなしでも低いです」（暗号化の保証）
- 「ISO 27001認証を取得した運用環境です」（第三者認証の提示）
「除外してください」ではなく「除外しても安全な理由はこの3つです」という言い方をすると、だいたいスムーズに通ります。根拠なく除外を依頼するのは信頼を損なうのでNG。
12.5 実際のログ解析事例
状況
E病院で稼働中のSmart Assistの通信が突然失敗した。前日までは正常に動作していた。
収集したログ
Smart Assist PCからのcurl出力
curl -v https://smartassist.example.com/health
* Trying 52.194.10.20:443...
* Connected to smartassist.example.com (52.194.10.20) port 443
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, certificate expired (557):
* SSL certificate problem: certificate has expired
証明書情報の確認
openssl s_client -connect smartassist.example.com:443 < /dev/null 2>/dev/null \
| openssl x509 -noout -dates -issuer -subject
subject= /CN=smartassist.example.com
issuer= /C=US/O=Amazon/CN=Amazon RSA 2048 M01
notBefore=Feb 15 2025 00:00:00 GMT
notAfter=Feb 14 2026 00:00:00 GMT ← 有効期限内
分析
- curlでは「certificate has expired」と表示されている
- しかし、opensslで確認したサーバ証明書の有効期限は2026年2月14日であり、期限内
この矛盾をどう解釈するか？
追加調査：中間証明書の確認
openssl s_client -connect smartassist.example.com:443 -showcerts < /dev/null 2>&1
---
Certificate chain
0 s:/CN=smartassist.example.com
i:/C=US/O=Amazon/CN=Amazon RSA 2048 M01
Validity: Not After: Feb 14 2026 ← サーバ証明書（有効）
1 s:/C=US/O=Amazon/CN=Amazon RSA 2048 M01
i:/C=US/O=Starfield Technologies/CN=Starfield Services Root CA
Validity: Not After: Feb 10 2026 ← 中間証明書（期限切れ！）
---
原因
サーバ証明書自体は有効期限内だったが、中間証明書（Intermediate CA Certificate）の有効期限が切れていた。証明書チェーンの中間証明書が期限切れであるため、証明書チェーン全体の検証に失敗していた。
解決策
Smart Assist運用チームにエスカレーションし、AWS上のロードバランサ（ALB）に設定されている中間証明書を更新してもらった。
ログ解析のポイント
| ポイント | 内容 |
|---|---|
| エラーメッセージだけで判断しない | 「certificate expired」でもサーバ証明書が原因とは限らない |
| 証明書チェーン全体を確認する | -showcertsオプションで中間証明書も表示させる |
| 複数のツールで確認する | curlとopensslで異なる角度から確認する |
| 「昨日まで動いていた」を手がかりにする | 時間に関連する原因（証明書期限、ライセンス期限など）を疑う |
12.6 大学病院向けセキュリティ説明の実例
状況
F大学病院（大規模大学病院）にSmart Assistの導入を提案した。大学病院では独自の情報セキュリティポリシーを持ち、厳格なセキュリティレビューが実施される。この事例では、実際に大学病院向けに作成した説明資料の構成を通じて、大規模施設への提案方法を学ぶ。
大学病院のセキュリティレビューの特徴
大学病院のセキュリティレビューは、一般の中小規模病院と比較して以下の特徴がある。
| 特徴 | 一般的な病院 | 大学病院 |
|---|---|---|
| 審査体制 | IT担当者の判断 | 情報セキュリティ委員会の審議 |
| 審査期間 | 1〜4週間 | 1〜6か月（委員会開催サイクルに依存） |
| 要求される資料 | 基本的なシステム概要 | 詳細な技術設計書、リスクアセスメント結果 |
| セキュリティ基準 | 施設独自の基準 | 大学全体のポリシー + 医学部・病院固有の基準 |
| 関与する部門 | IT部門のみ | IT部門 + 医療情報部 + 事務部門 + 場合により研究部門 |
説明資料の構成（大学病院向け）
大学病院向けの説明資料は、以下の4つのパートで構成する。各パートは、セキュリティ委員会のメンバー（必ずしも技術者ではない）にも理解できるよう、図を多用した構成にする。
パート1: クラウドシステム全体構成
AWSクラウド構成図を用いて、システムの全体像を説明する。
| 説明要素 | 内容 | 強調すべきポイント |
|---|---|---|
| 院内側 | AUTION EYE → PC → 院内LAN → ファイアウォール | 既存の院内インフラの範囲内で動作 |
| 通信経路 | Outbound Only（443/tcp） | 外部からの着信接続は一切なし |
| AWS構成 | ALB → Lambda → S3/RDS | マネージドサービス中心で運用負荷を軽減 |
| 認証 | Cognito（ID管理） | 認証されたデバイスのみアクセス可能 |
パート2: セキュリティ設計の詳細
技術者向けの詳細説明として、以下の要素を図と表で示す。
| セキュリティ要素 | 実装 | 説明時の表現 |
|---|---|---|
| 通信の暗号化 | TLS 1.2 + AES | 通信経路の全区間で暗号化 |
| 認証・認可 | Cognito + IAM | デバイスIDに基づくアクセス制御 |
| ネットワーク分離 | Private Subnet + Security Group | データベースは外部からアクセス不可能 |
| データ保護 | S3暗号化 + RDS暗号化 | 保存データも暗号化 |
| 監査ログ | CloudTrail + CloudWatch | すべてのアクセスを記録 |
| 脅威検知 | GuardDuty + Shield | DDoS防御と異常検知 |
パート3: ファイアウォール設定の具体的指示
大学病院のIT部門が実際にFW設定を行えるよう、具体的な設定値を提示する。
| 通信先カテゴリ | FQDN/URL | ポート | 方向 |
|---|---|---|---|
| Smart Assist API | *.arkray-smartassist.com | 443/tcp | Outbound |
| 画像保存先 | *.s3.us-east-1.amazonaws.com | 443/tcp | Outbound |
| 時刻同期 | ntp.nict.jp 等 | 123/udp | Outbound |
第7章 7.7で解説したFW許可FQDN一覧を、そのまま大学病院IT部門に提示する形となる。
パート4: 第三者認証・監査結果の提示
大学病院は特に第三者による認証を重視する傾向がある。以下の3層のセキュリティ保証を提示する。
| 認証・レポート | 対象レイヤ | 提示する資料 | 解説章 |
|---|---|---|---|
| ISO/IEC 27001 | アプリケーション開発・運用 | MSA-IS-718 認証書 | 第9章 9.7 |
| SOC 2 Type II | AWSインフラ | SOC 2レポート | 第8章 8.8 |
| HIPAA Risk Assessment | 規制準拠 | ecfirst社監査レポート | 第9章 9.6 |
大学病院での想定質問と回答
| 質問 | 回答のポイント |
|---|---|
| 「データはどこに保存されるか？」 | AWSの米国リージョン（us-east-1）。保存データは暗号化。データ保持期間はポリシーに基づき設定可能 |
| 「外部から院内ネットワークにアクセスされるリスクはないか？」 | Outbound Onlyのため、外部からの着信接続は一切不可。ファイアウォールのルールで確認可能 |
| 「インシデント発生時の通知体制は？」 | GuardDutyによる自動検知、CloudWatch Alarmによる即座通知。サポート体制の連絡先を提示 |
| 「大学の情報セキュリティポリシーに適合しているか？」 | ISO 27001認証を取得しており、国際的な情報セキュリティ基準に適合。個別ポリシーとの照合が必要な場合は対応する |
| 「他の大学病院での導入実績はあるか？」 | 具体的な施設名は守秘義務により開示できないが、同等規模の施設での導入実績があることを説明 |
教訓
- 大学病院では委員会審議のスケジュールを早期に確認し、導入計画に組み込む
- 資料は非技術者にもわかる図と技術者が検証できる具体的な設定値の両方を含める
- 第三者認証の提示が信頼獲得の決め手になることが多い
- 提案から稼働開始まで6か月以上を見込んでスケジュールを組む（第11章 11.7参照）
全ケーススタディのまとめ
| 事例 | 原因カテゴリ | 根本原因 | 防止策 |
|---|---|---|---|
| 12.1 | DNS | FWでDNS通信が未許可 | 通信要件にDNSを含める |
| 12.2 | プロキシ | 認証プロキシのセッションタイムアウト | 認証方式の事前確認 |
| 12.3 | プロセス | セキュリティレビュー・規制準拠資料の不備 | 事前の資料準備と想定問答 |
| 12.4 | SSL | SSLインスペクションによる証明書差し替え | ヒアリングでの事前確認 |
| 12.5 | 証明書 | 中間証明書の期限切れ | 証明書監視の仕組み構築 |
| 12.6 | プロセス | 大学病院の厳格なセキュリティレビュー | 委員会スケジュール把握、多層的資料準備 |
補足（国際的な文脈）: 本章のケーススタディは日本の病院環境を前提としているが、技術的な問題（DNS許可漏れ、プロキシ誤設定、SSLインスペクション、証明書期限切れ）は地域を問わず発生する。セキュリティレビューのプロセス（12.3）については、米国ではHIPAA準拠のSecurity Risk AssessmentやBAA締結のプロセス、EUではGDPR DPIAのプロセスに読み替えて理解すること。
本教材のまとめ: Smart Assistのネットワーク技術者は、通信技術の知識だけでなく、医療ITの文脈を理解し、病院IT担当者と信頼関係を構築できる能力が求められる。本教材で学んだ知識を土台に、実務経験を積み重ねることで、自立したエンジニアへと成長してほしい。