Kesintisiz Sır Döndürme: Çift Anahtar, Dönüşümlü Kullanıcı ve Eski Değerle Kalan Tüketiciler

Bir parolayı, API anahtarını ya da imza anahtarını değiştirmek kâğıt üzerinde tek satırlık bir iştir: yeni değeri üret, eskisinin yerine koy. Pratikte en çok kesinti yaratan bakım işlerinden biridir. Sebebi değerin kendisi değil, o değeri kullanan yerlerdir. Bir sırrı kim okuyor, değeri bellekte ne kadar süre tutuyor, değişikliği ne zaman fark ediyor? Bu üç soruya cevap vermeden yapılan döndürme ya bir servisi düşürür ya da daha kötüsü, bir tüketiciyi haftalarca sessizce başarısız bırakır.

Bu yazı, sır döndürmeyi kesintisiz ve doğrulanabilir hâle getirmek için kullanılan yaklaşımları, uygulama adımlarını ve sık düşülen tuzakları anlatıyor.

Asıl problem: değiştirmek ile geri almak aynı anda olmaz

Sır döndürmenin iki ayrı adımı vardır: yeni değeri geçerli kılmak ve eski değeri geçersiz kılmak. Kesintiler, bu iki adım tek bir anda yapıldığında çıkar. Eski parola iptal edildiği saniyede, yeni değeri henüz almamış her tüketici kimlik doğrulamasında düşer.

Doğru model, iki değerin birlikte geçerli olduğu bir örtüşme dönemidir. Önce yeni değer eklenir, tüketiciler yeni değere geçer, geçiş ölçülür, ancak ondan sonra eski değer iptal edilir. Bu modeli uygulamanın üç yaygın yolu var.

Üç yaklaşım

1. Çift anahtar (aynı kimliğe iki geçerli değer). Sağlayıcı bir kimliğe aynı anda birden fazla anahtar tanımlamaya izin veriyorsa en temiz yol budur. Bulut sağlayıcılarının erişim anahtarları, HMAC ile imzalanan webhook sırları ve JWT imza anahtarları bu gruptadır. Örneğin AWS IAM bir kullanıcıya en fazla iki erişim anahtarı tanımlamaya izin verir; bu sınır tam olarak döndürme için vardır.

JWT'de bu model anahtar kimliğiyle (kid) kurulur. Yeni açık anahtar önce JWKS listesine eklenir, doğrulayan tarafların önbellekleri yenilenene kadar beklenir, sonra imzalama yeni anahtara geçer. Eski anahtar listeden ancak onunla imzalanmış en uzun ömürlü jetonun süresi dolduktan sonra çıkarılır. Sırayı ters çevirirseniz, yani önce yeni anahtarla imzalamaya başlarsanız, JWKS önbelleği henüz güncellenmemiş her doğrulayıcı geçerli jetonları reddeder.

2. Dönüşümlü kullanıcılar. Veritabanı gibi bir kullanıcıya tek parola tanımlayan sistemlerde parolayı yerinde değiştirmek yerine iki kullanıcı tutulur ve döndürme her seferinde diğerine geçer. AWS Secrets Manager'ın döndürme şablonlarında da "alternating users" adıyla geçen yaklaşım budur.

PostgreSQL'de yetkiler ortak bir role verilir, iki giriş kullanıcısı bu role üye olur:

CREATE ROLE app_owner NOLOGIN;
CREATE ROLE app_a LOGIN PASSWORD 'ilk-deger' IN ROLE app_owner;
CREATE ROLE app_b LOGIN PASSWORD 'ikinci-deger' IN ROLE app_owner;
GRANT USAGE ON SCHEMA public TO app_owner;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO app_owner;

Döndürme sırası şudur: kullanımda olmayan kullanıcının parolasını değiştir, uygulamayı o kullanıcıya geçir, eski kullanıcının bağlantılarının bittiğini ölç, sonra eski kullanıcıyı kapat.

SELECT usename, count(*) FROM pg_stat_activity GROUP BY usename;
ALTER ROLE app_a NOLOGIN;

3. Yerinde değiştirip yeniden başlatmak. Sistem tek değer destekliyorsa ve ikinci kullanıcı açmak mümkün değilse, değer değiştirilir ve tüm tüketiciler hemen yeniden başlatılır. Bu yaklaşımda kısa bir kesinti kaçınılmazdır, dolayısıyla bakım penceresi gerektirir.

Taraf tutmak gerekirse: sağlayıcı izin veriyorsa çift anahtar, vermiyorsa dönüşümlü kullanıcı. Yerinde değiştirme yalnızca tüketici sayısı az, hepsi tek elden yeniden başlatılabilen ve birkaç saniyelik hatanın sorun olmadığı durumlar için kabul edilebilir. Bunu varsayılan yöntem yapan ekipler, döndürmeyi korkulan bir iş hâline getirir ve sonunda hiç yapmaz.

Uygulanabilir adımlar

Tüketici envanterini döndürmeden önce çıkarın. Bir sırrın kimler tarafından okunduğu, döndürmenin en zor sorusudur. Envanteri o an dosya sistemini tarayarak çıkarmaya çalışmak hem yavaş hem eksiktir. Daha iyisi, sırrın kaydının yanına tüketici listesini yazmak ve her döndürmede bu listeyi güncellemektir. Bir sonraki döndürme, öncekinin kaydından başlar.

Değeri tek kaynaktan dağıtın. Aynı sırrın beş farklı yapılandırma dosyasında düz metin olarak durması, döndürmede birinin unutulacağı anlamına gelir. Sırrı bir kasada tutup tüketicilere oradan taşımak, güncellenecek yer sayısını bire indirir.

Geçişi ölçün, varsaymayın. Yeni değeri dağıttıktan sonra eskisini iptal etmeden önce, eski değerin hâlâ kullanılıp kullanılmadığına bakın. Veritabanında oturum listesi, bulut sağlayıcılarında anahtarın son kullanım zamanı, API ağ geçidinde anahtar başına istek sayısı bu ölçümü verir. Eski anahtar son bir saatte hâlâ kullanılıyorsa, envanterde eksik bir tüketici vardır.

İptalden sonra da ölçün. Eski değeri iptal ettikten sonra onunla bir istek atın ve gerçekten reddedildiğini görün. İptal işleminin başarılı dönmesi, değerin artık çalışmadığı anlamına gelmez; bazı sistemler iptali önbellek süresi kadar geç uygular.

Tuzaklar

Ortam değişkenleri süreç başlarken okunur. Değeri ortam değişkeniyle alan bir süreç, değişikliği yeniden başlatılana kadar görmez. Konteynerlerde bu daha da sinsidir: konteyneri yeniden başlatmak çoğu zaman yeterli değildir, çünkü ortam değişkenleri konteyner oluşturulurken sabitlenir. Docker Compose'da .env dosyasını değiştirdikten sonra docker restart eski değerle kalkar; konteynerin docker compose up -d ile yeniden oluşturulması gerekir.

Kubernetes'te Secret güncellemesi her yere ulaşmaz. Hacim olarak bağlanan Secret'lar kubelet tarafından bir süre sonra güncellenir, ama ortam değişkeni olarak verilenler pod yeniden oluşturulana kadar eski kalır. subPath ile bağlanan dosyalar da hiç güncellenmez. Dosya güncellense bile uygulamanın onu yeniden okuması gerekir; açılışta bir kez okuyan uygulama için dosyanın değişmesi bir şey ifade etmez. Bu yüzden döndürmeden sonra bir kubectl rollout restart deployment/<ad> çoğu zaman şarttır.

Uzun ömürlü süreçler eski kimliği bellekte taşır. Bir depolama alanını dosya sistemi gibi bağlayan bir süreç, bir tünel istemcisi ya da sürekli açık bir bağlantı havuzu, kimlik bilgisini başlangıçta bir kez okur. Yapılandırma dosyası güncellense bile süreç eski değeri kullanmaya devam eder ve hata, ancak eski değer iptal edildiğinde ortaya çıkar. Daha kötüsü, bu süreçler çoğunlukla gece çalışan bir yedekleme ya da eşitleme işinin altındadır; hata ilk koşuda değil, birkaç gün sonra fark edilir. Envantere yalnızca yapılandırma dosyalarını değil, o dosyaları okuyan uzun ömürlü süreçleri de yazın.

Mevcut oturumlar iptalden etkilenmez. PostgreSQL'de bir kullanıcının parolasını değiştirmek ya da NOLOGIN yapmak, o kullanıcıyla açılmış bağlantıları kapatmaz. Bağlantı havuzu eski oturumları saatlerce yaşatabilir ve döndürmenin "çalıştığını" sanırsınız. Ertesi gün havuz yeni bağlantı açmaya çalıştığında hata başlar. Geçişi kesinleştirmek için eski kullanıcının oturumlarını bilinçli olarak sonlandırın ve uygulamanın yeniden bağlandığını görün.

Dönüşümlü kullanıcılarda nesne sahipliği bölünür. Göç betikleri app_a ile çalışıp tablo oluşturursa, tablonun sahibi app_a olur. Bir sonraki döndürmede app_b'ye geçtiğinizde bu tablo üzerinde ALTER yetkisi kalmaz. Göç betiklerinin başına SET ROLE app_owner; koyarak nesnelerin ortak role ait olmasını sağlayın.

Hata mesajı döndürmeyi işaret etmez. Eski anahtarla kalmış bir tüketici "403 Forbidden", "authentication failed" ya da sadece "bağlantı kurulamadı" der. Bu mesajlar döndürmeyle ilişkilendirilmeden günlerce izlenebilir. Döndürme kaydına tarih düşmek ve sonraki birkaç gün kimlik doğrulama hatalarını bu tarihe karşı okumak, kök nedeni dakikalar içinde bulmayı sağlar.

Yeni değer kimsenin görmediği bir yerde üretilmeli. Yeni sırrı bir terminale yazdırıp oradan kopyalamak, onu kabuk geçmişine, ekran kaydına ya da bir sohbet penceresine bırakır. Değer üretildiği yerden doğrudan kasaya ve tüketicilere gitmeli, döndürmeyi yapan kişi bile onu görmemelidir.

Ne zaman döndürme sıklığını artırmamalı

Sık döndürme, süreç otomatik değilse güvenliği artırmaz, kesinti riskini artırır. Elle yapılan aylık bir döndürme, her ay unutulan bir tüketici demektir. Önce süreci otomatikleştirin ve doğrulamayı sürece gömün, sıklığı ancak ondan sonra artırın.

Daha iyi bir hedef, döndürülecek uzun ömürlü sırların sayısını azaltmaktır. İş yükü kimliği, kısa ömürlü sertifikalar ya da bir kimlik sağlayıcıdan dakikalık süreyle alınan jetonlar, döndürme problemini kökünden ortadan kaldırır. Uzun ömürlü statik bir anahtarı her hafta döndürmek yerine onu hiç tutmamak, çoğu zaman daha az iş ve daha az risktir.

Döndürmeyi ne zaman yapacağınızı değil, bir sızıntıdan sonra ne kadar hızlı yapabileceğinizi sorun. Sızan bir anahtarı bir saat içinde kesintisiz döndüremiyorsanız, sorun takvimde değil süreçtedir.