test

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

Kerberos サービスの動作

この節では Kerberos 認証システムの概要について説明します。詳細については、「Kerberos 認証システムの動作方法」を参照してください。

Kerberos セッションが起動されたあとは、ユーザーから見ると Kerberos サービスが意識されることはほとんどありません。rsh や ftp などのコマンドは、ほぼ変わりなく動作します。Kerberos セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。

Kerberos システムは、「チケット」の概念を中心に動作します。チケットは、ユーザー、および NFS サービスなどのサービスを特定する一連の電子情報です。運転免許証が運転する人と免許の種類を表すのと同じように、チケットもユーザーとユーザーのネットワークアクセス権を表します。Kerberos に基づくトランザクションを実行する (ほかのマシンへの遠隔ログインなど) と、「鍵配布センター (KDC)」に対してチケットの要求が透過的に送信されます。KDC はデータベースにアクセスしてそのユーザーを認証し、そのマシンへのアクセスを許可するチケットを返します。「透過的」とは、チケットを明示的に要求する必要がないという意味です。この要求は rlogin コマンドの中で行われます。特定のサービスのチケットを取得できるのは認証されたクライアントだけで、別のクライアントが識別情報を仮定して rlogin を使用することはできません。

チケットには一定の属性が与えられています。たとえば、チケットには、新しい認証処理を行わなくても別のマシンで使用できる「転送可能」の属性があります。また、指定の日付まで有効にならない「遅延」の属性もあります。どのユーザーがどの種類のチケットを取得できるかを指定するなど、チケットをどのように使用するかは、「ポリシー」によって設定されます。ポリシーは、Kerberos サービスのインストールや管理の際に決定します。

注 –

「資格」と「チケット」という用語は、頻繁に使用されます。広い意味の Kerberos では、これらの用語は同じ意味で使われることがありますが、技術的には資格は、チケットとそのセッションに対する「セッション鍵」からなります。この違いについては、 「Kerberos によるサービスへのアクセス」で詳しく説明します。

次の節では、Kerberos 認証プロセスについて詳細に説明します。

初期認証: チケット認可チケット (TGT)

Kerberos 認証には、後続の認証を準備する初期認証と、後続の認証の 2 つのフェーズが あります。　

次の図では、初期認証の手順を示します。

図 21–1 Kerberos セッションの初期認証

クライアントは、まず KDC に TGT を要求し、次に KDC から受け取った TGT を復号化します。

  1. クライアント (ユーザー、または NFS などのサービス) は、KDC に TGT を要求して Kerberos セッションを開始します。ほとんどの場合、この要求はログイン時に自動的に実行されます。

    TGT は、ほかの特定のサービスのチケットを取得するために必要です。TGT は、パスポートに似ています。パスポートと同様に、TGT はユーザーを識別して、さまざまなビザの取得をユーザーに許可します。ここでいうビザ (チケット) は、外国に入国するためのものではなく、遠隔マシンやネットワークサービスにアクセスするためのものです。パスポートやビザと同様に、TGT などのチケットには有効期限があります。ただし、Kerberos コマンドは、ユーザーがパスポートを所有していることを通知し、ユーザーに代わってビザを取得します。ユーザー自身がトランザクションを実行する必要はありません。

    チケット認可チケットに類似した例として、4 つのスキー場で使える 3 日間のスキーパスを挙げます。ユーザーは、パスが期限切れになるまで、このパスを任意のスキー場で提示して、そのスキー場のリフトチケットを受け取ります。リフトチケットを入手したら、そのスキー場で好きなだけスキーをすることができます。翌日別のスキー場に行った場合は、またパスを提示して、そのスキー場のリフトチケットを入手します。ただし、Kerberos に基づくコマンドは、ユーザーが週末スキーパスを所有していることをユーザーに通知し、ユーザーに代わってリフトチケットを入手します。したがって、ユーザー自身がトランザクションを実行する必要はありません。

  2. KDC は TGT を作成し、それを暗号化してクライアントに送信します。クライアントは、自身のパスワードを使用して TGT を復号化します。

  3. クライアントは、有効な TGT を入手したので、TGT が期限切れになるまで、rlogin、telnet などあらゆる種類のネットワーク操作チケットを要求できます。この TGT の有効期限は通常、数時間です。クライアントは一意のネットワーク操作を実行するたびに、TGT は KDC にその操作のチケットを要求します。

初期認証後の Kerberos 認証

クライアントが初期認証を受け取ると、後続の認証はそれぞれ次の図のように実行されます。

図 21–2 Kerberos 認証を使用してサービスへのアクセスを取得する

クライアントは、まず KDC にチケットを要求するため TGT を送り、次に受け取ったチケットを使用してサーバーにアクセスします。

  1. クライアントは、別のマシンに遠隔ログインするなど、特定のサービスのチケットを KDC に要求するために、識別情報の証拠として自身の TGT を KDC に送信します。

  2. KDC は、そのサービスのチケットをクライアントに送信します。

    たとえば、ユーザー joe が、krb5 認証を要する共有を行っている NFS ファイルシステムにアクセスするとします。このユーザーはすでに認証されている (すでに TGT を持っている) ため、そのファイルにアクセスを試みると、NFS クライアントシステムは NFS サービスのチケットを KDC から自動的および透過的に取得します。

    たとえば、ユーザー joe がサーバー boston 上で rlogin を使用するとします。このユーザーはすでに認証されている (つまり、すでにチケット認可チケットを持っている) ため、rlogin コマンドの一部として自動的かつ透過的にチケットを取得します。このチケットが期限切れになるまで、このユーザーは必要に応じて boston に遠隔ログインできます。joe がマシン denver に遠隔ログインする場合は、手順 1 の方法で別のチケットを取得します。

  3. クライアントはサーバーにチケットを送信します。

    NFS サービスを使用している場合、NFS クライアントは自動的および透過的に NFS サービスのチケットを NFS サーバーに送信します。

  4. サーバーはクライアントにアクセス権を許可します。

これらの手順では、サーバーと KDC 間の通信は発生していないように見えます。しかし、サーバーは KDC と通信していて、最初のクライアントと同様に、KDC に自身を登録しています。わかりやすくするために、その部分は省略しています。

Kerberos 遠隔アプリケーション

joe などのユーザーは、次の Kerberos に基づく (Kerberos 化された) コマンドを使用できます。

これらのアプリケーションは、同じ名前の Solaris アプリケーションと同じです。ただし、トランザクションを認証するときに Kerberos 主体を使用できるようにアプリケーションを拡張することにより、Kerberos に基づくセキュリティーを提供します。主体の詳細については、「Kerberos 主体」を参照してください。

これらのコマンドについては、「Kerberos ユーザーコマンド」で詳しく説明します。

Kerberos 主体

Kerberos サービス内のクライアントは、その「主体 (プリンシパル)」で識別されます。主体は、KDC がチケットを割り当てることができる一意の ID です。主体には、joe などのユーザー、または nfs、telnet などのサービスがあります。

主体名は慣習により「一次」、「インスタンス」、「レルム」という 3 つの部分から なります。joe/admin@ENG.EXAMPLE.COM は一般的な Kerberos 主体の例です。上記の例では、

次に有効な主体名を示します。

Kerberos レルム

「レルム」とはドメインのようなもので、同じ「マスター KDC」の下にあるシステムをグループとして定義する論理ネットワークです。図 21–3 では、レルム間の関係を示します。階層構造のレルムでは、1 つのレルムがほかのレルムの上位集合になります。階層ではない (直接接続の) レルムでは、2 つのレルム間のマッピングを定義する必要があります。Kerberos サービスでは、レルム間で共通の認証が可能です。その場合、各レルムの KDC に、他のレルムの主体エントリだけが必要になります。Kerberos のこの機能は、「レルム間認証」と呼ばれます。

図 21–3 Kerberos レルム

図は、「ENG.EXAMPLE.COM」レルムが、「SEAMCO.COM」とは階層関係がなく、「EXAMPLE.COM」とは階層関係があることを示しています。

Kerberos サーバー

各レルムには、主体データベースのマスターコピーを保守するサーバーが含まれる必要があります。このサーバーを「マスター KDC サーバー」と呼びます。また各レルムには、主体データベースの重複コピーを保持する「スレーブ KDC サーバー」が少なくとも 1 つ必要です。マスター KDC サーバーおよびスレーブ KDC サーバーは、認証の確立に使用されるチケットを作成します。

レルムにはまた、Kerberos アプリケーションサーバー も含めることができます。このサーバーは、Kerberos サービス (ftp、telnet、rsh、NFS など) へのアクセスを提供します。SEAM 1.0 または 1.0.1 がインストールされている場合、レルムに Kerberos ネットワークアプリケーションサーバーが含まれている可能性がありますが、このソフトウェアはこれらのリリースには含まれていませんでした。

次の図では、レルムの構成例を示します。

図 21–4 一般的な Kerberos レルム

一般的な Kerberos レルム「EXAMPLE.COM」です。1 つのマスター KDC、3 つのクライアント、2 つのスレーブ KDC、および 2 つのアプリケーションサーバーからなっています。