Unutulan API anahtarları: hizmeti durdurmadan nasıl iptal edilir

OpenRouter’ın iç denetiminde 85 çalışana ait 1.000’den fazla etkin API anahtarı bulundu; şirketin açıklamasına göre 168 anahtar aylardır kullanılmıyordu. Bunlar OpenRouter’ın kendi denetiminden elde edilen sayılardır, sektör çapında bağımsız bir araştırmanın sonuçları değildir. Ancak özel bir örnek olarak bile tanıdık bir mühendislik tuzağını gösteriyor: Bir anahtar unutulabilir, ama ona bağımlı uygulama unutulmaz. Şirket, Security Center duyurusunu 28 Eylül 2026 tarihli olarak yayımladı.

Sorun, en eski kimlik bilgisini bulup silmekten ibaret değildir. Ekip, anahtarın sahibini belirlemeli, nerede kullanıldığını öğrenmeli ve nadiren çalışan bir görevi ya da unutulmuş bir hizmeti devre dışı bırakmadan anahtarı nasıl değiştireceğini anlamalıdır. Bu bilgiler olmadan erişimi iptal etmek, temizlikten çok riskli bir deneye dönüşür.

Security Center’da görülenler ve bunların kanıtlamadıkları

OpenRouter’ın açıklamasına göre Security Center, hesaptaki anahtarları bir araya getirerek sahiplerini, son kullanım zamanını, harcama limitini ve son kullanma tarihini gösteriyor; kuruluş yöneticileri tüm anahtarları, üyeler ise kendi oluşturdukları anahtarları görebiliyor. Toplu işlemler için en fazla 500 anahtar seçilebiliyor: devre dışı bırakma, arşivleme veya harcama limiti belirleme. Devre dışı bırakma geri alınabilir, arşivleme ise geri alınamaz. Bunlar, sağlayıcının kendi açıkladığı araç özellikleridir; etkinliğine dair bağımsız bir değerlendirme değildir.

“Silinebilir” durumunu, bağımlılıkların bulunmadığının kanıtı olarak değil, inceleme ipucu olarak değerlendirmek özellikle önemlidir. Kullanım metriği geçmiş istekleri gösterir, ancak anahtarın hangi cron görevine, olağanüstü durum senaryosuna veya mevsimsel sürece ait olduğunu açıklamayabilir. OpenRouter da silme işlemini sahibine doğrulatmanızı öneriyor; güvenlik ayarları belgeleri de devre dışı bırakmadan veya arşivlemeden önce bağımlılıkların kontrol edilmesi gerektiği konusunda uyarıyor.

Ağ kısıtlamaları için ayrıca dikkate alınması gereken bir not var: IP izin listesi, Enterprise planındaki yöneticilere sunuluyor ve kuruluşun tüm anahtarlarına uygulanıyor. Listedeki adreslerin dışından gelen istekler 403 hatasıyla reddediliyor ve değişiklikler hemen yürürlüğe giriyor. Bu nedenle kısıtlamayı etkinleştirmeden önce üretim sunucularının, ofis ağının ve CI runner’larının adreslerini hesaba katın; aksi takdirde güvenlik önlemi meşru çağrıları kesebilir.

Temizlik adımları: önce sahibi belirleyin, sonra erişimi iptal edin

1. Envanter çıkarın. Her anahtar için sahibini, amacını, ortamını, tüketicilerini, harcama limitini ve son kullanma tarihini kaydedin. Sistem yalnızca bir kişiyi sahip olarak gösteriyorsa, kişi ayrıldığında sorumluluğu devralacak ekibi veya hizmeti de belirleyin.
2. Kullanımı ve bağımlılıkları kontrol edin. Son istek zamanını arka plan görevlerinin çizelgeleri, yedek senaryolar, yayın iş akışları ve harici entegrasyonlarla karşılaştırın. Yakın zamanda etkinlik görülmemesi, sahibine soru sormak için bir nedendir; hemen silmek için tek başına yeterli gerekçe değildir.
3. Geçişten önce riski azaltın. Desteklenen yerlerde makul bir harcama limiti ve son kullanma tarihi belirleyin. En az ayrıcalık ilkesini ve sırların saklanmasına ilişkin kuralları gözden geçirin: OWASP’ın sır yönetimi kılavuzu, kimlik bilgilerinin envanterini, erişimini ve yaşam döngüsünü sürecin ayrı bileşenleri olarak ele alıyor.
4. Yenisini oluşturup tüketicileri taşıyın. Sırrı depolama alanında veya dağıtım yapılandırmasında güncelleyin, ardından uygulamaları aşamalı olarak geçirin. Anahtar değerini destek taleplerine, günlük dosyalarına veya kaynak koda koymayın.
5. Erişimi iptal etmeden önce üretimi doğrulayın. CI ve nadiren çalışan görevler dâhil, bilinen tüm tüketicilerde yeni anahtarın çalıştığından emin olun. Ardından, geri alınabilir bir işlem varsa önce eski anahtarı devre dışı bırakın; geçişi ve belirlenen izleme süresini doğruladıktan sonra arşivleyin veya silin.

“Yeni anahtar oluştur → uygulamaları taşı → çalışmayı doğrula → eskisini sil” sıralaması, OpenRouter’ın anahtar döndürme kılavuzuyla örtüşüyor. Bu önerilen bir sıradır, kesinti yaşanmayacağının garantisi değildir: Sonuç, kimlik bilgisini kullanan tüm sistemleri bulup bulmadığınıza bağlıdır.

Hizmet anahtarları, kuruluşun tüm sırları değildir

Belirli bir sağlayıcının paneli o hizmetin anahtarlarını yönetmeye yardımcı olur, ancak tek başına buluttaki, veritabanlarındaki, CI/CD’deki ve diğer API’lerdeki sırları merkezileştirmez. OWASP’ın sır yaşam döngüsüne ilişkin genel önerileri merkezi depolamayı, erişim denetimini, denetim kayıtlarını, anahtar döndürmeyi ve erişimi iptal etmeyi kapsıyor. Google Cloud’un önerileri de anahtarların kapsamını sınırlamayı, gereksiz kimlik bilgilerini silmeyi ve kullanımı izlemeyi ayrıca tavsiye ediyor.

OpenRouter ayrıca Security Center’ın istemleri ve yanıtları okumak yerine anahtar meta verilerini, harcamaları ve son kullanma tarihlerini kullandığını belirtiyor. Bu, sağlayıcının kendi iddiasıdır; incelenen kaynaklarda bağımsız bir teknik doğrulama bulunmuyor. Genel olarak bir panelin varlığı da ekibin olay sayısını veya harcamalarını zaten azalttığını kanıtlamaz: İncelenen materyallerde lansman sonrasına ait kamuya açık sonuçlara rastlanmadı.