Nový Azure Firewall: na co se hodí a v čem je jiný, než NSG nebo App Gateway?
Před pár dny bylo uvedeno preview produktu Azure Firewall. Kdy mám použít Network Security Group, kdy Application Gateway, kdy Azure Firewall a kdy prvky třetích stran? Pojďme si na to odpovědět a Azure Firewall vyzkoušet.
Řízení síťového provozu v Azure
Azure nabízí dva nativní prostředky, které jsou k dispozici zdarma. Jde o Network Security Group, která umožňuje filtrovat provoz stavovým způsobem na základě IP adres, portů a tagů (například na některé služby v Azure) a Application Security Group, která doplňuje NSG o možnost vytvářet dynamické objekty (skupiny VM). Je to plně stavové řešení a lze je aplikovat na subnet, na samotné VM nebo na oboje současně. Přečtěte si o NSG a ASG více zde: https://tomaskubica.cz/jak-navrhnout-fw-pravidla-v-azure-s-nsg-a-asg/
Jak vystavit aplikaci do Internetu? Stáčí dát vašemu VM Public IP a povolit provoz v NSG. Pokud se jedná o farmu webů, můžete dát Public IP na Azure Load Balancer a na něm nastavit pravidla pro balancování webového provozu dovnitř farmy. Pokud chcete mít věci ještě víc pod kontrolou a vystavit aplikaci „nepřímo“ přes reverse proxy, je tu Azure Application Gateway. Ta dokáže terminovat TLS provoz, provádět chytré směrování na základě domén a URL nebo aplikovat pravidla Web Application Firewallu.
Chybí něco?
Se zmíněnými základními prostředky se dá udělat opravdu hodně, tak chybí něco?
Co se týče pokročilých funkcí nějakého NGFW jako jsou IPS, DLP či proudový antivir, něco takového nativní prostředky Azure nedělají. Stejně tak můžete mít potřebu používat zařízení, která máte schválena ve firemním standardu a nemusíte si tak nechat zdlouhavě schvalovat něco jiného. To samé platí pro nějaké hybridní řešení správy všech firewallů apod. Máte-li tyto požadavky, použijte řešení třetí strany dle vaší volby – podpora pro Azure je velmi bohatá.
Nechme ale tohle stranou – ještě něco by to chtělo? Zaměřme se na odchozí provoz do Internetu. Pokud VM nedáte Public IP a ona bude chtít do Internetu, půjde napřímo (pokud jí to nezakážete v NSG) nebo třeba přes on-premises za VPNkou (s force tunnelingem – není moc efektivní, ale jde to). NSG pravidly tedy můžeme ovlivnit kam se z VM dostaneme a kam ne. To je fajn, ale v tomto případě daleko častěji potřebujeme doménové jméno, než IP. Ta se u veřejně dostupných služeb často mění, rozhodující je spíše URL. To NSG neumí. Řadu PaaS služeb můžete řešit přes Service Endpoint (to v zásadě dělá něco podobného – propouští provoz z VNETu do cílové PaaS služby a v ní blokuje přístupy odjinud z Internetu – nicméně je to spíše protunelování, uvnitř PaaS služby uvidíte v logu přístup z privátní adresy VNETu). Ne všechny služby ale Service Endpoint mají a ne všechny služby jsou Azure PaaS. Co třeba Visual Studio Team Services, GitHub, API či otevřená data vašeho města či jiná cloudová služba?
Druhá starost může vzniknou v okamžiku, kdy vaše aplikace komunikuje do nějakého API běžícího na veřejné IP, které vyžaduje whitelisting vaší IP adresy. V on-premises to necháte protéct vaším firewallem, zaNATujete a víte, že to odejde s konkrétní IP. Pokud ale VM v Azure nemá Public IP, odchozí adresa vám bude propůjčena per session (takže ji dopředu nevíte). Můžete dát Public IP každé VM aplikace, ale to znamená řešit whitelist pro několik adrest. Můžeme před VMka dát Azure LB s Public IP a odchozí provoz z VM bude dělat SNAT na jeho IP. To se nám ale nemusí hodit. Tak například pro VMka potřebujeme interní LB, protože aplikace je určena pro vnitřní síť. To znemožňuje mít na ní ještě druhý LB s public IP. Nebo máme potřebu dát jednu IP směrem ven pro různé části aplikace a dát je pod jeden LB nedává smysl. Nebo jsou tyto části v různých subnetech nebo dokonce různých VNETech propojeních přes VNET peering. Zkrátka někdy tam LB nedostaneme, tak co s tím?
Napadá mě ještě třetí situace. Máte větší prostředí a z důvodu oddělení různých projektů používáte více subscription a jednu sdílenou s kontektivitou a infrastrukturou (/en-us/azure/networking/networking-virtual-datacenter). V rámci vaší politiky chcete řídit co smí do Internetu, co se má vystavit do Internetu a jak mohou projekty komunikovat mezi sebou. Mohli bychom to řešit v rámci projektové subscription s využitím NSG/ASG pro filtraci a Application Gateway pro vystavení do Internetu. Ale co když je projektů několik? A vlastníci projektů tak nebudou mít přístup k nastavení NSG, aby neobcházeli pravidla? Nebude to omezující? Potřebovali bychom centralizované řešení tohoto problému uvnitř sdílené subskripce.
Azure Firewall
Produkt byl oznámen před několika dny a jeho první verze se právě nachází v Preview, o které můžete požádat. Dá se tak očekávat, že produkt se bude aktivně rozvíjet a aktuální sada funkcí bude postupně vylepšována. Pojďme si říct jak to funguje, na co je to dobré a prakticky si to nasadit.
Pokračovat ve čtení
(Článek napsal Tomáš Kubice, pokračování a další informace na jeho blogu...)