この章では、SEAM 製品について紹介します。
SEAM (Sun Enterprise Authentication Mechanism) は、確実なユーザー認証、およびデータの完全性とプライバシを提供するクライアント/サーバーアーキテクチャで、ネットワークにおいてセキュリティの保護されたトランザクションを実現します。認証によって、ネットワークトランザクションにおける送信者と受信者が確実に正しく識別されます。また、SEAM は送受信されるデータの有効性を検証でき (完全性)、トランザクション中にはデータを暗号化できます (プライバシ)。SEAM を使用すると、セキュリティの保護された状態で他のマシンにログインして、コマンドの実行、データの交換、ファイルの転送ができます。さらに、SEAM は承認サービスも提供します。このサービスにより、管理者はサービスやマシンへのアクセスを制限でき、SEAM ユーザーは自分のアカウントへの他のユーザーからのアクセスを制御できます。
SEAM はシングルサインオンシステムです。つまり、ユーザーはセッションごとに 1 回だけ SEAM から認証されれば、それ以降そのセッション中のトランザクションは自動的に保証されます。SEAM がユーザーを認証した後、ユーザーは、SEAM ベースのコマンド (ftp や rsh など) を使用したり、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 サービス、telnet、ftp など) で SEAM ベースと非 SEAM ベースの両方の要求を処理するように構成できます。つまり、SEAM がインストールされていないシステム上でも、現在の Solaris アプリケーションを実行できます。もちろん、SEAM ベースのネットワーク要求だけを処理するようにも構成できます。
さらに、他のセキュリティ機構が開発された場合、アプリケーションは SEAM を使用し続ける必要はありません。SEAM はモジュール方式で Generic Security Service API に統合されるように設計されているため、GSS-API を使用するアプリケーションはニーズに最適な機構を利用できます。
次に、SEAM 認証システムの概要を説明します。詳細は、「認証システムの動作」を参照してください。
SEAM セッション開始後、自動的に認証システムが働くのでユーザーは認証について意識する必要はありません。rsh や ftp などのコマンドは通常の方法で動作します。SEAM セッションを初期化するには、ログインして Kerberos パスワードを入力するだけです。
SEAM システムにおいて重要な概念は「チケット」です。チケットとは、ユーザーやサービス (NFS サービスなど) の身元証明書となる電子情報の集合です。免許証が人を識別し、どの種類の免許を持っているかを示すように、チケットはユーザーを識別し、どのネットワークアクセス権を持っているかを示します。SEAM ベースのトランザクションを実行するとき (たとえば、rlogin を使用して他のマシンにリモートログインするとき)、ユーザーは透過的にチケットの要求を鍵発行センター (KDC) に送信します。そして KDC はデータベースにアクセスして、ユーザーの身元を認証します。そして、他のマシンにアクセスする特権を与えるチケットをユーザーに戻します。「透過的」とは、ユーザーが明示的にチケットを要求する必要がないと言うことです。この要求は、rlogin コマンドの一部として実行されます。認証されたクライアントだけが特定のサービスのチケットを取得できるため、他のクライアントは rlogin できません。
チケットは特定の属性を持っています。たとえば、チケットには転送可能 (新たに認証を行う必要なしに他のマシンで使用できること) や、遅延 (指定した時間までは有効でない) を設定できます。どのようにチケットが使用されるか (たとえば、どのユーザーがどのタイプのチケットを取得できるか) は、SEAM をインストールまたは管理するときにポリシーで設定します。
「資格」と「チケット」という用語はよく用いられます。Kerberos では、広い意味でこれらの用語を同じ意味で使用します。しかし、技術的には、資格はチケットにそのセッションのセッション鍵を加えたものです。この違いについては、「SEAM によるサービスへのアクセス」を参照してください。
次の節では、SEAM 認証プロセスを簡単に説明します。
Kerberos 認証には 2 つの段階があります。1 つは初期認証で、この後に続くすべての認証に関して許可を与えます。もう 1 つは、それ以後の認証です。
図 1-1 に、初期認証がどのように行われるかを示します。
クライアント (ユーザーまたは NFS などのサービス) は、チケット許可チケット (TGT) を鍵発行センターに要求し、SEAM セッションを開始します。これはしばしばログイン時に自動的に行われます。
チケット許可チケットは、他の特定のサービスのチケットを取得するために必要です。たとえば、チケット許可チケットはパスポートのようなものです。パスポートと同様に、チケット許可チケットはユーザーを識別し、さまざまな「ビザ」を取得できるようにします。この場合、「ビザ」(チケット) は、外国に行くためのものではなく、リモートのマシンやネットワークサービスのチケットのことです。パスポートやビザと同様に、チケット許可チケットと他のさまざまなチケットには有効期限があります。異なる点は、「Kerberos 化」されたコマンドは、ユーザーがパスポートを持っており、ビザを取得できることを認識しているということです。ユーザー自身がトランザクションを実行する必要はありません。
KDC はチケット許可チケットを作成し、暗号化して、クライアントに戻します。クライアントは、クライアントのパスワードでチケット許可チケットを復号化します。
有効なチケット許可チケットを取得した後、クライアントはあらゆる種類のネットワーク操作 (rlogin や telnet など) のチケットを要求できます。ただし、これはチケット許可チケットが有効な間だけです。通常、チケット許可チケットが有効なのは数時間です。クライアントは、固有のネットワーク操作を実行するたびに、その操作に必要なチケットを KDC に要求します。
クライアントが初期認証を受け取った後、個々の認証は次のパターンに従います (図 1-2 を参照)。
クライアントは特定のサービスのチケットを KDC に要求します。つまり、rlogin を実行して他のマシンにリモートログインします。このとき、身元の証明として、クライアントのチケット許可チケットを KDC に送信します。
KDC は特定のサービスのチケットをクライアントに送信します。
たとえば、ユーザー joe がサーバー boston 上で rlogin を実行すると仮定します。joe はすでに認証されている (つまり、すでにチケット許可チケットを持っている) ため、joe は、rlogin コマンドの一部として、チケットを自動的および透過的に取得します。joe はこのチケットを使用して、チケットの有効期限が来るまで、boston にリモートログインを何度でもできます。マシン denver にリモートログインしたい場合、joe は手順 1 と同様に別のチケットを取得します。
クライアントはチケットをサーバーに送信します。
サーバーはクライアントにアクセスを許可します。
上記手順を考えてみると、サーバーが KDC と通信していないように見えます。しかし、実際には通信しています。最初のクライアントと同様に、サーバーは自分自身を KDC に登録します。ここでは詳細な説明は省略します。
次に、ユーザー (上記例の joe など) が使用できる SEAM ベースの (あるいは「Kerberos 化」された) コマンドを示します。
ftp
rcp
rlogin
rsh
telnet
これらのアプリケーション名は Solaris アプリケーション名と同じです。ただし、SEAM ベースのコマンドは Kerberos プリンシパルを使用してトランザクションを認証します。つまり、Kerberos ベースのセキュリティを提供します。プリンシパルについては、「プリンシパル」を参照してください。
SEAM ベースのコマンドについての詳細は、「SEAM コマンド」を参照してください。
SEAM のクライアントはそのプリンシパルによって識別されます。プリンシパルとは、KDC がチケットを割り当てることができる、固有に識別される対象です。プリンシパルはユーザー (joe など) でもサービス (nfs や telnet など) でもかまいません。
慣習上、プリンシパル名は 3 つの部分からなります。プライマリ、インスタンス、およびレルムです。典型的な SEAM プリンシパルとして joe/admin@ENG.ACME.COM という例を考えてみましょう。
joe はプライマリです。プライマリはユーザー名 (上記の場合) でもサービス (nfs など) でもかまいません。また、さまざまなネットワークサービス (ftp、rcp、rlogin など) を提供するために設定されたサービスプリンシパルであることを意味する .host という単語も指定できます。
admin はインスタンスです。インスタンスはユーザープリンシパルの場合は任意ですが、サービスプリンシパルの場合は必須です。たとえば、ユーザー joe がシステム管理者として活動することもある場合、joe/admin を使用することによって、管理者としての自分と通常のユーザーとしての自分を区別できます。同様に、joe が 2 つの異なるホストでアカウントを持っている場合、インスタンスが異なる 2 つのプリンシパル名を使用できます。たとえば、joe/denver.acme.com と joe/boston.acme.com です。SEAM は joe と joe/admin を 2 つのまったく異なるプリンシパルとして扱うことに注意してください。
サービスプリンシパルの場合、インスタンスは完全指定のホスト名です。たとえば、bigmachine.eng.acme.com です。この場合、プライマリ/インスタンスは ftp/bigmachine.eng.acme.com や host/bigmachine.eng.acme.com となります。
ENG.ACME.COM は SEAM のレルムです。レルムについては、 「レルム」を参照してください。
次に、すべての有効なプリンシパル名を示します。
joe
joe/admin
joe/admin@ENG.ACME.COM
ftp/host.eng.acme.com@ENG.ACME.COM
host/eng.acme.com@ENG.ACME.COM
レルムは、ドメインのような論理的なネットワークで、同じマスター KDC (下記を参照) の下でシステムのグループを定義します。図 1-3 に、どのようにレルムが他のレルムと関連するかを示します。いくつかのレルムは階層構造 (つまり、他のレルムのスーパーセット) になっています。レルムが階層構造でない場合は、2 つのレルム間のマッピングが定義されている必要があります。SEAM の特徴はレルム間で認証を許可することです。各レルムは、その KDC に他のレルムのプリンシパルエントリを持つだけでよいのです。
各レルムには、プリンシパルデータベースのマスターコピーを保持しているサーバーが必要です。このサーバーのことをマスター KDC サーバーと呼びます。さらに、各レルムで、プリンシパルデータベースの複製コピーを持つサーバーがあれば望ましいですが、なくても動作します。このサーバーのことをスレーブ KDC サーバーと呼びます。マスター KDC サーバーとスレーブ KDC サーバーは両方とも、認証を確立するためのチケットを作成します。
さらに、レルムは 2 種類の SEAM サーバーを持つことができます。SEAM ネットワークのアプリケーションサーバーは、Kerberos 化されたアプリケーション (ftp、telnet、rsh など) へのアクセスを提供するサーバーです。レルムは、Kerberos 認証で NFS サービスを提供する NFS サーバーを持つこともできます。
図 1-4 に、レルムの例を示します。
SEAM はユーザーを確実に認証するとともに、2 つのセキュリティサービスを提供します。
完全性 - 認証はネットワーク上のクライアントが要求元であることを保証するように、完全性はクライアントが送信したデータが有効であり、転送中に変更されていないことを保証します。これは、データの暗号チェックサム方式で行われます。完全性にはユーザー認証も含まれます。
プライバシ - プライバシとは、セキュリティをさらに一歩進めたものです。転送されたデータの完全性を検証するだけではなく、転送前にデータを暗号化し、傍受されることを防ぎます。プライバシもユーザーを認証します。
米国の輸出規制のため、SEAM ユーザーでもプライバシサービスを利用できない場合があります。
現在、SEAM の一部であるさまざまな Kerberos 化されたアプリケーションの中で、ユーザーが実行時にセキュリティサービスを変更できるのは ftp コマンドだけです。開発者は RPCSEC_GSS プログラミングインタフェースを使用して、セキュリティサービスを選択できるように RPC ベースのアプリケーションを設計できます。
Kerberos V5 の MIT 配布版と同様に、SEAM には次の構成要素があります。
鍵発行センター (KDC) (マスター)
Kerberos データベース管理デーモン - kadmind
Kerberos チケット処理デーモン - krb5kdc
スレーブ KDC
データベース管理プログラム - kadmin と kadmin.local
データベース伝達ソフトウェア - kprop
チケットを取得、表示、および破棄するためのユーザープログラム - kinit、klist、kdestroy
SEAM パスワードを変更するためのユーザープログラム - kpasswd
アプリケーション - ftp、rcp、rlogin、rsh、telnet
これらアプリケーションのデーモン - ftpd、rlogind、rshd、telnetd
管理ユーティリティ - ktutil、kdb5_util
いくつかのライブラリ
さらに、SEAM 製品には次の構成要素も含まれています。
SEAM 管理ツール (gkadmin) - KDC を管理できます。この JavaTM ベースのツールを使用すると、管理者は通常は kadmin コマンドで実行する作業を GUI で実行できます。
Pluggable Authentication Module (PAM) - アプリケーションがさまざまな認証機構を使用できます。PAM を使用すると、ユーザーは透過的にログインおよびログアウトできます。
ユーティリティ (gsscred) とデーモン (gssd) - UNIX の ユーザー ID とプリンシパル名のマッピングに役立ちます。SEAM の NFS サーバーは、プリンシパル名ではなく、UNIX の ID でユーザーを識別するために必要です。両者の形式はまったく異なります。
GSS_API フレームワーク - Generic Security Service Application Programming Interface (GSS-API) を使用すると、アプリケーションは複数のセキュリティ機構を使用できます。新しいセキュリティ機構を追加するたびに再コンパイルする必要はありません。GSS-API はマシンに依存しないため、インターネット上のアプリケーションに適しています。GSS-API は、認証と同様に、セキュリティサービスの完全性とプライバシを実現する機能をアプリケーションに提供します。
RPCSEC_GSS Application Programming Interface (API) - NFS サービスが Kerberos 認証で使用します。RPCSEC_GSS は新しいセキュリティフレーバで、使用する機構に依存しないセキュリティサービスを提供します。RPCSEC_GSS は GSS-API 層の一番上に位置します。RPCSEC_GSS を使用するアプリケーションは、差し替え可能な GSS_API ベースのあらゆるセキュリティ機構を使用できます。
事前構成手順 - SEAM をインストールおよび構成するためのパラメータを設定し、SEAM のインストールを自動化できます。特に、インストールが複数あるときに便利です。
カーネルの変更 - 性能が向上します。