Siber Güvenlik ve Veri Koruma
Node.js Güvenlik Güncellemesini Üretimde Güvenle Uygulayın
Node.js güvenlik güncellemesini çalışan sürümü doğrulayarak, uygulama uyumluluğunu test ederek ve geri dönüş hazırlığını tamamlayarak üretime alın.
Güvenli güncelleme, çalışan süreci doğrulamakla başlar
Node.js güvenlik güncellemesini üretim ortamına uygulamak, sunucuya yeni bir sürüm kurmaktan ibaret değildir. Çalışan uygulama eski Node.js dosyasını veya önceki container imajını kullanmayı sürdürebilir. Önce gerçek çalışma zamanını belirleyin, ardından güvenlik duyurusundaki etkilenen ve düzeltilen sürümleri karşılaştırın. Hedef sürümü uygulamanızın desteklediği seçenekler arasından seçin.
Strapi, Next.js ve n8n kurulumlarında çalışma zamanı, bağımlılıklar ve dağıtım yöntemi birlikte değerlendirilmelidir. Ancak bunların hepsini aynı anda değiştirmek, bir hatanın kaynağını bulmayı zorlaştırır. Mümkünse güvenlik düzeltmesini gereken en dar değişiklikle uygulayın; ana sürüm geçişi zorunluysa uyumluluk testlerini ayrıca planlayın. Buradaki amaç değişikliği küçültürken gerekli düzeltmeleri ertelememektir.
Bu rehber bir operasyon çerçevesidir; belirli bir CVE veya yama sürümü bildirmez. Bölümlerdeki kaynaklar genel güvenlik yaklaşımına ilişkindir ve teknik komutların ya da sürüm eşleştirmelerinin dayanağı olarak kullanılmamalıdır. Dağıtımdan önce Node.js ve kullandığınız ürünlerin resmi belgeleri üzerinden ortamınıza özgü doğrulamaları yapın. Test onayını, dağıtımı ve geri dönüş kararını kimin vereceğini de baştan belirleyin.
Uygulama süreci
Çalışma zamanı envanterini ve Plesk yollarını çıkarın
Yönetici hesabındaki sürüm bilgisi, uygulamanın kullandığı sürümü göstermeyebilir. Dağıtım kullanıcısı, servis hesabı, derleme ortamı ve container farklı Node.js dosyaları kullanabilir. Kontrolleri ilgili bağlamda yapın. Gizli bilgileri loglara taşımadan uygulama commit’ini, lockfile durumunu, başlangıç komutunu ve varsa imaj kimliğini kaydedin. Böylece sonraki karşılaştırma için güvenilir bir başlangıç noktası oluşturursunuz. Plesk’te alan adına bağlı Node.js seçimi ile SSH oturumunun PATH değişkeni farklı olabilir. Bağımlılıkların bir sürümle hazırlanıp başka bir sürümle çalıştırılmasını önlemek için panel ayarını ve komutların kullandığı yolu karşılaştırın. Ortak sistem kurulumunu değiştirmeden önce etkilenecek diğer servisleri listeleyin. Güncelleme sonrasında aynı kontrolleri tekrarlayın. Kurulum, derleme ve çalıştırma adımlarında aynı onaylı çalışma zamanını kullanmayı hedefleyin. Bunun bütün sunucudaki uygulamaların aynı ana sürüme geçirilmesi gerektiği anlamına gelmediğini unutmayın. Her uygulamanın uyumluluğunu ve dağıtım sınırını ayrı değerlendirin; paylaşılan bir değişikliğin kapsamını görünür tutun. Envantere yalnızca web sürecini değil, worker ve zamanlanmış işleri de ekleyin.
- 01
Dosya yolunu kontrol edin
Uygun Linux ortamında node -v, command -v node ve node -p "process.execPath" komutlarını çalıştırın; servis tanımındaki yolu ayrıca inceleyin.
- 02
Plesk ayarını kaydedin
Seçilen sürümü, uygulama kökünü ve başlangıç dosyasını doğrulayın. Sürüme bağlı dosya yolunu varsaymak yerine sunucudan kontrol edin.
Karşılaştırma
Node.js yaması ile bağımlılık düzeltmesini ayırın
npm audit fix komutunu Node.js yaması saymak
Düzeltmeyi içeren uyumlu Node.js sürümüne geçmek
Üretimde zorlayıcı düzeltme çalıştırmak
Ayrı dalda değişiklikleri doğrulamak
Kontrol listesi
Üretime benzer ortamda derleme ve işlev testlerini tamamlayın
Yeni sürümü önce izole ve üretime benzer bir ortamda deneyin. Aynı uygulama commit’i ve onaylı lockfile ile kurulumu yapın; projenin test ve derleme komutlarını çalıştırın. Yerel modülleri eski ortamdan kopyalamayın. Derleme sırasında gereken geliştirme bağımlılıklarını erken kaldırmayın; üretim paketini hazırlarken doğrulanmış dağıtım akışını izleyin. Test verilerinin ve kimlik bilgilerinin üretimden ayrıldığından emin olun. Kritik kullanıcı yolculuklarını uygulama sahibiyle seçin. Ana sayfanın açılması veya sağlık kontrolünün yanıt vermesi bütün işlevlerin çalıştığını göstermez. Beklenen sonuçları ve yayını durduracak koşulları testten önce yazın. Yalnızca komut çıktısını değil, işlemlerin gerçekten tamamlandığını da kaydedin. Hatalı sonuçları yeni sürümün olağan davranışı kabul ederek geçiştirmeyin. Entegrasyon testlerinde veritabanı, SMTP, nesne depolama ve dış API bağlantılarını kapsayın. Başarısız işlemlerde hata kaydını inceleyin; güvenlik kontrollerini gevşeterek testi başarılı göstermeyin. Derleme çıktısının hangi çalışma zamanıyla üretildiğini saklayın. Bu kayıt, üretimde kullanılan çıktıyla test edilen çıktının aynı olduğunu kontrol etmenizi kolaylaştırır.
- ✓
Strapi kontrolleri
Yönetim panelini derleyin; giriş, içerik düzenleme, medya yükleme, yetkilendirme, eklentiler ve özel API uçlarını sınayın.
- ✓
Next.js ve n8n kontrolleri
Next.js üretim çıktısını ve sunucu işlevlerini; n8n için webhook, zamanlanmış iş ve varsa worker akışlarını test edin.
Öne çıkanlar
Yayın öncesinde geri dönüş sınırını belirleyin
Önceki uygulama çıktısını, imaj kimliğini ve servis yapılandırmasını koruyun. Veritabanı ve dosya yedeklerinin geri yüklenebilirliğini kontrol edin. Şema değişikliği varsa yalnızca eski container’a dönmek yeterli olmayabilir. Güvenlik yamasını gereksiz veri değişiklikleriyle birleştirmemek geri dönüşü sadeleştirir. Yedeklerin bulunduğunu bilmekle yetinmeyin; geri yükleme adımlarının anlaşılır ve uygulanabilir olduğunu da doğrulayın. Tek süreçli uygulamada yeniden başlatma kesinti oluşturabilir. Kademeli geçişi ancak mimari destekliyorsa planlayın. Hata oranı, yanıt süresi, süreç kapanmaları ve kritik işlem sonuçları için kendi normal değerlerinize dayanan kabul ölçütleri belirleyin. Dağıtım sırasında bu ölçütleri değiştirmeyin. Sorun çıkarsa önce trafiği ve veriyi koruyun, ardından neden analizine geçin. Geri dönüş kararı yalnızca teknik bir komut değildir. Kararı kimin vereceği, hangi kayıtların korunacağı ve kullanıcılara nasıl bilgi verileceği belli olmalıdır. Eski sürüme dönmek giderilmeye çalışılan güvenlik riskini yeniden açabileceğinden, geri dönüşü geçici bir operasyon önlemi olarak değerlendirin ve sonraki düzeltme adımını kaydedin. Açık kalan riski sahipsiz bırakmayın.
Arka plan işlerini unutmayın
Kuyruk, zamanlanmış görev ve webhook işlemlerinin dağıtım sırasında nasıl ele alınacağını belirleyin. Yarıda kalan işi yeniden çalıştırmanın güvenli olup olmadığını kontrol edin.
Geri dönüş yetkisini netleştirin
Karar sorumlusunu, tetikleyici koşulları ve korunacak kayıtları yayın başlamadan belirleyin.
Uygulama süreci
Yeni çalışma zamanını PM2, Plesk ve Docker üzerinde devreye alın
Dağıtım sonrasında uygulamanın gerçekten yeni çalışma zamanıyla başladığını doğrulayın. Shell’de görünen node -v çıktısı servis kontrolünün yerine geçmez. Eski süreçlerin, worker’ların veya eski imajla çalışan örneklerin kalmadığından emin olun. Başlatma yöntemini mevcut servis tanımına göre seçin; kullanıcı, çalışma dizini ve ortam değişkenlerini bilinçli biçimde yönetin. Docker’da taban imajı güncellemek ile çalışan container’ı yenilemek ayrı işlemlerdir. Yeni imajın içeriğini doğrulayın ve dağıtım kaydına imaj kimliğini ekleyin. n8n gibi hazır imajla dağıtılan ürünlerde içerideki Node.js dosyasını elle değiştirmek yerine ürünün desteklenen güncelleme yolunu izleyin. Aynı etiketin her zaman aynı içeriği gösterdiğini varsaymayın; onaylanan çıktıyı izlenebilir tutun. Mimari uygunsa önce sınırlı trafikle doğrulama yapın, ardından kalan örnekleri aynı onaylı çıktıya taşıyın. Uygulamanın farklı bir kullanıcıyla başlaması dosya izinlerini ve erişimleri etkileyebilir. Bu nedenle yalnızca sürecin ayakta olmasına değil, test edilen işlevlerin dağıtım sonrasında da tamamlanmasına bakın. Kesintisiz geçişi her ortam için garanti kabul etmeyin.
- 01
PM2 ve Plesk
PM2 interpreter yolunu ve başlangıç yapılandırmasını kontrol edin. Plesk uygulamasını panelin yönettiği yöntemle yenileyin; çakışan süreç yöneticileri oluşturmayın.
- 02
Docker container’ları
Onaylanan tabanla yeni imaj oluşturun ve container’ları bu imajdan yenileyin. Eski container’ı yeniden başlatmak taban imajı değiştirmez.
Kontrol listesi
Güncellemeyi doğrulama kayıtlarıyla kapatın
Yayından sonra kritik işlemleri yeniden deneyin; bağlantı hatalarını, bellek kullanımını ve beklenmeyen yeniden başlamaları izleyin. Güvenlik taramasının sessiz kalması tek başına başarı kanıtı değildir. Çalışan sürümü, dağıtılan çıktıyı ve işlevsel testleri birlikte doğrulayın. İzleme süresini ve sorumlusunu uygulamanın riskine göre belirleyin. Logları incelerken erişim yetkilerini ve hassas veri sınırlarını koruyun. Envanteri güncelleyin; kalan eski örnekleri, geçici önlemleri ve ertelenen bağımlılık işlerini sorumlularıyla kaydedin. Düzenli bakım sürecini yapılandırırken Bikare’nin BT bakım ve teknik destek hizmetleri ile siber güvenlik ve erişim yönetimi hizmetini inceleyebilirsiniz. Amaç, sonraki duyuruda hangi uygulamanın nasıl güncelleneceğinin önceden belli olduğu bir işletim düzeni kurmaktır. Kapanış kaydı yalnızca başarılı dağıtım bildiriminden oluşmasın. Hangi riskin hedeflendiği, hangi sürümün seçildiği, hangi kontrollerin tamamlandığı ve hangi işlerin açık kaldığı aynı kayıttan anlaşılabilsin. Bakım sırasında eklenen geçici erişimleri ve ayrıntılı loglamayı gözden geçirin; kalıcı güvenlik kontrollerini ise gerekçesiz kaldırmayın. Böylece güncelleme sonraki bakım için de kullanılabilir bir kayıt bırakır.
- ✓
Kanıtları saklayın
Resmi duyuru referansını, çalışan sürümü, commit’i, lockfile durumunu, imaj kimliğini ve test sonuçlarını değişiklik kaydına ekleyin.
- ✓
Açık işleri takip edin
Geçici önlemlerin, destek dışı dalların ve ertelenen düzeltmelerin sorumlusunu ve sonraki adımını belirleyin.
Keşfetmeye devam et
İlgili içerik ve hizmetler
Konuyu tamamlayan Bikare içeriklerine göz atın.
