Konfigürasyon Drift Tespiti: Staging ve Prod Ortamlarının Güvenlik Uyumu

Konfigürasyon drift; beklenen konfigürasyon ile gerçek sistem konfigürasyonunun zamanla farklılaşmasıdır. Drift, bazen “küçük bir ayar” gibi görünür ama etkisi büyüktür: güvenlik açıkları, stabilite problemleri ve debug maliyeti.

Konfigürasyon drift nedir, neden tehlikelidir?

Konfigürasyon drift, staging/prod veya node’lar arasında ayarların zamanla sapmasıdır. Tehlikelidir çünkü aynı sistemi farklı davranır hale getirir, güvenlik kontrollerini zayıflatır ve sorunların sadece belirli node/ortamda ortaya çıkmasına yol açar. Drift tespiti yapılmadığında “neden sadece burada?” soruları uzar ve risk büyür.

Drift hangi katmanlarda görünür?

• •Firewall/security group kuralları
• •Kullanıcı/rol ve sudo izinleri
• •Paket sürümleri ve servis konfigleri
• •TLS/sertifika ayarları
• •İzleme/log ajanları ve policy’ler

☑ Mini Check : Drift sinyalleri

• •Aynı cluster’da node’lar farklı paket sürümünde mi?
• •Staging ile prod’da açık port listesi aynı mı?
• •Bir node’da 403/500 artışı var mı?
• •Acil “manuel fix” sonrası geri toplama yapılmıyor mu?
• •IaC/baseline “tek kaynak gerçek” değil mi?

Staging/prod ayrışması çoğu zaman “niyetli” değil, “pratik” nedenlerle olur: prod’da acil kapatma/açma, staging’de eksik trafik, farklı release temposu, farklı ekip müdahalesi. Sorun; farkın yönetilmemesidir.

Staging ve prod ortamlarının güvenlik uyumunu nasıl kontrol ederim?

Önce bir “beklenen konfigürasyon” referansı belirleyin (IaC veya hardening baseline). Sonra staging ve prod’dan konfig çıktıları alıp aynı kontrol setiyle karşılaştırın (portlar, kullanıcı/rol, paket sürümleri, policy’ler). Son adımda farkları kritik seviyeye göre sınıflandırıp, düzeltmeyi planlı şekilde uygulayın ve yeniden taramayla doğrulayın.

“Parite” hedefi: aynı olmak zorunda mı?

Her şey aynı olmak zorunda değil; ama farklar bilinçli ve dokümante olmalı. Örneğin staging’de debug açık olabilir; prod’da kapalı olmalıdır. Buradaki ana kural: “bilinen fark” ≠ “drift”.

☑ Mini Check : Parite yönetimi

• •Staging/prod farkları dokümante mi?
• •Prod acil değişiklikleri baseline’a geri toplanıyor mu?
• •Staging’de güvenlik kontrolleri “en az prod kadar” mı?
• •Release ve patch temposu senkron mu?
• •Drift raporu aksiyona dönüşüyor mu?

Drift’in en tehlikeli türü güvenlik drift’idir: bir node’da root login açılması, bir segmentte yanlış port, bir sunucuda eski paket sürümü gibi. Bu drift’ler sessiz ilerler ve genelde incident sırasında fark edilir.

Kritik drift örnekleri

• •Firewall kuralı drift’i (geçici port kalıcı)
• •Kullanıcı/grup drift’i (eski kullanıcı erişimi)
• •Paket versiyon drift’i (CVE taşıyan node)
• •Log/agent drift’i (bazı node’larda iz yok)

Drift’i azaltmanın en pratik yolu: “enforcement”

Sadece tespit yetmez; düzeltme döngüsü kurulmalıdır. IaC veya konfig yönetimiyle baseline “yeniden uygulanabilir” olursa drift hızla toparlanır.

☑ Mini Check : Güvenlik drift’i tespit

• •Açık port listesi node bazında aynı mı?
• •Root/admin politikası her node’da tutarlı mı?
• •Paket sürümü uyumu var mı?
• •SIEM/log agent kapsaması %100 mü?
• •İstisnalar süreli ve kayıtlı mı?

Araçlar değişir; yaklaşım sabittir: beklenen tanım → gerçek ölçüm → fark analizi → aksiyon → yeniden doğrulama.

Drift tespiti için hangi araç ve teknikleri kullanabilirim?

IaC (Terraform) ile plan/state üzerinden “beklenen vs gerçek” farkını görebilir, konfig yönetimi (Ansible) ile idempotent rolleri yeniden uygulayabilir ve compliance scan araçları/script’leriyle (agent→rapor) drift ölçümü yapabilirsiniz. En iyi sonuç; bu kontrolleri CI/CD ve bakım döngülerine entegre etmektir.

Yaklaşım 1 — IaC “plan” ve state karşılaştırması

• •Altyapı kaynakları (SG, network) drift tespiti
• •Drift varsa PR/review ile düzeltme

Yaklaşım 2 — Baseline/compliance scan (agent → rapor)

• •OS ve hardening kontrolleri pass/fail
• •Node bazlı uyum raporu

Yaklaşım 3 — “Golden config” ve idempotent uygulama

• •Ansible role/Terraform module ile baseline yeniden uygulanır
• •Manuel değişiklikler geri toplanır

☑ Mini Check : Drift tespit mekanizması

• •Baseline (beklenen) tek kaynak gerçek mi?
• •Tarama periyodu belirli mi?
• •Drift raporu ticket’a dönüşüyor mu?
• •Düzeltme otomasyona bağlı mı?
• •Re-scan ile doğrulama yapılıyor mu?

Bu bölüm “gerçek hayatta” drift nasıl çıkar ve nasıl azalır sorusunu örnekler.

Otel — DMZ/web farm’larında drift

• •Bir web node’a acil WAF bypass kuralı/port açılır
• •Sonra unutulur, sadece o node farklı kalır
• •Çözüm: node bazlı drift taraması + baseline yeniden uygulama

B2B — çok node’lu API cluster drift’i

• •Bir node’da paket güncellenir, diğerinde kalır
• •Tek node’da 500/timeout artar
• •Çözüm: paket sürüm uyumu + otomatik compliance raporu + rollout standardı

Otel ve B2B ortamlarında drift riskini nasıl azaltırım?

Manuel değişiklikleri sınırlayıp IaC/baseline’ı tek kaynak gerçek yapın. Drift taramasını periyodik ve tetikleyici (patch/release sonrası) çalıştırın; kritik sapmaları hızlıca geri toplayın. Node/cluster seviyesinde rapor üretip “tek node sorunu”nu erken yakalayın.

Fark yaratan mini bölüm (Competitor Gap): “Drift, kaçınılmaz ama yönetilebilir”

Gerçek altyapıda patch ve manuel müdahaleler kaçınılmazdır; drift kontrolü bu yüzden pratik bir güvenlik ve stabilite sigortasıdır. Drift tespiti yapan kurumlarda tek node hataları ve staging/prod farkı kaynaklı vakaların azalması beklenir.

☑ Mini Check : Sürdürülebilir drift programı

• •Patch sonrası drift taraması zorunlu
• •Release sonrası drift taraması var
• •Allowed differences dokümanı var
• •Otomatik düzeltme veya hızlı geri toplama var
• •Periyodik gözden geçirme takvimi (365 gün) var

6) Kontrol listesi

• •Allowed differences listesi var
• •Patch sonrası drift taraması zorunlu
• •Node bazlı rapor üretiliyor
• •Kritik drift için alarm var
• •Düzeltme sonrası re-scan yapılıyor