CIS Benchmark ve Hardening Baseline: Standart Bazlı Sunucu Güvenliği

CIS Benchmark, işletim sistemleri ve yaygın bileşenler için “güvenli konfigürasyon” önerileri sunan, sektörde yaygın kabul görmüş bir referans setidir. Ama benchmark’ı olduğu gibi uygulamak her kurum için uygun olmayabilir; çünkü iş ihtiyaçları (remote erişim, log saklama, entegrasyonlar) farklıdır. Bu nedenle hedef; benchmark’ı “kaynak” olarak kullanıp kurum baseline’ına dönüştürmektir.

CIS Benchmark nedir, sunucu güvenliğinde nasıl kullanılır?

CIS Benchmark, belirli OS/web server için güvenli konfigürasyon önerileri sunan standart bir rehber setidir. Sunucu güvenliğinde; uygun benchmark seçilir, kurum ihtiyaçlarına göre uyarlanmış bir baseline çıkarılır ve uyumu otomatik taramalarla sürekli doğrulanır.

CIS’i “doğru yerde” konumlandırmak

• •CIS = referans ve kapsamlı kontrol listesi
• •Baseline = kurumun “minimum güvenlik barı”
• •Compliance scan = baseline’a uyumun sürekli ölçümü

Bu üçü birlikte çalıştığında hardening sürdürülebilir olur.

☑ Mini Check : Benchmark seçimi net mi?

• •Hangi OS/web server için benchmark seçildi?
• •DMZ/web ve iç katmanlar için farklı profil var mı?
• •“Uygulanamaz” kontroller gerekçeli mi?
• •Baseline dokümanı tek kaynak gerçek mi?
• •Güncelleme/patch sonrası tekrar kontrol planı var mı?

Baseline; kurumun minimum güvenlik seviyesini yazılı hale getirir ve yeni sunucu açılışlarında “unutulmuş ayar” riskini azaltır. Buradaki temel prensip: minimum bar + tekrar edilebilir uygulama + doğrulanabilir kanıt.

Hardening baseline nasıl hazırlanır?

Önce hedef sistemleri sınıflandırın (DMZ web, app, DB, API/portal). Sonra CIS benchmark’tan seçilmiş kontrolleri “kurum standardı”na çevirin ve uygulanabilir maddeleri netleştirin. Son adımda baseline’ı otomasyonla uygulayın (IaC/konfig yönetimi) ve compliance taramasıyla uyumu sürekli ölçün.

Baseline içeriği (pratik bölümler)

• •Erişim politikası (SSH/RDP, MFA, bastion/SSM)
• •Hesap/rol yapısı (least privilege)
• •Servis/port politikası (minimum exposure)
• •Loglama ve audit (kim ne yaptı?)
• •Patch sonrası doğrulama (regresyon kontrolü)

Otel ve B2B için “profil” yaklaşımı

• •Otel DMZ/web: daha sıkı inbound kuralları, WAF/CDN, minimum servis
• •B2B API/portal: rate limit, audit log, entegrasyon güvenliği

Baseline’da profil yaklaşımı, “her sunucuya aynı kural” hatasını azaltır.

☑ Mini Check : Baseline doküman kalitesi

• •Kontroller ölçülebilir mi (pass/fail)?
• •Her kontrolün owner’ı ve istisna prosedürü var mı?
• •DMZ/web ve API/portal profilleri ayrıldı mı?
• •Kanıt üretimi tanımlı mı (rapor, log, screenshot)?
• •Baseline değişiklikleri versiyonlanıyor mu?

Hardening’in “sürekli” olmasını sağlayan kısım otomatik kontrol mekanizmasıdır. Çünkü sunucular zamanla drift eder: acil değişiklik, patch sonrası ayar kayması, yeni servis ekleme gibi. Compliance taraması bu sapmayı görünür kılar.

Otomatik uyum taraması (compliance scan) nasıl çalışır?

Compliance scan, sunucuya agent veya script yaklaşımıyla kurulur; baseline kontrollerini otomatik ölçer ve rapor üretir. Rapor; hangi maddelerin uyumlu/uyumsuz olduğunu gösterir ve düzeltme aksiyonlarına dönüşür. Patch sonrası veya değişiklik sonrası tarama çalıştırılarak drift erken yakalanır.

Agent→rapor akışı ve operasyonel döngü

• •Agent/script çalışır → ölçer → raporlar
• •Rapor ticket’a dönüşür → owner atanır
• •Düzeltme uygulanır → yeniden tarama ile doğrulanır

Bu döngü, güvenliği “ölçülen” hale getirir.

Uyum raporlarının KVKK teknik tedbirlerle ilişkisi

Hardening baseline, KVKK teknik tedbirlerinin “uygulandığını gösteren” kanıt üretir. Bu nedenle raporların saklanması, erişim kontrolü ve log/audit (kim erişti?) süreci /tr/raporlama/kvkk-veri-guvenligi ile uyumlu olmalıdır.

☑ Mini Check : Compliance sistemi çalışıyor mu?

• •Tarama periyodu ve tetikleyiciler (patch sonrası) var mı?
• •Raporlar ticket’a dönüşüyor mu?
• •Owner ve SLA tanımlı mı?
• •False-positive/istisna yönetimi var mı?
• •Raporlar KVKK uyumlu saklanıyor mu?

Bu bölüm, “politikayı nasıl yazarım?” sorusunu somutlaştırır. Amaç; yeni sunucuların minimum güvenlik seviyesini garanti ederken iş gereksinimlerini bozmamaktır.

Otel — DMZ/web katmanı profili

• •DMZ’de minimum servis + minimum inbound
• •Yönetim erişimi ayrı ağdan, oturum kayıtlı
• •WAF/CDN/Rate limit ile saldırı yüzeyi azaltma
• •Log/audit zorunlu

B2B — API/portal profili

• •API uçlarında rate limit, audit log, least-privilege servis hesapları
• •Secrets management (vault/KMS) zorunlu
• •Patch sonrası compliance taraması zorunlu
• •Staging/prod ayrımı net

Otel ve B2B için örnek hardening politikası nasıl görünür?

Politika; hangi OS/web server benchmark’ının temel alındığını, DMZ/web ve API/portal için ayrı profilleri, zorunlu kontrolleri (erişim, port/servis, log/audit, secrets, patch sonrası tarama) ve istisna yönetimini içerir. Her kontrolün ölçüm yöntemi ve kanıt formatı tanımlı olmalıdır.

Fark yaratan mini bölüm (Competitor Gap): “Baseline yaşayan dokümandır”

Baseline bir kez yazılıp bırakılırsa eskir. Yeni tehdit modeli, OS sürümü, ürün güncellemesi geldikçe baseline revize edilmelidir. Sheet notu ile uyumlu: baseline ve benchmark’lar yaşayan dokümanlar olmalı ve 365 günlük periyotta gözden geçirilmelidir.

☑ Mini Check : Politika sürdürülebilir mi?

• •Profil bazlı baseline var (DMZ vs API)
• •Patch sonrası zorunlu compliance kontrol var
• •İstisnalar süreli ve kayıtlı
• •Baseline versiyonlanıyor
• •KVKK teknik tedbirlerle ilişki kurulmuş

Varsayım: Baseline maddeleri OS/web server’a göre uyarlanır; tablo örnek “alan seti” sunar.

6) Kontrol listesi

• •Baseline profilleri ayrıldı
• •Pass/fail ölçüm tanımlı
• •Scan periyodu ve tetikleyiciler net
• •Rapor→ticket→fix akışı var
• •Revizyon takvimi (365 gün) var

Deliverables

• •Benchmark seçim dokümanı
• •DMZ-Web ve API/Portal profil tanımları
• •Pass/fail baseline kontrol seti
• •Agent/script compliance scan planı
• •Rapor→ticket→fix→re-scan akışı
• •İstisna kaydı ve 365 günlük revizyon takvimi