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

Bir ürün birçok müşterinin AI modellerini aramasına olanak tanıdığında, yanlış temel öğe genellikle yukarı akış sağlayıcı anahtarıdır. Sağlayıcı anahtarı genellikle bir hesabı, projeyi, çalışma alanını veya hizmet hesabını temsil eder. Ürününüzün daha dar kapsamlı bir şeye ihtiyacı var: bir kiracıyı, müşteriyi, uygulamayı, ortamı, model politikasını, bütçeyi ve denetim kuralını tanımlayan, müşteriye yönelik bir anahtar.

Müşteri kapsamlı AI API anahtarlarının amacı budur. Ağ geçidi anahtarı verir, istekleri doğrular, politikayı uygular, kullanımı ölçer ve ardından gizli kimlik bilgilerini kullanarak yukarı akış sağlayıcılarını arar. Alt müşteriler hiçbir zaman sağlayıcı anahtarını almazlar. Platformunuzla istikrarlı bir sözleşme alırlar.

Okuyucu Sorunu: Müşteri Başına Bir Sağlayıcı Projesi Olmadan Müşterinin Yalıtılması

SaaS geliştiricileri, ajansları ve bayi platformlarının, yapay zeka erişimini aşağı yönde açığa çıkarmadan önce genellikle pratik soruları yanıtlamaları gerekir:

• Bu kullanımı hangi müşteri oluşturdu?
• Çağrıyı hangi uygulama, ortam veya entegrasyon yaptı?
• Hangi modellere ve yöntemlere izin veriliyor?
• Bu müşteri bu ay ne kadar harcayabilir?
• Bir anahtar sızdırılırsa ne olur?
• Bu müşteri, diğer herkesi etkilemeden askıya alınabilir mi?
• Kullanım daha sonra sağlayıcı raporlarıyla mutabakata varılabilir mi?

Sağlayıcı tarafı projeleri ve çalışma alanları yardımcı olabilir, ancak bunlar her alt müşteri için her zaman doğru birim olmayabilir. Müşteri başına bir yukarı akış sınırı oluşturmak, sıkı izolasyonu ve raporlamayı iyileştirebilir, ancak aynı zamanda temel hazırlık yüküne, kota bölünmesine, kimlik bilgilerinin yayılmasına ve daha fazla mutabakat çalışmasına da neden olur.

Ağ geçidi tarafından verilen anahtar, yukarı yöndeki kimlik bilgileri havuzda toplandığında bile ürüne müşteri düzeyinde bir kontrol noktası sağlar. Ayrıca, müşterinin sözleşmeye dayalı ayrılığa, ikamet sınırlarına veya doğrudan sağlayıcı hesabı sahipliğine ihtiyacı olduğunda kiracıya bağlı sağlayıcı kimlik bilgileri veya kendi anahtarınızı getir gibi daha güçlü modları da destekler.

Gerçekler, Öneriler ve Tahminler

Gerçekler

• OpenAI proje; üyeleri, hizmet hesaplarını, API anahtarları, kullanım sınırlarını, bütçeleri ve kapsam dahilindeki proje kaynaklarını destekler. Bu, projeleri yukarı yöndeki sınırlar olarak faydalı kılar ancak otomatik olarak her son müşteri için doğru ilkel değildir.
• OpenAI kullanım raporlaması, kullanımı proje, kullanıcı, API anahtarı, model, toplu iş ve hizmet katmanı gibi boyutlara göre gruplandırabilir. SaaS ters ibrazı için hâlâ sağlayıcı kayıtlarının ürüne ait müşteri tanımlayıcılarıyla birleştirilmesi gerekiyor.
• Anthropic çalışma alanları, API kaynakları kullanım senaryosuna, ekibe, departmana, projeye veya ürüne göre ayırır. API anahtarlar, oluşturuldukları çalışma alanına bağlıdır ve çalışma alanları arasında taşınamaz.
• Anthropic kullanım ve maliyet raporlama, API anahtarına, çalışma alanına, modele, hizmet katmanına, bağlam penceresine, veri yerleşimine ve hızla ilgili seçeneklere göre gruplandırmayı destekler; maliyetler günlük USD paketler halinde döndürülür.
• Google Gemini API tuş kılavuzu, anahtarların kısıtlanmasını önerir ve Gemini API anahtarları varsayılan olarak Üretken Dil API ile sınırlıdır. Dağıtım şekline bağlı olarak IP adresleri gibi uygulama kısıtlamaları mevcut olabilir.
• OWASP kılavuzu, API anahtarı, korunan uç noktalar için gerekli kontroller olarak ele alır ve istemciler kullanım sözleşmelerini ihlal ettiğinde anahtarların iptal edilmesi gerektiğini söyler.
• OWASP sırları kılavuzu, en az ayrıcalığı, gizli sırlar artık gerekli olmadığında veya gizliliği ihlal edildiğinde iptali ve uygulama hatasını azaltmak için otomatik rotasyonu vurgular.

Öneriler

• Yalnızca kimlik doğrulama jetonlarını değil, ağ geçidi tarafından verilen müşteri anahtarlarını politika tanıtıcıları olarak kullanın.
• Üst düzey sağlayıcı kimlik bilgilerini alt müşterilerden gizli tutun.
• Sağlayıcı kontrol panellerine güvenmeden önce istek sırasında bir ağ geçidi kullanım defteri yazın.
• Yüksek riskli, yüksek hacimli, düzenlemeye tabi, ikamet konusunda hassas veya sözleşmeye bağlı olarak ayrı müşteriler için sağlayıcı projelerini veya çalışma alanlarını seçici bir şekilde kullanın.
• Anahtar rotasyonunu anlık bir kırılma olayı olarak değil, çakışan bir iş akışı olarak oluşturun.

Tahminler

• Daha fazla sağlayıcı, daha zengin kullanım gruplaması ve bütçe kontrolleri sunacak ancak SaaS faturalandırması ve bayi raporlaması için ürüne ait müşteri ilişkilendirmesi hâlâ gerekli olacak.
• Bayi ve ajans platformları, ağ geçidi anahtarlarını giderek daha fazla ticari nesneler olarak ele alacak: planlara, kredi bakiyelerine, kapsamlara ve destek iş akışlarına bağlı.
• Sıkı uyumluluk veya satın alma ihtiyaçları olan müşteriler BYOK veya sağlayıcı hesabı sahipliğini isteyecek, sıradan müşterilerin çoğu ise yönetilen ağ geçidi sözleşmesini tercih edecektir.

Ağ Geçidi Anahtar Nesnesi

Müşteri kapsamlı bir anahtarın yapılandırılmış bir politika nesnesine çözümlenmesi gerekir. En azından anahtarı bir karma ve addan daha fazlası olarak modelleyin.

{
  "key_id": "key_01J9...",
  "tenant_id": "tenant_acme",
  "customer_id": "cust_4812",
  "application_id": "app_support_bot",
  "environment": "production",
  "owner": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "monthly_budget": {
    "currency": "USD",
    "amount": "500.00"
  },
  "rate_limits": {
    "requests_per_minute": 120,
    "input_tokens_per_minute": 250000,
    "output_tokens_per_minute": 80000
  },
  "retention_policy": "metadata_only",
  "status": "active",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": null
}

Tam alanlar değişiklik gösterebilir ancak prensip böyle olmamalıdır: gelen her istek, gönderilmeden önce anahtarı kiracı politikasına dönüştürür. 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 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 Ekle

Model profili, müşteriye yönelik model adlarını sağlayıcı modelleri ve yetenekleriyle eşleştirir. Örneğin support-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 Fiyat 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 yumuşak sınır.
• 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ı, gerçek maliyeti tamamlandıktan sonra kapatmalı ve kullanılmayan rezervi serbest bırakmalıdır. Bu, faturalandırmayı gecikmeli bir raporlama görevi olarak ele almak yerine temel politikayı AI API faturalandırma'ya bağlar.

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

Düz metin sırrını bir kez göster. 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 sonu" tanımlamasına yardımcı olur.

Tipik bir depolama düzeni şöyledir:

• key_id: kararlı veritabanı tanımlayıcısı.
• secret_hash: uygun bir şifre veya jeton karma stratejisi kullanılarak tam sırrın karması.
• secret_prefix: hassas olmayan kısa ekran öneki.
• fingerprint: denetim araması için belirleyici tanımlayıcı.
• created_by: anahtarı oluşturan kullanıcı veya İş Ortağı API istemcisi.
• status: 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ıyı, müşteriyi, uygulamayı, ortamı, sahibi 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ını, 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önderim.
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çeğin tek kaynağı değil, mutabakat girdileri haline gelir.

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

Bir ağ geçidi defteri, varsayılan olarak ham istem depolama 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.
• tenant_id, customer_id, application_id ve key_id.
• 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 API varsa 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 API anahtar yönetimi iş akışını destekler. ilgisiz kiracıları ifşa etmeden.

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

Havuzda Toplanan 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 birleştirmelisiniz.

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. Ayrıca, sağlayıcının bu sınırdaki sınırları desteklemesi durumunda kesin bir kota geri dönüşü de sağlayabilir.

Maliyet, operasyonel karmaşıklıktır. Temel hazırlık, 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şmesini 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.

Buradaki ödün, 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:

• active: isteklere izin veriliyor.
• draining: eski anahtar, rotasyon aralığı sırasında kabul edilir, ancak uyarılar ve denetim etkinlikleri yayınlanır.
• revoked: yeni istekler kalıcı olarak reddedilir.
• quarantined: yeni istekler kötüye kullanım, ödeme, politika veya olaya müdahale nedeniyle engellendi.
• expired: 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ırdığı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çeğe 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öster.
3. Eski anahtarı draining.
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. Eski anahtar son teslim tarihi yaklaştığında hâlâ kullanılıyorsa, sahibine veya İş Ortağı API müşterisine bildirimde bulunun.
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 ama kanıtları ve son teslim tarihlerini içeren operasyonel bir iş akışına dönüşüyor.

İş Ortağı API Yüzey

Aşağı yönlü platformlar müşterileri programatik olarak yönetiyorsa, önemli operasyonları bir İş Ortağı API aracılığıyla ortaya çıkarın. API, kimlik değiştirme anahtarlarını ve denetim etkinliklerini desteklemelidir çünkü temel hazırlık genellikle faturalandırma, katılım veya CRM iş akışlarının içinde gerçekleşir.

Minimum uç noktalar:

• POST /customers: 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ı listeleyin.
• PATCH /keys/{key_id}: kapsamları, sahibi, sınırları, model profilini veya durumu güncelleyin.
• POST /keys/{key_id}/rotate: yedek parça oluştur ve eski anahtarı boşalıyor olarak işaretle.
• POST /keys/{key_id}/revoke: derhal 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 eksiklik anahtarını kabul etmelidir. Her değişiklik, aktör, hedef, öncesi ve sonrası alanları, kaynak IP'si veya istemci kimliği ve mümkün olduğu durumlarda nedenini içeren bir denetim etkinliği yazmalı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 analizi 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ı 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 göre çözümleyin.
• Sağlayıcı aramalarından ö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ş rotasyonu çakışmasını destekleyin.
• İş Ortağı API işlemlerini idempotency anahtarlarıyla açığa çıkarın.
• Sağlayıcı projelerini veya çalışma alanlarını yalnızca işletim maliyetlerinin haklı olduğu durumlarda kullanın.

Uygulanabilir Sonuç

Yapay zeka erişimi için müşteri izolasyonu 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ı mutabakata varın.

İlgili okuma

• idempotent İş Ortağı API müşteriler, anahtarlar ve krediler için temel hazırlık