- Konu sahibi
- #1
Sır rotasyonu sırasında hizmet kesintisini önlemenin temel yolu, yeni sırrı önce hazırlayıp doğrulamak, uygulamaları yeni sırla çalıştırmak ve eski sırrı tüm tüketiciler geçiş yaptıktan sonra kaldırmaktır. Eski sırrı yeni sır etkinleşmeden iptal etmek, uygulamanın yeniden başlatılması, bağlantı havuzlarının yenilenmesi veya önbelleklerin temizlenmesi sırasında kesintiye yol açabilir.
Sır; veritabanı parolası, API anahtarı, imzalama anahtarı veya servisler arası kimlik bilgisi olabilir. Planlı rotasyonda sağlayıcı destekliyorsa geçiş penceresinde iki geçerli sürüm kullanılabilir:
Bu yöntem, uygulamaların sır değişikliğini aynı anda algılayamadığı durumlarda özellikle önemlidir. Sırrı kaynak koduna gömmek yerine sürümlü sır yönetimi kullanmak rotasyonu kolaylaştırır. Uygulamanın depo erişimi, önbellek TTL’i ve hot-reload davranışı planlanmalıdır; her istekte ağdan sır okumak zorunlu değildir ve yeni bir bağımlılık arızası oluşturabilir.
Bu plan normal, zamanlanmış rotasyon içindir. Sır ele geçirildiyse eskiyi uzun süre açık tutmak veya ona geri dönmek güvenli olmayabilir; olay müdahalesi kapsamında iptal hızı ve hizmet devamlılığı birlikte değerlendirilir. İmzalama anahtarıyla veri şifreleme anahtarı da aynı değildir: eski şifreli veriyi açabilmek için kontrollü decryption/re-encryption planı gerekebilir.
Bir web uygulamasının
Başarı ölçütü yalnızca uygulamanın yeniden başlaması değildir. Yeni sırla yapılan gerçek istek başarılı olmalı, geçiş tamamlandığında tüm beklenen tüketiciler yeni sürümü kullanmalı ve eski sırrın iptal edilmesinden sonra hata oranı normale dönmelidir. Yeni sırla bağlantı kurulamıyorsa dağıtımı durdurun; eski sır hâlâ geçerliyse uygulamayı eski sürüme döndürün, hatanın nedenini giderip yeniden deneyin.
Rotasyon yöntemini sırrın ve hizmetin özelliklerine göre seçin:
Genel işlem sırası şöyledir:
Token imzalama rotasyonunda yeni anahtarın doğrulayıcılara/JWKS önbelleklerine yayılmasını, sonra yeni anahtarla imzalamayı ve eski tokenların azami geçerlilik penceresini koordine edin. Tek parola destekli DB’de eski açık bağlantıların çalışması yeni bağlantının kurulacağını kanıtlamaz; havuzu yenileyerek doğrulayın. Anahtarın değerini değil güvenli sürüm kimliğini izleyin.
Eski sırrı önce iptal etmek: Yeni dağıtım tamamlanmadıysa çalışan örnekler anında yetkilendirme hatası üretir.
Sadece bir örneği test etmek: Farklı ortam değişkenleri, önbellekler veya uzun ömürlü worker süreçleri diğer örneklerin eski sırrı kullanmasına neden olabilir.
Sırrı kaynak koduna veya kalıcı yapılandırma dosyasına yazmak: Rotasyon için yeni dağıtım gerekir ve eski değer unutulabilir. Sır deposu sürümleri ve çalışma zamanı yenileme mekanizması tercih edilmelidir.
İmzalama anahtarını hemen değiştirmek: Daha önce üretilmiş token veya oturumlar yeni anahtarla doğrulanamayabilir. Doğrulama katmanının geçici olarak iki anahtarı tanıyıp yalnızca yenisiyle imzalaması gerekebilir.
Geri dönüş planı olmadan iptal etmek: Sağlayıcı eski sırrı geri açmaya izin vermiyorsa geri dönüş, yeni bir sır üretip tüketicileri tekrar geçirmek anlamına gelir. Bu işlem rotasyon planında açıkça yer almalıdır.
Kesintisiz geçiş garanti edilemez. Kontrollü bir bakım penceresi planlayın; yeni sırrı uygulamaya tanıtın, bağlantıları yenileyin, doğrulama isteği başarılı olduktan sonra eski sırrı devre dışı bırakın. Hizmet sağlayıcı destekliyorsa geçici iki anahtarlı modele geçmek daha güvenlidir.
Uygulama süreci, bağlantı havuzu veya sır önbelleği eski değeri bellekte tutuyor olabilir. Yeni sürümü gerçekten okuduğunu log veya güvenli sürüm kimliğiyle doğrulayın; ardından desteklenen yeniden yükleme ya da yeniden başlatma yöntemini uygulayın. Hata sürerse dağıtımı durdurup eski geçerli sürümle hizmeti koruyun.
Sır rotasyonu nasıl çalışır?
Sır; veritabanı parolası, API anahtarı, imzalama anahtarı veya servisler arası kimlik bilgisi olabilir. Planlı rotasyonda sağlayıcı destekliyorsa geçiş penceresinde iki geçerli sürüm kullanılabilir:
- Eski sürüm mevcut çalışan istemcileri desteklemeye devam eder.
- Yeni sürüm güvenli bir depoya eklenir ve erişim yetkileri kontrol edilir.
- Uygulamalar yeni sürümü kullanacak şekilde dağıtılır.
- Yeni sürümle gerçek bir doğrulama yapılır.
- Geçiş tamamlanınca eski sürüm iptal edilir.
Bu yöntem, uygulamaların sır değişikliğini aynı anda algılayamadığı durumlarda özellikle önemlidir. Sırrı kaynak koduna gömmek yerine sürümlü sır yönetimi kullanmak rotasyonu kolaylaştırır. Uygulamanın depo erişimi, önbellek TTL’i ve hot-reload davranışı planlanmalıdır; her istekte ağdan sır okumak zorunlu değildir ve yeni bir bağımlılık arızası oluşturabilir.
Bu plan normal, zamanlanmış rotasyon içindir. Sır ele geçirildiyse eskiyi uzun süre açık tutmak veya ona geri dönmek güvenli olmayabilir; olay müdahalesi kapsamında iptal hızı ve hizmet devamlılığı birlikte değerlendirilir. İmzalama anahtarıyla veri şifreleme anahtarı da aynı değildir: eski şifreli veriyi açabilmek için kontrollü decryption/re-encryption planı gerekebilir.
Somut varsayımsal örnek
Bir web uygulamasının
payments-api adlı harici servise bir API anahtarıyla bağlandığını varsayalım. Uygulamanın yalnızca tek bir anahtar okuyabildiği, ancak harici servisin iki anahtarı aynı anda geçerli tutabildiği durumda şu geçiş yapılır:- Harici serviste yeni anahtarı oluşturun; eski anahtarı henüz silmeyin.
- Yeni anahtarı sır deposunda yeni bir sürüm olarak kaydedin. Uygulamanın okuyacağı ad, değişmeden kalmalı; etkin sürüm etiketi kontrollü değiştirilir. Sürümü açıkça pinleyen tüketiciler varsa onların dağıtımı da güncellenmelidir.
- Uygulamayı yeni sürümü okuyacak şekilde yeniden başlatın veya destekleniyorsa güvenli bir yeniden yükleme yapın.
- Gerçek ödeme oluşturmayan sağlayıcının test/doğrulama uç noktasına istek gönderin ve uygulama loglarında kimlik doğrulama hatası, yetki reddi ve bağlantı havuzu hatası olmadığını kontrol edin.
- Tüm uygulama örneklerinin yeni anahtarla çalıştığını doğrulayın. Dağıtım gecikmesi veya önbellek nedeniyle eski sürümü kullanan örnekler varsa eski anahtarı hemen iptal etmeyin.
- Geçiş penceresi sonunda eski anahtarı iptal edin ve iptalin ardından normal isteklerin sürdüğünü kontrol edin.
Başarı ölçütü yalnızca uygulamanın yeniden başlaması değildir. Yeni sırla yapılan gerçek istek başarılı olmalı, geçiş tamamlandığında tüm beklenen tüketiciler yeni sürümü kullanmalı ve eski sırrın iptal edilmesinden sonra hata oranı normale dönmelidir. Yeni sırla bağlantı kurulamıyorsa dağıtımı durdurun; eski sır hâlâ geçerliyse uygulamayı eski sürüme döndürün, hatanın nedenini giderip yeniden deneyin.
Uygulanabilir rotasyon planı
Rotasyon yöntemini sırrın ve hizmetin özelliklerine göre seçin:
| Durum | Tercih edilen geçiş | Dikkat edilmesi gereken |
|---|---|---|
| İki anahtara izin veriliyor | Yeni anahtar oluştur, tüketicileri geçir, eskisini iptal et | İptalden önce tüm örnekleri doğrula |
| Tek parola destekleniyor | Kısa bakım penceresi veya bağlantı kabul eden kontrollü geçiş | Bağlantı havuzları ve yeniden deneme davranışı test edilmeli |
| İmzalama anahtarı kullanılıyor | Yeni anahtarla imzala, doğrulamada eski ve yeniyi geçici olarak kabul et | Eski anahtarı erken kaldırmak mevcut oturumları geçersiz kılabilir |
Genel işlem sırası şöyledir:
- Sırrı kullanan tüm uygulama, worker, cron görevi ve dış entegrasyonları listeleyin. Bilinmeyen tüketiciler varsa eski sırrın iptal zamanını planlamayın.
- Yeni sırrı oluşturun ve en az ayrıcalıkla aynı erişim kapsamını verin. Yeni sırrın yanlış kapsamla oluşturulması, kesintisiz fakat başarısız bir geçişe neden olabilir.
- Üretim dışı ortamda gerçek kimlik doğrulama akışını test edin. Yalnızca sır deposunda kaydın bulunması yeterli değildir.
- Kademeli dağıtım yapın. Önce bir uygulama örneğini yeni sırla çalıştırıp istekleri ve hata loglarını izleyin.
- Sorun yoksa kalan örnekleri geçirin. Dağıtım sırasında eski sırrı kullanan örneklerin ne zaman sona ereceğini hesaba katın.
- Yeni sırla çalışan tüm tüketicileri doğrulayın ve ancak bundan sonra eski sırrı iptal edin.
- İptal sonrası izlemeyi sürdürün. Hata görülürse eski sır geri açılamıyorsa yeni bir geçici sır oluşturmak gerekebilir; bu nedenle geri dönüş planı önceden hazırlanmalıdır.
Token imzalama rotasyonunda yeni anahtarın doğrulayıcılara/JWKS önbelleklerine yayılmasını, sonra yeni anahtarla imzalamayı ve eski tokenların azami geçerlilik penceresini koordine edin. Tek parola destekli DB’de eski açık bağlantıların çalışması yeni bağlantının kurulacağını kanıtlamaz; havuzu yenileyerek doğrulayın. Anahtarın değerini değil güvenli sürüm kimliğini izleyin.
Sık yapılan hatalar
Eski sırrı önce iptal etmek: Yeni dağıtım tamamlanmadıysa çalışan örnekler anında yetkilendirme hatası üretir.
Sadece bir örneği test etmek: Farklı ortam değişkenleri, önbellekler veya uzun ömürlü worker süreçleri diğer örneklerin eski sırrı kullanmasına neden olabilir.
Sırrı kaynak koduna veya kalıcı yapılandırma dosyasına yazmak: Rotasyon için yeni dağıtım gerekir ve eski değer unutulabilir. Sır deposu sürümleri ve çalışma zamanı yenileme mekanizması tercih edilmelidir.
İmzalama anahtarını hemen değiştirmek: Daha önce üretilmiş token veya oturumlar yeni anahtarla doğrulanamayabilir. Doğrulama katmanının geçici olarak iki anahtarı tanıyıp yalnızca yenisiyle imzalaması gerekebilir.
Geri dönüş planı olmadan iptal etmek: Sağlayıcı eski sırrı geri açmaya izin vermiyorsa geri dönüş, yeni bir sır üretip tüketicileri tekrar geçirmek anlamına gelir. Bu işlem rotasyon planında açıkça yer almalıdır.
Kaynaklar
Sık sorulan sorular
İki sır aynı anda geçerli tutulamıyorsa ne yapılır?
Kesintisiz geçiş garanti edilemez. Kontrollü bir bakım penceresi planlayın; yeni sırrı uygulamaya tanıtın, bağlantıları yenileyin, doğrulama isteği başarılı olduktan sonra eski sırrı devre dışı bırakın. Hizmet sağlayıcı destekliyorsa geçici iki anahtarlı modele geçmek daha güvenlidir.
Sır değiştiği hâlde uygulama eski değeri kullanıyorsa sorun nedir?
Uygulama süreci, bağlantı havuzu veya sır önbelleği eski değeri bellekte tutuyor olabilir. Yeni sürümü gerçekten okuduğunu log veya güvenli sürüm kimliğiyle doğrulayın; ardından desteklenen yeniden yükleme ya da yeniden başlatma yöntemini uygulayın. Hata sürerse dağıtımı durdurup eski geçerli sürümle hizmeti koruyun.
