Mobil uygulama güvenliği, yalnızca giriş ekranına parola koyarak sağlanmaz. Kurumsal uygulamalarda kimlik doğrulama, oturum yönetimi, cihaz güveni, rol bazlı erişim ve denetim kayıtları birlikte ele alınmalıdır. Özellikle saha ekipleri, bayi ağları, distribütörler ya da kurum içi personel tarafından kullanılan mobil uygulamalarda tek bir zayıf halka ciddi veri sızıntılarına yol açabilir. Bir çalışanın telefonu kaybolduğunda, eski bir personelin hesabı kapatılmadığında ya da API seviyesinde yetki kontrolleri eksik bırakıldığında risk doğrudan iş süreçlerine yansır.
Bu rehberde, mobil uygulama güvenliği odağında SSO, MFA ve rol bazlı erişim mimarisini ele alacağız. Amacımız, teknik açıdan doğru, işletme tarafında ise sürdürülebilir bir çerçeve sunmak. Anlatım boyunca OAuth 2.0, OpenID Connect, kısa ömürlü token, refresh token rotasyonu, cihaz bağlama ve API yetkilendirme gibi pratik başlıklara da değineceğiz.
Mobil uygulama güvenliği neden giriş ekranından ibaret değildir?
Kurumsal senaryolarda saldırı yüzeyi yalnızca mobil uygulamanın kendisiyle sınırlı değildir. API katmanı, kimlik sağlayıcı, cihaz depolaması, ağ trafiği ve yönetim paneli de bu zincirin parçalarıdır. Örneğin satış ekibinin kullandığı bir B2B sipariş uygulamasını düşünelim. Uygulamada 3 farklı profil olsun: bölge müdürü, satış temsilcisi ve bayi kullanıcısı. Giriş yapan herkes aynı API uç noktalarına erişebiliyor, fakat ekranda bazı butonlar gizleniyorsa bu güvenlik anlamına gelmez. Kullanıcı, bir proxy aracıyla isteği doğrudan gönderip erişmemesi gereken kaynağa ulaşabilir.
İyi bir tasarımda kontrol katmanları birbirinden ayrılır. Kim olduğunuz doğrulanır. Neye erişebileceğiniz belirlenir. Hangi şartlarda erişeceğiniz değerlendirilir. Ardından tüm kritik işlemler kayıt altına alınır. Buradaki temel prensip nettir: istemciye değil, sunucuya güvenilir.
En sık karşılaşılan 4 hata şunlardır:
- Token veya kullanıcı bilgisini cihazda düz metin olarak saklamak
- Rol kontrolünü yalnızca mobil arayüzde yapmak
- Uzun ömürlü oturumları iptal mekanizması olmadan açık bırakmak
- Eski çalışan hesaplarını merkezi dizinden bağımsız yönetmek
Kurumsal ölçekte güvenli giriş için kimlik doğrulama ile yetkilendirme birbirinden ayrılmalıdır. Bu ayrım, ileride SSO ve MFA eklemek gerektiğinde ciddi bir esneklik sağlar.
SSO mobil uygulamalarda nasıl çalışır?
SSO, yani Single Sign-On, kullanıcının tek bir kurumsal kimlikle birden fazla uygulamaya erişmesini sağlar. Mobil tarafta en sağlıklı yaklaşım, uygulamanın kullanıcı parolasını doğrudan toplaması yerine kurumsal kimlik sağlayıcıya yönlendirmesidir. Burada yaygın olarak kullanılan standartlar OAuth 2.0 ve OpenID Connect'tir. Kurumlar çoğunlukla Microsoft Entra ID, Okta, Keycloak ya da benzeri bir kimlik sağlayıcı kullanır.
Mobil uygulamada önerilen akış genellikle Authorization Code Flow with PKCE olur. PKCE, özellikle public client olarak kabul edilen mobil uygulamalarda kod ele geçirme riskini azaltır. Kullanıcı uygulamada “Giriş Yap” dediğinde, gömülü webview yerine sistem tarayıcısı veya platformun güvenli oturum bileşeni açılır. Android tarafında Custom Tabs, iOS tarafında ise ASWebAuthenticationSession benzeri yaklaşımlar tercih edilir. Bu yöntem, kimlik bilgilerinin uygulamanın içine gömülmemesi açısından önem taşır.
Örnek SSO akışı
- Kullanıcı mobil uygulamada kurumsal giriş seçeneğine dokunur.
- Uygulama kimlik sağlayıcıya PKCE ile yetkilendirme isteği gönderir.
- Kullanıcı kurumsal hesabıyla giriş yapar.
- Kimlik sağlayıcı uygulamaya authorization code döner.
- Uygulama bu kodu access token ve ID token ile değiştirir.
- API çağrıları access token ile yapılır.
Burada dikkat edilmesi gereken nokta, token doğrulamanın yalnızca istemci tarafında bırakılmamasıdır. API tarafı; issuer, audience, expiration ve imza doğrulamasını yapmalıdır. Access token ömrü çoğu mimaride 5 ila 15 dakika arasında tutulur. Refresh token kullanılıyorsa rotasyon uygulanmalı, tekrar kullanım algılanırsa oturum iptal edilmelidir.
SSO'nun kurumsal değeri yalnızca kullanıcı deneyimiyle sınırlı değildir. Personel işten ayrıldığında dizin hesabı kapandığı anda mobil erişim de sonlanır. Ayrı ayrı hesap kapatma yükü azalır. Denetim süreçleri de sadeleşir.
MFA ne zaman zorunlu olmalı, ne zaman risk bazlı çalışmalı?
MFA, yani çok faktörlü kimlik doğrulama, parolaya ek bir doğrulama katmanı ekler. Mobil uygulama güvenliği açısından MFA; özellikle uzaktan erişim, hassas veri görüntüleme, finansal işlem onayı ve yönetici yetkileri için kritik önem taşır. Yine de her ekranda aynı sertliği uygulamak doğru olmaz. Güvenlik ile kullanılabilirlik arasında dengeli bir karar vermek gerekir.
Pratik bir sınıflandırma yapılabilir. Örneğin yalnızca duyuru görüntüleyen bir kurum içi uygulama ile müşteri verisi indiren satış uygulaması aynı seviyede değerlendirilmez. Yönetici paneline mobil erişim varsa MFA varsayılan olmalıdır. Kişisel cihazlardan girişte risk daha yüksektir. Kayıtlı ve uyumlu cihazlardan, düşük riskli ağlardan yapılan erişimlerde ise adım bazlı doğrulama tercih edilebilir.
Kurumsal MFA yöntemleri
- Authenticator uygulaması ile TOTP kodu
- Push onayı
- FIDO2 veya passkey tabanlı doğrulama
- SMS kodu, yalnızca geçiş çözümü olarak
SMS hâlâ birçok sistemde kullanılıyor, ancak SIM değişimi ve sosyal mühendislik riskleri nedeniyle daha güçlü yöntemlerin gerisinde kalır. 2024 itibarıyla birçok kurum passkey ve phishing-resistant MFA yaklaşımlarına yöneliyor. Uygulamanız çalışanlar, bayi kullanıcıları ve dış partnerleri aynı yapıda buluşturuyorsa, en azından ayrı risk politikaları tanımlanmalıdır.
Somut bir senaryo düşünelim. Depo yöneticisi stok düzeltme işlemi yapabiliyor. İşlemin finansal etkisi yüksek. Kullanıcı sabah 09:10'da kurumsal cihazdan giriş yapmış olsa bile, 50.000 TL üzeri sipariş değişikliğinde yeniden MFA istemek mantıklıdır. Buna step-up authentication denir. Yani tek seferlik oturum açmak yerine işlem bazlı güvenlik uygulanır.
Rol bazlı erişim nasıl tasarlanmalı?
Rol bazlı erişim kontrolü, yani RBAC, kullanıcının görevine göre yetkilerini sınırlar. Ancak birçok projede roller fazla geniş tanımlanır. “Admin”, “User”, “Manager” gibi 3 etiketle başlayan yapı kısa sürede karmaşık hale gelir. Daha sağlıklı yaklaşım, önce iş yetkilerini listelemek, ardından bunları rollere bağlamaktır.
Örneğin bir servis operasyon uygulamasında şu yetkiler olabilir: iş emri görüntüleme, iş emri atama, fiyat güncelleme, müşteri notu görme, rapor dışa aktarma. Her yetki ayrı bir permission olarak ele alınır. Roller ise bu izinlerin paketlenmiş halidir. Saha teknisyeni 2 izne sahip olabilir, operasyon yöneticisi 5 izne sahip olabilir. Böylece yeni bir görev çıktığında tüm sistemi bozmadan yalnızca ilgili permission eklenir.
RBAC için pratik model
{
"user_id": "u_1842",
"roles": ["field_technician"],
"permissions": [
"workorder.read",
"workorder.update_own"
],
"scope": {
"region": "TR-34",
"tenant_id": "tenant_9"
}
}Buradaki scope alanı önemlidir. Çünkü yalnızca “hangi işlem” değil, “hangi veri kümesi üzerinde” sorusu da yanıtlanmalıdır. Çok şubeli, çok şirketli veya bayi yapılı sistemlerde tenant bazlı izolasyon zorunludur. Aksi halde kullanıcı doğru role sahip olsa bile başka şirketin verisini görebilir.
Rol bazlı modelin yanında bazı durumlarda ABAC, yani öznitelik tabanlı erişim de gerekir. Örneğin kullanıcı sadece kendi bölgesindeki kayıtları görebilsin, gece 22:00 sonrası fiyat değişikliği yapamasın, onaysız cihazdan rapor indiremeyin. Bu kontroller API katmanında uygulanmalıdır. Mobil arayüzde buton gizlemek yalnızca kullanıcı deneyimi sağlar; güvenlik sağlamaz.
Token, oturum ve cihaz güveni nasıl yönetilmeli?
Kurumsal mobil uygulamalarda en kritik teknik başlıklardan biri oturum yönetimidir. Access token kısa ömürlü olmalıdır. 10 dakika iyi bir referans olabilir, ancak nihai süre risk seviyesine göre belirlenir. Refresh token daha uzun yaşayabilir; buna rağmen cihaz bazlı bağlama, rotasyon ve sunucu tarafında iptal listesi gibi kontroller eklenmelidir.
Token saklama yeri de önemlidir. Android Keystore ve iOS Keychain gibi güvenli depolama alanları kullanılmalıdır. Uygulama içine düz SQLite kayıtları bırakmak, loglara token yazmak veya panoya kopyalamak ciddi hatalardır. Hassas uygulamalarda cihaz root veya jailbreak kontrolü, sertifika sabitleme ve cihaz bütünlüğü sinyalleri de değerlendirilebilir. Bunlar tek başına kesin koruma sağlamaz, ancak savunmayı katmanlı hale getirir.
Oturum güvenliği için kontrol listesi
- Access token süresi kısa tutulur: örneğin 5-15 dakika
- Refresh token rotasyonu aktif edilir
- Çıkış yapıldığında sunucu tarafında oturum iptal edilir
- Parola değişimi veya personel çıkışında tüm cihazlar düşürülür
- API isteklerinde token audience ve scope doğrulanır
Gerçek hayatta en çok ihmal edilen konu, merkezi oturum sonlandırmadır. Bir personelin işten ayrıldığı gün hesabı kapatılır ama mobil uygulama 30 gün daha çalışmaya devam eder. Teknik olarak sorun yokmuş gibi görünebilir. Güvenlik açısından ise bu büyük bir açıktır.
API yetkilendirmesi ve mobil istemci sınırları
Mobil uygulama güvenliği konuşulurken odak kolayca istemciye kayar. Oysa asıl kararlar API katmanında verilmelidir. Her endpoint için gerekli scope ve permission tanımlanmalı, her istek sunucuda doğrulanmalıdır. Örneğin GET /orders/7842 isteğinde yalnızca token varlığına bakmak yeterli değildir. Kullanıcının bu siparişi görme hakkı var mı, sipariş kendi tenant'ına mı ait, bölge kapsamı uygun mu, işlem loglanmalı mı; tüm bu sorular da değerlendirilmelidir.
Burada BFF, yani Backend for Frontend deseni faydalı olabilir. Mobil uygulama doğrudan tüm mikroservislerle konuşmak yerine, mobil ihtiyaçlara göre şekillenmiş kontrollü bir ara katmana bağlanır. Bu yapı token yönetimini sadeleştirir, istemciye fazla veri sızmasını önler ve yetki kararlarını merkezileştirir. Özellikle 20'den fazla endpoint kullanan kurumsal uygulamalarda bakım kolaylığı belirgin hale gelir.
Ek olarak loglama ve gözlemlenebilirlik de unutulmamalıdır. Başarısız MFA denemeleri, sıra dışı cihaz değişiklikleri, kısa sürede farklı şehirlerden gelen girişler, admin yetkisi atamaları izlenmelidir. Buradaki amaç yalnızca olay sonrası inceleme yapmak değil, anomali tespiti de yapabilmektir.
Kurumsal bir geçiş planı nasıl kurgulanır?
Mevcutta e-posta ve parola ile çalışan bir mobil uygulamayı SSO, MFA ve gelişmiş yetkilendirmeye geçirmek tek sprintte yapılacak bir iş değildir. Aşamalı ilerlemek daha güvenlidir. İlk aşamada mevcut kullanıcı havuzu ile kurumsal dizin eşleştirilir. Ardından yeni girişler SSO'ya alınır, eski yöntem kontrollü biçimde kapatılır. Paralelde API seviyesinde permission kontrolleri devreye alınır.
Tipik bir geçiş planı 6 ila 10 haftaya yayılabilir. İlk 2 haftada keşif ve risk analizi yapılır. Sonraki birkaç haftada kimlik sağlayıcı entegrasyonu, test ortamı, token akışları ve mobil istemci güncellemeleri hazırlanır. Son fazda ise pilot grup açılır. Örneğin 30 kullanıcı ile başlanır. Hata oranı, destek talepleri ve MFA tamamlama başarısı izlenir. Ardından tüm organizasyona yayılır.
Başarı ölçütleri hem teknik hem de operasyonel olmalıdır. Kaç kullanıcının SSO'ya geçtiği tek başına yeterli değildir. Eski hesapların kapanma süresi, başarısız yetki denemeleri, kayıp cihaz senaryosunda oturum iptal süresi, destek ekibine gelen giriş sorunu sayısı gibi ölçümler daha anlamlıdır.
Kapanışta ana çerçeve netleşiyor: mobil uygulama güvenliği, iyi tasarlanmış bir giriş deneyimi ile güçlü API yetkilendirmesinin birleşimidir. SSO merkezi kontrol sağlar. MFA, hesabın ele geçirilmesini zorlaştırır. Rol bazlı erişim ise kullanıcının yalnızca ihtiyaç duyduğu veriye ulaşmasını mümkün kılar. Kurumsal ölçekte güvenilir çözüm, bu parçaları tek tek değil, aynı güvenlik mimarisinin katmanları olarak ele aldığınızda ortaya çıkar.
