ITセキュリティチームは、企業が写真／動画共有のソーシャルメディア「Snapchat」やバンキングアプリ「Chase Mobile」の成功に続こうとモバイル開発に乗り出す前に、副次的な影響をしっかり考えているだろうか。

　企業は、開発者がコードをまだ書き始める前に、セキュリティとプライバシーに関する多くの問題を検討しなければならない。安全上の不備が発生し得る領域は、プラットフォームの分散アーキテクチャから、メディアで大きく報じられることになりかねないアプリケーションにおける個人情報の扱いまで、多岐にわたる（例えば、米Snapchatは先ごろ、セキュリティに関する外部からの警告を放置したところ、ソフトウェアの脆弱性を突かれてユーザーの名前と電話番号が流出した）。

　こうしたセキュリティとプライバシーの問題は、モバイルアプリケーションのアイデアの根幹を左右することに留意しよう。これらの問題は、開発チームが米Googleの「Android」と米Appleの「iOS」のどちらを採用していても、あるいは「BlackBerry 10」アプリケーションをプログラミングしていても変わらない（実際には、最後のケースはあまりないが）。

　企業はモバイル開発に先立って、開発プラットフォームに加え、開発者および品質保証チームによって行われるセキュリティテストを評価するとともに、これら全員にプライバシー問題への理解を徹底する必要がある。

開発プラットフォーム

　企業が最初にクリアすべき問題は、どの開発プラットフォームを使うかだ。これは、アプリケーションがiOS、Android、他のモバイルプラットフォームのどれをサポートすべきかという問題ではない（この問題はいずれ検討されることになるだろう）。開発者がさまざまなモバイルプラットフォームに対応するネイティブコードを作成するかどうか、各モバイルOSのネイティブ開発環境を使うかどうかを決めるということだ。

　以前は、デバイスのモバイルプラットフォームをベースにしたネイティブアプリケーションを開発するという選択肢しかなかった。すなわち、iOSスマートフォンおよびタブレット向けには、開発者はAppleの「Xcode」を使ってObjective-Cでプログラミングを行っていた。Androidデバイス向けのアプリケーションは一般的に、「Eclipse」または他のIDE（統合開発環境）と「ADT（Android Development Tools）Plugin」を使ってJavaで作成されていた。

　この開発モデルには一長一短がある。アプリケーションは、適切に作成されていればネイティブに動作する。また、当該のプラットフォームで可能な限り高速で安定したパフォーマンスを発揮する。さらに、このアプローチでは、モバイルプラットフォームのネイティブインタフェースおよび機能にフルアクセスできる。

　一方、ネイティブ開発の主な難点は、ソフトウェア開発ツールと開発プロセスがプラットフォームごとにいくらか異なっていることだ。そのためIT部門は、サポートしたいモバイルプラットフォームごとに統合開発およびテスト環境を構築する必要がある。また、開発者は、それぞれのプラットフォームについてプログラミング方法を知っていなければならず、OSの複数のバージョンにわたって脆弱性も把握していなければならない。こうしたことから、ほとんどのアプリケーションは、最初に1つのモバイルプラットフォーム向けにリリースされてから、他のプラットフォームに移植される。

　最近では、モバイルアプリケーション開発にクロスプラットフォーム環境を使うという考え方が普及してきている。この手法にはたくさんの選択肢があるが、最も人気があるのは、HTML5やJavaScriptといったWeb技術を使い、それらをネイティブコンテナでラップするというものだ。

　その格好の例として、オープンソースプロジェクトの「Apache Cordova」がある。Cordovaは、モバイルアプリケーションを開発するためのさまざまなコンポーネントを提供する。これらのコンポーネントは標準的なWeb技術を利用しており、ネイティブアプリケーションコンテナにパッケージ化される。この開発モデルの最大のメリットは、開発者がエンタープライズモバイルアプリケーションの開発を簡単に始められることだ。その半面、このモデルにはオーバーヘッドがあるため、パフォーマンスの問題が発生しかねない。

セキュリティテスト

　企業が対処しなければならないもう1つの重要な問題が、セキュリティテストだ。ITセキュリティチームは、アプリケーション、そのデータ、バックエンドサービスをインターネットに公開する場合、それらの組み合わせが、悪者や好奇心旺盛なユーザーから猛攻撃を浴びる恐れがあることを認識していなければならない。全てのインタフェースが攻撃の標的になりかねないため、開発チームは、こうしたアプリケーションによって増大するリスクや脆弱性の存在をしっかり理解する必要がある。

　さらに企業は、アプリケーションのセキュリティを評価するテストの計画を立てなければならない。この計画は、開発者がコードを書き始める前に策定する必要がある。アプリケーションにセキュリティを組み込むことは、アプリケーションの展開後や、開発が始まってからの方が大変になり、コストもかさむからだ。

　Webアプリケーションに対して実行されるセキュリティテストは、アプリのバックエンドサービスの評価に利用できることを頭に入れておくとよい。そうした評価に利用できるのは、これらのサービスが一般的にWebベースだからだ。

　また、セキュリティテストによって、エンタープライズスマートフォンやタブレット、BYOD（私物端末の業務利用）プログラムにどのような問題が存在する可能性があるかを判断する必要もある。「アプリケーションがデバイスで提供される暗号化機能を利用しているか」「アプリケーションが機密情報を、デバイス上の安全な領域の外部に保存していないか」といった点をチェックする必要がある。チームはセキュリティテストが、少なくとも主要なリスクを全てカバーするようにしなければならない。

　テストの参考になる有益な情報源を提供しているのが、「OWASP Mobile Security Project」（英文）だ。（なお、私が参加しているオープンソースプロジェクトの1つである「MobiSec」は、この包括的なプロジェクトの一部を成している）。モバイルリスクのトップ10の解説は、「Top 10 Mobile Risks」（英文）から参照できる。この解説は、脆弱なサーバサイドコントロール、危険なデータストレージ、不適切なセッション処理、バイナリ保護など、幅広いリスク領域を網羅している。

プライバシーの問題

　企業は、モバイル分野におけるプライバシーの問題を考慮する必要がある。現在、プライバシーは大きな問題となっている。米国家安全保障局（NSA）によるスマートフォン上の個人データの収集や、Snapchatや米Starbucksのユーザーデータの流出などがメディアを賑わせる中、企業はエンタープライズモバイルアプリケーションの運用に乗り出す前に、潜在的なプライバシーの問題に正面から取り組まなければならない。この問題は、「どのような情報の提供を求めるか」「どのような情報を保存するか」という2つのカテゴリーに大別される。

　「どのような情報の提供を求めるか」という問題は一般的に、モバイル開発において直接的には意識されない。この問題はアプリケーション開発時に、「アプリケーションがアクセスする必要があるスマートフォンの機能」という形で具体化される。例えば、アプリケーションは位置情報を取得するために、GPSセンサーを使おうとするかもしれない。

　アプリケーションがこうしたデバイスの機能を使う際、ユーザーは許可を求められる（あるいは、アプリケーションのインストール時に、こうした機能の使用について許可を求められることもある）。アプリケーションがあまりにも多くの許可を求めると、ユーザーは「この提供元は何をしようとしているのか」と疑念を抱く。ユーザーのこの種の反応から（ネットで）騒ぎが起き、会社の評判が悪くなってブランドに傷が付く恐れもある。米LinkedInは最近、アップグレード後のモバイルアプリケーションがカレンダー情報や個人情報に関する許可の拡大を求めたことから、こうしたトラブルに見舞われた。

　「どのような情報を保存するか」もプライバシー上の問題だ。アプリケーションはしばしば、モバイルデバイスに機密データを保存する。この処理が正しく、あるいは安全に行われないと、企業にとって重大な問題が発生する恐れがある。StarbucksのiPhone用モバイル決済アプリケーションは最近、ユーザーの名前、パスワード、電子メール、GPS位置ファイルを平文で保存することが発見された。そのために同社は反発を買っただけでなく、「そのアプリケーションには他にもデータセキュリティ問題があるのではないか」と疑われるようになった。

モバイル化の大勢は変わらない

　今、モバイルアプリケーションは普及が進んでおり、セキュリティ問題の増大で企業の導入にブレーキがかかることはなさそうだ。企業が開発プラットフォームとセキュリティテスト計画をよく検討し、開発者が具体的なビジネスニーズに対応したモバイルアプリケーションを開発すれば、そのメリットは多くの場合、問題を上回る。個人的には、Apache Cordovaアプリケーションの開発に取り掛かりたい。さまざまなプラットフォームで簡単に動作するからだ。