Partager via

bibliothèque de client Azure Attestation pour Java - version 1.1.18

  • Article

Microsoft Azure Attestation (préversion) est une solution unifiée de vérification à distance de la fiabilité d’une plateforme et de l’intégrité des fichiers binaires qui s’y exécutent. Le service prend en charge l’attestation des plateformes reposant sur des modules de plateforme sécurisée (TPM), en plus de la possibilité d’attester de l’état des environnements d’exécution de confiance (TEE), tels que les enclaves Intel® SGX (Software Guard Extensions) et les enclaves de sécurité basée sur la virtualisation (VBS).

L’attestation est un processus permettant de démontrer que les binaires logiciels ont été correctement instanciés sur une plateforme approuvée. Les parties de confiance distantes peuvent alors avoir l’assurance que seuls des logiciels de ce type s’exécutent sur du matériel approuvé. Azure Attestation est un framework et un service orientés client unifiés pour l’attestation.

Azure Attestation permet des paradigmes de sécurité de pointe tels que l’informatique confidentielle Azure et la protection de périphérie intelligente. Les clients ont demandé à pouvoir vérifier indépendamment la localisation d’un ordinateur, la posture d’une machine virtuelle sur cet ordinateur et l’environnement dans lequel les enclaves s’exécutent sur cette machine virtuelle. Azure Attestation permet de répondre à ces demandes des clients et à bien d’autres.

Azure Attestation reçoit des preuves des entités de calcul, les transforme en un ensemble de revendications, les valide par rapport à des stratégies configurables et génère des preuves cryptographiques pour les applications basées sur les revendications (par exemple, les parties de confiance et les autorités d’audit).

REMARQUE : Il s’agit d’un Kit de développement logiciel (SDK) préliminaire pour le service Microsoft Azure Attestation. Il fournit toutes les fonctionnalités essentielles pour accéder au service Azure Attestation, mais nécessite une quantité importante d’infrastructure pour fonctionner correctement.

Prise en main

Inclure le package

Inclure le fichier de nomenclature

Incluez azure-sdk-bom dans votre projet pour dépendre de la version de disponibilité générale de la bibliothèque. Dans l’extrait de code suivant, remplacez l’espace réservé {bom_version_to_target} par le numéro de version. Pour en savoir plus sur la nomenclature, consultez le README BOM du KIT DE DÉVELOPPEMENT LOGICIEL AZURE.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.azure</groupId>
            <artifactId>azure-sdk-bom</artifactId>
            <version>{bom_version_to_target}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

puis incluez la dépendance directe dans la section dépendances sans la balise de version, comme indiqué ci-dessous.

<dependencies>
  <dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-security-attestation</artifactId>
  </dependency>
</dependencies>

Inclure une dépendance directe

Si vous souhaitez dépendre d’une version particulière de la bibliothèque qui n’est pas présente dans la nomenclature, ajoutez la dépendance directe à votre projet comme suit.

<!-- Install the Azure Attestation SDK -->
<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-security-attestation</artifactId>
    <version>1.1.18</version>
</dependency>

Prérequis

az attestation create --resource-group <your-resource-group-name> --name <your-instance-name>

Authentifier le client

Pour interagir avec le service Azure Attestation, votre client doit présenter un jeton du porteur Azure Active Directory au service.

Le moyen le plus simple de fournir un jeton du porteur consiste à utiliser la DefaultAzureCredential méthode d’authentification en fournissant des informations d’identification de clé secrète client dans cette section de prise en main, mais vous pouvez trouver d’autres façons de vous authentifier avec azure-identity.

Concepts clés

Le service Microsoft Azure Attestation s’exécute dans deux modes distincts : « Isolé » et « AAD ». Lorsque le service s’exécute en mode « Isolé », le client doit fournir des informations supplémentaires au-delà de ses informations d’authentification pour vérifier qu’il est autorisé à modifier l’état d’une attestation instance.

Quatre types de clients principaux sont fournis dans ce KIT de développement logiciel (SDK) en préversion :

Chaque instance d’attestation fonctionne dans l’un des deux modes de fonctionnement distincts :

  • Mode AAD.
  • Mode isolé

En mode « AAD », l’accès au service est contrôlé uniquement par les Access Control basées sur le rôle Azure. En mode « Isolé », le client est censé fournir des preuves supplémentaires pour prouver que le client est autorisé à modifier le service.

Enfin, chaque région dans laquelle le service Microsoft Azure Attestation est disponible prend en charge une instance « partagée », qui peut être utilisée pour attester les enclaves SGX qui n’ont besoin que d’une vérification par rapport à la base de référence Azure (aucune stratégie n’est appliquée à l’instance partagée). L’attestation TPM n’est pas disponible dans le instance partagé. Bien que le instance partagé nécessite l’authentification AAD, il n’a pas de stratégie RBAC . Tout client disposant d’un jeton de porteur AAD valide peut attester à l’aide de la instance partagée.

Attestation

L’attestation SGX ou TPM est le processus de validation des preuves collectées à partir d’un environnement d’exécution approuvé pour s’assurer qu’elle respecte à la fois la base de référence Azure pour cet environnement et les stratégies définies par le client appliquées à cet environnement.

Détection et validation du certificat de signature de jeton d’attestation

La plupart des réponses du service MAA sont exprimées sous la forme d’un jeton web JSON. Ce jeton sera signé par un certificat de signature émis par le service MAA pour le instance spécifié. Si le service MAA instance s’exécute dans une région où le service s’exécute dans une enclave SGX, le certificat émis par le serveur peut être vérifié à l’aide de l’API oe_verify_attestation_certificate().

Gestion des stratégies

Une stratégie est appliquée à chaque service d’attestation instance qui définit des critères supplémentaires définis par le client.

Pour plus d’informations sur les stratégies d’attestation, consultez Stratégie d’attestation

Gestion des certificats de gestion des stratégies

Lorsqu’une instance d’attestation s’exécute en mode « Isolé », le client qui a créé le instance a fourni un certificat de gestion des stratégies au moment de la création du instance. Toutes les opérations de modification de stratégie nécessitent que le client signe les données de stratégie avec l’un des certificats de gestion de stratégie existants. Les API de gestion des certificats de gestion des stratégies permettent aux clients d’ajouter, de supprimer ou d’énumérer les certificats de gestion des stratégies.

Exemples

Instancier un client d’attestation synchrone

La AttestationClientBuilder classe est utilisée pour créer des instances du client d’attestation :

AttestationClientBuilder attestationBuilder = new AttestationClientBuilder();
// Note that the "attest" calls do not require authentication.
AttestationClient client = attestationBuilder
    .endpoint(endpoint)
    .buildClient();

Récupérer des certificats de validation de jeton

Utilisez listAttestationSigners pour récupérer l’ensemble de certificats, qui peut être utilisé pour valider le jeton retourné par le service d’attestation. Normalement, ces informations ne sont pas requises, car le KIT de développement logiciel (SDK) d’attestation effectue la validation dans le cadre de l’interaction avec le service d’attestation, mais les API sont fournies à des fins d’exhaustivité et pour faciliter la validation indépendante des résultats de l’attestation par le client.

AttestationSignerCollection certs = client.listAttestationSigners();

certs.getAttestationSigners().forEach(cert -> {
    System.out.println("Found certificate.");
    if (cert.getKeyId() != null) {
        System.out.println("    Certificate Key ID: " + cert.getKeyId());
    } else {
        System.out.println("    Signer does not have a Key ID");
    }
    cert.getCertificates().forEach(chainElement -> {
        System.out.println("        Cert Subject: " + chainElement.getSubjectDN().getName());
        System.out.println("        Cert Issuer: " + chainElement.getIssuerDN().getName());
    });
});

Attester d’une enclave SGX

Utilisez la attestSgxEnclave méthode pour attester une enclave SGX.

BinaryData decodedRuntimeData = BinaryData.fromBytes(SampleCollateral.getRunTimeData());
BinaryData sgxQuote = BinaryData.fromBytes(SampleCollateral.getSgxEnclaveQuote());

// Attest evidence from an OpenEnclave enclave specifying runtime data which should be
// interpreted as binary data.
AttestationResult result = client.attestSgxEnclave(new AttestationOptions(sgxQuote)
    .setRunTimeData(
        new AttestationData(decodedRuntimeData, AttestationDataInterpretation.BINARY)));

String issuer = result.getIssuer();

System.out.println("Attest Sgx Enclave completed. Issuer: " + issuer);
System.out.printf("Runtime Data Length: %d\n", result.getEnclaveHeldData().getLength());

Instancier un client d’administration synchrone

Tous les clients administratifs sont authentifiés.

AttestationAdministrationClientBuilder attestationBuilder = new AttestationAdministrationClientBuilder();
// Note that the "policy" calls require authentication.
AttestationAdministrationClient client = attestationBuilder
    .endpoint(endpoint)
    .credential(new DefaultAzureCredentialBuilder().build())
    .buildClient();

Obtenir la stratégie d’attestation

Utilisez l’API getAttestationPolicy pour récupérer la stratégie d’attestation actuelle pour un TEE donné.

String currentPolicy = client.getAttestationPolicy(AttestationType.OPEN_ENCLAVE);
System.out.printf("Current policy for OpenEnclave is: %s\n", currentPolicy);

Définir une stratégie d’attestation non signée

Lorsqu’un instance d’attestation est en mode AAD, l’appelant peut utiliser une méthode pratique pour définir une stratégie d’attestation non signée sur le instance.

// Set the listed policy on an attestation instance. Please note that this particular policy will deny all
// attestation requests and should not be used in production.
PolicyResult policyResult = client.setAttestationPolicy(AttestationType.OPEN_ENCLAVE,
    "version=1.0; authorizationrules{=> deny();}; issuancerules{};");
System.out.printf("Policy set for OpenEnclave result: %s\n", policyResult.getPolicyResolution());

Définir la stratégie d’attestation signée

Pour les instances d’attestation en mode isolé, la demande de stratégie de définition ou de réinitialisation doit être signée à l’aide de la clé associée aux certificats de signature d’attestation configurés sur le instance d’attestation.

// Set the listed policy on an attestation instance using a signed policy token.
PolicyResult policyResult = client.setAttestationPolicy(AttestationType.SGX_ENCLAVE,
    new AttestationPolicySetOptions()
        .setAttestationPolicy("version=1.0; authorizationrules{=> permit();}; issuancerules{};")
            .setAttestationSigner(new AttestationSigningKey(certificate, privateKey)));
System.out.printf("Policy set for Sgx result: %s\n", policyResult.getPolicyResolution());

Répertorier les certificats de gestion des stratégies

Lorsqu’une instance d’attestation est en Isolated mode, les API de stratégie ont besoin d’une preuve d’autorisation supplémentaire. Cette preuve est fournie via le AttestationSigningKey paramètre passé dans les API de stratégie set et reset.

Chaque Isolated mode instance dispose d’un ensemble de certificats, qui déterminent si un appelant a l’autorité nécessaire pour définir une stratégie d’attestation. Lorsqu’une stratégie d’attestation est définie, le client présente un « jeton » signé au service, qui est signé par la clé dans le AttestationSigningKey. Le jeton signé, y compris le certificat dans est AttestationSigningKey envoyé au service d’attestation, qui vérifie que le jeton a été signé avec la clé privée correspondant à la clé publique dans le jeton. L’opération de définition ou de réinitialisation de stratégie réussit uniquement si le certificat dans le jeton est l’un des jetons de gestion de stratégie. Cette interaction garantit que le client est en possession de la clé privée associée à l’un des certificats de gestion des stratégies et est donc autorisé à effectuer l’opération.

AttestationSignerCollection signers = client.listPolicyManagementCertificates();
System.out.printf("Instance %s contains %d signers.\n", endpoint, signers.getAttestationSigners().size());
for (AttestationSigner signer : signers.getAttestationSigners()) {
    System.out.printf("Certificate Subject: %s", signer.getCertificates().get(0).getSubjectDN().toString());
}

Ajouter un certificat de gestion des stratégies

Ajoute un nouveau certificat à l’ensemble de certificats de gestion des stratégies. La demande d’ajout du certificat de gestion des stratégies doit être signée avec la clé privée associée à l’un des certificats de gestion de stratégie existants (cela garantit que l’appelant est autorisé à mettre à jour l’ensemble de certificats de stratégie).

Remarque : l’ajout du même certificat deux fois n’est pas considéré comme une erreur . Si le certificat est déjà présent, l’ajout est ignoré (ce comportement peut-être surprenant, car les nouvelles tentatives peuvent entraîner l’exécution de l’ajout plusieurs fois)

System.out.printf("Adding new certificate %s\n", certificateToAdd.getSubjectDN().toString());
PolicyCertificatesModificationResult modificationResult = client.addPolicyManagementCertificate(
    new PolicyManagementCertificateOptions(certificateToAdd,
        new AttestationSigningKey(isolatedCertificate, isolatedKey)));
System.out.printf("Updated policy certificate, certificate add result: %s\n",
    modificationResult.getCertificateResolution());
System.out.printf("Added certificate thumbprint: %s\n", modificationResult.getCertificateThumbprint());

Supprimer le certificat de signature d’attestation

Supprime un certificat de l’ensemble de certificats de gestion des stratégies. La demande de suppression du certificat de gestion des stratégies doit être signée avec la clé privée associée à l’un des certificats de gestion des stratégies existants (cela garantit que l’appelant est autorisé à mettre à jour l’ensemble de certificats de stratégie).

Remarque : la suppression d’un certificat inexistant n’est pas considérée comme une erreur : si le certificat n’est pas présent, la suppression est ignorée (ce comportement peut-être surprenant, car les nouvelles tentatives peuvent entraîner l’exécution de la suppression plusieurs fois)

System.out.printf("Removing existing certificate %s\n", certificateToRemove.getSubjectDN().toString());
PolicyCertificatesModificationResult modificationResult = client.deletePolicyManagementCertificate(
    new PolicyManagementCertificateOptions(certificateToRemove,
        new AttestationSigningKey(isolatedCertificate, isolatedKey)));
System.out.printf("Updated policy certificate, certificate remove result: %s\n",
    modificationResult.getCertificateResolution());
System.out.printf("Removed certificate thumbprint: %s\n", modificationResult.getCertificateThumbprint());

Dépannage

Vous trouverez des informations de résolution des problèmes pour le service MAA ici

Étapes suivantes

Pour plus d’informations sur le service Microsoft Azure Attestation, consultez notre page de documentation.

Contribution

Ce projet accepte les contributions et les suggestions. La plupart des contributions vous demandent d’accepter un contrat de licence de contribution (CLA) déclarant que vous avez le droit de nous accorder, et que vous nous accordez réellement, les droits d’utilisation de votre contribution. Pour plus d’informations, visitez https://cla.microsoft.com.

Quand vous envoyez une demande de tirage (pull request), un bot CLA détermine automatiquement si vous devez fournir un contrat CLA et agrémenter la demande de tirage de façon appropriée (par exemple, avec une étiquette ou un commentaire). Suivez simplement les instructions fournies par le bot. Vous ne devez effectuer cette opération qu’une seule fois sur tous les dépôts utilisant notre contrat CLA.

Ce projet a adopté le Code de conduite Open Source de Microsoft. Pour plus d’informations, consultez la FAQ sur le code de conduite ou contactez opencode@microsoft.com pour toute question ou tout commentaire supplémentaire.

Impressions