RASP — এটি কী, কাজের পদ্ধতি এবং রিয়েল-টাইম সুরক্ষা

RASP কী?

Runtime Application Self-Protection (RASP) একটি নিরাপত্তা প্রযুক্তি যা বিল্ড টাইমে বা রানটাইম এজেন্টের মাধ্যমে অ্যাপ্লিকেশনে সংহত করা হয়। RASP এক্সিকিউশনের সময় অ্যাপ্লিকেশনের আচরণ বিশ্লেষণ করে এবং কনটেক্সটের ভিত্তিতে আক্রমণ ব্লক করার সিদ্ধান্ত নেয়: কলটি কোথা থেকে এসেছে, কী ডেটা পাস করা হচ্ছে, স্ট্যাকের অবস্থা কী। সিগনেচার-ভিত্তিক সিস্টেমের বিপরীতে, RASP পরিচিত আক্রমণের প্যাটার্ন খোঁজে না — এটি অস্বাভাবিক আচরণ সনাক্ত করে যা প্রত্যাশিত কোড এক্সিকিউশন পরিস্থিতি থেকে বিচ্যুত হয়।

RASP ধারণাটি Gartner দ্বারা 2011 সালে আনুষ্ঠানিকভাবে রূপায়িত হয়েছিল এবং প্রথম বাণিজ্যিক বাস্তবায়ন 2014–2015 সালে আবির্ভূত হয়। মোবাইল প্ল্যাটফর্মের জন্য, RASP সক্রিয়ভাবে 2017 সালে ব্যবহার শুরু হয়, যখন বাজার ঐতিহ্যবাহী অস্পষ্টকরণের (obfuscation) অপ্রতুলতা উপলব্ধি করে। MarketsandMarkets (2025) এর রিপোর্ট অনুযায়ী, RASP সমাধানের বাজার 2.8 বিলিয়ন USD যেখানে বার্ষিক বৃদ্ধি 24.5%। পেমেন্ট ডেটা প্রক্রিয়াকারী অ্যাপ্লিকেশনের জন্য OWASP Mobile Top 10 এবং PCI DSS 4.0 মানদণ্ড দ্বারা RASP বাস্তবায়ন সুপারিশ করা হয়।

RASP দুটি স্তরে কাজ করে: ইন্টারসেপশন এবং অ্যাসেসমেন্ট। ইন্টারসেপশন — বিল্ড টাইমে বা ডায়নামিক ইন্সট্রুমেন্টেশনের মাধ্যমে রানটাইমে কোডে এম্বেড করা হুকের মাধ্যমে সিস্টেম এবং লাইব্রেরি কল ইন্টারসেপ্ট করা। অ্যাসেসমেন্ট — কল কনটেক্সট বিশ্লেষণ: ইনপুট প্যারামিটার, কল স্ট্যাক, স্যান্ডবক্স অবস্থা, ডিবাগারের উপস্থিতি পরীক্ষা। সিদ্ধান্ত ডেভেলপারের নির্ধারিত নিরাপত্তা নীতির ভিত্তিতে নেওয়া হয়। নীতি কঠোর (ব্লক), নরম (লগ) বা অভিযোজিত (হুমকির স্তর অনুযায়ী আচরণ পরিবর্তন) হতে পারে।

RASP কীভাবে কাজ করে: আর্কিটেকচার এবং প্রক্রিয়া

RASP এজেন্ট আর্কিটেকচারে তিনটি উপাদান রয়েছে: ইন্সট্রুমেন্টেশন লেয়ার, বিশ্লেষক এবং নীতি। ইন্সট্রুমেন্টেশন লেয়ার সিস্টেম কল এবং ফ্রেমওয়ার্ক কল ইন্টারসেপ্ট করে। বিশ্লেষক প্রত্যাশিত প্যাটার্নের বিপরীতে কনটেক্সট পরীক্ষা করে। নীতি প্রতিক্রিয়া নির্ধারণ করে।

কোড ইন্সট্রুমেন্টেশন

মোবাইল অ্যাপ্লিকেশনের জন্য কম্পাইল-টাইম ইন্সট্রুমেন্টেশন ব্যবহার করা হয়: বিল্ড টাইমে বাইটকোড বা নেটিভ কোড পরিবর্তন করা হয় — প্রতিটি বিপজ্জনক কলের আগে একটি পরীক্ষা ঢোকানো হয়। RASP এজেন্ট কম্পাইলার এন্ট্রি পয়েন্ট FileOutputStream.write(), Runtime.exec(), Class.forName() এবং android.app.Activity.onStart() পরিবর্তন করে। Android-এর জন্য, Gradle plugin-এর মাধ্যমে DEX বাইটকোড ট্রান্সফর্মেশন ব্যবহার করা হয়; iOS-এর জন্য, পোস্ট-লিংক স্ক্রিপ্টের মাধ্যমে Mach-O বাইনারি পরিবর্তন।

কনটেক্সট বিশ্লেষণ

একটি কল ইন্টারসেপ্ট করার সময়, RASP বিশ্লেষণ করে: কলার ক্লাস এবং মেথড (কে কল করছে), স্ট্যাক ট্রেস (কল চেইন), আর্গুমেন্ট (পাস করা ডেটা), রিটার্ন ভ্যালু (কী ফিরছে), টাইমস্ট্যাম্প এবং থ্রেড আইডি। একটি অসঙ্গতি রেকর্ড করা হয় যখন, উদাহরণস্বরূপ, 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 এজেন্ট একটি Gradle plugin-এর মাধ্যমে এম্বেড করা হয় যা বিল্ড টাইমে DEX বাইটকোড পরিবর্তন করে। এজেন্ট 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 method swizzling-এর মাধ্যমে কম্পাইল-টাইম ইন্সট্রুমেন্টেশন সুপারিশ করা হয়।

বিশ্লেষণ সরঞ্জাম সনাক্তকরণ

মোবাইল 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 এজেন্ট 89–97% ইন্সট্রুমেন্টেড Frida সেশন সনাক্ত করে।

বাস্তবে RASP এজেন্ট বাস্তবায়ন

মোবাইল অ্যাপ্লিকেশনে RASP সংহত করতে ইন্সট্রুমেন্টেশন কনফিগার করা, নীতি নির্ধারণ এবং ঘটনা লগ সংগ্রহের জন্য SIEM সিস্টেমের সাথে সংহতকরণ প্রয়োজন।

বাস্তবায়ন পছন্দ: কম্পাইল-টাইম বনাম রানটাইম

কম্পাইল-টাইম ইন্সট্রুমেন্টেশন — বিল্ড টাইমে বাইটকোড পরিবর্তন, রানটাইম কর্মক্ষমতা প্রভাবিত করে না। রানটাইম ইন্সট্রুমেন্টেশন (সার্ভারে 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 ms যোগ করে। লক্ষ্যযুক্ত ইন্সট্রুমেন্টেশন সুপারিশ করা হয় — শুধুমাত্র গুরুত্বপূর্ণ ফাংশন, সব সম্ভাব্য নয়। পরীক্ষার সময় RASP এজেন্টের সাথে প্রোফাইলিং বাধ্যতামূলক।

মিথ্যা পজিটিভ

RASP বৈধ আচরণ ব্লক করতে পারে: Firebase Crashlytics নেটওয়ার্ক কলের মাধ্যমে ত্রুটি স্ট্যাক পাঠায়, এটি ডেটা নিষ্কাশন বলে ভুল হতে পারে; Google Play Integrity API ডিভাইস অখণ্ডতা পরীক্ষা করে, এটি সন্দেহজনক কল হিসাবে চিহ্নিত হতে পারে। মিথ্যা পজিটিভ কমাতে, 7–14 দিনের শেখার মোড (learning mode) প্রয়োজন, যার সময় RASP শুধু লগ করে কিন্তু ব্লক করে না।

RASP বাইপাস করা

যদি আক্রমণকারী কার্নেল-স্তরের অ্যাক্সেস পায় (কার্নেল এক্সপ্লয়িটের মাধ্যমে), RASP নিজের পরীক্ষার উপরও নির্ভর করতে পারে না — এজেন্ট ইউজার স্পেসে কাজ করে এবং কেবল তা-ই দেখে যা কার্নেল তাকে দেখতে দেয়। কার্নেল স্তরে বাইপাস প্রতিরোধ করতে, সার্ভার-সাইড অ্যাটেস্টেশন-এর সাথে Secure Boot Chain পরীক্ষা ব্যবহার করা হয়। অতিরিক্তভাবে, RASP এজেন্ট নিজেই অস্পষ্ট এবং ডিবাগিং থেকে সুরক্ষিত হতে হবে — অন্যথায় আক্রমণকারী আক্রমণ শুরু করার আগে RASP সরিয়ে বা নিষ্ক্রিয় করবে।