Mobil Uygulamalarda Kullanıcı Verisi Nasıl Korunur?

Bir mobil uygulama; telefon numarası, konum, cihaz bilgisi, ödeme hareketi, mesaj içeriği, profil fotoğrafı, sağlık verisi veya alışveriş geçmişi gibi birçok kullanıcı verisine temas edebilir. Kullanıcı uygulamayı açtığında yalnızca arayüzü görür; arka tarafta ise cihaz, API, veritabanı, üçüncü parti servisler, bildirim altyapısı ve yönetim paneli arasında sürekli veri akışı vardır.

Mobil uygulamalarda kullanıcı verisi korunacaksa mesele tek bir “güvenlik eklentisi” ile çözülmez. Koruma; ürün fikrinin ilk keşif toplantısından App Store / Google Play yayın sürecine, oradan da bakım dönemine kadar tasarlanmalıdır.

Atalay Tech’te mobil uygulama, web platformu, yönetim paneli ve AI entegrasyonu projelerinde en kritik gördüğümüz nokta şudur: Güvenlik sonradan eklenen bir katman değil, mimarinin kendisidir. Özellikle üyelik, ödeme, mesajlaşma, dosya yükleme, konum, bildirim ve yönetim paneli içeren projelerde kullanıcı verisinin nasıl toplandığı, nerede saklandığı, kimlerin eriştiği ve ne zaman silindiği netleşmeden sağlıklı bir ürün geliştirme süreci kurulamaz.

Bu rehber, mobil uygulama geliştirme sürecinde kullanıcı verisinin teknik, yasal ve operasyonel olarak nasıl korunması gerektiğini anlatır. Amaç satış sayfası gibi konuşmak değil; mobil uygulama fikri olan kurucu, ürün yöneticisi veya teknik ekip için uygulanabilir bir güvenlik çerçevesi sunmaktır.

Kullanıcı Verisi Mobil Uygulamada Ne Anlama Gelir?

Kullanıcı verisi yalnızca “ad, soyad, e-posta” değildir. Mobil uygulama tarafında veri; kullanıcının kim olduğunu, nasıl davrandığını, ne satın aldığını, nerede bulunduğunu veya hangi cihazdan eriştiğini gösteren her parçayı kapsayabilir.

Örneğin bir pazar yeri uygulamasında kullanıcı verisi; alıcı profili, satıcı bilgisi, ürün favorileri, ödeme geçmişi, teslimat adresi, destek talepleri ve cihaz bildirimi token’larından oluşur. Bir sosyal ağ uygulamasında ise mesaj içerikleri, bağlantılar, gönderiler, beğeniler, profil fotoğrafları ve şikayet kayıtları veri kapsamına girer.

Mobil uygulamalarda veri türleri genellikle şu şekilde ayrılır:

Buradaki kritik ayrım şudur: Her veri aynı hassasiyette değildir. Kullanıcının profil rengi tercihi ile kimlik numarası aynı güvenlik sınıfına konulamaz. Sağlam mimari, veriyi önem derecesine göre sınıflandırır ve her sınıfa farklı koruma uygular.

Veri Koruma Neden Sadece KVKK Maddesi Değildir?

Türkiye’de kullanıcı verisi denildiğinde akla doğal olarak KVKK uyumluluğu gelir. Kişisel Verileri Koruma Kurumu’nun resmi kaynaklarında da veri işleme, aydınlatma, ihlal bildirimi ve kurul kararları gibi başlıklar düzenli olarak ele alınır: KVKK resmi sitesi.

Fakat mobil uygulama güvenliği yalnızca metin onayı almakla tamamlanmaz. Kullanıcıya “aydınlatma metnini kabul ediyorum” kutusu göstermek, veri akışınız güvensizse tek başına yeterli değildir.

Bir örnek düşünelim:

Ayşe, 28 yaşında freelance tasarımcı. Bir görev yönetimi uygulamasına üye oluyor, profil fotoğrafı yüklüyor, ekip arkadaşlarını davet ediyor ve dosya paylaşımı yapıyor. Uygulama KVKK metni gösteriyor ama dosyalar tahmin edilebilir URL’lerle herkese açık tutuluyor. Bu durumda hukuki metin var gibi görünür; fakat teknik veri koruma zayıftır.

Gerçek koruma için üç katman birlikte çalışmalıdır:

• Hukuki katman: Aydınlatma metni, açık rıza, veri saklama süresi, silme talebi.
• Teknik katman: Şifreleme, güvenli API, yetkilendirme, log kontrolü, güvenli dosya erişimi.
• Operasyonel katman: Yetkili personel erişimi, düzenli test, ihlal planı, bakım süreci.

Kullanıcı verisini güçlü biçimde koruyan ekipler, bu üç katmanı birbirinden koparmaz. KVKK metni ürünün dış yüzü ise güvenli mimari ürünün omurgasıdır.

Mobil Uygulamalarda En Sık Veri Güvenliği Hataları

Mobil uygulamalarda veri sızıntısı çoğu zaman “çok gelişmiş saldırı” nedeniyle değil, basit ihmal zinciri nedeniyle oluşur. Özellikle hızlı MVP çıkarma baskısı altında bazı ekipler güvenlik kararlarını sonraya bırakır. Bu yaklaşım, ürün büyüdükçe teknik borcu ve hukuki riski artırır.

Aşağıdaki tablo, mobil uygulamalarda sık görülen veri güvenliği hatalarını ve doğru yaklaşımı özetler:

Atalay Tech projelerinde özellikle API yetkilendirme, dosya erişimi, yönetim paneli rol sistemi ve bildirim token yönetimi gibi noktalar erken aşamada netleştirilir. Çünkü bu alanlar ürün büyüdüğünde değiştirilmesi en maliyetli alanlardır.

Veri Minimizasyonu: Toplamadığın Veriyi Korumak Zorunda Kalmazsın

Mobil uygulamalarda kullanıcı verisini korumanın en güçlü yolu, gereksiz veriyi hiç toplamamaktır. Buna veri minimizasyonu denir.

Bir spor salonu rezervasyon uygulaması düşünelim. Kullanıcıdan ad, telefon, üyelik tipi ve rezervasyon saati alınması yeterliyken T.C. kimlik numarası, açık adres ve doğum tarihi isteniyorsa gereksiz risk üretilir. Ürün ekibi “ileride lazım olabilir” diye veri topladığında, aslında ileride korunması, açıklanması ve silinmesi gereken ek yük oluşturur.

Veri minimizasyonu için pratik kontrol listesi:

• Bu veri uygulamanın temel işlevi için gerçekten gerekli mi?
• Aynı amaç daha az hassas veriyle çözülebilir mi?
• Veri kullanıcı hesabına bağlı tutulmak zorunda mı?
• Saklama süresi belli mi?
• Kullanıcı bu verinin neden istendiğini anlayabilir mi?
• Veriyi üçüncü taraf servislerle paylaşmak şart mı?

Örneğin bir teslimat uygulamasında konum verisi operasyon için kritik olabilir. Fakat her 5 saniyede arka planda konum almak yerine, yalnızca teslimat aşamasında ve kullanıcıya açık şekilde konum erişimi almak daha sağlıklı bir yaklaşımdır.

Google Play tarafında geliştiriciler, uygulamanın hangi kullanıcı verilerini topladığını ve paylaştığını Data safety form üzerinden beyan eder. Google’ın resmi açıklamasına göre bu form, kullanıcılara uygulamanın hangi veri türlerini topladığını ve paylaştığını göstermek için kullanılır: Android Developers Data Safety.

Apple tarafında da App Privacy Details, uygulamanın hangi verileri topladığını ve bu verilerin nasıl kullanıldığını kullanıcılara açıklamayı hedefler: Apple App Privacy Details.

İzin Yönetimi: Kullanıcıdan Doğru Anda Doğru İzni İstemek

Mobil uygulamalarda izin yönetimi hem güvenlik hem dönüşüm oranı açısından kritiktir. Kullanıcı uygulamayı ilk açtığında kamera, mikrofon, konum, bildirim ve rehber izni aynı anda istenirse güven düşer. Daha kötüsü, kullanıcı izni reddeder ve uygulamanın temel akışı bozulur.

Doğru yaklaşım, izni bağlam içinde istemektir.

Örneğin:

• Profil fotoğrafı yüklerken kamera veya galeri izni istenebilir.
• Harita üzerinden yakındaki hizmetleri gösterirken konum izni istenebilir.
• Sipariş durumunu bildirmek için ödeme sonrası bildirim izni istenebilir.
• Sesli görüşme özelliği başlatılırken mikrofon izni istenebilir.

Aşağıdaki tablo, izinlerin nasıl ele alınması gerektiğini gösterir:

İzin ekranı yalnızca teknik bir popup değildir. Kullanıcının uygulamaya duyduğu güvenin ilk temas noktalarından biridir. Kısa, anlaşılır ve bağlama uygun açıklama dönüşüm oranını yükseltirken veri gizliliği algısını da güçlendirir.

Güvenli API Mimarisi: Mobil Uygulamanın Asıl Koruma Duvarı

Mobil uygulama cihazda çalışır; ama kullanıcı verisinin büyük kısmı backend ve API tarafında korunur. Bu yüzden API entegrasyonu yalnızca “mobil uygulama backend’e bağlansın” işi değildir. Doğru kimlik doğrulama, yetkilendirme, rate limit, loglama, hata yönetimi ve veri doğrulama birlikte tasarlanmalıdır.

En yaygın risklerden biri, mobil uygulamada görünen ID değerlerine fazla güvenmektir. Örneğin kullanıcı /orders/125 isteğini gönderdiğinde backend yalnızca “125 numaralı sipariş var mı?” diye bakarsa hata yapar. Backend ayrıca “bu sipariş bu kullanıcıya mı ait?” kontrolünü de yapmalıdır.

Güvenli API için temel ilkeler:

• Tüm trafik HTTPS üzerinden yapılmalı.
• Access token kısa ömürlü, refresh token kontrollü olmalı.
• Kritik işlemlerde backend ownership kontrolü yapılmalı.
• Rate limit ve brute force koruması uygulanmalı.
• API response’ları gereksiz veri döndürmemeli.
• Hata mesajları sistem detayı sızdırmamalı.
• Dosya erişimleri süreli signed URL ile yönetilmeli.
• Admin paneli ile mobil API yetkileri ayrı kurgulanmalı.

OWASP Mobile Application Security Verification Standard, mobil yazılım mimarları, geliştiriciler ve güvenlik test ekipleri için mobil uygulama güvenliğini değerlendirmeye yönelik sektör standardı olarak konumlanır: OWASP MASVS.

Bu standart, özellikle kimlik doğrulama, veri saklama, kriptografi, ağ iletişimi, platform etkileşimi ve kod kalitesi gibi alanlarda referans çerçeve sunar. Mobil uygulama büyüdükçe bu tip standartlara göre kontrol yapmak, “gözden kaçan küçük açıkların” büyük veri riskine dönüşmesini engeller.

Cihaz Üzerinde Veri Saklama: Token, Cache ve Offline Kullanım

Mobil uygulamalarda bazı veriler cihaz üzerinde saklanır. Bu, kullanıcı deneyimi için gereklidir: Kullanıcı her açılışta tekrar giriş yapmak istemez, bazı ekranlar hızlı açılmalı, internet yokken belirli bilgiler görüntülenebilmelidir. Fakat cihaz tarafında saklanan her veri güvenlik riski taşır.

Özellikle şu alanlara dikkat edilmelidir:

• Access token ve refresh token
• Kullanıcı profil bilgileri
• Offline cache verileri
• Mesaj taslakları
• Dosya önizlemeleri
• Analitik event kuyruğu
• Push notification token

React Native gibi cross-platform yapılarda token saklama konusu ayrıca önemlidir. Token’ı kolay erişilebilir düz metin depolama alanlarında tutmak yerine iOS Keychain ve Android Keystore tabanlı güvenli saklama çözümleri tercih edilmelidir. Native tarafta da platformun sunduğu güvenli depolama mekanizmaları kullanılmalıdır.

Offline kullanım gerekiyorsa, cache verisinin kapsamı net belirlenmelidir. Örneğin e-ticaret uygulamasında ürün listesi cache’lenebilir; fakat kullanıcının fatura adresi veya ödeme geçmişi cihazda uzun süre düz biçimde tutulmamalıdır.

Cihaz tarafında pratik koruma yaklaşımı:

Buradaki amaç uygulamayı kullanılmaz hale getirmek değildir. Amaç, kullanıcı deneyimi ile veri güvenliği arasında doğru dengeyi kurmaktır.

Şifreleme: Hangi Veri Nerede Şifrelenmeli?

Şifreleme, mobil veri güvenliğinin en bilinen ama en yanlış anlaşılan konularından biridir. “Veritabanını şifreledik” demek tek başına yeterli değildir. Veri hareket halindeyken, saklanırken ve yedeklenirken farklı risklere sahiptir.

Temel ayrım şu şekildedir:

• In transit: Veri cihaz ile sunucu arasında taşınırken korunur. HTTPS/TLS zorunludur.
• At rest: Veri veritabanında, dosya depolamada veya yedekte saklanırken korunur.
• In use: Veri uygulama veya sunucu belleğinde işlenirken erişim kontrolleriyle korunur.

Örneğin bir sağlık randevu uygulamasında kullanıcının doktor notları, reçete dosyaları ve randevu geçmişi hassas veri sınıfına girer. Bu veriler yalnızca HTTPS ile gönderilmemeli; backend erişim izinleri, dosya erişim süreleri, log maskeleme ve yedekleme politikalarıyla da korunmalıdır.

Şifreleme kararları ürün tipine göre değişir:

Şifreleme tasarımında önemli olan, kriptografiyi uygulamanın tek savunması gibi görmemektir. Zayıf yetkilendirme varsa şifreli veritabanı bile kullanıcı bazlı veri sızıntısını engelleyemez.

Üçüncü Parti SDK ve Servisler: Görünmeyen Veri Akışı

Mobil uygulamalar genellikle tek başına çalışmaz. Analitik, crash reporting, push notification, ödeme, harita, sosyal giriş, reklam ve müşteri destek SDK’ları ürüne dahil edilir. Bu servislerin her biri veri akışına yeni bir kapı ekler.

Örneğin bir mobil uygulama şu servisleri kullanabilir:

• Firebase Analytics
• Crashlytics
• OneSignal veya Firebase Cloud Messaging
• Google Maps
• Apple Sign In / Google Sign-In
• Stripe, iyzico veya benzeri ödeme sağlayıcıları
• Sentry gibi hata takip araçları
• AI tabanlı öneri veya destek servisleri

Her SDK için şu sorular sorulmalıdır:

• Hangi kullanıcı verisini topluyor?
• Veriyi hangi ülke veya bölgede işliyor?
• Kullanıcı kimliğiyle eşleşen veri tutuyor mu?
• Veri paylaşımı App Store / Google Play beyanlarına giriyor mu?
• SDK güncel mi?
• Varsayılan ayarları gereğinden fazla veri topluyor mu?
• Silme talebi geldiğinde bu servisteki veri de silinebiliyor mu?

Google Play Data safety ve Apple App Privacy beyanlarının doğru yapılması için yalnızca kendi kodunuzu değil, kullandığınız üçüncü taraf servisleri de bilmeniz gerekir. Akademik çalışmalarda da geliştiricilerin veri toplama beyanlarında zorlandığı, özellikle üçüncü taraf kod ve veri sınıflandırması nedeniyle hatalı raporlama riskleri oluştuğu gösterilmiştir: Android veri beyanı çalışması.

Bu yüzden mobil uygulama geliştirme sürecinde “SDK envanteri” çıkarılmalıdır. Hangi SDK neden kullanılıyor, hangi veriye erişiyor, hangi ekranda devreye giriyor ve hangi beyana konu oluyor netleştirilmelidir.

Yönetim Paneli ve Ekip Erişimi: Veri Sızıntısı Sadece Hack ile Olmaz

Kullanıcı verisi yalnızca mobil uygulamadan sızmaz. Yönetim paneli, müşteri temsilcisi ekranı, operasyon paneli veya destek ekibi erişimi de risk oluşturur.

Bir pazaryeri uygulamasında destek personeli sipariş detaylarını görebilir. Bir eğitim uygulamasında eğitmen öğrenci listesini görüntüleyebilir. Bir sağlık randevu sisteminde klinik personeli randevu notlarına erişebilir. Bu erişimler gerekli olabilir; ancak sınırsız olmamalıdır.

Rol bazlı erişim kontrolü burada devreye girer.

Veri koruma mimarisinde yönetim paneli çoğu zaman mobil uygulama kadar önemlidir. Kullanıcı cihazındaki token güvenliyken admin paneli zayıf şifreyle korunuyorsa sistem yine risk altındadır.

Atalay Tech’in mobil uygulama ve web platformu projelerinde yönetim paneli genellikle ürünün kontrol merkezi olarak ele alınır. Kullanıcı, içerik, ödeme, bildirim, dosya, rapor ve destek süreçleri aynı panelden yönetildiğinde rol bazlı yetkilendirme erken aşamada tasarlanmalıdır.

Test Süreci: Veri Koruma Yayından Önce Nasıl Kontrol Edilir?

Mobil uygulama testinde yalnızca ekranların çalışması yeterli değildir. Kullanıcı verisi korunacaksa güvenlik ve yetki senaryoları ayrıca test edilmelidir.

Geliştirme süreci şu adımlarla ilerlediğinde veri koruma daha kontrollü olur:

1. Keşif: Hangi veri toplanacak, neden toplanacak, kim erişecek?
2. Tasarım: İzin ekranları, kullanıcı akışları, silme talebi, KVKK metni nerede gösterilecek?
3. MVP geliştirme: Minimum veriyle çalışan ilk sürüm inşa edilecek.
4. API ve backend testi: Yetkilendirme, rate limit, token akışı, dosya erişimi kontrol edilecek.
5. Mobil test: Cihaz saklama, izin yönetimi, offline cache, bildirim davranışı incelenecek.
6. Yayın hazırlığı: App Store privacy details ve Google Play Data safety beyanları doldurulacak.
7. Bakım: Güvenlik güncellemeleri, SDK güncellemeleri, log inceleme ve ihlal planı sürdürülecek.

Test senaryoları gerçek kullanıcı davranışına göre yazılmalıdır. Örneğin:

• Kullanıcı A, Kullanıcı B’nin sipariş detayını ID değiştirerek görebiliyor mu?
• Silinen kullanıcının push token’ı hâlâ bildirim alıyor mu?
• Şifre sıfırlama linki sonsuza kadar geçerli mi?
• Admin panelinde düşük yetkili rol tüm kullanıcıları indirebiliyor mu?
• Hata loglarına telefon, adres veya token düşüyor mu?
• Dosya bağlantısı süresi dolduktan sonra erişilebiliyor mu?

Bu testler, ürünü yayına hazırlarken “güvenli çalışıyor mu?” sorusuna daha gerçekçi cevap verir.

Yayın Sonrası Bakım: Güvenlik Bir Defalık Kontrol Değildir

Mobil uygulama yayınlandıktan sonra veri güvenliği bitmez. İşletim sistemi güncellemeleri, SDK değişiklikleri, yeni cihaz davranışları, API versiyonları ve kullanıcı sayısındaki artış güvenlik risklerini sürekli değiştirir.

Bu nedenle teknik destek ve bakım süreci, yalnızca hata düzeltme paketi olarak görülmemelidir. Bakım; güvenlik güncellemesi, performans takibi, log inceleme, veri tabanı yedekleme, üçüncü parti servis kontrolü ve mağaza uyumluluğunu da kapsamalıdır.

Yayın sonrası düzenli kontrol edilmesi gereken başlıklar:

Bir uygulama 500 kullanıcıdayken tolere edilebilen küçük bir hata, 50.000 kullanıcıda ciddi veri krizine dönüşebilir. Bu yüzden güvenlik ve bakım, uygulama büyüdükçe daha sistematik hale gelmelidir.

Mobil Veri Koruma Maliyeti: MVP, Orta Ölçek ve Kurumsal Yaklaşım

Veri koruma maliyeti, uygulamanın kapsamına göre değişir. Basit bir MVP’de temel güvenlik katmanları yeterli olabilir. Finans, sağlık, kurumsal operasyon veya yüksek hacimli pazaryeri uygulamalarında ise güvenlik, test ve bakım bütçesi daha yüksek planlanmalıdır.

Aşağıdaki maliyet aralıkları Türkiye piyasası ve Atalay Tech’in proje değerlendirme yaklaşımı için tahmini referans niteliğindedir. Kapsam, entegrasyon sayısı, kullanıcı rolleri, veri hassasiyeti ve yayın sonrası destek beklentisi fiyatı doğrudan etkiler.

Burada önemli nokta, güvenliği “ekstra maliyet” gibi görmemektir. Zayıf veri mimarisiyle yayına çıkan bir uygulamada sonradan yapılacak düzeltmeler çoğu zaman ilk geliştirme maliyetinden daha pahalı olabilir.

mobil uygulama fiyatları tarafında maliyet hesaplanırken yalnızca ekran sayısı değil; veri hassasiyeti, API sayısı, entegrasyonlar, panel yetkileri, test gereksinimi ve bakım kapsamı da değerlendirilmelidir.

Mobil Uygulama Yaptırırken Veri Koruma İçin Hangi Sorular Sorulmalı?

mobil uygulama yaptırmak isteyen bir kurucu veya işletme, teklif alırken yalnızca “kaç ekran olacak?” sorusuna odaklanmamalıdır. Kullanıcı verisinin korunması için teknik ekibe net sorular yöneltilmelidir.

Sorulması gereken pratik sorular:

• Hangi kullanıcı verilerini toplayacağız?
• Bu verilerin hangileri gerçekten gerekli?
• Veriler hangi sunucuda ve hangi bölgede tutulacak?
• API yetkilendirmesi nasıl yapılacak?
• Kullanıcı silme talebi geldiğinde ne olacak?
• App Store ve Google Play veri beyanları kim tarafından hazırlanacak?
• Üçüncü parti SDK’lar hangi verileri topluyor?
• Yönetim panelinde kim hangi veriye erişecek?
• Hata loglarında kişisel veri maskelenecek mi?
• Yayın sonrası güvenlik güncellemeleri nasıl yönetilecek?

Bu sorular, proje başlamadan önce belirsizlikleri azaltır. Aynı zamanda geliştirici ekibin yalnızca arayüz değil, veri mimarisi konusunda da ne kadar hazırlıklı olduğunu gösterir.