Oddwit


Googleのセキュリティ事故

Posted in Whatnot by マルコ on the October 19th, 2006

僕は今ゼミかじというプロジェクトに参加している。

これは、全国の大学ゼミに対して簡単ホームページとグループウェアをホスティングし、さらに他のゼミとのコミュニケーションや学生が興味を持ちそうなイベントの紹介などさまざまな付加価値をつけて提供しようというプロジェクト。サービスの構想はほぼ出来上がっていて、細部を決定すれば開発に着手可能という状況だ。

改善していくため教授方にいろいろと話を聞いていると、セキュリティはどうなるんだということをよく聞かれる。ゼミ内でファイルを共有できるのは良いが、他のゼミや一般人に見せるわけに行かない機密情報も少なからずある。そういった情報はいかにして保護されるのか、と。

質問文がはっきりせず何を問われているのか一概には判断できないが、システムのハイレベルな設計について問われているのであれば、答えは「はい」だ。ハイレベルとは優れたという意味ではなく、俯瞰的なという意味だ。例えばアセンブリ言語に対してC言語がハイレベル、という意味でのハイレベルである。つまり、他の人が見られないようちゃんとエリア分けができるのか、という意味で質問されているのだとすれば。

当然、ロールや権限の組み合わせで、掲載者が意図してするものしか情報を閲覧できないようにするような設定は可能だし、システムはそのように設計する。

問題は、ローレベルな設計だ。「そんな風に設計するだろうが、本当に守られるのか?」と問われているとすると、こちらとしては「保障できないが、がんばる」としか答えようが無い。

Google様とて例外ではない。

TechCrunch のこの記事にGoogleのここ最近のセキュリティ事故がリストアップされている。

2004/7: Gmailで他人の登録情報を閲覧できてしまうセキュリティホール
2005/1: Gmailで他人のメールを読めてしまうセキュリティホール
2005/11: Gmailで他人のアカウントを完全に乗っ取れてしまうセキュリティホール
2006/3: 誤ってGoogle公式ブログを削除してしまう
2006/7: Writely で Platypus プロジェクトに関するGoogle内部文書が閲覧できてしまう
2006/10: Google公式ブログがハックされ、第三者により記事が投稿される
2006/10: Blogger APIを通じて投稿した記事が他人のブログに載るとユーザーより苦情
2006/10: Platypus を誤って公開

セキュリティに絶対はない。そこらの書籍に書かれているようなXSSやSQLインジェクションに対しては防御策を取るが、セキュリティホールとはその定義からして思いもよらぬところでポンと表れてしまうものだ。重要なのは、ホールが見つかったときどれだけすばやく、徹底した対応を取れるかだろう。

(誤ってブログを削除とかってどう考えてもセキュリティ事故じゃないけど。)

Leave a Reply