Veri merkezinde (ya da on-prem odakta) “en kritik erişim” çoğu zaman uygulama sunucusuna SSH değildir; sunucunun BMC kartına (iDRAC, iLO, IPMI, Redfish) erişimdir. Çünkü BMC:
- Sunucu kapalıyken bile çalışır (out-of-band).
- Konsol, güç yönetimi, firmware ve boot ayarlarını kontrol eder.
- Yanlış yapılandırılırsa “kalıcı” ve “görünmez” bir arka kapıya dönüşür.
Bu yazıda BMC’yi bir “kolay yönetim aracı” değil, kritik yönetim düzlemi olarak ele alan hardening ve segmentasyon modelini anlatıyorum.
1) Tehdit modeli: BMC neden farklı?
Uygulama sunucusu compromise olduğunda genelde “o host” etkilenir. BMC compromise olduğunda ise:
- Host’u yeniden imajlamak bile yetmeyebilir (persist).
- Firmware seviyesinde risk doğar.
- Aynı yönetim ağında başka BMC’lere pivot ihtimali artar.
Bu yüzden BMC için hedefiniz sadece “parola güçlü” değil; erişim yüzeyini küçültmek olmalı.
2) Mimari temel: ayrı yönetim ağı (management plane) + net sınırlar
Minimum viable tasarım:
- BMC VLAN/VRF: üretim data plane’den ayrı
- Yönetim bastion / jump: tek giriş kapısı
- Kimlik: merkezi (SSO/MFA) + rol bazlı
- Log: BMC audit log + ağ akışı + bastion oturum kaydı
3) Segmentasyon pratikleri: L2 ayrım yetmez, L3 kural şart
Sahada işe yarayan guardrail seti:
- BMC ağına sadece bastion subnet erişsin (L3 ACL / firewall)
- BMC ağı dışarıya (internet) kesinlikle çıkmasın
- Yönetim ağında east-west’i kıs: bir BMC’den diğerine erişim gereksiz
İlk iterasyon hedefi: “kimler bağlanabilir”i kısıtlamak. İkinci iterasyon: “ne zaman ve neden bağlanabilir”i görünür yapmak.
4) Kimlik ve erişim: yerel admin kültüründen çık
Üretimde gördüğüm en riskli örüntü: her ekipte paylaşılan “idracadmin” benzeri hesaplar.
Pratik model:
- Yerel “break-glass” hesabı sadece kasa içinde, alarm ve prosedür ile
- Günlük operasyon için kişisel kimlik + MFA
- Roller: “view”, “power”, “firmware”, “console” gibi yetki ayrımı
Eğer cihaz/ürün izin vermiyorsa bile şu iki şeyi yapın:
- Paylaşılan hesabın parolasını periyodik döndür + erişim logla
- Erişimi bastion üstünden geçir + oturum kaydı al
5) Protokoller ve servisler: kapat, sıkılaştır, güncelle
Hardening’in en pratik kısmı şu sorudur: “Bu BMC’de gerçekten hangi servisler açık olmalı?”
Genel öneriler:
- IPMI klasik arayüzlerini (özellikle şifresiz/legacy modları) kapatabiliyorsanız kapatın
- Yönetim için modern API gerekiyorsa Redfish gibi daha güncel arayüzleri tercih edin
- TLS konfigürasyonu zayıfsa (legacy cipher’lar), sadece yönetim ağı içinde dahi risk kabul etmeyin: güncelleme planlayın
Bu bölüm ürün ve firmware’e göre değişir; ama prensip değişmez: minimum servis, minimum port, minimum erişim.
6) Gözlemlenebilirlik: BMC erişimi “audit sinyali” olmalı
Başarılı BMC işletiminin alameti farikası şudur: BMC’ye erişim “görünmez” değildir.
Ölçülebilir sinyaller:
- Bastion üzerinden BMC erişim sayısı (kim, ne zaman, hangi cihaz)
- Başarısız giriş denemeleri (trend)
- Firmware değişikliği / power cycle event’leri
- Yönetim ağı akış anomalileri (beklenmeyen kaynak/destinasyon)
7) Break-glass runbook: yönetim düzlemi kesilirse ne olur?
En kritik senaryo: yönetim ağı, bastion veya kimlik altyapısı kesildi; ama sunucuya müdahale şart.
Minimum viable break-glass:
- Kasa/şifre kasası erişimi ayrı (MFA + onay)
- Kim break-glass açabilir? (rol + iki kişi kuralı)
- Erişim açıldığında otomatik alarm (SIEM / pager)
- İş bitince: parola rotasyonu + oturum raporu
Bu runbook yazılmadan “BMC güvenli” denmez.
8) Kapanış: BMC, yönetim kolaylığı değil yönetim riski de taşır
BMC’ler operasyonu hızlandırır; ama doğru tasarlanmazsa saldırgan için en hızlı yoldur. Sağlam yaklaşım:
- Ayrı management plane
- Bastion üzerinden erişim
- Rol bazlı kimlik + MFA
- Audit ve alarm
- Break-glass prosedürü
Bu çerçeveyi kurduğunuzda BMC, korkulan bir yüzey olmaktan çıkar; kontrollü ve denetlenebilir bir yönetim katmanına dönüşür.