Ansible ile Sunucu Sertleştirme Baseline'ı

Sunucu güvenliğinde en yorucu noktalardan biri, iyi bildiğiniz kontrolleri her yeni sunucuda yeniden uygulamak zorunda kalmaktır. SSH ayarı, gereksiz servislerin kapatılması, auditd, zaman senkronizasyonu, journald sınırları ve temel firewall politikaları çoğu kurumda bilinir; ancak bilgi ile uygulanabilir standart aynı şey değildir. Ansible ile sertleştirme baseline’ı kurmak, güvenliği tek seferlik kontrol listesinden çıkarıp sürdürülebilir operasyon pratiğine dönüştürür.

Baseline neden önemlidir?

Birçok ekipte güvenlik sertleştirmesi “kurulumdan sonra bakarız” başlığı altında kalır. Bu durumda iki problem ortaya çıkar:

• Yeni sunucular arasında fark oluşur.
• Hangi kontrolün gerçekten uygulandığı net takip edilemez.

Baseline yaklaşımı, minimum kabul edilen güvenlik standardını kodla tanımlar. Böylece sunucu değişse bile standart değişmez.

Başlangıçta hangi kontrolleri seçmeli?

Aşırı uzun bir ilk listeyle başlamak yerine, hem etkili hem de güvenli değişiklikler seçmek daha doğrudur. Benim çoğu Linux altyapısında ilk eklediğim kontroller şunlardır:

1. SSH için parola ile girişin kapatılması
2. Root login’in sınırlandırılması
3. Gereksiz ağ servislerinin kaldırılması
4. UFW veya nftables üzerinden temel inbound politika
5. auditd, chrony ve log rotasyonunun doğrulanması

Bu kontroller kurumun gereksinimine göre genişletilebilir; ama ilk adımda hızlı kazanım üretir.

Rol yapısını nasıl kurmalı?

Tek bir dev playbook kısa vadede kolay görünür; uzun vadede bakımı zorlaştırır. Bunun yerine baseline’ı küçük ve anlaşılır rollere bölmek daha sağlıklıdır:

• common-packages
• ssh-hardening
• audit-and-logging
• firewall
• compliance-facts

Bu yapı sayesinde hangi katmanın sorun çıkardığını anlamak ve kontrollü genişlemek kolaylaşır.

- name: Harden baseline
  hosts: linux_servers
  become: true
  roles:
    - common-packages
    - ssh-hardening
    - audit-and-logging
    - firewall

Idempotent tasarım neden kritik?

Ansible ile güvenlik yönetirken en önemli prensiplerden biri, playbook’un her çalıştığında aynı sonucu güvenle üretmesidir. Eğer aynı görev ikinci çalıştırmada gereksiz değişiklik yapıyorsa, iki sorun doğar: güven azalır ve operasyon ekibi otomasyonu düzenli çalıştırmaktan kaçınır.

Bu nedenle görevler mümkün olduğunca şu özellikleri taşımalıdır:

• Dosya içerikleri açık şekilde tanımlanmalı
• Servis restart koşulları kontrollü olmalı
• Dağıtım ortamı bazında istisnalar değişkenlerle yönetilmeli
• Her kontrol için doğrulama çıktısı üretilmeli

Compliance görünürlüğü nasıl sağlanır?

Sunucu sertleştirmesinin en zayıf noktası, uygulandıktan sonra unutulmasıdır. Bunu engellemek için her çalıştırmadan sonra asgari bir uyum çıktısı üretmek gerekir. Örneğin:

• Hangi hostlar başarılı geçti?
• Hangi hostlarda drift tespit edildi?
• Hangi kontrol istisna nedeniyle atlandı?
• Son çalıştırma ne zaman yapıldı?

Bu veriler CI/CD, AWX veya merkezi log sistemiyle ilişkilendirildiğinde baseline yaşayan bir kontrol mekanizmasına dönüşür.

Üretim ortamında dikkat edilmesi gerekenler

SSH sertleştirme gibi kritik ayarlar için kademeli yayılım önemlidir. Tüm host grubuna aynı anda uygulama yapmak yerine:

1. Pilot host grubunda çalıştırın.
2. Doğrulama komutlarını otomatik ekleyin.
3. Değişiklik sonrası erişim testini zorunlu kılın.
4. Başarılı ise kalan gruplara yayın.

Bu akış, güvenliği artırırken erişim kaybı riskini düşürür.

Sonuç

Ansible ile sunucu sertleştirme baseline’ı oluşturmak, güvenlik ekibinin beklentilerini operasyon gerçekliğiyle buluşturur. Standart bir minimum seviye tanımladığınızda, güvenlik yalnızca denetim gününde hatırlanan bir kontrol listesi olmaktan çıkar. Sunucular çoğaldıkça değeri artan şey tek tek müdahaleler değil, güvenilir ve tekrar edilebilir baseline olur.