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

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 zasad sieci wirtualnej

W przypadku korzystania z samych sieciowych grup zabezpieczeń (NSG) stosowanie zasad na szeroką skalę w sieciach wirtualnych w ramach wielu aplikacji, zespołów, a nawet całych 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 odpowiedzialne za nadzór ustanawiają mechanizmy ochronne za pomocą reguł administracyjnych zabezpieczeń, pozostawiając jednocześnie poszczególnym zespołom możliwość elastycznego i precyzyjnego dostosowywania zabezpieczeń do potrzeb za pomocą reguł sieciowych grup zabezpieczeń (NSG). Reguły administratora zabezpieczeń nie służą do zastępowania reguł NSG. Zamiast tego działają razem z regułami NSG, aby umożliwić egzekwowanie i elastyczność w całej Twojej organizacji.

Modele wymuszania

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

Model 1 - zarządzanie przez centralny zespół nadzoru przy użyciu NSG

W tym modelu centralny zespół ds. zarządzania w organizacji zarządza wszystkimi grupami NSG.

Zalety Minusy
Centralny zespół ds. ładu może wymuszać ważne reguły zabezpieczeń. Narzut operacyjny jest wysoki, ponieważ administratorzy muszą zarządzać każdą grupą NSG, a wraz ze wzrostem liczby grup NSG rośnie też to obciążenie.

Model 2 — indywidualne zarządzanie zespołem przy użyciu sieciowych grup zabezpieczeń (NSG)

W tym modelu poszczególne zespoły w organizacji, która nie ma scentralizowanego zespołu ds. nadzoru, zarządzają własnymi grupami zabezpieczeń sieciowych (NSG).

Zalety 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ą grupami NSG. Różnica polega na tym, że sieciowe grupy zabezpieczeń są tworzone przy użyciu usługi Azure Policy do ustawiania standardowych reguł. Modyfikacja tych reguł spowodowałaby wysyłanie powiadomień audytu.

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. nadzoru nadal nie może egzekwować standardowych zasad zabezpieczeń, ponieważ właściciele NSG w poszczególnych zespołach nadal mogą je modyfikować.

Zarządzanie powiadomieniami byłoby również przytłaczające.

Egzekwowanie ruchu sieciowego i wyjątki przy użyciu reguł administratora ds. 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 produktowe zarządzają własnymi grupami NSG bez reguł zabezpieczeń definiowanych przez administratora, administrator nie może wymuszać krytycznych reguł zabezpieczeń, co naraża system na potencjalne zagrożenia bezpieczeństwa. 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ń za pomocą sieciowych grup zabezpieczeń w usłudze Azure Virtual Network Manager.

Krok 1: Utwórz instancję menedżera sieci

Administrator firmy może utworzyć menedżera sieciowego, którego zakresem jest główna grupa zarządzania firmy dla tej instancji menedżera sieciowego.

Krok 2. Tworzenie grup sieciowych dla sieci wirtualnych

Administrator tworzy dwie grupy sieci — grupę sieci ALL obejmującą wszystkie sieci wirtualne w organizacji oraz grupę sieci aplikacji obejmującą sieci wirtualne 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ń

Reguły administratora ds. zabezpieczeń są przetwarzane zgodnie z kolejnością priorytetów, a reguła z niższym numerem priorytetu jest przetwarzana jako pierwsza. W tym etapie konfiguracja administratora bezpieczeństwa zawiera dwie reguły administratora bezpieczeństwa:

  • Reguła administratora bezpieczeństwa, która odmawia ruchu SSH dla grupy sieci ALL o priorytecie 100.
  • Reguła administratora bezpieczeństwa, która pozwala na ruch przychodzący SSH dla grupy sieciowej aplikacji o priorytecie 10.

Ponieważ 10 jest mniejsze niż 100, reguła zezwalania dla grupy sieci aplikacji jest oceniana przed zasadą odmowy, która dotyczy każdej wirtualnej sieci w organizacji.

Krok 4. Wdrażanie konfiguracji administratora zabezpieczeń

Po wdrożeniu konfiguracji administratora bezpieczeństwa wszystkie sieci wirtualne w firmie mają regułę odmowy ruchu SSH przychodzącego, wymuszoną przez regułę administratora bezpieczeństwa. Żaden zespół nie może zmodyfikować reguły odmowy. Tylko administrator firmy może to zdefiniować. Wirtualne sieci aplikacji mają zarówno regułę zezwalania na przychodzący ruch SSH, jak i regułę odmowy ruchu SSH (odziedziczoną z reguły All network group ). Reguła zezwalania na ruch przychodzący SSH dla grupy sieci aplikacji ma priorytet 10, więc jest oceniana jako najpierw. Gdy przychodzący ruch SSH dociera do wirtualnej sieci App, reguła o priorytecie 10 zezwala na ten ruch. Zakładając, że na podsieciach wirtualnych sieci aplikacji znajdują się NSG, ten przychodzący ruch SSH jest następnie oceniany na podstawie NSG ustawionych przez zespół aplikacyjny. Opisana tutaj metodyka reguł administratora ds. zabezpieczeń umożliwia administratorowi przedsiębiorstwa skuteczne egzekwowanie zasad firmy i tworzenie elastycznych mechanizmów ochronnych w całej organizacji, współpracujących z sieciowymi grupami zabezpieczeń (NSG).

Następne kroki

  • Last updated on