RASP — とは何か、動作原理、リアルタイム保護

RASPとは？

Runtime Application Self-Protection（RASP）は、ビルド時またはランタイムエージェントを介してアプリケーションに統合されるセキュリティ技術です。RASPは実行中にアプリケーションの動作を分析し、コンテキスト（呼び出し元、渡されるデータ、スタックの状態）に基づいて攻撃をブロックする判断を下します。署名ベースのシステムとは異なり、RASPは既知の攻撃パターンを探すのではなく、期待されるコード実行シナリオから逸脱した異常な動作を検出します。

RASPの概念は2011年にGartnerによって形式化され、最初の商用実装は2014–2015年に登場しました。モバイルプラットフォームでは、2017年に市場が従来の難読化の不十分さを認識し、RASPが積極的に使用され始めました。MarketsandMarkets（2025）のレポートによると、RASPソリューション市場は28億USDで、年間成長率は24.5%です。RASPの導入は、支払いデータを処理するアプリケーションに対してOWASP Mobile Top 10およびPCI DSS 4.0標準で推奨されています。

RASPはインターセプションとアセスメントの2つのレベルで動作します。インターセプションとは、ビルド時または動的インストルメンテーションによるランタイムにコードに埋め込まれたフックを介したシステムコールおよびライブラリコールの傍受です。アセスメントとは、呼び出しコンテキストの分析（入力パラメータ、コールスタック、サンドボックス状態、デバッガの存在のチェック）です。判断は開発者が設定したセキュリティポリシーに基づいて行われます。ポリシーは厳格（ブロック）、ソフト（ログ）、または適応型（脅威レベルに応じて動作を変更）にすることができます。

RASPの仕組み：アーキテクチャとメカニズム

RASPエージェントのアーキテクチャは、インストルメンテーション層、アナライザ、ポリシーの3つのコンポーネントで構成されています。インストルメンテーション層はシステムコールとフレームワークコールをインターセプトします。アナライザは期待されるパターンに対してコンテキストをチェックします。ポリシーが応答を決定します。

コードインストルメンテーション

モバイルアプリケーションでは、コンパイル時インストルメンテーションが使用されます。ビルド時にバイトコードまたはネイティブコードが変更され、危険な呼び出しの前にチェックが挿入されます。RASPエージェントコンパイラは、エントリポイントFileOutputStream.write()、Runtime.exec()、Class.forName()、android.app.Activity.onStart()を変更します。Androidでは、Gradleプラグインを介したDEXバイトコード変換が使用され、iOSでは、ポストリンクスクリプトを介したMach-Oバイナリの変更が行われます。

コンテキスト分析

呼び出しをインターセプトする際、RASPは以下を分析します：呼び出し元クラスとメソッド（誰が呼び出しているか）、スタックトレース（呼び出しチェーン）、引数（渡されるデータ）、戻り値（何が返されるか）、タイムスタンプとスレッドID。異常は、例えばRuntime.exec()がUIスレッドやアプリケーションコードからではなく、非標準パスでJNI経由でロードされたライブラリから呼び出された場合に記録されます。または、FileOutputStream.write()が期待されるPNGヘッダーの代わりに実行可能なバイトコードを含むデータを受け取った場合も同様です。

応答ポリシー

RASPは3種類の応答をサポートしています：Block — 攻撃検出時にアプリケーションを強制終了、Log — アプリケーションを停止せずにインシデントの詳細をログ収集サーバーに送信、Deceive — 戻り値を偽の値に置き換えて攻撃者に誤ったデータを渡します。LogとDeceiveの組み合わせにより、検出の事実を明かさずに攻撃者に関する情報を収集できます。

// 例：Runtime.exec()呼び出しのRASPチェック
public class RASPAgent {
    public static Object onExecCalled(String command,
            StackTraceElement[] stack) {

        // 呼び出し元をチェック中
        String caller = stack[1].getClassName();

        // 呼び出しが自パッケージからのものでない場合 — 疑わしい
        if (!caller.startsWith("com.example.app")) {
            SecurityPolicy.reportIncident(
                "UNEXPECTED_EXEC", command, stack
            );
            return SecurityPolicy.getAction().execute(command);
        }

        // ブラックリストに対するコマンドのチェック
        String[] blocked = {"su", "frida", "ptrace", "/data/local"};
        for (String pattern : blocked) {
            if (command.contains(pattern)) {
                SecurityPolicy.reportIncident(
                    "BLOCKED_CMD", command, stack
                );
                return new Process(); // deceiving: 空のプロセス
            }
        }

        return null; // 実行を許可
    }
}

RASP vs WAFおよびその他のセキュリティツール

RASPはWeb Application Firewall（WAF）とよく比較されますが、基本的な違いは位置づけにあります。WAFはネットワーク境界に位置し、HTTPリクエストのみを分析します。RASPはアプリケーション内部で動作し、処理ロジックを認識します。

コードを読み取り不能にする難読化（ProGuard、DexGuard）とは異なり、RASPは攻撃の実行中に積極的に検出します。難読化は受動的な保護であり、攻撃者がリバースエンジニアリングに十分な時間を費やせばコードは読み取られます。RASPは能動的であり、攻撃者がアプリケーションをデバッグしようとしていることを認識し、コードが1行も読み取られる前に対応します。難読化+RASPの組み合わせは多層防御を提供し、難読化が分析を遅らせ、RASPがインストルメンテーション段階で攻撃を中断します。

モバイルアプリケーションにおけるRASP

モバイルRASPソリューションはAndroidとiOSの特性に適応しています。サーバーサイドJavaアプリケーションとは異なり、モバイルRASPエージェントは限られたメモリとバッテリーの条件下で動作するため、軽量なインストルメンテーションが必要です。

AndroidでのRASP

Androidでは、RASPエージェントはビルド時にDEXバイトコードを変更するGradleプラグインを介して組み込まれます。エージェントは50以上のシステムコールをインターセプトします。これには以下が含まれます：Runtime.exec()（suやFridaの実行検出）、Class.forName()（疑わしいクラスのロード識別）、System.loadLibrary()（非標準パスからのネイティブライブラリのロード制御）。さらに、/proc/self/mapsでライブラリfrida-agent、frida-helper、libinject、substrateの存在をチェックします。

iOSでのRASP

iOSでは、RASPはMach-Oバイナリの後処理を通じて実装されます。Appleのバイナリ変更に関する厳格な要件のため、iOSはより複雑です。エージェントはfork()、dlopen()、ptrace()関数の呼び出しをインターセプトし、ロードされたライブラリ内のCydiaSubstrate.dylibの存在をチェックします。iOS用RASPはApp Storeビルドではコードを変更できません — Enterprise配布のみ可能です。App Storeの場合は、Swift MacroまたはObjective-Cメソッドスウィズリングによるコンパイル時インストルメンテーションが推奨されます。

分析ツールの検出

モバイルRASPは以下を検出します：Frida（/proc/self/mapsおよび/data/local/tmp/frida*のチェックによる）、Xposed Framework（ClassLoader内のde.robv.android.xposed.XposedBridgeのチェックによる）、JDWPデバッガ（Debug.isDebuggerConnected()による）、エミュレータ（Build.FINGERPRINT、Build.HARDWARE、Build.MODELのチェックによる）、AndroidManifestのdebuggableフラグ。NowSecure Mobile Threat Report（2025）によると、RASPエージェントはインストルメント化されたFridaセッションの89–97%を検出します。

RASPエージェントの実践的実装

モバイルアプリケーションにRASPを統合するには、インストルメンテーションの設定、ポリシーの定義、インシデントログ収集のためのSIEMシステムとの統合が必要です。

実装の選択：コンパイル時 vs ランタイム

コンパイル時インストルメンテーション — ビルド時のバイトコード変更であり、ランタイムパフォーマンスに影響しません。ランタイムインストルメンテーション（サーバー上のJava Agentまたはクライアント上のFrida経由）はより柔軟ですが、5–10%のオーバーヘッドが追加されます。モバイルアプリケーションでは、一定のネットワーク接続を必要とせず、分析のためにバッテリーを消費しないコンパイル時アプローチが推奨されます。

既存ライブラリとの統合

RASPエージェントは人気のあるSDKと正しく動作する必要があります。Firebase Crashlytics、Google Analytics、Appseeはブロックされるべきではありません。既知のライブラリのホワイトリスト設定は必須です。エージェント設定では例外が指定されます：com.google.firebaseクラスからの呼び出しの場合 — チェックはスキップされます。ホワイトリストは各SDKリリースで更新されます。

インシデント処理の例

RASPエージェントを介してFridaが検出されると、以下の処理が行われます：コンテキスト収集（スタックトレース、OSバージョン、時刻）、暗号化された形式でのログサーバーへのデータ送信、ポリシーの実行（クラッシュ、ログのみ、またはdeceive）、大量攻撃を特定するためのカウンターの増加。異なるデバイスからのデータはサーバーで集約され、攻撃パターンを特定します。

class RASPManager {
    fun analyzeAndReact() {
        val threats = detectThreats()
        if (threats.isNotEmpty()) {
            val report = ThreatReport().apply {
                threats = threats
                timestamp = System.currentTimeMillis()
                deviceId = DeviceInfo.getHashedId()
                stackTrace = Thread
                    .currentThread()
                    .stackTrace
                    .take(10)
                    .toList()
            }

            val policy = SecurityPolicy.getPolicy(threats.maxBy { it.severity })

            when (policy) {
                Policy.BLOCK   -> throw SecurityException("Protection triggered")
                Policy.LOG     -> ServerLogger.sendReport(report)
                Policy.DECEIVE -> DeceptionLayer.activate(report)
            }
        }
    }
}

制限事項と誤検出

RASPは銀の弾丸ではありません。この技術には、保護を設計する際に考慮すべき制限があります。

パフォーマンス

インターセプトされた各呼び出しはコンテキストチェックを追加します。攻撃的な設定（すべてのIOおよびexec呼び出しのインターセプト）では、パフォーマンスが5–15%低下する可能性があります。モバイルアプリケーションでは起動時間が重要であり、RASPの初期化は起動時に200–500ミリ秒追加します。対象を絞ったインストルメンテーション — すべての可能な関数ではなく、重要な関数のみ — が推奨されます。テスト中はRASPエージェントを使用したプロファイリングが必須です。

誤検出

RASPは正当な動作をブロックする可能性があります：ネットワークコールを介してエラースタックを送信するFirebase Crashlyticsはデータ外部流出と誤認される可能性があり、デバイスの整合性をチェックするGoogle Play Integrity APIは疑わしい呼び出しとして識別される可能性があります。誤検出を減らすために、7–14日間の学習モード期間が必要であり、その間RASPはログのみを行いブロックはしません。

RASPの回避

攻撃者がカーネルレベルのアクセスを取得した場合（カーネルエクスプロイト経由）、RASPは自身のチェックすら信頼できません — エージェントはユーザースペースで動作し、カーネルが許可するものだけを認識します。カーネルレベルでの回避を防ぐために、サーバー側アテステーションと組み合わせたSecure Boot Chainチェックが使用されます。さらに、RASPエージェント自体が難読化され、デバッグから保護される必要があります — そうでなければ、攻撃者は攻撃を開始する前にRASPを削除または無効化します。