test

NIS+ への移行

第 3 章 NIS+ セキュリティ基準の選択

この章では、名前空間のセキュリティに関する選択を行うための一般的な指針と推奨事項を示します。

NIS+ セキュリティの影響について理解する

NIS+ には、NIS にはなかったセキュリティが備わっているため、さらに多くの管理作業が必要になります。chkey、keylogin、または keylogout の手順の実行に慣れていないユーザーにも、より多くの作業が要求されることがあります。さらに、NIS+ によって提供される保護は、完璧に安全というものではありません。十分な計算能力と知識があれば、Diffie-Hellman 公開鍵暗号システムを破ることができます。

192 ビットを超える Diffie-Hellman 鍵を使用すると、NIS+ セキュリティが大幅に向上します。ただし、鍵が長くなるにつれて認証に必要な時間が長くなるため、性能が低下する可能性があります。

注 -

nisauthconf を使用して、この種類の Diffie-Hellman 鍵を設定します。長い鍵の使用については、nisauthconf(1M) を参照してください。

また、キーサーバープロセスによって格納された秘密鍵は、資格を持つ、ルート以外のユーザーがログアウトしても、そのユーザーが keylogout によってログアウトしないかぎり、自動的に削除されません。セキュリティは、ユーザーが keylogout(1) によってログアウトしたとしても、完全ではありません。これは、セッションキーが、その期限が切れるか、または再初期化されるまで、有効なためです (詳細については keylogout(1) のマニュアルページを参照してください)。ルートキーは、keylogin -r によって作成されて、/etc/.rootkey に格納されますが、これは .rootkey ファイルが明示的に削除されるまで残ります。スーパーユーザーは keylogout(1) を使用することができません。しかしそれでも、NIS+ は、NIS よりもはるかに安全です。

NIS+ セキュリティがユーザーに与える影響

NIS+ セキュリティを使用すると、NIS+ から取得する情報の信頼性が向上し、情報への不正なアクセスを防げるため、ユーザーにとって有益です。ただし、NIS+ セキュリティを使用するには、ユーザーは、セキュリティに関する若干の知識を習得して、2 〜 3 の管理手順を実行しなければなりません。

NIS+ ではネットワークログインが必要ですが、ユーザーがさらにキーログインを実行する必要はありません。これは、クライアントが正しく設定されていれば、login コマンドにより、そのクライアントのネットワーク鍵が自動的に取得されるためです。クライアントは、そのログインパスワードと SecureRPC パスワードが同じであれば、正しく設定されます。ユーザー root の秘密鍵は、通常、/etc/.rootkey ファイルで入手することができます (潜在的なセキュリティの問題として前述しました)。NIS+ ユーザーのパスワードと資格が、passwd コマンドによって変更されると、そのユーザーの資格情報も自動的に変更されます。

ただし、ユーザーがそのネットワークパスワードだけでなく、ローカルの /etc/passwd ファイルのパスワードも管理できて、これらのパスワードがネットワークパスワードと異なる場合、ユーザーは login を実行するたびに keylogin を実行しなければなりません。この理由は、『Solaris ネーミングの管理』のセキュリティに関する章に説明されています。

NIS+ セキュリティがシステム管理者に与える影響

Solaris オペレーティング環境は、認証のための DES 暗号機構を備えているため、セキュリティ保護操作を必要とするシステム管理者は、別に暗号キットを購入する必要がありません。ただし、システム管理者は、ユーザーに、passwd コマンドと passwd -r コマンドを使用する方法と、これらのコマンドをいつ使用するかを指示する必要があります。

また、セキュリティを強化した NIS+ 名前空間の設定は、通常の名前空間の設定よりも複雑です。この複雑さは、名前空間の設定に必要なステップが多いことだけではなく、すべての NIS+ 主体に対するユーザーの資格とマシンの資格を作成して管理しなければならないということに原因があります。管理者は、passwd テーブルとhosts テーブルから不要なアカウント情報を削除するのと同様に、不要な資格を削除する必要があります。また、管理者は、サーバーの公開鍵が変更された場合、nisupdkeys を使用して、名前空間全体の鍵も変更しなければなりません。さらに管理者は、他のドメインからこのドメインへのリモートログインを望んだり、NIS+ への認証されたアクセスを望むユーザーに対して、LOCAL 資格を追加しなければなりません。

NIS+ セキュリティが移行の計画に与える影響

NIS+ セキュリティの利点と管理上の要件をよく理解したら、NIS+ セキュリティを、移行中または移行後のどちらで実装するかを決める必要があります。NIS 互換モードで、ドメイン内のサーバーの一部またはすべてを操作している場合でも、完全な NIS+ セキュリティを使用するようお勧めします (ドメイン内のすべてのサーバーが同じ NIS 互換モードを使用しているのが、望ましい状態です)。ただし、これには管理の手間が非常にかかります。簡単な方法としては、NIS 互換セキュリティによって NIS+ サーバーと名前空間を設定し、NIS+ クライアントの資格は作成しないことです。ただし、管理者とサーバーには、やはり資格が必要です。NIS+ クライアントは、NIS クライアントとともに、未認証カテゴリに割り当てられます。これにより、学習と設定の作業は軽減されますが、次のような欠点があります。

資格を選択する

NIS+ には、LOCAL と DES という 2 つの種類の資格があります。

注 -

このマニュアルでは、「DES 資格」という用語は、拡張 640 ビット Diffie-Hellman 鍵と、オリジナルの 192 ビット Diffie-Hellman (デフォルト) 鍵の長さについて使用します。 cred テーブルでは、拡張鍵は DES キーワードではなく、DH640-0 のような着信先を使用します。長い鍵の使用については、nisauthconf(1M) を参照してください。

どの NIS+ 主体も、これらの資格のうち少なくとも 1 つを必要とします。名前空間がセキュリティレベル 2 (デフォルト) で管理されているときは、すべての NIS+ 主体 (クライアント) は、そのホームドメインに、DES 資格がなければなりません。また、すべてのユーザー (ワークステーションではなく) は、そのホームドメインと、ログインアクセスが必要な他のすべてのドメインに、LOCAL 資格がなければなりません。

名前空間の資格の必要を調べるには、次のことを検討してください。

NIS+ の主体になれるのは、ユーザーか、クライアントワークステーション上のスーパーユーザーです。図 3-1 を参照してください。

図 3-1 NIS+ の主体

Graphic

作成する必要がある資格を決めたら、その資格の対象となる主体の種類を確認してください。たとえば、NIS+ クライアントを nisclient によって設定した場合は、ワークステーションとユーザーの両方に資格を作成することになります。ユーザーの資格を作成しないと、そのユーザーには、未認証クラスに許可されたアクセス権しか与えられません。意図してそのように名前空間を設定している場合は、この設定は十分正しく機能します。しかし、未認証クラスにアクセス権を何も与えていないと、ユーザーはその名前空間を使用することができません。

セキュリティレベルを選択する

NIS+ はセキュリティレベル 2 で実行されるように設計されており、このレベルがデフォルトです。セキュリティレベルの 0 および 1 は、テストとデバッグの目的にのみ用意されています。実際にユーザーが存在しているネットワーク (operational network) は、レベル 2 以外で運用しないでください。NIS+ のセキュリティレベルの詳細については、『Solaris ネーミングの管理』を参照してください。

パスワード有効期限の基準、原則、および規則を確立する

パスワードの有効期限は、ユーザーに対し定期的にパスワードを変更させる仕組みです。パスワードの有効期限については、次の設定が可能です。

さまざまな最大日数や期間に到達していても、それまでにすでにログインしているユーザーは、上記の機能には影響されないことを覚えておいてください。これらのユーザーは、通常どおりに作業を継続できます。パスワード有効期限に関する制限と動作は、ユーザーがログインした場合、または次の操作のうちの 1 つを実行した場合のみ実行されます。

パスワード有効期限のパラメータは、ユーザー単位を基本として適用されます。また、ユーザーごとに異なるパスワード有効期限を設定できます。さらに、個別に有効期限を設定したユーザー以外のすべてのユーザーに適用される、一般的なデフォルトのパスワード有効期限パラメータを設定できます。

NIS+ の名前空間を計画する場合、実装したいパスワード有効期限の機能と指定したいデフォルト値を決定してください。パスワードの有効期限についての詳細は、『Solaris ネーミングの管理』のパスワードに関連する章を参照してください。

NIS+ グループの計画

NIS+ は、NIS にはない新しい種類のグループをネームサービス管理に導入します。NIS+ グループは、NIS+ アクセス権を一度にいくつかの NIS+ 主体に与える手段としてだけ使用します。またこれは、NIS+ の承認にだけ使用します。

NIS+ グループは、アクセス権が基準を置いている、4 つの承認クラスのうちの 1 つです。4 つの承認クラスは次のとおりです。

NIS+ スクリプトにより、アクセス権を与える目的で作成されたデフォルトのグループ名は、admin グループです。また、別の名前を付けて別のグループを作成することも、別のグループに別の NIS+ オブジェクトを割り当てることもできます。

あるオブジェクトグループのメンバーユーザーには、そのオブジェクトに特定の変更を行うアクセス権のような特権があります。たとえば、admin グループに何人かの見習い管理者を追加し、passwd テーブルと hosts テーブルだけを変更できるが、他のテーブルは変更できないようにすることができます。admin グループを使用すると、管理作業を、階層全体のスーパーユーザーだけに行わせるのではなく、多数のユーザーに分散させることができます。NIS+ admin グループには、NIS 互換モードでドメインを管理している場合でも、そのメンバーのために作成された資格がなければなりません。これは、認証を受けたユーザーだけが、NIS+ テーブルを変更するアクセス権を持つためです。

必要な資格の種類を確認したら、名前空間に必要なアクセス権を選択する必要があります。この作業を容易にするには、まずいくつの管理用のグループが必要かを決めます。複数のグループに異なる権利を割り当てたい場合は、独立したグループを使用すると便利です。通常、グループはドメイン別に作成します。各ドメインには、admin グループが 1 つだけなければなりません。

NIS+ グループとディレクトリへのアクセス権の計画

主体をグループに配置したあと、名前空間のオブジェクトによって、他のカテゴリの主体 (未認証、所有者、グループ、その他) だけでなく、これらのグループに許可されるアクセス権の種類を決めます。これらの割り当てを事前に決めておくと、一貫性のあるセキュリティの方針を確立するうえで役立ちます。

Table 3-1 に示すように、NIS+ では名前空間の各オブジェクトに対してデフォルトのアクセス権を提供します。

Table 3-1 NIS+ オブジェクトへのデフォルトのアクセス権

オブジェクト 

未認証 

所有者 

グループ 

その他 

ルートディレクトリオブジェクト 

r---

rmcd

rmcd

r---

ルート以外のディレクトリオブジェクト 

r---

rmcd

rmcd

r---

groups_dir ディレクトリオブジェクト 

r---

rmcd

rmcd

r---

org_dir ディレクトリオブジェクト 

r---

rmcd

rmcd

r---

NIS+ グループ 

----

rmcd

r---

r---

NIS+ テーブル 

varies

varies

varies

varies

デフォルトのアクセス権を使用するか、または独自のアクセス権を割り当てることができます。独自のアクセス権を割り当てるときは、名前空間内のオブジェクトがどのようにアクセスされるかをよく考える必要があります。未認証クラスは、NIS+ クライアントからのすべての要求から構成されており、その要求は認証されていてもいなくても構わない、ということに注意してください。その他のクラスは、NIS+ クライアントからの認証を受けているすべての要求から構成されます。したがって、認証されていない要求に対し、名前空間へのアクセス権を与えたくなければ、未認証クラスへのアクセス権を割り当てず、その他のクラスだけを割り当てます。一方で、いくつかのクライアントが、たとえばアプリケーションを通して、認証されていない読み取り要求を出すことが予測されるときは、未認証クラスに読み取り権を割り当てる必要があります。NIS クライアントを NIS 互換モードでサポートしたい場合は、未認証クラスに読み取り権を割り当てなければなりません。

また、各種の名前空間オブジェクトが、最初に指定した NIS+ グループに割り当てる権利についても検討してください。名前空間の管理方法によって、利用できるアクセス権の一部またはすべてを、このグループに割り当てることができます。マスタサーバー上のユーザー root を、admin グループの所有者にすることをお勧めします。admin グループには、ルートドメインのオブジェクトに対する作成権と削除権が必要です。1 人の管理者にだけ、ルートドメインを作成、変更させたい場合は、その管理者だけを admin グループに所属するようにしてください。グループには、いつでもメンバーを追加することができます。設定を行う管理者が何人かいる場合は、その管理者をすべてグループに追加して、そのグループにすべての権利を割り当ててください。その方が、所有者を切り替えたり元に戻したりするよりも簡単です。

オブジェクトの所有者にはすべての権利が与えられていなければなりません。ただし、グループにすべての権利が与えられていれば、このことはさほど重要ではありません。すべての権利を所有者にだけ与えると、名前空間のセキュリティ保護はより安全なものになります。しかし、管理グループにすべての権利を与えた方が管理は容易です。

NIS+ テーブルのアクセス権の計画

NIS+ テーブル以外の NIS+ オブジェクトは主に構造として存在するものですが、NIS+ テーブルは、種類の異なるオブジェクトであり、情報を伝えるものです。NIS+ テーブルへのアクセスは、すべての NIS+ 主体と、これらの主体に代わって実行されるアプリケーションで必要とされます。このため、NIS+ へのアクセス要件は若干異なります。

表 3-2 は、NIS+ テーブルに割り当てられるデフォルトのアクセス権を示しています。列が、テーブルの権利以外の権利を持つ場合は、それらの権利も示しています。テーブルとエントリのレベルの権利は、nischmod コマンドによって変更することができます。また、列レベルの権利は、nistbladm -u コマンドによって変更することができます。「暗号化されているパスワードフィールドの保護」 には、テーブル権利を変更して異なる要求に応える方法の一例を示してあります。

表 3-2 NIS+ テーブルと列のデフォルトのアクセス権

テーブル / 列 

未認証 

所有者 

グループ 

その他 

hosts テーブル 

r---

rmcd

rmcd

r---

bootparams テーブル 

r---

rmcd

rmcd

r---

passwd テーブル 

----

rmcd

rmcd

r---

 

ユーザー名 (name) 列 

r---

----

----

----

 

パスワード (passwd) 列 

----

-m--

----

----

 

ユーザー ID (uid) 列 

r---

----

----

----

 

グループ ID (gid) 列 

r---

----

----

----

 

GCOS (gcos) 列 

r---

-m--

----

----

 

ホームディレクトリ (home) 列 

r---

----

----

----

 

ログインシェル (shell) 列 

r---

----

----

----

 

シャドー (shadow) 列 

----

----

----

----

group テーブル 

----

rmcd

rmcd

r---

 

名前 (name) 列 

r---

----

----

----

 

パスワード (passwd) 列 

----

-m--

----

----

 

グループ ID (gid) 列 

r---

----

----

----

 

メンバ (members) 列 

r---

-m--

----

----

cred テーブル 

r---

rmcd

rmcd

r---

 

cname 列 

----

----

----

----

 

auth_type 列 

----

----

----

----

 

auth_name 列 

----

----

----

----

 

public_data 列 

----

-m--

----

----

 

private_data 列 

----

-m--

----

----

networks テーブル 

r---

rmcd

rmcd

r---

netmasks テーブル 

r---

rmcd

rmcd

r---

ethers テーブル 

r---

rmcd

rmcd

r---

services テーブル 

r---

rmcd

rmcd

r---

protocols テーブル 

r---

rmcd

rmcd

r---

rpc テーブル 

r---

rmcd

rmcd

r---

auto_home テーブル 

r---

rmcd

rmcd

r---

auto_master テーブル 

 

rmcd

rmcd

r---

注 -

NIS 互換ドメインは、テーブルオブジェクトレベルの passwd テーブルに、未認証クラスの読み取り権を与えます。

暗号化されているパスワードフィールドの保護

表 3-2 を見るとわかるように、passwd テーブルを除くすべてのテーブルで、未認証クラスに読み取り権が与えられています。NIS+ テーブルは、未認証クラスの読み取りアクセス権を与えます。これは、NIS+ テーブルにアクセスする必要がある多くのアプリケーションが、認証されていないクライアントとして実行されるためです。ただし、passwd テーブルに対して同じことを行うと、暗号化されているパスワードの列が、認証されていないクライアントに公開されてしまいます。

表 3-2 に示す構成は、NIS 互換ドメインに対するデフォルトのアクセス権です。NIS 互換ドメインは、passwd 列に、未認証クラスの読み取りアクセス権を与えなければなりません。これは、NIS クライアントが認証されておらず、未認証クラスの読み取りアクセス権を与えないと、その passwd 列にアクセスできないためです。したがって、NIS 互換ドメインでは、パスワードが暗号化されていても、復号化されやすい状態にあります。パスワードを、所有者以外には読めないようにしておくと、より安全になります。

標準の NIS+ ドメイン (NIS 互換ではない) には、さらに別のレベルのセキュリティがあります。 nissetup によって提供されるデフォルトの構成では、列ごとに制御する方法で、passwd 列を未認証ユーザーから保護しますが、passwd テーブルの残りの部分に対するアクセス権は与えられます。テーブルレベルでは、未認証の主体に読み取りアクセス権はありません。列レベルでは、passwd 列を除くすべての列への読み取りアクセス権があります。

エントリ所有者が、パスワード列に対するアクセス権を取得する方法について説明します。エントリ所有者は、各自のエントリに対する読み取り権と変更権の両方を持ちます。エントリ所有者は、その他のクラスのメンバーになることによって、読み取り権を取得します (テーブルレベルでは、その他のクラスに読み取り権があることに注意してください)。また、エントリ所有者は、列レベルでの明示的な割り当てによって、変更権を取得します。

テーブルの所有者とエントリの所有者は、同じ NIS+ 主体であることはほとんどなく、また同じである必要もないことに注意してください。したがって、所有者にテーブルレベルの読み取り権があっても、特定のエントリの所有者に読み取り権があるということではありません。

前に述べたように、これは、Solaris 2.3 以降のデフォルト設定です。テーブル、エントリ、列それぞれのレベルでのセキュリティの詳細については、『Solaris ネーミングの管理』を参照してください。