認証

Kerberos 認証

Caché で強力な認証が必要な場合は、Kerberos プロトコルを使用することで、ユーザと Caché 自身との間でお互いを識別し、セッション内で有効な接続を確立できます。 Kerberos の簡単な説明は、このドキュメントの “はじめに” の章にある “Kerberos について” のセクションを参照してください。Kerberos の詳細は、“Kerberos に関する MIT の Web サイトOpens in a new tab” および “Kerberos に関する入手可能な資料のリストOpens in a new tab” を参照してください。

Kerberos モデルには、いくつかのアクターがあります。Kerberos で認証されるさまざまなプログラムと人物を総称して、プリンシパルといいます。Kerberos のシステムは、Kerberos Key Distribution Center (KDC) で管理されます。Windows では、Windows ドメイン・コントローラが KDC の役目を果たしています。KDC は、ユーザがプログラムと対話できるようにユーザにチケットを発行します。これらのプログラムそのものは、サービス・プリンシパルで表現されます。ユーザが認証され、サービス・チケットを受け取ると、そのユーザはプログラムを使用できるようになります。

具体的には、Kerberos 認証は 3 つの独立したトランザクションで構成されます。

1. クライアントは “TGT” (“チケット保証チケット”) と暗号化セッション・キーを受け取ります。

2. クライアントは TGT とセッション・キーを使用して、Caché のサービス・チケットと別の暗号化セッション・キーの両方を取得します。

3. クライアントはサービス・チケットと 2 番目のセッション・キーを使用して、Caché への認証を行い、必要に応じて保護された接続を確立します。

該当する場合に表示される最初のパスワードのプロンプトを除き、この処理はユーザには表示されないようになっています。

強力な認証を意味あるものとするために、そのような認証をサポートしているすべての Caché サービスでは Kerberos を有効にし、そのような認証をサポートしていない Cach サービスはすべて無効にする必要があります。この要求に対する例外は、Caché の安全な境界内で動作することを意図したサービス (ECP など) で、これらは Kerberos をサポートしていません。これらのサービスは、外部に対して安全が確保されている環境で使用するように設計されているので、有効化と無効化のみを設定できます。

オペレーティング・システム・ベースの認証

オペレーティング・システム・ベースの認証では、オペレーティング・システムのユーザ ID を使用して、Caché を使用するユーザを識別します。具体的には以下の処理が実行されます。

1. Caché は、目的のプロセスに対する、オペレーティング・システムのユーザ識別情報を入手します。

2. オペレーティング・システムから得られた識別情報が、Caché のユーザ名と一致するかどうかがチェックされます。両者が一致すれば、ユーザは自動的に Caché についても認証されます。

Caché 認証

Caché は、パスワード・ベースの認証を実現する独自のアルゴリズムを備えています。このメカニズムは、管理ポータルに “[パスワード]” 認証として表示されます。通常、Kerberos 認証と OS ベースの認証はどちらもパスワードを使用するため、このドキュメントでは、ネイティブな Caché メカニズムを Caché ログインと呼びます。

パスワードによる認証では、Caché に各ユーザ・アカウントのパスワード値が保持されていて、ユーザがログインするたびに、その値とユーザが入力したパスワードが比較されます (Caché に実際に格納されているのはパスワードの値そのものではなく、それをハッシュ化した値です。 ユーザがログインすると、入力されたパスワードがハッシュ化され、これら 2 つのハッシュ値が比較されます)。 システム・マネージャは、パスワードの最小長などの一定のパスワード基準を設定することで、ユーザが選択するパスワードに一定の度合いの堅牢性を確保できます。この基準については、“システム管理およびセキュリティ” の章の “パスワードの強固さとパスワードのポリシー” のセクションで説明しています。

Caché パスワードの回復不可能な暗号化ハッシュのみを格納します。ハッシュは、Public Key Cryptography Standard #5 v2.1 “Password-Based Cryptography Standard” の定義に従って、HMAC-SHA-1 擬似ランダム関数と PBKDF2 アルゴリズムを使用して計算されます。 現在の実装では 1024 回の反復、64 ビットのソルトを使用して、20 バイトのハッシュ値を生成します。 これらのハッシュ値から元のパスワードを回復するための既知のテクニックはありません。

LDAP 認証

Caché では、LDAP (Lightweight Directory Access Protocol) に基づく認証をサポートしています。LDAP 認証を使用すると、Caché は、ユーザ情報を中央の LDAP リポジトリから取得します。環境が LDAP 認証を既にサポートしている場合があるため (Windows Active Directory を使用している環境など)、Caché のインスタンスはその認証に LDAP を使用でき、このより大きなインフラストラクチャに適合するだけの場合があります。LDAP 認証の詳細は、“LDAP 認証の使用法” の章を参照してください。

代行認証

Caché は、“代行認証” というものによるカスタム認証メカニズムの使用をサポートしています。代行認証は、Caché のインスタンスの %SYS ネームスペースに ZAUTHENTICATE ルーチンがある場合に行われます。このようなルーチンが存在する場合、Caché はこれを使用して、新規コードと既存のコードのいずれかを呼び出してユーザを認証します。代行認証の詳細は、“代行認証の使用法” の章を参照してください。

非認証のアクセス

任意の Caché サービスを、認証メカニズムなしで動作するように構成することもできます。これを、非認証のアクセスといいます。通常、非認証のアクセスを許可するように Caché サービスを構成する場合は、非認証のアクセスのみを使用することをお勧めします。認証メカニズムと、認証失敗時に適用する非認証アクセスの両方をサポートする場合、このような状況をカスケード認証といいます。詳細は “カスケード認証” を参照してください。また、複数の認証メカニズムを使用する状況の詳細は、“複数の認証メカニズムの使用” を参照してください。

ローカル・アクセスについて

ローカル・アクセスでは、Caché サーバと同じマシン上にエンド・ユーザが存在します。ユーザがデータにアクセスするには、共有メモリとの間で読み取りと書き込みを実行する Caché のプライベート・イメージを実行します。複数のローカル・ユーザが存在する場合、それぞれのユーザは Caché の実行可能プログラムの個人用コピーを使用し、これらすべての実行可能プログラムは同じ共有メモリを参照します。ユーザと実行可能プログラムが同じマシン上に存在することから、両者の間の通信を保護したり、暗号化したりする必要がありません。これは、この実行可能プログラムと他の実行可能プログラムとの間で情報が受け渡されることがないからです。ユーザと Caché との間の通信が単独のプロセスの範囲で処理されるので、この認証をプロセス内認証ともいいます。

ローカル・アクセスは以下の場合に利用できます。

• ターミナル — ターミナルは、Windows では %Service_Console サービスを使用し、Windows 以外のオペレーティング・システムでは %Service_Terminal サービスを使用します。

• コールイン — コールインでは、%Service_CallIn サービスが使用されます。

クライアント・サーバ・アクセスについて

クライアント・サーバ・アクセスでは、Caché の実行可能プログラムはサーバであり、そのサーバから独立したマシンに、クライアント側の実行可能プログラムを置くことができます。Caché は、多くの場合はネットワーク経由でこのクライアントとの接続を受け入れます。この接続では、Caché でサポートされているものであれば、どのような言語またはプロトコルも使用できます。これには、以下のものがあります。

• ActiveX — %Service_Bindings を使用

• C++ — %Service_Bindings を使用

• Caché Direct — %Service_CacheDirect を使用

• ComPort — %Service_ComPort を使用

• Java — %Service_Bindings を使用

• JDBC — %Service_Bindings を使用

• ODBC — %Service_Bindings を使用

• Perl — %Service_Bindings を使用

• Python — %Service_Bindings を使用

• Telnet — %Service_Telnet を使用

Caché ログインを介した認証のみをサポートする %Service_ComPort を除くすべての接続ツールは、Kerberos または Caché ログインを介した認証をサポートします。

どの場合でも、サポートされる認証タイプはサーバで指定されています。クライアントがサーバに対するアクセスを開始するときは、これらのサポートされている認証タイプのいずれかを使用する必要があります。他のタイプを使用すると、接続が拒否されます。接続ツールによっては、一部の認証タイプを使用できないことがあります。

Web アクセスについて

Web アクセス・モードでは、以下の形式の接続がサポートされています。

1. Web ブラウザで、ユーザがコンテンツまたはアクションを要求します。

2. ユーザの要求が Web ブラウザから Web サーバに渡されます。

3. CSP ゲートウェイが Web サーバと同じ場所に置かれていて、ユーザの要求が CSP ゲートウェイに渡されます。

4. ユーザの要求がゲートウェイから Caché サーバに渡されます。

ユーザに関連したコンテンツが Caché サーバから提供されたとき、またはユーザに関連したアクションが Caché サーバで実行されたとき、上記と逆方向で同じプロセスが発生します。

Caché に認証されるユーザにとって、ユーザ名とパスワードは完全な形で渡される必要があります。このことから、このアクセス・モードはプロキシ・モードまたはプロキシ接続とも呼ばれます。Caché を実行しているマシンに情報が到達すれば、ユーザとサーバとの関係はローカル・アクセス・モードの場合と似たものになります。実際、Web アクセス・モードでは、プロセス内認証も使用されます。

Kerberos およびアクセス・モードについて

接続ツールごとに、サービスを使用して Caché との接続が設定されます。特定のアクセス・モードも使用されます。最大限の保護を実現するには、使用している接続ツールに基づいて、必要なサービスを決定します。使用しないサービスがあれば無効にします。

以下は、接続ツールおよびそのアクセス・モードとサービスのリストです。

Web

Web アプリケーションの実行 (CSP または Zen を使用) では、ユーザと Caché サーバとの間に直接の対話は発生しません。監視からすべての情報を保護するには、ユーザと Caché 間の接続を以下のように暗号化する必要があります。

• SSL によりブラウザと Web サーバとの接続を保護するよう Web サーバを構成します。

• Web サーバと CSP ゲートウェイは同じ場所に置かれるため、両者間の接続を保護する必要はありません。

• Kerberos 認証と暗号化を使用するように CSP ゲートウェイを構成します。このような接続を確立するには、ゲートウェイの Kerberos プリンシパルを使用します。

これは CSP と Zen の両方に適用されます。Zen では基礎となる接続に CSP を使用するからです。

この場合のアーキテクチャは以下のとおりです。

Kerberos で保護された Web 接続のアーキテクチャ

エンド・ユーザと Caché 間の通信は、すべて SSL で暗号化されたパイプまたは Kerberos で暗号化されたパイプを通じて行われます。Kerberos で保護された接続の場合、この通信にはエンド・ユーザの Kerberos 認証が含まれます。

エンド・ユーザにパスワードを要求するプロンプトを Caché サーバから表示することはできないので、プロンプトを表示する HTML コンテンツをブラウザに送信する API が呼び出されます。送信されたフォームにユーザが所要の情報を入力すると、その情報は Web サーバに返送されます。この情報は、Web サーバから CSP ゲートウェイに渡され、さらにそこから Caché そのものを構成する CSP サーバに渡されます。CSP サーバは、ブラウザを使用しているユーザのためにプロキシとして機能します。この種類の接続がプロキシ接続と呼ばれるのはこのためです。同時に、ローカル・アクセス・モード同様、ユーザに関連するすべての情報はサーバ・マシンに存在します。したがって、Web 接続は、プロセス内認証の 1 つの形式ともいえます。

接続のセキュリティ・レベルの指定

Caché とのクライアント・サーバ接続では、以下のいずれかのサービスが使用されます。

• %Service_Bindings — ActiveX、C++、Java、JDBC、ODBC、Perl、Python

• %Service_CacheDirect — Caché Direct

• %Service_Telnet — Telnet

これらのサービスのいずれかを使用している Kerberos 接続では、その接続をサーバが受け入れるためのセキュリティ・レベルを指定する必要があります。目的のサービスでサポートされる接続のセキュリティ・レベルを構成するには、以下の手順に従います。

1. [認証/CSPセッションオプション] ページ ([システム管理] > [セキュリティ] > [システム・セキュリティ] > [認証/CSPセッションオプション]) で、Caché インスタンス全体に対して有効にする接続セキュリティ・レベルを指定します。以下のレベルにできます。

   • [Kerberos] — 最初の認証のみ

   • [Kerberos パケット整合性] — 最初の認証およびパケットの整合性

   • [Kerberos 暗号化] — 最初の認証、パケットの整合性、およびすべてのメッセージの暗号化

   [認証オプション] ページの詳細は、“システム管理およびセキュリティ” の章の “認証オプション” を参照してください。

2. [サービス] ページ ([システム管理] > [セキュリティ] > [サービス]) の [名前] 列でサービス名をクリックすると、そのサービスの [サービス編集] ページが表示されます。

3. [サービス編集] ページで、Kerberos 接続の一部として要求する接続のセキュリティ・レベルを指定します。レベルを選択したら、[保存] をクリックします。

サーバに指定されているセキュリティ・レベルより低いレベルのセキュリティを使用して、クライアントがそのサーバに接続しようとしても、その接続は受け入れられません。サーバに指定されているセキュリティ・レベルより高いレベルのセキュリティを使用してクライアントがそのサーバに接続しようとすると、そのサーバ接続では、サーバに指定されたレベルのセキュリティを使用して認証が試行されます。

クライアントの設定

クライアント・サーバ・アクセス・モードを使用する場合は、クライアントを構成する必要があります。このプロセスの詳細は、使用している接続テクノロジによって異なります。

ユーザの資格情報の入手

すべてのアクセス・モードについて、アプリケーションでユーザの資格情報を入手する方法を指定する必要があります。この方法には、既存の資格情報キャッシュから得る方法と、ユーザにユーザ名とパスワードを要求して得る方法があります。

クライアント・サーバ・アクセス・モード用の資格情報の入手

クライアント・サーバ・アクセス・モードでは、クライアント・アプリケーションをホストしているマシンにユーザの資格情報が存在します。この場合は、クライアントが以下のいずれの接続方法を使用しているかによって、資格情報の入手方法を指定する形式が異なります。

• ActiveX、Caché Direct、C++、ODBC、Perl、Python、および Telnet

• Java および JDBC

ActiveX、Caché Direct、C++、ODBC、Perl、Python、および Telnet

これらの接続ツールで使用される基盤の Caché コードでは、エンド・ユーザが既に資格情報を持っていることが前提となっています。したがって、プロンプトの表示は不要です。

Windows では、ドメインにログオンしているすべてのユーザごとに資格情報キャッシュがあります。

Windows 以外のオペレーティング・システムでは、そのユーザに対してオペレーティング・システムで Kerberos 認証を実行済みである場合、またはユーザが明示的に kinit を実行済みである場合に、そのユーザの資格情報キャッシュが存在します。 それ以外の場合は、キャッシュにユーザの資格情報が存在しないので、接続ツールは認証に失敗します。

Note:

オペレーティング・システムによっては、一部の接続ツールが使用できないことがあります。

Java および JDBC

Java および JDBC を使用する際には、2 つの異なる Java 実装 (SUN による実装と IBM による実装) があります。2 つの実装に共通する動作もあれば、互いに異なる動作もあります。

どちらの実装でも、java.util.Properties クラスのインスタンスのプロパティに接続情報が格納されます。以下のプロパティがあります。

• user — Caché サーバに接続しているユーザの名前。この値は特定の接続動作に対してのみ設定されます。

• password — そのユーザのパスワード。この値は特定の接続動作に対してのみ設定されます。

• service principal name — Cachéサーバの Kerberos プリンシパル名。この値はすべての接続動作に対して設定されます。

• connection security level — この接続に対して Kerberos が提供する保護のタイプ。1 は認証のみに Kerberos を使用すること、2 は認証およびクライアントとサーバ間で受け渡されるすべてのパケットの整合性の確保に Kerberos を使用すること、3 は認証、パケットの整合性、およびすべてのメッセージの暗号化に Kerberos を使用することをそれぞれ指定します。この値はすべての接続動作に対して設定されます。

以下の説明では、java.util.Properties クラスのインスタンスを connection_properties オブジェクトとして指定しています。各プロパティの値は、次のような connection_properties.put メソッドの呼び出しによって設定されます。

 String principalName = "MyCacheServer";
 connection_properties.put("service principal name",principalName);

どちらの実装でも、資格情報に関連する動作は isclogin.conf ファイル内の特定のパラメータの値で決まります (このファイルの詳細は、“Kerberos で使用する Java クライアントまたは JDBC クライアントの設定” を参照)。

2 つの Java 実装の動作には、次の 2 つの相違点があります。

• 資格情報に関連する動作を指定するために isclogin.conf ファイルに設定されるパラメータの名前が実装間で異なります。

  • IBM では、パラメータ名は useDefaultCcache です。

  • Sun では、パラメータ名は useTicketCache です。

• 使用できる動作が実装間で異なります。これらは以下のセクションで説明しています。

IBM の実装を使用しているクライアントに対する動作の指定

オプションは以下のとおりです。

• 資格情報のキャッシュを使用するには、useDefaultCcache パラメータの値を True に設定し、user プロパティと password プロパティには値を設定しません。資格情報キャッシュが使用できない場合は、例外が発生します。

• プログラムによる処理で渡されるユーザ名とパスワードを使用するには、useDefaultCcache パラメータの値を False に設定し、user プロパティと password プロパティに該当の値を設定します。

• ユーザにユーザ名とパスワードを要求するには、useDefaultCcache パラメータの値を False に設定し、user プロパティと password プロパティには値を設定しません。これらのプロパティに値を設定しないことにより、Caché に付属するライブラリのクラスを使用して、ユーザ名とパスワードを要求するプロンプトを生成できます。

Sun の実装を使用しているクライアントに対する動作の指定

オプションは以下のとおりです。

• プログラムによる処理で渡されるユーザ名とパスワードを排他的に使用するには、useTicketCache パラメータの値を False に設定し、user プロパティと password プロパティに該当の値を設定します。

• ユーザにユーザ名とパスワードを排他的に要求するには、useTicketCache パラメータの値を False に設定し、user プロパティと password プロパティには値を設定しません。これらのプロパティに値を設定しないことにより、Caché に付属するライブラリのクラスを使用して、ユーザ名とパスワードを要求するプロンプトを生成できます。

• 資格情報キャッシュを排他的に使用するには、useTicketCache パラメータの値を True に設定します。余分なアクションが発生しないようにするには、user プロパティと password プロパティに、存在しない値を設定します。これによってプロンプトが表示されなくなり、このプロパティの値に基づいて認証しようとしても必ず失敗するようになります。

• 資格情報キャッシュの使用を試し、それが使用できなかった場合にプログラムによる処理で渡されるユーザ名とパスワードを使用するには、useTicketCache パラメータの値を True に設定し、user プロパティと password プロパティに該当の値を設定します。資格情報キャッシュが存在しない場合は、これらのプロパティの値が使用されます。

• 資格情報キャッシュを試し、それが使用できなかった場合にユーザ名とパスワードを要求するには、useTicketCache パラメータを True に設定し、user プロパティと password プロパティには値を設定しません。資格情報キャッシュが存在しない場合は、Caché に付属するライブラリのクラスを使用して、ユーザ名とパスワードを要求するプロンプトを生成できます。

Web 接続で使用するセキュア・チャンネルの設定

Web 接続に最大限の保護を実現するには、2 つの重要な通信経路であるブラウザと Web サーバの間および CSP ゲートウェイと Caché の間でセキュア・チャンネルを使用することをお勧めします。これにより、Kerberos のユーザ名とパスワードなどのあらゆる情報が、複数のポイント間で伝送されるときに保護されます。以下の各通信チャネルを保護するには、以下の手順に従います。

• Web ブラウザと Web サーバの間

• CSP ゲートウェイと Caché の間

%Service_Console に関するメモ

コンソール (%Service_Console) は Windows ベースのサービスであり、Windows ドメインのログインでは Kerberos を使用することが普通なので、コンソールの OS ベース認証でローカル・ログインに対する認証が得られます。

%Service_Callin に関するメモ

コールイン (%Service_Callin) では、OS レベルのプロンプトからのみ OS ベース認証を使用できます。プログラム処理でコールインを使用する場合は、OS ベース認証がサポートされていません。この場合は、認証されていないアクセスのみが可能です。

Web

Web アクセスでは、必要に応じて、Caché ログインを通じ、CSP ゲートウェイでゲートウェイ自身を Caché サーバに認証するように要求できます。この構成を実行するには、以下の手順に従います。

1. 管理ポータルのホーム・ページで、[ウェブゲートウェイ管理] ページ ([システム管理] > [構成] > [CSP ゲートウェイ管理]) に移動します。

2. [ウェブゲートウェイ管理] ページでは、左側に選択項目のセットが表示されています。[構成] の下にある [サーバ接続] をクリックします。[サーバ接続] ページが表示されます。

3. [サーバ接続] ページでは、新規の構成の追加、または既存の構成の編集が可能です。新規の構成を追加するには、[サーバ追加] ボタンをクリックします。既存の構成を編集するには、左側のリストから目的の構成を選択し、[サーバ編集] ラジオ・ボタンを選択して [実行] をクリックします。サーバ接続パラメータを編集または構成するためのページが表示されます。ヘルプ画面に説明がある一般的なパラメータに加え、このページでは、ゲートウェイのセキュリティに関するパラメータを指定できます。Caché ログイン接続の場合は、以下のパラメータがあります。

   • [接続セキュリティレベル] — [パスワード] をドロップダウン・リストから選択して Caché ログインを使用します。

   • [ユーザ名] — ゲートウェイ・サービスが実行されるユーザ名 (インストール・プロセスでは、この目的のために CSPSystem ユーザが作成されます)。このユーザ (CSPSystem またはその他のユーザ) には、有効期限を設定する必要はありません。つまり、Expiration Date プロパティの値は 0 になります。

   • [パスワード] — 上で入力したユーザ・アカウントに関連付けられたパスワード。

   • [プロダクト] — 使用している製品に応じて [Caché] または [アンサンブル] を指定します。

   • [サービスプリンシパル名] — これには値を指定しないでください(このフィールドは、Kerberos で使用するためにゲートウェイを構成するときに使用します)。

   • [キーテーブル] — これには値を指定しないでください(このフィールドは、Kerberos で使用するためにゲートウェイを構成するときに使用します)。

   これらの値をすべて入力した後、[設定を保存] ボタンをクリックすると、入力した値が保存されます。

ゲートウェイに対する認証要件と、そのゲートウェイを使用するアプリケーションに対する認証要件との間に直接の関係はない点に注意する必要があります。例えば、Kerberos 認証を使用するようにゲートウェイを構成していても、Web アプリケーションに対する認証メカニズムとして Caché ログインを要求できます。ゲートウェイに対して認証方法をまったく構成していなくても同様です。実際、ゲートウェイそのものに対して特定の認証メカニズムを選択しても、Web アプリケーションに対して技術的な要件は発生しません。逆に Web アプリケーションに対する認証メカニズムを選択しても、ゲートウェイに対する要件は発生しません。同時に、CSP では他の場合に比べ、ペア化が発生する可能性が高くなります。Web アプリケーションで Kerberos 認証を使用している場合、ゲートウェイに対して他の形式の認証を使用すると、暗号化されていないチャンネルを通じて Kerberos 認証の情報が流れることになります。その結果、Kerberos 認証の効果が低下する可能性があります。

Caché ログインを使用している Web アプリケーションでは、エンド・ユーザのユーザ名とパスワードはブラウザから Web サーバに渡され、次にその Web サーバと同じ場所にある CSP ゲートウェイに渡されます。このゲートウェイは Caché サーバとの独自の接続を備えているので、ユーザ名とパスワードはその Caché サーバに渡されます。ゲートウェイと Caché サーバとの接続を確立するために、このゲートウェイでは CSPSystem アカウントが使用されます。このアカウントは、Caché の事前定義アカウントの 1 つです。

既定では、これらのトランザクションはどれも暗号化されていません。SSL を使用すれば、ブラウザから Web サーバに送信されるメッセージを暗号化できます。Kerberos を使用すると、“CSP 接続で使用するセキュア・チャネルの設定” のセクションで説明したように、ゲートウェイから Caché サーバに送信されるメッセージを暗号化できます。Kerberos を使用していない場合は、ゲートウェイと Caché サーバのホスト・マシン間の接続を物理的に保護することをお勧めします。例えば、両方のマシンをロックされた同じ領域に置いて、両者間で直接的な物理接続を確立することにより、接続を保護できます。

ODBC

Caché では、サポート対象のすべてのプラットフォーム間で ODBC 接続に対する Caché ログインがサポートされています。この場合は、クライアント側の構成が必要です。クライアントの動作を構成する手順は、以下のようにプラットフォームによって異なります。

• Windows 以外のプラットフォームでは、Caché の ODBC 初期化ファイルを使用して、接続情報を提供する名前の値の対を指定します。このファイルについては、"Caché ODBC の使用法" で概要を説明しています。このファイルには、Caché ログインに関連する以下の変数があります。

  • Authentication Method — ODBC クライアントを DSN に認証する方法を指定します。0 は Caché ログイン、1 は Kerberos を指定します。

  • UID — DSN への接続に使用する既定のユーザ・アカウントの名前を指定します。実行時には、アプリケーションの動作に応じて、エンド・ユーザはこの値を別のユーザ・アカウントに置き換えることができます。

  • Password — 既定のユーザ・アカウントに関連付けられたパスワードを指定します。エンド・ユーザによる UID 値の変更が許可されている場合は、新しく指定されたユーザのパスワードがアプリケーションで受け入れられます。

• Windows クライアントに対する接続情報は、GUI を使用した指定、またはプログラムによる指定のいずれかが可能です。

  • GUI では、ODBC DSN を構成するダイアログを使用します。[システム DSN] タブにオプションが表示されます。この画面には、それぞれのフィールドを説明するヘルプがあります。Windows の [スタート] メニューからの操作でこの画面を表示する方法は、Windows のバージョンによって異なりますが、多くの場合は [コントロール パネル] の [管理ツール] で [データ・ソース (ODBC)] の画面に表示されます。

  • プログラムで指定する場合は、名前と値の組み合わせのセットを受け取る SQLDriverConnect 関数が使用できます。SQLDriverConnect は ODBC API を構成する C 呼び出しで、その説明は Microsoft の Web サイトOpens in a new tabで入手できます。この名前と値の組み合わせは、パスワードが PWD キーワードで識別される点を除けば、Windows 以外のプラットフォームで使用できる初期化ファイルにあるものと同じです。

Telnet および Caché Direct

Caché Direct および Windows 用の Caché Telnet サーバを使用して接続を確立すると、クライアントでは、Caché リモート・サーバの一部として格納されている構成情報が使用されます。リモート・サーバを構成するには、クライアント・マシンに移動します。そのマシンで以下の手順を実行します。

1. Caché キューブをクリックし、メニューから [優先接続サーバ] を選択します ([優先接続サーバ] の選択対象には、現在の優先サーバの名前も表示されています)。

2. 表示されたサブメニューから、[追加/編集] を選択します。

3. リモート・サーバを新規に作成するには、[追加] ボタンをクリックします。既存のサーバを構成するには、接続先の Caché サーバを選択し、[編集] ボタンをクリックします。

4. [接続を追加] ダイアログが表示されます。このダイアログの [認証方法] 領域で、Caché ログインを指定する [パスワード] をクリックします。

5. 既存のサーバの値を編集する場合は、このダイアログにある一般的な内容のフィールドで値を変更したり、追加したりする必要はありません。これらの値は、編集するサーバを選択することで自動的に決まります。

   サーバを新規に追加する場合に値の入力が必要なフィールドについては、“Caché システム管理ガイド” の “リモート・サーバへの接続” の章にある “リモート・サーバ接続の定義” に説明があります。

6. [OK] をクリックすると、指定した値が保存され、ダイアログが閉じます。

2 要素認証の設定の概要

2 要素認証の設定の主な手順は以下のとおりです。

1. インスタンス全体に対する 2 要素認証の有効化および構成を行います。インスタンスを構成して SMS テキスト認証、TOTP 認証、またはその両方を使用できます。TOTP 認証の詳細は、“2 要素の TOTP の概要” のセクションを参照してください。

2. SMS テキスト認証の場合、必要に応じて携帯電話サービス・プロバイダの構成を行います。これには以下が含まれます。

   • ある携帯電話サービス・プロバイダが必要であるのに、既定のプロバイダのリストに含まれていない場合、このサービス・プロバイダを追加する。

   • 既存のプロバイダに対し、必要に応じて構成情報を変更する (既定または追加)。

3. 以下のサービスを適切に構成します。

   • %Service_Bindings — サービスに対して 2 要素認証を有効化し、次の手順に進みます。

   • %Service_Console および %Service_Terminal — 単にサービスに対して 2 要素認証を有効化します。必要な手順はこれですべてです。

   • %Service_CSP — %Service_CSP の 2 要素認証の有効化を中央で行う方法はありません。次の手順に進みます。

   各サービスに対していずれかまたは両方の認証のタイプを有効にできます。サービスの詳細は、“サービス” の章を参照してください。

4. クライアント/サーバ・アプリケーションおよび Web アプリケーションを適切に構成します。

   1. クライアント/サーバ・アプリケーション (%Service_Bindings を使用するアプリケーション) の場合、2 要素認証をサポートするクライアント・アプリケーションに適切な呼び出しを追加します。これは、使用中のクライアント側のコンポーネント (ODBC、JDBC、C++、Java、.NET、Python、Perl など) に応じて異なるプログラミング・タスクです。

      Important:

      2 要素認証は、人のエンドユーザからの応答をリアルタイムで受け取るように設計されています。1 つのセッションが実際には複数の連続セッションから構成されているとエンドユーザがみなしている場合、2 番目の要素を繰り返し要求することは、予期しない困難なユーザ・エクスペリエンスをもたらすことになる場合があります。クライアント/サーバ・アプリケーションでは、基礎プロトコルによって、クライアントが接続の確立、切断、再確立を繰り返し強いられることがよくあります。この種のアプリケーションでは、このような作業のために、2 要素認証の使用は不適切になります。

   2. Web アプリケーション (%Service_CSP を使用するアプリケーション) では、2 要素認証をサポートするよう、各アプリケーションを構成します。

   Note:

   Windows では %Service_Console サービスを使用し、他のオペレーティング･システムでは %Service_Terminal サービスを使用する Caché ターミナルの場合、サーバ側の設定の他に必要な構成はありません。Caché は、これらのシステムにおいてプロンプトを制御するため、2 要素認証プロンプトを使用して (認証メカニズムに関係なく) 標準プロンプトに従い、エンドユーザ入力をこれに応じて処理するだけです。

5. 代行認証を使用する場合は、必要に応じて ZAUTHENTICATE.mac ルーチンを変更します。詳細は “代行認証の使用法” を参照してください。

6. 各エンドユーザを構成し、SMS テキスト認証または TOTP 認証を有効にします。エンドユーザは、両方のメカニズムを使用するように構成できますが、同時に両方のメカニズムを有効にすることはできません。

2 要素の TOTP の概要

タイムベース・ワンタイム・パスワード (TOTP) 認証を使用した 2 要素認証は以下のように動作します。

1. 要件として、各エンドユーザは、このようなパスワードを生成する認証デバイスまたはアプリケーションのいずれかを持っている必要があります。例えば、エンドユーザは、携帯電話の以下のアプリケーションのいずれかを使用できます。

   • Google AuthenticatorOpens in a new tab (Android、BlackBerry、または iPhone 用)

   • Duo MobileOpens in a new tab (Android または iPhone 用)

   • Amazon AWS MFAOpens in a new tab (Android 用)

   • AuthenticatorOpens in a new tab (Windows Phone 7 用)

2. 2 要素の TOTP 認証向けにエンドユーザを構成すると、システムは秘密鍵を生成します。この鍵は、ベース 32 でエンコードされてランダム化されたビット文字列として表示されます。Caché およびエンドユーザはこの秘密鍵を共有します (これが共有秘密と呼ばれる理由です)。Caché とエンドユーザの両方の認証デバイスまたはアプリケーションはこの秘密鍵を使用して、検証コードとして作用する TOTP 自体を生成します。[検証コード] フィールドまたはプロンプトにエンドユーザが入力する TOTP は 6 桁の文字列で、定期的 (既定では 30 秒毎) に新しいものが生成されます。

3. ログイン時、エンドユーザが Caché にパスワードを入力した後、Caché は追加で TOTP の入力を求めます。エンドユーザが TOTP を入力すると、ログイン・プロセスが完了します。

エンドユーザは、以下のいくつかの方法で Caché から秘密鍵を取得できます。

• 2 要素の TOTP 認証をサポートするようにエンドユーザのアカウントを構成するとき、エンドユーザの [ユーザ編集] ページにエンドユーザの秘密鍵が発行者の名前およびエンドユーザのアカウント名と共に表示されます。上記の情報をすべて含む QR コードも表示されます (QR コードは下の写真のようなマシンが読むことができるコードです)。ここでエンドユーザは、コードをスキャンするか情報を手入力することによって、情報を認証デバイスまたはアプリケーションに入力できます。

• Web アプリケーションまたはターミナル・セッションにログインするとき (%Service_Console または %Service_Terminal を使用) エンドユーザに秘密鍵を表示することを選択する場合、[ユーザ編集] ページの [次回のログイン時にタイムベース・ワンタイム・パスワードの QR コードを表示する] フィールドを選択することによってこの動作を有効にできます。これを行うと、ターミナル・セッションはエンドユーザの発行者、アカウント、および秘密鍵を表示します。Web アプリケーションは、エンドユーザの発行者、アカウント、および秘密鍵を QR コードと共に表示します。ここで、エンドユーザはコードをスキャンするか、情報を手入力できます。

  Important:

  このオプションはお勧めしません。詳細は、以下の注意事項を参照してください。

Caution:

以下は、2 要素の TOTP 認証を使用するときの重要なセキュリティ上の問題です。

• 安全でない環境では、秘密鍵や QR コードを転送しないでください。安全なネットワークでも帯域外転送をお勧めします(秘密鍵は Caché または Caché アプリケーションにログインする手段をエンドユーザに提供します。ユーザまたはエンドユーザが秘密鍵の安全性を確保できない場合、攻撃者がアクセスできるようになる可能性があり、秘密鍵がセキュリティの役に立たなくなります)。

• 組織に対して 2 要素の TOTP 認証を構成するとき、各エンドユーザに秘密鍵を直接渡すか、電話で伝えるか、または管理者が立ち会っている状況でエンドユーザに QR コードをスキャンさせることを強くお勧めします。こうすることによって、秘密鍵を取得する個人を認証する機会がもたらされます。

  ネットワークを介して秘密鍵を渡すと、漏えいの可能性が高くなります。これには、Web アプリケーション、コンソール、またはターミナルに最初にログインするときにエンドユーザに秘密鍵を表示することが含まれます。また、Web アプリケーションに最初にログインするときにエンドユーザに QR コードを表示することも含まれます。

TOTP 発行者、アカウント、鍵、および QR コード

Note:

2 要素の TOTP 認証を使用していて、QR コードを生成する場合、Caché サーバで Java 1.7 以降を実行している必要があります。Java なしでも Caché で 2 要素の TOTP 認証を使用できますが、認証デバイスまたはアプリケーションでエンドユーザが発行者、アカウント、および鍵の値を手入力する必要があります。

サーバの 2 要素認証の構成

Caché サーバの 2 要素認証を構成する手順は以下のとおりです。

1. インスタンス全体に対する 2 要素認証の有効化および構成を行います。インスタンスを構成して SMS テキスト認証、TOTP 認証、またはその両方を使用できます。

2. SMS テキスト認証の場合、必要に応じて携帯電話サービス・プロバイダの構成を行います。これには以下が含まれます。

   • ある携帯電話サービス・プロバイダが必要であるのに、既定のプロバイダのリストに含まれていない場合、このサービス・プロバイダを追加する。

   • 既存のプロバイダに対し、必要に応じて構成情報を変更する (既定または追加)。

サービスに対する 2 要素認証の有効化または無効化

%Service_Bindings、%Service_Console、および %Service _Terminal に対して 2 要素認証を有効化または無効化する手順は以下のとおりです。

1. 管理ポータルのホーム・ページで、[サービス] ページ ([システム管理] > [セキュリティ] > [サービス]) に移動します。

2. [サービス] ページで、いずれかの形式の 2 要素認証を有効にするサービスの名前をクリックします。選択したサービスの [サービス編集] ページが表示されます。

3. そのサービスの [サービス編集] ページで、[2 要素の SMS] チェック・ボックス、[2 要素のタイムベース・ワンタイム・パスワード] チェック・ボックス、またはその両方にチェックを付けるか、またはチェックを外します。これらの各チェック・ボックスは、そのインスタンスに対して 2 要素認証が有効になっている場合にのみ表示されます。

4. [保存] をクリックします。

2 要素認証向けの Web アプリケーションの構成

インスタンスに対して 2 要素認証を有効にしたら、これを使用するすべての Web アプリケーションでもこれを有効にする必要があります。アプリケーションでこれを有効にする手順は以下のとおりです。

1. 管理ポータルのホーム・ページで、[ウェブ・アプリケーション] ページ ([システム管理] > [セキュリティ] > [アプリケーション] > [ウェブ・アプリケーション]) に移動します。

2. [Web アプリケーション] ページで、2 要素認証を有効にするアプリケーションの名前をクリックし、そのアプリケーションの [編集] ページを表示します。

3. [編集] ページの [セキュリティ設定] セクションで、[2 要素の SMS] チェック・ボックス、[2 要素のタイムベース・ワンタイム・パスワード] チェック・ボックス、またはその両方にチェックを付けるか、またはチェックを外します。これらの各チェック・ボックスは、そのインスタンスに対して 2 要素認証が有効になっている場合にのみ表示されます。

[ウェブ・アプリケーション編集] ページに関する一般情報は、"Caché Server Pages (CSP) の使用法" のドキュメントの “CSP アーキテクチャ” の章にある “CSP アプリケーションのオプション” のセクションを参照してください。

2 要素認証向けのエンドユーザの構成

2 要素認証向けに 1 回限りのセキュリティ・トークンを受信するようにエンドユーザを構成する手順は以下のとおりです。

1. 管理ポータルのホーム・ページで、[ユーザ] ページ ([システム管理] > [セキュリティ] > [ユーザ]) に移動します。

2. 既存のユーザの場合は、編集するユーザの名前をクリックします。新規ユーザの場合は、[新規ユーザ作成] をクリックしてユーザの作成を始めます (新規ユーザの作成の詳細は、“ユーザ” の章の “新規ユーザの作成” のセクションを参照)。これらのアクションのどちらを実行しても、そのエンドユーザの [編集] ページが表示されます。

3. [ユーザ編集] ページで、[SMS テキスト有効] または [タイムベース・ワンタイム・パスワード有効] を適切に選択します。

4. [SMS テキスト] を選択した場合、以下のフィールドをすべて入力する必要があります。

   • [携帯電話サービスプロバイダ] — ユーザに携帯電話サービスを提供する会社。リストからプロバイダを選択します。プロバイダがリストに表示されていない場合は、[新規プロバイダ] をクリックして、Caché インスタンスに新規プロバイダを追加します ([新規プロバイダ] をクリックすると、[新規携帯電話プロバイダの作成] ウィンドウが表示されます。このウィンドウには、[サービスプロバイダ] フィールドおよび [SMSゲートウェイ] フィールドがあります。これらの目的は、"携帯電話サービス・プロバイダの作成または編集" のセクションで説明した目的と同じです)。

   • [携帯電話番号] — ユーザの携帯電話番号。これは 2 つ目の要素で、1 回限りのセキュリティ・トークンを含むテキスト・メッセージをユーザが受信する電話番号です。

5. [タイムベース・ワンタイム・パスワード有効] を選択した場合、ページに以下のフィールドおよび情報が表示されます。

   • [次回のログイン時にタイムベース・ワンタイム・パスワードの QR コードを表示する] — ユーザが次回ログインしたときに QR コードを表示するかどうか。選択されている場合、Caché は、次回のログイン時に QR コードを表示し、これをスキャンして認証デバイスまたはアプリケーションに取り込むようユーザに求めます。さらに、トークンを表示して提供し、認証プロセスの完了を促します。既定では、このオプションは選択されていません。このオプションは使用しないことをお勧めします。

   • [新しいタイムベース・ワンタイム・パスワードの鍵を生成する] — エンドユーザの新しい共有秘密と新しい QR コードの両方を作成して表示します。

     Important:

     ユーザに新しいタイムベース・ワンタイム・パスワードの鍵を生成すると、ユーザの認証アプリケーションの現在の鍵は機能しなくなります。ログインする前に、ユーザは、QR コードをスキャンするか、または手入力して新しい鍵を認証アプリケーションに入力する必要があります(これは既存のセッションには影響しません)。

   • [発行者] — インスタンスの 2 要素の TOTP 認証を構成するときに設定した Caché インスタンスの識別子。

   • [アカウント] — Caché アカウントの識別子。これはアカウントのユーザ名です。

   • [Base32 のタイムベース・ワンタイム・パスワード (OTP) の鍵] — エンドユーザが認証デバイスまたはアプリケーションに入力する秘密鍵。

   • [QR コード] — 発行者、アカウント、および秘密鍵の値が格納されているスキャン可能なコード。

6. [保存] をクリックして、このユーザのこれらの値を保存します。

サービスが 2 要素認証を使用していて、エンドユーザが 2 要素認証を有効にしている場合、認証には以下が必要です。

• SMS テキスト認証では、テキスト・メッセージを受信できる携帯電話。

• TOTP 認証では、検証コードを生成できるアプリケーションまたは認証デバイス。

これらがないと、エンドユーザは認証できません。

• SMS テキスト認証では、エンドユーザは携帯電話を所持していて、その電話でテキスト・メッセージを受信できる必要があります。これは、1 回限りのセキュリティ・トークンを含むテキスト・メッセージを SMS テキストとしてユーザが受信する電話番号です。

• TOTP 認証では、ユーザは、QR コードをスキャンできるか、または TOTP (検証コードとして作用) の生成に必要な秘密鍵などの情報を受け入れることができる、認証デバイスまたはアプリケーションを所持している必要があります。

2 要素認証向けのバインディング・クライアントの構成

クライアント/サーバ接続は %Service_Bindings を使用します。この接続で 2 要素認証を使用するために必要なコードは、プログラミング言語によって異なります (コンソール、ターミナル、および Web アプリケーションではクライアント側の構成は必要ありません)。サポートされている言語には以下のものがあります。

• C++

• Java および JDBC

• .NET

• ODBC

• Perl

• Python

クライアント側のコードで実行される処理は以下の 3 つです。

1. Caché サーバへの接続を確立した後、2 要素認証がサーバで有効になっているかどうかを確認します。通常、この確認にはクライアントの接続オブジェクトのメソッドが使用されます。

2. ユーザから 1 回限りのセキュリティ・トークンを取得します。この処理では一般的に、Caché と特別な関係のないユーザ・インタフェース・コードが使用されます。

3. 1 回限りのセキュリティ・トークンを Caché サーバに提供します。この処理でも一般的に、接続オブジェクトのメソッドが使用されます。

C++

C++ では、2 要素認証のサポートは、以下のように tcp_conn クラスのメソッドを 2 つ使用します。

• bool tcp_conn::is_two_factor_enabled()
  

  

  このメソッドは、サーバで 2 要素認証が有効になっているかどうか確認します。このメソッドはブーリアン値を返します。true は、2 要素認証が有効であることを意味します。

• bool tcp_conn::send_two_factor_token(const wchar_t* token, Conn_err* err)
  

  

  このメソッドは、サーバに 2 要素認証トークンを提供します。このメソッドはブーリアン値を返します。true は、ユーザが認証されたことを意味します。このメソッドは以下の 2 つの引数をとります。

  • token。ユーザが受信した 2 要素認証トークンです。トークンの値をユーザから取得するのはクライアント・アプリケーションの役割です。

  • err。ユーザが正常に認証されない場合にメソッドがスローするエラーです。

Important:

2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、このインスタンスのメソッドを使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、サーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。このサンプル・コードは、アプリケーション・コードが std::string 型の変数に 1 回限りのセキュリティ・トークンを格納したと想定しています。その後、このコードは、文字列クラスの c_str メソッドを使用し、NULL で終了する文字列として 1 回限りのセキュリティ・トークンを取り出し、サーバに渡します。

// Given a connection called "conn"
if (conn->is_two_factor_enabled()) {
  // Prompt the user for the one-time security token.
  // Store the token in the "token" variable of type std::string.
  Conn_err err;
  if (!conn->send_two_factor_token(token.c_str(), &err;))
      // Process the error from a invalid authentication token here.
} 

Note:

Light C++ バインディングは、2 要素認証をサポートしていません。

Java および JDBC

Java では、2 要素認証のサポートは、以下のように CacheConnection クラスのメソッドを 2 つ使用します。

• public boolean isTwoFactorEnabled() throws Exception
  

  

  このメソッドは、サーバで 2 要素認証が有効になっているかどうか確認します。このメソッドはブーリアン値を返します。true は、2 要素認証が有効であることを意味します。

• public void sendTwoFactorToken(String token) throws Exception
  

  

  このメソッドは、1 回限りのセキュリティ・トークンをサーバに提供します。このメソッドは 1 つの引数 token をとります。これは、ユーザが受信した 1 回限りのセキュリティ・トークンです。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、このインスタンスのメソッドを使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、サーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。

Important:

2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

// Given a connection called "conn"
if (conn.isTwoFactorEnabled()) {
  // Prompt the user for the two-factor authentication token.
  // Store the token in the "token" variable.
  try {
    conn.sendTwoFactorToken(token); 
  } 
  catch (Exception ex) {
    // Process the error from a invalid authentication token here.
  }
}

.NET

.NET, Caché は、Managed Provider および ADO.NET との 2 要素認証を使用した接続をサポートしています。2 要素認証のサポートは、以下のように tcp_conn クラスのメソッドを 2 つ使用します。

• bool CacheConnection.isTwoFactorEnabledOpen()
  

  

  このメソッドは、Caché サーバへの接続を開き、2 要素認証がこの接続で有効になっているかどうかを確認します。このメソッドはブーリアン値を返します。true は、2 要素認証が有効であることを意味します。

• void CacheConnection.sendTwoFactorToken(token)
  

  

  このメソッドは、1 回限りのセキュリティ・トークンをサーバに提供します。返り値はありません。このメソッドは 1 つの引数 token をとります。これは、ユーザが受信した 1 回限りのセキュリティ・トークンです。トークンの問題 (有効でないなど) と接続の問題のいずれかがある場合、このメソッドは例外をスローします。

Important:

クライアント・アプリケーションは、CacheConnection.Open を呼び出す代わりに isTwoFactorEnabledOpen を呼び出します。isTwoFactorEnabledOpen メソッドは、続けて sendTwoFactorToken を呼び出す必要があります。

また、2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、このインスタンスのメソッドを使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、サーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。

// Given a connection called "conn"
try {
  if (conn.isTwoFactorEnabledOpen()) {
    // Prompt the user for the two-factor authentication token.
    // Store the token in the "token" variable.
    conn.sendTwoFactorToken(token);
  }
}
catch (Exception ex) {
  // Process exception
}

ODBC

ODBC では、2 要素認証のサポートは、ODBC の標準的な関数呼び出しを 2 つ使用します ("Microsoft ODBC API ReferenceOpens in a new tab" を参照)。

• SQLRETURN rc = SQLGetConnectAttr(conn, 1002, &attr, sizeof(attr), &stringLengthPtr);
  

  

  Microsoft ODBC API の一部である SQLGetConnectAttrOpens in a new tab 関数は、指定された接続属性の現在値を返します。Caché ODBC クライアントは、この関数を使用して、サーバが 2 要素認証をサポートしているかどうかを判定します。最初の引数の値は、クライアントからサーバへの接続のハンドルです。2 つ目の引数の値は、1002 で、これは 2 要素認証がサポートされているかどうかを指定する ODBC 属性です。これ以降の引数の値は、属性 1002 の値を含む文字列および関係のある変数のサイズ用です。

• SQLRETURN rc = SQLSetConnectAttr(conn, 1002, unicodeToken, SQL_NTS);
  

  

  同じく Microsoft ODBC API の一部である SQLSetConnectAttrOpens in a new tab 関数は、指定された接続属性の値を設定します。Caché ODBC クライアントは、この関数を使用して、2 要素認証トークンの値をサーバに送信します。4 つの引数の値は、それぞれ以下のとおりです。

  • クライアントからサーバへの接続。

  • 1002。2 要素認証がサポートされているかどうかを指定する ODBC 属性です。

  • 1 回限りのセキュリティ・トークンの値。

  • SQLNTS。1 回限りのセキュリティ・トークンが文字列に格納されていることを示します。

Important:

2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、SQLGetConnectAttr を使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、SQLSetConnectAttr 呼び出しによってサーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。SQLSetConnectAttr が失敗すると、サーバは接続を切断します。そのため、再び認証を行うには、その前に接続を再確立する必要があります。

// Given a connection called "conn"
SQLINTEGER stringLengthPtr;
SQLINTEGER attr;  
SQLRETURN rc = SQLGetConnectAttr(conn, 1002, &attr, sizeof(attr), &stringLengthPtr);
if attr {
  // Prompt the user for the two-factor authentication token.
  wstring token;
  SQLRETURN rc = SQLSetConnectAttr(conn, 1002, token, SQL_NTS);
    if !rc {
      // Process the error from a invalid authentication token.
    }
} 

Perl

Perl では、2 要素認証のサポートは、以下のように Intersys::PERLBIND::Connection クラスのメソッドを 2 つ使用します。

• is_two_factor_enabled()
  

  

  このメソッドは、サーバで 2 要素認証が有効になっているかどうか確認します。このメソッドは整数を返します。1 は 2 要素認証が有効であることを意味し、0 は無効であることを意味します。

• send_two_factor_token($token)
  

  

  このメソッドは、サーバに 2 要素認証トークンを提供します。整数が返され、1 は成功を表し、0 は失敗を表します。この引数 $token は、ユーザが受信してからクライアントのプロンプトで入力した 2 要素認証トークンです。トークンの値をユーザから取得するのはクライアント・アプリケーションの役割です。

Important:

2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、このインスタンスのメソッドを使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、サーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。

// Given a connection called "conn"
if ($conn->is_two_factor_enabled()) {
  # Prompt the user for the one-time security token.
  # Store the token in the "token" variable of type std::string.
  if (!$conn->send_two_factor_token($token)) {
    # Process the error from a invalid authentication token here.
  } else {
    # two-factor authentication succeeded
} 
else {
  # Handle if two-factor authentication is not enabled on the server.
}

Caché には、Perl での 2 要素認証を例示するサンプル・プログラムが付属しています。サンプル・プログラムは、install-dir\dev\perl\ ディレクトリにある samples\two_factor.pl です。Caché で Perl のサンプル・プログラムを使用する方法の詳細は、"Caché での Perl の使用法" の “Caché Perl バインディング” の章にある “サンプル・プログラム” のセクションを参照してください。

Python

Python では、2 要素認証のサポートは、以下のように intersys.pythonbind.connection クラスのメソッドを 2 つ使用します。

• is_two_factor_enabled()
  

  

  このメソッドは、サーバで 2 要素認証が有効になっているかどうか確認します。このメソッドはブーリアン値を返します。true は、2 要素認証が有効であることを意味します。

• send_two_factor_token(token)
  

  

  このメソッドは、サーバに 2 要素認証トークンを提供します。このメソッドはブーリアン値を返します。true は、ユーザが認証されたことを意味します。このメソッドは 1 つの引数 token をとります。これは、ユーザが受信した 2 要素認証トークンです。トークンの値をユーザから取得するのはクライアント・アプリケーションの役割です。

  Note:

  Python は入力のキャリッジ・リターンをそのままにします。つまり、1 回限りのセキュリティ・トークンを処理するとき、すべてのキャリッジ・リターンをセキュリティ・トークンから削除する必要があります。

Important:

2 要素認証がサーバで有効になっていて、クライアント・コードが 2 要素認証呼び出しを実装していない場合、サーバはクライアントとの接続を切断します。

以下の例では、conn という接続のインスタンスを使用します。

1. この例では、このインスタンスのメソッドを使用して、2 要素認証が有効になっているかどうか確認します。

2. この例では、サーバにトークンを提供しようとし、これに失敗するとエラー処理が行われます。

// Given a connection called "conn"
if conn.is_two_factor_enabled():
  # Prompt the user for the one-time security token.
  # Store the token in the "token" variable of type std::string.
  # Make sure that the carriage returns are stripped from the string.
  if !conn.send_two_factor_token(token):
    # Process the error from a invalid authentication token here.
  else:
    # two-factor authentication succeeded
else:
  # Handle if two-factor authentication is not enabled on the server.

Caché には、Python での 2 要素認証を例示するサンプル・プログラムが付属しています。サンプル・プログラムは、install-dir\dev\Python\ ディレクトリにある samples\two_factor.py (Python 2.6 用) および samples3\two_factor.py (Python 3.0 用) です。Caché で Python のサンプル・プログラムを使用する方法の詳細は、"Caché での Python の使用法" の “Caché Python バインディング” の章にある “サンプル・プログラム” のセクションを参照してください。

システム変数および認証

認証の後は、以下の 2 つの変数に値が設定されます。

• $USERNAME にはユーザ名が設定されます。

• $ROLES には、このユーザが保持するロールのコンマ区切りのリストが格納されます。

$ROLES 変数を使用すれば、プログラムからロールを管理できます。詳細は、“ロール” の章の “プログラムで管理するロール” のセクションを参照してください。

複数の認証メカニズムの使用

複数の認証メカニズムの使用が推奨される状況として、現状よりも高い厳格さを備えた認証メカニズムに移行する場合があります。例えば、認証を使用していないインスタンスで Kerberos への移行を図る場合は、以下のシナリオが考えられます。

1. 移行期間については、認証されていないアクセスと Kerberos 認証によるアクセスの両方を使用できるように、サポート対象のすべてのサービスを構成します。これにより、ユーザはどちらのメカニズムを使用しても接続できます。

2. 適切であれば、認証に Kerberos を使用するクライアント・ソフトウェアを新規にインストールします。

3. Caché ユーザのリストと Kerberos データベースにあるユーザのリストが同じ内容になった時点で、すべてのサービスに対し、認証されていないアクセスを無効にします。

複数の認証メカニズムを使用する場合は、通常、以下のセクションで説明するカスケード認証を組み合わせます。

カスケード認証

Caché では、多数の認証メカニズムをサポートしていますが、Kerberos と共に他のパスワード・ベースの認証メカニズムを使用しないことをお勧めします。また、一部の特定の状況では、インスタンスでの複数の認証メカニズムの使用が推奨されます。

サービスが複数の認証メカニズムをサポートしている場合、Caché では “カスケード認証” によってユーザ・アクセスが管理されます。カスケード認証では、指定されているメカニズムが以下の順番で適用されてユーザの認証が行われます。

• Kerberos キャッシュ (整合性チェックや暗号化を伴う Kerberos と伴わない Kerberos のどちらも含みます)。

• OS ベース

• LDAP (LDAP 資格情報キャッシュを 2 番目にチェック)

• 代行

• Caché ログイン

• 非認証

例えば、以下のメカニズムによる認証をサポートしているサービスを考えます。

1. Kerberos キャッシュ

2. OS ベース

3. 非認証

ユーザが Caché に接続しようとすると、そのユーザが Kerberos のチケット保証チケット (TGT) を所有するかどうかがチェックされます。このチケットがあれば、Caché のサービス・チケットを取得しようとする処理が実行されます。この処理が成功すると、ユーザは接続できます。最初の TGT が存在しない場合、または Caché サービスを取得できない場合は認証が失敗し、カスケードにある次の順番のメカニズムに移ります。

Caché ユーザ・リストにユーザの OS ベースの識別情報が含まれていれば、ユーザは接続できます。ユーザの OS ベースの識別情報が Caché ユーザ・リストにない場合は認証が失敗し、カスケードにある次の順番のメカニズムに移ります。

認証されていないアクセスが、カスケード認証にある最後の選択肢であれば、このレベルまで移ってきたユーザは全員 Caché にアクセスできます。

UnknownUser アカウントとの接続の確立

Caché ログインと認証されていないモードの両方が有効になっていると、[ユーザ名] プロンプトと [パスワード] プロンプトで Enter キーを押すだけで、ユーザは非認証モードのサービスに接続できます。この場合は、UnknownUser アカウントが使用されます。Caché ログインのみが有効になっている場合は、[ユーザ名] プロンプトと [パスワード] プロンプトで Enter キーを押しただけでは、サービスへのアクセスが拒否されます。Caché では、この処理が、UnknownUser アカウントでログインしようとしたユーザが、正しくないパスワードを指定したものとして扱われるためです。

プログラムによるログイン

状況によっては、アプリケーションの実行が始まった後でユーザがログインすることが必要な場合があります。 このような状況の例として、認証されていないユーザには一部の機能のみを提供し、保護された機能を提供する場合には、ユーザにログインを要求するアプリケーションがあります。

$SYSTEM.Security クラスの Login メソッドを使用すると、アプリケーションから Caché ログイン機能を呼び出すことができます。これには、以下の構文を使用します。

 set success = $SYSTEM.Security.Login(username,password)

以下はその説明です。

• success はブーリアン値で、1 は成功、0 は失敗を示します。

• username は、ログインするアカウントの名前を保持する文字列です。

• password は、username アカウントのパスワードを保持する文字列です。

有効なユーザ名とパスワードが指定され、該当のユーザ・アカウントが有効で期限切れになっていなければ、ユーザはログインできます。それに応じて $USERNAME と $ROLES が更新され、この関数からは 1 が返されます。 それ以外の場合、$USERNAME と $ROLES は変更されず、この関数からは 0 が返されます。

$SYSTEM.Security.Login を実行した結果として、特権のチェックは行われません。その結果、プロセスがそれまで保持していた特権が失われる可能性があります。

$SYSTEM.Security.Login には、引数が 1 つのみの以下のような形式もあります。

 set success = $SYSTEM.Security.Login(username)

この形式の動作は、パスワードがチェックされない点を除けば、引数が 2 つの形式とまったく同じになります。引数を 1 つ使用した形式の $SYSTEM.Security.Login が便利なのは、アプリケーションで独自の認証が実行されることから、Caché ユーザの識別方法をそれに応じて設定する必要がある場合です。 また、あるプロセスが特定のユーザのために実行されても、そのプロセスを開始するのはそのユーザではない場合にも、この形式を使用できます。

JOB コマンド、および新しいユーザ識別の確立

JOB コマンドを使用してプロセスを作成すると、その基となったプロセスからセキュリティの特性 ($USERNAME および $ROLES の値) が継承されます。 親プロセスに保持されている、User や Added などのすべてのロールが継承されます。

しかし、新しく作成するプロセスの $USERNAME と $ROLES の値を、その親とは異なる値にすることが必要な場合があります。 例えば、特定のユーザ向けに特定の時間に特定のタスクを開始する目的で、タスク・マネージャが作成されることがあります。 タスク・マネージャ自体は大きな特権を持っていることが普通ですが、該当のタスクはタスク・マネージャの特権ではなく、そのタスクの対象であるユーザの特権で実行する必要があります。

以下の擬似コードは、この処理方法を示しています。

WHILE ConditionToTest {
    IF SomeThingToStart {
        DO Start(Routine, User)
    }
}

Start(Routine, User) {
    NEW $ROLES    // Preserve $USERNAME and $ROLES

    // Try to change username and roles
    IF $SYSTEM.Security.Login(User) {
        JOB ...
        QUIT $TEST
    }
    QUIT 0       // Login call failed
}