WebSphere Business Integration システムは、保護される必要のある重要なビジネス・データを使用する分散システムです。転送中またはディスクに保管されたデータを、無許可の第三者が表示または変更するのを防ぐ必要があります。システムでのデータの保護には、必ず認証、メッセージ保全性、およびプライバシーの 3 つのセキュリティー・サービスが 関係します。認証は、許可されていると主張するユーザーを検証することです。認証によるアクセス制御は、認証済みユーザーが誰であるか、およびそのユーザーに付与されている許可が何であるかに基づいて、システムの部分に対するアクセスを制限します。メッセージ保全性は、データが変更されていないことを保証します。プライバシーは、許可ユーザーのみがデータを表示できることを保証します。保全性、プライバシー、および認証は、暗号化により実現できます。一方、RBAC は、ユーザー ID とパスワードを設定することにより実現できます。
3 つのセキュリティー・サービスのほかに、InterChange Server の保護に関係する 3 つの セキュリティー機構があります。これらの機構のうち、2 つの機構は、暗号化によるデータのエンコードに関係します。これらは 対称暗号化および非対称暗号化です。対称暗号化では、暗号化アルゴリズムまたは鍵を使用してデータをエンコードします。データのエンコードとデコードでは、同じ鍵が使用されます。あるプロセスがデータを暗号化し、別のプロセスがそのデータを暗号化解除する必要がある分散システムでは、無許可ユーザーが鍵を使用してデータにアクセスできないようにするために、セキュアな方法で鍵を共用および交換する必要があります。鍵を共用できるようにすることが、対称暗号化における重要なポイントです。
非対称暗号化の機構は、鍵を共用または交換するために一般的に使用されている 方法です。この方法では、データは鍵ペアを使用して暗号化および暗号化解除されます。鍵ペアの一方の鍵は秘密に保持される秘密鍵であり、鍵ペアのもう一方の鍵は他の人に共用および配布される公開鍵です。公開鍵を使用して暗号化されたデータは、鍵ペアの対応する秘密鍵によってのみ暗号化解除できます。送信側は受信側の公開鍵を使用してデータを暗号化します。このため、適切な受信側のみが自身の秘密鍵を使用してそのデータを暗号化解除できます。非対称暗号化は低速なため、データの暗号化には使用されません。その代わり、秘密鍵を非対称的に暗号化および暗号化解除するために使用され、この秘密鍵を使用して、データが対称的に暗号化されます。システムでのプライバシーを確保するために重要となるのが鍵の強度であるため、このプロセスにより、セキュリティーと速度の最適な組み合わせが実現されます。
秘密鍵は、データのディジタル署名を作成するためにも使用されます。ディジタル署名は、送信側の識別 (認証) と、送信されたデータの保全性 (メッセージ保全性) を 検査するために使用できます。ディジタル署名を作成するために、ハッシュという処理でデータが小規模な固定長のメッセージ・ダイジェストに 変換されます。これがマップ (メッセージ・ダイジェスト) を作成する片方向の機能です。メッセージ・ダイジェストは 送信側の秘密鍵を使用して暗号化され、これによりディジタル署名が作成されます。ディジタル署名はデータに追加され、受信側に送信されます。受信側は公開鍵を使用してディジタル署名を暗号化解除してメッセージ・ダイジェストに戻し、これにより署名が検証されます。なぜなら、公開鍵は、送信側のみが所有している秘密鍵を使用して暗号化されたデータのみを暗号化解除できるからです。その後、受信側はデータをハッシュしてメッセージ・ダイジェストを作成し、これを送信されたメッセージ・ダイジェストと比較します。両方のメッセージ・ダイジェストが同じであれば、受信側は、送信側が署名した後にデータが変更されていないことを確認できます。
重要なビジネス・データを保護するために、InterChange Server には、次のセキュリティー機能が組み込まれています。
アダプター・プロセスと InterChange Server は、メッセージを送信することにより通信します。メッセージは双方向であり、InterChange Server とアダプター・プロセスは、どちらもメッセージの送受信を行うことができます。SSL は、ノード間、またはリンク・レベルのセキュリティーを提供します。メッセージは、ノード間を移動する際は保護されますが、ノードでディスクに保管されている時は保護されません。メッセージおよびデータは平文であり、無許可ユーザーがこれらを表示したり変更したりすることができます。エンドツーエンド・プライバシーでは、発信元のノードから送信されたメッセージが中間ノードを経由して宛先ノードに到達するまでの間、メッセージを保護することができます。非対象および動的セキュリティーを使用すると、転送中のメッセージが保護され、処理を待つ間、ディスク上のキュー・マネージャーで保管されている間も 保護されます。メッセージは、暗号化やエンドポイント認証など、さまざまなレベルのセキュリティーで保護されます。エンドポイント認証は、通信におけるエンドポイント (InterChange Server やアダプターなど) が、ディジタル署名を使用して、自分の身元が、自分が主張しているものであることを証明するときに発生します。
分散システムでは、送信側と受信側の両方が、通信の通話者になり得ます。通信が保護される必要がある場合、着信メッセージと発信メッセージのセキュリティー・レベルが同じであれば、これは対称セキュリティーとみなされます。このタイプのセキュリティーは、サーバーとアダプターの間に密結合を作成します。SSL は、対称セキュリティーの 代表的な形式です。
サード・パーティー製セキュリティー製品の多くは、Secure Sockets Layer (SSL) セキュリティー・プロトコルに基づいています。SSL は、TCP/IP 接続に関して、データ暗号化、サーバー認証、メッセージの保全性、およびオプションでクライアント認証を提供します。通常、SSL は 対称セキュリティーを使用する密結合されたシステムに関連するため、データが重要かどうかに関係なく、すべてのデータが暗号化されます。SSL では、非セキュアなデータとセキュアなデータを区別することができません。着信メッセージと発信メッセージとのセキュリティー・レベルが違ってもよい場合、これは非対称セキュリティーとみなされます。例えば、あるユーザーがサーバーから大きな文書を受信する前にユーザー ID とパスワードを使用してサーバーで認証する必要があるとします。ユーザー ID およびパスワードは、転送中に無許可ユーザーによって見られないように暗号化する必要がありますが、転送中の文書を暗号化する必要はありません。SSL を使用する場合、ユーザー ID およびパスワードの両方、並びに大きな文書が暗号化されます。大きな文書を暗号化すると、サーバーのパフォーマンスに影響を与える可能性があります。
非対称セキュリティーを使用する場合、ユーザーからのメッセージ・フローではユーザー ID およびパスワードを暗号化するように設定し、サーバーからユーザーへのメッセージ・フローでは暗号化を行わないように設定することができます。ユーザーからのユーザー ID およびパスワードは暗号化によって保護され、一方、ユーザーに大きな文書を送信する前にこの文書を暗号化する必要がないので、サーバーのパフォーマンスは高まります。非対称セキュリティーでは、通信の通話者間のセキュリティー・パラメーターに対する動的更新も使用可能です。SSL などの非対称セキュリティーを使用する場合、セキュリティー・パラメーターは、通信開始時に設定されます。セキュリティー・パラメーターに対する変更は、新しい通信セッションが開始されるまで有効にはなりません。非対称セキュリティーを使用する場合、通信の各通話者が個々のセキュリティー・パラメーター定義を所有しているため、セキュリティー・パラメーターに対する変更を動的にすることができます。一方の通話者のセキュリティー・パラメーターに対する変更は、現在のセキュリティー・セッションを中断せず、他方の通話者に対する更新を要求します。非対称セキュリティーは柔軟ですが、エンド・ノードと直接結合していても、弱く (または間接的に) 結合している中間ノードでは 許可されていないソースによってデータが操作されてしまうぜい弱性があります。
エンドツーエンド・プライバシーを使用すると、アプリケーション層でセキュリティーを設定し、アプリケーションに出入りする前に メッセージを保護できます。このタイプのセキュリティーにより、中間ノードにメッセージがあるときに許可されていないソースがメッセージにアクセスする 危険性を回避できます。エンドツーエンド・プライバシーにより、メッセージ・タイプごとにセキュリティーのレベルを変えることもできます。
セキュリティーのレベルは、個々のアダプターおよび InterChange Server について、それぞれのメッセージ・タイプごとに構成されます。次の 4 つのセキュリティー・レベルがあります。
秘密鍵は、受信側の公開鍵を使用して暗号化されます。暗号化された秘密鍵は、受信側の秘密鍵でのみ暗号化解除できます。受信側の秘密鍵を使用できるのは受信側だけなので、メッセージはセキュアになります。
InterChange Server とアダプターは、自身の鍵ストアを保持します。鍵ストアは、パスワード保護されたファイルであり、公開鍵と秘密鍵をセキュアに保管するために使用します。InterChange Server は、自身の公開鍵と秘密鍵のペア、およびインストールされているすべてのアダプターの公開鍵が格納された鍵ストアを保持します。個々のアダプターは、自身の公開鍵と秘密鍵のペア、InterChange Server の公開鍵、自身が通信するすべてのプロセスの公開鍵が格納された鍵ストアを保持します。
個々のアダプターおよび InterChange Server について、セキュリティーのレベルと、保護するメッセージのタイプを組み合わせることができます。例えば、InterChange Server からの管理メッセージについて保全性を構成し、SAP アダプターからのビジネス・オブジェクト・メッセージについてプライバシーを構成し、E メール・アダプターからのメッセージにはセキュリティーを設定しないことができます。
アダプターまたは InterChnage Server からの保護されるメッセージのタイプは次の 4 つです。
エンドツーエンド・プライバシーを使用してメッセージを保護する場合、管理者は、保護するメッセージのタイプおよび必要なセキュリティー・レベルを決定した上で、InterChange Server および個々のアダプターの両方を構成する必要があります。InterChange Server に対してエンドツーエンド・プライバシーを構成した場合、これは InterChange Server から送信されるメッセージにのみ適用されます。個別のアダプターに対してエンドツーエンド・プライバシーを構成した場合、これはそのアダプターから送信されるメッセージにのみ適用されます。エンドツーエンド・プライバシーをオンにする前に、既存のすべてのイベントをシステムから除去する必要があります。既存のイベントは、エンドツーエンド・プライバシーを構成している間は適切に処理されません。エンドツーエンド・プライバシーの構成方法の詳細については、「システム管理ガイド」を参照してください。
無許可ユーザーがシステムにアクセスするのを防止するには、ユーザー ID とパスワードが、基本的なセキュリティー要件に対応します。ユーザー ID はシステムにアクセスする必要のあるユーザー (個人またはプロセス) に対して発行されます。ユーザーを認証することは、そのユーザーがシステムのすべての部分に対してアクセスできなければならないことを意味するわけではありません。システムには、選択されたユーザーのみがアクセスできる重要な、つまり機密性の高い部分と、すべてのユーザーがアクセス可能な部分がある可能性があります。アクセス制御は、認証済みユーザーが誰であるか、およびそのユーザーに付与されている許可が何であるかに基づいて、システムの部分に対するアクセスを制限することを意味します。個々のユーザーに対してさまざまなコンポーネントへのアクセスを許可することが可能ですが、このような方法で許可を管理するのは、管理者にとって時間がかかる作業です。役割ベースのアクセス制御は、InterChange Server へのアクセスを求めるユーザーを認証した上で、ユーザーに割り当てられた役割に基づいて、個々のコンポーネントへのユーザーのアクセスを制限します。
役割は、いくつかの機能的関連を持つ 1 人以上のユーザーの集合です。役割に基づいて許可を割り当てることにより、管理の負担が大幅に削減されます。管理者は、保護される必要のあるそれぞれの操作ごとに、その操作の実行を許可された役割を定義します。許可された役割のメンバーであるユーザーだけが、その操作の実行を許可されます。役割に許可を割り当てると、その役割許可が役割のセキュリティー・ポリシーとして参照されます。ユーザーには、複数の役割を割り当てることができます。
操作すなわちアクションに役割が割り当てられていない場合、そのアクションは保護されておらず、すべての認証済みユーザーがそのアクションを実行できます。保護されたアクションへのアクセスを許可された役割がユーザーに割り当てられている場合にのみ、ユーザーはそのアクションの実行を許可されます。
InterChange Server には、定義済みの管理者役割がデフォルトの役割として組み込まれています。管理者役割のメンバーは、サーバー上でのすべての操作 (ユーザーの作成、役割の作成、役割への許可の付与など) を実行する許可を持っています。管理者は、組織の構造をより適切に反映する追加の役割を作成することができます。例えば、ある組織では、異なるグループによって開発されたコンポーネントへのアクセスを 制限するために、Finance Developers や Redevelopers などといった複数の開発者役割がある 可能性があります。ユーザーは、複数の役割に所属することができます。デフォルトの役割は削除できません。
管理者は、システムを照会して、システムに現在ログインしているユーザーを調べることができます。1 人のユーザーは、同時に最大で 20 個のセッションにログインできます。管理者は、現在ログインしている任意のユーザーの特定のセッションをログアウトすることができます。また、管理者は、あるユーザーが開いているすべてのセッションをログアウトすることもできるので、ユーザーがログアウトするのを忘れた場合、管理者がユーザーの代わりにログアウトすることができます。ユーザーがすでに 20 個のセッションを開いている場合、ログインしようとすると例外がスローされます。管理者は、ユーザーのパスワードを再設定することもできます。
ゲスト・ユーザーがデフォルトのユーザーとして事前定義されており、ゲストのパスワードが割り当てられています。デフォルトのユーザーは削除できません。ゲストがログインできるセッションの数に制限はありません。
InterChange Server 管理者は、コンポーネントに割り当てられた許可であるセキュリティー・ポリシーを security.xml としてインポートまたはエクスポートすることができます。適切な役割を持つユーザーは、System Manager およびコマンド行ツール repos_copy を使用して、役割定義および役割メンバーシップに関する情報をファイルにエクスポートしたり、ファイルからインポートすることができます。このファイルの名前は、RoleMembership.xml です。ユーザーおよびパスワードは、バイナリー・ファイルにエクスポートしたり、バイナリー・ファイルからインポートすることが可能であり、このバイナリー・ファイルは別のサーバーにインポートすることができます。パスワードをエクスポートすることには、セキュリティー上のリスクがあります。このファイルは、オペレーティング・システムのセキュリティーによって保護されているディレクトリーにエクスポートする必要があり、インポート後に削除する必要があります。
デフォルトのセキュリティー・ポリシーでは、管理者役割を持つユーザーのみが、InterChange Server のサーバーの開始と停止、セキュリティーの管理、構成ファイルのエクスポート、および構成ファイルの配置を行うことができます。新規コンポーネントに対するデフォルトの許可では、認証済みユーザーは、すべてのアクションを実行できることになっています。デフォルトでは、コンポーネントは保護されていません。
役割ベースのアクセス制御は、InterChange Server のインストール時に自動的には構成されません。役割ベースのアクセス制御を構成する方法については、「システム管理ガイド」を参照してください。役割ベースのアクセス制御をオンに設定する前に、少なくとも 1 人のユーザーを管理者役割に追加する必要があります。InterChange Server でリポジトリー実装を使用する場合は、ユーザーを作成して管理者役割に追加する必要があります。役割ベースのアクセス制御がオンに設定されている場合、管理者役割に属するユーザーが 1 人もいない状態でサーバーが開始されると、サーバーはエラー・メッセージをログに記録して、役割ベースのアクセス制御をオフにした状態で開始されます。サーバーを開始するためにユーザー ID およびパスワードは必要なく、すべてのユーザーがすべての操作に対してアクセス権を持ちます。役割ベースのアクセス制御がオンに設定されている場合は、サーバーを開始するためにはユーザー ID とパスワードが必要であり、すべての許可またはアクセス・チェックが機能します。
監査により、管理者は、ログイン、ログアウト、ユーザー/役割/許可の管理などのセキュアな操作を実行したユーザーを追跡できるようになります。収集される監査データには、日時、ユーザー ID、実行した操作、および操作の状況 (成功、アクセス否認、例外発生など) があります。監査ログは、通常の Interchangesystem.log ファイルには書き込まれません。これは、セキュアでない your_ics_dir_name/log/audit directory ディレクトリーにある別のファイルに書き込まれます。監査ログ・ファイルには、無許可ユーザーがこのファイルを表示できないように、オペレーティング・システムによって保護される必要のある情報が含まれています。ログ・ファイルのサイズおよび新規ログ・ファイルを作成する頻度は、構成可能です。ファイルの名前は、ログ・ファイルがファイル・サイズ設定値を越えて新規ログ・ファイルを作成する必要の生じた頻度に応じて決まります。頻度のオプションには、毎日、毎週、および毎月があります。デフォルト値は毎週です。監査ログ・ファイル名の形式は、以下のようになります。
Daily file: icsaudit_yyyymmmdd_nnn.log Weekly file: icsaudit_yyyymmmwx_nnn.log Where x = 1,2,3.... Week numbers Monthly file : icsaudit_yyyymmm_nnn.log
ここで、yyyy は年、mmm は月、dd は日、wx は週番号を表します。nnn は 001......999 であり、ログ・ファイルがファイル・サイズ設定値を超えたために 1 つの期間内に複数のファイルを作成する必要がある場合に使用されます。監査できる操作には、以下が含まれます。
ユーザー・レジストリーは、ユーザー名およびパスワードを保管するシステムです。デフォルトでは、ユーザーおよびパスワードは、ローカルの WBI リポジトリーに保管されます。userRegistry 構成パラメーターを使用して、InterChange Server が Lightweight Directory Access Protocol (LDAP) ディレクトリーをユーザー・レジストリーとして使用するように構成できます。LDAP は、エンタープライズ・ディレクトリー・サービスにアクセスするためのプロトコルです。エンタープライズ・ディレクトリーは、複数のアプリケーション間で共用できる情報を保管するために使用されます。例えば、すべてのエンタープライズ・アプリケーションで必要なユーザー情報には、ユーザー名、パスワード、および E メール・アドレスなどがあります。この情報を個々のアプリケーションの専有データベースに保管し、データを複写する場合、同期を保つのが困難です。新しい従業員が会社に加わったときは、それぞれのアプリケーションでその従業員用のユーザー ID およびパスワードを作成する必要があります。しかし、ディレクトリー・サービスを使用すると、ユーザー ID とパスワードはこのディレクトリーで一度作成するだけで済み、エンタープライズ・アプリケーションはこの情報を再利用できます。
プロバイダーがユーザー・リポジトリーとして LDAP ディレクトリーを使用するようにするにはプロバイダーを LDAP に設定し、ユーザー・レジストリーとしてローカルの WBI リポジトリーを使用するようにするには REPOS に設定します。WBI リポジトリーを使用してユーザーおよびパスワードを保管する場合は、それ専用の個別のデータベースを使用することを強くお勧めします。ユーザー・レジストリーをホスティングするデータベースの URL を指定することができます。これは、構成ファイル interchangesystem.cfg 内の USER_REGISTRY という名前の階層プロパティーです。構造は既存の REPOSITORY プロパティーと同じであり、データベースの URL、ユーザー名、およびパスワードを指定できます。このプロパティーは、サーバーの構成ツールを使用して編集できます。LDAP を 使用する場合も WBI データベースを使用する場合も、1 つのエンタープライズごとに 1 つのユーザー・レジストリーを 設定し、InterChange Server の複数のインスタンスがユーザーやパスワードをインポートおよびエクスポートする 必要なしに同じユーザー・レジストリーを共用できるようにすることを お勧めします。InterChange Server は、RFC 2798 に記述されている InetOrgPerson スキーマを使用して、LDAP ディレクトリーのユーザー名およびパスワードを使用できます。InetOrgPerson は、各スキーマを固有に識別するために IETF によって割り当てられたオブジェクト ID (OID) 2.16.840.1.113730.3.2.2 を持っています。InterChange Server は、ディレクトリー内のディレクトリー・ツリー構造について何の推測も行いません。ユーザーは、ユーザーおよび役割の両方の構成の一部として基本識別名 (baseDN) を指定できます。この baseDN は、すべての検索および更新のルートとして使用されます。
保護可能なコンポーネントおよびアクションのリストを以下に示します。
保護可能なコンポーネント | 保護可能なアクション |
---|---|
InterChange Server |
|
コラボレーション・オブジェクト |
|
コネクター |
|
マップ |
|
関係 |
|
ベンチマーク |
|