Solaris のシステム管理 (セキュリティサービス)

用語集

admin 主体

username/admin という形式 (jdoe/admin など) の名前を持つユーザー主体。通常のユーザー主体より多くの特権 (ポリシーの変更など) を持つことができます。主体名ユーザー主体も参照してください。

AES

Advanced Encryption Standard の略。対称 128 ビットブロックのデータ暗号技術。2000 年の 10 月、米国政府は暗号化標準としてこのアルゴリズムの Rijndael 方式を採用しました。ユーザー主体の暗号化に代わる米国政府の標準として、AES が採用されています。

audit policy

どの監査イベントが記録されるかを決定する設定であり、大域の設定とユーザーごとの設定があります。大域の設定は監査サービスに適用され、一般にどのオプション情報を監査トレールに含めるかを決定します。2 つの設定 cntahlt は、監査キューがいっぱいになった時点でのシステムの処理を決定します。たとえば、各監査レコードにシーケンス番号を含めるように監査ポリシーを設定できます。

Blowfish

32 ビットから 448 ビットまでの可変長キーの対称ブロックの暗号化アルゴリズム。その作成者である Bruce Schneier 氏は、鍵を頻繁に変更しないアプリケーションに効果的であると述べています。

DES

Data Encryption Standard。1975 年に開発され、1981 年に ANSI X.3.92 として ANSI で標準化された対称鍵の暗号化方式。DES では 56 ビットの鍵を使用します。

device policy

カーネルレベルでのデバイス保護。デバイスポリシーは、2 つの特権セットとしてデバイスに実装されます。この 1 つはデバイスに対する読み取り権を制御し、もう 1 つはデバイスに対する書き込み権を制御します。ポリシーも参照してください。

Diffie-Hellman プロトコル

公開鍵暗号化としても知られています。1976 年に Diffie 氏と Hellman 氏が開発した非対称暗号鍵協定プロトコルです。このプロトコルを使用すると、セキュリティー保護されていない伝達手段で、事前の秘密情報がなくても 2 人のユーザーが秘密鍵を交換できます。Diffie-Hellman は Kerberos で使用されます。

DSA

デジタル署名アルゴリズム。512 ビットから 4096 ビットまでの可変長キーの公開鍵アルゴリズム。米国政府標準である DSS は最大 1024 ビットです。DSA は入力に SHA1 を使用します。

FQDN

完全指定形式のドメイン名。central.example.com など (単なる denver は FQDN ではない)。

GSS-API

Generic Security Service Application Programming Interface の略。さまざまなモジュールセキュリティーサービス (Kerberos サービスなど) をサポートするネットワーク層。GSS-API は、セキュリティー認証、整合性、およびプライバシサービスを提供します。認証整合性プライバシも参照してください。

KDC

鍵配布センター (Key Distribution Center)。次の 3 つの Kerberos V5 要素で構成されるマシン。

  • 主体と鍵データベース

  • 認証サービス

  • チケット許可サービス

レルムごとに、1 つのマスター KDC と、1 つ以上のスレーブ KDC を配置する必要があります。

Kerberos

認証サービス、Kerberos サービスが使用するプロトコル、または Kerberos サービスの実装に使用されるコード。

Solaris Kerberos は、Kerberos V5 認証にほぼ準拠して実装されています。

「Kerberos」と「Kerberos V5」は技術的には異なりますが、Kerberos のマニュアルでは多くの場合、同じ意味で使用されます。

Kerberos (または Cerberus) は、ギリシャ神話において、ハデスの門を警護する 3 つの頭を持つどう猛な番犬のことです。

Kerberos policy

Kerberos サービスでのパスワードの使用方法を管理する一連の規則。ポリシーは、主体のアクセスやチケットのパラメータ (有効期限など) を制限できます。

key

1. 一般には、次に示す 2 種類の主要鍵のどちらか一方です。

  • 対称鍵 – 復号化鍵とまったく同じ暗号化鍵。対称鍵はファイルの暗号化に使用されます。

  • 非対称鍵または公開鍵 – Diffie-Hellman や RSA などの公開鍵アルゴリズムで使用される鍵。公開鍵には、1 人のユーザーしか知らない非公開鍵、サーバーまたは一般リソースによって使用される公開鍵、およびこれらの 2 つを組み合わせた公開鍵と非公開鍵のペアがあります。非公開鍵は、「秘密鍵」とも呼ばれます。公開鍵は、「共有鍵」や「共通鍵」とも呼ばれます。

  • 2. キータブファイルのエントリ (主体名)。キータブファイルも参照してください。

    3. Kerberos では暗号化鍵であり、次の 3 種類があります。

  • 「非公開鍵」 – 主体と KDC によって共有される暗号化鍵。システムの外部に配布されます。非公開鍵も参照してください。

  • 「サービス鍵」– 非公開鍵と同じ目的で使用されますが、この鍵はサーバーとサービスによって使用されます。サービス鍵も参照してください。

  • 「セッション鍵」 – 一時的な暗号化鍵。2 つの主体の間で使用され、その有効期限は 1 つのログインセッションの期間に制限されます。セッション鍵も参照してください。

kvno

鍵バージョン番号。特定の鍵に対して、生成順に付けられたシーケンス番号。もっとも大きい kvno が、最新の鍵を示します。

MAC

1. メッセージ認証コード (MAC)を参照してください。

2. 「ラベル付け」とも呼ばれます。政府のセキュリティー用語規定では、MAC は「Mandatory Access Control」の略です。「Top Secret」や「Confidential」というラベルは MAC の例です。MAC と対称をなすものに DAC (Discretionary Access Control) があります。UNIX アクセス権は DAC の 1 例です。

3. ハードウェアにおいては、LAN における一意のマシンアドレス。マシンが Ethernet 上に存在する場合は、Ethernet アドレスが MAC に相当します。

MD5

デジタル署名などのメッセージ認証に使用する繰り返し暗号化のハッシュ関数。1991 年に Rivest 氏によって開発されました。

network policies

ネットワークトラフィックを保護するためにネットワークユーティリティーで行われる設定。ネットワークセキュリティーの詳細は、『Solaris のシステム管理 (IP サービス)』のパート IV「IP セキュリティー」を参照してください。

NTP

ネットワークタイムプロトコル (NTP)。デラウェア大学で開発されたソフトウェア。ネットワーク環境で、正確な時間またはネットワーククロックの同期化を管理します。NTP を使用して、Kerberos 環境のクロックスキューを管理できます。「クロックスキュー」も参照してください。

PAM

プラグイン可能認証モジュール (Pluggable Authentication Module)。複数の認証メカニズムを使用できるフレームワーク。認証メカニズムを使用するサービスはコンパイルし直す必要がありません。PAM は、ログイン時に Kerberos セッションを初期化できます。

password policy

パスワードの生成に使用できる暗号化アルゴリズム。パスワードをどれぐらいの頻度で変更すべきか、入力ミスを何回まで認めるかといったセキュリティー上の考慮事項など、パスワードに関連した一般的な事柄を指すこともあります。セキュリティーポリシーにはパスワードが必要です。パスワードポリシーでは、たとえば MD5 アルゴリズムによってパスワードを暗号化することを設定できます。また、パスワードの長さに関連する要件を設定することも可能です。

policy for public key technologies

鍵管理フレームワーク (KMF) におけるポリシーは、証明書の使用を管理します。KMF ポリシーデータベースを使えば、KMF ライブラリによって管理される鍵や証明書の使用に、制約を設けることができます。

policy in the cryptographic framework

Solaris 暗号化フレームワークでは、ポリシーは既存の暗号化メカニズムの無効化を意味します。無効に設定されたメカニズムは使用できなくなります。暗号化フレームワークでは、ポリシーにより、プロバイダ (DES など) の特定のメカニズム (CKM_DES_CBC など) が使用できなくなることがあります。

principal

1. ネットワーク通信に参加する、一意の名前を持つ「クライアントまたはユーザー」あるいは「サーバーまたはサービス」のインスタンス。Kerberos トランザクションでは、主体 (サービス主体とユーザー主体) 間、または主体と KDC の間で対話が行われます。つまり、主体とは、Kerberos がチケットを割り当てることができる一意のエンティティーのことです。主体名サービス主体ユーザー主体も参照してください。

2. (RPCSEC_GSS API) クライアント主体サーバー主体を参照してください。

QOP

保護の質 (Quality of Protection)。整合性サービスまたはプライバシサービスで使用する暗号化アルゴリズムを選択するときに使用されるパラメータの 1 つ。

RBAC

Role-Based Access Control の略。役割によるアクセス制御。すべての機能を持つスーパーユーザーの代替アカウント。RBAC を使用すると、組織はスーパーユーザーの機能を分割して、それらを役割と呼ばれる特殊なユーザーアカウントに割り当てることができます。各ユーザーにはそれぞれの責任に応じて役割を割り当てることができます。

RBAC policy

コマンドに関連付けられるセキュリティーポリシー。現在、有効なポリシーは susersolaris です。solaris ポリシーは、特権と setuid セキュリティー属性を認識します。suser ポリシーは、setuid セキュリティー属性だけを認識します。Solaris システムとの相互運用が可能な Trusted Solaris システムでは、特権、setuid セキュリティー属性、およびプロセスのラベルを認識する tsol ポリシーを使用できます。

RSA

デジタル署名と公開鍵暗号化システムを取得するための方法。その開発者である Rivest 氏、Shamir 氏、Adleman 氏によって 1978 年に最初に公開されました。

SEAM

Sun Enterprise Authentication Mechanism の略。ネットワークを介してユーザーの認証を行うシステムの初期バージョンの製品名。マサチューセッツ工科大学 (MIT) で開発された Kerberos V5 技術に準拠します。この製品は、現在 Kerberos サービスと呼ばれています。SEAM は、各種の Solaris リリースには含まれていなかった Kerberos サービスの部分を指します。

Secure Shell

セキュリティー保護されていないネットワークを通して、セキュリティー保護された遠隔ログインおよびその他のセキュリティー保護されたネットワークサービスを使用するための特別なプロトコル。

SHA1

セキュリティー保護されたハッシュアルゴリズム。メッセージ要約を作成するために 264 文字以下の長さを入力するときに操作します。SHA1 アルゴリズムは DSA に入力されます。

stash ファイル

stash ファイルには、KDC のマスター鍵を暗号化したコピーが含まれます。サーバーがリブートされると、このマスター鍵を使用して KDC が自動的に認証されてから、kadmind プロセスと krb5kdc プロセスが起動されます。stash ファイルにはマスター鍵が入っているため、このファイルやこのファイルのバックアップは安全な場所に保管する必要があります。暗号が破られると、この鍵を使用して KDC データベースのアクセスや変更が可能になります。

TGS

チケット認可サービス (Ticket-Granting Service)。KDC の構成要素の 1 つ。チケットを発行します。

TGT

チケット認可チケット (Ticket-Granting Ticket)。KDC によって発行されるチケット。クライアントは、このチケットを使用して、ほかのサービスのチケットを要求することができます。

アクセス制御リスト (ACL)

アクセス制御リスト (ACL) を使用すると、従来の UNIX ファイル保護よりもきめ細かな方法でファイルセキュリティーを確立できます。たとえば、特定のファイルにグループ読み取り権を設定し、そのグループ内の 1 人のメンバーだけにそのファイルへの書き込み権を与えることが可能です。

アプリケーションサーバー

ネットワークアプリケーションサーバーを参照してください。

アルゴリズム

暗号化アルゴリズム。これは、入力を暗号化 (ハッシング) する既成の再帰的な計算手続きです。

暗号化アルゴリズム

アルゴリズムを参照してください。

インスタンス

主体名の 2 番目の部分。インスタンスは、主体の主ノード指定します。サービス主体の場合、インスタンスは必ず指定する必要があります。host/central.example.com のように、ホストの完全指定ドメイン名を指定します。ユーザー主体の場合、インスタンスは省略することができます。ただし、jdoejdoe/admin は、一意の主体です。主ノード主体名サービス主体ユーザー主体も参照してください。

オーセンティケータ

オーセンティケータは、KDC にチケットを要求するときおよびサーバーにサービスを要求するときに、クライアントから渡されます。オーセンティケータには、クライアントとサーバーだけが知っているセッション鍵を使用して生成された情報が含まれます。オーセンティケータは、最新の識別として検査され、そのトランザクションが安全であることを示します。これをチケットとともに使用すると、ユーザー主体を認証できます。オーセンティケータには、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプが含まれます。チケットとは異なり、オーセンティケータは一度しか使用できません。通常、サービスへのアクセスが要求されたときに使用されます。オーセンティケータは、そのクライアントとそのサーバーのセッション鍵を使用して暗号化されます。

仮想プライベートネットワーク (VPN)

暗号化とトンネルを使用して、セキュリティー保護された通信を提供するネットワーク。公開ネットワークを通してユーザーを接続します。

関係

kdc.conf または krb5.conf ファイルに定義される構成変数または関係の 1 つ。

監査トレール

すべてのホストから収集した一連の監査ファイル。

監査パーティション

監査ファイルを保持するように設定された、ハードディスク内のパーティション。

監査ファイル

バイナリ形式の監査ログ。監査ファイルは、監査パーティションに別々に保存されます。

キータブファイル

1 つまたは複数の鍵 (主体) が含まれるキーテーブル。ホストまたはサービスとキータブファイルとの関係は、ユーザーとパスワードの関係と似ています。

基本セキュリティーモジュール (Basic Security Module、BSM)

Solaris の監査サービスとデバイス割り当て。この 2 つの機能によって C2 レベルのセキュリティーが満たされます。

基本セット

ログイン時にユーザーのプロセスに割り当てられる一連の特権。変更されていないシステムの場合、各ユーザーの初期の継承可能セットはログイン時の基本セットと同じです。

機密性

プライバシを参照してください。

強化

ホストが本来抱えるセキュリティー上の脆弱性を解決するためにオペレーティングシステムのデフォルト構成を変更すること。

許可されたセット

プロセスによって使用できる一連の特権。

クライアント

狭義では、rlogin を使用するアプリケーションなど、ユーザーの代わりにネットワークサービスを使用するプロセスを指します。サーバー自身が他のサーバーやサービスのクライアントになる場合もあります。

広義では、a) Kerberos 資格を受け取り、b) サーバーから提供されたサービスを利用するホストを指します。

広義では、サービスを使用する主体を指します。

クライアント主体

(RPCSEC_GSS API) RPCSEC_GSS で保護されたネットワークサービスを使用するクライアント (ユーザーまたはアプリケーション)。クライアント主体名は、rpc_gss_principal_t 構造体の形式で格納されます。

クロックスキュー

Kerberos 認証システムに参加しているすべてのホスト上の内部システムクロックに許容できる最大時間。参加しているホスト間でクロックスキューを超過すると、要求が拒否されます。クロックスキューは、krb5.conf ファイルに指定できます。

継承可能セット

プロセスが exec の呼び出しを通して継承できる一連の特権。

権利プロファイル

権利またはプロファイルとも呼ばれます。RBAC で使用される優先指定の集合。役割またはユーザーに割り当てることができます。権利プロファイルは、承認、セキュリティー属性を指定したコマンド、その他の権利プロファイルから構成できます。

公開鍵の暗号化

暗号化方式の 1 つ。各ユーザーが 1 つの公開鍵と 1 つの非公開鍵を所有します。公開鍵の暗号化では、送信者は受信者の公開鍵を使用してメッセージを暗号化し、受信者は非公開鍵を使用してそれを復号化します。Kerberos サービスは非公開鍵システムです。非公開鍵の暗号化も参照してください。

更新可能チケット

有効期限の長いチケットは、セキュリティーを低下させることがあるため、「更新可能」チケットに指定することができます。更新可能チケットには 2 つの有効期限があります。 a) チケットの現在のインスタンスの有効期限と、b) 任意のチケットの最長有効期限です。クライアントがチケットの使用を継続するときは、最初の有効期限が切れる前にチケットの有効期限を更新します。たとえば、すべてのチケットの最長有効期限が 10 時間のときに、あるチケットが 1 時間だけ有効だとします。このチケットを保持するクライアントが 1 時間を超えて使用する場合は、チケットの有効期限を更新する必要があります。チケットが最長有効期限に達すると、チケットの有効期限が自動的に切れ、それ以上更新できなくなります。

コンシューマ

Solaris 暗号化フレームワークでは、コンシューマはプロバイダが提供する暗号化サービスのユーザー。コンシューマになりえるものとして、アプリケーション、エンドユーザー、カーネル処理などが挙げられます。Kerberos、IKE、IPsec などはコンシューマの例です。プロバイダの例は、プロバイダを参照してください。

サーバー

ネットワーククライアントにリソースを提供する主体。たとえば、マシン central.example.comrlogin する場合、このマシンが rlogin サービスを提供するサーバーになります。サービス主体も参照してください。

サーバー主体

(RPCSEC_GSS API) サービスを提供する主体。サーバー主体は、service@host という書式で ASCII 文字列として格納されます。クライアント主体も参照してください。

サービス

1. ネットワーククライアントに提供されるリソース。多くの場合、複数のサーバーから提供されます。たとえば、マシン central.example.comrlogin する場合、このマシンが rlogin サービスを提供するサーバーになります。

2. 認証以外の保護レベルを提供するセキュリティーサービス (整合性またはプライバシ)。整合性プライバシも参照してください。

サービス鍵

サービス主体と KDC によって共有される暗号化鍵。システムの外部に配布されます。keyも参照してください。

サービス主体

1 つまたは複数のサービスに Kerberos 認証を提供する主体。サービス主体では、一次名はサービス名 (ftp など) で、インスタンスはサービスを提供するシステムの完全指定ホスト名になります。ホスト主体ユーザー主体も参照してください。

最小化

サーバーを稼働させる上で必要な最小限のオペレーティングシステムをインストールすること。サーバーの処理に直接影関係がないソフトウェアはすべて、インストールされないか、あるいはインストール後削除されます。

シード

乱数生成のスターター (元になる値)。この値から生成が開始されます。このスターターがランダムソースから生じる場合、このシードは「ランダムシード」と呼ばれます。

資格

チケットと照合セッション鍵を含む情報パッケージ。主体の識別情報を認証するときに使用します。チケットセッション鍵も参照してください。

資格キャッシュ

KDC から受信した資格を含む記憶領域。通常はファイルです。

主体名

1. 主体の名前。書式は、primary/instance@REALMインスタンス主ノードレルムも参照してください。

2. (RPCSEC_GSS API) クライアント主体サーバー主体を参照してください。

主ノード

主体名の最初の部分。インスタンス主体名レルムも参照してください。

承認

1. Kerberos では、主体がサービスを使用できるかどうか、主体がアクセスできるオブジェクト、各オブジェクトに許可するアクセスの種類を決定するプロセス。

2. 役割によるアクセス制御 (RBAC) で、役割またはユーザーに割り当てることができるアクセス権。権利プロファイルに埋め込まれていることもあります。承認が与えられていない動作クラスは、セキュリティーポリシーによって拒否されます。

初期チケット

直接発行されるチケット (既存のチケット許可チケットは使用されない)。パスワードを変更するアプリケーションなどの一部のサービスでは、クライアントが非公開鍵を知っていることを確認するために、「初期」と指定されたチケットを要求することができます。初期チケットを使用した検査は、クライアントが最近認証されたことを証明するときに重要になります。チケット許可チケットの場合は、取得してから時間が経過していることがあります。

スーパーユーザーモデル

コンピュータシステムにおける典型的な UNIX セキュリティーモデル。スーパーユーザーモデルでは、管理者は絶対的なマシン制御権を持ちます。一般に、マシン管理のために 1 人のユーザーがスーパーユーザー (root) になり、すべての管理作業を行える状態となります。

スレーブ KDC

マスター KDC のコピー。マスター KDC のほとんどの機能を実行できます。各レルムには通常、いくつかのスレーブ KDC (と 1 つのマスター KDC) を配置します。KDCマスター KDCも参照してください。

制限セット

プロセスとその子プロセスでどの特権が利用できるかを示す上限。

整合性

ユーザー認証に加えて、暗号チェックサムを使用して、転送されたデータの有効性を提供するセキュリティーサービス。認証プライバシも参照してください。

セキュリティーサービス

サービスを参照してください。

セキュリティー属性

RBAC では、セキュリティーポリシーに優先します。セキュリティー属性を使用すると、スーパーユーザー以外のユーザーでも管理コマンドを実行できます。スーパーユーザーモデルでは、setuid プログラムと setgid プログラムがセキュリティー属性です。これらの属性がコマンドで指定されると、そのコマンドがどのようなユーザーによって実行されているかにかかわらず、コマンドは正常に処理されます。特権モデルでは、セキュリティー属性が特権です。特権がコマンドで指定されると、そのコマンドは正常に処理されます。特権モデルは、スーパーユーザーモデルと互換性があります。このため、特権モデルは setuid プログラムと setgid プログラムをセキュリティー属性として認識します。

セキュリティーフレーバ

フレーバを参照してください。

セキュリティーポリシー

ポリシーを参照してください。

セキュリティーメカニズム

メカニズムを参照してください。

セッション鍵

認証サービスまたはチケット認可サービスによって生成される鍵。セッション鍵は、クライアントとサービス間のトランザクションのセキュリティーを保護するために生成されます。セッション鍵の有効期限は、単一のログインセッションに制限されます。keyも参照してください。

ソフトウェアプロバイダ

Solaris 暗号化フレームワークでは、暗号化サービスを提供するカーネルソフトウェアモジュールまたは PKCS #11 ライブラリ。プロバイダも参照してください。

単一システムイメージ

単一システムイメージは、同じネームサービスを使用する一連の検査対象マシンを記述するために、Solaris 監査で使用されます。これらのマシンは監査レコードを中央の監査サーバーに送信しますが、その監査サーバー上では、それらのレコードがまるで 1 つのマシンからやってきたかのように、レコードの比較を行えます。

遅延チケット

遅延チケットは、作成されても指定された時点まで有効になりません。このようなチケットは、夜遅く実行するバッチジョブなどのために効果的です。そのチケットは盗まれても、バッチジョブが実行されるまで使用できないためです。遅延チケットは、無効チケットとして発行され、a) 開始時刻を過ぎて、b) クライアントが KDC による検査を要求したときに有効になります。遅延チケットは通常、チケット認可チケットの有効期限まで有効です。ただし、その遅延チケットが「更新可能」と指定されている場合、その有効期限は通常、チケット認可チケットの有効期限に設定されます。無効チケット更新可能チケットも参照してください。

チケット

ユーザーの識別情報をサーバーやサービスに安全に渡すために使用される情報パケット。チケットは、単一クライアントと特定サーバー上の特定サービスだけに有効です。チケットには、サービスの主体名、ユーザーの主体名、ユーザーのホストの IP アドレス、タイムスタンプ、チケットの有効期限を定義する値などが含まれます。チケットは、クライアントとサービスによって使用されるランダムセッション鍵を使用して作成されます。チケットは、作成されてから有効期限まで再使用できます。チケットは、最新のオーセンティケータとともに提示されなければ、クライアントの認証に使用することができません。オーセンティケータ資格サービスセッション鍵も参照してください。

チケットファイル

資格キャッシュを参照してください。

デバイスの割り当て

ユーザーレベルでのデバイス保護。デバイス割り当ては、一度に 1 人のユーザーだけが使用できるようにデバイスを設定する作業です。デバイスデータは、デバイスが再使用される前に消去されます。誰にデバイス割り当てを許可するかは、承認を使用して制限できます。

転送可能チケット

チケットの 1 つ。クライアントが遠隔ホスト上のチケットを要求するときに使用できます。このチケットを使用すれば、遠隔ホスト上で完全な認証プロセスを実行する必要がありません。たとえば、ユーザー david がユーザー jennifer のマシンで転送可能チケットを取得した場合、david は自分のマシンにログインするときに新しいチケットを取得する必要はありません (再び認証を受けることもない)。プロキシ可能チケットも参照してください。

同期監査イベント

監査イベントの大半を占めます。これらのイベントは、システムのプロセスに関連付けられています。失敗したログインなど、あるプロセスに関連付けられた、ユーザーに起因しないイベントは、同期イベントです。

特権

Solaris システムにおいてプロセスに対する個々の権利。特権を使用すると、root を使用するよりもきめ細かなプロセス制御が可能です。特権の定義と適用はカーネルで行われます。特権の詳細は、privileges(5) のマニュアルページを参照してください。

特権セット

一連の特権。各プロセスには、プロセスが特定の特権を使用できるかどうかを判断する 4 セットの特権があります。詳細は、制限セット有効セット許可されたセット、および 継承可能セットを参照してください。

基本セットも、ユーザーのログインプロセスに割り当てられる特権セットです。

特権付きアプリケーション

システム制御に優先するアプリケーション。このようなアプリケーションは、セキュリティー属性 (特定の UID、GID、承認、特権など) をチェックします。

特権モデル

コンピュータシステムにおいてスーパーユーザーモデルより厳密なセキュリティーモデル。特権モデルでは、プロセスの実行に特権が必要です。システムの管理は、管理者が各自のプロセスで与えられている特権に基づいて複数の個別部分に分割できます。特権は、管理者のログインプロセスに割り当てることも、特定のコマンドだけで有効なように割り当てることも可能です。

認証

特定の主体の識別情報を検証するプロセス。

ネームサービススコープ

特定の役割が操作を許可されている適用範囲。つまり、特定のネームサービス (NIS、NIS+、LDAP など) を使用する個々のホストまたはすべてのホストです。スコープは、Solaris 管理コンソールツールボックスに適用されます。

ネットワークアプリケーションサーバー

ネットワークアプリケーションを提供するサーバー (ftp など)。レルムは、複数のネットワークアプリケーションサーバーで構成されます。

ハードウェアプロバイダ

Solaris 暗号化フレームワークにおいては、デバイスドライバとそのハードウェアアクセラレータを指します。ハードウェアプロバイダを使用すると、コンピュータシステムから負荷の高い暗号化処理を解放され、その分 CPU リソースをほかの用途に充てることができます。プロバイダも参照してください。

パスフレーズ

非公開鍵がパスフレーズユーザーによって作成されたことを検証するために使用されるフレーズ。望ましいパスフレーズは、10 - 30 文字の長さで英数字が混在しており、単純な文や名前を避けたものです。通信の暗号化と復号化を行う非公開鍵の使用を認証するため、パスフレーズの入力を求めるメッセージが表示されます。

非公開鍵

各ユーザー (主体) に与えられ、主体のユーザーと KDC だけが知っている鍵。ユーザー主体の場合、鍵はユーザーのパスワードに基づいています。keyも参照してください。

非公開鍵の暗号化

非公開鍵の暗号化では、送信者と受信者は同じ暗号化鍵を使用します。公開鍵の暗号化も参照してください。

非同期監査イベント

非同期イベントは、システムイベントの内の少数です。これらのイベントは、プロセスに関連付けられていないため、ブロックした後に起動できるプロセスはありません。たとえば、システムの初期起動や PROM の開始および終了のイベントは、非同期イベントです。

秘密鍵

非公開鍵を参照してください。

プライバシ

セキュリティーサービスの 1 つ。送信データを送信前に暗号化します。プライバシには、データの整合性とユーザー認証も含まれます。認証整合性サービスも参照してください。

フレーバ

従来は、「セキュリティーフレーバ」と「認証フレーバ」は、認証のタイプ (AUTH_UNIX、AUTH_DES、AUTH_KERB) を指すフレーバとして、同じ意味を持っていました。RPCSEC_GSS もセキュリティーフレーバですが、これは認証に加えて、整合性とプライバシのサービスも提供します。

プロキシ可能チケット

クライアントに代わってクライアント操作を行うためにサービスによって使用されるチケット。このことを、サービスがクライアントのプロキシとして動作するといいます。サービスは、チケットを使用して、クライアントの識別情報を所有できます。このサービスは、プロキシ可能チケットを使用して、ほかのサービスへのサービスチケットを取得できますが、チケット認可チケットは取得できません。転送可能チケットと異なり、プロキシ可能チケットは単一の操作に対してだけ有効です。転送可能チケットも参照してください。

プロバイダ

Solaris 暗号化フレームワークでは、コンシューマに提供される暗号化サービス。プロバイダには、PKCS #11 ライブラリ、カーネル暗号化モジュール、ハードウェアアクセラレータなどがあります。プロバイダは Solaris 暗号化フレームワークに結合 (プラグイン) されるため、プラグインとも呼ばれます。コンシューマの例は、コンシューマを参照してください。

プロファイルシェル

RBAC では、コマンド行から役割 (またはユーザー) が、その役割の権利プロファイルに割り当てられた任意の特権付きアプリケーションを実行できるようにするシェル。プロファイルシェルには、pfshpfcsh、および pfksh があります。これらはそれぞれ、Bourne シェル (sh)、C シェル (csh)、および Korn シェル (ksh) に対応します。

ホスト

ネットワークを通じてアクセス可能なマシン。

ホスト主体

サービス主体のインスタンスの 1 つ (一次名は host)。さまざまなネットワークサービス (ftprcprlogin など) を提供するために設定します。host/central.example.com@EXAMPLE.COM はホスト主体の例です。サーバー主体も参照してください。

ポリシー

一般には、意思やアクションに影響を与えたり、これらを決定したりする計画や手続き。コンピュータシステムでは、多くの場合セキュリティーポリシーを指します。実際のサイトのセキュリティーポリシーは、処理される情報の重要度や未承認アクセスから情報を保護する手段を定義する規則セットです。たとえば、セキュリティーポリシーで、システムの監査、特権によるデバイスの保護、6 週ごとのパスワード変更といったことを設定できます。

Solaris OS の特定領域におけるポリシー実装については、audit policypolicy in the cryptographic frameworkdevice policyKerberos policypassword policyRBAC policyを参照してください。

マスター KDC

各レルムのメイン KDC。Kerberos 管理サーバー kadmind と、認証とチケット認可デーモン krb5kdc で構成されます。レルムごとに、1 つ以上のマスター KDC を割り当てる必要があります。また、クライアントに認証サービスを提供する複製 (スレーブ) KDC を任意の数だけ割り当てることができます。

無効チケット

まだ使用可能になっていない遅延チケット。無効チケットは、有効になるまでアプリケーションサーバーから拒否されます。これを有効にするには、開始時期が過ぎたあと、TGS 要求で VALIDATE フラグをオンにしてクライアントがこのチケットを KDC に提示する必要があります。遅延チケットも参照してください。

メカニズム

1. データの認証や機密性を実現するための暗号化技術を指定するソフトウェアパッケージ。たとえば、 Kerberos V5、Diffie-Hellman 公開鍵など。

2. Solaris 暗号化フレームワークにおいては、特定用途のアルゴリズムの実装。たとえば、認証に適用される DES メカニズム (CKM_DES_MAC など) は、暗号化に適用されるメカニズム (CKM_DES_CBC_PAD) とは別です。

メッセージ認証コード (MAC)

データの整合性を保証し、データの出所を明らかにするコード。MAC は盗聴行為には対応できません。

メッセージ要約

メッセージ要約は、メッセージから計算されるハッシュ値です。ハッシュ値によってメッセージはほぼ一意に識別されます。要約は、ファイルの整合性を検証するのに便利です。

役割

特権付きアプリケーションを実行するための特別な ID。割り当てられたユーザーだけが引き受けられます。

有効セット

プロセスにおいて現在有効である一連の特権。

ユーザー主体

特定のユーザーに属する主体。ユーザー主体の一次名には、ユーザー名を指定します。オプションのインスタンスには、対応する資格の使用方法を説明する名前を指定します (jdoejdoe/admin など)。「ユーザーインスタンス」とも呼ばれます。サービス主体も参照してください。

ユーザーに起因しない監査イベント

開始した人を特定できない監査イベント。AUE_BOOT イベントなど。

要約

メッセージ要約を参照してください。

レルム

1. 1 つの Kerberos データベースといくつかの鍵配布センター (KDC) を配置した論理ネットワーク。

2. 主体名の 3 番目の部分。主体名が jdoe/admin@ENG.EXAMPLE.COM の場合、レルムは ENG.EXAMPLE.COM です。主体名も参照してください。