9.6. パスワードポリシーの設計

パスワードポリシーとは、特定のシステムでパスワードがどのように使用されるかを管理する一連のルールのことです。Directory Server のパスワードポリシーは、期間、長さ、ユーザーがパスワードを再利用できるかどうかなど、パスワードが有効であると見なされるために満たす必要のある基準を指定します。
以下のセクションでは、健全なパスワードポリシーを設計するための詳細情報を提供します。

9.6.1. パスワードポリシーの仕組み

Directory Server は、きめ細かいパスワードポリシーをサポートします。つまり、パスワードポリシーをサブツリーおよびユーザーレベルで定義することができます。これにより、ディレクトリーツリー内の任意の時点でパスワードポリシーを定義する柔軟性が可能になります。
  • ディレクトリー全体。
    このようなポリシーは グローバル パスワードポリシーと呼ばれます。ポリシーは設定および有効化されると、ディレクトリー内のすべてのユーザーに適用されます。ただし、Directory Manager エントリーと、ローカルのパスワードポリシーが有効になっているユーザーエントリーは適用から除外されます。
    これにより、すべてのディレクトリーユーザーに共通の単一のパスワードポリシーを定義することができます。
  • ディレクトリーの特定のサブツリー。
    このようなポリシーは サブツリーレベル または ローカル パスワードポリシーと呼ばれます。設定および有効化されると、ポリシーは指定されたサブツリー配下のすべてのユーザーに適用されます。
    これは、すべてのホストされた会社に単一のポリシーを適用するのではなく、ホストされた会社ごとに異なるパスワードポリシーをサポートするホスティング環境に適しています。
  • ディレクトリーの特定のユーザー。
    このようなポリシーは ユーザーレベル または ローカル パスワードポリシーと呼ばれます。設定および有効化されると、ポリシーは指定されたユーザーのみに適用されます。
    これにより、ディレクトリーユーザーごとに異なるパスワードポリシーを定義できます。たとえば、一部のユーザーがパスワードを毎日変更し、一部のユーザーが毎月パスワードを変更し、他のすべてのユーザーが 6 か月ごとにパスワードを変更するように指定します。
デフォルトでは、Directory Server にはグローバルパスワードポリシーに関連するエントリーおよび属性が含まれます。つまり、同じポリシーがすべてのユーザーに適用されます。サブツリーまたはユーザーにパスワードポリシーを設定するには、サブツリーまたはユーザーレベルでエントリーを追加し、cn=config エントリーの nsslapd-pwpolicy-local 属性を有効にします。この属性はスイッチとして機能し、粒度の細かいパスワードポリシーをオンおよびオフに切り替えます。
コマンドラインまたは Web コンソールを使用してパスワードポリシーを変更できます。dsconf pwpolicy コマンドを使用してグローバルポリシーを変更し、dsconf localpwp コマンドを使用してローカルポリシーを変更します。パスワードポリシーの設定に関する詳細は、『管理ガイド を参照してください』。
注記
以前にローカルパスワードポリシーを管理していた ns-newpwpolicy.pl スクリプトが非推奨になりました。ただし、このスクリプトは 389-ds-base-legacy-tools パッケージで使用できます。
パスワードポリシーエントリーがディレクトリーに追加されると、Directory Server が強制するパスワードポリシーのタイプ (グローバルまたはローカル) が決定されます。
ユーザーがディレクトリーにバインドしようとすると、Directory Server は、ローカルポリシーが定義され、ユーザーのエントリーに対して有効になっているかどうかを判断します。
  • 詳細なパスワードポリシーが有効になっているかどうかを判断するために、サーバーは cn=config エントリーの nsslapd-pwpolicy-local 属性に割り当てられた値(on または off)をチェックします。値が off の場合、サーバーはサブツリーおよびユーザーレベルで定義されたポリシーを無視し、グローバルパスワードポリシーを適用します。
  • ローカルポリシーがサブツリーまたはユーザーに定義されているかどうかを判断するために、サーバーは対応するユーザーエントリーの pwdPolicysubentry 属性をチェックします。属性が存在する場合は、サーバーは、ユーザーに設定されたローカルパスワードポリシーを適用します。属性が存在しない場合、サーバーはエラーメッセージをログに記録し、グローバルパスワードポリシーを強制します。
その後、サーバーはユーザーが指定したパスワードを、ユーザーのディレクトリーエントリーで指定された値と比較して、それらが一致することを確認します。サーバーは、パスワードポリシーで定義されたルールも使用して、ユーザーがディレクトリーにバインドできるようになる前にパスワードが有効であることを確認します。

図9.3 パスワードポリシーの確認プロセス

パスワードポリシーの確認プロセス
バインド要求の他に、userPassword 属性(以下のセクションを参照)が要求に存在する場合、パスワードポリシーチェックは追加および変更操作中にも行われます。
userPassword の値を変更すると、以下の 2 つのパスワードポリシー設定が確認されます。
  • パスワードの最低期間ポリシーがアクティブになります。最低期間要件が満たされないと、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。
  • パスワード履歴ポリシーがアクティブになります。userPassword の新しい値がパスワード履歴にある場合、または現在のパスワードと同じ場合は、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。
userPassword の値を追加および変更すると、パスワードポリシーでパスワード構文がチェックされます。
  • パスワードの最小長ポリシーがアクティブになります。userPassword の新しい値が必要な最小長未満の場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。
  • パスワード構文の確認ポリシーがアクティブになります。userPassword の新しい値がエントリーの別の属性と同じ場合、サーバーは constraintViolation エラーを返します。パスワード更新操作は失敗します。

9.6.2. パスワードポリシーの属性

以下のセクションでは、サーバーのパスワードポリシーを作成する属性を説明します。
これらの属性の設定方法は『Red Hat Directory Server Administration Guide』を参照してください。

9.6.2.1. 失敗の最大回数

これは、パスワードベースのアカウントのロックアウトを有効にするパスワードポリシーの設定です。ユーザーが一定の回数ログインを試みて失敗すると、そのアカウントは管理者がアンロックするか、オプションで特定の時間が経過するまでロックされます。これは passwordMaxFailure パラメーターで設定されます。
試行失敗の最大数に達したときを評価する場合、ログイン試行をカウントする方法は 2 つあります。数に達したときにアカウントをロックする (n) か、カウントを超えたときにのみアカウントをロックする (n + 1) ハード制限を適用できます。たとえば、失敗の制限が試行 3 回である場合、アカウントは 3 回目の失敗 (n) または 4 回目の失敗 (n + 1) でロックできます。n+1 の動作は LDAP サーバーの過去の動作であるため、レガシー動作とみなされます。新しい LDAP クライアントでは、より厳密なハード制限が想定されます。デフォルトでは、Directory Server は厳密な制限(n)を使用しますが、passwordLegacyPolicy パラメーターでレガシー動作を有効にできます。

9.6.2.2. リセット後のパスワード変更

Directory Server パスワードポリシーでは、初回のログイン後、または管理者がパスワードをリセットした後にユーザーがパスワードを変更する必要があるかどうかを指定できます。
管理者が設定するデフォルトのパスワードは、通常、ユーザーのイニシャル、ユーザー ID、会社名などの会社の規則に従います。この規則が検出された場合、通常、侵入者がシステムの侵入に使用するのは最初の値です。したがって、管理者がパスワードをリセットした後に、ユーザーはパスワードを変更することが推奨されます。パスワードポリシーにこのオプションが設定されている場合、ユーザー定義のパスワードが無効であっても、パスワードを変更する必要があります。
ユーザーが自分のパスワードを変更する必要がないまたは許可されていない場合、管理者が割り当てたパスワードは、明白な規則に従わないようにし、発見を困難にします。
デフォルト設定では、リセット後にユーザーがパスワードを変更する必要はありません。
詳細は、「ユーザー定義のパスワード」 を参照してください。

9.6.2.3. ユーザー定義のパスワード

パスワードポリシーは、ユーザーが自分のパスワードを変更できるようにするかどうかを設定できます。強固なパスワードポリシーには、適切なパスワードが必要です。適切なパスワードには普通の言葉が含まれません。辞書にある単語、ペットや子供の名前、誕生日、ユーザー ID、または簡単に見つけられる (またはディレクトリー自体に保存されている) ユーザーに関するその他の情報は、パスワードとしては適切ではありません。
適切なパスワードには、文字、数字、および特殊文字の組み合わせが含まれる必要があります。ただし、便宜上、ユーザーは覚えやすいパスワードを使用することがよくあります。そのため、企業によっては、強固なパスワード基準を満たすユーザーにパスワードを設定し、ユーザーがパスワードを変更できないようにすることがあります。
管理者にユーザーのパスワードを設定させることには、2 つの欠点があります。
  • 管理者の時間がかなり必要です。
  • 管理者が指定したパスワードは通常、覚えるのが難しいため、ユーザーはパスワードを書き留める可能性が高く、発見されるリスクが高くなります。
デフォルトでは、ユーザー定義のパスワードが許可されます。

9.6.2.4. パスワードの有効期限

パスワードポリシーを使用すると、同じパスワードを無期限に使用することを許可したり、一定期間後にパスワードの有効期限が切れるように設定することが可能です。一般的に、パスワードの使用期間が長いほど、パスワードが検出される可能性が高くなります。ただし、パスワードの期限切れが頻繁に発生すると、ユーザーはパスワードを覚えるのに苦労し、パスワードを書き留めてしまう可能性があります。一般的なポリシーでは、パスワードは 30 - 90 日ごとに失効します。
サーバーは、パスワードの有効期限が無効であっても、パスワード失効の仕様を記憶します。パスワードの有効期限が再度有効になると、パスワードは最後に無効になった前に設定された期間のみ有効になります。
たとえば、パスワードポリシーが 90 日ごとに期限切れになるように設定されてから、パスワードの有効期限が無効になり、再度有効にすると、デフォルトのパスワード有効期限は 90 日になります。
デフォルトでは、ユーザーパスワードは期限切れになりません。

9.6.2.5. 有効期限の警告

パスワードの有効期限が設定されている場合、パスワードの期限が切れる前に警告をユーザーに送信することが推奨されます。
ユーザーがサーバーにバインドすると、Directory Server が警告を表示します。パスワードの失効が有効になっている場合、ユーザーのクライアントアプリケーションがこの機能をサポートしていれば、デフォルトでは、ユーザーのパスワードの有効期限が切れる 1 日前に警告が (LDAP メッセージを使用して) ユーザーに送信されます。
パスワード失効の警告が送信される有効な範囲は、1 - 24,855 日です。
注記
パスワードは、有効期限の警告が送信されるまで期限切れになることはありません

9.6.2.6. 猶予ログイン制限

期限切れパスワードの 猶予期間 とは、パスワードが期限切れであっても、ユーザーがシステムにログインできることを意味します。一部のユーザーが期限切れのパスワードを使用してログインできるようにするには、パスワードの有効期限が切れた後にユーザーに許可される猶予ログインの試行回数を指定します。
デフォルトでは、猶予ログインは許可されていません。

9.6.2.7. パスワードの構文チェック

パスワード構文チェックは、パスワード文字列のルールを強制するため、パスワードは特定の基準満たす必要があります。すべてのパスワード構文チェックは、サブツリーごとまたはユーザーごとにグローバルに適用できます。パスワードの構文チェックは passwordCheckSyntax 属性で設定されます。
デフォルトのパスワード構文には、最低 8 文字が必要で、パスワードに普通の言葉を使用できません。単純な単語は、ユーザーのエントリーの uidcnsngivenNameou、または mail属性に保存されている値です。
さらに、他の形式のパスワード構文を強制でき、パスワード構文にさまざまなオプションのカテゴリーを提供します。
  • パスワードに必要な最小文字数(passwordMinLength)
  • 桁の最小数。ゼロから 9 の間の数字を意味します(passwordMinDigits)
  • ASCII アルファベットの最小数(大文字と小文字の両方)(passwordMinAlphas)
  • 大文字の ASCII アルファベットの最小数(passwordMinUppers)
  • 小文字の ASCII アルファベットの最小数(passwordMinLowers)
  • !@#$ などの特殊 ASCII 文字の最小数(passwordMinSpecials)
  • 8 ビット文字の最小数(passwordMin8bit)
  • aaabbb (passwordMaxRepeats)など、同じ文字をすぐに繰り返すことができる最大回数()
  • パスワードごとに必要な文字カテゴリーの最小数。カテゴリーは大文字、小文字、特殊文字、数字、または 8 ビット文字(passwordMinCategories)
  • Directory Server は CrackLib ディクショナリーに対してパスワードをチェックします(passwordDictCheck)。
  • Directory Server はパスワードに回文が含まれているかどうかを確認します(passwordPalindrome)
  • Directory Server は、同じカテゴリーの文字を連続して持つパスワードを設定できなくなります(passwordMaxClassChars)
  • Directory Server が特定の文字列を含むパスワードが設定されないようにする(passwordBadWords)
  • Directory Server は管理者定義属性に設定された文字列を含むパスワードが設定されないようにする(passwordUserAttributes)
必要な構文のカテゴリーが多いほど、パスワードは強力になります。
デフォルトでは、パスワード構文のチェックは無効になっています。

9.6.2.8. パスワードの長さ

パスワードポリシーでは、ユーザーパスワードの最小の長さを要求できます。一般的に、パスワードが短いほど解読されやすくなります。パスワードの適切な長さは 8 文字です。これは、解読が難しく、ユーザーがパスワードを書き留めなくても覚えられる長さです。この属性に有効な値の範囲は、2 - 512 文字です。
デフォルトでは、パスワードの最小長は設定されません。

9.6.2.9. パスワードの最小期間

パスワードポリシーにより、ユーザーが指定された期間はパスワードを変更できないようにすることができます。passwordHistory 属性とともに使用すると、古いパスワードの再使用は推奨されません。
たとえば、パスワードの最小期間(passwordMinAge)属性が 2 日である場合、ユーザーは 1 つのセッション中にパスワードを繰り返し変更できません。これにより、パスワード履歴を循環して、古いパスワードを再利用できるようになります。
この属性に有効な値の範囲は、0 - 24,855 日です。0 の値は、ユーザーがすぐにパスワードを変更できることを示しています。

9.6.2.10. パスワード履歴

Directory Server は、パスワード履歴に 2 - 24 個のパスワードを保存できます。パスワードが履歴にある場合、ユーザーは自分のパスワードをその古いパスワードに再設定することはできません。これにより、ユーザーは覚えやすいいくつかのパスワードを再利用できなくなります。または、パスワード履歴を無効にして、ユーザーがパスワードを再利用できるようにすることもできます。
パスワード履歴がオフの場合でもパスワードは履歴に残るため、パスワード履歴をオンに戻しても、パスワード履歴をオフにする前に履歴にあったパスワードは再利用できません。
サーバーはデフォルトではパスワード履歴を維持しません。

9.6.2.11. パスワードストレージスキーム

パスワードストレージスキームは、ディレクトリー内に Directory Server パスワードを保存するために使用される暗号化の種類を指定します。Directory Server は、さまざまなパスワードストレージスキームをサポートします。
  • Salted Secure Hash Algorithm (SSHA、SSHA-256、SSHA-384、および SSHA-512)。これは最も安全なパスワードストレージスキームで、これがデフォルトになります。 推奨される SSHA スキームは SSHA-256 以上です。
  • CLEAR、暗号化がないことを意味します。これは SASL Digest-MD5 と併用できる唯一のオプションであるため、SASL を使用するには CLEAR パスワードストレージスキームが必要です。
    ディレクトリーに保存されているパスワードは、アクセス制御情報 (ACI) 命令を使用して保護できますが、プレーンテキストのパスワードをディレクトリーに保存することは適切とはいえません。
  • Secure Hash Algorithm (SHA、SHA-256、SHA-384、および SHA-512).これは SSHA よりも安全性が低いです。
  • UNIX CRYPT アルゴリズム。このアルゴリズムは、UNIX パスワードとの互換性を提供します。
  • MD5。このストレージスキームは SSHA よりも安全性が低くなりますが、MD5 を必要とするレガシーアプリケーション用に含まれています。
  • Salted MD5。このストレージスキームは、プレーンな MD5 ハッシュよりも安全ですが、SSHA よりも安全性が低くなります。このストレージスキームは、新しいパスワードと併用するために含まれていませんが、salted MD5 に対応するディレクトリーからのユーザーアカウントを移行するのに役立ちます。

9.6.2.12. パスワードの最終変更時刻

passwordTrackUpdateTime 属性は、エントリーのパスワードが最後に更新されたときのタイムスタンプを記録するようにサーバーに指示します。パスワードの変更時間はユーザーエントリーで pwdUpdateTime 操作属性 (modifyTimestamp または lastModified 操作属性とは別) として保存されます。
デフォルトでは、パスワードの変更時刻は記録されません

9.6.3. レプリケートされた環境でのパスワードポリシーの設計

パスワードとアカウントのロックアウトポリシーは、以下のようにレプリケートされた環境で次のように適用されます。
  • パスワードポリシーはデータサプライヤーで実施されます。
  • アカウントのロックアウトは、レプリケーション設定のすべてのサーバーに適用されます。
ディレクトリーのパスワードポリシー情報。パスワードの期間、アカウントのロックアウトカウンター、および期限切れ警告カウンターなどがすべてレプリケートされます。ただし、設定情報はローカルに保存され、複製されません。この情報には、パスワード構文とパスワード変更の履歴が含まれます。
レプリケートされた環境でパスワードポリシーを設定する場合は、以下の点を考慮してください。
  • すべてのレプリカは、パスワードの期限切れが近いことを警告します。この情報は各サーバーでローカルに保存されるため、ユーザーが複数のレプリカに順番にバインドすると、ユーザーは同じ警告を複数回受け取ります。さらに、ユーザーがパスワードを変更すると、この情報がレプリカにフィルターされるまで時間がかかる場合があります。ユーザーがパスワードを変更してからすぐに再バインドすると、レプリカが変更を登録するまでバインドに失敗する可能性があります。
  • サプライヤーやレプリカなど、すべてのサーバーで同じバインド動作が発生する必要があります。各サーバーに常に同じパスワードポリシー設定情報を作成します。
  • アカウントロックアウトカウンターは、マルチサプライヤー環境で想定どおりに機能しない場合があります。