7 アクセス制御

アクセス制御では、次のものが提供されます。

  • ボリュームアクセス制御では、ボリュームを 1 つのクライアントアプリケーションに割り当てることができます。そのクライアントのボリュームへのアクセスをほかのクライアントに許可できます。

  • コマンドアクセス制御では、管理者が、特定の ACSLS コマンドを特定のクライアントに割り当てることができます。

ボリュームアクセス制御とコマンドアクセス制御はどちらも、ACSAPI 経由でリクエストを送信するクライアントアプリケーションのユーザーに適用されます。

アクセス制御では、cmd_proc または ACSLS GUI を使用してライブラリリクエストを送信する管理ユーザーによるアクセスは制限されません。

ボリュームアクセス制御

有効になっている場合、特定のユーザーによって所有されているボリュームはそのユーザーか、または信頼できるほかのユーザーからのみアクセスできます。

ACSLS でボリュームアクセス制御をはじめて構成する場合は、次の手順に従います。

  1. ACSLS でボリュームアクセス制御を有効にします。

  2. クライアントアプリケーションをユーザー名に関連付けます。

  3. そのユーザーのボリュームにほかのどのユーザーがアクセスできるかを定義します。

  4. ボリュームの所有権を確立します。

ボリュームアクセス制御の有効化

ACSLS でボリュームアクセス制御を有効にするには:

  1. 構成ユーティリティー acsss_config を実行します。

    メインメニューが表示されます。

  2. 「Option 4 - Set Access Control Variables」を選択します。

    各変数が一度に 1 つずつ表示され、その現在の設定が表示されます。

  3. 現在の設定またはデフォルト設定を受け入れるには、Enter をクリックします。

  4. ユーティリティーにメッセージ Access control is active for volumes が表示されたら、「[TRUE]」を選択して Enter をクリックします。

  5. ユーティリティーにメッセージ Default access for volumes [ACCESS/NOACCESS]... が表示されたら、次のいずれかを選択します。

    • 目標が特定のユーザーに対してアクセスを禁止し、ほかのすべてのユーザーに対してアクセスを許可することである場合は、「[ACCESS]」を選択します。

      これには、特定のユーザーを users.ALL.disallow ファイルまたは特定の users.COMMAND.disallow ファイルにリストしておく必要があります。ユーザーのボリュームへのアクセスが許可されるほかのユーザーの定義を参照してください。

    • 目標が特定のユーザーに対してアクセスを許可し、ほかのすべてのユーザーに対してアクセスを禁止することである場合は、「[NOACCESS]」を選択します。

      これには、特定のユーザーを users.ALL.allow ファイルまたは特定の users.COMMAND.allow ファイルにリストしておく必要があります。ユーザーのボリュームへのアクセスが許可されるほかのユーザーの定義を参照してください。

      ボリュームへのアクセスが拒否されたインスタンスをログに記録する場合は、そのプロンプトに応答して「[TRUE]」を選択します。

      ボリュームアクセスを有効または無効にした場合は常に、変更を有効にするために ACSLS を再起動する必要があります。

      
Associating a client identity with a user name

すべてのクライアントアプリケーションが ACSLS リクエストパケットでユーザー ID を渡すわけではありません。クライアントがユーザー名で識別されない場合は、ユーザー ID を割り当てることできます。

  1. access_control 構成ディレクトリに移動します。

    $ACS_HOME/data/external/access_control.

  2. internet.addresses という名前でファイルを作成するか、または internet.addresses.SAMPLE ファイルをコピーします。

  3. このファイル内に、クライアントごとのレコードを作成します。各レコードには、クライアント IP アドレスと、それに続く対応するユーザー名の少なくとも 2 つのフィールドが含まれます。コメントのための追加フィールドを含めることができます。

    次の例に示すように、各フィールドをスペースまたはタブで区切ります。

    192.0.2.1  ulyssis   payroll department

    クライアントとユーザーの関連付けは、使用しているクライアントアプリケーションと同じ数だけ作成できます。

    • クライアントアプリケーションが ACSLS リクエストでユーザー名を渡す場合は、internet.addresses ファイルが指定されている IP アドレスでユーザー名を認証し、両方のフィールドがリクエストパケット内の値と一致しない場合はアクセスを拒否します。複数のクライアントが共通のプラットフォームからホストされている場合は、このファイル内に同じ IP アドレスが複数回含まれている可能性があるため、このアドレスをその IP アドレスに正しく適用されるものと同じ数のユーザー名に関連付けることができます。

    • クライアントアプリケーションがリクエストでユーザー名を渡さない場合は、internet.addresses ファイルがそのクライアントのユーザー名を確立します。この場合は、どのクライアント IP アドレスにも 1 つのユーザー名しか関連付けることができません。

  4. internet.addresses ファイルへの更新をすべて保存します。

    • acsss_config を実行します。

    • 「Option 6 - "Rebuild Access Control Information"」を選択します。

    ACSLS は、この変更を動的に認識します。

    TCP/IP を使用しない SNA および OSLAN クライアントの場合は、access_control ディレクトリ内の lu62.names または adi.names ファイルを参照してください。

ユーザーのボリュームへのアクセスが許可されるほかのユーザーの定義

ユーザーによって所有されているボリュームへのアクセスをほかのユーザーに許可するには:

  1. access_control ディレクトリ内にファイル users.ALL.allow または users.ALL.disallow を作成します。

    テンプレート users.SAMPLE.allow または users.SAMPLE.disallow をコピーできます。

  2. このファイルに所有者ごとのレコードを追加し、所有者のユーザー ID を左マージンに置きます。

  3. 影響を受けるユーザーを各所有者と同じ行に指定します。

  4. 次の例に示すように、各ユーザー名をスペースまたはタブで区切ります。

    owner_john   user-Allie   user-andre

    users.allow および users.disallow ファイルにリストされているユーザー名は、大文字小文字は関係なく、一意である必要があります。ユーザー名の大文字小文字は無視されます。

    所有者と同じ行にリストされていないユーザーには、所有者のボリュームへのデフォルトの (ACCESS または NOACCESS) 関係が与えられます。

    注:

    同じコマンドまたは ALL に対する users.COMMAND.allow ファイルと users.COMMAND.disallow ファイルの両方に同じ owner_ID と user_ID のペアを含めることはできません。また、同じ users.COMMAND.allow および users.COMMAND.disallow ファイル内に重複した owner_ID と user_ID のペアを含めることもできません。これには、同じ行での同じ user_ID の繰り返しが含まれます。

    1 人の所有者に対して許可されるユーザーの数が多すぎて 1 行に収まらない場合は、許可されるユーザーのリストを以降の行に続けることができます。各行が所有者 ID で始まる必要があります。

  5. オプションで、定義したボリュームアクセスポリシーの例外を確立できます。

    ユーザーには一般に、アクセス制御の下にあるボリュームへのフルアクセスが許可されるか、またはどのアクセスも許可されません。ただし、ユーザーに、ほかのユーザーのボリュームへの特定の制限されたアクセスを許可できます。

    たとえば、特定のユーザーによって所有されているボリュームのマウントまたはマウント解除はできないが、これらのボリュームの照会をすべてのユーザーに許可するポリシーを設定できます。例外は、アクセス制御によって影響を受けるすべてのコマンドに適用できます。

    特定のコマンドに対するボリュームアクセスポリシーの例外を構成するには:

    • users.COMMAND.allow または users.COMMAND.disallow ファイルを作成する必要があります (ここで、COMMAND は、許可または制限する特定のコマンドに置き換えられます)。

      users.COMMAND.allow および users.COMMAND.disallow ファイルには、下に示されているものとまったく同じように指定された名前 (コマンド名は大文字) を持つコマンドコンポーネントが含まれている必要があります。コマンドのその他のバリアント (QUERY_VOLUME など) へのアクセスの制御はサポートされていません。

      DISMOUNT 
EJECT 
LOCK 
MOUNT (1) 
MOUNT_READONLY (2) 
QUERY 
REGISTER 
SET_CLEAN 
SET_SCRATCH 
UNLOCK

      注:

      • MOUNT (1) - MOUNT ポリシーは、mount scratch にも適用されます。ポリシーは、mount readonly には適用されません

      • MOUNT_READOLNY (2) - mount readonly のためのポリシーは、mount とは別に定義されています。

      • 所有者 ID と許可されるユーザー ID のペアが重複していてはいけないこと、および許可されるユーザーのリストを以降の行に続けることに関する上の考慮事項は、禁止されるユーザーのリストにも適用されます。

    • 所有者ごとに、所有者の名前を左マージンに置き、それに続けてポリシーが適用されるユーザーを並べます。

  6. 定義するポリシーへの更新をすべて保存します。

    • acsss_config を実行します

    • 「Option 6 - "Rebuild Access Control Information"」を選択します。

    ACSLS は、この変更を動的に認識します。

ボリュームの所有権の確立

ボリュームアクセス制御は、明示的な所有権を持つボリュームにのみ適用されます。ライブラリ内の所有されていないボリュームは、すべてのユーザーからアクセスできます。ボリューム所有権を明示的に設定するには、cmd_proc インタフェースを使用します。

ACSSA>set owner "daffy" volume V00100-V00199 
Set: owner set for volumes V00100-V00199 
Set: Set completed, Success.

空の文字列を使用すると、同様の方法で所有権を削除できます。

ACSSA> set owner "" volume V00100-V00199 
Set: owner set for volumes V00100-V00199

この操作によって、範囲内のすべてのボリュームから所有権がクリアされます。詳細は、set ownerを参照してください。

ボリューム所有権は、watch_vols ユーティリティーで自動的に設定できます。詳細は、watch_volsを参照してください。

所有権ポリシー

所有権を自動的に設定および削除するためのポリシーは、ACSLS でも定義できます。たとえば、マウントされたすべてのスクラッチボリュームが、それをマウントしたユーザーによって所有されるようになるポリシーを設定できます。それ以降、そのボリュームはそのユーザーによって所有されます。同じポリシーを、そのボリュームがスクラッチステータスに戻された場合は常に所有権を削除するように拡張することもできます。ポリシーを記述して、挿入されたすべてのボリュームがデフォルトユーザーか、その挿入をリクエストしたユーザーか、またはそのボリュームが以前に所有されていた場合は以前の所有者に割り当てられるようにもできます。この機能によって、非常に高い柔軟性が提供されます。

所有権ポリシーは、access_control ディレクトリ内に存在する ownership.assignments ファイルで定義されます。このファイル内のポリシーを、enter、automatic enter、set scratch、または mount scratch 操作ごとに所有権を自動的に割り当てまたは割り当て解除するように設定できます。ownership.assignments ファイルでは、デフォルトの所有者を定義できます。あるボリュームでこれらのいずれかの操作が実行された場合は常に、その所有権を次に割り当てることができます。

  • Owner_default (デフォルトの所有者)

  • 同じ (以前の所有者)

  • リクエスタ (現在のリクエストを発行したユーザー)

  • 未所有 (ボリュームの所有権を取り消します)

    注:

    所有権ポリシーを定義するための手順については、ownership.assignments ファイルで詳細に説明されています。このファイルには、ボリューム所有権を設定するために使用できるコマンドの完全なリストが含まれています。

  • 定義するポリシーへの更新をすべて保存します。

    • acsss_config を実行します

    • 「Option 6 - Rebuild Access Control Information」を選択します。

    ACSLS は、この変更を動的に認識します。

所有権の確認

所有権を確認するには、owner_id.volrpt テンプレートを使用して volrpt を実行できます。

cd ~acsss/data/external/volrpt 
volrpt -f owner_id.volrpt

これにより、ライブラリ内のすべてのボリュームの表示が生成され、それぞれに関連付けられた所有者とともに一覧表示されます。

ボリュームアクセスのサマリー

ボリュームアクセス制御では、次のコマンドがサポートされています。

dismount* 
display 
eject 
enter 
lock 
set_clean 
set_scratch 
mount 
query_mount 
query_scratch 
query_volume 
unlock

force オプションが StorageTek ACSLS にボリューム ID を無視し、ボリュームを無条件にマウント解除するよう指示するため、dismount force にアクセス制御は適用されません。

次の表は、ボリュームアクセス制御が有効になっているときに適用されるコンテキストについて要約したものです。

表7-1 ボリュームアクセスが有効

ボリュームに対するデフォルトアクセスは ACCESS アクセスが
許可される		 アクセスが
拒否される

アクセスは cmd_proc 経由である

X

  

指定されたボリュームは所有されていない

X

  

ユーザーはボリュームの所有者である

X

  

ユーザーは users.ALL.disallow 内の所有者に関連付けられている

  

X

ユーザーが users.ALL.disallow 内の所有者に関連付けられていない場合

X

  

表7-2 ボリュームアクセスが有効

ボリュームに対するデフォルトアクセスは NOACCESS アクセスが
許可される		 アクセスが
拒否される

アクセスは cmd_proc 経由である

X

  

指定されたボリュームは所有されていない

X

  

ユーザーはボリュームの所有者である

X

  

ユーザーは users.ALL.allow 内の所有者に関連付けられている

X

  

ユーザーが users.ALL.allow 内の所有者に関連付けられていない場合

  

X

コマンドアクセス制御

コマンドアクセス制御では、ACSLS 管理者が特定のクラスのコマンドを、ネットワーク全体にわたる特定のクライアントアプリケーションまたは特定のユーザーに制限できます。制御されたアクセスは、ACSAPI 経由で送信されるユーザーコマンドにのみ適用され、cmd_proc を使用してコマンドを送信するローカルユーザーには適用されません。

ACSLS でコマンドアクセス制御を構成するプロセスには、3 つの手順が含まれます。

ACSLS でコマンドアクセス制御をはじめて構成する場合は、次の手順に従います。

  1. ACSLS でコマンドアクセス制御を有効にします。

  2. クライアント ID をユーザー名に関連付けます。

  3. どのユーザーがどのようなコマンドを使用できるかを定義します。

コマンドアクセス制御の有効化

ACSLS でコマンドアクセス制御を有効にするには、

  1. 構成ユーティリティー acsss_config を実行します。

    メインメニューが表示されます。

  2. 「Option 4 - Set Access Control Variables」を選択します。

    各変数が一度に 1 つずつ表示され、その現在の設定が表示されます。

  3. 現在の設定またはデフォルト設定を受け入れるには、Enter をクリックします。

  4. ユーティリティーにメッセージ Access control is active for commands が表示されたら、「TRUE」を選択して Enter をクリックします。

  5. メッセージ「Default access for commands」が表示されたら、次を実行します。

    • すべてのユーザーにすべてのコマンドへのアクセスを許可する場合は、「ACCESS」を選択します。

      特定のユーザーのコマンド発行をブロックするには、それらのユーザーを command.ALL.disallow ファイルまたは特定の command.XXX.disallow ファイルにリストしておく必要があります。ここでは:

      XXX は、アクセス制御の対象となるコマンドです

    • コマンドへのユーザーアクセスを拒否する場合は、「[NOACCESS]」を選択します。

      特定のユーザーのコマンド発行を許可するには、それらのユーザーを command.ALL.allow ファイルまたは特定の command.XXX.allow ファイルにリストしておく必要があります。

      注:

      コマンドへのアクセスが拒否されたインスタンスをログに記録する場合は、そのプロンプトに応答して「TRUE」を入力します。

      注:

      コマンドアクセスを有効または無効にした場合は常に、変更を有効にするために ACSLS を再起動する必要があります。

クライアント ID のユーザー名への関連付け

Associating a client identity with a user nameの手順を参照してください。

どのユーザーがどのようなコマンドを使用できるかの定義

このプロセスは、コマンドアクセス制御を有効にしたときに選択したデフォルトの動作によって異なります。$ACS_HOME/data/external/access_control ディレクトリ内にポリシーファイルを作成する必要があります。

  • 上で定義したデフォルトの動作が [NOACCESS] である場合は、すべての ACSLS コマンドへのアクセスを許可する各クライアントのユーザー ID を含む command.ALL.allow ファイルを作成する必要があります。各ユーザー ID をこのファイル内の個別の行にリストするようにしてください。

    特定のユーザーに特定のコマンドのみを許可する場合は、そのユーザーが実行を許可されるコマンドごとに command.XXX.allow ファイルを作成する必要があります。たとえば、特定のユーザーにボリュームをライブラリに挿入する権限を許可するには、command.ENTER.allow という名前のファイルを作成し、認定された各「挿入」ユーザーの ID をファイル内の個別の行にリストします。

  • 上で定義したデフォルトの動作が [ACCESS] である場合は、すべての ACSLS コマンドへのアクセスを許可しない各クライアントのユーザー ID を含む command.ALL disallow ファイルを作成する必要があります。各ユーザー ID をこのファイル内の個別の行にリストするようにしてください。

    注:

    同じコマンドまたは ALL に対する command.XXX.allow ファイルと command.XXX.disallow command.XXX ファイルの両方に同じ user_ID を含めることはできません。

コマンドアクセス制御の許可および禁止ファイルのコマンド名

command.XXX.allow および command.XXX.disallow ファイルには、下に示されているものとまったく同じように指定された名前 (コマンド名は大文字) を持つコマンドコンポーネントが含まれている必要があります。コマンドのその他のバリアント (QUERY_VOLUME など) へのアクセスの制御はサポートされていません。

AUDIT 
CANCEL 
CHECK_REGISTRATION 
CLEAR_LOCK 
DEFINE_POOL 
DELETE_POOL 
DISMOUNTDISMOUNT_FORCE 
DISPLAY 
EJECT 
ENTER      (1) 
IDLE 
LOCK 
MOUNT      (2) 
QUERY 
QUERY_LOCK 
REGISTER 
SET_CAP 
SET_CLEAN 
SET_OWNER 
SET_SCRATCH 
START 
UNLOCK 
UNREGISTER 
VARY

注:

ENTER (1) - ポリシーは仮想挿入および手動挿入に適用されますが、自動挿入には適用されません。MOUNT (2) - ポリシーは、mount scratch および mount readonly にも適用されます。

次の表は、コマンドアクセスがいつ許可されるかを判定するためのクイックリファレンスとして使用してください。

表7-3 コマンドアクセスが有効

コマンドに対するデフォルトアクセスは NOACCESS アクセスが
許可される		 アクセスが
拒否される

リクエストは cmd_proc から入力された

X

  

user_ID は command.COMMAND.allow にリストされている

X

  

user_ID は command.ALL.allow にリストされている

X

  

- - その他のすべての状態 - -

  

X

表7-4 コマンドアクセスが有効

コマンドに対するデフォルトアクセスは ACCESS アクセスが
許可される		 アクセスが
拒否される

リクエストは cmd_proc から入力された

X

  

user_ID は command.COMMAND.disallow にリストされている

  

X

user_ID は command.ALL.disallow にリストされている

  

X

- - その他のすべての状態 - -

X

  

  • 定義するポリシーへの更新をすべて保存します。

    • acsss_config を実行します

    • 「Option 6 - "Rebuild Access Control Information"」を選択します。

    ACSLS は、この変更を動的に認識します。

アクセス制御メッセージのロギング

ユーザーがアクセスを拒否されたために失敗したすべてのトランザクションをログに記録するためのポリシーを設定できます。メッセージには、ユーザー名と試行されたコマンドが表示されます。

アクセス制御のロギングを有効にするには:

  1. acsss_config を実行し、「Option 4 - "Set Access Control Variables"」を選択します

  2. 「Messages will be logged when access to commands or volumes is denied」のプロンプトで、[FALSE] を [TRUE] に変更します。

  3. 「Option 6 - "Rebuild Access Control Information"」を選択します。

ACSLS はこの変更を認識し、コマンドのリクエストが拒否されるたびにロギングを開始します。