Udostępnij za pośrednictwem

Samouczek: Tworzenie niestandardowej definicji zasad

  • Artykuł

Niestandardowa definicja zasad umożliwia klientom definiowanie własnych reguł dotyczących korzystania z platformy Azure. Te reguły często wymuszają:

  • Rozwiązania z zakresu bezpieczeństwa
  • Zarządzanie kosztami
  • Reguły specyficzne dla organizacji (np. dotyczące nazewnictwa lub lokalizacji)

Niezależnie od potrzeb biznesowych wymagających utworzenia zasad niestandardowych, kroki definiowania nowych zasad niestandardowych są takie same.

Przed utworzeniem zasad niestandardowych zapoznaj się z przykładami zasad, aby sprawdzić, czy zasady spełniające Twoje potrzeby już istnieją.

Proces tworzenia zasad niestandardowych obejmuje następujące kroki:

  • Określanie wymagań biznesowych
  • Mapowanie każdego wymagania na właściwość zasobu platformy Azure
  • Mapowanie właściwości na alias
  • Określanie efektu do użycia
  • Tworzenie definicji zasad

Wymagania wstępne

Jeśli nie masz subskrypcji platformy Azure, przed rozpoczęciem utwórz bezpłatne konto.

Określanie wymagań

Ważne jest, aby przed utworzeniem definicji zasad poznać przeznaczenie zasad. W tym samouczku jako celu użyjemy typowego wymagania dotyczącego zabezpieczeń w przedsiębiorstwie, aby przedstawić wykonywane kroki:

  • Każde konto magazynu musi mieć włączoną obsługę protokołu HTTPS
  • Każde konto magazynu musi mieć wyłączoną obsługę protokołu HTTP

Wymagania powinny wyraźnie definiować zarówno „poprawne”, jak i „zakazane” stany zasobów.

Chociaż zdefiniowaliśmy oczekiwany stan zasobu, nie zdefiniowaliśmy jeszcze, co chcemy zrobić z niezgodnymi zasobami. Usługa Azure Policy obsługuje wiele efektów. W tym samouczku zdefiniujemy wymaganie biznesowe, które zakazuje tworzenia zasobów, jeśli nie są one zgodne z regułami firmy. Aby osiągnąć ten cel, użyjemy efektu Deny (Odmów). Chcemy również mieć możliwość wstrzymania zasad dla określonych przypisań. Dlatego użyjemy efektu Disabled (Wyłączone) i określimy go jako parametr w definicji zasad.

Określanie właściwości zasobów

Zgodnie z wymaganiem biznesowym zasobem platformy Azure objętym inspekcją usługi Azure Policy jest konto magazynu. Jednak nie znamy właściwości do użycia w definicji zasad. Usługa Azure Policy ocenia reprezentację zasobu w formacie JSON, dlatego musimy zrozumieć właściwości dostępne w tym zasobie.

Istnieje wiele sposobów określania właściwości zasobu platformy Azure. Omówimy każdy z nich na potrzeby tego samouczka:

  • Rozszerzenie usługi Azure Policy dla programu VS Code
  • Szablony usługi Azure Resource Manager (szablony usługi ARM)
    • Eksportowanie istniejącego zasobu
    • Środowisko tworzenia
    • Szablony Szybki start (GitHub)
    • Dokumentacja szablonu
  • Eksplorator zasobów Azure

Wyświetlanie zasobów w rozszerzeniu programu VS Code

Przy użyciu rozszerzenia programu VS Code można przeglądać zasoby w środowisku i wyświetlać właściwości usługi Resource Manager dla każdego zasobu.

Szablony usługi ARM

Istnieje kilka sposobów przeglądania szablonu usługi ARM zawierającego właściwość, którą chcesz zarządzać.

Istniejący zasób w portalu

Najprostszym sposobem na znalezienie właściwości jest przyjrzenie się istniejącemu zasobowi tego samego typu. Zasoby już skonfigurowane za pomocą ustawienia, które ma być wymuszane, służą także do porównywania wartości. Sprawdź stronę Eksportuj szablon (w obszarze Ustawienia) w witrynie Azure Portal dla tego konkretnego zasobu.

Ostrzeżenie

Szablon arm wyeksportowany przez witrynę Azure Portal nie może być podłączony bezpośrednio do deployment właściwości szablonu usługi ARM w definicji zasad deployIfNotExists .

Zrzut ekranu przedstawiający stronę Eksportuj szablon w istniejącym zasobie w witrynie Azure Portal.

Wykonanie tego działania dla konta magazynu spowoduje wyświetlenie szablonu podobnego do następującego przykładu:

...
"resources": [{
    "comments": "Generalized from resource: '/subscriptions/{subscriptionId}/resourceGroups/myResourceGroup/providers/Microsoft.Storage/storageAccounts/mystorageaccount'.",
    "type": "Microsoft.Storage/storageAccounts",
    "sku": {
        "name": "Standard_LRS",
        "tier": "Standard"
    },
    "kind": "Storage",
    "name": "[parameters('storageAccounts_mystorageaccount_name')]",
    "apiVersion": "2018-07-01",
    "location": "westus",
    "tags": {
        "ms-resource-usage": "azure-cloud-shell"
    },
    "scale": null,
    "properties": {
        "networkAcls": {
            "bypass": "AzureServices",
            "virtualNetworkRules": [],
            "ipRules": [],
            "defaultAction": "Allow"
        },
        "supportsHttpsTrafficOnly": false,
        "encryption": {
            "services": {
                "file": {
                    "enabled": true
                },
                "blob": {
                    "enabled": true
                }
            },
            "keySource": "Microsoft.Storage"
        }
    },
    "dependsOn": []
}]
...

W obszarze properties znajduje się właściwość o nazwie supportsHttpsTrafficOnly ustawiona na wartość false. Ta właściwość prawdopodobnie jest właściwością, której szukamy. Ponadto właściwość type zasobu ma wartość Microsoft.Storage/storageAccounts. Ten typ umożliwia ograniczenie zasad do zasobów tylko tego typu.

Tworzenie zasobu w portalu

Innym sposobem użycia portalu jest środowisko tworzenia zasobu. Podczas tworzenia konta magazynu za pośrednictwem portalu na karcie Zaawansowane znajduje się pozycja Wymagany transfer zabezpieczeń. Ta właściwość ma opcje Wyłączone i Włączone. Ikona informacji zawiera dodatkowy tekst, który potwierdza, że ta opcja jest prawdopodobnie odpowiednia. Jednak portal nie podaje nazwy właściwości na tym ekranie.

W dolnej części karty Przeglądanie + tworzenie znajduje się link Pobierz szablon automatyzacji. Wybranie linku otwiera szablon, który tworzy skonfigurowany zasób. W tym przypadku są widoczne dwie kluczowe informacje:

...
"supportsHttpsTrafficOnly": {
    "type": "bool"
}
...
"properties": {
    "accessTier": "[parameters('accessTier')]",
    "supportsHttpsTrafficOnly": "[parameters('supportsHttpsTrafficOnly')]"
}
...

Te informacje określają typ właściwości i potwierdzają, że właściwość supportsHttpsTrafficOnly jest tą, której szukamy.

Szablony Szybki start w usłudze GitHub

Szablony Szybki start platformy Azure w usłudze GitHub obejmują setki szablonów usługi ARM stworzonych z myślą o różnych zasobach. Szablony te mogą być doskonałym sposobem na znalezienie szukanej właściwości zasobu. Niektóre właściwości mogą wydawać się odpowiednie, lecz kontrolują coś innego.

Dokumentacja zasobu

Aby sprawdzić poprawność właściwości supportsHttpsTrafficOnly , sprawdź dokumentację szablonu usługi ARM dla zasobu konta magazynu u dostawcy magazynu. Obiekt właściwości zawiera listę prawidłowych parametrów. Wybranie linku Obiekt StorageAccountPropertiesCreateParameters umożliwia wyświetlenie tabeli dopuszczalnych właściwości. Właściwość supportsHttpsTrafficOnly jest obecna i jej opis odpowiada naszym wymaganiom biznesowym.

Eksplorator zasobów Azure

Innym sposobem eksplorowania zasobów platformy Azure jest użycie usługi Azure Resource Explorer (wersja zapoznawcza). To narzędzie używa kontekstu subskrypcji, więc musisz uwierzytelnić się w witrynie internetowej przy użyciu poświadczeń platformy Azure. Po uwierzytelnieniu możesz przeglądać pozycje według dostawców, subskrypcji, grup zasobów i zasobów.

Znajdź zasób konta magazynu i poszukaj właściwości. Tutaj także znajduje się właściwość supportsHttpsTrafficOnly. Po wybraniu karty Dokumentacja widać, że opis właściwości pasuje do tego, co znaleźliśmy wcześniej w dokumentacji.

Znajdowanie aliasu właściwości

Zidentyfikowaliśmy właściwość zasobu, ale musimy zamapować tę właściwość na alias.

Istnieje kilka sposobów określenia aliasów dla zasobu platformy Azure. Omówimy każdy z nich na potrzeby tego samouczka:

  • Rozszerzenie usługi Azure Policy dla programu VS Code
  • Interfejs wiersza polecenia platformy Azure
  • Azure PowerShell

Uzyskiwanie aliasów w rozszerzeniu programu VS Code

Rozszerzenie usługi Azure Policy dla rozszerzenia programu VS Code ułatwia przeglądanie zasobów i odnajdywanie aliasów.

Uwaga

Rozszerzenie programu VS Code uwidacznia tylko właściwości trybu usługi Resource Manager i nie wyświetla żadnych właściwości trybu dostawcy zasobów.

Interfejs wiersza polecenia platformy Azure

W interfejsie wiersza polecenia platformy Azure polecenie az provider służy do wyszukiwania aliasów zasobu. Przefiltrujemy przestrzeń nazw Microsoft.Storage za pomocą uzyskanych wcześniej szczegółów dotyczących zasobu platformy Azure.

# Login first with az login if not using Cloud Shell

# Get Azure Policy aliases for type Microsoft.Storage
az provider show --namespace Microsoft.Storage --expand "resourceTypes/aliases" --query "resourceTypes[].aliases[].name"

W wynikach jest widoczny alias o nazwie supportsHttpsTrafficOnly obsługiwany przez konta magazynu. Istnienie tego aliasu oznacza, że możemy zapisać zasady, aby wymuszać nasze wymagania biznesowe!

Azure PowerShell

W programie Azure PowerShell polecenie cmdlet Get-AzPolicyAlias służy do wyszukiwania aliasów zasobu. Przefiltrujemy przestrzeń nazw Microsoft.Storage za pomocą uzyskanych wcześniej szczegółów dotyczących zasobu platformy Azure.

# Login first with Connect-AzAccount if not using Cloud Shell

# Use Get-AzPolicyAlias to list aliases for Microsoft.Storage
(Get-AzPolicyAlias -NamespaceMatch 'Microsoft.Storage').Aliases

Podobnie jak w przypadku interfejsu wiersza polecenia platformy Azure, w wynikach jest widoczny alias o nazwie supportsHttpsTrafficOnly obsługiwany przez konta magazynu.

Określanie efektu do użycia

Określenie, co należy zrobić z niezgodnymi zasobami, jest niemal tak ważne, jak zdecydowanie, co należy ocenić w pierwszej kolejności. Każda możliwa odpowiedź na niezgodny zasób jest nazywana efektem. Efekt kontroluje, czy niezgodny zasób jest rejestrowany, blokowany, czy są dołączane do niego dane lub czy jest z nim kojarzone wdrożenie przywracające zasób do stanu zgodności.

W naszym przykładzie odmów jest efekt, którego chcemy użyć, ponieważ nie chcemy, aby niezgodne zasoby zostały utworzone w naszym środowisku platformy Azure. Audit (Inspekcja) jest dobrym pierwszym wyborem dla efektu zasad, umożliwiając określenie wpływu zasad przed ustawieniem dla nich efektu Deny (Odmów). Jednym ze sposobów na ułatwienie modyfikowania efektu dla przypisania jest sparametryzowanie efektu. Zobacz Parametry poniżej, aby uzyskać szczegółowe informacje na ten temat.

Tworzenie definicji

Teraz mamy szczegóły i alias właściwości, którą chcemy zarządzać. Następnie utworzymy samą regułę zasad. Jeśli jeszcze nie znasz języka zasad, zapoznaj się z artykułem dotyczącym struktury definicji zasad, aby dowiedzieć się, jak określić strukturę definicji zasad. Pusty szablon z definicją zasad wygląda następująco:

{
    "properties": {
        "displayName": "<displayName>",
        "description": "<description>",
        "mode": "<mode>",
        "parameters": {
                <parameters>
        },
        "policyRule": {
            "if": {
                <rule>
            },
            "then": {
                "effect": "<effect>"
            }
        }
    }
}

Metadane

Pierwsze trzy składniki to metadane zasad. Łatwo jest podać wartości dla tych składników, ponieważ wiemy, jaki jest cel tworzenia reguły. Tryb dotyczy przede wszystkim tagów i lokalizacji zasobu. Ponieważ nie potrzebujemy ograniczać oceny do zasobów obsługujących tagi, użyjemy wartości all (wszystko) dla parametru mode (tryb).

"displayName": "Deny storage accounts not using only HTTPS",
"description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
"mode": "all",

Parametry

Mimo że nie użyliśmy parametru do zmiany oceny, chcemy użyć parametru, aby zezwolić na zmienianie efektu na potrzeby rozwiązywania problemów. Zdefiniujemy parametr effectType (typEfektu) i ograniczymy go tylko do opcji Deny (Odmów) i Disabled (Wyłączone). Te dwie opcje pasują do naszych wymagań biznesowych. Ukończony blok parametrów wygląda jak w następującym przykładzie:

"parameters": {
    "effectType": {
        "type": "string",
        "defaultValue": "Deny",
        "allowedValues": [
            "Deny",
            "Disabled"
        ],
        "metadata": {
            "displayName": "Effect",
            "description": "Enable or disable the execution of the policy"
        }
    }
},

Reguła zasad

Utworzenie reguły zasad to ostatni krok tworzenia niestandardowej definicji zasad. Określiliśmy dwa warunki do testowania:

  • Typ konta magazynu to Microsoft.Storage/storageAccounts
  • Konto magazynu obsługuje wartośćHttpsTrafficOnly nie jest prawdziwa

Ponieważ obie te instrukcje muszą być prawdziwe, użyjemy operatora logicznego allOf. Przekażemy parametr effectType (typEfektu) do efektu zamiast określania deklaracji statycznej. Ukończona reguła wygląda podobnie do następującego przykładu:

"if": {
    "allOf": [
        {
            "field": "type",
            "equals": "Microsoft.Storage/storageAccounts"
        },
        {
            "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
            "notEquals": "true"
        }
    ]
},
"then": {
    "effect": "[parameters('effectType')]"
}

Ukończona definicja

Oto kompletna definicja zawierająca wszystkie trzy części zasad:

{
    "properties": {
        "displayName": "Deny storage accounts not using only HTTPS",
        "description": "Deny storage accounts not using only HTTPS. Checks the supportsHttpsTrafficOnly property on StorageAccounts.",
        "mode": "all",
        "parameters": {
            "effectType": {
                "type": "string",
                "defaultValue": "Deny",
                "allowedValues": [
                    "Deny",
                    "Disabled"
                ],
                "metadata": {
                    "displayName": "Effect",
                    "description": "Enable or disable the execution of the policy"
                }
            }
        },
        "policyRule": {
            "if": {
                "allOf": [
                    {
                        "field": "type",
                        "equals": "Microsoft.Storage/storageAccounts"
                    },
                    {
                        "field": "Microsoft.Storage/storageAccounts/supportsHttpsTrafficOnly",
                        "notEquals": "true"
                    }
                ]
            },
            "then": {
                "effect": "[parameters('effectType')]"
            }
        }
    }
}

Ukończonej definicji można użyć do utworzenia nowych zasad. Portal i każdy z zestawów SDK (interfejsu wiersza polecenia platformy Azure, programu Azure PowerShell i interfejsu API REST) przyjmuje definicję w inny sposób, więc należy przejrzeć polecenia dla każdego z nich, aby zwalidować poprawność składni. Następnie przypisz ją za pomocą sparametryzowanego efektu do odpowiednich zasobów w celu zarządzania zabezpieczeniami kont magazynu.

Czyszczenie zasobów

Jeśli nie planujesz dalszej pracy z zasobami utworzonymi w tym samouczku, wykonaj poniższe kroki, aby usunąć wszystkie utworzone powyżej przypisania lub definicje:

  1. Wybierz pozycję Definicje (lub Przypisania, jeśli próbujesz usunąć przypisanie) w obszarze Tworzenie w lewej części strony usługi Azure Policy.

  2. Wyszukaj nowo utworzoną definicję inicjatywy lub zasad (albo przypisanie), którą chcesz usunąć.

  3. Kliknij prawym przyciskiem myszy wiersz albo wybierz wielokropek na końcu definicji lub przypisania, a następnie wybierz pozycję Usuń definicję (lub Usuń przypisanie).

Wykonaj przegląd

W tym samouczku pomyślnie wykonano następujące czynności:

  • Określono wymagania biznesowe
  • Zamapowano każde wymaganie na właściwość zasobu platformy Azure
  • Zamapowano właściwości na alias
  • Określono efekt do użycia
  • Utworzono definicję zasad

Następne kroki

Następnie za pomocą niestandardowej definicji zasad utwórz i przypisz zasady:

Tworzenie i przypisywanie definicji zasad