- Впровадження детальної системи видимості, яка замінює монолітний патч безпеки компонентним аналізом.
- Можливість аудиту певних вразливостей шляхом інтеграції з базою даних OSV та відстеженням CVE.
- Стандартизація зв'язку між виробниками та додатками через постачальника стану безпеки для керування оновленнями OTA.
Чесно кажучи, захист смартфона Android у наші дні – це справжній головний біль. З огляду на складність екосистеми, розробники раніше покладалися на дуже загальний показник під назвою «Рівень патчів безпеки» (SPL), що було фактично схоже на спробу визначити, чи безпечний будинок, лише дивлячись на дату останнього капітального ремонту, не маючи жодного уявлення про те, чи зламаний замок задніх дверей.
Щоб усунути цю інформаційну прогалину, з'явилися бібліотеки AndroidX Security State та Security State Provider . Ці інструменти змінюють правила гри, пропонуючи детальний огляд кожного куточка системи, дозволяючи програмному забезпеченню бути справді стійким до атак і дозволяючи додаткам приймати інтелектуальні рішення на основі реальних доказів, а не лише припущень, таким чином створюючи модель нульової довіри.
Прощавай, єдиний патч: ера гранулярності
Основна проблема використання єдиного SPL полягає в тому, що Android тепер оновлюється по частинах завдяки оновленням системи Project Mainline та Google Play. Щоб упорядкувати цей хаос, нові бібліотеки розділяють безпеку на три стовпи: основна операційна система (оновлюється по повітрю), системні модулі (постачаються через Google Play) та ядро Linux , яке є основою всього та вимірюється за допомогою версій LTS, а не щомісячних дат випуску.
Для кожного з цих компонентів можна звернутися до трьох різних держав, що дає повне уявлення про ситуацію:
- Звуковий тиск пристрою (DSPL): Він показує, що встановлено та працює на пристрої в цей конкретний момент, без необхідності підключення до Інтернету.
- Опублікований SPL (PSPL): Це найновіша версія, офіційно опублікована в бюлетені безпеки Android.
- Доступний рівень звукового тиску (ASPL): Він показує, чи вже завантажено оновлення, чи воно готове до встановлення через механізм міжпроцесного зв'язку (IPC).
Контроль вразливостей та аудит CVE
Однією з перлин є інтеграція з базою даних вразливостей з відкритим кодом (OSV) . Більше не потрібно здогадуватися, чи виправляє патч за певний місяць певну вразливість; тепер можна програмно відстежувати конкретні CVE .
Це чисте золото для фінтех-, банківських чи медичних програм, оскільки вони можуть обмежувати перекази великих сум або доступ до конфіденційних даних, якщо виявлять, що на пристрої все ще активна критична вразливість Bluetooth або NFC . Наприклад, такі недоліки, як запис за межами дозволеного доступу до libimagecodec.quram.so, можуть дозволити віддаленим зловмисникам виконувати довільний код, перетворюючи застарілий пристрій на бекдор у корпоративні мережі.
Implementación técnica y 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).
Роль постачальника стану безпеки та нові функції в Android 17
Щоб вся ця система працювала, хтось має оголосити про доступність оновлень. Саме тут і з'являється Security State Provider , який стандартизує те, як клієнти оновлень повідомляють ASPL. Раніше інформація OTA кожного виробника була заблокована у власних ізоляціях; тепер будь-який авторизований додаток може отримати доступ до даних незалежно від марки телефону.
Крім того, Android 17 запровадив потужне покращення для виробників (OEM) завдяки XML-файлу додаткових виправлень . Це дозволяє їм оголошувати власні впроваджені виправлення безпеки, не чекаючи глобального випуску SPL, гарантуючи, що поточні зусилля з виправлення будуть негайно розпізнані та що пристрій не виглядатиме вразливим навіть після того, як його буде захищено.
Інші інструменти в екосистемі безпеки AndroidX
Окрім стану системи, існують й інші ключові компоненти. Бібліотека security-crypto є важливою для керування ключами та шифрування файлів або SharedPreferences. Хоча деякі версії JetSec зараз застарілі, краще не зловживати сховищем конфіденційних даних, оскільки модель пісочниці Android та шифрування на основі файлів вже дуже надійні.
Також варто відзначити security-app-authenticator , який спрощує перевірку надійності програми на основі її ідентифікаційної особи підпису. Використовуючи XML з іменами пакетів та ідентифікаторами, бібліотека гарантує, що лише легітимні програми можуть взаємодіяти з критично важливими компонентами системи.
Перехід до детальної перевірки на рівні компонентів, можливість аудиту CVE через OSV та стандартизація OTA-оновлень роблять AndroidX Security State золотим стандартом для покращеної мобільної безпеки. Завдяки інтеграції цих інструментів критично важливі робочі процеси стають стійкими, а кінцеві користувачі завжди захищені від найновіших загроз у цифровому середовищі.