Çalışma mantığı
Koruma bileşeni uygulamanın içinde çalışır; imza, kod, süreç ve cihaz ortamından sinyaller toplar. Politika bu sinyallerin anlamını belirler. Karar yerelde uygulanabilir veya sunucuya taşınabilir. Her ürün aynı kontrolleri, aynı sıklıkta ve aynı platform kapsamıyla sunmaz.
Uygulamada nasıl değerlendirilir?
Bir para transferinde uygulama bütünlüğü şüpheli görünüyorsa oturumu koşulsuz kapatmak yerine transferi durdurup sunucuda ek doğrulama istenebilir. Hesap bakiyesini görüntüleme ile yeni alıcı ekleme aynı risk sınıfına konmamalıdır.
Sınırlar ve yaygın hatalar
RASP, kaynak koddaki açığı düzeltmez ve sunucudaki yetkilendirmenin yerini almaz. Kullanıcının kontrol ettiği cihazda hiçbir yerel kontrol mutlak güvence sağlamaz.
Kontrol listesi
- Korunan işlemleri belirleyin
- Algılama ile yaptırımı ayırın
- Normal cihazlarla karşılaştırmalı test yapın
Karar verirken
Önce tehdit modelini kurun. RASP yatırımını, engellemesini beklediğiniz somut müdahale ve kabul edilebilir kullanıcı etkisi üzerinden değerlendirin.
Bir koruma zincirini okumak
RASP kısaltması Runtime Application Self-Protection ifadesinden gelir. Mobil uygulamada koruma, cihazın tamamını yönetmekten çok uygulamanın kendi güven varsayımlarını denetlemeye odaklanır. Bu nedenle bir kullanıcının telefonunda risk görülmesi ile o kullanıcının hesabında yetkisiz işlem yapılması farklı durumlardır.
Örneğin yalnızca açılışta çalışan bir bütünlük kontrolü ile transfer isteğine bağlanan güncel kanıt aynı güvenceyi sağlamaz. Tasarım incelemesinde sinyalin nerede üretildiğini, taşınırken nasıl korunduğunu ve kararı hangi bileşenin uyguladığını sorun. Zincirin sonundaki sunucu istemcinin kararına sorgusuz güveniyorsa yerel kontrolün gücü tek başına yeterli olmaz.
İlgili rehberler: Mobile RASP için tehdit modeli hazırlama, RASP kararını cihaz mı sunucu mu vermeli?.
Mobile RASP güvenlik mimarisinde nereye oturur?
Bir mobil uygulama, geliştiricinin yönetemediği cihazlarda çalışır. Kullanıcı işletim sistemini değiştirebilir, uygulama dosyasını inceleyebilir veya ağ bağlantısını farklı bir yoldan geçirebilir. Savunmanın başlangıç noktası bu koşulları yok saymak yerine güveni sınırlamaktır. Sunucu, istemciden gelen her iddiayı aynı derecede güvenilir kabul etmez.
Mobile RASP bu mimaride uygulamanın kendi bağlamına yakın gözlem ve tepki yeteneği ekler. Korumanın pratik değeri, belirli bir saldırı yolunda sonucu değiştirebilmesidir. Bir alarmın üretilmesi yararlıdır; ancak para transferi yine de kabul ediliyorsa hedeflenen iş kaybı önlenmemiş olabilir.
| Katman | Temel soru | Örnek |
|---|---|---|
| Güvenli geliştirme | Uygulamanın kodu ve yapılandırması doğru mu? | Yetkisiz veri erişiminin düzeltilmesi |
| Platform koruması | Anahtar, paket ve veri hangi koşullarda korunuyor? | İmzalama, Keychain, Keystore |
| Mobile RASP | Çalışma anında müdahale veya risk işareti var mı? | Bütünlük ve runtime denetimleri |
| Sunucu denetimi | Bu kullanıcı bu işlemi yapabilir mi? | Nesne yetkisi, işlem bağlama, kota |
| Operasyon | Karar doğru mu ve gerektiğinde değiştirilebilir mi? | Yanlış pozitif incelemesi, geri alma |
İlk Mobile RASP projesi nasıl başlatılır?
Başlangıç için tek bir yüksek etkili akış seçin. Örneğin yeni ödeme alıcısı eklenmesini ele alın. Kullanıcının gördüğü bilgiler, sunucuya giden alanlar ve işlemi kabul eden servis belirlenir. Hangi müdahalenin yanlış alıcı eklenmesine yol açabileceği yazılır. Ardından bunu önlemek veya fark etmek için gerekli kontrol zinciri kurulur.
Denemede iki ayrı soru sorulur: kontrollü risk durumunda ne oluyor ve normal kullanıcı ne yaşıyor? Sadece birincisini ölçmek kullanılabilirliği, sadece ikincisini ölçmek savunmanın etkisini saklar. Test cihazı, uygulama sürümü ve politika kaydı tutulduğunda sonuç başka sürümle karşılaştırılabilir.
Üretime geçişte olayın sahibi ve tepki yetkisi belirlenir. Yeni kuralın kullanıcıları yanlış engellemesi durumunda geri alma süreci hazır olmalıdır. RASP entegrasyonu tek seferlik bir SDK ekleme işi olarak bırakılırsa platform değişimleri ve yeni saldırı yöntemleri karşısında değeri zamanla azalabilir.
Sık sorulan temel sorular
RASP olmayan bir mobil uygulama mutlaka güvensiz midir?
Bu sonuç tek başına çıkarılamaz. Gereksinim uygulamanın tehdit modeline, iş etkisine ve mevcut kontrollerine bağlıdır. Çalışma zamanı müdahalesinin önemli kayba yol açabildiği uygulamalarda ek direnç ve görünürlük daha güçlü gerekçeye sahip olabilir.
RASP uygulamayı tamamen saldırıya kapatır mı?
Hayır. Kullanıcının kontrolündeki cihazda mutlak koruma varsayımı yapılmamalıdır. RASP, saldırı maliyetini artırabilir, belirli müdahaleleri algılayabilir ve etkilerini sınırlayabilir. Sunucu açıkları ve ele geçirilmiş hesaplar için başka kontroller de gerekir.
Ücretsiz bir root kontrolü yeterli olabilir mi?
Dar bir gereksinimde yardımcı bileşen olabilir. Bunun hangi riski azalttığı, neyi göremediği ve bakımının kimde olduğu açıklanmalıdır. Tek root kontrolü geniş bir RASP platformunun kod koruma, olay yönetimi ve sunucu entegrasyonu kapsamıyla eş tutulmaz.
Kaynaklar ve kapsam
Teknik özelliklerin başvuru noktaları aşağıdadır. Uygulama örneği ve kontrol listesi bu yayın için hazırlanmış değerlendirme önerileridir; bağımsız ürün testi sonucu değildir.