Generic Security Standard Application Programming Interface (GSS-API) は、ピアとなるアプリケーションに送信されるデータを保護する方法をアプリケーションに提供します。通常、ピアとなるアプリケーションとは、同じマシン上のクライアントから別のマシン上のサーバーまで、様々な可能性があります。名前が示すとおり、GSS-API を使用すると、プログラマはセキュリティの点で汎用的なアプリケーションを作成できます。つまり、特定のプラットフォーム、セキュリティ機構、保護の種類、または転送プロトコル向けに特定のセキュリティ実装を施す必要はありません。GSS-API を実装したアプリケーションはセキュリティを制御できます。しかし、GSS-API を使用するプログラマは、ネットワークデータを保護する方法についての詳細を知らなくてもプログラムの作成を行うことができます。したがって、GSS-API を使用するプログラムはネットワークセキュリティに関して移植性がより高くなります。この移植性が Generic Security Standard API の最も優れた特徴です。
GSS-API 自身はセキュリティサービスを実際に提供しません。GSS-API はセキュリティサービスを汎用的な方法で呼び出し側に提供するためのフレームワークであり、実際の機構やテクノロジなど (Kerberos v5 や公開鍵テクノロジなど) を幅広くサポートできます。図 1–1 を参照してください 。
GSS-API の主な機能は簡単に言うと次の 2 つです。
セキュリティコンテキストを作成し、アプリケーション間でデータを受け渡します。コンテキストとは、2 つのアプリケーション間における一種の「信用状態」であると考えられます。コンテキストを共有するアプリケーションは誰が相手であるかを知っており、したがって、そのコンテキストが継続する限り、アプリケーション間でデータを転送できます。
1 つまたは複数の種類の保護 (セキュリティサービス) を転送されるデータに適用します。セキュリティサービスについては、セキュリティサービスを参照してください。
もちろん、GSS-API は上記よりももっと複雑です。GSS-API の他の機能には、データ変換、エラー検査、ユーザー特権の委託、情報の表示、および ID の比較などがあります。GSS-API にはさまざまなサポート機能や便利な機能があります。
上記のとおり、GSS-API は複数の種類の移植性をアプリケーションに提供します。
機構非依存性。GSS-API は実装されている機構に対して、汎用的なインタフェースを提供します。デフォルトのセキュリティ機構を指定することによって、アプリケーションはどの機構 (たとえば Kerberos v5 など) を使用しているかや、どの種類の機構を利用しているかを知る必要がありません。たとえば、アプリケーションがユーザーの資格 (credential) をサーバーに転送するとき、その資格が Kerberos 形式であるか、他の機構の形式であるかを知る必要はありません。あるいは、その資格が機構によってどのように格納されるか、その資格がアプリケーションによってどのようにアクセスされるかを知る必要もありません。必要であれば、アプリケーションは使用する特定の機構を指定できます。
プロトコル非依存性。GSS-API は特定の通信プロトコルまたはプロトコル群に依存しません。GSS-API は、ソケット、RCP、TCP/IP などを使用するアプリケーションで使用できます。
RPCSEC_GSS は、GSS-API と RPC をスムースに統合するために追加される層です。詳細は、RPCSEC_GSS 層を参照してください。
プラットフォーム非依存性。GSS-API は、アプリケーションが動作しているオペレーティングシステムにまったく依存しません。
保護品質に対する非依存性。保護品質 (Quality of Protection: QOP) とは、データを暗号化したり、暗号タグを生成したりするときに使用されるアルゴリズムの種類を示します。GSS-API を使用し、GSS-API が提供するデフォルトを使用すると、プログラマは QOP を無視することができます。必要であれば、アプリケーションは QOP を指定することもできます。
GSS-API が提供する基本的なセキュリティは認証です。認証とは ID の検証のことです。あるユーザーが認証されるということは、そのユーザーが自分が宣言したユーザーとして認識されたことを意味します。
実際の機構がサポートする場合、GSS-API は認証以外にも次の 2 種類のセキュリティサービスを提供します。
整合性。データを送信しているアプリケーションが、本当に自ら主張しているとおりのアプリケーションであるかどうかを知るだけでは、必ずしも常に十分であるとは言えません。データ自身が破壊または破損している可能性もあります。GSS-API はメッセージ整合性コード (MIC) と呼ばれる暗号化タグをデータに添付することによって、ユーザーのところに到着したデータとアプリケーションが送信したデータが同じであることを証明します。このようにデータの有効性を検証することを整合性と呼びます。
機密性。認証と整合性はどちらもデータ自身をそのままにしておくため、誰かに横取りされたときは読まれてしまいます。したがって、実際の機構がサポートする場合、GSS-API はデータを暗号化できます。このようにデータを暗号化することを機密性と呼びます。
GSS-API の現在の実装では、Kerberos v5 セキュリティ機構だけに適用されます。この中には、Sun が変更して作成した Solaris Enterprise Authentication Mechanism (SEAM) も含まれます。詳細は、『Solaris のシステム管理 (第 2 巻)』の「SEAM の概要」を参照してください。したがって、GSS-API を使用するプログラムが動作しているシステムには、Kerberos v5 または SEAM がインストールされている必要があります。
RPC (Remote Procedure Call) プロトコルをネットワークアプリケーションに使用するプログラマは、RPCSEC_GSS を使用してセキュリティを提供できます。RPCSEC_GSS は GSS-API 上にある別の層であり、GSS-API のすべての機能を RPC 向けの方法で提供します。事実、RPCSEC_GSS は GSS-API の多くの側面をプログラマが意識する必要がないようにするため、特に、RPC セキュリティのアクセス性と移植性が向上します。RPCSEC_GSS についての詳細は、『ONC+ 開発ガイド』を参照してください。
GSS-API はデータの保護を簡単にしますが、汎用性という性質を最大限にするために、次のことは行いません。
セキュリティ資格をユーザーまたはアプリケーションに提供すること。セキュリティ資格は実際のセキュリティ機構が提供する必要があります。GSS-API では、アプリケーションが資格を自動的または明示的に獲得することを許可しています。
アプリケーション間でデータを転送すること。セキュリティ関連のデータまたは通常のデータのどちらの場合でも、アプリケーション間でデータの転送を処理するのはアプリケーションの責任です。
転送されたデータの種類を区別すること。たとえば、データパケットが通常のデータであり、GSS-API 関連のデータではないことを判断するなどです。
リモート (非同期) エラーによる状態を示すこと。
マルチプロセスプログラムのプロセス間で送信される情報を自動的に保護すること。
GSS-API 関数に渡される文字列バッファを割り当てること。文字列および類似のデータを参照してください。
GSS-API データ領域を解放すること。GSS-API データ領域の解放は、gss_release_buffer() や gss_delete_name() などの関数で明示的に行う必要があります。
このマニュアルでは現在、GSS-API の C 言語バインディング (関数とデータ型) だけをカバーしています。将来的には、GSS-API の Java バインディングも使用できるようになる予定です。
GSS-API については、次の 2 つのマニュアルでも説明されています。この 2 つの文書はアプリケーション開発者向けというよりも GSS-API 実装者向けです。『Generic Security Service Application Program Interface』 (ftp://ftp.isi.edu/in-notes/rfc2743.txt) は、GSS-API の概念的な概要を示し、『Generic Security Service API Version 2: C-Bindings』 (ftp://ftp.isi.edu/in-notes/rfc2744.txt) は C 言語ベースの GSS-API の特徴について説明します。