test

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