レベル: 中級 Mark O'Neill, CTO, Vordel
2009年 6月 16日 この 3 回からなるシリーズでは、ハイブリッド・クラウド・アプリケーションの作成について説明しています。今回はその第 3 回、つまり最終回として、クラウド・コンピューティングのガバナンスとセキュリティーを検証します。まず、第 2 回の HybridCloud アプリケーションを基に、このアプリケーションで使用する Amazon の SQS (Simple Queue Service) にアクセス制御ポリシーを追加する方法を検証します。そしてクラウド・サービスに対してこの HybridCloud アプリケーション自体を認証する方法と、Amazon の S3 (Simple Storage Service) にログ監査トレールを追加する方法について詳細に調べます。最後に、Google Apps が OAuth をどのように使用しているか、また Force.com のクラウド・サービスでは不注意にも DoS （サービス拒否) 攻撃を受けてしまうのを避けるために、テストを組み込むことを要求していることについて説明します。
はじめに
クラウド・ガバナンスでは、クラウド・サービスの使い方にポリシーを適用する必要があります。クラウド・ガバナンスについて考えるためには、クラウド・ガバナンスとは逆の状況を考えてみることが有効です。つまり、何ら監督されることなく組織がクラウド・サービスを好き勝手に利用できる状況を考えてみるのです。そうした状況によって生じる混乱を避けるためには、クラウド・サービスの使い方にポリシーを適用することで、個人情報がクラウドに漏洩しないように管理し、クラウド・サービスを過度に使用することがないように管理する必要があります (クラウド・サービスが有料であることを忘れてはなりません)。ガバナンスとセキュリティーが整備されれば、クラウド・コンピューティングを安心して、安全に使用することができます。
SOA ガバナンスからの教訓
SOA が採用されるようになるにつれ、ガバナンスという言葉が注目されるようになりました。SOA の世界では、ガバナンスは、(Web サービスのポリシーを定義する) 設計時のガバナンスと、(そうしたポリシーをリアルタイム・トラフィックに実際に適用する) 実行時のガバナンスに分けられていました。
 |
頻繁に使用する頭字語
- API: Application Programming Interface
- DSA: Digital Signature Algorithm
- IP: Internet Protocol
- IT: Information Technology
- REST: Representational State Transfer
- SOA: Service Oriented Architecture
- SSL: Secure Sockets Layer
- URI: Universal Resource Identifier
- WSDL: Web Services Description Language
- XML: Extensible Markup Language
|
|
SOA でのサービスと同じように、クラウド・プラットフォームは主に Web サービスの API を使ってアクセスされることが多いため、クラウド・ガバナンスは SOA の場合と同じようなものと見なせるかもしれません。少なくとも、SOA ガバナンスの背後にある原則は再利用することができます。
通常、SOA ガバナンスはレジストリーがあることを前提にしています。レジストリーは SOA ガバナンスの中心であり、ユーザーはレジストリーを調べれば SOA のサービスを見ることができ、またそうしたサービスに適用されるポリシーもレジストリーを調べればわかります。標準的な WS-Policy、そしてそれを補完する WS-Attachment 仕様によって、SOA のサービスにポリシーを割り当てることができます。そのためサービスには、実質的にそのサービスのポリシーへの「ポインター」が含まれることになります。このサービスとポリシーとの関係をレジストリーが管理します。
SOA ガバナンスで重要なもう 1 つの機能が、SOA ガバナンスの製品によって提供される、サービスのライフサイクル管理です。ライフサイクル管理というのは、サービスに対する変更を管理、追跡できる機能や、誰がサービスを変更できるのかを管理できる機能を指します。ライフサイクル管理が整備されると、誰がサービスを作成したのか、誰がサービスを変更したのか、いつ変更が行われたのかを組織が判断できるようになります。
では、SOA ガバナンスがあれば、クラウド・ガバナンスに関する問題は解決済みなのでしょうか。そうではありません。SOAP と WSDL は一般的な SOA ガバナンスで使用される 2 つの標準ですが、通常のクラウド・サービスでは送受信されるメッセージは SOAP ではなく、またサービスを定義する際に WSDL は使用されません。これはつまり、SOA ガバナンスのレジストリーにサービスをインポートすることは単純ではない、ということです。クラウド・コンピューティングで使用される Web サービスは SOAP と WSDL をバイパスし、代わりに軽量の REST スタイルのサービスを使用します。この軽量の REST スタイルのサービスは比較的単純であるため、開発者の間でよく使われています。
仮想マシンもクラウド・コンピューティングを SOA と区別する特徴の 1 つです。クラウド・コンピューティングでは、Web サービスを利用するだけではなく、仮想マシンも利用します。Amazon の EC2 (Elastic Compute Cloud) 環境は、サービスのセットではなく、一種の仮想ホスティング環境と見なすことができます。従って Amazon EC2 のガバナンスは仮想マシンのガバナンスの一例と見なすことができます。仮想マシンのガバナンスの中でも、特に仮想マシンのデプロイメントは混乱に陥りがちです。これは、組織がさまざまな仮想マシンを使用してしまい、それらの仮想マシンが、ドキュメント化されていない部分で互いに少しずつ異なるためです。VMware や Citrix Xen のユーザーの多くがよく知っているように、個人のユーザーにとってさえ、仮想マシンの管理は簡単ではありません。この問題が、組織にとっては何倍にもなること、さらには仮想マシンがサードパーティーのクラウド・サービスでホストされている場合にはもっと大きくなることを想像してみてください。
一方、VM (仮想マシン) のガバナンスによるメリットには、SOA ガバナンスにおける「ライフサイクル・ガバナンス」によるメリットと重なる部分があります。Amazon EC2 クラウドの世界では、VM は AMI (Amazon Machine Image) のインスタンスです。特定のユーザーが特定の AMI をデプロイできるようなルールを強制できる機能は重要です。さらに詳細なレベルでは、誰が VM をリブートでき、誰が既存の VM 環境に容量を追加でき、誰が既存の仮想マシン・インスタンスを削除できるのか、等の管理を行える機能が重要です。
今挙げた最後の項目、つまり Amazon の AMI インスタンスの削除は特に重要です。AMI インスタンスを使用すると、組織はそれに対する料金を支払う必要があるからです。料金は、(イメージが実行状態になっている場合の) 使用時間とデータ・トラフィックが基になります。クラウド・ガバナンス・システムを用意しない限り、必要ないにもかかわらず実行される AMI マシン・インスタンスが大量に発生し、本来必要のないコストが発生します。一方、その逆の場合もあります。つまりクラウド・ガバナンス・ソリューションを用意しない限り、有用な AMI インスタンスが誤って削除されてしまう可能性があります。こうした面倒を起こす AMI インスタンスの問題は、AMI インスタンスのライフサイクルを管理することによって回避することができます。これは SOA の場合とまったく同じです。SOA の場合も、ガバナンスのフレームワークを用意しない限り、面倒を起こすサービスが組織内に大量に増えてしまう傾向があり、そうした問題に SOA ガバナンスで対応するのです。
プロセスであり、製品ではありません
SOA ガバナンスはプロセスであり、製品ではない、とよく言われます。クラウド・ガバナンスにも、このルールが当てはまります。ガバナンス・ルールを強制できるかどうかは、ガバナンス・フレームワークが用意されていることを開発者が認識するかどうかにかかっています。例えば SOA ガバナンスのレジストリーが使われている場合、このレジストリーに Web サービス (特に、開発者による WSDL 定義) を登録する必要がある、と開発者が認識しなければなりません。登録しない限り、その Web サービスは対象として認識されません。開発者に対して、クラウド・サービスを使用していることを開発者の組織に登録するよう要請がされない場合、SOA ガバナンスの場合と同様のことがクラウド・ガバナンスにも起こります。
SOA ガバナンスの世界では、レジストリーによって提供される設計時のガバナンスの他に、レジストリーの中で構成されたルールを強制するための実行時のガバナンスもあります。通常、サービスに対してそうしたルールを強制するポイントは、組み込みエージェントであったり、ネットワークを中継するポイント (XML ゲートウェイなど) であったりします。
SOA ガバナンスには、レジストリー、そして実行時にルールを強制するポイント (エージェントや XML ゲートウェイなど) といった、SOA ガバナンスを実践する手段となるものがありますが、そうしたものがクラウド・コンピューティングの世界にはありません。これはつまり、クラウド・コンピューティング・サービスのユーザーにとって、さまざまなサービスや関連するポリシーをすべて見られる中心的なポイントがないということです。また、接続先のクラウド・コンピューティング・サイドには (クラウド・サービス・プロバイダー自身によって) ポリシーが強制されますが、そのポリシーはクライアント・サイドには強制されません。これはクラウド・コンピューティングのガバナンスにとって非常に重要な課題です。
面倒を起こすクラウド
多くの面で、クラウド・コンピューティングは、Web サービスの初期の頃に似ています。つまり当時は、この新しい技術をプロジェクトに使用することを開発者が個別に判断し、そして実際に使用していました。これは企業の IT 管理に認識されることなく行われていました。その後、遅ればせながら、ガバナンスの傘が追加されるようになりました。現状では、大部分の組織はクラウド・コンピューティングに関して、ガバナンス以前の段階にあります。ある開発者が、あるプロジェクトのために AMI イメージを使おうとすることは特別なことではありません。最初のプロトタイピングで、彼ら個人の Amazon アカウントとクレジットカードを使うことさえあるのです。
クライアント・サイドのガバナンス ― アクションが欠落していませんか？
通常、クラウド・サービス・プロバイダーは、サービスのダウンタイムに関する情報を事前に顧客に知らせる必要がありません。また当然ですが、予想外の原因によってサービスの停止が発生した場合、クラウド・サービス・プロバイダーは、そのことをクラウド・サービスのユーザーに対して伝える義務はありません。クラウド・サービスの応答時間と可用性を監視するためには、クライアント・サイドのコンポーネントが必要です。このクライアント・サイドのコンポーネント (例えば XML ゲートウェイなど) によってクラウド・プラットフォームへの接続を監視するのです。接続に時間がかかる場合には、XML ゲートウェイがアラートを発行するか、あるいは救済アクションを実行します (例えばキャッシュにあるレスポンスを使用するなど)。このようにキャッシュを使用することにより、クラウド・サービスが停止したことによる影響を軽減することができます。
また、クラウドに送信されるデータをクライアントの XML ゲートウェイによってスキャンし、個人データや会社の機密データの漏洩を防ぐこともできます。さらに、クラウド・プロバイダーに送信する前にデータを暗号化したり、あるいは選択的に暗号化したりする方法もあります。例えば、クラウド・コンピューティング・プロバイダーに送信されるデータを XML ゲートウェイによって識別不能にし、それらのデータと個人情報との関連付けができないようにすることもできます。
Vordel XML Gateway クラウド版などの XML ゲートウェイは、クラウド・プラットフォームに送信されるトラフィックをフィルタリングし、またクラウド・サービスへのアクセスにポリシーを適用します。こうした機能があることから、XML ゲートウェイはクライアント・サイドにとって、クラウド・サービスに接続するための入り口の役割を果たします。
HybridCloud アプリケーションを管理する
このシリーズの第 2 回目で、Amazon Web サービスを使用する HybridCloud アプリケーションの作成を開始しました。クラウドのガバナンスとセキュリティーについて広い視野で検討するために、このアプリケーションが Amazon Web サービスによってどのように認証されるのか、またこのアプリケーションの使い方にポリシーを適用する方法について調べてみましょう。
Amazon サービスでのキー
HybridCloud アプリケーションは Amazon SQS クラウド・サービスを利用します。他の AWS (Amazon Web サービス) の場合と同様、SQS では、アクセス・キー ID と、その ID に関連付けられた秘密鍵を使う必要があります。前回の記事では、HybridCloud の Java™ コードの中で Amazon のキーが使われていることを説明し、またこれらのキーを、Amazon SQS クラウドを使用する HybridCloud アプリケーションの中にハードコーディングしました。しかし、これらのキーは一体何なのでしょう。これらのキーの詳細を調べてみましょう。
|
RSA とは何を意味するのか
RSA 非対称暗号アルゴリズムの名前の中にある「RSA」という文字は、このアルゴリズムを最初に作成した人達、「Rivest、Shamir、Adleman」を表します。
|
|
PKI (Public Key Infrastructure: 公開鍵基盤) をよく理解している読者は、この 2 つのキーが実際には (デジタル署名や暗号化用の RSA アルゴリズムや DSA アルゴリズムで使われている) 非対称鍵ペアに関係する公開鍵と秘密鍵だと思っているのではないでしょうか。しかし Amazon のキーは典型的な公開鍵と秘密鍵ではありません。アクセス・キー ID は識別子として使われ、AWS サービスにアクセスするユーザーを識別します。アクセス・キー ID はユーザー名の概念と似ており、リクエストに入れて暗号化せずに送ることができます。実際、Amazon S3 クラウド・サービスがオンライン・ストレージに使用される場合、URL の一部にはアクセス・キー ID が含まれています。例えば、あるユーザーに「123456789」というアクセス・キー ID が割り当てられた場合、Amazon S3 上の (そのユーザーの) ファイル・バケットに格納されているファイルを取得するために使われる URL は、https://s3.amazonaws.com/123456789- bucketname/filekey となります。
| |
Amazon S3 で定義されるバケットはファイルを格納するためのストレージ・コンテナーにすぎません。このため、S3 上で必要となるスペースを定義するには、バケットを作成し、そのバケットに Amazon システム全体で一意の名前を付ければよいだけです。
|
|
アクセス・キー ID は URL を見ると明確にわかります。これはつまり、(ファイルにアクセスできるように Amazon S3 のバケットにリクエストをルーティングする) ネットワーク構成機器のログにも、アクセス・キー ID が保存されるということです。従って、すべてのルーターまたはプロキシーがアクセス・キー ID を入手することができます。アクセス・キー ID はとても簡単に検出されてしまうため、認証用には向いていません。アクセス・キー ID はあくまでも識別用であり、認証用ではありません。
認証に使われるのはシークレット・アクセス・キーです。しかし、このキーがクライアントから AWS サービスに送信されることはありません。シークレット・アクセス・キーは、このキーを所持していることの証明としてのデジタル署名のフォームを作成するために使われます。このように、所持していることを証明するという方式は、SSL ハンドシェーク・プロトコルと似ています (SSL ハンドシェーク・プロトコルでは、クライアントが実際に秘密鍵を所持していることを暗号化によって証明し、キー自体は送信しません)。クライアントがこのキーを使えるということは、そのキーがそのクライアントの管理下にあることを示します。
PKI での公開鍵と秘密鍵のペアの場合、これらのキーの間には数学的な関係があります。秘密鍵を使って暗号化されたデータは、対応する公開鍵を使って復号することができます。これは PKI ベースのデジタル署名の基本です。鍵を持っていない限り署名を作成することはできませんが、その署名の検証は公開鍵にアクセスできる人ならば誰でもできます (公開鍵は通常 X.509 証明書から取得されます)。
Amazon Web サービスのモデルのシークレット・アクセス・キーには、そうした性質がありません。このシークレット・アクセス・キーは、AWS リソース (クラウド・サービスなど) を使用する開発者と Amazon.com との間で共有される秘密と考えることができます。シークレット・アクセス・キーを他の人と共有してはなりません。そんなことをすると、その人はシークレット・アクセス・キーを使って Amazon クラウド・サービスにアクセスするかもしれません。クラウド・サービスの使用料金は当該開発者に請求されるため、シークレット・アクセス・キーが絶対に悪意のある人の手に渡らないようにしなければなりません。そうでないと、巨額の請求をされるかもしれません。第三者がシークレット・アクセス・キーにアクセスしたと疑われる場合には、新しいシークレット・アクセス・キーをオンラインで生成する必要があります。
この HybridCloud アプリケーションでは、このキーはアプリケーション自体の中にハードコーディングされていますが、Java の難読化ツールを使用しなければ、攻撃者がこのアプリケーションをリバースエンジニアリングしてキーを発見するかもしれません。このことから、Java の難読化ツールを使用する必要があります (「参考文献」を参照)。
HybridCloud アプリケーションのポリシー
このシリーズの第 2 回目で、HybridCloud アプリケーションが X 線画像のデータを Amazon SQS に送信することを説明しました。当然ながら X 線画像は個人の医療データなので、Amazon SQS サービスに送信されるこのデータをクライアント・サイドでスキャンし、プライベートなデータが必要最低限になるようにする必要があります。データが Amazon SQS に到達してからでは遅すぎます。ここにも、クラウド・コンピューティング・リソースへの接続にローカルのゲートウェイを使う理由があります。
HybridCloud アプリケーションのセキュリティーに関するもう 1 つの注意点として、Amazon SQS サービスへのアクセスを制限し、信頼できるクライアント以外はサービスにアクセスできないようにする必要があります。そのためには Amazon SQS のポリシーを使用します。Amazon SQS のポリシーは JSON (JavaScript Object Notation) で定義されます。
HybridCloud アプリケーションに適用できそうな Amazon SQS ポリシーをいくつか検証してみましょう (このアプリケーションの詳細とソース・コードは、このシリーズの第 2 回を参照してください)。
まず、下記のポリシーでは、Amazon Web サービスのアカウント番号が 1234567890 の開発者のみがキューにアクセスできること、またそのキューをリソースの URI が /987654321/queue1 の開発者が所有していることを指定しています (リスト 1)。
リスト 1. Amazon SQS ポリシーを検証する
{
"Version": "2008-10-17",
"Id": 12345678901234567890
"Statement":
{
"Sid":"Queue1_SendMessage",
"Effect": "Allow",
"Principal": {
"AWS": "1234567890"
},
"Action": "SQS:SendMessage",
"Resource": "/987654321/queue1"
}
}
|
では、このポリシーを詳細に検証してみましょう。最初にバージョン情報があります。現状で、このフィールドに対する有効な値は 2008-10-17 のみです。次に、このルールの ID があります。この ID は Amazon Web サービス全体の中で一意の識別子でなければなりません。”Statement” は実際のポリシーです。この中を見ると、リソースが Amazon SQS キューであることがわかります。ここでは、ある特定の “Principal” (この場合は特定の AWS ユーザー) が特定のキューにアクセスできること、またその “Principal” 以外はキューにアクセスできないことを指定しています。
また、日付、時刻、ソース IP アドレスに基づいて SQS キューへのアクセスを制御するポリシーを設定することもできます (リスト 2)。
リスト 2. SQS キューへのアクセスを制御するポリシーを設定する
"Condition" : [{
"DateGreaterThan" : {
"AWS:CurrentTime" : "2009-04-10T09:00:00Z"
}
"DateLessThan": {
"AWS:CurrentTime" : "2009-04-10T17:30:00Z"
}
"IpAddress" : {
"AWS:SourceIp" : ["4.3.2.1/24"]
}
}]
|
この場合、コード化されたポリシーは、クライアントがキューにアクセスできるのは 2009年4月10日の午前9:00 から午後5:30 の間のみで、しかも特定の IP アドレスの範囲からのみであることを指定しています。
各キューへの特定のアクセス権の設定と削除には、それぞれ AddPermission 関数と RemovePermission 関数を使います。
Amazon SQS のポリシーは、当然ながらクラウド・サービス・プロバイダーで実行されます。ただし、クラウド・サービス・プロバイダーに送信する前にデータの暗号化やスキャンを行う場合には、そのための理想的なツールとなるのはクライアント・サイドの XML ゲートウェイ装置です。
これで、HybridCloud アプリケーションが Amazon SQS サービスにアクセスする際のアクセス制限方法を理解できたので、今度は Amazon、Google、Salesforce によるクラウドのセキュリティー・ソリューションを簡単に調べてみましょう。
Amazon S3
Amazon S3 (Simple Storage Service) はオンライン・ストレージのためのクラウド・サービスです。Amazon S3 は、写真共有サイト SmugMug (リンクは「参考文献」を参照) などの Web サイトのバックエンド・ストレージとして使われています。もちろん、Amazon S3 を企業の内部データ用に使うこともできます。ただしコンテキストによっては、Amazon S3 に格納されるデータは危険にさらされるおそれがあります。データが他人に見られたくないものである場合には、Amazon SQS サービスに送信する前に XML ゲートウェイを使ってデータを暗号化した方が賢明です。さらに、S3 に格納されているデータに対して Amazon SQS からどのようなアクセスが行われたのかを追跡する必要があります。プライバシーの問題の他に、S3 を使用することによって料金が発生するため、S3 がどのような使われ方をしているのかを追跡する必要があるのです。誰しも高額な請求に驚かされたくはありませんし、そうした請求に至った S3 の使用についての完全な監査がなされていないことを望んではいないはずです。こうしたさまざまな理由から、Amazon S3 サービスに対してロギングを行うことが重要なのです。
Amazon S3 のバケットに対してロギングを行うための簡単な方法として、Cloudberry Explorer アプリケーションを使用して、S3 インスタンスに対するロギングをオンにする方法があります (詳細は「参考文献」を参照)。Cloudberry Explorer は、実質的に Amazon S3 に対する GUI フロントエンドになります。Cloudberry Explorer では単純にバケットを選択し、ツールバーの Logging ボタンをクリックします。次に Use logging チェックボックスにチェックを入れ、ドロップダウン・リストから、ログ・ファイルを格納することになるバケットを選択します。この記事の例の場合には cloudberry.log です。実際にはログは Amazon のクラウド・サービスに書き込まれます。ログ・ファイルが書き込まれるバケットは、ロギング対象のバケットと地理的に同じ場所になければなりません (つまり米国にある S3 のバケットを利用しているアプリケーションは、米国にある S3 のバケットにログを書き込む必要があります)。ログ・ファイルの分は毎月の請求書に追加されますが、これはログ・ファイルが Amazon S3 のストレージを使用するためです。とはいっても、Amazon S3 ストレージ・サービスにアクセスしたユーザーの監査トレールを作成するための費用として、ログ・ファイルのための費用はわずかな額にすぎません。
Google Apps
Google は、クライアント・サイドの Java アプリケーションを Google Apps クラウド・サービスに接続するための、SDC (Google Secure Data Connector) というツールを提供しています。このツールを利用すると、ローカル・ネットワークと Google Apps との間のリンクを暗号化することができます。SDC は主に、(Google がホストする) Google Apps アプリケーションをローカル・ネットワークに接続するために使われます。SDC は、Google Apps でない限りこの接続を利用できないように作られています。また SDC は、どの Google Apps ガジェットがどの内部システムにアクセスできるのかを制限するフィルターとしても動作します。これはファイアーウォールのルールとよく似ていますが、SDC の場合はアプリケーション・レベルで動作します。SDC では、どのアプリケーションにアクセスできるかを制御できるだけでなく、ユーザー・レベルの制御を追加することもできます。この機能を利用すると、組織は誰がどの Google Apps サービスにアクセスできるのかを制御することができます。
Google Apps の SDC 用の識別フレームワークでは OAuth が使われています。例えば、ホストされている Google Apps サービスは OAuth を使うことで、ローカル・アプリケーションに対して Google Apps サービス自体 (そしてそのユーザー) の認証を要求することができます。現状では OAuth は広く採用されているわけではありませんが、Amazon が OAuth を支持したことで、その状況が変わるかもしれません。
Force.com での安全対策と「使いながらのテスト」
このシリーズの第 1 回で説明したように、SalesForce による Force.com クラウド・サービスでは Apex というプログラミング言語を使用しています。Force.com では、Force.com のクラウド・プラットフォームでホストされる Apex コードが必ず要求どおり動作するように、そのコードにアサートを含めることを要求しています。そうしたコードは、開発される Apex クラスの少なくとも 75%、できれば 100% をカバーしている必要があります。これは、不注意にもシステム全体に対する DoS（サービス拒否) 攻撃を受けてしまうのを避けるための手段として採用されています。例えば、無限ループに入る可能性があるコードや、無限ループに入らなくても過度のリソースを使用する可能性のあるコードは、そうした事態を検出できるテスト・コードの中にラップしておく必要があります。Force.com ではさらなる安全を期すために、スタックの深さやストリング・サイズなどの数的指標に対してルールを強制するための、governor と呼ばれる制約を適用することも義務付けています。
他のクラウド・プロバイダーには Force.com と似たテスト規定はありませんが、たとえクラウド・プラットフォームとして Force.com を使わない場合であっても、彼らの推奨事項に従っておくのは得策です。DoS 攻撃に対して保護すると同時に、クラウド・プロバイダーから予想外に高額の使用料を請求されて驚くことがないようにしておく必要があります。
まとめ
クラウドのセキュリティーに取り組むために、Cloud Security Alliance など、いくつかの活動が行われています。現状では、Amazon、Google、Force.com などのプロバイダーが先頭に立ってサービス・プロバイダーのレベルを維持しようとしています。しかしすべての人々がそれを信用しているわけではありません。例えば Federal Trade Commission (米連邦取引委員会) はクラウド・コンピューティングに関するリスクを調査するように要請を受けていますが、これはデータ管理に関する問題があると認識されているためです。クラウド・ガバナンスとセキュリティーに関する意識が高まるにつれ、クラウド・ガバナンスとセキュリティーに関して提供されるサービスも一層発展するものと期待することができます。
参考文献 学ぶために
製品や技術を入手するために
- Amazon S3 のための無料の Windows® クライアント、Cloudberry Explorer を試してみてください。
- 写真共有サイト、SmugMug を訪れてください。このサイトでは Amazon S3 をバックエンドのストレージとして使用しています。
- IBM 製品の試用版をダウンロードするか、あるいは IBM SOA Sandbox をオンラインで試し、DB2® や Lotus®、Rational®、Tivoli®、WebSphere などが提供するアプリケーション開発ツールやミドルウェア製品をお試しください。
議論するために
著者について | | | Mark O'Neill は XML ネットワーキング企業である Vordel の最高技術責任者です。彼は『Web Services Security』の著者でもあり、『Hardening Network Security』の共著者でもあります (どちらもMcGraw-Hill/Osborne Media から出版されています)。彼は Vordel の製品開発ロードマップの責任者であり、フォーブス誌の Global 2000 に選定された全世界の企業や政府機関に対して、XML、Web サービス、SOA 技術を戦術的かつ戦略的に採用するための助言を行っています。彼は Trinity College Dublin で数学と心理学の学位を取得しており、またオックスフォード大学でのニューラル・ネットワーク・プログラミングの卒業資格を持っています。彼はマサチューセッツ州ボストンに住んでいます。 |
記事の評価
| 
