Partner API Erişimi için Passkey’ler

Passkey’ler, kullanıcının bir forma parola yazması yerine, cihazında saklanan kriptografik bir anahtar çiftiyle kimliğini kanıtlamasını sağlar. Bayiler, VAR’lar ve distribütörler genelinde API erişimini yöneten operasyon ve güvenlik liderleri için bu değişim önemlidir. Çünkü çoğu partner kimlik bilgisi zincirindeki en zayıf halkayı ortadan kaldırır: yeniden kullanılan, paylaşılan veya e-posta ile gönderilen parola.

Bu rehber, passkey’lerin pratik bir API güvenliği yaklaşımında nereye oturduğunu, kapsamlı izinler ve oturum kontrolleriyle nasıl çalıştığını ve tek başına nerede yetersiz kaldığını açıklar.

Paylaşılan parolalar neden kanala özgü bir sorundur

Yazılım kanalı firmalarında çoğu zaman aynı API ağ geçidine bağlanan birçok harici taraf bulunur. Bir bayinin entegrasyon ekibi, birkaç çalışan arasında 1 kimlik bilgisi setini paylaşabilir. Bir distribütör personel değiştirirken anahtarları döndürmeyebilir. Bir iç operasyon kullanıcısı, kolaylık için bir token’ı elektronik tabloya kopyalayabilir.

Bu alışkanlıkların her biri, "kimin erişimi var" sorusu ile "API çağrısını şu anda kim yapıyor" sorusu arasında boşluk yaratır. Bir şey ters gittiğinde — yapılmaması gereken bir veri çekimi veya kapsamı dışında kullanılan bir izin — denetim izi kişiye değil, kimlik bilgisine işaret eder.

Passkey’ler bu boşluğu kimlik doğrulama katmanında kapatır. Her passkey belirli bir cihaza ve çoğu uygulamada o cihazdaki belirli bir biyometrik doğrulamaya veya PIN’e bağlıdır. Bir passkey’i elektronik tabloya kopyalayamazsınız. Bir iş arkadaşınıza e-posta ile gönderemezsiniz. Kimlik bilgisi ve kişi, tasarım gereği birbirine bağlanır.

Passkey’ler kapsamlı API izinleriyle nasıl birlikte çalışır

Kimlik doğrulama ve yetkilendirme ayrı konulardır. Bir passkey, talepte bulunan kişinin kim olduğunu kanıtlar. Kapsamlı API izinleri ise o kişinin ne yapmasına izin verildiğini belirler. Modelin çalışması için ikisinin birlikte işlemesi gerekir.

Genel işleyiş şöyledir: kullanıcı passkey’i ile kimlik doğrular, ağ geçidi kriptografik beyanı onaylar ve oturum, kullanıcının rolüne bağlı izinlerle başlatılır — daha geniş bir yetkiyle değil. Bir bayi entegrasyon sorumlusunun sipariş verilerini okuma erişimine ihtiyacı varsa, ancak fiyatlandırma üzerinde yazma yetkisi yoksa, bu sınır kimlik doğrulama yönteminden bağımsız olarak korunur.

Kademeli erişim de aynı kalıbı izler. Belirli bir API işlemi daha yüksek risk taşıyorsa — örneğin toplu veri dışa aktarma veya yapılandırma değişikliği — etkin bir oturum içinde bile işlem izin almadan önce yeni bir passkey doğrulaması isteyebilirsiniz. Kullanıcı sürece baştan başlamaz; yalnızca yüksek yetkili işlem istendiği anda kimliğini tekrar doğrular.

Bu mimariyi nerede uygulayacağınızı değerlendirirken, API entegrasyon ağ geçidinizi doğal kontrol noktası olarak düşünün. Apivom Atlas, yazılım kanalı firmaları için geliştirilmiş bir API entegrasyon ağ geçididir. Yığınınızda her katmanın nerede duracağını belirlerken aynı değerlendirme ölçütlerini kullanın: passkey zorunluluğu, kapsamlı izinler ve oturum kontrolleri.

Erişim katmanı	Gerekli kimlik doğrulama	Tipik kullanım örneği
Standart okuma	Oturum başlangıcında passkey	Sipariş durumu, lisans sorguları
Standart yazma	Oturum başlangıcında passkey	Sipariş gönderme, kayıt güncelleme
Yüksek yetkili işlem	Oturum ortasında kademeli passkey doğrulaması	Toplu dışa aktarma, yapılandırma değişiklikleri
Yönetici işlemi	Kademeli passkey doğrulaması + onay	Rol değişiklikleri, partner ilişiği kesme

Oturum kontrolleri neyi korur

Passkey, oturum açma anını yönetir. Oturum kontrolleri ise sonrasında olan her şeyi yönetir. Oturum sınırları yoksa, geçerli bir kimlik doğrulama olayı uzun ve izlenmeyen bir pencereye dönüşebilir. Bu noktada başlangıçtaki bağlam artık geçerli olmayabilir.

Partner API bağlamında yararlı oturum kontrolleri şunlardır: yeniden kimlik doğrulama gerektiren azami oturum süresi, boşta kalan oturumları kapatan hareketsizlik zaman aşımı ve beklenmeyen konumlardan gelen istekleri işaretleyen IP veya ağ bağlama. Bunların hiçbiri passkey’lere özgü değildir, ancak passkey’ler bu kontrolleri daha pratik hale getirir. Çünkü yeniden kimlik doğrulama hızlıdır. Bir kullanıcıdan birkaç saatte bir biyometrik doğrulama ile kimliğini tekrar onaylamasını istemek makul bir beklentidir. Aynı sıklıkta parola hatırlayıp yazmasını istemek çoğu zaman değildir.

Kısa oturumlar, ele geçirilmiş bir cihazın etki alanını da azaltır. Bir dizüstü bilgisayar çalınırsa, oturum süresi dolmadan önce saldırganın dar bir zaman aralığı olur. Yeni bir passkey beyanı gerektiğinde ise çalınan cihaz kilitlenmiş veya silinmiş olabilir.

Yararlı bir denetim izi nasıl görünür

Bir partnerin çalışanı ayrıldığında, hangi API bağlantılarına sahip olduğunu, bunları en son ne zaman kullandığını ve ayrılışından sonra herhangi bir işlem olup olmadığını bilmeniz gerekir. Bir ekip tarafından paylaşılan kimlik bilgisi, bu yeniden oluşturmayı zorlaştırır. Adlandırılmış bir kullanıcıya bağlı passkey ise bunu açık hale getirir.

Passkey destekleyen bir API erişim sistemi, her kimlik doğrulama olayını beyan eden kimlikle, zaman bilgisiyle ve ardından oluşan oturumla birlikte kaydetmelidir. Bir partner bir çalışanın ilişiğini kestiğinde, o kullanıcının passkey kaydının iptal edilmesi, aynı kimlikle yapılan sonraki çağrıların kimlik doğrulama katmanında başarısız olmasına neden olmalıdır. Bu sonlanma noktası kayıtta net biçimde görünmelidir.

Bu durum iç incelemeler, müşteri denetimleri ve kontrollü erişimi göstermenizi isteyen uyumluluk süreçleri için önemlidir. Kanıt, gerçek kişilerle eşleşip eşleşmediği belirsiz kimlik bilgisi ID’leri listesi yerine, adlandırılmış bireylere ait zaman damgalı bir kayıt haline gelir. Kullanıma geçmeden önce seçtiğiniz ağ geçidinin bu biçimde kayıt ürettiğini doğrulayın.

Nerede yetersiz kalır

Passkey’ler bir kimlik doğrulama kontrolüdür. Kimlik doğrulama dışında kalan sorunları çözmez.

Rol tasarımınız zayıfsa — örneğin bir bayi bağlantısı oluşturulduğunda kapsamı kimse gözden geçirmediği için gerekenden daha geniş izinlere sahipse — passkey bunu düzeltmez. Kullanıcı temiz biçimde kimlik doğrular ve ardından aşırı erişimle işlem yapar. Bu hâlâ bir risktir.

Partner ilişiği kesme süreciniz yavaş veya gayriresmî ise, bir passkey kaydı ait olduğu kişi organizasyondan ayrıldıktan uzun süre sonra aktif kalabilir. Teknik kontrol, onu tetikleyen süreç kadar zamanında çalışır.

Yüksek yetkili işlemler için onay süreciniz zayıfsa, kademeli passkey doğrulaması yalnızca kimliği onaylar. Niyeti veya yetkiyi onaylamaz. En hassas işlemler için hâlâ bir insan kontrol noktasına ihtiyacınız vardır.

Passkey’ler ayrıca cihaz erişilebilirliğine bağlıdır. Kayıtlı cihazını kaybeden veya cihazı bozulan bir partner, yeniden kayıt yapılana kadar kimlik doğrulayamaz. Arka kapıya dönüşmeyecek kadar güvenli, ancak kritik bir anda meşru kullanıcıları dışarıda bırakmayacak kadar erişilebilir bir kurtarma yoluna ihtiyacınız vardır.

Bir araya getirmek

Partner API erişimi için pratik bir passkey geçişi, en yüksek riskli bağlantılarınızla başlar: yazma erişimi olan partnerler, yönetici izinlerine sahip operatörler ve hassas müşteri veya fiyatlandırma verilerine dokunan tüm bağlantılar. Önce bu kullanıcıları kaydedin, oturum kalıplarını gözlemleyin ve denetim kayıtlarının ihtiyacınız olan kanıtı ürettiğini doğrulayın.

Ardından standart okuma bağlantılarına genişleyin. Risk profili daha düşük olsa bile, passkey’lerin parolalara göre sürtünmeyi azaltması burada da gerçektir. Tüm partner kitlesine ulaştığınızda, ekibiniz yeni kimlik doğrulama katmanının ortaya çıkardığı rol tasarımı ve ilişik kesme boşluklarını net biçimde görmüş olur. Sırada ele alınması gereken sorunlar bunlardır.

API entegrasyon ağ geçidi kullanım senaryoları için Apivom Atlas’ı inceleyin: https://apivom.com/products/atlas