test

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

SEAM の動作

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

ユーザーの観点からいえば、SEAM は、SEAM セッションが起動されたあとはほとんど意識しません。SEAM セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。

SEAM システムは、チケットの概念を中心に動作します。チケットは、ユーザー ID や NFS などのサービス ID となる一連の電子情報です。運転免許証が運転する人と免許の種類を表すのと同じように、チケットもユーザーとユーザーのネットワークアクセス権を表します。SEAM ベースのトランザクションを実行する (ほかのマシンへの rlogin など) と、鍵配布センター (KDC) に対してチケットの要求が透過的に送信されます。KDC はデータベースにアクセスしてそのユーザーを認証し、そのマシンへのアクセス権を許可するチケットを返します。「透過的」とは、明示的にチケットを要求する必要がないことを意味します。

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

注 –

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

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

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

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

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

図 7–1 SEAM セッションの初期認証

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

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

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

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

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

後続の認証

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

図 7–2 サービスへのアクセスを取得する

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

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

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

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

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

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

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

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

主体

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

主体名は慣習により「一次」、「インスタンス」、「レルム」という 3 つの部分からなります。joe/admin@ENG.EXAMPLE.COM は一般的な SEAM 主体の例です。各文字列は次の意味を持ちます。

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

レルム

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

図 7–3 レルム

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

レルムとサーバー

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

レルムには、「NFS サーバー」も含まれます。NFS サーバーは Kerberos 認証を使用する NFS サービスを提供します。SEAM 1.0 または SEAM 1.0.1 をインストールすると、レルムには、Kerberos アプリケーション (ftp、telnet、rsh など) からアクセスされる SEAM ネットワークのアプリケーションサーバーもインストールされます。

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

図 7–4 一般的なレルム

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