セキュリティで保護されたモバイル アプリケーション – 矛盾した表現?
「セキュリティ」と「モバイル アプリケーションの開発」はめったに同じ文章の中に現れることはありません。最近私は多くのイギリスの開発者たちとモバイル アプリケーションの開発についてお話をしました。何名がセキュリティという側面に興味があるかとお尋ねしたところ、約 2 パーセントが「興味がある」と回答されました。これは 140 名中、たったの 3 人でした。
もし、皆さんがその 2 パーセントであれば、そのよい取り組みを継続してください。しかし、なぜモバイル開発者の大多数がセキュリティに無関心なのでしょうか? 「セキュリティで保護されたモバイル アプリケーション」とは矛盾した表現であるというのは本当でしょうか?
この無関心さについてのいくつかの理由は、モバイル アプリケーションを開発する開発チームについて考えれば、分かるでしょう。アプリケーションの大部分が 2、3 人で構成されている小さなチームによるもので、このようなチームは少ない予算で隙間製品を市場に送り出すためにビジネスのスタートアップを頻繁に作り出しています。時に、モバイル開発は、より大きなデスクトップ プロジェクトの「モバイル オプション」にチェック マークを入れる機会を探しているエンタープライズ IT 開発のサイド プロジェクトです。
両方のケースで、多くの場合、セキュリティについての特徴のない単調な野暮ったい考慮点のための時間やお金はほとんどありません。セキュリティについての考慮点は、チェックブックとペンに手をのばさせるような、最高技術責任者からの非常にインパクトのある機能やエキサイティングなユーザー インターフェイスの影に紛れたままとなっています。
そのほかの状況では、セキュリティはユーザビリティに対する障壁として捕らえられています。ユーザーはモバイル デバイスおよびソフトウェアはデータがすぐに手に入るという利便性がすべてであることを知っています。また、単に注文の状況をチェックするためにパスワードを入力しなければならないことについて、苦情があふれてきています。
長いリストから 2 つほど反対がありましたが、これらの討論に対する正当性の中核を拒否するものはありません。セキュリティに時間が費やされると、追加される予定の機能の多くが削除される可能性があります。また、最初のプロジェクトの時間とコストの見積もりが長くなる可能性があり、ユーザビリティに対しプライバシが常に両立しないものとなります。
では、これは目新しいものでしょうか? 同様の争いが長年にわたりデスクトップとサーバー スペースで行われています。これは今でも続いています。新生のモバイル スペースでもガイダンスを提供できる経験、失敗、そして成功がありすぎるほどあります。私たちは単にデスクトップから自分のシャツのポケットに入っている何かにプラットフォームをシフトしたというだけの理由で同じ過ちを犯す必要はありません。結局、両方ともコンピュータではありませんか? 信頼できるコンピューティング (英語情報) の規則 – セキュリティ、プライバシ、信頼性およびビジネスの慣習 - は依然として当てはまります。
セキュリティで保護されたモバイル アプリケーションを構築する
おそらく、質問の方向を変えるべきでしょう。では、なぜ、すべてのモバイル開発者はセキュリティに注意を払うべきなのでしょうか? 信頼できるコンピューティングはハードウェアに関わらず、当てはまります。強固なソリューションに対するユーザーの期待は依然として存在します。内密に提供された情報は機密のままであることが要求されます。モバイル ワーカーは自分自身の携帯電話が企業ネットワークに入り込む迷惑コードのソースになることを望んでいません。
それがセキュリティとなれば、モバイル アプリケーション開発はデスクトップ開発と歩調を合わせるべきです。設計のプロセスの初期で、ソリューションに関連する資産像を明確に描き、脅威や脆弱性の可能性のあるものを理解し、危険およびその潜在的な影響を明らかにすることが重要です。なりすまし、改ざん、否認、情報の漏えい、サービス拒否、特権の昇格の STRIDE (英語情報) ステップを経ることにより、脅威モデル (英語情報) などの技術を使用して、セキュリティをソフトウェア開発ライフサイクルに統合してください。新しいレベルの明確さと理解で、これらのプロセスを介し、設計の選択と直接的な開発者の注意により、明らかにされた危険を緩和または完全に回避することができます。
開発ライフサイクルにおけるセキュリティの統合方法に向けられた技術と情報が多数あり、脅威モデルは単に一般によく使用されるプロセスの 1 つです。どのプロセスまたはフレームワークを使用するかという選択は、特定の開発チームの力学により異なりますが、最も重要なことは戦略が選択され、実行されることです。どこから開始すべきかを検討しているのであれば、patterns & practices Security Engineering paper (英語情報) または Michael Howard および Steve Lipner 著の The Security Development Lifecycle (英語情報) をご覧ください。
モバイル ソリューションに特有の考慮点
モバイル プラットフォームのセキュリティの基礎はデスクトップのものと同じであるということは本当ですが、セキュリティ上の危険とセキュリティ上の考慮点はモバイル ユーザーとモバイル ハードウェアの性質のため、若干異なります。たとえば、携帯電話の電源が入っており、ロックしていない状態のままタクシーに置き忘れしてしまう可能性は、ラップトップを同じ状態で置き忘れてしまうよりもずっと高いでしょう。このため、アプリケーションの資産やデバイスの紛失や盗難による企業への影響を理解することが重要です。
ここにちょうどモバイル アプリケーションに関するいくつかの考慮点があります。(モバイルのセキュリティ情報についての詳細は MSDN コラムの Application Security, Deployment and Management (英語情報) をご覧ください。)
データ入力に関する考慮点
画面の面積やテンキー入力が制限されているため、ユーザー インターフェイスのデザインは非常に難しいものです。表示される情報量とデータにアクセスするために必要なキーを押す回数の間で、正しいバランスをとることが重要です。パスワードはこの問題の不可欠な部分です。ユーザーに 10 桁のアルファベットや数字のパスワードを 30 秒ごとに入力させるとしたら、企業のセキュリティ責任者は夜ぐっすり眠れることでしょう。しかし、これを行うのであれば、ユーザーに単にデバイスのスイッチをオフにさせ、ペンと紙を使わせることになるでしょう。また、ユーザーがデバイスの後ろにパスワードをメモしたものをテープで貼っている危険性も常にあります。(私はこれを見たことがあります!)
このような状況で、両立しないものの間の妥協点とは、パスワードをより短くするためにモバイル アプリケーションから制限されたデータをいくつか削除することでしょう。または、ユーザーがフル パスワードを入力する頻度はより低くなり、ユーザーの ID を確認するための短い PIN 番号を入力する頻度はより高くなる 2 段階のロックを検討してください。バイオメトリクスが利用可能なデバイスもあり、スマート カードやカードの磁気データ読取装置などのそのほかの 2 つの要素のソリューションもまたユーザーの入力を簡素化することができます。
暗号化
Windows Mobile には Cryptography Application Programming Interface (CAPI) の実装が含まれ、対称的および非対称的な暗号化アルゴリズムを含むさまざまな機能をサポートします。さらに、Microsoft .NET Compact Framework 2.0 にはデスクトップ フレームワーク クラスに従う管理されたクラスがあり、暗号化ライブラリへの簡素なアクセスを提供します。これはすぐれており、これらの機能を使用して適切にデータのプライバシーを提供することが推奨されています。しかし、モバイル ソリューションには注意が必要です。
一般的に、モバイル デバイスの処理力は、今日のデスクトップ機器よりも 2、3 年ほど遅れているため、モバイル ソリューション設計の際、CPU の負担を考慮する必要がある場合もあります。非対称アルゴリズムは、処理するため CPU の相当な労力を要し、また著しくデバイスの速度を遅くさせる可能性があります。非対称暗号化を使用する場合、保護されているデータを重要なコンポーネントのみに制限し、表示またはプログラムの使用のために必要な場合のみ、解読するのがよいでしょう。多くの場合、対称キーをデータの大部分に使用して、次に非対称暗号化で対称キーを暗号化することで十分です。これにより、CPU 負荷が緩和され、デバイスのバッテリー寿命にプラスの影響がもたらされます。
キーの管理
暗号化使用時には、常にマスタ キーの説明がある必要があり、それがキーの管理を導入します。キーの管理はプラットフォームに関わらずそれ自体の問題をもたらしますが、モバイル デバイスのキーの管理は深刻な問題となり得ます。Windows Mobile はキー管理について、Windows XP や Windows Vista オペレーティング システムと同じような方法でコンピュータまたはユーザー保護されたストアを提供しないため、Windows Mobile 搭載のデバイスでのキーのストレージは注意が必要です。Windows Mobile はオブジェクト レベルのセキュリティを実装しないため、コードでの、またはストアのファイルでのマスタ キーの保存はほとんど受け入れられるソリューションではありません。このため、ファイルはそのほかのプロセスにより、または Active Sync のような技術を介し、外部のアクセスから個々に制限できません。圧倒的に最も容易で安全なマスタ キーを取り扱う方法は、それをユーザーに提供し、デバイスから問題を取り除くことです。つまり、マスタ キーをデバイスの境界線またはアプリケーションの境界線でのユーザーのパスワードから引き出すことです。いくつかの場合において満足いくそのほかのソリューションは、電話ベースのデバイスに Mobile Subscriber Identity 番号 (IMSI) などのモバイル デバイスに利用可能な一意の ID のひとつを使用する、または Windows Mobile を搭載した各デバイスが含む一意のデバイス ID を使用することです。しかし、この種類のデータを使用する場合には注意する必要があります。この理由は、キー データがアプリケーションに利用可能な場合、そのほかのアプリケーションにも利用可能となります。または IMSI の場合には、ロックされていないデバイスのキーパッドを介し対話的に検索することができる可能性があります。
Windows Mobile は CryptProtectData などの Data Protection Application Programming Interface (DPAPI) 機能も提供します。これはオフ デバイス攻撃からデータを保護するためにデバイスに特定のキーを活用します。これらの API をデバイス アプリケーションのセキュリティのセットと使用し、実行から署名された信頼されるアプリケーションのみに制限すると、ストアが作成されるデバイスによってのみ読み取り可能なデバイスでファイルまたはデータ ストアを作成することができます。デバイスのセキュリティ ポリシーの構成についてはこちらをクリックしてください。また、DPAPI についてはこちらをご覧ください。
バッファ オーバーラン
ローカル スタック変数をオーバーランさせることにより、関数のリターン アドレスを変更する通常のバッファ オーバーランは、Intel X86 搭載のコンピュータで非常に問題となっています。しかし、これはローカル変数上に保存されているリターン ポインタで高いメモリ アドレスからのダウンロードを増加させるスタック アーキテクチャに依存しています。現在、モバイル デバイスは異なる CPU アーキテクチャおよびインストラクションのセットを使用し、劇的にこれらの種類の攻撃が行われることを難解にし、これらの技術を悪用するウイルスをモバイル デバイスでさらに少なくします。
さらに、デバイスのインターネット プロトコル (IP) アドレスは、デバイスがワイヤレス ベースのステーション間で移動するごとに変更され、受信通信をリッスンしているアプリケーションはほとんどありません。実際、デバイスで機能が削減されることは、攻撃されるコードがより少なくなるという意味です。
これらは現状に甘んじる言い訳ではありません! 常時接続のデバイスは業界が推進しているもので、これらのデバイスは頻繁にインターネットの閲覧や企業ネットワーク接続に使用されています。出回っているデバイスの数については、有効な攻撃が文書化され、共有されるのは時間の問題です。
バッファ オーバーランには様々な方法で損害を及ぼす可能性があり、関数のリターン アドレスを攻撃するのみに限定されず、CPU アーキテクチャに関わらず、モバイル アプリケーションはこれらの種類の攻撃の影響を受けます。コード レビューやセキュリティ レビューをともなう賢明な開発プロセスに加え、C# または VB.NET などのアプリケーション用の管理されたコードを使用することにより、これらの危険性に対するよい緩和策が提供されます。
Windows Mobile を保護する
Windows Mobile は、ホストするデバイスやアプリケーションを保護するためのセキュリティ戦略を作り出すために使用できる多くのインフラストラクチャ機能および開発ツールを提供します。
まず、ユーザーにより、境界線セキュリティのポリシーを PIN またはパスワードを必要とするよう設定することができ、これにより、デバイスへのアクセスについて最初のレベルの防御が提供されます。このメカニズムは、ローカル認証サブ システム (LASS) を介し実装され、カスタム ローカル認証プラグイン (LAP) を介し拡大されます。これはカスタム ユーザー インターフェイスと認証を提供する方法です。エンタープライズ モバイル アプリケーションについて、これはユーザーからマスタ キーをキャプチャし、それをデバイスで実行されているアプリケーションに伝達するための非常に有益なツールです。LASS および LAP のアーキテクチャに関する詳細情報は、こちら (英語情報) をご覧ください。
別の主な保護メカニズムはコード署名を介し実装されます。Windows Mobile は、ダイナミック リンク ライブラリ (.dll) や実行可能ファイル (.exe) などのありとあらゆる実行可能なモジュールが、そのコードが署名されており、その署名が有効で、デバイスにインストールされている認識されている証明書と一致するかを検証するために読み込まれると、それらをチェックします。Windows Mobile はこれらの基準と一致しないコードが実行されることを阻止するよう構成でき、これにより、デバイスが悪意のあるコードから保護されます。CAB ファイルによるソフトウェアのインストールはそれ自体の証明書ストアを持つこのプロセスによっても保護され、失効ストアがデバイスで利用可能で、不正なアプリケーションの実行やインストールを阻止します。コード署名に加え、Windows Mobile はストア内の証明書に関連するセキュリティ ロールを使用し、ファイル、レジストリ キーおよびコンピュータのそのほかの資産へのアクセスを制限します。署名のセキュリティに関する詳細は、こちら (英語情報) をご覧ください。
関連するデータについて、モバイル デバイスでの情報の保存のための多くのソリューションがあります。Microsoft SQL Compact はデバイスで豊富で用途の広い関連ストアを提供するばかりでなく、データの暗号化やパスワード保護のオプションも含まれています。Microsoft SQL Compact に関する詳細情報は、こちらをご覧ください。
セキュリティで保護された通信、サーバー認証、デバイスの管理 (すなわち、リモート ワイプ) およびウイルス チェックなどの多くのそのほかのエリアはここでは取り扱っていません。これらおよびモバイル デバイスについての多くのそのほかのセキュリティの考慮点に関する詳細は、Windows Mobile Development Center (英語情報) の Security, Deployment and Management (英語情報) をご覧ください。
要約
セキュリティは乗り越えられない問題ではありません。また、セキュリティはモバイル アプリケーションにも間違いなく当てはまります。信頼できるモバイル アプリケーションを開発する手助けとなるツールやリソースが利用可能です。何もしないことが最も安価で容易なオプションのようですが、これは非常に短期的な見方です。お客様が社内のエンタープライズ ユーザーでも、一般の方であっても、自分たちのお客様の信頼を得たいのであれば、ユーザーが大切にしているデータを保護し、ユーザーのデバイスが悪意のあるコードのエントリ ポイントにならないよう、ソフトウェアが本来意図されているよう記述する必要があります。モバイル プロジェクトのセキュリティについてお考えになったことがないのであれば、今がその時期です。「セキュリティで保護されたモバイル アプリケーション」とは「矛盾した表現」ではありません。その問題に責任を負い、開発ライフサイクルを通じてセキュリティを適用するのは個々の開発者の義務です。
この記事は、マイクロソフト セキュリティ ニュースレターで配信しました。