Kotlin için token, anahtar ve kişisel veriler (PII) güvenli depolama kontrol listesi

Korumaya çalıştığınız şey (sade ifadeyle)

İş uygulamalarında güvenli depolama tek bir şey demektir: biri telefona (veya uygulamanızın dosyalarına) erişse bile kaydettiklerinizi okuyup yeniden kullanamamalı. Bu, disk üzerindeki veriyi kapsar ve aynı zamanda yedekler, loglar, hata raporları veya debug araçları yoluyla sızıntıları da içerir.

Basit bir zihin testi: bir yabancı uygulamanızın depolama klasörünü açarsa ne yapabilir? Birçok uygulamada en değerli öğeler fotoğraflar veya ayarlar değildir. Erişim sağlayan küçük dizeler (tokenlar) en değerlisidir.

Cihaz üzerinde saklananlar genellikle oturum tokenları (kullanıcıların girişte kalması için), refresh tokenlar, API anahtarları, şifreleme anahtarları, ad ve e-posta gibi kişisel veriler (PII) ve çevrimdışı kullanılan önbelleğe alınmış iş kayıtlarıdır (siparişler, biletler, müşteri notları).

Gerçek hayatta sık rastlanan başarısızlık senaryoları:

• Kaybolan veya çalınan cihaz incelenir ve tokenlar kopyalanarak kullanıcı taklidi yapılır.
• Kötü amaçlı yazılım veya bir “yardımcı” uygulama rootlu cihazda veya erişilebilirlik hileleriyle yerel dosyaları okur.
• Otomatik cihaz yedekleri uygulama verilerinizi planlamadığınız bir yere taşır.
• Debug derlemeler tokenları loglar, hata raporlarına yazar veya güvenlik kontrollerini devre dışı bırakır.

Bu yüzden “sadece SharedPreferences'a koy” diye düşünmek, erişim veren herhangi bir şey (tokenlar) veya kullanıcıya ve şirkete zarar verebilecek PII için uygun değil. Düz SharedPreferences bir yapışkan not üzerine sır yazmak gibidir: kullanışlı, ama biri okursa okumaya çok açıktır.

En yararlı başlangıç noktası, her saklanan öğeyi adlandırmak ve iki soru sormaktır: bir şeyi açıyor mu, ve kamuya açılması sorun olur mu? Geri kalan (Keystore, encrypted preferences, şifreli veritabanı) bu sınıflandırmadan gelir.

Verilerinizi sınıflandırın: tokenlar, anahtarlar ve PII

Tüm "hassas verileri" aynı muameleye tabi tutmayı bırakınca güvenli depolama kolaylaşır. Uygulamanın ne kaydettiğini ve sızıntı olursa ne olacağını listeleyerek başlayın.

Tokenlar parolalarla aynı değil. Access token ve refresh token oturumun sürdürülmesi için saklanır, ama yine de yüksek değerli sırdır. Parolalar asla saklanmamalı. Giriş gerekiyorsa, oturum sürdürmek için gereken minimumu saklayın (genellikle tokenlar) ve parola doğrulamasını sunucuya bırakın.

Anahtarlar farklı bir sınıftır. API anahtarları, imzalama anahtarları ve şifreleme anahtarları tüm sistemleri açabilir; cihazdan çıkarılırsa kötüye kullanım otomatikleştirilebilir. Kural: bir değer uygulama dışında kullanılıp uygulamayı taklit edebiliyorsa veya veriyi çözebiliyorsa, onu kullanıcı tokenından daha yüksek riskli sayın.

PII bir kişiyi tanımlayabilecek her şeydir: e-posta, telefon, adres, müşteri notları, kimlik numaraları, sağlık verileri. Birleşince zararlı olabilecek görünüşte zararsız alanlar bile hassastır.

Pratik bir etiketleme sistemi:

• Oturum sırları: access token, refresh token, oturum çerezi
• Uygulama sırları: API anahtarları, imzalama anahtarları, şifreleme anahtarları (mümkünse cihazlara koymaktan kaçının)
• Kullanıcı verisi (PII): profil bilgiler, tanımlayıcılar, belgeler, sağlık veya finansal bilgiler
• Cihaz ve analiz kimlikleri: reklam ID'si, cihaz ID'si, kurulum ID'si (birçok politika altında hâlâ hassastır)

Android Keystore: ne zaman kullanılır

Android Keystore, cihazdan ham halde asla çıkmaması gereken sırları korumak istediğinizde en uygunudur. Keystore kriptografik anahtarlar için bir kasa gibidir, asıl veritabanınızın yerini almaz.

İyi olduğu şeyler: şifreleme, şifre çözme, imzalama veya doğrulama için kullanılan anahtarları üretmek ve tutmak. Genellikle token veya çevrimdışı veriyi başka yerde şifreler, Keystore anahtarı ise onu açmak için kullanılır.

Donanım destekli anahtarlar: gerçekte ne demek

Birçok cihazda Keystore anahtarları donanım destekli olabilir. Bu, anahtar işlemlerinin korumalı bir ortam içinde yapılması ve anahtar materyalinin çıkarılamaması demektir. Bu, uygulama dosyalarını okuyabilen kötü amaçlı yazılımdan riski azaltır.

Donanım destekli olmak her cihazda garanti değildir ve model ile Android sürümüne göre davranış değişir. Anahtar işlemlerinin başarısız olabileceğini varsayarak tasarlayın.

Kullanıcı kimlik doğrulama bariyerleri

Keystore, bir anahtarın kullanılmadan önce kullanıcı varlığı gerektirmesini sağlayabilir. Böylece erişimi biyometriye veya cihaz kimlik bilgisine bağlarsınız. Örneğin, bir export tokenını şifreleyip yalnızca parmak izi veya PIN ile onaylandığında çözebilirsiniz.

Keystore, anahtarı dışa aktarmaya izin vermeyen bir çözüm istediğinizde, biyometrik veya cihaz kimlik doğrulamasıyla hassas işlemleri sınırlandırmak istediğinizde ve eşitleme veya yedeklerle taşınmaması gereken cihaz başına sırlar istediğinizde güçlü bir tercihtir.

Dezavantajlar: kilit ekranı değişiklikleri, biyometrik değişiklikler veya güvenlik olayları sonrası anahtarlar geçersizleşebilir. Hataları bekleyin ve temiz bir geri dönüş yolu uygulayın: geçersiz anahtarları tespit edin, şifreli blob'ları silin ve kullanıcıdan tekrar giriş isteyin.

EncryptedSharedPreferences: ne zaman yeterli

EncryptedSharedPreferences, anahtar-değer formundaki küçük bir sır seti için iyi bir varsayılan seçenektir. "SharedPreferences ama şifrelenmiş" olduğu için birisi dosyayı açıp değerleri okuyamaz.

Altında bir master anahtar kullanır ve bu master anahtar Android Keystore ile korunur; böylece uygulamanız ham şifreleme anahtarını açık metin halinde saklamaz.

Sık okunan birkaç küçük öğe için genellikle yeterlidir: access ve refresh tokenlar, oturum ID'leri, cihaz ID'leri, ortam bayrakları veya son senkron zamanı gibi küçük durum parçaları. Gerçekten saklamanız gereken küçük kullanıcı verileri için de uygundur, ama PII için çöplük haline getirmeyin.

Büyük veya yapısal veriler için uygun değildir. Çevrimdışı listeler, arama veya alanlara göre sorgulama gerekiyorsa EncryptedSharedPreferences yavaş ve kullanışsız hale gelir. Bu durumda şifreli bir veritabanı kullanmak istersiniz.

Basit bir kural: saklanan her anahtarı tek bir ekranda listeleyebiliyorsanız muhtemelen EncryptedSharedPreferences yeterlidir. Satırlar ve sorgular gerekiyorsa öteye geçin.

Veritabanı şifreleme: ne zaman gerekli

Veritabanı şifrelemesi, küçük bir ayar veya tek token'dan fazlasını sakladığınızda önemlidir. Uygulamanız cihazda iş verisi tutuyorsa, telefon kaybolduğunda verilerin çıkarılabileceğini varsayın ve koruyun.

Veritabanı, kayıtların çevrimdışı erişimine, performans için yerel önbelleğe, geçmiş/takip kayıtlarına veya uzun notlar ve ek dosyalara ihtiyaç duyduğunuzda mantıklıdır.

İki yaygın şifreleme yaklaşımı

Tam veritabanı şifreleme (genellikle SQLCipher benzeri) dosyanın tamamını diskte şifreler. Uygulamanız onu bir anahtar ile açar. Her sütunun korunup korunmadığını düşünmek zorunda kalmadığınız için açıklaması kolaydır.

Uygulama katmanı alan şifrelemesi yalnızca belirli alanları yazmadan önce şifreler, okuduktan sonra çözer. Çoğu kayıt hassas değilse veya dosya formatını değiştirmeden belirli alanları korumak istiyorsanız işe yarayabilir.

Gizlilik vs arama ve sıralama: ödünler

Tam veritabanı şifreleme diskte her şeyi gizler, ancak veritabanı açıldıktan sonra uygulamanız normal şekilde sorgulayabilir.

Alan şifrelemesi belirli sütunları korur ama şifrelenmiş değerlere göre kolay sıralama veya arama kaybedilir. Şifrelenmiş bir soyada göre sıralama güvenilir çalışmaz; arama ya "çözme sonrası ara" (yavaş) ya da "ek indeks sakla" (daha fazla karmaşıklık ve potansiyel sızıntı) olur.

Anahtar yönetimi temel kuralları

Veritabanı anahtarı asla hardcode edilmemeli veya uygulamayla gönderilmemelidir. Yaygın bir desen, rastgele bir veritabanı anahtarı oluşturmak ve sonra onu Android Keystore'da tutulan bir anahtarla sarılmış (şifrelenmiş) şekilde saklamaktır. Logout'ta sarılmış anahtarı silebilir ve yerel veritabanını kullanılmaz sayabilirsiniz; ya da uygulamanız çevrimdışı çalışmayı sürdürmeli ise farklı bir strateji izleyebilirsiniz.

Nasıl seçilir: pratik karşılaştırma

Burada seçim "genel olarak en güvenli" değil; verinin nasıl kullanıldığına göre en güvenli ve uygun seçeneği seçiyorsunuz.

Gerçekten doğru seçimi belirleyen sorular:

• Veri ne sıklıkla okunuyor (her başlatmada mı nadiren mi)?
• Ne kadar veri (birkaç byte mı binlerce kayıt mı)?
• Sızarsa ne olur (rahatsız edici, maliyetli, yasal bildirim gerektiren)?
• Çevrimdışı erişim, arama veya sıralama gerekiyor mu?
• Uyumluluk gereksinimleriniz var mı (saklama, denetim, şifreleme kuralları)?

Uygulanabilir eşleme:

• Tokenlar (OAuth access ve refresh tokenlar) genellikle EncryptedSharedPreferences içinde saklanır çünkü küçük ve sık okunurlar.
• Anahtar materyali mümkün olduğunca Android Keystore'da tutulmalıdır; böylece cihazdan kopyalanma şansı azalır.
• PII ve çevrimdışı iş verisi birkaç alandan fazlasını sakladığınızda genellikle veritabanı şifrelemesi gerektirir.

Karışık veri iş akışları iş uygulamalarında normaldir. Pratik bir desen, yerel veritabanınız veya dosyanız için rastgele bir veri şifreleme anahtarı (DEK) üretmek, yalnızca Keystore destekli bir anahtarla sarılmış DEK'i saklamak ve gerektiğinde döndürmektir.

Emin değilseniz, daha basit güvenli yolu seçin: daha az saklayın. Çevrimdışı PII'dan kaçının, gerçekten gerekmedikçe anahtarları Keystore'da tutun.

Adım adım: bir Kotlin uygulamasında güvenli depolamayı uygulamak

Cihaza kaydetmeyi planladığınız her değeri ve bunun tam nedenini yazın. Bu, "ihtimal diye" saklamayı önlemenin en hızlı yoludur.

Koda başlamadan önce kurallarınızı belirleyin: her öğe ne kadar yaşayacak, ne zaman değiştirilecek ve "logout" gerçekte ne anlama geliyor. Bir access token 15 dakikada dolabilir, bir refresh token daha uzun sürebilir ve çevrimdışı PII için 30 gün sonra silme gibi kurallarınız olabilir.

Bakımı kolay bir uygulama için:

• Uygulamanın geri kalanının doğrudan SharedPreferences, Keystore veya veritabanına dokunmaması için tek bir "SecureStorage" sarmalayıcısı oluşturun.
• Her öğeyi doğru yere koyun: tokenlar EncryptedSharedPreferences, şifreleme anahtarları Android Keystore ile korunmuş, büyük çevrimdışı veri setleri ise şifreli veritabanında.
• Hataları kasıtlı olarak ele alın. Güvenli depolama başarısız olursa kapalı başarın. Düz saklamaya sessizce geri dönmeyin.
• Veri sızdırmayacak şekilde tanılama ekleyin: olay türleri ve hata kodlarını loglayın, asla token, anahtar veya kullanıcı detaylarını yazmayın.
• Silme yollarını birbirine bağlayın: logout, hesap kaldırma ve "uygulama verilerini temizle" aynı temizleme rutinine gitmeli.

Sonra güvenli depolamayı üretimde kırabilecek sıkıcı durumları test edin: yedekten geri yükleme, eski bir sürümden yükseltme, cihaz kilit ayarı değişikliği, yeni telefona taşıma. Kullanıcıların şifre çözme yapılamayan veriler yüzünden takılıp kalmadığından emin olun.

Son olarak, bütün kararları bir sayfada yazın: ne saklanır, nerede, saklama süreleri ve şifre çözme başarısız olduğunda ne yapılır.

Güvenli depolamayı bozan yaygın hatalar

Çoğu başarısızlık yanlış kütüphane seçimiyle değil, küçük bir kısayolun sırları istemeden başka yerlere kopyalamasıyla olur.

En büyük kırmızı bayrak, refresh token (veya uzun ömürlü oturum tokenı) herhangi bir yerde açık metin olarak saklanmasıdır: SharedPreferences, bir dosya, "geçici" önbellek veya yerel veritabanı sütunu. Birisi bir yedek, rootlu cihaz dökümü veya debug artifaktı ele geçirirse o token paroladan daha uzun süre geçerliliğini koruyabilir.

Sırlar görünürlük yoluyla da sızar, saklama yoluyla değil. İstek başlıklarını loglamak, tokenları debug sırasında yazdırmak veya hata raporlarına/analitik olaylarına yardımcı bağlam eklemek kimlik bilgilerini cihaz dışına çıkarabilir. Logları herkese açık kabul edin.

Anahtar yönetimi başka bir yaygın boşluktur. Her şey için tek bir anahtar kullanmak patlama alanını büyütür. Anahtarları hiç döndürmemek ise eski ihlallerin geçerliliğini sürdürmesine izin verir. Anahtar sürümleri, döndürme ve eski şifrelenmiş verinin ne olacağı için bir planınız olsun.

"Kasadışındaki" yolları unutmayın

Şifreleme cihaz yedeklerinin yerel uygulama verilerini kopyalamasını engellemez. Ekran görüntüleri veya ekran kaydı PII'ı yakalayabilir. Debug derlemeler gevşek ayarlarla gelebilir veya dışa aktarma özellikleri (CSV/paylaşım) hassas alanları sızdırabilir. Panoya kopyalama tek seferlik kodları veya hesap numaralarını sızdırabilir.

Ayrıca şifreleme yetkilendirmeyi düzeltmez. Kullanıcı çıkış yaptıktan sonra PII gösteriliyorsa veya önbelleğe alınmış veriler tekrar kimlik doğrulaması olmadan erişilebiliyorsa bu bir erişim kontrol hatasıdır. UI'ı kilitleyin, hassas önbellekleri logout'ta silin ve korunan veriyi göstermeden önce izinleri yeniden kontrol edin.

Operasyonel ayrıntılar: yaşam döngüsü, logout ve uç durumlar

Güvenli depolama sadece sırları nereye koyduğunuz değildir; aynı zamanda zaman içinde nasıl davrandıklarıdır: uygulama uyku modundayken, kullanıcı çıkış yaptığında veya cihaz kilitlendiğinde.

Tokenlar için tam yaşam döngüsünü planlayın. Access tokenlar kısa ömürlü olmalı. Refresh tokenlar parola gibi muamele görmeli. Bir token süresi dolduysa sessizce yenileyin. Yenileme başarısız olursa (iptal edilmiş, parola değişmiş, cihaz kaldırılmış) tekrar deneme döngüsünü durdurun ve temiz bir giriş isteyin. Sunucu tarafı iptal desteği sağlayın. Yerel depolama mükemmel olsa bile çalınmış kimlik bilgileri sunucu tarafında geçersiz kılınmazsa işe yaramaz.

Biyometriyi her şey için değil, yeniden kimlik doğrulama gereken eylemler için kullanın. PII görüntüleme, veri dışa aktarma, ödeme detaylarını değiştirme veya tek seferlik anahtar gösterme gibi gerçek risk içeren işlemlerde isteyin. Her uygulama açılışında sormayın.

Logout'ta katı ve öngörülebilir davranın:

• Önce bellekteki kopyaları temizleyin (singletonlarda, interceptorlarda veya ViewModel'lerde cache'lenmiş tokenlar).
• Saklanan tokenları ve oturum durumunu silin (refresh token dahil).
• Tasarımınız izin veriyorsa yerel şifreleme anahtarlarını kaldırın veya geçersiz kılın.
• Çevrimdışı PII ve önbelleğe alınmış API yanıtlarını silin.
• Veri yeniden çekebilecek arka plan görevlerini devre dışı bırakın.

Uç durumlar iş uygulamalarında önemlidir: bir cihazda birden fazla hesap, iş profilleri, yedek/geri yükleme, cihazlar arası transfer ve kısmi logout (tam çıkış yerine şirket/alan değişikliği). Force stop, OS yükseltmeleri ve saat değişikliklerini test edin; zaman sapması süresi bitmiş tokenları bozabilir.

Tahrif tespiti bir ödünleşmedir. Basit kontroller (debuggable derlemeler, emulator bayrakları, basit root sinyalleri, Play Integrity kararları) sıradan kötüye kullanımı azaltabilir, ama kararlı saldırganlar bunları atlatabilir. Tahrif sinyallerini risk girdisi olarak kullanın: çevrimdışı erişimi sınırlayın, yeniden kimlik doğrulama isteyin ve olayı kaydedin.

Göndermeden önce hızlı kontrol listesi

Yayınlamadan önce bunu kullanın. Gerçek iş uygulamalarında güvenli depolamanın başarısız olduğu yerleri hedef alır.

• Cihazın düşmanca olabileceğini varsayın. Bir saldırgan rootlu bir cihaz veya tam cihaz imajına sahipse uygulama dosyalarından token, anahtar veya PII okuyabilir mi? Cevap "belki" ise sırları Keystore destekli korumaya taşıyın ve yükü şifreleyin.
• Yedeklemeler ve cihaz transferlerini kontrol edin. Hassas dosyaları Android Auto Backup, bulut yedekleri ve cihazlar arası transfer dışında tutun. Bir geri yüklemede anahtar kayboluyorsa şifre çözmeyi kıracaksa kurtarma akışı planlayın (yeni giriş ve yeniden indirme, deşifre etmeye çalışmamak).
• Diskteki kazara açık metni arayın. Geçici dosyalar, HTTP önbellekleri, hata raporları, analiz olayları ve resim önbelleklerinde PII veya token arayın. Debug loglarını ve JSON dump'larını kontrol edin.
• Süresi dolma ve döndürme. Access token kısa süreli olmalı, refresh token korunmalı ve sunucu tarafı oturumlar iptal edilebilir olmalı. Anahtar döndürme ve kabul edilmeyen tokenlarda uygulamanın ne yaptığı tanımlı olsun (temizle, yeniden kimlik doğrula, bir kez yeniden dene).
• Yeniden yükleme ve cihaz değişimi davranışı. Kaldırma ve yeniden yükleme, sonra çevrimdışı açma test edin. Keystore anahtarları yoksa uygulama güvenli şekilde davranmalı (şifreli veriyi sil, giriş göster, kısmi okumalarla durumu bozma).

Hızlı bir doğrulama: kötü bir gün testi: bir kullanıcı çıkış yapar, parolasını değiştirir, yedeği yeni telefona geri yükler ve uçakta uygulamayı açar. Sonuç öngörülebilir olmalı: ya veri doğru kullanıcı için deşifre olur ya da silinir ve tekrar girişten sonra yeniden getirilir.

Örnek senaryo: çevrimdışı PII saklayan bir iş uygulaması

Sinyal olmayan bölgelerde kullanılan saha satış uygulamasını düşünün. Temsilciler sabah bir kez giriş yapar, atanan müşterilere çevrimdışı erişir, toplantı notu ekler ve daha sonra senkronize eder. İşte burada kontrol listesi teori olmaktan çıkar ve gerçek sızıntıları önler.

Pratik bir ayrım:

• Access token: kısa ömürlü tutun ve EncryptedSharedPreferences içinde saklayın.
• Refresh token: daha sıkı koruyun ve erişimini Android Keystore ile kısıtlayın.
• Müşteri PII (isimler, telefonlar, adresler): şifreli yerel veritabanında saklayın.
• Çevrimdışı notlar ve ekler: şifreli veritabanında saklayın, dışa aktarma ve paylaşım için ekstra dikkat gösterin.

Şimdi iki özellik ekleyin ve risk değişir.

Eğer "beni hatırla" eklerseniz, refresh token hesabın tekrar açılmasının ana yolu haline gelir. Bunu bir parola gibi ele alın. Kullanıcı bazen cihaz kilidi (PIN/desen/biyometri) ile decrypt etme isteyebilirsiniz.

Çevrimdışı mod eklerseniz, artık sadece bir oturumu değil tamam bir müşteri listesini koruyorsunuz. Bu genellikle veritabanı şifrelemesi ve açık logout kuralları: yerel PII'yı sil, sadece bir sonraki giriş için gerekenleri tut ve arka plan senkronunu iptal et şeklinde kararlar gerektirir.

Gerçek cihazlarda test edin, sadece emülatörlerde değil. En azından kilit/açılma davranışını, yeniden yükleme davranışını, yedek/geri yükleme ve çoklu kullanıcı veya iş profili ayrımını doğrulayın.

Sonraki adımlar: tekrar edilebilir bir ekip alışkanlığı haline getirin

Güvenli depolama ancak bir alışkanlık olduğunda işe yarar. Ekip olarak hangi verinin nerede saklanacağına dair kısa bir politika yazın: ne Keystore'da, ne EncryptedSharedPreferences'ta, ne şifreli veritabanında olacak; ne hiçbir zaman saklanmayacak; logout'ta ne silinecek.

Bunu günlük teslimatın bir parçası yapın: definition of done, kod incelemesi ve release kontrolleri.

Hafif bir inceleyici kontrol listesi:

• Her saklanan öğe etiketlenmiş (token, anahtar materyali veya PII).
• Depolama seçimi kod yorumlarında gerekçelendirilmiş.
• Logout ve hesap değişimi doğru verileri kaldırıyor (ve sadece onları).
• Hatalar ve loglar sırları veya tam PII'yı asla yazdırmıyor.
• Birisi politikadan sorumlu ve güncel tutuyor.

Eğer ekibiniz AppMaster (appmaster.io) kullanıyorsa ve Android istemcisi için Kotlin kaynakları üretiyorsa, aynı SecureStorage sarmalayıcı yaklaşımını kullanın ki üretilen ve özel kod tutarlı bir politika izlesin.

Küçük bir proof-of-concept ile başlayın

Bir auth token ve bir PII kaydı (ör. çevrimdışı gerekli bir müşteri telefon numarası) saklayan küçük bir POC oluşturun. Sonra temiz kurulum, yükseltme, logout, kilit ekranı değişiklikleri ve uygulama verilerini temizleme senaryolarını test edin. Wipe davranışı doğru ve tekrar üretilebilir hale gelmeden genişletmeyin.