Ekipler için LLM API Anahtar Yönetimi: İzolasyon, Rotasyon, Harcama Limitleri ve Sızıntıya Müdahale

Paylaşılan bir LLM API anahtarı, ilk sızıntıya, açıklanamayan faturaya veya üretim kesintisine kadar uygundur. API anahtar yönetimi'nin pratik hedefi yalnızca kimlik bilgilerini gizli tutmak değildir. Patlama yarıçapını sınırlamak, kullanımı özniteleştirmek, güvenli bir şekilde döndürmek, anormal harcamaları tespit etmek ve ilgisiz uygulamaları bozmadan erişimi iptal etmektir.

Bu kılavuz, ekiplere sağlayıcılar, ağ geçitleri, dahili uygulamalar, ajanslar ve müşteriye yönelik ürünler genelinde LLM API anahtarları için bir işletim modeli sunar. Doğrulanmış güvenlik gerçeklerini önerilen uygulama seçeneklerinden ayırır ve her sağlayıcının aynı kontrolleri sunduğu varsayımını ortadan kaldırır.

İşletim modeli: her anahtarın bir sınıra ihtiyacı vardır

Yararlı bir anahtar strateji tek bir soruyla başlar: Bu anahtar kötüye kullanılırsa veya iptal edilirse ne başarısız olmalıdır? Cevap "tüm şirket" ise anahtar çok geniş kapsamlıdır.

Fact: OpenAI'in API anahtar güvenlik kılavuzu, her ekip üyesinin benzersiz bir API anahtarı kullanmasını önerir, anahtarları paylaşmanın Kullanım Şartlarına aykırı olduğunu söyler ve desteklendiği yerlerde ayrı ayrı anahtarlara izin atanmasını önerir. OpenAI kılavuzu ayrıca, API anahtarlarının tarayıcılar veya mobil uygulamalar gibi istemci tarafı ortamlarda dağıtılmasına karşı da tavsiyede bulunur; çünkü açığa çıkan anahtarlar, sahibi adına istekte bulunmak için kötüye kullanılabilir.

Öneri: anahtarları kolaylık odaklı değil, operasyonel sınırlar çerçevesinde oluşturun. Ortak sınırlar şunları içerir:

• Ortam: üretim, hazırlama, geliştirme, korumalı alan.
• Uygulama: sohbet robotu arka ucu, belge işlemci, kodlama asistanı, analiz iş akışı.
• Sahip: ekip, hizmet hesabı, geliştirici, ajans müşterisi, kiracı.
• Risk düzeyi: herkese açık iş akışı, dahili otomasyon, toplu iş, deneysel entegrasyon.
• Sağlayıcı veya rota: yukarı akış sağlayıcısı A, sağlayıcı B, onaylı model grubu veya ağ geçidi rotası.

Büyüyen bir ekip için iyi bir varsayılan seçenek şudur: uygulama veya hizmet başına bir üretim anahtarı, ortam başına bir üretim dışı anahtar ve yüksek riskli otomasyon veya müşteri düzeyinde kullanım için ayrı anahtarlar. Ajanslar ve bayiler, yukarı akış sağlayıcı kimlik bilgilerini paylaşmak yerine müşteri düzeyindeki sanal anahtarları tercih etmelidir.

Sağlayıcı anahtarlarını hiçbir zaman dağıtılmış istemcilere koymayın

Tarayıcılar, mobil uygulamalar, masaüstü uzantıları, genel eklentiler ve müşteri tarafı komut dosyaları, ham sağlayıcı kimlik bilgileri için düşmanca yerlerdir. Anahtarı gizleseniz bile dağıtılan yazılım incelenebilir, kopyalanabilir veya ele geçirilebilir.

Gerçek: OpenAI, istemci tarafı ortamlarında API anahtarlarının dağıtılmaması konusunda açıkça uyarıyor. Mobil uygulamalar üzerinde yapılan araştırmalar aynı zamanda iOS uygulamalarında LLM API kimlik bilgisi sızıntısının devam ettiğini de rapor etti ve bu da aynı pratik uyarıyı destekliyor: dağıtılmış istemcilere yerleştirilmiş kimlik bilgileri kaçma eğilimindedir.

Öneri: bir arka uç veya ağ geçidi modeli kullanın:

1. İstemci, bir kullanıcı oturumu, JWT, müşteri belirteci veya kısa ömürlü kimlik bilgilerini kullanarak uygulamanızda kimlik doğrulaması yapar.
2. Arka ucunuz kullanıcıyı, kiracıyı, planı ve istenen işlemi doğrular.
3. Arka uç veya AI API ağ geçidiniz, korumalı sunucu tarafı kimlik bilgilerini kullanarak yukarı akış LLM sağlayıcısını arar.
4. Yanıt, politika kontrolleri, günlük kaydı ve maliyet muhasebesi sonrasında müşteriye geri gönderilir.

Bu tasarım, harcama gerçekleşmeden önce ürün kurallarını uygulamanıza olanak tanır. Örneğin, ücretsiz plan kullanıcısı daha küçük modellerle sınırlandırılabilir, ücretli kiracı daha yüksek günlük kotalar alabilir ve dahili yönetici iş akışı, daha sıkı izlemeyle ayrı bir yol kullanabilir.

Olay yanıtına ihtiyaç duymadan önce önemli bir envanter oluşturun

Ekipler genellikle bir sızıntı sırasında açığa çıkan anahtarın hangi hizmete ait olduğunu kimsenin bilmediğini keşfeder. Bu bir envanter hatasıdır.

Gerçek: OWASP API Güvenlik İlk 10 2023, önemli bir API güvenlik riski olarak uygunsuz envanter yönetimini içerir. LLM altyapısı için anahtar envanter API envanterinin bir parçasıdır: hangi kimlik bilgilerinin mevcut olduğunu, nelere erişebileceğini ve bunların kime ait olduğunu bilmeniz gerekir.

Öneri: her anahtarın meta verileri olmalıdır. En azından şunu takip edin:

• Anahtar adı ve dahili anahtar kimliği.
• Sahip ekip ve acil durumda iletişime geçilecek kişi.
• Ortam: üretim, hazırlama, geliştirme, korumalı alan.
• Amaç: uygulama, iş akışı, kiracı, entegrasyon veya geliştirici kullanımı.
• Desteklendiği yerlerde izin verilen sağlayıcılar, modeller, uç noktalar veya yollar.
• Oluşturulma tarihi, son kullanılan zaman damgası ve planlanan inceleme tarihi.
• Harcama tavanı veya kotası.
• Döndürme durumu ve bağlantılı dağıtım yapılandırması.

Uyarılarda okunabilir durumda kalan bir adlandırma kuralı kullanın. Örneğin:

prod-supportbot-teamcx-gpt4class-2026q3
stg-docprocessor-platform-lowcost-2026q3
tenant-acme-prod-standard-2026q3
dev-jlee-sandbox-2026q3

Tam biçim, tutarlılıktan daha az önemlidir. Amaç, bir uyarının "kiracı-acme-üretim-standartının günlük eşiğini aştığını" bildirebilmesi ve sorumlu sahibin ne yapacağını bilmesidir.

Platformun izin verdiği yerde en az ayrıcalığı uygula

Her sağlayıcı veya ağ geçidi aynı izin denetimlerini sunmaz ancak prensip tutarlıdır: Bir anahtar yalnızca iş yükünün ihtiyaç duyduğu şeyi yapabilmelidir.

Öneri: anahtarları, desteklendiği durumlarda aşağıdaki kontrollerden bir veya daha fazlasıyla kısıtlayın:

• Proje: anahtarları tüm kuruluş yerine bir projeye bağlayın.
• Model: yalnızca onaylı modellere izin verir; pahalı veya deneysel modelleri varsayılan olarak engelleyin.
• Uç nokta: sohbetin tamamlanmasına izin verir ancak ilgisiz yönetim uç noktalarını reddeder.
• Sağlayıcı yolu: her yukarı akış sağlayıcısına doğrudan erişim yerine ağ geçidi yoluna izin verir.
• Oran: dakika başına istek sınırı veya eşzamanlı istekler.
• Bütçe: anahtar başına, ekip başına veya kiracı başına harcama sınırlarını zorunlu kılın.

Örneğin, bir hazırlama anahtarının genellikle en pahalı üretim modeline erişmesine gerek yoktur. Bir belge sınıflandırma çalışanının muhtemelen görüntü oluşturma erişimine ihtiyacı yoktur. Müşteriye yönelik bir kiracı anahtarı, başka bir kiracının bütçesini tüketmemelidir.

Katmanlarda harcama kontrollerini tasarlayın

LLM API güvenliği ve maliyet kontrolü çakışıyor. Sızdırılan bir anahtar, genellikle bir güvenlik olayı olarak algılanmadan önce, bir faturalandırma anormalliği olarak algılanır.

Gerçek: OpenAI hesap güvenliği kılavuzu, makul harcama sınırları önerir ve API anahtarlarını ayıran notların, kullanımın özelliğe, ekibe, ürüne veya projeye göre görüntülenmesini kolaylaştırabileceğini belirtir. OpenAI'nin kullanım raporlaması aynı zamanda proje kimliği, kullanıcı kimliği, API anahtar kimliği, model, toplu iş ve hizmet katmanı gibi alanlar aracılığıyla ayrıntılı analizi de destekler.

Öneri: tek bir genel sınır yerine katmanlı sınırlar kullanın:

• Anahtar başına sınır: tek bir kimlik bilgisinin tüm bütçeyi tüketmesini önler.
• Ekip başına sınır: departman kullanımını görünür ve sorumlu tutar.
• Kiracı başına sınır:, SaaS ve ajans senaryolarında müşteri kullanımını izole eder.
• Günlük anormallik eşiği:, kullanım normal kalıplardan saptığında uyarıları tetikler.
• Genel acil durdurma:, kötüye kullanım etkin olduğunda hızlı bir şekilde askıya alınmasına olanak tanır.

Sabit sınırlar faydalıdır ancak yasal toplu işleri kesintiye uğratabilirler. Daha güvenli bir üretim modeli bir dizi kontrolden oluşur:

1. Beklenen günlük harcamanın yüzde 50'sine ulaştığında uyarı.
2. Yüzde 80 oranında artırın.
3. Kritik olmayan trafiği yüzde 100 oranında kısıtlayın.
4. Genel kapatmayı kullanmadan önce yalnızca rahatsız edici anahtarı, kiracıyı veya rotayı engelleyin.

Ödül: Katı bütçeler faturalandırma riskini azaltır ancak kullanılabilirlik riski yaratabilir. İş yüküne göre katman sınırları: Etkileşimli üretim trafiği, müşteriye yönelik ücretli trafik, arka plan işleri, denemeler ve geliştirici sanal alanlarının hepsi aynı şekilde başarısız olmamalıdır.

Kullanımı anahtar ve mantıksal aktöre göre izleyin

Anahtar, kimlik bilgisini tanımlar. İsteğe neden olan gerçek kullanıcıyı, kiracıyı, özelliği veya iş akışını tanımlamayabilir. Yararlı AI kullanım analizleri için hem teknik hem de iş boyutlarını günlüğe kaydedin.

Öneri: Gizlilik ve politikanın izin verdiği durumlarda her istek için aşağıdaki alanları toplayın:

• İstek kimliği ve zaman damgası.
• API anahtar kimliği veya sanal anahtar kimliği.
• Uygulama, ekip, kiracı, kullanıcı veya iş akışı tanımlayıcısı.
• Sağlayıcı, model, rota ve hizmet katmanı.
• İstem ve tamamlama belirteci sayıları veya eşdeğer kullanım birimleri.
• Tahmini maliyet.
• Gecikme, durum kodu, yeniden deneme sayısı ve hata sınıfı.

Maliyet gözlemlenebilirliğini gereksiz veri toplamaya dönüştürmeyin. Kişisel veriler, müşteri sırları veya düzenlemeye tabi içerik içerebiliyorsa tüm istemleri varsayılan olarak depolamaktan kaçının. Çoğu durumda, karma hale getirilmiş kullanıcı kimlikleri, kiracı kimlikleri, belirteç sayıları ve model adları, ters ibraz ve anormallik tespiti için yeterlidir.

Kesinti olmadan rotasyon: güvenli bir iş akışı

Gerçek: NIST'in anahtar yönetimi kılavuzu, anahtar yönetimini oluşturma, depolama, etkinleştirme, döndürme, askıya alma, iptal etme ve imhayı içeren bir yaşam döngüsü disiplini olarak ele alır. Yüksek Lisans API anahtarları için rotasyon tek seferlik bir güvenlik işi değildir; operasyonel bir iş akışıdır.

Öneri: kesinti olmayan bu rotasyon sürecini kullanın:

1. Yedek anahtarı oluşturun. Gerekli izinleri, bütçeyi, rotayı ve meta verileri eşleştirin. Eski anahtarı henüz iptal etmeyin.
2. Gizli yöneticide saklayın. Yerel dosyalardan, sohbet mesajlarından, destek taleplerinden ve yapıştırılan ortam değişkenlerinden kaçının.
3. Yapılandırmayı aşamalı olarak dağıtın. Tek seferde bir hizmeti, bölgeyi, çalışan grubunu veya kiracı segmentini güncelleyin.
4. Trafik hareketini doğrulayın. İsteklerin yeni anahtar kapsamında ulaştığını ve hata oranları ile gecikmenin normal kaldığını doğrulayın.
5. Eski anahtara yazma işlemlerini dondurun. Yeni dağıtımların ona referans vermesini engelleyin.
6. Eski anahtarı iptal edin. Trafik taşındıktan sonra, onu unutulmuş bir yedek olarak bırakmak yerine devre dışı bırakın.
7. Başıboş olanları denetleyin. Eski anahtar kimliği için günlükleri, dağıtım bildirimlerini, gizli depoları, CI değişkenlerini ve çalışma zamanı hatalarını arayın.

Hala statik ortam değişkenlerini kullanan uygulamalar için döndürme hassas olacaktır. Dinamik gizli yüklemeye, merkezi yapılandırmaya veya ağ geçidi tarafından yönetilen sanal anahtarlara doğru ilerleyin. İptalden önce en azından hangi dağıtımın değişmesi gerektiğini belgeleyin.

Sızıntı yanıtı runbook'u

Bir anahtar sızdırıldığında hız önemlidir. Yanıt, fatura paniğinde doğaçlama değil, olaydan önce yazılmalıdır.

Acil kontrol altına alma

1. Açığa çıkan anahtarı iptal edin veya askıya alın.
2. İptal, üretimin kesintiye uğramasına neden olacaksa önce yenisini yayınlayın ve kritik trafiği hemen değiştirin.
3. Kötüye kullanım hâlâ etkinse rotayı, kiracıyı veya sağlayıcıyı engelleyin.
4. Kötüye kullanımı belirlemek için gereken günlükleri koruyun.

Soruşturma

1. Anahtarın nerede göründüğünü tanımlayın: depo, ön uç paketi, mobil uygulama, günlük dosyası, destek bileti, tedarikçi aracı veya sohbet.
2. Bilinen son yasal kullanımı bulun.
3. Şüphelenilen maruziyetten önceki ve sonraki kullanımı karşılaştırın.
4. Kullanılan modelleri, istek hacmini, maliyeti, varsa coğrafyayı ve olağandışı durum kodlarını inceleyin.
5. Bağımlı sırların veya bitişik sistemlerin de açığa çıkıp çıkmayacağını kontrol edin.

Kurtarma ve önleme

1. Aynı ortamın birden fazla sırrı sızdırmış olması durumunda bağımlı kimlik bilgilerini döndürün.
2. Uygun olduğunda sahip ekibini ve etkilenen müşteri paydaşlarını bilgilendirin.
3. Depolara ve CI ardışık düzenlerine gizli tarama ekleyin.
4. İstemci tarafındaki çağrıları bir arka uç veya ağ geçidinin arkasına taşıyarak yinelenmeyi önleyin.
5. Olayın zaman çizelgesini, temel nedenini, maliyet etkisini ve kontrol iyileştirmelerini belgeleyin.

Tahmin: Ekipler daha fazla aracıyı, eklentiyi, otomasyon aracını ve müşteriye özel iş akışlarını LLM'lere bağladıkça, önemli sızıntılar giderek daha fazla önce maliyet olayları, sonra da güvenlik olayları gibi görünecek. Anahtar başına ilişkilendirme ve bütçe kontrollerine sahip ekipler, sorunları tek bir paylaşılan kimlik bilgisi kullanan ekiplere göre daha hızlı çözecektir.

Çok sağlayıcılı ekipler için ağ geçidi tarafından yönetilen anahtarlar

Kuruluşunuz birden fazla LLM sağlayıcısı kullanıyorsa, doğrudan sağlayıcı anahtarları dağınık yönetim oluşturabilir: farklı kontrol panelleri, farklı faturalandırma görünümleri, farklı izin modelleri ve tutarsız rotasyon süreçleri.

Ağ geçidi tarafından yönetilen bir anahtar katmanı, uygulamaya yönelik anahtarlar verirken yukarı akış sağlayıcı kimlik bilgilerini gizli tutarak bunu basitleştirebilir. Uygulamalar OpenAI-uyumlu API uç noktasını çağırırken ağ geçidi yönlendirmeyi, kullanım analizini, faturalandırma ilişkilendirmesini ve politika uygulamasını yönetir.

Öneri: Aşağıdakilere ihtiyacınız olduğunda bir ağ geçidi veya proxy katmanı kullanmayı düşünün:

• Birden fazla sağlayıcıdaki ekip anahtarlarını yönetebileceğiniz tek yer.
• Birleşik AI API faturalandırma ve anahtar başına harcama raporlama.
• Ajanslar, bayiler veya SaaS kiracıları için müşteri düzeyinde sanal anahtarlar.
• Merkezi model izin verilenler listeleri, rota politikaları ve acil durum askıya alma.
• Kiracıya, özelliğe, iş akışına veya iş ortağı müşterisine göre kullanım ilişkilendirmesi.

Ödül: Ağ geçidi, yönetimi iyileştirir ve yukarı akış kimlik bilgilerini gizler, ancak istek yolunun bir parçası haline gelir. Üretim altyapısı gibi izleyin: Gecikme, kullanılabilirlik, hata oranları, sıraya alma, yeniden deneme davranışı ve sağlayıcıya özgü hatalar hepsi önemlidir.

Uygulama kontrol listesi

• Kuruluş çapında paylaşılan anahtarları uygulama, ortam, kiracı veya iş akışına göre kapsamı belirlenen anahtarlarla değiştirin.
• Tarayıcılardan, mobil uygulamalardan, masaüstü uzantılarından ve genel komut dosyalarından ham sağlayıcı anahtarlarını kaldırın.
• İstemci isteklerini bir arka uç veya AI API ağ geçidi üzerinden yönlendirin.
• Her anahtara sahip, amaç, ortam, izin verilen modeller, bütçe ve inceleme meta verilerini ekleyin.
• En az ayrıcalığı uygulayın: mümkün olduğunda proje, uç nokta, model, rota, ücret ve bütçe kontrolleri.
• Anahtar başına, ekip başına, kiracı başına ve genel harcama sınırlarını belirleyin.
• Günlük anahtarı kimliği, mantıksal aktör, model, jeton kullanımı, tahmini maliyet, gecikme ve durum kodu.
• Kesintisiz bir rotasyon iş akışı oluşturun ve bunu acil bir durumdan önce test edin.
• Muhafaza etme, inceleme ve önleme adımlarını içeren bir sızıntıya müdahale runbook'u yazın.
• Etkin olmayan anahtarları inceleyin ve sahibi olmayan veya yakın zamanda meşru kullanımı olmayan her şeyi iptal edin.

Harekete geçirilebilir sonuç

En yüksek riskli anahtarla başlayın: Üretimde kullanılan, birden fazla kişi tarafından paylaşılan, çok fazla yere yerleştirilmiş veya en büyük harcamadan sorumlu olan anahtar. Ona bir sahip verin, sınırlara göre bölün, bir bütçe ekleyin, müşterilerin görebileceği bir arka uç veya ağ geçidinin arkasına taşıyın ve nasıl döndürüleceğini belgeleyin.

Sonra tekrarlayın. Güçlü LLM API anahtar yönetimi tek bir gizli depolama kararı değildir. Bu bir yaşam döngüsüdür: envanter, izolasyon, en az ayrıcalık, kullanım ilişkilendirme, maliyet kontrolü, rotasyon ve sızıntı müdahalesi. Bunun getirisi basit: Bir şeyler ters gittiğinde yalnızca bir uygulama, kiracı veya iş akışı risk altında olmalıdır; AI bütçesinin tamamı değil.

İlgili okumalar

• üretim LLM API yönlendirme ve geri dönüş tasarımı
• earlier Model Gate blog notlar
• giriş Model Gate makale