Çalışma mantığı
Anahtar kaydı ve sonraki doğrulama istekleri farklı aşamalardır. Sunucu Apple'ın tarif ettiği doğrulamayı yapmalı, uygulama kimliği ve isteğin bağını kontrol etmelidir. Desteklenmeyen ortam için açık davranış gerekir.
Uygulamada nasıl değerlendirilir?
Yeni cihaz kaydından sonra hassas işlem isteklerini aynı kayıt ilişkisine bağlayın. Uygulamanın yeniden kurulmasını anahtar yaşam döngüsünde hesaba katın.
Sınırlar ve yaygın hatalar
App Attest kullanıcı kimliğini veya işlem niyetini doğrulamaz. Geçerli uygulama içinde kötüye kullanım yine mümkündür.
Kontrol listesi
- Sunucu doğrulamasını uygulayın
- Yeniden kurulum yolunu test edin
- Hizmet hatasını ayrı yönetin
Karar verirken
App Attest'i tek güven kararı yerine, işlem yetkilendirmesini besleyen bir kanıt katmanı olarak kullanın.
Uygulama örneği ile kullanıcı hesabını ayırmak
App Attest akışında oluşturulan anahtar ve doğrulama kaydı, hesap yetkisinin kendisi değildir. Sunucu uygulama örneğiyle kullanıcı arasındaki ilişkiyi kendi kayıt ve oturum süreci içinde kurmalıdır. Aynı cihazdaki hesap değişimi ayrıca ele alınır.
Hizmet desteği veya doğrulama başarısızlığında ne yapılacağı belirlenmelidir. Ağ hatasını doğrudan jailbreak sonucu gibi yorumlamak doğru değildir. Kritik işleme bağlanan assertion ve sunucu doğrulama adımları, yalnızca ilk kayıt çağrısının başarılı olmasından daha geniş bir kapsam oluşturur.
İlgili rehberler: App Attest sunucu doğrulaması, Güvenli cihaz kayıt akışı.
Kayıt ile günlük istekleri ayırmak
App Attest entegrasyonunda başlangıçtaki anahtar doğrulaması ve sonraki assertion doğrulamaları ayrı amaçlar taşır. Sunucu, doğrulanan uygulama örneğinin kaydını yaşam döngüsü boyunca yönetir. Cihaz veya uygulama örneği değiştiğinde önceki ilişki otomatik doğru kabul edilmez.
| Durum | Tasarım sorusu |
|---|---|
| İlk kayıt | Beklenen uygulama kimliği ve challenge nasıl doğrulanıyor? |
| Hassas istek | Assertion hangi iş verisine bağlı ve sunucuda nasıl denetleniyor? |
| Yeniden kurulum | Yeni uygulama örneği güvenli biçimde nasıl kaydediliyor? |
| Hizmet hatası | Hangi işlem erteleniyor, hangi düşük riskli erişim sürüyor? |
| Hesap değişimi | Yerel anahtarla kullanıcı yetkisi arasındaki ilişki nasıl yenileniyor? |
Bu sorulara verilen yanıt, platform kanıtını uygulamanın gerçek güven modeline bağlar. Sadece istemci tarafındaki başarılı API çağrısı yeterli değildir. Sunucu doğrulama kodunun hatalı koşulları reddetmesi ve normal tekrar akışını doğru yönetmesi de test edilmelidir.
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.