Androidにおけるセキュリティ設計と動作（前編）

※この記事は、書籍『Android Security 安全なアプリケーションを作成するために』の第3章の内容を、ThinkIT向けに特別にオンラインで公開しているものです。詳しくは記事末尾の書籍紹介欄をご覧ください。

セキュアなアンドロイドアプリを開発するためには、アンドロイドOSのセキュリティ設計を理解しておく必要があります。本章では、アンドロイドのセキュリティ関連の設計と動作について技術的な観点から見ていきます。

3.1　セキュリティアーキテクチャ

アンドロイドのセキュリティは、以下の4つの要素で構成されています。

1. 証明書（キーストアファイル）
   アプリケーションの作者を識別するだけではなく、パーミッションの一部としても使用されます。
2. ユーザID
   アンドロイドOSにインストールされたアプリケーションにはそれぞれ個別のIDが割り当てられます。このIDはLinuxのユーザIDとグループIDに相当します。また、アンドロイドOS自体もいくつかのIDによって分割されています。
3. パーミッション
   各アプリケーションには、実行可能な機能の範囲を限定できるパーミッションという概念が導入されており、データや機能へのアクセスを細かく制限することが可能になっています。
4. ファイルのアクセス許可
   アンドロイドアプリが作成するファイルや、アプリケーションが配置されるディレクトリなどに対して、デフォルトでアクセス許可が設定されます。

これらの要素を組み合わせることにより、アンドロイドOSは次のようなセキュアな構造を実現しています。

• アプリケーションは互いのデータに直接アクセスできない。
• アプリケーションはOSの機能のうち、限定された部分にのみアクセスできる。

つまり、アンドロイドのセキュリティの基本設計では、アプリケーションがOSや他のアプリケーションにアクセスしたり、ユーザデータを読み書きしたりする動作は、デフォルトでは許可されていません。

たとえば、連絡先や電子メールデータへのアクセス、ネットワークアクセス、デバイスの制御なども一切行うことはできません。

アンドロイドアプリはそれぞれアンドロイドOSのサンドボックス内で動作しているため、サンドボックスが提供していないリソースやデータへのアクセスが必要な場合は、各アプリケーションがOSに対してそれらへのアクセスを明示的に宣言する必要があります（図3-1）。この宣言はパーミッションの設定を通じて行うようになっており、各アプリケーションは必要なパーミッションをマニフェストファイルに静的に宣言します。アンドロイドOSは、アプリケーションのインストール時にアプリケーションが要求するパーミッションをユーザに通知します。なお、アプリケーションの実行中にパーミッションを動的に変更することはできません。

3.2　証明書とアプリケーションの署名

すべてのアンドロイドアプリには署名が必要です。署名されていないアプリケーションは、不正なアプリケーションファイルと認識され、アンドロイド端末にインストールできません。署名に使用する証明書は、アプリケーションの作者を識別する目的に加えて、アプリケーション間で信頼関係を確立する手段として使用されます。WebシステムでHTTPSプロトコルを使用するときには、第三者機関である認証局から発行されたSSLサーバ証明書が必要ですが、アンドロイドアプリは認証局を必要としない自己証明書を使用します。自己証明書は、証明書としての正しさが保証されているものではありませんが、アンドロイドでは、特定のデータへのアクセスが可能かどうかの判断や、ユーザIDの共有が可能かどうかの判断など、アプリケーション内部のデータアクセスを制御するために署名を使用します。この用途では、データの提供元と提供先が同じ証明書を持っていることを確認できればよいため、自己証明書でも十分であると言えます。

3.2.1　秘密鍵のセキュリティ

証明書（キーストアファイル）とキーが第三者に渡ると、その証明書を使って作者になりすまし、アプリケーションに署名して配布し、アプリケーションを勝手に置き換えたり、正規のアプリケーションが作成したデータを盗んだりすることが可能になります。このため、厳重な管理が必要です。

キーを安全に保つための指針

• キーストアとキーに強力なパスワードを選択する。
• キーの作成時およびアプリケーションへの署名時にパスワードがシェルの履歴に記録されないようにする。
• キーストアファイルにアクセスできる（保管場所を知っている）人間を限定する。

受託開発時の注意

受託開発では、アプリケーションを作成して発注者に納品します。開発時はデバッグ証明書を用いて動作確認を行いますが、最終的にアプリケーションをリリースするためには、リリース証明書が必要です。通常は、発注者を証明する証明書を作成し、署名します。受託開発の場合、署名を誰が行うかによって以下のケースが考えられます。

• 受託者が無署名のAPKを作成、納品し、発注者が署名を行う。
• 受託者が署名まで行い、署名付きのAPKを納品する。

受託者が無署名のAPKを作成、納品し、発注者が署名を行う場合

通常は、こちらのケースになると思われます。前述したとおり、証明書とパスワードは厳重に管理する必要があるので、受託者が管理することはありません。しかし、発注者がアンドロイドアプリに署名が必要なことを知らない可能性もあります。このような場合には、署名の必要性や発注者側で署名を行う意味について説明する必要があります。発注者側が署名の意味を正しく理解せず、ずさんな管理を行った場合、バージョンアップ時に証明書が見つからなかったり、パスワードがわからなくなったりするなどのトラブルが発生し、バージョンアップができなくなることも考えられます。受託者側は、このようなトラブルを未然に防ぐためのサポートを行う必要があります。また、アプリケーションがGoogleマップを利用する場合は、リリース証明書のハッシュ値をGoogleマップサービスに登録する必要があるので注意してください。

受託者が署名まで行い、署名付きのAPKを納品する場合

通常、署名は発注者側で行いますが、署名作業が受託者に依頼される場合もあります。この場合は、証明書とパスワードを受託者が作成し、使用することになります（まれに、発注者側が証明書とパスワードを用意することもあります）。受託者が署名を行う場合は、署名に使用した証明書をできるだけすみやかに発注者側に引き渡し、手元に置かないようにするのが理想的です。証明書とパスワードの管理は発注者側の責任であることを説明し、なるべく受託者側で署名を行わないようにするのが最もよい方法です。

このように、受託開発では、リリース時の署名と証明書に関する事項を発注者に説明し、作業を適切に行う必要があります。