- Tek parça halindeki güvenlik yamasını bileşen tabanlı analizle değiştiren, ayrıntılı bir görünürlük sisteminin uygulanması.
- OSV veritabanı ve CVE izleme sistemiyle entegrasyon sayesinde belirli güvenlik açıklarını denetleme olanağı.
- OTA güncellemelerini yönetmek için Güvenlik Durumu Sağlayıcısı aracılığıyla üreticiler ve uygulamalar arasındaki iletişimin standartlaştırılması.
Günümüzde bir Android akıllı telefonu güvende tutmak, açıkçası, gerçek bir baş ağrısı. Ekosistemin ne kadar karmaşık hale geldiği göz önüne alındığında, geliştiriciler eskiden Güvenlik Yama Seviyesi (SPL) adı verilen çok genel bir ölçüte güveniyorlardı; bu da temelde bir evin güvenliğini, arka kapı kilidinin hala bozuk olup olmadığını bilmeden, yalnızca son büyük tadilatın tarihine bakarak belirlemeye çalışmak gibiydi.
Bu bilgi açığını gidermek için AndroidX Güvenlik Durumu ve Güvenlik Durumu Sağlayıcı kütüphaneleri geldi . Bu araçlar, sistemin her köşesine ayrıntılı görünürlük sağlayarak, yazılımın saldırılara karşı gerçekten dayanıklı olmasını ve uygulamaların yalnızca varsayımlara değil, gerçek kanıtlara dayalı akıllı kararlar almasını sağlayarak, sıfır güven modelini kurarak oyunun kurallarını değiştiriyor.
Tek yamaya veda: ayrıntılılık çağı
Tek bir SPL'ye güvenmenin en büyük sorunu, Android'in artık Project Mainline ve Google Play sistem güncellemeleri sayesinde parça parça güncellenmesidir. Bu kaosa düzen getirmek için yeni kütüphaneler güvenliği üç temel üzerine kuruyor: çekirdek işletim sistemi (kablosuz olarak güncellenir), sistem modülleri (Google Play aracılığıyla sunulur) ve her şeyin temeli olan ve aylık sürüm tarihleri yerine LTS sürümleri kullanılarak ölçülen Linux çekirdeği .
Bu bileşenlerin her biri için, durumun tam bir resmini veren üç farklı duruma başvurulabilir:
- Cihaz SPL (DSPL): İnternet bağlantısına ihtiyaç duymadan, o an cihazda yüklü olan ve çalışan uygulamaları gösterir.
- Yayınlanan SPL (PSPL): Bu, Android güvenlik bülteninde resmi olarak yayınlanan en son sürümü temsil etmektedir.
- Mevcut SPL (ASPL): Bu, bir güncellemenin zaten indirilmiş olup olmadığını veya süreçler arası iletişim (IPC) mekanizması aracılığıyla yüklenmeye hazır olup olmadığını ortaya koyar.
Güvenlik açığı kontrolü ve CVE denetimi
En önemli özelliklerinden biri de Açık Kaynak Güvenlik Açıkları (OSV) veritabanıyla entegrasyonudur. Artık belirli bir ayın yamasının belirli bir güvenlik açığını giderip gidermediğini belirlemek için tahmine dayalı yöntemlere gerek yok; artık belirli CVE'leri programatik olarak takip etmek mümkün .
Bu, özellikle fintech, bankacılık veya sağlık hizmetleri uygulamaları için paha biçilmez bir fırsat; çünkü cihazda kritik bir Bluetooth veya NFC güvenlik açığının hala aktif olduğunu tespit ederlerse, yüksek değerli transferleri veya hassas verilere erişimi kısıtlayabilirler . Örneğin, libimagecodec.quram.so'ya sınırların dışında yazma gibi kusurlar, uzaktan saldırganların rastgele kod yürütmesine olanak tanıyarak, eski bir cihazı kurumsal ağlara açılan bir arka kapıya dönüştürebilir.
Teknik Uygulama ve Trabajo Grip
Bunu çalışır hale getirmek için geliştiricinin bağımlılığı eklemesi gerekir. androidx.security:security-state:1.1.0 Gradle dosyanızda. Başlatma basittir ve bir Android bağlamı gerektirir, ancak JSON formatındaki bir güvenlik açığı raporunu doğrudan yapıcıya ileterek hızı artırabilirsiniz. GüvenlikYamasıDurumu.
İş akışı genel olarak üç tür kontrole ayrılır:
- Eş zamanlı doğrulamalar: Uygulama başlatıldığında DSPL'yi incelemek ve zorunlu bir temel tarihle karşılaştırmak için kullanılırlar.
- Asenkron sorgular: içinden
fetchAvailableSecurityPatchLevelUygulama, kullanıcıya bekleyen bir güncelleme olduğunu bildirebilir ve onları ayarlara yönlendirebilir. - Detaylı denetimler: ile
queryAllAvailableUpdatesVerilerin güncelliğini analiz edebilir ve hangi güncelleme sağlayıcısının yanıt verdiğini öğrenebilirsiniz.
Destek durumunun sistem sürümüne bağlı olarak değiştiğini belirtmek önemlidir. Android 11 ve sonrası tam destek sunarken, Android 10'da resmi çekirdek desteği bulunmamaktadır ve Project Mainline modüllerinin mevcut olmadığı 9 ve önceki sürümlerde sistem varsayılan olarak Unix tarihini (1970-01-01) döndürür.
Güvenlik Durumu Sağlayıcısının Rolü ve Android 17'deki Yeni Özellikler
Bu sistemin düzgün çalışması için, birinin güncellemelerin mevcut olduğunu duyurması gerekiyor. İşte burada Güvenlik Durumu Sağlayıcısı devreye giriyor ve güncelleme istemcilerinin ASPL'ye nasıl rapor vereceğini standartlaştırıyor. Daha önce, her üreticinin OTA bilgileri özel veri depolarında kilitliydi; şimdi ise, telefon markasından bağımsız olarak, yetkilendirilmiş herhangi bir uygulama verilere erişebiliyor.
Ayrıca, Android 17, Ek Yama XML dosyası aracılığıyla üreticiler (OEM'ler) için güçlü bir iyileştirme getirdi . Bu, küresel SPL sürümünü beklemeden kendi uyguladıkları güvenlik düzeltmelerini bildirmelerine olanak tanıyarak, devam eden yama çalışmalarının anında tanınmasını ve cihazın güvenliği sağlandıktan sonra bile savunmasız görünmemesini sağlar.
AndroidX Güvenlik ekosistemindeki diğer araçlar
Sistem durumunun ötesinde, başka önemli bileşenler de mevcuttur. Güvenlik şifreleme kütüphanesi, anahtarları yönetmek ve dosyaları veya SharedPreferences'ı şifrelemek için gereklidir. JetSec'in bazı sürümleri artık eski olsa da, Android'in sanal alan modeli ve dosya tabanlı şifrelemesi zaten çok sağlam olduğundan, hassas verilerin depolanmasını aşırı kullanmamak en iyisidir .
Ayrıca , uygulamanın güvenilirliğini imzalama kimliğine göre doğrulamayı basitleştiren security-app-authenticator da dikkat çekicidir. Paket adları ve kimlikleri içeren XML kullanan bu kütüphane, yalnızca meşru uygulamaların kritik sistem bileşenleriyle etkileşim kurabilmesini sağlar.
Ayrıntılı bileşen düzeyinde incelemeye geçiş, OSV aracılığıyla CVE'leri denetleme yeteneği ve OTA güncellemelerinin standardizasyonu, AndroidX Güvenlik Durumu'nu gelişmiş mobil güvenlik için altın standart haline getiriyor. Bu araçların entegrasyonuyla, kritik iş akışları dayanıklı hale geliyor ve son kullanıcılar dijital ortamdaki en yeni tehditlere karşı her zaman korunuyor .