Bu makale, “Ağ Altyapınızın Kontrolünü Nasıl Ele Alırsınız?” başlıklı makale serisinin üçüncüsüdür. Serideki tüm yazıların içeriğine ve bağlantılara ulaşabilirsiniz .
Güvenlik risklerinin tamamen ortadan kaldırılmasından bahsetmenin bir anlamı yok. Prensip olarak bunları sıfıra indiremeyiz. Ağı daha güvenli hale getirmeye çalışırken çözümlerimizin de giderek daha pahalı hale geldiğini de anlamamız gerekiyor. Ağınız için anlamlı olan maliyet, karmaşıklık ve güvenlik arasında bir denge bulmanız gerekir.
Elbette, güvenlik tasarımı genel mimariye organik olarak entegre edilmiştir ve kullanılan güvenlik çözümleri ağ altyapısının ölçeklenebilirliğini, güvenilirliğini, yönetilebilirliğini etkiler ve bunların da dikkate alınması gerekir.
Ancak şunu da hatırlatmak isterim ki şu anda bir ağ oluşturmaktan bahsetmiyoruz. Bize göre zaten tasarımı seçtik, ekipmanı seçtik, altyapıyı oluşturduk ve bu aşamada mümkünse önceden seçtiğimiz yaklaşımı “yaşamalı” ve çözümler bulmalıyız.
Artık bizim görevimiz ağ düzeyinde güvenlikle ilgili riskleri tespit edip makul seviyeye indirmek.
Ağ güvenliği denetimi
Kuruluşunuz ISO 27k süreçlerini uyguladıysa güvenlik denetimleri ve ağ değişiklikleri bu yaklaşım kapsamındaki genel süreçlere sorunsuz bir şekilde uymalıdır. Ancak bu standartlar hala belirli çözümlerle ilgili değil, konfigürasyonla ilgili değil, tasarımla ilgili değil... Net bir tavsiye yok, ağınızın nasıl olması gerektiğini ayrıntılı olarak dikte eden standartlar yok, bu, bu görevin karmaşıklığı ve güzelliği.
Birkaç olası ağ güvenliği denetimini vurgulayacağım:
- ekipman konfigürasyon denetimi (sertleştirme)
- güvenlik tasarımı denetimi
- erişim denetimi
- süreç denetimi
Ekipman konfigürasyon denetimi (sertleştirme)
Çoğu durumda ağınızın güvenliğini denetlemek ve geliştirmek için en iyi başlangıç noktasının bu olduğu görülmektedir. IMHO, bu Pareto yasasının iyi bir göstergesidir (%20 çaba, sonucun %80'ini üretir ve geri kalan %80 çaba, sonucun yalnızca %20'sini üretir).
Sonuç olarak, ekipmanı yapılandırırken genellikle satıcılardan güvenlik için "en iyi uygulamalara" ilişkin öneriler alıyoruz. Buna “sertleşme” denir.
Ayrıca, ekipmanınızın konfigürasyonunun bu "en iyi uygulamalara" ne kadar iyi uyduğunu belirlemenize ve sonuca göre ağınızda değişiklikler yapmanıza yardımcı olacak bu tavsiyelere dayalı bir anketi sıklıkla bulabilir (veya kendiniz bir anket oluşturabilirsiniz) . Bu, neredeyse hiçbir ücret ödemeden, oldukça kolay bir şekilde güvenlik risklerini önemli ölçüde azaltmanıza olanak tanır.
Bazı Cisco işletim sistemleri için çeşitli örnekler.
Bu belgelere dayanarak her ekipman türü için konfigürasyon gereksinimlerinin bir listesi oluşturulabilir. Örneğin, bir Cisco N7K VDC için bu gereksinimler şöyle görünebilir: .
Bu sayede ağ altyapınızda bulunan farklı tipteki aktif ekipmanlar için konfigürasyon dosyaları oluşturulabilir. Daha sonra manuel olarak veya otomasyonu kullanarak bu yapılandırma dosyalarını "yükleyebilirsiniz". Bu sürecin nasıl otomatikleştirileceği, orkestrasyon ve otomasyonla ilgili başka bir makale dizisinde ayrıntılı olarak tartışılacaktır.
Güvenlik tasarımı denetimi
Tipik olarak bir kurumsal ağ, şu veya bu biçimde aşağıdaki bölümleri içerir:
- DC (Kamu hizmetleri DMZ ve Intranet veri merkezi)
- internet erişimi
- Uzaktan erişim VPN
- WAN kenarı
- şube
- Kampüs (Ofis)
- çekirdek
Alınan başlıklar model, ancak elbette bu isimlere ve bu modele tam olarak bağlanmak gerekli değildir. Yine de formalitelere takılıp kalmadan işin özünden bahsetmek istiyorum.
Bu segmentlerin her biri için güvenlik gereksinimleri, riskler ve buna bağlı olarak çözümler farklı olacaktır.
Güvenlik tasarımı açısından karşılaşabileceğiniz sorunlar için her birine ayrı ayrı bakalım. Elbette, bu makalenin hiçbir şekilde tamamlanmış gibi görünmediğini, gerçekten derin ve çok yönlü bu konuda bunu başarmanın kolay (imkansız olmasa da) olmadığını, ancak kişisel deneyimimi yansıttığını bir kez daha tekrar ediyorum.
Mükemmel bir çözüm yok (en azından henüz değil). Her zaman bir uzlaşmadır. Ancak bir yaklaşımı veya diğerini kullanma kararının, hem artıları hem de eksileri anlaşılarak bilinçli olarak verilmesi önemlidir.
Veri Merkezi
Güvenlik açısından en kritik segment.
Ve her zamanki gibi burada da evrensel bir çözüm yok. Her şey büyük ölçüde ağ gereksinimlerine bağlıdır.
Güvenlik duvarı gerekli mi, değil mi?
Cevap açık gibi görünüyor, ancak her şey göründüğü kadar net değil. Ve seçiminiz yalnızca etkilenebilir fiyat.
Örnek 1. Gecikmeler.
Bazı ağ bölümleri arasında düşük gecikme önemli bir gereklilikse (örneğin, değişim durumunda bu geçerli), bu durumda bu bölümler arasında güvenlik duvarı kullanamayacağız. Güvenlik duvarlarında gecikmeyle ilgili çalışma bulmak zordur, ancak çok az anahtar modeli 1 mksec'den daha az veya daha düşük gecikme süresi sağlayabilir, bu nedenle mikrosaniyeler sizin için önemliyse güvenlik duvarlarının size göre olmadığını düşünüyorum.
Örnek 2. Performans.
En iyi L3 anahtarlarının verimi genellikle en güçlü güvenlik duvarlarının veriminden çok daha yüksektir. Bu nedenle, yüksek yoğunluklu trafik söz konusu olduğunda, büyük olasılıkla bu trafiğin güvenlik duvarlarını atlamasına da izin vermeniz gerekecektir.
Örnek 3. Güvenilirlik.
Güvenlik duvarları, özellikle modern NGFW (Yeni Nesil FW) karmaşık cihazlardır. L3/L2 anahtarlarından çok daha karmaşıktırlar. Çok sayıda hizmet ve yapılandırma seçeneği sağlarlar, bu nedenle güvenilirliklerinin çok daha düşük olması şaşırtıcı değildir. Hizmet sürekliliği ağ için kritik öneme sahipse, neyin daha iyi kullanılabilirliğe yol açacağını seçmeniz gerekebilir: güvenlik duvarı ile güvenlik veya normal ACL'ler kullanan anahtarlar (veya çeşitli yapı türleri) üzerine kurulu bir ağın basitliği.
Yukarıdaki örnekler söz konusu olduğunda, büyük olasılıkla (her zamanki gibi) bir uzlaşma bulmak zorunda kalacaksınız. Aşağıdaki çözümlere bakın:
- Veri merkezi içinde güvenlik duvarlarını kullanmamaya karar verirseniz, çevredeki erişimi mümkün olduğunca nasıl sınırlayacağınızı düşünmeniz gerekir. Örneğin, İnternet'ten yalnızca gerekli bağlantı noktalarını (istemci trafiği için) ve veri merkezine yönetim erişimini yalnızca atlama ana bilgisayarlarından açabilirsiniz. Jump ana makinelerinde gerekli tüm kontrolleri gerçekleştirin (kimlik doğrulama/yetkilendirme, antivirüs, günlük kaydı, ...)
- PSEFABRIC'te açıklanan şemaya benzer şekilde, veri merkezi ağının mantıksal bir bölümünü bölümlere ayırabilirsiniz. . Bu durumda yönlendirme, gecikmeye duyarlı veya yüksek yoğunluklu trafiğin bir segment "içinde" (p002, VRF durumunda) ilerleyeceği ve güvenlik duvarından geçmeyeceği şekilde yapılandırılmalıdır. Farklı segmentler arasındaki trafik güvenlik duvarından geçmeye devam edecek. Trafiğin güvenlik duvarı üzerinden yönlendirilmesini önlemek için VRF'ler arasındaki rota sızıntısını da kullanabilirsiniz.
- Güvenlik duvarını şeffaf modda ve yalnızca bu faktörlerin (gecikme/performans) önemli olmadığı VLAN'lar için de kullanabilirsiniz. Ancak her satıcı için bu modun kullanımıyla ilgili kısıtlamaları dikkatlice incelemeniz gerekir.
- bir hizmet zinciri mimarisi kullanmayı düşünebilirsiniz. Bu, yalnızca gerekli trafiğin güvenlik duvarından geçmesine izin verecektir. Teoride hoş görünüyor, ancak bu çözümü üretimde hiç görmedim. Yaklaşık 5 yıl önce Cisco ACI/Juniper SRX/F3 LTM servis zincirini test ettik ancak o zamanlar bu çözüm bize "kaba" göründü.
Koruma seviyesi
Artık trafiği filtrelemek için hangi araçları kullanmak istediğiniz sorusuna cevap vermeniz gerekiyor. NGFW'de genellikle mevcut olan özelliklerden bazıları şunlardır (örneğin, ):
- Durum bilgisi olan güvenlik duvarı (varsayılan)
- uygulama güvenlik duvarı
- Tehdit önleme (antivirüs, casus yazılım önleme ve güvenlik açığı)
- URL filtreleme
- veri filtreleme (içerik filtreleme)
- dosya engelleme (dosya türleri engelleme)
- dos koruması
Ve her şey de net değil. Görünüşe göre koruma seviyesi ne kadar yüksek olursa o kadar iyi olur. Ama şunu da düşünmelisin
- Yukarıdaki güvenlik duvarı işlevlerini ne kadar çok kullanırsanız, doğal olarak o kadar pahalı olacaktır (lisanslar, ek modüller)
- bazı algoritmaların kullanılması güvenlik duvarı verimini önemli ölçüde azaltabilir ve ayrıca gecikmeleri artırabilir; örneğin bkz.
- Herhangi bir karmaşık çözüm gibi, karmaşık koruma yöntemlerinin kullanılması da çözümünüzün güvenilirliğini azaltabilir; örneğin, uygulama güvenlik duvarı kullanırken, oldukça standart çalışan bazı uygulamaların (dns, smb) engellenmesiyle karşılaştım.
Her zaman olduğu gibi ağınız için en iyi çözümü bulmanız gerekiyor.
Hangi koruma fonksiyonlarının gerekli olabileceği sorusuna kesin olarak cevap vermek imkansızdır. Birincisi, elbette ilettiğiniz veya sakladığınız ve korumaya çalıştığınız verilere bağlı olduğu için. İkinci olarak, gerçekte güvenlik araçlarının seçimi genellikle satıcıya olan inanç ve güven meselesidir. Algoritmaları bilmiyorsunuz, ne kadar etkili olduklarını bilmiyorsunuz ve onları tam olarak test edemiyorsunuz.
Bu nedenle kritik segmentlerde farklı firmaların tekliflerini kullanmak iyi bir çözüm olabilir. Örneğin, güvenlik duvarında antivirüsü etkinleştirebilir, ancak aynı zamanda ana bilgisayarlarda yerel olarak antivirüs korumasını (başka bir üreticinin) kullanabilirsiniz.
segmentasyon
Veri merkezi ağının mantıksal segmentasyonundan bahsediyoruz. Örneğin, VLAN'lara ve alt ağlara bölümlendirme de mantıksal bölümlendirmedir ancak açık olması nedeniyle bunu dikkate almayacağız. FW güvenlik bölgeleri, VRF'ler (ve bunların çeşitli satıcılarla ilişkili analogları), mantıksal cihazlar (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ... gibi varlıkları dikkate alan ilginç segmentasyon ...
Bu tür mantıksal segmentasyona ve şu anda talep gören veri merkezi tasarımına bir örnek aşağıda verilmiştir. .
Ağınızın mantıksal kısımlarını tanımladıktan sonra trafiğin farklı segmentler arasında nasıl hareket ettiğini, filtrelemenin hangi cihazlarda ve hangi araçlarla gerçekleştirileceğini açıklayabilirsiniz.
Ağınızın net bir mantıksal bölümü yoksa ve farklı veri akışları için güvenlik politikaları uygulama kuralları resmileştirilmemişse, bu, şu veya bu erişimi açtığınızda, bu sorunu çözmek zorunda kalacağınız ve büyük olasılıkla her seferinde farklı şekilde çözecektir.
Çoğu zaman segmentasyon yalnızca FW güvenlik bölgelerine dayanır. O zaman aşağıdaki soruları cevaplamanız gerekir:
- hangi güvenlik bölgelerine ihtiyacınız var
- bu bölgelerin her birine hangi düzeyde koruma uygulamak istiyorsunuz?
- bölge içi trafiğe varsayılan olarak izin verilecek mi?
- değilse, her bölgede hangi trafik filtreleme politikaları uygulanacaktır?
- Her bir bölge çifti (kaynak/hedef) için hangi trafik filtreleme politikaları uygulanacaktır?
TCAM
Yaygın bir sorun, hem yönlendirme hem de erişim için yetersiz TCAM'dir (Üçlü İçerik Adreslenebilir Bellek). IMHO, ekipman seçerken bu en önemli konulardan biridir, bu nedenle bu konuya uygun derecede özen göstermeniz gerekir.
Örnek 1. İletim Tablosu TCAM.
Düşünelim güvenlik duvarı
IPv4 yönlendirme tablosu boyutunun* = 32K olduğunu görüyoruz.
Üstelik bu rota sayısı tüm VSYS'ler için ortaktır.Tasarımınıza göre 4 VSYS kullanmaya karar verdiğinizi varsayalım.
Bu VSYS'lerin her biri BGP aracılığıyla BB olarak kullandığınız bulutun iki MPLS PE'sine bağlanır. Böylece, 4 VSYS tüm spesifik rotaları birbirleriyle değiştirir ve yaklaşık olarak aynı rota setlerine (ancak farklı NH'lere) sahip bir yönlendirme tablosuna sahiptir. Çünkü her VSYS'nin 2 BGP oturumu vardır (aynı ayarlarla), ardından MPLS aracılığıyla alınan her rotanın 2 NH'si ve buna göre Yönlendirme Tablosunda 2 FIB girişi vardır. Bunun veri merkezindeki tek güvenlik duvarı olduğunu ve tüm rotaları bilmesi gerektiğini varsayarsak bu, veri merkezimizdeki toplam rota sayısının 32K/(4 * 2) = 4K'dan fazla olamayacağı anlamına gelecektir.Şimdi, 2 veri merkezimiz olduğunu (aynı tasarıma sahip) varsayarsak ve veri merkezleri arasında "uzatılmış" VLAN'lar kullanmak istiyorsak (örneğin, vMotion için), o zaman yönlendirme problemini çözmek için ana bilgisayar rotalarını kullanmalıyız . Ancak bu, 2 veri merkezi için 4096'dan fazla olası ana makineye sahip olamayacağımız anlamına gelir ve elbette bu yeterli olmayabilir.
Örnek 2. ACL TCAM.
L3 anahtarlarındaki (veya Cisco ACI gibi L3 anahtarlarını kullanan diğer çözümlerdeki) trafiği filtrelemeyi planlıyorsanız, ekipmanı seçerken TCAM ACL'ye dikkat etmelisiniz.
Cisco Catalyst 4500'ün SVI arayüzlerine erişimi kontrol etmek istediğinizi varsayalım. , arayüzlerde giden (ve gelen) trafiği kontrol etmek için yalnızca 4096 TCAM hattını kullanabilirsiniz. Bu, TCAM3'ü kullanırken size yaklaşık 4000 bin ACE (ACL hattı) verecektir.
Yetersiz TCAM sorunuyla karşı karşıya kalırsanız öncelikle elbette optimizasyon olasılığını dikkate almanız gerekir. Dolayısıyla Yönlendirme Tablosunun boyutuyla ilgili bir sorun olması durumunda rotaları birleştirme olasılığını göz önünde bulundurmanız gerekir. Erişimler için TCAM boyutuyla ilgili bir sorun olması durumunda, erişimleri denetleyin, eski ve çakışan kayıtları kaldırın ve muhtemelen erişimlerin açılması prosedürünü revize edin (erişimlerin denetlenmesi bölümünde ayrıntılı olarak ele alınacaktır).
Yüksek kullanılabilirlik
Soru şu: HA'yı güvenlik duvarları için mi kullanmalıyım yoksa "paralel" iki bağımsız kutu mu kurmalıyım ve bunlardan biri arızalanırsa trafiği ikinciye mi yönlendirmeliyim?
Görünüşe göre cevap açık - HA kullanın. Bu sorunun hala ortaya çıkmasının nedeni, ne yazık ki, pratikte teorik ve reklamsal yüzdelerin ve erişilebilirliğin birkaç ondalık yüzdesinin o kadar da pembe olmaktan uzak olmasıdır. HA mantıksal olarak oldukça karmaşık bir şeydir ve farklı ekipmanlarda ve farklı satıcılarda (hiçbir istisna yoktu) sorunlar, hatalar ve hizmet kesintileri yakaladık.
HA kullanıyorsanız, bireysel düğümleri kapatma, hizmeti durdurmadan bunlar arasında geçiş yapma olanağına sahip olacaksınız; bu, örneğin yükseltmeler yaparken önemlidir, ancak aynı zamanda her iki düğümün de devre dışı kalması ihtimali sıfırdan çok uzaktır. aynı anda bozulacaktır ve ayrıca bir sonraki yükseltme satıcının vaat ettiği kadar sorunsuz ilerlemeyecektir (yükseltmeyi laboratuvar ekipmanında test etme fırsatınız varsa bu sorundan kaçınılabilir).
HA kullanmıyorsanız, çifte arıza açısından riskleriniz çok daha düşüktür (2 bağımsız güvenlik duvarınız olduğundan), ancak... oturumlar senkronize edilmezse bu güvenlik duvarları arasında her geçiş yaptığınızda trafiği kaybedersiniz. Elbette durum bilgisi olmayan güvenlik duvarı kullanabilirsiniz, ancak bu durumda güvenlik duvarı kullanmanın amacı büyük ölçüde kaybolur.
Bu nedenle, denetim sonucunda yalnız güvenlik duvarları keşfettiyseniz ve ağınızın güvenilirliğini artırmayı düşünüyorsanız, o zaman HA elbette önerilen çözümlerden biridir ancak bununla ilgili dezavantajları da dikkate almalısınız. bu yaklaşımla ve belki de özellikle ağınız için başka bir çözüm daha uygun olacaktır.
Yönetilebilirlik
Prensipte HA aynı zamanda kontrol edilebilirlikle de ilgilidir. 2 kutuyu ayrı ayrı yapılandırmak ve yapılandırmaları senkronize tutma sorunuyla uğraşmak yerine, bunları sanki tek bir cihazınız varmış gibi yönetirsiniz.
Ancak belki de çok sayıda veri merkeziniz ve çok sayıda güvenlik duvarınız var, o zaman bu soru yeni bir düzeyde ortaya çıkıyor. Ve soru sadece konfigürasyonla ilgili değil, aynı zamanda
- yedekleme yapılandırmaları
- güncellemeler
- yükseltmeler
- izleme
- Kerestecilik
Ve tüm bunlar merkezi yönetim sistemleri ile çözülebilir.
Örneğin, Palo Alto güvenlik duvarlarını kullanıyorsanız, o zaman böyle bir çözümdür.
Devam edecek.
Kaynak: habr.com