AI API'leri için API Anahtar Yönetimi: Güvenlik, Rotasyon, Harcama Limitleri ve Olay Müdahalesi

API anahtar yönetimi artık küçük bir kontrol paneli görevi değil. AI API'leri kullanan ekipler için bu; bilgi istemleri gönderen, model çıktısı alan, araçları çağıran veya ölçülü çıkarım için para harcayan her uygulamaya yönelik güvenlik, maliyet ve operasyon modelinin bir parçasıdır.

Birçok ekip, yerel ortam dosyasındaki bir sağlayıcı anahtarıyla başlar. Bu, aynı anahtar CI değişkenlerinde, not defterlerinde, IDE uzantılarında, aracılarda, toplu işlerde, müşteri entegrasyonlarında ve destek komut dosyalarında görünene kadar işe yarar. Bu noktada sızdırılan anahtar yalnızca bir kimlik doğrulama sorunu değildir. İstemleri ve yanıtları açığa çıkarabilir, beklenmedik ücretleri tetikleyebilir, premium modelleri çağırabilir, uygulama yetkisiyle araçları çalıştırabilir veya olaylara müdahaleyi tahmine dayalı hale getirebilir.

Bu kılavuz, API anahtar yönetimini bir yaşam döngüsü olarak ele alır: anahtarların nasıl tasarlandığı, yayınlandığı, depolandığı, kapsamının belirlendiği, izlendiği, döndürüldüğü ve iptal edildiği. Alışılagelmiş API güvenliği endişelerinin model erişimi, jeton tabanlı harcama, çoklu sağlayıcı kimlik bilgileri, müşteri ilişkilendirmesi ve OpenAI uyumlu istemcilerle birleştiği AI API erişimine odaklanır.

API anahtarlarının API güvenliğine uygun olduğu yer

Bir API anahtarı genellikle bir kimlik bilgisine sahip olunduğunu kanıtlar. "Bu arayanın geçerli bir sırrı var mı?" sorusunu yanıtlıyor. Önemli olan her yetkilendirme sorusunu tek başına yanıtlamaz.

Arka ucun yine de arayanın belirli bir kiracıya, nesneye, modele, uç noktaya, araca, çalışma alanına, rapora veya yönetim işlevine erişip erişemeyeceğine karar vermesi gerekir. OWASP API Güvenliği Bozuk nesne düzeyinde yetkilendirme, bozuk kimlik doğrulama, sınırsız kaynak tüketimi ve bozuk işlev düzeyinde yetkilendirme gibi ilk 10 risk, geçerli bir kimlik bilgisinin sistemin yalnızca bir katmanı olduğunu hatırlatır.

AI API'leri için bu ayrım önemlidir çünkü aynı anahtar çok farklı risk profilleriyle eylemler gerçekleştirebilir. Dahili bir iş akışı için düşük maliyetli bir metin modelini çağırabilen bir anahtarın otomatik olarak premium modelleri çağıramaması, toplu işler oluşturamaması, başka bir kiracının verilerine erişememesi, e-posta gönderen araçları çağıramaması veya faturalandırma ayarlarını yönetememesi gerekir.

Dayanıklı bir API güvenlik modeli üç kaygıyı birbirinden ayırır:

• Kimlik doğrulama: isteğin geçerli bir kimlik bilgisi, belirteç veya oturuma sahip olduğunu kanıtlama.
• Yetkilendirme: kimliği doğrulanmış arayanın mevcut kiracı, ortam ve iş bağlamında ne yapabileceğine karar vermek.
• Yönetim: harcamayı, oranı, model erişimini, veri erişimini ve yönetim kontrolünü sınırlandırarak tek bir hatanın sınırlı bir patlama yarıçapına sahip olmasını sağlar.

API anahtarları faydalıdır, ancak hassas veya yüksek değerli kaynakları koruyan tek kontrol bunlar olmamalıdır. Bunları HTTPS, sunucu tarafı yetkilendirme kontrolleri, denetim günlükleri, en az ayrıcalık, oran sınırları, harcama sınırları ve güvenli gizli işleme ile kullanın.

Canlı bir API anahtar envanteriyle başlayın

Adlandıramadığınız anahtarları yönetemezsiniz. İlk pratik adım, AI sistemleriniz tarafından kullanılan her API anahtarının ve kimlik bilgisi benzeri nesnelerin canlı bir envanteridir.

Her anahtar kaydı en azından bir anahtar kimliği, geri alınamayan bir karma veya parmak izi, sahip, oluşturucu, ekip veya kiracı, ortam, iş yükü, kapsamlar, izin verilen modeller, izin verilen uç noktalar, harcama politikası, ücret politikası, geçerli olduğu durumlarda IP kısıtlamaları, durum, oluşturma zamanı, son kullanma tarihi, son kullanılan zaman damgası, rotasyon grubu ve denetimi içermelidir. meta veriler.

Envanter, üretim çalışma zamanı anahtarlarından daha fazlasını kapsamalıdır. Kişisel geliştirici anahtarlarını, hizmet hesabı anahtarlarını, CI/CD anahtarlarını, çalışma alanı anahtarlarını, müşteri veya kiracı anahtarlarını, bayi tarafından yönetilen anahtarları, faturalama/raporlama anahtarlarını, yönetim API kimlik bilgilerini ve yukarı akış sağlayıcı kimlik bilgilerini içerir.

En önemli alanlar sahiplik, amaç, kapsam, son kullanım ve sınır politikasıdır. Bunlar olmadan gelecekteki tüm güvenlik görevleri daha yavaş hale gelir: çıkarma, rotasyon, sızıntı müdahalesi, maliyet araştırması ve müşteri desteği.

Anahtar sınırları bilinçli olarak tasarlayın

API anahtar yönetiminin en büyük hatası, çok fazla sınır boyunca tek bir anahtar kullanmaktır. Paylaşılan bir üretim anahtarı ilk başta uygundur, ancak ilişkilendirmeyi yok eder ve iptali zorlaştırır. Sızıntı olması durumunda, soruna hangi iş yükünün neden olduğunu hâlâ belirleyemeseniz de her hizmet için trafiği durdurmak zorunda kalabilirsiniz.

İşin ve yazılımın şeklini iyi temel sınırlar takip eder. Üretimi geliştirmeden, insanları hizmetlerden, müşterileri dahili ekiplerden, kiracıları birbirinden, çalışma zamanı kimlik bilgilerini yönetici kimlik bilgilerinden ve ağ geçidi tarafından verilen müşteri anahtarlarını yukarı akış sağlayıcı anahtarlarından ayırın.

Ortam sınırları

Geliştirme, hazırlama ve üretim ayrı anahtarlar kullanmalıdır. Bir geliştirme anahtarı üretim verilerine veya üretim bütçelerine ulaşmamalıdır.Sıkı bir şekilde kontrol edilen bir neden olmadığı sürece bir aşamalandırma anahtarının canlı müşteri iş yüklerine erişimi olmamalıdır.

İş yükü sınırları

Her hizmet, toplu iş, aracı filosu, entegrasyon veya zamanlanmış görevin kendi anahtarı veya hizmet hesabı olmalıdır. Bu, hangi iş yükünün parayı harcadığı, hangi hizmetin kimlik doğrulamada başarısız olmaya başladığı, hangi entegrasyonun kullanımdan kaldırılmış bir model kullandığı ve bir olay sırasında hangi anahtarın dondurulması gerektiği gibi temel soruları yanıtlamanıza olanak tanır.

Kiracı ve müşteri sınırları

Çok kiracılı sistemler ilişkilendirmeye ve izolasyona ihtiyaç duyar. İstemleri göndermek için müşteriye yönelik bir API anahtarı kullanılıyorsa, istek müşteriye, kiracıya, uygulamaya ve ideal olarak takma adlı bir son kullanıcıya veya aktöre bağlanmalıdır. Bir kiracı için güvenliği ihlal edilmiş bir anahtar, başka bir kiracının verilerine, model profiline, bütçesine veya günlüklerine erişime izin vermemelidir.

Sağlayıcı kimlik bilgisi sınırları

Geliş yönündeki sağlayıcı anahtarları, müşterilerinize veya dahili uygulamalara verdiğiniz anahtarlardan farklıdır. Sağlayıcı kimlik bilgileri sunucu tarafında kalmalı, bir kasada veya gizli yöneticide saklanmalı ve asla tarayıcılara, mobil uygulamalara, masaüstü istemcilere, genel not defterlerine veya müşteri tarafından kontrol edilen ortamlara gönderilmemelidir.

Bir ağ geçidi, müşteriye yönelik bir anahtar yüzeyini açığa çıkarırken aynı zamanda yukarı akış sağlayıcı kimlik bilgilerini ağ geçidinin arkasında tutarak bu konuda yardımcı olabilir. Bu, sağlayıcılar arasında kullanım analitiğini, iptali, ekip kontrollerini ve politika uygulamasını merkezileştirmeyi mümkün kılar. İstemcileri OpenAI uyumlu bir API çerçevesinde standartlaştırıyorsanız, çoğu araç tek bir temel URL ve taşıyıcı jeton beklediğinden ağ geçidi sınırı özellikle önem kazanır.

Modellere, uç noktalara, araçlara ve harcamalara en az ayrıcalığı uygulayın

En az ayrıcalık, bir anahtarın yalnızca iş yükü için gereken erişime sahip olması gerektiği anlamına gelir. Yapay zeka sistemleri için kapsam yalnızca API uç noktalarının bir listesi değildir. Aynı zamanda modeller, araçlar, belirteç bütçeleri, ücret sınırları, kiracılar, veri sınıfları ve yönetim işlevlerini de içerir.

Pratik bir AI API anahtar politikası şunları içerebilir:

• İzin verilen model aileleri veya belirli model kimlikleri.
• Sohbet tamamlamalar, yerleştirmeler, toplu işler veya görüntü oluşturma gibi izin verilen uç noktalar.
• İzin verilmeyen yönetim API'leri, anahtar yönetimi API'leri, faturalandırma API'leri ve çalışma zamanı anahtarları için çalışma alanı yönetimi API'leri.
• dakika başına istekler ve dakika başına belirteçler için anahtar başına hız sınırları.
• Kiracı başına, ekip başına veya müşteri başına harcama sınırları.
• Premium model, düşük riskli bir iş akışının aniden en pahalı modeli kullanamayacağı şekilde kontrol eder.
• Bir anahtarın harici bağlayıcıları, kod yürütmeyi, alma sistemlerini veya işi çağırıp çağıramayacağı gibi araç izinleri. eylemler.
• Ağ yolunun öngörülebilir olduğu, kararlı sunucu tarafı iş yükleri için IP izin verilenler listeleri.

Harcama kontrolü, ölçülü AI API'leri için API güvenliğinin bir parçasıdır. Sızdırılan bir anahtar, hassas verilere hiç erişmese bile doğrudan mali zarara neden olabilir. Oran limitleri yardımcı olur ancak yeterli değildir. Belirteç hacmi, yeniden denemeler, toplu işler, araç çağrıları ve model seçiminin tümü maliyeti etkiler. Güvenli bir uygulama, oran kontrollerini harcama tavanları, model izin verilenler listeleri, anormallik tespiti ve acil durum dondurma kontrolleriyle birleştirmelidir.

Model maliyetini ve erişim politikalarını karşılaştıran ekipler, güvenlik ve finansı uyumlu tutmalıdır. Model fiyatlandırması yalnızca bir satın alma sorunu değildir; güvenliği ihlal edilmiş veya yanlış yapılandırılmış bir anahtarın ne kadar harcama yapabileceğini belirler. Onaylanmış model profillerini bütçelere bağlı tutun ve model karışımınız değiştiğinde, özellikle de iş yüklerini maliyet ve yeteneğe göre yönlendirmek için AI modeli fiyatlandırmasını kullanırken bunları gözden geçirin.

Gizli dizileri ait oldukları yerde saklayın

API anahtarları, gizli dizi yöneticilerine, sunucu tarafı yapılandırmasına, kontrollü CI/CD değişkenlerine veya kasa destekli bir ağ geçidine aittir. Kaynak koduna, tarayıcı JavaScript'ine, mobil paketlere, masaüstü uygulama paketlerine, genel not defterlerine, ekran görüntülerine, sohbet mesajlarına, analiz yüklerine, destek bildirimlerine veya günlüklere ait değildirler.

İstemci tarafının açığa çıkması yaygın bir hata modudur. Sağlayıcı anahtarı bir tarayıcıya veya mobil uygulamaya yerleştirilmişse, uygulamayı inceleyebilen herkes onu çıkarabilir ve hesap sahibi adına istekte bulunabilir. Kontrolsüz ortamlarda çalışan tarayıcılar, mobil uygulamalar, IDE filoları ve aracılar için sunucu tarafı proxy'yi veya dar kapsamlı kısa ömürlü temsilci kimlik bilgilerini kullanın. Uzun ömürlü sağlayıcı kimlik bilgilerini kontrol edemediğiniz istemcilere dağıtmayın.

CI/CD'nin de aynı disipline ihtiyacı vardır. Anahtarları korumalı değişkenler olarak saklayın. Bunları kimlerin okuyabileceğini veya değiştirebileceğini kısıtlayın. Derleme günlüklerinde ortam değişkenlerini yazdırmaktan kaçının. Başarısız istek dökümlerindeki Yetkilendirme başlıklarını düzenleyin. Önizleme dağıtımlarını ve çatallı çekme isteklerini, korumalı üretim hatlarından farklı güven bölgeleri olarak ele alın.

Günlükler ve gözlemlenebilirlik sistemleri, özel ilgiyi hak eder.Anahtar parmak izlerini, istek kimliklerini, kiracı kimliklerini, model kimliklerini, yanıt durumunu, belirteç sayaçlarını, maliyet sayaçlarını, uygun olduğunda IP veya istemci meta verilerini ve politika kararlarını saklayın. Tam API anahtarlarını saklamayın. İzlemelerdeki gizli bilgileri, ters proxy günlüklerini, istisna raporlarını, web kancası yüklerini, destek araçlarını, analiz olaylarını ve atılacak ileti kuyruklarını düzeltin.

Acil durumdan önce rotasyon oluşturun

Rotasyon yalnızca bir anahtarı silip yenisini oluşturmak değildir. Dağıtılan hizmetler hâlâ eski anahtara bağlıysa silme işlemi kesintiye neden olur. Güvenilir bir rotasyon sürecinde örtüşme, gözlem ve net bir kullanımdan kaldırma noktası kullanılır.

Ortak bir model, iki aktif slota sahip bir rotasyon grubudur. Yeni anahtarı oluşturun, bağımlı tüm sistemlere dağıtın, eski anahtarın son kullanımını gözlemleyin, trafik hareket ettiğinde eski anahtarı dondurun ve bir güven penceresinden sonra onu silin. Geri alma kurallarını açık tutun: Eski anahtar ne zaman yeniden etkinleştirilebilir, bunu kim onaylayabilir ve ne kadar süreyle kullanılabilir durumda kalabilir?

Kısa anahtar yaşam süreleri eski kimlik bilgileri riskini azaltır ancak operasyonel yükü artırır. Uzun ömürlü anahtarlar dağıtım kaybını azaltır ancak unutulan kimlik bilgileri ve çalışanların işten ayrılma boşlukları için daha büyük bir pencere oluşturur. Doğru politika iş yüküne bağlıdır. Yüksek değerli bir üretim hizmeti hesabı, otomasyonla sabit bir programa göre rotasyona tabi tutulabilir. Geçici bir geliştirici anahtarının süresi kısa sürede dolacaktır. Müşteri tarafından yönetilen bir entegrasyon, daha uzun bir geçiş aralığına ve net kullanımdan kaldırma mesajlarına ihtiyaç duyabilir.

Her anahtarı aynı şekilde döndürmeyin. Anahtarları listeleyebilen, oluşturabilen, silebilen veya değiştirebilen yönetici kimlik bilgileri, çalışma zamanı çıkarım anahtarlarından daha yüksek risk taşır ve daha güçlü denetimlere, daha dar erişime ve daha agresif izlemeye sahip olmalıdır. Çalışma zamanı anahtarları, incelenen belirli bir neden olmadığı sürece idari yetki taşımamalıdır.

Sızıntıları ve anormal kullanımı tespit edin

Sızıntı tespiti, birden fazla sistem birbirini desteklediğinde en iyi sonucu verir. Kaynak kontrollü gizli tarama, depolara gönderilen anahtarları yakalayabilir. CI kontrolleri, birleştirme öncesinde bariz sızıntıları engelleyebilir. Özel desenler dahili anahtar formatlarını algılayabilir. Sağlayıcı kontrol panelleri olağandışı etkinlikleri ortaya çıkarabilir. Ağ geçidi telemetrisi yeni IP'leri, yeni coğrafyaları, başarısız kimlik doğrulama patlamalarını, ani harcama hızını veya beklenmedik modellere yapılan çağrıları gösterebilir.

Kullanışlı güvenlik kontrol panelleri arasında hareketsiz anahtarlar, sahipsiz anahtarlar, sınırsız anahtarlar, süresi dolmak üzere olan anahtarlar, yeni ağlardan kullanılan anahtarlar, hızlı jeton büyümesine sahip anahtarlar, hala trafik alan donmuş anahtarlar, başarısız kimlik doğrulama patlamaları ve harcama tavanlarına yaklaşan müşteri anahtarları yer alır.

Algılama ayrıca günlükleri ve eşzamansız sistemleri de kapsamalıdır. Web kancaları, arka plan işleri, kuyruklar ve gecikmeli tamamlamalar, istek kimliklerine ve orijinal anahtar ilişkilendirmesine ihtiyaç duyar. Aksi takdirde, şüpheli bir geri çağırmanın veya toplu sonucun, onu oluşturan anahtara ve kiracıya bağlanması imkansız olabilir.

Git geçmişinde bir sır göründüğünde, onu depodan kaldırmak yeterli değildir. Depoya, derleme günlüklerine, aynalara, çatallara, paket yapılarına veya önbelleğe alınmış sayfalara erişen herkes anahtarı zaten kopyalamış olabilir. Kimlik bilgilerinin geçersiz kılınması veya dondurulması ve ardından değiştirilmesi gerekir.

Güvenliği ihlal edilmiş bir API anahtarına yanıt verme

İyi bir olay yanıt planı kısa, prova edilmiş ve spesifiktir. İlk karar genellikle dondurmak mı yoksa iptal etmek mi olduğudur. Dondurma, kaydı soruşturma için korurken trafiği hızlı bir şekilde durdurur. İptal, anahtarı kalıcı olarak devre dışı bırakır. Bazı ekipler denetim sürekliliğine ve anında geri alma seçeneklerine ihtiyaç duyduklarında önce dondurmayı kullanır; diğerleri ise onaylanmış kamuya açık sızıntılar için otomatik olarak iptal eder. Her iki yaklaşımın da otomasyona ve açık yetkiye ihtiyacı vardır.

Pratik bir yanıt akışı şuna benzer:

1. Şüphelenilen anahtarı önem derecesi ve güvene göre dondurun veya iptal edin.
2. Sahibi, kiracıyı, iş yükünü, kapsamları, model erişimini, harcama politikasını ve son kullanılan zaman çizelgesini tanımlayın.
3. Olağandışı istemler, modeller, uç noktalar, araçlar, IP'ler, belirteç hacmi ve maliyetin kullanımını inceleyin.
4. Etkilenenleri değerlendirin veriler, kiracılar, aşağı yönlü işlemler ve faturalandırma etkisi.
5. Düzeltilmiş kapsam ve sınırlara sahip bir yedek anahtar yayınlayın.
6. Kaydedilmiş gizli kod, açığa çıkan günlük, aşırı geniş CI değişkeni veya istemci tarafı paketi gibi temel nedeni kaldırın.
7. Gizli tarama, günlük düzenleme, daha dar kapsamlar, daha kısa süre sonu veya harcama uyarıları gibi bir önleme kontrolü ekleyin.
8. Olayı belgeleyin ve güncelleyin runbook'lar.

Değiştirme adımı aynı riski yeniden yaratmamalıdır. Bir anahtar on hizmet arasında paylaşıldığı için sızdırıldıysa onu ayrı hizmet hesabı anahtarlarıyla değiştirin. Günlüklere sızdıysa yeni bir anahtar vermeden önce günlüğü düzeltin. Her modeli arayabileceği için fazla harcama yaptıysa, model izin verilenler listeleri ekleyin ve harcama limitleri ekleyin.

Ağ geçidi tarafından yönetilen anahtarlar ve çok sağlayıcılı yapay zeka erişimi

Yapay zeka ekipleri genellikle birden fazla model sağlayıcı kullanır.Her sağlayıcının kendi anahtar modeli, çalışma alanı yapısı, hız sınırları, model adları, fiyatlandırması ve yönetim API'leri vardır. Her sağlayıcı anahtarının doğrudan her uygulamada yönetilmesi operasyonel riski artırır.

Ağ geçidi tarafından yönetilen bir anahtar modeli bu karmaşıklığı azaltabilir. Uygulamalar ağ geçidini müşteriye yönelik veya dahili bir anahtarla çağırır. Ağ geçidi arayanın kimliğini doğrular, kiracı politikasını uygular, modeli uygular ve harcama kontrollerini uygular, kullanımı kaydeder ve sunucu tarafında yukarı akış sağlayıcı kimlik bilgilerini kullanır. Bu, çok modelli uygulamalar, dahili platformlar, ajanslar ve bayi hizmetleri için kullanışlıdır.

Model Gate için ağ geçidi rolünün önemli olduğu yer burasıdır: müşteriye yönelik merkezi anahtarlar, birleştirilmiş kullanım analitiği, ekip kontrolleri, harcama sınırları, IP güvenliği, Telegram operasyonel entegrasyonları, İş Ortağı API otomasyonu ve kötüye kullanım yanıtı. Müşterilerin veya alt hizmetlerin temel hazırlığını yapan işletmeler için İş Ortağı API otomasyonu, manuel yerine anahtar oluşturmayı, güncellemeleri sınırlandırmayı, dondurmayı ve bayi iş akışlarını tutarlı hale getirebilir.

Ağ geçidi, uygulama ekibinin tüm sorumluluğunu ortadan kaldırmaz. Hala güvenli depolamaya, arka uç yetkilendirmesine, kiracı izolasyonuna, uç nokta tasarımına, CI/CD hijyenine, hızlı ve yanıt veri politikasına ve mevcut olduğunda sağlayıcı tarafı kısıtlamalarına ihtiyacınız var. Ağ geçidi, yüksek değere sahip bir kontrol düzlemi haline gelir ve bu nedenle güçlü kasaya alma, denetim günlükleri, erişim kontrolleri, kullanılabilirlik planlaması ve yönetim ayrımı gerektirir.

Yaygın API anahtar yönetimi hataları

En yaygın hatalar tahmin edilebilirdir. Ekipler sağlayıcı anahtarlarını doğrudan istemci uygulamalarına koyar. Her hizmet ve müşteri için bir üretim anahtarı kullanırlar. Önce silerek, sonra konuşlandırarak dönüşümlü olarak çalışırlar. Sahibi, sınırı, kapsamı veya geçerlilik süresi olmayan anahtarlar oluştururlar. Yetkilendirme başlıklarının tamamını günlüğe kaydederler. Yapay zeka maliyet kontrolü için yalnızca oran sınırlarına güveniyorlar. Çalışma zamanı hizmetleri yönetici kimlik bilgilerini verirler. Sızan bir anahtarı iptal etmeden Git'ten kaldırırlar. Çalışanları işten çıkarıyorlar ancak kişisel anahtarları, yerel ortam dosyalarını ve CI değişkenlerini aktif bırakıyorlar.

Bir diğer ince hata ise bilgi istemi ve yanıt günlüğünü tamamen işlevsel olarak ele almaktır. Ayrıntılı günlükler kötüye kullanımın araştırılmasına yardımcı olabilir ancak aynı zamanda kişisel veriler, müşteri içeriği, sırlar veya yasal düzenlemelere tabi bilgiler de içerebilir. Meta veri öncelikli günlük kaydı genellikle daha güvenlidir: varsayılan olarak anahtar parmak izlerini, model kimliklerini, belirteç sayılarını, maliyetleri, durum kodlarını, politika kararlarını ve istek kimliklerini yakalayın, ardından daha derin hata ayıklama verileri için kontrollü erişim gerektirir.

Uygulama kontrol listesi

Güçlü bir API anahtar yönetimi programı odaklanmış bir kontrol listesiyle başlayabilir:

• Tüm anahtarların, sahiplerin, ortamların, kiracıların, kapsamların, sınırların ve son kullanımın bir envanterini oluşturun zaman damgaları.
• Anahtarları ortama, iş yüküne, kiracıya, müşteriye ve kimlik bilgisi sınıfına göre ayırın.
• Sağlayıcı kimlik bilgilerini sunucu tarafına ve tarayıcıların, mobil uygulamaların, not defterlerinin ve genel istemcilerin dışına taşıyın.
• Modeller, uç noktalar, araçlar, kiracılar, bütçeler ve yönetim işlevleri için en az ayrıcalığı kullanın.
• Harcama sınırları, oran sınırları, model izin verilenler listeleri, anormallik uyarıları ve acil durum dondurma ekleyin kontrolleri.
• Gizli bilgileri gizli bir yöneticide, kasada, korumalı CI değişken deposunda veya ağ geçidi tarafından yönetilen kimlik bilgisi sisteminde saklayın.
• Günlüklerden, izlemelerden, analizlerden, destek araçlarından, web kancalarından ve hata raporlarından gizli bilgileri çıkarın.
• Çakışan anahtarlar, son kullanım izleme, dondurma ve son silme ile rotasyon uygulayın.
• Özel anahtar dahil olmak üzere depolarda ve CI/CD'de gizli taramayı entegre edin kalıplar.
• Kişisel anahtarlar, hizmet hesapları, çalışma alanı anahtarları ve müşteri anahtarları için ayrılma davranışını belgeleyin.
• Çalışma zamanı çıkarım kimlik bilgilerini yönetici sağlayıcı kimlik bilgilerinden ayrı tutun.
• Gerçek bir sızıntı süreci zorlamadan önce olay müdahalesini test edin.

Sonuç

AI API'leri için API anahtar yönetimi, kimliği, yetkiyi, maliyeti ve operasyonel patlama yarıçapını kontrol etmekle ilgilidir. Güvenli anahtar yalnızca rastgele bir dize değildir. Sahibi, amacı, kapsamı, ortamı, bütçesi, geçerlilik sonu, rotasyon yolu, denetim takibi ve olay müdahale planı vardır.

Pratik amaç, her talebin etrafında bürokrasi oluşturmak değildir. Normal çalışmayı daha güvenli hale getirmektir: Geliştiriciler oluşturabilir, hizmetler çalıştırabilir, müşterilerin temel hazırlığını yapabilir ve güvenlik ekipleri bir anahtar sızdırıldığında veya harcamalarda ani artışlar olduğunda ne olduğuna yanıt verebilir. Envanter ve sınırlarla başlayın, ardından en az ayrıcalık, güvenli depolama, rotasyon, izleme ve yanıt otomasyonunu ekleyin. Çoklu sağlayıcılı yapay zeka erişimi için, bir ağ geçidi bu kontrolün çoğunu merkezileştirebilir ancak uygulama yetkilendirmesi ve gizli hijyen hâlâ temel mühendislik sorumlulukları olmaya devam etmektedir.