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는 두 가지 수준에서 작동합니다: 인터셉션과 평가. 인터셉션은 빌드 시 또는 동적 계측을 통한 런타임에 코드에 내장된 훅을 통해 시스템 및 라이브러리 호출을 가로채는 것입니다. 평가는 호출 컨텍스트 분석(입력 매개변수, 호출 스택, 샌드박스 상태, 디버거 존재 여부 확인)입니다. 결정은 개발자가 설정한 보안 정책을 기반으로 이루어집니다. 정책은 엄격(차단), 소프트(로깅) 또는 적응형(위협 수준에 따라 동작 변경)일 수 있습니다.

RASP 작동 방식: 아키텍처 및 메커니즘

RASP 에이전트 아키텍처는 계측 계층, 분석기 및 정책의 세 가지 구성 요소로 구성됩니다. 계측 계층은 시스템 호출과 프레임워크 호출을 가로챕니다. 분석기는 예상 패턴에 대해 컨텍스트를 확인합니다. 정책은 대응을 결정합니다.

코드 계측

모바일 애플리케이션의 경우 컴파일 타임 계측이 사용됩니다. 빌드 시 바이트코드 또는 네이티브 코드가 수정되어 위험한 호출 전에 검사가 삽입됩니다. 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는 세 가지 유형의 대응을 지원합니다: 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 대 WAF 및 기타 보안 도구

RASP는 종종 Web Application Firewall(WAF)과 비교되지만, 근본적인 차이는 위치에 있습니다. WAF는 네트워크 경계에 위치하며 HTTP 요청만 분석합니다. RASP는 애플리케이션 내부에서 작동하며 처리 로직을 확인합니다.

코드를 읽을 수 없게 만드는 난독화(ProGuard, DexGuard)와 달리 RASP는 공격 실행 중에 적극적으로 탐지합니다. 난독화는 수동적 보호입니다. 공격자가 리버스 엔지니어링에 충분한 시간을 투자하면 코드를 읽을 수 있습니다. RASP는 능동적입니다. 공격자가 애플리케이션을 디버깅하려는 것을 감지하고 코드 한 줄이 읽히기도 전에 대응합니다. 난독화 + 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–500ms를 추가합니다. 모든 가능한 함수가 아닌 중요한 함수만 대상으로 하는 계측이 권장됩니다. 테스트 중 RASP 에이전트를 사용한 프로파일링은 필수입니다.

오탐

RASP는 합법적인 동작을 차단할 수 있습니다: 네트워크 호출을 통해 오류 스택을 전송하는 Firebase Crashlytics는 데이터 유출로 오인될 수 있고, 장치 무결성을 확인하는 Google Play Integrity API는 의심스러운 호출로 식별될 수 있습니다. 오탐을 줄이기 위해 7–14일의 학습 모드 기간이 필요하며, 이 기간 동안 RASP는 로깅만 수행하고 차단하지 않습니다.

RASP 우회

공격자가 커널 수준 액세스 권한을 획득하면(커널 익스플로잇을 통해) RASP는 자체 검사조차 신뢰할 수 없습니다 — 에이전트는 사용자 공간에서 작동하며 커널이 허용하는 것만 볼 수 있습니다. 커널 수준에서의 우회를 방지하기 위해 서버 측 증명과 함께 Secure Boot Chain 검사가 사용됩니다. 또한 RASP 에이전트 자체는 난독화되고 디버깅으로부터 보호되어야 합니다 — 그렇지 않으면 공격자가 공격을 시작하기 전에 RASP를 제거하거나 비활성화합니다.