Dela via


Självstudie: Skapa en anpassad principdefinition

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

Förutsättningar

Om du inte har någon Azure-prenumeration skapar du 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 du ett vanligt säkerhetskrav för företag som mål för att illustrera stegen:

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

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

Även om vi definierade resursens förväntade tillstånd har vi inte definierat vad vi vill göra med icke-kompatibla resurser. Azure Policy stöder många effekter. I den här självstudien definierar vi affärskravet som att förhindra att resurser skapas om de inte är kompatibla med affärsreglerna. För att uppnå det här målet använder vi neka-effekten. Vi vill också ha alternativet för att inaktivera principen för specifika tilldelningar. Använd den inaktiverade effekten och gör effekten till 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å de 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 tittar 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 i 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 properties är ett värde med namnet supportsHttpsTrafficOnly inställt på false. Den här egenskapen verkar vara den egenskap vi letar efter. Resursens type är Microsoft.Storage/storageAccountsockså . 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 Avancerat säkerhetsöverföring obligatoriskt. Den här egenskapen har alternativen Inaktiverad och Aktiverad. Informationsikonen har mer text som bekräftar att det här alternativet troligen är den egenskap vi vill ha. Men portalen anger inte egenskapsnamnet 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 anger egenskapstypen och bekräftar supportsHttpsTrafficOnly även att det är den egenskap 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 kan verka vara det du letar efter, men kontrollera något annat.

Resursreferensdokument

supportsHttpsTrafficOnly Kontrollera att egenskapen är korrekt genom att kontrollera ARM-mallreferensen för lagringskontoresursen på lagringsprovidern. Egenskapsobjektet har en lista med giltiga parametrar. Om du väljer objektlänken StorageAccountPropertiesCreateParameters visas en tabell med godkända egenskaper. supportsHttpsTrafficOnly är närvarande och beskrivningen matchar det vi letar efter när det gäller 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 ser fastigheten supportsHttpsTrafficOnly här också. 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 måste mappa den egenskapen till ett alias.

Det finns några olika sätt att avgöra alias för en Azure-resurs. Vi tittar 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

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

Kommentar

VS Code-tillägget exponerar endast Resource Manager-lägesegenskaper 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 filtrerar efter Microsoft.Storage namnområdet baserat på den information vi fick om Azure-resursen tidigare.

# 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 lagringskontona 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. Filtrera efter Microsoft.Storage namnområdet baserat på den information vi fick om Azure-resursen tidigare.

# 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

Liksom Azure CLI visar resultaten ett alias som stöds av lagringskontona 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 deny är 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 val för en principeffekt för att avgöra vilken effekt en princip har innan du ställer in den på deny. Ett sätt att underlätta ändring av effekt per tilldelning är att parameterisera effekten. Mer information finns i parametrar .

Skapa definitionen

Nu har vi egenskapsinformation och alias för det vi planerar att hantera. Därefter skapar vi själva principregeln. Om du inte är bekant med principspråket refererar du till principdefinitionsstrukturen för hur du strukturerar principdefinitionen. Här är en tom mall för hur en principdefinition ser 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ärderingen till resurser som stöder taggar använder du alla värden för mode.

"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

Även om vi inte använde en parameter för att ändra utvärderingen, vill vi använda en parameter för att tillåta ändring av felsökningen effect . Du definierar en effectType parameter och begränsar den till endast deny och disabled. 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 att testa för:

  • Lagringskontot type är Microsoft.Storage/storageAccounts.
  • Lagringskontot supportsHttpsTrafficOnly är inte true.

Eftersom vi behöver båda dessa instruktioner för att vara sanna använder du den allOf logiska operatorn. Skicka parametern effectType till 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 från den här självstudien använder du följande steg för att ta bort någon av de tilldelningar eller definitioner som du skapade:

  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).

Granskning

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: