1.3.2.2. 証明書ベースの認証

証明書ベースの認証の利点の 1 つは、認証の最初の 3 ステップを、ネットワークを越えて送信されない 1 つのパスワードを供給する仕組みに置き換えることができ、管理者がユーザーの認証を一元的に制御できることです。これは シングルサインオン と呼ばれます。
図1.5「証明書を使用したクライアントのサーバーへの認証」 は、証明書と SSL/TLS を使用してクライアント認証がどのように機能するかを示しています。ユーザーをサーバーに認証するには、クライアントが無作為に生成されたデータの一部に署名し、ネットワーク全体で証明書と署名済みデータの両方を送信します。サーバーは、証明書および署名されたデータのデータに基づいてユーザーのアイデンティティーを認証します。
図1.4「パスワードを使用したクライアントのサーバーへの認証」図1.5「証明書を使用したクライアントのサーバーへの認証」 と同様に、ユーザーがすでにサーバーを信頼し、リソースをリクエストしたこと、および要求されたリソースへのアクセスを付与する前にクライアント認証が要求されていることを前提としています。

図1.5 証明書を使用したクライアントのサーバーへの認証

証明書を使用したクライアントのサーバーへの認証
図1.4「パスワードを使用したクライアントのサーバーへの認証」 の認証プロセスとは異なり、図1.5「証明書を使用したクライアントのサーバーへの認証」 の認証プロセスには SSL/TLS が必要です。また、図1.5「証明書を使用したクライアントのサーバーへの認証」 は、クライアントがサーバーに対してクライアントを識別するのに使用できる有効な証明書を持っていることを前提としています。証明書ベースの認証は、秘密鍵を所有し、パスワードを知っているユーザーの両方に基づいているため、パスワードベースの認証よりも優先されます。ただし、これら 2 つの仮定は、権限のない担当者がユーザーのマシンまたはパスワードにアクセスできず、クライアントソフトウェアの秘密鍵データベースのパスワードが設定されており、ソフトウェアが適度な頻度でパスワードを要求するように設定されている場合にのみ当てはまります。
注記
パスワードベースの認証または証明書ベースの認証は、個々のマシンまたはパスワードへの物理的なアクセスに関連するセキュリティーの問題に対応します。公開鍵暗号は、一部のデータの署名に使用される秘密鍵が証明書の公開鍵に対応していることを確認することしかできません。マシンの物理的なセキュリティーを保護し、秘密鍵のパスワードを秘密にしておくことは、ユーザーの責任です。
図1.5「証明書を使用したクライアントのサーバーへの認証」 に記載されている認証手順は以下のとおりです。
  1. クライアントソフトウェアは、そのクライアントに対して発行された証明書に発行される公開鍵に対応する秘密鍵のデータベースを維持します。クライアントは、証明書ベースのクライアント認証を必要とする SSL/TLS 対応サーバーに初めてアクセスしようとしたときなど、特定のセッション中にクライアントが初めてデータベースにアクセスする必要があるときに、このデータベースのパスワードを要求します。
    このパスワードを一度入力すると、他の SSL/TLS 対応サーバーにアクセスする場合でも、残りのセッションに対して再度入力する必要はありません。
  2. クライアントは秘密鍵データベースのロックを解除し、ユーザーの証明書の秘密鍵を取得し、その秘密鍵を使用してクライアントとサーバーの両方からランダムなデータに署名します。このデータとデジタル署名は、秘密鍵の有効性について証明されています。デジタル署名はその秘密鍵でのみ作成でき、SSL/TLS セッションに固有の署名済みデータに対して、対応する公開鍵で検証できます。
  3. クライアントは、ユーザーの証明書とランダムに生成されたデータの両方をネットワーク経由で送信します。
  4. サーバーは、証明書と署名済みデータを使用してユーザーのアイデンティティーを認証します。
  5. サーバーは、クライアントが提示する証明書が LDAP ディレクトリー内のユーザーのエントリーに保存されていることを確認するなど、他の認証タスクを実行できます。その後、サーバーは、指定のユーザーが要求されたリソースにアクセスできるかどうかを確認します。この評価プロセスでは、LDAP ディレクトリーまたは企業のデータベースで追加情報を使用すると、さまざまな標準的な承認メカニズムを使用できます。評価の結果が正である場合、サーバーは、要求されたリソースにクライアントがアクセスすることを許可します。
証明書は、クライアントとサーバーと間の相互作用の認証部分を置き換えます。ユーザーがネットワーク全体でパスワードを送信しなければならない代わりに、シングルサインオンでは、ネットワーク経由で送信せずに、ユーザーが秘密鍵のデータベースパスワードを一度入力する必要があります。セッションの残りの部分では、クライアントはユーザーの証明書を提示して、遭遇したそれぞれの新しいサーバーでユーザーを認証します。認証されたユーザー ID に基づく既存の承認メカニズムには影響はありません。