Tous les produits
Search
Centre de documentation

Key Management Service:Présentation des points d'accès applicatifs (AAP)

Dernière mise à jour :Aug 09, 2026

Key Management Service (KMS) utilise des points d'accès applicatifs (AAP) pour contrôler l'authentification et l'accès aux clés et aux secrets des applications autogérées au sein d'une instance KMS. Une application doit s'authentifier via un AAP avant de pouvoir utiliser une clé ou un secret.

Un AAP comprend deux composants : une politique d'autorisations et un identifiant.

Important

Créez un AAP distinct pour chaque application accédant à KMS. Chaque application disposera ainsi de ses propres autorisations d'accès et pourra faire l'objet d'un audit indépendant.

Fonctionnement

Chaque AAP applique deux niveaux de contrôle :

  • Politique d'autorisations : définit les clés et les secrets accessibles par l'application, ainsi que les adresses IP autorisées.

  • Identifiant : authentifie l'identité de l'application avant d'accorder l'accès.

Politiques d'autorisations

Une politique d'autorisations spécifie les ressources KMS accessibles par une application et les conditions associées. Chaque AAP prend en charge jusqu'à trois politiques d'autorisations.

Chaque politique inclut les éléments suivants :

  • Autorisations RBAC : opérations autorisées pour l'application.

  • Ressources accessibles : clés ou secrets auxquels l'application peut accéder.

  • Règles d'accès réseau : adresses IP source à partir desquelles l'accès est autorisé.

Autorisations RBAC

Rôle Étendue Opérations prises en charge
CryptoServiceKeyUser Clés dans une instance KMS Opérations cryptographiques via l'API d'instance. Consultez la section Liste des opérations par fonction.
CryptoServiceSecretUser Secrets dans une instance KMS Opérations liées aux secrets via l'API d'instance. Consultez la section Liste des opérations par fonction.
SecretUser Tous les secrets du compte Alibaba Cloud actuel GetSecretValue via OpenAPI

Identifiants

Un identifiant prouve l'identité de l'application accédant à KMS. Deux types d'identifiants sont pris en charge : la clé client et le rôle RAM.

Choisir un type d'identifiant

Scénario Type d'identifiant
L'application requiert une authentification de l'identité et du comportement pour utiliser des clés ou des secrets dans une instance KMS Clé client
L'application s'exécute sur Elastic Compute Service (ECS), Container Service for Kubernetes (ACK) ou Function Compute, et est associée à un rôle Resource Access Management (RAM) Rôle RAM

Clé client

Une clé client signe les requêtes envoyées par l'application à KMS et vérifie ces signatures. Elle se compose de deux parties :

  • Application Access Secret (ClientKeyContent)

  • Mot de passe

Limites du cycle de vie :

Propriété Valeur
Période de validité par défaut Cinq ans (un an recommandé)
Nombre maximal de clés clients par AAP Trois
Stockage KMS ne stocke pas les clés clients. Si vous perdez une clé client, supprimez-la et créez-en une nouvelle.
Réponse en cas de compromission Supprimez immédiatement la clé compromise et créez un remplacement.

Pour renouveler une clé client avant son expiration, consultez la rubrique Modifier une clé client. Après avoir activé la nouvelle clé, supprimez l'ancienne de KMS.

Rôle RAM

Utilisez un rôle RAM lorsque votre application s'exécute sur ECS, ACK ou Function Compute, qu'elle est déjà associée à un rôle RAM et que vous devez récupérer la valeur d'un secret via un endpoint KMS. KMS authentifie les requêtes OpenAPI via RAM ; aucune clé client n'est requise.

Kits SDK prenant en charge l'authentification par clé client

Les différents kits SDK KMS prennent en charge différentes méthodes d'authentification. Pour obtenir une vue d'ensemble complète, consultez la section Références des kits SDK.

Les kits SDK suivants prennent en charge l'authentification par clé client :

Kit SDK Étendue d'accès Type d'endpoint
Kit SDK d'instance KMS Clés et secrets dans une instance KMS Endpoint d'instance KMS (nécessite une clé client)
Kit SDK de secret Secrets dans une instance KMS, ou secrets dans l'ensemble du compte Alibaba Cloud actuel Endpoint d'instance KMS ou endpoint KMS
Remarque

Lorsque vous utilisez le kit SDK de secret avec un endpoint KMS, vous pouvez vous authentifier à l'aide d'une clé client, d'une paire AccessKey d'utilisateur RAM ou d'un rôle RAM. Le type d'endpoint dépend de la configuration de l'étendue de la politique d'autorisations : définissez-le sur une instance KMS pour utiliser un endpoint d'instance KMS, ou sur Shared KMS Gateway pour utiliser un endpoint KMS.

Notifications d'expiration des clés clientes

Alibaba Cloud envoie des notifications d'expiration par e-mail ou par message interne aux intervalles suivants avant l'expiration d'une clé cliente : six mois, trois mois, un mois et sept jours.

Pour configurer des alertes proactives, paramétrez CloudMonitor afin qu'il envoie des notifications 180 jours, 90 jours, 30 jours et 7 jours avant l'expiration. Consultez les Événements d'alerte.

Journaux et audit

Événements de gestion

KMS s'intègre à ActionTrail pour enregistrer les événements de gestion des AAP. Consultez les rubriques Événements d'audit de KMS et Utiliser ActionTrail pour interroger les événements KMS.

Journaux d'appels de clés clientes

KMS s'intègre à Simple Log Service (SLS) pour enregistrer les appels effectués à l'aide de clés clientes. Les journaux sont conservés pendant 180 jours et sont consultables sur la page Simple Log Service for KMS. Pour vérifier si une clé cliente spécifique a été utilisée, saisissez son ID dans la zone de recherche sous kms_audit_log. Si le champ access_key_id dans les résultats correspond à l'ID de la clé cliente, cela signifie que la clé a été utilisée.

Étapes suivantes