病院情報ネットワーク・ファイアウオールの
基本要件とその実装推奨案

――作業中間報告 (９７年１月)――

国立大学附属病院医療情報処理部門連絡会議
データ保護班

  1. はじめに

病院情報システムが稼動している病院情報ネットワーク（病院内ＬＡＮ）をインターネットと接続して､病院情報システムのユーザーに､インターネット上の情報リソースの利用とコミュニケーション機能を提供したいというニーズが、ここ数年急速に高まってきた。大学病院医療情報ネットワークＵＭＩＮも１９９４年度からインターネット接続によるＵＭＩＮ２システムが稼動している。このような状況から、最近では院内ＬＡＮをインターネットと接続する大学病院が増えつつある。

しかし今さら書くまでもなく、院内ＬＡＮ上ではプライバシー保護を必要とする患者データが交換され日常業務システムが稼動しているので、不特定多数の人間やシステムが利用しているインターネットとの接続にあたっては、十分なセキュリティー対策を必要とする。ところが、このようなセキュリティー対策は、個々の大学病院においてシステム管理に携わる管理者と病院情報システムのベンダーとあいだで妥当と思われるものが設計、構築されるてきており、十分な知識とスキルの持ち合わせていない病院ではインターネットとの接続を躊躇するか、不安の抱えたままベンダー任せの接続システムを導入するほかなかった。

そこで、国立大学附属病院医療情報処理部門連絡会議ではデータ保護班を組織し、院内ＬＡＮとインターネットを接続する上での基本要件を提案することとなった。

  1. データ保護班のメンバー

データ保護班のメンバーは順不同で、大江和彦（東大）、新澤陽英 （山形大）、酒巻哲夫（群馬大）、木内貴弘（東大ＵＭＩＮ）、羽柴正夫（新潟大）、分校久志（金沢大）、山下芳範（福井医大）、杉本喜久（滋賀医大）、今出孝行（大阪大）、栗原幸男（高知医大）、坂本憲広（九州大）、村永文学（鹿児島大）、山本隆一（大阪医大）、広瀬一郎（東大　医事課）の１４名であり、大江が班長である。なお、大阪医大の山本は国立大学医療情報処理部門連絡会議のメンバー大学ではないが、大江の判断でとくにメンバーに加わっていただいた。

３．データ保護班の目標、前提と作業範囲

本作業班の平成８年度の目標は、大学病院の病院情報ネットワークとインターネットを接続する上で必要となるファイアウオールに限定して、その基本要件、およびそれに基づいた実装推奨案を、現状の技術で可能な範囲で具体的に提示することである。提示は「病院情報ネットワーク・ファイアウオールの基本要件とその実装推奨案」として報告書をまとめることにより行う。ファイアウオールの運用方法の推奨案を提示することはファイアウオールが持つべき本来の機能を果たすためには必要不可欠であるが、これは作業班の来年度の目標とし、平成８年度では余裕があれば資料作成を行うにとどめる。

前提として、院内ＬＡＮ上には患者データなど保護されるべきデータが暗号化されない形態でＴＣＰ／ＩＰプロトコルにより交換されており、インターネットからの侵入者がこのデータを破壊、盗聴、改ざんしたり、院内ＬＡＮ上の業務用コンピュータをソフトウエア的に破壊または機能不全に陥れる危険があるものとしている。したがって、院内ＬＡＮ上の守られるべきデータがすべて十分な安全性をもって暗号化されている場合や、ＴＣＰ／ＩＰプロトコルが用いられていない、１社のベンダーに依存した非公開かつベンダー独自プロトコルにより患者情報の交換がおこなわれていてこれらの危険がない、院内ＬＡＮが診療業務システムに用いられておらず研究用ネットワークとして位置づけられている、といった状況は今回の検討作業の対象としない。また、大学病院の院内ＬＡＮとインターネットとを安全に接続するには、いわゆるファイアウオールを構築すること以外に現状では現実的な方法はないという前提で作業をすすめる。

また、病院情報システムがインターネットと接続すべきかどうかといったポリシーに関わる問題が議論の範囲に含めない。

  1. 報告書の位置づけと本中間報告

作業班の成果物である「病院情報ネットワーク・ファイアウオールの基本要件とその実装推奨案」報告書は、病院情報ネットワークをインターネットと接続したいと自らのポリシーにより判断した大学病院が、接続にあたって必要なファイアウオールをどのように構成したらよいかを検討する材料を提供するものである。この推奨案は病院情報ネットワークとインターネットを接続すべきだと主張するものでもないし、接続するにあたってこの推奨案をそのまま採用しなければならないと強制するものでもない。しかし、データ保護班としては、大学病院がファイアウオールを構築する場合には、少なくともこの報告書を熟読し、どのような構成が推奨され、どのような構成は危険と考えているか、またベンダーへの要求仕様書に何を記載すべきかということを理解していただきたいと強く希望している。

実際に個々の大学病院がファイアウオールを構成する際には、個々のネットワーク構成と運用ポリシーの実状にあわせた修正案を策定することになるであろう。

本中間報告書は、上記の成果物である報告書の文字どおり中間報告書であり、データ保護班が現在までに検討した結果、最終的にまとめる報告書に記載されるであろう基本要件と推奨案を、データ保護班のメンバー以外の人に公開して意見を広く聞き、過不足を修正し、推奨案をより優れた内容にするためのものである。特に、本中間報告書の内容に対して、すでにファイアウオールを構築して運用している大学や設計中の大学からの意見を求めたい。

  1. 作業方法

大学病院の院内ＬＡＮとインターネットとを安全に接続するには、いわゆるファイアウオールを構築すること以外に現状では現実的な方法はないという前提にたち、まず作業班大学を担当するベンダー各社にファイアウオールの提案と概算価格見積もりの提出を、作業班大学が分担して依頼した（分担：大阪医大―富士通、九州大学―日本ＩＢＭ、福井医大―住友電工とＤＥＣ、金沢大―ＮＥＣ）。この内容と、ファイアウオール構築に関する技術書の記述を参考にして、基本要件とファイアウオール推奨案のたたき台を作成し、議論した。この過程は、すべてデータ保護班専用のメーリングリスト上で議論することにより行った。

また、作業班大学のファイアウオールやデータ保護対策についての実状を調査するため、栗原（高知医大）がアンケート調査を行い結果をとりまとめた。

  1. 作業班１２大学の調査結果

１２大学中、回答は８大学であった。調査結果の詳細は割愛するが、

  1. 病院ＬＡＮをインターネットを含む外部ＬＡＮと接続しているか？

では、8大学中５大学が接続しており、

２）どのようなハードウエアを介して外部ＬＡＮと接続しているか？

では、6大学中4大学がＵＮＩＸマシンによるゲートウエイであった。

７．ファイアウオールの基本要件
以下ではファイアウオールの内部を内部ネットワーク、インターネットなど不特定多数の利用者がTCP/IPプロトコルで通信する、病院の管理権限の及ばないコンピュータを接続して利用しているネットワーク外部ネットワークを外部ネットワークと呼ぶ。大学の医局研究用ネットワークの位置づけをどのように考えるかはその大学病院のポリシーに依存するが、ここでは研究用ネットワークはインターネットと同等とみなし、外部ネットワークとして扱うことにする。

１）セキュリティー要件

２）サービス要件

３）ロギング機能要件

４）基本要件を実現する上での許容事項

・ファイアウオールを設置することにより、内部ネットワークから外部ネットワーク上のサービスを利用する手順や使い勝手が、ファイアウオールがない場合に比べて異なること。

・ファイアウオールを設置することにより、インターネットＲＦＣ（Request For Comment）で公開されていない標準的でない手順による外部ネットワーク上でのサービスを利用できなくなること。

５）ファイアウオールのアップデートに関する要件

・広くインターネット上で普及している新しい標準的なサービスを内部ユーザーがタイムラグなく利用できるよう、ファイアウオールを常に最新の機能に維持すること。

・セキュリティー要件を脅かすようなファイアウオール上の問題点（ＯＳやアプリケーションプログラムのバグやセキュリティーホールを含む）が発見されたり公開されたりした場合、即時に問題点を改修すること。

  1. 基本要件を満たすファイアウオール設計にあたっての考え方

  1. ファイアウオールの実装推奨案について

ここでは、まず推奨される標準構成を提示してそれを説明し、そのあとで標準構成の一部に安全性を下げることなく変更を加えたバリアント構成を提示する。さらに、標準構成のバリアントであるにもかかわらず安全性が低下するために推奨できない形態を提示する。

９．１ 推奨される標準構成

図１が、データ保護班が推奨するファイアウオールの標準構成である。

セキュリティー要件を実現する装置として、外部ネットワーク側から順に、（Ａ）外部ルータ、（Ｂ）デュアルホーム・ゲートウエイ（ＤＨ−ＧＷ）、（Ｃ）内部ルータから構成される。外部ルータとＤＨ−ＧＷの間にあるセグメントをここでは外側緩衝セグメント、ＤＨ−ＧＷと内部ルータの間にあるセグメントをここでは内部緩衝セグメントと呼ぶことにする。


図１ 推奨される標準構成

それぞれの役割や必要な最低限の設定を順に解説する。

  1. 外部ルータ
    このルータの機能は、外部ネットワークとファイアウオールを構成する機器やネットワーク（ここでは外側緩衝セグメント）とを分離しこれらを保護することである。また同時に、これより内側のファイアウオールの障害によりなんらかの理由で届いてしまった内部ネットワークからの直接のパケットが流出することを防ぐ最後の砦でもある。
    しかし、外部ネットワークは大学キャンパスネットワークのこともあれば、インターネットプロバイダ側のルータである場合もある。このルータの管理は病院側で行えることが望ましいが大学病院と接続先外部ネットワークの管理者との関係によってはそれが不可能な場合もある。
    したがって、ファイアウオール全体としては、このルータのパケットフィルター機能にはそれほど重きをおいていない。
    ファイアウオールを構成する機器と外側緩衝セグメントを、外部ネットワークからなるべく保護するために、可能であればこのルータにはパケットフィルタを設定し、外部ネットワークからＤＨ−ＧＷへのコネクション確立を禁止することが望ましい。
    このルータを通過して外部ネットワークに出て行く外向きパケットは、外部緩衝セグメント上のコンピュータだけであり、それ以外のソースＩＰアドレスを持つパケットの通過は禁止することが望ましい。
  2. 外側緩衝セグメント
    外部ルータは、セキュリティー要件の実現の上では信頼のおける役割を果たしていないので、外側緩衝セグメントはセキュリティー保護上は外部ネットワークと同等程度の危険なセグメントである。
    このセグメント上には、病院が外部ネットワークに向けて一般に提供したい情報サービスのためのサーバ（ＷＷＷ、    anonymousＦＴＰなど）を設置する。また、必要なら内部ネットワークのユーザーのためのNewsサーバを設置し、外部ネットワーク上のNewsサーバからのnewsの配信を受ける。
    さらに、このセグメントには内部ネットワーク上の内部メールサーバあての外部ネットワークからのすべての電子メールを一括して受信し、内部ネットワーク上のメールサーバへメールを転送する役割を持つメールゲートウエイ（図ではメールＧＷ）を設置することが多い。
    そしてこのセグメントには、次項のデュアルホームゲートウエイ（ＤＨ−ＧＷ）が設置される。
    なお、このセグメントはここに記載した目的以外の研究や開発用のコンピュータを接続することや、ファイアウオールの管理者がユーザー管理を厳格にできないような利用者をユーザーアカウントとして登録されているようなコンピュータを接続してはならない。
  3. デュアルホームゲートウエイ（ＤＨ−ＧＷ）
    ＤＨ−ＧＷは、文字どおり２つのネットワークインターフェイスをもち、一方を外側緩衝セグメント、もう一方を内側緩衝セグメントに接続している。
    この２つのネットワークインターフェイス間では直接のパケット交換は行わないように設定し、内部ネットワーク上の利用者が必要なサービスごとに対応したアプリケーションレベルの    ProxyソフトウエアまたはＳＯＣＫＳソフトウエアなどを稼動させる。
    なお、ＤＨ−ＧＷ上でメールＧＷを機能させることは、ＤＨ−ＧＷ自体をなるべく侵入しにくくしたいという観点からすると、推奨できない。
    ＤＨ−ＧＷはふたつのインターフェイスを持ち、すべてのパケットはアプリケーションレベルで交換されるため、ソース・デスティネーションＩＰアドレスの両方が付け替えられることになるため、内側緩衝セグメントと内部ネットワーク上ではプライベートアドレス領域を使用することができる。
    ＤＨ−ＧＷは、安全とは言えない外部緩衝セグメントに直接つながっているので、外部からの非常に攻撃を受けやすい（ねらわれやすい）コンピュータであり、侵入されることを前提に考える必要がある。
  4. 内側緩衝セグメントと内側ルータ
    上記のように、ＤＨ−ＧＷは外部から侵入される可能性が高いコンピュータである。侵入されれば、内側インターフェイス上のデータは盗聴することが可能である。そこで、ＤＨ−ＧＷの内側インターフェイスは、患者情報などが流れる内部ネットワークには直接接続せず、患者情報が流れいないセグメントを作成し、それに接続するようにする。この目的で作成されたセグメントが内側緩衝セグメントであり、これと内部ネットワークを隔てるのが内側ルータである。
    内側緩衝セグメントには、ＤＨ−ＧＷと専用ルータ（内側ルータも専用ルータ）以外の機器を一切接続しないことが強く推奨される。バリアントを考える場合にも、ＤＨ−ＧＷの内側インターフェイス上には患者情報やパスワード情報が流れないセグメントになるよう留意する必要がある。
    内側ルータは、内部ネットワークとＤＨ−ＧＷ間のパケット以外は通過しないようにパケットフィルターを設定し、静的ルーティングの設定により内部ネットワークのルーティング情報が内側緩衝セグメントに流れないようにする。

なお、この標準構成において、ＤＨ−ＧＷの役割をＩＰアドレスの付け替えだけ行い、各種サービスのためのアプリケーションゲートウエイ機能は、外部緩衝セグメント上のマシンで別に提供するという方法も考えられ、推奨案に含められる。


  1. ２ 推奨される基本構成のうち推奨可能なバリアント



図２ 標準構成のバリアント

標準構成のバリアントとして、図２の構成も推奨する。この構成が標準案と異なるのは、２つのネットワークインターフェイスを持つデュアルホームゲートウエイを設置しないで、外部緩衝セグメントに相当するセグメントにネットワークインターフェイスをひとつだけ持つゲートウエイマシン（図２ではAppli.Level.GW）を設置し、これにＤＨ−ＧＷが持っていたアプリケーションゲートウエイの機能を持たせることにある。
この案でも、内部ルータは内部ネットワークとAppli.Level.GWとの間でのみパケット交換を行うように設定する。これにより内部からのすべての外部向けパケットは、一旦Appli.Level.GWで受け、アドレスが付け替えられて、外部ルータ経由で外部ネットワークへ出て行く。当然、静的ルーティングの設定により内部ネットワークのルーティング情報が緩衝セグメントに流れないようにする。

９．３ 標準構成の推奨できないバリアント

図３は、９．１で説明した推奨される標準構成のうち、内部ルータを省略した構成である。この構成は、9.1の（４）で説明したように、もっともねらわれやすいデュアルホームゲートウエイに侵略されてしまうと、それより内側に何ら防御機構がないため、危険である。したがって、図３のように内部ルータを省略する案は推奨できない。

図３. 推奨できないバリアント

  1. ４ 標準構成から派生するさまざまなバリアント
    バリアントを網羅して提示することは不可能であるが、9.1〜9.3での説明を理解すれば、何が推奨され、何が推奨されないかを把握できるであろう。ファイアウオールの構成として9.1または9.2で提示した構成の基本骨格を崩さずに、ルータやデュアルホームゲートウエイの多段構成にすれば、より強固なファイアウオールになる。一方で内部ネットワークのユーザから外部ネットワークを利用する手順が複雑になるというデメリットと、複雑な構成のファイアウオールは管理が複雑になる結果として全体のセキュリティーレベルを低下させかねない管理ミスが発生する可能性があることを留意する必要がある。

１０．ベンダー各社の提案と推奨案との関係

全5社のうち1社は3種類の提案をしたので、合計7種類のファイアウオールシステムが提案された。名称は、Digital FireWall （DEC）、Gauntlet（住友電工）、FireWall-1（富士通）、Safegate（富士通）、Borderware（富士通）、Goahセキュリティーサーバー（NEC）、Internet Connection Secure Network Gateway（日本ＩＢＭ）である。これらの名称はベンダーによって、ルータを含めたファイアウオールシステムとしての名称の場合もあれば、ファイアウオールを構成する上で中核機能を提供するデュアルホームゲートウエイとその上で動作するソフトウエアシステムの名称である場合もある。
後者の場合も、ベンダーはそれを用いたファイアウオールシステムの構成を案として提示している。結論からいうと、７製品ともにデュアルホームゲートウエイを採択しており、Decと住友電工は9.1で示した推奨案を提示してきたのに対して、それ以外のベンダーは9.3で示した「内部ルータのない案」、つまり推奨しない案を提示してきた。

各ベンダーともに、用意しているデュアルホームゲートウエイシステム自体の機能にとりあてて問題はなく、単に内部ルータをいれた内側緩衝セグメントの導入を行っていないだけであるので、どのベンダーでも容易に9.1で示した推奨案を実現できるものと思われた。

１１． おわりに

この中間報告書について、質問、コメント、追加修正すべき点などがありましたら、データ保護班班長（下記）まで、必ずご自分の所属と氏名、電子メールアドレス、

ＦＡＸ番号を明記の上でお寄せください。

連絡先： 東大病院中央医療情報部 大江和彦

kohe@hcc.h.u-tokyo.ac.jp

FAX: 03-3813-7238

参考書

D. Brent Chapman, Elizabeth D. Zwicky: 歌代和正監訳,鈴木克彦訳「ファイアウオール構築 インターネットセキュリティー」, オライリージャパン, 1996