FortiGate Firewall Web Filtre: Kategori ve Güvenli Arama

FortiGate Firewall web filtre, kullanıcıların açtığı web sitelerini adrese ya da kategoriye göre izleyip engelleyen güvenlik profilidir. Kategoriye göre filtre her siteyi Fortinet’in FortiGuard servisine sorar ve cevaba göre karar verir.

Fortinet’in güvenlik profilleri sayfasına göre web filtresi ve DNS filtresi kullanıcının dışarı çıkan trafiğine uygulanır ve bütün kurallarda tek bir denetim kipi kullanılır. Arama motorlarının güvenli araması da en sağlam biçimde DNS’ten zorlanır.

Bu yazı FortiGate Firewall ileri seviye rehberimizin 2. adımıdır. Tek bir siteyi elle engellemeyi FortiGate kullanım rehberimizde ölçtük; burada misafir ağına kategori filtresi, DNS filtresi ve güvenli arama koyuyorum. Lab cihazımın FortiGuard aboneliği yok ve sunuculara da ulaşamıyor: aboneliği bitmiş ya da internet bağlantısı FortiGuard’a çıkamayan bir cihaz gibi.

Lab’da üç şey beklenenden farklı çıktı. DNS filtresi, Google, YouTube ve Microsoft’un kendi belgelerinde saydığı dokuz addan ikisini güvenli arama adlarına yönlendirmedi. Web filtresi bağlanınca misafirin internette taradığı her adreste dört port açık göründü; o portlara sunucu değil FortiGate cevap veriyordu. DNS filtresinde puanlama hatası seçeneği kapalıyken de misafir ağında hiçbir ad çözülmedi.

Örnekteki sınır kapısında görevli her yükü, merkezden her gün gelen bir kategori kataloğuna bakarak sınıflandırır. Katalog bir gün gelmezse görevli hiçbir yükü sınıflandıramaz ve bariyeri indirir; ancak “katalog gelmezse hepsini geçir” talimatı varsa kaldırır. FortiGate’te katalog FortiGuard’ın kategori servisi, talimat da profildeki puanlama hatası (rating error) seçeneğidir.

Bu yazı, Kurumsal Network Kurulumu hizmetimizde misafir ve çalışan ağlarına web filtresi kurarken izlediğimiz sırayı anlatır.

FortiGate Web Filtresi Nasıl Olmalı?

Misafir ağında kategori filtresiyle DNS filtresi birlikte çalışır, ikisi de FortiGuard’a ulaşılamadığında trafiği geçirecek biçimde ayarlanır ve güvenli arama DNS filtresinden zorlanır. Çalışan ağında puanlama hatası seçeneği kapalı kalır ve FortiGuard bağlantısı izlenir. Bütün kurallar tek bir denetim kipinde çalışır.

Bu düzeni dört kaynak birlikte tarif ediyor:

1. Fortinet FortiOS 7.0 Best Practices, Security profiles: web filtresi gelen trafiğe değil, kullanıcının dışarı çıkan trafiğine uygulanır ve kullanıcının web trafiğini kategoriye ve alan adına göre izler ve engeller. DNS filtresi alan adlarının puanına göre sorguları süzer. Akış (flow) kipi verimin öncelikli olduğu kurallarda, proxy kipi titizliğin öncelikli olduğu kurallarda kullanılır. Kaynakları verimli kullanmak için bütün kurallarda tek kip önerilir. İki kipin kullanıcıya nasıl göründüğünü FortiGate antivirüs yazımızda ölçtük. Aynı sayfa, güvenlik profili bağlanan kuralın 8008, 8010, 8015 ve 8020 portlarını açabileceğini ve bunların close-ports ile kapatılabileceğini yazıyor.
2. Google, SafeSearch’ü yönetilen ağlarda kilitleme belgesi: www.google.com için DNS kaydı, kullanıcıların kullanabileceği diğer ülke ve bölge alan adları da dahil, forcesafesearch.google.com adına CNAME olarak yazılır.
3. Google Workspace, YouTube içeriğini kısıtlama belgesi: www.youtube.com, m.youtube.com, youtubei.googleapis.com, youtube.googleapis.com ve www.youtube-nocookie.com adları restrict.youtube.com’a CNAME ile yönlendirilir ya da isteğe YouTube-Restrict: Strict başlığı eklenir.
4. Microsoft, Bing SafeSearch belgesi: ağdaki herkes için www.bing.com adı strict.bing.com adına yönlendirilir, adres yerine CNAME kullanılır. Edge kenar çubuğu için edgeservices.bing.com da aynı ada yönlendirilir.

İki ağ tipinde kararlar:

Hangi Kategoriler Engellenir?

Fortinet bir liste dayatmıyor, ama fabrika default web filtre profili bir başlangıç noktası veriyor. Profilin kategori numaralarını adlarıyla eşleyince şu çıktı:

1. Engelli, 26 kategori: Yetişkin/Olgun İçerik grubunun hepsi (kumar, yetişkin içerik, flört, silah satışı gibi), Güvenlik Riski grubunun hepsi (zararlı siteler, oltalama, spam, dinamik DNS, yeni kaydedilmiş alan adları), Potansiyel Sorumluluk grubundan çocuk istismarı, terör, kripto madenciliği ve istenmeyen program. Bir de puanlanmamış siteler (Unrated).
2. İzlenen, 8 kategori: Potansiyel Sorumluluk grubunun geri kalanı (uyuşturucu, hacking, ayrımcılık, şiddet, proxy ile kaçış gibi). Engellenmez, logda görünür.
3. Geri kalanı serbest.

DNS filtresinde yeni açılan profil ise yalnız dört kategoriyi engelliyor: zararlı siteler, oltalama, spam ve dinamik DNS. Lab’da web filtresinin engellediği öteki kategorileri DNS profiline de ayrıca işledim; işlenmezse yetişkin içerik DNS’ten serbest kalır.

Ne Zaman Değişir?

Profil değişikliği hemen etki etmiyor. Lab’da kuralın profilini değiştirdikten sonra misafir makinesinden iki saniyede bir istek gönderdim (saatler ntp01’in, UTC):

22:57:19 403
22:57:21 403
22:57:23 200
22:57:25 200

Yaklaşık 4 saniye boyunca eski profil çalıştı. Bir değişikliği denerken ilk sonuca değil, birkaç saniye sonraki sonuca bakılır.

FortiGate Web Filtre Öncesi: Abonelik Durumu

Kategori filtresinin ne yapacağını abonelik durumu belirliyor, o yüzden önce ona baktım (get webfilter status):

Locale       : english
Service      : Web-filter
Status       : Disable

Security Profiles → Web Filter ekranında fabrika ayarında dört hazır profil var: default, monitor-all, wifi-default ve sniffer-profile. default profili akış kipinde ve komut satırındaki tam yapılandırmasında ftgd-wf altında options boş; yani “puanlama hatasında izin ver” seçili değil.

Lab’da misafir ağının (10.34.60.0/24) kendi internet çıkış kuralı var: kural 11, yalnız DNS, HTTP ve HTTPS. Testleri bu kuralda yaptım. Servis sağlayıcı tarafında da gelen her isteği ve başlıklarını kaydeden küçük bir web sunucusu (203.0.113.70) ve misafirin kullandığı bir DNS sunucusu (203.0.113.54) çalıştırdım; arama motoru adları bu sunucuya çözülüyor. Böylece FortiGate’in bir isteği değiştirip değiştirmediği sunucunun kaydından okunabiliyor.

FortiGate Kategori Filtresi: FortiGuard Yoksa Bütün Web Kapanıyor

Profil kurala Policy & Objects → Firewall Policy → kural formundaki Security Profiles bölümünden bağlanır. Lab’da misafir kuralının (11) son hâlinde dört alan iş görüyor:

1. Inspection Mode: Flow-based.
2. Web Filter: açık, misafir-web.
3. DNS Filter: açık, misafir-dns. Güvenli aramayı DNS sorgusunda uyguluyor, aşağıda “DNS Filtresinde Güvenli Arama” bölümünde ölçtüm.
4. SSL Inspection: certificate-inspection. HTTPS’te şifre açılmıyor, alan adı görülüyor.

Son hâlin komut satırındaki karşılığı:

config firewall policy
    edit 11
        set name "Misafir internet cikisi"
        set utm-status enable
        set ssl-ssh-profile "certificate-inspection"
        set webfilter-profile "misafir-web"
        set dnsfilter-profile "misafir-dns"
    next
end

Akış kipi fabrika değeri olduğu için inspection-mode satırı çıktıda görünmüyor.

İlk denemede kurala fabrika default profilini bağladım (set utm-status enable, set ssl-ssh-profile "certificate-inspection", set webfilter-profile "default") ve misafir makinesinden üç adrese istek gönderdim:

403 http://test.example.com/
403 http://www.google.com/search?q=deneme
403 http://test.example.com/a

Üçü de engellendi. Sayfanın başlığı Web Page Blocked, metni de sebebi söylüyor: error occurred while trying to rate the website using the webfiltering service ve Fortiguard servers failed to respond, yani web filtreleme hizmetiyle site puanlanırken hata oluştu, FortiGuard sunucuları cevap vermedi. Kategori filtresi siteyi FortiGuard’a soramadı, kategorisini bilmediği her siteyi engelledi. Misafir ağında web tamamen kapandı.

Arayüz bunu önceden söylüyor. Profilde FortiGuard Category Based Filter açıkken hemen altında bir uyarı duruyor:

Web filtre logu (Log & Report → Web Filter) her engellemeyi aynı gerekçeyle yazdı:

date=2026-10-02 time=01:56:55 ... hostname="test.example.com" profile="default" action="blocked" ... url="http://test.example.com/a" ... msg="A rating error occurs" error="all Fortiguard servers failed to respond"

Allow Websites When a Rating Error Occurs: Kapı Açılır, Filtre Susar

Profilin en altındaki Rating Options bölümünde Allow websites when a rating error occurs seçeneği var. Fabrika profilini kopyalayıp seçeneği açtım:

config webfilter profile
    clone "default" to "misafir-web"
    edit "misafir-web"
        config ftgd-wf
            set options error-allow
        end
    next
end

Kurala yeni profili verince istekler geçti ve sunucunun kaydına düştü. Log yine puanlama hatası yazdı, ama eylem değişti:

time=01:57:42 ... profile="misafir-web" action="passthrough" ... url="http://test.example.com/gecis-12" ... msg="A rating error occurs"

Seçenek iki kötü sonuç arasında bir tercih:

1. Kapalı: FortiGuard’a ulaşılamadığı an bütün web engellenir. Denetim sıkı kalır, ama kullanıcılar çalışamaz.
2. Açık: aynı durumda bütün siteler geçer ve kategori filtresi o süre boyunca hiçbir şeyi engellemez. Kullanıcı fark etmez, ama filtre de yoktur.

Misafir ağında açık tutulur; misafirin işini durdurmaktansa o süre filtresiz kalmak tercih edilir. Sıkı denetim gereken bir ağda kapalı kalır ve FortiGuard bağlantısı izlenir; paneldeki lisans kutusu bu bağlantının durumunu gösterir.

Örnekteki görevli de “katalog gelmezse hepsini geçir” talimatını aldığında bariyeri kaldırır; ama o gün kapıdan geçen yükler sınıflandırılmamış olur.

FortiGate Güvenli Arama: İsteği Değiştirmek mi, Adresi mi?

Bir mektubun içindekini değiştirmek için zarfı açmanız gerekir. Mektubun gideceği yeri değiştirmek içinse zarfa dokunmazsınız; yalnız postacıya hangi kapıya bırakacağını söylersiniz.

Bu sahneyi sınır kapısının dört parçası taşıyor:

1. Arama isteği sürücünün taşıdığı mühürlü yüktür; HTTPS’te mühür şifrelemedir.
2. Web filtresinin güvenli araması yükü açıp etiketini değiştirmektir: adrese safe=active, isteğe YouTube-Restrict: Strict eklenir.
3. DNS filtresinin güvenli araması yol tabelasıdır: sürücü “www.google.com nerede?” diye sorduğunda tabela forcesafesearch.google.com yönünü gösterir.
4. Güvenli arama sunucusu arama motorunun güvenli şubesidir; oraya varan yük açılmadan güvenli kurallarla karşılanır.

Örnekteki sınır kapısında mühürlü bir yükün etiketini değiştirmek için mühür kırılır, ve mührü ancak yetkili bir memur kırabilir. Yolu değiştirmek içinse yalnız tabelaya dokunulur. FortiGate’te iki yol şöyle işliyor:

1. Web filtresi isteği yolda açar ve değiştirir. Bu yalnız proxy kipinde çalışır; HTTPS’te isteği açmak için derin denetim gerekir.
2. DNS filtresi istemcinin ad sorusunun cevabını değiştirir. İstemci şifreli bağlantıyı doğrudan güvenli sunucuya kurar; FortiGate bağlantının içine bakmaz, akış kipi yeter.

DNS yolunun kazancı, Fortinet’in “bütün kurallarda tek kip” önerisiyle uyuşmasıdır: güvenli arama için kuralı proxy kipine çevirmek gerekmez. Bedeli de aynı yerden geliyor: yönlendirme ad listesine bağlıdır ve listede olmayan bir ad yönlenmez. Lab’da ikisini de ölçtüm.

Web Filtresinde Güvenli Arama: Yalnız Proxy Kipinde

Akış kipindeki misafir-web profilinde güvenli aramayı komut satırından açmaya çalıştım; iki komut da tanınmadı:

gmfw01 (web) # set safe-search url header
command parse error before 'safe-search'
Command fail. Return code -61
gmfw01 (web) # set youtube-restrict strict
command parse error before 'youtube-restrict'
Command fail. Return code -61

Profilin Feature set alanını Proxy-based yapıp kural 11’in denetim kipini de proxy’ye çevirince (set inspection-mode proxy) ayarlar kabul edildi. Arayüzde de Search Engines bölümü yalnız proxy kipindeki profilde görünüyor; akış kipindeki profilde bölüm hiç yok. Satırların yanındaki kırmızı P rozeti de özelliğin proxy’ye bağlı olduğunu gösteriyor:

Misafir makinesinden arama motorlarına istek gönderdim ve sunucunun kaydına baktım:

GET /search?q=deneme&safe=active HTTP/1.1 | Host: www.google.com | YouTube-Restrict: None | Cookie: None
GET /search?q=deneme&safe=active HTTP/1.1 | Host: www.google.com.tr | YouTube-Restrict: None | Cookie: None
GET /search?q=deneme HTTP/1.1 | Host: www.bing.com | YouTube-Restrict: None | Cookie: None
GET /watch?v=abc HTTP/1.1 | Host: www.youtube.com | YouTube-Restrict: Strict | Cookie: None
GET /watch?v=abc HTTP/1.1 | Host: m.youtube.com | YouTube-Restrict: Strict | Cookie: None
GET /kontrol HTTP/1.1 | Host: test.example.com | YouTube-Restrict: None | Cookie: None

Satırlar sırayla şunu söylüyor:

1. Google: hem .com hem .com.tr adresinin sonuna &safe=active eklendi.
2. Bing: istek değişmedi; çerez de eklenmedi. Bu sürümde Bing için web filtresinin bir etkisini göremedim.
3. YouTube: masaüstü ve mobil adın ikisine de YouTube-Restrict: Strict başlığı kondu.
4. Kontrol isteği değişmedi.

Burada önemli bir sınır var. Gerçek arama motorlarının hepsi HTTPS kullanıyor ve FortiGate bir HTTPS isteğinin adresini ya da başlığını ancak bağlantıyı açarsa değiştirebilir; bunun için derin denetim gerekir. NGFW’nin şifreli trafiğin içini nasıl gördüğünü firewall nedir yazımızda anlattık. Değerlendirme lisanslı lab cihazımda derin denetim kullanıcıya 512 bitlik anahtarlı bir sertifika veriyor ve güncel istemciler bununla bağlanmıyor (FortiGate SSL inspection yazımızda ölçtük). Yukarıdaki ölçüm bu yüzden HTTP üzerinde.

Ölçümden sonra profili akış kipine geri almak istedim ve FortiGate reddetti (node_check_object fail! for feature-set flow). Proxy’ye özgü ayarlar profilde dururken kip değişmiyor. Profili fabrika default’tan yeniden kopyalayıp yalnız puanlama seçeneğini açtım; lab’daki son misafir-web akış kipinde.

DNS Filtresinde Güvenli Arama

Menü yolu: Security Profiles → DNS Filter → Create New. Enforce ‘Safe Search’ on Google, Bing, YouTube ve Restrict YouTube Access (Strict) açılır; profil (misafir-dns) kuralın DNS Filter alanına bağlanır.

CLI karşılığı:

config dnsfilter profile
    edit "misafir-dns"
        set safe-search enable
        set youtube-restrict strict
        config ftgd-dns
            set options error-allow
        end
    next
end

Misafir makinesinden belgelerin saydığı dokuz adı ve bir kontrol adını sordum. Profil bağlanmadan önce onu da test sunucusunun adresine çözülüyordu (203.0.113.70). Profil bağlandıktan sonra, kural akış kipindeyken:

www.google.com: forcesafesearch.google.com. 216.239.38.120  (status: NOERROR)
www.google.com.tr: forcesafesearch.google.com. 216.239.38.120  (status: NOERROR)
www.youtube.com: restrict.youtube.com. 216.239.38.120  (status: NOERROR)
m.youtube.com: restrict.youtube.com. 216.239.38.120  (status: NOERROR)
youtubei.googleapis.com: restrict.youtube.com. 216.239.38.120  (status: NOERROR)
youtube.googleapis.com: 203.0.113.70  (status: NOERROR)
www.youtube-nocookie.com: restrict.youtube.com. 216.239.38.120  (status: NOERROR)
www.bing.com: strict.bing.com. 150.171.27.16 150.171.28.16  (status: NOERROR)
edgeservices.bing.com: 203.0.113.70  (status: NOERROR)
test.example.com: 203.0.113.70  (status: NOERROR)

Dokuz addan yedisi güvenli arama adlarına yönlendi; Bing bu kez etkilendi. İki ad değişmedi: YouTube’un youtube.googleapis.com’u ve Microsoft’un Edge kenar çubuğu için saydığı edgeservices.bing.com. Kontrol adı da değişmedi.

FortiGate soruyu yine misafirin DNS sunucusuna iletiyor; o sunucunun kaydında www.google.com sorusu duruyordu. Cevabı ise dönüşte değiştiriyor: cevapta yetkili (aa) bayrağıyla bir CNAME ve güvenli arama sunucusunun adresi geliyor, adresi FortiGate kendisi çözüp ekliyor. DNS’in nasıl çözüldüğünü DNS nedir yazımızda anlattık.

Yönlenmeyen İki Ad: Teşhis

Belgelerin listesiyle cihazın davranışı arasındaki fark, ölçmeden görünmüyor. Sıra şöyle:

1. Kendi listenizi çıkarın: Google, YouTube ve Microsoft’un belgelerindeki adlar, Google için kullanıcıların açtığı ülke alan adlarıyla birlikte.
2. Her adı misafir ağından sorun ve cevabın güvenli ada (CNAME) gidip gitmediğine bakın.
3. Yönlenmeyen ad varsa sıkı bir ağda o ad için kurumun kontrol ettiği DNS’te CNAME kaydı yazılır; Google ve Microsoft’un tarif ettiği yol budur. Misafir ağı servis sağlayıcının DNS’ini kullanıyorsa bu kayıt oraya yazılamaz, misafir DNS’i önce kurumun DNS’ine ya da FortiGate’in kendi DNS servisine alınır.

Lab’da bu iki ad için ayrı bir kayıt yazmadım; misafir ağında kalan açık bu iki ad.

FortiGate Web Filtresi Bağlanınca Açılan Portlar

Fortinet’in sayfasındaki uyarıyı ölçtüm. Profil bağlanmadan önce misafir ağından FortiGate’in misafir arayüzünü ve internetteki test sunucusunu taradım; test sunucusu yalnız 80’de dinliyor. Profil bağlandıktan sonra, kural proxy kipindeyken test sunucusunun taraması değişti:

8008/tcp open  http
8010/tcp open  xmpp
8015/tcp open  cfg-cloud
8020/tcp open  intu-ec-svcdisc

Sunucu bu portların hiçbirinde dinlemiyordu. 8008’e istek gönderince cevabı FortiGate verdi ve 8010’a yönlendirdi:

HTTP/1.1 302 Found
Location: https://203.0.113.70:8010/

FortiGate bu portları uyarı sayfaları, kimlik doğrulama ve kategori aşma (override) için kullanıyor. Akış kipinde de 8008, 8015 ve 8020 açık göründü, 8010 kapalı. Trafik kuraldan sızmıyor; ama misafir ağından internete yapılan her tarama, gerçekte orada olmayan dört port görüyor ve PCI gibi bir port taraması testi bu yüzden başarısız olabilir.

Fortinet’in çözümü tek satır:

config webfilter fortiguard
    set close-ports enable
end

Ayarı açınca dört port da filtered oldu ve misafirin web erişimi sürdü (200). Bedeli Fortinet’in sayfasında yazıyor: web filtresinin Warning ve Authenticate eylemleri ve kullanıcıya kategori aşma izni çalışmaz, engelleme sayfası Fortinet logosunu göstermez; URL ve kategori engellemesi etkilenmez. Lab’da bu eylemler kullanılmadığı için ayar açık kaldı.

FortiGate DNS Filtresinde Puanlama Hatası: Bütün Adlar Çözülemez

DNS filtresinin FortiGuard Category Based Filter bölümü de açık geliyor ve web filtresindeki seçeneğin DNS karşılığı formun en altında: Allow DNS requests when a rating error occurs.

Seçeneği kapatıp aynı soruları tekrarladım:

www.google.com: bos (status: SERVFAIL)
www.bing.com: bos (status: SERVFAIL)
test.example.com: bos (status: SERVFAIL)
000 Could not resolve host: test.example.com

Bütün sorgular SERVFAIL aldı ve web isteği ad çözülemediği için hiç gitmedi. Web filtresindeki puanlama hatası web sayfalarını kapatmıştı; DNS filtresindeki aynı hata ad çözümlemesini kapattı, yani misafirler için yalnız web değil, ad kullanan her uygulama durdu.

Güvenli arama yönlendirmesi de çalışmadı, çünkü sorgu o aşamaya gelmeden düştü. DNS filtresi FortiGuard aboneliği olmayan bir cihaza konuyorsa bu seçenek açılır; seçeneği geri açınca sorgular geçti.

Doğrulama: FortiGate Web Filtresi Doğru Kuruldu mu?

1. Kural misafirin internet çıkışında, akış kipinde; web ve DNS filtresi bağlı.
2. Kategori listeleri iki profilde de aynı engelleri taşıyor; DNS profiline yetişkin içerik ayrıca işlenmiş.
3. Puanlama hatası misafir ağında iki profilde de geçiriyor; çalışan ağında web filtresi engelliyor ve FortiGuard bağlantısı izleniyor.
4. Güvenli arama DNS filtresinden; misafir ağından belgelerdeki her ad sorulup cevabın güvenli ada gittiği görülmüş.
5. Portlar: misafir ağından internetteki bir adres tarandığında 8008, 8010, 8015 ve 8020 açık görünmüyor (close-ports enable).
6. Log: Log & Report → Web Filter satırlarında doğru profil adı ve eylem görünüyor.

Sonuç: FortiGate Web Filtresinde Asıl Karar FortiGuard’sız Ne Olacağı

FortiGate’te kategori filtresi ve güvenli arama birkaç anahtarla açılıyor; asıl kararlar, FortiGuard’a ulaşılamadığında ne olacağı ve güvenli aramanın hangi yoldan zorlanacağıdır. Lab’da beş şey beklenenden farklı çıktı:

1. Fabrika profili FortiGuard’sız misafirin bütün web’ini kapattı; DNS filtresinde aynı durum bütün ad çözümlemesini durdurdu (SERVFAIL).
2. DNS filtresi belgelerin saydığı dokuz addan ikisini yönlendirmedi: youtube.googleapis.com ve edgeservices.bing.com.
3. Web filtresi bağlanınca misafirin internette taradığı adreslerde dört port açık göründü; cevabı FortiGate veriyordu, close-ports kapattı.
4. Web filtresindeki güvenli arama Bing’i etkilemedi ve proxy kipi istedi; ayarları kaldırmadan profil akış kipine dönmedi.
5. Yeni DNS profili yalnız güvenlik riski kategorilerini engelliyordu; web filtresinin engellediği yetişkin içerik DNS’ten serbestti.

Örnekteki görevli, katalog gelmediğinde bariyeri indirmeyi mi kaldırmayı mı seçeceğini önceden bilir; yol tabelasının hangi adları güvenli şubeye çevirdiğini de bir kez kendisi yürüyerek dener. FortiGate’te ilki profildeki puanlama hatası seçeneği, ikincisi DNS filtresinin ad listesidir. Misafir ağının işletmeye nasıl sunulduğunu misafir Wi-Fi hizmetimizde anlattık. Sıradaki adım rehberin 3. adımı, uygulama kontrolü.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn