Co to jest usługa Azure Policy?

Usługa Azure Policy pomaga wymuszać standardy organizacyjne i oceniać zgodność na dużą skalę. Za pośrednictwem pulpitu nawigacyjnego zgodności zapewnia ona zagregowany widok do oceny ogólnego stanu środowiska z możliwością przechodzenia do szczegółów według zasobu i szczegółowości per-policy. Pomaga również zapewnić zgodność zasobów przez zbiorcze korygowanie istniejących zasobów i automatyczne korygowanie nowych zasobów.

Typowe przypadki użycia dla Azure Policy obejmują implementowanie ładu w zakresie spójności zasobów, zgodności z przepisami, zabezpieczeń, kosztów i zarządzania. Definicje zasad dla tych typowych przypadków użycia są już dostępne w środowisku platformy Azure jako wbudowane, które ułatwiają rozpoczynanie pracy.

Wszystkie Azure Policy i obiekty są szyfrowane w spoczynku. Aby uzyskać więcej informacji, zobacz Szyfrowanie danych magazynowych na platformie Azure.

Omówienie

Azure Policy ocenia zasoby 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ą znane jako definicje zasad. Aby uprościć zarządzanie, można zgrupować razem kilka reguł biznesowych w celu postaci inicjatywy zasad (czasami nazywanej zasadąUstawienia). Po zdefiniowaniu reguł biznesowych definicja zasad lub inicjatywa są przypisywane do dowolnego zakresu zasobów, które obsługuje platforma Azure, takich jak grupy zarządzania, subskrypcje,grupy zasobów lub poszczególne zasoby. Przypisanie dotyczy wszystkich zasobów w Resource Manager zakresu tego przypisania. W razie potrzeby można wykluczyć zakresy podrzędne. Aby uzyskać więcej informacji, zobacz Zakres w Azure Policy.

Azure Policy format JSON jest używany do określania, czy zasób jest zgodny, czy nie, logiki używanej w ocenie. 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 dopasować je dokładnie do określonego scenariusza. Reguła zasad określa, które zasoby w zakresie przypisania są oceniane.

Understand evaluation outcomes (Opis wyników oceny)

Zasoby są oceniane w określonych momentach w cyklu życia zasobu, cyklu życia przypisania zasad i regularnej ciągłej oceny zgodności. Poniżej przedstawiono czas lub zdarzenia, które powodują ocenę zasobu:

  • Zasób jest tworzony, aktualizowany lub usuwany w zakresie za pomocą przypisania zasad.
  • Zasady lub inicjatywa są nowo przypisywane do zakresu.
  • Zasady lub inicjatywa już przypisana do zakresu zostaną zaktualizowane.
  • W trakcie standardowego cyklu oceny zgodności, który odbywa się 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 dotyczące obsługi niezgodnych zasobów różnią się w zależności od organizacji. Przykłady sposobu, w jaki organizacja chce, aby platforma odpowiadała na niezgodny zasób:

  • Odmowa zmiany zasobu
  • Rejestrowanie zmiany w zasobie
  • Zmienianie zasobu przed zmianą
  • Zmienianie zasobu po zmianie
  • Wdrażanie powiązanych zgodnych zasobów

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

Korygowanie niezgodnych zasobów

Chociaż te efekty wpływają głównie na zasób podczas tworzenia lub aktualizowania zasobu, Azure Policy obsługuje również obsługę istniejących niezgodnych zasobów bez konieczności zmieniania tego zasobu. Aby uzyskać więcej informacji na temat 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

Azure Policy i RBAC platformy Azure

Istnieje kilka kluczowych różnic między Azure Policy a kontrolą dostępu na podstawie ról (RBAC) platformy Azure. Azure Policy ocenia stan, sprawdzając właściwości zasobów, które są reprezentowane w Resource Manager i właściwości niektórych dostawców zasobów. Azure Policy nie ogranicza akcji (nazywanych również operacjami). Azure Policy, że stan zasobu jest zgodny z regułami biznesowymi bez obaw o to, kto dokonał zmiany lub kto ma uprawnienia do jej zmiany.

System RBAC platformy Azure koncentruje się na zarządzaniu akcjami użytkowników w różnych zakresach. Jeśli wymagana jest kontrola nad akcją, kontrola RBAC platformy Azure jest właściwym narzędziem do użycia. Nawet jeśli osoba ma dostęp do wykonania akcji, jeśli wynik jest niezgodnym zasobem, Azure Policy nadal blokuje tworzenie lub aktualizowanie.

Kombinacja kontroli RBAC platformy Azure i 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ń zasobom usługi Azure Policy. Rola Współautor zasad zasobów obejmuje większość Azure Policy zasobów. Właściciel ma pełne uprawnienia. Zarówno współautor, jak i czytelnik mają dostęp do wszystkich operacji odczytu Azure Policy odczytu. Współautor może wyzwalać korygowanie zasobów, ale nie może tworzyć definicji ani przypisań. Administrator dostępu użytkowników jest niezbędny do udzielenia tożsamości zarządzanej na stronie deployIfNotExists lub zmodyfikowania przypisań niezbędnych uprawnień.

Jeśli żadna z wbudowanych ról nie ma wymaganych uprawnień, należy utworzyć rolę niestandardową.

Uwaga

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

Zasoby objęte Azure Policy

Azure Policy ocenia wszystkie zasoby platformy Azure na poziomie subskrypcji lub poniżej, w tym zasoby z obsługą usługi Arc. W przypadku niektórych dostawców zasobów,takich jak konfiguracja gościa ,Azure Kubernetes Service i Azure Key Vault, istnieje bardziej głęboka integracja na temat zarządzania ustawieniami i obiektami. Aby dowiedzieć się więcej, zobacz Tryby dostawcy zasobów.

Zalecenia dotyczące zarządzania zasadami

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

  • Rozpocznij od efektu inspekcji zamiast efektu odrzucenia, aby śledzić wpływ definicji zasad na zasoby w Twoim środowisku. Jeśli masz już skrypty umożliwiające automatyczne skalowanie swoich aplikacji, skonfigurowanie efektu odrzucenia może negatywnie wpłynąć na zdefiniowane wcześniej zadania 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.

  • Firma Microsoft zaleca tworzenie i przypisywanie definicji inicjatyw, nawet w przypadku pojedynczych definicji zasad. Na przykład możesz mieć definicję zasad policyDefA utworzoną w ramach definicji inicjatywy initiativeDefC. Jeśli zdecydujesz się na utworzenie w późniejszym czasie kolejnej definicji zasad policyDefB o celach podobnych do policyDefA, możesz dodać ją do definicji 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.

Azure Policy obiektów

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 (odmowa): określa, czy wdrażane konto magazynu należy do zestawu rozmiarów jednostki 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 jednostki SKU maszyn wirtualnych, 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ślony przez żądanie wdrożenia.
  • Niedozwolone typy zasobów (Odmów): uniemożliwia wdrażanie listy typów zasobów.

Aby móc zaimplementować te definicje zasad (wbudowane i niestandardowe), musisz 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, które są dostosowane do osiągnięcia jednego 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ę o nazwie Włączanie monitorowania w Azure Security Center, której celem jest monitorowanie wszystkich dostępnych zaleceń dotyczących zabezpieczeń w Azure Security Center.

Uwaga

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

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

  • Monitorowanie niezaszyfrowanych SQL Database w Security Center — do monitorowania niezaszyfrowanych baz danych i serwerów SQL.
  • Monitorowanie luk w zabezpieczeniach systemu operacyjnego Security Center — do monitorowania serwerów, które nie spełniają skonfigurowanego planu bazowego.
  • Monitorowanie braku programu Endpoint Protection Security Center — do monitorowania serwerów bez zainstalowanego agenta programu Endpoint Protection.

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 array Ten parametr oczekuje listy ciągów dla wartości, ponieważ typ parametru został zdefiniowany jako tablica
policyB allowedSingleLocation ciąg 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 zasadAallowedLocations i policyB parametru - 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 na temat struktur definicji inicjatyw, zapoznaj się ze strukturą definicji inicjatywy.

Przypisania

Przypisanie to definicja zasad lub inicjatywa, która została przypisana do określonego zakresu. Zakresem może być od grupy zarządzania do pojedynczego zasobu. Termin zakres odnosi się do wszystkich zasobów, grup zasobów, subskrypcji lub grup zarządzania, do których przypisano definicję. 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ć zakres podrzędny 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żna przypisać definicję listy zezwalania typu zasobu na poziomie grupy zarządzania. Następnie przypisujesz bardziej permisywne zasady (zezwalające 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ż Azure Policy to system jawnej odmowy. Zamiast tego należy wykluczyć podrzędną grupę zarządzania lub subskrypcję z przypisania na poziomie grupy zarządzania. Następnie przypisz bardziej permisywną definicję na poziomie podrzędnej grupy zarządzania lub subskrypcji. Jeśli jakiekolwiek przypisanie powoduje odmowę zasobu, jedynym sposobem, aby zezwolić na zasób, jest zmodyfikowanie przypisania odmowy.

Aby uzyskać więcej informacji na temat ustawiania przypisań za pośrednictwem portalu, zobacz Tworzenie przypisania zasad w celu zidentyfikowania 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 Assignments Structure (Struktura przypisań).

Maksymalna liczba Azure Policy obiektów

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

Lokalizacja Co Maksymalna liczba
Zakres Definicje zasad 500
Zakres Definicje inicjatyw 200
Dzierżawa Definicje inicjatyw 2500
Zakres Przypisania zasad lub inicjatyw 200
Zakres Zwolnienia 1000
Definicja zasad Parametry 20
Definicja inicjatywy Zasady 1000
Definicja inicjatywy Parametry 250
Przypisania zasad lub inicjatyw Wykluczenia (notScopes) 400
Reguła zasad Zagnieżdżone instrukcje warunkowe 512
Zadanie korygowania Zasoby 500

Następne kroki

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