Altyapıda güvenlik genelde “network perimeter” ve “OS hardening” etrafında konuşulur. Fakat bazı sınıf saldırılarda sorun daha aşağıdadır: boot zinciri. Eğer firmware/bootloader/kernel katmanı manipüle edilebiliyorsa, üst katman kontrolleriniz “yanlış zeminde” çalışır.
Bu yazıda iki kavramı sahaya indiriyorum:
- Secure Boot: “Sadece imzalı bileşenler boot edebilir”
- TPM + Measured Boot: “Ne boot ettiğini ölç ve kanıtla”
Secure Boot neyi çözer, neyi çözmez?
Secure Boot doğru kurulduğunda:
- Bootloader / kernel / driver bileşenleri imzasızsa çalışmaz
- “Bootkit” sınıfı kalıcılıklar için eşiği yükseltir
Ama şunu çözmez:
- OS içinde yetki kazanmış bir aktörün “çalışan sistem” üzerinde yaptığı her şeyi
- İmzalı ama kötü niyetli/kompromize bileşenleri
Bu yüzden Secure Boot’u TPM ölçümü ile birlikte düşünmek gerekir.
TPM ve Measured Boot: “kanıt”
TPM, boot sırasında bazı bileşenlerin hash’lerini “PCR” (Platform Configuration Registers) denen kayıtlara yazar. Özetle:
- Her boot, bir ölçüm izi bırakır
- Bu iz, “beklenen” değerlerle karşılaştırılabilir
Bu sayede şu soruyu teknik olarak cevaplayabilirsiniz:
“Bu sunucu gerçekten benim beklediğim boot zinciriyle mi açıldı?”
Operasyonel model: Fleet’te nasıl yönetilir?
Tek makinede Secure Boot açmak kolay; zor olan fleet yönetimi. Benim sahada işleyen modelim:
- Golden boot profile (referans)
- Attestation policy (kabul kriteri)
- Rollout ring (canary → genişleme)
- Break-glass (kilitlenmeden kurtarma)
1) Golden boot profile
Bir “referans” tanımlayın:
- Firmware/UEFI sürümü
- Secure Boot key set (PK/KEK/db/dbx)
- Bootloader (shim/grub) sürümü
- Kernel + initramfs + imzalama süreci
Bu profile “değişiklik” olduğunda, bu bir release’dir.
2) Attestation policy
Attestation’ın amacı “her şey mükemmel” demek değil; risk sınıflandırması yapmaktır.
Örnek policy seviyeleri:
- Green: PCR set beklenen, host prod kabul
- Yellow: sürüm farkı var (planned update), prod kabul ama ticket aç
- Red: beklenmeyen ölçüm, prod kabul etme / karantinaya al
3) Rollout ring
Secure Boot/TPM rollout’u da bir “deployment” gibi ele alınmalı:
- Canary: düşük kritik host seti
- Pilot: seçili servis grubu
- Genelleme: tüm fleet
Her aşamada şu metrikler:
- Boot success rate
- Ortalama reboot süresi
- Kurtarma (recovery) süresi
- Red/Yellow oranı
4) Break-glass: kilitlenme senaryosu
Secure Boot yanlış kurgulanırsa en kötü gün şudur: “Update yaptık, sistem boot etmiyor.”
Break-glass planı:
- Fiziksel/remote console erişimi (OOB yönetim)
- Kurtarma medyası (imzalı)
- Key rollback prosedürü
- dbx güncellemesi geri alma (güvenli sınırlar içinde)
Bu planı yazmadan prod’da “enable” etmeyin.
En sık gördüğüm 5 hata
- Key yönetimini dokümante etmemek (kim, nerede, hangi süreçle?)
- Firmware update’leri için ring stratejisi olmadan gitmek
- Attestation’ı “binary” yapmak (ya hep ya hiç)
- OOB yönetimi zayıf bırakmak (kurtarma yok)
- Secure Boot’u açıp TPM’yi “süs” olarak bırakmak (ölçüm/policy yok)
Kapanış: Güven kökü, liderlik konusu da
Secure Boot + TPM teknik olduğu kadar organizasyonel bir iş: change yönetimi, ring rollout, runbook ve break-glass planı olmadan “enable” etmek risklidir. Doğru kurgulanırsa ise altyapıya çok değerli bir özellik kazandırır: kanıtlanabilir durum.