test

Trusted Solaris 管理の手順

第 9 章 Trusted Solaris におけるホスト管理およびネットワーク管理の概念

この章では、ネットワーク上のホストの管理に関する必要な概念と背景について、次の項目について説明します。

「トラステッドネットワークデータベース」の更新手順、ならびに他の関連操作の手順については、第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」を参照してください。トラステッドネットワークの概要に関しては『Trusted Solaris 管理の概要』の「トラステッドネットワークの管理」を参照してください。

トラステッドネットワーク通信の確認

Trusted Solaris オペレーティング環境は、Trusted Solaris 7 ホストと次の 4 種類のホスト間におけるネットワーク通信をサポートします。

ネットワーク通信およびネットワークサービスは、次に挙げるさまざまな Trusted Solaris サブシステムによって管理されます。

トラステッドネットワークの目的

トラステッドネットワークソフトウェアでは、次の機能が保証されています。

tnrhdb(4)、tnrhtp(4)、tnidb(4) の各トラステッドネットワークデータベースには、ホスト、ネットワーク、ネットワークインタフェースに適用されるラベルや他のセキュリティ属性が格納されます。トラステッドネットワークデータベースについては、「トラステッドネットワークデータベース」で詳しく説明します。また、操作手順については、第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」で説明します。

セキュリティ管理者は、トラステッドネットワークデータベースの特定のフィールドを使用して、Trusted Solaris マシンからの通信が、転送データの機密レベルと同じセキュリティレベルのゲートウェイを介してのみ配信されるように指定できます。このようなルーティングは、「トラステッドルーティング」と呼ばれています。

ルーティングの仕組みおよび Trusted Solaris 環境で使用されるデータベースについては、「ルーティング」の項で説明します。

Trusted Solaris ネットワークの例

最も単純で保護しやすいネットワーク構成は、単一スタンドアロン型の同機種分散システムです。この構成はまた、ネットワーク通信の保護に関する評価基準を完全に満たした、唯一の構成といえます。分散システムは、次の条件下で稼動する 1台から複数台のホストによって構成されます。

この方法で管理されるホストはみな、同じセキュリティドメインに属すものと考えられます。単一セキュリティドメイン内では、ワイヤ上に送出されるパケットが同じネットワークに接続された他のすべてのホストによって拾い上げられるため、ルーティングテーブルを必要としません。

この種のネットワークでは、顧客側で傍受に対する物理的な保護対策が施されていると想定されます。これは、Trusted Solaris ソフトウェアが暗号化機能をサポートしていないためです。

すでにおわかりのように、Trusted Solaris オペレーティング環境を単独で実行している単一ホストは、スタンドアロン型セキュリティドメインとみなされます。

同機種セキュリティドメインの例

図 9-1 は、NIS+ マスターとして動作するホスト F が接続された単一のセキュリティドメインを示しています。それぞれのホストは、単一のネットワークインタフェースによってネットワークに接続されます。「ネットワークインタフェース」とは、ホストをネットワークケーブルに接続するホスト上の物理コネクタを指します。大抵の場合、インタフェースには Ethernet コネクタが使用され、ローカルネットワークのすべてのホストが接続されている Ethernet ケーブルに接続されます。ホストまたはネットワークインタフェースの「ネットワーク認可範囲」 (インタフェースを介す通信すべてに適用されます) は、最下位機密ラベルと最上位機密ラベルで定義されます。この認可範囲はセキュリティ管理者によって決定され、トラステッドネットワークデータベースに指定されます。

図 9-1 単一のセキュリティドメイン

Graphic

異機種システム混在ネットワーク

Trusted Solaris ホストは、他のオペレーティングシステムを実行するホストとも通信可能です。それらのホストが同じワイヤに接続されているか、あるいは別のネットワークに接続されているかは問いません。

ネットワークに追加しようとしているホストが、さまざまな信頼レベルで他のオペレーティングシステムを実行するローカルネットワークに接続されている場合は、セキュリティ管理者は、ワイヤを保護するための何らかの手段を検討しなければなりません。Trusted Solaris は暗号化を提供しません。

他のホストタイプに用意されたトラステッドネットワークデータベースのエントリに、それらのホストタイプから転送されないセキュリティ属性を指定したり、それらのホストと通信可能なラベルを指定する必要があります。次の図は、異機種システム混在ネットワークと、Trusted Solaris ホストが通信可能なホストタイプの例をいくつか示しています。

図 9-2 異機種システム混在ネットワーク

Graphic

上の図で、Solaris ホストが NIS+ 対応の Solaris バージョンを実行している場合は、このホストを NIS+ マスターホスト F の NIS+ クライアントとして構成できます。CIPSO、RIPSO、TSIX ホストは、それぞれの構成情報がローカルファイルに保持されるスタンドアロンシステムとして、ネットワークに構成されます。(cipso、ripso、tsix ホストタイプは、表 9-1 に示します。)

ホストタイプ、テンプレート、プロトコル

tnrhdb と tnrhtp データベースのエントリの組み合わせにより、複数のホストとネットワークを特定のホストタイプに対応付けることができます。このホストタイプによって、カーネルがメッセージの解読に使用するプロトコルが識別され、そのプロトコルによって、カーネルはパケットのヘッダーから検出されるべきセキュリティ属性を知ることができます。次の表は、ホストタイプと、それに対して作成されるトラステッドネットワークデータベースのエントリを示しています。

表 9-1 ホストタイプ名
 ホストタイプ トラステッドネットワークデータベースで使用される名称 プロトコルと注釈
 Trusted Solaris 2.x またはそれ以降sun_tsol TSOL プロトコル。このプロトコルは、Trusted Solaris 2.x またはそれ以降で実行するホスト間のセキュリティ属性の転送を簡易化する。TSOL は TSIX(RE) 1.1 - SAMP プロトコルから派生したプロトコルで、ネットワークプロトコルスタックの同様の場所にセキュリティ属性を渡し、同様のヘッダー構造を使用する。TSOL プロトコルはバイナリ形式でセキュリティ属性を渡すため、トークンマッピングを必要としない。Trusted Solaris 2.x またはそれ以降で実行するホスト間に限り使用される。
 TSIX/REtsix 制限付環境用トラステッドセキュリティ情報交換 (Trusted Security Information Exchange for Restricted Environments (TSIX/RE) ) プロトコル (セキュリティ属性の受け渡しにはトークンマッピングを使用)。
 MAXSIXmsix Trusted Solaris 1.x、MAXSIX が使用するネットワークプロトコル。このプロトコルの使用により、Trusted Solaris 1.2 マシンとのネットワーク接続が可能になる。このプロトコルはもともと MaxSix 1.0 で使用されたもので、トークン形式でセキュリティ属性を IP オプションフィールドに渡す。ラベルは CIPSO のタグタイプ 3 として渡される。
 TSIX(RE) 1.1 - CIPSOcipso Common IP Security Option プロトコルの TSIX(RE) 1.1。IP オプションフィールドに渡されるセキュリティラベルの指定に使用される。CIPSO ラベルはデータの機密ラベルから自動的に取得される。セキュリティラベルの受け渡しにはタグタイプ 1 が使用される (CIPSO)。その後このラベルは、IP レベルでのセキュリティ検査に使用される。また、ネットワークパケット内のデータのラベル設定に使用される場合もある。
 RIPSOripso IETF REC 1108 に記述される Revised IP Security Option (RIPSO)。ラベルを IP パケットに組み込むための DoD IP ラベル付け方式を定義する。また、ネットワーク MAC の検査にも使用される。管理目的で設定された固定式の RIPSO ラベルは、特定のホストと交換されたネットワークパケットに適用される。この機能は REC 規格を完全に満たすものではないが、RIPSO ラベルを必要とする場合に十分な機能を与えるものとされている。
 ラベルなしラベルなしSolaris またはラベルのないオペレーティングシステムを実行するホストに割り当てられる。ラベルなしホストへのパケット転送は、ADMIN_LOW からそのホストのテンプレートのデフォルトのラベルエントリで指定された機密ラベルまでの、すべての有効な機密ラベルで行われる。パケットを単一機密ラベルに制限するには、最下位機密ラベルと最上位機密ラベルが同等でなければならない。受信パケットには、デフォルトの機密ラベルが割り当てられる。

上の表の 2 列目のホストタイプ名称は、トラステッドネットワークデータベースで使用されている名称です。

デフォルトの tnrhtp データベースには、各ホストタイプに １ つずつサンプルのテンプレートが含まれています。セキュリティ管理者役割は、これらのテンプレートをそのまま使用することも、コピー、リネーム、変更して使用することもできます。tnrhtp データベースに含まれるすべてのテンプレート名は、データーベースマネージャで tnrhdb データベースを使用してホストの IP アドレスにテンプレートを指定しようとすると、画面に一覧表示されます。図 9-3 を参照してください。

たとえば、Trusted Solaris をトラステッドホスト (ホストタイプに sun_tsol を指定したホスト) として構成するとします。この場合、セキュリティ管理者役割は、tnrhdb データベースにそのホストのエントリを追加し、tnrhtp データベースから sun_tsol ホストタイプを持つ適切なテンプレートを割り当てます。

図 9-3 tnrhtb データベースのテンプレート名一覧 : 「追加 (Add)」メニュー

Graphic

ホストタイプ別の構成可能なセキュリティ属性は、第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」の 表 10-1 を参照してください。

複数のセキュリティドメイン例

複数の NIS+ ドメインから成る複数のセキュリティドメインは、ゲートウェイで接続される場合があります。次の図は、2 つのセキュリティドメイン構成を示しています。ホスト F はセキュリティドメイン #1 の NIS+ マスターで、ホスト K はセキュリティドメイン #2 の NIS+ マスターです。2 つのセキュリティドメインは、ゲートウェイホスト G によって接続されています。

図 9-4 2 つのセキュリティドメイン

Graphic

Trusted Solaris 管理用語でいう「ゲートウェイ」とは通常、複数のネットワークインタフェースを持つホストを指します。したがって、複数のネットワークは Trusted Solaris ゲートウェイで接続される場合があり、これは推奨される構成でもあります。Trusted Solaris ゲートウェイを使用すると、トラステッドネットワークソフトウェアにトラステッドネットワークデータベースに定義された属性を使用させることでネットワークを行き来するパケットのセキュリティポリシーを実施したり、CIPSO や RIPSO ラベルのパケットのトラステッドルーティングをサポートしたりすることが可能になります。

ネットワーク認可範囲の条件

ゲートウェイのトラステッドネットワークインタフェースである tnidb(4) データベースのネットワーク認可範囲を制限することは、セキュリティ管理者役割にとって、他のネットワークとの通信を実現する上で、開放や制御の適切なレベルを構成する 1 つの手段となります。

ほとんどの Trusted Solaris ホストでは、認可範囲を ADMIN_LOW から ADMIN_HIGH に指定します。この認可範囲にしておくと、同機種 Trusted Solaris 分散システム内のすべてのホストが、同じシステムの他のホストからパケットをさまざまな機密ラベルで受信することができます。ゲートウェイの認可範囲は、ローカル分散システム外のホストとあらゆる機密ラベルで通信できるように設定したり、あるいは限定されたラベルに通信を制限するように設定したりできます。

注 -

ネットワークインタフェースの認可範囲を制限する際には注意が必要です。ネットワークサービスは、ネットワークインタフェースの認可範囲に、それらのサービスに適した機密ラベルが含まれていないと機能しません。たとえば、NIS+ マスターとの通信には、ADMIN_LOW から ADMIN_HIGH までのネットワーク認可範囲が要求されます。監査サーバーに書き込まれる ADMIN_HIGH の監査トレールファイルの場合は、ネットワークインタフェースの認可範囲に ADMIN_HIGH が含まれている必要があります。

図 9-5 認可範囲の異なる 2 つのセキュリティドメイン

Graphic

通信を制限するには、上の図に示すゲートウェイ G の tnidb エントリを、次の表のように指定します。

表 9-2 ネットワークの認可範囲を制限する場合の tnidb エントリの例

インタフェース名 

ネットワーク認可範囲 

le0 (セキュリティドメイン #1 に対するインタフェース) 

PUBLIC から INTERNAL USE ONLY

le1 (セキュリティドメイン #2 に対するインタフェース) 

ADMIN_LOW から ADMIN_HIGH

ネットワークにおけるセキュリティ属性の搬送方法

セキュリティ属性がパケットにどのように追加されるのかを理解しておくことは、さまざまな種類のホストを定義したり、トラステッドネットワークデータベースにおいて、セキュリティ属性を指定したりする方法を理解するための必要条件となります。また、ここに説明する内容は、トラステッドルーティングを設定する上でも重要になります。

最上位レベルのネットワークパケットは、次の図に示すような形式になります。

表 9-3 パケットの形式
 Ethernet ヘッダー IP ヘッダー [IP オプション] TCP または UDP ヘッダー データ Ethernet トレーラ

ネットワーク通信には、TCP/IP と UDP/IP のどちらも使用できます。トラステッドネットワークデータベースのエントリで、ホストタイプとして sun_tsol または tsix を指定すると、トラステッドネットワークソフトウェアによって、TCP または UDP ヘッダーの後、すなわちデータの前に「security attribute modulation protocol (SAMP)」ヘッダーが挿入されます。ホストタイプが sun_tsol または tsix に指定された場合のパケットは、次の図のような形式になります。

表 9-4 TSIX および Trusted Solaris のパケット形式
 Ethernet ヘッダー IP ヘッダー [IP オプション] TCP または UDP ヘッダー SAMP ヘッダー データ Ethernet トレーラ

SAMP ヘッダーには、属性がバイナリ形式かトークン形式かを指定する属性ヘッダーなどの、パケットのセキュリティ属性が入ります。SAMP ヘッダーがルーティングに使用されることはありません。

IP オプション

IP ヘッダーの IP オプションフィールド (表 9-4 の [IP オプション] 部) には、RIPSO または CIPSO のどちらかのラベルとオプションが入り、トラステッドルーティングに使用されます。Trusted Solaris ホストでは、宛先ホストの tnrhdb と tnrhtp エントリを構成して、送信パケットの IP オプションフィールドに CIPSO または RIPSO のどちらかのラベル情報をセットできるようになっています。サポートされている CIPSO オプションには、CIPSO ホスト用のタグタイプ 1 と、MSIX ホスト用のタグタイプ 3 の 2 種類があります。「パケットの CIPSO ラベル」、「パケットの RIPSO ラベル」、「トラステッドネットワークデータベースにおけるエントリの作成」を参照してください。

パケットの CIPSO ラベル

そのホストに割り当てられたトラステッドネットワークテンプレートのエントリが、次の条件のいずれかを満たしている場合、トラステッドネットワークソフトウェアは、送信パケットの IP オプションに、CIPSO ラベルと CIPSO DOI (domain of interpretation) 番号をセットします。一方、着信パケットでは、IP オプションにセットされた CIPSO ラベルと DOI を調べます。

テンプレートの IP ラベルフィールドが CIPSO に設定されていたり、リモートホストタイプが cipso に設定されている場合は、タグタイプ 1 が使用されます。リモートホストタイプが msix の場合は、CIPSO タグタイプの 3 が使用されます。

送信パケットで搬送される CIPSO ラベルは、トラステッドネットワークソフトウェアによって、データに対応する実際の機密ラベルから取得されます。場合によっては、Trusted Solaris の機密ラベルが CIPSO ラベルと直接一致することもあります。たとえば、機密ラベル CONFIDENTIAL が、CIPSO ラベル CONFIDENTIAL と一致します。しかし、大半の Trusted Solaris の機密ラベルは、CIPSO ラベルに直接対応しません。

注 -

トラステッドルーティングを設定するために CIPSO ラベルを使用したり、ホストタイプが cipso のホストとの通信を希望するサイトでは、CIPSO ラベルにうまく割り当てることができるよう、セキュリティ管理者が前もってサイトのラベルの構成案を立てておくことをお勧めします。

CIPSO DOI (domain of interpretation) も指定する必要があります。このとき、次のホストがみな同じ CIPSO DOI を共有するようにします。

機密ラベルと CIPSO ラベル間でマッピングを行うには、格付け値は 255 以下である必要があります。すべてのコンパートメントビット番号は 239 以下である必要があります。

デフォルトでは、CIPSO ラベルに割り当てられないほど大きな機密ラベルで送られてきたメッセージは、破棄するようになっています。

表 9-5 CIPSO ラベルにマッピングされるラベルの構成要素の制限
 構成要素 値 (この値以下)
 格付け値 255
 コンパートメント番号 239

ADMIN_HIGH ラベルは上記表に示された制限を超えるため、デフォルトでは、ADMIN_HIGH ラベル付きのパケットは破棄されます。ADMIN_HIGH ラベルをネットワークインタフェース経由で送信する必要がある場合、関連するすべてのマシン上で tsol_admin_high_to_cipso カーネルフラグを 1 に設定します。このフラグは、セキュリティ管理者役割が /etc/system ファイルで設定できます。したがって、パケットが ADMIN_HIGH 機密ラベルを持つとき、そのラベルは、格付け値が 255 で、0 から 239 までのすべてのコンパートメントビットがオンの状態で CIPSO ラベルにマッピングされます。

注 -

ADMIN_HIGH ラベルがマッピングされるようにフラグが設定されている場合、格付け値が 255 で、0 から 239 までのすべてのコンパートメントビットがオンであるラベルがユーザー認可範囲内に存在しないことを確認してください。そうしなければ、マッピング後、このようなユーザーラベルは ADMIN_HIGH と区別が付かなくなります。すべてのラベルがマッピング可能であることを保証するために、コンパートメント番号が 239 を超えるユーザーラベルが存在しないことを確認します。

パケットの RIPSO ラベル

そのホストに割り当てられたトラステッドネットワークテンプレートのエントリが、次の条件のいずれかを満たしている場合、トラステッドネットワークソフトウェアは、送信パケットの IP オプションに RIPSO ラベルをセットします。一方、ホストからの着信パケットでは、IP オプションにセットされた RIPSO ラベルを調べます。

送信パケットの RIPSO ラベルは、管理上の目的で定義されます。セキュリティ管理者役割は、tnrhtp データベース内で格付けを「RIPSO 送信クラス (RIPSO Send Class)」フィールドに、コンパートメントまたは保護許可フラグ (PAF) を「RIPSO 送信 PAF (RIPSO Send PAF)」フィールドに指定します。

次の表はRIPSOA ラベルでサポートされている送信用の格付けを示しています。

表 9-6 RIPSO ラベルでサポートされている格付け
 RIPSO ラベルでサポートされている格付け
Top_Secret
Secret
Confidential
Unclassified

「RIPSO 送信 PAF (RIPSO Send PAF)」と「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドは、表 9-7 に示す保護許可フラグ (PAF) を参照します。「RIPSO 送信 PAF (RIPSO Send PAF)」 フィールドに設定された PAF は、コンパートメント名と同様に、RIPSO ラベル内で格付けと共に使用されます (例 : Top_Secret SCI)。「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドに指定された PAF は、ICMP メッセージのラベル付けで使用されます。このメッセージは、RIPSO ラベルの着信パケットに対するエラー応答として作成されるものです。ICMP メッセージで返送される格付けは、パケットの RIPSO の格付けと同じものが使用されます。

表 9-7 「RIPSO 送信 PAF (RIPSO Send PAF)」 または「RIPSO 戻り PAF (RIPSO Return PAF)」フィールドに設定される保護許可フラグ
 保護許可フラグ(RIPSO ラベルでサポートされている格付けで設定されるか、RIPSO エラーとして設定される)
GENSER
SIOP-ESI
SCI
NSA
DOE

ルーティング

ローカルネットワークから外への通信を単一のラベル (PUBLIC など) に制限したいサイトもあります。このようなサイトでは、ネットワーク認可範囲 PUBLIC を外部ネットワークに接続されているインタフェースに割り当てます。Trusted Solaris 環境には、ネットワーク間通信のルーティング手段が何種類かサポートされているため、セキュリティ管理者役割は、サイトのセキュリティポリシーで要求されるセキュリティレベルを実施できるような経路 (ルート) を設定できます。TCP/IP とルーティングの詳細については、『TCP/IP とデータ通信』を参照してください。

背景

同じネットワーク上でのホストからホストへの通信の場合は、ルートやルーターは必要ありません。 (この項では、ゲートウェイと「ルーター」という用語をそれぞれ置き換えて使用することがあります。なぜなら、ゲートウェイがパケットのルーティングを行うからです)。認可範囲チェックは発信元で実行されます。ただし、受信側ホストが Trusted Solaris を実行している場合は、受信先で実行されます。

発信元ホストと宛先ホストが物理的に異なるネットワークに接続されている場合は、パケットは発信元ホストからゲートウェイに送信されます。宛先ホストと最初のホップのゲートウェイの認可範囲は、ルート選択時に発信元ホストでチェックされます。ゲートウェイは、宛先ホストが接続されているネットワークにパケットを転送します。宛先に到達するまでに、複数のゲートウェイを経由するパケットもあります。Trusted Solaris ゲートウェイでは認可範囲の検査が実行されまることがありますが、中間ゲートウェイでは実行されず、単にパケットを受け渡すだけとなります。

ゲートウェイにはそれぞれ、すべての宛先に対するルートリストが保持されます。標準 Solaris のルーティングメトリックでは、宛先までの最短経路に基づくルート選択が可能ですが、Trusted Solaris 2.5.1 および 7 の拡張版は、それに加え、セキュリティ条件を満たしたトラステッドルーティングを実現しています。パケットに IP セキュリティオプションを付加することによって、中間ルーターでも認可範囲チェックに IP ラベルを使用できるようになるからです。トラステッドルーティングは、すべてのゲートウェイが RIP (拡張経路制御情報プロトコル、extended Routing Information Protocol) を認識するかどうかに依存します。したがって、トラステッドルーティングはルーティングに他のプロトコルを使用するインターネットでは使用できません。すべてのゲートウェイが拡張 RIP (経路制御情報プロトコル、Routing Information Protocol) を使用するイントラネット上でのみトラステッドルーティングは使用できます。

トラステッドルーティングを採用しているサイトでは、ラベルなしホストのクラスタの反対側に接続された Trusted Solaris ホストとの通信や、ラベルを認識しないルーターを 1 つ以上経由する通信のセキュリティを確保しなければなりません。このようなサイトでは、セキュリティ管理者役割がトンネリングを設定する必要があります。なお、「クラスタ」および「トンネリング」という用語については、「用語と概念」で定義しています。

修正版 TCP/IP ルーティング機能

トラステッドネットワークの構成とルートの設定を始める前に、セキュリティ管理者役割は次のことを理解しておく必要があります。

セキュリティ管理者役割はまた、次のことも理解しておかなければなりません。これらの項目については、残りの項で説明します。

次の TCP/IP ルーティング機能は、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

認可チェック

トラステッドネットワークソフトウェアは、認可検査を実行して、発信元ホスト、宛先ホスト、そこに設定されるルートの各セキュリティ属性を比較します。セキュリティ属性 (認可範囲と指定された CIPSO または RIPSO ラベル情報) は、ホストの tnrhdb または tnrhtp ファイルのエントリから取得されます。ルートのセキュリティ属性 (SRI) は、ルーティングテーブル内のそのルートの拡張メトリックから取得されます。ルートの拡張メトリックが指定されていない場合は、最初のホップのゲートウェイホストのエントリのセキュリティ属性が検査されます。

ルータ上では、転送されるべきパケットに RIPSO または CIPSO ラベルがあり、パケットの IP オプション部のラベルが使用されているときにのみ認可チェックが行われます。パケットに CIPSO ラベルがあれば、その機密ラベルは、入出力インタフェースのラベル範囲と比較されます。その機密ラベルは、次のホップのゲートウェイのラベル範囲とも比較されます。

送信メッセージにおける MAC の実施

送信側ホストでは、次の認可検査が行われます。

注 -

最初のホップの検査は、あるネットワークのホストから別のネットワークのホストにゲートウェイを介してメッセージが送信される場合に行われます。

転送メッセージにおける MAC 検査

Trusted Solaris ゲートウェイでは、次のホップとネットワークインタフェースの認可検査が実行されます。

パケットに CIPSO ラベル情報が含まれる場合は、転送されるパケットで以下の条件が満たされなければなりません。

パケットに RIPSO ラベル情報が含まれる場合は、転送されるパケットで以下の条件が満たされなければなりません。

メッセージの機密ラベルがどの宛先ホスト、ゲートウェイ、またはネットワークインタフェースについても、それらの認可範囲として指定された最下位および最上位ラベルの中に含まれない場合、そのメッセージはドロップされます。

着信メッセージにおける MAC の実施

受信側ホストでは、次の検査が行われます。

受信の場合、Trusted Solaris ネットワークソフトウェアは、可能な限り機密ラベルと他のセキュリティ属性をパケット自体から取得します。ただし、これが問題なく行えるのは、メッセージが Trusted Solaris システムで認識可能な形式のラベルと必要な属性をサポートしているシステムから送信される場合だけです。多くの場合、パケットはラベルを認識しないホストや、認識可能なラベルを送信しないホストから送られてきます。そしてまた、パケットに必要な属性が完全に含まれていない場合もあります。

すべての必要なセキュリティ属性をパケットから取得できない場合は、不足している属性がトラステッドネットワークデータベースからメッセージに割り当てられます。ホストのエントリから取得不能な属性は、メッセージが経由してきたインタフェースに適用される、トラステッドネットワークインタフェースのデータベースのエントリに指定された属性によって補われます。

静的ルーティングの設定

LAN の外側で行われる通信の静的ルーティングを設定するには、Trusted Solaris セキュリティ管理者役割が、各ホストの /etc ディレクトリにある 2 つの静的ルーティングテーブルの 1 つにゲートウェイを指定する必要があります。tsolgateways(4) ファイルには、次の 2 種類のゲートウェイを指定できます。

ルーティングテーブルにネットワークエントリだけのエントリを指定すると、指定されたネットワークだけに通信が制限されます。ルーティングテーブルに 1 個以上ネットワークエントリを指定した場合でも、デフォルトエントリを指定することができます。

単純なネットワークでは、デフォルトゲートウェイを /etc/defaultrouter ファイルに指定できます (詳細は、route(1M) のマニュアルページを参照してください)。

「静的ルーティング」で説明したように、トラステッドネットワークソフトウェアは、最初に tsolgateways を検索し、このファイルが見つかった場合は defaultrouter ファイルを検索しません。どちらのファイルも見つからない場合は、動的ルーティングが使用されます。

tsolgateways ファイルのメトリックフィールドに入力される数値は、発信元ホストと宛先ホスト間にあるゲートウェイの数になります。同じネットワークのホストに対する伝送では、ホップは使用されません。図 9-9 は、ホップ数 0 の同一ネットワークに接続された 4 台のホスト (H1、H2、H3、H4) を示しています。

図 9-9 単一セキュリティドメインの 4 台のホスト間で行われるホップ数 0 の通信例

Graphic

発信元ネットワークのゲートウェイに直接接続されたネットワークへの伝送では、ホップ数が 1 となります。図 9-10 は、ゲートウェイ G1によってネットワーク 129.150.102.0 に直接接続されたネットワーク 129.150.101.0 を示しています。ゲートウェイ G1には、インタフェースごとに 1 つずつホスト名が付いています。gateway-101 は 101 ネットワークに接続されたインタフェースの名前であり、gateway-102 は 102 ネットワークに接続されたインタフェース用の名前です。ゲートウェイが 1 つしかない単純なネットワークには /etc/defaultrouter を使用できます。したがって、129.150.101.0 ネットワーク上のホスト H1、H2、H3、H4 に、gateway-101 だけを指定する defaultrouter ファイルを作成することができます。tsolgateways ファイルを使用する場合は、ネットワークアドレスを 129.150.102.0 に、メトリックをホップ数 1 に指定します。

図 9-10 単一ゲートウェイで構成された 2 つのセキュリティドメインのデフォルトルートとネットワークルートの例

Graphic

2 台のゲートウェイを経由するネットワークの伝送では、図 9-11 に示すようにホップ数が 2 となります。この図では、IP アドレス 129.150.101.0 のネットワーク上のホスト H1、H2、H3、H4 に作成される tsolgateways ファイルの例を示しています。図に示されるように、ゲートウェイ G1 はネットワーク 129.150.101.0 とネットワーク 129.150.102.0 を接続し、ゲートウェイ G2 はネットワーク 129.150.102.0 とネットワーク 129.150.103.0 を接続しています。tsolgateways ファイルの最初のエントリには、ゲートウェイ 1 - 101 を介す 129.150.102.0 へのネットワークルートが設定されており、メトリック欄の 1 は、宛先ネットワークまでのホップ数が 1 個であることを示しています。2 番目のエントリには、ゲートウェイ 1 - 101 を介す 129.150.103.0 へのネットワークルートが設定されており、メトリック欄の 2 は、宛先ネットワークまでのホップ数が 2 個であることを示します。

図 9-11 3 つのネットワーク間通信に設定された tsolgateways ファイルの例

Graphic

次の図は、ゲートウェイ G1、G2、G3 を使用した、さらに複雑なネットワークトポロジを示しています。

手順については、「単一ゲートウェイで構成されたネットワークの簡易デフォルトルートを設定するには」を参照してください。

図 9-12 複雑なゲートウェイ構成とルーティングテーブルの例

Graphic

トラステッドルーティングの設定

この節では、送信データの機密レベルと同じセキュリティレベルで構成されたゲートウェイだけを経由する通信ルートが必ず使用されるために、知っておかなければならないことが書かれています。この節は、「ルーティング」の節をすでに読んで理解していることを前提にしています。ルーティングの設定手順については、第 10 章「トラステッドネットワークデータベース におけるセキュリティ属性の指定とルーティング設定」の「ルーティングの IP ラベルを設定するには」を参照してください。

トラステッドルーティングを設定するには、セキュリティ管理者が、すべてのホストとゲートウェイにあるトラステッドネットワークデータベースのエントリを設定できなければなりません。

送信側ホストで、テンプレートに CIPSO IP ラベルと CIPSO DOI が定義されている宛先にパケットを送信する場合は、宛先に割り当てられた DOI と送信側ホストに割り当てられた DOI が一致しなければなりません。さらに、最初のホップのゲートウェイのテンプレートには、宛先のものと一致する CIPSO DOI が定義され、パケットの CIPSO ラベルを含む認可範囲が設定される必要があります。テンプレートに RIPSO IP ラベル (格付け) と RIPSO PAF (コンパートメント) が定義されている宛先にパケットを送信する場合は、宛先に割り当てられた RIPSO の格付けとコンパートメントの組み合わせが、送信側ホストに割り当てられた組み合わせと一致しなければなりません。また、最初のホップのゲートウェイのテンプレートには、宛先と同じ RIPSO ラベルと PAF が定義される必要があります。セキュリティ管理者役割によって宛先ホストのテンプレートに IP ラベルが指定されると、トラステッドネットワークソフトウェアは、指定されたラベルを送信パケットの IP 部に挿入します。IP ラベル型を CIPSO にする場合は、パケットの機密ラベルから CIPSO ラベルを取得します。IP ラベル型を RIPSO にする場合は、宛先ホストのテンプレートに管理目的で定義された RIPSO ラベルを使用します。

受信側ホストでパケットを受信する場合は、発信元ホストのテンプレートに指定された CIPSO ラベルと CIPSO DOI が、受信側ホストに指定された CIPSO ラベルと CIPSO DOI に一致しなければなりません。

トラステッドルーティングの考慮事項

ここでは、前の節に記述した規則を簡単な例と図で説明していきます。ホスト H1 と H2 は Trusted Solaris ホストであり、これらのホストは、CIPSO IP ラベルに基づくトラステッドルーティングを使用して通信します。H1 は、G1 までのデフォルトルートを設定する in.rdisc を実行しています。G1 と H2 の間には、他の Trusted Solaris ゲートウェイが存在する可能性もあります。

次の図は、発信元ホスト H1 がパケットを G1 経由で H2 に送信できるようにするために、H1 の tnrhdb、tnrhtp、tnidb ファイルに設定しなければならない定義内容を示しています。パケットの機密ラベルは CONFIDENTIAL になっており、この例では、この機密ラベルによって直接 CIPSO ラベルの CONFIDENTIAL に割り当てられているとします。

図 9-13 送信側ホストのトラステッドネットワークファイルの定義

Graphic

送信側ホストでは、パケットの送信前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

すべての検査に合格すると、トラステッドネットワークソフトウェアは CIPSO ラベル C と CIPSO DOI 1 をパケットに挿入し、G1 に送信します。図 9-13 は前の図の続きで、パケットの転送前にゲートウェイで実行される検査を示しています。

図 9-14 パケット転送前にゲートウェイで実行される検査

Graphic

ゲートウェイでは、パケットの転送前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

次の図は図 9-14の続きで、パケット受信時に宛先ホストで実行される検査を示しています。

図 9-15 受信側ホストで実行される検査

Graphic

宛先ホスト H2 では、パケットを受信する前に、トラステッドネットワークソフトウェアが次の手順で検査を行います。

セキュリティ管理者役割は、最初のホップのゲートウェイおよび宛先ホストに対し、同じホストタイプと IP ラベル型を指定します。

IP ラベルを指定するには、ホストタイプとして次のどれかを指定します。

また、IP ラベル型を次のどちらかで統一する必要があります。

例:

RIPSO をサポートする非 Trusted Solaris システムを実行しているゲートウェイ、または商用 RIPSO ルーターのための IP ラベルを指定する場合は、次のホストタイプを入力します。

CIPSO をサポートする非 Trusted Solaris システムを実行しているゲートウェイ、または商用 CIPSO ルーターのための IP ラベルを指定する場合は、次のホストタイプを入力します。

CIPSO タイプ 3 を使用して Trusted Solaris 1.x ホストを経由させる場合は、IP ラベルとして次のホストタイプを入力します。

Trusted Solaris ゲートウェイはまず、設定されたテンプレートによって sun_tsol、tsix、ciposo、ripso のいずれかのホストタイプとして識別されます。その後で RIPSO または CIPSO の IP ラベル型が IP ラベルフィールドに割り当てられます。RIPSO または CIPSO ラベルをサポートする非 Trusted Solaris ホストや商用ルーターも、ripso または cipso ホストタイプを使用して構成できます。Trusted Solaris 1.x ホストの場合は、パケットにタイプ 3 の CIPSO ラベルが挿入されるため、トラステッドルーティングには使用できません。

CIPSO ラベルは、トラステッドネットワークソフトウェアによってパケットの機密ラベルから取得されます。一方、RIPSO ラベルは、セキュリティ管理者役割によってテンプレートの 「RIPSO Send Class」と「RIPSO -Send PAF」フィールドに指定されます。

パケットがゲートウェイで転送されるときは、トラステッドネットワークソフトウェアによってパケットの CIPSO または RIPSO ラベルが参照され、ルーティングテーブルにルートの拡張メトリック情報がある場合は、それと比較されます。ルートの拡張メトリック情報がない場合は、最初のホップのゲートウェイのトラステッドネットワークデータベースのエントリのセキュリティ情報と比較されます。このようにして、メッセージが適切な信頼レベルのゲートウェイだけを経由することが保証されます。

トラステッドネットワークソフトウェアは、次の図に示すパケットの部分しか参照しません。Trusted Solaris と TSIX ラベル、その他のセキュリティ属性は、パケットの TCP/UDP ヘッダーとEthernet トレーラ間にあるアクセス不能な部分に保存されます。一方、CIPSO ラベルと RIPSO ラベルは、パケットのアクセス可能な IP ヘッダー部に保存されます。

表 9-8 トラステッドネットワークソフトウェアがアクセス可能なパケット部
 Ethernet ヘッダー IP ヘッダー [IP オプションの RIPSO ラベル] TCP または UDP ヘッダー  . . . Ethernet トレーラ

CIPSO または RIPSO IP ラベルで指定された sun_tsol と tsix ホストタイプとの組み合わせを使用すると、パケットに Trusted Solaris または TSIX のセキュリティ属性を付加して、それらの属性を認識する宛先ホストに送信できるようになります。また、宛先との間にある Trusted Solaris ルーターでは、トラステッドネットワークソフトウェアがパケットのアクセス可能な IP 部の CIPSO または RIPSO ラベルを参照し、パケットの搬送ルートを制御されます。IP ラベルが指定されていないと、ゲートウェイのトラステッドネットワークソフトウェアは、パケットのラベルを確認したり、次のホップで必要な認可チェックを実行することができません。なぜなら、トラステッドネットワークソフトウェアは、パケット内に保持されているラベルと他のセキュリティ属性を確認しないからです。

注 -

CIPSO ラベルは、送信データの実際の機密ラベルから取得されるため、セキュリティ管理者役割が CIPSO ラベルを指定することはありません。ただし、IP ラベル型が CIPSO の場合は、このラベル型の通信がルートされる各セキュリティドメインのセキュリティ管理者の間で、通信に使用される Trusted Solaris の機密ラベルが合意されていなければなりません。これは、トラステッドネットワークソフトウェアによって、機密ラベルが同等の CIPSO ラベルに変換されるためです。また、セキュリティ管理者たちは、先に掲げたすべてのホストタイプに対し、同じ CIPSO DOI を指定することも承諾している必要があります。

注 -

RIPSO ラベルと RIPSO エラーは管理上の目的で定義されるため、リストにあげたホストには、それぞれ同じ RIPSO ラベルと RIPSO エラーを指定しなければなりません。IP ラベル型が RIPSO の場合は、この IP ラベルの通信がルートされる各セキュリティドメインのセキュリティ管理者の間で、先に掲げたすべてのホストタイプに対し、指定すべき RIPSO ラベル、保護許可フラグ、RIPSO エラーが合意されている必要があります。

単一ラベルのゲートウェイで複数のラベルのパケットを転送可能にするには

単一ラベルのホスト (ラベルなしあるいは ripso のホストの種類として指定されたもの) には、テンプレートにデフォルトの機密ラベルを割り当てる必要があります。ラベルなしホストのテンプレートにおける最下位および最上位機密ラベルは、ルーティングに使用する認可範囲を確定します。それぞれのラベルなしのホストに割り当てられた認可範囲は、単一ラベルゲートウェイによるパケットの転送に使われます。これは、デフォルトの機密ラベルだけでは受信が許可されないためです。

単一ラベルゲートウェイの認可範囲は、トラステッドネットワークソフトウェアがどのパケットをそのゲートウェイで送信するかを決めるのに使われています。ラベルのないゲートウェイで転送されるパケットは、認可範囲内になければなりません。

ADMIN_LOW から ADMIN_HIGH までのデフォルトのラベル範囲は、デフォルトの unlabel テンプレートで設定されます。必要に応じて、セキュリティ管理者役割は、そのデフォルトのラベル範囲の変更を行うことができます。