Uzun süreli Android güvenliği için üretici kılavuzu

Bu kılavuzda, Android Uyumluluk Test Paketi (CTS) tarafından değerlendirilen güvenlik yamalarını uygulama konusunda Google'ın önerdiği en iyi uygulamalar açıklanmaktadır. Araçlar, TV'ler, set üstü kutular ve ev aletleri gibi üç yıldan uzun süre desteklenecek Android uyumlu OEM ekipmanlarının üreticileri (üreticiler) için tasarlanmıştır. Bu kılavuz, son kullanıcılar (ör. araç sahipleri) için değildir.

Onaylar ve sorumluluk reddi beyanları

Bu kılavuz, Google'ı veya diğer üreticileri yasal ya da sözleşmesel olarak bağlamaz ve bir dizi şart olarak tasarlanmamıştır. Bu kılavuz, önerilen uygulamaları açıklayan bir eğitim yardımıdır.

Geri bildirim

Bu kılavuzun kapsamlı olması amaçlanmamıştır. Ek düzeltmeler planlanmaktadır. Geri bildiriminizi manufacturers-guide-android@googlegroups.com adresine gönderin.

Sözlük

Terim Tanım
ACC Android Uyumluluk Taahhüdü. Eski adıyla Android Parçalanma Karşıtı Sözleşme (AFA).
AOSP Android Açık Kaynak Projesi
ASB Android Güvenlik Bülteni
BSP Kapsamlı Destek Paketi
CDD Uyumluluk Tanımlama Belgesi
CTS Compatibility Test Suite
FOTA kablosuz donanım yazılımı güncellemesi
GPS küresel konum belirleme sistemi
MISRA Motor Industry Software Reliability Association
NIST Ulusal Standartlar ve Teknoloji Enstitüsü
OBD araç içi teşhis (OBD-II, hem yeterlilik hem de standardizasyon açısından OBD-I'e göre daha iyidir)
OEM özgün donanım üreticisi
OS işletim sistemi
SEI Yazılım Mühendisliği Enstitüsü
Çip üzerinde sistem (SoC) çip üzerinde sistem
SOP üretimin başlangıcı
SPL Güvenlik Yaması Seviyesi
TPMS lastik basıncı izleme sistemi

Android OS hakkında

Android, çeşitli cihazlar ve form faktörleri için tasarlanmış, Linux tabanlı açık kaynaklı bir tam yazılım yığınıdır. 2008'de ilk kez piyasaya sürüldüğünden beri Android, dünya genelinde 1,4 milyardan fazla cihazda (2016) kullanılan en popüler işletim sistemi (OS) haline geldi. Mart 2017 itibarıyla bu cihazların yaklaşık% 67'sinde Android 5.0 (Lollipop) veya daha yeni bir sürüm kullanılıyordu (daha güncel rakamlar Android Kontrol Paneli'nde mevcuttur). Cihazların büyük çoğunluğu cep telefonları ve tabletler olsa da Android; akıllı saatler, TV'ler ve otomotiv araç içi bilgi-eğlence (IVI) cihazlarında büyümeye devam ediyor.

Google Play Store'da sunulan Android uygulamalarının sayısı 2,2 milyonu aşmıştır (2016). Android uygulama geliştirme, Uyumluluk Tanımlama Belgesi (CDD) aracılığıyla bir dizi koşulu tanımlayan ve Uyumluluk Test Paketi (CTS) aracılığıyla test araçları sağlayan Android Uyumluluk Programı tarafından desteklenir. Android uyumluluk programları, herhangi bir Android uygulamasının, uygulama için gerekli özellikleri destekleyen Android uyumlu herhangi bir cihazda çalışmasını sağlar.

Google düzenli olarak yeni işletim sistemi sürümleri, işletim sistemi güvenlik güncellemeleri ve keşfedilen güvenlik açıkları hakkında bilgiler yayınlar. Üreticiler, bu güncellemelerin Android OS destekli ürünlerde geçerli olup olmadığını öğrenmek için Android Güvenlik Bültenleri'ni incelemelidir. Android güvenlik, uyumluluk ve derleme sistemlerinin incelenmesi için aşağıdaki kaynaklara bakın:

Bağlı araçlar (standart uzun ömürlü ürünler) hakkında

Araçlar, 1920'lerde AM radyonun kullanıma sunulmasıyla bağlanmaya başladı. Düzenleyiciler ve otomobil üreticileri teşhis ve hizmeti kolaylaştırmak (ör. OBD-II bağlantı noktası), güvenliği artırmak (ör. TPMS) ve yakıt tasarrufu hedeflerini karşılamak için elektronik cihazlara yöneldiğinden, harici fiziksel ve kablosuz bağlantıların sayısı giderek arttı. Bağlantı teknolojilerindeki bir sonraki dalga, uzaktan anahtarsız giriş, telematik sistemler gibi sürücüye kolaylık sağlayan özelliklerin yanı sıra Bluetooth, kablosuz ve akıllı telefon projeksiyonu gibi gelişmiş bilgi-eğlence özelliklerini de beraberinde getirdi. Günümüzde entegre sensörler ve bağlantı (ör. GPS), güvenlik ve yarı otonom sürüş sistemlerini desteklemektedir.

Araç bağlantılarının sayısı arttıkça olası araç saldırısı yüzeyinin alanı da artar. Bağlantılar, tüketici elektroniğiyle ilgili siber güvenlik endişelerine benzer endişeler doğurur. Ancak yeniden başlatma, günlük yama güncellemeleri ve açıklanamayan davranışlar tüketici elektroniği için normal olsa da araçlar gibi güvenliğin kritik olduğu sistemlere sahip ürünlerde tutarsızlıklar görülür.

Üreticiler, sahada kullanılan ürünlerin güvenliğinin ve güvenlik durumunun devamlılığını sağlamak için proaktif bir yaklaşım benimsemelidir. Kısacası, üreticiler üründeki bilinen güvenlik açıklarının farkında olmalı ve bunları gidermek için riske dayalı bir yaklaşım benimsemelidir.

Uzun vadeli güvenlik sağlama

Bağlı araçlarda genellikle işletim sistemi, kitaplıklar, yardımcı programlar vb. gibi birden fazla yazılım bileşeni içeren bir veya daha fazla elektronik kontrol birimi (ECU) bulunur. Üreticiler bu tür bileşenleri izlemeli ve aşağıdakiler de dahil olmak üzere proaktif analizle bilinen yayınlanmış güvenlik açıklarını belirlemelidir:

  • Ürünü Common Vulnerabilities and Exposures (CVE) veritabanına göre düzenli olarak değerlendirme
  • Ürünle ilgili güvenlik kusurları için istihbarat toplama.
  • Güvenlik testi.
  • Android güvenlik bültenlerini aktif olarak analiz ediyoruz.

Örnek işletim sistemi ve güvenlik yaması güncellemeleri (Android çalıştıran IVI'ler):

Şekil 1. Araç kullanım ömrü boyunca örnek büyük işletim sistemi ve güvenlik güncellemesi dağıtımı.

# Adım Etkinlikler

①

 Geliştirme Şubesi Üretici, bir Android sürümü (Android X) seçer. Bu örnekte, "Android X" ilk seri üretime (SOP) başlamadan iki yıl önce araçta gönderilecek olan yazılımın temelini oluşturur.
② İlk Lansman Android X, üründe gönderilen ilk işletim sistemi sürümü olmadan birkaç ay önce güvenlik güncellemeleri Android Güvenlik Bültenleri'nden (ASB'ler) ve üretici tarafından değerli kabul edilen diğer kaynaklardan alınır. y2 = Android'in X sürümü için ikinci güvenlik bülteni, üretici tarafından Android X'e uygulanır (geri bağlantı). Bu güncelleme üründe yer alır ve üretim süreci, Android X.y2 ile sıfırıncı yılda başlar.

Bu örnekte, üretici daha yeni olan Android X+1 yıllık sürümünü göndermemeye karar verdi. En yeni sürümün gönderilmesinin nedenleri arasında yeni özellikler ekleme, yeni güvenlik açıklarını giderme ve/veya daha yeni Android sürümünü gerektiren Google ya da üçüncü taraf hizmetlerini gönderme yer alır. En son sürümle gönderime karşı nedenler arasında, tüm düzenleyici ve sertifika şartlarına uygunluk da dahil olmak üzere değişikliklerin entegrasyonu, testi ve doğrulanması için gereken araç geliştirme ve lansman sürecinde yeterli zaman olmaması yer alır.
③ Tam İşletim Sistemi Güncellemesi Üretici, SOP'den sonra Android X+2 işletim sistemi güncellemesini yayınlar. Bu güncelleme, ilk üründe kullanılan sürümden (Android X0) iki Android sürümü sonrasını içerir. ASB güvenlik güncellemeleri, API düzeyi için (gönderim tarihi itibarıyla) kullanılabilir.Bu nedenle güncelleme, SOP'den yaklaşık 1,25 yıl sonra X+2.y0 olarak yayınlanır. Bu işletim sistemi güncellemesi, sahada kullanılan ürünlerle uyumlu olabilir veya olmayabilir. Bu durumda, dağıtılan araçların güncellenmesi için bir plan oluşturulabilir.

Başka ticari sözleşmeler yürürlükte olmadığı sürece, tam işletim sistemi güncellemesi yapma kararı tamamen üreticinin takdirine bağlıdır.
④ Güvenlik güncellemesi Üretici, aracın üretim ömrünün ikinci yılında Android X+2 işletim sistemine yama uygular. Bu karar, üreticinin risk değerlendirmesine dayanmaktadır. Üretici, X+2 sürümü için üçüncü ASB güvenlik güncellemesini güncellemenin temeli olarak seçer. Güvenlik güncellemesi alan ürünler artık (X+2.y3) OS + Android güvenlik yaması düzeyinde.

Üreticiler, herhangi bir ASB'den tek tek güvenlik yamaları seçebilse de bültenle ilişkili Android güvenlik yaması seviyesini (SPL) (ör. 2017-02-05) kullanmak için bültendeki gerekli tüm sorunları düzeltmelidir. Desteklenen ürün için geri bağlantı ve güvenlik sürümü oluşturmak üreticinin sorumluluğundadır.
⑤ Tam İşletim Sistemi Güncellemesi 3. adımın (Tam İşletim Sistemi Güncellemesi) tekrarı olan ikinci tam işletim sistemi güncellemesi, ürünün Android X+4 sürümüne yükselmesini sağlar. Bu güncelleme, aracın üretim ömrünün üçüncü yılında yapılır. Üretici, yeni Android sürümünün yeni donanım gereksinimlerini ürünün donanımıyla ve güncellenmiş Android işletim sisteminin kullanıcıya sağladığı avantajlarla dengeliyor. Üretici, güvenlik güncellemeleri içermeyen bir güncelleme yayınlar. Bu nedenle ürün artık (X+4.y0) OS + Android güvenlik yaması düzeyindedir.

Bu örnekte, donanım sınırlamaları nedeniyle X+4, bu ürün için sunulacak son büyük Android sürümüdür. Aracın 6 yıldan uzun olması beklenen kullanım ömrü için güvenlik desteği gerekir.
⑥ Güvenlik güncellemesi 4. adımın (Güvenlik Güncellemesi) tekrarı. Üretici, ASB güvenlik güncellemelerini Android'in çok daha yeni bir sürümünden (X+6) alıp bu güncellemelerin bir kısmını veya tamamını Android X+4'e aktarmakla görevlidir. Güncellemeleri birleştirme, entegre etme ve gerçekleştirme (veya üçüncü tarafla sözleşme yapma) sorumluluğu üreticiye aittir. Ayrıca, üretici artık desteklenmeyen Android sürümlerindeki güvenlik sorunlarının ASB kapsamında olmadığını bilmelidir.
⑦ Güvenlik güncellemesi Aracın üretim yaşam döngüsünün sekizinci yılında, 5. adımda (tam işletim sistemi güncellemesi) son işletim sistemi güncellemesinden bu yana dört Android sürümü yayınlandı ve Android X'in belirtilmesinden bu yana on yıl geçti. Bu durumda, API düzeyi herkese açık sürümünden üç yıldan daha eski olan sürümlerde güvenlik yamalarını düzenleme ve geriye dönük olarak taşıma yükü tamamen üreticinin üzerindedir.

Güvenlikle ilgili en iyi uygulamalar

Google, güvenlik ihlallerini zorlaştırmak için Güvenliği Uygulama başlıklı makalede açıklandığı gibi, güvenlik ve yazılım mühendisliğiyle ilgili yaygın olarak kabul edilen en iyi uygulamaların kullanılmasını önerir ve bu uygulamaları kullanır.

Güvenlik yönergeleri

Güvenlik için önerilen uygulamalar şunlardır:

  • Harici kitaplıkların ve açık kaynak bileşenlerin en son sürümlerini kullanın.
  • İşletim sisteminin yayın sürümlerine izinsiz hata ayıklama işlevleri eklemeyin.
  • Kullanılmayan işlevleri kaldırın (gereksiz saldırı yüzeyini azaltmak için).
  • En az ayrıcalık ilkesini ve diğer Android uygulama geliştirme en iyi uygulamalarını kullanın.

Yazılım geliştirme yönergeleri

Sistemin yaşam döngüsü boyunca güvenli yazılım geliştirme için önerilen uygulamalar şunlardır:

  • Öğeleri, tehditleri ve olası azaltma yöntemlerini sıralamak ve belirlemek için tehdit modellemesi yapın.
  • Güvenli ve sağlam bir tasarım için mimari/tasarım incelemesi yapın.
  • Anti-pattern'leri ve hataları en kısa sürede belirlemek için düzenli olarak kod incelemeleri yapın.
  • Aşağıdakiler dahil olmak üzere yüksek kod kapsamlı birim testleri tasarlayın, uygulayın ve çalıştırın:
    • İşlevsel test (olumsuz test senaryoları dahil)
    • Düzeltilen hataların yeniden ortaya çıkmadığından emin olmak için düzenli regresyon testi
    • Fuzz testi (birim testi paketinin bir parçası olarak)
  • Olası sorunları belirlemek için statik kaynak kodu analiz araçlarını (scan-build, lint vb.) kullanın.
  • Sistem geliştirme sırasında olası sorunları belirlemek ve azaltmak için AddressSanitizer, UndefinedBehaviorSanitizer ve FORTIFY_SOURCE (yerel bileşenler için) gibi dinamik kaynak kodu analiz araçlarını kullanın.
  • Yazılım kaynak kodu ve yayın yapılandırması/sürümü için bir yönetim stratejiniz olmalıdır.
  • Yazılım yamalarının oluşturulması ve dağıtılması için bir yama yönetimi stratejisine sahip olun.

Güvenlik geri taşıma politikası

Google, keşfedilen ve bildirilen güvenlik açıklarının güvenlik geriye bağlantıları için API düzeyinin herkese açık olarak yayınlanmasından itibaren üç (3) yıl boyunca aktif destek sunmaktadır. Aktif destek aşağıdakileri içerir:

  1. Güvenlik açığı raporlarını alma ve inceleme
  2. Güvenlik güncellemeleri oluşturma, test etme ve yayınlama
  3. Güvenlik güncellemelerini ve güvenlik bülteni ayrıntılarını düzenli olarak yayınlar.
  4. Belirlenen kurallara göre önem derecesi değerlendirmesi yapın.

API düzeyinin herkese açık yayınlanma tarihinden üç yıl sonra Google aşağıdaki yönergeleri önerir:

  • API sürümünden üç yıldan daha eski olan işletim sistemi güvenlik güncellemeleri için geri bağlantı desteği sağlamak üzere üçüncü taraflardan (ör. SoC satıcısı veya çekirdek sağlayıcı) yararlanma.
  • Herkese açık olarak sağlanan ASB'leri kullanarak kod incelemeleri yapmak için üçüncü taraflardan yararlanma ASB'ler, şu anda desteklenen sürümdeki güvenlik açıklarını tanımlarken üreticiler, yeni yayınlanan güncellemeleri önceki sürümlerle karşılaştırmak için sağlanan bilgileri kullanabilir. Bu veriler, etki analizi yapmak ve API sürümünden üç yıldan daha eski işletim sistemi sürümleri için benzer yamalar oluşturmak amacıyla kullanılabilir.
  • Uygun olduğunda güvenlik güncellemelerini Android Açık Kaynak Projesi'ne (AOSP) yükleyin.
  • Üretici, tedarikçiye özel kod (ör. tescilli cihaza özel kod) için güvenlik güncellemelerinin işlenmesini koordine etmelidir.
  • Üretici, NDA Android Güvenlik Bülteni İş Ortağı Önizleme bildirim grubuna katılmalıdır (Geliştirici NDA'sı gibi yasal sözleşmelerin imzalanması gerekir). Bültenler şunları içermelidir:
    • Duyurular
    • CVE ve önem derecesi dahil olmak üzere yama seviyesine göre sorunların özeti
    • Uygun durumlarda güvenlik açığı ayrıntıları

Ek referanslar

Güvenli kodlama ve yazılım geliştirme uygulamalarıyla ilgili talimatlar için aşağıdakilere bakın:

Google, aşağıdaki önerilen uygulamaların kullanılmasını teşvik eder.

Genel olarak, bağlı tüm ürünlerin en yeni işletim sistemi sürümüyle başlatılması önerilir ve üreticiler, ürünü piyasaya sürmeden önce en yeni işletim sistemi sürümünü kullanmaya çalışmalıdır. Sürümün kilitlenmesi, test ve doğrulama öncesinde kararlılığı sağlamak için gereklidir. Ancak üretici, eski işletim sistemi sürümlerinden elde edilen ürün kararlılığını, bilinen güvenlik açığı daha az olan ve gelişmiş güvenlik korumaları sunan yeni işletim sistemi sürümleriyle dengelemelidir.

Önerilen yönergeler:

  • Araç geliştirme sürecinde uzun geliştirme süreleri olduğundan üreticilerin n-2 veya daha eski bir işletim sistemi sürümüyle lansman yapması gerekebilir.
  • Kablosuz (OTA) kampanyasıyla yayınlanan her Android OS sürümünde Android Uyumluluğu'na uygunluğu koruyun.
  • Hızlı ve müşteri dostu güncellemeler için ürünlerde Android Firmware-over-the-air (FOTA) özelliğini kullanın. FOTA, ürün ile BT arka ofisi arasında kod imzalama ve TLS bağlantısı gibi güvenlik alanındaki en iyi uygulamalar kullanılarak yapılmalıdır.
  • Bağımsız olarak tespit edilen Android güvenlik açıklarını Android güvenlik ekibine gönderme

Not: Google, Android Güvenlik Bültenleri'nde cihaz türüne veya sektöre özel bildirimleri değerlendirmiştir. Ancak Google, belirli bir cihazın (araç, TV, giyilebilir cihaz, telefon vb.) çekirdeğini, sürücülerini veya yonga setlerini bilmediği için Google'ın belirli bir güvenlik sorununu cihaz türüyle etiketlemek için deterministik bir yolu yoktur.

Üretici, ürün döngüsü geliştirmeleri sırasında kullanılan sürüm için en yeni işletim sistemi sürümünü veya güvenlik güncellemelerini kullanmak için her türlü çabayı göstermelidir. Güncellemeler, yinelenen düzenli ürün güncellemeleri sırasında veya kalite ve/veya diğer sorunları gidermek için acil düzeltmeler kapsamında yapılabilir. Önerilen uygulamalar şunlardır:

  • Sürücü, çekirdek ve protokol güncellemelerini ele almak için bir plan oluşturun.
  • Dağıtılan araçlara güncelleme sağlamak için sektöre uygun bir yöntem kullanın.

Uyumluluk Tanımlama Belgesi (CDD)

Uyumluluk Tanımlama Belgesi (CDD), bir cihazın Android uyumlu olarak kabul edilmesi için gereken koşulları açıklar. CDD herkese açık ve herkes tarafından kullanılabilir. CDD sürümlerini Android 1.6'dan en son sürüme kadar source.android.com adresinden indirebilirsiniz.

Bir ürünün bu şartları karşılaması için aşağıdaki temel adımlar uygulanır:

  1. İş ortağı, Google ile Android Uyumluluk Taahhüdü'nü (ACC) imzalar. Ardından, rehber olarak bir Teknik Çözüm Danışmanı (TSC) atanır.
  2. İş ortağı, ürünün Android işletim sistemi sürümü için CDD incelemesini tamamlar.
  3. İş ortağı, sonuçlar Android Uyumluluğu için kabul edilebilir olana kadar CTS sonuçlarını (aşağıda açıklanmıştır) çalıştırır ve gönderir.

Uyumluluk Test Paketi (CTS)

Uyumluluk Test Paketi (CTS) test aracı, ürün uygulamasının Android ile uyumlu olduğunu ve en son güvenlik yamalarının dahil edildiğini doğrular. CTS herkese açık, açık kaynaklı ve herkesin kullanımına sunulmuştur. Android 1.6'dan en son sürüme kadar olan CTS sürümlerini source.android.com adresinden indirebilirsiniz.

Android yazılımının herkese açık olarak yayınlanan her sürümü (fabrika yüklemesi ve sahada güncelleme görüntüleri), CTS sonuçları aracılığıyla Android uyumluluğunu kanıtlamalıdır. Örneğin, cihazda Android 7.1 çalışıyorsa yayın amaçlı derleme görüntüsü oluşturulup test edilirken CDD 7.1 ve CTS 7.1'in ilgili en son sürümüne başvurulmalıdır. Üreticilerin, sorunları belirlemek ve düzeltmek için CTS'yi erken ve sık kullanmaları önemle tavsiye edilir.

NOT: Google Mobil Hizmetleri (GMS) gibi başka sözleşmeler imzalayan iş ortaklarının başka şartları da karşılaması gerekebilir.

CTS iş akışı

CTS iş akışında test ortamını ayarlama, testleri çalıştırma, sonuçları yorumlama ve CTS kaynak kodunu anlama yer alır. Aşağıdaki yönergeler, CTS kullanıcılarının (ör. geliştiriciler, üreticiler) CTS'yi etkili ve verimli bir şekilde kullanmasına yardımcı olmak için hazırlanmıştır.

  • Sık sık test yapın. CTS, derleme sisteminize entegre olan otomatik bir araç olarak tasarlanmıştır. CTS'yi sık sık çalıştırmak, yazılımda bozulma veya gerileme meydana geldiğinde kusurları hızlı ve erken bir aşamada bulmanıza yardımcı olabilir.
  • CTS kaynak kodunu indirip inceleyin. Tam CTS kaynak kodu, herkesin indirip kullanabileceği açık kaynak yazılımdır (indirilen kaynak kodu tamamen oluşturulabilir ve çalıştırılabilir). Cihazda bir test başarısız olduğunda, nedenini belirlemek için kaynak kodun ilgili bölümünü inceleyebilirsiniz.
  • En yeni CTS'yi edinin. Yeni Android sürümleri, hata düzeltmeleri, iyileştirmeler ve yeni testlerle CTS'yi güncelleyebilir. CTS İndirmeleri'ni düzenli olarak kontrol edin ve CTS programınızı gerektiği gibi güncelleyin. Ürün lansmanının başarılı olması için üretici ve Google, CTS sürümü konusunda anlaşmalıdır. CTS yenilenmeye devam ederken ürünün belirli bir noktada dondurulması gerekir.

CTS'yi geçme

Google, Android uyumlu bir ürünün CTS ve CTS Verifier raporlarındaki test sonuçlarının kabul edilebilir olmasını sağlar. Prensip olarak tüm testler başarılı olmalıdır. Ancak, cihazın Android uyumluluk koşullarına uymaması dışında başka nedenlerle başarısız olan testler Google tarafından incelenir. Bu işlem sırasında:

  1. Üretici, Google'a önerilen CTS yamalarını, yama doğrulamalarını ve argümanı kanıtlamak için gerekçeleri sağlar.
  2. Google, gönderilen materyali inceler ve kabul ederse ilgili CTS testlerini güncelleyerek cihazın CTS'nin bir sonraki sürümünde testi geçmesini sağlar.

Bir güvenlik yaması uygulandıktan sonra CTS testi aniden başarısız olursa üretici, yamanın uyumluluğu bozmaması için yamayı değiştirmeli VEYA testin yanlış olduğunu gösterip test için bir düzeltme sağlamalıdır (yukarıda açıklandığı gibi).

CTS, test düzeltmelerinin incelenmesi için açık kalmaya devam eder. Örneğin, Android 4.4 düzeltmeleri kabul etmeye devam ediyor ( https://android-review.googlesource.com/c/platform/cts/+/273371 adresini inceleyin).

Sık sorulan sorular (SSS)

S: Android'in belirli bir uygulamasına güvenlik güncellemelerini uygulamak kimin sorumluluğundadır?

Y: Cihazı doğrudan sağlayan üretici sorumludur. Bu kuruluş, AOSP'de güvenlik güncellemeleri yayınlayan ve belirli bir cihaz (ör. araç) için yayınlamayan Google değildir.

S: Google, Android'deki güvenlik sorunlarını nasıl ele alıyor?

Y: Google, sorunları sürekli olarak araştırır ve olası düzeltmeler geliştirir. Bu düzeltmeler, düzenli güvenlik güncelleme sürecinin bir parçası olarak Google tarafından desteklenen tüm API düzeylerinde kullanılabilir. Google, Ağustos 2015'ten beri source.android.com'daki güncellemelerle ilgili bültenler ve bağlantılar yayınlamaya devam ediyor. Google, büyük işletim sistemi sürümlerinin bir parçası olarak güvenlik güncellemeleri de yayınlıyor. Ayrıca Güvenlik geri bağlantı politikasını da inceleyin.

S: Bir üretici, ASB'deki tüm AOSP yamalarını entegre etti ancak aynı bültende belirtilen BSP tedarikçisinden gelen yamaları entegre etmediyse yine de güvenlik seviyesini yükseltebilir mi (ör. ilgili yamayı platforma/derlemeye uygulayabilir mi)?

Y: Bir üreticinin Android güvenlik yaması seviyesi (SPL) bildirmesi için Android Güvenlik Bülteni'nde yayınlanan ve belirli bir Android SPL ile eşlenen önceki bültenler de dahil olmak üzere tüm gerekli sorunları gidermesi gerekir. Örneğin, Mart 2017 Güvenlik Bülteni'ni (2017-03-01 SPL) kullanan bir üretici, Mart 2017 bülteninde bu SPL için belgelenen tüm gerekli sorunları ve cihazla ilgili güncellemeler de dahil olmak üzere önceki tüm Android Güvenlik Bültenleri'ne yönelik tüm önceki güncellemeleri (2017-02-05 SPL ile ilişkili cihazla ilgili güncellemeler dahil) ele almıştır.

S: Üretici, BSP satıcısı tarafından sağlanan güvenlik güncellemelerini kabul etmediğinde VEYA ASB tarafından zorunlu kılınan güvenlik güncellemeleri satıcılar tarafından sağlanmadığında ne olur?

Y: ASB'ler, güvenlik açıklarını (CVE listesiyle numaralandırılmış) açıklar ve genellikle eşleşen güvenlik testleri sağlar. Amaç, listelenen güvenlik açıklarının artık cihazda yeniden üretilememesini ve cihazın ilgili güvenlik testlerini geçebilmesini sağlamaktır. Bu nedenle sorun, Google veya üçüncü taraf bir satıcı tarafından sağlanan güvenlik güncellemesini almakla ilgili değil, üreticinin cihazın ASB'deki CVE listesine karşı savunmasız olmadığını onaylamasıyla ilgilidir. Üretici, sağlanan güvenlik güncellemelerini kullanabilir veya cihazına daha uygun bir değişiklik varsa bunun yerine bu değişikliği kullanabilir.

Örneğin, Google'ın bir AOSP güvenlik açığını, bileşenin tam işlevsel kalmasını ve CDD'ye uygun olmasını sağlayan bir kod değişikliğiyle ele aldığı bir durumu ele alalım. Üretici, bileşenin cihazda gerekli olmadığını veya CDD (ya da ilgili sertifika testi) tarafından zorunlu kılınmadığını belirlerse gelecekteki servis ihtiyaçlarını ve saldırı yüzeyini azaltmak için bileşeni kaldırabilir. Üretici, sağlanan güvenlik güncellemesini kullanmamış olsa da cihazın güvenlik bülteninde belgelenen CVE'ye karşı savunmasız olmamasını sağlamıştır. Ancak üretici, önerilen güvenlik güncellemesinden saparak sorunu yanlış ele alma, yeni güvenlik açıkları oluşturma veya nihai derlemenin işlevselliğini başka bir şekilde azaltma riski alır.

Bir ASB'deki tüm sorunlar için düzeltmelerin mevcut olmasını sağlamak üzere tüm SoC iş ortaklarıyla birlikte çalışsak da üreticilerin bir cihazın yaşam döngüsü boyunca SoC tedarikçileriyle servis anlaşması yapmasını öneririz. SoC'ler, bir yonga setine hizmet vermeyi istenenden daha erken durdurabilir. Bu nedenle, cihaz yonga seti seçimi öncesinde anlaşmalar yapmak, cihaz lansman sürecinin önemli bir parçasıdır.

Son olarak, bir ASB'de belgelenen bir sorun için doğrudan düzeltme edinmenin veya bağımsız olarak düzeltme oluşturmanın mümkün olmadığı durumlarda, üretici önceki Android SPL'yi koruyabilir ve yine de yeni düzeltmeleri derlemeye ekleyebilir. Ancak bu uygulama, Android'in sertifikalı cihazlarda en son güvenlik yaması seviyesinin kullanılabilir olmasını sağlaması nedeniyle, derleme sertifikasıyla ilgili sorunlara yol açar. Google, bu uygulamadan kaçınmak için önceden SoC'nizle birlikte çalışmanızı önerir.

S: Üretici, ASB öğesinin ürünü için geçerli olmadığını belirlerse diğer Google şartlarını karşılamak veya CTS'yi geçmek için öğenin yine de uygulanması ya da düzeltilmesi gerekir mi?

Y: Android güvenlik yaması seviyesini (SPL) bildirmek için yamaların alınması gerekmez. Ancak üreticinin, derlemesinin bu soruna karşı savunmasız olmadığını onaylaması gerekir.

Örneğin, düzeltme eki uygulanan bir bileşen üreticinin sisteminde mevcut değildir veya bir bileşen, sorunu gidermek için üreticinin sisteminden kaldırılmıştır. Bu durumda sistem, üreticinin yama almasını gerektirmeden uyumlu olabilir.

Bu durum, örneğin bir üreticinin yalnızca kritik yamaları düzeltmek istemesi, ancak güvenlik testinin başarısız olmasına neden olacak diğer geçerli yamaları uygulamaması durumundan temelde farklıdır. Bu durumda, SPL'nin karşılanmadığı varsayılır.