FortiGate CLI ile Çok Sayıda Adres Objesi ve Grup Oluşturmak

Onlarca subnet’i güvenlik duvarına eklemek ilk bakışta mekanik bir iştir. Tam da bu nedenle hata riski küçümsenir: bir octet yanlış yazılır, mevcut obje sessizce değiştirilir, grup üyeliği eksik kalır veya benzer isim başka VDOM’da farklı anlam taşır. CLI hızı artırır; fakat hızın kontrolsüzlüğe dönüşmemesi için girdinin kaynağı, isim standardı ve doğrulama çıktısı tasarımın parçası olmalıdır.

20 Temmuz 2026 tarihinde çok sayıda şube ağını ortak politika grubuna alma ihtiyacında, doğrudan üretim cihazına komut yapıştırmadık. IP planını temizledik, mevcut objelerle çakışmaları karşılaştırdık ve laboratuvar yapılandırmasında tekrar çalıştırılabilir bir komut seti hazırladık. Değişiklik öncesi yedek, kapsamlı diff, grup üyeliği kontrolü ve politika etkisi testiyle CLI işlemini denetlenebilir bir mini otomasyona dönüştürdük.

Sorunun ortaya çıkışı

Yeni şube ve kullanıcı subnetleri ortak erişim politikasına eklenmeliydi. GUI üzerinden tek tek obje oluşturmak zaman alıyor ve farklı yöneticilerin farklı ad/açıklama kullanmasına yol açıyordu. Kaynak liste elektronik tabloda tutulmuştu; bazı satırlarda host adresi, bazılarında CIDR ve bazılarında eski açıklama bulunuyordu. Listeyi doğrudan komuta dönüştürmek güvenilir değildi.

İş sadece adres objesi oluşturmakla bitmiyordu. Objelerin doğru VDOM’da, doğru tipte ve var olan grup içinde olması; grubun bağlı olduğu politikaların beklenmedik erişim açmaması gerekiyordu. Ayrıca aynı isimli mevcut bir objenin farklı subnet göstermesi halinde otomasyonun onu sessizce üzerine yazmaması şarttı. Başarı ölçütünü “CLI hata vermedi” yerine yapılandırma ve trafik sonucu olarak tanımladık.

İlk belirtiler ve yanlış varsayımlar

İlk yanlış varsayım, `edit` komutunun her zaman yeni nesne oluşturacağıydı. Aynı ad varsa mevcut nesne düzenlenir; set komutları çalışan politikayı değiştirebilir. İkinci varsayım, grup için `set member` kullanmanın ekleme yapacağıydı. Bu kullanım mevcut üyeleri değiştirebilir; korunması gereken üyeler gözden kaçarsa geniş bir servis kesintisi oluşur. Komut semantiği sürüm dokümantasyonuyla doğrulanmalıdır.

Başka bir yanılgı, isim standardının kozmetik olduğuydu. Objede lokasyon, ağ rolü ve ortam anlaşılmıyorsa sonraki politika incelemesi zorlaşır; ancak isme bütün teknik ayrıntıyı doldurmak da değişiklikte yeniden adlandırma yükü yaratır. Açıklama ve yorum alanı sahiplik ile talep referansı için kullanılmalı, sır veya gerçek kişi bilgisi içermemelidir.

Teknik analiz

Kaynak liste şema kontrolünden geçirildi: benzersiz obje adı, geçerli ve ağ sınırına oturan CIDR, lokasyon kodu, iş sahibi ve hedef grup. Çakışan subnetler yalnızca metin eşitliğiyle değil ağ kapsaması açısından incelendi. FortiGate yapılandırmasındaki mevcut adresler ve gruplar salt okunur çıktıyla dışa alındı; ad ve değer farkları değişiklik öncesi raporlandı.

Komut üretimi deterministik sırada yapıldı. Her adres için edit, subnet, comment ve next blokları; grup için mevcut üyeleri koruyan açık üyelik listesi hazırlandı. CLI toplu çalıştırma öncesi desteklenen maksimum ad ve grup sınırları kontrol edildi. Değişiklik sonrası show çıktısı beklenen veriyle makine ve insan gözüyle karşılaştırıldı; politika hit ve lookup testi yapıldı.

# Dokümantasyon subnetleriyle güvenli şablon; üretim değerleri değildir
config firewall address
    edit "BRANCH-DEMO-USERS"
        set subnet 192.0.2.0 255.255.255.0
        set comment "Onaylı değişiklik kaydına bağlı örnek"
    next
end
# Grup üyeliğini değiştirmeden önce mevcut yapılandırmayı mutlaka okuyun.

Uygulanan çözüm veya önerilen mimari

Standart, büyük harfle kısa lokasyon kodu, ağ rolü ve ortam bileşenlerinden oluşturuldu; subnet değeri isim yerine obje alanında kaldı. Her obje açıklamasına kişisel veri içermeyen sahiplik ve değişiklik referansı eklendi. Üretim öncesi tam yapılandırma yedeği alındı, komut seti ikincil yönetici tarafından gözden geçirildi ve bakım penceresinde doğru VDOM bağlamında çalıştırıldı.

Grup üyelikleri değişiklik öncesi ve sonrası sıralı liste olarak karşılaştırıldı. Yeni subnetlerin beklenen politikaya eşleştiği policy lookup ile, izin verilmeyen hedeflere erişemediği negatif testle doğrulandı. Kaynak veri ile üretilen komut ve doğrulama raporu aynı değişiklik kaydında saklandı. Böylece sonraki toplu ekleme, eski dosyayı kopyalamak yerine güncel envanterden yeniden üretilebildi.

Alternatifler ve karar gerekçesi

GUI az sayıda obje için görsel doğrulama sağlar ve hata mesajlarını okumayı kolaylaştırır. Bu kapsamda tekrar sayısı fazla olduğu için tutarsızlık riski yükseliyordu. FortiManager veya API tabanlı otomasyon daha güçlü onay, şablon ve idempotency sağlayabilir; mevcut ölçek ve araç yetkinliğinde gözden geçirilmiş CLI seti en küçük güvenli adımdı.

Subnetleri tek bir büyük özet ağ objesiyle temsil etmek grup üyeliğini azaltabilirdi, fakat arada kuruma ait olmayan veya farklı güven bölgesinde kalan adresleri istemeden kapsayabilirdi. Açık subnet objeleri daha uzun ama denetlenebilirdi. Dinamik connector seçenekleri bulut kaynaklarında değerlidir; statik şube IP planı için kaynak envanter ve kontrollü obje grubu tercih edildi.

Güvenlik ve operasyonel riskler

Yanlış subnet maskesi beklenenden geniş kaynak grubuna erişim verebilir. Özellikle ağ adresine oturmayan girdiler normalize edilip sessizce farklı kapsam yaratabilir. Toplu komutlar yüksek ayrıcalıkla çalıştığı için kişisel yönetici hesabı, MFA korumalı yönetim ağı ve oturum kaydı kullanılmalıdır. Komut dosyasında parola, token veya gerçek dış erişim detayları bulunmamalıdır.

Geri dönüş yalnızca yeni objeleri silmek değildir; objeler politikada kullanılıyorsa silme başarısız olabilir veya ilişkiyi bozabilir. Önce eski grup üyeliği geri yüklenmeli, politika etkisi doğrulanmalı, sonra kullanılmayan objeler kontrollü kaldırılmalıdır. Ad standardı ve kaynak IP planı sahiplenilmezse birkaç ay içinde otomasyon yeniden dağınık veriye dönüşür; periyodik kullanılmayan obje gözden geçirmesi gerekir.

Çıkarılan Dersler

Kontrol Listesi