FortiGate Firmware Upgrade Kararı: Yeni Sürüm Çıktı Diye Upgrade Yapılır mı?

01 / KISA CEVAP

Kısa Cevap

Hayır. Yeni FortiOS sürümü yayınlandı diye üretim ortamındaki FortiGate hemen upgrade edilmemelidir.

Doğru soru:

Yeni sürüme geçmek için teknik veya güvenlik açısından geçerli bir nedenimiz var mı ve bu geçişin riskini yönetebiliyor muyuz?

Firmware kararı basitçe şu denge üzerinden verilmelidir:

             UPGRADE KARARI
                   |
        +----------+----------+
        |                     |
        v                     v
     Kazanç                  Risk
        |                     |
  Security fix           Known Issues
  Bug fix                Feature changes
  Required feature       Service impact
  Vendor support         Rollback complexity
        |                     |
        +----------+----------+
                   |
                   v
            Planlı Upgrade

Amaç en yeni sürümü çalıştırmak değil, ortam için en uygun ve yönetilebilir sürümü çalıştırmaktır.

02 / FEATURE VE MATURE RELEASE NE ANLAMA GELIR?

Feature ve Mature Release Ne Anlama Gelir?

FortiOS sürümlerinde Feature ve Mature etiketleri görülebilir.

Basitleştirirsek:

Mature etiketi üretim ortamlarında önemli bir sinyal olabilir. Ancak şu anlama gelmez:

Mature = Known Issue yok

Doğru yaklaşım:

Mature
   +
Release Notes
   +
Known Issues
   +
Kullanılan özelliklerin kontrolü
   =
Daha sağlıklı karar

Aynı şekilde Feature release de otomatik olarak “kullanılmamalı” anlamına gelmez. Ortamın ihtiyaç duyduğu bir özellik, kritik güvenlik düzeltmesi veya destek gereksinimi ilgili release hattına geçmeyi gerekli kılabilir.

03 / ÖNCE UPGRADE SEBEBINI BELIRLEYIN

Önce Upgrade Sebebini Belirleyin

Upgrade planlamadan önce ilk soru şudur:

Neden upgrade ediyoruz?

Geçerli nedenlerden bazıları:

• Kritik güvenlik açığının giderilmesi
• Ortamda yaşanan ve yeni sürümde düzeltilen bir bug
• İhtiyaç duyulan yeni bir özellik
• Mevcut release hattının destek durumunun değişmesi
• Fortinet TAC tarafından önerilen düzeltme sürümü
• Donanım veya Security Fabric bileşenleriyle uyumluluk gereksinimi

Zayıf gerekçe ise yalnızca şudur:

"GUI'de yeni firmware göründü."

Yeni sürümün varlığı, tek başına production değişikliği için yeterli gerekçe değildir.

04 / RELEASE NOTES OKUMADAN UPGRADE KARARI VERMEYIN

Release Notes Okumadan Upgrade Kararı Vermeyin

Firmware seçiminde en kritik dokümanlardan biri ilgili sürümün Release Notes dokümanıdır.

Sadece “Resolved Issues” bölümüne bakmak yeterli değildir.

Kontrol edilmesi gereken başlıklar:

Release Notes
     |
     +-- Special Notices
     +-- Known Issues
     +-- Resolved Issues
     +-- Changes in CLI
     +-- Changes in GUI behavior
     +-- Changes in default behavior
     +-- Upgrade Information
     +-- Supported models / limitations

Özellikle üretim ortamında kullanılan özellikleri anahtar kelime olarak aramak faydalıdır:

IPsec
SSL VPN
BGP
OSPF
SD-WAN
HA
Web Filter
Proxy
SAML
RADIUS
FortiLink
NP6 / NP7

Örneğin ortamınızda IPsec yoğun kullanılıyorsa, yeni sürümde IPsec ile ilgili Known Issue bulunması sizin için genel bir GUI problemiyle aynı ağırlıkta değildir.

05 / KNOWN ISSUE VARSA UPGRADE YAPILMAZ MI?

Known Issue Varsa Upgrade Yapılmaz mı?

Hayır. Neredeyse her büyük yazılım platformunda Known Issues bulunabilir.

Asıl soru:

Bu Known Issue benim kullandığım özelliği, modelimi veya trafik akışımı etkiliyor mu?

Örnek değerlendirme:

Bu nedenle yalnızca Known Issue sayısını saymak yerine iş etkisini değerlendirmek gerekir.

06 / SSL VPN ETKISINI ÖZELLIKLE KONTROL EDIN

SSL VPN Etkisini Özellikle Kontrol Edin

Major veya minor FortiOS branch değişimlerinde yalnızca bug davranışları değil, özelliklerin yaşam döngüsü de değişebilir.

Bunun güçlü örneklerinden biri SSL VPN'dir.

Fortinet'in güncel dokümantasyonunda FortiOS 7.6.3 ve sonrasında SSL VPN tunnel mode'un artık desteklenmediği ve IPsec VPN'e geçiş yapılması gerektiği belirtilmektedir.

Bu durumda örneğin:

Mevcut ortam
    |
    +-- SSL VPN Tunnel Mode
    |
    v
FortiOS 7.6.3+

geçişi yalnızca:

Firmware Upgrade

değildir.

Aynı zamanda:

Remote Access Migration

projesidir.

Dolayısıyla upgrade öncesinde şunlar kontrol edilmelidir:

• Kullanılan remote-access yöntemi
• FortiClient uyumluluğu
• Authentication yöntemi
• MFA / SAML entegrasyonu
• Kullanıcı grupları
• Split tunnel davranışı
• Yeni IPsec dialup tasarımı gerekiyorsa geçiş planı

07 / MODEL VE ORTAM AYNI DEĞILSE BAŞKASININ TECRÜBESI YETERLI DEĞILDIR

Model ve Ortam Aynı Değilse Başkasının Tecrübesi Yeterli Değildir

Bir firmware'in başka bir FortiGate modelinde sorunsuz çalışması sizin ortamınız için garanti değildir.

Çünkü değerlendirme şunlara bağlıdır:

FortiGate modeli
FortiOS mevcut sürüm
Hedef sürüm
HA / Standalone
VDOM kullanımı
Routing protokolleri
VPN yapısı
Security Profiles
NPU platformu
FortiManager / FortiAnalyzer entegrasyonu
Security Fabric bileşenleri

Bu nedenle:

“Aynı firmware'i başka müşteride kullandım, sorun çıkmadı.”

faydalı bir tecrübedir fakat resmi upgrade path ve release notes kontrolünün yerini tutmaz.

08 / UPGRADE PATH MUTLAKA KONTROL EDILMELI

Upgrade Path Mutlaka Kontrol Edilmeli

FortiOS upgrade işlemlerinde mevcut sürümden hedef sürüme her zaman doğrudan geçiş mümkün olmayabilir.

Fortinet'in Upgrade Path Tool aracı model, mevcut sürüm ve hedef sürüm için doğrulanmış geçiş adımlarını gösterir.

Örnek mantık:

Current Version
      |
      v
Intermediate Release
      |
      v
Intermediate Release
      |
      v
Target Version

Ara sürümleri atlayarak doğrudan hedef firmware'e geçmek aşağıdaki riskleri oluşturabilir:

• Konfigürasyon kaybı
• Yönetim erişiminin kaybedilmesi
• HA senkronizasyon problemi
• Beklenmeyen servis kesintisi
• Boot problemi

Bu nedenle her değişiklik öncesinde güncel Upgrade Path Tool tekrar kontrol edilmelidir. Daha önce aynı geçiş yapılmış olsa bile Fortinet desteklenen path bilgisini güncelleyebilir.

Resmi araç:

Fortinet Upgrade Path Tool

09 / HA ORTAMINDA İLK KONTROL FIRMWARE DEĞIL CLUSTER SAĞLIĞIDIR

HA Ortamında İlk Kontrol Firmware Değil Cluster Sağlığıdır

HA çalışan FortiGate'lerde upgrade öncesi mevcut cluster zaten problemliyse firmware değişikliği riski artırır.

Önce cluster'ın sağlıklı ve senkron durumda olduğu doğrulanmalıdır.

Temel kontroller:

get system status
get system ha status
diagnose sys ha status
diagnose sys ha checksum cluster

Kontrol edilmesi gerekenler:

• Primary / Secondary durumu
• HA heartbeat
• Configuration synchronization
• Session pickup tasarımı
• Interface health
• Mevcut alarm ve performans problemleri

Basit kural:

HA zaten sağlıksız
      |
      X
Firmware upgrade ile düzeltmeye çalışma
      |
      v
Önce mevcut problemi çöz

Firmware upgrade bir troubleshooting yöntemi olarak rastgele kullanılmamalıdır.

10 / BACKUP ALMAK ROLLBACK PLANI DEMEK DEĞILDIR

Backup Almak Rollback Planı Demek Değildir

Upgrade öncesi configuration backup almak zorunlu bir adımdır; ancak rollback planının tamamı değildir.

Gerçek rollback planı şu sorulara cevap vermelidir:

Yeni firmware açılmazsa ne yapacağız?
Management erişimi kaybolursa ne yapacağız?
HA üyelerinden biri upgrade olmazsa ne yapacağız?
Kritik VPN'ler çalışmazsa ne kadar bekleyeceğiz?
Hangi koşulda geri dönüş kararı vereceğiz?
Kim karar verecek?

Minimum hazırlık:

• Güncel configuration backup
• Lisans / gerekli sistem dosyalarının yedeği
• Mevcut firmware/build bilgisinin kaydı
• Upgrade path çıktısı
• Console / out-of-band erişim
• Bakım penceresi
• Doğrulama testleri
• Geri dönüş kriterleri

Fiziksel FortiGate cihazları önceki firmware'i alternatif partition'da tutabilir. Ancak Fortinet'in dokümantasyonunda bu yöntem yalnızca bir önceki upgrade adımına geri dönebildiği için çok adımlı upgrade'lerde her hop sonrasında test yapılması özellikle önemlidir.

Ayrıca Fortinet klasik anlamda desteklenen bir downgrade path sunmaz. Bu nedenle “gerekirse eski firmware'i tekrar yükleriz” yaklaşımı rollback planı olarak kabul edilmemelidir.

11 / HER UPGRADE HOP'UNDAN SONRA TEST EDIN

Her Upgrade Hop'undan Sonra Test Edin

Örneğin upgrade path üç firmware adımı içeriyorsa yalnızca son sürümde test yapmak risklidir.

Daha doğru yaklaşım:

Version A
   |
   v
Version B
   |
   +--> Test
   |
   v
Version C
   |
   +--> Test
   |
   v
Target Version
   |
   +--> Final Test

Çünkü backup partition ile geri dönüş imkanı genellikle yalnızca bir önceki firmware adımı için anlamlıdır.

Her adımda en azından:

• Management erişimi
• HA durumu
• Routing
• Internet erişimi
• Kritik VPN'ler
• Authentication
• Kritik firewall policy akışları

kontrol edilmelidir.

12 / UPGRADE SONRASI CONFIG ERROR KONTROLÜ

Upgrade Sonrası Config Error Kontrolü

Firmware geçişi sonrasında eski konfigürasyondaki bazı satırlar yeni sürümde değişmiş veya desteklenmiyor olabilir.

Kontrol için kullanılabilecek önemli komutlardan biri:

diagnose debug config-error-log read

Bu çıktı upgrade sırasında parse edilemeyen veya dönüştürülemeyen configuration satırlarını tespit etmeye yardımcı olabilir.

Çıktının boş olması tek başına tüm servislerin sağlıklı olduğu anlamına gelmez; operasyonel testler ayrıca yapılmalıdır.

13 / PRODUCTION ÖNCESI BASIT BIR KARAR MATRISI

Production Öncesi Basit Bir Karar Matrisi

Firmware kararını aşağıdaki gibi puanlamak pratik olabilir:

Bu tablo “otomatik karar” vermez; değişiklik öncesinde kritik soruların unutulmasını önler.

14 / ÖNERILEN KARAR AKIŞI

Önerilen Karar Akışı

Yeni firmware yayınlandı
        |
        v
Upgrade için gerçek ihtiyaç var mı?
        |
     +--+--+
     |     |
    Hayır  Evet
     |     |
     v     v
   Bekle   Release Notes
             |
             v
        Known Issues
             |
             v
      Kullanılan servisler
             |
             v
       Model / HA / Fabric
             |
             v
       Upgrade Path Tool
             |
             v
       Backup + Rollback
             |
             v
          Test Planı
             |
             v
        Change Window
             |
             v
           UPGRADE

15 / NE ZAMAN BEKLEMEK DAHA MANTIKLI OLABILIR?

Ne Zaman Beklemek Daha Mantıklı Olabilir?

Aşağıdaki durumlarda hedef firmware'i hemen production'a almak yerine beklemek veya farklı bir patch değerlendirmek daha sağlıklı olabilir:

• Upgrade için operasyonel bir ihtiyaç yoksa
• Kritik kullanılan servislerle ilgili Known Issue varsa
• Yeni major/minor branch'e geçiş yapılıyorsa ve yeterli test yoksa
• Rollback erişimi hazır değilse
• HA cluster zaten sağlıksızsa
• Security Fabric uyumlulukları doğrulanmadıysa
• Remote access gibi kritik bir özellik davranış değiştiriyorsa

Ancak aktif olarak sömürülen kritik bir güvenlik açığı gibi durumlarda “Mature release beklemek” de yanlış karar olabilir. Güvenlik riski ile operasyon riski birlikte değerlendirilmelidir.

16 / EN KRITIK ÇIKARIM

En Kritik Çıkarım

Firmware yönetiminde en tehlikeli iki yaklaşım şunlardır:

"Yeni sürüm çıktı, hemen geçelim."

ve

"Çalışıyor, hiçbir zaman upgrade etmeyelim."

İyi firmware yönetimi bu iki uç arasında risk bazlı karar vermektir.

Doğru firmware, en yeni firmware değil; güvenlik, stabilite, özellik ihtiyacı, bilinen problemler ve geri dönüş kabiliyeti birlikte değerlendirildiğinde ortam için en doğru olan firmware'dir.

17 / YAYIN ÖNCESI KONTROL LISTESI

Yayın Öncesi Kontrol Listesi

18 / RESMI KAYNAKLAR

Resmi Kaynaklar

• Fortinet Upgrade Path Tool
• FortiOS 7.6 — SSL VPN tunnel mode replaced with IPsec VPN
• FortiOS Release Notes

19 / SONUÇ

Sonuç

FortiGate firmware upgrade kararı yalnızca sürüm numarasına bakılarak verilmemelidir.

Sağlıklı karar modeli:

Feature / Mature
       +
Release Notes
       +
Known Issues
       +
Kritik servis etkileri
       +
Upgrade Path
       +
Backup / Rollback
       +
Test Planı
       =
Yönetilebilir Firmware Upgrade

Yeni firmware önemli olabilir; ancak production ortamında asıl hedef en güncel görünmek değil, kontrollü ve geri dönülebilir şekilde güvenli kalmaktır.