Üretici datasheet'lerindeki maksimum throughput değerleri, tüm güvenlik servisleri aynı anda açıkken elde edilen gerçek proje performansını tek başına temsil etmeyebilir. İnternet hızının yanında eş zamanlı oturum, uygulama trafiği, SSL inspection ve VPN yükü de değerlendirilmelidir.
IPS/IDS, web filtreleme, uygulama kontrolü, DNS güvenliği, anti-malware ve SSL inspection gibi servisler cihaz kaynaklarını kullanır. Hangi özelliklerin gerçekten aktif olacağı baştan belirlenmelidir.
Site-to-site VPN, remote-access VPN ve çok lokasyonlu mimarilerde tünel sayısı, kullanıcı sayısı, kimlik doğrulama ve MFA ihtiyacı sizing kararını etkiler.
Yüksek erişilebilirlik ihtiyacı varsa cihaz çiftleri, bağlantı yapısı ve failover senaryosu ayrıca tasarlanmalıdır. Cihaz seçimi yalnız bugünkü yük için değil, öngörülen büyüme için de pay bırakmalıdır.
Gerçek sizing, lisans, güvenlik veya mimari kararı; mevcut altyapı, üretici destek koşulları ve proje gereksinimleri değerlendirilerek verilmelidir.
Hayır. Rehber genel değerlendirme kriterlerini açıklar. Gerçek ürün, lisans veya mimari kararı mevcut altyapı ve ihtiyaç analiziyle verilmelidir.
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.
Firewall boyutlandırmasında pazarlama throughput değeri yerine kullanılacak inspection, VPN, TLS ve HA özellikleriyle gerçek trafik değerlendirilir. Eşzamanlı oturum, yeni oturum hızı ve küçük paket davranışı hat hızı kadar önemlidir. Sophos, FortiGate, Check Point, Palo Alto ve Linux tabanlı seçenekler aynı gereksinim matrisiyle karşılaştırılmalıdır.
500 Mbit/s internet bağlantısı için örnek pilotta yoğun saatte güvenlik profilleri açık test yapın. Kullanıcı web trafiği, VPN ve backup aynı anda çalışsın. HA düğümü kaybedildiğinde kalan cihazın kapasitesini ve devam eden oturumların davranışını ölçün; cihaz modelini yalnız kullanıcı sayısından seçmeyin.
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Hız testi iyi, yoğun saatte erişim kötü | Küçük paketler, TLS yükü, oturum limiti veya kayıt kuyruğu sınır olabilir. | Yoğun saat dağılımıyla CPU, oturum, drop ve p95 gecikmesini birlikte ölçün. |
| İzin verilmesi beklenen işlem engelleniyor | Kural 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üyor | Mevcut 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ıyor | Eksik 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. |
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.
Kimlik doğrulama kullanıcının veya iş yükünün kim olduğunu kanıtlar; yetkilendirme ise bu kimliğin ne yapabileceğini belirler. Başarılı oturum açma, bütün kaynaklara erişim izni anlamına gelmez. Kullanıcı oturumları, servis kimlikleri, API belirteçleri ve cihaz sertifikaları farklı yaşam döngülerine sahiptir. İlk giriş kadar oturum süresi, belirteç yenileme, işten ayrılma, kayıp cihaz ve acil erişim senaryolarını da tasarlayın. Kimlik sağlayıcı erişilemez olduğunda hangi oturumların süreceğini ve hangi yeni erişimlerin engelleneceğini ölçün.
En az yetki, bir görevin gerektirdiği izinlerin belirli kaynak ve süreyle sınırlandırılmasıdır. Herkese aynı yönetici rolünü vermek, erişim incelemesini ve olay araştırmasını zorlaştırır. Günlük kullanıcı hesabı ile ayrıcalıklı hesabı ayırın; servis hesaplarının etkileşimli kullanımını ve gereksiz ağ erişimini kısıtlayın. Yetki matrisi, kimliğin kaynağa hangi işlemle eriştiğini göstermelidir. Bir izin kaldırıldığında uygulamanın çalışmayı sürdürmesi de test kapsamına girer: gereksiz yetkiler bazen yalnız kontrollü azaltma sırasında ortaya çıkar.
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.
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.
TLS iletişimin gizliliğini ve bütünlüğünü sağlar; sertifika doğrulaması karşı taraf kimliğinin kontrolüne yardımcı olur. Sertifika adı, zincir, geçerlilik süresi ve güvenilen kökler birlikte değerlendirilmelidir. Bir bağlantının şifreli olması uygulamanın yetkilendirmesinin doğru olduğu anlamına gelmez. Reverse proxy veya inspection kullanılıyorsa TLS oturumunun hangi noktada sonlandırıldığını çizimde açıkça gösterin. Hata teşhisinde sertifika kontrolünü kapatmak kalıcı çözüm değildir; yanlış hostname, eksik ara sertifika ve cihaz saatini ayrı inceleyin.
Teknik rehberlerde kaynağı, hazırlama yöntemini ve güncellik bilgisini açıkça gösteriyoruz. Bu sayfa ürün seçimini otomatikleştirmek için değil, doğru soruları sormaya yardımcı olmak için hazırlanmıştır.
İçerik, Doz Teknoloji teknik ekibinin kurumsal firewall ve ağ güvenliği projelerinde kullandığı değerlendirme başlıkları temel alınarak hazırlanmıştır.
Doz Teknoloji hakkındaSizing; gerçek trafik, güvenlik servisleri, VPN, SSL inspection, oturum kapasitesi, arayüz ihtiyacı, HA ve büyüme payı birlikte değerlendirilerek ele alınır. Rehber; NIST, CISA ve üretici teknik dokümantasyonuyla çapraz kontrol edilmiştir.
Amaç yalnız internet hızına bakarak model seçmek yerine, güvenlik servisleri devredeyken oluşacak gerçek kapasite ihtiyacını ve büyüme planını birlikte değerlendirmeye yardımcı olmaktır.
Kaynaklar ve sizing kriterleri teknik olarak yeniden kontrol edildi.
Konuyu teknik rehber, ürün/lisans veya proje senaryosu üzerinden ayrıntılı olarak inceleyin.
Teknik konuyu uygulamaya dönüştürmek için ilgili hizmet ve çözüm sayfalarına geçebilirsiniz.
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