Mobil Uygulamada API Anahtarı: Gömülü LLM Anahtarı Riski
Mobil uygulamada API anahtarı saklamak LLM hizmetlerinde neden güvensizdir? Sunucu tarafı vekil, App Check, kota ve rotasyonla bu riski kalıcı olarak azaltın.
Mobil uygulamada API anahtarı saklamanın güvenli bir yolu yoktur. Uygulama paketi kullanıcının cihazına iner ve incelenebilir, bu yüzden pakete yazılan her değer bir gün çıkarılabilir. LLM hizmetlerinde bu, faturanın ve hesabın başkasının eline geçmesi demektir. Doğru tasarım, anahtarı yalnız sunucuda tutan bir vekil katman, uygulama bütünlüğü doğrulaması, kullanıcı bazlı kota ve önceden prova edilmiş bir rotasyon planıdır.
Mobil uygulamada API anahtarı neden gizli kalmaz?
Uygulama paketi; derlenmiş kod, kaynak dosyaları ve yapılandırma içerir. Bunların hepsi cihazda durur. Metin dizilerini taramak, uygulamayı çalıştırıp ağ trafiğini izlemek ya da kodu geri çevirmek, yaygın analiz araçlarıyla yapılabilen işlerdir. Karıştırma (obfuscation) çıtayı yükseltir ama anahtarı kalıcı olarak gizleyemez. Uygulamanın anahtarı kullanabilmesi için çalışma anında açık hale getirmesi gerekir.
OWASP Mobile Top 10 listesinin ilk maddesi olan M1 (Improper Credential Usage), kaynak koda ya da yapılandırma dosyasına gömülü kimlik bilgisini açık bir zafiyet göstergesi sayar. Önerileri nettir: sırları koda gömmeyin, kullanıcı kimlik bilgisini cihazda tutmayın, iptal edilebilir erişim jetonları kullanın ve anahtarları düzenli yenileyin. OpenAI de API anahtarının tarayıcı ya da mobil uygulama gibi istemci ortamlarına konmamasını, isteklerin kendi arka uç sunucunuzdan geçmesini önerir.
Sık başvurulan geçici çözümler de sonucu değiştirmez. Anahtarı şifreleyip uygulama içinde çözmek, çözme anahtarını da pakete koymayı gerektirir. Anahtarı açılışta uzak yapılandırmadan çekmek, onu yine cihazın belleğine ve ağ trafiğine taşır. Android Keystore ya da iOS Keychain kullanıcının kendi oturum bilgisini korumak için uygundur, ama tüm kullanıcılarda aynı olan bir sağlayıcı anahtarını gizlemez.
Sorun ölçekle büyür. Mağazadaki paket herkes tarafından indirilebilir. Bir kez çıkarılan anahtar paylaşılabilir, betiklerle kullanılabilir ve başka ürünlerde yeniden satılabilir. Maliyet ise uygulama sahibine kalır.
Çalınan bir LLM anahtarı hangi zararı doğurur?
Zarar anahtarın yetkisine göre büyür. Yalnız metin üretimine yetkili bir anahtar çoğunlukla maliyet üretir. Dosya yükleme, toplu iş ya da kayıtlı içerik uçlarına erişebilen bir anahtar ise kurum verisine kapı açar.
| Zarar türü | Neden oluşur | Azaltan kontrol |
|---|---|---|
| Maliyet | Kontrolsüz çağrı ve pahalı model seçimi | Sunucuda sabit model, kota, bütçe uyarısı |
| Veri | Geniş yetkili anahtar | En dar yetki, ayrı anahtar ve proje |
| Hizmet kesintisi | Kötüye kullanım nedeniyle hesabın askıya alınması | Kötüye kullanım tespiti, hızlı iptal |
| İtibar | Anahtarla zararlı içerik üretimi | Kullanıcı doğrulama, çıktı denetimi |
Maliyet saldırılarının mekaniği ve Türkçe metinde token tüketiminin etkisi için ajan maliyet patlatma yazısına bakabilirsiniz.
Sunucu tarafı vekil katman nasıl kurulur?
Vekil katman, mobil uygulama ile yapay zekâ sağlayıcısı arasına giren kendi sunucunuzdur. Uygulama isteği vekile gönderir. Vekil kullanıcıyı doğrular, politikayı uygular ve gizli anahtarla sağlayıcıyı çağırır. Anahtar istemciye hiç gitmez.
Kurulum adımları:
- Sağlayıcı anahtarını uygulamadan tamamen kaldırın. Depoyu ve derlenmiş paketi anahtar kalıntısına karşı tarayın.
- Kendi arka ucunuzda bir uç nokta açın. Anahtarı yalnız sunucu ortamındaki sır yönetim hizmetinde tutun.
- Kullanıcıyı oturumla doğrulayın. Anonim kullanıma izin veriyorsanız cihaz ve uygulama bütünlüğü kontrolü ekleyin.
- Kullanıcı ve cihaz başına istek ve token sınırı tanımlayın.
- Model adını, en yüksek çıktı uzunluğunu ve diğer maliyet belirleyen parametreleri sunucuda sabitleyin.
- Yanıt süresine ve boyutuna üst sınır koyun, her isteği kayda alın.
Beşinci adım sık atlanır. İstemci model adını seçebiliyorsa saldırgan en pahalı modeli çağırır. Kullanıcıya açık olan, yalnız sizin tanımladığınız özelliklerdir, sağlayıcının tüm API'si değil. Birden fazla uygulamanın aynı ara katmanı paylaştığı kurumsal mimari için LLM gateway yazısına bakın.
App Check ve cihaz doğrulaması ne işe yarar?
Vekil katman anahtarı korur, ama vekile gelen isteğin gerçekten sizin uygulamanızdan gelip gelmediğini tek başına bilemez. Uygulama bütünlüğü doğrulaması bu boşluğu daraltır.
Android'de Play Integrity API, isteğin Google Play'den kurulmuş gerçek uygulamanızdan ve sertifikalı bir cihazdan geldiğini doğrulamaya yarar. Doğrulama sonucu sizin arka ucunuzda değerlendirilir. Apple platformlarında App Attest ve DeviceCheck benzer işi görür. Firebase App Check bu sağlayıcıları tek bir katmanda toplar.
Firebase AI Logic belgeleri sorunu açıkça adlandırır: bir API'yi doğrudan mobil ya da web uygulamasından çağırdığınızda API yetkisiz istemcilerin kötüye kullanımına açık kalır. Firebase, 2 Kasım 2026'dan itibaren Firebase AI Logic kullanımı için App Check zorunluluğunu şart koşuyor. Tekrar oynatma koruması açıldığında her istek yeni üretilmiş, tek kullanımlık bir jeton taşımak zorundadır.
Bu araçların sınırını da bilin. Bütünlük doğrulaması kötüye kullanımı pahalı hale getirir, ama kullanıcı kimliği ve kota olmadan tek başına yeterli değildir. Ayrıca App Check'i uygulamayan eski sürümlerden gelen istekler doğrulanmamış sayılır ve zorunluluk açıldığında engellenir. Geçişi sürüm planıyla birlikte yapın.
Kota, limit ve izleme nasıl tasarlanır?
Limitleri birden fazla boyutta tanımlayın: kullanıcı, cihaz, IP adresi, saat ve gün. Tek boyut yetmez, saldırgan yükü dağıtarak sınırı aşar. Token tabanlı limit, istek sayısı limitinden daha adildir, çünkü uzun girdi ve çıktı daha çok maliyet üretir.
Sağlayıcı tarafında da proje ya da çalışma alanı bütçesi ve eşik uyarıları tanımlayın. Hesap düzeyinde bir harcama sınırı, sızan bir anahtarın bile sınırsız zarar vermesini önler. Kendi panelinizde bu sınırın istekleri durduran sert bir sınır mı yoksa yalnız uyarı mı olduğunu kontrol edin.
İzlenecek işaretler:
- Normal kullanıcı davranışından sapan istek hacmi
- Aynı hesaba bağlı çok sayıda cihaz ya da oturum
- Mesai dışında yoğunlaşan trafik
- Bütünlük doğrulamasından geçemeyen istek oranında artış
- Çok uzun girdiler ve beklenmeyen parametreler
Uyarının bir sahibi olsun ve hafta sonu da izlensin. Kötüye kullanım çoğu zaman mesai dışında başlar.
Anahtar sızınca rotasyon nasıl yapılır?
Vekil katmanın en büyük operasyonel kazancı burada görünür. Anahtar sunucudaysa yenisini üretir, sunucuya dağıtır ve eskisini iptal edersiniz. Kullanıcılar hiçbir şey fark etmez. Anahtar uygulama paketine gömülüyse durum farklıdır. İptal, o sürümü kullanan herkes için özelliği durdurur. Yeni sürüm mağaza incelemesinden geçene ve kullanıcılar güncelleyene kadar ya özellik kapalı kalır ya da çalınmış anahtar çalışmaya devam eder.
Bu nedenle sızıntı fark edildiğinde kesinti pahasına iptal edin. Ardından vekil katmanlı sürümü yayımlayın ve eski sürümler için zorunlu güncelleme mekanizmasını devreye alın. Sızıntı sonrası ilk iki saatin ayrıntılı adımları için LLM API anahtarı sızdı yazısına bakın.
Olay planında şu sorular yanıtlanmış olmalıdır:
- Anahtarı iptal etme yetkisi kimde ve mesai dışında ulaşılabilir mi?
- Yeni anahtarı üretip dağıtma adımları yazılı mı?
- Kullanım kayıtları kimin, ne zaman, hangi çağrıyı yaptığını gösteriyor mu?
- Kişisel veri etkilenirse KVKK kapsamındaki 72 saatlik bildirim değerlendirmesini kim başlatıyor?
Cihaz üstü model kullanmak sorunu çözer mi?
Modeli cihazda çalıştırmak sağlayıcı anahtarı ihtiyacını ortadan kaldırır ve kullanıcı verisini cihazda tutar. Ancak model dosyası da uygulamayla birlikte iner ve kopyalanabilir. Küçük cihaz üstü modeller her görev için yeterli olmaz, bu yüzden çoğu uygulama karma çalışır: hafif işler cihazda, ağır işler vekil katman üzerinden.
Hangi verinin hangi tarafta işleneceğini veri sınıflandırmasına göre belirleyin. Hassas veri cihazda kalabilir, ama hangi verinin sunucuya gittiği aydınlatma metninde açıkça anlatılmalıdır. Model dosyasına ticari değer atfediyorsanız lisans ve kopyalama riskini ayrıca değerlendirin.
Derleme hattında hangi kontroller olmalı?
Hatayı mağazaya ulaşmadan yakalamak en ucuz yoldur. Geliştirme sırasında konulan bir test anahtarı üretim sürümüne kolayca geçer.
- Her birleştirme isteğinde depo için sır taraması çalıştırın.
- Derlenmiş paketi yayımlamadan önce bilinen anahtar desenlerine karşı tarayın.
- Sağlayıcı anahtarlarını yalnız sunucu tarafı sır deposunda tutun, mobil yapılandırma dosyalarına hiç yazmayın.
- Hata ayıklama jetonlarını ve test yapılandırmalarını üretim derlemesine almayın.
Bu kontrolleri birleştirme politikasına bağlamak için AI üretimi kod için CI güvenlik kapısı yazısındaki kapı tasarımı kullanılabilir.
Sık Sorulan Sorular
Mobil uygulamaya gömülü API anahtarı neden güvensizdir?
Uygulama paketi kullanıcının cihazına iner ve orada incelenebilir. Koda, kaynak dosyasına ya da yapılandırmaya yazılan anahtar, karıştırma uygulansa bile çıkarılabilir. OWASP Mobile Top 10 listesinin ilk maddesi bu sorunu ele alır, OpenAI de anahtarın mobil uygulamaya konmamasını açıkça önerir. Sağlayıcı anahtarı yalnız sizin kontrol ettiğiniz sunucuda durmalıdır.
Sunucu tarafı vekil katman nasıl çalışır?
Uygulama yapay zekâ sağlayıcısını doğrudan çağırmaz. İsteği kendi sunucunuza gönderir. Sunucu kullanıcıyı ve uygulama bütünlüğünü doğrular, kotayı ve politikayı uygular, ardından gizli anahtarla sağlayıcıyı çağırır. Model adı ve maliyet belirleyen parametreler sunucuda sabittir. Anahtar istemciye hiç gitmediği için değiştirmek yeni uygulama sürümü gerektirmez.
App Check gibi uygulama doğrulama araçları anahtarı korur mu?
Anahtarı korumaz, isteğin gerçek uygulamanızdan geldiğini doğrulamaya yardım eder. Firebase App Check, Android'de Play Integrity, Apple platformlarında App Attest ya da DeviceCheck kullanır. Firebase AI Logic için App Check zorunluluğu 2 Kasım 2026'da başlıyor. Bu doğrulama kötüye kullanımı zorlaştırır, ama kota ve kullanıcı kimliği olmadan tek başına yeterli değildir.
Anahtar sızarsa ilk ne yapılmalı?
Anahtarı sağlayıcı konsolunda hemen iptal edin, kullanım kayıtlarını inceleyin ve harcama limitini daraltın. Anahtar uygulama paketine gömülüyse iptal, o sürümü kullanan herkes için özelliği durdurur. Bu yüzden vekil katmana geçen yeni sürümü yayımlayın, eski sürümler için zorunlu güncelleme planlayın. Kişisel veri etkilendiyse KVKK bildirim değerlendirmesini de başlatın.
Kaynaklar
İlgili Yazılar
Bu yazı, Türkiye odaklı Yapay Zekâ Güvenliği Rehberi'nin destek makalelerinden biridir.