識別,認証,および承認は,システム・セキュリティに不可欠の要素です。システム・セキュリティは,セキュリティ・ポリシを作成することによって構築します。セキュリティ・ポリシによって,システム上のリソースにアクセスするユーザやアプリケーション (エンティティ) との間,およびローカル・ネットワークや拡張ネットワークの内部にある他のシステムとの間で,必要な信用レベルが決まります。
システムのリソースにアクセスするエンティティを完全に信用するには,まずそのエンティティを識別する必要があります。エンティティは識別されたら,システムに対して自身が本物であることを証明しなければなりません。最後に,エンティティを識別して認証した後,システムはそのエンティティによるアクセスが承認されるシステム上のリソースを決定する承認情報を適用します。
この章には,次の情報が含まれています。
認証を成功させるには,ユーザやアプリケーション (エンティティ) がシステムに対して何らかの形で信任状を提示する必要があります。信任状として使えるのは,そのユーザだけが知っていること (ユーザ名とパスワード),そのユーザ自身の情報 (バイオメトリックスや網膜スキャン),またはそのユーザだけが持っているもの (スマート・カードや証明書) です。
Tru64 UNIX オペレーティング・システム・ソフトウェアでは,従来からチャレンジ・レスポンス方式によるユーザ認証にローカル認証方式 (ユーザのログイン名とパスワード) が使われていました。この場合,システムはユーザが入力した名前とパスワードをローカルのユーザ・アカウント・データベース内のエントリと照合します。
ユーザ・アカウント・データベース内のユーザ・エントリは,管理者がユーザ・アカウントを作成したときに作成されます。一致するエントリがユーザ・アカウント・データベースに存在しない場合,そのユーザは認証されません。一致するエントリがユーザ・アカウント・データベースに存在し,パスワードが正しければ,そのユーザは認証されます。
コンピュータ環境が分散化,オープン化,および多様化するにしたがって,何らかのネットワーク接続を経由して別のシステムからシステムにアクセスするリモート・ユーザに対するチャレンジ・レスポンス方式による認証では,次のような問題が発生しました。
分散型の認証データベースがない
システムごとに独立したユーザ・アカウント・データベースが維持され,データベースの情報を異なるシステム間で共有できません。このため,ユーザは利用するリソースが存在するシステムごとにユーザ・アカウントを作成する必要があります。また,各システムは他のシステムの識別情報やユーザの識別情報の正当性を安全な信頼性の高い方法で判定できません。
システム間で共通の暗号化方式がない
暗号化されたデータをシステム間でやり取りできません。ユーザ名やパスワードを含むデータが平文のままネットワーク経由で配布されます。
データの完全性を判定できない
各システムは,データが送信中に傍受,参照,変更されたかどうかを簡単に検出できません。
データの送信元が判定できない
各システムは,データの送信元を簡単に証明できません。
認証に関するこれらの問題を解決するため,リモート認証方式 (アプリケーション,メカニズム,プロトコル,およびアプリケーション・プログラミング・インタフェース (API)) が開発されました。この方式では,何らかのネットワーク接続を経由して別のシステムからアクセスするユーザのために,次のようなリモート認証サービスが提供されます。
分散型の認証データベース
ユーザ認証情報は,プライマリ・サーバに保存され,維持されます。各システムはプライマリ・サーバにユーザ認証要求を送信します。システムごとに独自のユーザ・アカウント・データベースを維持する必要はありません。各システムでは,他のシステムの識別情報やユーザの識別情報の正当性を安全で信頼性の高い方法で判定する認証方式が使われます。
システム間で共通の暗号化方式
各システムは,ユーザに意識させることなく暗号化されたデータをやり取りします。
データの完全性を判定する機能
各システムは,データが転送中に傍受,参照,および変更されたかどうかを判定できます。
データの送信元を判定する機能
各システムがデータの送信元を証明できるため,ユーザやエンティティはデータに関して特定の操作を実行した事実やデータの所有者に関する証拠を否定できません。
ローカル認証方式とリモート認証方式では,ローカル認証やリモート認証に必要な複数の信用レベルを持つセキュリティ・ドメインを作成するセキュリティ・ポリシを実装できます。
ローカル認証の場合は,Tru64 UNIX システムのリソースへのアクセスを要求するユーザの認証をそのシステムが担当します。リモート認証の場合は,Tru64 UNIX システムがリモート・サーバのクライアントになり,そのシステムのリソースへのアクセスを要求するユーザの認証処理をリモート・サーバに依頼します。表 1-1
は,各種のローカルおよびリモート認証方式について,認証の実装方法を比較した表です。
表 1-1: 認証方式の比較
認証方式 | ローカル/リモート | 実装方法 |
基本 (BSD) セキュリティ・メカニズム |
ローカル |
パスワード |
エンハンスト・セキュリティ・メカニズム |
ローカル |
パスワード |
r* コマンド ( |
ローカル |
|
セキュア・シェル・アプリケーション |
リモート |
|
NIS (Network Information Service) プロトコル |
リモート |
パスワード |
LDAP (Lightweight Directory Access Protocol) |
リモート |
パスワード |
Single Sign On (SSO)/Kerberos メカニズム |
リモート |
パスワードと秘密鍵 |
Advanced Server for UNIX (ASU) |
リモート |
パスワード |
IPsec プロトコル |
リモート |
公開鍵 |
SSL (Secure Socket Layer) API |
リモート |
公開鍵 |
CDSA (Common Data Security Architecture) API |
リモート |
公開鍵 |
GSS API |
リモート |
パスワードと秘密鍵 |
この項では,認証の実装について説明します。
1.2.1 パスワード認証
パスワード認証では,ユーザがパスワードで保護されたユーザ・アカウントを持つ必要があります。このユーザ・アカウントは,ローカルの Tru64 UNIX パスワード認証メカニズムとリモートのパスワード認証方式のどちらかを使って認証できます。
ユーザが認証を必要とする操作 (システムへのログインなど) を実行すると,ユーザはパスワードの入力を求められます。システムはユーザが入力した名前とパスワードをユーザ・アカウント・データベース内のエントリと照合します。ユーザ・アカウント・データベース内のユーザ・エントリは,管理者がユーザ・アカウントを作成したときに作成されます。一致するエントリがユーザ・アカウント・データベースに存在しない場合,そのユーザは認証されません。一致するエントリがユーザ・アカウント・データベースに存在し,パスワードが正しければ,そのユーザは認証されます。
1.2.2 ホスト・ベース認証
ホスト・ベース認証は,ホスト名とユーザ名の識別に基づく UNIX の非対話型認証方式です。ホスト・ベース認証では,各ユーザが特定のホストからネットワーク・コマンド (rcp
,rlogin
,rsh
の各コマンドや同等のセキュア・シェル・コマンドなど) を使用するユーザに対して,自分のユーザ・アカウントへのアクセスを許可できます。セキュア・シェル・コマンドの詳細については,1.4.3 項を参照してください。
ユーザがアクセスを許可するときは,自分のホーム・ディレクトリ内の
.rhosts
ファイルおよび
.shosts
ファイルにホスト名とユーザ名から成るエントリを追加します。ユーザが使用するファイルは,次の条件で決まります。
ユーザが
rcp
,rlogin
,rsh
の各コマンドを使用する場合は,.rhosts
ファイルを使用します。
ユーザがセキュア・シェル・コマンドを使用するか,または
rcp
,rlogin
,rsh
の各コマンドでセキュア・シェル接続を使用するように構成した場合は,.rhosts
ファイルおよび
.shosts
ファイルを使用します。これらのコマンドでセキュア・シェル接続を使用するように構成する方法の詳細については,B.4 節を参照してください。
.shosts
ファイルの用途や形式は
.rhosts
ファイルと同じですが,このファイルを読み込むのはセキュア・シェル・サーバだけです。2 つのファイルが両方とも存在する場合,セキュア・シェル・サーバは最初に
.rhosts
ファイルを読み込み,次に
.shosts
ファイルを読み込みます。どちらかのファイルで特定の接続に対するアクセスが許可されていれば,もう一方のファイルでアクセスが許可されていなくてもセキュア・シェル接続が使われます。
セキュア・シェルのホスト・ベース認証では,他にも構成が必要な項目があります。セキュア・シェルのホスト・ベース認証の詳しい構成方法については,B.5.3 項を参照してください。
.rhosts
ファイルや
.shosts
ファイルのエントリには,該当するユーザを認証するのに使うホストの完全修飾ドメイン名を入れます。たとえば,ホスト
zeus
上にある
$HOME/peter/.shosts
ファイルの次のエントリは,リモート・ホスト
saturn.ne.corp.com
のユーザ
evan
と
justin
に対して,zeus
上にある
peter
のユーザ・アカウントへのログインを許可します。
saturn.ne.corp.com evan saturn.ne.corp.com justin
ユーザ
evan
と
justin
はパスワードを入力する必要がなく,次のコマンドを入力すれば
zeus
上にある
peter
のユーザ・アカウントにログインします。
$ rlogin -l peter zeus
ホスト・ベース認証は,スクリプトや自動化されたプロセス (cron
ジョブ,自動バックアップ,自動ファイル転送など),および認証情報を入力するユーザがいないその他の状況に最適です。非対話式のログインは,本質的に安全とは言えません。ユーザに対するチャレンジがない認証では,必ずある程度のリスクを想定する必要があります。
.rhosts
と
.shosts
のファイル形式は同じです。詳細については,
.rhosts
(4)1.2.3 公開鍵認証
公開鍵認証は暗号化技術の一種で,2 つの通信プリンシパル (通常はクライアントとサーバ) が公開鍵と秘密鍵を使って相手のシステムやユーザを認証し,やり取りするデータを暗号化および復号します。一方の公開鍵または秘密鍵で暗号化したデータは,もう一方の対応する公開鍵または秘密鍵でしか復号できません。暗号化の詳細については,1.2.5 項を参照してください。
公開鍵は公開され,ユーザが通信先とするシステムの特定のディレクトリにコピーされます。秘密鍵は一切公開・配布されず,ユーザは秘密鍵に秘密のパスフレーズを割り当てます。公開鍵と秘密鍵には数学的な相互関係がありますが,一方の鍵からもう一方の鍵を算出することは不可能です。このため,公開鍵の情報から対応する秘密鍵が漏洩するおそれはありません。
公開鍵を使う場合は,システム (クライアント) が他のシステム (サーバ) にサービスを要求した時点で認証が開始されます。
クライアントがサーバの公開鍵のコピーを使ってメッセージを暗号化し,サーバにそのメッセージを送信します。
サーバがユーザにパスフレーズの入力を求め,入力されたパスフレーズとサーバの秘密鍵を使ってメッセージを復号します。
サーバがクライアントの公開鍵のコピーを使って応答メッセージを暗号化し,クライアントにそのメッセージを送信します。
クライアントが自身の秘密鍵を使ってメッセージを復号します。
それぞれの秘密鍵に対応する公開鍵は 1 つしかないので,暗号化と復号が成功することによってプリンシパルが認証されます。
1.2.3.1 デジタル署名と証明書
あるユーザが鍵のペアを生成して公開鍵を公開する場合,使われる識別情報が本物だという保証はありません。公開鍵の不正利用を防ぐには,デジタル署名およびデジタル証明書と呼ばれるデジタル文書を使用します。
デジタル署名は,文書を基にした小さなデータとプリンシパルの秘密鍵から生成されます。通常,デジタル署名はハッシュと秘密の署名アルゴリズムを使って作成され,秘密鍵で暗号化されます。ハッシュとは,テキストの文字列から生成される数値のことです。
元の電子メッセージのバイナリ・コードに対してハッシュ・アルゴリズムが実行されると,いわゆるメッセージ・ダイジェスト (元のメッセージに固有の 160 ビットから成る数字列) が生成されます。このメッセージ・ダイジェストに対して秘密の署名アルゴリズムが実行されます。この署名処理では,プリンシパルの秘密鍵が署名アルゴリズムに組み込まれます。この結果得られた数字列がデジタル署名です。プリンシパルは,署名を生成した側のプリンシパルの公開鍵を持っていれば,その署名を検証できます。
デジタル証明書は,個人,サーバ,会社,その他のプリンシパルを識別するための電子文書で,公開鍵によってそのプリンシパルと結び付けられています。運転免許,パスポート,その他の一般的に使われる個人 ID と同じように,デジタル証明書はプリンシパルの公認された身元証明を提供します。
デジタル証明書の発行,検証,および管理は,認証局 (CA) と呼ばれる信頼される第三者機関によって行われます。ただし,テスト目的の証明書は IPsec で提供されるツールを使って作成できます。他の身分証明と同じように,CA の信頼性は非常に重要です。CA が識別情報を検証する方法は,各 CA のポリシによって異なります。一般に,CA はデジタル証明書を発行する前に,公開された検証手順を使って,デジタル証明書を要求するプリンシパルが申し立てどおりのプリンシパルであることを確認します。発行されたデジタル証明書は,CA のデータベースに保管されます。
デジタル証明書には,識別するプリンシパルの名前,そのプリンシパルの公開鍵,有効期限,証明書を発行した CA の名前,シリアル番号,およびその他の情報が入っています。また,最も重要な要素として発行元の CA のデジタル署名が含まれています。これにより,プリンシパルが不明でも CA が信頼されていれば,デジタル署名を含むデジタル証明書によってそのプリンシパルを識別することができます。
1.2.4 秘密鍵認証
秘密鍵認証は暗号化技術の一種で,2 つの通信プリンシパル (通常はクライアントとサーバ) が同じ秘密鍵 (セッション鍵) を使ってシステムやユーザを認証し,やり取りするデータを暗号化および復号します。一方のセッション鍵で暗号化したデータは,もう一方の一致するセッション鍵でしか復号できません。暗号化の詳細については,1.2.5 項を参照してください。
信頼される KDC (Key Distribution Center) は,プリンシパル間の通信を仲介し,プリンシパル間専用のセッション鍵を作成します。秘密鍵を使う場合は,ユーザがログインした時点で認証が開始されます。
ユーザがユーザ名とパスワードをシステム (クライアント) に入力します。
クライアントが入力されたユーザ名を KDC に送信します。
KDC は,仲介する各ユーザのエントリを暗号化されたプリンシパル・データベースに保存しています。このエントリには,ユーザについての情報 (パスワードやマスター鍵など) が入っています。
KDC がプリンシパル・データベースから該当するユーザのエントリを検索します。一致するエントリがあれば,KDC は次のものを作成します。
クライアントと KDC が専用で使うセッション鍵。
セッション鍵のコピー,ユーザの名前,および有効期限が入った TGT (チケット・グランティング・チケット)。KDC は KDC のマスター鍵を使ってこのチケットを暗号化します。
KDC がセッション鍵と TGT の入ったメッセージを作成します。このメッセージはユーザのマスター鍵で暗号化され,クライアントに送信されます。
クライアントが一方向ハッシュ関数を使ってユーザのパスワードをユーザのマスター鍵に変換します。次に,そのマスター鍵を使ってメッセージを復号し,セッション鍵と TGT を取り出します。
セッション鍵と TGT は,ユーザの信任状キャッシュ (クライアント上のファイル) に保存されます。クライアントはそれ以降の KDC との通信にこのセッション鍵と TGT を使用します。クライアントを含むどのプリンシパルも,TGT の内容を参照および変更できません。
次に示す手順では,2 つのプリンシパル (クライアント) が通信しようとしている場合の認証処理について説明します。
要求する側のプリンシパルが次の内容を含むメッセージを KDC に送信します。
TGT
通信相手となるプリンシパルの識別情報
認証子 (プリンシパルと KDC が共有するセッション鍵を使って暗号化されたタイムスタンプ)
KDC がマスター鍵を使って TGT を復号します。前述のように,TGT にはユーザの名前とセッション鍵のコピーが入っています。次に,KDC がセッション鍵を使って認証子を復号します。
該当するプリンシパルと KDC だけが同じセッション鍵を持っているので,認証子が正常に復号されれば,KDC とプリンシパルは互いの識別情報を確認することができます。
KDC がそれぞれのプリンシパルのためにチケットのペアを作成します。各チケットには,相手側のプリンシパルの名前,タイムスタンプ,チケットの有効期間,およびプリンシパルどうしが専用で使う新しいセッション鍵が入っています。
KDC が要求する側のプリンシパル用のチケットから成るメッセージを作成します。この中には,要求される側のプリンシパルの鍵で暗号化した要求される側のプリンシパル用のチケットが入っています。
KDC は,要求する側のプリンシパルと共有するセッション鍵を使ってこのメッセージを暗号化し,要求する側のプリンシパルに送信します。
要求する側のプリンシパルが KDC と共有しているセッション鍵を使ってメッセージを復号します。新しいセッション鍵と要求される側のプリンシパル用のチケットが取り出されます。
要求する側のプリンシパルは新しいセッション鍵を使って認証子 (タイムスタンプ) を暗号化し,この認証子と要求される側のプリンシパル用のチケットが入ったメッセージを要求される側のプリンシパルに送信します。
要求される側のプリンシパルが次の処理を実行します。
自分のマスター鍵を使ってチケットを復号します。
チケットからセッション鍵を取り出します。
取り出したセッション鍵を使って認証子を復号します。
ここで使われるセッション鍵は 2 つのプリンシパル専用なので,認証子の復号に成功すれば,認証子の暗号化と復号に同じセッション鍵が使われたことになり,プリンシパル間で互いの身元を確認することができます。
暗号化とは,システムが暗号化アルゴリズム (暗号) を使ってデータを暗号化および復号することです。暗号によって,平文 (暗号化されていないテキスト) が暗号文 (暗号化されたテキスト) に変換されます。復号とは,同じ暗号を使って暗号文を平文に変換することです。
クライアントとサーバは同じ暗号をサポートする必要があります。また,サポートするプロトコルのバージョン,許容する暗号強度に関する企業方針,政府の輸出規制,データの機密性,暗号処理の速度などの要因に応じて,複数の暗号スイート (暗号セット) をサポートすることができます。管理者は,クライアントとサーバでサポートされる任意の暗号スイートを有効または無効にできます。
クライアントとサーバは,接続開始時の処理の一環として,互いの共通の最高強度の有効な暗号スイートを特定し,それをセッションに使用します。
ほぼすべての暗号で,鍵 (暗号化されていないテキストと何らかの方法で結び付けられた値) とアルゴリズム (鍵とテキストを結びつける公式) が使われます。暗号には,一般に次の 2 種類があります。
メッセージを複数のセクション (64 ビット単位のテキストなど) に分割し,各セクションに鍵を結び付けるブロック暗号。現在の暗号は,ほとんどがブロック暗号です。
ビットごとに 1 つの鍵を適用するストリーム暗号。
暗号アルゴリズムには,たとえば次のようなものがあります。
DES (Data Encryption Standard)
3DES
RSA (Ron Rivest,Adi Shamir,Len Adleman)
Blowfish および Twofish
ローカル認証とは,Tru64 UNIX システムがリソースへのアクセスを要求するユーザを何らかの認証方式によって認証することです。この項では,次のローカル認証方式について説明します。
基本 (BSD) メカニズム
エンハンスト・セキュリティ・メカニズム
基本 (BSD) セキュリティは,Tru64 UNIX オペレーティング・システム・ソフトウェアが稼動するシステムで利用できる標準のセキュリティ・レベルです。
基本セキュリティでは,/etc/passwd
ファイルに格納されているユーザ情報を使ってユーザを認証します。Tru64 UNIX のユーザ・アカウントを作成すると,特に指定しなければそのユーザのエントリがローカル・システムの
/etc/passwd
ファイルに追加されます。各エントリには,各ユーザに関する情報 (ユーザ名,ユーザ ID (UID),パスワード,ログイン・ディレクトリ,シェルなど) が入っています。/etc/passwd
ファイルおよびユーザ・アカウントの作成の詳細については,『システム管理ガイド』を参照してください。
ユーザが Tru64 UNIX システムにログインするためにユーザ名とパスワードを入力すると,Tru64 UNIX サーバはユーザが入力した情報を
etc/passwd
ファイルの各エントリと照合します。一致するエントリが存在し,パスワードが正しければ,認証に成功し,ユーザはログインすることができます。一致するエントリが存在しないと,認証に失敗し,ユーザはログインできません。
/etc/passwd
ファイルの編集や整合性チェックを実行するには,pwck
コマンドまたは
vipw
コマンドを使用します。基本セキュリティを使用している場合,ユーザは
passwd
コマンドを使ってパスワードを変更します。
基本 (BSD) メカニズムでは,ローカル・システム上にある
/etc/group
ファイルによってユーザ承認情報が提供されます。/etc/passwd
ファイルの編集や整合性チェックを実行するには,grpck
コマンドまたは
vipw
コマンドを使用します。/etc/group
ファイルおよびユーザ・グループの作成の詳細については,『システム管理ガイド』を参照してください。
1.3.2 エンハンスト・セキュリティ・メカニズム
Tru64 UNIX オペレーティング・システムには,エンハンスト・セキュリティ・メカニズムがオプションで用意されています。エンハンスト・セキュリティ・メカニズムは,BSD メカニズムをベースに構築されていますが,セキュリティ情報の一部がデータベースに移動され,侵入回避機能が追加され,アカウントやパスワードの制御が強化されています。エンハンスト・セキュリティのデータベースでは,BSD のファイルに比べてシステム・セキュリティの制御が強化されています。
エンハンスト・セキュリティ・メカニズムをインストールして構成したシステムのことをトラステッド・システムと呼びます。エンハンスト・セキュリティ機能をすべて有効にすると,『Trusted Computer System Evaluation Criteria』 (TCSEC,いわゆる『Orange Book』) で定義された,C2 クラスの信頼性を満たすシステムを構成できます。また,そのシステムは『Information Technology Security Evaluation Criteria』 (ITSEC) で定義された F-C2 機能クラスも満たしています。C2 クラスの信頼性のセキュリティを満たすシステムの構築方法については,付録 E を参照してください。
エンハンスト・セキュリティは,次の機能拡張を提供することで BSD セキュリティを拡張しています。
ログイン制御の拡張
パスワードの拡張
エンハンスト・セキュリティのログイン制御に関する機能を次に示します。
最後にログインに成功および失敗した端末の記録
最後にログインに成功した日時の記録
最後にログインに失敗した日時の記録
連続して失敗したログイン操作回数の記録
連続して指定回数以上アクセス操作に失敗したアカウントの自動ロックアウト
ログイン失敗後の次のログイン操作までの遅延時間,およびログイン操作が完了しないままログイン操作の失敗が確定するまでの最大時間に関する端末ごとの設定
端末からの新しいアクセスがロックされるまでの最大連続失敗ログイン操作回数に関する端末ごとの設定
最後に成功したログイン操作と最後に失敗したログイン操作に関する情報をログイン時に表示する機能
端末経由のログインが発生するごとにログイン情報を記録する機能
エンハンスト・セキュリティでは,パスワードの制御に関して以下の機能が提供されます。
パスワードの最大長の設定 (最大 80 文字)
パスワードの有効期間の設定
パスワードの最小長の設定
システム生成パスワード (意味のない音節で構成される発音可能なパスワード,文字セット内のランダムな文字で構成される発音できないパスワード,または任意のアルファベット (ASCII の英字) で構成される発音できないパスワードなど)
ユーザごとのパスワード生成フラグ (たとえば,ユーザにシステム生成パスワードの使用を強制できる)
ユーザのパスワードを最後に変更した (そのユーザ以外の) 人の記録
パスワードの使用履歴
リモート認証とは,Tru64 UNIX システムがリモート・サーバのクライアントになり,そのシステムのリソースへのアクセスを要求するユーザの認証処理をリモート・サーバに依頼することです。各システムが使用するリモート認証方式は,Tru64 UNIX システムとリモート・サーバで設定される共通のリモート認証方式およびやり取りされるデータの種類によって決まります。
リモート・サーバが認証するユーザ名とパスワードのデータは,NIS や LDAP を使ってやり取りできます。
rcp
,rlogin
,rsh
の各ネットワーク・コマンドを使ってやり取りされるデータには,セキュア・シェルまたは Kerberos を使用できます。
ftp
,telnet
の各ネットワーク・コマンドを使ってやり取りされるデータには,Kerberos を使用できます。
rcmd()
関数を使用するアプリケーションによってやり取りされるデータには,セキュア・シェルを使用できます。
IP トランスポートを使ってやり取りされるデータには,IPsec を使用できます。
分散アプリケーションによってやり取りされるデータには,SSL,CDSA,または GSS の各 API を使用できます。
以降の項では,各種のリモート認証方式について説明します。
1.4.1 NIS プロトコル
NIS は,LAN (ローカル・エリア・ネットワーク) で情報を共有するための分散クライアント/サーバ型データ検索サービスです。
NIS サーバには,BSD セキュリティやエンハンスト・セキュリティのユーザ・アカウント・データベースの一部または全部を格納できます。ユーザが NIS クライアントとして構成されたシステムにログインするためにユーザ名とパスワードを入力すると,NIS クライアントはそのユーザ情報を NIS サーバに送信して認証処理を依頼します。NIS サーバはユーザ情報をデータベース内のエントリと照合し,その結果を NIS クライアントに返信します。一致するエントリが存在し,パスワードが正しければ,認証に成功し,ユーザはログインすることができます。一致するエントリが存在しないと,認証に失敗し,ユーザはログインできません。
Tru64 UNIX システムは,NIS クライアントおよび NIS サーバとして構成できます。NIS の詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。
1.4.2 LDAP メカニズム
LDAP (Lightweight Directory Access Protocol) は,TCP/IP 上で動作するインターネット標準の分散クライアント/サーバ型ディレクトリ・サービスのプロトコルです。
LDAP サーバは,ユーザの識別情報と承認情報を LDAP ディレクトリのエントリとして格納します。ユーザが LDAP クライアントとして構成されたシステムにログインするためにユーザ名とパスワードを入力すると,LDAP クライアントはそのユーザ情報を LDAP サーバに送信して認証処理を依頼します。LDAP サーバはユーザ情報を LDAP ディレクトリ内のエントリと照合し,その結果を LDAP クライアントに返信します。一致するエントリが存在し,パスワードが正しければ,認証に成功し,ユーザはログインすることができます。一致するエントリが存在しないと,認証に失敗し,ユーザはログインできません。
Tru64 UNIX システムは,LDAP クライアントおよび LDAP サーバとして構成できます。ユーザ認証のために Tru64 UNIX を LDAP クライアントとして構成する方法については,付録 D
を参照してください。
1.4.3 セキュア・シェル・アプリケーション
セキュア・シェルは,一連のネットワーク・コマンドを提供するクライアント/サーバ型アプリケーションです。セキュア・シェル・コマンドを使ってデータをやり取りすることにより,リモート認証サービスが提供されます。セキュア・シェル・コマンドは,従来の安全性の低いネットワーク・コマンドに追加して,またはそれらに代えて使用できます (表 1-2)。
表 1-2: セキュア・シェル・コマンド
作業 | 従来のコマンド | セキュア・シェル・コマンド |
リモート・システム上でのコマンド実行 | rsh |
ssh |
リモート・システムへのログイン | rlogin
または
telnet |
ssh |
システム間のファイル転送 | rcp
または
ftp |
scp
または
sftp |
必要に応じて,rcp
,rlogin
,rsh
の各コマンドおよび
rcmd()
関数の使用時に自動的にセキュア・シェルが使われるように構成することもできます。
特に指定がなければ,オペレーティング・システム・ソフトウェアを Tru64 UNIX Version 5.1B 以上にアップグレードしたとき,またはこれらのバージョンをインストールしたときにセキュア・シェル・ソフトウェアがインストールされます。セキュア・シェル・ソフトウェアの設定と使用の詳細については,付録 Bを参照してください。
1.4.4 SSO/Kerberos メカニズム
Single Sign On (SSO) ソフトウェアは,ftp
,rcp
,rlogin
,rsh
,telnet
の各ネットワーク・コマンドを使ってデータをやり取りする場合に,Kerberos を使ったリモート認証サービスを提供するオプションのクライアント/サーバ型ソフトウェアです。
SSO ソフトウェアのインストール,設定,および使用の詳細については,付録 Cを参照してください。
1.4.5 Advanced Server for UNIX (ASU)
Advanced Server for UNIX (ASU) ソフトウェアは,認証要求を Windows NT Server Version 4.0 に転送するように Tru64 UNIX オペレーティング・システム・ソフトウェアを構成するためのメカニズムを提供するオプションのクライアント/サーバ型ソフトウェアです。
Tru64 UNIX システムに代わって,Windows NT Server Version 4.0 がユーザ・アカウント情報を使ってユーザを認証します。この機能は,Windows NT Server Version 4.0 上にユーザ・アカウント情報があり,Tru64 UNIX システム上にユーザ・アカウント・データベースを作成したくない場合に便利です。
Windows NT Version 4.0 の認証に関する設定の詳細については,ASU の『Advanced Server for UNIX インストレーション/管理ガイド』 を参照してください。
1.4.6 IPsec プロトコル
IPsec プロトコルは,TCP/IP トランスポート・プロトコルを使ってやり取りされるデータに IP 層での認証サービスを提供するオプションのセキュリティ・フレームワークです。
IPsec を有効にして IP 層を保護し,使用する接続を構成することにより,ネットワークを保護することができます。アプリケーション,コマンド,ユーティリティは,変更せずにそのまま IPsec を使用できます。
IPsec の有効化と構成の詳細については,『ネットワーク管理ガイド』を参照してください。
1.4.7 SSL,CDSA,および GSS の API
SSL (Secure Socket Layer) API,CDSA (Common Data Security Architecture) API,および GSS (Generic Security Service) API は,これらの API を使用する分散アプリケーションに対してリモート認証サービスを提供します。これらの API を使用するアプリケーションは,基盤となるセキュリティ・メカニズムを意識することなくリモート認証サービスを要求できます。これらのセキュリティ API は,広範囲のセキュリティ・メカニズムをサポートします。
CDSA は,アプリケーションが特定のサービスに関して使用するリモート認証サービス・モジュールをソフトウェアやハードウェアのベンダが作成するアーキテクチャです。アプリケーションは,CSSM (Common Security Services Manager) API を使って CDSA 内のモジュールにリモート認証サービスを要求します。
SSL API は,主に Web アプリケーション開発者が複数のソケット間でリモート認証サービスを提供するために使用します。
GSS API は,ソケット方式のプロトコルに基づいてネットワーク内でアプリケーションがリモート認証サービスを提供できるようにします。これにより,クライアントは必要な認証メカニズムがサーバにあるかどうかを判定した後,そのメカニズムを使って認証を行います。
詳細については,
cdsa
(3)ssl
(3)1.5 セキュリティ統合アーキテクチャの概要
Tru64 UNIX を構成して,1 つまたは複数のセキュリティ方式を使用するようにできます。Tru64 UNIX では,セキュリティ方式の適用順序がセキュリティ統合アーキテクチャ (SIA) によって管理されています。各セキュリティ方式によってセキュリティ・メカニズムが提供され,SIA に追加されます。セキュリティ・メカニズムは,認証の方法を決定するための独自のルールと,エンティティを認証する前にそのメカニズムが達成すべき信頼性レベルを定義したものです。
SIA には 2 つのインタフェース・レイヤがあります。1 つはアプリケーション,コマンド,およびユーティリティを作るプログラマ向けのメカニズム非依存インタフェースで,もう 1 つはシステム・セキュリティのプロバイダ用のメカニズム依存インタフェースです。セキュリティを扱うアプリケーション,コマンド,ユーティリティは,セキュリティ・サービスを提供するために SIA のメカニズム非依存インタフェースを呼び出します。メカニズム非依存インタフェースは,構成された各 SIA メカニズム・レイヤの対応するルーチンを呼び出して,要求されたアクセスが許可されるかどうかを判定します。
システム・セキュリティのプロバイダは,あらかじめ定義された一連のエントリ・ポイントを持つ共有ライブラリとしてセキュリティ・メカニズムを提供します。これにより,セキュリティ・ニーズの変化に合わせて,アプリケーション,コマンド,ユーティリティに変更を加えずに新しい SIA メカニズムを追加できます。
Tru64 UNIX では,次のセキュリティ・メカニズムが提供されます。
libc.so
ライブラリの基本 ( BSD) セキュリティ・メカニズム (標準)。
/usr/shlib/libsecurity.so
ライブラリのエンハンスト・セキュリティ・メカニズム。これは,OSFC2SEC
サブセットに格納されているオプションのメカニズムです。
/usr/shlib/libsialdap.so
ライブラリの LDAP メカニズム。これは,OSFLDAPAUTH
サブセットと
OSFSSOW2K
サブセットに格納されているオプションのメカニズムです。
/usr/shlib/libcsfk5siad.so
ライブラリの Kerberos ベースのメカニズム。これは,OSFSSOW2K
サブセットに格納されているオプションのメカニズムです。
SIA メカニズムでは,次の基本領域を扱う一連の定義済みインタフェースを使ってセキュリティ・ポリシが実装されます。
セッション制御
認証 (パスワードと承認) データの取得
パスワード,finger 情報,シェル・データの変更
SIA メカニズムではすべてのセキュリティ機能を提供する必要はありませんが,データベースの変更機能を提供する場合はセッション機能も提供する必要があります。
SIA フレームワークにより,Tru64 UNIX システムや TruCluster Server 環境で複数のメカニズムが共存できる構造が提供されます。たとえば,ユーザが Kerberos パスワードを使ってログインしようとしたが,Kerberos サーバが稼動していないために認証に失敗した場合,同じログイン処理の中でローカルの
/etc/passwd
ファイルを使った省略時の BSD メカニズムによるユーザ認証を自動的に実行することができます。図 1-1
に,SIA のアーキテクチャを示します。
図 1-1: セキュリティ統合アーキテクチャ
ユーザが変更ルーチンのコマンド (passwd
,chfn
,chsh
などのコマンド) を入力すると,メカニズム依存ルーチンが呼び出され,実行しようとしている変更がセキュリティ・メカニズムによってサポートされているかどうか,および変更の対象となるユーザがセキュリティ・メカニズムによって認識されているかどうかが判定されます。
chfn
コマンドや
chsh
を使って finger 情報やシェル情報を変更する場合,そのユーザが複数のセキュリティ・メカニズムによって認識されていると,変更を適用するセキュリティ・メカニズムをユーザに選択してもらうためのメニューが表示されます。
passwd
コマンドを使ってパスワード情報を変更する場合は,メカニズム非依存インタフェースによって該当するユーザのパスワード変更をサポートするセキュリティ・メカニズムが識別されます。複数のセキュリティ・メカニズムが識別された場合は,パスワードの変更を適用するメカニズムをユーザに選択してもらうためのメニューが表示されます。1 つまたは全部を選択できます。
変更ルーチンの詳細については,『システム管理ガイド』を参照してください。
1.5.2 SIA の構成
SIA を設定すると,1 つまたは複数のセキュリティ・メカニズムを使用できるようになります。一般的なセキュリティ・メカニズムの組み合わせには,ローカル・システムのセキュリティのみを扱うローカル・メカニズムといくつかのシステムにまたがるセキュリティ事項を扱うリモート (分散) セキュリティ・メカニズムが含まれています。SIA の階層構造により,これら 2 つのメカニズムは共存できるようになっています。メカニズム依存ルーチンは,ユーザがセキュリティ・メカニズムによって認識されているかどうかに基づいて認証を処理します。メカニズムの統合は,たとえばログインやセッションの処理に有効です。SIA の階層構造により,セッション処理時に複数のセキュリティ・メカニズム間でコンテキストが受け渡されます。このコンテキストには,収集された名前,パスフレーズ,およびセッション処理の現在の状態が含まれています。
各セキュリティ・メカニズムは,以前に実行されたメカニズムの認証プロセスを信頼することができます。これにより,認証の保証が可能になります。この場合,分散メカニズムがユーザの認証に成功すると,ローカル・メカニズムはその認証を信頼して受け入れ,セッション処理を継続することができます。また,SIA ではローカル・メカニズムが保証を受け入れないようにすることもできます。この場合,以前の認証結果に関係なく,ローカル・メカニズムで独自の認証処理が実行されます。その結果,ユーザに対してパスワードの入力要求が複数回行われることがあります。SIA ではメカニズムの順序は任意ですが,保証を受け入れるメカニズムは保証を受け入れないメカニズムの後に構成してください。Tru64 UNIX によって提供されるメカニズムは,保証を受け入れます。
/etc/sia/matrix.conf
ファイルには,SIA メカニズムごとのエントリを作成する必要があります。SIA メカニズムが呼び出される順序は,matrix.conf
ファイル内のエントリの並び順によって決まります。matrix.conf
ファイル内の SIA メカニズムのエントリは,/usr/sbin/siacfg
ユーティリティを使って管理します。
matrix.conf
ファイルには,事前に定義されたメカニズム依存インタフェース
siad_*()
が 1 行ごとに指定されています。各行には,一意のメカニズム識別子 (または
mech_type
) とそのメカニズムの共有ライブラリへのパスで構成される属性が含まれています。次に
matrix.conf
ファイルのエントリの例を示します。
siad_init=(BSD,libc.so)
siad_init
はルーチン名,BSD
は一意の識別子,libc.so
は
siad_init
ルーチンを持つ共有ライブラリ名です。libc.so
ライブラリには省略時のメカニズムが含まれていて,このライブラリは既に開かれているので,このライブラリへのパスを指定する必要はありません。複数のメカニズムを構成する場合は,次のように 1 つのエントリに複数の属性を指定します。
siad_init=(OSFC2,/usr/shlib/libsecurity.so),(BSD,libc.so)
この場合は,最初に
libsecurity.so
ライブラリ内の
siad_init
ルーチンが呼び出され,次に
libc.so
ライブラリのルーチンが呼び出されます。sia_*()
インタフェースは,この属性セットを使って各メカニズムを左から右へ順番に呼び出します。特定のカテゴリのインタフェースに対するサポートがメカニズムによって提供されない場合は,省略時の BSD メカニズムが使われます。
注意
Tru64 UNIX Version 5.0 以前は,
siacfg
コマンドが存在しませんでした。また,matrix.conf
ファイルを編集できないようにし,依存するメカニズムのプロバイダから各メカニズムの属性を含む構成ファイルが提供されるようにするため,/etc/sia/matrix.conf
ファイルは別のファイル (/etc/sia/bsd_matrix.conf
ファイルや/etc/sia/OSFC2_matrix.conf
ファイルなど) へのリンクになっていました。
Tru64 UNIX オペレーティング・システムには,libc.so
ライブラリに含まれる BSD メカニズムのルーチンを使用する省略時の
matrix.conf
ファイルが用意されています。例 1-1
に省略時の
matrix.conf
ファイルを示します。
例 1-1: 省略時の /etc/sia/matrix.conf ファイル
# sia matrix configuration file (BSD only) siad_init=(BSD,libc.so) siad_chk_invoker=(BSD,libc.so) siad_ses_init=(BSD,libc.so) siad_ses_authent=(BSD,libc.so) siad_ses_estab=(BSD,libc.so) siad_ses_launch=(BSD,libc.so) siad_ses_suauthent=(BSD,libc.so) siad_ses_reauthent=(BSD,libc.so) siad_chg_finger=(BSD,libc.so) siad_chg_password=(BSD,libc.so) siad_chg_shell=(BSD,libc.so) siad_getpwent=(BSD,libc.so) siad_getpwuid=(BSD,libc.so) siad_getpwnam=(BSD,libc.so) siad_setpwent=(BSD,libc.so) siad_endpwent=(BSD,libc.so) siad_getgrent=(BSD,libc.so) siad_getgrgid=(BSD,libc.so) siad_getgrnam=(BSD,libc.so) siad_setgrent=(BSD,libc.so) siad_endgrent=(BSD,libc.so) siad_ses_release=(BSD,libc.so) siad_chk_user=(BSD,libc.so)
SIA メカニズムは,システムのブート時に
/usr/sbin/siainit
ユーティリティによって初期化されます。siainit
ユーティリティは,/etc/sia/matrix.conf
ファイルを読み込み,siad_init()
エントリ・ポイントに設定された各メカニズムを呼び出してブート時の初期化処理を実行します。
siad_init()
の呼び出しによってエラーが返されると,システムは強制的にシングル・ユーザ・モードに移行し,コンソールに "SIA Initialization Failure
" というメッセージが表示されます。このため,siad_init()
の呼び出しによってエラーが返るのは,セキュリティ上の問題が発生した場合,または root ユーザにログインが許可されない場合に限られます。siad_init()
ルーチンの実行に成功すると,/etc/sia/siainitgood
ファイルが (存在しない場合は) 作成されます。実行に失敗すると,/etc/sia/siainitgood
ファイルは削除されます。
TruCluster 環境では,siainitgood
ファイルが削除されると,問題が解決されるまで各ノードで実行されるプロセスが認証要求や承認要求の処理に失敗し始めます。引き続き SIA インタフェースを使用した場合は,構成されているメカニズムごとに
matrix.conf
のエントリ・ポイントを記述する内部構造を設定する前に,siainitgood
ファイルの存在確認が行われます。
1.5.2.2 SIA メカニズムの追加
各 SIA メカニズムのプロバイダは,siacfg
コマンドを使って,該当するメカニズムをサポートするように
matrix.conf
ファイルを更新します。
SIA にメカニズムを追加するときは,siacfg
コマンドにメカニズムの一意の名前とメカニズムの共有ライブラリの場所を指定する必要があります。siacfg
コマンドは指定されたライブラリを開き,すべての関数カテゴリを検索し,必要な関数 (ルーチン) がすべてライブラリにあることを確認します。必要なルーチンがすべて見つかったら,各ルーチンのエントリを
matrix.conf
ファイルに追加します。
SIA メカニズムを手作業で追加するときは,以下の手順に従います。
インストール手順に従ってメカニズムをインストールします。
/etc/sia
ディレクトリに移動します。
次のようにして SIA メカニズムを追加します。
#
/sbin/siacfg -a
SIA_mechanism_name
library_path
次のようにしてシステムをリブートします。
#
/usr/sbin/reboot
次のようにしてシステムをシングル・ユーザ・モードにします。
#
/usr/sbin/shutdown now
次のようにして SIA メカニズムを削除します。
#
/sbin/siacfg -r
SIA_mechanism_name
siacfg
コマンドは,SIA_mechanism_name
に指定された名前を持つルーチン・エントリを
matrix.conf
ファイルから削除します。
次のようにしてシステムをリブートします。
#
/usr/sbin/reboot
SIA は,呼び出し側のコマンドやユーティリティに返される成功または失敗の応答の受け渡しのみをサポートします。このため,どの SIA メカニズムでエラーが発生したかを判定するのがむずかしい場合があります。そのため,SIA には,次の種類のログ・エントリについてタイムスタンプ付きのエントリを
/var/adm/sialog
ファイルに生成する汎用のロギング機能が用意されています。
EVENT
。通常は SIA 内の処理に成功したことを表します。
ERROR
。通常は SIA 内の処理に失敗したことを表します。
ALERT
。SIA インタフェース内のセキュリティ構成やセキュリティ上のリスクを表します。
次のようにして
/var/adm/sialog
ファイルを作成する必要があります。
# touch /var/adm/sialog
例 1-2
に
/var/adm/sialog
ファイルの例を示します。
例 1-2: /var/adm/sialog ファイルの例
SIA:EVENT Wed Feb 3 05:21:31 2002 Successful SIA initialization SIA:EVENT Wed Feb 3 05:22:08 2002 Successful session authentication for terry on :0 SIA:EVENT Wed Feb 3 05:22:08 2002 Successful establishment of session SIA:ERROR Wed Feb 3 05:22:47 2002 Failure to authenticate session for root on :0 SIA:ERROR Wed Feb 3 05:22:52 2002 Failure to authenticate session for root on :0 SIA:EVENT Wed Feb 3 05:22:59 2002 Successful session authentication for root on :0 SIA:EVENT Wed Feb 3 05:22:59 2002 Successful establishment of session SIA:EVENT Wed Feb 3 05:23:00 2002 Successful launching of session SIA:EVENT Wed Feb 3 05:24:40 2002 Successful authentication for su from root to terry SIA:EVENT Wed Feb 3 05:25:46 2002 Successful password change for terry