第7章 ファイアウォール設計実務
Palo Alto Networks(代表的な次世代FWベンダー)
Fortinet(FortiGate)
ファイアウォール装置の例(Cisco ASA 5510)
病院ネットワークで使用される業務用ファイアウォールの外観
7.1 FQDN許可とIP許可
2つの許可方式
ファイアウォールで外部への通信を許可する方法には、大きく分けて2つの方式がある。
| 方式 | 設定例 | 特徴 |
|---|---|---|
| IP許可 | 宛先: 52.194.10.20 | 特定のIPアドレスへの通信のみ許可 |
| FQDN許可 | 宛先: smartassist.example.com | ドメイン名で指定し、名前解決結果のIPを自動許可 |
AWSではFQDN許可が推奨される理由
AWSのサービスでは、以下の理由からIPアドレスが動的に変化する可能性がある。
- ロードバランサのスケーリング: 負荷に応じてIPが追加・変更される
- 障害時のフェイルオーバー: 別のIPアドレスに切り替わることがある
- メンテナンス: AWS側のインフラ更新に伴うIP変更
FQDN許可が使えない場合
古いファイアウォール機器ではFQDN許可に対応していない場合がある。その場合の対処法を以下に示す。
| 対処法 | 説明 |
|---|---|
| IPレンジで許可 | AWSのIPレンジ(公開情報)を使用して広めに許可する |
| 定期的なIP確認 | FQDNのIPアドレスを定期的に確認し、変更があればFWルールを更新する |
| プロキシ経由 | プロキシサーバでFQDN制御を行い、FWではプロキシのみ許可する |
実はこれ、現場ではけっこう多いんですよね。「FQDNベースの許可ルール」が使えない古いFW(Cisco ASA 5500シリーズの旧ファームとか)に当たることがある。そのとき焦らないで。
一番現実的なのはプロキシ経由に切り替える方法。FW側はプロキシサーバのIPだけ許可して、FQDN制御はプロキシに任せる。プロキシがない場合は、nslookup で現在のIPを確認して申請しつつ、「IPが変わる可能性がある」ことを病院IT担当者に伝えておくのがポイント。黙ってると、IP変更時に突然通信が止まって大騒ぎになります。
7.2 ポート開放の考え方
最小権限の原則
ファイアウォールのポート開放は、必要最小限の通信のみを許可する原則に基づいて設計する。
Smart Assistに必要なポート
| プロトコル | ポート | 方向 | 用途 |
|---|---|---|---|
| TCP | 443 | Outbound | HTTPS通信(データ送受信) |
| UDP | 53 | Outbound | DNS名前解決(FQDNの場合) |
ファイアウォールルールの設計例
# Smart Assist 通信許可ルール
Rule 1: HTTPS通信
送信元: 192.168.10.50/32 (Smart Assist PC)
宛先: smartassist.example.com
プロトコル: TCP
宛先ポート: 443
アクション: ALLOW
Rule 2: DNS通信(直接DNSの場合)
送信元: 192.168.10.50/32 (Smart Assist PC)
宛先: 院内DNSサーバ
プロトコル: UDP
宛先ポート: 53
アクション: ALLOW
Default Rule:
送信元: *
宛先: *
プロトコル: *
宛先ポート: *
アクション: DENY
やってはいけない設定
| 設定例 | 問題点 |
|---|---|
| 宛先: ANY、ポート: ANY | 全外部通信を許可してしまう |
| 宛先: ANY、ポート: 443 | あらゆるHTTPSサイトにアクセス可能になる |
| 送信元: ANY | Smart Assist PC以外からも通信できてしまう |
病院IT担当者に「まず全開けで接続テストして、あとで絞りましょう」と提案したくなる気持ち、分かります。でもこれ、絶対にやっちゃダメ。
理由は2つ。まず、セキュリティレビューを通過した後の病院で「一時的にでも全開け」は信頼を失います。次に、「あとで絞る」が実行されないまま本番稼働に入るリスクが高い。一度開けた穴を閉じるのは、最初からちゃんと設定するよりはるかに難しいんです。
最初から最小権限で設定して、通らなかったらトラブルシューティングで原因を特定する。この順番を守ること。
7.3 プロキシ環境での注意点
プロキシ経由の通信構成
プロキシ環境では、Smart Assist PCはファイアウォールではなくプロキシサーバを経由して通信する。
プロキシ環境で必要な設定
| 設定箇所 | 設定内容 |
|---|---|
| Smart Assist PC | プロキシサーバのアドレスとポート番号を設定 |
| プロキシサーバ | Smart Assistの宛先FQDNをホワイトリストに追加 |
| ファイアウォール | プロキシサーバから外部への443/tcp通信を許可 |
Smart Assist PCでのプロキシ設定方法
# 環境変数で設定する場合
HTTPS_PROXY=http://proxy.hospital.local:8080
# アプリケーション設定で指定する場合
プロキシホスト: proxy.hospital.local
プロキシポート: 8080
認証プロキシへの対応
認証プロキシの場合、通信ごとに認証情報の送信が必要となる。
| 確認事項 | 内容 |
|---|---|
| 認証方式 | Basic認証、NTLM認証、Kerberos認証など |
| サービスアカウント | 常時稼働するサービス向けの専用アカウントが必要か |
| パスワード変更ポリシー | 定期的なパスワード変更がSmart Assistの通信に影響しないか |
認証プロキシの病院で一番ハマるのが、サービスアカウントの問題。個人のADアカウントで認証してる環境だと、Smart Assistは「誰のアカウントでプロキシ認証するの?」という問題が出てくる。
事前に確認すべきことはこの3つ:
- Smart Assist PC専用のサービスアカウント(ADアカウント)を作成してもらえるか
- そのアカウントのパスワード有効期限ポリシーは?(90日で期限切れだと定期的に通信が止まる)
- 認証除外リスト(IPベースでプロキシ認証をスキップできる設定)は使えるか
一番楽なのは認証除外リスト。Smart Assist PCのIPアドレスを登録してもらえば、認証の問題が丸ごとなくなります。
7.4 SSLインスペクションの影響
SSLインスペクションとは
SSLインスペクション(SSL/TLSインスペクション、HTTPSインスペクション)は、暗号化されたHTTPS通信の中身をファイアウォールやプロキシが復号して検査する機能である。
動作の仕組み
Smart Assistへの影響
| 影響 | 説明 |
|---|---|
| 証明書エラー | Smart Assist PCがFWの証明書を信頼していない場合、通信が失敗する |
| 証明書ピンニング | アプリケーションが特定の証明書を期待している場合、差し替え証明書を拒否する |
| パフォーマンス低下 | 復号・再暗号化の処理負荷により通信速度が低下する可能性がある |
対処方法
| 対処法 | 説明 |
|---|---|
| 除外設定 | SSLインスペクションの対象からSmart Assistの宛先FQDNを除外する |
| CA証明書インストール | FW/Proxyの発行するCA証明書をSmart Assist PCにインストールする |
多くの場合、除外設定が最もシンプルかつ確実な対処法である。
「SSLインスペクションを除外してください」と言うだけだと、病院IT担当者は不安になります。除外申請を出すときは、なぜ除外しても安全なのかを一緒に説明するのがコツ。
申請に含めるべきポイント:
- 除外対象FQDN:
*.arkray-smartassist.comと S3のFQDN(具体的に記載) - 除外の理由: 証明書ピンニングによりインスペクション環境で動作しないため
- 安全性の根拠: 宛先は自社管理のAWS環境のみ、TLS 1.2で暗号化済み、WAFで不正リクエストをフィルタリング済み
「除外しても安全」と言える根拠を3つ以上示すと、だいたい通ります。
7.5 許可申請書の書き方
病院への申請に含めるべき情報
ファイアウォールの許可申請は、病院IT部門が判断に必要な情報を過不足なく含める必要がある。
申請書テンプレート
| 項目 | 内容 |
|---|---|
| 送信元 | 192.168.10.50(Smart Assist PC) |
| 宛先 | smartassist.example.com |
| ポート | 443/tcp(HTTPS) |
| 通信方向 | Outbound Only |
| 暗号化 | TLS 1.2以上 |
- 匿名化された検体ID
- 顕微鏡画像(有形成分)
- 自動分類結果(信頼度スコア)
- 通信はすべてHTTPS(TLS 1.2以上)で暗号化
- 通信の起点は常に院内PC側(Outbound Only)
- クラウドから院内への新規接続は発生しません
- 接続先はAWS上の特定FQDNのみ
- 通信シーケンス図(別紙1)
- セキュリティ設計書(別紙2)
7.6 病院ITへの説明方法
説明の基本原則
| 原則 | 内容 |
|---|---|
| 相手の懸念に先回りする | 聞かれる前にセキュリティ上の懸念点と対策を説明する |
| 技術用語を使いすぎない | 必要な技術用語は使うが、必ず説明を添える |
| 図を使う | 通信フロー、ネットワーク構成は必ず図示する |
| 根拠を示す | 「安全です」ではなく「なぜ安全か」を技術的に説明する |
| 質問を歓迎する | 質問は信頼構築のチャンスと捉える |
説明の流れ(推奨)
| 順番 | 内容 | 目的 |
|---|---|---|
| 1 | Smart Assistの業務上の目的を説明 | なぜこの通信が必要かを理解してもらう |
| 2 | 通信フロー図を示す | 何がどこに流れるかを可視化する |
| 3 | 送信データの内容を明示 | 個人情報が含まれないことを確認してもらう |
| 4 | 通信方向がOutbound Onlyであることを説明 | 最大の懸念に対する回答を提示する |
| 5 | ファイアウォール設定の具体案を提示 | 実装可能な具体案を示す |
| 6 | 障害時の影響範囲を説明 | 最悪の場合でも何が起きるかを明確にする |
| 7 | 質疑応答 | 懸念を丁寧に解消する |
避けるべき説明パターン
| NG例 | 理由 |
|---|---|
| 「クラウドだから安全です」 | 根拠がない |
| 「技術的に問題ありません」 | 相手は技術的な問題だけを心配しているのではない |
| 「他の病院でも問題なく動いています」 | その病院のポリシーが同じとは限らない |
| 「詳しいことは技術担当に聞いてください」 | 信頼を失う |
補足(国際的な文脈): 本章で示した許可申請書テンプレートは日本の病院IT部門向けの標準的な形式である。米国では、ベンダーセキュリティ質問票(SIG: Standardized Information Gathering、CAIQ: Consensus Assessment Initiative Questionnaire)やHIPAA Security Risk Assessmentに基づいた申請プロセスが一般的である。EUでは、GDPR第35条に基づくDPIA(Data Protection Impact Assessment)の実施や、DPO(Data Protection Officer)との協議が必要となるケースが多い。いずれの地域でも「通信フローの可視化」「送信データの明示」「Outbound Onlyの技術的根拠」を示すという本質は同じである。
7.7 資料の読み方:FW許可FQDN一覧(実際の設定値)
資料の概要
ネットワーク説明資料(Network Explanatory Materials)には、ファイアウォールで許可すべき具体的なFQDN/ポートの一覧が記載されている。担当者はこの一覧をもとに、病院IT担当者にFW設定の具体案を提示する。
Smart Assist通信(必須)
| カテゴリ | FQDN | プロトコル | ポート |
|---|---|---|---|
| Smart Assist | *.arkray-smartassist.com | HTTPS | 443 |
| Smart Assist (S3) | remote-us1pdv2-bucket-measure-info.s3.us-east-1.amazonaws.com | HTTPS | 443 |
時刻同期(NTP)
| カテゴリ | FQDN | プロトコル | ポート |
|---|---|---|---|
| NTP | ntp.nict.jp | UDP/TCP | 123 |
| NTP | *.pool.ntp.org | UDP/TCP | 123 |
| NTP | time.windows.com | UDP/TCP | 123 |
セキュリティソフト更新
| カテゴリ | FQDN | プロトコル | ポート |
|---|---|---|---|
| McAfee更新 | update.nai.com | HTTPS | 443 |
| McAfee更新 | download.mcafee.com | HTTPS | 443 |
| McAfee更新 | updates.mcafee.com | HTTPS | 443 |
| McAfee更新 | gti.mcafee.com | HTTPS | 443 |
| McAfee更新 | cloud.gti.mcafee.com | HTTPS | 443 |
| McAfee更新 | crl.trustwave.com | HTTPS | 443 |
Windows Update
| カテゴリ | 主要FQDN(抜粋) | プロトコル | ポート |
|---|---|---|---|
| Windows Update | windowsupdate.microsoft.com | HTTPS | 443 |
| Windows Update | *.windowsupdate.microsoft.com | HTTPS | 443 |
| Windows Update | update.microsoft.com | HTTPS | 443 |
| Windows Update | *.update.microsoft.com | HTTPS | 443 |
| Windows Update | download.microsoft.com | HTTPS | 443 |
| Windows Update | *.download.microsoft.com | HTTPS | 443 |
| Windows Update | dl.delivery.mp.microsoft.com | HTTPS | 443 |
| Windows Update | settings-win.data.microsoft.com | HTTPS | 443 |
注意: Windows Updateの完全なFQDN一覧はネットワーク説明資料を参照すること。上記は主要なものの抜粋である。
VPN接続オプション(Option 2)を使用する場合
VPN接続オプションを選択した場合、Smart Assistant通信用のFQDN許可のみで済む(NTP・McAfee・Windows UpdateはVPN経由となる)。
| カテゴリ | FQDN | プロトコル | ポート |
|---|---|---|---|
| Smart Assist | *.arkray-smartassist.com | HTTPS | 443 |
| Smart Assist (S3) | remote-us1pdv2-bucket-measure-info.s3.us-east-1.amazonaws.com | HTTPS | 443 |
| AWS Client VPN | 設定ファイルにて提供 | — | — |
担当者が注意すべきポイント
- ワイルドカード(*)の許可:
*.arkray-smartassist.comのようなワイルドカード指定は、FW機器によっては対応していない場合がある。その場合は具体的なサブドメインを個別に許可する - S3のFQDN: S3バケットへの直接アクセスURLはリージョン情報を含む長いFQDNとなる。正確にコピーすること
- NTPの重要性: 時刻同期が行えないと、TLS証明書の検証に失敗する可能性がある(第10章の証明書期限切れトラブルシューティング参照)
- 段階的な許可: まずSmart Assist通信(2つ)のみ許可し、通信テスト後にNTP・更新系を追加する方法も有効
*.arkray-smartassist.com のワイルドカード指定がFWで通らないケース、実はそこそこあります。特にPalo AltoやFortiGateの古いファームウェア、またはポリシーでワイルドカードを禁止している病院。
そのときは慌てず、実際に使われているサブドメインを個別に展開して申請しましょう。具体的なサブドメインはネットワーク説明資料(Network Explanatory Materials)に記載されています。まずその資料を確認し、必要なFQDNを個別にリストアップして申請してください。
S3のFQDNも忘れずに。remote-us1pdv2-bucket-measure-info.s3.us-east-1.amazonaws.com は長いので、コピペ必須です(手入力すると100%タイプミスします)。
次章では、Smart Assistのクラウド側基盤であるAWSの基本構造を理解する。