VPN'den VLAN'a erişim: önce matris, sonra kurallar
Bir yanda roller, diğer yanda hizmetler. Beş kontrol, belirsiz bir VPN'den VLAN'a erişim tasarımını güvenlik duvarı sahibinin uygulayabileceği bir tabloya dönüştürür.
Güvenlik duvarı sözdizimiyle değil, matrisle başlayın. Bir yanda rollerin, diğer yanda hizmetlerin olduğu bir tabloyu bir uygulama sahibi inceleyebilir, bir güvenlik sahibi tartışabilir ve ağ geçidini elinde tutan kişi uygulayabilir. Bu inceleme, kimsenin üzerinde anlaşmadığı kurallarda hata ayıklamaktan daha ucuzdur.
Yazmaya harcanan bir saat, sonradan bir haftalık kural arkeolojisinden tasarruf ettirir. Tasarım kimin hangi hizmete ulaştığını anlatır ve yeniden numaralandırmadan sonra kalan kısım da budur.
Adım 1: rolleri ağlardan önce adlandırın
Anahtardan değil, insanlardan başlayın. Uzaktan bağlanan her grubu ve o grubun ne yaptığını anlatan tek cümleyi yazın; örneğin stok seviyelerini okuyan depo personeli ya da tek bir entegrasyonu sürdüren bir yüklenici. İki grup aynı erişimi alacaksa, bu amaç için tek roldürler.
Bir rol yalnızca organizasyon şeması yüzünden varsa burada durun. Kendine özgü hizmet ihtiyacı olmayan rol, aynı hücrelerden bir satıra dönüşür ve aynı satırlar birini sonradan kolaylık olsun diye bütün bir alt ağ vermeye teşvik eder. İnsanların ne yaptığına göre bölün, giderlerini kimin imzaladığına göre değil. Küçük bir ofis için altı rol genellikle çoktur ve üç çoğu zaman doğrudur.
Adım 2: her hücreyi bir hizmet beyanına dönüştürün
«Uygulamalar» yazan bir hücre test edilemez. «Personel havuzundan 443'teki ERP sunucusuna HTTPS» yazan hücre test edilebilir. Her ağ adını bir hedef, bir protokol ve bir bağlantı noktasıyla değiştirin, ardından hizmetin onsuz çalışamayacağı bağımlılığı ekleyin; örneğin iç çözümleyici ya da kimlik sağlayıcı.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Yön sütunu en pahalı hataları yakalar. Personele bir uygulamayı açma izni, uygulama sunucularına personelin dizüstü bilgisayarlarına geri bağlantı açma izni anlamına gelmez ve ilk yöne izin veren durum bilgili bir kural çoğu zaman ikinciye de izin veriyormuş gibi okunur.
Adım 3: kimliğin nerede politikaya dönüştüğüne karar verin
Birinin kimliği doğrulanmış oturumu ağ geçidinin uygulayabileceği bir role dönüştürmesi gerekir. Desteklenen seçenekler arasında kimlik doğrulama arka ucunun sağladığı grup ilkesi, güvenilir oturum öznitelikleri veya her rol için ayrı adres havuzları bulunur. Üçü de çalışır; istemcinin gönderdiği etiket çalışmaz. Ağ geçidinizin belgelediği mekanizmayı seçin, bir forum gönderisinin anlattığını değil.
Yalnızca bir VLAN'a ait görünen bir adres atamak, başka bir kılıktaki aynı yanıtsızlıktır. OpenVPN güvenlik duvarı kurallarına ilişkin Netgate kılavuzu bu ayrımı açık kılar: tünelin yukarı çıkmasına izin vermek, trafiğin içinden geçmesine izin vermekten farklı bir karardır.
Hangi mekanizmayı seçtiğinizi ve nerede yapılandırıldığını yazın. Bir rol değiştiğinde, o not tek bir düzenleme ile üç arayüzde arama arasındaki farktır. Ayrıca denetçiye önce nereye bakması gerektiğini söyler.
Adım 4: hedefin gördüğü kaynak adresini izleyin
Yönlendirme ilkesi sınırda gerçek kaynakla eşleşmelidir. Ağ geçidi VPN istemcilerini kendi adresine çeviriyorsa, aşağıdaki her güvenlik duvarı tek bir kaynak görür ve rol bazında karar verme yeteneğini kaybeder. İstemci adresini koruyorsa, o havuz için dönüş yolu bulunmalıdır.
Son kuralları yazmadan önce iki yönü de test edin, sonra gözlenen kaynağı her hücrenin yanına not edin. Aynı kontrolü iki farklı rolden çalıştırın ve sonucu karşılaştırın. İkisi de ağ geçidinin adresini gösteriyorsa rol ayrımı çoktan kaybolmuştur. Ağ geçidi kaynak çevirisi yaparken adreslerin korunduğunu varsayan bir matris, ilk alt ACL'de başarısız olur.
Adım 5: yayına almadan önce her hücreyi test edin
İzin verilen her hücreyi tek bir temsili işleme, reddedilen her hücreyi ise olumsuz bir duruma dönüştürün. İkisini de gerçek roldeki bir istemciden çalıştırın, ağ geçidi konsolundan değil, çünkü konsol test ettiğiniz yolu atlar.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'Bağlanan bir olumsuz durum bir bulgudur, tesadüf değildir ve kural düzeltilene kadar matriste başarısız hücre olarak yer alır. Test komutlarını tablonun yanında tutun ki bir sonraki gözden geçiren, akıl yürütmeyi yeniden kurmak yerine onları yeniden çalıştırsın.
Bitmiş tablo, kendisi için yazıldığı ağ geçidinden daha uzun yaşar. Kurallar ürün yazılımı ve üreticiyle birlikte değişir; oysa bir yüklenicinin tek bir proje hizmetine ulaştığını söyleyen satır, o iş değişene kadar doğru kalır.