セキュリティ上のリスクが増大

AppleはなぜiOSアプリの「ホットパッチング」を禁止したのか

Appleは、モバイルアプリ開発者によるホットパッチングの利用を禁止した。この技術は、審査済みのアプリの挙動を変更できるからだ。

公開 2017年06月02日 08時01分

更新 2018年03月01日 11時17分

著者

Kevin Beaver

[TechTarget]

印刷する

Appleの「方針変更」が開発者やIT管理者、そしてユーザーを振りまわすのも事実だが、それが結果的に全体のメリットとなることもある

　Appleは2017年3月から、「Rollout.io」や「JSPatch」のようなフレームワークを通じてホットパッチングを利用しているモバイルアプリ開発者に対し、Appleの規定に違反していると警告し始めた。

　Appleは開発者に送信した電子メールの中で、次のように述べている。「あなたのアプリケーション、拡張、またはリンクされたフレームワークは、アプリケーション審査の承認後にあなたのアプリケーションの挙動や機能を変更できるように明確に設計されたコードを含んでいるようです。これは、Apple Developer Programライセンス契約の3.3.2と、App Store審査ガイドライン2.5.2に違反しています」

　ガイドライン2.5.2は、次のように定められている。「アプリケーションはバンドル内で自己完結している必要があります。別のiOS、watchOS、macOS、tvOSのアプリケーションを含め、指定されたコンテナエリア外に対するデータの読み書き、またはエリア外からのコードのダウンロード、インストール、実行は許可されません」（訳注：なお、審査ガイドラインの引用部分は、こちらを参照しています）

併せて読みたいお薦め記事

Apple製品を襲うセキュリティリスク

Apple製品のセキュリティリスクを回避する取り組み

　ホットパッチングは、エンドユーザーにとって透過的なリモート更新プロセスを指す。モバイルアプリケーションの脆弱（ぜいじゃく）性を緊急に修正する必要がある場合など、開発者とエンドユーザーの両方にとって、大半の状況で優れたアプローチだ。だが、ホットパッチングは、「App Store」などのアプリケーションエコシステムでは、問題視される可能性がある。ホットパッチングによって、AppleのApp Store審査後にアプリの挙動や機能を変更できるからだ。これにより、悪意ある開発者や中間者攻撃を行う者は、Appleの監督を回避して、思い通りにコードを注入または変更できる。

　悪意あるコードについての自分の知識と、人々のシステムのセキュリティやプライバシーを侵害しようとするハッカーや政府機関の数を考え合わせると、この件に関するAppleの判断は責められない。App Storeのセキュリティは常に厳重に監視されており、開発者にホットパッチングの利用を認め続ければ、Appleがユーザーの利益を最優先して行ってきた取り組みが、無駄になるかもしれない。

　Appleがこうしたパッチングを認める決定を下した当時は、悪意ある者が悪用する可能性を考慮していなかったのだろう。この決定の下でホットパッチングを直接利用してきたのは、モバイルアプリユーザー数全体と比べると比較的少ない開発者だ。だが、Appleはビジネス上の判断として、全体のリスクを最小限に抑えるために、その利用を禁止するに至った。

　では、この変更はエンタープライズ環境にどのような影響を与えるだろうか。

　Appleによると、エンドユーザーの観点から見れば、ホットパッチングが行われていたiOSアプリは、これまでより安全になると考えられる。アプリのアップデートは、Appleによる再審査を受けなければならないからだ（バグのアップデートは、App Store審査プロセスを通過する必要がある。ただし開発者は、重大な脆弱性を修正するアップデートについては、優先審査を求めることができる）。

　ただし「Appleは、App Store審査プロセスの対象となる全てのモバイルアプリの全ての欠陥を発見することを保証できる」という確証はない。Appleはホットパッチングを排除したことで、モバイルアプリの脆弱性を調べるセキュリティチェックを、これまでより数多く実施しなければならないだろう。それでも、ユーザーが直面する基本的なコンピュータおよび情報が抱える数多くの脆弱性の中で、ホットパッチングの悪用については、危険が最小化されたと考えられる。

　エンタープライズセキュリティに関しては、以下の領域を考慮する必要がある。

モバイルアプリ開発のライフサイクルに組み込む（または組み込む必要がある）セキュリティのレベル。モバイルアプリを従来のソフトウェア開発ライフサイクルの管理下に置くか。誰が脅威の基準とモデルを定義するか
自社の環境で、特に中核的なビジネス目的で使われるモバイルアプリに対するチェックのレベル。どのようなリスクにさらされているか。CheckmarxやNowSecureのようなベンダーのツールを使って、セキュリティの欠陥をテストしたか
BYOD（私物デバイスの業務利用）とモバイルアプリ利用に関して、ユーザーが決定できる事項。これに基づくシャドーITによって、社内における攻撃対象がどのような影響を受けるか、ビジネスリスクがどの程度上昇するか
自社の環境で行われているモバイルデバイスおよびアプリの監視とアラートの規模。問題のあるアプリや悪意あるネットワークトラフィックを検出できるか。検出した場合の対応策はどのようなものか
ネットワーク全体のセキュリティアーキテクチャ（仮想ネットワーク、ゲスト用無線LAN、クラウドサービスを含む）。モバイルアプリの脆弱性が悪用されてしまった場合、本番環境の基幹部分がどのようなリスクにさらされるか

　確かに、モバイルアプリをより快適かつ安全に使えるようにすることを目指している開発者とRollout.ioのような企業が反対の意を示すのに同情してもいいだろう。Appleがホットパッチングの禁止に踏み切ったことが、彼らの反発を買っているのは確かだ。この決定は、モバイルアプリの開発およびサポートライフサイクルにおいて、効率やセキュリティを損なっている。とはいえ、Rollout.ioは認証ベースのソリューションを提案しており、誰もが納得のいく妥協点を見いだすのにこれが役立つかもしれない。

　今後の行方がどうなるかにかかわらず、アプリケーションセキュリティや情報セキュリティに携わる人は、この問題とその帰結を見守る必要がある。

印刷する