Müşteri Kapsamlı AI API Anahtarları: Sağlayıcı Anahtar Yayılımı Olmadan Kiracıları, Bütçeleri ve Kötüye Kullanımı Yalıtın

Tam alanlar değişiklik gösterebilir, ancak prensip böyle olmamalıdır: gelen her istek, gönderilmeden önce kiracı politikasının anahtarını çözer. Kimlik doğrulama "kim arıyor?" sorusunu yanıtlar. Politika çözümü "Bu arayan ne yapabilir, ne kadar harcayabilir, istek nereye yönlendirilebilir ve nelerin günlüğe kaydedilmesi gerekir?" sorusunun yanıtını verir.

Bu aynı zamanda anlamsal ürün stratejisinin de önemli olduğu yerdir. Ajanslar için AI API'si satan bir platformun müşteri ve kampanya boyutlarına ihtiyacı olabilir. Bir geliştirici aracının çalışma alanı ve depo boyutlarına ihtiyacı olabilir. Bayinin, faturalandırma sistemiyle eşleşen harici müşteri kimliklerine ihtiyacı olabilir.

Anahtar Oluşturma İş Akışı

Anahtar oluşturma, otomasyon için yeterince belirleyici ve güvenlik incelemesi için yeterince katı olmalıdır.

1. Önce Müşteri Kaydını Oluşturun

Yetim anahtarlar oluşturmayın. Anahtarın var olmadan önce kiracıya ve müşteri kaydına ait olması gerekir. Bayi platformları için müşteri kaydı, bayinin CRM veya faturalandırma sistemindeki harici kimlikleri, plan meta verilerini, gerekirse vergi veya fatura gruplamasını ve tüm alt anahtarları askıya alabilecek bir durum alanını içermelidir.

2. Bir Model Profili Ekleyin

Bir model profili, müşteriye yönelik model adlarını sağlayıcı modelleri ve yetenekleriyle eşleştirir. Örneğin, destek standardı dengeli bir metin modeline, resim girişine ve kod çalıştırılmamasına izin verebilir. research-premium, uzun bağlam modellerine, web aramasına ve istek başına daha yüksek tavanlara izin verebilir.

Aşağı akış uygulamalarını sağlayıcı model kimliklerini sabit kodlamaya zorlamayın. Kullanılabilirliği, geri dönüşü, fiyatlandırmayı ve kullanımdan kaldırmayı yönetmek için ağ geçidi profilini kullanın.

3. Harcama ve Oran Sınırlarını Belirleyin

Bütçeleri ve ücret sınırlarını birlikte kullanın. Aylık bütçe, zaman içinde faturanın zarar görmesini önler. Hız sınırları, ani kötüye kullanım, yeniden deneme fırtınaları veya kazara oluşan döngülerin bütçenin tamamını dakikalar içinde tüketmesini önler.

Yararlı kontroller şunları içerir:

• Aylık müşteri bütçesi.
• Anormallik tespiti için günlük esnek tavan.
• Anahtar başına istek oranı.
• Giriş ve çıkış jeton oranı.
• İstek başına maksimum tahmini maliyet.
• Barındırılan arama, dosya işleme veya kod yürütme için araca özgü sınırlar.

Bütçenin uygulanması, tahmini maliyeti sevkıyattan önce ayırmalı, fiili maliyeti tamamlanmadan sonra kapatmalı ve kullanılmayan rezervi serbest bırakmalıdır. Bu, faturalandırmayı gecikmiş bir raporlama görevi olarak ele almak yerine temel politikayı AI API faturalandırmaya bağlar.

4. Sırrı Doğru Şekilde Oluşturun ve Saklayın

Düz metin sırrını bir kez görüntüleyin. Destek araması için yalnızca güçlü bir karmanın yanı sıra kısa bir önek veya parmak izi saklayın. Önek, destek ekiplerinin sırrı görmeden "8F2A'daki anahtar son"u belirlemesine yardımcı olur.

Tipik bir depolama düzeni şöyledir:

• key_id: kararlı veritabanı tanımlayıcısı.
• secret_hash: uygun bir şifre veya belirteç karma stratejisi kullanarak tam sırrın karması.
• secret_prefix: hassas olmayan kısa ekran öneki.
• parmak izi: denetim araması için belirleyici tanımlayıcı.
• yaratan_: anahtarı oluşturan kullanıcı veya İş Ortağı API istemcisi.
• durum: etkin, tükeniyor, iptal edildi, karantinaya alındı, süresi doldu.

Yukarı akış sağlayıcı anahtarlarını asla müşteri anahtarı nesnesinde saklamayın. Sağlayıcı kimlik bilgileri, kendi erişim kurallarına sahip ayrı bir kimlik bilgisi kasasına aittir.

İstek Zamanında Uygulama

Ağ geçidi, her model çağrısını bir sağlayıcı gönderimi tarafından takip edilen bir politika kararı olarak ele almalıdır. Pratik bir istek yolu şuna benzer:

1. Sunulan ağ geçidi anahtarını ayrıştırın.
2. Anahtar karmasını ve durumunu arayın.
3. Kiracı, müşteri, uygulama, ortam, sahip ve model profilini çözümleyin.
4. Kiracının ve müşterinin etkin olup olmadığını kontrol edin.
5. İstenen model takma adını, yöntemini, araçları, saklama modunu, bölgeyi ve hizmet katmanını doğrulayın.
6. İstek maliyetini ve ayırma bütçesini tahmin edin.
7. Oran sınırlarını ve kötüye kullanım eşiklerini kontrol edin.
8. Yukarı akış kimlik bilgisi modunu seçin: havuza alınmış, kiracıya bağlı veya BYOK.
9. Sağlayıcıya gönderin.
10. Kullanımı, maliyeti, sağlayıcı referanslarını, hataları ve güvenlik sinyallerini yakalayın.
11. Bütçe rezervasyonunu yapın ve son genel muhasebe etkinliğini yazın.

Bu sıra, ağ geçidini müşteri sözleşmesinden sorumlu tutar. Sağlayıcı kontrol panelleri, gerçeklerin tek kaynağı değil, mutabakat girdileri haline gelir.

Daha Sonra Yardımcı Olacak Kullanım Defter Alanları

Bir ağ geçidi defteri, varsayılan olarak ham bilgi istemi depolaması gerektirmeden destek, faturalandırma, kötüye kullanım ve yönlendirme sorularını yanıtlamak için yeterli ayrıntıyı korumalıdır.

Yararlı alanlar şunları içerir:

• request_id ve trace_id.
• kiracı_kimliği, müşteri_kimliği, uygulama_kimliği ve anahtar_kimliği.
• Son kullanıcı tanımlayıcı, tercihen uygun olduğu yerde takma ad.
• Müşteri tarafından talep edilen model takma adı.
• Çözülmüş yukarı akış sağlayıcısı ve modeli.
• Giriş, çıkış, akıl yürütme, önbelleğe alınmış, ses, resim, video ve uygun olduğu yerde araç kullanımı.
• Teklif edilen maliyet, ayrılan tutar, belirlenen maliyet, para birimi ve fiyatlandırma kataloğu sürümü.
• Sağlayıcı istek kimliği, kullanım raporu referansı, proje, çalışma alanı veya varsa API anahtarı gruplandırma boyutu.
• Saklama politikası uygulandı.
• Güvenlik, kötüye kullanım veya politika karar kodları.
• Hata kategorisi ve meta verileri yeniden deneyin.

Bu yapı, geri ödemeyi, müşteri desteğini, olay müdahalesini ve "Bu anahtar ne yaptı?" sorusunu yanıtlayabilen bir API anahtar yönetimi iş akışını destekler. ilgisiz kiracıları açığa çıkarmadan.

Kimlik Bilgisi Modları: Havuza Alınmış, Kiracıya Bağlı ve BYOK

Havuzlanmış Sağlayıcı Kimlik Bilgileri

Varsayılan modda, birçok müşteri anahtarı daha küçük bir sağlayıcı kimlik bilgileri kümesi üzerinden yönlendirilir. Bu, operasyonel olarak basittir ve sağlayıcı tarafındaki yayılmayı azaltır. Ağ geçidinde güçlü kiracı ilişkilendirmesi, bütçe uygulaması, hız sınırlaması, kötüye kullanım izolasyonu ve önbellek sınırı kontrolleri bulunduğunda çalışır.

Buradaki ödün, sağlayıcı tarafı raporlamanın yalnızca ağ geçidi kimlik bilgilerini veya sağlayıcı projesini gösterebilmesidir. Müşteri düzeyinde faturalandırma ve analiz üretmek için sağlayıcı kayıtlarını ağ geçidi defter kayıtlarına geri bağlamanız gerekir.

Kiracıya Bağlı Sağlayıcı Kimlik Bilgileri

Daha büyük veya riskli kiracılar için kiracıyı özel bir sağlayıcı projesine, çalışma alanına, hizmet hesabına veya anahtara bağlayın. Bu, daha güçlü bir yukarı akış ayrımı sağlar ve sağlayıcı tarafı raporlamayı basitleştirebilir. Sağlayıcının bu sınırdaki sınırları desteklemesi halinde, kesin bir kota geri dönüşü de sağlayabilir.

Maliyet operasyonel karmaşıklıktır. Tedarik, rotasyon, sağlayıcı sınırları, olaylara müdahale ve mutabakat artık daha fazla yukarı akış nesnesinde gerçekleşiyor.

Kendi Anahtarınızı Getirin

BYOK, müşterilerin sağlayıcı hesabına sahip olması, kendi sağlayıcı sözleşmelerini müzakere etmesi veya sağlayıcı faturalarını ayrı tutması gerektiğinde yararlı olabilir. Ağ geçidi, mümkün olduğu durumlarda model profillerini, yönlendirme politikasını, analizleri ve uygulama düzeyindeki kontrolleri uygulamaya devam eder.

Değiştirme, desteğin karmaşıklığıdır. Her müşterinin sağlayıcı hesabı farklı model erişimine, kotalara, fiyatlandırmaya, saklama ayarlarına ve olay durumuna sahip olabilir. Ağ geçidinin bu farklılıkları net bir şekilde tespit etmesi ve açıklaması gerekir.

İptal ve Karantina

İptal, ilgisiz yukarı akış sağlayıcı kimlik bilgilerini döndürmeden müşteri anahtarına yönelik yeni istekleri hemen engellemelidir. Bu, sanal anahtarların temel avantajlarından biridir.

Farklı operasyonel işlemler için ayrı durumlar kullanın:

• etkin: isteklere izin verilir.
• boşaltma: eski anahtar bir rotasyon penceresi sırasında kabul edilir, ancak uyarılar ve denetim etkinlikleri yayınlanır.
• iptal edildi: yeni istekler kalıcı olarak reddedilir.
• karantinaya alındı: yeni istekler kötüye kullanım, ödeme, politika veya olay müdahalesi nedeniyle engellendi.
• süresi doldu: anahtarın kullanım ömrü doldu ve değiştirilmesi gerekiyor.

Olay çözümlendiğinde karantina geri döndürülebilir olmalıdır. Eski sırların geri yüklenmesi kafa karışıklığını ve riski artıracağından, iptal genellikle geri alınamaz.

Bir anahtar kullanım politikasını ihlal ettiğinde yaptırımın nedenini, aktörünü, zamanını ve kapsamını günlüğe kaydedin. Karar otomatikleştirilmişse kural sürümünü ve onu tetikleyen sinyalleri koruyun. Bu, müşteri görüşmelerinin gerçeklere dayalı olmasını sağlar.

Üretimi Kesmeden Rotasyon

Anahtar rotasyonunda iki anahtar çakışması iş akışı kullanılmalıdır:

1. Operatör kasıtlı olarak değiştirmediği sürece aynı müşteri, uygulama, model profili ve limitlere sahip bir yedek anahtar oluşturun.
2. Yeni sırrı bir kez görüntüleyin.
3. Eski anahtarı boşaltma olarak işaretleyin.
4. Müşteri planına ve riske bağlı olarak her iki anahtarı da 7, 14 veya 30 gün gibi sınırlı bir süre boyunca kabul edin.
5. Boşaltma anahtarında kullanım uyarıları yayınlayın.
6. Son tarih yaklaştığında eski anahtar hâlâ kullanılıyorsa, sahibine veya İş Ortağı API istemcisine bildirin.
7. Pencerenin sonundaki eski anahtarı iptal edin.
8. Aynı müşteri ve uygulama altında her iki anahtar kimliği arasındaki ilişkilendirmeyi koruyun.

Bu, güvenlik iyileştirmesinin üretim kesintisine dönüştüğü yaygın hata modunu önler. Rotasyon hâlâ bir kontrol olsa da kanıtları ve son teslim tarihlerini içeren operasyonel bir iş akışına dönüşüyor.

İş Ortağı API Yüzeyi

Aşağı yönlü platformlar müşterileri programatik olarak yönetiyorsa temel operasyonları bir İş Ortağı API'si aracılığıyla kullanıma sunun. Temel hazırlık genellikle faturalandırma, katılım veya CRM iş akışlarının içinde gerçekleştiğinden API, boş anahtarları ve denetim olaylarını desteklemelidir.

Minimum uç noktalar:

• POST /müşteriler: bir müşteri oluşturun veya müşteriyi yükseltin.
• POST /customers/{customer_id}/keys: bir anahtar oluşturun.
• GET /customers/{customer_id}/keys: anahtarları ve durumları listeler.
• PATCH /keys/{key_id: kapsamları, sahibi, sınırları, model profilini veya durumu güncelleyin.
• POST /keys/{key_id}/rotate: yedek parçayı oluşturun ve eski anahtarı boşalıyor olarak işaretleyin.
• POST /keys/{key_id}/revoke: hemen iptal edin.
• GET /customers/{customer_id}/usage: zaman aralığına, anahtara, uygulamaya, modele veya son kullanıcı boyutuna göre kullanımı ve maliyeti döndürür.

Her mutasyona uğrayan istek bir idempotency anahtarını kabul etmelidir. Her değişiklikte aktör, hedef, öncesi ve sonrası alanları, kaynak IP'si veya istemci kimliği ve mümkünse nedeninin yer aldığı bir denetim etkinliği yazılmalıdır.

Sağlayıcı Projeleri veya Çalışma Alanları Ne Zaman Kullanılmalı

Ağ geçidi anahtarlarına ve sağlayıcı sınırlarına birbirini dışlayan öğeler olarak davranmayın. Farklı sorunları çözüyorlar.

Normal müşteri düzeyinde kontrol için ağ geçidi anahtarlarını kullanın:

• Müşteri başına ilişkilendirme.
• Uygulama başına anahtarlar.
• Bütçe ve ücret sınırları.
• Hızlı askıya alma.
• Rotasyon iş akışları.
• Kullanım analizleri ve bayi raporlamasını kullanın.

Müşteri daha güçlü bir ayrıma ihtiyaç duyduğunda sağlayıcı projeleri, çalışma alanları veya özel sağlayıcı kimlik bilgileri ekleyin:

• Ayrılmış kotaları hak eden yüksek aylık hacim.
• Açık ikamet veya saklama gereksinimleri olan düzenlenmiş iş yükleri.
• Sözleşmeye dayalı fatura ayrımı.
• Sağlayıcı tarafının katı bütçesi veya kota geri dönüşleri.
• Özel kötüye kullanım izleme veya güvenlik incelemesi sınırları.
• BYOK aracılığıyla müşterinin sahip olduğu sağlayıcı hesapları.

Pratik varsayılan, seçici yukarı akış sabit sınırlarıyla ağ geçidi tarafından zorlanan izolasyondur. Bu, daha fazla ayrılığa ihtiyaç duyan müşteriler için yükseltme yolunu korurken ortak yolu basit tutar.

Uygulama Kontrol Listesi

• Kiracı, müşteri, uygulama, ortam, sahip, model profili, sınırlar, saklama politikası ve durumu içeren bir müşteri anahtarı şeması tanımlayın.
• Kullanılmayan gizli dizileri karma hale getirin ve düz metni yalnızca bir kez görüntüleyin.
• Ağ geçidi anahtarlarını yukarı akış sağlayıcının kimlik bilgileri deposundan ayırın.
• Gönderilmeden önce her isteği politikaya dönüştürün.
• Sağlayıcı aramadan önce bütçe ayırın ve son kullanım öğrenildikten sonra ödeme yapın.
• Müşteri, anahtar, model takma adı, yukarı akış modeli, jeton kategorileri, araç kullanımı, teklif edilen maliyet, sabit maliyet ve sağlayıcı referanslarıyla kullanımı kaydedin.
• Etkin, boşaltılan, iptal edilmiş, karantinaya alınmış ve süresi dolmuş durumlarını uygulayın.
• İki tuş rotasyonunun çakışmasını destekleyin.
• Idempotency anahtarlarıyla İş Ortağı API işlemlerini açığa çıkarın.
• Sağlayıcı projelerini veya çalışma alanlarını yalnızca işletim maliyetlerinin haklı olduğu durumlarda kullanın.

Uygulamaya Uygulanabilir Sonuç

Yapay zeka erişimi için müşteri yalıtımı genellikle sağlayıcı anahtarında değil, ağ geçidi anahtarında başlamalıdır. Ağ geçidi anahtarı müşteriye yönelik sözleşmedir: kiracıyı, müşteriyi, uygulamayı, model profilini, bütçeyi, oran sınırını, saklama kuralını ve denetim politikasını adlandırır. Sağlayıcı anahtarı, söz konusu sözleşmenin arkasında yer alan bir uygulama ayrıntısıdır.

Bu mimari, SaaS oluşturucularına ve bayi platformlarına, varsayılan olarak her müşteri için tek bir yukarı akış sağlayıcı projesi oluşturmadan, hızlı iptal, doğru ilişkilendirme, müşteri başına bütçeler, kontrollü rotasyon ve faydalı kullanım analizleri sağlar. Risk, hacim, ikamet veya sözleşme gerektirdiğinde yukarı akış projelerini, çalışma alanlarını, kiracıya bağlı kimlik bilgilerini veya BYOK'u kullanın. Sıradan yol için, ağ geçidi defterinde ve politika motorunda müşteri izolasyonunu zorunlu kılın, ardından sağlayıcı kayıtlarını uzlaştırın.

İlgili okumalar

• müşteriler, anahtarlar ve krediler için zamanında İş Ortağı API'si sağlama