Udostępnij za pośrednictwem

Wymuszanie sieci wirtualnej przy użyciu reguł administratora zabezpieczeń w usłudze Azure Virtual Network Manager

  • Artykuł

W tym artykule dowiesz się, jak reguły administratorów zabezpieczeń zapewniają elastyczne i skalowalne wymuszanie zasad zabezpieczeń za pośrednictwem narzędzi, takich jak sieciowe grupy zabezpieczeń. Najpierw poznasz różne modele wymuszania sieci wirtualnej. Następnie poznasz ogólne kroki wymuszania zabezpieczeń przy użyciu reguł administratora zabezpieczeń.

Wymuszanie sieci wirtualnej

W przypadku samych sieciowych grup zabezpieczeń powszechne wymuszanie sieci wirtualnych w kilku aplikacjach, zespołach, a nawet w całej organizacji może być trudne. Często istnieje równoważenie między próbami scentralizowanego wymuszania w całej organizacji i przekazanie szczegółowej, elastycznej kontroli zespołom.

Reguły administratora zabezpieczeń mają na celu wyeliminowanie tej przesuwającej się skali między wymuszaniem i elastycznością przez skonsolidowanie zalet każdego z tych modeli przy jednoczesnym zmniejszeniu wad każdego z nich. Centralne zespoły ds. ładu ustanawiają koleje ochrony za pośrednictwem reguł administratora zabezpieczeń, pozostawiając jednocześnie miejsce dla poszczególnych zespołów, aby elastycznie wskazać bezpieczeństwo zgodnie z potrzebami za pośrednictwem reguł sieciowej grupy zabezpieczeń. Reguły administratora zabezpieczeń nie są przeznaczone do zastępowania reguł sieciowej grupy zabezpieczeń. Zamiast tego współpracują z regułami sieciowej grupy zabezpieczeń, aby zapewnić wymuszanie i elastyczność w całej organizacji.

Modele wymuszania

Przyjrzyjmy się kilku typowym modelom zarządzania zabezpieczeniami bez reguł administratora zabezpieczeń oraz ich zaletami i wadami:

Model 1 — centralne zarządzanie zespołem ds. ładu za pomocą sieciowych grup zabezpieczeń

W tym modelu centralny zespół ds. ładu w organizacji zarządza wszystkimi sieciowymi grupami zabezpieczeń.

Plusy Minusy
Centralny zespół ds. ładu może wymuszać ważne reguły zabezpieczeń. Obciążenie operacyjne jest wysokie, ponieważ administratorzy muszą zarządzać każdą sieciową grupą zabezpieczeń, w miarę wzrostu liczby sieciowych grup zabezpieczeń obciążenia.

Model 2 — indywidualne zarządzanie zespołami za pomocą sieciowych grup zabezpieczeń

W tym modelu poszczególne zespoły w organizacji bez scentralizowanego zespołu ds. ładu zarządzają własnymi sieciowymi grupami zabezpieczeń.

Plusy Minusy
Indywidualny zespół ma elastyczną kontrolę nad dostosowywaniem reguł zabezpieczeń na podstawie ich wymagań dotyczących usług. Centralny zespół ds. ładu nie może wymuszać krytycznych reguł zabezpieczeń, takich jak blokowanie ryzykownych portów.

Pojedynczy zespół może również błędnie skonfigurować lub zapomnieć o dołączeniu sieciowych grup zabezpieczeń, co prowadzi do ujawnienia luk w zabezpieczeniach.

Model 3 — sieciowe grupy zabezpieczeń są tworzone za pośrednictwem usługi Azure Policy i zarządzane przez poszczególne zespoły.

W tym modelu poszczególne zespoły nadal zarządzają sieciowymi grupami zabezpieczeń. Różnica polega na tym, że sieciowe grupy zabezpieczeń są tworzone przy użyciu usługi Azure Policy do ustawiania standardowych reguł. Zmodyfikowanie tych reguł spowoduje wyzwolenie powiadomień inspekcji.

Plusy Minusy
Zespół indywidualny ma elastyczną kontrolę nad dostosowywaniem reguł zabezpieczeń.

Centralny zespół ds. ładu może tworzyć standardowe reguły zabezpieczeń i otrzymywać powiadomienia, jeśli reguły są modyfikowane.		 Centralny zespół ds. ładu nadal nie może wymusić standardowych reguł zabezpieczeń, ponieważ właściciele sieciowych grup zabezpieczeń w zespołach nadal mogą je modyfikować.

Powiadomienia byłyby również przytłaczające do zarządzania.

Wymuszanie ruchu sieciowego i wyjątki z regułami administratora zabezpieczeń

Zastosujmy pojęcia omówione do tej pory w przykładowym scenariuszu. Administrator sieci firmowej chce wymusić regułę zabezpieczeń, aby zablokować przychodzący ruch SSH dla całej firmy. Wymuszanie tego typu reguły zabezpieczeń było trudne bez reguły administratora zabezpieczeń. Jeśli administrator zarządza wszystkimi sieciowymi grupami zabezpieczeń, obciążenie związane z zarządzaniem jest wysokie, a administrator nie może szybko reagować na potrzeby zespołów ds. produktów w celu zmodyfikowania reguł sieciowej grupy zabezpieczeń. Z drugiej strony, jeśli zespoły produktów zarządzają własnymi sieciowymi grupami zabezpieczeń bez reguł administratora zabezpieczeń, administrator nie może wymusić krytycznych reguł zabezpieczeń, pozostawiając potencjalne zagrożenia bezpieczeństwa otwarte. Korzystanie zarówno z reguł administratora zabezpieczeń, jak i sieciowych grup zabezpieczeń może rozwiązać ten dylemat.

W takim przypadku administrator może utworzyć regułę administratora zabezpieczeń, aby zablokować przychodzący ruch SSH dla wszystkich sieci wirtualnych w firmie. Administrator może również utworzyć regułę administratora zabezpieczeń, aby zezwolić na przychodzący ruch SSH dla określonych sieci wirtualnych, które wymagają wyjątku. Reguła administratora zabezpieczeń jest wymuszana w całej firmie, a administrator może nadal zezwalać na wyjątki dla określonych sieci wirtualnych. Odbywa się to za pomocą kolejności priorytetu dla każdej reguły.

Na diagramie pokazano, jak administrator może osiągnąć następujące cele:

  • Wymuszanie reguł administratora zabezpieczeń w całej organizacji.
  • Zezwalaj na wyjątki dla zespołu aplikacji do obsługi ruchu SSH.

Diagram wymuszania reguł administratora zabezpieczeń z sieciowymi grupami zabezpieczeń.

Krok 1. Tworzenie wystąpienia menedżera sieci

Administrator firmy może utworzyć menedżera sieci z główną grupą zarządzania firmy jako zakres tego wystąpienia menedżera sieci.

Krok 2. Tworzenie grup sieciowych dla sieci wirtualnych

Administrator tworzy dwie grupy sieciowe — WSZYSTKIE grupy sieciowe składające się ze wszystkich sieci wirtualnych w organizacji, a grupa sieci aplikacji składająca się z sieci wirtualnych dla aplikacji wymagającej wyjątku. Wszystkie grupy sieciowe na powyższym diagramie składają się z sieci wirtualnej 1 do sieci wirtualnej 5, a grupa sieci aplikacji ma sieć wirtualną 4 i sieć wirtualną 5. Użytkownicy mogą łatwo definiować obie grupy sieciowe przy użyciu członkostwa dynamicznego.

Krok 3. Tworzenie konfiguracji administratora zabezpieczeń

W tym kroku zdefiniowano dwie reguły administratora zabezpieczeń z następującą konfiguracją administratora zabezpieczeń:

  • reguła administratora zabezpieczeń blokująca przychodzący ruch SSH dla wszystkich grup sieciowych o niższym priorytcie 100.
  • reguła administratora zabezpieczeń zezwala na przychodzący ruch SSH dla grupy sieci aplikacji o wyższym priorytcie 10.

Krok 4. Wdrażanie konfiguracji administratora zabezpieczeń

Po wdrożeniu konfiguracji administratora zabezpieczeń wszystkie sieci wirtualne w firmie mają regułę odmowy ruchu przychodzącego SSH wymuszaną przez regułę administratora zabezpieczeń. Żaden indywidualny zespół nie może zmodyfikować reguły odmowy, tylko zdefiniowany administrator firmy może. Sieci wirtualne aplikacji mają zarówno regułę ruchu SSH dla ruchu przychodzącego SSH, jak i regułę ruchu SSH dla ruchu przychodzącego (dziedziczona z reguły grupy sieci wszystkie). Przy mniejszym numerze priorytetu reguły zezwalania na ruch przychodzący SSH dla grupy sieci aplikacji reguła jest oceniana jako pierwsza. Gdy przychodzący ruch SSH przychodzi do sieci wirtualnej aplikacji, reguła administratora zabezpieczeń o wyższym priorytcie zezwala na ruch. Zakładając, że istnieją sieciowe grupy zabezpieczeń w podsieciach sieci wirtualnych aplikacji, ten przychodzący ruch SSH jest następnie oceniany na podstawie sieciowych grup zabezpieczeń ustawionych przez zespół aplikacji. Opisana tutaj metodologia reguł administratora zabezpieczeń umożliwia administratorowi firmy efektywne wymuszanie zasad firmy i tworzenie elastycznych szyn ochrony zabezpieczeń w całej organizacji, która współpracuje z sieciowymi grupami zabezpieczeń.

Następne kroki