国立大学附属病院医療情報処理部門連絡会議
データ保護班
病院情報システムが稼動している病院情報ネットワーク(病院内LAN)をインターネットと接続して、病院情報システムのユーザーに、インターネット上の情報リソースの利用とコミュニケーション機能を提供したいというニーズが、ここ数年急速に高まってきた。大学病院医療情報ネットワークUMINも1994年度からインターネット接続によるUMIN2システムが稼動している。このような状況から、最近では院内LANをインターネットと接続する大学病院が増えつつある。
しかし今さら書くまでもなく、院内LAN上ではプライバシー保護を必要とする患者データが交換され日常業務システムが稼動しているので、不特定多数の人間やシステムが利用しているインターネットとの接続にあたっては、十分なセキュリティー対策を必要とする。ところが、このようなセキュリティー対策は、個々の大学病院においてシステム管理に携わる管理者と病院情報システムのベンダーとあいだで妥当と思われるものが設計、構築されるてきており、十分な知識とスキルの持ち合わせていない病院ではインターネットとの接続を躊躇するか、不安の抱えたままベンダー任せの接続システムを導入するほかなかった。
そこで、国立大学附属病院医療情報処理部門連絡会議ではデータ保護班を組織し、院内LANとインターネットを接続する上での基本要件を提案することとなった。
データ保護班のメンバーは順不同で、大江和彦(東大)、新澤陽英
(山形大)、酒巻哲夫(群馬大)、木内貴弘(東大UMIN)、羽柴正夫(新潟大)、分校久志(金沢大)、山下芳範(福井医大)、杉本喜久(滋賀医大)、今出孝行(大阪大)、栗原幸男(高知医大)、坂本憲広(九州大)、村永文学(鹿児島大)、山本隆一(大阪医大)、広瀬一郎(東大 医事課)の14名であり、大江が班長である。なお、大阪医大の山本は国立大学医療情報処理部門連絡会議のメンバー大学ではないが、大江の判断でとくにメンバーに加わっていただいた。
3.データ保護班の目標、前提と作業範囲
本作業班の平成8年度の目標は、大学病院の病院情報ネットワークとインターネットを接続する上で必要となるファイアウオールに限定して、その基本要件、およびそれに基づいた実装推奨案を、現状の技術で可能な範囲で具体的に提示することである。提示は「病院情報ネットワーク・ファイアウオールの基本要件とその実装推奨案」として報告書をまとめることにより行う。ファイアウオールの運用方法の推奨案を提示することはファイアウオールが持つべき本来の機能を果たすためには必要不可欠であるが、これは作業班の来年度の目標とし、平成8年度では余裕があれば資料作成を行うにとどめる。
前提として、院内LAN上には患者データなど保護されるべきデータが暗号化されない形態でTCP/IPプロトコルにより交換されており、インターネットからの侵入者がこのデータを破壊、盗聴、改ざんしたり、院内LAN上の業務用コンピュータをソフトウエア的に破壊または機能不全に陥れる危険があるものとしている。したがって、院内LAN上の守られるべきデータがすべて十分な安全性をもって暗号化されている場合や、TCP/IPプロトコルが用いられていない、1社のベンダーに依存した非公開かつベンダー独自プロトコルにより患者情報の交換がおこなわれていてこれらの危険がない、院内LANが診療業務システムに用いられておらず研究用ネットワークとして位置づけられている、といった状況は今回の検討作業の対象としない。また、大学病院の院内LANとインターネットとを安全に接続するには、いわゆるファイアウオールを構築すること以外に現状では現実的な方法はないという前提で作業をすすめる。
また、病院情報システムがインターネットと接続すべきかどうかといったポリシーに関わる問題が議論の範囲に含めない。
作業班の成果物である「病院情報ネットワーク・ファイアウオールの基本要件とその実装推奨案」報告書は、病院情報ネットワークをインターネットと接続したいと自らのポリシーにより判断した大学病院が、接続にあたって必要なファイアウオールをどのように構成したらよいかを検討する材料を提供するものである。この推奨案は病院情報ネットワークとインターネットを接続すべきだと主張するものでもないし、接続するにあたってこの推奨案をそのまま採用しなければならないと強制するものでもない。しかし、データ保護班としては、大学病院がファイアウオールを構築する場合には、少なくともこの報告書を熟読し、どのような構成が推奨され、どのような構成は危険と考えているか、またベンダーへの要求仕様書に何を記載すべきかということを理解していただきたいと強く希望している。
実際に個々の大学病院がファイアウオールを構成する際には、個々のネットワーク構成と運用ポリシーの実状にあわせた修正案を策定することになるであろう。
本中間報告書は、上記の成果物である報告書の文字どおり中間報告書であり、データ保護班が現在までに検討した結果、最終的にまとめる報告書に記載されるであろう基本要件と推奨案を、データ保護班のメンバー以外の人に公開して意見を広く聞き、過不足を修正し、推奨案をより優れた内容にするためのものである。特に、本中間報告書の内容に対して、すでにファイアウオールを構築して運用している大学や設計中の大学からの意見を求めたい。
大学病院の院内LANとインターネットとを安全に接続するには、いわゆるファイアウオールを構築すること以外に現状では現実的な方法はないという前提にたち、まず作業班大学を担当するベンダー各社にファイアウオールの提案と概算価格見積もりの提出を、作業班大学が分担して依頼した(分担:大阪医大―富士通、九州大学―日本IBM、福井医大―住友電工とDEC、金沢大―NEC)。この内容と、ファイアウオール構築に関する技術書の記述を参考にして、基本要件とファイアウオール推奨案のたたき台を作成し、議論した。この過程は、すべてデータ保護班専用のメーリングリスト上で議論することにより行った。
また、作業班大学のファイアウオールやデータ保護対策についての実状を調査するため、栗原(高知医大)がアンケート調査を行い結果をとりまとめた。
12大学中、回答は8大学であった。調査結果の詳細は割愛するが、
では、8大学中5大学が接続しており、
2)どのようなハードウエアを介して外部LANと接続しているか?
では、6大学中4大学がUNIXマシンによるゲートウエイであった。
7.ファイアウオールの基本要件
以下ではファイアウオールの内部を内部ネットワーク、インターネットなど不特定多数の利用者がTCP/IPプロトコルで通信する、病院の管理権限の及ばないコンピュータを接続して利用しているネットワーク外部ネットワークを外部ネットワークと呼ぶ。大学の医局研究用ネットワークの位置づけをどのように考えるかはその大学病院のポリシーに依存するが、ここでは研究用ネットワークはインターネットと同等とみなし、外部ネットワークとして扱うことにする。
1)セキュリティー要件
2)サービス要件
3)ロギング機能要件
4)基本要件を実現する上での許容事項
・ファイアウオールを設置することにより、内部ネットワークから外部ネットワーク上のサービスを利用する手順や使い勝手が、ファイアウオールがない場合に比べて異なること。
・ファイアウオールを設置することにより、インターネットRFC(Request
For Comment)で公開されていない標準的でない手順による外部ネットワーク上でのサービスを利用できなくなること。
5)ファイアウオールのアップデートに関する要件
・広くインターネット上で普及している新しい標準的なサービスを内部ユーザーがタイムラグなく利用できるよう、ファイアウオールを常に最新の機能に維持すること。
・セキュリティー要件を脅かすようなファイアウオール上の問題点(OSやアプリケーションプログラムのバグやセキュリティーホールを含む)が発見されたり公開されたりした場合、即時に問題点を改修すること。
ここでは、まず推奨される標準構成を提示してそれを説明し、そのあとで標準構成の一部に安全性を下げることなく変更を加えたバリアント構成を提示する。さらに、標準構成のバリアントであるにもかかわらず安全性が低下するために推奨できない形態を提示する。
9.1 推奨される標準構成
図1が、データ保護班が推奨するファイアウオールの標準構成である。
セキュリティー要件を実現する装置として、外部ネットワーク側から順に、(A)外部ルータ、(B)デュアルホーム・ゲートウエイ(DH−GW)、(C)内部ルータから構成される。外部ルータとDH−GWの間にあるセグメントをここでは外側緩衝セグメント、DH−GWと内部ルータの間にあるセグメントをここでは内部緩衝セグメントと呼ぶことにする。
図1
推奨される標準構成
それぞれの役割や必要な最低限の設定を順に解説する。
なお、この標準構成において、DH−GWの役割をIPアドレスの付け替えだけ行い、各種サービスのためのアプリケーションゲートウエイ機能は、外部緩衝セグメント上のマシンで別に提供するという方法も考えられ、推奨案に含められる。
図2
標準構成のバリアント
標準構成のバリアントとして、図2の構成も推奨する。この構成が標準案と異なるのは、2つのネットワークインターフェイスを持つデュアルホームゲートウエイを設置しないで、外部緩衝セグメントに相当するセグメントにネットワークインターフェイスをひとつだけ持つゲートウエイマシン(図2ではAppli.Level.GW)を設置し、これにDH−GWが持っていたアプリケーションゲートウエイの機能を持たせることにある。
この案でも、内部ルータは内部ネットワークとAppli.Level.GWとの間でのみパケット交換を行うように設定する。これにより内部からのすべての外部向けパケットは、一旦Appli.Level.GWで受け、アドレスが付け替えられて、外部ルータ経由で外部ネットワークへ出て行く。当然、静的ルーティングの設定により内部ネットワークのルーティング情報が緩衝セグメントに流れないようにする。
9.3 標準構成の推奨できないバリアント
図3は、9.1で説明した推奨される標準構成のうち、内部ルータを省略した構成である。この構成は、9.1の(4)で説明したように、もっともねらわれやすいデュアルホームゲートウエイに侵略されてしまうと、それより内側に何ら防御機構がないため、危険である。したがって、図3のように内部ルータを省略する案は推奨できない。
図3.
推奨できないバリアント
10.ベンダー各社の提案と推奨案との関係
全5社のうち1社は3種類の提案をしたので、合計7種類のファイアウオールシステムが提案された。名称は、Digital
FireWall (DEC)、Gauntlet(住友電工)、FireWall-1(富士通)、Safegate(富士通)、Borderware(富士通)、Goahセキュリティーサーバー(NEC)、Internet
Connection Secure Network Gateway(日本IBM)である。これらの名称はベンダーによって、ルータを含めたファイアウオールシステムとしての名称の場合もあれば、ファイアウオールを構成する上で中核機能を提供するデュアルホームゲートウエイとその上で動作するソフトウエアシステムの名称である場合もある。
後者の場合も、ベンダーはそれを用いたファイアウオールシステムの構成を案として提示している。結論からいうと、7製品ともにデュアルホームゲートウエイを採択しており、Decと住友電工は9.1で示した推奨案を提示してきたのに対して、それ以外のベンダーは9.3で示した「内部ルータのない案」、つまり推奨しない案を提示してきた。
各ベンダーともに、用意しているデュアルホームゲートウエイシステム自体の機能にとりあてて問題はなく、単に内部ルータをいれた内側緩衝セグメントの導入を行っていないだけであるので、どのベンダーでも容易に9.1で示した推奨案を実現できるものと思われた。
11. おわりに
この中間報告書について、質問、コメント、追加修正すべき点などがありましたら、データ保護班班長(下記)まで、必ずご自分の所属と氏名、電子メールアドレス、
FAX番号を明記の上でお寄せください。
連絡先: 東大病院中央医療情報部 大江和彦
FAX: 03-3813-7238
参考書
D. Brent Chapman, Elizabeth D. Zwicky: 歌代和正監訳,鈴木克彦訳「ファイアウオール構築
インターネットセキュリティー」,
オライリージャパン,
1996