ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
![]() |
Solaris のシステム管理: セキュリティーサービス Oracle Solaris 10 1/13 Information Library (日本語) |
パート II システム、ファイル、およびデバイスのセキュリティー
13. Oracle Solaris の暗号化フレームワーク (概要)
14. Oracle Solaris の暗号化フレームワーク (タスク)
Solaris 10 5/08 リリースでの Kerberos の追加機能
Solaris 10 8/07 リリースでの Kerberos の追加機能
Solaris 10 6/06 リリースでの Kerberos の追加機能
Solaris 10 3/05 リリースでの Kerberos の拡張機能
24. Kerberos エラーメッセージとトラブルシューティング
26. Kerberos アプリケーションの使用 (タスク)
この節では Kerberos 認証システムの概要について説明します。詳細は、「Kerberos 認証システムの動作方法」を参照してください。
Kerberos セッションが起動されたあとは、ユーザーから見ると Kerberos サービスが意識されることはほとんどありません。rsh や ftp などのコマンドは、ほぼ変わりなく動作します。Kerberos セッションの初期化には通常、ログインと Kerberos パスワードの入力しか必要ありません。
Kerberos システムは、チケットの概念を中心に動作します。チケットは、ユーザー、および NFS サービスなどのサービスを特定する一連の電子情報です。運転免許証が運転する人と免許の種類を表すのと同じように、チケットもユーザーとユーザーのネットワークアクセス権を表します。Kerberos に基づくトランザクションを実行すると (たとえば、別のマシンにリモートログインする場合)、チケットのリクエストは鍵配布センター (つまり、KDC) に透過的に送信されます。KDC はデータベースにアクセスしてそのユーザーを認証し、そのマシンへのアクセスを許可するチケットを返します。「透過的」とは、チケットを明示的に要求する必要がないという意味です。このリクエストは、rlogin コマンドの一部として行われます。特定のサービスのチケットを取得できるのは認証されたクライアントだけで、別のクライアントが識別情報を仮定して rlogin を使用することはできません。
チケットには、特定の属性が関連付けられています。たとえば、チケットには、新しい認証処理を行わなくても別のマシンで使用できる「転送可能」の属性があります。また、指定の日付まで有効にならない「遅延」の属性もあります。どのユーザーがどの種類のチケットを取得できるかを指定するなど、チケットをどのように使用するかは、「ポリシー」によって設定されます。ポリシーは、Kerberos サービスのインストールや管理の際に決定します。
注 - 資格およびチケットという用語は、頻繁に目にします。広い意味の Kerberos では、これらの用語は同じ意味で使われることがありますが、技術的には資格は、チケットとそのセッションに対する「セッション鍵」からなります。この違いについては、 「Kerberos によるサービスへのアクセス」で詳しく説明します。
次のセクションでは、Kerberos 認証プロセスについて詳細に説明します。
Kerberos 認証には、後続の認証を準備する初期認証と、後続の認証の 2 つのフェーズがあります。
次の図では、初期認証の手順を示します。
図 21-1 Kerberos セッションの初期認証
クライアント (ユーザー、または NFS などのサービス) は、KDC に TGT を要求して Kerberos セッションを開始します。ほとんどの場合、この要求はログイン時に自動的に実行されます。
TGT は、ほかの特定のサービスのチケットを取得するために必要です。TGT は、パスポートに似ています。パスポートと同様に、TGT はユーザーを識別して、さまざまなビザの取得をユーザーに許可します。ここでいうビザ (チケット) は、外国に入国するためのものではなく、リモートマシンやネットワークサービスにアクセスするためのものです。パスポートやビザと同様に、TGT などのチケットには有効期限があります。ただし、Kerberos コマンドは、ユーザーがパスポートを所有していることを通知し、ユーザーに代わってビザを取得します。ユーザー自身がトランザクションを実行する必要はありません。
チケット認可チケットに類似した例として、4 つのスキー場で使える 3 日間のスキーパスを挙げます。ユーザーは、パスが期限切れになるまで、このパスを任意のスキー場で提示して、そのスキー場のリフトチケットを受け取ります。リフトチケットを入手したら、そのスキー場で好きなだけスキーをすることができます。翌日別のスキー場に行った場合は、またパスを提示して、そのスキー場のリフトチケットを入手します。ただし、Kerberos に基づくコマンドは、ユーザーが週末スキーパスを所有していることをユーザーに通知し、ユーザーに代わってリフトチケットを入手します。したがって、ユーザー自身がトランザクションを実行する必要はありません。
KDC は TGT を作成し、それを暗号化してクライアントに送信します。クライアントは、自身のパスワードを使用して TGT を復号化します。
これで有効なチケット認可チケットを入手できたため、そのチケット認可チケットが有効であるかぎり、クライアントは、あらゆる種類のネットワーク操作 (rlogin や telnet など) に対してチケットをリクエストできます。この TGT の有効期限は通常、数時間です。クライアントは一意のネットワーク操作を実行するたびに、TGT は KDC にその操作のチケットを要求します。
クライアントが初期認証を受け取ると、後続の認証はそれぞれ次の図のように実行されます。
図 21-2 Kerberos 認証を使用してサービスへのアクセスを取得する
クライアントは、別のマシンにリモートログインするなど、特定のサービスのチケットを KDC に要求するために、識別情報の証拠として自身の TGT を KDC に送信します。
KDC は、そのサービスのチケットをクライアントに送信します。
たとえば、ユーザー joe が、krb5 認証を要する共有を行なっている NFS ファイルシステムにアクセスするとします。このユーザーはすでに認証されている (すでに TGT を持っている) ため、そのファイルにアクセスを試みると、NFS クライアントシステムは NFS サービスのチケットを KDC から自動的および透過的に取得します。
たとえば、ユーザー joe がサーバー boston 上で rlogin を使用しているとします。このユーザーはすでに認証されている (つまり、すでにチケット認可チケットを持っている) ため、rlogin コマンドの一部として自動的かつ透過的にチケットを取得します。このチケットが期限切れになるまで、このユーザーは必要に応じて boston にリモートログインできます。joe がマシン denver にリモートログインする場合は、手順 1 にあるように、別のチケットを取得します。
クライアントはサーバーにチケットを送信します。
NFS サービスを使用している場合、NFS クライアントは自動的および透過的に NFS サービスのチケットを NFS サーバーに送信します。
サーバーはクライアントにアクセス権を許可します。
これらの手順では、サーバーと KDC 間の通信は発生していないように見えます。しかし、サーバーは KDC と通信していて、最初のクライアントと同様に、KDC に自身を登録しています。わかりやすくするために、その部分は省略しています。
joe などのユーザーは、次の Kerberos に基づく (Kerberos 化された) コマンドを使用できます。
ftp
rcp
rdist
rlogin
rsh
ssh
telnet
これらのアプリケーションは、同じ名前の Solaris アプリケーションと同じです。ただし、トランザクションを認証するときに Kerberos 主体を使用できるようにアプリケーションを拡張することにより、Kerberos に基づくセキュリティーを提供します。主体の詳細については、「Kerberos 主体」を参照してください。
これらのコマンドについては、「Kerberos ユーザーコマンド」で詳しく説明します。
Kerberos サービス内のクライアントは、その主体で識別されます。主体は、KDC がチケットを割り当てることができる一意の ID です。主体には、joe などのユーザー、または nfs や telnet などのサービスがあります。
慣例上、主体名はプライマリ、インスタンス、レルムの 3 つのコンポーネントに分割されます。標準的な Kerberos 主体は、たとえば、joe/admin@ENG.EXAMPLE.COM となります。この例では、
joe がプライマリです。プライマリには、この例のようなユーザー名や nfs などのサービスを指定します。また、host を指定することもできます。host を指定すると、ftp、rcp、rlogin などのさまざまなネットワークサービスを提供する、サービス主体として設定されます。
admin はインスタンスです。インスタンスは、ユーザー主体の場合はオプションですが、サービス主体では必須です。たとえば、ユーザー joe が必要に応じてシステム管理者の権限を使用する場合は、joe/admin と通常のユーザー ID を使い分けることができます。同様に、joe が 2 つの異なるホスト上にアカウントを持っている場合は、異なるインスタンスで 2 つの主体名を使用できます (たとえば、joe/denver.example.com と joe/boston.example.com)。Kerberos サービスでは、joe と joe/admin が完全に異なる 2 つの主体として処理されることに注意してください。
サービス主体では、インスタンスは完全指定されたホスト名です。bigmachine.eng.example.com はこのようなインスタンスの例です。この例のプライマリとインスタンスは、ftp/bigmachine.eng.example.com または host/bigmachine.eng.example.com になる可能性があります。
ENG.EXAMPLE.COM は Kerberos レルムです。レルムについては、「Kerberos レルム」を参照してください。
次に有効な主体名を示します。
joe
joe/admin
joe/admin@ENG.EXAMPLE.COM
nfs/host.eng.example.com@ENG.EXAMPLE.COM
host/eng.example.com@ENG.EXAMPLE.COM
「レルム」とはドメインのようなもので、同じ「マスター KDC」の下にあるシステムをグループとして定義する論理ネットワークです。図 21-3 は、レルム間の関係を示しています。階層構造のレルムでは、1 つのレルムがほかのレルムの上位集合になります。階層ではない (直接接続の) レルムでは、2 つのレルム間のマッピングを定義する必要があります。Kerberos サービスでは、レルム間で共通の認証が可能です。その場合、各レルムの KDC に、他のレルムの主体エントリだけが必要になります。Kerberos のこの機能は、「レルム間認証」と呼ばれます。
図 21-3 Kerberos レルム
各レルムには、主体データベースのマスターコピーを保守するサーバーが含まれる必要があります。このサーバーを「マスター KDC サーバー」と呼びます。また各レルムには、主体データベースの重複コピーを保持する「スレーブ KDC サーバー」が少なくとも 1 つ必要です。マスター KDC サーバーおよびスレーブ KDC サーバーは、認証の確立に使用されるチケットを作成します。
レルムにはまた、Kerberos アプリケーションサーバー も含めることができます。このサーバーは、Kerberos サービス (ftp、telnet、rsh、NFS など) へのアクセスを提供します。SEAM 1.0 または 1.0.1 がインストールされている場合、レルムに Kerberos ネットワークアプリケーションサーバーが含まれている可能性がありますが、このソフトウェアはこれらのリリースには含まれていませんでした。
次の図は、仮想的なレルムに含まれる可能性のあるものを示しています。
図 21-4 一般的な Kerberos レルム