Kerberos のコンポーネント

Kerberos には、レルム、ネットワークプログラム、主体、サーバーなどのコンポーネントが含まれています。コマンドとモジュールのリストについては、Kerberos ユーティリティーを参照してください。

Kerberos ネットワークプログラム

ユーザーが使用できる Kerberos に基づく (「Kerberos 化された」) コマンドは次のとおりです。

• ftp

• rcp、rlogin、rsh

• ssh、scp、sftp

• telnet

これらのアプリケーションは、同じ名前の Oracle Solaris アプリケーションと同じです。ただし、トランザクションを認証するときに Kerberos 主体を使用できるようにアプリケーションを拡張することにより、Kerberos に基づくセキュリティーを提供します。主体については、Kerberos 主体を参照してください。

これらのコマンドについては、Kerberos のユーザーコマンドで詳しく説明します。

Kerberos 主体

Kerberos サービス内のクライアントは、その「主体」で識別されます。主体は、KDC がチケットを割り当てることができる一意の ID です。主体には、jdoe などのユーザーや、nfs などのサービスがあります。

慣例上、主体名はプライマリ、インスタンス、レルムの 3 つのコンポーネントに分割されます。標準的な Kerberos 主体は、たとえば jdoe/admin@CORP.EXAMPLE.COM のようになります。この例では、次のようになります。

• jdoe はプライマリです。プライマリには、この例のようなユーザー名や nfs などのサービスを指定します。また、プライマリが host という単語である場合もあります。これは、この主体が ftp、scp、ssh などのさまざまなネットワークサービスを提供するように設定されているサービス主体であることを示します。

• admin はインスタンスです。インスタンスは、ユーザー主体の場合はオプションですが、サービス主体では必須です。たとえば、ユーザー jdoe がシステム管理者の役割を果たす場合もあるときは、主体 jdoe/admin によってユーザーと管理者を区別できます。同様に、jdoe が 2 つの異なるホスト上にアカウントを持っている場合、これらのアカウントでは、インスタンスが異なる 2 つの主体名 (jdoe/denver.example.com と jdoe/boston.example.com など) を使用できます。Kerberos サービスでは jdoe と jdoe/admin が 2 つの完全に異なる主体として処理されることに注意してください。

  サービス主体では、インスタンスは完全指定されたホスト名です。bighop.corp.example.com はこのようなインスタンスの例です。この例のプライマリとインスタンスは、ftp/bighop.corp.example.com または host/bighop.corp.example.com になる可能性があります。

• CORP.EXAMPLE.COM は Kerberos レルムです。レルムについては、Kerberos レルムを参照してください。

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

• jdoe

• jdoe/admin

• jdoe/admin@CORP.EXAMPLE.COM

• nfs/host.corp.example.com@CORP.EXAMPLE.COM

• host/corp.example.com@CORP.EXAMPLE.COM

Kerberos レルム

「レルム」とはドメインのようなもので、同じ「マスター KDC」の下にあるシステムをグループとして定義する論理ネットワークです。図 6は、各レルムが相互にどのように関連するかを示しています。階層構造のレルムでは、1 つのレルムがほかのレルムの上位集合になります。階層ではない (直接接続の) レルムでは、2 つのレルム間のマッピングを定義する必要があります。Kerberos のレルム間認証を使用すると、レルムにまたがる認証が可能になります。その場合、各レルムの KDC に、他のレルムの主体エントリだけが必要になります。

図 6  Kerberos レルム

Kerberos サーバー

各レルムには、主体データベースのマスターコピーを保守するサーバーが含まれる必要があります。このサーバーを「マスター KDC サーバー」と呼びます。さらに、各レルムにはセカンダリサーバーを含めるようにしてください。セカンダリサーバーは、マスター KDC からリフレッシュまたは伝播される主体データベースの複製コピーを含むスレーブ KDC サーバーにすることができます。セカンダリサーバーは、マルチマスター構成を形成するもう 1 つのマスター KDC にすることもできます。マスター KDC サーバーとスレーブ KDC サーバーはどちらも、認証の確立に使用されるチケットを作成します。

レルムにはまた、Kerberos アプリケーションサーバー も含めることができます。このサーバーは、ftp、ssh、NFS などの Kerberos サービスへのアクセスを提供します。

次の図は、仮想レルムに含まれる可能性のあるものを示しています。

図 7  一般的な Kerberos レルム

Kerberos ユーティリティー

MIT が配布する Kerberos V5 製品と同様に、Oracle Solaris リリースの Kerberos サービスには次が含まれています。

• 鍵配布センター (KDC):

  • Kerberos データベース管理デーモン – kadmind。

  • Kerberos チケット処理デーモン – krb5kdc。

  • データベース管理プログラム – kadmin (マスターのみ)、kadmin.local、および kdb5_util。

  • データベース伝播ソフトウェア – kprop (スレーブのみ) および kpropd。

• 資格を管理するためのユーザープログラム – kinit、klist、および kdestroy。

• Kerberos パスワードを変更するためのユーザープログラム – kpasswd。

• ネットワークアプリケーション – ftp、rcp、rlogin、rsh、scp、sftp、ssh、および telnet。

• リモートアプリケーションデーモン – ftpd、rlogind、rshd、sshd、および telnetd。

• キータブ管理ユーティリティー – ktutil。

• Generic Security Service Application Programming Interface (GSS-API) – 新しいメカニズムが追加されるたびにアプリケーションを再コンパイルしなくても、アプリケーションが複数のセキュリティーメカニズムを使用できるようにします。GSS-API では、アプリケーションを多くのオペレーティングシステムに移植可能にする標準インタフェースが使用されます。GSS-API はアプリケーションに、認証だけでなく、整合性およびプライバシセキュリティーサービスを組み込む機能を提供します。ftp と ssh は、どちらも GSS-API を使用しています

• RPCSEC_GSS Application Programming Interface (API) – NFS サービスが Kerberos 認証を使用できるようにします。RPCSEC_GSS API は、使用されているメカニズムには依存しないセキュリティーサービスを提供します。RPCSEC_GSS は、GSS-API 層の最上位に位置しています。GSS_API ベースのセキュリティーメカニズムは、プラグイン可能なので、RPCSEC_GSS を使用するアプリケーションで使用できます。

さらに、Oracle Solaris の Kerberos サービスには、次のものが含まれています。

• PAM 用の Kerberos V5 サービスモジュール – Kerberos サービスのための認証、アカウント管理、セッション管理、およびパスワード管理を提供します。これらのモジュールにより、Kerberos 認証はユーザーに対して透過的に実行されます。

• Kerberos V5 ユーザーごとの PAM スタック – /etc/security/pam_policy ディレクトリ内にある、さまざまなシナリオのための PAM 構成ファイルを提供します。

• カーネルモジュール – NFS サービスで使用される、Kerberos サービスのカーネルベースの実装を提供します。これにより、パフォーマンスが大幅に向上します。

詳細は、Kerberos サービスのリファレンスを参照してください。

Kerberos セキュリティーサービス

Kerberos サービスは、ユーザーの認証を行うほかに、次の 2 つのセキュリティーサービスを提供します。

• 「整合性」 – 認証が、あるネットワーク上のクライアントが本人であるかどうかを確認するのと同様に、整合性は、クライアントの送信データが有効で、伝送の間に改ざんされていないことを確認します。整合性の確認は、データの暗号チェックサムによって行われます。整合性にはユーザー認証も含まれます。

• 「プライバシ」 – プライバシによって、セキュリティーがさらに向上します。プライバシは、伝送データの整合性を検証するだけでなく、伝送前にデータを暗号化して盗聴を防ぎます。プライバシにもユーザー認証が含まれます。

Kerberos 暗号化タイプ

暗号化タイプは、暗号処理が実行されるときに使用する暗号アルゴリズムとモードを特定します。サポートされている暗号化タイプのリストについては、krb5.conf(4) および kdb5_util(1M) のマニュアルページを参照してください。

クライアントが KDC にチケットを要求する場合、KDC はクライアントとサーバーで互換性のある暗号化タイプの鍵を使用する必要があります。Kerberos プロトコルでは、クライアントは KDC に、チケット応答のクライアントの部分に特定の暗号化タイプを使用するようリクエストできます。このプロトコルでは、サーバーが KDC に暗号化タイプを指定することは許可されません。

暗号化タイプを変更する前に、次の問題を考慮してください。

• KDC では、主体データベースのサーバー主体エントリに関連する最初の鍵/暗号化タイプはサーバーによってサポートされているものとします。

• KDC 上で、主体に対して生成される鍵が、その主体を認証するシステムと互換性があることを確認する必要があります。デフォルトで、kadmin コマンドは、サポートされるすべての暗号化タイプの鍵を生成します。主体を使用するシステムがこの暗号化タイプのデフォルトのセットをサポートしていない場合、主体の作成時に暗号化タイプを制限する必要があります。暗号化タイプを制限するために推奨される 2 つの方法として、kadmin addprinc で –e フラグを使用するか、または kdc.conf ファイル内の supported_enctypes パラメータをこのサブセットに設定します。supported_enctypes パラメータは、Kerberos レルム内のほとんどのシステムが暗号化タイプのデフォルトセットのサブセットをサポートしている場合に使用します。supported_enctypes を設定すると、kadmin addprinc が特定のレルムに対して主体を作成するときに使用する暗号化タイプのデフォルトセットが指定されます。

• システムがサポートする暗号化タイプを決定する場合は、システム上で実行されている Kerberos のバージョンと、サーバー主体が作成される対象のサーバーアプリケーションでサポートされている暗号化アルゴリズムの両方を考慮してください。たとえば、nfs/hostname サービス主体を作成する場合は、暗号化タイプをそのホスト上の NFS サーバーがサポートしているタイプに制限するようにしてください。

• kdc.conf ファイル内の master_key_enctype パラメータを使用すると、主体データベース内のエントリを暗号化するマスター鍵の暗号化タイプを制御できます。KDC 主体データベースが既に作成済みの場合は、このパラメータを使用しないでください。データベースの作成時に master_key_enctype パラメータを使用すると、マスター鍵のデフォルトの暗号化タイプを aes256-cts-hmac-sha1-96 から別の暗号化タイプに変更できます。スレーブ KDC を構成するときに、すべてのスレーブ KDC が選択された暗号化タイプをサポートしていること、およびそれぞれの kdc.conf ファイル内に同一の master_key_enctype エントリが存在することを確認してください。また、kdc.conf で supported_enctypes が設定されている場合は、master_key_enctype が supported_enctypes 内のいずれかの暗号化タイプに設定されていることも確認してください。これらの問題のいずれかが適切に処理されない場合、マスター KDC はスレーブ KDC と連携できない可能性があります。

• クライアント上では、krb5.conf ファイル内のパラメータを使用して、KDC に対する暗号化タイプのリクエストを制御できます。default_tkt_enctypes パラメータは、クライアントが KDC にチケット認可チケット (TGT) をリクエストするときに使用する暗号化タイプを指定します。TGT は、より効果的な方法でほかのサーバーチケットを取得するためにクライアントにより使用されます。default_tkt_enctypes を設定すると、クライアントが TGT を使用してサーバーチケットを要求する (TGS 要求と呼ばれる) ときに、クライアントと KDC 間の通信を保護するために使用される暗号化タイプを一部制御できます。default_tkt_enctypes で指定された暗号化タイプは、KDC 上に格納されている主体データベース内の主体鍵の暗号化タイプの少なくとも 1 つに一致している必要があることに注意してください。一致しない場合、TGT 要求は失敗します。default_tkt_enctypes は相互運用性の問題の原因になる場合があるため、ほとんどの状況ではこのパラメータを設定しないようにしてください。デフォルトでは、クライアントコードは、サポートされるすべての暗号化タイプと KDC に、KDC が主体データベースで検索した鍵に基づいて暗号化タイプを選択するようリクエストします。

• default_tgs_enctypes パラメータは、サーバーチケットを取得するために使用される TGS リクエストでクライアントがリクエストする暗号化タイプを制限します。このパラメータは、クライアントとサーバーが共有するセッション鍵を作成するときに KDC が使用する暗号化タイプも制限します。たとえば、セキュアな NFS の実行中にクライアントで 3DES 暗号化だけを使用する場合は、default_tgs_enctypes = des3-cbc-sha1 を設定するようにしてください。クライアント主体とサーバー主体の主体データベース内に des-3-cbc-sha1 鍵が存在することを確認してください。default_tkt_enctype と同様に、資格が KDC とサーバーの両方で正しく設定されていないと相互運用性の問題の原因になる場合があるため、ほとんどの状況ではこのパラメータを設定しないようにしてください。

• サーバー上では、kdc.conf ファイル内の permitted_enctypes パラメータを使用して、サーバーが受け入れる暗号化タイプを制御できます。さらに、サーバーが keytab エントリを作成するときに使用する暗号化タイプを指定できます。KDC は使用する鍵または暗号化タイプを決定するときにサーバーアプリケーションと通信しないため、これらの方法のいずれかを使用して暗号化タイプを制御することはできるだけ避け、代わりに、KDC に使用する暗号化タイプを決定させるようにしてください。