Share via


Structure d’attestation Azure Policy

Les attestations sont utilisées par Azure Policy pour définir les états de conformité des ressources ou des étendues ciblées par des stratégies manuelles. Elles permettent également aux utilisateurs de fournir des métadonnées supplémentaires ou d’établir un lien vers des preuves qui accompagnent l’état de conformité attesté.

Notes

Les attestations peuvent être créées et gérées uniquement via Azure Policy API Azure Resource Manager (ARM),PowerShell ou Azure CLI.

Meilleures pratiques

Les attestations peuvent être utilisées pour définir l’état de conformité d’une ressource individuelle pour une stratégie manuelle donnée. Cela signifie que chaque ressource applicable nécessite une attestation par affectation de stratégie manuelle. Pour faciliter la gestion, les stratégies manuelles doivent être conçues pour cibler l’étendue qui définit la limite des ressources dont l’état de conformité doit être attesté.

Par exemple, supposons qu’une organisation divise les équipes par groupe de ressources et que chaque équipe est tenue d’attester du développement de procédures pour la gestion des ressources au sein de ce groupe de ressources. Dans ce scénario, les conditions de la règle de stratégie doivent spécifier que le type est égal à Microsoft.Resources/resourceGroups. Ainsi, une attestation est requise pour le groupe de ressources, plutôt que pour chaque ressource individuelle. De même, si l’organisation divise les équipes par abonnements, la règle de stratégie doit cibler Microsoft.Resources/subscriptions.

En règle générale, la preuve fournie doit correspondre aux étendues pertinentes de la structure organisationnelle. Ce modèle évite la nécessité de dupliquer des preuves sur de nombreuses attestations. Ces duplications rendent les stratégies manuelles difficiles à gérer et indiquent que la définition de stratégie cible les mauvaises ressources.

Exemple d’attestation

Voici un exemple de création d’une ressource d’attestation qui définit l’état de conformité d’un groupe de ressources ciblé par une affectation de stratégie manuelle :

PUT http://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.PolicyInsights/attestations/{name}?api-version=2019-10-01

Corps de la demande

Voici un exemple d’objet JSON de ressource d’attestation :

"properties": {
    "policyAssignmentId": "/subscriptions/{subscriptionID}/providers/microsoft.authorization/policyassignments/{assignmentID}",
    "policyDefinitionReferenceId": "{definitionReferenceID}",
    "complianceState": "Compliant",
    "expiresOn": "2023-07-14T00:00:00Z",
    "owner": "{AADObjectID}",
    "comments": "This subscription has passed a security audit. See attached details for evidence",
    "evidence": [
        {
          "description": "The results of the security audit.",
          "sourceUri": "https://gist.github.com/contoso/9573e238762c60166c090ae16b814011"
        },
        {
          "description": "Description of the attached evidence document.",
          "sourceUri": "https://storagesamples.blob.core.windows.net/sample-container/contingency_evidence_adendum.docx"
        },
    ],
    "assessmentDate": "2022-11-14T00:00:00Z",
    "metadata": {
         "departmentId": "{departmentID}"
     }
}
Propriété Description
policyAssignmentId ID d’affectation requis pour lequel l’état est défini.
policyDefinitionReferenceId ID de référence de définition facultatif, s’il s’agit d’une initiative de stratégie.
complianceState État souhaité des ressources. Les valeurs autorisées sont Compliant, NonCompliant et Unknown.
expiresOn Date facultative à laquelle l’état de conformité doit revenir de l’état de conformité attesté à l’état par défaut
owner ID d’objet Azure AD facultatif de la partie responsable.
comments Description facultative de la raison de la définition de l’état.
evidence Tableau facultatif de liens vers la preuve d’attestation.
assessmentDate Date à laquelle la preuve a été évaluée.
metadata Informations supplémentaires facultatives sur l’attestation.

Étant donné que les attestations sont une ressource distincte des affectations de stratégie, elles ont leur propre cycle de vie. Vous pouvez placer (PUT), obtenir (GET) et supprimer (DELETE) des attestations à l’aide de l’API ARM. Les attestations sont supprimées en cas de suppression de l’attribution manuelle de stratégie ou du policyDefinitionReferenceId, ou si une ressource unique à l’attestation est supprimée. Pour plus d’informations, consultez l’article Informations de référence sur l’API REST Stratégie.

Étapes suivantes