Sistem güvenliğiyle ilgili en iyi uygulamalar

Bu bölümde, Android işletim sisteminin temel güvenliğini ve cihazların güvenliğini sağlamaya yönelik öneriler yer alır.

Biyometrik kimlik doğrulama

Kullanıcı kimlik doğrulaması için biyometrik verileri dikkatli bir şekilde edinin, saklayın ve işleyin. Şunları yapmalısınız:

  • Diğer kimlik doğrulama biçimlerini (biyometri dahil) kullanmadan önce birincil kimlik doğrulama yöntemini zorunlu kılın.
  • Kimlik doğrulamayla bağlı anahtarları içeren işlemler (ör. ödemeler) için yüz tanıma gibi pasif biyometrik modülleri kullanırken amacı belirtmek üzere açık bir onay alın.
  • Birincil kimlik doğrulama yönteminin 72 saatte bir kullanılmasını zorunlu kılın.
  • Tüm biyometrik veriler ve işleme için tamamen güvenli bir ardışık düzen kullanın.
  • Biyometrik verileri (ham sensör ölçümleri ve türetilmiş özellikler dahil) hiçbir zaman cihaz dışına göndermeyin. Mümkünse bu verileri güvenilir yürütme ortamı (TEE) veya Güvenli Öğe gibi güvenli ve izole bir ortamda saklayın.

Biyometrik özellikli cihazlar, uygulama geliştiricilerin uygulamalarında biyometri tabanlı kimlik doğrulamadan yararlanmaları için ortak ve tutarlı bir arayüz sunan BiometricPrompt API'yi desteklemelidir. Yalnızca güçlü biyometriler BiometricPrompt ile entegre edilebilir ve entegrasyonlar Android Uyumluluk Tanım Belgesi (CDD) yönergelerine uymalıdır.

Daha fazla biyometrik yönerge için Biyometrik HAL uygulama yönergelerine bakın.

SELinux

SELinux, Android'in güvenlik modelinin büyük bir kısmının tanımını ve yaptırımını sağlar. SELinux'un doğru şekilde kullanılması, Android cihazların güvenliği açısından kritik öneme sahiptir ve güvenlik açıklarının etkisini azaltmaya yardımcı olabilir. Bu nedenle tüm Android cihazlarda sağlam bir SELinux politikası uygulanmalıdır.

  • En az ayrıcalık politikası uygulayın.
  • CAP_DAC_OVERRIDE, CAP_SYS_ADMIN ve CAP_NET_ADMIN izinlerini vermeyin.
  • Sistem verilerini SD karta kaydetmez.
  • Sürücü erişimi için sağlanan türleri (ör. gpu_device, audio_device vb.) kullanın.
  • İşlemler, dosyalar ve SELinux türleri için anlamlı adlar kullanın.
    • Varsayılan etiketlerin kullanılmadığından ve bunlara erişim izni verilmediğinden emin olun.
  • Cihazlara özgü politika, bir cihazda çalışan genel politikanın %5 ila %10'unu oluşturmalıdır. %20'nin üzerindeki özelleştirmeler neredeyse kesinlikle aşırı ayrıcalıklı alanlar ve geçersiz politika içerir. Gereksiz yere büyük politikalar, bellek ve disk alanı tüketir (daha büyük bir önyükleme resmi gerektirir) ve çalışma zamanında politika arama sürelerini olumsuz etkiler.

SELinux politikasının dinamik olarak yüklenmesi

Android cihazlara SELinux politikasını dinamik olarak yüklemeyin. Bu işlem, aşağıdaki gibi sorunlara neden olabilir:

  • Kritik güvenlik yamalarını kabul etmeyi engelleme.
  • Politikaları yeniden yükleyerek bir cihazı rootlama özelliğini gösterme
  • Politika güncelleyiciye yönelik ortadaki adam saldırıları için bir vektör ortaya çıkarabilir.
  • Politika güncellemeleriyle ilgili hatalar nedeniyle cihazların kullanılamaz hale gelmesine neden olur.

Arka kapılar

Android uygulamalarında, sisteme veya verilere normal güvenlik mekanizmalarını atlatan arka kapılar ya da erişim yolları bulunmamalıdır. Teşhis, hata ayıklama, geliştirme veya geliştiricinin bildiği gizli anahtarlarla korunan özel garanti onarım erişimi bu kapsamdadır. Arka kapıları önlemek için:

  • Endüstri tarafından tanınan bir uygulama güvenlik açığı tarama aracı kullanarak tüm üçüncü taraf uygulamalarını tarayın.
  • Üçüncü taraf kitaplıkları da dahil olmak üzere hassas erişime sahip tüm kodlarda kod incelemeleri gerçekleştirin.
  • Tarama için uygulamaları Google Play'e yükleyerek Google Play Protect'ten yararlanın. Google Play'de yayınlamadan tarama için uygulama yükleyebilirsiniz.
  • Teşhis veya onarım odaklı araçları sürüm sürümlerine önceden yüklemeyin. Bu araçları yalnızca belirli sorunları çözmek için isteğe bağlı olarak yükleyin. Ayrıca bu araçlar, hesaba özgü verileri işlememeli veya yüklememelidir.

Geliştirme araçları

Hata ayıklama, test ve teşhis araçları gibi geliştirme araçları, genellikle nasıl çalıştıklarını ve topladıkları verileri göstererek cihazınızda istenmeyen güvenlik boşlukları oluşturabilir. Geliştirme araçlarının üretim derlemelerine dahil edilmediğinden emin olmak için:

  • Şirket içi hata ayıklama ve test aracı karmalarının kara listesini oluşturun ve sistem imajını kullanmadan önce bu APK'lar için derlemeleri tarayın.
  • Endüstri tarafından tanınan bir uygulama güvenlik açığı tarama aracı kullanarak tüm birinci taraf uygulamaları tarayın.
  • Özellikle uygulama üçüncü taraf tarafından geliştirilmişse önemli güncellemelerden önce tüm kritik cihaz üzerinde teşhis uygulamalarını değerlendirmek için bir üçüncü taraf uygulama güvenlik testi firması ile çalışın.
  • Destek oturumu sırasında yalnızca kullanıcının sözlü olarak veya sohbet üzerinden aracı etkinleştirebildiğinden emin olun. Gerekli teşhis bilgilerini topladıktan sonra izin yapılarını saklayın ve aracı devre dışı bırakın.
  • Bu aracın kullanım kaydını, kullanıcının operatör hesabında erişebileceği bir günlükte saklayın.
  • Araç tarafından toplanan kimliği tanımlayabilecek bilgilerin (PII) veya cihaz telemetri verilerinin, ülkeyle ilgili anonimleştirme, saklama ve silme uygulamalarına tabi olduğundan emin olun. Yalnızca destek aramasıyla alakalı veriler toplanmalıdır. Bu veriler her görüşmeden sonra silinmelidir.
  • Klavye tuş vuruşlarının günlüğe kaydedilmesi, mikrofon kullanımı veya kamera kullanımı gibi casus yazılımlarda kullanılabilecek tekniklerin, kullanıcının açık izni olmadan kullanılmadığından emin olun. Gizliliği ihlal etme potansiyeli olan bu yöntemleri kullanan uygulamalar, kullanıcının izin vermesi gereken bir gizlilik politikasıyla birlikte çok net bir şekilde açıklanmalıdır. Bu tür uygulamalar, kullanıcının açık izni olmadan etkinleştirilmemelidir.

Açıklama ve izinleri uygularken yararlanabileceğiniz bazı ek öneriler:

Uygulama içi açıklama

  • Uygulamanın normal kullanımını doğrudan uygulama içinde gösterin. Kullanıcının bir menüye veya ayarlara gitmesini gerektirmeyin.
  • Toplanan veri türünü ve verilerin nasıl kullanıldığını açıklayın.
  • İdeal olarak bu bilgileri bir gizlilik politikasına veya hizmet şartlarına yerleştirmeyin. Kişisel veya hassas verilerin toplanmasıyla ilgisi olmayan diğer açıklamalara dahil etmeyin.
  • İzin olumlu olmalıdır. Açıklamadan çıkılması (başka bir alana dokunma veya geri ya da ana sayfa düğmesine basma) izin olarak kabul edilmemelidir.
  • Rıza mesajını açık ve net bir şekilde sunmalıdır.
  • Kabul etmek için kullanıcının onay verdiğini gösteren bir işlem yapmasını (ör. kabul etmek için dokunma veya bir komutu konuşma) gerektirmelidir.
  • Olumlu izin almadan kişisel veya hassas verileri toplamayın.
  • Otomatik kapanan veya süresi dolan mesajlar kullanmayın.

AOSP'ye yerleştirilmiş işlevler

AOSP'ye ek işlevler yerleştirmek genellikle beklenmedik davranışlara ve sonuçlara yol açabilir. Bu nedenle, işleme dikkatli bir şekilde devam edin.

  • Kullanıcıdan farklı varsayılan uygulamalar (ör. arama motoru, web tarayıcısı, başlatıcı) kullanmak isteyip istemediği sorulur ve cihazdan veri gönderme işlemi açıklanır.
  • AOSP APK'larının AOSP sertifikasıyla imzalandığından emin olun.
  • AOSP APK'larına kod eklenip eklenmediğini belirlemek için regresyon testleri çalıştırın ve bir değişiklik günlüğü tutun.

Güvenlik güncellemeleri

Android cihazlar, kullanıma sunulduktan sonra en az iki yıl boyunca sürekli güvenlik desteği almalıdır. Bilinen güvenlik açıklarını gideren düzenli güncellemeler de buna dahildir.

  • Android cihazınızdaki tüm bileşenler için uygun destek sözleşmeleri yapmak amacıyla SoC tedarikçileriniz gibi donanım iş ortaklarıyla birlikte çalışın.
  • Kullanıcıların Android cihazlarında güncellemeleri kabul etme ve yükleme olasılığını artırmak için güvenlik güncellemelerinin minimum kullanıcı etkileşimiyle yüklenebildiğinden emin olun. Sorunsuz Sistem Güncellemeleri'ni veya eşdeğer bir güvenlik özelliğini uygulamanız önemle tavsiye edilir.
  • Android Güvenlik Bülteni'nde belirtilen Android Güvenlik Yaması Düzeyi'nin (SPL) kümülatif şartını anladığınızdan emin olun. Örneğin, 2018-02-01 güvenlik yaması düzeyini kullanan cihazlar, bu güvenlik yaması düzeyiyle ilişkili tüm sorunların yanı sıra önceki tüm güvenlik bültenlerinde bildirilen tüm sorunların düzeltmelerini içermelidir.

Dinamik çekirdek güncellemeleri

Kritik sistem bileşenlerini dinamik olarak değiştirmeyin. Dinamik çekirdek güncellemelerinin acil durum tehditlerine karşı koruma sağladığını gösteren bazı araştırmalar olsa da şu anda değerlendirilen maliyet, avantajlardan daha ağır basıyor. Bunun yerine, güvenlik açığı korumalarını hızlı bir şekilde dağıtmak için güçlü bir OTA güncelleme yöntemi oluşturun.

Anahtar yönetimi

İmzalama anahtarlarının güvenliğini sağlamak için iyi anahtar yönetimi politikaları ve uygulamaları sürdürün.

  • İmzalama anahtarlarını harici taraflarla paylaşmayın.
  • Bir imzalama anahtarının güvenliği ihlal edilirse yeni bir anahtar oluşturun ve bundan sonra tüm uygulamaları iki kez imzalayın.
  • Tüm anahtarları, erişmek için birden fazla faktör gerektiren yüksek güvenlikli modül donanımlarında veya hizmetlerde depolayın.

Sistem görüntüsünü imzalama

Sistem görüntüsünün imzası, cihaz bütünlüğünü belirlemek için kritik öneme sahiptir.

  • Cihazları herkese açık bir anahtarla imzalamayın.
  • Cihaz imzalama anahtarlarını, sınırlı ve denetlenebilir erişim sağlayan bir donanım güvenlik modülü (HSM) dahil olmak üzere hassas anahtarlarla ilgili endüstri standardı uygulamalarla tutarlı bir şekilde yönetin.

Kilidi açılabilir bootloader'lar

Birçok Android cihaz, kilit açma özelliğini destekler. Bu özellik, cihaz sahibinin sistem bölümünü değiştirmesine veya özel bir işletim sistemi yüklemesine olanak tanır. Üçüncü taraf sistem resmi yükleme ve cihazda sistem düzeyinde geliştirme yapma, yaygın kullanım alanlarından bazılarıdır. Örneğin, bir Google Nexus veya Pixel cihazdaki sistem görüntüsünün kilidini açmak için kullanıcı fastboot oem unlock komutunu çalıştırabilir. Bu komut, şu mesajı görüntüler:

En iyi uygulama olarak, kilidi açılabilen Android cihazların kilidi açılmadan önce tüm kullanıcı verilerinin güvenli bir şekilde silinmesi gerekir. Kilit açıldığında tüm verilerin düzgün şekilde silinmemesi, fiziksel olarak yakın bir saldırganın gizli Android kullanıcı verilerine yetkisiz erişmesine neden olabilir. Kullanıcı verilerinin ifşa edilmesini önlemek için kilit açma özelliğini destekleyen cihazların bu özelliği düzgün bir şekilde uygulaması gerekir.

  • Kullanıcı kilit açma komutunu onayladıktan sonra cihazın anında veri silme işlemini başlatması gerekir. Güvenli silme işlemi tamamlanana kadar unlocked işareti ayarlanmamalıdır.
  • Güvenli silme işlemi tamamlanamazsa cihaz kilitli durumda kalmalıdır.
  • Temel blok cihaz tarafından destekleniyorsa ioctl(BLKSECDISCARD)veya eşdeğeri kullanılmalıdır. Yerleşik MultiMediaCard (eMMC) cihazlarda bu, Güvenli Silme veya Güvenli Kırpma komutunun kullanılması anlamına gelir. eMMC 4.5 ve sonraki sürümler için bu, normal bir Silme veya Kırpma işleminin ardından bir Sanitize işleminin kullanılması anlamına gelir.
  • BLKSECDISCARD, temeldeki blok cihaz tarafından desteklenmiyorsa bunun yerine ioctl(BLKDISCARD) kullanılmalıdır. eMMC cihazlarda bu normal bir Trim işlemidir.
  • BLKDISCARD desteklenmiyorsa engellenen cihazların tümünün sıfırla yazılması kabul edilir.
  • Kullanıcıların, bölüm yüklemeden önce kullanıcı verilerinin silinmesini zorunlu kılma seçeneği olmalıdır. Örneğin, Nexus cihazlar kullanıcı verilerini silmek için fastboot oem lock komutunu kullanır.
  • Cihazlar, eFuses veya benzer bir mekanizma aracılığıyla cihazın kilidinin açılıp açılmadığını ve/veya yeniden kilitlenip kilitlenmediğini kaydedebilir. Ancak bootloader'ı yeniden kilitleyip ardından fabrika ayarlarına sıfırlamanın cihazın tüm işlevlerini geri yükleyeceğini önemle belirtmek isteriz.

Bu şartlar, kilit açma işlemi tamamlandıktan sonra tüm verilerin yok edilmesini sağlar. Bu korumaların uygulanmaması orta düzeyde bir güvenlik açığı olarak kabul edilir.

Kilidi açılmış bir cihaz, fastboot oem lock komutu kullanılarak tekrar kilitlenebilir. Önyükleyicinin kilitlenmesi, yeni özel işletim sisteminde kullanıcı verilerinin orijinal cihaz üreticisinin işletim sisteminde olduğu gibi korunmasını sağlar (örneğin, cihazın kilidi tekrar açılırsa kullanıcı verileri silinir).

Cihaz penetrasyon testi

Cihazlar, gönderimden önce yetkili bir güvenlik testi uzmanı tarafından incelenmelidir. Pentest, cihazın burada sağlanan güvenlik yönergelerinin yanı sıra dahili OEM güvenlik yönergelerine uyduğunu belirlemelidir.

Güvenlik testi

AOSP tarafından sağlanan Güvenlik Testi araçlarını kullanın. Özellikle

  • Geliştirme sırasında bellek güvenliği araçlarını kullanın: Destekleniyorsa (ARMv9 ve üzeri) MTE'yi, desteklenmiyorsa HWASan'ı kullanın. Bu araçlar etkinken mümkün olduğunca fazla test çalıştırın.
  • Bellek güvenliği sorunlarını olasılıksal olarak tespit etmek için üretimde GWP-ASan ve KFENCE'yi kullanın.