RASP คืออะไร — Runtime Application Self-Protection ป้องกันแอปมือถือ
เมื่อแอปมือถือให้บริการธนาคาร ร้านค้า และบริการสาธารณะ การป้องกันแอประหว่างทำงานควรพิจารณาควบคู่กับความปลอดภัยฝั่ง Server บทความนี้อธิบาย RASP (Runtime Application Self-Protection) สำหรับมือถือ ความสามารถที่ควรประเมิน ข้อจำกัด และบทบาทของการทดสอบ
RASP คืออะไร?
ในบริบท Mobile Security ผู้ผลิต Guardsquare อธิบาย RASP ว่าเป็นการตรวจพฤติกรรมน่าสงสัยขณะแอป iOS/Android ทำงาน เพื่อช่วยรับมือการดัดแปลงแอปและ Dynamic Analysis โดยทำงานภายในแอป ต่างจากการป้องกันเฉพาะที่เครือข่ายหรือ Perimeter.[6]
อาจเปรียบได้กับ “จุดตรวจภายในแอป” แต่ไม่ควรตีความว่า RASP เข้าใจ Business Logic ทั้งหมด ตรวจทุก Function Call หรือหยุดภัยทุกชนิดได้ ความสามารถขึ้นอยู่กับผลิตภัณฑ์ เวอร์ชัน ระบบปฏิบัติการ และจุดที่นำไปติดตั้ง
RASP ทำงานอย่างไร?
Guardsquare อธิบายว่าการตรวจอาจครอบคลุมทั้งตัวแอปและสภาพแวดล้อม เช่น สัญญาณ Root/Jailbreak หรือ Function Hooking และตอบสนองด้วยการกระทำที่กำหนดไว้ล่วงหน้า เช่น ยุติ Session แสดงคำเตือน หรือจำกัดฟังก์ชัน.[6]
ตัวอย่างขั้นตอนสำหรับวางระบบ:
- Integrate — เลือกวิธีเชื่อมต่อที่ผู้ผลิตรองรับกับ Build Pipeline หรือแอป และตรวจความเข้ากันได้กับ Framework ที่ใช้
- Monitor — กำหนดสัญญาณที่ต้องตรวจ ไม่สมมติว่าครอบคลุมทุกการทำงานของแอป
- Detect — ประเมินผลตรวจภัยควบคู่กับ False Positive บนอุปกรณ์ที่ผู้ใช้ใช้งานจริง
- Respond — กำหนดการเตือน จำกัดฟังก์ชัน หรือส่งสัญญาณให้ Server โดยพิจารณาความเสี่ยงและผลกระทบต่อผู้ใช้
RASP vs WAF vs SAST vs DAST — ตารางเปรียบเทียบ
ตารางนี้เปรียบเทียบบทบาทเพื่อช่วยออกแบบการป้องกัน ไม่ใช่ผล Benchmark หรือคำรับรองคุณสมบัติของผลิตภัณฑ์ใด
| มิติ | Mobile RASP | WAF | SAST | DAST |
|---|---|---|---|---|
| ชื่อเต็ม | Runtime Application Self-Protection | Web Application Firewall | Static Application Security Testing | Dynamic Application Security Testing |
| งานหลัก | ตรวจและตอบสนองต่อสัญญาณเสี่ยงภายในแอประหว่างทำงาน | ตรวจและควบคุม HTTP/HTTPS ที่ผ่านจุดบังคับใช้นโยบาย | วิเคราะห์โค้ดหรือ Artifact โดยไม่รันแอปตามปกติ | ทดสอบพฤติกรรมแอปหรือบริการที่กำลังทำงาน |
| ตำแหน่ง | ในแอปหรือส่วนประกอบที่เชื่อมเข้าไป | หน้า Web/API หรือจุดที่รับส่ง Traffic | ในวงจรพัฒนาและตรวจโค้ด | สภาพแวดล้อมทดสอบที่เปิดใช้งานแอป |
| ต้องมี Source Code หรือไม่ | ขึ้นกับวิธี Integration | โดยทั่วไปไม่ต้อง | ขึ้นกับเครื่องมือ บางชนิดวิเคราะห์ Bytecode/Binary | โดยทั่วไปไม่ต้อง แต่ต้องตั้งค่าการเข้าถึงตามขอบเขต |
| การป้องกันระหว่างใช้งาน | ตอบสนองตามสัญญาณและนโยบายที่รองรับ | บล็อกหรือจำกัด Request ที่ผ่าน WAF ตามนโยบาย | แจ้งสิ่งที่ควรแก้ ไม่ใช่ Runtime Enforcement | แจ้งสิ่งที่พบจากการทดสอบ ไม่ใช่ Runtime Enforcement |
| บทบาทต่อ Mobile App | เพิ่มความทนทานของตัวแอป | ช่วยปกป้อง Backend Web/API ไม่ใช่ Binary บนโทรศัพท์ | ตรวจแอปและ Backend ที่เครื่องมือรองรับ | ประเมินพฤติกรรมและ API ตามขอบเขตทดสอบ |
RASP, WAF, SAST และ DAST ไม่ได้แทนที่กัน และไม่ควรจัดอันดับ False Positive ว่าเครื่องมือประเภทใดต่ำหรือสูงกว่าเสมอโดยไม่มีชุดทดสอบเดียวกัน RASP ในบทความนี้หมายถึงการป้องกันแอปมือถือ ไม่อนุมานความสามารถจากผลิตภัณฑ์ RASP ฝั่ง Server
RASP ทำอะไรได้: ความสามารถที่ควรประเมิน
Guardsquare กล่าวถึง Root/Jailbreak Detection, Runtime Integrity Checks และการตรวจภัยระหว่างทำงาน ส่วน OWASP MASVS แยก RESILIENCE ออกจาก AUTH, NETWORK, STORAGE และ Control กลุ่มอื่น จึงควรตรวจความปลอดภัยแต่ละด้านแยกกัน ไม่สรุปว่ามี RASP แล้วผ่าน MASVS ทั้งหมด.[6][3]
1. Root/Jailbreak Detection
ประเมินว่าเครื่องมือรับรู้สภาพแวดล้อมที่ถูกเปลี่ยนสิทธิ์ระบบได้เพียงใด และแอปตอบสนองตามนโยบายหรือไม่ การตรวจว่าไม่พบ Root/Jailbreak ไม่ใช่หลักฐานว่าอุปกรณ์ปราศจากมัลแวร์; ควรทดสอบทั้งกรณีเสี่ยงและอุปกรณ์ปกติที่องค์กรรองรับ
2. TLS และ Certificate Pinning
Pinning เป็นการจำกัด Certificate/Public Key ที่ยอมรับเพิ่มเติมจากการตรวจ TLS ปกติ ไม่ใช่คุณสมบัติที่ต้องรวมใน RASP ทุกผลิตภัณฑ์ ตัวอย่าง Android Network Security Configuration ใช้ Hash ของ Public Key และแนะนำให้มี Backup Key เพื่อรองรับการเปลี่ยน Key/CA โดยไม่ทำให้แอปขาดการเชื่อมต่อ.[5]
ควรแยกผลตรวจการเชื่อมต่อออกจากผลตรวจ Integrity ของแอป และไม่ถือว่าการทดสอบบนอุปกรณ์ที่ผู้ทดสอบควบคุมได้สะท้อนความสามารถดักข้อมูลผู้ใช้ทั่วไปจากระยะไกล
3. Code Integrity Check
ตรวจว่าแอปหรือส่วนประกอบสำคัญอยู่ในสภาพที่อนุญาตหรือไม่ เช่น การตรวจลายเซ็นและความสมบูรณ์ของไฟล์ตามวิธีที่แพลตฟอร์มและผลิตภัณฑ์รองรับ ควรกำหนดว่าจะตรวจเมื่อใด ตอบสนองอย่างไร และบันทึกหลักฐานอะไร โดยไม่พึ่งเพียงผลตรวจด้าน Client สำหรับอนุญาตธุรกรรมสำคัญ
4. Anti-Debugging และ Instrumentation Detection
ประเมินการรับรู้การวิเคราะห์หรือเปลี่ยนพฤติกรรมแอปขณะทำงาน คำว่า Debugger และ Dynamic Instrumentation ไม่ใช่สิ่งเดียวกันเสมอ ต้องตรวจว่าผลิตภัณฑ์รองรับสัญญาณใดและมีข้อจำกัดอะไร ไม่สรุปจากชื่อฟีเจอร์เพียงอย่างเดียว
5. Anti-Tampering
ประเมินการรับรู้แอปที่ถูกแก้ไขหรือบรรจุใหม่ รวมถึงการตอบสนองต่อ Integrity Check ที่ผิดพลาด มาตรการนี้สัมพันธ์กับ Code Integrity และ Code Hardening แต่ไม่มีหลักฐานว่าการใช้ฟีเจอร์เดียวทำให้แอปแก้ไขไม่ได้โดยเด็ดขาด
6. Environment และ Screen Protection
ตัวอย่างเงื่อนไขที่ควรถามผู้ผลิตและทดสอบแยกตาม OS:
- Emulator/Virtual Environment — รองรับการตรวจแบบใด และมีกรณีใช้งานที่องค์กรอนุญาตหรือไม่
- Overlay/Remote Control — แยกพฤติกรรมเสี่ยงออกจากเครื่องมือช่วยการเข้าถึงที่ผู้ใช้จำเป็นต้องใช้ได้อย่างไร
- Screen Protection — ปิดบังหรือจำกัดการจับภาพในหน้าสำคัญได้แค่ไหน ไม่ถือว่าป้องกันการบันทึกภาพทุกช่องทางได้
รายการนี้เป็น Checklist สำหรับประเมิน ไม่ใช่การอ้างว่าทุกข้อรวมอยู่ใน RASP ทุกตัว
ตัวอย่างผลิตภัณฑ์และเกณฑ์เลือก RASP
เอกสารของ Guardsquare (DexGuard / iXGuard) นำเสนอ Code Hardening และ RASP สำหรับ Android/iOS รวมถึงแนวทางเปลี่ยนตำแหน่งและรูปแบบ Check ในแต่ละ Build.[6] นี่เป็นคำอธิบายจากผู้ผลิต ไม่ใช่ผลเปรียบเทียบอิสระหรือหลักฐานว่าใช้แพร่หลายในธนาคารไทย
เกณฑ์ที่แนะนำให้ประเมินกับแอปจริง:
| ประเด็น | หลักฐานที่ควรขอหรือทดสอบ |
|---|---|
| Compatibility | เวอร์ชัน OS, Framework, ABI และวิธี Build ที่รองรับ |
| Coverage | Control ที่เปิดใช้งานจริง จุดตรวจ และข้อยกเว้น |
| ผลกระทบผู้ใช้ | เวลาเปิดแอป Crash การใช้ทรัพยากร และ False Positive |
| Operational Response | นโยบายเตือน/จำกัดบริการ การส่ง Telemetry และแนวทางช่วยเหลือผู้ใช้ |
| Maintenance | การอัปเดต SDK การทดสอบเมื่อเปลี่ยน OS และแผนย้อนกลับเมื่อเกิดปัญหา |
| Privacy | ข้อมูลที่เก็บ วัตถุประสงค์ ระยะเวลาเก็บ และสิทธิ์เข้าถึง |
ไม่ควรใช้คำโฆษณาว่า “Bypass ยากแบบ Exponential” เป็นผลพิสูจน์ทางเทคนิคหากไม่มีวิธีวัดและข้อมูลทดสอบรองรับ
ข้อจำกัดของ RASP และบทบาทของ Pentest
ไม่ควรรับรองว่า RASP ป้องกันได้ทั้งหมด และไม่ควรฟันธงว่า RASP ทุกผลิตภัณฑ์ถูกหลบเลี่ยงได้ทุกกรณีเช่นกัน ผลขึ้นอยู่กับ Threat Model สิทธิ์บนอุปกรณ์ การติดตั้ง และเงื่อนไขการทดสอบ
1. ความครอบคลุมของจุดตรวจ
ต้องประเมินว่าจุดตรวจสัมพันธ์กับฟังก์ชันสำคัญจริงหรือไม่ มีเส้นทางใช้งานที่ไม่ได้รับการป้องกันหรือไม่ และนโยบายตอบสนองครอบคลุมสถานะ Offline หรือข้อผิดพลาดอย่างไร
2. ความเสี่ยงจากการพึ่ง Client
การตรวจบนอุปกรณ์ผู้ใช้ไม่ควรแทนการตรวจสิทธิ์ เจ้าของบัญชี สถานะธุรกรรม และข้อจำกัดการทำรายการฝั่ง Server ควรแยก Security Boundary ให้ชัด และออกแบบให้ข้อมูลจาก Client เป็นสิ่งที่ต้องตรวจสอบ
3. False Positive และการเข้าถึงบริการ
การปิดแอปเมื่อพบสัญญาณเสี่ยงอาจกระทบผู้ใช้ปกติ จึงควรมีข้อมูลประกอบการตัดสินใจ กระบวนการช่วยเหลือ และการประเมินผลกระทบต่อ Accessibility โดยไม่ลดทอนข้อกำหนดที่ใช้บังคับ
4. ผลทดสอบมีขอบเขต
OWASP MASVS/MASTG ช่วยจัดโครงสร้างการตรวจและความสม่ำเสมอของผลทดสอบ ขณะที่ Guardsquare เองแนะนำ Testing และ Monitoring ควบคู่กับการป้องกัน.[3][6] ควรกำหนดขอบเขตที่ได้รับอนุญาต เก็บหลักฐานสิ่งที่พบ และทดสอบซ้ำหลังแก้ไข ไม่ใช้ผลผ่านครั้งเดียวรับรองว่าแอปปลอดภัยตลอดไป
แนวทางที่แนะนำ: Defense in Depth
| ชั้น | ตัวอย่างมาตรการ | เป้าหมาย |
|---|---|---|
| Code Hardening | Obfuscation และลด Secret ในแอป | เพิ่มความยากในการทำความเข้าใจและลดข้อมูลที่เปิดเผย |
| RASP | Integrity/Environment Checks ตามที่รองรับ | ตรวจและตอบสนองต่อสัญญาณเสี่ยงระหว่างทำงาน |
| Server-side Validation | ตรวจสิทธิ์และเงื่อนไขธุรกรรมฝั่ง Server | ไม่ใช้การตัดสินใจของ Client เป็นหลักฐานเพียงอย่างเดียว |
| Threat Monitoring | Telemetry ที่จำเป็นและการติดตามเหตุ | ตรวจแนวโน้มและประเมินผลกระทบต่อผู้ใช้ |
| Security Testing | Review, ทดสอบตามความเสี่ยง และ Retest | ค้นหาช่องว่างภายใต้ขอบเขตที่กำหนด |
RASP กับข้อกำหนด ธปท.
ประกาศ ธปท. ที่ 4/2568 ใช้กับสถาบันการเงินตามกฎหมายว่าด้วยธุรกิจสถาบันการเงิน ข้อ 5.3.2 กำหนดมาตรการที่เกี่ยวข้องกับการป้องกันฝั่งแอป ได้แก่.[1]
- ข้อ (2.3) ตรวจการเปลี่ยนแปลงแอปทันทีทุกครั้งที่เข้าใช้งาน และไม่ให้ใช้แอปที่ถูกเปลี่ยนแปลงแก้ไข.[1]
- ข้อ (2.5) ป้องกัน Source Code ไม่ให้อ่านเข้าใจได้ง่าย เช่น Obfuscation.[1]
- ข้อ (3.1) ไม่ให้แอปใช้งานบนอุปกรณ์ที่ตรวจพบ Root/Jailbreak.[1]
- ข้อ (3.2) ไม่ให้แอปทำงานขณะที่แอปอื่นมีพฤติกรรมเสี่ยงต่อการสวมรอย เช่น Remote Control หรือปิดบัง/ขโมยข้อมูลบนหน้าจอ.[1]
RASP อาจช่วยดำเนินการบาง Control แต่ประกาศนี้ ไม่ได้กำหนดให้ซื้อผลิตภัณฑ์ชื่อ RASP หรือยี่ห้อใด และการติดตั้ง RASP ไม่ได้ยืนยันว่าผ่านทุกข้อกำหนด ต้องตรวจการนำไปใช้ร่วมกับการปกป้องข้อมูล Session และระบบฝั่ง Server.[1]
สรุป
RASP เป็นส่วนหนึ่งของการป้องกันแอปมือถือ ไม่ใช่สิ่งทดแทน Secure Development หรือการตรวจธุรกรรมฝั่ง Server แนวทางที่แนะนำคือ:
- ใช้ RASP ร่วมกับ Code Hardening ตาม Threat Model
- ตรวจสิทธิ์และ Business Logic สำคัญฝั่ง Server
- ทดสอบตามความเสี่ยงและเมื่อมีการเปลี่ยนแปลงสำคัญ
- ติดตามภัยควบคู่กับ False Positive และผลกระทบผู้ใช้
- บริการ Mobile Penetration Testing →
- อ่านเพิ่ม: ความปลอดภัยแอป Mobile Banking →
- หลักสูตร Mobile Pentest Training →
Sources
[1] บนอุปกรณ์เคลื่อนที่(Mobile Banking Security) สาหรับสถาบันการเงิน
[3] OWASP MASVS - OWASP Mobile Application Security
[5] Network security configuration | Security | Android Developers
[6] What is Runtime Application Self-Protection (RASP)? | Guardsquare