Sun Enterprise Authentication Mechanism ガイド

第 1 章 SEAM の概要

この章では、SEAM 製品について紹介します。

SEAM とは

SEAM (Sun Enterprise Authentication Mechanism) は、確実なユーザー認証、およびデータの完全性とプライバシを提供するクライアント/サーバーアーキテクチャで、ネットワークにおいてセキュリティの保護されたトランザクションを実現します。認証によって、ネットワークトランザクションにおける送信者と受信者が確実に正しく識別されます。また、SEAM は送受信されるデータの有効性を検証でき (完全性)、トランザクション中にはデータを暗号化できます (プライバシ)。SEAM を使用すると、セキュリティの保護された状態で他のマシンにログインして、コマンドの実行、データの交換、ファイルの転送ができます。さらに、SEAM は承認サービスも提供します。このサービスにより、管理者はサービスやマシンへのアクセスを制限でき、SEAM ユーザーは自分のアカウントへの他のユーザーからのアクセスを制御できます。

SEAM はシングルサインオンシステムです。つまり、ユーザーはセッションごとに 1 回だけ SEAM から認証されれば、それ以降そのセッション中のトランザクションは自動的に保証されます。SEAM がユーザーを認証した後、ユーザーは、SEAM ベースのコマンド (ftprsh など) を使用したり、NFS ファイルシステム上のデータにアクセスするたびに認証を繰り返す必要はありません。つまり、これらのサービスを使用するたびに、パスワードをネットワーク上で送信する必要はありません。そのためネットワーク上で送信されたパスワードが傍受される危険性がなくなります。

SEAM は Massachusetts Institute of Technology (MIT) で開発された Kerberos V5 ネットワーク認証プロトコルに基づいています。したがって、Kerberos V5 を使用しているユーザーにとって SEAM は非常に親しみやすいものです。Kerberos V5 はネットワークセキュリティにおける事実上の業界標準であるため、SEAM は他のシステムとの相互運用性を高めます。つまり、SEAM は Kerberos V5 を使用するシステムで動作するため、異機種ネットワーク上でもセキュリティの保護されたトランザクションを提供できます。さらに、SEAM によりドメイン間でも単一のドメイン内でも認証が行われセキュリティが保証されます。


注 -

SEAM は Kerberos V5 に基づき、Kerberos V5 と相互運用されるように設計されているため、このマニュアルでは、「Kerberos」と「SEAM」という用語をほとんど同じ意味で使用しています。たとえば、「Kerberos レルム」や「SEAM ベースのユーティリティ」などです。また、「Kerberos」と「Kerberos V5」も同じ意味で使用しています。このマニュアルでは、必要な場合のみこれらの用語を区別するようにしています。


SEAM は Solaris アプリケーションの実行に柔軟性を与えます。SEAM は、ネットワークサービス (NFS サービス、telnetftp など) で SEAM ベースと非 SEAM ベースの両方の要求を処理するように構成できます。つまり、SEAM がインストールされていないシステム上でも、現在の Solaris アプリケーションを実行できます。もちろん、SEAM ベースのネットワーク要求だけを処理するようにも構成できます。

さらに、他のセキュリティ機構が開発された場合、アプリケーションは SEAM を使用し続ける必要はありません。SEAM はモジュール方式で Generic Security Service API に統合されるように設計されているため、GSS-API を使用するアプリケーションはニーズに最適な機構を利用できます。

SEAM はどのように動作するのか

次に、SEAM 認証システムの概要を説明します。詳細は、「認証システムの動作」を参照してください。

SEAM セッション開始後、自動的に認証システムが働くのでユーザーは認証について意識する必要はありません。rshftp などのコマンドは通常の方法で動作します。SEAM セッションを初期化するには、ログインして Kerberos パスワードを入力するだけです。

SEAM システムにおいて重要な概念は「チケット」です。チケットとは、ユーザーやサービス (NFS サービスなど) の身元証明書となる電子情報の集合です。免許証が人を識別し、どの種類の免許を持っているかを示すように、チケットはユーザーを識別し、どのネットワークアクセス権を持っているかを示します。SEAM ベースのトランザクションを実行するとき (たとえば、rlogin を使用して他のマシンにリモートログインするとき)、ユーザーは透過的にチケットの要求を鍵発行センター (KDC) に送信します。そして KDC はデータベースにアクセスして、ユーザーの身元を認証します。そして、他のマシンにアクセスする特権を与えるチケットをユーザーに戻します。「透過的」とは、ユーザーが明示的にチケットを要求する必要がないと言うことです。この要求は、rlogin コマンドの一部として実行されます。認証されたクライアントだけが特定のサービスのチケットを取得できるため、他のクライアントは rlogin できません。

チケットは特定の属性を持っています。たとえば、チケットには転送可能 (新たに認証を行う必要なしに他のマシンで使用できること) や、遅延 (指定した時間までは有効でない) を設定できます。どのようにチケットが使用されるか (たとえば、どのユーザーがどのタイプのチケットを取得できるか) は、SEAM をインストールまたは管理するときにポリシーで設定します。


注 -

「資格」と「チケット」という用語はよく用いられます。Kerberos では、広い意味でこれらの用語を同じ意味で使用します。しかし、技術的には、資格はチケットにそのセッションのセッション鍵を加えたものです。この違いについては、「SEAM によるサービスへのアクセス」を参照してください。


次の節では、SEAM 認証プロセスを簡単に説明します。

初期認証: チケット許可チケット

Kerberos 認証には 2 つの段階があります。1 つは初期認証で、この後に続くすべての認証に関して許可を与えます。もう 1 つは、それ以後の認証です。

図 1-1 に、初期認証がどのように行われるかを示します。

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

Graphic

  1. クライアント (ユーザーまたは NFS などのサービス) は、チケット許可チケット (TGT) を鍵発行センターに要求し、SEAM セッションを開始します。これはしばしばログイン時に自動的に行われます。

    チケット許可チケットは、他の特定のサービスのチケットを取得するために必要です。たとえば、チケット許可チケットはパスポートのようなものです。パスポートと同様に、チケット許可チケットはユーザーを識別し、さまざまな「ビザ」を取得できるようにします。この場合、「ビザ」(チケット) は、外国に行くためのものではなく、リモートのマシンやネットワークサービスのチケットのことです。パスポートやビザと同様に、チケット許可チケットと他のさまざまなチケットには有効期限があります。異なる点は、「Kerberos 化」されたコマンドは、ユーザーがパスポートを持っており、ビザを取得できることを認識しているということです。ユーザー自身がトランザクションを実行する必要はありません。

  2. KDC はチケット許可チケットを作成し、暗号化して、クライアントに戻します。クライアントは、クライアントのパスワードでチケット許可チケットを復号化します。

  3. 有効なチケット許可チケットを取得した後、クライアントはあらゆる種類のネットワーク操作 (rlogintelnet など) のチケットを要求できます。ただし、これはチケット許可チケットが有効な間だけです。通常、チケット許可チケットが有効なのは数時間です。クライアントは、固有のネットワーク操作を実行するたびに、その操作に必要なチケットを KDC に要求します。

その後の認証

クライアントが初期認証を受け取った後、個々の認証は次のパターンに従います (図 1-2 を参照)。

図 1-2 サービスへのアクセスの取得

Graphic

  1. クライアントは特定のサービスのチケットを KDC に要求します。つまり、rlogin を実行して他のマシンにリモートログインします。このとき、身元の証明として、クライアントのチケット許可チケットを KDC に送信します。

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

    たとえば、ユーザー joe がサーバー boston 上で rlogin を実行すると仮定します。joe はすでに認証されている (つまり、すでにチケット許可チケットを持っている) ため、joe は、rlogin コマンドの一部として、チケットを自動的および透過的に取得します。joe はこのチケットを使用して、チケットの有効期限が来るまで、boston にリモートログインを何度でもできます。マシン denver にリモートログインしたい場合、joe は手順 1 と同様に別のチケットを取得します。

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

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

上記手順を考えてみると、サーバーが KDC と通信していないように見えます。しかし、実際には通信しています。最初のクライアントと同様に、サーバーは自分自身を KDC に登録します。ここでは詳細な説明は省略します。

SEAM ベースのコマンド

次に、ユーザー (上記例の joe など) が使用できる SEAM ベースの (あるいは「Kerberos 化」された) コマンドを示します。

これらのアプリケーション名は Solaris アプリケーション名と同じです。ただし、SEAM ベースのコマンドは Kerberos プリンシパルを使用してトランザクションを認証します。つまり、Kerberos ベースのセキュリティを提供します。プリンシパルについては、「プリンシパル」を参照してください。

SEAM ベースのコマンドについての詳細は、「SEAM コマンド」を参照してください。

プリンシパル

SEAM のクライアントはそのプリンシパルによって識別されます。プリンシパルとは、KDC がチケットを割り当てることができる、固有に識別される対象です。プリンシパルはユーザー (joe など) でもサービス (nfstelnet など) でもかまいません。

慣習上、プリンシパル名は 3 つの部分からなります。プライマリ、インスタンス、およびレルムです。典型的な SEAM プリンシパルとして joe/admin@ENG.ACME.COM という例を考えてみましょう。

次に、すべての有効なプリンシパル名を示します。

レルム

レルムは、ドメインのような論理的なネットワークで、同じマスター KDC (下記を参照) の下でシステムのグループを定義します。図 1-3 に、どのようにレルムが他のレルムと関連するかを示します。いくつかのレルムは階層構造 (つまり、他のレルムのスーパーセット) になっています。レルムが階層構造でない場合は、2 つのレルム間のマッピングが定義されている必要があります。SEAM の特徴はレルム間で認証を許可することです。各レルムは、その KDC に他のレルムのプリンシパルエントリを持つだけでよいのです。

図 1-3 レルム

Graphic

レルムとサーバー

各レルムには、プリンシパルデータベースのマスターコピーを保持しているサーバーが必要です。このサーバーのことをマスター KDC サーバーと呼びます。さらに、各レルムで、プリンシパルデータベースの複製コピーを持つサーバーがあれば望ましいですが、なくても動作します。このサーバーのことをスレーブ KDC サーバーと呼びます。マスター KDC サーバーとスレーブ KDC サーバーは両方とも、認証を確立するためのチケットを作成します。

さらに、レルムは 2 種類の SEAM サーバーを持つことができます。SEAM ネットワークのアプリケーションサーバーは、Kerberos 化されたアプリケーション (ftptelnetrsh など) へのアクセスを提供するサーバーです。レルムは、Kerberos 認証で NFS サービスを提供する NFS サーバーを持つこともできます。

図 1-4 に、レルムの例を示します。

図 1-4 典型的なレルム

セキュリティサービス

SEAM はユーザーを確実に認証するとともに、2 つのセキュリティサービスを提供します。

現在、SEAM の一部であるさまざまな Kerberos 化されたアプリケーションの中で、ユーザーが実行時にセキュリティサービスを変更できるのは ftp コマンドだけです。開発者は RPCSEC_GSS プログラミングインタフェースを使用して、セキュリティサービスを選択できるように RPC ベースのアプリケーションを設計できます。

SEAM の構成要素

Kerberos V5 の MIT 配布版と同様に、SEAM には次の構成要素があります。

さらに、SEAM 製品には次の構成要素も含まれています。