Vynucení virtuální sítě pomocí pravidel správce zabezpečení ve službě Azure Virtual Network Manager
V tomto článku se dozvíte, jak pravidla správců zabezpečení poskytují flexibilní a škálovatelné vynucování zásad zabezpečení u nástrojů, jako jsou skupiny zabezpečení sítě. Nejprve se seznámíte s různými modely vynucení virtuální sítě. Pak se seznámíte s obecnými kroky pro vynucování zabezpečení pomocí pravidel správce zabezpečení.
Vynucení virtuální sítě
S jednotlivými skupinami zabezpečení sítě (NSG) může být rozšířené vynucování virtuálních sítí napříč několika aplikacemi, týmy nebo dokonce celou organizací složité. Často existuje vyvážení mezi pokusy o centralizované vynucování v rámci organizace a předání podrobného a flexibilního řízení týmům.
Pravidla správce zabezpečení se zaměřují na odstranění tohoto posuvného rozsahu mezi vynucením a flexibilitou tím, že konsolidují výhody každého z těchto modelů a zároveň snižují nevýhody jednotlivých modelů. Centrální týmy zásad správného řízení vytvářejí ochranné mantinely prostřednictvím pravidel správy zabezpečení a přitom stále opouští prostor pro jednotlivé týmy, aby pružně určily zabezpečení podle potřeby prostřednictvím pravidel NSG. Pravidla správce zabezpečení nejsou určená k přepsání pravidel NSG. Místo toho pracují s pravidly NSG, která zajišťují vynucování a flexibilitu ve vaší organizaci.
Modely vynucení
Podívejme se na několik běžných modelů správy zabezpečení bez pravidel správce zabezpečení a jejich výhod a nevýhod:
Model 1 – Centrální správa týmů zásad správného řízení pomocí skupin zabezpečení sítě
V tomto modelu spravuje centrální tým zásad správného řízení v organizaci všechny skupiny zabezpečení sítě.
| Výhody | Nevýhody |
|---|---|
| Centrální tým zásad správného řízení může vynutit důležitá pravidla zabezpečení. | Provozní režie je vysoká, protože správci potřebují spravovat každou skupinu zabezpečení sítě, protože se zvyšuje počet skupin zabezpečení sítě, zvyšuje se zatížení. |
Model 2 – individuální týmová správa pomocí skupin zabezpečení sítě
V tomto modelu jednotlivé týmy v organizaci bez centralizovaného týmu zásad správného řízení spravují vlastní skupiny zabezpečení sítě.
| Výhody | Nevýhody |
|---|---|
| Individuální tým má flexibilní kontrolu nad přizpůsobením pravidel zabezpečení na základě požadavků na služby. | Centrální tým zásad správného řízení nemůže vynucovat důležitá pravidla zabezpečení, jako je blokování rizikových portů. Individuální tým může také chybně nakonfigurovat nebo zapomenout připojit skupiny zabezpečení sítě, což vede k ohrožení zabezpečení sítě. |
Model 3 – Skupiny zabezpečení sítě se vytvářejí prostřednictvím služby Azure Policy a spravují je jednotlivé týmy.
V tomto modelu stále spravují jednotlivé týmy skupiny zabezpečení sítě. Rozdíl je v tom, že skupiny zabezpečení sítě se vytvářejí pomocí Azure Policy k nastavení standardních pravidel. Úprava těchto pravidel by aktivovala oznámení auditu.
| Výhody | Nevýhody |
|---|---|
| Individuální tým má flexibilní kontrolu nad přizpůsobením pravidel zabezpečení. Centrální tým zásad správného řízení může vytvořit standardní pravidla zabezpečení a přijímat oznámení, pokud jsou pravidla upravena. |
Centrální tým zásad správného řízení stále nemůže vynucovat standardní pravidla zabezpečení, protože vlastníci NSG v týmech je stále můžou upravovat. Správa oznámení by také zahlcela. |
Vynucení síťového provozu a výjimky s pravidly správce zabezpečení
Pojďme použít koncepty, které jsme zatím probírali, na ukázkový scénář. Správce podnikové sítě chce vynutit pravidlo zabezpečení, které zablokuje příchozí provoz SSH pro celou společnost. Vynucení tohoto typu pravidla zabezpečení bylo obtížné bez pravidla správce zabezpečení. Pokud správce spravuje všechny skupiny zabezpečení sítě, režijní náklady na správu jsou vysoké a správce nemůže rychle reagovat na požadavky produktového týmu na úpravy pravidel NSG. Na druhou stranu, pokud produktové týmy spravují vlastní skupiny zabezpečení sítě bez pravidel správce zabezpečení, nemůže správce vynutit důležitá pravidla zabezpečení a ponechat potenciální rizika zabezpečení otevřená. Toto dilema vyřešíte pomocí pravidel správce zabezpečení i skupin zabezpečení sítě.
V takovém případě může správce vytvořit pravidlo správce zabezpečení, které zablokuje příchozí provoz SSH pro všechny virtuální sítě ve společnosti. Správce může také vytvořit pravidlo správce zabezpečení, které povolí příchozí provoz SSH pro konkrétní virtuální sítě, které potřebují výjimku. Pravidlo správce zabezpečení se vynucuje v celé společnosti a správce může dál povolovat výjimky pro konkrétní virtuální sítě. To se provádí pomocí pořadí priority pro každé pravidlo.
Diagram znázorňuje, jak může správce dosáhnout následujících cílů:
- Vynucujte pravidla správce zabezpečení v celé organizaci.
- Povolte výjimky pro tým aplikace, aby zpracovával provoz SSH.
Krok 1: Vytvoření instance správce sítě
Správce společnosti může vytvořit správce sítě s kořenovou skupinou pro správu firmy jako rozsah této instance správce sítě.
Krok 2: Vytvoření skupin sítě pro virtuální sítě
Správce vytvoří dvě skupiny sítí – všechny skupiny sítí, které se skládají ze všech virtuálních sítí v organizaci, a skupina sítí aplikací, která se skládá z virtuálních sítí pro aplikaci, která potřebuje výjimku. Všechny skupiny sítí ve výše uvedeném diagramu se skládají z virtuální sítě 1 do virtuální sítě 5 a skupina sítí aplikací má virtuální síť 4 a virtuální síť 5. Uživatelé mohou snadno definovat obě skupiny sítě pomocí dynamického členství.
Krok 3: Vytvoření konfigurace správce zabezpečení
V tomto kroku jsou definována dvě pravidla správce zabezpečení s následující konfigurací správce zabezpečení:
- pravidlo správce zabezpečení, které blokuje příchozí provoz SSH pro všechny skupiny sítí s nižší prioritou 100.
- Pravidlo správce zabezpečení, které povoluje příchozí provoz SSH pro skupinu sítí aplikací s vyšší prioritou 10.
Krok 4: Nasazení konfigurace správce zabezpečení
Po nasazení konfigurace správce zabezpečení mají všechny virtuální sítě ve společnosti pravidlo odepření příchozího provozu SSH vynucené pravidlem správce zabezpečení. Pravidlo zamítnutí nemůže upravovat žádný jednotlivý tým, ale jenom definovaný správce společnosti může. Virtuální sítě aplikace mají jak pravidlo povoleného příchozího provozu SSH, tak pravidlo odepření příchozího provozu SSH (zděděno ze všech pravidel skupiny sítě). S menším číslem priority u pravidla povoleného příchozího provozu SSH pro skupinu sítí aplikací se pravidlo vyhodnotí jako první. Pokud příchozí provoz SSH přichází do virtuální sítě aplikace, pravidlo správce zabezpečení s vyšší prioritou povoluje provoz. Za předpokladu, že v podsítích virtuálních sítí aplikace existují skupiny zabezpečení sítě, vyhodnotí se tento příchozí provoz SSH dále na základě skupin zabezpečení sítě nastavených týmem aplikací. Metodologie pravidel správce zabezpečení popsaná tady umožňuje správci společnosti efektivně vynucovat firemní zásady a vytvářet flexibilní ochranné mantinely zabezpečení v organizaci, která pracuje se skupinami zabezpečení sítě.
Další kroky
Zjistěte, jak blokovat porty s vysokým rizikem pomocí pravidel správce zabezpečení.
Nejčastější dotazy ke službě Azure Virtual Network Manager