Caliency.
Mobil Uygulama

Uygulama Güvenliği ve Gizlilik: Kontrol Listesi

İki mağaza da cihazdan hangi verinin çıktığını beyan ettiriyor — yazmadığınız kodun aldığı veri dâhil. Yaptırım para cezası değil, durdurulan güncelleme.

C

Caliency

12 dk okuma
Bir elin, ekranında parlayan kilit simgesi bulunan telefona dokunuşunun yakın çekimi.

Uygulama güvenliği tavsiyelerinin çoğu ya uygulanamayacak kadar soyut ya da müşteriye verilemeyecek kadar teknik. İkisi de olmayan sürüm, her sürümde anında ve bir makine tarafından uygulanan iki şeyle başlıyor: mağaza beyanları. Hem Apple hem Google artık cihazdan hangi verinin çıktığını belirtmenizi istiyor ve ikisi de yazmadığınız kodun hesabını size sorduruyor.

Bu rehber önce onu ele alıyor — çünkü son tarihi olan kısım o — sonra karşısında çalışılmaya değer güvenlik standardını, sonra da hukuki danışmanlığın başladığı dürüst sınırı.

Beyanlar zorunlu ve sürümleri kilitliyor

Apple'ın uygulama gizlilik ayrıntıları gereksinimi net: bu bilgi "App Store'a yeni uygulama ve uygulama güncellemesi göndermek için gerekli."

Google'ın Veri güvenliği gereksinimi kapsamda daha da ileri gidiyor: "Google Play'de yayımlanmış uygulaması olan tüm geliştiriciler Veri güvenliği formunu doldurmalıdır; kapalı, açık ya da üretim test kanallarındaki uygulamalar dâhil." Kapalı bir beta muafiyet değil.

Yanlış yapmanın sonucu, bir karar vericinin önüne konmaya değer kısım. Google şöyle diyor:

"Google, uygulama davranışınızla beyanınız arasında bir tutarsızlık fark ettiğinde, yaptırım dâhil uygun işlemi yapabilir."

Sonuçlar engellenen güncellemeler ya da Google Play'den kaldırma olarak tarif ediliyor. Apple aynı sürekli yükümlülüğü koyuyor: "Yanıtlarınızı doğru ve güncel tutmaktan siz sorumlusunuz. Uygulamalarınız değişirse App Store Connect'teki yanıtlarınızı güncelleyin."

Bu, bütçeleyebileceğiniz bir ceza değil. Yayınlayamadığınız bir sürüm — ki daha kötü; çünkü bir takvimde değil, dağıtmanız gereken bir düzeltmenin olduğu gün geliyor. Aynı mantık güncellemeleri durduran red sebeplerinde de geçerli.

Herkesi yakalayan madde: başkasının kodu

Çoğu ekibin geç keşfettiği gereklilik burada. Apple "sizin ya da üçüncü taraf iş ortaklarınızın topladığı tüm veriyi tanımlamanızı" istiyor ve bu ortakları şöyle tanımlıyor:

"analitik araçları, reklam ağları, üçüncü taraf SDK'lar ya da uygulamanıza kodunu eklediğiniz diğer harici sağlayıcılar."

Google'ın kapsamı da aynı: beyan "uygulamalarında kullanılan üçüncü taraf kütüphaneler ya da SDK'lar aracılığıyla toplanan ve işlenen veriyi içerir" ve "eksiksiz ve doğru beyanlarda bulunmaktan yalnızca siz sorumlusunuz."

Yani bu işin dürüst tarifi şu: derlemedeki her SDK için, cihazdan ne gönderdiğini ve neden gönderdiğini yazın. Bir analitik kütüphanesi, bir çökme raporlayıcısı, bir reklam ağı, bir sohbet bileşeni, bir ödeme SDK'sı, bir harita bileşeni. Çoğu ekip bunu kendi bağımlılık listesi için yanıtlayamıyor ve cevap kodda değil — her sağlayıcının dokümantasyonunda. Bu yüzden bu, gönderim günü doldurulacak bir form değil, takvimi olan bir araştırma işi.

Buradan iki pratik sonuç çıkıyor. Birincisi, her yeni SDK bir beyan değişikliğidir; yani eklemek bir geliştirici tercihi değil bir ürün kararıdır. İkincisi, taşıdığınız SDK ne kadar azsa bu yükümlülük o kadar küçüktür — bağımlılıklarda katı olmanın, paket boyutuyla hiç ilgisi olmayan bir gerekçesi.

"Toplamak" gerçekte ne demek

Apple'ın tanımı kelimenin çağrıştırdığından dar ve bunu bilmek hem fazla hem eksik beyanı önlüyor:

"'Toplama', verinin cihazdan dışarı, sizin ve/veya üçüncü taraf ortaklarınızın iletilen isteği gerçek zamanlı karşılamak için gerekenden daha uzun süre erişebileceği biçimde iletilmesi anlamına gelir."

Bunun dışında kalan iki şey var. Cihazdan hiç çıkmayan veri. Ve yalnızca anlık isteği karşılamak için iletilip saklanmayan veri. İkisi de yine özen istiyor ama bir kullanıcının bilgisini saklamakla aynı şey değiller.

Apple takibi de özel olarak tanımlıyor: "uygulamanızdan belirli bir son kullanıcı ya da cihaz hakkında toplanan verinin, hedefli reklam ya da reklam ölçümü amacıyla Üçüncü Taraf Verisiyle ilişkilendirilmesi ya da bu verinin bir veri simsarıyla paylaşılması."

Takip kutusunu işaretlemeden önce bunu okuyun; çünkü kutunun, uygulamanın kullanıcıya ne sorması gerektiği açısından sonuçları var.

Karşısında gerçekten doğrulama yapabileceğiniz bir standart

"Uygulamayı güvenli yapın" bir şartname değil. OWASP'ın Mobile Application Security Verification Standard'ı şartname ve işi sekiz gruba ayırıyor:

MASVS-STORAGE, MASVS-CRYPTO, MASVS-AUTH, MASVS-NETWORK, MASVS-PLATFORM, MASVS-CODE, MASVS-RESILIENCE ve MASVS-PRIVACY.

Değeri şu: her grup, bir geliştiriciden göstermesini isteyebileceğiniz bir şey. Kimlik bilgileri nerede, hangi platform anahtar deposunda saklanıyor? Ne, neyle şifreleniyor ve anahtar kimde? Oturumlar nasıl kuruluyor ve nasıl iptal ediliyor? Uygulama güvenmediği bir ağda ne yapıyor? Hangi platform izinlerini istiyor ve onlarsız çalışabiliyor mu?

Bunlar kanıtı olan, yanıtlanabilir sorular — bir güvenlik gereksinimini bir güvenlik temennisinden ayıran şey de bu; yayımlanmış eşiği olan metrikleri yalnızca rapor dolduranlardan ayıran ayrımın aynısı. Aynı tablonun backend yarısı için, backend'inizin neyi ölçtüğü ve sakladığı cevapların çoğunu belirliyor.

Hukuk nerede başlıyor, biz nerede duruyoruz

KVKK, GDPR ve muadilleri hukuki yükümlülükler. Sizden ne istedikleri; yargı alanınıza, hangi veriyi işlediğinize, veri sorumlusu mu işleyeni mi olduğunuza ve verinin fiziksel olarak nerede durduğuna bağlı. Bu sorular kendi hukuk danışmanınıza ait; bir blog yazısında yanıtlayan ajans haddini aşıyordur.

Söyleyeceğimiz şey, gerçekten işe yarayan ayrım: mağaza gereksinimleriyle hukuki gereksinimler türce farklı. Mağaza gereksinimleri evrensel, gönderdiğiniz anda geçerli ve çalışmayı bırakan bir düğmeyle uygulanıyor. Hukuki gereksinimler değişken, daha uzun bir zaman ölçeğinde geliyor ve düzenleyiciler tarafından uygulanıyor. Birini karşılamak diğerini karşılamıyor; ekipler de düzenli olarak mağaza formunu uyum işi sanıyor.

İkisinin buluştuğu yer veri envanteri. Neyi, kimden, niçin topladığınızın; nereye gittiğinin ve ne kadar saklandığının listesi hem mağaza beyanına hem danışmanınıza hem de kendi mühendisliğinize hizmet ediyor. Bir kez kurun, güncel tutun; iki konuşma da kısalsın.

Nerede hayır diyoruz

Müşteri her birinin ne işe yaradığına yazılı olarak karar vermeden analitik ya da reklam SDK'sı eklemiyoruz. Her biri kalıcı bir beyan yükümlülüğü ve birinin doğru tutması gereken bir cevap.

Gizlilik politikası yazmıyor, KVKK ya da GDPR uyumu konusunda danışmanlık vermiyoruz. Hukuk danışmanınızın belirlediğini inşa eder ve ihtiyaç duyduğu veri envanterini üretiriz — gerçekten yapabileceğimiz kısım bu.

Ve güvenliği sondaki bir aşama saymıyoruz. Depolama, iletim ve kimlik doğrulama kararları ilk haftada veriliyor ve sonradan dönmek pahalı; bu yüzden kapsam belirlemeye ait — mobil uygulama geliştirme rehberimizde ele aldığımız gibi.

Kontrol listesi

  1. Derlemedeki her SDK'yı listeleyin ve her biri için cihazdan ne ilettiğini yazın. Yanıtlayamıyorsanız ilk iş bu.
  2. Veri envanterini yazın: ne, kimden, niçin, nereye gidiyor, ne kadar saklanıyor.
  3. İki mağaza beyanını da bu envanterden doldurun, hafızadan değil.
  4. Bir bağımlılık değiştiğinde beyanı yeniden kontrol edin. Yeni bir SDK bir beyan değişikliğidir.
  5. Sekiz MASVS grubunu geçin ve her biri için kanıtı kaydedin; uygulamanın güvenli olduğunu iddia etmek yerine.
  6. Envanteri hukuk danışmanınıza gönderin ve iki konuşmayı ayrı tutun.

Beyanların ve envanterin gönderimde keşfedilmesi yerine yapımın parçası olarak üretilmesini isterseniz, uygulamanın neyi işlediğini bize anlatın — ya da mobil uygulama geliştirme sayfasından başlayın.

Bir fikriniz mi var?

Kısa bir görüşmede kapsamlandırıp sabit fiyat verelim.

Proje başlat →