System iを強固にする:ファイヤーウォール親和性の高いVPN

eビジネスに対する要望が高まるにつれて、それに付随するデータ・セキュリティに対する要件を避けて通ることはできません。IPセキュリティ・アーキテクチャに基づく仮想プライベート・ネットワーク(IPsec VPN: Virtual Private Network with IP Security Architecture)は、エンド・ツー・エンドの暗号化機能や認証機能をIPレイヤーで提供し、必ずしも信用できないネットワーク上を流れる機密データを保護することでこうした要件に応えるものです。IPsecにはサポート範囲が広いこと、きめ細かな保護設定を俊敏に変えられることなどの利点がありますが、一方ではIPsec VPNとファイヤーウォールが使用するネットワーク・アドレス変換(NAT: Network Address Translation)との間に互換性がないという問題があります。 IPsec VPNがeビジネスの世界で広く使用されるようになるためには、こうした非互換性の問題を解決する必要があります。その解決策の1つがファイヤーウォール親和性の高いVPNです。V5R4では、System iはNATを通過するVPN接続のクライアントにもサーバーにもなることができます。ファイヤーウォール親和性の高いVPN は無数のeビジネスのシナリオに恩恵をもたらすことができます。たとえば、銀行のお客様にオンラインの預金取引明細書を発行したり、保険会社の販売代理支店がインターネット経由で保険請求を安全に申請できるようにしたり、System iをご利用のお客様がIBM RETAINサーバーからドキュメントをダウンロードできるようにしたり、などといったようにです。

仮想プライベート・ネットワークとは?

仮想プライベート・ネットワーク(VPN: Virtual Private Network)は公衆の遠隔通信インフラストラクチャ(そのほとんどの場合インターネット)を利用してトンネリング・プロトコルを使用することでデータのセキュリティを維持します。VPNは共用の公衆インフラストラクチャを使用してプライベートなネットワークと同じネットワーク機能を格段に安いコストでユーザーに提供するものです。VPNの実際の実装形態にはいろいろあり、IPsec、レイヤー2トンネリング・プロトコル(L2TP: Layer 2 Tunneling Protocol)、SSLなどがあります。こうしたテクノロジーの中で、IPsec VPNが最も成熟して広く使用されているテクノロジーです。

インターネット・プロトコルのセキュリティ

IPsecのセキュリティ機能は2つのプロトコルで成り立っています。認証ヘッダー(AH: Authentication Header)と暗号化保全ペイロード(ESP: Encapsulating Security Payload)です。AHは、送信元から送られた各データグラムを検証し、そのデータグラムのコンテンツが転送途中で改変されていないことを検証することでデータの認証と完全性を提供します。ESPは、暗号化機能を使用してメッセージのコンテンツを隠蔽することで機密保持を提供します。またESPはオプションで認証も提供しています(図1)。

AHとESPは送信側と受信側がともに完全性チェック値(ICV: Integrity Checking Value)を計算するときに認証が行なわれます。ICVはハッシュ・アルゴリズム(たとえば、メッセージ・ダイジェスト・アルゴリズム バージョン5 - MD5 -やセキュア・ハッシュ・アルゴリズム - SHA- など)を使用してIPパケットからフィールドを取得します。万が一パケットが転送中に改変された場合、受信側で計算されたICVが送信側で計算されたICVと異なるので、そのパケットは破棄しなければなりません。データの発生元の認証を確実にするには、送信側と受信側の両方に認証用に使用するアルゴリズム中に共用の秘密鍵を持ちます。

ESPは送信側と受信側で共用鍵を使用してやり取りするデータを暗号化および復号化することによりデータの完全性を保っています。転送されるデータは暗号化されているため、万が一パケットが途中で盗用されてもこの共用鍵がなければ中の重要な情報を取り出すことはできません。

インターネット鍵交換プロトコル

公衆ネットワーク上でデータを安全に送信する前に、VPNクライアントとVPNサーバーはデータをどのように保護するのかについて合意しておく必要があります。たとえば、認証アルゴリズム、暗号化アルゴリズム、鍵の更新間隔などといったものです。この合意は手操作によるポリシーでもインターネット鍵交換(IKE: Internet Key Exchange)プロトコルを使用した動的な交渉でも構いません。IKEはVPNクライアントとVPNサーバーとの間のメッセージ交換メカニズムを定義します。VPNサーバーは鍵の交渉が成功するたびに接続を保護するための鍵を再生成し、攻撃者が接続状態から情報を取得しようとするのを困難にします。

ネットワーク・アドレス変換

NATはIPアドレスのある集合を別のIPアドレスの集合に変換します。NATテクノロジーが採用されている典型的な例はマスカレードNAT(別名ポート・アドレス変換 － PAT － またはネットワーク・アドレス・ポート変換 ― NAPT ―ともいう)です。マスカレードNATは複数のIPアドレスを1つのIPアドレスに変換します(図2)。NATはプライベートなIPアドレスを公衆のIPアドレスの背後に隠すことでセキュリティ機能を提供しています。マスカレードNATはIPアドレスの枯渇を軽減させる一助ともなっています。

NATを破壊するIPsec

IPsec VPNとNATは異なる観点からセキュリティ機能を提供していますが、ネットワーク・インフラストラクチャの中で互いに併用することができるのでしょうか。残念なことにこの2つのテクノロジーの間には非互換性があって互いに併用することができません。

IKEアドレス識別子とNATとの間に存在する非互換性

送信側も受信側もIKEネゴシエーション中に自分自身を識別します。受信側はパケットの送信元IPアドレスと送信元が主張している身分とが一致するかどうかをチェックします。一致しない場合は、そのパケットの受信を拒否します。NAT機器がパケットのIPアドレスを変更するので、ネットワークの経路上にNAT機器が存在していることを相手側が認識していない場合、IKEネゴシエーションは完了しません。

TCPパケットが暗号化されているとトンラスポート用のポートをNAT中で変更できない

送信側も受信側もIKEネゴシエーション中に自分自身を識別します。受信側はパケットの送信元IPアドレスと送信元が主張している身分とが一致するかどうかをチェックします。一致しない場合は、そのパケットの受信を拒否します。NAT機器がパケットのIPアドレスを変更するので、ネットワークの経路上にNAT機器が存在していることを相手側が認識していない場合、IKEネゴシエーションは完了しません。

NATはIPアドレスが修正されないように保護するプロトコルを破壊する

IPsecのテクノロジーは認証および完全性チェックの機能を使用してパケットの改ざんを防ぎます。しかしその一方、NAT機器はパケットのIPアドレスを転送中に修正します。そういう設計になっているからです。したがってNATは、前述の通りデータグラムのコンテンツが転送中に変更されていないことを検証する認証機能であるAHでのICV計算を不可能にしています。ESPにも同様の問題が存在しうるのではないかと疑問をお持ちでしょう。ESPは修正されたIPアドレスを含んだIPヘッダーを認証する必要はないのです。ただし、TCP/UDPヘッダー中のポート番号情報は認証に必要なICVの一部です。したがってマスカレードNATを使用している場合、ESP認証が失敗します。さらに、NATはIPチェックサムとTCPチェックサムの両方を破壊する場合があります。

以上に述べた互換性の問題を解消しNATとIPsecの共存させるための解決策は2つのインターネット標準を使用してファイヤーウォール親和性の高いVPNを構築することです。

ファイヤーウォール親和性の高いVPNのためのフレームワーク

インターネット・エンジニアリング・タスクフォース(IETF: Internet Engineering Task Force - ietf.org)はIPsec VPNとNATの非互換性への対応として2つの標準を設計しました。1つはIKEネゴシエーション用のNATトラバーサル(RFC 3947)で、もう1つはESPパケットのUDPカプセル化(RFC 3948)です。

簡潔に言うと、NATトラバーサルはVPN接続中にあるNAT機器の存在とその位置をどのように検知するかをIKEに対して伝えます。NATが検知された場合、IKEはポート500からポート4500へ流れIKEネゴシエーションを完了します。またIKEはトンネルにおけるハートビートのような賦活パケットも送信します。

IPsecパケットは新しいIP/UDPヘッダーの中に包み隠された後、UDPカプセル化と呼ばれるプロセスでUDPポート4500上で送信されます。新しいIPヘッダー中のアドレスはNAT機器を通過する際に変換されます。新しいUDPポートはマスカレードNAT用に使用されます。パケットが送信先に到達すると、受信側はUDPヘッダーを取り除き、元のIPsecパケットを復号化します。

前節で説明した解決策はトンネル・モードまたはトランスポート・モードのいずれかのESPパケットにのみ適用できます。AHはNATとの間で非互換性の問題があり、上記の2つの標準ではこの問題は解消されません。トンネル・モードとトランスポート・モードでUDPカプセル化されたESPパケットのフォーマットを図3に示します。UDPカプセル化の送受信の流れを図4に示します。

V5R4のファイヤーウォール親和性の高いVPN

i5/OSのファイヤーウォール親和性の高い新しいVPNはIETFのRFC 3947およびRFC 3948の両標準に準拠しています。ファイヤーウォール親和性の高いVPNのフレームワークはIPsecパケットがファイヤーウォールをどのように通過するのかに関する一般的なプロセスについての標準によって規定されています。V5R4のファイヤーウォール親和性の高いVPNはクライアントとサーバーの両方をフルにサポートしています。またi5はIETFの標準に準拠しているだけでなく、IETFからローカル実装で解決するように残されているサーバー側の技術的課題もいくつか上手く解決しています。これについてもう少し詳しく見てみましょう。

複数のクライアントがサーバーに対して同時にデータを送信する可能性があり、ファイヤーウォールの後ろ側に隠れているクライアントはIPアドレスが重複する可能性があるので競合が発生する場合があります。複雑なネットワーク環境ではIPアドレスやポートが重複していることで発生する競合は複数の送信元で発生します。図5に示した通り、ファイヤーウォールN1とN2の後ろにあるローカル・ゲートウェイ(GW1とGW3)は重複したIPアドレスを持っているかもしれません。異なるゲートウェイの後ろにあるクライアントもIPアドレスが重複している可能性があります。

着信パケットがサーバーに到達すると、処理後にパケットの身分証明の一部が取り除かれます。着信パケットがサーバーに到達した後、送信側のIPと送信側のポート(つまりUDPカプセル化ヘッダーからのUDP送信元ポート)、NATの背後にあるクライアントの重要な識別子がUDPの非カプセル化処理中に取り除かれます。トンネル・モードを使用した暗号化の場合、ゲートウェイ情報は復号化中に取り除かれます。上述の身分証明のいずれかが着信プロセス中に保存されなかったり送信プロセス中に適切に復元されない場合、サーバーからの送信パケットは正しいクライアントに送信できません。

System iではこうした問題が上手く解決されており、図5に示す通り、TCP/UDPトラフィックが流れるときにファイヤーウォールの背後にある複数のクライアントからの同時VPN接続をサーバーは処理することができます。その他のタイプのトラフィックに対しても同じレベルの接続同時性を保つには、クライアントとサーバー間でL2TP/VPNを一緒に使用することをお勧めします。

NATと暗号化処理のためにサーバーがエンド・ツー・エンドの通信プロトコル(たとえばTCP)を処理するのが困難になっています。クライアントがTCPパケットを暗号化するとき(図4の上半分)、TCPのチェックサムはクライアントとサーバーのIPアドレスに基づいています。そして暗号化されたパケットは図4に示す通り全ての送信ステップを通過します。ステップ5が終了すると、パケットはNAT機器のIPアドレスを送信元IPアドレスとして持つことになります。暗号化/復号化がトランスポート・モードを使用している場合は、TCPチェックサムがサーバー側で失敗します。サーバーはパケットが認証された送信元(クライアント)から来たものであり、送信元IPがNATを通過した後も正しく変更されていることを確認します。サーバーはTCPチェックサムを再調整して送信元のIPアドレスとNAT通過後のIPアドレスの矛盾を修正します。i5のファイヤーウォール親和性の高いVPNソリューションを使用することで、TCPはIPsecトランスモードでも円滑に動作します。

互換性/相互運用性

前述した通り、V5R4のファイヤーウォール親和性の高いVPNはRFC3947とRFC3948をサポートしています。V5R4のファイヤーウォール親和性の高いVPNは上記両RFCのドラフト２およびドラフト3に対して下位互換性を保っていますので、同じ標準に準拠したさまざまなプラットフォーム上のクライアントと相互運用性を保つことができます。現在までのところ、Windows、Linux、System i上のクライアントとの相互運用性が確認されています。

VPNを保護する

時代の流れとともにデータのセキュリティはますます重要になるばかりで、セキュリティに関する要件や規制の影響をますます受けています。ここでの課題は生産性を維持しながらも会社や顧客のデータを保護することです。V5R4のファイヤーウォール親和性の高いVPNはこのバランスを保つためのすばらしいツールです。

ファイヤーウォール親和性の高いVPNに関するヒントとテクニック

ユーザー・データグラム・プロトコル(UDP: User Datagram Protocol)のトラフィックが、VPN(Virtual Private Network)クライアント、サーバー、ファイヤーウォールのフィルター規則によってポート500や4500でブロックされないことを確認してください。 (ファイヤーウォール親和性の高いVPNではない)通常のVPNでは、図Aに示す画面上でのPermit ALL IKE Trafficオプション(IKEはInternet Key Exchangeの略)を選択するかまたは何も選択しないかを選ぶことができます。このオプションが選択された場合、明示的なフィルター規則が生成されIKEネゴシエーション･パケットがUDPポート500に流れます。このオプションが選択されない場合、システムはそうしたトラフィックを暗示的に流します。 VPN構成がファイヤーウォールを通過するかどうかを構成時に判断するのは困難です。現在のところ、System iはUDPトラフィックがポート4500を予定より早く流れるようにする明示的な規則を生成していません。ファイヤーウォール親和性の高いVPNでは、Permit ALL IKE TrafficオプションをはずしてシステムがIKEパケットをUDPポート500または4500を実行時に流せるようにします。 賦活パケットが一定間隔で送信されネットワーク・アドレス変換(NAT: Network Address Translation)通過/UDPカプセル化トンネルが活動状態にあることを示します。IPsecによって保護されているアプリケーションの中には独自の賦活インターバルを持っているものもあります(たとえばレイヤー2トンネリング・プロトコル－L2TP)。マスカレードNATは通常タイムアウト値も保持しています。インターバルやタイムアウトはプラットフォーム毎に異なる値に設定されている可能性があり、状況によってはこれらを調整する必要がある場合があります。 IKEネゴシエーション・パケットはNATを検出したあとポート4500に流れます。暗号化保全ペイロード(ESP: Encapsulating Security Payload)パケットはUDPポート4500にカプセル化されてNATを通過します。IKEパケットとESPパケットをどのように識別するのでしょうか。IKEパケットの中ではUDPペイロードの最初の4バイトが0に設定されているのに対し、UDPカプセル化パケットの中ではUDPヘッダーのすぐあとにESPヘッダーが続きます。 VPNゲートウェイの考え方をご存知であれば、V5R4のファイヤーウォール親和性の高いVPNでサーバーをゲートウェイとして使用することができない点に注意してください。クライアントは複数のホストのゲートウェイとして使用することはできますが、サーバーはホストとしてしか使用できません。では、サーバーの背後にある他のホストにデータを到達させたい場合はどうすればよいのでしょうか。そのような場合は、クライアントとサーバーの間にL2TP/VPNを設置することをお勧めします。サーバーとその背後にあるホストはプライベート・ネットワーク・レンジ(図B)を使用します。L2TPトンネルが作動した後は、クライアントはサーバーが所属するネットワーク・レンジと同じネットワーク・レンジからのプライベートなIPアドレスで参加します。その結果、L2TPトンネルが作動していてデータがIPsec VPNでデータが保護されていれば、クライアントと同じプライベート・ネットワーク・レンジにあるサーバーの背後にある他のホストへクライアントからデータを流すことができます。

あわせて読みたい記事