Condividi tramite

Informazioni di base sulla struttura di definizione di Criteri di Azure

  • Articolo

Le definizioni di Criteri di Azure descrivono le condizioni di conformità delle risorse e l'effetto da eseguire se viene soddisfatta una condizione. Una condizione confronta un valore o un campo proprietà della risorsa con un valore richiesto. È possibile accedere ai campi delle proprietà delle risorse usando gli alias. Quando un campo proprietà della risorsa è una matrice, è possibile usare un alias di matrice speciale per selezionare i valori di tutti i membri della matrice e applicare una condizione a ognuno. Altre informazioni sulle condizioni.

Usando le assegnazioni di criteri, è possibile controllare i costi e gestire le risorse. È ad esempio possibile specificare che vengano consentiti solo determinati tipi di macchine virtuali. In alternativa, è possibile richiedere che le risorse abbiano un tag specifico. Le assegnazioni in un ambito si applicano a tutte le risorse nell'ambito e quelle sottostanti. Se un'assegnazione dei criteri viene applicata a un gruppo di risorse, è applicabile a tutte le risorse in tale gruppo.

È possibile usare JSON per creare una definizione di criteri che contiene elementi per:

  • displayName
  • description
  • mode
  • version
  • metadata
  • parameters
  • policyRule
    • valutazioni logiche
    • effect

Ad esempio, la notazione JSON seguente illustra un criterio che limita i punti in cui vengono distribuite le risorse:

{
  "properties": {
    "displayName": "Allowed locations",
    "description": "This policy enables you to restrict the locations your organization can specify when deploying resources.",
    "mode": "Indexed",
    "metadata": {
      "version": "1.0.0",
      "category": "Locations"
    },
    "parameters": {
      "allowedLocations": {
        "type": "array",
        "metadata": {
          "description": "The list of locations that can be specified when deploying resources",
          "strongType": "location",
          "displayName": "Allowed locations"
        },
        "defaultValue": [
          "westus2"
        ]
      }
    },
    "policyRule": {
      "if": {
        "not": {
          "field": "location",
          "in": "[parameters('allowedLocations')]"
        }
      },
      "then": {
        "effect": "deny"
      }
    }
  }
}

Per altre informazioni, vedere lo schema di definizione dei criteri. Criteri di Azure predefiniti e i modelli si trovano in esempi di Criteri di Azure.

Nome visualizzato e descrizione

Usare displayName e description per identificare la definizione dei criteri e fornire il contesto di utilizzo della definizione. displayName ha una lunghezza massima di 128 caratteri e description una lunghezza massima di 512 caratteri.

Nota

Durante la creazione o l'aggiornamento di una definizione di criteri, id, type e name sono definiti dalle proprietà esterne al file JSON e non sono necessarie nel file JSON. Il recupero della definizione dei criteri tramite SDK restituisce le proprietà id, type e name come parte del codice JSON, ma ognuna è costituita da informazioni di sola lettura correlate alla definizione dei criteri.

Tipo di criterio

Anche se la proprietà policyType non può essere impostata, esistono tre valori restituiti dall'SDK e visibili nel portale:

  • Builtin: Microsoft fornisce e gestisce queste definizioni di criteri.
  • Custom: tutte le definizioni dei criteri create dai clienti hanno questo valore.
  • Static: indica una definizione di criteri di Conformità con le normative con Proprietà di Microsoft. I risultati della conformità per queste definizioni di criteri sono i risultati dei controlli non Microsoft dell'infrastruttura Microsoft. Nel portale di Azure questo valore viene talvolta visualizzato come Gestito da Microsoft. Per altre informazioni, vedere Responsabilità condivisa nel cloud.

Modalità

Il parametro mode viene configurato in base al fatto che i criteri siano destinati a una proprietà di Azure Resource Manager o a una proprietà del provider di risorse.

Modalità di Resource Manager

Il parametro mode determina quali tipi di risorse vengono valutati per una definizione dei criteri. Le modalità supportate sono:

  • all: vengono valutati i gruppi di risorse, le sottoscrizioni e tutti i tipi di risorse
  • indexed: vengono valutati solo i tipi di risorse che supportano tag e il percorso

Ad esempio, la risorsa Microsoft.Network/routeTables supporta i tag e il percorso e viene valutata in entrambe le modalità. Tuttavia, la risorsa Microsoft.Network/routeTables/routes non può essere contrassegnata e non viene valutata in modalità indexed.

È consigliabile impostare mode su all nella maggior parte dei casi. Tutte le definizioni di criteri create tramite il portale usano la modalità all. Se si usa PowerShell o l'interfaccia della riga di comando di Azure, è possibile specificare manualmente il parametro mode. Se la definizione dei criteri non include un valore mode, l'impostazione predefinita sarà all in Azure PowerShell e null nell'interfaccia della riga di comando di Azure. Una modalità null equivale all'uso di indexed per supportare la compatibilità con le versioni precedenti.

indexed deve essere usato durante la creazione di criteri che applicano tag o percorsi. Sebbene non sia necessario, evita che le risorse che non supportano tag e percorsi vengano visualizzate come non conformi nei risultati sulla conformità. L'eccezione è rappresentata dai gruppi di risorse e dalle sottoscrizioni. Le definizioni di criteri che impongono la località o i tag in un gruppo di risorse o una sottoscrizione devono impostare mode su all e specificamente indicare il tipo di destinazione Microsoft.Resources/subscriptions/resourceGroups o Microsoft.Resources/subscriptions. Per un esempio, vedere Modelli: Tag - Esempio 1. Per un elenco di risorse che supportano i tag, vedere Supporto dei tag per le risorse di Azure.

Modalità del provider di risorse

Sono supportate completamente le modalità del provider di risorse seguenti:

  • Microsoft.Kubernetes.Data per la gestione di cluster e componenti Kubernetes, ad esempio pod, contenitori e ingressi. Supportata per i cluster del servizio Azure Kubernetes e i cluster Kubernetes abilitati per Azure Arc. Le definizioni che usano questa modalità del provider di risorse usano gli effetti controllo, nega e disabilitato.
  • Microsoft.KeyVault.Data per la gestione di insiemi di credenziali e certificati in Azure Key Vault. Per altre informazioni su queste definizioni di criteri, vedere Integrare Azure Key Vault con Criteri di Azure.
  • Microsoft.Network.Data per la gestione dei criteri di appartenenza personalizzati di Gestione rete virtuale di Azure tramite Criteri di Azure.

Le modalità del provider di risorse seguenti sono attualmente supportate come anteprima:

  • Microsoft.ManagedHSM.Data per la gestione delle chiavi del modulo di protezione hardware gestito tramite Criteri di Azure.
  • Microsoft.DataFactory.Data per l'uso di Criteri di Azure per negare i nomi di dominio del traffico in uscita di Azure Data Factory non specificati in un elenco elementi consentiti. Questa modalità del provider di risorse è di sola imposizione e non segnala la conformità nell'anteprima pubblica.
  • Microsoft.MachineLearningServices.v2.Data per la gestione delle distribuzioni di modelli di Azure Machine Learning. Questa modalità del provider di risorse segnala la conformità per i componenti appena creati e aggiornati. Durante l'anteprima pubblica i record di conformità valgono per 24 ore. Le distribuzioni di modelli esistenti prima dell'assegnazione di queste definizioni dei criteri non segnalano la conformità.

Nota

Se non specificato in modo esplicito, le modalità del provider di risorse supportano solo le definizioni dei criteri predefinite e le esenzioni non sono supportate a livello di componente.

Quando viene rilasciato il controllo delle versioni di Criteri di Azure, le modalità del provider di risorse seguenti non supportano il controllo delle versioni predefinite:

  • Microsoft.DataFactory.Data
  • Microsoft.MachineLearningServices.v2.Data
  • Microsoft.ManagedHSM.Data

Versione (anteprima)

Le definizioni dei criteri predefinite possono ospitare più versioni con lo stesso definitionID. Se non viene specificato alcun numero di versione, tutte le esperienze visualizzeranno la versione più recente della definizione. Per visualizzare una versione specifica di una definizione dei criteri predefinita, è necessario specificarla nell'API, nell'SDK o nell'interfaccia utente. Per fare riferimento a una versione specifica di una definizione all'interno di un'assegnazione, vedere versione della definizione all'interno dell'assegnazione

Il servizio Criteri di Azure usa versionproprietà , previewe deprecated per trasmettere lo stato e il livello di modifica a una definizione o un'iniziativa predefinita dei criteri. Il formato di version è: {Major}.{Minor}.{Patch}. Quando una definizione di criteri è in stato di anteprima, l'anteprima del suffisso viene aggiunta alla version proprietà e considerata come un valore booleano. Quando una definizione di criteri è deprecata, la deprecazione viene acquisita come valore booleano nei metadati della definizione usando "deprecated": "true".

  • Versione principale (esempio: 2.0.0): introdurre modifiche di rilievo, come modifiche importanti alla logica delle regole, rimozione di parametri, aggiunta di un effetto di imposizione per impostazione predefinita.
  • Versione secondaria (esempio: 2.1.0): introdurre cambiamenti come modifiche minime alla logica delle regole, aggiunta di nuovi valori consentiti dei parametri, modifica a roleDefinitionIds, aggiunta o rimozione di definizioni all'interno di un'iniziativa.
  • Versione patch (esempio: 2.1.4): introdurre modifiche a stringhe o metadati e scenari di sicurezza per l'accesso di emergenza (rari).

Per altre informazioni sulle definizioni predefinite delle versioni di Criteri di Azure, vedere Controllo delle versioni predefinite. Per altre informazioni sul significato di un criterio deprecato o in anteprima, vedere Criteri in anteprima e deprecati.

Metadati UFX

La proprietà facoltativa metadata archivia informazioni sulla definizione dei criteri. I clienti possono definire qualsiasi proprietà e valori utili per l'organizzazione in metadata. Esistono tuttavia alcune proprietà comuni usate da Criteri di Azure e nelle impostazioni predefinite. Ogni proprietà metadata ha un limite di 1.024 caratteri.

Proprietà comuni dei metadati

  • version (stringa): tiene traccia dei dettagli sulla versione del contenuto di una definizione di criteri.
  • category (stringa): determina in quale categoria del portale di Azure viene visualizzata la definizione dei criteri.
  • preview (booleana): flag true o false che indica se la definizione dei criteri è in anteprima.
  • deprecated (booleana): flag true o false che indica se la definizione dei criteri è contrassegnata come deprecata.
  • portalReview (stringa): determina se i parametri devono essere esaminati nel portale, indipendentemente dall'input richiesto.

Posizione della definizione

Durante la creazione di iniziative o criteri è importante specificare la posizione della definizione. La posizione della definizione deve essere specificata come un gruppo di gestione o una sottoscrizione. Tale posizione determina l'ambito al quale la definizione delle iniziative o dei criteri può essere assegnata. Le risorse devono essere membri diretti o elementi figli all'interno della gerarchia della posizione della definizione da destinare all'assegnazione.

Se la posizione della definizione è:

  • Sottoscrizione: è possibile assegnare alla definizione dei criteri solo le risorse all'interno di tale sottoscrizione.
  • Gruppo di gestione: è possibile assegnare alla definizione dei criteri solo le risorse all'interno dei gruppi di gestione figlio e delle sottoscrizioni figlio. Se si intende applicare questa definizione di criteri a più sottoscrizioni, la posizione deve essere un gruppo di gestione contenente ogni sottoscrizione.

Per altre informazioni, vedere Informazioni sull'ambito in Criteri di Azure.

Passaggi successivi