| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
Oracle Solaris 11 セキュリティーサービス開発ガイド Oracle Solaris 11 Information Library (日本語) |
| ナビゲーションリンクをスキップ | |
| 印刷ビューの終了 | |
|
|
Oracle Solaris 11 セキュリティーサービス開発ガイド Oracle Solaris 11 Information Library (日本語) |
1. Oracle Solaris の開発者向けセキュリティー機能 (概要)
3. PAM アプリケーションおよび PAM サービスの記述
8. Oracle Solaris 暗号化フレームワークの紹介
9. ユーザーレベルの暗号化アプリケーションとプロバイダの記述
証明書失効リスト
Certificate Signing Request
Generic Security Service Application Programming Interface の略。 さまざまなモジュール方式のセキュリティーサービスのサポートを提供するネットワーク層です。 GSS-API はセキュリティー認証、整合性、および機密性のサービスを提供します。さらに、セキュリティーに関連して、アプリケーションの移植性を最大限にすることを可能にします。 認証、機密性、および整合性の項も参照してください。
Oracle Solaris 鍵管理フレームワーク
メッセージ整合性コード (MIC)の項を参照してください。
機構名 (MN)の項を参照してください。
主体の名前。たとえば、user@machine などです。 GSS-API の名前は gss_name_t 構造体を通じて処理されます。このような名前はアプリケーションには不透明です。 エクスポート名、機構名 (MN)、名前型、およびprincipalの項も参照してください。
Online Certificate Status Protocol
データの値や形式がそれを使用する関数から見えない場合、そのデータに適用されます。 たとえば、gss_init_sec_context() への input_token パラメータはアプリケーションには不透明ですが、GSS-API にとっては重要です。 同様に、gss_wrap() への input_message パラメータは GSS-API には不透明ですが、ラップを行うアプリケーションにとっては重要です。
公開鍵の暗号化標準
Public Key Infrastructure
ネットワーク通信に参加する、一意の名前を持つクライアント/ユーザーまたはサーバー/サービスのインスタンス。GSS-API ベースのトランザクションでは主体間の対話が必要となります。
次に、主体名の例を示します。
user
user@machine
nfs@machine
123.45.678.9
ftp://ftp.company.com
Secure Sockets Layer
特定のアクセス権を持つ主体のリストが格納されているファイル。 通常、サーバーはアクセス制御リストを調べて、クライアントがサービスを使用するための権限を持っているかどうかを判断します。 GSS-API で認証されていても ACL で許可されていなければ、主体はサービスを拒否される可能性があることに注意してください。
実際のセキュリティー機構で許可されている場合、主体 (通常はコンテキスト起動側) は、自分の資格とピアとなる主体 (通常はコンテキスト受け入れ側) に「委託」することで、ピア主体をプロキシに指定できます。 「委託」された資格を使用すると、ピア主体はオリジナル主体の代わりに要求を行うことができます。たとえば、主体が rlogin を使用して、あるマシンから別のマシンにリモートログインする場合などです。
gss_export_name() によって GSS-API 内部形式から GSS-API エクスポート形式に変換された機構名。 エクスポート名は memcmp() で GSS-API 以外の文字列形式と比較できます。 機構名 (MN)とnameの項も参照してください。
PKI オブジェクト用の格納システム。 よく使用されるキーストアの例を次に示します。
OpenSSL はキーおよび証明書をディスク上のファイルに格納します (PEM、DER、または PKCS#12 形式)。
NSS は、オブジェクトを格納する非公開データベースです。 NSS は PKCS#11 トークンもサポートします。
PKCS#11 の格納は選択されたトークンに依存し、ローカルファイルは Oracle Solaris ソフトトークンを使用します。 たとえばスマートカードはハードウェアトークンを使用します。
GSS-API 内部形式名の特別なインスタンス。 通常の GSS-API 内部形式名では 1 つの名前に対して複数のインスタンス (それぞれが実際の機構の形式での) を持つことができます。 ただし、機構名は特定の機構に一意です。 機構名は gss_canonicalize_name() で生成されます。
データを暗号化するセキュリティーサービス。 機密性には整合性と認証のサービスも含まれます。 認証、整合性、サービスも参照してください。
狭義では、rlogin を使用するアプリケーションなど、ユーザーの代わりにネットワークサービスを使用するプロセスを指します。 サーバー自身が他のサーバーやサービスのクライアントになる場合もあります。 広義では、サービスを使用する主体を指します。
多くのセキュリティー機構では、メッセージストリーム中のメッセージが不適切な順序で受信されたことを検出できます。 メッセージの誤順序の検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。
システムサービスを使用するアプリケーション、ライブラリ、またはカーネルモジュール。
2 つのアプリケーション間の信用の状態。 2 つのピア間でコンテキストが正常に確立されると、コンテキスト受け入れ側はコンテキスト起動側が本当に主張しているとおりのアプリケーションであることを認識して、コンテキスト受け入れ側に送信されたメッセージを検証および復号化できます。 コンテキストに相互認証が含まれている場合、起動側は受け入れ側の ID が有効であると認識して、受け入れ側から送信されたメッセージを検証および復号化できます。
トークンの項を参照してください。
ネットワーククライアントにリソースを提供する主体。 たとえば、rlogin を使用して boston.eng.acme.com というマシンにログインすると、そのマシンは rlogin サービスを提供するサーバーになります。
1. (ネットワークサービスと同意)。ネットワーククライアントに提供されるリソース。複数のサーバーによって提供されることもあります。 たとえば、rlogin を使用して boston.eng.acme.com というマシンにログインすると、そのマシンは rlogin サービスを提供するサーバーになります。
2. 「セキュリティーサービス」は整合性または機密性のサービスであり、認証以上の保護レベルを提供します。 認証、整合性、および機密性の項も参照してください。
主体を識別する情報パッケージと主体の識別情報。 資格は、主体がだれであるか、そして多くの場合、主体がどのような特権を持っているかを示します。 資格はセキュリティー機構によって生成されます。
主体がサービスを使用できるかどうか、主体がどのオブジェクトにアクセスできるか、および、各オブジェクトにどのようなアクセスの種類が許可されているかを決定するプロセスです。
ユーザー認証に加えて、転送されたデータの有効性を暗号タグで証明するセキュリティーサービス。 認証、機密性、およびメッセージ整合性コード (MIC)の項も参照してください。
サービスを参照してください。
フレーバを参照してください。
メカニズムを参照してください。
コンテキストが確立されるとき、コンテキスト起動側は自分自身をコンテキスト受け入れ側に認証する必要があります。 場合によっては、コンテキスト起動側が受け入れ側の認証を要求することもあります。 受け入れ側が自己認証を行なった場合、両者は相互認証されていると言います。
データの形式。たとえば、int、string、gss_name_t 構造体、gss_OID_set 構造体などです。
メッセージストリーム中の単一のメッセージが複数回受信された場合。 多くのセキュリティー機構でデータリプレイの検出をサポートしています。 リプレイの検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。
GSS-API 構造体 gss_buffer_t の形式であるデータパケット。 トークンは、ピアとなるアプリケーションへの転送用に、GSS-API 関数で生成されます。
トークンには 2 種類あります。 コンテキストレベルトークンには、セキュリティーコンテキストを確立または管理するために使用される情報が格納されます。 たとえば、gss_init_sec_context() は、コンテキストの受け入れ側に送信するための、コンテキスト起動側の資格ハンドル、ターゲットマシンの名前、要求されるさまざまなサービスのフラグなどの項目をトークンに格納します。
メッセージトークン (メッセージ毎トークンやメッセージレベルトークンとも呼ぶ) には、ピアとなるアプリケーションに送信されるメッセージから GSS-API 関数によって生成された情報が格納されます。 たとえば、gss_get_mic() は、指定されたメッセージから識別用の暗号タグを生成し、ピアに送信されるトークンに (メッセージと一緒に) 格納します。 技術的には、トークンはメッセージとは別であると考えられています。このため、gss_wrap() は output_token ではなく output_message を生成すると言われます。
メッセージの項も参照してください。
名前の形式。 名前型は gss_OID 型として格納され、名前に使用されている形式を示します。 たとえば、名前 user@machine の名前型は、GSS_C_NT_HOSTBASED_SERVICE になります。 エクスポート名、機構名 (MN)、およびnameの項も参照してください。
要求された主体の ID を確認するセキュリティーサービス。
機密性の項を参照してください。
従来、フレーバは認証の種類 (AUTH_UNIX、AUTH_DES、AUTH_KERB など) を示していたため、セキュリティーフレーバと認証フレーバは同じ意味です。 RPCSEC_GSS もセキュリティーフレーバですが、これは認証に加えて、整合性と機密性のサービスも提供します。
サービスをコンシューマに提供するアプリケーション、ライブラリ、またはカーネルモジュール。
整合性や機密性のサービスと一緒に使用される暗号化アルゴリズムを選択するときに使用されるパラメータです。 整合性と一緒に使用する場合、QOP はメッセージ整合性コード (MIC) を生成するアルゴリズムを指定します。 機密性と一緒に使用する場合、QOP は MIC の生成とメッセージの暗号化の両方に対するアルゴリズムを指定します。
ネットワークを通じてアクセス可能なマシン。
データの認証や機密性を実現するための暗号化技術を指定するソフトウェアパッケージ。 たとえば、Kerberos v5 や Diffie-Hellman 公開鍵などです。
GSS-API ベースのアプリケーションからピアとなるアプリケーションに送信される gss_buffer_t オブジェクト形式のデータ。 たとえば、「ls」はリモートの ftp サーバーにメッセージとして送信されます。
メッセージには、ユーザーが提供するデータ以外の情報が格納されることもあります。 たとえば、gss_wrap() はラップされていないメッセージを受け取り、そのメッセージを送信用にラップします。 このとき、ラップされたメッセージには、オリジナル (ユーザーが提供した) メッセージとともにその MIC が格納されます。 メッセージを含まない、GSS-API が生成した情報は「トークン」と呼ばれます。 トークンの項を参照してください。
データの有効性を保証するために、転送されるデータに添付される暗号タグ。 データ受信側は別の MIC を生成し、送信された MIC と比較します。 両者が同じ場合、メッセージは有効です。 gss_get_mic() で生成される MIC などはアプリケーションからも見えますが、gss_wrap() や gss_init_sec_context() で生成される MIC などはアプリケーションからは見えません。
トークンの項を参照してください。
トークンの項を参照してください。
多くのセキュリティー機構は、メッセージストリーム中のメッセージが不正に繰り返されたことを検出できます。 メッセージリプレイの検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。
|