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