- Egy részletes láthatósági rendszer megvalósítása, amely a monolitikus biztonsági javítást komponensalapú elemzéssel helyettesíti.
- Lehetőség van specifikus sebezhetőségek auditálására az OSV adatbázissal és a CVE-k nyomon követésével való integráció révén.
- A gyártók és az alkalmazások közötti kommunikáció szabványosítása a biztonsági állapotszolgáltatón keresztül az OTA frissítések kezelése érdekében.
Manapság őszintén szólva igazi fejfájást okoz egy Android okostelefon biztonságának megőrzése. Tekintettel arra, hogy az ökoszisztéma mennyire összetetté vált, a fejlesztők korábban egy nagyon általános mérőszámra, a Security Patch Level (SPL)-re támaszkodtak, ami alapvetően olyan volt, mintha egy ház biztonságát csak a legutóbbi nagyobb felújítás dátuma alapján próbálnánk megállapítani, anélkül, hogy tudnánk, hogy a hátsó ajtó zárja még mindig hibás-e.
Ennek az információs hiányosságnak a pótlására jelentek meg az AndroidX Security State és a Security State Provider könyvtárak . Ezek az eszközök forradalmi változásokat hoznak, részletes betekintést nyújtanak a rendszer minden szegletébe, lehetővé téve a szoftverek számára, hogy valóban ellenállóak legyenek a támadásokkal szemben, és lehetővé téve az alkalmazások számára, hogy valós bizonyítékok, ne pedig puszta feltételezések alapján intelligens döntéseket hozzanak, ezáltal létrehozva egy zéró bizalom modellt.
Viszlát az egyetlen patchnek: a granularitás korszaka
Az egyetlen SPL-re való támaszkodás fő problémája, hogy az Android mostantól darabonként frissül a Project Mainline és a Google Play rendszerfrissítéseinek köszönhetően. A káosz rendbetételére az új könyvtárak három pillérre bontják a biztonságot: az alapvető operációs rendszerre (vezeték nélkül frissül), a rendszermodulokra (a Google Playen keresztül szállítva), és a Linux kernelre , amely minden alapja, és amelyet LTS verziók, nem pedig havi megjelenési dátumok alapján mérnek.
Ezen összetevők mindegyikéhez három különböző állapot tekinthető meg, amelyek teljes képet adnak a helyzetről:
- Eszköz hangnyomásszintje (DSPL): Azt jelzi, hogy mi van telepítve és fut az eszközön abban a pillanatban, internetkapcsolat nélkül.
- Kiadott hangnyomásszint (PSPL): Ez a legújabb, hivatalosan az Android biztonsági közleményében közzétett verzió.
- Elérhető hangnyomásszint (ASPL): Egy folyamatok közötti kommunikációs (IPC) mechanizmuson keresztül felfedi, hogy van-e már letöltött vagy telepítésre kész frissítés.
Sebezhetőségi ellenőrzés és CVE-auditálás
Az egyik igazi kincs a nyílt forráskódú sebezhetőségi adatbázissal (OSV) való integráció . Nincs többé találgatás annak meghatározására, hogy egy adott hónap javítása javít-e egy adott sebezhetőséget; mostantól programozottan is nyomon követhetők az egyes CVE-k .
Ez színtiszta aranyat ér a fintech, banki vagy egészségügyi alkalmazások számára, mivel korlátozhatják a nagy értékű átutalásokat vagy az érzékeny adatokhoz való hozzáférést, ha kritikus Bluetooth- vagy NFC-sebezhetőséget észlelnek az eszközön. Például az olyan hibák, mint a libimagecodec.quram.so fájlba történő határokon túli írás, lehetővé tehetik a távoli támadók számára tetszőleges kód futtatását, egy elavult eszközt hátsó ajtóvá alakítva a vállalati hálózatokba.
Implementación técnica y flujo de trabajo
Ahhoz, hogy ez működjön, a fejlesztőnek hozzá kell adnia a függőséget androidx.security:security-state:1.1.0 a Gradle-fájlodban. Az inicializálás egyszerű és Android-környezetet igényel, bár a sebesség javítható, ha egy JSON formátumú sebezhetőségi jelentést közvetlenül a konstruktornak adunk át. Biztonsági javítás állapota.
A munkafolyamat általában háromféle ellenőrzésre oszlik:
- Szinkron ellenőrzések: Ezeket a DSPL ellenőrzésére használják az alkalmazás indításakor, és összehasonlítják egy kötelező alapdátummal.
- Aszinkron lekérdezések: keresztül
fetchAvailableSecurityPatchLevelAz alkalmazás értesítheti a felhasználót a függőben lévő frissítésekről, és átirányíthatja őket a beállításokhoz. - Részletes auditok: Con
queryAllAvailableUpdatesElemezheti az adatok frissességét, és megtudhatja, melyik frissítési szolgáltató válaszol.
Fontos megjegyezni, hogy a támogatás a rendszer verziójától függően változik. Míg az Android 11 és újabb verziók teljes támogatást nyújtanak, az Android 10 nem rendelkezik hivatalos kernel-támogatással, a 9-es és korábbi verziókban pedig, ahol nem léteztek Project Mainline modulok, a rendszer alapértelmezés szerint a Unix dátumot (1970-01-01) adja vissza.
A biztonsági állapotszolgáltató szerepe és új funkciói az Android 17-ben
Ahhoz, hogy ez az egész rendszer működjön, valakinek be kell jelentenie, hogy frissítések érhetők el. Itt jön képbe a Biztonsági Állapot Szolgáltató (Security State Provider) , amely szabványosítja, hogy a frissítési kliensek hogyan jelentenek az ASPL-nek. Korábban minden gyártó OTA-információi saját, zárt silókban voltak elzárva; most bármely jogosult alkalmazás hozzáférhet az adatokhoz, függetlenül a telefon márkájától.
Továbbá az Android 17 egy erőteljes fejlesztést vezetett be a gyártók (OEM-ek) számára egy kiegészítő javításokat tartalmazó XML fájl révén . Ez lehetővé teszi számukra, hogy a globális SPL kiadás megvárása nélkül deklarálják saját biztonsági javításaikat, biztosítva, hogy a folyamatban lévő javítási erőfeszítések azonnal felismerésre kerüljenek, és hogy az eszköz a biztonságossá tétele után sebezhetőnek tűnjön.
További eszközök az AndroidX Security ökoszisztémában
A rendszerállapoton túl más kulcsfontosságú összetevők is léteznek. A security-crypto könyvtár elengedhetetlen a kulcsok kezeléséhez és a fájlok vagy a SharedPreferences titkosításához. Bár a JetSec egyes verziói már elavultak, a legjobb, ha nem használjuk túl az érzékeny adatok tárolását, mivel az Android sandbox modellje és fájlalapú titkosítása már nagyon robusztus.
Szintén említésre méltó a security-app-authenticator , amely leegyszerűsíti az alkalmazás megbízhatóságának ellenőrzését az aláíró identitásának alapján. XML-t használva csomagnevekkel és identitásokkal, a függvénykönyvtár biztosítja, hogy csak legitim alkalmazások léphessenek kapcsolatba a kritikus rendszerösszetevőkkel.
Az átállás a részletes komponensszintű ellenőrzésre, a CVE-k OSV-n keresztüli auditálásának lehetősége és az OTA frissítések szabványosítása teszi az AndroidX Security State-et a fokozott mobilbiztonság aranystandardjává. Ezen eszközök integrálásával a kritikus munkafolyamatok rugalmassá válnak, és a végfelhasználók mindig védve vannak a digitális környezet legújabb fenyegetései ellen.