test

Trusted Solaris のラベル管理

第 1 章 Trusted Solaris ラベルエンコーディングの概要

この章では、label_encodings(4) ファイルの作成を担当する管理者の準備項目を説明します。次の項目を参考にして、ユーザーの組織のどの管理者が、ファイル作成を行うべきかを割り出し、また何を行う必要があるかを理解してください。

このマニュアルは、セキュリティ管理者役割になるユーザーを対象読者としています。この章ではまず、次のことから説明します。

注 -

この章は、『Trusted Solaris 管理の概要』の「ラベル」をユーザーが読み、理解していることを前提にしています。

注 -

ラベル非表示で実行する予定であっても、この章と次章は、すべて読んでください。また、「ラベル非表示での実行」を必ず参照してください。

政府支給のラベルファイルまたは既存のラベルファイルを使用する場合

組織によっては、政府支給のlabel_encodings(4) ファイルを使用するところもあります。詳細な説明とリファレンスについては、Trusted Solaris 管理者マニュアルセット中に含まれている『コンパートメントモードワークステーションのラベル作成: エンコード形式』(805-8096-10) の「はじめに」を参照してください。Sun では、政府支給ファイルを LOCAL DEFINITIONS セクションで拡張しています (LOCALとは、Sun の実装に対して local (局所) という意味)。この LOCAL DEFINITIONS では、さまざまなラベル変換オプションを設定し、ラベルに色を割り当てています。

政府支給の label_encodings ファイルを持つサイトのセキュリティ管理者役割は、/etc/security/tsol 中の Trusted Solaris 用 label_encodings ファイルのいずれかの LOCAL DEFINITIONS: セクションを修正して、セクションを組織の label_encodings ファイルに追加してからインストールする必要があります。第 4 章「LOCAL DEFINITIONS セクションの Sun 拡張機能の変更」では、Sun の拡張をユーザーのファイルに追加する方法、およびユーザーのサイトに合わせて拡張を修正する方法を説明します。

サイトにラベルファイルがない場合

ほとんどの組織では、インストールの前または後に、セキュリティ管理者役割が label_encodings(4) ファイルのバージョンを作成します。

付録 A 「使用例: ラベルエンコーディングファイル」 は、第 5 章「使用例: 組織のラベルの計画」 に説明されている計画に基く label_encodings ファイルの例を示します。

インストール後

サンプルの label_encodings.simple ファイルが、/etc/security/tsol ディレクトリにインストールされているので、修正して使用、またはそのまま使用できます。付録 A 「使用例: ラベルエンコーディングファイル」 の最初の部分では、実例ファイルに定義されているラベルとコンパートメントについて説明しています。あるいは、label_encodings ファイルのデフォルト版または /etc/security/tsol の下にある他の label_encodings ファイルのいずれかを、サイトの要件に合うように修正することもできます。

インストール前

あらかじめ label_encodings(4) ファイルを準備するには、セキュリティ管理者役割は、付録 A 「使用例: ラベルエンコーディングファイル」 の実例を手動でコピーし、コピーした実例に修正を行います。または、このマニュアルにある例を使用して label_encodings ファイルを作成することもできます。

複雑な関係のラベルの作成

このマニュアルでは、一部のインストールで必要となる、格付け、インバース語句、階層的な語句の複雑な関係をエンコーディングする方法については示していません。詳細については、『コンパートメントモードワークステーションのラベル作成: エンコード形式』(805-8096-10) を参照してください。このマニュアルは、Trusted Solaris マニュアルのセットの一部です。

ラベルエンコーディング関連の概念を再確認する

ラベルの型の区別や、アクセス制御の決定時のラベルの比較については、『Trusted Solaris ユーザーズガイド』および『Trusted Solaris 管理の概要』を参照してください。

『Trusted Solaris 管理の手順』の「特定の役割への移行と役割ワークスペースでの作業」では、セキュリティ管理者がセキュリティ管理者役割として行う予備知識について説明しています。セキュリティ管理者役割は、ラベルを設定し、セキュリティ管理に関するその他の作業を行うことです。

次の定義では、ラベルの定義とエンコーディングに直接関連するラベルの基本概念をいくつか見直します。それらの基本概念は、サイトに対する機密ラベルとユーザー認可上限の設定方法を決定する場合に必要となります。ここでの用語、理解できないその他の関連用語の詳細については、Intro(2) のマニュアルページの定義も参照してください。

ラベルの使用方法

UNIX システムでは、ほとんどすべて (スプレッドシート、プリンタ、レター、マニュアルの章、メールメッセージなど) をファイルとして扱います。ファイルはディレクトリに保存されます (ウィンドウシステムでは、ファイルをドキュメント、ディレクトリをフォルダと呼び、どちらもアイコンで表示される)。

どんな作業を行う場合でも、ファイルやディレクトリにアクセスしなければならないので、ラベルは、すべてのユーザー、管理者、全ファイル、全ディレクトリに割り当てられます。アクセスの決定が Trusted Solaris 必須アクセス制御機構によって行われるときに、ラベルが比較されます。

ラベルの定義方法

ラベルコンポーネントは、セキュリティ管理者役割によって /etc/security/tsol/label_encodings ファイルで定義されます。次の表は、label_encodings ファイルの必須のセクションで、各セクションの開始を示すキーワードを示しています。各セクションでセキュリティ管理者役割が定義するコンポーネントについては、この章の後半で説明します。

注 -

Trusted Solaris 7 で情報ラベルが使用されていない場合でも、INFORMATION LABELS セクションが存在して、SENSITIVITY LABELS セクションで指定されている各コンパートメントに対して、語句が定義されている必要があります。

VERSION=

CLASSIFICATIONS:

INFORMATION LABELS:

SENSITIVITY LABELS:

CLEARANCES:

CHANNELS:

PRINTER BANNERS:

ACCREDITATION RANGE:

LOCAL DEFINITIONS:

認可上限、最下位のラベル、アカウントラベルの範囲の概要

認可上限ラベルと最下位のラベルは、各新規ユーザーと役割アカウントに割り当てられます。これらのラベルは、ユーザーマネージャの「ラベル (Labels)」ダイアログボックスを使用してアカウントのセキュリティ面の設定を行うときに、セキュリティ管理者役割によって割り当てられます。認可上限はアカウントが作業を行えるラベルの上限を設定し、最下位のラベルは下限を設定します。認可上限ラベルは、label_encodings の CLEARANCES セクションで定義されています。「認可上限ラベルの詳細」を参照してください。

アカウントラベルの範囲

ユーザーや役割がいつでも作業を行えるラベルの集合を「アカウントラベルの範囲」といいます。アカウントラベルの範囲の上限はアカウントの認可上限で、下限はアカウントの最下位のラベルです。1 つのラベルだけでしか作業が許可されていないユーザーの認可上限は、最下位のラベルと同じです。システムの全ユーザーが使用できるすべてのラベルの中からアカウント認可上限を選択する方法については、「認可範囲の例」を参照してください。

認可上限の 2 つのタイプ

認可上限には、アカウントの作成時に割り当てられるアカウント認可上限と「セッション認可上限」の 2 種類があります。社員がシステムにログインするとき、その人はログインからログアウトまでの間の有効なセッション認可上限を指定します。セッション認可上限は、アカウント認可上限の範囲内になければなりません。セッション認可上限の詳細については、次の項および 「セッションの許可上限の指定方法」を参照してください。

セッション認可上限

セッション認可上限を使用すると、複数のラベルで作業を行える設定のアカウントが特定のセッションで使用できるラベルの範囲を自主的に制限できます。セッション認可上限のデフォルト値は、アカウント認可上限です。それより下位の認可上限が選択される場合もあります。

セッション認可上限は、セッション中の通常のユーザーに代わって処理が行われる範囲の上限を設定できます。役割アカウントのセッション認可上限は、アカウント認可上限と同じです。ユーザーの最下位のラベルは常に、セッション中のアカウントが作業できるラベルの下限です。

アクセス対象のラベルの範囲

ラベルの範囲の割り当ては、次のものに割り当てられます。

ラベルのいろいろな設定方法については、『Trusted Solaris 管理の手順』を参照してください。このマニュアルの「デバイス割り当ての管理とデバイスラベル範囲の設定」に、ラベルの範囲をデバイスに設定する方法が説明されています。

ラベルの範囲設定の対象

ラベル範囲は、次のラベルを制限します。

ラベルは、情報の実際の機密レベルや情報の取り扱い方を決定する場合にも使用します。さらに、ラベルは、自動的に電子メールメッセージに割り当てられたり、プリンタ出力として印刷されます。

ラベルの型

前述した認可上限ラベル以外に、ラベルには、機密ラベルと情報ラベルという 2 つの型があります。それぞれのサイトの label_encodings(4) ファイルに次のそれぞれのラベルから 1 つずつ定義する必要があります。

注 -

Trusted Solaris 7 で情報ラベルが使用されていない場合でも、情報ラベルを必ず 1 つ定義してください。

どの型のラベルにも、label_encodings(4) ファイルで定義された「格付け」とオプションの「語句」というコンポーネントがあります。

格付け

格付けは、ラベル、または認可上限の階層的な部分です。各ラベルには、1 つしか格付けがありません。各ラベルの内部表現では、格付け値を格納するのに 15 ビットを使用できます。

格付けフィールド 

15 ビット (32,767 個の値)。値は 256 個に制限される 

ラベル変換ソフトウェアでは、格付け値を 256 個に制限しています。1 〜 255 の数値 (整数) が、label_encodings ファイル中の各格付けに割り当てられています。値 0 は、ADMIN_LOW 管理ラベルに予約されています (「管理ラベル」も参照)。

ラベルの格付け部分は、ファイルやディレクトリに含まれる情報の機密度に基づいた機密保護の相対的なレベルを示します。ユーザーやアプリケーションを実行するプロセス、ユーザーのコマンドなどに割り当てられた認可上限において、格付けは信頼度のレベルを示します。

高い値を持つ格付けは、低い値の格付けよりも優位です (優位性に関しては、「ラベルの優位性」を参照)。

民間 (Sun の情報保護ラベル) 

値 

米国政府 

値 

 

Registered

 

6

 

Top Secret

 

6

 

Need to Know

 

5

 

Secret 	

5

 

Internal Use Only

 

4

 

Confidential

 

4

 

Public

 

1

 

Unclassified

 

1

機密ラベル、情報ラベル、および認可上限を少なくとも 1 つずつ定義する必要があります。すべてのタイプのラベルが、少なくとも 1 つ、格付けコンポーネントを必要とします。ラベルのセットは、各ラベルに対する 1 つの格付けだけで、語句を含めないことができます。

格付けは、label_encodings(4) の CLASSIFICATIONS セクションで、すべてのタイプのラベルに対して 1 度定義します。

格付けの計画に次の表を使用できます。アスタリスク (*) は省略可能な項目です。

表 1-1 格付けの計画

name= 

sname=/*aname=  

value= 

*initial compartments=ビット番号/語句 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

語句

語句は、格付け以外のラベルのコンポーネントです。どの型のラベルも同じ格付けを使用するのに対して、それぞれのラベルの型ごとに定義された語句は、異なっていることがあります。これは、同じビットでエンコーディングされたり、文字通り同じものを指す場合でも、同様です。ラベルコンポーネントとしての語句は、次のいずれかです。

各ラベルの各セクションに対応する label_encodings(4) ファイルのサブセクションを次の表に示します。サブセクションでは、ラベルの語句を定義し、オプションとして語句を併用する場合の制限を加えます。

表 1-2 ラベル定義セクション内のサブセクション

セクション 

サブセクション 

SENSITIVITY LABELS: 

WORDS: 

REQUIRED COMBINATIONS: 

COMBINATION CONSTRAINTS: 

CLEARANCES: 

WORDS: 

REQUIRED COMBINATIONS: 

COMBINATION CONSTRAINTS: 

省略形 

名前 

REG 

REGISTERED 

NTK 

NEED_TO_KNOW 

IUO 

INTERNAL_USE_ONLY 

EMG 

EXECUTIVE MANAGEMENT GROUP 

SALES 

SALES 

FIN 

FINANCE 

LEG 

LEGAL 

MRKTG 

MARKETING 

HR 

HUMAN RESOURCES 

ENG 

ENGINEERING 

MANU 

MANUFACTURING 

SYSADM 

SYSTEM ADMINISTRATION  

NDA 

NON-DISCLOSURE AGREEMENT 

コンパートメント

コンパートメントは、機密ラベル、または認可上限で使用する「語句」のオプションの 1 つです。他のトラステッドシステムでは、コンパートメントをカテゴリと呼ぶことがあります。また、政府機関ではチャネルと呼ぶこともあります。

コンパートメント語句は、割り当てられたビットで構成され、それらは、もともと階層的なものではありません。コンパートメント語句間に階層関係を確立することもできますが、それらの階層は、1 つのコンパートメント語句のビットを他のコンパートメントのビットの中に含めるという規則に基づいて形成されたものです。

コンパートメントの例

コンパートメント語句の使い方はさまざまです。たとえば、興味のある分野、ワークグループ、部署、部門、あるいは地理的な区域などを表すのに使用されます。ラベル内のコンパートメント語句からファイルやそのファイルにアクセスする権利のある人々を特定できます。たとえば、ラベルの NEED TO KNOW の格付けは、ENGINEERING、 HUMAN RELATIONS、LEGAL などの会社の部署名で定義された 1 つまたは複数のコンパートメント語句の存在によって制限できます。NEED TO KNOW LEGAL ファイルは、認可上限に NEED TO KNOW 格付けと LEGAL コンパートメント語句を持つ人々だけが利用できます。

もう 1 つの例として、政府官公庁や国際的な企業は、合衆国、メキシコ、中国、日本、アフリカといった各国あるいは各大陸ごとにコンパートメント語句を作成する場合もあります。大きな企業であれば、SunSoft、SunFed、SMCC、SunConnect、JavaSoft のように各部門ごとにコンパートメントを作成する場合もあります。

コンパートメント語句の定義方法

コンパートメント語句は、ラベルの型ごとに WORDS サブセクションでオプションとして定義されます。各コンパートメント語句は、1 つまたは複数のビットに割り当てられます。短形式名 (sname) が SUNFED、コンパートメントビットとして 40 - 50 を割り当てられた SUN FEDERAL コンパートメント語句の例を次に示します。

例 1-1 機密ラベルのコンパートメントの定義例


SENSITIVITY LABELS:

WORDS:

name= SUN FEDERAL; sname= SUNFED; compartments= 40-50;

各ラベルには、その格付けフィールドとともに、256 ビットのコンパートメントフィールドが 1 つあります。各ビットには、表 1-3 に示すように、コンパートメントをまったく割り当てないことも、1 つ以上のコンパートメント語句を割り当てることもできます。各コンパートメント語句には、1 つ以上のコンパートメントビットを割り当てることができます。256 ビットの使用可能ビットから、作成できるコンパートメント語句の数は、実質的には無限です。

表 1-3 格付けおよびコンパートメントのコンポーネントに使用するビット

格付けフィールド 

コンパートメントフィールド 

15 ビット (32,767 個の値)。値は 256 個に制限される 

256 ビット 

コンパートメントビットの割り当ては次の表で管理します。

表 1-4 コンパートメントビットの管理表

 

 

 

 

 

 

 

 

 

 

 

           
                                 

機密ラベル (SL): 使い方とフォーマット

ファイルやディレクトリの機密ラベルは、固定されたセキュリティラベルです。新規に作成されたファイルやディレクトリには、その作成プロセスの機密ラベルが割り当てられます。通常、それは、プロセスを開始したワークスペースの機密ラベルです。機密ラベルは、次のような人たちによって明示的なアクションがとられない限り、同じ状態を保ちます。

機密ラベルのコンポーネント

各機密ラベルは、以下の表に示すように 1 個の格付けと 0 個以上のコンパートメントから構成されています。ここで name は名前、word は語句を示します。

表 1-5 機密ラベルのコンポーネント

格付け 

コンパートメント 

name 

[word1, word2, ..., wordN]

次の表の例は、ある機密ラベルでは、コンパートメントがなく、格付けは INTERNAL_USE_ONLY であるのに対して、もう一方の機密ラベルは、格付けは NEED_TO_KNOW で、コンパートメントは ENGINEERING と SALES の 2 つであることを示しています。

表 1-6 機密ラベルのコンポーネント例

格付け 

コンパートメント 

 

INTERNAL_USE_ONLY

なし 

NEED_TO_KNOW 

ENGINEERING, SALES 

機密ラベルの内部表現

格付けフィールド以外にも、各機密ラベルには、表 1-7 に示すようなコンパートメント用の 256 ビットフィールドがあります。ラベルは、1 つ以上のコンパートメントを含みます。ただし、まったく含まない場合もあります。各コンパートメント語句には、1 ビット以上のコンパートメントビットが割り当てられています。同じコンパートメントビットを、複数の語句に割り当てることが可能です。

表 1-7 格付けおよびコンパートメントのコンポーネントに使用するビット

格付けフィールド 

コンパートメントフィールド 

15 ビット 

32,767 個の値 

値は 256 個に制限される 

256 ビット 

コンパートメントとビットの可能な組み合せ: 10 の 70 乗 

SL の昇格および降格の承認

機密ラベルの変更が行えるのは、プロファイルのいずれか 1 つに適切な承認を持つユーザーまたは管理者だけです。機密ラベルを上位のものに優先させることを「機密ラベルのファイルの昇格」といい、下位のものに優先させることを「機密ラベルのファイルの降格」といいます。auth_desc(4) も参照してください。

ユーザーが 1 つのラベルに制限される理由

システムが 1 つの機密ラベルだけで実行するように設定されていると、そのシステムの管理的な立場にないユーザーアカウントの作業はすべてその 1 つの機密ラベルに制限されます。このようなシステムでは、すべてのユーザーアカウントの認可上限は、必然的にそのアカウントの最下位の機密ラベルと同等に設定されます。

複数の機密ラベルで実行するシステムでは、セキュリティ管理者役割がアカウントの認可上限を最下位の機密ラベルと同等に設定していれば、すべてのアカウントの作業が 1 つの機密ラベルに制限されます。

複数の機密ラベルを含むアカウントラベルの範囲を持つアカウントをセキュリティ管理者役割が設定していれば、ユーザーは任意に作業中のセッションを 1 つの機密ラベルに限定できます。詳細については、次の項の「複数の SL を持つアカウントによる各セッションの SL の指定方法」を参照してください。

セッションの許可上限の指定方法

ユーザーのアカウントが複数のラベルを使用できるように設定されている場合、ユーザーがログインして Trusted Solaris ホスト上でセッション開始直後に次の方法によってセッション中に使用できる機密ラベルを指定できます。

選択された 1 つのラベルまたはセッション認可上限は、ログインからログアウトまでセッション中は、一貫して有効です。セッション中、ユーザーは任意の機密ラベルで作業を行うことができます。この機密ラベルはセッション認可上限よりも下位にありますが、ユーザーの最下位のラベルよりは上位にあります。「有効なラベル」で説明するように、機密ラベルは、label_encodings(4) ファイルに定義された有効なラベルでなくてはなりません。

ラベル付けされたワークスペース

Trusted Solaris のウィンドウシステムは、ラベルを認識する CDE ウィンドウシステムです。CDE のワークスペースは、 1 つのセッションを通して、ユーザーが複数の機密ラベルで作業できるようにする上で重要な役割を果たします。

ユーザーが初めてログインすると、起動した最初のワークスペースにそのユーザーの最下位の機密ラベルが割り当てられます (フロントパネルのワークスペーススイッチ部分に同じ最下位の機密ラベルで新たに 3 つの追加ワークスペースのボタンが作成される)。ユーザーは、新たにワークスペースを起動して、任意のワークスペースの機密ラベルを変更することができますが、ワークスペースの機密ラベルをセッション認可上限より上位に設定することはできません。これによってユーザーは、セッション認可上限より高い機密ラベルでは作業ができなくなります。ワークスペースの機密ラベルは、そのワークスペースで作成される新しい各ウィンドウに割り当てられます。

マルチレベルセッションを許容されたユーザーは、任意のワークスペースのラベルを付け直すことができます。ユーザーはフロントパネルのスタイルマネージャの「起動 (Startup)」ダイアログボックスを使用して、ログイン時に起動するワークスペースとアプリケーションを指定することができます。2 回目以降のログインで起動する最初のワークスペースはユーザーによって指定できるため、最初のログイン以降のログインで起動する最初のワークスペースの機密ラベルは、アカウントのラベルの範囲内であれば、ユーザーが選択する任意の機密ラベルにすることができます。

認可上限ラベルの詳細

認可上限ラベルについては、「認可上限、最下位のラベル、アカウントラベルの範囲の概要」を参照してください。認可上限ラベルのコンポーネントと内部表現は、機密ラベルと同じです。

認可上限ラベルのコンポーネント

認可上限ラベルは、次の表に示すように 1 個の格付けと 0 個以上のコンパートメントから構成されています。ここで name は名前、word は語句を示します。

表 1-8 認可上限ラベルのコンポーネント

格付け 

コンパートメント 

name 

[word1, word2, ..., wordN]

表 1-9 の例は、ある機密ラベルでは、コンパートメントがなく、格付けは INTERNAL_USE_ONLY であるのに対して、もう一方の機密ラベルでは、格付けは NEED_TO_KNOW で、コンパートメントは ENGINEERING と SALES の 2 つがあることを示しています。

表 1-9 機密ラベルのコンポーネント例

格付け 

コンパートメント 

INTERNAL USE ONLY 

なし 

NEED TO KNOW 

ENGINEERING, SALES 

認可上限ラベルの内部表現

格付けフィールド以外にも、認可上限ラベルにはそれぞれ、次の表に示すようなコンパートメント用の 256 ビットフィールドがあります。

表 1-10 格付けおよびコンパートメントのコンポーネントに使用するビット

格付けフィールド 

コンパートメントフィールド 

15 ビット (32,767 個の値)。値は 256 個に制限される 

256 ビット 

アクセス制御の決定における SL と認可上限の使用方法

アクセス制御の決定を行うときに機密ラベルと認可上限が比較されます。アプリケーションを実行するプロセスの認可上限はセッションの認可上限と同じです。このプロセスの機密ラベルと認可上限は、アプリケーションがアクセスしようとする対象の機密ラベルと比較されます。機密ラベルの優位性が比較されます。機密ラベルが比較されるときに適用される必須アクセス制御の規則の詳細については、Intro(1) の「定義」セクションを参照してください。

ウィンドウシステム内では、通常、プロセスの機密ラベルがアクセスの対象の機密ラベルと同等でなければ、アクセスが行われません。同位読み取り / 同位書き込み規則に対する顕著な例外は、電子メールの読み手で、これには、上位書き込み/下位読み取り (write up/read down: WURD) 規則が適用されます。上位書き込みはセッションの認可上限によって制限されます。

必須アクセス制御の決定例

機密ラベルが PUBLIC のワークスペースでユーザーがテキストエディタを起動すると、そのテキストエディタを実行するプロセスにもワークスペースと同じ機密ラベルが割り当てられます。

アクセス制御の決定に使用される 2 つの機密ラベルを比較したものを 図 1-1 に示します。ユーザーは、INTERNAL_USE_ONLY という機密ラベルの付いたワークスペースにいます。テキストエディタを起動すると、テキストエディタを実行しているプロセスの機密ラベルが自動的に現在作業中のワークスペースの機密ラベルに設定され、テキストエディタは、INTERNAL_USE_ONLY というラベルを表示します。テキストエディタを使用して編集を行うためにファイルを開こうとすると、そのテキストエディタの機密ラベルとファイルの機密ラベルが比較されます。この例では、2 つの機密ラベルが同等なので、アクセスが行われます。

図 1-1 テキストエディタの SL と編集対象のファイルの SL との比較

Graphic

ラベルの優位性

いずれの型のラベルであれ、他のラベルと比較したときに、そのラベルのセキュリティレベルが他のセキュリティレベルよりも同等か高い場合は、最初のラベルが 2 つ目のラベルよりも「優位である」といいます。このセキュリティレベルの比較は、格付けとラベルのコンパートメントに基づいています。優位なラベルの格付けは、2 つ目のラベルの格付けと同等かそれよりも高くなければなりません。優位なラベルには、もう一方のラベルのコンパートメントのすべてが含まれていなければなりません。

2 つのラベルが同等な場合は、「互いに優位である」といいます。優位性のもう 1 つの種類は、「完全な優位性」と呼ばれるものです。2 つのラベルを比較したとき、最初のラベルが 2 つ目のラベルよりもセキュリティレベルが高ければ、「完全に優位である」といいます。完全な優位性には、同等の部分がありません。最初のラベルの格付けは 2 つ目の格付けよりも高く、最初のラベルには 2 つ目のラベルのコンパートメントの内容がすべて含まれていなければなりません。また、両方のラベルの格付けが同じであれば、最初のラベルは 2 つ目のラベルのコンパートメントをすべて含んでおり、さらに、最初のラベルには 2 つ目のラベルに比べて 1 つ以上コンパートメントが多くなければ、2 つ目のラベルよりも完全に優位であるとはいえません。

ラベルの変換

プログラムがラベルの操作を行うたびにラベルの変換が行われます。たとえば getlabel(1) のようなプログラムがファイルのラベル名を得ると、ラベルのバイナリ表現が人が読める形式に変換されてからユーザーに画面で表示されます。Trusted Solaris システムでは、呼び出し元のプロセスの機密ラベルが変換対象のラベルよりも優位である場合に限り、ラベル変換を行うことができます。プロセスの SL がそのラベルよりも優位でなければ、そのプロセスでラベルを変換しようとしても変換することはできません。sys_trans_label 特権を使用すると、この制約を無視することができます。

したがって、たとえばあるプログラムが、その有効な特権セット中に sys_trans_label 特権を持っている場合には、そのプロセスのラベルよりも優位なラベルを変換できます。

Trusted Solaris 7 の情報ラベル

Trusted Solaris 7 は、情報ラベルを使用しません。label_encodings(4) ファイルに INFORMATION LABELS WORDS セクションが定義されていないと、chk_encodings(1M) ユーティリティは異常終了します。SENSITIVITY LABELS セクションで定義した WORDS を INFORMATION LABELS セクションにコピーおよびペーストすることによって、この要件が満たされます。

ラベルに略語を使用しない場合

機密ラベルの名前をわかりやすくし、省略語や頭字語を避けたい場合には、その長形式名と等しい格付けと語句の短形式名を指定できます。格付けの長形式名を短形式名と等しく指定すると、完全な機密ラベル名だけが、[ ] 内に表示されます。したがって、たとえば、機密ラベルが INTERNAL_USE_ONLY の場合に、セキュリティ管理者役割が、長形式名と同じ短形式名を定義すると、機密ラベルは、[INTERNAL_USE_ONLY] と表示されることになります。

管理ラベル

ADMIN_LOW と ADMIN_HIGH の 2 つのデフォルトの管理ラベルは常に定義されます。

この 2 つの管理ラベルは、次のどの型のラベルに対しても常に自動的に定義されます。

ADMIN_LOW は、システム内で最下位のラベルで、格付け値が 0 で、コンパートメントもマーキングもありません。その他のラベルはすべて、この ADMIN_LOW より優位です。

ADMIN_HIGH は、システム内で最上位のラベルで、格付け値が 32767 です。システム内で最上位にあるため、この ADMIN_HIGH 機密ラベルと ADMIN_HIGH 認可上限の 256 個のコンパートメントビットはすべて 1 に設定されています。ADMIN_HIGH ラベルは、他のどのラベルよりも優位です。

システムファイルと一般的に使用される実行可能ファイルには、ADMIN_LOW 機密ラベルが割り当てられます。システムログファイルのような通常のユーザーが見てはならないデータを含むファイルはすべて、ADMIN_HIGH レベルで取り扱われます。管理ラベルは、システムファイルを保護するために機密ラベルとして使用されるだけでなく、情報ラベル、認可上限、デフォルトの管理役割の最下位のラベルに使用されます。

管理ラベルの名前に関する問題

管理ラベルの名前は変更する必要はありませんが、サイトのセキュリティ管理者役割は次のことを行うこともできます。

管理ラベルの名前の変更

サイトのセキュリティ管理者役割は、label_encodings(4) ファイル (次の例を参照) の 2 行のコメント行を有効にしたり、編集したりできます。それによって、管理ラベルの代替名と交換します。

例 1-2 label_encodings ファイルの管理ラベルの名前の変更


LOCAL DEFINITIONS:

*
*       The names for the administrative high and low name are set to
*       site_high and site_low respectively by the example commands below.
*
*       NOTE:   Use of these options could lead to interoperability problems
*               with machines that do not have the same alternate names.

*Admin Low Name= site_low;
*Admin High Name= site_high;

必要に応じて、第 4 章「LOCAL DEFINITIONS セクションの Sun 拡張機能の変更」の 「管理ラベルの名前を変更する (省略可能)」の手順を参照してください。

管理ラベルの名前の表示と非表示

ラベル表示を設定するオプションを使用すると、セキュリティ管理者役割は、管理ラベルの名前を管理者以外のユーザーにも表示するかどうかを決定できます。サイト側が管理ラベルの名前を非表示にするときは、次のような理由があります。

外部表示

ラベル表示が外部用に設定されていると、次のようになります。

内部表示

内部表示に設定することによって、ユーザーは管理ラベルの名前の表示を見ることができます。名前は、ADMIN_HIGH、ADMIN_LOW などの文字例、またはそれ以外の管理者の権限を使用して設定した代替名です。必要に応じて 「管理ラベルの名前の変更」を参照してください。

ラベル表示の設定の階層

ラベル表示は、3 種類の異なる方法で、外部用または内部用のいずれかに設定されます。この節では、それらの方法を優先度の低いものから順に説明します。

label_encodings ファイルでの設定

デモ版の label_encodings(4) ファイルは、例 1-3 に示すように、LOCAL DEFINITIONS セクションで、ラベル表示が External (外部用) に設定されています。Default Label View という用語は、上記の他の 2 つの設定のどちらか一方によって無効にされない限り、適用されるデフォルト設定であるために使用されます。

例 1-3 ラベル表示のデフォルト設定


Default Label View is External;

サイトの label_encodings(4) ファイルを作成するとき、セキュリティ管理者役割が、External 設定をそのまま受け入れる場合と、それを Internal に変更する場合とがあります。その設定の意味については、「管理ラベルの名前の表示と非表示」を参照してください。また、この設定値は、セキュリティ管理者役割でシステムの稼働後、label_encodings ファイルを編集することによって変更できます。

注 -

「管理ラベルの名前の変更」で述べたように、セキュリティ管理者役割では、管理ラベルの代替名を label_encodings(4) ファイルに指定することができるので、管理ラベルの名前は変更されていることがあることを念頭に入れておく必要があります。

ユーザーマネージャでの設定

プロセスのラベル表示の設定でシステム全体の設定値を変更することができます。プロセスのラベル表示は、内部用 (Internal) 、外部用 (External) 、Sys デフォルト (Sys Default) のいずれかに設定されます。Sys デフォルトの場合のラベル表示には、label_encodings ファイルのデフォルト値が設定されます。プロセスのラベル表示は、次のようにして間接的に設定されます。

図 1-2 ユーザーマネージャの「ラベル (Labels)」ダイアログボックス

Graphic

ラベル表示は、/etc/security/tsol/tsoluser ファイルのアカウントエントリの labelview フィールドに保存される最初の値で、その後に showsl または hidesl が続きます。次の例では、labelview フィールドの最初の設定値が internal であるため、ラベル表示はローカルに生成された auditadmin 管理役割アカウントとして内部用に設定されます。

例 1-4 監査管理役割アカウントの tsoluser エントリの例


auditadmin:fixed:automatic:Audit Control,Audit Review,Media Restore,:none:5:
lock:internal,showsl:0x000000000000000000000000000000000000000
00000000000000000000000000000:0x7fffffffffffffffffffffffffffffffffffffffffff
ffffffffffffff:utadm:res1:res2:res3
注 -

tsoluser(4) ファイルは、直接編集しないでください。アカウントのラベル表示の変更は、ユーザーマネージャの「ラベル (Labels)」ダイアログボックスを使用して下さい。

setpattr(2) によるプロセスの PAF_LABEL_VIEW フラグの設定

ユーザーまたは役割がプロセスを開始すると、そのアカウントの tsoluser(4) ファイルエントリが検索され、そこで指定されたラベル表示に基づいてプロセス属性フラグ PAF_LABEL_VIEW が setpattr(2) により設定されます。PAF_VIEW_EXT は External、PAF_VIEW_INT は Internal を設定します。Sys ラベル表示を tsoluser で指定すると、PAF_VIEW_DEF には label_encodings(4) ファイルのデフォルト値が設定されます。

プログラムによる設定

プログラムは、ライブラリルーチン (マニュアルページの bltos(3) または『Trusted Solaris 開発ガイド』の「ラベル」を参照) を使用してプロセスのラベル表示を設定または取得します。

PAF_LABEL_VIEW フラグの値に関係なく、バイナリからテキストにラベルを変換するのに使用されるライブラリ呼び出しは、ラベルが内部用または外部用のいずれかのラベル表示で変換されるように指定できます。VIEW_EXTERNAL または VIEW_INTERNAL フラグがライブラリルーチンへの呼び出しで指定されなかった場合は、ADMIN_LOW と ADMIN_HIGH ラベルの変換は、ラベル表示プロセス属性フラグによって制御されます。ラベル表示プロセス属性フラグが VIEW_SYS として定義されていれば、変換は、label_encodings(4) ファイルで設定されたラベル表示によって制御されます。

有効なラベル

label_encodings(4) ファイルの規則は、ラベルコンポーネントの一部の組み合わせを不適格とすることがあります。有効なラベルあるいは正しい形式のラベルとは規則に準じたラベルです。

規則は、ラベルの型ごとに指定された制約によって定義されます。それには次のようなものがあります。

例

A、B、Cという語句が機密ラベルに一緒に表示できない場合を想定します。そのときの有効なラベルと認可上限を次の表に示します。TS ABC は、認可上限としては有効ですが、機密ラベルとしては有効ではありません。認可上限が TS ABC であれば、ユーザーは TS A、TS B、TS C でラベル付けされたファイルにアクセスできます。

表 1-11 有効なラベルと認可上限

有効な SL 

有効な認可上限 

TS A

TS ABC

TS A

TS B

TS AB

TS B

TS C

TS AC

TS C

認可範囲

次の 2 つの認可範囲が label_encodings で指定されています。

認可範囲は実際には範囲ではありません。定義された最大値と最小値の間に、ラベルコンポーネントのすべての組み合わせは含まれていないためです。「認可範囲の例」を参照してください

システム認可範囲

システム認可範囲には、常に管理ラベル (ADMIN_HIGH と ADMIN_LOW) が含まれています。

label_encodings ファイルの REQUIRED COMBINATIONS と COMBINATION CONSTRAINTS、およびその他のセクションの規則は、格付けと語句の組み合わせによっては、それを許容したりしなかったりします。

管理者や承認されたユーザーは、この範囲で作業することができます。

ユーザー認可範囲

ユーザー認可範囲は、通常のユーザーがアクセスできる最大のラベルセットで、常に ADMIN_HIGH と ADMIN_LOW は除外されます。

ユーザー認可範囲は、label_encodings (4) ファイルの ACCREDITATION RANGE セクションで指定されている規則によって決まります。

認可範囲の例

以降の図 (図 1-3、図 1-4、図 1-5) で、システムとユーザー認可範囲が label_encodings (4) ファイルでどのように定義されているかを示します。ここでは、格付けは、TOP SECRET (TS)、SECRET (S)、CONFIDENTIAL (C)、コンパートメントは、A、B、C を指定しています。

図 1-3 は、REQUIRED COMBINATIONS セクションで B が常に A と一緒に表示されるように定義している場合のシステム認可範囲に含まれるラベルと、除外されるラベルを示しています。B は常に A と一緒に表示される必要があるので、TS B、S B、C B は除外されています。しかし、A は常に B と一緒に表示されなければならないとは定義されていないため、TS A、S A、C A はシステム認可範囲に含められています。

図 1-3 REQUIRED COMBINATIONS で制限された可能な組み合わせの例

Graphic

次の図は、同じ例の続きで、ユーザー認可範囲が、同じファイル中の ACCREDIATION RANGE セクションのルールによって記述されている様子を示しています。S A と単独 S のラベルの組み合わせの可能性は、S に対する唯一の有効なコンパートメントの組み合わせが、S A B であることを指定する直線によって除外されています。

図 1-4 有効なコンパートメントの組み合わせにより制限されたユーザー認可範囲

Graphic

次の図は、ユーザー認可範囲は、最下位の認可上限と、最下位の機密ラベルの設定の S A B によってさらに制限されています。これによって、C A B と C が除外されています。

図 1-5 最下位の認可上限と最下位の機密ラベルにより制限されたユーザー認可範囲

Graphic

この例における可能な組み合わせ、システム認可範囲、およびユーザー認可範囲の相違点をまとめたものを次の表に示します。

表 1-12 システムとユーザーの認可範囲およびアカウントラベルの範囲

可能な組み合わせ 

システム認可範囲 

ユーザー認可範囲 

アカウントラベルの範囲 

(認可上限は TS A B) 

アカウントラベルの範囲 

(認可上限は TS A) 

ADMIN_HIGH

ADMIN_HIGH

 

 

 

TS A B

TS A B

 

 

 

TS A

TS A

TS A

TS A

TS A

TS

TS

TS

TS

TS

S A B

S A B

S A B

S A B

 

S A

 

 

 

 

S

 

 

 

 

C A B

C A B

 

 

 

C A

C A

 

 

 

C

C

 

 

 

ADMIN_LOW

ADMIN_LOW

 

 

 

何も承認されていない通常のユーザーは、ユーザー認可範囲のカラムにある機密ラベルでしか作業できません。表 1-12 の 4 つ目のカラムは、ユーザーのアカウントラベルの範囲の認可上限が TS A B で、最下位の機密ラベルが、S A B であることを示しています (認可上限は、ユーザー認可範囲内である必要はありません)。このアカウントラベルの範囲では、ユーザーは、TS A、TS、S A B の機密ラベルのセットで作業できます。表 1-12 の 5 つ目のカラムからもわかるように、認可上限が TS A のアカウントは、TS A と TS の機密ラベルでしか作業できません。機密ラベルの S A B に認可上限に含まれていない B が含まれているためです。

コンパートメントとユーザー認可範囲の組み合わせの計画に次の表を使用できます。ACCREDITATION RANGE (認可範囲) の設定値は次のどれかでなければなりません。

表 1-13 コンパートメントとユーザー認可範囲の組み合わせの計画シート

格付け 

コンパートメント名/単形式名/ビット 

REQUIRED COMBINATIONS/ COMBINATION CONSTRAINTS 

ACCREDITATION RANGE 設定値 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

管理役割の再確認

デフォルトでは、Trusted Solaris 管理タスクは、セキュリティ管理者役割とシステム管理者役割の 2 つの主要な管理役割に分割されます。この 2 つの役割には、直接ログインするわけではありません。まず、ユーザーは、自分自身のユーザー名でログインし、パスワードを指定して認証を受けた後、セッション認可上限を設定し （複数のラベルでの作業が許可されている場合）、通常のユーザーワークスペースで作業を開始します。そのアカウントで起動されたプロセスはすべて、アカウントの UID を持ちます。管理役割を担当できるユーザーに対しては、「トラステッドパス (Trusted Path)」メニュー上に役割用のオプションが表示されます。管理タスクを実行する前に、ユーザーは、再度手順を踏んで、「トラステッドパス (Trusted Path)」メニューからオプションを選択して、いずれかの管理役割になる必要があります。ユーザーは、役割のパスワードで、自身の再認証を受ける必要があります。

いったん役割が設定されると、固有の属性を持つ管理役割のワークスペースが作成されます。通常のユーザーは、「すべての定義済みラベルを使用 (use all defined labels)」承認を得ていない限り、ユーザー認可上限内のラベルでしか作業ができず、ユーザー認可上限から外れた認可上限や最下位の機密ラベルを持つことはできません。一方、デフォルトの役割では、ADMIN_LOW と ADMIN_HIGH の 2 つの管理ラベルを含めてシステムの有効なラベルであればどのラベルでも作業することができます。デフォルトの設定では、ADMIN_LOW 機密ラベルは、管理役割を引き受けた最初のワークスペースと、フロントパネルのワークスペースのスイッチ領域に作成される 3 つの追加ワークスペースに割り当てられます。最初に役割を引き受けると、その役割は次の役割のワークスペースを起動し、その役割のアカウント認可範囲にある有効な機密ラベルでラベル付けを行います。アプリケーションは、管理役割のワークスペースのトラステッドパスプロセス属性によってのみ起動できます。

Trusted Solaris 環境では、セキュリティ管理者とシステム管理者の両役割は、ホストのインストールと構成、およびユーザーの設定をともに実行します。セキュリティ管理者役割は、インストール作業を監督して、サイトのセキュリティポリシーに関わる決定を正しく確実に実施させ、各アカウントに対するラベル範囲と表示の有無を指定し、組織の label_encodings(4) ファイルを与えます。このファイルは、インストール後に可変部分として置き換えて使用します。

インストールチームのための決定事項

    サイトのセキュリティポリシーにより、1 つの機密ラベルを使用するか複数のラベルを使用するかを決定する

    サイトのセキュリティポリシーにより、昇格したファイルやディレクトリの名前を表示する必要があるかどうかを決定する

各サイトで指定すべきラベルの型

各サイトでは、次の 3 つの型のラベルをそれぞれ少なくとも 1 つ定義する必要があります。

バナーページ、トレーラページ、本文ページのラベル印刷の設定

セキュリティ管理者役割は、印刷ジョブのバナー、トレーラページおよび本文ページに印刷するラベルの印刷仕様、さらにバナーおよびトレーラページに表示されるテキストを変更できます。label_encondings(4) ファイルには次の 2 つのフィールドを指定します。

計画の概要

    システムのインストール前に label_encodings(4) ファイルを十分検討するだけの時間をとる

    計画に十分な時間をとる

    サイトでエンコーディングを行い、構文的にも意味的にも正しいものを作成するのは、手作業で行う作業であり、時間のかかる作業です。

    自分のサイトのセキュリティポリシーを知る

    これまでにインストールされた多くの Trusted Solaris のセキュリティポリシーは政府の方法によって開発されてきました。民間組織は、ラベル付けされたセキュリティの計画に関してはそれほど多くの経験を持っているわけではありませんが、情報を保護するという目的を検証することから始め、どのようにラベルを使用するかを常識的に決定することができます。印刷物や電子メールにラベル付けをする法的な必要が企業に生じた場合、こうしたガイドラインから始めるのがよいでしょう。一民間企業が法務部門のラベル付けに関する諸条件に基づいて簡単なセキュリティポリシーを開発する例については、第 5 章「使用例: 組織のラベルの計画」を参照してください。自分のサイトのセキュリティポリシーの設定の詳細については、『Trusted Solaris のインストールと構成』の付録 A「サイトのセキュリティポリシー」を参照してください。

    米国政府のラベルエンコーディングファイルを検討する。Trusted Solaris バージョンは、この構文や規則を踏襲しています。

    『コンパートメントモードワークステーションのラベル作成: エンコード形式』を参照してください。

    インストール前にエンコーディングを完成させるプランを立てる

    すでに稼働しているシステム上で label_encodings(4) ファイルを変更するのは危険を伴います。第 2 章「エンコーディングファイルの作成と編集」の 「システム起動後の label_encodings ファイルの変更」を参照してください。

エンコーディングファイルの計画

次の手順で進めることによって、後で安全に拡張できる正しい label_encodings(4) ファイルを作成できる組織作りが可能となります。

    項目を追加できるように余地を残しておく

後でファイルを拡張することができるような進め方をしてください。そうすることによって新しくファイルを作り直さなくても済みます。たとえば、格付けの番号の割り当ても 10 個単位で行うことによって、必要に応じて、後で中間の格付けを追加することができます。同様の理由から、コンパートメントのビット番号も後から追加することを考えて、スペースを空けておくと便利です。

    自分のサイトがインバースコンパートメントやインバースマーキングを使用していれば、後の定義を考慮して初期コンパートメントと初期マーキングビットを予約しておく

インバースコンパートメントやインバースマーキングの詳細については、『コンパートメントモードワークステーションのラベル作成: エンコード形式』を参照してください。これについては、このマニュアルの「はじめに」でも触れています。また、第 2 章「エンコーディングファイルの作成と編集」の 「デフォルト語句およびインバース語句の設定」を参照してください。

    サイトの格付けを決定する

「格付け」でも述べたように、サイトあたりで定義可能な格付けの総数は、254 です。格付けに 0 は使用しないでください。

ラベルの格付けの部分は、格付け同士の相対的な機密度を表します。人が読める形式の名前に関係なく、このシステムでは 10 と格付けされた機密度を 2 と格付けされた機密度よりも上位とみなします。

注 -

CLASSIFICATIONS、COMPARTMENTS セクションについて、セキュリティ管理者役割は後で、人が読める形式の名前なら変更することができますが、値の変更には必ず潜在的な危険性を伴います。

同じ格付けの値に異なった語句を割り当てることはできません。それぞれの格付けの語句は、他のものよりも、上位か下位かのどちらかである必要があります。これは、ラベル同士の優位性を比較したときに、必ずどちらか一方のラベルがもう一方のラベルよりも優位でなくてはならないからです。複数の名前に同じ番号を割り当てると名前の異なるセキュリティレベルが発生しますが、システムでは同じレベルとして扱われます。2 つのラベルが同一レベルとして評価されることはありません。

    コンパートメントを決定する

データとプログラムをどのようにグループ化するか、およびデータやプログラムを混在させるかどうかを決定します。たとえば、あるデータに関して、人事ファイルを取り扱うプログラムからはアクセスできないデータであるが、問題に対処するプログラムからはアクセスできるデータであるとサイトのセキュリティ管理者が判断する場合もあるでしょう。

この時点では、人は考慮の対象外としてください。だれではなく、何をという点から考えてください。

    名前を設計する

label_encodings(4) ファイルの CLASSIFICATIONS と WORDS セクションには、必須の長形式名とオプションの短形式名の 2 つの形式があります。CMW ラベルの情報ラベル部分には、デフォルトで、格付けの長形式名や任意の語句が表示されます。機密ラベル部分には、[ ] 内にデフォルトで、格付けの短形式名や任意の語句が表示されます。ウィンドウ上のスペースを使い切ってしまうと、その上のラベルは、途中で切られてしまいます。したがって、ラベルが途中で切られずに全部表示されているにせよ、長形式名も短形式名もその意味が分かる程度にできるだけ短くしたほうが読みやすくなります。

    関係を調整する

コンパートメントとマーキングは、階層的な関係を持たせて構成することもできますが、本来は非階層的なものです。システム内のオブジェクトやサブジェクトにビット (またはフラグ) を付けて表現します。これらのビットの組み合わせで、サブジェクトやオブジェクトのアクセスの可能性が決まります。それらの関係を設定する前に、『コンパートメントモードワークステーションのラベル作成: エンコード形式』の例を説明したセクションを何度も注意深く読み、具体例を検討してください。

この手順を簡単にする 1 つの方法は、図 1-6 に示したように、大きなボードと使用する格付け、コンパートメント、マーキングなどを記載した紙片を使用することです。この方法によって、関係を視覚化することができ、満足の行くまで、各部分を入れ替えたりして調整できます。

注 -

コマンド chk_encodings(1M) を使用してラベルエンコーディングファイルにエラーがないかどうかを検査しても、検査されるのは構文だけです。-a オプションを指定すると、chk_encodings を使用してラベル間の関係を分析したりレポートを出力したりできます。

図 1-6 ラベルの関係を示す計画ボードの例

Graphic

    ユーザー別に適用される認可上限を決定する

    認可上限の計画に次の表を使用できます。

    表 1-14 認可上限の計画用紙

    CLASS (格付け) 

    COMP (コンパートメント) 

    COMP (コンパートメント) 

    COMP (コンパートメント) 

    COMP (コンパートメント) 

    COMP (コンパートメント) 

    COMP (コンパートメント) 

    注 

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

     

    機密度の低い順に、格付けおよびコンパートメントのラベルを整理します。

    それぞれの語句の定義を内部形式の整数、ビットパターン、論理関係式と関連付ける

    ラベルに使用する色を決定する

多数のラベルの作成

コンパートメントの語句に割り当て可能な 256 個のコンパートメントビットを使用すると、語句を使って作成できるラベルの最大数は格付けごとに 32767 個になります。作成可能な異なるラベル (相互に相手より優位になることがあるラベル) と固有ラベル (相互に相手より優位になることはないラベル) の最大数は次のとおりです。

表 1-15 格付けごとに作成可能なラベル数
 固有ラベルの数 異なるラベルの数
 10 の 40 乗 10 の 70 乗

固有ラベルの作成

固有ラベルの作成には、語句か、社会保険番号などの数値を使用します。固有ラベルを多数作成する場合は、次の手順に従います。

次の表の例で示すように、定義するコンパートメントグループの数が多くなれば、各グループに指定できるコンパートメント語句の数は少なくなり、作成可能な固有ラベルの数は多くなります。

表 1-16 例: 固有ラベルを定義する要素
 コンパートメントグループの数 各グループのコンパートメント数 固有ラベルの最大数
 85 3 10 の 40 乗
 4 20 (会社セット) 50 (部門セット) 50 (グループセット) 600 万
 9 10 米国のすべての社会保険番号より多い

注 -

多数のコンポーネントを使って多数のラベルを作成する場合には、ユーザーマネージャの「ラベル (Label)」ダイアログボックスは適していません。ラベルを作成するこのダイアログボックスは、規則を適用するように設計されていないからです。たとえば、ラベルに各コンパートメントグループのコンパートメントを 1 つずつ使用する必要がある場合には適していません。多数のラベルを作成する場合は、スクリプトを作成して、規則を適用しながら tsoluser(4) ファイルのユーザーにラベルを自動的に割り当てる必要があります。