2011年4月22日金曜日

「クラウド」と「モバイル」時代に備えたセキュリティの取り組み方

 企業ITの分野でここ数年の注目キーワードとなっているのが「クラウド」や「モバイル」だ。こうしたキーワードに関連する製品やサービスを企業が本格導入する際に、セキュリティ管理者はどのような対策を講じるべきだろうか。
セキュリティインシデントが複雑化
 例えば2010年には、世界各国の外交機密文書がWikileaksに流出したり、尖閣諸島沖で中国漁船と海上保安庁の巡視船が衝突した映像がYouTubeに流出したりする事件が注目を集めた。いずれも情報を保有する側が非公開とした内容がインターネット上に公開され、誰でも閲覧できる状態になった。企業でこうした事態が起きれば、重要なデータがあらゆる端末を通じて拡散するため、流出経路や影響範囲を特定して収束させることが事実上不可能になる。
 企業向けに提供されるセキュリティ技術は「ID・アクセス管理」「データ・アプリケーション保護」「インフラ保護」の3つに分類される。これまでは、PCやサーバに重要なデータが格納されるケースが多いことから、「インフラ保護」に当たるエンドポイントの対策に重点が置かれてきたという。
 だが、ITリソースやデータをネットワーク越しで利用するクラウドでは、ユーザーが正規の権限を持つ人物であるか、また、データとそのデータを処理するアプリケーションが安全な環境にあるかも重要であり、従来以上に「ID・アクセス管理」や「データ・アプリケーション保護」を強化しなければならない。
クラウドのセキュリティ技術に注目を
 クラウドの普及に伴って、「クラウドのセキュリティ」も本格的に議論されるようになった。しかし、議論の焦点がガイドラインや制度など「管理」の視点に寄り、実際にセキュリティを確保するための技術の議論が進んでいないと指摘する。
 前述した「ID・アクセス管理」や「データ・アプリケーション保護」を実現するクラウドでのセキュリティ技術として、取り上げるのが「デジタル著作権管理(DRM)」「Webベースのシングルサインオン(SSO)」「仮想化環境のセキュリティ」「特権IDの操作ログ管理」である。
 DRMは、データの利用権限をファイル単位で付与することにより、権限の無い人間による悪用を防ぐ。例えば、尖閣諸島問題の映像流出でも映像ファイルに適切なDRMを付与していれば、誰もが閲覧できる状況にはならなかったという。
 WebベースのSSOは、ユーザー権限の安全性を確保しつつ、フェデレーションと呼ばれるID連携の仕組みを利用して、クラウドサービスの利便性を高める。ユーザー情報の本体はユーザー側で保有し、外部のサービスを利用する際に、ユーザー情報を別の形に置き換えて認証を行うことで、外部サービス側にユーザー情報の本体を提供するリスクを軽減する。
 「仮想化環境のセキュリティ」や「特権IDの操作ログ管理」は、国内ではあまり普及していないという。仮想化環境におけるセキュリティリスクは、さまざまなものが専門家やベンダーの間で想定されているが、特に特権IDの運用に注目している。
 例えばクラウド事業者がシステムをメンテナンスする際に、ユーザーの仮想マシン環境に特権IDでアクセスする場合が想定され、作業が適切に行われているかを第三者視点が管理できる仕組みが重要になる。製品の中には、コンピュータ画面を録画して特権IDで行われた操作をチェックできるものもあり、こうした製品の活用が期待されるという。
 また、クラウド利用が広がればインターネットに接続する機会も必然的に増えることになり、悪質なWebサイトに接触してしまうリスクが高まる。現状の対策技術は、特定された悪質サイトへの接続を遮断するURLフィルタリングが中心だ。

モバイルセキュリティは発展途上
 もう1つのキーワードの「モバイル」は、スマートフォンやタブレット端末の爆発的な普及が背景にある。企業ではPCを補完したり、代替したりする業務端末としての利用に注目が集まっている。
 モバイル端末は、小型・軽量で持ち運びに優れるために盗難や紛失に遭遇しやすい。PCと同じように、不正プログラムに感染する恐れもある。こうした原因によって、端末から情報が流出したり、不正利用されたりするリスクが存在している。
 このため、モバイル端末でもさまざまなセキュリティ技術が登場している。盗難・紛失対策では遠隔操作でデータを消去したり、操作をロックさせたりできる。不正プログラム対策では、アンチウイルスソフトも提供されるようになった。企業が一斉導入した多数のモバイル端末を集中管理するための「モバイルデバイスマネジメント」も開発された。
 PC向けにこれまで提供されてきたのと同様のセキュリティ対策をモバイル端末でも講じられるようになったが、PC向けの対策に比べるとまだ新しく、運用実績の面では物足りないのが現状だ。石橋氏は、こうしたモバイル端末向けのセキュリティ技術を導入する上で、市場動向に注視しながら検討していくべきとアドバイスしている。
これからのステップ
 クラウドやモバイルにおけるセキュリティでは、インシデントによる影響範囲を最小化すること重要であり、データを1個単位で保護することが重要だと石橋氏は指摘する。また、最新技術が必ずしも従来のセキュリティリスクを解消できるとは限らない。実績ある技術や製品をよりよく活用したり、既存対策の有効性を再確認したりするといった行動もポイントになる。

iPhoneがユーザーの位置情報をこっそり記録

 AppleのiPhoneと3G対応のiPadがユーザーの位置情報を定期的に記録して隠しファイルに保存していたことが分かったと、研究者が技術情報サイトのO'Reilly radarで発表した。
 研究者のアレスデア・アラン、ピート・ウォーデンの両氏によると、ユーザーの位置情報とタイムスタンプは、iOS 4の登場以降、記録されるようになったという。両氏はiPhoneユーザーにこの事実を確認してもらうため、問題のファイルから位置情報を取得して、自分がいつどこにいたかを地図上に示すオープンソースアプリケーション「iPhone Tracker」を開発、公開した。
 問題のファイルは暗号化などの保護がかけられておらず、端末を同期したマシン上にも保存されるため、不正に利用される恐れもあると両氏は指摘する。ただし、現時点でこの情報がAppleなど外部に転送されている形跡はないという。Appleの意図は不明だが、意図的にやっていることは明らかだと両氏は判断。セキュリティとプライバシーにも影響する問題だとしてAppleに連絡を取ったが、返答はなかったという。
 ユーザーができる当面の対策としては、iTunes経由でバックアップファイルを暗号化することを挙げている。
 一方、セキュリティ企業のF-Secureは4月21日、「iPhoneは1日に2回、あなたの位置情報をAppleに送っている」とする記事をブログに掲載した。iPhoneの位置情報収集は、Appleのグローバルロケーションデータベースプロジェクトと関係があると推測している。
 F-Secureは、米下院議員が2010年7月に公表したAppleの法務担当上級副社長ブルース・セウェル氏の書簡をブログに掲載。「端末が携帯電話ネットワークに接続する際、AppleはWi-Fiアクセスポイント情報とGPS座標を自動的に収集する。(中略)この情報とGPS座標は端末上に保存され、Appleに送信される情報に追加される」とのくだりを紹介した。
 今回発覚した位置情報の収集は、この機能に関連があるとF-Secureは見る。「Appleには送られていないとしても、iPhoneが常にユーザーの位置情報を収集しているのは明らか」と同社は結論付けている。

2011年4月19日火曜日

HTML5でiPhone用Webアプリをオフライン対応に

キャッシュマニフェスト」ファイルを作るには
 アプリケーションキャッシュを使うには、Webブラウザにキャッシュしてほしいファイルを知らせる「キャッシュマニフェスト」ファイルを作るところから始めます。
 Webアプリで使っている、JavaScriptのソースコードファイルや画像ファイル、CSSファイルなどのパスを書いておけば、一度ロードされるとアプリケーションキャッシュに格納されて、次回以降はリクエストされなくなります。
 キャッシュマニフェストファイルの中身を見てみましょう。
CACHE MANIFEST
# Version: 7022

CACHE:
/h/MobileView.do?v=1.2.11&lang=ja
/h/images/apple-touch-icon.png?v=1.2.11
/h/iui-0.40/iui.css
/h/iui-0.40/t/default/default-theme.css
/h/iui-0.40/t/default/backButton.png
/h/iui-0.40/t/default/backButtonBack.png
/h/iui-0.40/t/default/backButtonBrdr.png
/h/iui-0.40/t/default/blueButton.png
/h/css/my-iui.css?v=1.2.11
/h/js/prototype.js?v=1.2.11
/h/js/json2.js?v=1.2.11
/h/iui-0.40/iui.js


【省略】


NETWORK:
/h/STRMobileViewAPI.do
 キャッシュマニフェストファイルの1行目は、常に「CACHE MANIFEST」です。
□ 「#」はコメント
 「#」から始まる行はコメントです。キャッシュの更新はマニフェストファイルが変更されたことで検出されます。キャッシュの更新をWebブラウザに通知するためにバージョン番号や日付を入れておきます。
□ iPhoneのSafariは更新のチェックのリクエスト自体が来ない
 ここで注意ですが、一般にキャッシュマニフェストファイルの説明では、「1byteでも変更があると、キャッシュが更新される」とありますが、iPhoneのSafariの場合、更新のチェックのリクエスト自体が来ないので、いくらコメント部分を変更しても、それだけではキャッシュは更新されません。
 後述しますが、JavaScriptで明示的にキャッシュを更新する必要があります。
□ 「CACHE:」はキャッシュしたいURL
 「CACHE:」の行以降にキャッシュしたいURLを列挙します。ワイルドカードは使えないので、キャッシュしたいJavaScript、画像、CSSを1行に1つずつ記述します。
□ 「NETWORK:」はキャッシュしたくないURL
 「NETWORK:」の行の後にはキャッシュしたくないURLを列挙します。Ajaxで取得するXMLやJSONを返すURLは、こちらに記述します。
HTMLでキャッシュマニフェストを有効にするには
 HTMLでアプリケーションキャッシュを有効にするには、以下のように<html>タグの中で「manifest」属性を使って、このキャッシュマニフェストファイルを指定します。
<!doctype html>
<html manifest="cache.manifest">
<head>


【省略】


</head>
<body>


【省略】


</body>
</html>

Webサーバをキャッシュマニフェストに対応するには
 キャッシュマニフェストファイルは、「text/cache-manifest」というMIMEタイプで送信する必要があります。
□ Apacheの場合
 Webサーバとして「Apache httpd」を使っている場合、デフォルトではキャッシュマニフェストに対応していないので、「httpd.conf」ファイルに以下の行を追加して「 .manifest」という拡張子のファイルのときに、このMIMEタイプで送信するように設定します。
AddType text/cache-manifest .manifest
□ Tomcatの場合
 「Tomcat」などのJava用のアプリケーションコンテナの場合は、アプリごとの「web.xml」の<welcome-file-list>要素の直前に、以下の<mime-mapping>要素を追加します。
<mime-mapping>
<extension>manifest</extension>
<mime-type>text/cache-manifest</mime-type>
</mime-mapping>

 これで、アプリケーションキャッシュに指定したコンテンツがキャッシュされるようになります。

HTMLファイルをキャッシュマニフェストに含めるには
 キャッシュマニフェストファイルに、すべてのJavaScriptファイル、画像ファイル、CSSファイルを記述すると、ページのロード時間を劇的に短縮できます。
 キャッシュマニフェストには、これらのファイルだけでなくHTML自体を含めることができます。HTML自体をキャッシュに格納すると、そのURLのときは一切サーバにリクエストを出さずに画面を表示可能になります。
 先ほどの例では「CACHE:」の1行目の「/h/MobileView.do」がHTMLです。
 すべてのデータをAjaxで取得するアプリは、HTMLは毎回同じファイルになるはずなので、このようにHTML自体をキャッシュできます。
 こうしておくと、電波がまったく届いていないオフライン状態でも、Safariのブックマークなどから起動すると、普通にアプリが動作します。

対応必須! キャッシュの更新スクリプト
 このようにiPhoneのSafariでは、キャッシュマニフェストによるアプリケーションキャッシュは、かなり強力ですが、設定画面から[キャッシュを消去]を選択しても、キャッシュは消去されません。
 前述したとおり、キャッシュマニフェストファイルを変更してもマニフェストファイル自体がキャッシュされてしまいリクエストが来ないので、キャッシュを更新できないのです。
□ キャッシュデータの削除はiTunesで"復元"のみ?
 いろいろ試してみましたが、一度キャッシュされてしまったデータを削除するには、iTunesからiPhoneを"復元"するほかなさそうです。
 さすがにこれでは、アプリの不具合修正やバージョンアップがあっても更新できず実用的ではないので、アプリケーションキャッシュを使う場合は、JavaScriptで更新をチェックする処理をセットで作っておき、スクリプトから明示的にキャッシュを更新する必要があります。
 これをやらずに、いきなりアプリケーションキャッシュを試すと、もうそのURLでは二度とロードしなくなるので、要注意です。
□ キャッシュのチェックスクリプト
 JavaScriptでキャッシュを更新するのは簡単です。スクリプトの中で「window.applicationCache.update()」を呼び出せばOKです。この関数を呼び出すと、キャッシュマニフェストファイルをサーバからダウンロードしてキャッシュが更新されていないかどうかをチェックします。
 ここで初めて、マニフェストファイルに入れておいたコメントの中のバージョン番号が役に立ちます。もし、キャッシュが更新されていた場合は、applicationCacheオブジェクトでupdatereadyイベントが発生するので、「applicationCache.swapCache()」を呼び出して新しいキャッシュに切り替えます。
 これを実行するスクリプトは、以下のようになります。
var cache = window.applicationCache;
cache.addEventListener("updateready", function() {
if (confirm('アプリケーションの新しいバージョンが利用可能です。更新しますか?')) {
cache.swapCache();
location.reload();
}
});
if (navigator.onLine) {
cache.update();
}
 このスクリプトをHTMLのロードイベントで動作する関数の中に記述すると、ページのロード時にキャッシュの更新をチェックして、更新する必要がある場合は確認画面を表示してキャッシュを更新するようになります。