Sürücü ehliyeti bir inference servisinde ne arıyordu?

Bu sabah yayımladığımız haberde Uber, binlerce sürücünün ehliyet bilgilerinin bir tedarikçide çalındığını doğruladı. Tedarikçi, açık modelleri barındırıp inference hizmeti veren Fireworks AI. Üç eyaletin bildirimlerinde toplam 7.870 kişi var; Illinois ve California'da sayı henüz verilmedi.

Haberin en önemli cümlesi bence sayılarda değil, sonda: Uber, ehliyet bilgilerinin Fireworks'te hangi amaçla tutulduğunu açıklamadı. Benim sorum da tam olarak bu. Bir model sağlayıcısı neden kimlik belgesi düzeyinde veri tutuyordu?

Saldırgan veriyi değil, erişimi istiyordu

Fireworks'ün kendi açıklamalarına bakalım. 9 Kasım güncellemesine göre olay 6 Ekim'de iç kimlik bilgilerinin yetkisiz kullanımıyla fark edildi. İkinci aşamada saldırgan, Ar-Ge makinelerini barındıran bir üçüncü taraf bulut sağlayıcısı üzerinden geliştirme makinelerine ulaştı. Şirket izlerin LLMjacking yapan, yani ele geçirdiği erişimle model token'ı satan finansal güdümlü bir gruba çıktığını söylüyor.

Bu ayrıntı önemli. Saldırganın hedefi büyük ihtimalle Uber'in sürücüleri değildi; hedef, model erişimini paraya çevirmekti. Ama bir inference platformuna girdiğinizde orada ne bulursanız onu da alırsınız: ortam değişkenlerindeki API anahtarları, faturalama bilgisi, eksik model ağırlıkları, müşterilerin değerlendirme ve eğitim için yüklediği veri setleri. Uber'in sürücü verisi bu sonuncusunun içindeydi.

AI sağlayıcısı bir veri işleyendir, bir API değil

Mühendislik ekipleri model sağlayıcısını çoğu zaman bir fonksiyon çağrısı gibi düşünür: istek gider, cevap gelir, geride bir şey kalmaz. Fireworks da varsayılan olarak veri saklamayan inference hizmetlerinde etki tespit etmediğini söylüyor. Sorun, işin inference'tan çıkıp değerlendirmeye, ince ayara, batch işlemeye kaydığı yerde başlıyor. Orada veri bir süre duruyor, bir veri setine dönüşüyor ve sağlayıcının saldırı yüzeyinin parçası oluyor.

Notion'ın bildirimi aynı deseni farklı bir veriyle gösterdi. Insights özelliği için Fireworks'e giden Notion AI sohbet kayıtları erişilmiş olabilir; Notion bu kayıtlara parola ya da API anahtarı yapıştıranlara bunları hemen değiştirmelerini önerdi. Kullanıcı bir sohbet kutusuna yazdı; o metin bir üründen bir alt işleyiciye, oradan bir eğitim deneyine aktı.

Saldırı tekniği açısından yeni bir şey yok: çalınan kimlik bilgisi, üçüncü taraf bulut, yanal hareket. Yeni olan, AI iş akışlarının veriyi sessizce çoğaltması. Her değerlendirme işi ve her eğitim denemesi verinin bir kopyasını daha başka bir yere bırakıyor.

Savunma veri akışını çizmekle başlıyor

Burada model güvenliğinden çok veri mimarisinden söz ediyorum. Bir AI sağlayıcısına veri gönderen her ekip üç soruyu yazılı cevaplayabilmeli. Birincisi: hangi alanlar gidiyor ve modelin işi için gerçekten gerekli mi? Ehliyet numarası bir modelin vereceği karar için nadiren gereklidir; gerekiyorsa da token'lanmış hali çoğu zaman yeter. İkincisi: veri sağlayıcıda ne kadar kalıyor, hangi hizmet onu saklıyor? Saklamayan inference ile saklayan eğitim hattı aynı risk değildir. Üçüncüsü: sağlayıcının kendisi hangi alt yapılara dayanıyor? Fireworks olayında kırılan halka, Fireworks'ün de tedarikçisiydi.

Türkiye'deki veri sorumluları için bu sorular hukuki de. Yurt dışındaki bir veri işleyende yaşanan ihlal de bildirim yükümlülüğü doğurabilir; o zaman "biz sadece API çağırıyorduk" savunması işe yaramaz.

Son söz

Bir model sağlayıcısı ihlal edildiğinde kaybettiğiniz şey, ona gönderdiğiniz şeydir; ne eksik ne fazla. Uber vakası saldırganın asıl hedefi olmayan verinin de gittiğini gösteriyor. Bu yüzden AI güvenliğini prompt injection'dan önce bir veri akışı şemasıyla başlatın: alan alan, hizmet hizmet, alt işleyici alt işleyici.