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 kullanışlıdır. API anahtar yönetiminin pratik hedefi yalnızca kimlik bilgilerini gizli tutmak değildir. Patlama yarıçapını sınırlamak, kullanımı niteliklendirmek, 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 olur? Cevap "tüm şirket" ise anahtar çok geniş kapsamlı demektir.

Gerçek: OpenAI'nin API anahtarı güvenliği 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ı anahtarlara izin atanmasını önerir. OpenAI'nin 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 bulunuyor; çünkü açığa çıkan anahtarlar, sahibi adına istekte bulunmak için kötüye kullanılabilir.

Öneri: Anahtarları kolaylık etrafında değil, operasyonel sınırlar etrafında 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: halka 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 üzerine yapılan araştırmalar da iOS uygulamalarında LLM API kimlik bilgilerinin sürekli olarak sızdırıldığını bildirdi 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 süreli kimlik bilgilerini kullanarak uygulamanızda kimlik doğrulaması yapar.
2. Arka ucunuz kullanıcıyı, kiracıyı, planı ve talep edilen 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 müdahalesine 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üvenliği İlk 10 2023, önemli bir API güvenlik riski olarak uygunsuz envanter yönetimini içermektedir. Yüksek Lisans altyapısı için anahtar envanteri, 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 izleyin:

• 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 rotalar.
• Oluşturulma tarihi, son kullanılan zaman damgası ve planlanan inceleme tarihi.
• Tavanı veya kotayı harcayın.
• 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-2026q3stg-docişlemci-platformu-düşükmaliyet-2026q3
kiracı-acme-prod-standart-2026q3
dev-jlee-sandbox-2026q3

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

Platformun izin verdiği durumlarda en az ayrıcalığı uygulayın

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: desteklendiğinde anahtarları 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ı rotası: her yukarı akış sağlayıcısına doğrudan erişim yerine ağ geçidi rotasına izin verin.
• 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 kontrolleri tasarlama

LLM API güvenliği ve maliyet kontrolü örtüşü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 ayrı API anahtarlarının kullanımın özelliğe, ekibe, ürüne veya projeye göre görüntülenmesini kolaylaştırabileceğine dair notlar verir. OpenAI'nin kullanım raporlaması ayrıca 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: 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ı 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 durum durdurma:, kötüye kullanım etkin olduğunda hızlı bir şekilde askıya alınmasına olanak tanır.

Sert 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'si konusunda uyarı.
2. Yüzde 80'e yükselt.
3. Kritik olmayan trafiği yüzde 100 oranında kısın.
4. Genel kapatmayı kullanmadan önce yalnızca sorun yaratan anahtarı, kiracıyı veya rotayı engelleyin.

Ödül: Sıkı bütçeler faturalandırma riskini azaltır ancak kullanılabilirlik riski oluşturabilir. İş yüküne göre katman sınırları: Etkileşimli üretim trafiği, müşteriye yönelik ücretli trafik, arka plan işleri, deneyler 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

Bir 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ı yapay zeka 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:

• Kimlik ve zaman damgasını isteyin.
• 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 oluşturma işlemi uygulanmış kullanıcı kimlikleri, kiracı kimlikleri, jeton 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, rotasyon, askıya alma, iptal etme ve imhayı içeren bir yaşam döngüsü disiplini olarak ele alır. LLM 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. Yeni 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 yazılanları 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ırdığı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ı tanımlamak 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, satıcı 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önüşümlü olarak kullanı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 ilk önce maliyet olayları, ikinci olarak da güvenlik olayları gibi görünecek. Anahtar başına ilişkilendirme ve bütçe kontrollerine sahip ekipler, bu 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 bir 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ırması ve anahtar başına harcama raporlaması.
• 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: Bir 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ü arızaların 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 aracılığıyla 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ı ayarlayın.
• 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.
• Çevreleme, araştırma 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, AI bütçesinin tamamı değil, yalnızca bir uygulama, kiracı veya iş akışı risk altında olmalıdır.

İlgili okumalar

• üretim LLM API yönlendirmesi ve geri dönüş tasarımı
• önceki Model Gate blog notları
• Model Gate'e giriş makalesi