Smart Assist ネットワーク技術者育成テキスト
EN

第7章 ファイアウォール設計実務

Palo Alto Networks

Palo Alto Networks(代表的な次世代FWベンダー)

Fortinet

Fortinet(FortiGate)

Cisco ASA 5510 ファイアウォール

ファイアウォール装置の例(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変更
IP許可の場合の問題 FW許可: 宛先 52.194.10.20 OK AWS IP変更: 52.194.10.20 → 52.194.10.21 FW許可: 宛先 52.194.10.21 許可なし → 通信断 FQDN許可の場合 FW許可: 宛先 smartassist.example.com DNS解決結果のIPを自動許可 AWS IP変更: DNS応答が変わる FWが自動追従 通信継続 FQDN許可ならIPが変わっても自動で追従 → 通信が途切れない

FQDN許可が使えない場合

古いファイアウォール機器ではFQDN許可に対応していない場合がある。その場合の対処法を以下に示す。

対処法説明
IPレンジで許可AWSのIPレンジ(公開情報)を使用して広めに許可する
定期的なIP確認FQDNのIPアドレスを定期的に確認し、変更があればFWルールを更新する
プロキシ経由プロキシサーバでFQDN制御を行い、FWではプロキシのみ許可する
古いFWでFQDNが使えないときの現実的な対処法

実はこれ、現場ではけっこう多いんですよね。「FQDNベースの許可ルール」が使えない古いFW(Cisco ASA 5500シリーズの旧ファームとか)に当たることがある。そのとき焦らないで。

一番現実的なのはプロキシ経由に切り替える方法。FW側はプロキシサーバのIPだけ許可して、FQDN制御はプロキシに任せる。プロキシがない場合は、nslookup で現在のIPを確認して申請しつつ、「IPが変わる可能性がある」ことを病院IT担当者に伝えておくのがポイント。黙ってると、IP変更時に突然通信が止まって大騒ぎになります。


7.2 ポート開放の考え方

最小権限の原則

ファイアウォールのポート開放は、必要最小限の通信のみを許可する原則に基づいて設計する。

Smart Assistに必要なポート

プロトコルポート方向用途
TCP443OutboundHTTPS通信(データ送受信)
UDP53OutboundDNS名前解決(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サイトにアクセス可能になる
送信元: ANYSmart Assist PC以外からも通信できてしまう
"とりあえず全開けで試しましょう"は絶対にやるな

病院IT担当者に「まず全開けで接続テストして、あとで絞りましょう」と提案したくなる気持ち、分かります。でもこれ、絶対にやっちゃダメ

理由は2つ。まず、セキュリティレビューを通過した後の病院で「一時的にでも全開け」は信頼を失います。次に、「あとで絞る」が実行されないまま本番稼働に入るリスクが高い。一度開けた穴を閉じるのは、最初からちゃんと設定するよりはるかに難しいんです。

最初から最小権限で設定して、通らなかったらトラブルシューティングで原因を特定する。この順番を守ること。


7.3 プロキシ環境での注意点

プロキシ経由の通信構成

プロキシ環境では、Smart Assist PCはファイアウォールではなくプロキシサーバを経由して通信する。

直接通信の場合 Smart Assist PC ファイアウォール AWS プロキシ経由の場合 Smart Assist PC プロキシサーバ ファイアウォール AWS

プロキシ環境で必要な設定

設定箇所設定内容
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通信の中身をファイアウォールやプロキシが復号して検査する機能である。

動作の仕組み

SSLインスペクションなし PC TLS(AWSの証明書) AWS ※ PCはAWSのサーバ証明書を直接検証する SSLインスペクションあり PC TLS(FW証明書) FW / Proxy TLS(AWS証明書) AWS ※ PCが受け取る証明書はFW/Proxyが発行した「差し替え証明書」

Smart Assistへの影響

影響説明
証明書エラーSmart Assist PCがFWの証明書を信頼していない場合、通信が失敗する
証明書ピンニングアプリケーションが特定の証明書を期待している場合、差し替え証明書を拒否する
パフォーマンス低下復号・再暗号化の処理負荷により通信速度が低下する可能性がある

対処方法

対処法説明
除外設定SSLインスペクションの対象からSmart Assistの宛先FQDNを除外する
CA証明書インストールFW/Proxyの発行するCA証明書をSmart Assist PCにインストールする

多くの場合、除外設定が最もシンプルかつ確実な対処法である。

SSLインスペクション除外申請の書き方

「SSLインスペクションを除外してください」と言うだけだと、病院IT担当者は不安になります。除外申請を出すときは、なぜ除外しても安全なのかを一緒に説明するのがコツ。

申請に含めるべきポイント:

  • 除外対象FQDN: *.arkray-smartassist.com と S3のFQDN(具体的に記載)
  • 除外の理由: 証明書ピンニングによりインスペクション環境で動作しないため
  • 安全性の根拠: 宛先は自社管理のAWS環境のみ、TLS 1.2で暗号化済み、WAFで不正リクエストをフィルタリング済み

「除外しても安全」と言える根拠を3つ以上示すと、だいたい通ります。


7.5 許可申請書の書き方

病院への申請に含めるべき情報

ファイアウォールの許可申請は、病院IT部門が判断に必要な情報を過不足なく含める必要がある。

申請書テンプレート

ファイアウォール許可申請書
申請日
YYYY-MM-DD
申請者
[組織名] [部署名] [担当者名]
対象システム
システム名: Smart Assist
用途: 尿沈渣画像の遠隔分類支援
通信要件
項目内容
送信元192.168.10.50(Smart Assist PC)
宛先smartassist.example.com
ポート443/tcp(HTTPS)
通信方向Outbound Only
暗号化TLS 1.2以上
送信データの内容
  • 匿名化された検体ID
  • 顕微鏡画像(有形成分)
  • 自動分類結果(信頼度スコア)
※ 患者氏名、生年月日等の個人識別情報(PII/PHI)は含まれません
通信の安全性
  • 通信はすべてHTTPS(TLS 1.2以上)で暗号化
  • 通信の起点は常に院内PC側(Outbound Only)
  • クラウドから院内への新規接続は発生しません
  • 接続先はAWS上の特定FQDNのみ
補足資料
  • 通信シーケンス図(別紙1)
  • セキュリティ設計書(別紙2)

7.6 病院ITへの説明方法

説明の基本原則

原則内容
相手の懸念に先回りする聞かれる前にセキュリティ上の懸念点と対策を説明する
技術用語を使いすぎない必要な技術用語は使うが、必ず説明を添える
図を使う通信フロー、ネットワーク構成は必ず図示する
根拠を示す「安全です」ではなく「なぜ安全か」を技術的に説明する
質問を歓迎する質問は信頼構築のチャンスと捉える

説明の流れ(推奨)

順番内容目的
1Smart 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.comHTTPS443
Smart Assist (S3)remote-us1pdv2-bucket-measure-info.s3.us-east-1.amazonaws.comHTTPS443

時刻同期(NTP)

カテゴリFQDNプロトコルポート
NTPntp.nict.jpUDP/TCP123
NTP*.pool.ntp.orgUDP/TCP123
NTPtime.windows.comUDP/TCP123

セキュリティソフト更新

カテゴリFQDNプロトコルポート
McAfee更新update.nai.comHTTPS443
McAfee更新download.mcafee.comHTTPS443
McAfee更新updates.mcafee.comHTTPS443
McAfee更新gti.mcafee.comHTTPS443
McAfee更新cloud.gti.mcafee.comHTTPS443
McAfee更新crl.trustwave.comHTTPS443

Windows Update

カテゴリ主要FQDN(抜粋)プロトコルポート
Windows Updatewindowsupdate.microsoft.comHTTPS443
Windows Update*.windowsupdate.microsoft.comHTTPS443
Windows Updateupdate.microsoft.comHTTPS443
Windows Update*.update.microsoft.comHTTPS443
Windows Updatedownload.microsoft.comHTTPS443
Windows Update*.download.microsoft.comHTTPS443
Windows Updatedl.delivery.mp.microsoft.comHTTPS443
Windows Updatesettings-win.data.microsoft.comHTTPS443

注意: Windows Updateの完全なFQDN一覧はネットワーク説明資料を参照すること。上記は主要なものの抜粋である。

VPN接続オプション(Option 2)を使用する場合

VPN接続オプションを選択した場合、Smart Assistant通信用のFQDN許可のみで済む(NTP・McAfee・Windows UpdateはVPN経由となる)。

カテゴリFQDNプロトコルポート
Smart Assist*.arkray-smartassist.comHTTPS443
Smart Assist (S3)remote-us1pdv2-bucket-measure-info.s3.us-east-1.amazonaws.comHTTPS443
AWS Client VPN設定ファイルにて提供

担当者が注意すべきポイント

  1. ワイルドカード(*)の許可: *.arkray-smartassist.com のようなワイルドカード指定は、FW機器によっては対応していない場合がある。その場合は具体的なサブドメインを個別に許可する
  2. S3のFQDN: S3バケットへの直接アクセスURLはリージョン情報を含む長いFQDNとなる。正確にコピーすること
  3. NTPの重要性: 時刻同期が行えないと、TLS証明書の検証に失敗する可能性がある(第10章の証明書期限切れトラブルシューティング参照)
  4. 段階的な許可: まずSmart Assist通信(2つ)のみ許可し、通信テスト後にNTP・更新系を追加する方法も有効
ワイルドカードFQDNが通らないときの個別展開

*.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の基本構造を理解する。