- Имплементација система грануларне видљивости који замењује монолитну безбедносну закрпу анализом заснованом на компонентама.
- Могућност ревизије специфичних рањивости кроз интеграцију са OSV базом података и праћењем CVE-а.
- Стандардизација комуникације између произвођача и апликација путем добављача безбедносног стања ради управљања ОТА ажурирањима.
Одржавање безбедности Андроид паметног телефона ових дана је, искрено, права главобоља. С обзиром на то колико је екосистем постао сложен, програмери су се раније ослањали на веома општу метрику названу Ниво безбедносне закрпе (SPL), што је у основи било као покушај да се утврди да ли је кућа безбедна само гледајући датум последње велике реновације, без икакве идеје да ли је брава на задњим вратима још увек покварена.
Да би се решио овај информациони јаз, стигле су библиотеке AndroidX Security State и Security State Provider . Ови алати мењају правила игре, нудећи детаљан увид у сваки кутак система, омогућавајући софтверу да буде заиста отпоран на нападе и дозвољавајући апликацијама да доносе интелигентне одлуке на основу стварних доказа, а не само претпоставки, чиме се успоставља модел нултог поверења.
Збогом једној закрпи: ера грануларности
Главни проблем са ослањањем на један SPL је тај што се Андроид сада ажурира постепено захваљујући системским ажурирањима Project Mainline и Google Play-а. Да би се увео ред у овај хаос, нове библиотеке разлажу безбедност на три стуба: језгро оперативног система (ажурира се путем интернета), системске модуле (испоручују се преко Google Play-а) и Linux језгро , које је основа свега и мери се помоћу LTS верзија, а не месечних датума објављивања.
За сваку од ових компоненти могу се консултовати три различите државе, што даје потпуну слику ситуације:
- Звучни сигнал уређаја (DSPL): Показује шта је инсталирано и покренуто на уређају у том тачном тренутку, без потребе за интернет конекцијом.
- Објављени СПЛ (ПСПЛ): Представља најновију верзију званично објављену у Андроид безбедносном билтену.
- Доступни SPL (ASPL): Открива да ли је ажурирање већ преузето или је спремно за инсталацију путем механизма међупроцесне комуникације (IPC).
Контрола рањивости и ревизија CVE-а
Један од највећих драгуља је интеграција са базом података рањивости отвореног кода (OSV) . Више нема нагађања у одређивању да ли закрпа за одређени месец исправља одређену рањивост; сада је могуће програмски пратити одређене CVE .
Ово је чисто злато за финтех, банкарске или здравствене апликације, јер могу ограничити трансфере велике вредности или приступ осетљивим подацима ако открију да је критична рањивост за Bluetooth или NFC и даље активна на уређају. На пример, недостаци попут писања ван граница у libimagecodec.quram.so могли би омогућити удаљеним нападачима да извршавају произвољни код, претварајући застарели уређај у задња врата ка корпоративним мрежама.
Имплементацион тецница и флујо де трабајо
Да би ово покренуо, програмер мора да дода зависност androidx.security:security-state:1.1.0 у вашој Gradle датотеци. Иницијализација је једноставна и захтева Android контекст, мада се брзина може побољшати прослеђивањем извештаја о рањивости у JSON формату директно конструктору. Стање безбедносне закрпе.
Радни ток је генерално подељен на три врсте провера:
- Синхроне верификације: Користе се за преглед DSPL-а када се апликација покрене и упоређују га са обавезним основним датумом.
- Асинхрони упити: кроз
fetchAvailableSecurityPatchLevelАпликација може обавестити корисника да постоји ажурирање које чека и преусмерити га на подешавања. - Детаљне ревизије: са
queryAllAvailableUpdatesМожете анализирати свежину података и сазнати који добављач ажурирања одговара.
Важно је напоменути да се подршка разликује у зависности од верзије система. Док Андроид 11 и новије верзије нуде пуну подршку, Андроид 10 нема званичну подршку за језгро, а у верзијама 9 и ранијим, где модули Пројекта Мејнлајн нису постојали, систем подразумевано враћа Јуникс датум (1970-01-01) .
Улога добављача безбедносног стања и нове функције у Андроиду 17
Да би цео овај систем функционисао, неко мора да објави да су ажурирања доступна. Ту наступа Security State Provider , стандардизујући начин на који клијенти за ажурирања извештавају ASPL-у. Раније су OTA информације сваког произвођача биле закључане у власничким силосима; сада свака овлашћена апликација може да приступи подацима без обзира на марку телефона.
Штавише, Андроид 17 је увео снажно побољшање за произвођаче (OEM) кроз XML датотеку са додатним закрпама . Ово им омогућава да декларишу сопствене имплементиране безбедносне исправке без чекања на глобално издање SPL-а, осигуравајући да се текући напори закрпа одмах препознају и да уређај не делује рањиво чак ни након што је обезбеђен.
Остали алати у екосистему безбедности AndroidX-а
Поред стања система, постоје и друге кључне компоненте. Библиотека security-crypto је неопходна за управљање кључевима и шифровање датотека или SharedPreferences. Иако су неке верзије JetSec-а сада застареле, најбоље је не претерати са складиштењем осетљивих података, јер су Андроидов модел „пешчаника“ и шифровање засновано на датотекама већ веома робусни.
Такође је вредан пажње `security-app-authenticator` , који поједностављује проверу поузданости апликације на основу њеног идентитета за потписивање. Користећи XML са називима пакета и идентитетима, библиотека осигурава да само легитимне апликације могу да интерагују са критичним компонентама система.
Прелазак на детаљну инспекцију на нивоу компоненти, могућност ревизије CVE путем OSV-а и стандардизација OTA ажурирања чине AndroidX Security State златним стандардом за побољшану безбедност мобилних уређаја. Интеграцијом ових алата, критични токови рада постају отпорни, а крајњи корисници су увек заштићени од најновијих претњи у дигиталном окружењу.