クラウドのセキュリティー・シナリオについてのレビューと要約

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」より

この記事では、Cloud Computing Use Cases Discussion Group によって作成された「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」のセキュリティーに関するセクションを概説し、クラウドに移行する際にアーキテクトと開発者が考慮しなければならないセキュリティー問題に焦点を当てます。

developerWorks cloud computing editors, developerWorks Editors, IBM

developerWorks Cloud computing のエディターたちは、アプリケーションをより簡単に、より効率的にクラウドに移動するために皆さんが必要としている技術リソースのタイプについてのご意見を心待ちにしています。



2012年 4月 26日

このトピックに関するスキルを磨いてください

このコンテンツは、皆さんのスキルを漸進的に磨いていくための Knowledge Path の一部です。次のリンクをご参照ください。 クラウド・コンピューティング: Software as a Service の紹介

この記事では、Cloud Computing Use Case Discussion Group による「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」の内容を見ていきます。このホワイト・ペーパーは、900 人を超える参加者で構成されるオープン Web コミュニティーによって作成されたものであり、このコミュニティーで共有された情報がぎっしり詰まっています。Open Cloud Manifesto のサポーター・グループから始まった Cloud Computing Use Case Discussion Group は、今では大企業および中小企業、政府機関、コンサルタント、ベンダー、およびユーザーの代表者が参加するまでに成長しました。

Cloud Computing Use Case Discussion Group ではクラウド標準の開発に関して、以下の 3 つの原則に合意しています。

  • クラウドのユーザーと協力して行うこと
  • クラウド標準の開発はオープンであり、お客様中心で行われること
  • 可能な場合は必ず既存の標準を使用すること

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」の目標

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」で目標としているのは、「相互運用性、統合の容易さ、そして移植性を確実にするために、クラウド環境で標準化する必要のある機能と要件を明らかにすることです。このホワイト・ペーパーで説明するすべてのユース・ケースは、閉ざされた専有技術を使用せずに実装可能でなければなりません。クラウド・コンピューティングは、ベンダー・ロックインを最小限に抑え、お客様の選択肢を増やしながらオープン環境として進化していく必要があります」。

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー」で取り上げている話題は広範囲に及ぶため、1 回の記事で文書全体を網羅するつもりはありません。このレビューでは、クラウドでのセキュリティー問題およびシナリオについての Discussion Group の評価結果に焦点を絞ります。エンタープライズ・レベルのクラウド・コンピューティングでは、セキュリティーは、最初に検討しなければならない点の 1 つです。

クラウドのセキュリティー全般に関するトピック

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー」では、開発者とアーキテクトがクラウドへの移行を計画する際に検討しなければならないセキュリティー問題を取り上げています。このホワイト・ペーパーで強調しているのは、他のシステム環境と同じく、クラウド・コンピューティング全体も、「標準に基づく一貫した透明なセキュリティー・フレームワーク」の必要性を実証する理想的な例と見なせるということです。個々のクラウド・デプロイメント・モデルが違っていても、このことに変わりはありません。

クラウドでのセキュリティーについて考える際に、他の環境とは対照的な大きな違いがあるとしたら、それは何でしょうか?その違いは主に技術に関する問題ではありません。それは、クラウド・サービス・プロバイダーがインフラストラクチャーを制御することから、企業が機密データとアプリケーションに対する制御を失ってしまうのではないかという認識を持っていることです。この問題に対処するために検討するトピックには、以下に挙げるものがあります。

  • 法律および規制。技術的な問題ではありませんが、法律および規制により、機能要件よりも優先されるセキュリティー要件が決まります。
  • セキュリティー・コントロール。利用者にインフラストラクチャーが十分にセキュアであると安心させるために、クラウド・プロバイダーが提供できなければならない最小限のセキュリティー・コントロールのリストがあります。
  • セキュリティー・フェデレーション・パターン。インフラストラクチャー・プロバイダーがセキュリティー・コントロールを提供することを可能にする、最小限のセキュリティー・フェデレーション・パターン (メカニズム) のリストもあります。

このホワイト・ペーパーを完成させたコントリビューター

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」のコントリビューター (敬称略): Dustin Amrhein、Patrick Anderson、Andrew de Andrade、Joe Armstrong、Ezhil Arasan B、James Bartlett、Richard Bruklis、Ken Cameron、Reuven Cohen、Tim M. Crawford、Vikas Deolaliker、Andrew Easton、Rodrigo Flores、Gaston Fourcade、Thomas Freund、Valery Herrington、Babak Hosseinzadeh、Steve Hughes、William Jay Huie、Nguyen Quang Hung、Pam Isom、Sam Johnston、Ravi Kulkarni、Anil Kunjunny、Thomas Lukasik、Bob Marcus、Gary Mazzaferro、Craig McClanahan、Meredith Medley、Walt Melo、Andres Monroy-Hernandez、Dirk Nicol、Lisa Noon、Santosh Padhy、Greg Pfister、Thomas Plunkett、Ling Qian、Balu Ramachandran、Jason Reed、German Retana、Bhaskar Prasad Rimal、Dave Russell、Matt F. Rutkowski、Clark Sanford、Krishna Sankar、Alfonso Olias Sanz、Mark B. Sigler、Wil Sinclair、Erik Sliman、Patrick Stingley、Robert Syputa、Doug Tidwell、Kris Walker、Kurt Williams、John M. Willis、Yutaka Sasaki、Michael Vesace、Eric Windisch、Pavan Yara、Fred Zappert。

規制と法律の問題は、技術的な性質のものだけではありません。これは比較的単純な問題なので、最初に、このトピックから取り上げます。多くの政府が、特定のデータの物理的および論理的な廃棄に影響を及ぼす厳しいデータ・プライバシー法を設けているのは紛れもない事実です。同じような状況は、企業や非政府組織でもポリシー、あるいは業界固有の規制という形で存在します。これらの規制は、クラウド内で実行されるアプリケーションにも適用されるため、法律と規制に従うことが、他のあらゆる要件よりも優先されます。法律、規制、ポリシーを避けて通る道はありません (結局のところ、データやアプリケーションの所有者がそのような逃げ道をとることを許さないはずです)。これらの技術的ではない検討事項が、クラウドを使用するかどうかの技術的な選択自体を左右することもあります。

セキュリティー・コントロール

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー」では、セキュアなクラウド環境を適切に実現するために必要なセキュリティー・コントロールとして、以下のセキュリティー・コントロール (および、該当する場合は関連する標準) について説明しています。

資産管理。クラウド・インフラストラクチャーを構成するすべての物理/仮想ハードウェア、ネットワーク、およびソフトウェア資産を管理できなければなりません。これには、監査およびコンプライアンスのために資産にアクセス可能であることも含まれます。

暗号化: 鍵と証明書の管理。Web を開発したことがあれば考えるまでもないことですが、標準に基づく暗号化機能を使用して、保存されている情報や転送中の情報のセキュリティーを確保できなければなりません。標準: KMIP (OASIS Key Management Interoperability Protocol)

データやストレージのセキュリティー。データを暗号化されたフォーマットで保存できなければなりません。また、一部の利用者は、そのデータを他の利用者のデータとは別に保存する必要があることを認識することも重要です。標準: IEEE P1619 (IEEE Security in Storage Working Group による策定)

エンドポイントのセキュリティー。利用者は、クラウド・リソースへ接続するエンドポイントをセキュアにすることができなければなりません (つまり、ネットワーク・プロトコルやデバイス・タイプにより、エンドポイントを制限できるということです)。

イベントの監査とレポーティング。言うまでもないことのように思えるかもしれませんが、セキュリティーの重要な鍵の 1 つは、何が起きているのかを把握できることです。特に、システム障害や不正侵入、そしてあからさまな攻撃に関しては、迅速な対応が不可欠です。

ID 情報、役割、アクセス制御、属性。これは、クラウド・コンピューティングに伴うフェデレーションという側面を強調しています。すべてのリソースに対して、それらのリソースが相互運用可能な 1 つのシステムにあるかのようにアクセスできなければ、クラウドは存在することはできません。それと同じく、個人およびサービスの属性が「マシンで読み取れる一貫した方法」で定義されていない限り、クラウドでの効率的なセキュリティーは実現しません。標準: SAML (OASIS Security Assertion Markup Language) および X.509 証明書 (ITU Public Key and Attribute Certificate Frameworks Recommendation の一部)

ネットワーク・セキュリティー。スイッチ、ルーター、およびパケット・レベルでネットワーク・トラフィックをセキュアにすることができなければなりません。IP スタック自体もセキュアにする必要があります。

セキュリティー・ポリシー。アクセス制御およびリソース割り当てを効果的に行うには、一貫した堅牢な方法でセキュリティー・ポリシーを定義、解決、実施することができなければなりません。一貫した堅牢な方法により、ポリシーを自動的に適用できるようにします。標準: XACML (OASIS eXtensible Access Control Markup Language)

サービスの自動化。セキュリティー・コンプライアンスの監査をサポートする形で、セキュリティー管理の流れやプロセスを管理および分析するための自動化された手段 (セキュリティー・ポリシーや使用許諾契約書への違反を自動的に報告するなど) が必要です。

ワークロードおよびサービスの管理。定義されたセキュリティー・ポリシーおよび使用許諾契約書に従い、サービスを構成、配置、監視できる必要があります。標準: SPML (OASIS Service Provisioning Markup Language)

セキュリティー・フェデレーション・パターン

フェデレーションは、クラウド・コンピューティングを実現するための根本的な概念です。フェデレーションによって、独立した多数のリソース (資産、ID 情報、構成、その他) を単一のリソースのように動作させることができます。ホワイト・ペーパーでは、プロバイダーによるセキュリティー・コントロール要件の実装方法を定義できるように、以下のフェデレーション・パターンについて概説しています。

トラスト。2 つの関係者が信頼関係を定義できるようにするために、認証機関が提供する機能です。認証機関は資格情報 (X.509 証明書など) を交換し、交換した資格情報を使用してメッセージをセキュアにし、署名付きのセキュリティー・トークン (SAML など) を作成することができます。トラストは、すべてのセキュリティー・フェデレーション・パターンの土台となります。

ID 情報管理。ユーザーの資格情報 (ID、パスワード、証明書、等々) を受け付け、そのユーザーを識別する署名付きセキュリティー・トークンを返す ID プロバイダーを定義するための機能です。サービス・プロバイダーは、ユーザーを知らない場合でも、信頼する ID プロバイダーから返されたトークンがあれば、ユーザーにアクセスを許可することができます。

アクセス管理。この機能を使用して、セキュリティー・トークンを評価するポリシーを (例えば XACML で) 作成することにより、リソースへのアクセスをきめ細かく管理します。複数の要因を使用することで、リソースに対する複数のアクセス・レベルを決定することができます。

シングル・サインオンおよびサインオフ。1 つの信頼する認証機関からの資格情報を基に、ログイン処理を統合 (フェデレーション) することができます。このパターンを適用するには、ID 情報管理パターンが適用されていることが前提となります。

監査とコンプライアンス。複数のドメインに分散されているコンプライアンス・データを収集して、サービス・レベル・アグリーメントやその他の規制のコンプライアンスを文書化するには、監査をフェデレーションする必要があります。

構成管理。サービス、アプリケーション、および仮想マシンの構成データをフェデレーションする機能です。

セキュリティーの既存のベスト・プラクティスは、まさにその言葉どおり、「セキュリティーのベスト・プラクティス」です。ベスト・プラクティスは一般に標準という結果になるため、ホワイト・ペーパーでは、設計者や開発者に、フェデレーション・パターンを提供する方法として、まずは既存の標準を利用するように推奨しています。

セキュリティーに関するユース・ケース・シナリオ

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」では、さまざまなアプリケーション・タイプ、デプロイメント・モデル、パターン、および役割を取り上げた共通シナリオを作成し、以下の内容を説明しています。

クラウド・コンピューティングでのお客様の経験 + セキュリティー要件 = クラウドの有効使用

ホワイト・ペーパーで説明しているユース・ケースには、以下のような目的があります。

  • 相互運用性と標準に関する議論を進めるための、お客様の経験に基づく実際的なコンテキストを提供します。
  • 既存の標準を使用すべき部分を明確にします。
  • 標準化が必要な部分を明確にします。
  • ビジネスに対し、オープンなクラウド・コンピューティングの重要性を具体的に明らかにします。

以降の各セクションでは、最初に一般的なシナリオを紹介した後、以下の内容を記載します。

  • 「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」の説明を直接引用して、問題のシナリオを説明します。
  • クラウド・ソリューションによって問題がどのように解決されたかを説明します。
  • 要件、コントロール、およびソリューションを実現するために採用されたフェデレーション・パターンを記載します。

慎重に扱う必要のあるデータと、過負荷にさらされたプライベート・インフラストラクチャー

このシナリオの内容:

ある保険会社では、保険金支払要求アプリケーションを使用して、保険契約者および保険契約者が被った物的損害に関するデータを収集しています。現在、ハリケーンが米国の湾岸地域に上陸することが予想されており、莫大な物的損害が発生する可能性があります。そうなった場合は保険金支払要求が激増し、この会社の IT インフラストラクチャーに多大な負荷がかかります。

この会社は、パブリック・クラウド・プロバイダーを利用し、予想される需要に対処する仮想マシンを使用することを決定しました。

この場合、会社のシステムと、クラウド・プロバイダーがホストする仮想マシンの間のアクセスを制御し、社内の許可された外交員だけにアクセスを限定する必要があります。

また、アプリケーションのクラウド・ベースのインスタンスによって作成されたすべてのデータを企業のファイアウォールの内側にセキュアに転送する必要もあります。

最後に、クラウド・プロバイダーは、仮想マシンをシャットダウンする度に、アプリケーションやアプリケーション・データの痕跡を確実に消去する必要があります。

解決されるお客様の問題: この会社は、パブリック・クラウド環境を利用することにより、通常の 10 倍になる可能性があるワークロードを処理できるようになります。このワークロードに長期的に対処できるように物理リソースを購入するよりも、一時的にパブリック・クラウドを利用してワークロードの処理を任せるほうが、はるかにコストがかかりません。

要件とコントロール:

  • 要件: アプリケーションへのアクセスを特定の役割に制限すること
    セキュリティー・コントロール: ID 情報/役割/アクセス制御/属性、資産管理、ネットワーク・セキュリティー
  • 要件: VM のシャットダウン時にアプリケーションやデータのすべての痕跡を削除すること
    セキュリティー・コントロール: ワークロードおよびサービスの管理

フェデレーション・パターン: トラスト、アクセス管理、構成管理

限られたリソースと、新しいアプリケーションのニーズ

このシナリオの内容:

あるオンライン小売業者では新しい Web 2.0 店頭アプリケーションを開発する必要がありますが、自社の IT 担当者や既存のリソースに負担をかけたくないと考えています。

この会社は、クラウド・ベースの開発環境と共に、ホストされている開発ツールおよびリソース・コード・リポジトリーも提供するクラウド・プロバイダーを選択しました。新しいアプリケーションが多様なタイプのマシンおよび大量のワークロードを扱えるようにするため、テスト環境には、別のクラウド・プロバイダーを選択しました。

クラウド・ベースの開発およびテスト用に 2 社のプロバイダーを選択していることから、フェデレーションが極めて重要となります。

解決されるお客様の問題: クラウドでホストされる開発ツールを使用することにより、各開発者のマシンにツールをインストールして、構成、同期、管理する必要がなくなります。大規模な製品を作成しなければならないとしても、クラウド・インフラストラクチャーをスケール・アップして、規模の要件を満たすことができます。クラウドにテスト対象のファイルの新しいバージョンがある場合には、テスト環境でその最新バージョンにアクセスすることができます。

テストに関して言えば、(静的 Web ページに対してテストするのではなく) 静的 Web ページよりもサーバーとのやり取りがはるかに多い Web 2.0 インターフェースに対してテストすることで、実際にアプリケーションを使用した場合の弾性 (負荷の増加と多様な VM イメージに合わせて対応する能力) をより正確に判断できるようになります。

要件とコントロール:

  • 要件: 開発者ツールのインストールと保守を 1 ヶ所で集中的に行うこと
    セキュリティー・コントロール: 資産管理
  • 要件: VM のシャットダウン時にアプリケーションやデータのすべての痕跡を削除すること
    セキュリティー・コントロール: ワークロードおよびサービスの管理
  • 要件: 開発およびテスト・クラウドでシングル・サインオンを行うこと
    セキュリティー・コントロール: 暗号化、エンドポイントのセキュリティー、ID 情報/役割/アクセス制御/属性、ネットワーク・セキュリティー
  • 要件: ソース・コードやテスト計画へのアクセスを制御すること
    セキュリティー・コントロール: 資産管理、ID 情報/役割/アクセス制御/属性
  • 要件: ビルドおよびテストで VM を自動的に起動およびシャットダウンできること
    セキュリティー・コントロール: サービスの自動化
  • 要件: ビルドおよびテストで VM の使用量およびパフォーマンスに関する統計情報を報告できること
    セキュリティー・コントロール: イベントの監査とレポーティング

フェデレーション・パターン: トラスト、ID 情報管理、アクセス管理、シングル・サインオン、監査とコンプライアンス、構成管理

機密商品情報の保管と、機密商品情報へのアクセス

このシナリオの内容:

ある金融投資会社は新しい投資商品を発売する予定です。そこで、会社の代理店および系列会社に新商品の利点と特徴を伝えるために多くの商品映像を制作しました。これらの映像データは非常にデータ・サイズが大きく、しかもオンデマンドで提供しなければなりません。それには、クラウド環境に映像データを保存することで、この会社のインフラストラクチャーに対する要求が軽減されます。

ただし、これらの映像データへのアクセスは厳しく制御する必要があります。商品競争上の理由で、認定を受けている代理店のみが映像を表示できるようにする必要があります。さらに重要な制約として、商品販売前の沈黙期間中は映像データを含む商品の詳細を内密にしておかなければならないという規制があります。

この会社は、映像データをセキュアにホストおよび配信するために、パブリック・クラウド・ストレージ・プロバイダーを使用することにしました。

クラウド・ソリューションは、会社のセキュリティー・ポリシーを施行する監査可能なアクセス制御メカニズムで映像データへのアクセスを制御する必要があります。

解決されるお客様の問題: パブリック・クラウド・ストレージを使用することにより、この会社は自社のデータ・センターのリソースを補強せずに膨大なデータを管理することができます。このケースに関連する (ビジネスに関する事項よりも優先される) 政府規制は、クラウド・プロバイダーがコンプライアンスを保証できなければ、そのクラウド・プロバイダーは選択肢に入らないことを意味します。

要件とコントロール:

  • 要件: 映像データへのアクセスを特定の役割に制限すること
    セキュリティー・コントロール: ID 情報/役割/アクセス制御/属性、資産管理、ネットワーク・セキュリティー、ポリシー
  • 要件: クラウドに保存されているデータをセキュアにすること
    セキュリティー・コントロール: 暗号化、データやストレージのセキュリティー
  • 要件: クラウドに保存されているデータを会社のファイアウォールの内側に転送できること
    セキュリティー・コントロール: 暗号化、データやストレージのセキュリティー、エンドポイントのセキュリティー、ネットワーク・セキュリティー

フェデレーション・パターン: トラスト、ID 情報管理、アクセス管理、監査とコンプライアンス

セキュリティー・コントロールとシナリオ、フェデレーション・パターンとシナリオの相互参照

以下に記載する 2 つの表に、セキュリティー・コントロールとシナリオの関係、そしてフェデレーション・パターンとシナリオの関係を要約します。最初の表でセキュリティー・コントロールとお客様のシナリオの関係を要約し、2 番目の表でフェデレーション・パターンとシナリオの関係を要約します。

表 1. セキュリティー・コントロールとシナリオ
セキュリティー・コントロール負荷の急増/ 保険会社開発およびテスト/ 小売業者セキュアなストレージ/ 金融投資会社
資産管理+++
暗号化 ++
データやストレージのセキュリティー  +
エンドポイントのセキュリティー ++
イベントの監査とレポーティング + 
ID 情報、役割、アクセス制御、属性+++
ネットワーク・セキュリティー+ +
ポリシー  +
サービスの自動化 + 
ワークロードおよびサービスの管理++ 
表 2. セキュリティー・フェデレーション・パターンとシナリオ
フェデレーション・パターン負荷の急増/ 保険会社開発およびテスト/ 小売業者セキュアなストレージ/ 金融投資会社
トラスト+++
ID 情報管理 ++
アクセス管理+++
シングル・サインオン + 
監査とコンプライアンス ++
構成管理++ 

まとめ

「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」の著者たちは、「利用者がデータおよびアプリケーションをクラウドに移行しようとする際に、最も多く生じる質問は、一貫してセキュリティーに関するものです」と記しています。

クラウドでのセキュリティーに関して「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー 第 3 版」が出している結論は以下に示すように明らかです。

  • クラウド・コンピューティングは、管理者、計画者、開発者がこれまで一般的な IT セキュリティーを検討する際に直面したことのない新しいセキュリティー上の問題をもたらすわけではありません。
  • 一般的な IT のセキュリティーとクラウドでのセキュリティーの実装および施行方法の違いは、パブリック・クラウドを使用する場合には常にサード・パーティーが関与してくる点です (オンプレミス・クラウドは別の話です)。
  • クラウド・プロバイダーが重要な情報に関する透明性を持ち、情報を開示することが不可欠です。
  • 既存の標準でセキュリティーの要件を満たせる場合、クラウド・ユーザーはプロバイダーにその標準を使用するように求めなければなりません。そのような標準がない場合には、コミュニティーに要件を満たす標準を開発するように求める必要があります。

このレビューと要約では、まずクラウドのセキュリティーについての基本を説明し、その後でクラウドのセキュリティーに関する要件とコントロールを説明するシナリオの概要を紹介しました。ぜひとも、この記事がベースとしている「クラウド・コンピューティング ユース・ケース ホワイト・ペーパー」をひと通り読んでください。このホワイト・ペーパーでは Cloud Computing Use Case Discussion Group が、開発者と計画者が重要なデータとアプリケーションのためのセキュアな環境を実現する上でクラウド・プロバイダーに求めるべき要件を分析しています。

参考文献

学ぶために

  • この記事のベースとなっているのは、Cloud Computing Use Cases Group に属するエキスパートによる文書です。このホワイト・ペーパーの第 3 版は、PDF 版 [英語 | 中国語 (繁体字) | 中国語 (簡体字)] で用意されています。PDF 版の他、他のファイル形式でも入手できます。(訳注: 日本語版を含む第 4 版に、http://cloudusecases.org/ からアクセスできます)
  • Open Cloud Manifesto は、クラウド・コンピューティングのオープン性を保持していくための原則について述べたものです。
  • KMIP (OASIS Key Management Interoperability Protocol) は、暗号化システムと、新旧を含めた多様なエンタープライズ・アプリケーション (E メール、データベース、ストレージ・デバイスを含む) との間の通信に単独で対応する包括的なプロトコルです。
  • IEEE P1619 は、保管データの暗号化を標準化するためのプロジェクトですが、一般的には、保管データの保護および対応する暗号鍵管理のための一連の標準が含まれる IEEE P1619 SISWG (Security in Storage Working Group) の取り組みを指します。
  • SAML (OASIS Security Assertion Markup Language) は、ユーザー認証、資格付与、および属性に関する情報を伝達するための XML ベースのフレームワークです。
  • X.509 証明書 (ITU Public Key and Attribute Certificate Frameworks Recommendation の一部) は、シングル・サインオン (SSO) および特権管理インフラストラクチャー (PMI) の公開鍵インフラストラクチャー (PKI) に関する ITU-T 標準です。X.509 は何よりもまず、公開鍵証明書、証明書失効リスト、属性証明書、および証明書パス検証アルゴリズムの標準フォーマットを指定します。
  • XACML (OASIS eXtensible Access Control Markup Language) は、権限付与および資格付与ポリシーを表現するためのコア XMLスキーマです。
  • SPML (OASIS Service Provisioning Markup Language) は、ユーザー、リソース、およびサービス・プロビジョニングに関する情報を交換するための XML ベースのフレームワークです。
  • developerWorks のクラウド開発者向けリソースで、クラウド開発プロジェクトを作成しているアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  • developerWorks の Open source リソースで、オープンソースのアプリケーションおよびサービス開発者たちの知識と経験を調べて共有してください。
  • developerWorks の Technical events and webcasts で最新情報を入手してください。

製品や技術を入手するために

  • developerWorks から直接ダウンロードできる 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=Cloud computing, Open source
ArticleID=810981
ArticleTitle=クラウドのセキュリティー・シナリオについてのレビューと要約
publish-date=04262012