HarmonyOS Nextのセキュリティテスト：ツールとリスク

はじめに

HarmonyOSを稼働する端末が10億台近くに達するなか、モバイルアプリケーションに携わる多くのチームにとって、セキュリティテストは不可欠なものになりました。しかし、HarmonyOS Nextの登場によって大きな転換が起きています。Androidとの互換性がもはや含まれていないのです。これが重要なのは、このシステムが、ほとんどのセキュリティツールが前提とするAndroidのランタイムやフレームワークにもはや依存していないことを意味するからです。その結果、多くのAndroid向けテストツールは動作しなくなるか、不完全な結果しか出せなくなります。だからこそ、セキュリティテストには、Androidをベースとした挙動を前提とするのではなく、HarmonyOS専用に設計されたアプローチが必要になっているのです。

HarmonyOS Nextとは

HarmonyOS Next（HarmonyOS 5.0）は、2024年にリリースされたHuaweiの最新バージョンの一つで、Androidから離れ、完全に独立したオペレーティングシステムになりました。それ以前のHarmonyOSのバージョンには依然としてAndroidのコンポーネントが含まれており、Androidアプリを動作させることができました。しかし、HarmonyOS Nextはこの互換性を完全に取り除いています。これは、独自のカーネル（HongMeng）を含め、すべてがHuawei自身のシステム上に構築されています。その結果、Androidアプリはもはやサポートされず、HarmonyOS向けに専用開発されたアプリケーション（.app）のみが動作します。

HarmonyOS NextのセキュリティテストがAndroidと異なる理由

HarmonyOSは、アプリストア（AppGallery）、権限システム、ネイティブコードのサポートなど、表面的にはAndroidと似通った点があります。しかし、その内部アーキテクチャはまったく異なっており、それがセキュリティテストの進め方に直接影響します。

アプリケーションのランタイムとArkTS

HarmonyOSアプリケーションは、ArkTS（Ark TypeScript）を使って構築されます。これは、ArkUIフレームワークを通じてアプリを構築するためにHuaweiが設計した、TypeScriptベースの言語です。宣言的なUIのアプローチを採用しており、開発者はレンダリングの各ステップを手作業で制御するのではなく、インターフェースがどう見えるべきかを記述します。

ArkTSアプリケーションは、AndroidのDEXバイトコードにコンパイルされる代わりに、Pandaバイトコード（.abc）にコンパイルされます。これにより、Androidのセキュリティツールはすべて互換性を失います。Java/Kotlin向けに作られた静的解析ツールも、DEXファイル向けに設計されたリバースエンジニアリングのワークフローも、ここではそのままは通用しません。

プロセス間通信とDSoftBus

HarmonyOSは、AndroidのBinderシステムの代わりに、端末をまたぐ連携のために設計された通信レイヤーであるDSoftBusを使用します。

これにより、モデルは1台のスマートフォン内でアプリがやり取りするものから、複数の端末にまたがってアプリやサービスが連携するものへと変わります。そのため、セキュリティテストはもはや単一の端末だけを切り離して扱うものではなく、接続された端末間でデータがどう移動するかも対象になります。

HarmonyOSにおける最大の転換は、複数の端末が連携して動作することを中心に設計されている点です。

スマートフォン、タブレット、ウォッチがそれぞれ別個の環境であるAndroidとは異なり、HarmonyOSはアプリやサービスをスマートフォン、タブレット、ウォッチ、テレビ、その他の接続された端末にまたがって動作させることができます。

これは、アタックサーフェスがもはや1台の端末に限定されないことを意味します。端末同士が互いを信頼し、データを共有するときに何が起きるかにも対処しなければなりません。

HarmonyOSの権限もまた、1台の端末にとどまらず、複数の端末にまたがって広がり得ます。

つまり、アプリはスマートフォン本体上のものへのアクセスを求めるだけでなく、エコシステム内のほかの接続された端末に関わる機能へのアクセスを求めることもあります。そのため権限の挙動は把握しづらくなり、慎重に確認しなければ悪用されやすくなります。

HarmonyOS NEXTのセキュリティテストツール

HarmonyOSのセキュリティテストツールは、成熟したAndroidのエコシステムと比べると、まだ初期の開発段階にあります。今日利用できる最も重要なツールをいくつか紹介します。

カテゴリ	ツール / リソース	主な目的	主な機能	制約
Huawei公式ツール	AppGallery Cloud Testing	自動化されたベースラインチェック	既知の設定上の問題や脆弱性パターンをチェックします。	綿密なまたは手動のセキュリティ評価の代替にはなりません。
	DevEco Studio	統合開発環境（IDE）	デバッグユーティリティ、端末エミュレーター、パフォーマンスプロファイラー。	専用のセキュリティ解析向けの組み込みSASTやDASTを備えていません。
	バグバウンティプログラム	外部のセキュリティ研究	独立した研究者が脆弱性を見つけて報告するよう促します。	社内での継続的または自動化されたテストのワークフローには適しません。
コミュニティおよび新興のツール	ArkTS Decompilers	リバースエンジニアリング	コンパイル済みのコードやアプリケーションのロジックを調査できます。	初期段階の開発。手動での設定が必要です。
	ファジングユーティリティ	IPCのセキュリティテスト	プロセス間通信をテストし、クラッシュや脆弱性を調べます。	安定性やCI/CD連携を欠くことが多いです。
セキュリティテストプラットフォーム	Ostorlab	自動脆弱性スキャナー	ArkTS/.abcのアーティファクトを含むHarmonyOSアプリケーションの自動解析。よくあるセキュリティ上の問題や設定ミスを検出し、セキュリティテストのワークフローに組み込めます。	手動のセキュリティレビューを補完しますが、代替にはなりません。

OstorlabによるHarmonyOSおよびHuawei AppGalleryの自動脆弱性スキャン

手動テストを補完し、既存のツールのギャップを埋めるために、自動スキャンはHarmonyOS固有のリスクに対して一貫した反復可能なカバレッジを提供できます。

反復可能でスケーラブルなカバレッジを必要とするチームに対して、Ostorlabの脆弱性スキャナーはHarmonyOSアプリとHuawei AppGalleryのスキャンに直接対応しています。スキャンは、次のようなHarmonyOS固有のリスククラスを対象とします。

• エクスポートされたAbilityの乗っ取りと、暗黙的なWantの傍受
• Distributed Soft Busの悪用（端末をまたぐデータ漏えい、リモートからのAbilityの呼び出し）
• ArkUI WebView経由のJavaScriptインターフェースインジェクション
• 暗号化のないPreferencesやRDBへの安全でないデータ保存
• HUKSをバイパスするハードコードされた鍵と脆弱な暗号
• ネイティブのNAPIモジュールにおけるバッファオーバーフローとuse-after-free
• サプライチェーンにおける脆弱なサードパーティのHAR/HAPパッケージ

注記： これらのリスククラスはHarmonyOSのアーキテクチャに固有のものであり、Android中心のスキャナーでは通常カバーされません。定義についてはHuaweiの公式用語集を参照してください。

検出結果は実証レベルのエビデンスとともに提供されるため、チームはリスクを素早く検証し、修復の優先順位付けを行えます。既存のAppSecパイプラインに組み込んで、リリース前の検証や、継続的でバージョン単位のセキュリティ評価を行えます。

AppGalleryのアプリは、ostorlab.coからログイン不要でスキャンできます。また、アカウントを通じて.HAP / .APPパッケージを直接アップロードすることもできます。

HarmonyOS NEXTの主要なセキュリティ機能

HarmonyOSには、アプリの保護とテストのあり方に影響する組み込みの機能があります。これらはツールではなく、アプリがどう動作するか、何にアクセスできるか、そしてデータがどう保護されるかを定める、システムレベルの制御です。

これらの機能はセキュリティの仕組みを提供しますが、それでもテストの際には正しい実装と検証が求められます。

実行時のセキュリティ：HarmonyOS SafetyDetect API

HarmonyOSは、アプリケーションが実行時に端末の状態を評価できるようにする実行時セキュリティフレームワークであるSafetyDetectを提供します。これには4つの主要な機能が含まれます。

API	技術的な目的	セキュリティ検証の着眼点
SysIntegrity	root化/改ざんされた端末の状態を検知する。	検証は端末側のみで行われる。ネイティブなサーバー側のアテステーションを欠くため、監査人はアプリのロジックをローカルで操作して「クリーン」なステータスを返させられないかを確認する必要がある。
URLCheck	脅威インテリジェンスと照合してURLをスキャンする。	悪意ある結果が返ったときに、バイパス可能な警告をログに記録するだけでなく、アプリがセッションを終了することを検証する。
AppsCheck	端末上の悪意ある/リスクのあるアプリを検知する。	アプリがこれを受動的なテレメトリのためではなく、機微な操作を保護する（例：画面スクレイパーの検知）ために使っていることを確認する。
UserDetect	人間の操作とBotを区別する。	ネイティブAPI（NAPI）インジェクションによるバイパスを防ぐため、得られたトークンがバックエンドで検証されることを確認する。

これらのAPIはアプリケーションのロジックに組み込んで、信頼にかかわる判断を動的に強制できます。ただし、グローバルに展開するチームは、Wi-Fi関連の検知を含む一部のSafetyDetectの機能は、中国本土に限定される場合がある点に留意してください。本番のセキュリティアーキテクチャでこれらの制御に依拠する前に、展開対象のリージョンでAPIの挙動を検証してください。

HarmonyOSのデータ暗号化レベル

HarmonyOSは、アプリのデータにいつアクセスできるかを開発者が制御できる多段階の暗号化システムを使用します。一部のデータは常に利用可能である一方、より機微なデータはアクセスのたびにユーザー認証を要求できます。

このモデルは、一般的なAndroidのデフォルトよりも多くの制御を可能にし、iOSのデータ保護システムに似ています。

実際には、選択する暗号化レベルは、セキュリティと、ユーザーがアプリにどれだけ容易にアクセスできるかの両方に影響します。

レベル	名称	挙動	典型的な用途
EL1	常時有効	端末の電源が入っている間、データにアクセス可能	機微でないシステムまたはアプリのデータ
EL2	初回ロック解除後	端末の初回ロック解除後に利用可能になり、ロック中でも端末が稼働している間はアクセス可能なまま	バックグラウンドサービス（アラーム、システム機能）
EL3	初期ロック解除後	少なくとも1回のロック解除後にアクセス可能。画面がロックされていても利用可能なまま	機微性の低い機能（アクセシビリティ、緊急時データ）
EL4	ロック解除時のみ	端末が実際にロック解除されているときのみアクセス可能。画面がオフになると再びロックされる	ほとんどのアプリケーションデータのデフォルト
EL5	アクセスごとに認証	データへのアクセスのたびにユーザー認証を要求する	高度に機微なデータ（認証情報、健康、金融情報）

HarmonyOSのデータ暗号化レベルとiOSの対応付け

理解しやすくするために、これらのレベルはiOSがデータ保護を扱う方法とおおまかに比較できますが、同等ではありません。iOSにはEL1〜EL5のレベルはありません。代わりに、データへのアクセスは端末の状態と認証に依存します。簡単に言えば、iOSで常に利用可能なシステムデータはEL1に最も近く、初回ロック解除後に利用可能になるデータはEL2〜EL3に似ており、端末が実際にロック解除されていることを要求するデータはEL4に似ており、毎回の認証（Face ID / Touch ID）を要求するデータはEL5に最も近いです。

コードの保護：ArkGuardによる難読化

PandaバイトコードにコンパイルされたHarmonyOSアプリケーションは、端末から取り出せば静的解析が可能です。リバースエンジニアリングのハードルを上げるために、HuaweiはArkGuardを提供しています。これは、ビルドの過程でシンボル名を付け替え、コードの可読性を下げる難読化ツールです。

ArkGuardは静的解析に必要な労力を増やしますが、それ単体でセキュリティ境界として扱うべきではありません。

機微なアプリケーションを効果的に保護するには、多層的なアプローチが必要です。

1. 可能な場合は機微なロジックをバックエンドのシステムに移す
2. SysIntegrityまたは同等の手段を使って実行時にアプリケーションの整合性を検証する
3. 侵害された端末やroot化された端末では機能を制限する
4. リスクプロファイルが正当化する場合はアンチデバッグの仕組みを実装する
5. ArkGuardは実行時の保護の代わりにではなく、それと組み合わせて使う

HarmonyOSの主なセキュリティテスト上の脆弱性

プラットフォームのアーキテクチャとOstorlabのスキャン検出結果の双方に基づくと、HarmonyOSアプリケーションにとって最も重要なリスク領域は次のとおりです。

セキュリティリスク	説明
エクスポートされたAbilityの乗っ取り	HarmonyOSのAbility（AndroidのActivity/Serviceに相当）は、不適切にエクスポートされると悪用され得ます。悪意あるアプリがそれらを呼び出し、アクセス制御をバイパスできるようになります。
Distributed Soft Busの悪用	設定ミスのあるDSoftBus（端末をまたぐ通信レイヤー）は、データ漏えい、認可されていないリモートからのAbilityの呼び出し、端末をまたぐタスクの乗っ取りにつながる可能性があります。
ArkUI WebViewのインジェクション	ArkUI WebView内の安全でないJavaScriptブリッジは、信頼できないWebコンテンツにネイティブAPIを呼び出させる可能性があり、HarmonyOS固有のテストの適応が必要です。
安全でないローカルデータの保存	適切な暗号化なしにPreferencesやRDBに保存された機微なデータは、侵害された端末上で露出する可能性があります。自動スキャンでよく見つかります。
HAR/HAPパッケージによるサプライチェーンリスク	HAR（Harmony Archive）やHAP（Harmony Ability Package）モジュール内の脆弱なサードパーティ依存関係は、エコシステムの成長に伴いサプライチェーンリスクをもたらします。
脆弱な暗号とハードコードされた認証情報	HUKS（Huawei Universal Keystore）をバイパスしたり、コードにシークレットを埋め込んだりすると、脆弱な暗号セキュリティと認証情報の露出につながります。

HarmonyOSのためのOWASP MASVSマッピング

下の表は、チームが既存のテスト計画を適応させる助けとなるよう、OWASP MASVSのカテゴリをHarmonyOSの対応物にマッピングしたものです。

OWASP MASVSカテゴリ	HarmonyOSでの状況	備考
MASVS-STORAGE：機微なデータの保存	適応して適用	HarmonyOSの暗号化レベル（EL1-EL5）がAndroidのファイルベースの暗号化モデルに取って代わります。機微なデータがプラットフォームのデフォルトのままではなく、EL4またはEL5で保存されていることをテストします。
MASVS-CRYPTO：暗号	直接適用	HUKS（HarmonyOS Universal Keystore）がAndroid Keystoreに取って代わります。ハードコードされた鍵、脆弱なアルゴリズム、そしてHUKSが正しく使われているか完全にバイパスされているかをテストします。
MASVS-AUTH：認証	直接適用	Androidのサーバーで検証可能なトークンとは異なり、SysIntegrityのアテステーションは端末側のみです。バックエンドでの検証は別途テストする必要があります。
MASVS-NETWORK：ネットワーク通信	直接適用	標準的なTLSのテストが適用されます。加えて、Androidに対応物のない、端末間のDSoftBusのトラフィックをテストします。
MASVS-PLATFORM：プラットフォーム連携	適応して適用	エクスポートされたAbilityのテストが、Activity/Serviceのエクスポートのテストに取って代わります。インテントベースのテストは、HarmonyOSにおけるWantベースの呼び出しにおおまかに対応します。
MASVS-CODE：コード品質	適応して適用	静的解析のツールがまったく異なります。DEXベースのツールは適用できません。Pandaバイトコードにはark_disasmとArkTS固有の逆コンパイラーが必要です。
MASVS-RESILIENCE：改ざん防止と難読化	適応して適用	ArkGuardは難読化を提供しますが、サーバーレベルでAndroidのSafetyNet/Play Integrityに相当する実行時の整合性はありません。Star Shieldはインストール時の検証のみを扱います。
分散/端末をまたぐアタックサーフェス	OWASPに対応物なし	DSoftBus、分散された権限、端末をまたぐAbilityの呼び出しには、MASVSへの直接的なマッピングがなく、HarmonyOS固有の脅威モデリングが必要です。

よくある質問

Q：HarmonyOSのAbilityとは何ですか。
Abilityは、HarmonyOSアプリの中核的なコンポーネントで、AndroidのActivityやServiceに似ています。設計次第で、画面やバックグラウンドのタスクといった、アプリの特定の機能を表します。

セキュリティの観点では、Abilityはほかのアプリや、さらにはほかの端末にも公開され得ます。適切に設定されていない場合、正しい認可なしに呼び出される可能性があり、意図しない挙動やデータの露出につながりかねません。

Q：マイクロカーネルとは何ですか。そしてHarmonyOSがそれを使うのはなぜですか。
マイクロカーネルは、スレッドのスケジューリングやプロセス間通信といった必須のタスクのみを扱い、カメラ、ネットワーク、ストレージといったサービスは隔離されたユーザーモードのプロセスへと移します。HarmonyOSは独自のマイクロカーネルHongMengを使い、あるサービスが侵害された場合でも被害を限定します。攻撃者がシステムの残りの部分へ容易にピボットできないためです。これは、ほとんどのサービスを単一の特権カーネル空間で実行する従来のLinuxベースのカーネルとは対照的です。

Q：HarmonyOSのセキュリティはAndroidと比べてどうですか。
HarmonyOSは、システムの一部に形式検証を適用し、特定の脆弱性クラスが発生し得ないことを証明しています。同時に、そのHongMengマイクロカーネルは従来のLinuxカーネルよりも大幅に小さく、攻撃者が標的にできるコードの量を抑えています。

Q：Huaweiは、HarmonyOSのアプリやシステムコンポーネントのセキュリティアップデートとパッチ適用をどう扱っていますか。
Huaweiは、システムや組み込みアプリ全体にわたる複数のCVEを修正する、HarmonyOSとEMUI向けの月次セキュリティアップデートをリリースしています。これらのパッチは、メディアモジュールにおける重大度の高い競合状態や、ファイル管理における権限バイパスといった問題をカバーします。

Q：Star Shieldとは何ですか。そして何から保護しますか。
Star Shieldは、システムレベルで厳格なアプリの審査とコード署名のチェックを強制する、HarmonyOS NEXTのセキュリティフレームワークです。すべてのアプリはインストール前にHuaweiによって署名・検証されなければならず、これにより機微なデータへの認可されていないアクセスのほとんどが阻止され、HarmonyOSの以前のAndroid互換バージョンに存在したサイドローディングの経路も大部分が排除されます。

OstorlabでHarmonyOSスキャンを始める

上記で説明した自動スキャンを自社のHarmonyOSアプリで実行したい場合に、必要なものと、カバレッジの境界がどこにあるかを以下に示します。

必要なもの。

• AppGalleryからの、またはファイルとしてのアプリ。 New ScanメニューでAppGalleryを選び、アプリ名またはバンドル名でアプリを検索するか、HarmonyOS Appを選んでパッケージをアップロードします。対応するHarmonyOSのファイルは.HAP、.APP、.RPK、.APK、.AABです。AppGalleryのアプリは、ostorlab.coからログインせずにスキャンすることもできます。
• スキャンプロファイル。 Fastは素早い静的解析を、Fullは静的・動的・バックエンドの解析を、Privacy Scanはプライバシーリスクの調査を実行します。拡張された依存関係の検出のために、オプションでSBOMやロックファイルをアップロードできます。
• ログインが必要なフロー向けのテスト用認証情報。 動的解析がログインの先の画面に到達できるよう、Set scan credentialsのステップで追加します。対応する認証情報の種類については認証付きスキャンを参照してください。

得られるもの。 本ガイドで先に挙げたHarmonyOSのリスククラスに関する検出結果が、それらを検証し優先順位付けするための技術的なエビデンスとともに得られます。HarmonyOSアプリは、マルチアセットスキャンのモバイルアセットにすることもできます。マルチアセットスキャンは、そのアプリをAPI、Webバックエンド、ソースコードとともに1回のスキャンでテストします。マルチアセットスキャンに含められるモバイルアプリは最大1つです。

カバレッジの境界。

• 難読化、改ざん防止、アンチデバッグ、root/ジェイルブレイク検知を検証するMobile Shielding Scanは、AndroidとiOSのアプリ向けに文書化されています。
• 上記のツール一覧の表が示すとおり、自動スキャンはHarmonyOSアプリの手動セキュリティレビューを補完するものであり、それを置き換えるものではありません。

エビデンス。 HarmonyOSアプリスキャン + Huawei AppGalleryスキャンのご紹介では、HarmonyOSとAppGalleryのスキャンの提供開始について説明しており、ストアスキャンとファイルスキャンの手順ガイドが各画面を示しています。

次のステップ。 ostorlab.coでAppGalleryのアプリの無料スキャンを実行するか、デモを予約して、Android、iOS、HarmonyOSのリリースにまたがるテストを計画しましょう。

まとめ

HarmonyOSは、強固な基盤コンポーネントを備えた現代的なセキュリティアーキテクチャを提供します。しかし、このエコシステムのツール、テスト手法、リージョンごとの機能の提供状況は、セキュリティチームがAndroidのワークフローをそのまま適用するのではなく、既存の手法を適応させることを求めます。

HarmonyOSアプリケーションをテストするあらゆるチームにとっての要点は次のとおりです。

• Pandaバイトコードには新しい静的解析ツールが必要であり、既存のDEX向けパイプラインは適用できない
• DSoftBusは、Androidには存在しない端末をまたぐアタックサーフェスをもたらす
• SysIntegrityの実行時のみの信頼モデルは、リスクの高いアプリではバックエンドによる補強を必要とする
• データ暗号化レベルは、デフォルトに委ねるのではなく、意図的に選ぶべきである
• Ostorlabによる自動スキャンは、HarmonyOS固有のリスククラス全体にわたってベースラインのカバレッジを提供する

---

Ostorlabは、Android、iOS、HarmonyOSに対応したモバイルアプリケーションセキュリティテストプラットフォームです。セキュリティチームはOstorlabを使って、アプリケーションのライフサイクル全体にわたってアプリを継続的に評価し、脆弱性を検出しています。Ostorlabを無料で試す →