Kalıcı anahtar yerine tek seferlik token: Vercel, Postman, Pulumi ve Auth0 aynı şeyi söylüyor

Bir hafta içinde birbiriyle hiçbir bağı olmayan dört şirket aynı şeyi yazdı: ortam değişkenindeki ömürlük API anahtarını, dakikalarca yaşayan ve belirli bir iş için verilen token'la değiştirme zamanı geldi. İşletme sahibi için bu, “yüklenici giderse ya da dizüstü kaybolursa ne olur” sorusunun cevabı. Cevap da sistemlerinizin anahtarlarının nasıl verildiğine bağlı.

Aynı konuda dört metin

Vercel 22 Ekim'de uzun ömürlü anahtarlara savaş ilan etti. Karşılaştırmaları HTTPS ile: makine kimlik doğrulamasında bugün, HTTPS'in 2010'da, her şey için norm hâline gelmeden önce olduğu yerdeyiz. Vercel 1000'den fazla SaaS sağlayıcısını incelemiş ve yalnızca %8,4'ü güvenli giriş yöntemlerini destekliyor. Vercel'in kendisi acı verici anahtar rotasyonlarına binlerce mühendislik saati harcadığını ve artık bunu istemediğini yazıyor. Cevapları: 2024'ten beri çalışan OIDC federasyonu, API sağlayıcıları için OIDC UI form seti ve Vercel Connect. Sonuncusunda uygulama token'ı kullanıcı ve gereken scope'lar için istek anında alıyor, değişkenlerde anahtar yok.

Postman 20 Ekim'de komut satırından secret'larla çalışmayı gösterdi. Postman CLI 1.69.0 sürümünden itibaren secret, postman secret create komutuyla oluşturuluyor, kimliğiyle bir ortam değişkenine bağlanıyor ve isteklerde sıradan {{PAYMENT_API_TOKEN}} yazılıyor. Koleksiyonda ve ortam dosyasında depoya bir referans duruyor, değerin kendisi orada yok. Değer tarayıcıdaki tek kullanımlık bir formla ya da terminaldeki gizli girişle giriliyor. Böylece terminaldeki asistan süreci başlatabiliyor, anahtarı ise insan giriyor. Bu bana yakın: AI rutin işte ve hata ayıklamada bana yardım ediyor ve komut geçmişinde anahtarların durmasını istemiyorum.

Auth0 22 Ekim'de Terraform modüllerini yayınladı; ilki, b2b-saas-starter, Terraform Registry'de. Modülün tek bir bloğu uygulamayı, API'yi, tenant ayarlarını, saldırı korumasını ve MFA'yı oluşturuyor. İçinde API izin kontrolü, PKCE ve paralel istekler için üç saniyelik pencereli refresh token rotasyonu hazır geliyor. Benim için burada asıl olan, rotasyonun varsayılan olarak açık olması.

Pulumi 15 Ekim'de Pulumi ESC'ye herhangi bir servis için OIDC token üretmeyi ekledi. fn::open::oidc sağlayıcısı ortam açıldığı anda gereken audience ile kısa bir token imzalıyor, servis imzayı doğrulayıp kendi erişimini veriyor. Ömrü bir dakikadan bir saate kadar, varsayılan bir saat ve ESC hiçbir şey saklamıyor. Saklanan anahtar hakkındaki ifadeleri yerinde: anahtar, var olduğu sürece onu okuyan herkes için, her makineden çalışır.

Bu araç kiralama için ne demek

Bir araç kiralama şirketini ele alalım. Rezervasyon sitesi, iç uygulaması, AmoCRM'i, ödeme servisi ve sözleşmeler için e-postası var. Her bağlantının kendi anahtarı var. Biri sunucudaki .env'de, ikincisi CRM ayarlarında, üçüncüsü uygulamayı yapan ve çoktan ayrılmış geliştiricinin dizüstünde. Hiçbirinin süresi yok. Biri sızarsa bunu öğrenecek bir yer yok. Değiştirmek ise anahtarın durduğu bütün yerleri tek tek dolaşmak ve o sırada bir şeyi bozmak demek.

Sonuç: tehlikeli olan, süresi ve sınırı olmayan anahtar. Tek bir iş için on beş dakikalık bir anahtar da sızabilir, ama zararı o on beş dakikayla ve o işle sınırlı kalır.

Bende nasıl kurulu

Eylül ve Ekim 2026'da yaptığım “Birlikte Kahve” iç servisinde en değerli sır, Tasty Coffee toptan hesabının girişi. Sunucunun kapalı değişkenlerinde saklanıyor, tedarikçi token'ı ise yalnızca sürecin belleğinde yaşıyor. Bütün dış istekler Nginx ve Node.js üzerindeki gateway'den geçiyor: gateway istemcinin gönderdiği kimlik başlıklarını siliyor ve kullanıcıyı imzalı HttpOnly cookie'den kendisi belirliyor. Yönetici oturumu 8 saat yaşıyor; aynı adresten beş başarısız giriş denemesinden sonra giriş 15 dakika engelleniyor. Tedarikçiye ve Google E-Tablolar'a giden istekler, dışarıdan erişilemeyen iç proxy'ler üzerinden geçiyor. Vercel ve Pulumi'deki ilkenin aynısı, yalnızca 2 GB bellekli ortak bir sunucuda ve ücretli servisler olmadan.

2021'den beri çalıştığım ABD'deki PDR şirketinde sunucuya site, süper uygulama, telefon sistemi ve belge parser'ları gidiyor ve iç API'yi üçüncü sürümüne getirdim. Her bağlantının tam olarak hangi erişimlere sahip olduğunu açıklamıyorum. Şu kadarını söyleyeyim: şirkette güvenlik soruları bana geliyor; sunucuya, VPN'e ve ağ ekipmanına kendim bakıyorum.

Uzun zamandır çalıştığım kural: kod, veritabanı, sunucu ve bütün erişimler müşteriye aittir. Anahtarlar yüklenicinin defterinde yaşadığında rotasyon pazarlığa dönüşür.

Ne yapardım

Bütün anahtar ve token'ların listesini çıkarırdım: CRM, ödeme servisi, SMS, e-posta, haritalar, AI servisleri. Nerede duruyor, ne yapabiliyor, en son ne zaman değişti.

Anahtarları koddan ve makineden makineye kopyalanan dosyalardan çıkarırdım. Sunucuda kapalı değişkenler, CLI'da ve testlerde Postman'daki gibi depoya referanslar.

Servis OIDC ya da kısa token'ları destekliyorsa onlara geçerdim. Geri kalanlarda, Vercel'in araştırmasına göre bunlar %90'dan fazla, anahtarı izinlerle sınırlar ve takvime göre değiştirirdim.

Terminaldeki ve koddaki AI asistanının neyi gördüğüne karar verirdim. Kendimde kodla çalışmasına izin veriyorum, anahtar değerlerini ise kendim giriyorum.

Bütün bunların geliştirici olmadan yapılabildiğini kontrol ederdim: erişimler sizin, liste sizde.

İzinleri kontrol eden ortak merkez olarak sunucu üzerine: Sunucu: veri, erişim ve sürecin yürütülmesi. Yönlere göre: veri aktarım kuralları net API entegrasyonları ve yayınlanabilen ve geri getirilebilen altyapı. “Birlikte Kahve” sunucusu ortak kahve siparişi servisi vakasında, PDR şirketinin iç API'si ise birkaç uygulama için kendi API'si sayfasında anlatılıyor. Yakın yazılardan: ele geçirilen sertifika otoritesi, canlı sunucuda AI ajanı ve ajanlar için sandbox'lar ve yeni Git; daha önce sözleşme olarak geliştirme sırları ve API anahtarları ve sızıntılar üzerine yazmıştım. Kaç anahtarınız olduğunu ve nerede durduklarını bilmiyorsanız bu listeyle başlayın, gerisini birlikte konuşabiliriz. Görevi konuşalım.