test

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

第 16 章 認証サービスの使用 (手順)

この章では、Secure RPC を使用して NFS マウントでホストとユーザーを認証する方法について説明します。この章で説明する内容は次のとおりです。

Secure RPC の概要

Secure RPC (遠隔手続き呼び出し) は、認証メカニズムによって遠隔手続きを保護します。Diffie-Hellman 認証メカニズムは、サービスを要求するホストとユーザーを認証します。この認証メカニズムはデータ暗号化規格 (Data Encryption Standard、DES) 暗号化を使用します。Secure RPC を使用するアプリケーションには、NFS、およびネームサービスの NIS と NIS+ があります。

NFS サービスと Secure RPC

NFS を使用すると、複数のホストがネットワーク上でファイルを共有できます。NFS サービスでは、サーバーは、複数のクライアントから利用できるデータとリソースを保持します。クライアントは、サーバーがクライアントと共有するファイルシステムにアクセスできます。クライアントシステムにログインしたユーザーは、ファイルシステムをサーバーからマウントすることによって、そのファイルシステムにアクセスできます。このとき、クライアントシステム上のユーザーには、ファイルはクライアントのローカルファイルシステム上にあるように見えます。NFS のもっとも一般的な使用形態の 1 つは、システムを各オフィスにインストールして、すべてのユーザーファイルを 1 箇所で集中管理することです。mount コマンドの -nosuid オプションなどのいくつかの NFS 機能を使用すると、権限を持たないユーザーがデバイスやファイルシステムにアクセスすることを禁止できます。

NFS サービスでは Secure RPC を使用して、要求を出したユーザーをネットワーク上で認証します。このプロセスは、Secure NFS と呼ばれます。Diffie-Hellman 認証メカニズム AUTH_DH は、DES 暗号化を使用し、承認されたアクセスを保証します。AUTH_DH メカニズムは、AUTH_DES とも呼ばれます。詳細については、次を参照してください。

Secure NFS での DES 暗号化

データ暗号化規格 (Data Encryption Standard、DES) 暗号化機能は 56 ビットの鍵を使用して、データを暗号化します。資格を持つ 2 人のユーザー、すなわち主体が同じ DES 鍵を知っている場合、その鍵を使用してテキストを暗号化または復号化することによって、プライベートに通信できます。DES は比較的高速な暗号化メカニズムです。DES チップは暗号化をより高速にします。ただし、チップがなくても、ソフトウェアで代用できます。

DES 鍵を使用する上での問題点は、同じ鍵で暗号化された多数のテキストメッセージを侵入者が収集することによって、鍵が発見されてメッセージが解読される危険性があるということです。このため、Secure NFS などのセキュリティーシステムは鍵を頻繁に変更する必要があります。

Kerberos 認証

Kerberos は、マサチューセッツ工科大学 (MIT) で開発された認証システムです。Kerberos には DES に基づく暗号化もあります。Kerberos V4 は、Secure RPC ではサポートされていません。クライアント側とサーバー側には、RPCSEC_GSS を使用する Kerberos V5 がこのリリースに実装されています。詳細については、第 21 章Kerberos サービスについてを参照してください。

Diffie-Hellman 認証と Secure RPC

Diffie-Hellman (DH) のユーザー認証方式は簡単には破られません。クライアントとサーバーは、独自の非公開鍵と公開鍵を使って共通鍵を作り出します。非公開鍵は秘密鍵とも呼ばれます。クライアントとサーバーは、共通鍵を使って相互に通信します。共通鍵は、相互に合意した暗号化機能 (DES など) によって暗号化されます。

認証では、送信側のシステムの共通鍵を使用して現在の時刻を暗号化する機能を利用します。受信側のシステムは、その現在の時刻を復号し、自分の時刻と照合します。クライアントとサーバーで時刻が同期している必要があります。詳細については、『Solaris のシステム管理 (ネットワークサービス)』の「NTP の管理 (作業)」を参照してください。

公開鍵と非公開鍵は、NIS または NIS+ のデータベースに格納されます。NIS では、これらの鍵を publickey マップに格納します。NIS+ では、cred テーブルに格納します。これらのファイルには、すべてのユーザーの公開鍵と非公開鍵が入っています。

システム管理者は、NIS マップまたは NIS+ のテーブルを設定して、ユーザーごとに公開鍵と非公開鍵を生成する必要があります。非公開鍵は、ユーザーのパスワードで暗号化されて格納されます。これにより、その非公開鍵はそのユーザーだけが知っていることになります。

Diffie-Hellman 認証の実装

この節では、Diffie-Hellman 認証 (AUTH_DH) を使用するクライアントサーバーセッションにおける一連のトランザクションを説明します。

Secure RPC 用の公開鍵と秘密鍵を生成

システム管理者は、認証を開始する前に、newkey または nisaddcred コマンドを実行して公開鍵と秘密鍵を生成します。ユーザーごとに一意の公開鍵と秘密鍵が与えられます。公開鍵は、公開データベースに格納されます。秘密鍵は、暗号化された形式で、同じデータベースに格納されます。chkey コマンドは、公開鍵と秘密鍵のペアを変更します。

Secure RPC 用に keylogin コマンドを実行する

通常、ログインパスワードは Secure RPC パスワードと同じです。この場合、keylogin コマンドは必要ありません。ただし、これらのパスワードが異なる場合は、ユーザーはログインしたあとに keylogin コマンドを実行する必要があります。

keylogin コマンドを入力すると、Secure RPC パスワードの入力を求めるプロンプトが表示されます。コマンドは、このパスワードを使って秘密鍵を復号化します。次に keylogin コマンドは、復号化された秘密鍵をキーサーバープログラムに渡します。キーサーバーは、各コンピュータ上でローカルインスタンスを伴う RPC サービスです。キーサーバーは、復号化された秘密鍵を格納し、ユーザーとサーバーが Secure RPC トランザクションを開始するのを待機します。

ログインパスワードと RPC パスワードが一致している場合は、ログインプロセスは秘密鍵をキーサーバーに渡します。これらのパスワードが異なる場合は、ユーザーが常に keylogin コマンドを実行する必要があります。keylogin コマンドをユーザーの環境構成ファイル ( ~/.login、~/.cshrc、~/.profile ファイルなど) に設定すると、ユーザーがログインしたときに、keylogin コマンドが自動的に実行されます。

Secure RPC 用の対話鍵の生成

    ユーザーがサーバーとトランザクションを開始すると、次の処理が行われます。

  1. キーサーバーはランダムに対話鍵を生成します。

  2. カーネルは、この対話鍵などを使用してクライアントのタイムスタンプを暗号化します。

  3. キーサーバーは、公開鍵データベースからサーバーの公開鍵を検索します。詳細は、publickey(4) のマニュアルページを参照してください。

  4. キーサーバーはクライアントの秘密鍵とサーバーの公開鍵を使用して、共通鍵を作成します。

  5. キーサーバーは共通鍵を使用して対話鍵を暗号化します。

Secure RPC におけるサーバーとの最初の通信

次に、暗号化したタイムスタンプと暗号化した対話鍵を含む伝送データがサーバーに送信されます。伝送データには資格とベリファイアが含まれます。資格は、次の 3 つの構成要素を持ちます。

この場合の「ウィンドウ」とは、サーバーの時刻とクライアントのタイムスタンプとの間で許容される時間差のことで、クライアントが指定します。サーバーの時刻とクライアントのタイムスタンプとの間の差がウィンドウより大きい場合、サーバーはクライアントの要求を拒否します。通常の状態では、クライアントは RPC セッションを開始する前にサーバーと同期を取るため、クライアントの要求は拒否されません。

クライアントベリファイアは、次の要素で構成されます。

ウィンドウベリファイアは、他人がユーザーになりすますのを防ぐために使用されます。なりすましを試みる人は、資格やベリファイアの暗号化された各フィールドに正しい情報の代わりにランダムなビットを挿入するプログラムを作成します。サーバーはこの対話鍵を任意のランダム鍵に復号化し、それを使用してウィンドウとタイムスタンプを復号化しようと試みます。結果は、乱数が生成されるだけです。しかし、数千回の試行を重ねるうちには、このランダムなウィンドウとタイムスタンプのペアが認証システムを通過することが十分ありえます。ウィンドウベリファイアは、偽の資格が認証される可能性を小さくします。

Secure RPC における対話鍵の復号化

    サーバーがクライアントから伝送データを受信すると、次の処理が行われます。

  1. キーサーバーは、公開鍵データベース内でクライアントの公開鍵を検索します。

  2. キーサーバーはクライアントの公開鍵とサーバーの秘密鍵を使用して、共通鍵を計 算します。この共通鍵はクライアントが計算したものと同じです。共通鍵の計算は、秘密鍵の 1 つを知っている必要があるため、そのサーバーとクライアント以外は計算できません。

  3. カーネルは共通鍵を使用して、対話鍵を復号化します。

  4. カーネルはキーサーバーを呼び出して、復号化された対話鍵によりクライアントのタイムスタンプを復号化します。

Secure RPC におけるサーバーへの情報の格納

サーバーは、クライアントのタイムスタンプを復号化したあと、次の 4 つの情報を資格テーブルに格納します。

サーバーは、最初の 3 つの情報を将来の使用のために格納します。サーバーはクライアントのタイムスタンプを格納して、同じタイムスタンプが再度使用できないようにします。サーバーは、最後に参照したタイムスタンプよりも時間的にあとのタイムスタンプだけを受け付けます。結果として、すでに届いたトランザクションと同じタイムスタンプを持つトランザクションはすべて拒否されることが保証されます。

注 –

このトランザクションにおいて暗黙的に仮定されているのは呼び出し側の名前であり、何らかの方法でこの名前を認証する必要があります。キーサーバーは、呼び出し側を認証するときに、DES 認証を使用できません。キーサーバーが DES 認証を使用すると、デッドロックが発生するためです。キーサーバーは、ユーザー ID (UID) ごとに秘密鍵を格納し、ローカルの root のプロセスへの要求だけを認可することによってデッドロックを回避します。

Secure RPC でベリファイアをクライアントに返す

サーバーは、ベリファイアをクライアントに返します。ベリファイアには、次の構成要素が含まれます。

クライアントのタイムスタンプから 1 を引くのは、タイムスタンプを期限切れにするためです。期限切れのタイムスタンプはクライアントのベリファイアとして再利用できません。

Secure RPC におけるサーバーの認証

クライアントがベリファイアを受信し、そのサーバーを認証します。クライアントは、このベリファイアを送信できるのはサーバーだけであることを知っています。その理由は、クライアントが送信したタイムスタンプの内容を知っているのはサーバーだけだからです。

Secure RPC におけるトランザクションの処理

2 番目以降のすべてのトランザクションごとに、クライアントは次のトランザクションでインデックス ID をサーバーに返します。クライアントは、もう 1 つの暗号化されたタイムスタンプを送信します。サーバーは、クライアントのタイムスタンプから 1 を引いた値を対話鍵で暗号化して、返信します。

Secure RPC の管理 (作業マップ)

次の作業マップでは、NIS、NIS+、および NFS に対して Secure RPC を構成する手順を示します。

作業 

説明 

参照先 

1. キーサーバーを起動します。 

ユーザーが認証されるために鍵を作成できるようにします。 

「Secure RPC キーサーバーを再起動する方法」

2. NIS+ ホストで資格を設定します。 

NIS+ 環境でホスト上の root ユーザーが認証されるようにします。

「NIS+ ホストに Diffie-Hellman 鍵を設定する方法」

3. NIS+ ユーザーに鍵を指定します。 

NIS+ 環境でユーザーが認証されるようにします。 

「NIS+ ユーザーに Diffie-Hellman 鍵を設定する方法」

4. NIS ホストで資格を設定します。 

NIS 環境でホスト上の root ユーザーが認証されるようにします。

「NIS ホストに Diffie-Hellman 鍵を設定する方法」

5. NIS ユーザーに鍵を指定します。 

NIS 環境でユーザーが認証されるようにします。 

「NIS ユーザーに Diffie-Hellman 鍵を設定する方法」

6. 認証によって NFS ファイルを共有します。 

NFS サーバーが認証によって共有ファイルシステムを安全に保護できるようにします。 

「Diffie-Hellman 認証で NFS ファイルを共有する方法」

Secure RPC による認証の管理

マウントされた NFS ファイルシステムの使用に対する認証を要求することにより、ネットワークのセキュリティーが増します。

ProcedureSecure RPC キーサーバーを再起動する方法

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. keyserv デーモンが動作していることを検証します。


    # svcs \*keyserv\*
STATE    STIME   FMRI
disabled Dec_14  svc:/network/rpc/keyserv

  3. キーサーバーサービスがオンラインになっていない場合は、サービスを有効にします。


    # svcadm enable network/rpc/keyserv

ProcedureNIS+ ホストに Diffie-Hellman 鍵を設定する方法

この手順は、NIS+ ドメインのすべてのホストで実行します。root が keylogin コマンドを実行すると、サーバーはmech_dhに対して GSS-API のアクセプタの資格をもち、クライアントは GSS-API のイニシエータの資格を持ちます。

NIS+ セキュリティーの詳細については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : NIS+ 編)』を参照してください。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. ネームサービスの publickey テーブルを有効にします。

    次の行を /etc/nsswitch.conf ファイルに追加します。


    publickey: nisplus

  3. NIS+ クライアントを起動します。


    # nisinit -cH hostname

    hostname は、そのテーブルにクライアントシステム用のエントリを持つ、信頼されている NIS+ サーバー名です。

  4. クライアントを cred テーブルに追加します。

    次のコマンドを入力します。 


    # nisaddcred local
# nisaddcred des

  5. keylogin コマンドを使用して、設定を確認します。

    パスワードを求めるプロンプトが出力されたら、この手順は成功です。


    # keylogin
Password:
例 16–1 NIS+ クライアント上で root の新しい鍵を設定する

次の例は、ホスト pluto を使用して、earth を NIS+ クライアントとして設定しています。警告は無視できます。keylogin コマンドが受け付けられて、earth がセキュリティー保護された NIS+ クライアントとして正しく設定されていることを確認しています。


# nisinit -cH pluto
NIS Server/Client setup utility.
This system is in the example.com. directory.
Setting up NIS+ client ...
All done.
# nisaddcred local
# nisaddcred des 
DES principal name : unix.earth@example.com
Adding new key for unix.earth@example.com (earth.example.com.)
Network password:<Type password>
Warning, password differs from login password.
Retype password: <Retype password>
# keylogin
Password:        <Type password>
#

ProcedureNIS+ ユーザーに Diffie-Hellman 鍵を設定する方法

この手順は、NIS+ ドメインのすべてのユーザーで実行します。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. ユーザーをルートマスターサーバー上の cred テーブルに追加します。

    次のコマンドを入力します。


    # nisaddcred -p unix.UID@domain-name -P username.domain-name. des

    この場合、username.domain-name の終わりにピリオド (.) を付けてください。

  3. クライアントとしてログインし、keylogin コマンドを入力して、設定を確認します。

例 16–2 NIS+ ユーザー用の新しい鍵を設定する

次の例では、Diffie-Hellman 認証用の鍵をユーザー jdoe に与えます。


# nisaddcred -p unix.1234@example.com -P jdoe.example.com. des
DES principal name : unix.1234@example.com
Adding new key for unix.1234@example.com (jdoe.example.com.)
Password:       <Type password>
Retype password:<Retype password>
# rlogin rootmaster -l jdoe
% keylogin
Password:       <Type password>
%

ProcedureNIS ホストに Diffie-Hellman 鍵を設定する方法

この手順は、NIS ドメインのすべてのホストで実行します。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. ネームサービスの publickey マップを有効にします。

    次の行を /etc/nsswitch.conf ファイルに追加します。


    publickey: nis

  3. newkey コマンドを使用して、新しい鍵のペアを作成します。


    # newkey -h hostname

    hostname は、クライアント名です。

例 16–3 NIS クライアント上で root の新しい鍵を設定する

次の例では、earth をセキュリティー保護された NIS クライアントとして設定します。


# newkey -h earth
Adding new key for unix.earth@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

ProcedureNIS ユーザーに Diffie-Hellman 鍵を設定する方法

この手順は、NIS ドメインの各ユーザーに対して実行します。

始める前に

システム管理者だけが NIS マスターサーバーにログインしたときに、ユーザーの新しい鍵を作成できます。

  1. Primary Administrator 役割を引き受けるか、スーパーユーザーになります。

    Primary Administrator 役割には、Primary Administrator プロファイルが含まれます。役割を作成してユーザーに役割を割り当てるには、『Solaris のシステム管理 (基本編)』の第 2 章「Solaris 管理コンソールの操作 (手順)」を参照してください。

  2. ユーザーの新しい鍵を作成します。


    # newkey -u username

    username はユーザー名です。システムはパスワードを求めるプロンプトを出します。汎用パスワードを入力できます。非公開鍵は、汎用パスワードを使用して暗号化されて格納されます。

  3. ユーザーに、ログインして chkey -p コマンドを入力するように伝えます。

    このコマンドでは、そのユーザーは自分だけが知っているパスワードを使用して、自分の非公開鍵を暗号化し直すことができます。

    注 –

    chkey コマンドを使用すると、新しい鍵のペアをユーザーに作成できます。

例 16–4 NIS で新しいユーザー鍵を設定して暗号化する

この例では、スーパーユーザーが鍵を設定します。


# newkey -u jdoe
Adding new key for unix.12345@example.com
New Password:   <Type password>
Retype password:<Retype password>
Please wait for the database to get updated...
Your new key has been successfully stored away.
#

次に、ユーザー jdoe が非公開パスワードで鍵を再暗号化します。


% chkey -p
Updating nis publickey database.
Reencrypting key for unix.12345@example.com
Please enter the Secure-RPC password for jdoe:<Type password>
Please enter the login password for jdoe:     <Type password>
Sending key change request to centralexample...

ProcedureDiffie-Hellman 認証で NFS ファイルを共有する方法

この手順では、アクセスに対する認証を要求することにより、NFS サーバー上で共有されているファイルシステムを保護します。

始める前に

Diffie-Hellman の公開鍵認証がネットワークで有効である必要があります。ネットワークで認証を有効にするには、次のいずれかを行います。

  1. スーパーユーザーになるか、System Management プロファイルを含む役割を引き受けます。

    System Administrator 役割には、System Management プロファイルが含まれます。役割を作成し、作成した役割をユーザーに割り当てる方法については、「RBAC の構成 (作業マップ)」を参照してください。

  2. NFS サーバーで、 Diffie-Hellman 認証でファイルシステムを共有します。


    # share -F nfs -o sec=dh /filesystem

    filesystem は、共有されているファイルシステムです。

    -o sec=dh オプションは、ファイルシステムにアクセスするために AUTH_DH 認証が必要になるということです。

  3. NFS クライアントで、Diffie-Hellman 認証でファイルシステムをマウントします。


    # mount -F nfs -o sec=dh server:filesystem mount-point
    server

    filesystem を共有しているシステムの名前です

    filesystem

    /opt など、共有されているファイルシステムの名前です

    mount-point

    /opt など、マウントポイントの名前です

    -o sec=dh オプションにより、AUTH_DH 認証を使ってファイルシステムがマウントされます。