HP OpenVMS Systems Documentation |
前へ | 次へ | 目次 | 索引 |
第 1 章 で概要を説明したように, DECwindows トランスポート・インタフェースは, X プロトコル・リクエストをクライアントとサーバの間でやり取りするための,汎用のデータ伝送メカニズムです。
ここでは,サポートされるトランスポートの概要と, X ディスプレイ・サーバで利用できるようにする方法について説明します。クライアントのトランスポートを設定する方法については, 第 4.1 節 を参照してください。
3.2.1 ローカル・トランスポートの利用
ローカル・トランスポートはデフォルトのネットワーク・トランスポートであり,常に利用可能です。 DECwindows クライアントとディスプレイ・サーバが同じ OpenVMS システムで動作している場合には,ローカル・トランスポートを使用します。ローカル・トランスポートでは,クライアントとサーバの間で共用メモリを介してより直接的にデータが転送されるため,一般に性能が向上します。このメカニズムにより,システム内でデータをコピーする回数が減り,ネットワーク・アクセスによる余分なオーバヘッドが排除できます。
3.2.2 DECnet トランスポートの利用
DECwindows では,DECnet トランスポートもサポートされています。このトランスポートを有効にして使用する前に, HP DECnet Phase IV for OpenVMS ソフトウェアまたは HP DECnet-Plus (Phase V) for OpenVMS ソフトウェアをシステムにインストールして動作させておく必要があります。
ネットワーキング・ソフトウェアのインストールおよび実行方法については, DECnet 製品のマニュアルを参照してください。
サーバに接続しているときに DECnet または TCP/IP がシャットダウンされると,ネットワークが再開されたときに再接続するために,トランスポートはネットワークに対して継続的にポーリングを行います。 |
第 4 章 で説明したように,DECwindows Motif は, IPv4 (Internet Protocol Version 4) と IPv6 (Internet Protocol Version 6) の両方について TCP/IP トランスポートの実装をサポートします。このトランスポートを有効にして使用する前に, HP TCP/IP Services for OpenVMS ソフトウェアまたはサポートされている他社製の TCP/IP 製品をインストールし,システムのスタートアップの一環として実行する必要があります。
TCP/IP Services ソフトウェアは,デフォルトでシステムのスタートアップ時に起動するように構成されています。他社の製品を使用している場合は,ソフトウェアのインストール方法と構成方法について,製品のマニュアルを参照してください。
HP TCP/IP Services for OpenVMS ソフトウェアを,X プロトコルをサポートするのための最小限の DECwindows の要件を満たすように構成することで,メモリとプロセス・スロットを有効に利用することができます。 DECwindows に必要なものは,INET_ACP が動作していることだけです。 TCP/IP の概念とネットワーク・ソフトウェアの構成方法についての詳細は, TCP/IP Services for OpenVMS のマニュアルを参照してください。
3.2.4 LAT トランスポートの利用
DECwindows では,他の OpenVMS Alpha ワークステーションおよび OpenVMS I64 ワークステーションに表示するためのネットワーク・トランスポート・メカニズムとして,LAT をサポートしています。 LAT トランスポートを有効にして使用する前に,DECwindows のクライアントとサーバ・システムの両方で LAT ソフトウェアを起動する必要があります。 LAT ソフトウェアの起動と構成についての詳細は,『LATCP Utility Reference Manual』を参照してください。
LAT をトランスポートとして使用するためには,ディスプレイ・サーバ・システムで LAT サービス X$SERVER が動作している必要があります。 DECwindows のスタートアップ・プロシージャで強制的に LAT サービスを作成するには,次の論理名を定義します。
$ DEFINE /SYSTEM DECW$INSTALL_XTERMINAL SERVER |
この論理名は,DECwindows を起動する前に定義する必要があります。この論理名は,SYS$MANAGER:SYLOGICALS.COM で定義することをお勧めします。
3.2.5 デフォルト・トランスポートの変更
DECnet トランスポートとローカル・トランスポートはデフォルトで有効になっています。ディスプレイ・サーバで使用するトランスポートを有効または無効にするには, DECW$PRIVATE_SERVER_SETUP.COM ファイルを変更して, DECW$SERVER_TRANSPORTS パラメータを再定義します。
例 3-1 に,TCP/IP接続とローカル接続を使用し, DECnet 接続は使用しないようにシステムを設定する例を示します。
例 3-1 トランスポート接続の設定例 |
---|
$do_TCPIP: $ decw$server_transports == "TCPIP,LOCAL" $ exit $ ! |
ここでは, DECwindows Motif がサポートしているアクセス制御方式と,それを使用して X ディスプレイ・サーバへのアクセスを制御する方法について説明します。
3.3.1 ユーザ・ベースのアクセス制御
ユーザ・ベースのアクセス制御 では,ホスト,トランスポート,およびユーザ名の組み合わせ (たとえば DECNET ZEPHYR JONES) に対して X ディスプレイ・サーバへのアクセスが許可されます。指定したユーザ名,ノード名,およびトランスポート情報は,選択したユーザ・クラス以外のユーザを遮断するフィルタとして機能します。
ユーザ・ベースのアクセス制御は,許可ユーザ・リストまたはアクセス許可リストのどちらかにエントリがあるかぎり常に有効です。この形式のアクセス制御は,暗号化機能がなく, TCP/IP 環境でユーザ名を指定することができず,最もセキュリティが低いため,ローカル,DECnet,または LAT 環境でアクセスを許可するためにだけ使用することをお勧めします。
3.3.2 トークン・ベースのアクセス制御
トークン・ベースのアクセス制御では,接続要求時にクライアント・アプリケーションから提示されたパスワードまたはトークンに基づいて X ディスプレイ・サーバへのアクセスが許可されます。クライアントの認証レベルと認証方法は, Magic Cookie (MIT-MAGIC-COOKIE-1) と Kerberos (MIT-KERBEROS-5) のどちらのプロトコルを使用するかで変わります。
一般に,トークン・ベースのアクセス制御で保護されたサーバにクライアント・アプリケーションがアクセスしようとするたびに,サーバは X authority ファイルを参照して,使用する適切なプロトコルと,接続を許可するために使用する認証方法を判断します。
トークン・ベースのプロトコルでは,より高い保護が得られるだけでなく,オープンされたサーバ接続上で実行できる操作についてもより詳細な制御が可能です。たとえば,トークンを使用して信頼特権を許可または拒否することができます。 X ディスプレイ・サーバへの信頼されていない接続では,その接続上で実行できる操作が大幅に制限されます。
XDM-AUTHORIZATION-1 や SUN-DES-1 などのその他の X ウィンドウ・システムのセキュリティ・プロトコルは,現在サポートされていません。これらのプロトコルを使用して DECwindows の X ディスプレイ・サーバにアクセスする他社製のクライアント・アプリケーションは,デフォルトでユーザ・ベースのアクセス制御になります。 |
Magic Cookie は,ホスト・ベースのセキュリティ・メカニズムに代わるより安全なメカニズムを提供するために設計されたもので, X ウィンドウ・システムの以前のリリースでも利用可能です。このプロトコルは,トークン・ベースのアプローチとしては最初のものであり, X ディスプレイ・サーバへのアクセスをユーザ・レベルで制限するための標準的な手段として初めて提供されました。
Magic cookie では,cookie と呼ばれる,クライアントがサーバに対して提示するバイナリ数値に基づいてサーバへの接続が許可されます。通常,クライアントはこの cookie 値を X authority ファイルから取得しますが,プログラムによっては他の方法も使用します。
X authority ファイル内の Magic Cookie アクセス制御の各エントリには,以下の内容を指定します。
X ディスプレイ・デバイスのアドレス
プロトコル名 (MIT-MAGIC-COOKIE-1)
ランダムな数値の cookie 値
DECwindows Motif セッションで接続を許可するために Magic Cookie を使用する場合,ユーザがローカルの DECwindows Motif デスクトップに正常にログインするたびに cookie が生成されます。ローカル接続を許可する magic cookie は,デバイス,トランスポート,プロトコル名とともに X ディスプレイ・サーバに渡され,最新の X authority ファイル (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH) に保存されます。
セッション中にクライアント・アプリケーションがディスプレイ・サーバに接続を試みるたびに,アプリケーションは接続要求とともに有効な cookie をサーバに提示する必要があります。 cookie が,X ディスプレイ・サーバが保持しているいずれかの cookie と一致した場合,接続とアクセスが許可されて,ディスプレイがオープンされます。ユーザが DECwindows Motif セッションからログアウトすると,サーバはリセットされ,cookie は破棄されます。
ランダムに生成された値を使用するため,Magic Cookie はユーザ・ベースの方式よりも安全な形のアクセス制御を提供します。ただし,cookie は暗号化されずにネットワーク上でやり取りされるため,傍受されやすくなっています。したがって,この形のアクセス制御は,ローカル・エリア・ネットワーク (LAN),限定された DECnet 環境,他の方法で保護された TCP/IP ネットワーク上で接続を許可するために使用することをお勧めします。
3.3.2.2 Kerberos
Kerberos は,X ディスプレイ・サーバへの接続を,以下の要素の組み合わせに基づいて承認します。
X authority ファイル中のプロトコル名 (MIT-KERBEROS-5)
有効な Kerberos プリンシパルとそれに関連付けられたパスワードのリスト
有効な証明書の提示
Kerberos 証明書 (チケット)は,プリンシパルの身元を確認するために使用する一連の電子情報です。これらのプリンシパルは,サーバ・システムに保管されている許可プリンシパル・リストに格納されます。 Kerberos では,有効なプリンシパルで動作するクライアント・アプリケーションは, Kerberos で保護された X ディスプレイ・サーバに接続しようとするたびに, Kerberos KDC (Key Distribution Center) に対して,チケット要求を送信します。
サーバで Kerberos のアクセス制御を有効にすると,ユーザがローカルのデスクトップにログインするたびに,自動的に新しいチケットが KDC に対して要求されます。 KDC は,ユーザのプリンシパル名に関連付けられた チケット保証チケット (TGT: Ticket Granting Ticket) を作成し,パスワードを鍵としてそれを暗号化し,暗号化された TGT を返します。
TGT が正常に復号化されると,ユーザは認証され TGT はキャッシュされます。 TGT は認証されたプリンシパルが追加のチケットを取得するのを許可します。これらの追加のチケットは,特定のサービス (この場合は他のクライアント・アプリケーションからの X ディスプレイ・サーバへのアクセス) を許可します。これらの追加のチケットの要求と許可は,透過的に行われます。
DECwindows Motif では,ユーザごとの認証が使用されています。このモデルでは,クライアントとサーバの両方が接続の両端で Kerberos クライアントを使用して,ユーザの身元 (プリンシパル) を確認します。接続の両端でプリンシパルが認証されると,サーバへのアクセスが許可されます。
デフォルトでは,各 TGT は一定の時間で期限切れとなります。 TGT が期限切れとなるか信用できなくなった場合, Kerberos ログインを強制することで現在の TGT を破棄して新しい TGT を生成することができます。
Kerberos は,要求元のクライアントとサーバ・システム間での初期認証情報を暗号化するため,最も安全なアクセス制御方式です。したがって,インターネットなどの保護されていないネットワーク上でリモート・クライアント接続を許可するための方法としてお勧めします。
Kerberos は,ネットワーク接続上でやり取りされるすべてのデータを暗号化するために使用するセッション鍵を生成するように設計されています。 X ウィンドウ・システムでは,この鍵を使用して最初の認証メッセージだけが暗号化されます。いったんクライアントの身元が確認されると,以降のデータは暗号化されずにネットワーク・チャネル上で送信されます。そのため,サーバ自体はネットワーク・レベルの攻撃を受けることがあります。 |
X authority ファイル は,X ディスプレイ・サーバへの接続を許可するために使用する情報が格納されたバイナリ・データ・ファイルです。クライアント・アプリケーションは,X サーバに接続しようとするたびに,最新の X authority ファイルを参照して,接続を認証するために適用する適切な承認キーを決定します。
各承認キーは,プロトコル名とトークンで構成され,使用するプロトコルに応じて以下のいずれかになります。
デフォルトでは,Magic Cookie または Kerberos アクセス制御が構成されたシステム上のデスクトップにユーザが最初にログインしたときに,自動的に X authority ファイルが作成されます。このファイルはそのユーザの OpenVMS ログイン・ディレクトリ (SYS$LOGIN:DECW$XAUTHORITY.DECW$XAUTH) に保存されます。以降ユーザがそのシステムのデスクトップにログインするたびに,新しい承認キーが生成され,X ディスプレイ・サーバに渡されて,ユーザの X authority ファイルに書き込まれます。このキーは, DECwindows Motif セッションの間,X ディスプレイ・サーバへのアクセスを制御します。
通常の DECwindows Motif のログイン処理とは異なるサーバへのアクセスが必要なクライアント・アプリケーション用に,別の X authority ファイルを手動で定義することができます (DECW$SERVER_XAUTHORITY シンボルを使用します)。
セキュリティ拡張が有効な場合,承認キーを手動で生成することもできます。手動で生成したキーを使用して,サーバへのアクセスをさらに制限することができます。生成されたキーはクライアント・システム上の X authority ファイルに格納され,指定されたディスプレイ・サーバに対する既存の値を上書きします。特定のサーバへの接続を許可するために,キーをさまざまなクライアント・システムに配布したり,以降の接続を止めるために破棄することができます。
生成されたキーには,承認 ID が割り当てられます。これによって,キーとそれを生成したユーザが関連付けられます。その結果,キーを生成したユーザだけがキーを破棄することができます。
3.3.4 アクセス許可ファイル
アクセス許可ファイルは, X ディスプレイ・サーバへの追加の OpenVMS ユーザ・アクセスをサーバのスタートアップ時に自動的に許可するための ASCII テキスト・ファイルです。
アクセス許可設定は, DECwindows Motif デスクトップにユーザがログインするまで有効です。ユーザがデスクトップにログインして DECwindows Motif セッションが開始されると,セッション・マネージャでそのユーザ用に定義されたセキュリティ・オプションが適用されます。
ユーザがセッションを終了すると,サーバは再度初期化され,アクセス許可設定が復元されます。
アクセス許可ファイルは,通常は DECwindows Motif のログイン処理を使用しないワークステーションで使用するために設計されています。このファイルを使用すると DECwindows Motif システムのセキュリティが低下するおそれがあるため, DECwindows Motif のログイン処理を使用して X サーバへのアクセスを制限するシステムでは,このファイルを使用しないでください。 たとえば,アクセス許可ファイルでアクセスを許可されたユーザがログイン・ウィンドウを偽装して, DECwindows Motif デスクトップにログインしようとした他のユーザのパスワードを読み取るおそれがあります。 |
信頼されたユーザとは,セキュリティ設定の変更を許可されたユーザです。 アクセス信頼ファイルは,特定のディスプレイ・サーバのアクセス制御設定を変更することができる OpenVMS ユーザを識別する ASCII テキスト・ファイルです。
デフォルトでは,ローカルの SYSTEM アカウントに対して信頼権限が与えられます (ローカル・トランスポートまたは DECnet トランスポート上で)。このファイルのエントリは,トークン・ベースの認証方式が有効になっていないかぎり,アクセス許可ファイルに自動的に追加されます。トークン・ベースの認証方式が有効な場合は,アクセス許可リストに手動でエントリを追加するか,適切な X authority ファイルにエントリを追加することで,信頼されたユーザによる X ディスプレイ・サーバへのアクセスを許可する必要があります。
アクセス信頼設定は,アクセス許可ファイルの設定と同様に,ユーザが DECwindows Motif デスクトップにログインするまで有効です。
前へ | 次へ | 目次 | 索引 |