test

Trusted Solaris 管理の手順

用語と概念

この項では、知っておかなければならない用語から順に定義していきます。各用語は、先に出てきた用語の定義に基づいて定義されます。

ルーター

厳密にいえば、ルーターは 2 個以上のネットワークインタフェースを持ち、あるネットワークから別のネットワークにパケットを転送するマシンのことをいいます。「ルーター」の代わりに「ゲートウェイ」という用語が使用されることもあります。セキュリティ管理者は通常、Trusted Solaris 環境のルートを慎重に選択しなければならないため、機密情報に使用するすべてのルーターのセキュリティ特性を理解しておく必要があります。

信頼度の最も高いルーティングを確保するには、ルーターに Trusted Solaris ホストを使用してルートを設定します。他の種類のルーター上では、必ずしもすべての Trusted Solaris セキュリティ機能が使えるわけではなく、さらに、パケットはラベル付き (MAC) セキュリティ保護なしでルーターを通過できることを念頭に置いておくことが必要です。

Solaris ルーターは、IP オプションセクションに認識不能なラベルが検出されても、パケットを破棄せず、そのまま転送します。しかし、CIPSO、RIPSO、MSIX ルーターの場合は、対応するラベル型がパケットの IP オプションセクションに検出されないと、パケットを破棄してしまいます。たとえば、CIPSO ルーターでは、パケットの IP オプションセクションに CIPSO ラベルが検出されなければ、そのパケットは破棄されます。ホスト間の通信を設定する際は、このような注意事項を理解したうえで、パケットが適切なルーターに経由されるようにしなければなりません。

ルーティングテーブル

各ホストのカーネルに保持されるルーティングテーブルには、ルートが定義されます。このルーティングテーブルの各エントリによって、特定の宛先に対するルートが確定します。

 宛先 (特定のホストまたはネットワーク) 最初のホップゲートウェイ (ルート内の最初のゲートウェイ) ゲートウェイに対応するインタフェース

ルーティングソフトウェアはルートテーブルを参照し、宛先ホストに対するルートを見つけようとします。ルートテーブルに宛先ホストが明確に定義されていない場合は、そのホストが接続された (サブ) ネットワークのエントリを探します。宛先ホストも、そのホストが接続されたネットワークも定義されていない場合は、デフォルトゲートウェイにパケットを送信します (デフォルトゲートウェイが定義されている場合)。デフォルトゲートウェイは複数定義でき、それぞれ平等に扱われます。ポインタによって最後に使用されたデフォルトゲートウェイが記録され、次のルーティングにはリストの次のゲートウェイが使用されます。

注 -

場合によっては、複数のデフォルトゲートウェイによってループが生じることもあります。

トラステッドルーティングをサポートできるよう、Trusted Solaris ルーティングテーブルは、宛先までのホップ数を指定するメトリック (計測データ) に加え、セキュリティ情報も保持するよう拡張されています。「SRI」と「拡張メトリック」については、この後で定義します。

ルーティングテーブルのエントリは、次のどちらかの方法で作成されます。

小規模なネットワークでは、管理者役割が手動でルートを設定し、状況の変化に応じて手動でルーティングテーブルを変更することも可能です。たとえば、外部との通信を、すべて 1 台のゲートウェイで行っているサイトも多数あります。このようなケースでは、その 1 台のゲートウェイが、ネットワーク上の各ホストのデフォルトとして静的に定義されます。

注 -

静的ルーティングを使用するルーターは使用可能であることを公示しないためほとんどの場合、動的ルーティングを使用している他の大半のシステムには認識されません。

大規模なネットワークでは、静的ルートを手動で構成したり管理することは不可能です。大規模なネットワークでは、たいていの場合、動的ルーティングが使用されます。

SRI

トラステッドルーティングに必要なセキュリティ属性のセットを SRI (security routing information) と呼びます。SRI には、ルートの認可範囲を確定するために、常に次の情報が含まれます。

route(1M) のマニュアルページに書かれているように、次のセキュリティ属性を SRI に含めることもできます。

SRI は次のどちらかの方法で取得されます。

拡張 RIP

Xerox Routing Information Protocol (RIP) バージョンは、Trusted Solaris 環境用に拡張されており、ルーターからルートが伝達される際に、ルートのメトリックと共にセキュリティ属性がサポートされるようになっています。インターネットでは別のプロトコルを使用してルーティングが行われるため、拡張 RIP の互換性が保持されるのは、すべてのゲートウェイが RIP を認識できるイントラネット内だけになります。

拡張メトリック

拡張メトリック (Extended Metric) は、標準のルーティングメトリックと SRI の両方から成り、ルーティングテーブルにルートのエントリ単位で保存されます。ルーティングソフトウェアは、これらの拡張メトリックを比較することによって、セキュリティ条件を満たす最短の経路を選択します。拡張メトリックは、route(1M) を使用して、静的ルート用に手動で入力することもできます。ルートを手動で定義する方法については、「認可チェック」を参照してください。

動的ルーティングが使用される場合は、ルーティングデーモンの in.routed がセキュリティ強化された特殊な応答パケットを送信し、検出されたルートを伝達します。

送信側と受信側ホストの間には、複数のゲートウェイを経由する数種類のルートが存在する場合があり、ルートごとに拡張メトリックが異なることもあります。このような場合は、ルーティングソフトウェアによって、SRI がパケットのセキュリティ属性と一致するルートが選択されます。

sec_response パケット

基本的な Solaris システムでは、in.routed(1M) が各インタフェースのリクエストパケットを転送し、他のホストから送られてくるリクエストパケットや応答パケットを待ちます。一方、Trusted Solaris システムの in.routed は、応答パケットを送信する際に必ず sec_response パケットも送信します。このパケットには、ルートのメトリック以外に SRI も含まれています。応答パケットと同様に、sec_response パケットも、1 ホップずつメトリックと SRI を調整しながらルートを伝達していきます。

sec_response パケットは、Trusted Solaris ゲートウェイからは伝送されても、Trusted Solaris 以外の (以下、非 Trusted Solaris と呼びます) ゲートウェイからは伝送されません。2 台の Trusted Solaris ホスト間で、Trusted Solaris ルーターから 非 Trusted Solaris ゲートウェイにルートのセキュリティ情報を送信するには、クラスタのエッジにある Trusted Solaris ルーターにトンネリングを設定する必要があります。こうすることによって、Trusted Solaris ホストとその他のオペレーティングシステムまたは環境で実行されるホストが混在するイントラネットでも、経路制御が可能になります。次の「クラスタ / 雲」および 「トンネリング」を参照してください。

クラスタ / 雲

このマニュアルでいうクラスタとは、0 台以上のホストと1台以上のゲートウェイの集合 (または雲) を指します。

以下に示す 2 つの図では、イントラネットとその中のクラスタが雲の形で示されています。Trusted Solaris クラスタは白抜きの雲で、同ゲートウェイは白抜きの円で囲まれています。また、非 Trusted Solaris クラスタは影のついた雲で、同ゲートウェイは正方形で囲まれています。

次の図は、3 つのクラスタで構成されたイントラネットを示しています。Trusted Solaris ホストの H1 は、Trusted Solaris 7 または 2.5.1 ゲートウェイで 非 Trusted Solaris の雲に接続されています。ホスト H2 は、応答および sec_response パケットを自分のネットワークに伝送します。応答パケットはホスト H1 が接続されたネットワークに伝達されますが、sec_response パケットは伝達されません。sec_response パケットがないと、ホスト H1 はホスト H2 までのルートのセキュリティ情報が入った拡張メトリックを取得できません。なぜなら、中間クラスタの非 Trusted Solaris ゲートウェイで実行されている標準の RIP は、拡張 RIP のパケット を H2 のネットワークから H1 のネットワークに転送できないからです。

図 9-6 イントラネット内のクラスタの例

Graphic

トンネリング

2 つの Trusted Solaris クラスタの間に、トラステッドルーティングを使用する非 Trusted Solaris クラスタが存在するときは、セキュリティ管理者役割はトンネリングを設定して、2 つの Trusted Solaris クラスタ内のゲートウェイが各ルートの拡張メトリックを交換できるようにしなければなりません。クラスタはすべて同一イントラネット内に構成する必要があります。また、以前の Trusted Solaris リリースでは、動的ルーティングと、拡張メトリックを制御する拡張 RIP がサポートされていないため、Trusted Solaris ゲートウェイでは Trusted Solaris 7 または 2.5.1 を実行しなければなりません。図 9-7 は、トンネリングの設定方法を示しています。

1台以上の非 Trusted Solaris ゲートウェイを介してトンネルに設定される Trusted Solaris ルーターは、すべて転送ホストとして機能し、反対側に接続された Trusted Solaris ホストまでのルートの拡張メトリックを伝達します。図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックを、H2 が接続されたネットワークに直接ブロードキャストします。G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

図 9-7 イントラネット内の非 Trusted Solaris クラスタを通過するトンネリング

Graphic

有効なエントリで tunnel ファイルが作成されている場合は、拡張 in.routed デーモンによって、sec_t_response という特殊なラベルなし応答パケットが送信されます。ルートの拡張メトリック情報を含む sec_t_response パケットは、tunnel ファイルにリストされたネットワークに直接送信されます。

図 9-7 では、転送ホストゲートウェイ G1 の tunnel ファイルに、ホスト H2 が接続されたネットワークの IP アドレスが保持されます。G1 の Trusted Solaris ルーティングソフトウェアは、H1 までのルートの拡張メトリックが入った sec_t_response パケットを、H2 が接続されたネットワークに直接ブロードキャストします。このようにして、G2 は H1 までのルートの拡張メトリックを取得し、それを自分のルーティングテーブルに追加します (双方向通信を行う場合は、ゲートウェイ G3 と G4 にも、ホスト H1 のネットワークの IP アドレスが入った tunnel ファイルを作成する必要があります)。

sec_response パケットと同様に sec_t_response パケットも、in.routed が Trusted Solaris ルーターから応答パケットを送信するときに必ず送信されます。sec_t_response パケットは、直接宛先ネットワークに送信される必要があります。これは、宛先ネットワークとの間にある非 Trusted Solaris 2.5.1 または 7 ルーターでは sec_response パケットを転送できないからです。

非 Trusted Solaris クラスタを通る非 Trusted Solaris ルートはすべて、同じ SRI を持っていなければなりません。すなわち、これらのルートは、同じデフォルトラベルと IP ラベルオプション (ある場合) を使用して Trusted Solaris システムで定義される必要があります。

詳細については、in.routed(1M) のマニュアルページを参照してください。また、「トンネリングの設定」 および 第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」 「トンネリングを設定するには」を参照してください。

静的ルーティング

静的ルーティングは、同じく静的ルーティングを使用している他の Trusted Solaris ホストとネットワークとの通信にしか使用できません。静的ルーティングを使用するルーターは使用可能であることを公示しないため、動的ルーティングを使用しているシステムに認識されないからです。起動時には、次のファイルのどちらかが route(1M) コマンドによって使用され、カーネルテーブルにルーティングエントリが作成されます。

動的ルーティング

Trusted Solaris 2.5.1 またはそれ以降のバージョンは、Solaris 2.5 またはそれ以降のリリースで使用されている次の 2 つの動的ルーティングプロトコルを使用します。

なお、RIP プロトコルは拡張されています。

in.rdisc

ホストに /usr/sbin/in.rdisc プログラムはあっても、/etc/defaultrouter と /etc/tsolgateways ファイルが存在しない場合は、ICMP Router Discovery (RDISC) が動的ルーティングに使用されます。また、このプロトコルは、デフォルトゲートウェイをルーティングテーブルにインストールします。

デフォルトでは、in.rdisc がホストで実行されるようになっています。ホストで in.routed を実行するには、/usr/sbin/in.rdisc を削除するか、リネームする必要があります。in.rdisc によって設定されたデフォルトゲートウェイには、対応する拡張メトリックはありません。

in.routed

/usr/sbin/in.rdisc が存在しない場合、ホストは in.routed を実行します。『TCP/IP とデータ通信』に書かれているように、ルーターとして構成されたマシンは、自動的に Routing Information Protocol (RIP) バージョン 1 と RDISC プロトコルを実行します。in.routed は、完全なルーティングテーブルをインストールします。

動的ルーティングまたは静的ルーティングの決定

次の図に、ゲートウェイ以外の Trusted Solaris ホスト上に特定のファイルおよびプログラムが存在するかどうかによって、静的ルーティングまたは動的ルーティングのどちらを行うかを決定する方法を示します。

図 9-8 ホストが使用するルーティングの種類の確定方法

Graphic