GoogleがApp Engine上のアプリケーションのセキュリティをチェックするサービスGoogle Cloud Security Scannerをローンチ

Googleが今日(米国時間2/19)、同社のPaaSサービスGoogle App Engineを使っているデベロッパのための、新しいセキュリティツールをローンチした。その、Google Cloud Security Scannerと呼ばれるツールは、ユーザ(デベロッパ)のアプリケーションを定期的にスキャンして、クロスサイトスクリプティング混成コンテンツ(mixed content)に対する脆弱性をチェックする。

こんなツールを提供するのはもちろんGoogleが初めてではないが、今日の発表声明の中で、既存のツールは“必ずしもGoogle App Engineのデベロッパには向いていない”、と主張している。しかも既存のツールはセットアップが難しくて、デベロッパではなく“セキュリティの専門家向けだ”、とも言っている。

そのチェックを動かすためにGoogleは、ユーザのサイトをスキャンする小さなボットネットをCompute Engine上にセットアップする。HTTPリクエストは毎秒約15リクエストに抑えられ、 App Engineが問題なくそれらを処理できるようにする。

最初の実行ではスキャナーがユーザのサイトとアプリケーションを素早くクロールして、その基本的なHTMLのコードを解析する。それから、Googleの説明によると、二度目のスキャンではサイトの完全な表示(レンダリング)を行い、アプリケーションのもっと複雑な部分を調べる。それが済むとツールは、無害なペイロードにより、攻撃を試みる。それからChrome DevToolsのデバッガでブラウザとDOMの、攻撃の前とあとで変わった箇所を調べ、不正コードの注入に成功したかをチェックする。成功していたら、今後マルウェア等にやられる可能性がある。

デバッガを使うことによってGoogleは誤判断を避けようとしているが、それでも、見逃すバグがあるかもしれない、とも言っている。しかしGoogleによると、“デベロッパにとってセキュリティのチェックは、労力もノイズも少ないものが望まれているから、このトレードオフは前向きにとらえたい…”、と言っている。

スキャナーは、すべての入力フィールドに何かを書き込み、すべてのボタンやリンクをクリックしてみるから、アプリケーションの機能を実際に動かしてしまう可能性もある。たとえば、ブログのコメント欄に、“毎週9000ドル稼げる”というスパムが載ってしまうかもしれない。それを防ぐためには、Googleの推奨では、スキャナーをテスト用のサイトで動かすか、または臨時のCSSコードによってUIの一部を不活にしたり、一部のURLを排除するとよい。

スキャナーの利用は無料だが、ユーザのクォータの制限量や帯域に対する料金に影響が及ぶことは、あるかもしれない。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


オープンシステムの旗手Googleがクラウドサービスのロックインは当面必要と言い訳

Googleの技術者の一人が、Google+の彼のページで、ロックインのまったくないクラウドプラットホームはありえない、と結論していた。たしかにそれはそうだけど、でもそんなことをわざわざ言うのには理由がある。クラウドのユーザたちのあいだで議論になっているこのロックインというホットな話題に関しては、Googleも他社もあまり変わらない、とGoogleは言いたいのだ。

Googleのエンジニアリング部長Peter Magnussonが書いたその記事は、その真のねらいを汲んで読む必要がある。MagnussonはGoogle App Engine(GAE)のロックインの問題を主に述べているのだが、彼はそれと同時に、同社の管理サービスやIaaSを、AWSなどと比較しているのだ。そして彼曰く、Googleも、何らかの制約なくしてサービスを提供することはできない、と。彼らがこれから提供しようとしているのは、AppScaleなどが提供しているサービスに代わるものだ、という。

どうやらMagnussonがこんなことを言うのも、Google App Engineのユーザの中には、それにいくつかの制約が伴っていることを、嫌っている者がいるかららしい。ランタイム環境が独特だし、システムコールができない、ファイルシステムへのライト(write)ができない、オペレーティングシステムを選べない…。

Magnussonは、GoogleがGAEというサービスを提供するためにはロックインが避けられない、と言う:

ある程度のロックインなしに革新的なプラットホームを作ることは不可能だ。たとえばDatastoreは、そこらにあるそのほかのNoSQLやNearSQLサービスやスタックと似ていない。レプリケーションが複数のデータセンターで同期する、カーソルがある、ディスティンクトクェリ、プロジェクションクェリ、ジグザグマージJOIN、トランザクションタスク、自動シャーディング/ロードバランシング、マネージドセカンダリインデクス、マルチロウ/マルチマシントランザクションなどなど、いずれも独特だ。これらの機能を犠牲にして何らかの最小公分母で妥協することはできない。ベースとなっているソフトウェアの機能を十分に生かせる機能を、なるべく多く提供したいのだ。

GAEは、そのほかのPaaSプロバイダ、たとえばCloudbeesHeroku、6月にCenturyLinkが買収したAppFogなどと横並びで比較される。しかしGoogleは、手作業的な操作やインフラの管理など、そのほかのサービスが特長としている側面をあえて抽象化している。そこで、Googleのアプリケーションサービスには、ユーザが直接できないことがいくつかある。それらの部分は、ユーザのファイアウォールに代わってGoogleが担当し、DoS攻撃やウィルスなどを防いでいるからだ。

Magnussonの主張ではそのために、モバイルアプリやWebアプリケーションの多くが、立ち上がりが速くて、スケールするのも速い。スケールや、アプリケーションを別のデータセンターに移動させることなどは、すべてGoogleが面倒を見る。

しかし実際の問題は、ユーザをプロプライエタリなプラットホームに閉じ込めてしまうクローズドで独特なAPIだ。Twitterの上でぼくの質問に答えてくれた人たちの多くが、何らかのロックインは避けられないという点では同意している。

[訳]: ロックインのレベルはプラットホーム自身よりも顧客のユースケースに依存する面が大きい。データの重力の影響はそれほどでもないし、ツールがマイグレーションを十分に助けてくれる。

AWSはロックインのあるサービスとして挙げられている:

[訳]: AWSが独自のエコシステムを築こうとするやり方も、事実上のロックインだ。

ThinkJarのファウンダで主席アナリストのEsteban Kolskyによると、ロックインの最小化はオープンスタンダードで可能だが、現状のマーケットに関してそれを言うのはまだ早すぎる:

共通の規格を使えば理論的にはロックインは起きないが、まだそういうものを採用している企業が少ない。

自分が提供するプラットホームにある程度のロックインを設けることは、ベンダの利益に貢献する。今のライセンス方式では、ロックインによる“縛り”がないとユーザが流動的になりすぎて、売上の予測ができない。売上が今のクラウドが約束しているように(すでに小さなベンダが実行しているように)単純明快な従量制なら、ユーザは必然的に複数のベンダからつまみ食いする使い方になるので、ロックインは存在できなくなる…ただしそれも、現状ではあくまでも理論だ。しかしAmazonとRackspaceを比較しても分かるように、ロックインが今でも相当厳しいのは、プラットホーム(PaaS)よりもインフラストラクチャ(IaaS)の方だ。

また、ロックインにはユーザの利益もある。とくに企業のIT部門は身軽な移行ができないし、それを迫られてもいない。

だからこの問題は、エンタプライズソフトウェアの問題は何でもそうだけど、ユーザやベンダの目先の利便性をとるか、それとも経営トップや市場など最終受益者の利益を優先するか、という問題に帰結する。

ロックインという問題は、クラウドサービスのプロバイダにつねにつきまとう。OpenStackも、今後のプラットホームの多様化(Red Hat、IBM、Cloudscaling、HP、Rackspaceなどなど)とともに、結果的にロックインを余儀なくされる。

Magnussonも、スタンダードの重要性は認めつつ、まだそれを言うのは時期尚早だ、と述べている。たしかに、そんな見方もありえるだろう。

しかし、多くのベンダが今の市場で学びつつあるのは、あるクラウドから別のクラウドへデータやアプリケーションを移動させるサービスの重要性だ。そして複数のクラウドベンダが、顧客の要求の高度化により、互いの相互運用性を優先的に重視せざるをえなくなれば、彼ら全体が一つのエコシステムとして成長し、繁栄していくことになるだろう。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


Google App Engineがバージョンアップ, いよいよクラウドサービスに本腰

GoogleのGoogle App Engineが今日(米国時間6/12)から1.8.1となり、たくさんの新しい機能が盛り込まれた。中でもとくに注目すべきは、待望の検索APIとプッシュツーデプロイ機能だ。後者はGitのpushコマンドのようにコードをリポジトリにプッシュする。

これらの新しい機能は、Googleがクラウドサービス市場にいよいよ本格的に参入すると暗黙裡に宣言したような、多忙なGoogle I/Oからの必然的な流れだ。今回の発表までGoogleは、Google Cloud Platformについて沈黙していた。しかし一般公開した今では、毎週のように新機能を発表し、これまでバラバラに存在していた各種Web機能の新たな統一を推進している。

今日はGoogle App Engineに関しても、同様の趣旨のアップデートが行われた:

検索 API: リリースから約1年になる検索APIをGoogleはプレビュー段階へ移し、一般公開に備えている。この検索APIを使ってデベロッパは、プレーンテキスト、HTML、アトム、数値、日付、地理的な位置など、各種の構造化データを、自分のアプリケーションの中でGoogle的に検索できる。本誌が先週報じたように、Googleはその操作とストレージに対する課金を開始する。料金表は、ここにある。料金は、一般公開に向けて変わるかもしれない。

ソースのプッシュツーデプロイ(Push-to-Deploy): App Engine は新たにPythonとPHPのアプリケーションの展開をGitのツールを使ってサポートする。したがってデベロッパはアプリケーションの展開をGitのリポジトリにプッシュするときと同様に、容易に行える。

Google Cloud Storageのクライアントライブラリ: App EngineからGoogle Cloud Storageへのアクセスが、Cloud Storage Client Libraryのプレビューリリースにより改良される。Googleのブログ記事によると、そのクライアントライブラリにはFiles APIの機能性の多くが含まれ、それらがなお一層ブラッシュアップされてデベロッパの良質な利用体験を保証する。将来的には、重複を防ぐためにFiles APIは非推奨となる。Cloud Storage Client Libraryは、今後もアップグレードされる。

タスクキュー: この、要望の多かった機能により、デベロッパはタスクを迅速に任意のTask Queueに入れてしまえる。アプリケーションの本流がブロックしないので、リクエストの処理がより効率的になる。

データストア: Googleによると、Google Cloud Datastoreには二つの重要な変更が行われた。まず、デフォルトの自動IDのポリシーが散在型になった。またNDBライブラリが’DISTINCT’クェリをサポートする。

1.8.1の新機能とバグフィクスの完全なリストは、Googleのリリースノートにある。

[原文へ]
(翻訳:iwatani(a.k.a. hiwa))


守秘メールがリーク: Google App Engineの検索APIがプレビューへ, そして課金

GoogleはGoogle App Engineの検索APIを実験段階からプレビューステータスへ移し、オペレーションとストレージには課金することを準備中である。このニュースのソースは、Googleのプロダクトマネージャが検索APIを実験しているデベロッパたちに送ったメールだ。彼はそのメールの中で、たった一つのことを求めている: “このニュースは数週間後の公開リリースまで守秘していただきたい”。

そしてもちろん、次に起きることは? デベロッパの誰かがそのメールをリークするのだ。

検索APIはほぼ1年前にリリースされ、デベロッパは自分のアプリケーションの中で全文検索ができるようになった。検索する範囲を指定できるほか、合致箇所のマーキング(下線引きなど)やフレーズ取り出しなどの高度な機能もある。

今日(米国時間6/4)のメールでGoogleのApp Engine担当プロダクトマーケティングマネージャChris Ramsdaleは、APIは一般公開となるにあたって変更はほとんど行われない、と言っている。ただしAPIの堅牢性(ロバストネス)は改良して、魅力的なSLA(service level agreement ≒ サービス品質の保証)を提供したい、とも言っている。そしてメールの最後のほうで、プレビューリリースからストレージとオペレーションに課金を開始する、と言っている。

メールには、料金表もある:

検索ユーザへのプロモーションのための無料のクォータが提供される: 

Google App Engineに関しては、Google I/O以降、ニュースが多い。月曜日にはMobile Backend Starterのローンチが発表され、AndroidデベロッパがGoogleのApp Engine上で動く自分のアプリケーションのためにGoogleのクラウドインフラを利用できることになった。

この検索APIに関しては、今Googleの確認を求めている。何らかのコメントが得られ次第、この記事をアップデートしよう。


[原文へ]
(翻訳:iwatani(a.k.a. hiwa))