Konfigürasyon Yönetimi ve IaC: Terraform/Ansible ile Güvenlik Odaklı Altyapı

Konfigürasyon yönetimi; bir sunucunun/altyapının “nasıl olması gerektiğini” tanımlayıp bunu sürdürülebilir şekilde korumaktır. Amaç; ortamları (prod/stage) tutarlı yapmak ve değişiklikleri izlenebilir kılmaktır. Güvenlik perspektifinde bu; açık portlar, kullanıcı yetkileri, paket sürümleri, firewall kuralları, security group’lar ve sertifika/anahtar politikaları gibi ayarların kontrolüdür.

Konfigürasyon yönetimi ve IaC nedir, neden önemlidir?

Konfigürasyon yönetimi; sistem ayarlarını standartlaştırıp izlenebilir hale getirmektir. IaC (Infrastructure as Code) ise bu altyapı ve güvenlik ayarlarını kod olarak tanımlayıp repo üzerinden yönetmeyi sağlar. Önemlidir çünkü drift’i azaltır, “kim bu portu açtı?” sorusuna cevap verir ve tekrarlanabilir, denetlenebilir güvenlik sağlar.

Drift (sapma) neden oluşur?

• •Elle yapılan “geçici” değişiklikler kalıcılaşır
• •Farklı sunuculara farklı paket/sürüm kurulur
• •Acil durumlarda prosedür dışı ayar yapılır
• •Staging/prod ayrımı ya yoktur ya da sürdürülemez

☑ Mini Check: Drift sinyalleri

• •Aynı rol sunucular farklı port/paket seviyelerinde mi?
• •Staging’de çalışan prod’da bozuluyor mu?
• •Kim değişiklik yaptı sorusunun net cevabı yok mu?
• •Güvenlik ayarları “dokümanda” ama sunucuda farklı mı?
• •Acil değişiklikler geri toplanmıyor mu?

IaC, altyapıyı kodla yönetme yaklaşımıdır. Temel kazanım; kurulumun “adım adım” değil “tanım olarak” yapılmasıdır. Bu tanım repo’da yaşar; kim neyi değiştirdi, ne zaman değiştirdi, neden değiştirdi cevaplanır.

Terraform vs Ansible (rol ayrımı)

• •Terraform: altyapı kaynaklarını (network, compute, security group, load balancer) tanımlar ve yönetir.
• •Ansible: sunucu üzerinde konfigürasyon/paket/kullanıcı gibi “iç ayarları” idempotent şekilde uygular.
• •Pratikte çoğu mimaride birlikte kullanılır: Terraform “ne var?”, Ansible “içinde ne var?”

IaC pipeline mantığı (repo → plan → apply)

IaC’de değişiklikler; PR açılır, plan alınır, review edilir, sonra uygulanır. Bu akış; güvenlik değişikliklerini “gözden geçirilmiş” hale getirir. Otel/B2B projelerinde özellikle “sezonda acil değişiklik” baskısı varsa, bu pipeline kontrol mekanizmasıdır.

☑ Mini Check: IaC temeli

• •Altyapı tanımı repo’da mı?
• •PR ile değişiklik onayı var mı?
• •Plan çıktısı review ediliyor mu?
• •Apply için yetki kontrollü süreç var mı?
• •Staging/prod ayrımı kodda net mi?

Security-as-Code yaklaşımında hedef; güvenlik ayarlarını “kişilerin hafızası”ndan çıkarıp sistematik hale getirmektir. Burada kritik alanlar: security group/firewall, kullanıcı-yetki yönetimi, paket politikaları, hardening rolleri ve secret/state güvenliği.

Terraform/Ansible ile güvenlik ayarlarını nasıl yönetirim?

Terraform ile security group/firewall benzeri ağ güvenliğini kodla tanımlayıp değişiklikleri plan-review üzerinden kontrol edersiniz. Ansible ile kullanıcı/yetki, paket güncellemeleri ve hardening adımlarını idempotent rollere çevirirsiniz. İkisini birlikte kullanarak hem dış yüzeyi (portlar/erişim) hem de sunucu içini (kullanıcı/paket) denetlenebilir hale getirirsiniz.

Kritik ayarları kod tabanına taşımak (örnek kategori)

• •Security group / firewall kuralları (hangi port kimden erişir?)
• •Kullanıcı/grup/rol (root/admin politikası, sudo)
• •Paket ve servis baseline (gereksiz servisler kapalı)
• •SSH/RDP politikaları (key/MFA yaklaşımı, erişim daraltma)
• •Loglama/izleme ajanları kurulumu (SIEM entegrasyonu gibi)

Version control + code review neden güvenlik kontrolüdür?

Çünkü değişiklik “görünür” olur: kim açtı, ne açtı, neden açtı. Review süreci; hatalı port açma veya fazla yetki verme gibi riskleri daha prod’a gitmeden yakalar.

☑ Mini Check: Security-as-Code kontrol seti

• •Security group/firewall kuralları kodda mı?
• •Kullanıcı/yetki politikaları otomatik uygulanıyor mu?
• •Paket baseline ve hardening rolleri var mı?
• •Değişiklikler PR ile onaylanıyor mu?
• •Drift tespit/raporlama mekanizması var mı?

Bu rehber “komut listesi” değil; tekrar kullanılabilir model verir. Aşağıdaki örnekler, otel/B2B altyapısında en sık karşılaşılan güvenlik değişikliklerini temsil eder.

Terraform tarafı — güvenlik kaynakları (security group, network)

• •“Sadece gerekli portlar”: 80/443 public, yönetim portları allowlist/VPN
• •Ortam bazlı farklılık: staging daha esnek, prod daha sıkı
• •Modül yaklaşımı: tekrar eden güvenlik kuralları tek modülden

Terraform state güvenliği (kritik not)

State dosyası, altyapı “gerçeği”ni tutar; yanlış yönetilirse hassas bilgi sızdırabilir veya altyapı kontrolü bozulur. State’in erişimi ve saklanması (yetki, şifreleme, ayrık ortam) güvenlik planının parçasıdır.

Ansible tarafı — idempotent güvenlik rolleri

• •Kullanıcı/grup tanımı ve sudo politikası
• •Paket baseline (kurulacaklar/kaldırılacaklar)
• •Servis kapatma, firewall kuralları (sunucu içi)
• •SSH hardening (key zorunluluğu, root login kısıtı gibi)

☑ Mini Check: Örnekleri “model”e çevirme

• •Tekrarlanan kural setleri modülleştirildi mi?
• •Prod/stage farkı değişkenlerle yönetiliyor mu?
• •State erişimi ve şifreleme güvenli mi?
• •Ansible rolleri idempotent mi (tekrar çalışınca bozmuyor mu)?
• •Rollback planı var mı (yanlış değişiklikte geri dönüş)?

Otel tarafında çok sunuculu cluster (yük dengeleme, çoklu node) ve sezon trafik dalgalanması; B2B’de staging/prod ayrımı ve entegrasyon çeşitliliği; IaC’ye en çok ihtiyaç duyulan durumlardır.

Otel örneği — çok sunuculu cluster standardizasyonu

• •Her node aynı baseline güvenlik rolüyle gelir
• •Trafik artınca yeni node aynı kodla ayağa kalkar
• •“Kim bu portu açtı?” sorusu PR geçmişinden görülebilir

B2B örneği — staging/prod ayrımı ve kontrollü değişiklik

• •Staging’de plan-review ile test
• •Prod’a aynı tanımın “sıkı” varyantı uygulanır
• •Entegrasyonların erişim kuralları (IP allowlist) kodla yönetilir

Elle sunucu ayarı yerine IaC kullanmanın avantajları neler?

IaC; tekrarlanabilir kurulum, izlenebilir değişiklik geçmişi, drift azaltma ve güvenlik regresyonlarını erken yakalama avantajı sağlar. Elle ayarlarda bilgi kişilere bağımlı kalır; IaC’de bilgi repo’da yaşar ve review ile kalite kontrol edilir.

☑ Mini Check: Tekrarlanabilirlik testi

• •Yeni sunucu 30–60 dakikada aynı baseline ile kurulabiliyor mu?
• •Staging/prod farkı net ve kodla yönetiliyor mu?
• •Güvenlik değişiklikleri PR ile izleniyor mu?
• •Drift raporu düzenli üretiliyor mu?
• •Bakım/patch süreçleri IaC ile uyumlu mu?

Template İçeriği

6) Kontrol Listesi

• •Security group kuralları modülleştirildi
• •Ansible hardening rolleri idempotent
• •State güvenliği sağlandı (erişim/şifreleme)
• •PR + review zorunlu
• •Drift raporu ve geri alma süreci var