Ana içeriğe geç

SecuraWall.com

E-posta güvenliği ve sürekliliği

Keşfedin
Teknik Rehber

FortiGate Lisans Yenileme Rehberi
Yenilemeden Önce Kontrol Edilmesi Gerekenler

Mevcut lisansı otomatik olarak aynı kapsamla yenilemek her zaman en doğru seçenek olmayabilir. Cihazın kapasitesi, kullanım şekli, güvenlik servisleri ve destek yaşam döngüsü birlikte değerlendirilmelidir.

1. Mevcut Model ve Kapasite

CPU/bellek kullanımı, oturum sayısı, internet kapasitesi ve etkin güvenlik servisleri mevcut cihazın yeni dönem için yeterli olup olmadığını gösteren temel verilerdir.

2. Abonelik Kapsamı

IPS, web filtreleme, uygulama kontrolü ve diğer güvenlik servislerinin hangilerinin gerçekten kullanıldığı kontrol edilmelidir. Gereksiz veya eksik kapsamlar teklif öncesinde netleştirilebilir.

3. Destek ve Yaşam Döngüsü

Cihazın üretici destek durumu ve planlanan kullanım süresi dikkate alınmalıdır. Yakın dönemde donanım yenilemesi gerekiyorsa yalnız lisans uzatmak ekonomik veya teknik açıdan uygun olmayabilir.

4. Yenileme mi, Yeni Cihaz mı?

Karar; performans, güvenlik servisleri, bağlantı ihtiyacı, büyüme ve toplam sahip olma maliyeti üzerinden verilmelidir.

KONTROL LİSTESİ

Teklif veya Proje Öncesinde Hazırlayın

  • FortiGate model bilgisi
  • Mevcut lisans / destek bitiş tarihi
  • Aktif güvenlik servisleri
  • CPU ve bellek kullanımı
  • İnternet ve VPN kapasitesi
  • Büyüme ihtiyacı
  • Donanım yaşam döngüsü
ÖNEMLİ

Rehber Genel Bilgilendirme Amaçlıdır

Gerçek sizing, lisans, güvenlik veya mimari kararı; mevcut altyapı, üretici destek koşulları ve proje gereksinimleri değerlendirilerek verilmelidir.

FAQ

Sık Sorulan Sorular

Bu rehber ürün seçimi için tek başına yeterli mi?

Hayır. Rehber genel değerlendirme kriterlerini açıklar. Gerçek ürün, lisans veya mimari kararı mevcut altyapı ve ihtiyaç analiziyle verilmelidir.

Teklif almadan önce hangi bilgileri hazırlamalıyım?

Kullanıcı/cihaz sayısı, mevcut ürün veya altyapı, kapasite, lisans süreleri ve beklenen büyüme bilgileri teklif sürecini hızlandırır.

Mimari ve çalışma modeli

Yenilemede cihaz seri numarası, model, sözleşme bitişi ve kullanılan servislerin kapsamı birlikte incelenir. Destek, güncelleme, tehdit servisleri ve bulut özellikleri farklı haklar olabilir. Güncel paket veya destek süresini geçmiş satın alma adından varsaymayın. HA üyeleri, yedek cihaz ve büyüme gereksinimi maliyeti etkileyebilir.

  1. 1Cihaz ve sözleşme
  2. 2Gereksinim eşleştirmesi
  3. 3Resmî kapsam doğrulaması
  4. 4Yenileme sonrası kontrol
Model destek yaşam döngüsünü ve HA lisans kapsamını güncel resmî belgelerle doğrulayın.

Tasarım parametreleri

Cihaz ve entitlement
Seri numarası, sözleşme kapsamı ve portal kaydını eşleştirin; yenilemenin başka cihaza atanmadığını doğrulayın.
Güncelleme ve destek
İmza güncellemesi, bulut servisleri ve üretici desteğinin sürelerini ayrı kontrol edin; sürüm desteği lisans süresinden farklıdır.
Kimlik ve kapsam
Kullanıcı, cihaz ve servis kimliklerini ayırın. Politikanın uygulandığı kaynakları ve dışarıda kalan erişim yollarını listeleyin.
Politika kararı
İzin, engelleme ve istisna koşullarını açık yazın. Kural sırası, varsayılan davranış ve oturum yenilenmesi sonucu değiştirebilir.
Kapasite ve gecikme
Yoğun saatteki gerçek iş yükünü ölçün. Güvenlik kontrolü açıkken yanıt sürelerini ve kuyrukları kontrolsüz temel ölçümle karşılaştırın.
Kayıt ve müdahale
Karar kaydının hangi sistemde tutulduğunu belirleyin. Olay kimliği, zaman, kaynak ve politika gerekçesi araştırmayı mümkün kılmalıdır.

Hesap ve uygulama örneği

Örnek yenileme dosyasında mevcut haklar, kullanılan özellikler ve yeni dönemin gereksinimini üç sütunda karşılaştırın. İkinci HA üyesinin ve destek erişiminin kapsamını üreticiden doğrulayın. Yenileme sonrası entitlement görünümü ve kullanılan servislerin çalışmasını kontrol edin; yeni paket otomatik olarak aynı kapsam demek değildir.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Portal aktif, cihaz eski imzayla çalışıyorSaat, DNS, internet erişimi veya senkronizasyon sorunu olabilir.Cihazdaki güncelleme sonucunu, imza tarihini ve entitlement durumunu birlikte inceleyin.
İzin verilmesi beklenen işlem engelleniyorKural kapsamı veya istisna yanlış eşleşiyor olabilir; kontrolü bütünüyle kapatmak nedeni gizler.Tek bir test kimliği ve kaynakla karar kaydını inceleyin; aynı koşulu pilotta tekrar üretin.
Politika değiştiği halde erişim sürüyorMevcut oturum, belirteç veya başka bir erişim yolu farklı kontrol süresine sahip olabilir.Yeni ve mevcut oturumu ayrı test edin; doğrudan erişimin politika noktasını atlamadığını doğrulayın.
Alarm var ancak olay araştırılamıyorEksik alan, saat farkı veya veri toplama kesintisi ilişkilendirmeyi engelliyor olabilir.Kaynak kaydıyla merkezi kaydı eşleştirin; olayın baştan sona izlenebildiğini gösterin.

Kabul ve doğrulama kontrolleri

  1. Model destek yaşam döngüsünü ve HA lisans kapsamını güncel resmî belgelerle doğrulayın.
  2. İzinli ve reddedilmesi gereken akışları aynı test kimliğiyle ayrı doğrulayın.
  3. Yeni oturum, süresi dolan oturum ve iptal edilen yetkiyi sınayın.
  4. İstisnalar için sahip, kapsam ve bitiş tarihi kaydedin.
  5. Yanlış engelleme sırasında dar kapsamlı geri alma adımını uygulayın.
  6. Log kesintisi ve politika servisinin erişilememesi için davranışı belgeleyin.

İlgili kavramlar

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Maliyet ölçümünün sınırı

Maliyeti yalnız satın alma veya aylık kaynak bedeli olarak görmeyin. Lisans kapsamı, depolama, veri çıkışı, yedekleme, destek, işletim emeği ve arıza etkisi farklı kalemlerdir. Hesap için aynı hizmet seviyesi, kapasite ve süreyi kullanın; ucuz görünen seçenek başka bir yükümlülüğü dışarıda bırakıyor olabilir. Tahmin ile gerçekleşeni kaynak veya iş birimi bazında karşılaştırın. Taahhütlü modelde kullanım azalması, esnek modelde ise kontrolsüz büyüme riskini değerlendirin. Fiyat ve lisans koşullarını karar günündeki resmî belgelerden doğrulayın.

Yüksek erişilebilirlik ile kurtarma ayrımı

Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve yedekleme birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.

Politikanın yaşam döngüsü

Bir politika yalnız etkinleştirildiği anda değil, kapsamı değiştikçe de yönetilmelidir. Taslak, gözlem, pilot, uygulama ve periyodik inceleme aşamalarını ayırın. Her istisnanın sahibi, gerekçesi, kapsamı ve sona erme tarihi olmalıdır. Test verileri gerçek kullanıcı davranışını temsil etmezse başarılı pilot üretimde yanlış engellemelere dönüşebilir. Önce kimin ve hangi uygulamanın etkilenebileceğini belirleyin; sonra ölçülebilir kabul koşullarıyla devreye alın. Geri alma yolu yalnız düğme konumunu değil, değişikliğin kim tarafından ve hangi koşulda geri alınacağını da tanımlamalıdır.

Telemetri ve zaman eşleştirmesi

Telemetri, sistemin ne yaptığını açıklayan log, metrik ve olay kayıtlarının bütünüdür. Log bir olayın ayrıntısını, metrik zaman içindeki davranışı, dağıtık iz ise isteğin bileşenler arasındaki yolunu gösterir. Saat farkları aynı olayı farklı zamanlarda olmuş gibi gösterebilir. Merkezi zaman senkronizasyonu, kaynak kimliği ve tutarlı saat dilimi kullanın. Alarm tasarımında yalnız eşik değil, ne kadar sürdüğü ve kullanıcıya etkisi de değerlendirilmelidir. Kayıtların kesildiği durum ayrıca izlenmeli; günlük kaydı bulunmaması, olay yaşanmadığı şeklinde yorumlanmamalıdır.

Güven sınırı ve hata alanı

Güven sınırı, aynı erişim kararlarını paylaşan bileşenleri ayırır; hata alanı ise tek bir olayın birlikte etkileyebileceği kaynakları tanımlar. İki VLAN kullanmak, aralarında serbest yönlendirme varsa güçlü bir güven sınırı kurmaz. İki yedek aynı yönetici hesabıyla silinebiliyorsa da farklı klasörlerde bulunmaları ayrı hata alanı sağlamaz. Tasarımda fiziksel yer, kimlik sağlayıcı, yönetim hesabı, ağ yolu ve enerji kaynağını ayrı ayrı değerlendirin. Bir bileşen kaybedildiğinde hangi erişimlerin ve kurtarma seçeneklerinin ayakta kalacağını sınayın.

Birincil teknik dokümantasyon

Editoryal Şeffaflık · Kim · Nasıl · Neden

Bu Rehber Nasıl Hazırlandı?

KİM?

Doz Teknoloji Teknik Ekibi

Bu rehber, Doz Teknoloji teknik ekibinin kurumsal IT projelerinde kullandığı değerlendirme kriterleri temel alınarak hazırlanmıştır.

Doz Teknoloji hakkında
NASIL?

Teknik Kriterler + Birincil Kaynaklar

FortiGate seri numarası, FortiCare/FortiGuard kayıt durumu, sözleşme kapsamı ve yenileme öncesi kontrol adımları Fortinet’in güncel dokümantasyonuyla karşılaştırıldı.

NEDEN?

Karar Kalitesini Artırmak

Yenileme sırasında yanlış cihaz, yanlış sözleşme veya eksik servis kapsamı riskini azaltmak.

SON TEKNİK GÖZDEN GEÇİRME

İçerik ve birincil kaynaklar yeniden kontrol edildi.

İlgili Sonraki Adımlar

Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.

Bu Rehberle İlgili Kurumsal Çözümler

Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.

Teknik İhtiyacınızı Birlikte Değerlendirelim

Mevcut altyapı, kullanıcı veya iş yükü bilgilerini paylaşın; ürün, lisans veya proje kapsamını ihtiyaca göre netleştirelim.

Teknik Talep Oluşturun
Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!