AI API Ağ Geçitleri için BYOK Sağlayıcı Anahtarı Ekleme: Trafiği Yönlendirmeden Önce Müşteri Kimlik Bilgilerini Doğrulayın

BYOK'a katılım işlemini, yukarı akış API anahtarını kabul eden ve yönlendirmeyi hemen etkinleştiren bir metin kutusu olarak değerlendirmeyin. Üretim AI API ağ geçidinde, müşteri tarafından sağlanan kimlik bilgilerinin bir kontrol düzlemi iş akışına ihtiyacı vardır: sağlayıcı bağlamasını toplayın, anahtarı karantinaya alın, sağlayıcıya özel araştırmaları çalıştırın, bir yetenek matrisi oluşturun ve ancak bundan sonra kimlik bilgilerini kiracı yönlendirme politikasına ekleyin.

Okuyucu sorunu işlevseldir: Müşteri geçerli görünen bir OpenAI, Anthropic, Gemini veya Azure OpenAI kimlik bilgisi yapıştırır, ancak anahtarın yanlış projeye ait olması, model erişiminin olmaması, seçilen uç noktayı arayamaması, kotanın zayıf olması veya faturalandırma ve mutabakat için gereken kullanım verilerini göstermemesi nedeniyle ilk gerçek istek başarısız olur. Ağ geçidinin, müşteri trafiği bunlara bağlı olmadan önce bu kısıtlamaları keşfetmesi gerekir.

BYOK kimlik bilgisini durum bilgisi olan bir kontrol düzlemi nesnesi olarak tasarlayın

BYOK kimlik bilgisi, uygulamaların kullandığı ağ geçidi tarafından verilen anahtardan ayrı olmalıdır. Uygulamalar, ağ geçidini sabit bir sanal anahtarla çağırırken, ağ geçidi de kiracıyı, ürün planını, model profilini ve ilkesini doğrulanmış bir yukarı akış kimlik bilgisine eşlemelidir. Bu ayırma, müşteri bir yukarı akış anahtarını değiştirdiğinde, sağlayıcı projelerini değiştirdiğinde veya belirli bir model yeteneğini kaybettiğinde uygulama entegrasyonunu istikrarlı tutar.

En azından yukarı akış kimlik bilgilerini şu durumlarla modelleyin:

• gönderildi: kontrol düzlemi tarafından alındı ancak henüz kullanılamaz.
• karantinaya alındı: kasada depolanıyor ve yoklamalar çalışırken canlı trafikten engelleniyor.
• doğrulandı:, doğrulamayı geçen belirli yeteneklere izin verildi.
• bozulmuş: trafiğin bir kısmı için hâlâ kullanılabilir, ancak bir veya daha fazla özellik, kota sinyali veya kullanım raporlama beklentileri başarısız oldu.
• askıya alındı: kimlik doğrulama, izin, kota, faturalandırma veya politika hatalarından sonra geçici olarak engellendi.
• rotation-required: hâlâ ağ geçidi tarafından biliniyor, ancak üretimde kullanıma devam edilmeden önce değiştirilmesi gerekiyor.
• iptal edildi: yönlendirmeden kaldırıldı ve artık yedek olarak kabul edilmiyor.

Bu durum makinesi, multi-provider LLM API ağ geçidi oluşturan ekipler için önemlidir, çünkü tek bir normalleştirilmiş "geçerli anahtar" işareti, sağlayıcıya özgü davranışı gizler. Ağ geçidinin, her kiracı için hangi uç noktaların, modellerin, bölgelerin, yöntemlerin ve raporlama modlarının güvenli olduğunu bilmesi gerekir.

Gizli bilgiyi sormadan önce sağlayıcı bağlama alanlarını toplayın

İlk katılım formunda, gizli anahtarın öncesinde veya yanında gizli olmayan yönlendirme bağlamı da sorulmalıdır. Bu bağlam, belirsiz araştırmaları önler ve daha iyi hata mesajları üretir.

OpenAI

Hedeflenen organizasyon ve projeyi, talep edilen model profillerini ve anahtarın kullanıcı anahtarı mı yoksa hizmet hesabı anahtarı mı olduğunu toplayın. OpenAI kuruluş ve proje düzeylerinde rol tabanlı erişim kontrolünü belgelediğinden ve API izinler bu model tarafından yönetildiğinden, yararlı bir doğrulayıcının proje bağlamasını ve izinleri kontrol etmesi gerekir. Model listeleme gibi bir çağrı, ilgili anahtar ve rolden model okuma izinleri gerektirebilir.

Hizmet hesapları için kapsamları bağımsız otorite olarak değil, kısıtlama olarak değerlendirin. OpenAI hizmet hesabı anahtar kapsamları, hizmet hesabının yapabileceklerini sınırlayabilir ancak atanan proje rolü dışında izin veremezler. Pratik anlamda, bir anahtar dar kapsamlı görünebilir ve proje rolü istenen modele veya uç noktaya izin vermediğinden yine de başarısız olabilir.

Anthropic

Müşterinin birden fazla çalışma alanı varsa veya kimliğe bağlı akışlar kullanıyorsa amaçlanan çalışma alanı kimliğini toplayın. Anthropic çalışma alanları; üyeleri, hizmet hesaplarını, API anahtarlarını ve kaynak sınırlarını içerebilir ve merkezi faturalandırma ve yönetim kapsamında projeleri, ortamları veya ekipleri ayırmaya yöneliktir.

Doğrulayıcı, bir isteğin anthropic-workspace-id başlığına ihtiyaç duyup duymadığını korumalıdır. Anthropic belgeleri, kimliğe bağlı veya çoklu çalışma alanı API anahtar akışlarının bu başlığı gerektirebileceğini söylüyor. Ayrıca, çalışma zamanı çalışma alanı kapsamlı bir anahtarın kuruluş düzeyindeki kaynak sınırlarını denetleyebileceğini varsaymaktan kaçının. Çalışma alanı kapsamlı anahtarlar, çalışma alanı hız sınırı incelemesi gibi kuruluş düzeyindeki bazı Yönetici API işlemleri için geçerli değildir.

Gemini

Anahtarın AI Studio'dan mı yoksa bir Google Cloud projesinden mi geldiğini, amaçlanan proje içeriğini, izin verilen API'leri ve müşterinin beklediği kısıtlamaları toplayın. Google'in Gemini API anahtar belgeleri, her Gemini API anahtarının bir Google Cloud projesiyle ilişkili olduğunu ve yeni AI Studio anahtarlarının kimlik doğrulama anahtarları olarak oluşturulduğunu söylüyor. Ayrıca, güvenli olmayan kısıtlanmamış anahtarlardan uzaklaşmanın bir parçası olarak, kısıtlanmamış standart anahtarların Gemini API tarafından reddedildiğini de söylüyor.

İlk katılım kullanıcı arayüzü, müşterileri araştırma geçinceye kadar kısıtlamaları gevşetmeye teşvik etmek yerine, güvenli olmayan, kısıtlanmamış standart anahtarları işaretlemelidir. Google Bulut API-anahtar kılavuzu API kısıtlamalarını, sorgu parametrelerinde anahtarlardan kaçınılmasını, gereksiz anahtarların silinmesini ve anahtarların depolara kaydedilmemesini önerir. Gemini kimlik doğrulama anahtarları özel bir üretim istisnasıdır çünkü Gemini API, Google Bulut proje kaynakları oluşturmaz, ancak doğrulayıcının yine de anahtar türünü ve kısıtlama durumunu kaydetmesi gerekir.

Azure OpenAI

Müşteri sağlayabilirse uç noktayı, dağıtım adını, API sürümü, bölgeyi ve abonelik içeriğini toplayın. Azure OpenAI, müşteri tarafından oluşturulan dağıtımlar aracılığıyla yönlendirilir; dolayısıyla genel bir model adı yeterli değildir. İstenen dağıtım adı eksikken, farklı bir bölgedeyse veya ağ geçidinin beklemediği bir model sürümüne bağlıysa, kaynak için bir anahtar geçerli olabilir.

Azure OpenAI kotası, TPM birimlerinde abonelik, bölge, model ve dağıtım türü başına atanır. Atanan TPM, dağıtım hızı sınırlarına eşlenirken RPM de uygulanır. Çalışma zamanı yanıtları, kalan istekler, kalan belirteçler ve ms'den sonra yeniden deneme gibi yararlı hız sınırı başlıklarını ortaya çıkarabilir. Araştırmalar ve çalışma zamanı izleme sırasında bu sinyalleri yakalayın.

Doğrulamayı katmanlar halinde çalıştır

İyi bir ön kontrol paketi ucuz ve düşük riskli olarak başlar, ardından yalnızca müşteri onay verdiğinde minimum düzeyde faturalandırılabilir bir araştırma kullanır. Bazı sağlayıcılar, çalışma zamanı anahtarları aracılığıyla yeterince iç gözlem yapmamaktadır; bu nedenle, başarılı bir ilk katılım sonucunun yalnızca başarılı veya başarısız olması değil, bir güven düzeyi de içermesi gerekir.

1. Statik kontroller

Sağlayıcıyı aramadan önce bariz biçimlendirme sorunlarını, eksik alanları, uyumsuz uç nokta şekillerini, desteklenmeyen bölgeleri ve hatalı biçimlendirilmiş dağıtım adlarını doğrulayın. Statik kontroller hiçbir zaman ham sırrı günlüğe kaydetmemelidir. Bunun yerine parmak izini, oluşturma kaynağını, kiracı kimliğini, sağlayıcıyı ve kasa referansını saklayın.

Örnekler:

• Azure uç noktası, beklenen kaynak URL modeliyle eşleşmiyor.
• İstenen model profili Azure OpenAI.
ile eşleşse bile Azure dağıtım adı boş Çoklu çalışma alanı ekleme yolu için
• Anthropic çalışma alanı kimliği eksik.
• Gemini anahtarı, kısıtlamalar gerektiğinde kısıtlamasız standart anahtar olarak işaretlenir.
• İstenen profil, görüntü oluşturmayı içeriyor ancak sağlayıcı bağdaştırıcısı, BYOK kimlik bilgileri için bu yöntemi desteklemiyor.

2. Düşük riskli okuma araştırmaları

Sağlayıcının izin verdiği durumlarda salt okunur araştırmaları kullanın. Bir model listesi çağrısı, dağıtım meta veri kontrolü veya hesap yeteneği uç noktası, model çıktısı oluşturmadan kimlik doğrulamayı, proje bağlamayı ve izin hatalarını ortaya çıkarabilir. Hem normalleştirilmiş sonuçları hem de ham sağlayıcı durum kodlarını kaydedin.

Önerilen normalleştirilmiş sonuçlar şunları içerir:

• auth_failed: geçersiz, iptal edilmiş, süresi dolmuş veya devre dışı bırakılmış kimlik bilgisi.
• wrong_project_or_workspace: geçerli anahtar, ancak amaçlanan projeye veya çalışma alanına bağlı değil.
• permission_denied: kimliği doğrulanmış ancak uç nokta, model veya yönetici izni eksik.
• model_unavailable: anahtar çalışıyor, istenen model veya dağıtım çalışmıyor.
• quota_unknown: çalışma zamanı çalışıyor ancak kota incelenemiyor.
• usage_reporting_unavailable: ağ geçidi, sağlanan kimlik bilgileri aracılığıyla sağlayıcı tarafı kullanımını uzlaştıramıyor.

3. Minimal çıkarım araştırmaları

İstenen her model profili için genellikle en az bir gerçek çıkarım araştırması gereklidir, çünkü bir modeli listelemek, onu çalıştırmasına izin verilmesiyle aynı şey değildir. Açıkça müşteri izni isteyin, küçük bir araştırma bütçesi belirleyin ve gerekli yeteneği kullanan en ucuz uç noktayı kullanın.

Araştırmaları belirleyici ve sıkıcı tutun. Metin profili için düşük çıktı sınırına sahip kısa bir istem gönderin. Akış için, sağlayıcının beklenen yerde akış olaylarını ve son kullanım meta verilerini döndürdüğünü doğrulayın. Araç özellikli profiller için sentetik bir araç tanımı kullanın ve sağlayıcının araç şemasını kabul edip etmediğini doğrulayın. Sağlayıcı ve politika izin veriyorsa, görüş için bilinen küçük bir test görüntüsü kullanın. Hassas müşteri verilerini depolayan veya işletmeye özel istemler gerektiren araştırmalardan kaçının.

4. Negatif testler

Negatif testler, politika sınırlarının gerçek olduğunu kanıtlar. Kiracının yalnızca tanımlanmış bir model profilini kullanmasına izin veriliyorsa, doğrulayıcının açıkça izin verilmeyen bir modeli, uç noktayı, aracı veya bölgeyi denemesi ve sağlayıcı görmeden ağ geçidinin bunu engellediğini doğrulaması gerekir. Bunlar, sağlayıcının kötüye kullanımı testleri değil, ağ geçidi politikası testleridir.

Bu özellikle AI API müşteri temel hazırlığının aşağı yönlü anahtarları otomatik olarak oluşturduğu bayi ve SaaS kurulumları için önemlidir. Müşteri tarafından sağlanan bir yukarı akış anahtarı, daha geniş sağlayıcı izinlerine sahip olduğu için kiracının ağ geçidi politikasını atlamamalıdır.

Boole değil, yetenek matrisi depolayın

İlk katılımın çıktısı, kimlik bilgisi sürümüne eklenen bir yetenek matrisi olmalıdır. Bu matris, yönlendirme, destek, faturalandırma ve müşteriye yönelik durum sayfaları tarafından sorgulanabilir olmalıdır.

Pratik bir matris şunları içerir:

• Sağlayıcı, kimlik bilgisi sürümü, kasa referansı, kiracı ve ortam.
• Mümkün olduğu durumlarda kuruluş, proje, çalışma alanı, uç nokta, bölge veya dağıtım bağlaması gözlemlendi.
• Desteklenen uç noktalar: sohbet, yanıtlar, mesajlar, yerleştirmeler, gruplar, gerçek zamanlı, resimler, ses veya sağlayıcıya özgü eşdeğerler.
• Desteklenen modeller ve dağıtım adları.
• Desteklenen istek özellikleri: akış, araçlar, JSON modu, yapılandırılmış çıktı, görüntü, ses, istemi önbelleğe alma, toplu işler.
• Gözlemlenen hız sınırı başlıkları ve yeniden deneme başlıkları.
• Bilinen kota kaynağı: yönetici API, çalışma zamanı üstbilgileri, müşteri tarafından bildirilen veya bilinmiyor.
• Kullanım raporlama modu: sağlayıcı raporu mevcut, yalnızca ağ geçidi ölçümü, kısmi mutabakat veya desteklenmiyor.
• Doğrulama güvenirliği: derin, yüzeysel, yalnızca çalışma zamanı veya müşteri tarafından beyan edilen.
• Son başarılı araştırma, son başarısız araştırma ve ham hata kanıtı.

Yönlendirme bu matrisi kullanmalıdır. Matris, anahtarın metin çıkarımını desteklediğini ancak toplu işleri desteklemediğini söylüyorsa, ağ geçidinin metin trafiğine izin vermesi ve müşteriye yönelik net bir mesajla toplu trafiği reddetmesi gerekir. Kota denetlenemiyor ancak çalışma zamanı araştırmaları çalışıyorsa, ağ geçidinin tam kapasite görünürlüğüne sahip olduğunu varsaymak yerine, kimlik bilgisi sınırlı bir güvenle doğrulanmış olarak işaretlenebilir.

Doğrulama sonuçlarını yönlendirme politikasıyla eşleyin

Ağ geçidi doğrudan "kiracı tarafından seçilen sağlayıcı"dan "bu sırrı kullan"a yönlendirmemelidir. Kiracı politikasından model profiline, model profilinden yetenek gereksinimlerine ve gereksinimlerden uygun kimlik bilgisi sürümlerine yönlendirin.

Örneğin:

tenant: acme-prod
virtual_key: mgk_live_...
model_profile: support-chat-standard
requirements:
  endpoint: chat
  provider_candidates: [openai, anthropic, azure_openai]
  features: [streaming, tools]
  max_region: customer_approved_regions
  usage_mode: gateway_metered_with_provider_reconciliation_preferred
eligible_credentials:
  - byok_openai_project_key_v3: verified, tools=true, streaming=true, usage_report=partial
  - byok_azure_openai_v2: degraded, deployment_found=true, quota_low=true
routing_decision:
  primary: byok_openai_project_key_v3
  fallback: none unless customer permits provider-managed spillover

Bu politika katmanı aynı zamanda birleşik AI API faturalandırmayı da korur. Ağ geçidinin yalnızca istekleri iletmesi ve daha sonra sağlayıcı faturalarına güvenmesi durumunda BYOK, merkezi faturalandırmayı zayıflatabilir. Sağlayıcı tarafı kullanım raporları mevcut olmadığında bile ağ geçidinin kiracı düzeyindeki kullanımı, istek kimliklerini, model profilini, mümkün olduğu durumlarda normalleştirilmiş jeton sayımlarını, mutabakat güvenini ve desteklenmeyen raporlama modlarını kaydetmesi gerekir.

Müşteriye yönelik dil kullanarak hataları ele alın

Ham sağlayıcı hataları destek açısından faydalıdır ancak çoğu müşteri doğrudan düzeltme rehberliğine ihtiyaç duyar. Ham hata kodunu ve başlıklarını dahili olarak saklayın, ardından hatayı kararlı bir mesaja dönüştürün.

İlk katılımdan sonra kimlik bilgilerini yeniden kontrol edin

Başarılı bir ön kontrol anlık görüntüdür, garanti değildir. Proje rolleri, çalışma alanı politikası, kota, faturalandırma durumu, model kullanılabilirliği ve bölgesel kapasite, katılımdan sonra değişebilir. Ağ geçidi, planlanmış durum kontrollerini ve olaya dayalı yeniden kontrolleri çalıştırmalıdır.

Şu tarihten sonra yeniden kontrolü tetikleyin:

• 401 veya sağlayıcı kimlik doğrulama hataları.
• 403 veya izin reddedilen yanıtlar.
• 404 model, dağıtım veya uç nokta bulunamadı yanıtları.
• 429, normal trafik kalıplarının dışında kota aşıldı veya hız sınırı yanıtları.
• Sağlayıcı faturalandırması, organizasyon, çalışma alanı veya proje hataları.
• İstenen model profillerinde, bölgelerde, araçlarda veya veri politikasında müşteri değişiklikleri.

Bir özellik bozulduğunda kiracının tamamını hemen askıya almayın. Akış başarısız olmasına rağmen akış dışı çıkarım hala çalışıyorsa akış özelliğinin azaldığını işaretleyin ve politika izin veriyorsa uygun akış dışı iş yüklerini yönlendirin. Tek bir Azure dağıtımı eksikse müşterinin tüm sağlayıcı kimlik bilgileri yerine bu dağıtımı engelleyin.

Rotasyonu paralel bir doğrulama iş akışı olarak oluşturun

Döndürme kör üzerine yazma olmamalıdır. Yeni bir kimlik bilgisi sürümü oluşturun, bunu karantinada saklayın, orijinal katılımla aynı araştırmaları çalıştırın ve yönlendirmeyi yalnızca doğrulama geçtikten sonra atomik olarak değiştirin. Eski anahtarı, yalnızca müşterinin buna açıkça izin vermesi ve politikanın depolamanın sürdürülmesine izin vermesi durumunda kısa bir geri alma aralığında tutun.

Güvenli bir rotasyon iş akışı şuna benzer:

1. Müşteri, yedek kimlik bilgileri ve bağlayıcı alanları gönderir.
2. Gateway, sırrı karantinadaki yeni bir kimlik bilgisi sürümü olarak saklar.
3. Doğrulayıcı statik kontroller, okuma araştırmaları, çıkarım araştırmaları ve politika testleri gerçekleştirir.
4. Yetenek matrisi etkin sürümle karşılaştırılır.
5. Müşteri, toplu desteğin eksik olması veya kota güveninin düşük olması gibi herhangi bir gerilemeyi görür.
6. Ağ geçidi, tek bir kontrol düzlemi güncellemesinde yönlendirmeyi yeni sürüme geçirir.
7. Eski sürüm derhal iptal edilir veya kısa, açık bir geri alma aralığı boyunca tutulur.

Karşılaştırma adımı önemlidir. Temel metin modelini çağırabilen bir yedek anahtar, araç desteğini, kullanım raporlamasını, bölgesel kotayı veya üretim dağıtımına erişimi kaybederse yine de bir regresyon olabilir.

Açık bir şekilde ifade etmek için ödünler

Doğrulama, sağlayıcıdan küçük ücretler gerektirebilir. Öneri, izin istemek, maksimum araştırma bütçesi göstermek ve minimum istem ve çıktı sınırları kullanmaktır. Faturalandırılabilir araştırmaları "doğrulama"nın içinde saklamayın.

Yöneticinin iç gözlemi güveni artırır ancak patlama etki alanını artırır. Bazı müşteriler daha ayrıntılı doğrulama için yönetici veya raporlama kimlik bilgileri sağlar. Diğerleri yalnızca çalışma zamanı anahtarlarını sağlayacaktır. Her ikisini de destekleyin ancak ortaya çıkan güveni açıkça etiketleyin.

Sağlayıcı semantiği temiz bir şekilde normalleşmeyecektir. Tek bir durum listesi, ürün akışları için faydalıdır, ancak destek ekiplerinin ham sağlayıcı kodlarına, başlıklara, istek kimliklerine ve bağdaştırıcı düzeyinde kanıtlara ihtiyacı vardır. Hem normalleştirilmiş hem de ham kayıtları koruyun.

BYOK, faturalandırma sorumluluğunu değiştirir. BYOK, müşterilere sağlayıcı-sözleşme kontrolü sağlar, ancak ağ geçidinin sağlayıcı faturalarını mutabakat etme yeteneğini azaltabilir. Ağ geçidi, faturalandırmanın sağlayıcı tarafından mı mutabık kılındığını, ağ geçidi tarafından mı ölçüldüğünü, kısmi mi yoksa müşteri tarafından mı beyan edildiğini göstermelidir.

Sıkı katılım, bazı satış odaklı kurulumları yavaşlatır. Sınırlı bir korumalı alan modu yardımcı olabilir, ancak açıkça etiketlenmeli, sınırlanmalı ve otomatik üretim tanıtımı engellenmelidir. Üretim yönlendirmesi, doğrulanmış yetenek ve politika eşlemesi gerektirmelidir.

Uygulama kontrol listesi

• Açık yaşam döngüsü durumlarına ve değiştirilemez kimlik bilgileri sürümlerine sahip bir BYOK kimlik bilgisi nesnesi oluşturun.
• Doğrulamadan önce sağlayıcıya özel bağlama alanlarını toplayın.
• Gizli bilgileri yalnızca kimlik bilgisi kasasında saklayın; ham anahtarları değil, parmak izlerini ve kasa referanslarını günlüğe kaydedin.
• Sağlayıcı çağrılarından önce statik kontroller çalıştırın.
• İzin verilen yerlerde okuma araştırmaları çalıştırın ve ham sağlayıcı kanıtlarını koruyun.
• Müşteri onayı ve araştırma bütçesi ile talep edilen model profili başına bir minimum çıkarım araştırması çalıştırın.
• İzin verilmeyen modeller, araçlar, uç noktalar ve bölgeler için ağ geçidi politikası negatif testleri çalıştırın.
• Boole değil, güven düzeyine sahip bir yetenek matrisini sürdürün.
• Doğrudan seçilen bir gizli dizi aracılığıyla değil, kiracı politikası ve model profili gereksinimleri üzerinden yönlendirme yapın.
• Müşterilerin karşılaştığı hata mesajlarını belirli düzeltme adımlarıyla ortaya çıkarın.
• Durum kontrollerini planlayın ve çalışma zamanı hatalarından kaynaklanan yeniden kontrolleri tetikleyin.
• Paralel doğrulama ve ardından atomik yönlendirme anahtarı olarak rotasyonu uygulayın.

Sonuç

En güvenli BYOK katılım akışı bir form değil, bir doğrulayıcıdır. Müşteri tarafından sağlanan bir sağlayıcı anahtarı karantinaya girmeli, bağlayıcılığını, izinlerini, model erişimini, kota sinyallerini, uç nokta davranışını ve raporlama sınırlarını kanıtlamalı, ardından yalnızca gerçekten desteklediği özellikler için uygun hale gelmelidir.

Pratik öneri, doğrulamayı bir yetenek matrisi olarak depolamak, kiracı politikası aracılığıyla yönlendirmek ve üretim trafiği başladıktan sonra yeniden kontrol etmeye devam etmektir. Tahmin oldukça basit: sağlayıcı anahtar türleri, çalışma alanı kontrolleri, bölgesel kotalar ve modele özel izinler daha ayrıntılı hale geldikçe, BYOK'u tek seferlik gizli bir yükleme olarak ele alan ağ geçitleri daha fazla kaçınılabilir üretim hatasıyla karşılaşacak. Kimlik bilgisi doğrulamasını kontrol düzleminin bir parçası haline getiren ağ geçitleri, müşterileri başlangıçta daha yavaş bir şekilde kabul eder, ancak trafik başladıktan sonra daha az sürprizle karşılaşır.

İlgili okumalar

• çalışma zamanı, yönetici, faturalandırma ve BYOK erişimini ayırmak için kimlik bilgisi kasası modeli