Bir güvenlik duvarı cihazı satın almak ile o cihazın kurallarının yönetilmesi, olayların incelenmesi ve değişikliklerin uygulanması farklı hizmetlerdir. Kurumsal firewall teklifi değerlendirirken yalnız model ve fiyatı karşılaştırmak bu ayrımı gizleyebilir. Satın alma ve IT ekipleri için yararlı başlangıç, hangi işlemin kim tarafından ve hangi koşullarda yapılacağını yazmaktır. Bu rehber, ağ güvenliği ve trafik izleme görüşmesinde kullanılabilecek bir sorumluluk matrisi sunar; belirli bir ürün veya koruma düzeyi varsaymaz.
1. Korunacak iş akışını ve erişim sınırlarını tanımlayın
Çalışan ağı, misafir erişimi, sunucular, şubeler ve uzaktan bağlanan kullanıcıları ayrı düşünün. Her grubun hangi uygulamaya erişmesi gerektiğini, hangi erişimin gereksiz olduğunu belirleyin. ‘Güvenli ağ istiyoruz’ yerine somut bir ihtiyaç yazın: misafirler internete çıkabilsin, şirket sunucularına erişemesin; yetkili çalışan belirlenen uygulamayı VPN üzerinden kullanabilsin.
NIST'in Guidelines on Firewalls and Firewall Policy yayını, güvenlik duvarı politikasını seçim, yapılandırma, test ve yönetim süreçleriyle birlikte ele alır. Bu yaklaşımı satın almaya uygulamak, cihaz adından önce erişim kurallarını ve sorumlulukları konuşmayı sağlar. Belgenin varlığı, hizmetin NIST tarafından onaylandığı veya şirketiniz için yeterli olduğuna dair bir sertifika değildir.
2. Cihaz, lisans ve yönetim hizmetini ayrı kalemlerde görün
Teklifte cihazın sahibi, lisansların süresi ve hangi özelliklerin dahil olduğu açık olmalıdır. Kurulum bedeli ile düzenli yönetim ücretini ayırın. Lisans yenilenmediğinde hangi işlevlerin etkileneceğini, donanım arızasında hangi işlemin kimin sorumluluğunda olduğunu ve hizmet sonunda cihazla yapılandırmanın nasıl devredileceğini sorun. Üreticinin bir özelliği desteklemesi, teklifin o özelliği içerdiğini göstermez.
Kapasiteyi, kullanılması planlanan işlevlerle birlikte değerlendirin. VPN, inceleme ve kayıt gereksinimleri olan bir senaryoyu yalnız temel trafik kapasitesiyle karşılaştırmayın. Şube ve kullanıcı sayısı, yoğun saatlerdeki trafik ve büyüme beklentisi tasarım görüşmesinin girdileridir. Satıcıdan, önerisinin hangi varsayımlara dayandığını ve kabul sırasında nasıl doğrulanacağını açıklamasını isteyin.
3. İzleme, bildirim ve müdahaleyi birbirinden ayırın
Bir trafik grafiğinin sunulması, grafiği bir kişinin sürekli incelemesi anlamına gelmez. Uyarı üretilmesi de otomatik olarak müdahale taahhüdü oluşturmaz. Nelerin izlendiğini, normal dışı durumun nasıl belirlendiğini ve kime bildirildiğini sorun. Bildirimin hangi saatlerde değerlendirildiği ve şirketinizde kimin karar vereceği de işletim planında yer almalıdır.
Örnek olarak, beklenmeyen bir trafik artışında yalnız bilgilendirme mi yapılacak, uygulama sahibiyle görüşülecek mi, yoksa onaylı bir kural uygulanacak mı? Bu adımların iş etkisi farklıdır. Trafik izleme için erişilecek veri ve kayıtları, saklama yaklaşımını ve erişim yetkilerini şirketinizin teknik ve hukuki sorumlularıyla belirleyin; yalnız ürün adı üzerinden mevzuata uygunluk sonucu çıkarmayın.
| İşlem | Uygulayan | Onay veya bildirim | Teklifte netleştirilecek konu |
|---|---|---|---|
| Yeni erişim kuralı | Belirlenecek teknik sorumlu | Şirketin yetkili onayı | Talep, test ve kayıt süreci |
| Yazılım veya lisans güncellemesi | Müşteri ya da hizmet sağlayıcı | Bakım planı onayı | Zamanlama, etki ve geri dönüş |
| Olağandışı trafik bildirimi | İzleme hizmeti sorumlusu | Belirlenmiş irtibat | İzlenen veri, saatler ve öncelik |
| Acil kural değişikliği | Yetkilendirilmiş ekip | Önceden belirlenmiş yetki sınırı | Hangi durumda kimin karar verdiği |
| Yapılandırma yedeği | Tanımlanmış işletim sorumlusu | Şirketin saklama politikası | Erişim, geri yükleme ve devir |
4. Teslimde çalışan erişimi ve engellenen erişimi sınayın
Kabul testinde yalnız internetin açıldığını görmek yeterli değildir. İzin verilen uygulama çalışmalı; ayrılması gereken ağlar arasında istenmeyen erişim bulunmamalıdır. Kapsama alınmışsa VPN, bildirim ve yapılandırma geri yükleme adımları da kontrollü biçimde denenmelidir. Testleri yetkili kişilerle, kararlaştırılmış sınırlar içinde ve iş süreçlerine etkisi değerlendirilerek planlayın.
Her test için beklenen sonucu ve görülen sonucu kaydedin. Başarısız testi çözmeden tüm sistemi kabul etmek yerine, açık bulgunun etkisini ve sorumlusunu belirtin. Sonraki bir kural değişikliğinde hangi testlerin tekrarlanacağını da kararlaştırın. Böylece güvenlik hizmeti, kurulup unutulan bir cihaz yerine yönetimi tanımlanmış bir süreç haline gelir.
5. İhtiyaç tablonuzla hizmet kapsamını görüşün
MyFi Business'ın kurumsal teknoloji çözümleri sayfasında routing, firewall, uygun DDoS hizmeti ve trafik izleme proje kapsamıyla birlikte değerlendiriliyor. Görüşmeye mevcut ağın sade bir haritası, kritik uygulamalar, dış erişim ihtiyacı ve yukarıdaki sorumluluk tablosuyla başlayabilirsiniz. Yönetici parolalarını veya hassas müşteri verilerini ilk teklif talebine eklemeyin.
Sunulabilecek çözüm; lokasyon, altyapı, lisans ve kararlaştırılan yönetim kapsamına bağlıdır. Günün her saati izleme, belirli müdahale süresi, otomatik yasal uygunluk veya bütün saldırıların engellenmesi bu rehberin verdiği vaatler değildir. Bu tür beklentiler varsa açıkça belirtin ve karşılanabilen koşulların yazılı teklifte yer almasını isteyin.
Karşılaştırılabilir güvenlik teklifi; cihazı ve lisansı, kural yönetimini, izlemeyi, onay yetkisini ve kabul testlerini ayrı ayrı tanımlar. Kimin ne yapacağı bilinmeden yalnız fiyat veya ürün modeli üzerinden karar vermeyin.
Kaynaklar ve hizmet bağlantıları
- MyFi Business — Kurumsal teknoloji çözümleri ↗
- NIST SP 800-41 Rev. 1 — Guidelines on Firewalls and Firewall Policy ↗
Kaynak ve hizmet sayfaları 15 Ekim 2026 tarihinde kontrol edildi. Bu rehber Türkçe hazırlanmıştır; dil menüsü diğer dillerin rehber dizinine götürür.