Ekipler için Yüksek Lisans API Anahtar Yönetişim Sistemi Nasıl Tasarlanır

Paylaşılan LLM sağlayıcı anahtarları, ilk ayrılmaya, fatura artışına, iş ortağı entegrasyonuna veya sırların sızdırılmasına kadar kullanışlıdır. Pratik sorun yalnızca bir anahtarın açığa çıkması değildir. Paylaşılan bir anahtar, sahipliği belirsiz hale getirir, harcamayı zorlaştırır ve birden fazla başvuru aynı kimlik bilgilerine bağlı olabileceğinden acil durum iptali riskli hale gelir.

Çalışabilir bir AI API anahtar yönetişim sistemi, her istek için beş soruyu yanıtlamalıdır: bu erişimin sahibi kimdir, ne yapmasına izin verilmektedir, ne kadar harcayabilir, anormal kullanım nasıl tespit edilecektir ve ilgisiz sistemleri devre dışı bırakmadan nasıl iptal edilebilir?

Bu kılavuz, doğrulanmış gerçekleri uygulama önerilerinden ayırmaktadır. Gerçekler, büyük sağlayıcılar veya güvenlik çerçeveleri tarafından belgelenen yetenekleri ve riskleri açıklamaktadır. Öneriler, birden fazla Yüksek Lisans sağlayıcısı kullanan ekipler için pratik bir işletim modelini açıklamaktadır.

İki katmanlı bir kimlik bilgisi modeliyle başlayın

En önemli tasarım kararı, ham yukarı akış sağlayıcı anahtarlarının uygulamalar, komut dosyaları, dizüstü bilgisayarlar, CI işleri ve iş ortağı sistemleri arasında geniş çapta dağıtılmasına son vermektir. Bunun yerine iki katmanlı bir model kullanın:

• Sağlayıcı kimlik bilgileri: Yukarı akış AI sağlayıcıları tarafından verilen anahtarlar veya hizmet kimlik bilgileri. Bunlar yalnızca kontrollü bir arka uçta, ağ geçidinde, gizli yöneticide veya benzer şekilde kısıtlanmış bir hizmette depolanmalıdır.
• Yönetilen dahili kimlik bilgileri: Ekiplere, uygulamalara, ortamlara, CI işlerine veya iş ortaklarına verilen anahtarlar. Bu anahtarlar, politikayı, yönlendirmeyi, telemetriyi, sınırları ve iptali uygulayan kontrollü erişim katmanınızı çağırır.

Gerçek: Sağlayıcı rehberliği genellikle API anahtarlarının ekip arkadaşlarıyla paylaşılmamasını tavsiye eder, güvenli depolama önerir ve sızdırılan anahtarların yetkisiz etkinlik veya ücretlendirme oluşturabileceği konusunda uyarır. Yetenekler satıcıya ve plana göre farklılık gösterse de sağlayıcı konsolları projeyi, çalışma alanını, anahtar düzeyi kullanımını, ücret sınırını ve bütçe kontrollerini de destekleyebilir.

Öneri: Sağlayıcı anahtarlarını geliştiricilere kolaylık sağlayan jetonlar olarak değil, altyapı sırları olarak ele alın. Geliştiriciler, kapsamı bağımsız olarak belirlenebilen ve iptal edilebilen yönetilen anahtarlar almalıdır. Bu yaklaşım kurumsal LLM API işlemlerini destekler çünkü kimlik bilgisi politikası, analizler ve maliyet kontrolleri birden fazla model ve sağlayıcıya tutarlı bir şekilde uygulanabilmektedir.

Daha fazla anahtar vermeden önce anahtar sınıflandırmasını tanımlayın

Ekipler genellikle her bir anahtarın neyi temsil ettiğini tanımlamadan önce anahtarları vererek yönetim sorunları yaratır. Bir anahtar rastgele bir sırdan daha fazlası olmalıdır. Meta verileri, sahipliği, politikası ve yaşam döngüsü durumuyla yönetilen bir nesne olmalıdır.

Yönetilen her anahtar için minimum meta veriler

• Sahip ekip: Yalnızca bireysel talep sahibi değil, sorumlu grup.
• Uygulama veya iş yükü: Anahtarın kullanıldığı sistem, hizmet, komut dosyası veya entegrasyon.
• Ortam: Üretim, hazırlama, geliştirme, CI, korumalı alan veya iş ortağı.
• İş amacı: Müşteri desteği özeti, dahili arama, kod yardımı, belge çıkarma, aracı iş akışı veya onaylanmış başka bir kullanım örneği.
• İzin verilen model ailesi veya sağlayıcı yolu: Anahtarın hangi modellere veya sağlayıcılara erişebileceği.
• Veri hassasiyeti katmanı: İsteklerin genel, dahili, gizli, düzenlemeye tabi veya müşteri verilerini içerip içermediği.
• Bütçe tavanı: Günlük, haftalık, aylık veya proje düzeyinde harcama sınırı.
• Oran sınırları: Dakika başına istek, dakika başına jeton, eşzamanlı işler veya toplu iş sınırları.
• Son kullanma tarihi: Geçici anahtarlar için gereklidir ve üretim dışı anahtarların çoğu için önerilir.
• Acil durumda iletişime geçilecek kişi: Olaylar sırasında sorumlu bir ekip kanalı veya kişi.

Basit bir adlandırma kuralı, operatörlerin patlama yarıçapını hızlı bir şekilde anlamalarına yardımcı olur. Örneğin:

ekip: destek operasyonları
uygulama: bilet özetleyici
ortam: ürün
use_case: müşteri desteği özeti
data_tier: müşteri sırrı
models_allowed: [model-ailesi-a, model-ailesi-b]
aylık_bütçe_usd: 2500
rotasyon_interval_days: 90
sahibi_iletisim: #destek-platform-uyarıları

Öneri: Üretim sistemleri için alice-openai-key gibi bir kişinin adını taşıyan genel anahtarlar vermeyin. Anahtarın izlenebilirliğini korurken çalışan rolü değişikliklerinden etkilenmemesi için hizmet hesabı sahipliğini ve ekip sorumluluğunu kullanın.

Patlama yarıçapını azaltmak için ortamları ayırın

Bir LLM API anahtarını asla üretim, hazırlama, geliştirme, CI ve iş ortağı ortamlarında yeniden kullanmayın. Operasyonel nedeni basit: bu ortamların farklı risk profilleri var. Yerel geliştirmede kullanılan bir anahtarın kabuk geçmişinde, geçici dosyalarda, not defterlerinde veya test depolarında görünme olasılığı daha yüksektir. Bir üretim anahtarının genellikle daha yüksek kotaları ve hassas iş yüklerine erişimi vardır. Bunları birleştirmek her sızıntıyı daha ciddi hale getirir.

Pratik ortam politikası

• Üretim: Katı onay, hizmet hesabı sahipliği, geniş model erişimine yönelik düşük tolerans, izlenen bütçeler ve acil iptal prosedürleri.
• Aşamalama: Üretime benzer yönlendirme ancak daha düşük sınırlar ve açıkça onaylanmadıkça üretim verileri yok.
• Geliştirme: Daha düşük kotalar, kısa süre sonu, sınırlı veri hassasiyeti ve güvenli denemeyi teşvik eden model kısıtlamaları.
• CI ve otomasyon: Test işleri, karşılaştırma işleri, değerlendirme ardışık düzenleri ve sürüm iş akışları için özel anahtarlar.
• İş ortağı erişimi: Katı kotalara, belgelere ve iş ortağı başına gözlemlenebilirliğe sahip, yetki verilmiş veya iş ortağı kapsamlı anahtarlar.

Ödül: Ayrıntılı ortam ayrımı, yönetilmesi gereken kimlik bilgilerinin sayısını artırır. Cevap, her şeyi tek bir ortak anahtara sığdırmak değil. Bunun yanıtı, temel hazırlığı, meta veri yakalamayı, gizli depolamayı ve rotasyon durumunu otomatikleştirmektir.

API katmanında en az ayrıcalık politikasını uygulayın

LLM API anahtarı her modele, uç noktaya, bağlam boyutuna ve harcama düzeyine sınırsız erişim anlamına gelmemelidir. LLM kimlik bilgileri için en az ayrıcalık, evet veya hayır izin kontrolünden daha fazlasını gerektirir.

Uygulamaya değer kontroller

• İzin verilen modeller: Anahtarın kullanım durumu için yalnızca onaylı model ailelerine veya rotalara izin verin.
• Maksimum bağlam boyutu: Olağandışı büyük belgelerin veya bilgi istemi paketlerinin yanlışlıkla gönderilmesini önleyin.
• Maksimum çıkış jetonları: Kontrolsüz üretim maliyetini sınırlayın ve kötüye kullanımın etkisini azaltın.
• Uç nokta kısıtlamaları: İlgili yerlerde ayrı sohbet, yerleştirme, toplu iş, resim, araç kullanımı ve aracılı iş akışı erişimi.
• Bütçe sınırları: Anahtar düzeyinde, uygulama düzeyinde ve ekip düzeyinde tavanları ayarlayın.
• Oran sınırları: İstek ani artışlarını sınırlayın ve yukarı akış kotalarını koruyun.
• IP veya ağ kısıtlamaları: Desteklendiğinde ve operasyonel açıdan pratik olduğunda uygulayın.
• Engellenen kullanım örnekleri: Bilinen izin verilmeyen iş akışlarını, onaylanmamış veri katmanlarını veya yüksek riskli otomasyon yollarını reddedin.

Örneğin, dahili bir dokümantasyon asistanının yerleştirmeleri ve orta maliyetli bir metin oluşturma modelini kullanmasına izin verilebilir, ancak premium muhakeme modelleri, toplu toplu işler veya görüntü oluşturma için izin verilmeyebilir. Finans iş akışı, daha sıkı veri işleme ve daha dar model yönlendirme gerektirebilir. Geliştirme korumalı alanının günlük sınırı düşük olabilir ve yalnızca hassas olmayan test verilerine erişebilir.

Öneri: Tamamen uygulama koduna güvenmek yerine politika uygulamasını kontrollü erişim katmanına yerleştirin. Uygulama düzeyindeki kontroller faydalıdır ancak ekipler snippet'leri kopyaladığında, komut dosyaları oluşturduğunda veya yeni entegrasyonları hızlı bir şekilde eklediğinde bunların yanlışlıkla atlanması daha kolaydır.

Her anahtarı kullanım analiziyle donatın

Kimlik bilgileri verildiğinde ancak dikkate alınmadığında anahtar yönetimi başarısız olur. İzleme, yönetilen her anahtarın ilişkilendirilebilir ve teşhis edilebilir olmasını sağlamalıdır.

Varsayılan olarak yakalama için telemetri

• Gizli değerin kendisi hariç, anahtar kimliği ve anahtar adı.
• Sahip ekip, uygulama, ortam ve maliyet merkezi etiketleri.
• Zaman damgası, istek sayısı, jeton hacmi ve tahmini maliyet.
• Sağlayıcı, model, uç nokta, gecikme, durum kodu ve hata kategorisi.
• Varsa kaynak uygulaması, hizmet hesabı, bölge veya ağ kaynağı.
• İzin verilme, reddedilme, kısıtlanma, bütçenin engellenmesi veya geri dönüşe yönlendirilme gibi politika kararları.

Gerçek: Büyük yapay zeka sağlayıcıları bir tür kullanım, maliyet, proje, çalışma alanı veya anahtar düzeyinde raporlama sunar. Tam raporlama alanları ve yönetim API'leri sağlayıcıya ve plana göre değişir.

Öneri: Birden fazla sağlayıcı kullanıyorsanız kendi sisteminizdeki kullanım meta verilerini normalleştirin. Sağlayıcıya özgü kontrol panelleri faydalıdır ancak bir ekibin farklı iş yükleri için farklı modeller kullanabileceği durumlarda sağlayıcılar arası bir görünüm gereklidir.

İstem ve yanıt günlüğünün tutulması özel dikkat gerektirir. Ayrıntılı içerik günlükleri, olay incelemesine ve kalite hata ayıklamasına yardımcı olabilir, ancak aynı zamanda gizlilik ve uyumluluk yükümlülükleri de oluşturabilir. Daha güvenli bir varsayılan yöntem meta verileri, politika kararlarını, maliyetleri ve karmaları veya referansları günlüğe kaydetmektir. İçerik günlüğe kaydetmeyi yalnızca saklama kuralları ve erişim kontrolleri olan onaylı kullanım örnekleri için etkinleştirin.

Kimlik bilgilerinin kötüye kullanımını erken tespit eden uyarılar oluşturun

Harcama eşikleri gerekli ancak yeterli değil. Sızan bir anahtar, büyük bir faturaya ulaşmadan önce şüpheli trafik düzenlerine neden olabilir. Uyarı; maliyet, hacim, rota ve davranış sinyallerini birleştirmelidir.

Yararlı anormallik uyarıları

• Bir geliştirme anahtarı aniden üretime benzer bir trafik hacmi gönderir.
• Bir anahtar daha önce kullanmadığı bir model ailesini kullanır.
• Jeton hacmi, önceki dönemlerdeki aynı saat veya güne kıyasla keskin bir şekilde artıyor.
• İstekler yeni bir ağdan, bölgeden, iş ortağından veya dağıtım hedefinden geliyor.
• Otomatik bir istemcinin agresif bir şekilde yeniden denemesi nedeniyle hata oranlarında artış yaşanıyor.
• Anahtar bütçe tavanının %50'sine, %80'ine ve %100'üne yaklaşıyor.
• Hareketsiz bir anahtar, haftalarca veya aylarca kullanılmadığında etkin hale gelir.

Tahmin: Ekipler daha fazla aracılı iş akışı ve otomatik LLM işleri dağıttıkça, anahtar düzeyinde anormallik tespiti aylık fatura incelemesinden daha önemli hale gelecektir. Makine hızında sorunlar yaşanacağından yönetişim sistemlerinin neredeyse gerçek zamanlı sinyallere ihtiyacı vardır.

Kesintilere neden olmayan bir rotasyon iş akışı oluşturun

Ekipler üretimin kesintiye uğramasından korktuğu için anahtar rotasyonundan genellikle kaçınılır. Bu korku, rotasyonun manuel olduğu ve takip edilmediği durumlarda haklıdır. Daha güvenli bir rotasyon iş akışı, çakışan geçerlilik aralıklarını kullanır.

Rotasyon runbook'u

1. Aynı veya kasıtlı olarak güncellenen politikayla yedek anahtarı oluşturun.
2. Onaylanan gizli anahtar yöneticisinde saklayın ve aynı sahip, uygulama ve ortam meta verilerini ekleyin.
3. Normal yayınlama sürecini kullanarak uygulamaya veya iş yüküne yeni anahtarı dağıtın.
4. İsteklerin yeni anahtar kimliği altında geldiğini kontrol ederek trafik değişimini onaylayın.
5. Planlanmış işleri ve arka plan çalışanlarını kapsayacak kadar uzun bir süre üzerinde anlaşılan bir gözlem aralığının geçmesini bekleyin.
6. Eski anahtarı iptal edin, yalnızca meşru trafiğin kalmadığını doğruladıktan sonra.
7. Zaman damgası, sahip, neden ve politika değişiklikleriyle birlikte tamamlanmayı kaydedin.

Geçici iş ortağı konsept kanıtları, kısa ömürlü geliştirme anahtarları veya tek seferlik değerlendirme işleri için son kullanma tarihlerini ve otomatik hatırlatıcıları kullanın. Üretim iş yükleri için güvenlik gereksinimlerinize ve dağıtım olgunluğunuza uygun bir rotasyon aralığı seçin. Çok kısa ömürler riske maruz kalmayı azaltır ancak gizli dağıtımın güvenilmez olması durumunda kesintilere neden olabilir.

Ödül: Dönme sıklığı bir dengedir. Daha kısa aralıklar uzun süreli maruz kalmayı azaltır. Daha uzun aralıklar çalışma gürültüsünü azaltır. Otomasyon, sık rotasyonun daha az aksaklık yaratmasını sağlayarak dengeyi değiştirir.

Sızıntı meydana gelmeden önce bir sızıntıya müdahale runbook'u hazırlayın

Sızıntıya müdahale, anahtarın kime ait olduğu tartışmasıyla başlamamalıdır. Yönetim sistemi; sahiplik, son kullanım ve iptal seçeneklerini açıkça belirtmelidir.

Sızıntıya müdahale kontrol listesi

1. Sızdırılan değerden, önekten, karmadan, anahtar kimliğinden, depo bulmadan veya ağ geçidi günlüklerinden anahtarı tanımlayın.
2. Anahtar kaydını kullanarak sahibini ve ortamı bulun.
3. Önem düzeyine ve mevcut süreklilik seçeneklerine bağlı olarak anahtarı dondurun veya iptal edin.
Anormal istek hacmi, modeller, bölgeler, uç noktalar ve maliyet açısından
4. son kullanımı inceleyin.
Harcama, veri erişimi ve dokunulan alt sistemler de dahil olmak üzere
5. >Maruziyeti tahmin edin.
6. Anahtar diğer kimlik bilgilerinin yanında saklandıysa ilgili gizli dizileri döndürün.
7. Sahibi ekip, güvenlik, finans, hukuk, iş ortağı yöneticisi veya müşteri ekibi gibi paydaşları bilgilendirin.
8. Taahhüt edilen sır, istemci tarafının açığa çıkması, kopyalanan not defteri, güvenli olmayan CI değişkeni veya iş ortağının hatalı kullanımı gibi belgelerin temel nedeni.
9. Gizli tarama, daha kısa süre sonu, daha sıkı politika veya dağıtım değişikliği gibi önleyici bir kontrol ekleyin.

Gerçek: API anahtarlarının tarayıcılar veya mobil uygulamalar gibi istemci tarafı ortamlarda ifşa edilmesi, son kullanıcı cihazlarına dağıtılan sırların açığa çıkarılabilmesi nedeniyle yaygın olarak güvensiz olarak kabul edilmektedir. Mobil uygulama ekosistemleri üzerine yapılan araştırmalar da LLM API kimlik bilgilerinin sürekli olarak sızdırıldığını bildirdi ve bu da sağlayıcı kimlik bilgilerinin dağıtılmış istemcilerden uzak tutulması ihtiyacını güçlendirdi.

Yetki verilen erişimle iş ortağı entegrasyonlarını yönetin

İş ortağı entegrasyonları özel bir yönetim sorunu yaratır. İş ortaklarının istikrarlı erişime ihtiyacı vardır, ancak onlara ham sağlayıcı anahtarı vermek çok fazla kontrol sağlar ve ilişkilendirmeyi zayıflatır. İş ortağı depolamayı yanlış yapılandırırsa veya kararlaştırılan kullanımı aşarsa operasyonel ve finansal risk sağlayıcının anahtar sahibine aittir.

Bunun yerine iş ortağı kapsamındaki anahtarları veya yetki verilen erişim jetonlarını yayınlayın. Her iş ortağı kimlik bilgisinin kendi kotası, onaylanmış uç noktaları, izin verilen kullanım durumu, son kullanma veya yenileme tarihi ve destek yolu olmalıdır. İş ortağı trafiği, dahili uygulama trafiğinden ayrı olarak görünmelidir.

İş ortağı temel politikası örneği

iş ortağı: acme entegrasyonu
ortam: üretim
izin verilen_uç noktalar: [sohbet]
izin verilen_modeller: [onaylı-düşük gecikmeli-model]
aylık_bütçe_usd: 500
hız_limit_rpm: 60
max_output_tokens: 800
content_logging: devre dışı
yenileme_inceleme: 2026-12-31
support_contact: [email protected]

Öneri: İş ortağı anahtarlarını daha düşük varsayılan kotalarla başlatın ve trafiğin istikrarlı olduğunu gözlemledikten sonra bunları artırın. Bu, her iki tarafı da korur: İş ortağı net bir entegrasyon yoluna sahip olur ve platform sahibi, iptal etme ve harcama kontrolünü elinde tutar.

Sağlayıcıya özgü kontrolleri kullanın ancak tek bir sağlayıcının modeline bağlı kalmayın

Sağlayıcı projeleri, çalışma alanları, hizmet hesapları, bütçe uyarıları, ücret sınırları ve kullanım raporları değerlidir. Onları kullanın. Riski kaynağında azaltırlar ve ek bir koruma katmanı sağlayabilirler.

Ancak, çok sağlayıcılı ekipler hızla tutarsızlıkla karşılaşıyor. Bir sağlayıcı, anahtar düzeyindeki kullanım raporlarını açığa çıkarabilir; bir diğeri erişimi çalışma alanları etrafında yapılandırabilir; bir diğeri farklı yönetim API'leri veya plan bağlantılı kontroller sunabilir. Ekipler birden fazla LLM sağlayıcısı kullanıyorsa yönetişim, bunlar arasındaki işletim modelini normalleştirmelidir.

Öneri: Sağlayıcının yerel denetimleri mevcut olsa bile dahili bir anahtar kayıt defterini ve politika katmanını koruyun. Mümkün olduğunda dahili anahtarları sağlayıcı projeleri veya çalışma alanlarıyla eşleştirin. Bu, güvenlik, platform ve finans ekiplerine temel soruları yanıtlayabilecekleri tek bir yer sağlar: Bu trafiğin sahibi kim, hangi politika uygulandı, maliyeti ne oldu ve bunu nasıl kapatabiliriz?

Uygulama kontrol listesi

• Sahip, uygulama, ortam, amaç, veri katmanı, bütçe, son kullanma tarihi ve acil durumda iletişime geçilecek kişiyi içeren bir anahtar kaydı oluşturun.
• Sağlayıcı anahtarlarını kısıtlı bir arka uca, ağ geçidine veya gizli olarak yönetilen bir hizmete taşıyın.
• Ekipler, uygulamalar, ortamlar, CI işleri ve iş ortakları için yönetilen anahtarlar verin.
• En az ayrıcalıklı yönlendirmeyi uygulayın: izin verilen modeller, uç noktalar, jeton sınırları, ücret sınırları ve bütçe sınırları.
• Ayrı üretim, hazırlama, geliştirme, CI ve iş ortağı erişimi.
• Makineden makineye üretim iş yükleri için hizmet hesabı sahipliğini zorunlu kılın.
• Anahtar düzeyinde kullanım telemetrisini yakalayın ve bunu sağlayıcılar arasında normalleştirin.
• Harcama ani artışları, atıl anahtar etkinlikleri, yeni model kullanımı ve olağandışı ağ kaynakları için anormallik uyarıları ayarlayın.
• Çakışan anahtar rotasyonunu uygulayın ve tamamlamayı merkezi olarak izleyin.
• Sızıntıya müdahale runbook'unu yazın ve test edin.
• İçerik günlük kaydı açıkça onaylanmadığı sürece varsayılan olarak yalnızca meta veri günlük kaydını kullanın.
• Faaliyetsiz, sahipsiz, aşırı izin verilen ve süresi dolmak üzere olan anahtarları yinelenen bir programa göre inceleyin.

Harekete geçirilebilir sonuç

LLM API anahtar yönetiminin hedefi ekipleri yavaşlatmak değildir. Güvenli erişimi kolaylaştırmak ve güvenli olmayan erişimi gereksiz kılmaktır. Paylaşılan sağlayıcı anahtarları belirsiz mülkiyet, kontrolsüz patlama yarıçapı ve yavaş olay müdahalesi yaratır. Yönetilen anahtarlar yönetilebilir bir yaşam döngüsü oluşturur: istekte bulunun, onaylayın, yayınlayın, kapsamlayın, izleyin, döndürün ve iptal edin.

En yüksek riskli alanla başlayın: üretim ve iş ortağı erişimi. Sağlayıcı anahtarlarını kontrollü bir katmanın arkasına koyun, kapsamı belirlenmiş dahili kimlik bilgileri yayınlayın, sahiplik meta verilerini ekleyin ve anahtara göre harcama ve kullanımı izleyin. Bu temel oluşturulduktan sonra aynı modeli geliştirme, CI, değerlendirme ardışık düzenleri ve geçici deneylere kadar genişletin.

En iyi yönetişim sistemi, geliştiricilerin gerçekten kullanabileceği sistemdir: istekte bulunmak hızlıdır, politika açısından anlaşılırdır, varsayılan olarak gözlemlenebilirdir ve bir şeyler ters gittiğinde iptal edilmesi güvenlidir.

İlgili okumalar

• ekip başına LLM maliyet defteri