Gérez les clés d'API pour les charges de travail sensibles à la sécurité

AWS Secrets Manager vous aide à gérer, récupérer et alterner les informations d'identification de base de données, les informations d'identification des applications, les jetons OAuth, les clés d'API et d'autres secrets tout au long de leur cycle de vie. Cette page fournit des conseils prescriptifs pour la gestion des clés d'API et des informations d'identification tierces dans les charges de travail sensibles à la sécurité. Combinez la rotation automatique avec les AWS KMS clés gérées par le client et les politiques IAM de moindre privilège. Configurez également l'accès aux terminaux VPC pour minimiser la fenêtre d'exposition et le rayon d'action d'un identifiant compromis.

Stockez les clés d'API dans AWS Secrets Manager

Cette section explique comment structurer les secrets de vos clés d'API pour optimiser la rotation et la récupération. Stockez chaque clé d'API en tant que secret distinct avec une valeur JSON structurée. Grâce à cette structure, votre application peut récupérer des champs individuels et Secrets Manager peut transmettre les valeurs correctes à une fonction de rotation.

L'exemple suivant montre une structure JSON courante pour les secrets de clé d'API tiers. Les champs réels dépendent des exigences de votre fournisseur. Consultez la documentation du fournisseur pour connaître les informations d'identification et les métadonnées spécifiques que vous devez stocker.

{
  "apiKey": "your-api-key-value",
  "apiKeyId": "key-identifier",
  "endpoint": "https://api.example.com/v1",
  "provider": "example-service"
}

Exemple de structure secrète pour les clés d'API

Champ	Exemple de valeur	Objectif
apiKey	sk_live_abc123...	La valeur d'identification utilisée par votre application pour s'authentifier auprès de l'API tierce.
apiKeyId	key_001	Identifiant de la clé du côté du fournisseur. Utilisée pendant la rotation pour créer une nouvelle clé et supprimer l'ancienne.
endpoint	https://api.example.com/v1	URL du point de terminaison de l'API Stockez avec la clé afin que la récupération renvoie tout ce dont l'application a besoin pour se connecter.
provider	stripe	Nom du fournisseur. Utile pour la logique des fonctions de balisage, de filtrage et de rotation qui gère plusieurs fournisseurs.

Étiquetez chaque secret avec des métadonnées pour prendre en charge les conditions de politique IAM et le filtrage organisationnel. Par exemple, vous pouvez associer des secrets à l'équipe propriétaire, à l'environnement et à l'étendue de conformité à l'aide de la console AWS CLI or :

aws secretsmanager tag-resource \
    --secret-id prod/payments/stripe-api-key \
    --tags Key=Team,Value=payments Key=Environment,Value=production \
           Key=Provider,Value=stripe Key=Compliance,Value=pci-dss

Pour plus d'informations sur la création de secrets, consultezCréez un AWS Secrets Manager secret.

Configuration du chiffrement

Secrets Manager chiffre chaque valeur secrète au repos à l'aide d'une AWS KMS clé. Pour les charges de travail sensibles à la sécurité, choisissez la clé de cryptage en fonction de vos exigences de conformité et de contrôle d'accès.

Options de clé KMS pour les secrets de clé d'API

Type de clé	Quand l’utiliser	Considérations sur la sécurité
AWS clé gérée (aws/secretsmanager)	Par défaut pour la plupart des charges de travail. Pas de frais supplémentaires ni de frais de gestion des clés.	La politique clé est limitée aux opérations de Secrets Manager uniquement et ne peut pas être modifiée. Ne peut pas être utilisé pour l'accès entre comptes.
Clé gérée par le client	Exigences de conformité (par exemple, PCI DSS, HIPAA, SOC 2 ou autres normes applicables). Cross-account partage secret. Principales exigences en matière d'audit d'utilisation.	Vous contrôlez la politique clé. Vous pouvez restreindre les principaux qui peuvent déchiffrer. Vous pouvez désactiver ou planifier la suppression d'une clé indépendamment du secret. Fournit une piste d'audit indépendante.

Pour les charges de travail sensibles à la sécurité, utilisez une clé gérée par le client avec les conditions de politique clés suivantes :

• kms:ViaService— Limitez l'utilisation des clés aux requêtes provenant de Secrets Manager (secretsmanager.<region>.amazonaws.com).

• kms:EncryptionContext:SecretARN— Limitez le déchiffrement à des ARN secrets spécifiques en faisant correspondre le contexte de chiffrement de Secrets Manager.

• Clés distinctes par limite de conformité : utilisez AWS KMS des clés différentes pour les secrets dans différents domaines de conformité (par exemple, PCI par rapport à non-PCI).

Pour une explication complète du processus de chiffrement et de déchiffrement, consultezChiffrement et déchiffrement secrets dans AWS Secrets Manager.

Rotation automatique des clés API

La rotation automatique réduit la fenêtre d'exposition des informations d'identification compromises. Secrets Manager invoque une fonction Lambda selon un calendrier. La fonction crée une nouvelle clé API chez le fournisseur, met à jour la valeur secrète et supprime l'ancienne clé.

Secrets Manager fournit des fonctions de rotation gérées pour certains fournisseurs tiers par le biais de secrets externes gérés. Pour plus d'informations sur cette fonctionnalité et la liste des fournisseurs pris en charge, consultezSecrets externes gérés Partenaires. Pour les fournisseurs ne prenant pas en charge la gestion de la rotation, vous implémentez une fonction de rotation Lambda personnalisée qui appelle l'API du fournisseur pour créer et supprimer des clés.

Cycle de vie des fonctions de rotation

Une fonction Lambda de rotation implémente quatre étapes. Secrets Manager appelle la fonction une fois pour chaque étape, en lui transmettant un Step paramètre. Si l'une des étapes échoue, Secrets Manager réessaie automatiquement l'intégralité de la rotation.

Étapes de rotation pour les clés d'API

Step (Étape)	Action pour les clés d'API	Gestion des défaillances
createSecret	Appelez l'API du fournisseur pour créer une nouvelle clé. Stockez la nouvelle valeur de clé dans Secrets Manager avec l'AWSPENDINGétiquette intermédiaire.	Si la création de la clé échoue, la rotation ne passe pas à l'étape suivante. La clé existante reste active en tant queAWSCURRENT.
setSecret	Pour les clés d'API créées chez le fournisseur, cette étape est généralement inopérante. Cette étape est utilisée lorsqu'une clé aléatoire est générée dans Secrets Manager et doit être définie chez le fournisseur, ce qui n'est pas le flux de clés d'API typique.	Si cette étape échoue, la rotation ne se poursuit pastestSecret.
testSecret	Récupérez la AWSPENDING valeur dans Secrets Manager et effectuez un appel d'API de test au fournisseur pour vérifier que la nouvelle clé fonctionne.	Si le test échoue, supprimez la clé en attente chez le fournisseur et déclenchez une exception.
finishSecret	Passez AWSCURRENT à la nouvelle touche. L'ancienne touche passe àAWSPREVIOUS. Supprimez éventuellement l'ancienne clé chez le fournisseur.	Si la mise à jour de l'étiquette échoue, la rotation n'est pas terminée. La nouvelle clé existe mais n'est pas encore étiquetéeAWSCURRENT.

Pour le modèle complet de fonction de rotation et les conseils de mise en œuvre, consultezFonctions de rotation lambda.

Configuration du calendrier de rotation

Définissez l'intervalle de rotation en fonction de vos exigences de conformité et de vos politiques de sécurité internes. Reportez-vous aux normes de conformité applicables à votre charge de travail pour déterminer la fréquence de rotation appropriée.

Utilisez une fenêtre de rotation pour contrôler le moment où la rotation se produit. Cela empêche la rotation de s'exécuter pendant les pics de trafic ou les périodes de maintenance :

aws secretsmanager rotate-secret \
    --secret-id prod/payments/stripe-api-key \
    --rotation-rules '{
        "ScheduleExpression": "cron(0 4 ? * SUN *)",
        "Duration": "2h"
    }'

Pour la syntaxe des expressions de planification, consultezHoraires de rotation.

Récupérez des secrets efficacement

Secrets Manager prend en charge 10 000 transactions par seconde sur GetSecretValue les appels. La plupart des applications ne sont pas soumises à des ralentissements. Pour les applications présentant des volumes d'appels très élevés ou des chemins sensibles à la latence, utilisez une solution de mise en cache afin de réduire les appels d'API et d'améliorer les temps de réponse.

Secrets Manager fournit des clients de mise en cache pour plusieurs langues, ainsi qu'une extension Lambda qui met en cache les secrets localement dans l'environnement d'exécution. Pour plus d'informations sur les options de mise en cache, consultez Obtenez une valeur secrète de Secrets Manager à l'aide de Java avec mise en cache côté clientObtenez une valeur secrète de Secrets Manager en utilisant Python avec mise en cache côté client, etObtenez une valeur secrète de Secrets Manager à l'aide de Go avec la mise en cache côté client.

Pour tous les modèles d'accès, configurez des politiques IAM qui secretsmanager:GetSecretValue se limitent aux secrets spécifiques dont chaque application a besoin :

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "secretsmanager:GetSecretValue",
    "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/payments/*",
    "Condition": {
      "StringEquals": {
        "aws:ResourceTag/Environment": "production"
      }
    }
  }]
}

Renforcement de la sécurité pour les charges de travail sensibles

Les pratiques suivantes fournissent une défense approfondie des clés d'API dans les environnements soumis à des exigences de sécurité strictes (par exemple, PCI DSS, SOC 2, HIPAA ou autres cadres de conformité applicables) :

Restreindre l'accès au réseau avec des points de terminaison VPC

Créez un point de terminaison VPC d'interface pour Secrets Manager afin que la récupération de secrets ne passe jamais par l'Internet public. Appliquez une politique de point de terminaison qui limite les secrets auxquels il est possible d'accéder via le terminal. Pour de plus amples informations, veuillez consulter Utilisation d'un point de AWS Secrets Manager terminaison VPC.

Appliquer les politiques relatives aux ressources aux secrets

Associez une politique de ressources à chaque secret qui refuse explicitement l'accès aux principaux extérieurs à votre compte ou à des points de terminaison VPC spécifiques. Cela fournit une deuxième limite d'autorisation indépendante des politiques d'identité IAM.

Surveillez les accès secrets avec

enregistre automatiquement tous les appels d'API Secrets ManagerGetSecretValue, y comprisPutSecretValue, etRotateSecret. Pour les secrets sensibles à la sécurité, créez une CloudWatch alarme Amazon qui se déclenche lors d'GetSecretValueappels inattendus, par exemple, des appels provenant d'adresses IP sources non reconnues ou de responsables IAM.

À utiliser AWSPREVIOUS pour une rotation élégante

Pendant la rotation, Secrets Manager conserve la valeur clé précédente avec l'AWSPREVIOUSétiquette intermédiaire. Si votre fournisseur invalide la clé précédente lors de la création d'une nouvelle clé, configurez votre application pour qu'elle revienne à AWSPREVIOUS si une erreur d'authentification est AWSCURRENT renvoyée. Cela permet d'éviter les interruptions pendant la brève période entre la création de la clé et la mise à jour de l'étiquette.

Validez les politiques relatives aux ressources avant de joindre

Les secrets sans politique relative aux ressources bloquent déjà l'accès public. Lorsque vous associez une politique de ressources à votre secret, utilisez l'ValidateResourcePolicyAPI pour vous assurer que votre politique n'accorde pas un accès public étendu. Vous pouvez également utiliser le BlockPublicPolicy paramètre with PutResourcePolicy pour empêcher de joindre des politiques qui accordent un accès public. Utilisez la clé de aws:PrincipalOrgID condition dans les politiques relatives aux ressources pour empêcher l'accès des principaux acteurs extérieurs à votre organisation.

Questions fréquentes (FAQ)

Cette section répond aux questions courantes concernant la rotation des clés d'API et la gestion des secrets dans AWS Secrets Manager.

Comment gérer la période de chevauchement pendant la rotation ?

Cela n'est nécessaire que si le fournisseur invalide la clé existante lors de la création d'une nouvelle clé. Si le fournisseur prend en charge plusieurs clés actives simultanément, les deux clés fonctionnent pendant la période de rotation sans logique de repli côté application. Pour les fournisseurs qui invalident l'ancienne clé, configurez votre application pour qu'elle réessaie AWSPREVIOUS si la clé actuelle renvoie une erreur 401 ou 403. Supprimez l'ancienne clé chez le fournisseur à l'finishSecretétape uniquement après avoir confirmé que la nouvelle clé fonctionne.

Et si mon fournisseur ne prend pas en charge la création de clés programmatiques ?

Si le fournisseur exige la création manuelle de clés (via une console Web, par exemple), vous ne pouvez pas entièrement automatiser la rotation. Utilisez plutôt une fonction de rotation qui envoie une notification (via Amazon Simple Notification Service) lorsque la rotation arrive à échéance, invitant un opérateur à créer la clé manuellement et à mettre à jour la valeur secrète. Définissez le calendrier de rotation en fonction de vos exigences de conformité en matière de rotation et activez CloudWatch les alarmes Amazon days_since_last_rotation pour détecter les rotations manquées.

Comment éviter la limitation des API lors de la récupération de secrets ?

Secrets Manager prend en charge 10 000 transactions par secondeGetSecretValue. La plupart des applications ne sont pas soumises à des ralentissements. Si votre application effectue un volume d'appels exceptionnellement élevé, utilisez un client de mise en cache ou l'extension Lambda Parameters and Secrets. Ils mettent en cache la valeur secrète en mémoire et sont actualisés périodiquement, ce qui réduit le nombre d'appels d'API. Définissez le TTL du cache sur une valeur inférieure à votre intervalle de rotation afin que l'application récupère les nouvelles clés après la rotation.

Dois-je utiliser un secret par environnement ou un secret avec les versions ?

Utilisez des secrets distincts pour chaque environnement (par exemple, prod/payments/stripe etdev/payments/stripe). Cela permet d'appliquer des politiques IAM, des calendriers de rotation et des clés de chiffrement différents par environnement. Les versions secrètes (étiquettes intermédiaires) sont destinées à la gestion de l'état de rotation, et non à la séparation des environnements.