Udostępnij za pośrednictwem

Co to jest usługa Azure Policy?

  • Artykuł

Usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Za pośrednictwem pulpitu nawigacyjnego zgodności udostępnia zagregowany widok umożliwiający ocenę ogólnego stanu środowiska, z możliwością przechodzenia do szczegółów poszczególnych zasobów i zasad. Pomaga również zapewnić zgodność zasobów dzięki korygowaniu zbiorczemu istniejących zasobów i automatycznemu korygowaniu nowych zasobów.

Uwaga

Aby uzyskać więcej informacji na temat korygowania, zobacz Korygowanie niezgodnych zasobów za pomocą usługi Azure Policy.

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.

W szczególności niektóre przydatne akcje ładu, które można wymusić za pomocą usługi Azure Policy, obejmują:

  • Zapewnianie, że zespół wdraża zasoby platformy Azure tylko w dozwolonych regionach
  • Wymuszanie spójnego stosowania tagów taksonomicznych
  • Wymaganie od zasobów 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 Magazynowane szyfrowanie danych platformy Azure.

Omówienie

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 zgrupować kilka reguł biznesowych w celu utworzenia inicjatywy zasad (czasami nazywanej zestawem zasad). Po utworzeniu reguł biznesowych definicja zasad lub inicjatywa jest przypisywana do dowolnego zakresu zasobów, które pomoc techniczna platformy Azure, takich jak grupy zarządzania, subskrypcje, grupy zasobów lub poszczególne zasoby. Przypisanie dotyczy wszystkich zasobów w zakresie usługi Resource Manager tego przypisania. 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 w celu dopasowania dokładnie do żądanego scenariusza. Reguła zasad określa, które zasoby w zakresie przypisania są oceniane.

Omówienie wyników oceny

Zasoby są oceniane w określonych momentach w cyklu życia zasobów, cyklu życia przypisania zasad i regularnej 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 zasad.
  • Zasady lub inicjatywa jest nowo przypisana do zakresu.
  • Zaktualizowano zasady lub inicjatywę przypisaną do zakresu.
  • Podczas standardowego cyklu 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:

  • Odmowa zmiany zasobu
  • Rejestrowanie zmiany zasobu
  • Zmienianie zasobu przed zmianą
  • Zmiana zasobu po zmianie
  • Wdrażanie powiązanych zgodnych zasobów
  • Blokowanie akcji dotyczących 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 zasad definicji 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 zasobów.

Omówienie wideo

Poniższe omówienie usługi Azure Policy dotyczy kompilacji 2018. Aby pobrać slajdy lub klip wideo, odwiedź stronę Govern your Azure environment through Azure Policy (Zarządzanie środowiskiem platformy Azure przy użyciu usługi Azure Policy) w witrynie Channel 9.

Wprowadzenie

Usługa Azure Policy i kontrola dostępu oparta na rolach platformy Azure

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 projekt umożliwia przezroczystość wszystkim użytkownikom i usługom dotyczącymi reguł zasad ustawionych w ich środowisku.

Kontrola dostępu oparta na rolach platformy Azure koncentruje się na zarządzaniu akcjami użytkowników w różnych zakresach. 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 kontroli dostępu opartej na rolach platformy Azure i usługi Azure Policy zapewnia pełną kontrolę zakresu na platformie Azure.

Uprawnienia RBAC platformy Azure w usłudze Azure Policy

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

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 uprawnienia. 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 we wdrożeniuIfNotExists lub zmodyfikowaniu przypisań niezbędnych uprawnień.

Uwaga

Wszystkie obiekty zasad, w tym definicje, inicjatywy i przypisania, będą czytelne dla wszystkich ról w zakresie. Na przykład przypisanie zasad w zakresie subskrypcji platformy Azure będzie możliwe do odczytu przez wszystkich posiadaczy ról w zakresie subskrypcji i poniżej.

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. Należy przypisać tylko minimalny zestaw uprawnień niezbędnych do wykonania zadania, a te uprawnienia nie powinny być przyznawane użytkownikom, którzy ich nie potrzebują.

Uwaga

Tożsamość zarządzana wdrożeniaIfNotExists lub modyfikowanie przypisania zasad wymaga wystarczających uprawnień do tworzenia lub aktualizowania zasobów docelowych. Aby uzyskać więcej informacji, zobacz Konfigurowanie definicji zasad na potrzeby korygowania.

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 podstawowych zasad
  • Uprawnienia RBAC platformy Azure do dołączenia do grupy sieciowej (autoryzacja klasycznego administratora nie jest obsługiwana).

W szczególności wymagane uprawnienie dostawcy zasobów to Microsoft.Network/networkManagers/networkGroups/join/action.

Ważne

Aby zmodyfikować grupy dynamiczne AVNM, należy udzielić dostępu tylko za pośrednictwem przypisania roli RBAC platformy Azure. Autoryzacja administratora klasycznego/starszej wersji nie jest obsługiwana; Oznacza to, że jeśli twoje konto zostało przypisane tylko do roli subskrypcji współadministratora, nie masz uprawnień do grup dynamicznych AVNM.

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

Poniżej przedstawiono kilka wskazówek i porad, które warto uwzględnić:

  • audit Zacznij od efektu lub auditIfNotExist zamiast wymuszania (deny, modify, deployIfNotExist), aby śledzić wpływ definicji zasad na zasoby w środowisku. Jeśli masz już skrypty umożliwiające automatyczne skalowanie aplikacji, ustawienie efektu wymuszania może utrudniać wykonywanie takich zadań automatyzacji.

  • Podczas tworzenia definicji i przypisań należy zwrócić uwagę na hierarchie organizacyjne. Firma Microsoft zaleca tworzenie definicji wyższym poziomie, takim jak poziom grupy zarządzania lub subskrypcji. Następnie utwórz przypisanie na następnym poziomie podrzędnym. Jeśli utworzysz definicję na poziomie grupy zarządzania, można ograniczyć zakres przypisania do subskrypcji lub grupy zasobów w tej grupie zarządzania.

  • Zalecamy tworzenie i przypisywanie definicji inicjatyw, nawet jeśli zaczyna się od jednej definicji zasad. Dzięki temu można dodawać definicje zasad do inicjatywy później bez zwiększania liczby przypisań do zarządzania.

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

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

    • Podczas oceny przypisania inicjatywy oceniane są również wszystkie zasady w ramach tej inicjatywy. Jeśli konieczne jest indywidualne ocenianie zasad, lepszym rozwiązaniem jest nieuwzględnianie ich w inicjatywie.

  • Zarządzanie zasobami usługi Azure Policy jako kodem przy użyciu ręcznych przeglądów zmian definicji zasad, inicjatyw i przypisań. 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

Definicja zasad

Proces tworzenia i implementowania zasad w usłudze Azure Policy rozpoczyna się od utworzenia definicji zasad. Każda definicja zasad zawiera warunki, w jakich zasady są wymuszane. Zawiera także zdefiniowany efekt, który występuje w przypadku spełnienia warunków.

Usługa Azure Policy oferuje kilka wbudowanych zasad, które są domyślnie dostępne. Na przykład:

  • Dozwolone jednostki SKU konta magazynu (odmów): określa, czy wdrażane konto magazynu znajduje się w zestawie rozmiarów jednostek SKU. Jej efektem jest odrzucanie wszystkich kont magazynu, które nie są zgodne z zestawem zdefiniowanych rozmiarów 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 należą do 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 obszarów geograficznych.
  • 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 nie jest określona przez żądanie wdrożenia.
  • 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ć. Dowolną z tych zasad można przypisać za pośrednictwem witryny Azure Portal, programu PowerShell lub interfejsu wiersza polecenia platformy Azure.

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

Aby dowiedzieć się więcej o strukturach definicji zasad, zapoznaj się z tematem Policy Definition Structure (Struktura definicji zasad).

Parametry zasad ułatwiają zarządzanie zasadami przez redukowanie liczby definicji zasad, które należy utworzyć. Podczas tworzenia definicji zasad można zdefiniować parametry, które czynią je bardziej ogólnymi. Następnie można użyć tej definicji zasad ponownie w różnych scenariuszach. Polega to na przekazaniu innych wartości podczas przypisywania definicji zasad. Można na przykład określić jeden zestaw lokalizacji dla subskrypcji.

Parametry są definiowane podczas tworzenia definicji zasad. Jeśli parametr jest zdefiniowany, otrzymuje nazwę i opcjonalnie wartość. Na przykład można zdefiniować parametr dla zasad o nazwie location. Następnie podczas przypisywania zasad można przydzielić mu różne wartości, takie jak EastUS i WestUS.

Dodatkowe informacje na temat parametrów zasad zamieszczono w artykule Struktura definicji — parametry.

Definicja inicjatywy

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

Uwaga

Zestaw SDK, taki jak interfejs wiersza polecenia platformy Azure i program Azure PowerShell, użyj właściwości i parametrów o nazwie PolicySet , aby odwołać się do inicjatyw.

W ramach tej inicjatywy mogą występować definicje zasad, takie jak:

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

Podobnie jak parametry zasad, parametry inicjatywy upraszczają zarządzanie inicjatywą przez ograniczenie nadmiarowości. Parametry inicjatywy to parametry używane przez definicje zasad w ramach tej inicjatywy.

Na przykład masz definicję inicjatywy initiativeC oraz definicje zasad policyA i policyB. Każda z nich oczekuje innego typu parametru:

Zasady Nazwa parametru Typ parametru Uwaga
policyA allowedLocations tablica Ten parametr oczekuje listy ciągów dla wartości, ponieważ typ parametru został zdefiniowany jako tablica
policyB allowedSingleLocation string Ten parametr oczekuje jednego słowa dla wartości, ponieważ typ parametru został zdefiniowany jako ciąg

W tym scenariuszu podczas definiowania parametrów inicjatywy initiativeC dostępne są trzy opcje:

  • Użycie parametrów definicji zasad w ramach tej inicjatywy: w tym przykładzie allowedLocations i allowedSingleLocation stają się parametrami inicjatywy dla initiativeC.
  • Przekaż wartości parametrom definicji zasad w ramach tej definicji inicjatywy. W tym przykładzie można podać listę lokalizacji parametru policyA — allowedLocations i parametru policyB — allowedSingleLocation. Wartości można przekazać również podczas przypisywania tej inicjatywy.
  • Podaj listę opcji value, które mogą być używane podczas przypisywania tej inicjatywy. Podczas przypisywania tej inicjatywy odziedziczone parametry z definicji zasad w ramach tej inicjatywy mogą zawierać jedynie wartości z tej dostarczonej listy.

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

Aby dowiedzieć się więcej o strukturach definicji inicjatyw, zapoznaj się z tematem Initiative Definition Structure (Struktura definicji inicjatywy).

Przypisania

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. Przypisania są dziedziczone przez wszystkie zasoby podrzędne. 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żna wyłączyć grupę zasobów w ramach subskrypcji, która jest przeznaczona dla infrastruktury sieciowej. Następnie dostęp do tej grupy zasobów sieciowych można przyznać użytkownikom, którym powierzono tworzenie 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 spowoduje odmowę zasobu, jedynym sposobem zezwolenia na zasób jest zmodyfikowanie przypisania odmowy.

Przypisania zasad zawsze używają najnowszego stanu przypisanej definicji lub inicjatywy podczas oceniania zasobów. Jeśli definicja zasad, która jest już przypisana, zostanie zmieniona, wszystkie istniejące przypisania tej definicji będą używać zaktualizowanej logiki podczas oceny.

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ż instrukcje dotyczące korzystania z programu PowerShell i interfejsu wiersza polecenia platformy Azure. Aby uzyskać informacje na temat struktury przypisania, zobacz Struktura przypisań.

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.

Gdzie Co Maksymalna liczba
Scope Definicje zasad 500
Scope Definicje inicjatyw 200
Dzierżawa Definicje inicjatyw 2500
Scope Przypisania zasad lub inicjatywy 200
Scope Wyjątki 1000
Definicja zasad Parametry 20
Definicja inicjatywy Zasady 1000
Definicja inicjatywy Parametry 400
Przypisania zasad lub inicjatywy Wykluczenia (notScopes) 400
Reguła zasad Zagnieżdżone warunkowe 512
Zadanie korygowania Zasoby 50,000
Treść żądania definicji zasad, inicjatywy lub przypisania Bajty 1 048 576

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ł zasad, aby uzyskać więcej informacji.

Następne kroki

Teraz, gdy masz już podstawowe informacje na temat usługi Azure Policy i kluczowych pojęć, oto zalecane kolejne kroki: