ユーザー名とパスワードを使用してサービスにアクセスできるのに、なぜKerberosが必要なのですか？
企業ネットワーク内のさまざまなサーバー上のサービスにアクセスするユーザーの認証にKerberosが使用されることを読んだことがありますが、それでもKerberosの目的がわかりません。システム管理者が各サーバーの各ユーザーに対してユーザーアカウントを作成するだけで、ユーザーがユーザー名とパスワードを使用して、アクセスしたいリソースにアクセスできないのはなぜですか？なぜそのような手の込んだ認証プロトコルが必要なのですか？
システム管理者が各サーバーの各ユーザーに対してユーザーアカウントを作成するだけで、ユーザーが自分のユーザー名とパスワードを使用して、アクセスしたいリソースにアクセスできないのはなぜですか？
ユーザーが50人、サーバーが50台あるとします。簡単にするために、50人のユーザー全員が50台すべてのサーバーにアクセスできると想定し、すべてのサーバーで同じ特権を持っているとします。これらの特権を変更する必要はありません。これは、作成する必要がある合計2,500のパスワードエントリです。
新しいユーザーの追加
新しいユーザーを追加する場合、管理者は50台すべてのサーバーに移動し、その1人のユーザーをすべてのサーバーに追加する必要があります。これには、50台すべてのサーバーでcreate userコマンドを実行する管理者が必要です。そのビットは自動化できますが、安全に自動化できないことができない部分は、ユーザーがサーバーごとに1回、50回パスワードを入力する必要があることです。
なぜこの後者の問題ですか？ パスワード認証システムは、パスワードのコピーを保持しないように設計されているため 、暗号化されたコピーでさえありません。したがって、ユーザーがサーバー＃1で新しいパスワードを入力すると、そのサーバーはすぐにパスワードを忘れてしまうので、サーバー＃2や＃3などでもう一度入力する必要があります。
新しいサーバーの追加
たぶん今では、次のようなスクリプトを記述できると考えています。
- サーバーXで実行されます。
- 新しいユーザーに新しいパスワードの入力を求めます。
- 管理者にパスワードを要求します。
- サーバー＃1から＃50にログインし、それぞれに同じパスワードでユーザーアカウントを作成します。
それは少し危険ですが、それを行っても、さらに大きな問題が残ります。あなたの会社が新しいサーバーを購入したとしましょう。このサーバーにアクセスするには、50人のユーザーが必要です。まあ、どのサーバーにもユーザーのパスワードのコピーが含まれていないため、管理者は各ユーザーのところに行き、新しいサーバーのアカウントのパスワードを入力してもらう必要があります。そして、これを回避する方法はありません ユーザーのパスワードのコピーを保持していない限り。これも安全な方法ではありません 。
集中パスワードデータベース
これらの問題を解決するには、ユーザー/パスワードデータベースを1か所に集中化し、すべてのサーバーがそのデータベースを参照してユーザー名とパスワードを認証する必要があります。これは、管理可能なマルチユーザー/マルチサーバー環境に最低限必要なものです。今：
- 新しいユーザーを追加すると、すべてのサーバーが中央データベースから自動的にピックアップします。
- 新しいサーバーを追加すると、中央データベースからすべてのユーザーが自動的に取得されます。
これを行うためのさまざまなメカニズムがありますが、Kerberosが提供するメカニズムにはまだ足りません。
Kerberos
このような一元化されたデータベースを取得したら、管理のしやすさと利便性の両方のために、より多くの機能でデータベースを強化することは理にかなっています。 Kerberosは、ユーザーが1つのサービスに正常にログインすると、そのサービスが事実を「記憶」し、このユーザーが正常にログインした他のサービスを「証明」できる機能を追加します。そのため、そのような証明が提示された他のサービスは、ユーザーにパスワードを要求せずに入ることができます。
これにより、利便性と安全性が両立します。
- ユーザーは、その日に1回パスワードを正しく入力しても、何度もパスワードを要求されることはありません。
- 複数のサーバーにアクセスするプログラムを作成するプログラマーがいて、それらのサーバーが認証を必要とする場合、プログラムは、それらを実行するサーバーアカウントの資格情報を再利用することにより、パスワードを提示する必要なしにそれらのサーバーに対して認証できます。
後者は、安全ではないがあまりにも一般的な習慣であるユーザー名とパスワードのコピーを構成ファイルに入れることを要求する自動プログラムを最小限に抑えるか、または殺すため、重要です。繰り返しになりますが、安全なパスワード管理の重要なアイデアは、暗号化されたコピーでさえも、パスワードのコピーを保存しないことです。
簡単に言えば、それは管理上の悪夢です。
Kerberosを使用すると、管理者は任意の数の従業員に同じ資格情報を使用してドメイン全体のリソースにログインさせることができます。
これは単純なネットワークには存在しなかったとしましょう。
- ユーザーはパスワードを入力してコンピューターのロックを解除します。
- ユーザーがネットワークドライブをマップしたい。パスワードを再入力する必要があります
- その後、ユーザーはメールの受信を希望します。 Outlookを開いてから、さらに別のパスワードを入力する必要があります。
- 次に、ユーザーは会社のイントラネットにログオンする必要があります。それは別のパスワードです。
あなたはアイデアを得ます。 Kerberosを使用しないことは、ユーザーがホストサービスがアクセスする必要があるすべてのサーバーへのパスワードを維持する必要があることを意味します。これは、ユーザーと管理者のどちらにとっても頭痛の種です。ほとんどの企業ポリシーでは、ユーザーはX日ごとにパスワードを変更する必要があると述べています。エンドユーザーであり、必要なときに毎回5台のサーバーでパスワードを変更する必要があると想像できますか？
セキュリティの観点から、管理者は5つの異なるサーバーにログオンするのではなく、すべてのログイン試行（成功と失敗の両方）を1つの場所で取得します。これは、ログインの問題（ロックアウトなど）のトラブルシューティングに役立ち、ログの監査をはるかに簡単にします。
Kerberosは便利なものではなく、強化されたセキュリティ対策です。利便性は二次的なメリットです。
すばらしい説明は 認証システムの設計：4つのシーンでのダイアログ
基本的に、マジックトークン（つまり、パスワード）を渡すだけでなく、信頼できる情報源（Kerberos KDC、Microsoft ADなど）によって署名された「チケット」を取得します。チケットは、サービスが誰で、どのエンタイトルメントグループに属しているかをサービスに伝えます。それは、遊園地への入場券を購入するのではなく、公園での各乗車に付き添うお金を与えるようなものだと考えてください。
横方向のエスカレーションを防ぐため。
LDAPなどの一元化されたパスワードデータベースを使用することで、パスワード管理の管理の複雑さを軽減できます。ただし、これを行うと、横方向に拡大するリスクが生じます。攻撃者が1つのサーバーを制御する場合、それらはサイレントに存在し続け、パスワードを盗聴することができます。これらのパスワードは、他のサーバーを危険にさらすために使用できます-横方向のエスカレーション。
Kerberosはこれを解決しようとします。ユーザーは各サーバーにパスワードを送信しません。認証サーバーに送信するだけで、他のサーバーにチケットを提示します。最近では、mimikatzなどのツールによって悪用される いくつかの欠陥 が特定されています。ただし、少なくともKerberosは横方向の拡大を防ぐように設計されています。 LDAPはそれを止めることは何もしません。
Kerberosの主な利点は、アカウントの変更とパスワードの変更をすぐに同期できるようにすることです。
分散アカウントを集中管理するためのソリューションが手元にあり、ログイン後にパスワードプロンプトの99％に応答するクライアント側のパスワードエージェントはすべてユーザーがパスワードを変更することはまれであり、毎晩のバッチジョブまで待機できると想定しています。パスワードの変更を実際に有効にするため。ほとんどの場合、権限の変更についても同様です。今すぐ有効にするために権限の変更が必要な場合、下位のツールはそれを行うことができません。
Kerberosの機能には、暗号化せずに接続を安全に認証する機能がリストされています。これは実際には望ましくないことを証明し、その能力に依存すべきではありません。 Kerberosチケットを盗むことは、SMBへの攻撃の本質でした。これは、ユーザーがネットワーク共有をどこでも使用している場合に、ユーザーとしてすべてのアクセスを提供します。