Udržování bezpečnosti zařízení Android je monumentální úkol, zejména vzhledem k rozmanitému ekosystému. Proto Google učinil významný krok vpřed spuštěním knihoven AndroidX Security State a Security State Provider , což jsou převratné nástroje, které nabízejí úplnou transparentnost ohledně skutečného stavu zabezpečení zařízení s Androidem a posouvají je nad rámec generických metrik minulosti.
Ať už vyvíjíte bankovní aplikaci, platformu pro zdravotnictví nebo spravujete flotily firemních zařízení pomocí MDM, tyto knihovny vám umožňují programově kontrolovat zabezpečení každé komponenty. Místo spoléhání se na globální datum aktualizace, které vám někdy moc neřekne, nyní můžete přesně vědět, co je chráněno a jaké aktualizace čekají na vydání.
Konec monolitické záplaty: Pochopení tří úrovní SPL
Dříve jsme se spoléhali na úroveň bezpečnostních záplat (SPL), což je jediná vlastnost, která označovala datum vydání záplaty. S příchodem modulárních aktualizací Google Play se to ale nepodařilo. Aby se tento problém vyřešil, nové knihovny zavádějí tři odlišné úrovně viditelnosti , které poskytují mnohem přesnější obraz reality:
- Zvukový tlak zařízení (DSPL): Vztahuje se to na záplatu, která je nainstalováno a spuštěno na zařízení v daném okamžiku. Přístup k němu je lokální, bez nutnosti volání do sítě.
- Publikovaná SPL (PSPL): Je to nejnovější úroveň záplaty, která byla oficiálně zveřejněno v bulletinu zabezpečení systému Android pro tyto komponenty.
- Dostupný akustický tlak (ASPL): Označuje již nainstalovanou záplatu připraveno ke stažení a nainstalované na daném konkrétním zařízení, získané prostřednictvím IPC komunikace s klienty upgradu.
Toto rozdělení se týká tří kritických oblastí: jádra operačního systému (aktualizovaného bezdrátově), systémových modulů (spravovaných projektem Mainline) a jádra Linuxu . Za zmínku stojí, že jádro nepoužívá měsíční data vydání; místo toho je vyhodnocováno pomocí verzí s dlouhodobou podporou (LTS) , jako je například 5.15.159.
Chytré rozhodování a audit CVE
Díky velkému množství informací se vývojáři mohou odklonit od přístupu „všechno, nebo nic“. Například finanční aplikace může porovnat DSPL s ASPL a pokud zjistí čekající kritickou aktualizaci, vyzvat uživatele k aktualizaci telefonu před autorizací velké platby. To představuje posun od slepého blokování k kontextové správě zabezpečení v souladu s osvědčenými postupy pro bezpečné používání bankovních aplikací v systému Android.
Ale nekončí to jen u dat. Skutečná síla spočívá v ověřování specifických zranitelností (CVE) . Díky integraci s databází zranitelností s otevřeným zdrojovým kódem (OSV) mohou aplikace ověřit, zda byla opravena konkrétní chyba Bluetooth nebo NFC. To je zásadní pro autorizaci bezkontaktních platebních funkcí nebo sdílení dat prostřednictvím senzorů blízkosti, a to pouze tehdy, když je riziko zmírněno.
Role poskytovatele bezpečnostního státu a výrobců
Aby tohle všechno fungovalo, musí výrobci (OEM) a OTA klienti mluvit stejným jazykem. A zde přichází na řadu androidx.security.state.provider . Dříve byly informace o aktualizacích uzamčeny v proprietárních úložištích a aplikace třetích stran k nim neměly přístup. Nyní je zaveden standardizovaný mechanismus IPC.
Tento poskytovatel umožňuje klientům aktualizací jednotným způsobem deklarovat dostupnost oprav. Zatímco Google Play to již dělá, probíhá práce s výrobci po celém světě na začlenění jejich OTA klientů do tohoto rámce , což umožní jakékoli autorizované aplikaci zjistit, zda je oprava k dispozici, bez ohledu na to, kdo ji dodává.
Inovace v systému Android 17 a systému RBUS
Ekosystém se neustále vyvíjí a Android 17 zavádí velmi zajímavou funkci: doplňkové soubory XML s opravami . To umožňuje výrobcům deklarovat konkrétní opravy, které použili nad rámec oficiálního SPL. Pokud tedy výrobce OEM zpětně portuje kritickou bezpečnostní opravu, může okamžitě prokázat soulad s předpisy , aniž by čekal na globální změnu data měsíční opravy.
Kromě toho byl implementován systém aktualizací na základě rizik (RBUS) . To znamená, že pokud v daném měsíci nejsou pro konkrétní komponentu detekovány žádné nové hrozby, knihovny automaticky zvýší „efektivní“ úroveň zabezpečení této komponenty, čímž zajistí, že zařízení nebude v bezpečnostních kontrolách nespravedlivě penalizováno.
Další nástroje ze skupiny AndroidX Security
Ačkoli se zaměřuje na bezpečnost, skupina knihoven zahrnuje i další skvosty. Například Security Crypto (ačkoli některá jeho API byla zastaralá ve prospěch Android Keystore ) se stala základem pro správu šifrovaných souborů a zabezpečení sdílených preferencí. Je velmi důležité, aby existovaly neoficiální forky , které zachovaly podporu pro EncryptedSharedPreferences ve verzích, kde ji Google již neupřednostňuje, i když se vždy doporučuje pokud možno se vyhnout ukládání citlivých dat na zařízení.
Máme také Security App Authenticator , který zjednodušuje ověřování důvěryhodnosti aplikace na základě její podpisové identity, a Security Identity Credential , který umožňuje spravovat digitální doklady totožnosti (například řidičské průkazy pro mobilní zařízení) v souladu s normou ISO/IEC 18013-5 s využitím zabezpečeného hardwaru zařízení, pokud je k dispozici.
Implementace těchto nástrojů umožňuje přechod na model nulové důvěry založený na důkazech , kde zabezpečení zařízení již není jen otázkou data, ale podrobnou analýzou jeho komponent, ověřením skutečných zranitelností a bezproblémovou komunikací mezi hardwarem a softwarem, aby se zajistilo, že je nainstalována každá kritická záplata.
