Självstudie: Skapa en anpassad principdefinition

  • Artikel

Med en anpassad principdefinition kan kunderna definiera egna regler för att använda Azure. De här reglerna framtvingar ofta:

  • Säkerhetsmetoder
  • Kostnadshantering
  • Organisationsspecifika regler (till exempel namngivning eller platser)

Oavsett affärsdrivande faktor för att skapa en anpassad princip är stegen desamma för att definiera en ny anpassad princip.

Innan du skapar en anpassad princip bör du titta bland principexemplen för att se om det redan finns en princip som passar dina behov.

Metoden för att skapa en anpassad princip följer de här stegen:

  • Identifiera dina affärskrav
  • Mappa varje krav till en Azure-resursegenskap
  • Mappa egenskapen till ett alias
  • Fastställa vilken effekt som ska användas
  • Skapa principdefinitionen

Krav

Om du inte har en Azure-prenumeration kan du skapa ett kostnadsfritt konto innan du börjar.

Identifiera krav

Det är viktigt att du förstår syftet med principen innan du skapar principdefinitionen. I den här självstudien använder vi ett vanligt företagssäkerhetskrav som målet för att illustrera stegen som ingår:

  • Varje lagringskonto måste vara aktiverat för HTTPS
  • Varje lagringskonto måste vara inaktiverat för HTTPS

Dina krav bör tydligt identifiera både resurstillståndet ”to be” och ”not to be”.

Vi har definierat förväntat tillstånd för resursen, men vi har ännu inte definierat vad vi vill ha gjort med icke-kompatibla resurser. Azure Policy stöder många effekter. I den här självstudien ska vi definiera affärsbehov som att förhindra skapandet av resurser om de inte är kompatibla med affärsreglerna. För att nå detta mål använder vi effekten för att neka. Vi vill också ha alternativet för att inaktivera principen för specifika tilldelningar. Därför använder vi den inaktiverade effekten och skapar en parameter i principdefinitionen.

Fastställa resursegenskaper

Azure-resursen som ska granskas med Azure Policy är ett lagringskonto, baserat på affärsbehov. Vi vet emellertid inte vilka egenskaper som ska användas i principdefinitionen. Azure Policy utvärderas mot JSON-representationen av resursen, så vi måste förstå vilka egenskaper som är tillgängliga för den resursen.

Det finns många sätt att avgöra egenskaperna för en Azure-resurs. Vi ska titta på var och en för den här självstudien:

  • Azure Policy-tillägg för VS Code
  • Azure Resource Manager-mallar (ARM-mallar)
    • Exportera befintlig resurs
    • Skapandeupplevelse
    • Snabbstartsmallar (GitHub)
    • Mallreferensdokument
  • Azure Resource Explorer

Visa resurser i VS Code-tillägget

VS Code-tillägget kan användas för att bläddra bland resurser i din miljö och se Resource Manager egenskaper för varje resurs.

ARM-mallar

Det finns flera sätt att titta på en ARM-mall som innehåller egenskapen som du vill hantera.

Befintlig resurs i portalen

Det enklaste sättet att hitta egenskaper är att titta på en befintlig resurs av samma typ. Resurser som redan har konfigurerats med inställningen som du vill framtvinga innehåller också värdet att jämföra med. Titta på sidan Exportera mall (under Inställningar) i Azure Portal för den specifika resursen.

Varning

ARM-mallen som exporteras av Azure Portal kan inte anslutas direkt till deployment egenskapen för en ARM-mall i en deployIfNotExists-principdefinition.

Skärmbild av sidan Exportera mall på en befintlig resurs i Azure Portal.

Om du gör det för ett lagringskonto visas en mall som liknar det här exemplet:

...
"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": []
}]
...

Under egenskaper är ett värde med namnet supportsHttpsTrafficOnly inställt på falskt. Den här egenskapen verkar vara den vi letar efter. Resursens typ är Microsoft.Storage/storageAccounts. Med typen kan vi begränsa principen till endast resurser av den här typen.

Skapa en resurs i portalen

Ett annat sätt via portalen är resursskapandeupplevelsen. När du skapar ett lagringskonto via portalen är ett alternativ under fliken AvanceratSäkerhetsöverföring krävs. Den här egenskapen har alternativen Inaktiverad och Aktiverad. Informationsikonen har ytterligare text som bekräftar att det är sannolikt att det här alternativet är egenskapen vi vill ha. Dock visar inte portalen egenskapens namn på den här skärmen.

På fliken Granska + skapa finns en länk längst ned på sidan för att ladda ned en mall för automatisering. Om du väljer länken öppnas den mall som skapar den resurs som vi har konfigurerat. I det här fallet kan vi se två viktiga uppgifter:

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

Den här informationen talar om egenskapstypen och bekräftar även att supportsHttpsTrafficOnly är egenskapen vi letar efter.

Snabbstartsmallar på GitHub

Azure-snabbstartsmallarna på GitHub har hundratals ARM-mallar som skapats för olika resurser. Dessa mallar kan vara ett bra sätt att hitta resursegenskapen du letar efter. Vissa egenskaper kanske verkar vara det du letar efter, men styr något annat.

Resursreferensdokument

Kontrollera att supportsHttpsTrafficOnly är rätt egenskap genom att kontrollera ARM-mallreferensen för lagringskontoresursen på lagringsprovidern. Egenskapsobjektet har en lista med giltiga parametrar. Om du väljer länken StorageAccountPropertiesCreateParameters-object visas en tabell över godkända egenskaper. supportsHttpsTrafficOnly finns och beskrivningen matchar vad vi är intresserade av för att uppfylla affärskraven.

Azure Resource Explorer

Du kan även utforska dina Azure-resurser via Azure Resource Explorer (förhandsversion). Det här verktyget använder kontexten för din prenumeration, så du måste autentisera till webbplatsen med dina autentiseringsuppgifter för Azure. När autentiseringen är klar kan du söka genom providrar, prenumerationer, resursgrupper och resurser.

Leta upp en lagringskontoresurs och titta på egenskaperna. Vi kan se egenskapen supportsHttpsTrafficOnly även här. Om vi väljer fliken Dokumentation ser vi att egenskapsbeskrivningen matchar det vi påträffade i referensdokumenten tidigare.

Hitta egenskapsalias

Vi har identifierat resursegenskapen, men vi behöver mappa egenskapen till ett alias.

Det finns några olika sätt att avgöra alias för en Azure-resurs. Vi ska titta på var och en för den här självstudien:

  • Azure Policy-tillägg för VS Code
  • Azure CLI
  • Azure PowerShell

Hämta alias i VS Code-tillägget

Det Azure Policy tillägget för VS Code-tillägget gör det enkelt att bläddra bland dina resurser och identifiera alias.

Anteckning

VS Code-tillägget visar endast egenskaper för Resource Manager läge och visar inga egenskaper för resursproviderläge.

Azure CLI

I Azure CLI används az provider-kommandogruppen för att söka efter resursalias. Vi ska filtrera Microsoft.Storage-namnområdet utifrån den information som vi tidigare fått om Azure-resursen.

# 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"

I resultatet ser vi ett alias som stöds av lagringskonton med namnet supportsHttpsTrafficOnly. Den här förekomsten av det här aliaset innebär att vi kan skriva principen för att genomdriva våra affärskrav!

Azure PowerShell

I Azure PowerShell används cmdleten Get-AzPolicyAlias för att söka efter resursalias. Vi ska filtrera Microsoft.Storage-namnområdet utifrån den information som vi tidigare fått om Azure-resursen.

# 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

Som i Azure CLI visar resultatet ett alias som stöds av lagringskonton med namnet supportsHttpsTrafficOnly.

Fastställa vilken effekt som ska användas

Det är nästan lika viktigt att bestämma vad som ska göras med icke-kompatibla resurser som att bestämma vad som ska utvärderas i första hand. Varje möjligt svar på en icke-kompatibel resurs kallas för en effekt. Effekten kontrollerar om den icke-kompatibla resursen loggas, blockeras, har bifogade data eller en distribution associerad till sig för att sätta tillbaka resursen i ett kompatibelt tillstånd.

I vårt exempel är Neka den effekt vi vill ha eftersom vi inte vill att icke-kompatibla resurser ska skapas i vår Azure-miljö. Granskning är ett bra första alternativ för en principeffekt för att avgöra vad effekten av en princip är innan du nekar. Ett sätt att underlätta ändring av effekt per tilldelning är att parameterisera effekten. Se parametrarna nedan för information om hur.

Skapa definitionen

Nu har vi egenskapsinformation och alias för det vi planerar att hantera. Därefter ska vi skapa själva principregeln. Om du ännu inte är bekant med principspråket kan du titta på principdefinitionsstrukturen för att se hur du ska strukturera principdefinitionen. Här är en tom mall för hur en principdefinition ska se ut:

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

Metadata

De första tre komponenterna är principmetadata. De här komponenterna är enkla att ange värden för eftersom vi vet vad vi skapar regeln för. Läget handlar främst om taggar och resursplats. Eftersom vi inte behöver begränsa utvärdering till resurser som har stöd för taggar använder vi Alla som läge.

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

Parametrar

Vi använde inte någon parameter för att ändra utvärderingen, men vi vill använda en parameter för att tillåta ändring av effekten för felsökning. Vi ska definiera en effectType-parameter och begränsa den till endast Neka och Inaktiverad. De här två alternativen matchar våra affärskrav. Det slutförda parameterblocket ser ut som i följande exempel:

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

Principregel

Skapandet av principregeln är det sista steget i att skapa vår anpassade principdefinition. Vi har identifierat två instruktioner för testning:

  • Lagringskontotypen är Microsoft.Storage/storageAccounts
  • Lagringskontot supportsHttpsTrafficOnly är inte sant

Eftersom vi behöver att båda dessa instruktionerna är sanna använder vi den logiska operatornallOf. Vi ska skicka parametern effectType för effekten i stället för att göra en statisk deklaration. Vår slutförda regel ser ut som i följande exempel:

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

Slutförd definition

När alla tre delar av principen har definierats är här vår slutförda definition:

{
    "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')]"
            }
        }
    }
}

Den slutförda definitionen kan användas för att skapa en ny princip. Portalen och varje SDK (Azure CLI, Azure PowerShell och REST-API) accepterar definitionen på olika sätt, så gå igenom kommandona för varje att verifiera korrekt användning. Tilldela den sedan, med den parameteriserade effekten, till lämpliga resurser för att hantera säkerheten för dina lagringskonton.

Rensa resurser

Om du är klar med att arbeta med resurser i den här självstudien kan du använda följande steg för att ta bort tilldelningar eller definitioner som skapades ovan:

  1. Välj Definitioner (eller Tilldelningar om du ska ta bort en tilldelning) under Redigering till vänster på sidan Azure Policy.

  2. Sök efter den nya initiativ- eller principdefinition (eller tilldelning) som du vill ta bort.

  3. Högerklicka på raden eller välj ellipserna i slutet av definitionen (eller tilldelningen) och välj Ta bort definition (eller Ta bort tilldelning).

Genomgång

I den här självstudien har du genomfört följande uppgifter:

  • Identifierade dina affärskrav
  • Mappade varje krav till en Azure-resursegenskap
  • Mappade egenskapen till ett alias
  • Fastställde vilken effekt som skulle användas
  • Skapade principdefinitionen

Nästa steg

Använd din anpassade principdefinition för att skapa och tilldela en princip:

Skapa och tilldela en principdefinition