Hugging Face token’ını modele gömmeyin: Sızıntıyı tek anahtarla sınırlayın

Özel Hugging Face modeline en az yetkiyle erişmek için token’ı modele, kaynak koda veya container imajına gömmeyin. Yerel geliştirme, CI ve üretime ayrı token verin; her token’ı yalnızca gereken depo ve işlemle sınırlayın. Böylece bir değer sızdığında diğer uygulamaların anahtarlarına dokunmadan yalnızca etkilenen token’ı iptal edebilirsiniz.

Private depo, dar kapsamlı token ve uç nokta erişimi farklı riskleri denetler. Depo görünürlüğü model dosyalarını, token kapsamı ele geçirilen kimliğin yetkilerini, uç nokta ayarı ise çalışan modele kimlerin ve hangi ağdan ulaşacağını belirler. Özel bir modeli korumak için bu kontrolleri birlikte uygulamak gerekir.

Her uygulamaya ayrı bir yetki alanı verin

Hugging Face erişim token’ı belgeleri, uygulama veya kullanım başına ayrı token oluşturulmasını ve üretimde yalnızca fine-grained token kullanılmasını öneriyor. Belgeler ayrıca sızan bir token’ın ayarlardan silinebileceğini ya da yenilenebileceğini belirtiyor. Bu düzenin sonucu nettir: tek bir token iptal edilirken diğer kullanım alanları çalışmaya devam eder.

Fine-grained token’ı yalnızca adlandırmak yetmez; kaynak ve eylem kapsamını da daraltın. Sadece model indiren bir servis write yetkisi taşımamalı, tek bir özel modele ihtiyaç duyan üretim uygulaması hesabın erişebildiği bütün depoları okuyamamalıdır. Model yayımlayan iş akışıyla modeli yalnızca yükleyen çalışma zamanı aynı kimliği paylaşmamalıdır.

• Yerel geliştirme: Yalnızca geliştiricinin kullandığı model depolarını okuyabilen ayrı token.
• CI: Yalnızca ilgili iş akışına verilen ve gerekli depo işlemleriyle sınırlanan ayrı kimlik bilgisi.
• Üretim: Tek uygulama ve gerekli model kümesi için read yetkili fine-grained token.
• Yayınlama: Sadece hedef depoya yazabilen kimlik; bu yetki üretim çalışma zamanına aktarılmamalı.

Token’ı artefakta değil çalışma anına taşıyın

Kaynak koddan sonradan kaldırılan bir token, daha önce alınmış klonlardan, build çıktılarından veya yayımlanmış container katmanlarından kendiliğinden silinmez. Token’ı yapılandırma dosyasına, notebook hücresine, Dockerfile’a, model ağırlığına ya da uygulamayla dağıtılan başka bir artefakta yazmayın.

Gizli değeri kullandığınız platformun secret store’unda saklayın ve yalnızca çalışma anında ortama aktarın. Ortam değişkeni kullanıyorsanız süreç dökümlerinin ve tanılama çıktılarının bu değeri göstermediğini kontrol edin; dosya bağlama kullanıyorsanız dosya izinlerini uygulamanın servis hesabıyla sınırlayın. Build aşamasının modele erişmesi gerekiyorsa sırrın son imaj katmanına taşınmadığını ayrıca doğrulayın.

Günlükleme de aynı sınırın parçasıdır. İstek başlıklarını, ortam değişkenlerini veya hata nesnelerini topluca yazdırmak Authorization değerini kayda geçirebilir. Başarısız kimlik doğrulama yolunu da deneyerek token’ın uygulama günlüğünde, CI çıktısında ve komut geçmişinde görünmediğini denetleyin.

Ortam reçetesini tehdide göre ayırın

Yerel geliştirmede amaç, geliştirici rahatlığını hesap genelindeki yetkiye dönüştürmemektir. Kişisel makinedeki token yalnızca gereken depoları okumalı ve paylaşılan proje dosyalarına girmemelidir. Geliştiricinin yayınlama yetkisi gerekiyorsa bunu sürekli kullanılan okuma token’ına eklemek yerine ayrı bir kimliğe verin.

CI’da token’ı yalnızca onu kullanan iş veya ortam için tanımlayın. Korumasız dallardan ve dış fork’lardan başlayan iş akışlarına sır aktarmayın; salt test yapan bir işin yayınlama token’ını görmesine izin vermeyin. CI sağlayıcınız kısa ömürlü kimlik sunuyorsa kalıcı sır yerine onu değerlendirin, ancak seçilen yöntemin özel depoya gerçekten erişebildiğini doğrulamadan geçiş yapmayın.

Üretimde token’ın sahibi, kapsamı ve tüketen servis envanterde açıkça eşleşmelidir. Aynı token’ı birden fazla servis kullanıyorsa sızıntı anında hangi tüketicilerin güncelleneceğini ayırt edemezsiniz; başlıktaki “tek anahtar” sınırı da ortadan kalkar.

Private depo ile uç nokta erişimini karıştırmayın

Private depo model dosyalarının Hub üzerinde herkese açılmasını önler; çalışan çıkarım servisine ağ erişimini ayrıca yapılandırmanız gerekir. Inference Endpoints güvenlik genel bakışı, internetten kimlik doğrulamasız erişilen Public, geçerli Hugging Face token’ı isteyen Protected ve internete açılmadan bölge içi AWS ya da Azure PrivateLink kullanan Private düzeylerini tanımlıyor.

Hugging Face belgelerindeki adlandırma her sayfada aynı değil. Güncel yapılandırma kılavuzu, kimlik doğrulama seçeneklerini Private, Public ve Authenticated olarak sıralarken AWS PrivateLink’i ayrı bir Network ayarı olarak gösteriyor. Bu nedenle yalnızca “Protected” veya “Private” etiketini aramak yerine sonucu denetleyin: uç kimlik doğrulaması istiyor mu, kimlerin token’ını kabul ediyor ve trafik genel internetten erişilebilir mi?

İnternetten çağrı alması gereken özel bir üretim modeli için kimlik doğrulamalı erişim asgari seçimdir; deponun private olması Public ucu korumaz. Trafiğin VPC dışına çıkmaması gerekiyorsa sağlayıcı, bölge ve hesap koşullarını doğrulayarak PrivateLink kullanın. Konsolda görünen seçenekler ile güvenlik genel bakışındaki terimler ayrıştığında dağıtım ekranındaki etkin kimlik doğrulama ve ağ ayarlarını esas alın.

Sızıntıda önce yetkiyi kesin, sonra yenisini dağıtın

Token’ın herkese açık depo, günlük veya artefakta çıktığı doğrulandıysa ilk işlem eski değeri geçersiz kılmaktır. Kesintiyi önlemek için sızmış anahtarı açık tutmak, aynı süre boyunca ele geçiren tarafa da erişim bırakır. Uygulama başına ayrım sayesinde bu işlem bütün sistemin kimlik bilgilerini değiştirmeyi gerektirmez.

1. Token’ı sahibi, kapsamı, bağlı deposu ve kullanan uygulamayla eşleştirin.
2. Sızan token’ı silin veya yenileyerek eski değeri geçersiz kılın.
3. Eski geniş yetkileri kopyalamadan, yalnızca gereken kaynak ve eylemler için yeni fine-grained token oluşturun.
4. Yeni değeri ilgili secret store’a yazın; yalnızca etkilenen servisi yeniden başlatın veya dağıtın.
5. Model indirme ya da çıkarım çağrısını doğrulayın ve eski token’ın artık çalışmadığını kontrol edin.
6. Git geçmişi, CI çıktıları, container katmanları ve günlüklerde kalan kopyaları temizleyin; temizliği iptalin yerine koymayın.

Son kontrol üç soruya indirgenebilir: Her ortamın ayrı kimliği var mı, her kimlik yalnızca gereken modeli ve işlemi görebiliyor mu, uç noktanın kimlik doğrulama ve ağ sınırı tehdit modeline uyuyor mu? Üçüne de yanıt verebiliyorsanız bir sızıntının etkisi hesap geneline değil, iptal edilebilen tek uygulama token’ına sıkışır.

Ayrıca okuyun:

• Hugging Face’e ilk adım: Yanlış modeli çalıştırmadan önce üç kontrol
• Hugging Face yalnızca model deposu değil: Hub, Spaces ve Transformers farkı
• VMware Private AI Cloud geldi: Token ve GPU maliyeti tek panelde