İşletim rutini olarak güvenlik

Tek seferlik sağlamlaştırma yerine yinelenen VPS güvenlik listesi kullanın

İlk sağlamlaştırma yalnızca ilk kontrol noktasıdır. Güvenli bir VPS'nin ömrü boyunca güncel envantere, kime ait olduğu bilinen erişime, desteklenen yazılıma, planlı yamaya, sınırlandırılmış ağ görünürlüğüne, yararlı algılamaya, olay prosedürüne, bağımsız yedeklere ve tekrarlanan kurtarma testlerine ihtiyacı vardır.

Temel bilgiler

İnceleme ritmi
Değişikliklerden ve uyarılardan sonra ve belgelenmiş takvimde
Erişim temeli
Bireysel hesaplar, SSH anahtarları, dar ayrıcalıklar ve korunan kurtarma
Yama temeli
Desteklenen yazılım, güvenlik güncellemeleri ve doğrulanmış yeniden başlatmalar
Kurtarma kanıtı
Yedek işinin varlığı değil, başarılı geri yükleme testi

Güncel envanter ve belirlenmiş sorumlular tutun

VPS amacını, bölgeyi, işletim sistemi sürümünü, paket kaynaklarını, uygulamaları, alan adlarını, sertifikaları, herkese açık adresleri, dinleyen hizmetleri, yöneticileri, otomasyon kimliklerini, sırları, yedekleri, izlemeyi ve dış bağımlılıkları kaydedin. Sorumlu ve beklenen inceleme tarihi atayın. Bilinmeyen yazılım ve unutulmuş hesaplar güvenilir biçimde yamalanamaz veya kaldırılamaz.

Dağıtımlardan sonra amaçlanan envanteri gerçekle karşılaştırın. ss -lntup gibi komutlar dinleyen hizmetleri gösterebilir; paket ve süreç envanterleri neyin çalıştığını açıklar. Çıktı saldırı yüzeyini tanımladığı için hassas sayın. Eski kalıpları, depoları, örnek uygulamaları, hesapları, anahtarları ve DNS kayıtlarını kaldırın.

  • Her herkese açık portun neden gerekli olduğunu belgeleyin.
  • Sertifika ve alan adı sürelerini sunucunun dışında izleyin.
  • Her önemli uygulama değişikliğinden sonra envanteri inceleyin.

Yönetici erişimini dar ve kurtarılabilir yapın

Her yöneticiye ayrı hesap ve korunan SSH anahtarı verin. Yalnızca gerekli ayrıcalıkları tanıyın ve sorumluluk değiştiğinde erişimi hızla kaldırın. /etc/ssh/sshd_config dosyasını dikkatle inceleyin, yeniden yüklemeden önce değişiklikleri doğrulayın ve tek hatanın tüm kurtarma yollarını kapatmaması için ikinci test edilmiş oturum veya sağlayıcı konsolu tutun.

Barındırma hesabını benzersiz parola ve sunuluyorsa çok faktörlü kimlik doğrulamayla koruyun. Acil prosedürleri ve kurtarma kodlarını VPS dışında denetimli konumda saklayın. Hız sınırlama ve kimlik doğrulama izlemesi yinelenen saldırıları azaltabilir; ancak güçlü anahtarların, güncel yazılımın ve küçük açık yüzeyin yerini almaz.

  • Doğrudan root girişini yalnızca başka bir ayrıcalıklı yol çalıştıktan sonra kapatın veya sınırlandırın.
  • Personel değişikliği ya da görünürlük şüphesinden sonra kimlik bilgilerini döndürün.
  • Özel anahtarları veya kurtarma kodlarını asla destek taleplerine koymayın.

Desteklenen bileşenleri yamalayın ve sonucu doğrulayın

Desteklenen işletim sistemi sürümü ve güvenilir paket kaynakları kullanın. Üreticinin güvenlik bildirimlerini izleyin, güncellemeleri görünürlük ve önem derecesine göre planlayın ve kritik değişiklikleri mümkünse test edin. Gerekli hizmetler veya çekirdek yeniden başlatılmadan ve uygulama temel sağlık kontrolünü geçmeden güncelleme tamamlanmış değildir.

Çalışma zamanlarını, konteynerleri, kontrol panellerini, eklentileri, kitaplıkları, veritabanı motorlarını ve özel uygulamaları yama envanterine dahil edin. Otomatik güvenlik güncellemeleri görünürlük süresini kısaltabilir; ancak arızaların ve gereken yeniden başlatmaların nasıl algılandığını tanımlayın. Güvenlik düzeltmesi almayan yazılımı güvenlik duvarıyla süresiz telafi etmek yerine kullanımdan kaldırın.

  • Yüksek riskli değişikliklerden önce kurtarılabilir kontrol noktası alın, ancak bunu tek yedek saymayın.
  • Paket imzalarını ve depo sahipliğini doğrulayın.
  • İstisnaları bir sorumlu ve son tarihle kaydedin.

Eyleme geçirilebilir sinyaller toplayıp müdahaleye hazırlanın

Hizmet kullanılabilirliğini, kimlik doğrulama hatalarını, ayrıcalık değişikliklerini, beklenmedik dinleyicileri, disk tükenmesini, yedek hatalarını, beklenmedik giden trafiği ve uygulamaya özel güvenlik olaylarını izleyin. İncelemede journalctl ve ilgili uygulama günlüklerini kullanın; ancak yalnızca belirtilmiş güvenlik veya işletim amacı olan veriyi toplayın ve günlükleri yetkisiz erişimden ya da sessiz değişiklikten koruyun.

Kısa olay prosedürü yazın: sınırlamaya kim karar verir, konsol erişimi nasıl çalışır, kanıt nerede korunur, hangi kimlik bilgileri döndürülür, temiz yeniden kurulum nasıl başlatılır ve kullanıcılarla ya da sağlayıcılarla kim iletişim kurar? Şüpheli ele geçirmede, güvenli ve hukuka uygunsa yıkıcı temizlemeden önce ilgili kanıtı koruyun.

  • Zamanı eşitleyin ve kayıtlarda açık saat dilimleri kullanın.
  • Kritik uyarıları etkilenen VPS'nin dışına gönderin.
  • Bir hesap ele geçirme veya hizmet arızası senaryosu uygulayın.

Kurtarmayı test edin ve inceleme döngüsünü kapatın

Şifreli, sürümlü yedekleri sunucunun birincil arıza alanının dışında tutun. Veritabanları, izinler, sırlar, sertifikalar ve uygulama sağlığı dahil tam geri yüklemeyi yalıtılmış ortamda test edin. Kurtarılabilir veri yaşı ve toplam geri yükleme süresini iş yükü hedefleriyle karşılaştırın.

Bu listeyi önemli değişikliklerden sonra ve riskle orantılı takvimde çalıştırın. Bulguları, sorumluları, son tarihleri ve kapanış doğrulamasını kaydedin. Kullanımdan kaldırırken gerekli kayıtları dışa aktarın, anahtarları ve belirteçleri iptal edin, DNS ve otomasyonu kaldırın, kullanılabilir süreçle veriyi güvenle silin ve izlemenin sunucuyu artık var saymadığını doğrulayın.

  • Kontrol paneli erişilemezken geri yükleme talimatlarını erişilebilir tutun.
  • Erişim, yamalar, görünürlük, uyarılar ve kurtarmayı tek sistem olarak inceleyin.
  • Her olayı ve başarısız geri yüklemeyi izlenen iyileştirmeye dönüştürün.

Kaynaklar

  1. NIST SP 800-123 — Genel Sunucu Güvenliği Rehberi
  2. NIST SP 800-61 Rev. 3 — olay müdahalesi önerileri
  3. Ubuntu Güvenlik Belgeleri — güvenlik güncellemeleri
Sık sorulan sorular

Sık sorulan sorular

VPS güvenliğini ne sıklıkla incelemeliyim?

Önemli değişikliklerden veya uyarılardan sonra ve belgelenmiş yinelenen takvimde inceleyin. İnternete açık sistemler ve hassas iş yükleri genellikle düşük riskli geçici sunuculardan daha sık kontrol ister.

SSH portunu değiştirmek güvenlik denetimi midir?

Genel günlük gürültüsünü azaltabilir; ancak güçlü anahtarların, güncel yazılımın, dar erişimin, güvenlik duvarı kurallarının, izlemenin ve korunan kurtarmanın yerini almaz.

Otomatik güvenlik güncellemeleri etkin olmalı mı?

Görünürlük süresini kısaltabilir; ancak izin verilen güncellemeleri, bakım beklentilerini, yeniden başlatma işlemlerini, arıza uyarılarını ve uygulama kontrollerini tanımlayın. Kritik sistemlerin aşamalı teste de ihtiyacı olabilir.

Asgari yedek testi nedir?

Gerekli veri ve yapılandırmayı yalıtılmış ortama geri yükleyin, uygulamayı başlatın, tutarlılığı ve erişimi doğrulayın, sonucu ölçün ve eksik bağımlılıkları belgeleyin.