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 prosazování zásad ve virtuální síti. Pak se seznámíte s obecnými kroky pro vynucování zabezpečení pomocí pravidel správce zabezpečení.

Vynucování virtuální sítě

Se samotnými skupinami zabezpečení sítě (NSG) může být plošné vynucování zásad ve virtuálních sítích napříč několika aplikacemi, týmy nebo dokonce celými organizacemi obtížné. Č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 správy nastavují mantinely pomocí pravidel správce zabezpečení a zároveň ponechávají jednotlivým týmům prostor, aby mohly podle potřeby flexibilně upřesnit zabezpečení prostřednictvím pravidel NSG. Pravidla správce zabezpečení nejsou určena k nahrazení 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 – Správa centrálního governance týmu pomocí NSG

V tomto modelu spravuje všechny NSG centrální tým správy v rámci organizace.

Výhody Nevýhody
Centrální tým správy může prosazovat důležitá bezpečnostní pravidla. 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 - správa jednotlivých týmů pomocí NSGs

V tomto modelu jednotlivé týmy v organizaci, která nemá centrální tým pro správu a řízení, spravují vlastní skupiny zabezpečení sítě (NSG).

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ů.

Jednotlivé týmy také mohou chybně nakonfigurovat nebo zapomenout připojit NSG, což vede ke vzniku bezpečnostních zranitelností.

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 jednotlivé týmy stále spravují své NSG. 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 správy stále nemůže vynucovat standardní bezpečnostní pravidla, protože vlastníci NSG v jednotlivých týmech je stále mohou upravovat.

Spravovat oznámení by bylo také příliš náročné.

Vynucování pravidel síťového provozu a výjimky pomocí pravidel 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í NSG bez pravidel správce zabezpečení, správce nemůže vynucovat kritická bezpečnostní pravidla, čímž zůstávají otevřená potenciální bezpečnostní rizika. 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ů:

  • Prosazujte pravidla správce zabezpečení v celé organizaci.
  • Povolte výjimky pro aplikační tým pro zpracování provozu SSH.

Diagram vynucení pravidel správce zabezpečení se skupinami zabezpečení sítě ve službě Azure Virtual Network Manager

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í

Pravidla správce bezpečnosti jsou hodnocena podle prioritního pořadí a nejprve se hodnotí pravidlo s menším číslem priority. V tomto kroku obsahuje konfigurace správce bezpečnosti dvě pravidla pro správce bezpečnosti:

  • Pravidlo bezpečnostního administrátora, které odmítá příchozí SSH provoz pro skupinu ALL network s prioritou 100.
  • Pravidlo bezpečnostního administrátora, které umožňuje příchozí SSH provoz pro skupinu aplikací s prioritou 10.

Protože 10 je menší než 100, pravidlo povolení pro skupinu App Network se vyhodnocuje před pravidlem zamítnutí, které platí pro každou virtuální síť v organizaci.

Krok 4: Nasazení konfigurace správce zabezpečení

Po nasazení konfigurace správce bezpečnosti mají všechny virtuální sítě ve firmě pravidlo zamítnutí příchozího SSH provozu, které vynucuje pravidlo správců bezpečnosti. Pravidlo zamítnutí nemůže upravovat žádný jednotlivý tým. Pouze správce firmy ji může definovat. Virtuální sítě aplikací mají jak pravidlo povolit příchozí SSH provoz, tak pravidlo zakázat příchozí SSH provoz (zděděné z pravidla skupiny všech sítí). Pravidlo povolit příchozí SSH provoz pro skupinu aplikací je prioritou 10, takže se nejprve vyhodnocuje. Když do virtuální sítě App přichází příchozí provoz SSH, pravidlo s prioritou 10 tento provoz povolí. Za předpokladu, že jsou NSG na podsítích virtuálních sítí aplikace , je tento příchozí SSH provoz dále vyhodnocován na základě NSG nastavených aplikačním týmem. Zde popsaná metodika pravidel správce zabezpečení umožňuje správci firmy efektivně vynucovat firemní zásady a vytvářet v celé organizaci flexibilní bezpečnostní mantinely, které fungují s NSG.

Další kroky

  • Last updated on