SEC09-BP01 Implémenter la gestion sécurisée des clés et des certificats - Pilier Sécurité

SEC09-BP01 Implémenter la gestion sécurisée des clés et des certificats

Les certificats du protocole TLS (Transport Layer Security) permettent de sécuriser les communications réseau et établir l’identité des sites Web, des ressources et des charges de travail sur Internet, ainsi que sur les réseaux privés.

Résultat escompté : un système de gestion des certificats sécurisé qui peut provisionner, déployer, stocker et renouveler des certificats dans une infrastructure à clé publique (PKI). Un mécanisme sécurisé de gestion des clés et des certificats empêche la divulgation de la clé privée du certificat et renouvelle automatiquement et périodiquement le certificat. Il s’intègre également à d’autres services pour fournir des communications réseau et une identité sécurisées pour les ressources de la machine au sein de votre charge de travail. Les clés ne doivent jamais être accessibles aux identités humaines.

Anti-modèles courants :

  • Exécuter des étapes manuelles au cours des processus de déploiement ou de renouvellement des certificats.

  • Ne pas accorder suffisamment d’attention à la hiérarchie de l’autorité de certification (AC) lors de la conception d’une AC privée.

  • Utiliser des certificats auto-signés pour les ressources publiques.

Avantages liés au respect de cette bonne pratique :

  • Simplifiez la gestion des certificats en automatisant leur déploiement et leur renouvellement

  • Encouragez le chiffrage des données en transit à l’aide de certificats TLS

  • Amélioration de la sécurité et de l’auditabilité des actions de certification entreprises par l’autorité de certification

  • Organisation des tâches de gestion à différents niveaux de la hiérarchie de l’AC

Niveau d’exposition au risque si cette bonne pratique n’est pas respectée : élevé

Directives d’implémentation

Les charges de travail modernes font un usage intensif des communications réseau chiffrées à l’aide de protocoles PKI tels que le protocole TLS. La gestion des certificats PKI peut être complexe, mais le provisionnement, le déploiement et le renouvellement automatisés des certificats peuvent réduire les inconvénients liés à la gestion des certificats.

AWS fournit deux services pour gérer les certificats PKI à usage général : AWS Certificate Manager et AWS Private Certificate Authority (AWS Private CA). ACM est le principal service que les clients utilisent pour provisionner, gérer et déployer des certificats destinés à être utilisés dans des charges de travail AWS publiques et privées. ACM émet des certificats privés en utilisant AWS Private CA et s’intègre à de nombreux autres services gérés par AWS pour fournir des certificats TLS sécurisés pour les charges de travail. ACM peut également délivrer des certificats reconnus publiquement à partir d’Amazon Trust Services. Les certificats publics d’ACM peuvent être utilisés sur des charges de travail destinées au public, car les navigateurs et les systèmes d’exploitation modernes approuvent par défaut ces certificats.

AWS Private CA vous permet d’établir votre propre autorité de certification racine ou subordonnée et d’émettre des certificats TLS par l’intermédiaire d’une API. Vous pouvez utiliser ce type de certificats dans des scénarios où vous contrôlez et gérez la chaîne de confiance du côté client de la connexion TLS. En plus des cas d’utilisation TLS, AWS Private CA peut émettre des certificats à des pods Kubernetes, des attestations produits pour appareils Matter, une signature de code et d’autres cas d’utilisation avec un modèle personnalisé. Vous pouvez également utiliser Rôles Anywhere IAM pour fournir des informations d’identification IAM temporaires aux charges de travail sur site qui ont reçu des certificats X.509 signés par votre autorité de certification privée.

Outre ACM et AWS Private CA, AWS IoT Core fournit un support spécialisé pour le provisionnement, la gestion et le déploiement de certificats PKI sur les appareils IoT. AWS IoT Core fournit des mécanismes spécialisés pour intégrer des appareils IoT dans votre infrastructure à clé publique à grande échelle.

Certains services AWS, tels qu’Amazon API Gateway et Elastic Load Balancing, proposent leurs propres fonctionnalités d’utilisation de certificats pour sécuriser les connexions des applications. Par exemple, API Gateway et Application Load Balancer (ALB) prennent en charge le protocole TLS mutuel (mTLS) à l’aide de certificats client que vous créez et exportez à l’aide de la AWS Management Console, de CLI ou des API.

Considérations relatives à l’établissement d’une hiérarchie d’autorité de certification privée

Lorsque vous devez établir une autorité de certification privée, il est important de prendre soin de concevoir correctement la hiérarchie de l’autorité de certification dès le départ. La bonne pratique consiste à déployer chaque niveau de votre hiérarchie d’autorité de certification dans des Comptes AWS distincts lorsque vous créez une hiérarchie d’autorité de certification privée. Cette étape intentionnelle réduit la surface de chaque niveau de la hiérarchie de l’autorité de certification, ce qui facilite la découverte d’anomalies dans les données de journalisation CloudTrail et réduit l’étendue de l’accès ou l’impact en cas d’accès non autorisé à l’un des comptes. L’autorité de certification racine doit résider dans son propre compte et ne doit être utilisée que pour émettre un ou plusieurs certificats d’autorité de certification intermédiaire.

Créez ensuite une ou plusieurs autorités de certification intermédiaires dans des comptes distincts du compte de l’autorité de certification racine afin d’émettre des certificats pour les utilisateurs finaux, les appareils ou d’autres charges de travail. Enfin, émettez des certificats à partir de votre autorité de certification racine vers les autorités de certification intermédiaires, qui émettront à leur tour des certificats vers vos utilisateurs finaux ou vos appareils. Pour plus d’informations sur la planification du déploiement des AC et la conception de la hiérarchie des AC, y compris la planification de la résilience, la réplication interrégionale, le partage des AC au sein de votre organisation et plus encore, voir Planifier votre déploiement AWS Private CA.

Étapes d’implémentation

  1. Déterminez les services AWS pertinents requis pour votre cas d’utilisation :

    • De nombreux cas d’utilisation peuvent s’appuyer sur l’infrastructure de clés publiques existante d’AWS à l’aide d’AWS Certificate Manager. ACM peut déployer des certificats TLS pour les serveurs Web, les équilibreurs de charge ou d’autres utilisations pour des certificats publiquement approuvés.

    • Envisagez AWS Private CA si vous devez établir votre propre hiérarchie d’autorité de certification privée ou si vous avez besoin d’accéder à des certificats exportables. ACM peut ensuite être utilisé pour émettre de nombreux types de certificats d’entité finale à l’aide du AWS Private CA.

    • Pour les cas d’utilisation où les certificats doivent être provisionnés à grande échelle pour les appareils de l’Internet des objets (IoT) embarqués, envisagez AWS IoT Core.

    • Envisagez d’utiliser les fonctionnalités mTLS natives dans des services tels qu’Amazon API Gateway ou Application Load Balancer.

  2. Mettez en œuvre le renouvellement automatisé des certificats dans la mesure du possible :

  3. Établissez des journaux et des pistes d’audit :

    • Activez les journaux CloudTrail pour suivre l’accès aux comptes détenant des autorités de certification. Envisagez de configurer la validation de l’intégrité des fichiers journaux dans CloudTrail pour vérifier l’authenticité des données du journal.

    • Vous pouvez générer des rapports d’audit qui répertorient les certificats émis et révoqués par votre autorité de certification privée. Ces rapports peuvent être exportés vers un compartiment S3.

    • Lors du déploiement d’une autorité de certification privée, vous devrez également créer un compartiment S3 pour stocker la liste de révocation des certificats (CRL). Pour obtenir des conseils sur la configuration de ce compartiment S3 en fonction des exigences de votre charge de travail, voir Planification d’une liste de révocation de certificats (CRL).

Ressources

Bonnes pratiques associées :

Documents connexes :

Vidéos connexes :

Exemples connexes :

Outils associés :