|
|
日本−日本語 | |
|
|
 |
|
HP OpenVMS: システム・セキュリティ・ガイド > パート III システム管理者のためのセキュリティ
第12章 クラスタのセキュリティ保護 |
|
|
目次 この章では，クラスタ・システムのセキュリティ管理者が考慮すべき事項について説明します。 クラスタ・システムとは，さまざまなコンピュータ間で，ディスク，資源，および共通のオペレーティング・システムの共用が可能なハードウェアとソフトウェアを使用するシステムのことを指します。 VAX プロセッサで構成されるクラスタは，VAXcluster 環境を構成している，と言います。 一方，Alpha プロセッサと VAX プロセッサの両方を含むクラスタは，OpenVMS Cluster 環境を構成している，と言います。 クラスタに対するセキュリティ保護を適切に行うには，『HP OpenVMS Cluster システム』の内容に精通している必要があります。 『HP OpenVMS Cluster システム』では，クラスタ管理者が行うべき作業を説明しています。 クラスタ管理者の仕事は，システム管理者の仕事と同じですが，クラスタ管理者は，多数のノードに対して変更を適用する必要があります。 クラスタを担当するセキュリティ管理者は，クラスタ管理者と同じトレーニングを受け，同じスキルを持つことが要求されます。 クラスタのサイトによっては，一人でセキュリティ管理者とクラスタ管理者の両方の役割を担う場合があります。 また，クラスタ管理チームの他に，1 名または複数名のセキュリティ管理者を置くサイトもあります。 セキュリティ管理者とクラスタ管理者の仕事を分けているサイトでは，それぞれの役目の間での調整，協力，連絡が非常に重要となります。 これまでの章と同様，この章でもセキュリティ管理者という呼び名は，他に担当している役目に関係なく，システムのセキュリティに対する責任を負う人を指します。 クラスタ・システムは，スケーラビリティと可用性が高く，セキュリティ保護された均一なコンピューティング環境を提供します。 登録ユーザのセットが 1 つのみ存在し，クラスタの任意のメンバでこれらのユーザがプロセスを実行できることが重要です。 均一なコンピューティング環境を実現するため，クラスタは，クラスタの全メンバで次のコンポーネントが動作していることを前提とします。
クラスタ内では，ユーザの登録データおよびオブジェクトのセキュリティ・プロファイルがすべてのノードの間で整合性がとれていなければなりません。 これは，特定のオブジェクトに対する特定のユーザのアクセス要求が発生したときに，各クラスタ・メンバがアクセス制御について同じ判断をする必要があるためです。 12.2 項 「共通環境の構築」 および 12.3 項 「登録データの同期」 では，単一のセキュリティ管理領域を実現する方法について説明しています。 クラスタ内では，各ノードが共通の登録情報を利用してアクセス制御を仲介します。 単一のセキュリティ管理領域モデルの場合，権限を有する個人に代わって処理を行うプロセスは，クラスタの管理対象となっているオブジェクトへのアクセスを要求します。 すると，調整を行っているノードは，そのノードが保持している共通の登録データベースのコピーと，アクセスを要求されているオブジェクトのセキュリティ・プロファイルを比較して，アクセス要求に対する応答を決定します。 このモデルでは，登録情報とオブジェクトのセキュリティ・プロファイルがクラスタ内のすべてのノードの間で整合性がとれている場合のみセキュリティが適用されます。 クラスタ内のデータの整合性を確保するためには，サイトでは次の作業が必要です。
単一のセキュリティ管理領域を確立するもっとも簡単な方法は，クラスタにマウントされている 1 台以上のディスクに， 表 12-1 「クラスタ内で一本化する必要の必須システム・ファイル」に示す各ファイルを 1 つだけ置くことです。 あるノードで必須ファイルを作成すると，ただちにそのファイルをそのノード以外のすべてのクラスタ・メンバ上でも作成するか，共用ファイルとして参照できるようにする必要があります。 クラスタが複数のシステム・ディスクで構成されている場合は，システム論理名を使用して，各ファイルのコピーが 1 つのみ存在するようにできます。 表 12-1 「クラスタ内で一本化する必要の必須システム・ファイル」に示したファイルには，同期をとる必要のあるデータが含まれています。 これらのファイルの複数のバージョンを維持するサイトの場合， 12.2.3 項 「複数のバージョンが存在するファイルの同期」の説明に従ってデータの同期をとります。 表 12-1 クラスタ内で一本化する必要の必須システム・ファイル
表 12-2 「共通化が推奨されるシステム・ファイル」に示すファイルをクラスタのすべてのメンバで共用する必要はありませんが，これらのファイルに含まれるデータは完全に同期をとっておくことをお勧めします。 表 12-3 「複数バージョンの必須クラスタ・ファイルの使用」 では，これらのファイルの同期をとる方法と，同期がとれていない場合に生じる可能性のある問題についてまとめてあります。 一部の推奨ファイルは，要求した場合にのみ作成され，構成によっては存在しない場合があります。 あるノードの必須ファイルが存在しなくてもよいのは，他のすべてのノードに存在しない場合だけです。 あるノードで必須ファイルを作成すると，ただちにそのファイルをそのノード以外のすべてのクラスタ・メンバ上でも作成するか，共用ファイルとして参照できるようにする必要があります。 表 12-2 共通化が推奨されるシステム・ファイル
共用ファイルを使用することが，単一のセキュリティ管理領域を実現する唯一の方法というわけではありません。 サイトによっては，クラスタ内の別々のノード上に 1 つまたは複数の共用ファイルの複数のコピーを配置することを要件としている場合もあります。 クラスタ内の各ノードが利用できるセキュリティ情報が同一であれば，これらのサイトでは，単一のセキュリティ管理領域が実現されていることになります。 表 12-3 「複数バージョンの必須クラスタ・ファイルの使用」に，同期の必要なファイル，ファイルを更新するタイミング，同期がとれていない場合に発生しうる問題を示します。 表 12-3 複数バージョンの必須クラスタ・ファイルの使用
クラスタ上では，ユーザ登録データのすべての要素が共用データベースに存在する必要があります。 この登録要素には，システム・ユーザ登録ファイル (SYSUAF.DAT とそのバックアップの SYSUAFALT.DAT)，ライト・データベース (RIGHTSLIST.DAT)，ネットワーク登録ファイル (NETPROXY.DAT)，およびネットワーク・オブジェクト・データベース (NETOBJECTS.DAT) など，すべての OpenVMS システムに存在するものや，必要に応じて作成される自動ログイン・ファイル (SYSALF.DAT) などがあります。 クラスタの安全性を確保するには，すべてのノードの登録データの同期がとれていなければなりません。 サイトでこれらのファイルの複数のバージョンを維持する場合，データの同期をとる必要があります。 各ユーザは，すべてのノードで同じ UIC，グループ番号，および識別子のセットが定義されている必要があります。 特権とアクセス権の同期も重要です。 共用ディスクは，保護の度合いがもっとも低いノードと同じ水準で保護されます。 クラスタ内の各ノードで登録ファイルを個別に維持する場合は，システム・ユーザ登録ファイル (SYSUAF.DAT) のすべてのコピーについて，ユーザ特権が同じになるようにします。 表 12-4 「同期をとる必要のある SYSUAF.DAT のフィールド」に，各ノードで同一になっていなければならない SYSUAF.DAT のフィールドです。
表 12-4 同期をとる必要のある SYSUAF.DAT のフィールド
自動ログイン・ファイルを作成し，登録ファイルおよびライト・データベースといっしょに共用登録データベースに自動ログイン・ファイルを格納する場合は，SYSMAN を使用します。 クラスタ・システムの場合，自動ログイン・ファイルには，ターミナル名の接頭辞としてクラスタ・ノード名を含める必要があります。 たとえば，WILLOW というノード上の TTA0 ターミナルは，WILLOW$TTA0 のように表現します。 SYSMAN の概要については 12.8 項 「システム管理ユーティリティの使用」 を参照してください。 監査サーバ・データベースである VMS$AUDIT_SERVER.DAT には，監査対象のイベントに関する情報，監査ログ・ファイルの場所，および監査に伴う資源消費量の監視に使用する情報が格納されています。 監査ログ・ファイルは SYS$COMMON:[SYSMGR] にあります。 監査ログ・ファイルをシステム・ディスクとは別の場所にリダイレクトする場合，クラスタのすべてのノードで完全に同じようにリダイレクトすることが重要です。 監査ログ・ファイルのリダイレクトには，SET AUDIT/JOURNAL=SECURITY/DESTINATION=ファイル名 というコマンドを使用します。 このコマンドに指定するファイル名は，ノードごとに固有の名前ではなく，クラスタのすべてのノードで同じ名前に帰着するファイル名を指定します。 詳しい手順については，『HP OpenVMS Cluster システム』を参照してください。 単一のセキュリティ管理領域とは，特定のオブジェクトに対して，特定のユーザからアクセス要求が発生した場合に，その領域内の各クラスタ・メンバがアクセス制御について同じ判断を下さなければならない範囲のことです。 OpenVMS は，ファイル，キューのほか，クラスタの管理対象であるその他のオブジェクト (デバイス，ディスクやテープのボリューム，資源ドメインなど) に対して，このレベルの保護機能を提供します。 表 12-5 「クラスタにおけるオブジェクトの動作」に，各オブジェクト・クラスの動作の要約と，各オブジェクトがセキュリティ・プロファイルを格納する場所を示します。 各オブジェクト・クラスの説明については， 第5章 「オブジェクト・クラスの詳細」 を参照してください。 表 12-5 クラスタにおけるオブジェクトの動作
監査サーバは，クラスタ全体から可視となるオブジェクトのセキュリティ要素を VMS$OBJECTS.DAT (場所は SYS$COMMON:[SYSEXE]) というデータベース内に作成し，管理します。 このオブジェクト・データベースは，ノードごとに固有のファイル名ではなく，クラスタのすべてのノードで同じファイルに帰着するファイル名を指定することで，クラスタ内の各ノードに存在するようにします。 システムのブートのたびに論理名が設定されるようにするには，SYSECURITY.COM を使用して論理名を指定します。 SYSECURITY.COM コマンド・プロシージャは，監査サーバが起動する前に定義する必要があります。 このオブジェクト・データベースには，次の情報が格納されています。
このデータベースは，特性が変更されるたびに更新され，更新後の情報は，クラスタに参加するすべてのノードでオブジェクトについて同じ情報を共用できるよう配布されます。 オブジェクト・サーバが存在せず，クラスタ・データベースである VMS$OBJECTS.DAT が更新できない場合は，セキュリティ・プロファイルの変更や保護プロジェクトの作成はできません。 ただし，SECURITY_POLICY システム・パラメータを修正することで，ローカル・ノードでの保護オブジェクトのセキュリティ・プロファイルの変更 (第 4 ビット) やローカル・ノード上での保護オブジェクトの作成 (第 5 ビット) を行えるようにすることは可能です。 クラスタ全体での侵入検出では，あらゆる種類の攻撃からの保護措置をクラスタ全体に行き渡るようにします。 各システムからの侵入データや情報を統合し，クラスタ全体を 1 つのまとまりとして保護します。 クラスタ内のメンバ・システムで SECURITY_POLICY システム・パラメータを設定することで，不正侵入の試みと侵入イベントの状態のデータベースをローカルまたはクラスタ全体で管理できます。 SECURITY_POLICY の第 12 ビットがクリアされている場合，システムが攻撃を受けるか，何らかの侵入イベントが記録されると，すべてのクラスタ・メンバに通知されます。 あるシステムに記録されたイベントに基づき，クラスタ内の別のシステムが制限措置を講じることができます。 たとえば，ログインを試みるユーザをより詳細に監視し，ログインの再試行可能な回数と時間を制限する措置などが考えられます。 この場合，再試行の上限回数か時間制限を上回ると，そのユーザはログインできなくなります。 SECURITY_POLICY の第 12 ビットはデフォルトでクリアされています。 システム・サービスの $DELETE_INTRUSION，$SCAN_INTRUSION，および $SHOW_INTRUSION についての詳細は，『HP OpenVMS System Services Reference Manual』を参照してください。 DCL の DELETE INTRUSION コマンドおよび SHOW INTRUSION の詳細については，『OpenVMS DCL ディクショナリ』を参照してください。 システム管理ユーティリティ (SYSMAN) は，クラスタの管理に伴うセキュリティ管理者の作業を支援するツールです。 SYSMAN のノードとクラスタの一元管理機能によって，SYSMAN を実行するローカル・ノードから，管理対象環境のすべてのノードを対象にシステム管理作業ができます。 SYSMAN を使用するには，ローカル・ノードの OPER 特権と，リモート・ノードに対する OPER 特権の許可が必要です。 管理者のアカウントでクラスタ内で作業をしている場合は，SYSMAN にパスワードを入力する必要はありません。 オペレーティング・システムは，論理リンク接続，またはパスワードが必要となるユーティリティの操作を監査します。 SYSMAN を使用するシステム管理者は，各ノードで論理名を同じ名前に設定するように注意する必要があります。 クラスタ・システムでは，グループ番号とクラスタ・パスワードを使用することによって，拡張された同一の LAN (Local Area Network) に個別の複数のクラスタ・システムを共存できるようにするほか，権限のないコンピュータによるクラスタへの予期しないアクセスを回避できるようになります。 グループ番号は，LAN 上の各クラスタ・システムを一意に識別するためのものです。 クラスタ・パスワードは，同一 LAN 上で同じグループ番号を偶然使用してしまったクラスタの整合性を確保するための追加のチェック手順としての働きがあります。 パスワードは，グループ番号を知った侵入者によるクラスタへの参加を防ぐ働きもあります。 クラスタのグループ番号とパスワードは，暗号化され，クラスタ登録ファイルである SYS$COMMON:[SYSEXE]CLUSTER_AUTHORIZE.DAT に格納されます。 このファイルは，オペレーティング・システムのインストール時に，ローカル・エリア・クラスタまたは混合インターコネクト・クラスタをセットアップするよう指定した場合に作成されます。 その後，インストール・プロシージャによって，クラスタのグループ番号とパスワードの指定を求められます。 通常は，CLUSTER_AUTHORIZE.DAT ファイル内のレコードを会話形式で変更する必要はありません。 ただし，セキュリティ侵害の疑いがある場合は，必要に応じてクラスタ・パスワードを変更します。 クラスタ・パスワードの変更には，SYSMAN を使用します。 CLUSTER_AUTHORIZE.DAT には，SYSPRV 特権を持つユーザだけがアクセスできます。 グループ番号またはパスワードを変更した場合は，必ずクラスタ全体をリブートしてください。 複数のシステム・ディスクを使用する構成の場合，それぞれのディスクに CLUSTER_AUTHORIZE.DAT のコピーを置く必要があります。 SYSMAN を実行してすべてのコピーを更新する必要があります。 次のコマンド・シーケンスは，SYSMAN を使用してクラスタ・パスワードを変更する場合の出力例です。
クラスタ環境では，さまざまな資源共用モデル (ファイルとボリューム，ディスクとテープ・デバイス，バッチ・キュートプリント・キューなど) が使用できるため，通常は，DECnet ソフトウェアを利用してクラスタの別のノードに直接アクセスする必要がありません。 それでも，資源がクラスタ全体で均一に共用されないことがあります。 これは特に，サテライトのディスク・ボリュームやテープ・ボリュームへのクラスタによるアクセスを制限する，混合インターコネクト・クラスタ構成やローカル・エリア・クラスタ構成の場合に当てはまります。 このような場合は，DCL の SET HOST コマンドを使用するか，何らかのネットワーク・アクセス手段を用いて，他のクラスタ・メンバからサテライトの資源にアクセスする必要があります。 代理ログインによるネットワーク・アクセスの詳細については， 13.3 項 「代理アクセス制御」を参照してください。 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||
|
|||||||||||||||
