連載：.NET中心会議議事録 第2回 現場開発者視点で答える「Windows Azure業務アプリ開発の実際」 デジタルアドバンテージ　一色 政彦 2010/03/26
Page1 Page2 Page3 Page4 Page5

■セキュリティ・障害補償とサポート

新野　それでは、Windows Azureに関する詳細にブレークダウンしていきます。「セキュリティやサポート」「ライセンス形態や課金」「Windows Azureに関する性能」という3つのアジェンダを残しており、最後にQ＆Aとして客席から質問を受け付けます。まず「セキュリティやサポート」に関する問題提起を、＠IT／Insider.NETの一色さんからお願いします。

一色　今回のセミナーでは、できるだけ皆さんの疑問に真摯（しんし）に答えようという目的があります。当初は技術寄りの実践的な開発方法などの質問を想定していましたが、開催前に事前アンケートを取ってみるとセキュリティや障害補償やサポートという、導入前の基礎的な部分、つまり「本当にクラウドやWindows Azureを使って大丈夫なのか？」という部分に質問が集中していました。そこでまず、この「セキュリティ・障害補償とサポート」というテーマについて議論します。

　セキュリティとしては、例えばクラウドでは基本的に、データを外部にある第三者のデータセンターやサーバに預けることになり、情報漏えいや、海外にデータを置くことによる問題などが懸念されます。海外にデータを置く問題とは、例えば何らかの事件があってFBI（＝米国の連邦捜査局）などにデータをすべて没収されたときに、顧客は納得してくれるのかなどです。

●セキュリティ

砂金　セキュリティについては、皆さんからいろいろなご意見をいただいており、耳が痛いです。結論からいうと、真摯（しんし）に対応を進めているところです。現在のところ、いろいろといたらない点はあると思いますが、「時間が解決するだろう」と見ていただきたいです。

　セキュリティについていうと、前提としてWindows Azureが置かれているデータセンターが、ほかのサーバ環境と比較してセキュアか否かを考える必要があります。例えば一般的なオンプレミスのサーバ・ルームでは、誰かが管理者権限を持っているので、その人が悪意を持った行動をすれば、情報が漏えいするリスクがあります。一方のクラウドのデータセンターでは、そもそも物理的にセキュリティの高い場所にサーバを置いていますし、しかも「どのサーバにどのデータが入っているのか」は誰にも分かりません。そういった点を考慮したうえで、「オンプレミスとクラウドのどちらがセキュアですか？」という問いを、Windows Azureを検討している企業には考えていただいています。

　それでも、「クラウドは不安」と考える企業はたくさんあります。そういう場合には、「不安なデータは持ち出さない、クラウドに置かないでください」ということが、現時点でマイクロソフトがいえるセキュリティ・ガイドラインになります。ソフトウェア＋サービスというマイクロソフトの提言は、そのためのものです。例えば「住所や名前、性別などの情報は手元に置く。しかし、その人がどういう行動をしたかを追跡するためのID情報や、商品マスターなど、万が一漏えいしても損害が出ないと考えられるものは、クラウドに置く。その2つのデータをアプリ内で統合しましょう」というクラウドの活用手法が、現時点でのマイクロソフトのスタンスです。

　もちろん、「世の中のクラウドに対する考え方や法整備が、クラウドの活用に追いついてきて、すべてのデータをクラウドに置いても問題ない」という世の中に今後なっていくかもしれません。そうなれば、マイクロソフトのスタンスも変化しますが、現時点ではまだそういう状況ではないと考えています。ですので、セキュリティで不安なものは、無理せずオンプレミスとクラウドに適切に使い分けることをお願いしたいです。

シグマコンサルティング 橋本 圭一

橋本　セキュリティに関して、わたしが顧客との会話の中で一番困ったのが、「どのデータをクラウドに置くのか、どのデータはオンプレミスに置くのか」という方針を決めることでした。調べてみると、現時点ではまだ法整備が進んでおらず、お役所や業界団体の考えに振り回されることがあります。ですので、いま必要なのは、クラウドに関するセキュリティ・ガイドラインです。

市川　わたしはWindows Azureのデータセンターにおけるセキュリティに関しては信頼しています。別に盲信しているわけではなく、もちろん根拠があります。マイクロソフトは、セキュリティ対策として行っていることを資料「サービスの運用とセキュリティ管理（概要）」（下の表を参照）で提供しています。そういった資料の内容を開発ベンダが十分理解して、セキュリティに不安を持つエンド・ユーザー顧客にきちんと説明すれば、「マイクロソフトで実績もあるので、大丈夫ですね」と受け入れられることが多いです。

カテゴリ	対策	内容
機密性	物理的対策	・24時間、365日の監視
		・監視カメラによる監視
		・モーション・センサーの設置
		・生体認証による入退出管理
		・データセンター内への車での乗り入れ禁止
		・セキュリティ境界線突破時のアラーム通報
	ネットワーク対策	・CyberTrustによるセキュリティ認定（四半期ごとに実施）
		・9階層にわたるセキュリティ対策
	情報漏洩対策	・サポート／サービス・チームは、SecureID カードもしくは 　 RSH Secure ID Tokenを利用した認証を行う
		・データは全て128ビットで暗号化 ・全通信は HTTPS
完全性	データ保存	・Raid 5+1によるデータ保存
		・Disk to Disk to Disk（ミラーリングで最低4コピー保持）
	データ・バックアップ	・日時バックアップの実施
		・Disk to Disk to Diskバックアップ
可用性	物理的対策	・ジオ・リダンダント構成
		・複数の発電機を装備
		・電源は複数の発電所から2系統
		・各ラックでの電源2重化
		・発電機用の燃料は、地震などで道路が寸断された場合には空輸
		・バッテリーによるバックアップ
		・コンピュータ・コントロールによる空調制御
	ネットワーク対策	・フル・フェイル・オーバー
監査・ コンプライアンス	監査・コンプライアンス	・SAS 70 Type II
		・CyberTrust認定
		・専任のサービス・アドミン・チーム
		・ITIL／MOFベースの運用
		・ISO17799ベースの運用
		・e-Discovery対応可能
サービスの運用とセキュリティ管理（概要）（マイクロソフト提供）
※この資料では、Windows Azure Platformだけでなく、BPOSの運用／セキュリティ要件も含まれている。

　作り手側がなぜWindows Azureのセキュリティに不安を持つかというと、やはり情報が不足しているからです。例えば、1年ぐらい前から疑問に思っていることですが、DDoS攻撃を受けた場合に課金はどうなるかということです。Windows Azureは帯域の使用量に応じて課金されるようになっています。つまりDDoS攻撃を受けると、その課金が跳ね上がる可能性があるのです。Amazon EC2の場合は、これに関して一定のガイドラインを公開しています。ただしその内容でも、わたしはまだまだ不十分だと考えていますが。Windows Azureの利用を顧客に安心してもらうためにも、こういった危惧（きぐ）に対して勇気を持てる資料を、マイクロソフトに公開してほしいと思います。

一色　セキュリティについて補足しておくと、SQL Azureはファイアウォールもあるので、どこからでもアクセス可能なわけではありません。またSQL Azureとの通信時には、 データは暗号化されます。セキュリティ面では強度が高いと考えてよいと思います。

　さらにWindows Azureは障害対策もしっかりなされているようです。先日、Windows Azure開発担当者であるスティーブ・マークス（Steve Marx）氏から直接聞いた話ですが、Windows Azureをビル・ゲイツ氏に初めて評価してもらう際、ゲイツ氏はサーバ・ルームにある、そこら中のプラグやケーブルを抜き始めて、当然Windows Azureは機能しなくなったそうです。その経験を基にして、現在、Windows Azureではサーバ・ルームのケーブルをあちこち抜いて、それでも機能が停止しないかをテストし、実際にそれぐらいでは停止しなくなっているそうです。Windows Azureではこのように、障害に対して真剣に取り組んでいるという話は聞いています。

●障害補償

一色　続いて障害補償はどうでしょうか？ 例えば他社のサーバなので、そこで障害が起きたときに自分で解決できません。そういったとき「どうなるのだろう？」といった点です。

砂金　漏えいした場合の補償は、残念ながらありません。また、クラウド・プラットフォームが提供するSLA（＝サービス・レベル契約）には、（基本的に）稼働保証しかありません。Windows Azureの場合は「99.95％動きます」という保証ですが、稼働率がそれ以下になってしまった場合に、マイクロソフトに賠償責任はあるかというと、ありません。その場合には、「申し訳ありません。先月分の課金を少し割り引かせていただきます」という補償内容になっています。例えばデータ漏えいが本当に起きてしまったとして、それを基に訴訟を起こしたとしても、マイクロソフトの法務チームが注意深く契約事項を作成していると思いますので、まず勝てないと思います。ですので、クラウドやWindows Azureはそういうものだと理解したうえで、きちんとアーキテクチャ設計を考えていく必要があります。

橋本　データ漏えいについては、Windows Azureの構造や不具合に起因する場合と、開発者により記述された脆弱（ぜいじゃく）性のあるコードに起因する場合の2種類が考えられます。現実的には、どちらかというと後者の方が多いのではないでしょうか。しかしながら、後者の場合でも、新聞などのマスメディアで発表されるときには、「Windows Azureでデータ漏えい」という見出しが付いてしまいそうですが。

会場　（笑）

新野　例えば開発者がSQLインジェクション可能なコードを残したままで、アプリをクラウド上に公開してしまい、悪意のある者によってデータが抜き取られてしまったような場合ですね。

橋本　同様の事件が、mixiアプリで発生したことがありました。問題の原因はアプリ側にあるのに、新聞では「mixiでデータ漏えい」となっていました。

　しかし、こういったアプリ側のセキュリティ強度は、開発者側の努力によって高めることができます。例えばマイクロソフトのMSNというサイトがありますが、MSNのセキュリティ・ポリシーは強度が高く、専属のセキュリティ・チームも配備されています。実際に、SQLインジェクションなどの幅広い脆弱（ぜいじゃく）性のテストを行っているはずです。そういったマイクロソフトが蓄積しているノウハウやツールを、Windows Azure開発者にも提供してはいかがでしょうか。そうすれば、データ漏えいのような事故も減っていくのではないかと思います。

新野　セキュリティ検証の手段を提供するのは、非常に大切なことだと思います。例えばクラウドに対してセキュリティ検証のために勝手にアタックしてしまうと、問題になる可能性があります。セールスフォース・ドットコムの方にセキュリティ検証の方法についてお話をうかがったところ、「郵便局がForce.comを採用する際に、それがセキュアなのかどうかを調査しなければならなかった。しかし、勝手にForce.comをアタックするわけにはいきません。そのため、セールスフォース・ドットコムに相談したうえでセキュリティ検証を行った」そうです。クラウド上でセキュリティを高めるには、クラウド・プラットフォーム提供者と利用者側のベンダが、ある程度手を結んで、協力する必要がありますね。

砂金　そういったセキュリティ検証が必要な方は、事前にマイクロソフトにご相談ください。勝手にセキュリティ検証を行うと、悪意のある攻撃と判定されて、その後、思わぬ事態に発展する可能性もありますので。事前にご連絡をいただければ、対策をご一緒に考えさせていただきます。まったくセキュリティ検証が不可能というわけではありませんので。

一色　補足として1点いっておきたいのは、Windows Azureを始める前に、SLAは隅から隅までじっくり読んで納得しておいた方がいいということです。けっこう、驚くべきことが記述されている場合があります。例えば、「Windows Azureコンピュートのインスタンスは2つ以上起動していないとSLAは適用されない」といったことが書かれていたりします。当然、1つのインスタンスからSLAが適用されるだろうなどと勝手な思い込みをしていると痛い目に遭うかもしれません。

●マイクロソフトによるサポートと開発者支援

砂金　サポートとしては、Windows Azureの場合、大きく分けて3つあります。

　1つ目は、「Windows Azureのライセンスを、どうやって購入したらいいのか分からない」という場合にお使いいただけるMicrosoft Online Servicesカスタマー・サポート。

　2つ目は、「このデータセンターは、いま正常に動いていますか？」という場合にお使いいただけるダッシュボード。

　3つ目が、「こういうふうに動かそうと思っているが、正常に動かないので解決したい」という場合にお使いいただける開発サポートです。

　1つ目と2つ目は一部英語ですが、日本語化に尽力している最中です。最後の3番目は、Windows Azureに限ったサービスではなく、.NET開発をされる皆さんであれば、プレミア・サポートが提供されています。日本語によるサポート体制は、順次整備していきます。

　あともう1つ。MSDNフォーラムで、Windows Azureに関する質問を日本語で問い合わせられるフォーラムはまだありません。現在、このフォーラムの作成を画策しています（※執筆途中でこちらに公開された）。

Windows Azure Community 市川 龍太

市川　MSDNフォーラムの中には、やはりマイクロソフト社員も返答者としてご参加いただきたいです。その方が、気軽に技術的な質問に答えていただける場があるということで、Windows Azureに取り組む開発者も安心できます。

　Force.comに取り組む開発者と以前、会話したことがあります。そのとき、「Force.comで技術的な問題が発生したときには、どうするのか？」と尋ねたところ、「Force.comには掲示板があり、そこに直面している問題を書き込むと、本当にすぐにForce.comの開発担当者が回答してくれる」そうです。クラウドを実際に開発している担当者以上に詳しく説明できる人は世の中にいないと思いますので、それを聞いて非常に心強いなと思いました。

　もちろんMSDNフォーラムのWindows Azure英語版掲示板でも、マイクロソフトの開発担当者からの返答もありますが、やはり多くはMicrosoft MVPの方々からの返答が多いです。ここは、マイクロソフトのエンジニアやプロパーの方々が参加する掲示板を企画して、プレミアム・サポートではなく無償の提供をぜひ考えてほしいと思います。

●トラブル発生時の対応方法

新野　橋本さんは、実際にトラブルにあって、MSDNフォーラムのWindows Azure英語版掲示板に質問を書き込まれたのですよね？

橋本　はい。＠IT／Insider.NET向けに「業務システムでAzureを使うための42の覚え書き」という記事を執筆しました。その公開前日に、シンガポールにあるWindows Azureのデータセンターにサンプル・アプリの最新版をデプロイしようとしたときに、デプロイ自体は正常に済んだのですが、その後、実際にWebサイトにアクセスしてみると「404 File not found.」のエラーが表示されてしまっていました。「どうもDNSで障害が起きているらしい」と考え、Windows Azureカレント・ステータスのダッシュボードを見てみると、使っていない「AppFabric Service Bus [Southeast Asia]」でエラーが発生していました。実際に使っている「Windows Azure Compute [Southeast Asia]」は正常だったのですが、シンガポールのデータセンターで何かしら障害が発生していたようです。そのあたりの障害検知機能はまだ正確ではないと感じました。

　初めてのトラブルだったので、どう解決すればよいのか分かりませんでした。そこで、MSDNフォーラムのWindows Azure英語版掲示板でトラブルの内容を書いてみたところ、同じ問題で困っているインドの方もいらっしゃって、「やはりシンガポールで障害が発生しているのだな」という確信を深めました。その後、マイクロソフトの方から「障害の問題については、オンラインのサポートに問い合わせてほしい。そちらに問い合わせると8時間以内に解決する」というアドバイスが書き込まれました。

一色　ちなみに、Windows Azureが提供する各サービスの健康状態を見るダッシュボードについては、わたしも不満があります。一応、それぞれにRSSフィードが提供されており、これを購読しておけば、障害が起きているかどうかをチェックできます。しかし、何せRSSフィードはプル型なので、RSSフィードの状態が変化していないかを絶え間なくポーリングしながら確認し続けなければならないという弱点があります。ですので、状態が変更したとき、すぐに通知されるプッシュ型のサービスが早急に必要ではないでしょうか。

　また市川さんの話にも通じるところがありますが、Windows Azureの開発者や運用担当者が直接、何が起こっているかを説明する掲示板が必要だと思います。これがないと、Windows Azure上でクラウド・サービスを提供していて障害で停止したときに、エンド・ユーザーである顧客にうまく説明できません。「現在、ダッシュボードが赤くなって、どうやら障害か何かで停止しているようです」ぐらいの説明しかできないのは問題です。その点は、マイクロソフトさんに善処をお願いしたいと思います。

砂金　ここまでにあるようなご意見は、いろいろな方からうかがっています。先ほどの話の中でも、シンガポールのデータセンター全体で障害が起きている場合と、皆さんのインスタンス内部で障害が起きている場合では、状況がかなり異なります。皆さんが、障害に対して行えることは、管理APIや診断APIを定期的に呼び出して、自分のサービスがヘルシーかどうかを確認するプログラムを作成することです。なお、ログ出力APIは提供されていますが、デフォルトで有効になっていませんので、自分で明示的にコードを書いて有効にする必要があります。できるだけ詳細にログ出力を行い、いま現在どのような状態でアプリが動作しているのかを外部から確認できるように工夫することをお勧めします。このような障害対策はAmazon EC2であろうが同じだと思います。クラウド・ベンダ側ももちろん対策しますが、自分の身を守るためにも、アプリ側でも「いまこういう状態で、何が問題なので、復旧の見込みはこうです」と答えられるようにしておいていただきたいと思います。

新野　ありがとうございます。Windows Azureの現状が浮き彫りになった内容だったと思います。また、ほかのクラウドも状況はそれほど変わらないだろうとも思いました。次のアジェンダに進みます。

INDEX
	[連載] .NET中心会議議事録
	第2回 現場開発者視点で答える「Windows Azure業務アプリ開発の実際」
	1．各社のクラウド・プラットフォームの比較
	2．なぜWindows Azureを使うのか？
	3．Windows Azureのセキュリティ・障害補償とサポート
	4．ライセンス形態や課金
	5．Windows Azureに関する性能

「.NET中心会議議事録」

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）