サーバと通信を行うAndroidアプリケーションの場合、逆コンパイル対策としては、「重要なデータ・処理は端末側に持たせない」ことが最も有効だと考えられる。
一見当たり前のことのようであるが、現実には実装の複雑さ、電波の状態や通信によるタイムラグなどの点で、端末側にデータを持たせる方が優位な場合もある。このため、リスクを十分に想定せずに設計した場合、端末側に重要な情報/処理を持つ形にしてしまうことも考えられる。もし設計段階でリスクを想定していなかった場合、リスクの許容範囲や実現可能性も含め、一度見直しておくことが望ましい。
また、やむを得ず端末側に重要なデータを置く場合でも、データの閲覧防止や、閲覧を困難にする緩和策を導入することは可能である。
ただし、盗難/紛失などにより端末自体を他人に操作されてしまう状態になった場合、データの閲覧ができなくとも、不正利用自体は避けられない可能性がある。従って、サーバ側でも利用停止処理が可能な仕組みを入れておくことが望ましい。
以下に、データ閲覧対策や緩和策の一例を示す。ここに示したのはあくまでも一例であるため、各アプリケーションに適した対策方法を検討し、導入することが望ましい。
■サーバ側のみで復号/照合が必要なデータ
など
■端末側で復号・照合が必要なデータ
など
情報の利用方法などによって実装可能な対策方法は異なってくるため、アプリケーションごとに検討が必要となる。
実現したい内容によっては、仕組み上、完全な保護策を講じることができず、緩和策を駆使する形になる場合もあるだろう。このため、想定リスクを十分に吟味し、どの情報をどのレベルまで保護するかを決定していく必要がある。
ナツ 「なるほどー。確かに難しいことを考えるよりは、端末側に重要な情報を持たないようにする形にしたほうがシンプルだね」
クウ 「ふむ……。今から複雑な仕組みを導入するより、情報の持ち方を整理するほうが無難かもですね」
ナツ 「クウ、できそう?」
クウ 「たぶんいけると思いますけど、ちょっと考えてみます!」
ナツ 「了解。検討よろしく〜。ちょっと仕様変更になるから、大丈夫かはこっちで確認しとくね」
クウたちは、変更を最小限にとどめる方向で、リリースまでに検討・修正を行うこととした。
アプリケーションが完成した段階では、情報の保持方法のような、アプリケーション全体の基本に関わる部分の仕様変更は容易ではない。場合によっては、アプリケーション全体の大幅な作り直しや、提供機能の削除などを余儀なくされるケースも想定される。このため、取り扱う情報の種類や保持方法については、開発の早い段階で吟味するほうがよい。
ナツ 「確認してきたー。機能が損なわれることがなければ、変更しても大丈夫そうだったよ」
クウ 「了解です。変更が必要なとこも大体把握できました。リリース前にはちゃんとテストまでできそうです」
ナツ 「よかった。それならよろしく〜」
クウ 「はいっ! これ直したら安心してリリースができる状態になるかな〜」
ユウヤ 「……喜んでるとこ悪いけど、また別の問題があったってメール来てるよ」
クウ 「えー……」
ナツ 「まあ、初めてだし仕方ないよね〜」
クウ 「むー」
ナツ 「まだまだ、これから勉強していかないといけないこと多いけど、1つずつこなしていって、理解を深めていこうね」
クウ 「はいっ。頑張りましょー!」
クウたちがアプリ開発を始めてから直面したように、Androidにおけるセキュリティを確保しようとすると、アプリケーションはもちろん、OSの挙動まで考えなければいけない。決して一筋縄ではいかない部分が多く存在する。
本連載では、複数回に渡り、その中の一部の事象について取り上げて解説したが、取り上げた事象以外にも注意すべき点はまだ多く存在している。1つの対策だけで満足してしまわないように、広い視野でセキュリティを考えていくことが重要である。これから皆さんがAndroidアプリを開発する際に、ぜひ、頭の片隅にとどめていただければ幸いだ。
【クウたちの壁紙カレンダー、配布中!】
本連載のイラストを担当しているはるぷさんによる、毎月更新のカレンダーが配布されています。ぜひご利用ください!
特製ウォールペーパー
http://www.ubsecure.jp/wallpaper.php
杉山 俊春(すぎやま としはる)
株式会社ユービーセキュア
技術本部 VEXグループ リーダー 兼 セキュリティオーディットコンサルタント
セキュリティコンサルタントとして、主にWebアプリケーションのセキュリティ検査やWebアプリケーション検査ツールの開発などに従事している。大手ショッピングサイトなどの検査実績を持つ。
Copyright © ITmedia, Inc. All Rights Reserved.