- การนำระบบตรวจสอบความปลอดภัยแบบละเอียดมาใช้ ซึ่งจะแทนที่การแก้ไขช่องโหว่ความปลอดภัยแบบเดิมด้วยการวิเคราะห์แบบแยกส่วน
- ความสามารถในการตรวจสอบช่องโหว่เฉพาะเจาะจงผ่านการบูรณาการกับฐานข้อมูล OSV และการติดตาม CVE
- การกำหนดมาตรฐานการสื่อสารระหว่างผู้ผลิตและแอปพลิเคชันผ่านผู้ให้บริการสถานะความปลอดภัยเพื่อจัดการการอัปเดต OTA
การรักษาความปลอดภัยของสมาร์ทโฟน Android ในปัจจุบันนั้นพูดตามตรงคือเป็นเรื่องที่ยุ่งยากมาก ด้วยความซับซ้อนของระบบนิเวศที่เพิ่มขึ้น นักพัฒนาจึงเคยอาศัยตัวชี้วัดทั่วไปที่เรียกว่าระดับการอัปเดตความปลอดภัย (Security Patch Level หรือ SPL) ซึ่งก็เหมือนกับการพยายามตรวจสอบว่าบ้านปลอดภัยหรือไม่โดยดูจากวันที่ปรับปรุงครั้งใหญ่ครั้งล่าสุด โดยไม่รู้ว่ากลอนประตูหลังยังเสียอยู่หรือไม่
เพื่อแก้ไขช่องว่างด้านข้อมูลนี้ ไลบรารี AndroidX Security State และ Security State Provider จึงถือกำเนิดขึ้น เครื่องมือเหล่านี้เป็นตัวเปลี่ยนเกมอย่างแท้จริง โดยให้ข้อมูลเชิงลึกที่ละเอียดในทุกส่วนของระบบ ทำให้ซอฟต์แวร์มีความยืดหยุ่นต่อการโจมตีอย่างแท้จริง และช่วยให้แอปสามารถตัดสินใจได้อย่างชาญฉลาดโดยอิงจากหลักฐานจริง ไม่ใช่เพียงแค่การคาดเดา จึงเป็นการสร้าง โมเดลความไว้วางใจเป็นศูนย์ (Zero Trust )
ลาก่อนแพทช์เดี่ยว: ยุคแห่งความละเอียดเชิงลึก
ปัญหาสำคัญของการพึ่งพา SPL เพียงตัวเดียวคือ ปัจจุบัน Android ได้รับการอัปเดตแบบทีละส่วนเนื่องจาก Project Mainline และการอัปเดตระบบของ Google Play เพื่อจัดการกับความวุ่นวายนี้ ไลบรารีใหม่จึงแบ่งความปลอดภัยออกเป็นสามส่วนหลัก ได้แก่ระบบปฏิบัติการหลัก (อัปเดตผ่านทางอากาศ) โมดูลระบบ (ส่งผ่าน Google Play) และเคอร์เนล Linuxซึ่งเป็นรากฐานของทุกสิ่งและวัดโดยใช้เวอร์ชัน LTS แทนที่จะเป็นวันที่วางจำหน่ายรายเดือน
สำหรับส่วนประกอบแต่ละส่วนนี้ สามารถตรวจสอบสถานะที่แตกต่างกันได้สามสถานะ ซึ่งจะทำให้ได้ภาพรวมของสถานการณ์ที่สมบูรณ์:
- ระดับความดังเสียงของอุปกรณ์ (DSPL): โปรแกรมนี้แสดงให้เห็นว่ามีโปรแกรมอะไรบ้างที่ติดตั้งและกำลังทำงานอยู่บนอุปกรณ์ ณ เวลานั้น โดยไม่จำเป็นต้องเชื่อมต่ออินเทอร์เน็ต
- SPL ที่เผยแพร่แล้ว (PSPL): นี่คือเวอร์ชันล่าสุดที่ได้รับการเผยแพร่อย่างเป็นทางการในประกาศด้านความปลอดภัยของ Android
- ระดับความดังเสียงที่มีให้เลือก (ASPL): ฟังก์ชันนี้จะแสดงให้เห็นว่ามีการดาวน์โหลดการอัปเดตแล้วหรือพร้อมที่จะติดตั้งผ่านกลไกการสื่อสารระหว่างกระบวนการ (IPC) หรือไม่
การควบคุมช่องโหว่และการตรวจสอบ CVE
หนึ่งในจุดเด่นสำคัญคือการผสานรวมเข้ากับ ฐานข้อมูลช่องโหว่โอเพนซอร์ส (OSV) ต่อไปนี้ไม่ต้องคาดเดาอีกแล้วว่าแพทช์ของแต่ละเดือนจะแก้ไขช่องโหว่ใดได้หรือไม่ ตอนนี้สามารถ ติดตาม CVE เฉพาะเจาะจงได้โดยใช้โปรแกรม
นี่เป็นสิ่งที่มีค่าอย่างยิ่งสำหรับแอปพลิเคชันด้านฟินเทค การธนาคาร หรือการดูแลสุขภาพ เนื่องจากสามารถจำกัดการโอนเงินมูลค่าสูงหรือการเข้าถึงข้อมูลที่ละเอียดอ่อนได้ หากตรวจพบว่าช่องโหว่บลูทูธหรือ NFC ที่สำคัญยังคงทำงานอยู่บนอุปกรณ์ ตัวอย่างเช่น ข้อบกพร่องเช่นการเขียนข้อมูลเกินขอบเขตไปยัง libimagecodec.quram.so อาจทำให้ผู้โจมตีจากระยะไกลสามารถเรียกใช้โค้ดตามอำเภอใจได้ ทำให้แม้แต่อุปกรณ์ที่ล้าสมัยก็กลายเป็น ช่องทางลับเข้า สู่เครือข่ายขององค์กร
การดำเนินการ técnica และ flujo de trabajo
เพื่อให้ระบบทำงานได้ นักพัฒนาต้องเพิ่มส่วนประกอบที่จำเป็น androidx.security:security-state:1.1.0 ในไฟล์ Gradle ของคุณ การเริ่มต้นใช้งานนั้นง่ายและต้องการบริบท Android แม้ว่าความเร็วจะดีขึ้นได้โดยการส่งรายงานช่องโหว่ในรูปแบบ JSON ไปยังคอนสตรัคเตอร์โดยตรง สถานะแพทช์ความปลอดภัย.
โดยทั่วไปแล้ว ขั้นตอนการทำงานจะแบ่งออกเป็นสามประเภทของการตรวจสอบ:
- การตรวจสอบแบบซิงโครนัส: มีการใช้ข้อมูลเหล่านี้เพื่อตรวจสอบ DSPL เมื่อแอปเริ่มต้นทำงาน และเปรียบเทียบกับวันที่อ้างอิงที่กำหนดไว้
- การสืบค้นแบบอะซิงโครนัส: ตลอด
fetchAvailableSecurityPatchLevelแอปสามารถแจ้งเตือนผู้ใช้ว่ามีการอัปเดตที่กำลังจะมาถึง และนำผู้ใช้ไปยังหน้าการตั้งค่าได้ - การตรวจสอบเชิงลึก: กับ
queryAllAvailableUpdatesคุณสามารถวิเคราะห์ความทันสมัยของข้อมูลและตรวจสอบว่าผู้ให้บริการอัปเดตรายใดกำลังตอบสนองอยู่
สิ่งสำคัญที่ควรทราบคือ การรองรับจะแตกต่างกันไปตามเวอร์ชันของระบบ ในขณะที่ Android 11 และเวอร์ชันที่ใหม่กว่านั้นรองรับอย่างเต็มที่ แต่ Android 10 ไม่มีการรองรับเคอร์เนลอย่างเป็นทางการ และในเวอร์ชัน 9 และเวอร์ชันก่อนหน้า ซึ่งไม่มีโมดูล Project Mainline ระบบจะแสดงวันที่แบบ Unix (1970-01-01)เป็นค่าเริ่มต้น
บทบาทของ Security State Provider และฟีเจอร์ใหม่ใน Android 17
เพื่อให้ระบบทั้งหมดนี้ทำงานได้ จะต้องมีคนประกาศว่ามีการอัปเดตพร้อมใช้งานแล้ว นี่คือจุดที่Security State Provider เข้ามา มีบทบาท โดยจะกำหนดมาตรฐานวิธีการที่ไคลเอนต์อัปเดตรายงานไปยัง ASPL ก่อนหน้านี้ ข้อมูล OTA ของผู้ผลิตแต่ละรายถูกเก็บไว้ในระบบเฉพาะของตนเอง แต่ตอนนี้ แอปที่ได้รับอนุญาตใดๆ ก็สามารถเข้าถึงข้อมูลได้โดยไม่คำนึงถึงยี่ห้อโทรศัพท์
นอกจากนี้Android 17 ยัง ได้นำเสนอการปรับปรุงที่สำคัญสำหรับผู้ผลิต (OEM) ผ่าน ไฟล์ XML แพทช์เสริม (Supplemental Patches XML ) ซึ่งช่วยให้พวกเขาสามารถประกาศการแก้ไขความปลอดภัยที่ตนเองได้ดำเนินการโดยไม่ต้องรอการเผยแพร่ SPL ทั่วโลก ทำให้มั่นใจได้ว่าความพยายามในการแก้ไขอย่างต่อเนื่องจะได้รับการยอมรับทันที และอุปกรณ์จะไม่ปรากฏว่ามีช่องโหว่แม้หลังจากได้รับการแก้ไขความปลอดภัยแล้ว
เครื่องมืออื่นๆ ในระบบนิเวศความปลอดภัยของ AndroidX
นอกเหนือจากสถานะของระบบแล้ว ยังมีส่วนประกอบสำคัญอื่นๆ อีก ไลบรารี security-cryptoนั้นจำเป็นอย่างยิ่งสำหรับการจัดการคีย์และการเข้ารหัสไฟล์หรือ SharedPreferences ถึงแม้ว่า JetSec บางเวอร์ชันจะล้าสมัยไปแล้ว แต่ก็ควรหลีกเลี่ยงการใช้พื้นที่จัดเก็บข้อมูลที่ละเอียดอ่อนมากเกินไป เนื่องจาก โมเดลแซนด์บ็อกซ์ และการเข้ารหัสไฟล์ของ Android นั้นมีความแข็งแกร่งมากอยู่แล้ว
สิ่งที่น่าสนใจอีกอย่างคือsecurity-app-authenticatorซึ่งช่วยลดความซับซ้อนในการตรวจสอบความน่าเชื่อถือของแอปพลิเคชันโดยอิงจากข้อมูลประจำตัวของผู้ลงนาม โดยใช้ XML ที่มีชื่อแพ็กเกจและข้อมูลประจำตัว ไลบรารีนี้รับประกันว่าเฉพาะแอปพลิเคชันที่ถูกต้องตามกฎหมาย เท่านั้น ที่จะสามารถโต้ตอบกับส่วนประกอบสำคัญของระบบได้
การเปลี่ยนไปใช้การตรวจสอบระดับส่วนประกอบอย่างละเอียด ความสามารถในการตรวจสอบ CVE ผ่าน OSV และการกำหนดมาตรฐานการอัปเดต OTA ทำให้ AndroidX Security State เป็นมาตรฐานระดับสูงสุดสำหรับการรักษาความปลอดภัยบนมือถือที่ได้รับการปรับปรุง ด้วยการผสานรวมเครื่องมือเหล่านี้ กระบวนการทำงานที่สำคัญจึงมีความยืดหยุ่น และผู้ใช้ปลายทางจะได้ รับการปกป้อง จากภัยคุกคามล่าสุดในโลกดิจิทัลอยู่เสมอ