Co to jest usługa Azure Policy?

W tym omówieniu opisano, jak usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Za pośrednictwem panelu zgodności udostępnia zagregowany widok umożliwiający ocenę ogólnego stanu środowiska, z możliwością szczegółowej analizy na poziomie zasobów i polityk. Pomaga również zapewnić zgodność zasobów dzięki korygowaniu zbiorczemu istniejących zasobów i automatycznemu korygowaniu nowych zasobów.

Typowe przypadki użycia usługi Azure Policy obejmują implementowanie ładu na potrzeby spójności zasobów, zgodności z przepisami, bezpieczeństwa, kontroli kosztów i zarządzania. Definicje zasad dla tych typowych przypadków użycia są już dostępne w środowisku platformy Azure w celu ułatwienia rozpoczęcia pracy.

Oto niektóre przydatne działania związane z zarządzaniem, które można wymusić za pomocą usługi Azure Policy:

• Upewnij się, że zespół wdraża zasoby platformy Azure tylko w dozwolonych regionach.
• Wymuszaj spójne stosowanie tagów taksonomicznych.
• Wymagaj zasobów do wysyłania dzienników diagnostycznych do obszaru roboczego usługi Log Analytics.

Ważne jest, aby pamiętać, że wraz z wprowadzeniem usługi Azure Arc można rozszerzyć ład oparty na zasadach między różnymi dostawcami chmury, a nawet do lokalnych centrów danych.

Wszystkie dane i obiekty usługi Azure Policy są szyfrowane w spoczynku. Aby uzyskać więcej informacji, zobacz Szyfrowanie danych platformy Azure w stanie spoczynku.

Overview

Usługa Azure Policy ocenia zasoby i akcje na platformie Azure, porównując właściwości tych zasobów z regułami biznesowymi. Te reguły biznesowe, opisane w formacie JSON, są nazywane definicjami zasad. Aby uprościć zarządzanie, można grupować kilka reguł biznesowych w celu utworzenia inicjatywy polityki, zwanej także zbiorem zasad.

Po utworzeniu reguł biznesowych definicja zasad lub inicjatywa jest przypisywana do dowolnego zakresu zasobów, które obsługuje platforma Azure. Na przykład grupy zarządzania, subskrypcje, grupy zasobów lub poszczególne zasoby. Przypisanie dotyczy wszystkich zasobów w zakresie usługi Resource Manager danego zadania. W razie potrzeby można wykluczyć podzakresy. Aby uzyskać więcej informacji, zobacz Zakres w usłudze Azure Policy.

Usługa Azure Policy używa formatu JSON do utworzenia logiki używanej przez ocenę w celu określenia, czy zasób jest zgodny, czy nie. Definicje obejmują metadane i regułę zasad. Zdefiniowana reguła może używać funkcji, parametrów, operatorów logicznych, warunków i aliasów właściwości, aby dokładnie dopasować się do żądanego scenariusza. Reguła polityki określa, które zasoby w ramach przypisania podlegają ocenie.

Omówienie wyników oceny

Zasoby są oceniane w określonych momentach w cyklu życia zasobów, cyklu życia przypisania zasad oraz podczas regularnej i bieżącej oceny zgodności. Poniżej przedstawiono czasy lub zdarzenia, które powodują ocenę zasobu:

• Zasób jest tworzony lub aktualizowany w zakresie z przypisaniem polityki.
• Zakres otrzymuje nowe przypisanie polityki lub inicjatywy.
• Zaktualizowano zasady lub inicjatywę przypisaną do zakresu.
• Standardowy cykl oceny zgodności, który występuje co 24 godziny.

Aby uzyskać szczegółowe informacje na temat tego, kiedy i jak odbywa się ocena zasad, zobacz Wyzwalacze oceny.

Kontrolowanie odpowiedzi na ocenę

Reguły biznesowe do obsługi niezgodnych zasobów różnią się znacznie między organizacjami. Przykłady sposobu, w jaki organizacja chce, aby platforma odpowiadała na niezgodny zasób:

• Odmów zmiany zasobu.
• Zarejestruj zmianę zasobu.
• Zmień zasób przed zmianą.
• Zmień zasób po zmianie.
• Wdróż powiązane zasoby spełniające normy.
• Blokuj akcje dotyczące zasobów.

Usługa Azure Policy sprawia, że każda z tych odpowiedzi biznesowych jest możliwa dzięki zastosowaniu efektów. Efekty są ustawiane w części reguły zasaddefinicji zasad.

Korygowanie niezgodnych zasobów

Chociaż te efekty mają wpływ głównie na zasób podczas tworzenia lub aktualizowania zasobu, usługa Azure Policy obsługuje również obsługę istniejących niezgodnych zasobów bez konieczności zmiany tego zasobu. Aby uzyskać więcej informacji na temat zapewniania zgodności istniejących zasobów, zobacz Korygowanie niezgodnych zasobów za pomocą usługi Azure Policy.

Wprowadzenie

Azure Policy i Azure RBAC

Istnieje kilka kluczowych różnic między usługą Azure Policy i kontrolą dostępu opartą na rolach platformy Azure (Azure RBAC). Usługa Azure Policy ocenia stan, sprawdzając właściwości zasobów reprezentowanych w usłudze Resource Manager i właściwości niektórych dostawców zasobów. Usługa Azure Policy zapewnia, że stan zasobu jest zgodny z regułami biznesowymi bez obaw o to, kto wprowadził zmianę lub kto ma uprawnienia do wprowadzenia zmiany. Usługa Azure Policy za pomocą efektu DenyAction może również blokować niektóre akcje dotyczące zasobów. Niektóre zasoby usługi Azure Policy, takie jak definicje zasad, definicje inicjatyw i przypisania, są widoczne dla wszystkich użytkowników. Ten design umożliwia przezroczystość wszystkim użytkownikom i usługom w zakresie ustawionych zasad polityki w ich środowisku.

Azure RBAC koncentruje się na zarządzaniu działaniami użytkowników na różnych poziomach. Jeśli kontrola akcji jest wymagana na podstawie informacji o użytkowniku, kontrola RBAC platformy Azure jest właściwym narzędziem do użycia. Nawet jeśli dana osoba ma dostęp do wykonania akcji, jeśli wynik jest niezgodnym zasobem, usługa Azure Policy nadal blokuje tworzenie lub aktualizowanie.

Połączenie mechanizmu RBAC i usługi Azure Policy zapewnia pełny zakres kontroli w Azure.

Uprawnienia Azure RBAC w Azure Policy

Usługa Azure Policy ma kilka uprawnień, znanych jako operacje, w dwóch dostawcach zasobów:

• Microsoft.Authorization
• Microsoft.PolicyInsights

Wiele wbudowanych ról udziela uprawnień do zasobów usługi Azure Policy. Rola Współautor zasad zasobów obejmuje większość operacji usługi Azure Policy. Właściciel ma pełne prawa. Zarówno współautor , jak i czytelnik mają dostęp do wszystkich operacji odczytu usługi Azure Policy.

Współautor może wyzwolić korygowanie zasobów, ale nie może tworzyć ani aktualizować definicji i przypisań. Administrator dostępu użytkowników jest niezbędny do udzielenia tożsamości zarządzanej lub deployIfNotExistsmodify przypisań niezbędnych uprawnień.

Jeśli żadna z wbudowanych ról nie ma wymaganych uprawnień, utwórz rolę niestandardową.

Operacje usługi Azure Policy mogą mieć znaczący wpływ na środowisko platformy Azure. Przypisz tylko minimalny zestaw uprawnień niezbędnych do wykonania zadania i przyznaj je tylko użytkownikom, którzy potrzebują uprawnień.

Specjalne wymaganie dotyczące uprawnień usługi Azure Policy z usługą Azure Virtual Network Manager

Usługa Azure Virtual Network Manager (wersja zapoznawcza) umożliwia stosowanie spójnych zasad zarządzania i zabezpieczeń do wielu sieci wirtualnych platformy Azure w całej infrastrukturze chmury. Grupy dynamiczne programu Azure Virtual Network Manager (AVNM) używają definicji usługi Azure Policy do oceny członkostwa w sieci wirtualnej w tych grupach.

Aby utworzyć, edytować lub usunąć dynamiczne zasady grupy usługi Azure Virtual Network Manager, potrzebne są następujące elementy:

• Odczyt i zapis uprawnień RBAC platformy Azure do podległej polityki
• Uprawnienia RBAC platformy Azure do dołączenia do grupy sieciowej. Autoryzacja administratora klasycznego nie jest obsługiwana.

Wymagane uprawnienie dostawcy zasobów to Microsoft.Network/networkManagers/networkGroups/join/action.

Zasoby objęte usługą Azure Policy

Mimo że zasady można przypisać na poziomie grupy zarządzania, oceniane są tylko zasoby na poziomie subskrypcji lub grupy zasobów.

W przypadku niektórych dostawców zasobów, takich jak konfiguracja maszyny, usługa Azure Kubernetes Service i usługa Azure Key Vault, istnieje głębsza integracja zarządzania ustawieniami i obiektami. Aby dowiedzieć się więcej, przejdź do obszaru Tryby dostawcy zasobów.

Zalecenia dotyczące zarządzania zasadami

Oto kilka wskazówek i wskazówek, które należy wziąć pod uwagę:

• Zacznij od efektu audit lub auditIfNotExists zamiast efektu wymuszania (deny, modify, deployIfNotExists), aby śledzić, jak definicja polityki wpływa na zasoby w środowisku. Jeśli masz już skrypty umożliwiające automatyczne skalowanie aplikacji, ustawienie efektu wymuszania może utrudnić wykonywanie takich zadań automatyzacji.

• Podczas tworzenia definicji i przypisań należy wziąć pod uwagę hierarchie organizacyjne. Zalecamy tworzenie definicji na wyższych poziomach, takich jak grupa zarządzania lub poziom subskrypcji. Następnie utwórz przypisanie na następnym poziomie podrzędnym. Jeśli tworzysz definicję w grupie zarządzania, przypisanie można ograniczyć do subskrypcji lub grupy zasobów w ramach tej grupy zarządzania.

• Zalecamy tworzenie i przypisywanie definicji inicjatyw, nawet jeśli zaczyna się od jednej definicji zasad. Ta metoda umożliwia dodawanie definicji zasad polityki do inicjatywy w późniejszym czasie, bez zwiększania liczby przypisań, którymi trzeba zarządzać.

  • Załóżmy na przykład, że utworzysz definicję polityki policyDefA i dodasz ją do definicji inicjatywy initiativeDefC. Jeśli później utworzysz kolejną definicję polityki policyDefB z celami podobnymi do policyDefA, możesz dodać go do initiativeDefC i śledzić je razem.

  • Po utworzeniu przypisania inicjatywy definicje zasad dodane do inicjatywy również stają się częścią przypisań tej inicjatywy.

  • Po ocenie przypisania inicjatywy zostaną również ocenione wszystkie zasady w ramach inicjatywy. Jeśli musisz ocenić zasady indywidualnie, lepiej nie uwzględniać ich w inicjatywie.

• Zarządzaj zasobami Azure Policy jako kod, wykonując ręczne przeglądy zmian w definicjach zasad, inicjatywach i przypisaniach. Aby dowiedzieć się więcej na temat sugerowanych wzorców i narzędzi, zobacz Projektowanie usługi Azure Policy jako przepływów pracy kodu.

Obiekty usługi Azure Policy

Obiekty obejmują definicje zasad polityki, definicje inicjatyw i przypisania.

Definicja zasad

Proces tworzenia i implementowania zasad w usłudze Azure Policy rozpoczyna się po utworzeniu definicji zasad. Każda definicja zasad ma warunki, które są wymuszane. I ma zdefiniowany efekt, który ma miejsce, jeśli warunki są spełnione.

W usłudze Azure Policy oferujemy kilka wbudowanych zasad, które są domyślnie dostępne. Przykład:

• Dozwolone SKU konta magazynowego (Odmowa): Określa, czy wdrażane konto magazynowe należy do dopuszczalnych rozmiarów jednostek SKU. Jej efektem jest odmowa wszystkich kont magazynu, które nie są zgodne z zestawem zdefiniowanych rozmiarów jednostek SKU.
• Dozwolony typ zasobu (odmowa): definiuje typy zasobów, które można wdrożyć. Jej efektem jest odrzucanie wszystkich zasobów, które nie są częścią tej zdefiniowanej listy.
• Dozwolone lokalizacje (odmów): ogranicza dostępne lokalizacje dla nowych zasobów. Jej efekt jest używany do wymuszania wymagań dotyczących zgodności geograficznej.
• Dozwolone jednostki SKU maszyny wirtualnej (odmowa): określa zestaw jednostek SKU maszyny wirtualnej, które można wdrożyć.
• Dodaj tag do zasobów (Modyfikuj): stosuje wymagany tag i jego wartość domyślną, jeśli żądanie wdrożenia nie określi go.
• Niedozwolone typy zasobów (Odmów): uniemożliwia wdrażanie listy typów zasobów.

Aby zaimplementować te definicje zasad (zarówno wbudowane, jak i niestandardowe), należy je przypisać. Dowolne z tych zasad można przypisać za pomocą witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

Ocena polityk odbywa się przy użyciu kilku różnych czynności, takich jak przypisanie polityk lub aktualizacje polityk. Aby uzyskać pełną listę, zobacz Wyzwalacze oceny polityki.

Aby dowiedzieć się więcej o strukturach definicji zasad, zobacz Podstawy struktury definicji usługi Azure Policy.

Parametry zasad ułatwiają zarządzanie zasadami, zmniejszając liczbę definicji zasad, które należy utworzyć. Parametry można zdefiniować podczas tworzenia definicji zasad, aby uczynić ją bardziej ogólną. Następnie możesz ponownie użyć tej definicji zasad w różnych scenariuszach. W tym celu należy przekazać różne wartości podczas przypisywania definicji zasad. Na przykład określenie jednego zestawu lokalizacji dla subskrypcji.

Parametry są definiowane podczas tworzenia definicji zasad. Definicja parametru zawiera nazwę parametru i wartości opcjonalne. Można na przykład zdefiniować parametr dla zasad o nazwie lokalizacja. Następnie możesz nadać mu różne wartości, takie jak EastUS lub WestUS podczas przypisywania zasad.

Aby uzyskać więcej informacji na temat parametrów zasad, zobacz Parametry struktury definicji usługi Azure Policy.

Definicja inicjatywy

Definicja inicjatywy to zbiór definicji zasad dostosowanych do osiągnięcia pojedynczego nadrzędnego celu. Definicje inicjatyw upraszczają zarządzanie definicjami zasad i przypisywanie ich. Upraszczają one grupowanie zestawu zasad jako jednego elementu. Można na przykład utworzyć inicjatywę zatytułowaną Enable Monitoring in Microsoft Defender for Cloud (Włączanie monitorowania w usłudze Microsoft Defender for Cloud), której celem jest monitorowanie wszystkich dostępnych zaleceń dotyczących zabezpieczeń w wystąpieniu usługi Microsoft Defender for Cloud.

W ramach tej inicjatywy będziesz mieć definicje zasad, takie jak:

• Monitorowanie niezaszyfrowanej bazy danych SQL Database w usłudze Microsoft Defender for Cloud — monitorowanie niezaszyfrowanych baz danych SQL i serwerów.
• Monitorowanie luk w zabezpieczeniach systemu operacyjnego w usłudze Microsoft Defender for Cloud — w celu monitorowania serwerów, które nie spełniają skonfigurowanego punktu odniesienia.
• Monitorowanie braku programu Endpoint Protection w usłudze Microsoft Defender for Cloud — w celu monitorowania serwerów bez zainstalowanego agenta ochrony punktu końcowego.

Podobnie jak parametry zasad, parametry inicjatywy ułatwiają zarządzanie inicjatywami, zmniejszając nadmiarowość. Parametry inicjatywy to parametry używane przez definicje zasad w ramach inicjatywy.

Na przykład w poniższym scenariuszu masz definicję inicjatywy inicjatywaC z definicjami zasad zasadaA i zasadaB gdzie każda oczekuje innego typu parametru.

Podczas definiowania parametrów inicjatywy dla initiativeC dostępne są trzy opcje:

• Użyj parametrów definicji zasad w ramach tej inicjatywy: w tym przykładzie allowedLocations i allowedSingleLocation zostań parametrami inicjatywy initiativeC.
• Podaj wartości parametrów definicji zasad w ramach tej definicji inicjatywy. W tym przykładzie można podać listę lokalizacji do parametru policyA oraz allowedLocations. Możesz również podać wartości podczas przypisywania tej inicjatywy.
• Podaj listę opcji wartości , które mogą być używane podczas przypisywania tej inicjatywy. Po przypisaniu tej inicjatywy odziedziczone parametry z definicji zasad w ramach inicjatywy mogą zawierać tylko wartości z tej udostępnionej listy.

Podczas tworzenia opcji wartości w definicji inicjatywy nie można wprowadzić innej wartości podczas przypisywania inicjatywy, ponieważ nie jest ona częścią listy.

Aby dowiedzieć się więcej na temat struktur definicji inicjatyw, zapoznaj się ze strukturą definicji inicjatywy usługi Azure Policy.

Assignments

Przypisanie to definicja zasad lub inicjatywa przypisana do określonego zakresu. Ten zakres może obejmować od grupy zarządzania do pojedynczego zasobu. Termin zakres odnosi się do wszystkich zasobów, grup zasobów, subskrypcji lub grup zarządzania przypisanych do definicji. Wszystkie zasoby podrzędne dziedziczą przypisania. Ten projekt oznacza, że definicja zastosowana do grupy zasobów jest również stosowana do zasobów w tej grupie zasobów. Można jednak wykluczyć podzakres z przypisania.

Na przykład w zakresie subskrypcji można przypisać definicję, która uniemożliwia tworzenie zasobów sieciowych. Możesz wykluczyć grupę zasobów w tej subskrypcji, która jest przeznaczona dla infrastruktury sieciowej. Następnie przyznasz dostęp do tej grupy zasobów sieciowych użytkownikom, którym ufasz podczas tworzenia zasobów sieciowych.

W innym przykładzie możesz przypisać definicję listy dozwolonych typów zasobów na poziomie grupy zarządzania. Następnie przypiszesz bardziej permissywne zasady (zezwalając na więcej typów zasobów) w podrzędnej grupie zarządzania, a nawet bezpośrednio w subskrypcjach. Jednak ten przykład nie zadziała, ponieważ usługa Azure Policy jest jawnym systemem odmowy. Zamiast tego należy wykluczyć podrzędną grupę zarządzania lub subskrypcję z przypisania na poziomie grupy zarządzania. Następnie przypisz bardziej permissywną definicję na poziomie podrzędnej grupy zarządzania lub subskrypcji. Jeśli jakiekolwiek przypisanie skutkuje odmową dostępu do zasobu, jedynym sposobem na umożliwienie dostępu do zasobu jest zmodyfikowanie przypisania, które powoduje odmowę.

Przypisania zasad zawsze używają najnowszego stanu przypisanej definicji lub inicjatywy przy ocenie zasobów. Jeśli przypisana definicja zasad zostanie zmieniona, wszystkie istniejące przypisania tej definicji używają zaktualizowanej logiki podczas oceniania.

Aby uzyskać więcej informacji na temat ustawiania przypisań za pośrednictwem portalu, zobacz Tworzenie przypisania zasad w celu identyfikowania niezgodnych zasobów w środowisku platformy Azure. Dostępne są również kroki dla programu PowerShell i interfejsu wiersza polecenia platformy Azure . Aby uzyskać informacje na temat struktury przypisania, zobacz Struktura przypisywania polityki Azure Policy.

Maksymalna liczba obiektów usługi Azure Policy

Istnieje maksymalna liczba dla każdego typu obiektu dla usługi Azure Policy. W przypadku definicji wpis Zakres oznacza grupę zarządzania lub subskrypcję. W przypadku przypisań i wykluczeń wpis Zakres oznacza grupę zarządzania, subskrypcję, grupę zasobów lub pojedynczy zasób.

Reguły zasad mają więcej ograniczeń dotyczących liczby warunków i ich złożoności. Aby uzyskać więcej informacji, zobacz Limity reguł.

Dalsze kroki

Teraz, gdy masz już omówienie usługi Azure Policy i niektóre z kluczowych pojęć, skorzystaj z poniższych linków, aby dowiedzieć się więcej o usłudze.

• Słownik usługi Azure Policy.
• Podstawy struktury definicji usługi Azure Policy.
• Szybki start: tworzenie przypisania zasad w celu zidentyfikowania niezgodnych zasobów przy użyciu witryny Azure Portal.