集合のセキュリティー

Liberty での集合セキュリティーの原則を使用して、Data in Motion (流れているデータ) と Data at Rest (保存されたデータ) に対応することができます。

集合のセキュリティーには、次の 2 つの基本領域があります。
  • 管理可能ドメイン・セキュリティー構成

    Data in Motion (流れているデータ)、認証、および許可に対応します。

  • 集合リポジトリーのデータ・セキュリティー

    Data at Rest (保存されたデータ)、認証、および許可に対応します。

管理可能ドメイン・セキュリティー構成
集合の管理可能ドメイン・セキュリティー構成は、次の 2 つの部分で構成されます。
  • ユーザー・ドメイン

    このドメインは、管理者ロールを定義する Java™ ロール・ベース・セキュリティーに依存します。 このタイプのセキュリティーは、構成済みのユーザー・レジストリー内のユーザーにマップすることができます。

  • サーバー・ドメイン

    このドメインは、SSL 証明書ベースの認証に依存します。

ユーザーが集合コントローラーの MBean にアクセスするには、ユーザーが管理者ロールでなければなりません。 集合を通じた管理アクションではすべて、ユーザーに管理者ロールが付与されていることが必要です。 全詳細については、『Liberty へのセキュア JMX 接続の構成』を参照してください。

サーバー間通信はサーバー・ドメイン内で行われるため、集合のメンバー間の通信にはユーザー ID もパスワードも使用されません。 集合の各メンバーには、ホスト名、ユーザー・ディレクトリー、およびサーバー名で構成される、集合内で固有な ID があります。 集合内の各メンバーは、そのサーバー・ドメイン構成を定義します。 これは、serverIdentity.jks ファイルと collectiveTrust.jks ファイルで構成されます。 集合内でセキュア通信を確立するために必要な SSL 証明書が、これらのファイルに含まれています。 HTTPS 鍵の構成には特定のトラスト設定が必要で、これらはデフォルトで設定されています。

サーバー・ドメインの SSL 構成は、追加のトラステッド証明書のエントリーを collectiveTrust.jks 鍵ストアに追加することでカスタマイズできます。 コントローラーの複製時にすべてのトラストがコピーされるため、SSL のカスタマイズは最初のコントローラーに適用してください。 collectiveTrust.jks 鍵ストアへのトラストの追加は、 デフォルトの HTTPS 証明書が使用されない場合にのみ必要です。 HTTPS SSL 構成が変更された場合は、以下の証明書の規則が適用されます。
  • HTTPS トラストは、集合内のすべてのコントローラーおよびメンバーによって確立される必要があります。 HTTPS SSL 証明書が変更された場合は、集合コントローラーからの以下のルート署名者を HTTPS SSL トラストストアに追加する必要があります。
    • rootKeys.jks 鍵ストアからの controllerRoot 署名者をすべての集合メンバーの HTTPS SSL トラストストアに追加してください。
    • rootKeys.jks 鍵ストアからの controllerRoot 署名者と memberRoot 署名者をすべての集合コントローラーの HTTPS SSL トラストストアに追加してください。
  • 各メンバーは、集合コントローラーへのアウトバウンド接続を行うことができます。 集合コントローラーの collectiveTrust.jks 鍵ストアには、各メンバーの HTTPS SSL 証明書を信頼する証明書チェーンが含まれていなければなりません。すべての HTTPS 証明書をルート署名者によって署名することを強くお勧めします。その後、これらは collectiveTrust.jks 鍵ストアに追加することができます。共通のルート署名者を持たない個々の SSL 証明書を使用した場合、信頼を確立することはできますが、拡張されません。
  • 各コントローラーは、集合メンバーへのアウトバウンド接続を行うことができます。 集合メンバーの collectiveTrust.jks 鍵ストアには、各コントローラーの HTTPS SSL 証明書を信頼する証明書チェーンが含まれていなければなりません。すべての HTTPS 証明書をルート署名者によって署名することを強くお勧めします。その後、これらは collectiveTrust.jks 鍵ストアに追加することができます。共通のルート署名者を持たない個々の SSL 証明書を使用した場合、信頼を確立することはできますが、拡張されません。
サーバー間通信には、SSL 認証がサポートされていることが必要です。 HTTPS SSL 構成がカスタマイズされている場合には、SSL 構成に clientAuthenticationSupported="true" を指定する必要があります。 以下に例を示します。
<!-- clientAuthenticationSupported set to enable bidirectional trust -->
    <ssl id="defaultSSLConfig"
         keyStoreRef="defaultKeyStore"
         trustStoreRef="defaultTrustStore"
         clientAuthenticationSupported="true" />

集合コントローラーでの clientAuthentication="true" の設定は、一般的な振る舞いおよび予期される振る舞いの一部を妨げるため、推奨されません。例えば、この設定は、 Admin Center および集合コマンド・ライン・ユーティリティーにおけるユーザー名とパスワードでの認証を妨げます。

集合メンバーでの clientAuthentication="true" の設定は、ユーザー名とパスワードでのログインを防止するために望ましい場合があります。この設定が集合の操作を中断することはありません。コントローラーが発生元であるすべての操作は証明書を使用して認証されるためです。

CollectiveRegistration MBean を使用して、メンバーが集合コントローラーに情報を公開しないようにすることができます。disavow メソッドは認証を禁止し、avow メソッドは認証を有効にします。

集合リポジトリーのデータ・セキュリティー

集合リポジトリーのデータ・セキュリティー・ポリシーは、Data at Rest (保存されたデータ) のポリシー、特に、集合リポジトリーの内容へのアクセスに関するポリシーに対応します。

集合データに関する現行のセキュリティー・ポリシーは、以下のとおりです。
  • sys.host.auth.infosys.jmx.auth.info、 および sys.nologin の 3 つのノード名は、システムによって予約されています。 これらのノードは、ホストまたはサーバーのリポジトリー名前空間にあります。 ユーザーが作成したノードでは、接頭部 sys を使用しないでください。
  • システム資格情報の漏えいを防ぐために、sys.host.auth.infosys.jmx.auth.info のノードには、 MBean でアクセスすることができません。 これらのノードに保管されたデータにアクセスすると、ヌル応答になります。
  • 集合メンバーは、リポジトリー内の自身の情報のみの変更に制限されます。 認証された管理ユーザーは、上記の内容を除き、リポジトリー内の情報に無制限にアクセスすることができます。認証された管理ユーザーとは、管理ロールが付与されたすべてのユーザーです。

集合リポジトリーは根本的にはディスク上に存在するため、 ファイル・システム許可の設定が環境にとって安全なものでなければなりません。 集合コントローラーの構成は、当該ユーザーのみから読み取り/書き込み可能、当該グループのみから読み取り可能で、一般からは全くアクセス不能 (つまり、chmod 0640) にすることが推奨されます。組織で設定されたセキュリティー・ガイドラインがあれば、それに従ってください。


トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: Tuesday, 6 December 2016
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwlp_collective_sec
ファイル名: cwlp_collective_sec.html