IBM PureApplication System のセキュリティーと信頼

Ching-Yun (C.Y.) Chao, Ph.D. (cyc@us.ibm.com), Senior Software Engineer, IBM

IBM PureApplication System は、クラウド・コンピューティング・ソフトウェア、コンピューター・サーバー、ネットワーク機器、ディスク・ストレージ・コントローラー、そしてハード・ディスクおよびソリッド・ステート・ディスクによるストレージが 1 つに統合された、エキスパート・インテグレーテッド・システムです。この記事では PureApplication System のセキュリティーおよびトラスト・インフラストラクチャーの設計原則を概説します。その設計原則とは、デフォルト・セキュア、セキュリティー制御の層を重ねた多層防御、職務の分離によるアクセス制御、そしてユーザーの説明責任です。この記事の目標は、既存の IT インフラストラクチャーに PureApplication System のセキュリティーおよびトラスト・インフラストラクチャーを統合する企業を支援し、企業がセキュリティー・コンプライアンスの要件とリスク・マネジメントに対処できるようお手伝いすることです。この記事の内容は、IBM WebSphere 開発者向け技術ジャーナルの一部となっています。

Ching-Yun (C.Y.) Chao, Ph.D., Senior Software Engineer, IBM

Ching-Yun (C.Y.) Chao は、IBM PureApplication System および IBM Workload Deployer のセキュリティーおよびトラスト・フレームワークおよびインフラストラクチャーの設計、開発リーダーです。WebSphere Application Server Web サービス・セキュリティー開発に取り組むなかで、SAML (Security Assertion Mark Language) セキュリティー・トークンとクロスセキュリティー・ドメイン・トラスト・サポートの設計および開発を先導しています。Web サービス・セキュリティーに取り組む前は、WebSphere Application Server の主任セキュリティー・アーキテクトとして、プラガブル認証およびプラガブル権限付与メカニズム、マルチ・セキュリティー・ドメイン、セキュリティー監査の設計、開発を先導してきました。WebSphere 開発に参加する以前は、IBM PC サーバー高可用性システム・クラスタリング・プロジェクトの主任アーキテクト兼開発者でした。2006年に IBM Master Inventor を受賞した彼は、セキュリティーおよび高可用性システム・クラスタリングの分野で数々の特許を取得しています。彼は、ノースウェスタン大学で電気工学の博士号を取得しています。



2013年 1月 17日

はじめに

企業はビジネス・データとコンピューティング・リソースの完全性、機密性、権限付与、そして可用性を保護しなければなりません。さらに、クラウド環境で実行するビジネス・アプリケーションの完全性、機密性、プライバシーを保護することも重要な顧客要件となってきています。IBM PureApplication System はクラウドを対象に構築されたプラットフォームであり、ここにはネットワーク・リソース、コンピューティング・リソース、ストレージ・リソース、物理リソース、仮想リソースなどの管理ソフトウェア、IBM およびパートナーのビジネス・アプリケーション・ワークロード・パターン、そして慎重に設計かつ計画されたセキュリティーおよびトラスト・インフラストラクチャーがあらかじめ統合されています (詳細については、「Security in Development: The IBM Secure Engineering Framework」を参照してください)。

PureApplication System は、セキュリティーおよび信頼に関する要件に対処するために、さまざまなレベルでリソースを分離および保護します。このシステムでは、組み込みのセキュリティー制御機能によりコンピューティング・ノードの分離、ディスク・ストレージの分離、OS と仮想マシンの分離、ネットワークの分離、トラスト・ドメインの分離、通信の完全性と機密性の保護、そして粒度の細かいリソース・アクセス制御を行い、すべての仮想アプリケーションおよび共有サービスをそれぞれに異なるトラスト・ドメインで実行します。これらのトラスト・ドメインは互いに分離されるだけでなく、システム管理用のトラスト・ドメインからも分離されます。

PureApplication System は、企業のコンピューティング環境および IT インフラストラクチャーに欠かせない構成要素です。IT セキュリティー制御を補完するこの組み込みセキュリティー・インフラストラクチャーを企業の IT インフラストラクチャーに統合して、セキュリティー保護およびリスク・マネジメントのすべてを実現してください。

ハードウェア構成について詳しくは、IBM PureFlex リソースを参照してください。

この記事では、リソース分離およびトラスト・ドメインのポリシー・ベースでの管理をサポートする、さまざまなレベルでのリソースの分離とトラスト・インフラストラクチャーについて概説し、各種の使用シナリオを通してベスト・プラクティスを提案します。その目的は、企業が PureApplication System のセキュリティーおよびトラスト・インフラストラクチャーを計画し、IT アーキテクチャーに統合することで、攻撃対象領域全体を最小化するのを支援することです。


セキュリティー・エンジニアリングと設計原則

PureApplication System 管理ソフトウェアは、IBM WebSphere Application Server や IBM WebSphere DataPower SOA アプライアンスなどの IBM ソフトウェア製品と同じく、IBM Secure Engineering Framework が推奨するガイドラインとベスト・プラクティスに従って開発プロセスにセキュリティーを統合します (「Security in Development: The IBM Secure Engineering Framework」を参照)。その目的は、IBM のセキュリティー要件を満たし、業界のベスト・プラクティスに従った (あるいはそれらを上回る) 製品を設計、開発することです。PureApplication System はセキュリティーを念頭に、脅威分析およびリスク軽減によって攻撃対象領域全体が最小になるように設計されています。製品の開発および保守に不可欠な部分として、PureApplication System では IBM Security AppScan を用いて定期的にセキュリティーの脆弱性をテストします。

PureApplication System のセキュリティーおよびトラスト・インフラストラクチャーのアーキテクチャーは、以下の優れたセキュリティー設計原則に従っています。

デフォルト・セキュアの原則

送信中のデータの完全性および機密性は、デフォルトで SSL (Secure Socket Layer) プロトコルによって保護されます。サーバーに対するリクエスト・メッセージの完全性は、公開鍵技術を使用して保護されます。永続データ・ストレージの完全性および機密性に関しては、構成データとアプリケーション・イメージの両方が暗号化されます。デフォルトで、粒度の細かいアクセス制御が実施され、ユーザーのすべてのログイン、ログアウト、そして管理アクティビティーが監査されます。しかも、これらのデフォルトのセキュリティー保護を非アクティブにするためにユーザーが構成できるオプションはありません。

多層防御の原則

標準的なセキュリティー・プラクティスと同じく、PureApplication System はビジネス・アプリケーションおよびビジネス・データの前面および周囲で、複数のセキュリティー保護層を用います。

  • ネットワーク保護: PureApplication System では、物理ネットワークと仮想ネットワークの両方を分離できるようになっています。管理サブシステムとアプリケーション・サブシステムは別個の外部物理ネットワーク上に置かれ、アプリケーションは分離された仮想ネットワークにデプロイされます。デフォルトでは、仮想アプリケーション・パターンのファイアウォール・プラグインによって未使用のポートがクローズされます。
  • 通信保護: デフォルトで SSL トランスポート保護が構成され、実施されます。
  • OS 保護: すべての未使用ポートがクローズされるという点で、OS イメージの保護は強化されます。仮想アプリーションがデプロイされる仮想マシンは root アカウントでのログインを無効にして、2048 ビットの鍵を使用した RSA (Rivest, Shamir, and Adleman) 鍵認証によるセキュア・シェル (SSH) を要求します。
  • 認証: リソースへのアクセスには認証が必要です。機密リソースにアクセスする際には、強力な認証 (例えば、公開鍵と対称鍵に基づく認証) が要求されます。
  • トラスト・ドメイン: トラスト・ドメインはトラスト境界を定義し、これらのトラスト境界を越えたリソースの可視性を制限します。
  • 権限付与: リソースへのアクセスには、セキュリティー・ロールに基づく権限付与およびリソース・インスタンスに基づくアクセス制御が必要です。

最小限の特権付与の原則

PureApplication System の権限付与は、粒度の細かいアクセス制御をサポートし、ユーザーには各自のタスクを実行するために必要な最小限の特権を付与するというセキュリティー原則に従います。物理リソースであるか仮想リソースであるかに関わらず、一般にリソースがユーザーに対して可視になるのは、そのユーザーに明確なアクセス権が付与されている場合に限られます。

  • 職務の分離ポリシー

    PureApplication System では、管理ユーザーの責任を以下の 5 つの機能分野に分類しています (図 1 を参照)。

    • ハードウェア管理
    • クラウド・グループ管理
    • ワークロード・リソース管理
    • セキュリティー管理
    • 監査
    図 1. 管理責任の 5 つの分野
    管理責任の 5 つの分野

    ユーザーには、5 つの機能分野のうち、1 つ以上の分野の管理責任を付与することができます。それぞれの分野内で管理者に付与されるセキュリティー・ロールは、読み取り専用 (read-only) またはフル・アクセス権 (full permission) のいずれかです。フル・アクセス権のセキュリティー・ロールを持つ管理者は、その分野でのすべての管理アクションを実行することができます。一方、読み取り専用のセキュリティー・ロールを持つ管理者は、構成とステータスを監視することはできますが、変更操作を行うことはできません。

    5 つすべての管理分野の権限が必要になる管理者は 1 人もいません。ベスト・プラクティスとして推奨されるのは、管理者の間で管理責任を分けて、1 人の管理者がすべての分野の管理者ロールを持たないようにすることです。例えば、監査ロールを持つユーザーは、セキュリティー監査構成の管理、セキュリティー監査レコードの保存、監視、システム操作における異常な状態の分析を担当します。利害の対立を避けるためにも、ユーザーが行ったアクションに対する説明責任をユーザー自らが効果的に持てるようにするためにも、監査管理者に他の分野の管理責任を兼任させることは控えるのが理想的です。

  • 委譲ポリシー

    いずれかの分野でフル・アクセス権のセキュリティー・ロールを持つ管理者に、委譲のセキュリティー・ロールも与えられている場合、その管理者は自身のセキュリティー・ロールを他のユーザーに委譲することができます。図 2 では、ワークロード・リソース管理者に委譲のセキュリティー・ロールが付与されているため、このワークロード・リソース管理者は、他のユーザーやユーザー・グループにセキュリティー・ロールを付与することができます。

    図 2. 委譲ポリシー ― フル・アクセス権の管理ロールと委譲ロールの要求
    図 2. 委譲ポリシー ― フル・アクセス権の管理ロールと委譲ロールの要求

    管理者が他のユーザーに付与できるセキュリティー・ロールは、自身に付与されているセキュリティー・ロールのみです。委譲ルールは、管理者とユーザーが正当性のない他の特権を持つことがないように作られています。ユーザーまたはユーザー・グループが追加の特権を取得する唯一の方法は、特権を持つ別の管理者が、明示的にその特権を付与することです。

  • 必要最小限の可視性ポリシー

    最小限の特権付与の原則に従い、PureApplication System のユーザー・コンソールとコマンドライン・インターフェースは、管理機能とリソースを、それを知る必要があるユーザーにだけ公開します。セキュリティー・ロールを持たないユーザーや管理者は、そのセキュリティー・ロールに対応する管理機能およびパネルをコンソールに表示することができません。ユーザーまたは管理者が表示できるリソースは、自身がアクセス権を持つリソースのみです。

説明責任の原則

企業が米国の SOX 法 (Sarbanes-Oxley Act: サーベンス・オクスリー法)、HIPPA (Health Insurance Portability and Accountability Act: 医療保険の相互運用性と説明責任に関する法律)、そして欧州のプライバシー法などのセキュリティー・コンプライアンスの要件に対応できるように、PureApplication System は包括的な監査レコードをファイルに保存します。PureApplication System のユーザーと管理者は、それぞれが行ったデプロイメントや管理のアクションに対する説明責任を負います。そのため、PureApplication System ではユーザーのあらゆるセキュリティー・アクションおよび管理アクションの監査レコードをファイルに保存して維持します。すべての監査レコードには、「誰」が「どの」リソースに対して「どんな」アクションを「いつ」、「どこ」から行ったか、そしてそのアクションが成功した「かどうか」を記述する情報が格納されます。完全性を確保するとともに否認防止をサポートするために、イベント・ログのエントリーには一意のシーケンス番号が組み込まれ、監査サービスによってデジタル署名が付けられます。セキュリティー監査はデフォルトで有効に設定されます。これを無効にすることはできません。

あらゆる状態変更イベントの包括的な監査を継続しながらも、PureApplication System によってリクエストの応答時間に追加されるオーバーヘッドは最小限です。セキュリティー監査ログは、外部ストレージにプッシュされるように構成することができます。こうすると、イベント・ログ保存プロセスの自動化に役立つとともに、セキュリティー・コンプライアンス要件を満たすのにも有効です。外部ストレージ・サーバーとの通信は、SSH を使用して保護されます。SSH 構成には RSA 鍵ベースのクライアント認証をセットアップすることをお勧めします。

PureApplication System のセキュリティーおよびトラスト・インフラストラクチャーは、複数の保護層ですべてのセキュリティーを実現します (図 3 を参照)。以降のセクションでは、インフラストラクチャー層、プラットフォーム層、およびアプリケーション層でのセキュリティー・メカニズムについて説明します。

図 3. PureApplication System が管理する 3 つのクラウド・コンピューティング層
図 3. PureApplication System が管理する 3 つのクラウド・コンピューティング層

インフラストラクチャー層のセキュリティー

PureApplication System の IaaS (Infrastructure as a Service) 層は、物理リソース (コンピューター・ノード、ネットワーク、ディスク・ストレージなど) および仮想リソース (クラウド・グループ、仮想マシン、ディスク・ストレージ・ボリューム、IP アドレス、OS イメージなど) を管理します。IaaS システム管理ソフトウェアを構成するコンポーネントは、システム・マネージャーワークロード・マネージャーハイパーバイザーの 3 つです。この 3 つのコンポーネントは、管理ネットワークを介して内部で計算ノードに接続されます。管理リクエスト・フローに使用される管理ネットワークは、コンピューター・ノードをサービス・アプリケーション・リクエストに接続する外部物理ネットワークとは分離されます。外部ネットワークを PureApplication Systemに接続する際のベスト・プラクティスは、管理ネットワークとアプリケーション・ネットワークをそれぞれ別個の外部ネットワークに接続することです。

リソースの分離

仮想化およびリソース共有は大きなコスト・メリットをビジネスにもたらす一方で、企業の顧客にとって主な関心事となるのは、機密性、完全性、そしてプライバシーを確保するためにリソースを分離できるかどうかです。PureApplication System は、ネットワーク、通信、トラスト・ドメイン、アクセス制御 (後ほど説明します) によって、リソースの分離とデータの隔離を実現します。PureApplication System には、次の 2 つのタイプのデプロイメント・パターンが用意されています。

  • 仮想システム (vSys) パターン: トポロジー中心の手法を取るこのパターンでは、ユーザーがデプロイするシステムのトポロジーを指定することができます。
  • 仮想アプリケーション (vApp) パターン: アプリケーション中心の手法を取るこのパターンでは、ユーザーがアプリケーション成果物およびポリシー駆動のサービス品質特性 (スケーリングおよびロギング・レベルなど) を指定することができます。

vSys と vApp とでは、それぞれに異なるアプリケーション・ライフサイクル管理手法を採用し、使用するセキュリティー・メカニズムもリソース分離特性も異なります。

  • 仮想システム・パターンのデプロイメントではプッシュ手法が採用されます。この場合、PureApplication System 管理ソフトウェアはデプロイメントごとに、管理スクリプトを実行するための OS root アカウントへのアクセスに使用する 2048 ビットの SSH 鍵を構成します。この鍵を使用して、アプリケーション・コードとソフトウェア・パッチをデプロイ対象の VM にプッシュします。
  • 仮想アプリケーション・パターンのデプロイメントではプル手法が採用されます。この場合、PureApplication System 管理ソフトウェアはデプロイメントごとにトラスト・ドメインを構成し、デプロイ対象の VM のそれぞれにエージェント・プロセスをセットアップします。このプロセスで管理ソフトウェアとやりとりして、管理サービスにアクセスし、アプリケーション・コードとソフトウェア・パッチを取得することができます。

ネットワークによるリソースの分離

PureApplication System は、それぞれ個別の外部物理ネットワークを使用して、管理トラフィックとアプリケーション・ワークロード・トラフィックを分離します。さらにデプロイメント間でのリソースの分離をサポートするためには、クラウド・グループ、IP グループ、および環境プロファイルを構成します。IP グループとは基本的に、指定されたサブネットおよび仮想ローカル・エリア・ネットワーク (VLAN) 上の IP アドレスの集合です。クラウド・グループとは、計算ノード、管理 VLAN、およびアプリケーション IP グループからなる物理的なグループ分けです。クラウド・グループには、1 つ以上の計算ノードを含めることができます。その一方、各計算ノードが所属できるのは 1 つのクラウド・グループだけなので、計算ノードはクラウド・グループ間で物理的に分離されます。仮想ネットワークの分離は、管理ネットワーク上に構成することができます。具体的に言うと、各クラウド・グループに一意の管理 VLAN があるため、あるクラウド・グループ内の VM は、管理 VLAN を介して別のクラウド・グループ内の VM にアクセスすることはできません。仮想ネットワークの分離をアプリケーション・ネットワーク上に構成するには、IP グループを使用します。2 つの IP グループがそれぞれ異なる VLAN 上にある場合、この 2 つの IP グループは互いに仮想的に分離されます。異なるクラウド・グループに属する VM 同士がアクセスできるのは、それぞれの VLAN が、システム外部の顧客ネットワーク内でブリッジされている場合です。

環境プロファイルは、ワークロード・パターンをデプロイする運用環境を定義します。環境プロファイルには 1 つ以上のクラウド・グループ、選択したクラウド・グループの 1 つ以上の IP グループ、そしてコンピューター・リソースの割り当て制限が含まれます。この制限には、仮想 CPU とメモリー、ソフトウェア・ライセンスの数、デプロイメントの優先順位、ユーザー・アクセス権などがあります。環境プロファイルを使用すると、クラウド・グループと IP グループをグループ化することにより、リソースの分離をセットアップすることができます。もっと具体的に言うと、環境プロファイルにはクラウド・グループという手段で物理計算ノードの排他的セットを指定できるということです。環境プロファイルでクラウド・グループと IP グループを組み合わせることにより、仮想ネットワーク (管理ネットワークおよびアプリケーション・ネットワークの両方) を他の環境プロファイルの仮想ネットワークから分離することができます。

図 4 に、仮想的に分離された 2 つの環境プロファイルの例を示します。この例では、環境プロファイル 1 にクラウド・グループ 1、管理 VLAN 1、IP グループ 1、アプリケーション VLAN 3 が含まれ、環境プロファイル 2 にはクラウド・グループ 2、管理 VLAN 2、IP グループ 2、アプリケーション VLAN 4 が含まれます。

図 4. 物理計算ノードの分離と仮想ネットワークの分離を指定する 2 つの環境プロファイル
図 4. 物理計算ノードの分離と仮想ネットワークの分離を指定する 2 つの環境プロファイル

ユーザーやユーザー・グループごとに別々の環境プロファイルを構成することで、さまざまなビジネス・ニーズに対応することができます。アクセス制御ポリシーは、環境プロファイルの「Access Rights (アクセス権限)」属性を利用してセットアップすることができます。ある環境プロファイルにワークロード・リソースをデプロイするには、ユーザーが特権付きワークロード管理のセキュリティー・ロールを持っているか、あるいはその環境プロファイルに対する読み取りアクセス権を持っている必要があります。通常、ユーザーおよびグループには、少なくとも特定の環境プロファイルに対する読み取りアクセス権を明示的に付与します。アクセス権を付与することによって、ワークロード管理者は、知る必要がある関係者だけがアクセスできるアクセス制御ポリシーを環境プロファイル・レベルでセットアップできるようになります。一般に、クラウド・グループ、IP グループ、計算ノード、およびソフトウェア・ライセンスなどのシステム・リソースに対するアクセス権は、ユーザーには付与しません。ユーザーに環境プロファイルへのアクセス権を付与すると、ユーザーはその環境プロファイルにワークロードをデプロイして、その環境プロファイルに含まれるクラウド・グループ、IP グループ、計算ノード、ソフトウェア・ライセンスを、その環境プロファイルが課すポリシーおよびリソースの制限の下で使用できるようになります。

1 つの使用例として、PureApplication System が企業内の 4 つの部門 (経理、開発、テスト、サービス) で共有される場合を考えてみてください。この企業ではリソースの分離を考慮して、計算リソースを次のように 3 つのセットに分けることにしました。

  • 経理部門に割り当てる計算リソースのセット
  • 開発部門とテスト部門で共有する計算リソースのセット
  • サービス部門に割り当てる計算リソースのセット

この企業のセキュリティー・ポリシーには、この 3 つのリソース・セットを物理的および仮想的に分離すること、そして知る必要のある関係者だけがアクセスできるという基準でのユーザー・アクセス制御を 4 つの部門に応じて実施することが規定されています。開発部門とテスト部門のユーザーは、物理計算ノードのセットを共有します。通常は、製品開発サイクルのさまざまな段階で、必要となるクラウド・リソースの量は開発部門とテスト部門とで異なることから、リソース割り当て要件の変化に対応するには、開発部門とテスト部門の間で柔軟にリソースを割り当て可能であることが望まれます。

計算リソースの分離とアクセス制御の要件に対応するために、この企業は 3 つのクラウド・グループと 4 つの環境プロファイルを作成しました (図 5 を参照)。各部門には、それぞれに固有の環境プロファイルに対するアクセス権を付与します。開発環境プロファイルとテスト環境プロファイルは、同じクラウド・グループを共有するため、この 2 つの部門間で計算ノードの割り当てを調整することができます。3 つのクラウド・グループは、計算ノードを 4 つの部門間で物理的に分離します。仮想ネットワークを 4 つの部門間で分離するには、個別の VLAN を持つ IP グループを使用します。具体的には、経理部門のクラウド・グループとサービス部門のクラウド・グループごとに、それぞれ 1 つの IP グループを構成します。開発部門およびテスト部門のクラウド・グループには、開発部門用 IP グループとテスト部門用 IP グループの 2 つを構成します。以下の図に、この 4 つの環境プロファイルを示します。開発部門の環境プロファイルとテスト部門の環境プロファイルの間での計算リソースの割り当ては、環境プロファイルの属性「Environment limits (環境の制限)」および「Deployment priority (デプロイメントの優先順位)」を使用して調整することができます。

図 5. 環境プロファイルを使用したリソース分離の例
環境プロファイルを使用したリソース分離の例

この 4 つの環境プロファイルが、4 つの部門間で仮想ネットワークを分離し、ユーザー・アクセスを制御します。開発部門の環境プロファイルとテスト部門の環境プロファイルは、リソースの共有を指定すると同時に、2 つの部門間でのアプリケーション VLAN の分離とアクセス制御を指定します。この 2 つの環境プロファイルは 1 つの共通クラウド・グループを共有することから、共通管理 VLAN も共有するという点に注意してください。共通の管理 VLAN を共有することに懸念がある場合には、開発部門とテスト部門が共有するクラウド・グループを 2 つの異なるクラウド・グループに分割することもできます。

クラウド・グループ内または 2 つのクラウド・グループ間のネットワーク・トラフィックをフィルタリングするには、ソフトウェア・ファイアウォールと外部ファイアウォールという 2 つのコンポーネントを使用することができます。仮想アプリケーション・パターンでは、ファイアウォール・プラグインを構成することができます。このプラグインは、デフォルトですべての未使用ポートをクローズします。仮想システム・パターンの場合は、カスタム・スクリプト・パッケージを使用してファイアウォール・ポリシーを構成することができます。図 6 に、ファイアウォールを使用して WebSphere Application Server から DB2 データベースへのトラフィックをフィルタリングする多層ワークロード・パターンの一例を示します。

図 6. ファイアウォールが構成された多層ワークロード・パターンの例
ファイアウォールが構成された多層ワークロード・パターンの例

環境プロファイルには、複数のクラウド・グループを含めることができます。vSys パターンを複数のクラウド・グループにデプロイする場合は、ネットワーク・トラフィックの分離レベルを強化するためにファイアウォールを利用することができます。図 7 に、外部ネットワーク・スイッチを使用して、単一の仮想システム・ワークロード・パターンを複数のクラウド・グループにデプロイする例を示します。

図 7. 単一の仮想システム・ワークロード・パターンを複数のクラウド・グループにデプロイする例
単一の仮想システム・ワークロード・パターンを複数のクラウド・グループにデプロイする例

仮想アプリケーション・パターンは、現行バージョンの PureApplication System では 1 つのクラウド・グループにしかデプロイすることができません。仮想アプリケーション・ワークロード・パターンを複数のクラウド・グループにデプロイするには、複数のワークロード・パターンをデプロイする必要があります。

個別のネットワークを使用してリソースの可視性を制御するだけでなく、PureApplication System ではトラスト・ドメインを使用してトラスト境界を作成し、REST プログラミング・インターフェース・レベルでリソースを分離します。

トラスト・ドメインによるリソースの分離

PureApplication System の vApp デプロイメント・モデルでは、管理とインフラストラクチャーを分離するために、リソースをトラスト・ドメインに編成します。PureApplication System 管理ソフトウェアに含まれるトラスト・サービス (TS) は、検証可能なセキュリティー・トークンを各トラスト・ドメインに発行します。PureApplication System 管理ソフトウェアが配置されるのは、管理トラスト・ドメイン内です。

vApp デプロイメント・モデルでは、リソース間の通信は同じトラスト・ドメイン内に限られます。あるトラスト・ドメイン内のリソースが他のトラスト・ドメイン内のリソースと通信するには、その 2 つのトラスト・ドメイン間にトラスト関係が明示的に確立されていなければなりません。トラスト・ドメインは、公開鍵技術を使用して形成および保護されます。

図 8. PureApplication System の管理トラスト・ドメイン
PureApplication System の管理トラスト・ドメイン

すべての仮想アプリケーション・デプロイメントは、別々のデプロイメント・トラスト・ドメイン内に配置されます。各デプロイメント・トラスト・ドメインには、一意のデプロイメント・セキュリティー・トークンと所有者鍵があります。このデプロイメント・セキュリティー・トークンと所有者鍵がデプロイメント・トラスト・ドメイン間で完全に分離しているおかげで、あるデプロイメントのセキュリティーが侵害された場合に、セキュリティー攻撃が他のデプロイメント・トラスト・ドメインやシステム管理トラスト・ドメインにまで及ぶことはありません。

一例として、図 9 に 3 つの仮想アプリケーション・デプロイメントを含むクラウド・グループを示します。この 3 つの仮想アプリケーション・デプロイメントはそれぞれに個別のトラスト・ドメイン内に配置され、同じクラウド・グループに含まれる他の仮想アプリケーション・デプロイメントから分離されます。

図 9. 各デプロイメント・トラスト・ドメインおよび管理トラスト・ドメインの分離
各デプロイメント・トラスト・ドメインおよび管理トラスト・ドメインの分離

PureApplication System は、仮想アプリケーションのデプロイ時に仮想アプリケーションのデプロイメント・トラスト・ドメインとの相互トラスト関係をプロビジョニングします。相互トラスト関係は、以下のようにして確立されます。

  1. 管理ソフトウェアはデプロイメント・トラスト・ドメインの公開鍵を保持します。したがって、デプロイメント・トラスト・ドメインからの REST リクエストを検証することができます。
  2. 仮想アプリケーション・デプロイメントは管理ソフトウェアの公開鍵を保持します。したがって、管理トラスト・ドメインからの REST リクエストを検証することができます。

トラスト関係は、2 つのデプロイメント・トラスト・ドメイン間に確立することができます。共有サービス・デプロイメント (これは、特殊なケースの仮想アプリケーション・デプロイメントです) はこの方法で他の仮想アプリケーション・デプロイメントとトラスト関係を確立し、これらの仮想アプリケーション・デプロイメントが共有サービスを使用することを可能にします。

要するに、トラスト・ドメインによる分離は、仮想アプリケーション・パターンのデプロイメントでのネットワーク・ベースの分離をさらに強化するということです。同じクラウド・グループに属するすべてのデプロイ済み vApp がネットワークで可視になっているとしても (つまり、同じクラウド・グループ内のデプロイ済み vApp がネットワーク上で互いを見ることができるとしても)、2 つのトラスト・ドメイン間でトラスト関係が明示的に確立されていない限り、そのトラスト・ドメイン間でデプロイ済み vApp 同士が通信することはできません。

アクセス制御によるリソースの分離

ネットワーク、仮想ネットワーク、およびトラスト・ドメインによるリソースの分離に加え、PureApplication System ではアクセス制御によるリソースの分離もサポートしています。

ワークロード・リソース管理の分離

PureApplication System の管理では、ユーザーに明示的にアクセス権が付与されているクラウド・リソースにしか、ユーザーがワークロード・パターンをデプロイできないように、ワークロード・リソースとクラウド・リソースの分離が行われます。ユーザーのグループごとに異なるクラウド・リソース・セットの使用を許可するように環境プロファイルをセットアップして、クラウド・リソースを分離することを可能にするのは、粒度の細かいリソース・アクセス制御です。

クラウド・リソースに対するユーザー・アクセスは、環境プロファイルを使って管理します。環境プロファイルで、クラウド・グループ・リソース (IP グループなど) のセット、リソースの割り当て、および許可されたユーザーがデプロイメントに使用できるライセンスの制限を指定します。ユーザーが仮想アプリケーション・パターンと仮想システム・パターンを環境プロファイルにデプロイするには、その環境プロファイルに対する読み取りアクセス権が明示的に付与されていなければなりません。フル・アクセス権のセキュリティー・ロールを持つワークロード管理者が以下の作業を行うには、クラウド・リソースに対する読み取りアクセス権が必要となります。

  • 該当するクラウド・リソースを使用した環境の作成
  • 他のユーザーに対する、環境プロファイルへのアクセス権の付与
  • 環境プロファイルへの共有サービスのデプロイ

デプロイメント・アクセスの分離

vApp デプロイメント・モデルでは、それぞれの仮想アプリケーションがデプロイされた仮想マシンごとにデプロイメント・エージェント・プロセスが実行されます。デプロイメント・エージェントとは、リカバリーや自動スケーリングなどの管理機能を実行する PureApplication System のコンポーネントです。デプロイメント・エージェントが処理を行うには、PureApplication System 管理データ・ストアからデプロイメント構成データとバイナリー・コードを取得しなければなりません。一般に、人間のユーザーが持つアクセス権に比べると、デプロイメント・エージェント・プロセスに与えられるアクセス権は限られます。PureApplication System はエージェント・プロセスに、そのデプロイメントに属するデプロイメント・データに限って読み取りアクセスを許可し、他のデプロイメント・データへの読み取りアクセスは許可しません。さらに、デプロイメント・エージェントにはデプロイメント・データの変更が許可されないのが通常です。

ユーザー管理

PureApplication System のユーザー管理は、エンタープライズ LDAP ユーザー・ディレクトリー・サーバーを使用して、一元化されたユーザー認証をサポートします。LDAP ユーザーが自動的に PureApplication Systems ユーザーになることはありません。LDAP ユーザーはまず、PureApplication System に登録しなければなりません。LDAP ユーザーは、明示的に登録することも、暗黙的に登録することもできます。LDAP ユーザー・グループが登録される場合には、そのユーザー・グループに含まれるユーザーも暗黙的に登録されます。LDAP ユーザーおよびユーザー・グループが登録されたとしても、LDAP ユーザー・パスワードと LDAP ユーザー・グループ・メンバーシップはいずれも PureApplication System にコピーされません。ユーザーとユーザー・グループのデータは、引き続き LDAP ディレクトリー・サーバーで管理および保守されます。

PureApplication System のユーザー管理には、PureApplication System セキュリティーを自己完結型にするための組み込みユーザー・リポジトリーも用意されています。このユーザー・リポジトリーには、顧客がシステムを構成および管理したり、LDAP ディレクトリー・サーバーと統合したりできるように、デフォルトのユーザー・アカウントが自動的に作成されます。追加のユーザーおよびユーザー・グループを作成して、この組み込みユーザー・リポジトリーに追加することもできます。ベスト・プラクティスは、ユーザーがローカル・ユーザー・アカウントの数を最小限に抑えられるように、エンタープライズ LDAP ディレクトリー・サーバーを使用することです。デフォルトのアカウントにはすべてのセキュリティー・ロールが与えられます。したがって、この周知のアカウントでの攻撃を防ぐために、できるだけ早いうちに CLI コマンドを使用してデフォルトのアカウント名を変更し、デフォルトのパスワードをセキュアなパスワードに変更することがベスト・プラクティスとなります。

PureApplication System ではセキュリティー・ロールを次の 5 つの管理責任分野に分けています。

  • ワークロード管理: 基本的に、ワークロード・コンソール上のすべての管理機能を管理、監視します。ユーザーには自動的に以下の 4 つのサブロールが与えられます。
    • 新規パターンの作成
    • 新規環境プロファイルの作成
    • 新規カタログ・コンテンツの作成
    • ILMT (IBM License Metric Tool)
  • クラウド・グループ管理: クラウド・リソース (クラウド・グループ、IP グループ、仮想マシン、ストレージ・ボリュームなど) を管理および監視します。
  • ハードウェア管理: ハードウェア・リソース、システム構成、イベント、ジョブ・キュー、およびシステム・アクティビティーを管理および監視します。
  • セキュリティー管理: セキュリティー構成、ユーザー、ユーザー・グループを管理します。ユーザーに委譲権限とフル・アクセス権のセキュリティー・ロールも与えられている場合、そのユーザーはクラウド・グループ、IP グループ、仮想アプライアンス、および仮想マシンへのアクセス権の付与および取り消しを行うこともできます。
  • 監査管理: 監査リソースを管理および監視します。

ほとんどのユーザーは、ワークロード・リソース管理権限やその他の管理権限がなくても、仮想アプリケーション・パターンあるいは仮想システム・パターンをデプロイすることができます。ユーザーには、自身がデプロイした仮想アプリケーションまたは仮想システムに対するリソース・アクセス権が自動的に付与されます。ベスト・プラクティスは、職務の分離と最小限の特権付与というセキュリティー原則に従うことです。つまり、ユーザー、ユーザー・グループ、管理者には、それぞれがタスクを実行するのに必要となるセキュリティー・アクセス権だけを付与します。

一般に、あらゆる責任分野には 2 つのロールがあります。1 つは、ユーザーにリソースの管理と監視を許可するフル・アクセス権のセキュリティー・ロール、もう 1 つはユーザーにリソースの監視のみを許可する、読み取り専用ビューのセキュリティー・ロールです。表 1 に、各分野でのフル・アクセス権のセキュリティー・ロールに与えられる権限を記載します。読み取り専用ビューのセキュリティー・ロールはフル・アクセス権のセキュリティー・ロールと同様ですが、変更操作が許可されないという点が異なります。

表 1
管理責任分野フル・アクセス権のセキュリティー・ロールの権限
ワークロード管理
  • パターンの管理 (管理対象には以下のものが含まれます)
    • 仮想アプリケーション・パターン
    • 仮想システム・パターン
    • 仮想アプライアンス・パターン
    • データベース・パターン
  • カタログの管理 (管理対象には以下のものが含まれます)
    • 再利用可能コンポーネント
    • 仮想アプリケーション・テンプレート
    • 仮想イメージ
    • スクリプト・パッケージ
    • アドオン
    • 緊急フィックス
    • データベース・ツール
    • データベース・ワークロード標準
    • DB2 fix pack
  • デプロイメントの管理 (管理対象には以下のものが含まれます)
    • 共有サービス
    • システム・プラグイン
    • パターン・タイプ
    • デフォルト・デプロイ設定
    • 環境プロファイル
  • デプロイメント・インスタンスの管理 (管理対象には以下のものが含まれます)
    • 仮想アプリケーション・インスタンス
    • 仮想システム・インスタンス
    • 仮想アプライアンス・インスタンス
    • 共有サービス・インスタンス
    • データベース・インスタンス
  • システム・リソースの管理
    • トレース・レベル設定の管理
    • トレースおよびログ・ファイルの取得
    • ストア・ハウス・ブラウザーの使用
    • 製品ライセンスの管理
    • ライセンス・レポートの取得
クラウド・グループ管理
  • クラウド・リソースの管理 (管理対象には以下のものが含まれます)
    • クラウド・グループ
    • IP グループ
    • 仮想アプライアンス
    • 仮想マシン
    • 仮想マシン・グループ
    • ストレージ・ボリューム
  • レポートへのアクセス
    • マシン・アクティビティーの監視
    • ユーザー・アクティビティーの監視
  • システム・リソースの管理
    • ジョブ・キュー
    • 製品ライセンス
ハードウェア管理
  • ハードウェア・リソースの管理 (管理対象には以下のものが含まれます)
    • インフラストラクチャー・マップ
    • 計算ノード
    • 管理ノード
    • ストレージ・デバイス
    • ネットワーク・スイッチ
  • システム・リソースの管理
    • システム設定の管理
    • システム・フィックス・パックの管理
    • 顧客ネットワーク構成の設定
    • ジョブ・キューの管理
    • イベントの管理
    • トラブルシューティング設定の構成
    • 問題レポートの取得
    • 製品ライセンスの管理
  • レポートの管理
    • マシン・アクティビティー・レポートの取得
    • ユーザー・アクティビティー・レポートの取得
セキュリティー管理
  • セキュリティー・リソースの管理
    • ユーザーの管理
    • グループの管理
    • セキュリティー構成の管理
    • システム・リソースへのアクセス権の付与
  • レポートの監視
    • ユーザー・アクティビティー・レポートの取得
監査管理
  • 監査リソースの管理
    • 内部監査ログ使用の監視
    • 外部監査ログ・ストレージ・サーバーの構成

5 つの責任分野のいずれかに対するフル・アクセス権のセキュリティー・ロールに加え、委譲のセキュリティー・ロールも割り当てられているユーザーは、自身が持つセキュリティー・ロールを他のユーザーおよびユーザー・グループに付与したり、付与したセキュリティー・ロールを取り消したりすることができます。委譲のセキュリティー・ロールを持たせる管理者は、柔軟に選択することができます。ただし、セキュリティー監査管理者の責任は、潜在的な脅威を検出するためにユーザー・アクティビティーやシステム・アクティビティーでの異常を監視すること、そしてユーザーが行ったアクションに対する説明責任をユーザー自らが持てるようにすることであるため、利害の対立を避けるには、監査管理者を他の 4 つの分野の管理者から分離することを強く推奨します。

共有サービス・プロバイダーのセキュリティー統合

共有サービスは、クラウド内で複数のアプリケーションのデプロイメント (仮想アプリケーション、仮想システム、仮想アプライアンスなど) によってデプロイおよび共有される事前定義された仮想アプリケーション・パターンを提供します。そこで、ここでは PureApplication System 内でのいくつかの共有サービスのセキュリティー統合について見ていきます。具体的には、ハードウェアおよびデータベース監視共有サービスのセキュリティー統合です。

デプロイヤーには、共有サービスの監視ロールを使用して自らのデプロイメントのステータスを表示する権限が与えられます。ワークロード管理者には、同じく共有サービスの監視ロールを使用してすべてのデプロイメントのステータスを表示する権限が与えられます。共有サービスの監視ロールは、共通のユーザー集団を PureApplication System 自体と共有するという点で、特殊なロールです。PureApplication System セキュリティーに組み込まれているクライアント・プログラミング・ユーティリティー・ライブラリーを使用すると、プログラマーはセキュリティー・プロトコルの詳細を気にすることなく、リクエスターの真正性と完全性を検証するためのユーティリティー関数を使用することができます。共有サービス・プロバイダーは簡単に、このセキュリティーおよびトラスト・インフラストラクチャーを利用して、シームレスなセキュリティー・ロール・ベースの認証を統合したシングル・サインオン・ソリューションを作成することができます。

共有サービス・プロバイダーのセキュリティー統合は、完全にポリシー駆動であり、管理ロールの権限が必要となります。PureApplication System は、共有サービスのデプロイ時にトラスト関係をプロビジョニングします。共有サービスをデプロイするには、特権付きワークロード管理とフル・アクセス権のセキュリティー・ロールが必要です。共有サービス・プロバイダーは、ポリシーのアサーションによって、追加のセキュリティー・ロールを要求することができます。例えば、共有サービスの監視でハードウェア・ステータスを監視する必要がある場合には、ハードウェア管理の読み取り専用ビューのセキュリティー・ロールを要求するポリシー・アサーションを指定します。この場合、デプロイヤーがこの共有サービスをデプロイするには、特権付きワークロード管理とフル・アクセス権のセキュリティー・ロールに加え、ハードウェア管理の読み取り専用ビューのセキュリティー・ロールと委譲のセキュリティー・ロールも必要になります。

以上の説明をまとめると、共有サービス・セキュリティー・メカニズムは、セキュリティー・インフラストラクチャーを使用するのは単純でなければならないという設計原則、そして以下の設計原則を明らかに示しています。

  1. 共有サービスのセキュリティーは、セキュリティーおよびトラスト・インフラストラクチャーをベースに統合されること。
  2. 共有サービスのセキュリティー・ロールのプロビジョニングは、セキュリティー・ロールの委譲ポリシーと一貫していること。
  3. セキュリティー・クライアント・ユーティリティー・ライブラリーは、共有サービスの開発者から、セキュリティー・インフラストラクチャーおよびトラスト・インフラストラクチャーを完全に見えなくします。

プラットフォームのセキュリティー

PureApplication System は、管理インフラストラクチャーの関与という点で非常に単純なパターンから極めて高度なパターンに至るまで、仮想アプライアンス、仮想システム、仮想アプリケーションという 3 つのデプロイメント・パターンをサポートします。仮想アプライアンスをデプロイするということは、基本的には仮想マシン・イメージをデプロイすることです。仮想マシン上でアプリケーションのランタイム環境をセキュアにする全責任は、デプロイヤーにあります。仮想システム・パターンの場合には、デプロイヤーにはトポロジーを管理する責任が課せられます。vSys パターンのセキュリティーに関しては、基本的に仮想アプライアンスと同様です。つまり、デプロイヤーがアプリケーション・ランタイム環境をセキュアにする責任を持ちます。仮想アプリケーション・パターンは、ソフトウェア・アプリケーション、アプリケーション・プラットフォーム (WebSphere Application Server など)、ソフトウェア・コンポーネントの依存関係 (DB2、LDAP など)、そしてデプロイ後のアプリケーションのランタイム動作を制御する一連のサービス品質ポリシーといったものが、あらかじめ定義されて 1 つにまとめられた専門知識の集合です。セキュリティーに関しては、仮想アプリケーション・プラグイン・フレームワークがセキュアな実行ランタイム環境を提供します。この環境は、さらにカスタマイズすることが可能です。

仮想アプリケーション・デプロイメントの実行環境には、攻撃対象領域を最小限にする以下のセキュリティー制御が備わっています。

  • デプロイメントは、独自のトラスト・ドメインで実行されます。
  • デプロイメントの仮想マシン同士が通信するのは、デプロイメント境界内においてです。
  • デフォルトでは、仮想アプリケーションのファイアウォール・プラグインが、SSH ポートと PureApplication System 管理ポートを除くすべてのポートをクローズします。
  • SSH には、鍵長 2048 ビットの RSA 鍵ベースの認証およびデータ暗号化が必要です。
  • OS root アカウント・ログインは無効にされます。
  • デプロイヤーは非 root ユーザー・アカウントに SSH でログインします。
  • WebSphere Application Server のリモート管理インターフェースは無効にされます。
  • WebSphere Application Server のセキュリティーを有効にするには、ソフトウェアが生成する管理アカウント・パスワードを使用します。
  • WebSphere Application Server の LTPA 鍵、鍵ストア、およびトラスト・ストアは、デプロイメントのすべてのインスタンスで使用する PureApplication System ストレージに保管されます。
  • WebSphere Application Server は、ファイル・ベースの組み込みユーザー・レジストリーを使用するように構成されますが、LDAP サーバーへのリンクがパターンに含まれる場合には、LDAP ユーザー・レジストリーを使用します。

アプリケーションのセキュリティー

アプリケーションでは、ベンダーのセキュリティー・ソリューションとカスタム・セキュリティー・ソリューションを利用することができます。PureApplication System は、ユーザーがカスタム・セキュリティー・ソリューションを統合するために既存のパターンを変更したり、新規パターンを作成したりできるように、仮想システム・スクリプト・パッケージと仮想アプリケーション・プラグイン・フレームワークを提供しています。WebSphere Application Server には、標準の認証サービス拡張ポイント (User Registry アダプター、Trust Association Interceptor、JAAS ログイン・モジュールなど) および権限付与サービス拡張ポイント (JACC (Java Authorization Contracts with Containers) など) が用意されています。


セキュリティー・フィックスの管理

緊急フィックスは、ユーザーが誤って、または意図的に悪用してシステム・リソースにダメージを与える可能性のある OS、ミドルウェア、およびアプリケーション製品の問題と脆弱性に対処します。「PureApplication System Emergency Fixes (PureApplication System 緊急フィックス)」パネルには、緊急フィックスを管理してデプロイメントに適用するのに役立つユーティリティーが提供されています。緊急フィックスに含まれる service.xml ファイルに、その緊急フィックスを適用すべき仮想イメージのバージョンと、その緊急フィックスを適用する緊急性を定量的に記述する重大度フィールドが指定されています。

緊急フィックスは、IBM またはその他のベンダーにより提供され、IBM Fix Central からダウンロードすることができます。あるいは、独自の緊急フィックスを作成することも可能です。緊急フィックスを PureApplication System にロードするには、ワークロード・コンソールを使用します。緊急フィックスは、管理ソフトウェアにより、管理ネットワーク経由で RAID ディスク・ストレージにアップロードされます。緊急フィックスをデプロイ先の VM に適用するプロセスは以下のように自動化されています。

  • vApp の場合には、デプロイ先の VM ごとのエージェント・プロセスが、ファイバー・チャネル・ディスク・ネットワーク経由でイメージを VM に転送してフィックスを適用します。
  • vSys の場合には、管理ソフトウェアが、ディスク・ネットワーク経由でイメージを VM に転送し、すべてのサーバーを停止してフィックスを適用した後、すべてのサーバーを再起動します。

管理システムの保護

管理システムの完全性と機密性の保護に役立つように、PureApplication System の計算ノードは、ハード・ディスクおよびソリッド・ステート・ディスクに保管されるデータとバイナリー・イメージを暗号化します。この暗号化に使用されるのは、256 ビットの鍵による AES (Advanced Encryption Standard ) 暗号化アルゴリズムです。暗号鍵はディスクには保管されず、代わりにシステム管理コンピューター回路基板上の TPM (Trusted Platform Module) に保管されます。構成データとバイナリー・イメージは、OS ユーザーに対して可視にされません。OS ユーザーがログインする制限付きシェルは、シェル・スクリプトをサポートしていません。このため OS ユーザーは OS プロセスを開始することも停止することもできず、ファイルシステムにアクセスすることもできないようになっています。


サービスとリカバリー

PureApplication System のシステム・バックアップ・ユーティリティーは、システム障害時のシステム・リカバリーに備え、完全バックアップと増分バックアップの両方をサポートしています。データの機密性を保護するために、バックアップ・イメージは 128 ビットの鍵を使用した AES アルゴリズムで暗号化されます。一方、対称鍵は RSA 公開鍵で暗号化され、バックアップ・イメージとは別に保管されます。RSA 秘密鍵と証明書のペアをインポートすることも、自己署名付き証明書と 2048 ビットの秘密鍵を生成することもできます。外部バックアップ・イメージ・ストレージ・サーバーとの通信では、SSH を使用して機密性を保護します。

PureApplication System にはシステム・サービス・アカウントが組み込まれており、権限を与えられた IBM サービス担当者はこのアカウントを使用してシステムの問題を診断したり、下位レベルのリカバリー・アクションを行ったりすることができます。この組み込みシステム・サービス・アカウントは、デフォルトで無効にされています。これは、ハードウェア管理のフル・アクセス権を持つユーザーがアクティブにする必要があります。アカウントをアクティブにした後、IBM サービス担当者が IBM Service Center にサービス・アカウント・パスワードを要求することも必要です。このパスワードは一定の期間 (最大 36 時間) だけ有効であり、特定の PureApplication System でしか使用することができません。これにより、IBM サービス担当者はハードウェア・リソースと下位レベルの構成データにフル・アクセスすることができ、クラウド・グループ管理情報 (例えば、クラウド・グループ、IP グループ、仮想マシンの構成およびステータス) には読み取り専用アクセスすることができますが、仮想リソース構成を変更することも、さらに重要なことにワークロード・リソースおよびデータを利用することもできません。


まとめ

システム、ソフトウェア、ロード・バランシング・ポリシー、組み込みのソリューション・エキスパートの知識が統合された IBM PureApplication System は、アプリケーションのデプロイ時間を大幅に短縮するとともに、リソース使用量を顕著に改善します。PureApplication System は、セキュリティー・エンジニアリング・フレームワークのガイドラインと、業界のベスト・プラクティスのセキュリティー原則を採用することで、さまざまなレベルでのリソース分離およびセキュリティー防御によってシステムをセキュアにするのに役立てます。完全性、機密性、可用性、アクセス制御に対処するだけでなく、PureApplication System はユーザー・アクションの包括的な監査レコードをファイルに保存します。その目的は、ユーザーにそのアクションの責任を取らせること、そしてセキュリティー攻撃を検出してダメージの大きさを評価するフォレンジック分析のための情報を提供することの 2 つです。

この記事では IBM PureApplication System のセキュリティーとリソースの分離機能について概説し、企業のユーザー管理をネットワーク・インフラストラクチャーに統合する際の使用シナリオについて概説しました。この記事で提供した情報が、リスク・マネジメントとセキュリティー・コンプライアンスの要件に対処する上で皆さんのお役に立つことを願っています。


謝辞

PureApplication System セキュリティーおよびトラスト・インフラストラクチャーの設計、開発、テストには多くの方々が貢献してくれました。特に、John Y Chang 氏、Leo Uzcategui 氏、Ki Park 氏、Yuhsuke Kaneyasu 氏、Douglas Shue 氏、Marcos Lohmann 氏、Bertrand Chiu 氏、Ajay Apte 氏、Mark Li Yi 氏、Rohith Ashok 氏、Roy F. Bradson 氏、Xi Wang 氏、Kin Ueng 氏、Lewis Lo 氏、Patrick Davis 氏、Kristin R. Whetstone 氏、Nico Hao R Li 氏、Ankit Patel 氏、Barbara Vander Weele 氏、Nick Hill 氏、Jose Ortiz 氏、Lin Sun 氏、Marco Ling Lan 氏、Los Liang Wang 氏、Matthew J. Sheard 氏、Matthew K. Vaughton 氏、Mickael Madson 氏、Jay W Warfield 氏、Donald R. Wood 氏、James K. Kochuba 氏、Aaron J Quirk 氏、Iqbal Umair 氏、Christopher M. Laffoon 氏、Tamiko D Watts 氏、Vishwanath Venkataramappa 氏、Wendy Wen Hsu 氏、James Mullineux に感謝いたします。また、レビューして意見を寄せてくれた Ajay Apte 氏、Rohith Ashok 氏、Mark Li Yi 氏、Joe (J.P.) Wigglesworth 氏、Andrew Grohman 氏、Scott J. Tunley 氏、Rama Vykunta 氏にも感謝いたします。

注記

有効なセキュリティー・プラクティスについて: IT システム・セキュリティーには、企業の内外からの不正なアクセスの防止、検出、および対処によってシステムと情報を保護することが不可欠となります。不正なアクセスは、情報の改ざん、破壊、流用、誤用という結果を招いたり、システムにダメージが与えられる原因、またはシステムが悪用 (他への攻撃を含む) される原因になったりしかねません。完全にセキュアであると見なせる IT システムまたは製品というものはありません。また、不正な使用やアクセスを完全に防ぐことが可能な製品またはセキュリティー対策というものもありません。したがって、IBM のシステムおよび製品は、包括的なセキュリティー手段の一部として設計されています。包括的なセキュリティー手段には当然、さらに他の操作手順も関わってきます。また、最も効果的なセキュリティー手段にするために、他のシステムや製品、またはサービスが必要になることもあります。IBM は、IBM のシステムおよび製品が悪意のある行為または不正な行為から完全に逃れられるとは保証していません。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere, Mobile development
ArticleID=855149
ArticleTitle=IBM PureApplication System のセキュリティーと信頼
publish-date=01172013