Chiffrez le trafic Amazon ECS Service Connect - Amazon Elastic Container Service

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Chiffrez le trafic Amazon ECS Service Connect

Amazon ECS Service Connect prend en charge le chiffrement automatique du trafic à l'aide de certificats Transport Layer Security (TLS) pour les ECS services Amazon. Lorsque vous pointez vos ECS services Amazon vers un AWS Private Certificate Authority (AWS Private CA), Amazon fournit ECS automatiquement des TLS certificats pour chiffrer le trafic entre vos services Amazon ECS Service Connect. Amazon ECS génère, fait alterner et distribue les TLS certificats utilisés pour le chiffrement du trafic.

Le chiffrement automatique du trafic avec Service Connect utilise des fonctionnalités de chiffrement de pointe pour sécuriser vos communications interservices afin de répondre à vos exigences en matière de sécurité. Il prend en charge AWS Private Certificate Authority TLS les certificats 256-bit ECDSA et 2048-bit RSA le cryptage. Par défaut, la version TLS 1.3 est prise en charge, mais les TLS versions 1.0 à 1.2 ne sont pas prises en charge. Vous avez également un contrôle total sur les certificats privés et les clés de signature pour vous aider à respecter les exigences de conformité.

Note

Pour utiliser la version TLS 1.3, vous devez l'activer sur l'écouteur de la cible.

Seul le trafic entrant et sortant passant par l'ECSagent Amazon est chiffré.

AWS Private Certificate Authority certificats et Service Connect

Des IAM autorisations supplémentaires sont requises pour délivrer des certificats. Amazon ECS fournit une politique de confiance en matière de ressources gérées qui décrit l'ensemble des autorisations. Pour plus d'informations sur cette politique, consultez mazonECSInfrastructureRolePolicyForServiceConnectTransportLayerSecurityA.

AWS Private Certificate Authority modes pour Service Connect

AWS Private Certificate Authority peut fonctionner selon deux modes : usage général et de courte durée.

  • Usage général ‐ Certificats pouvant être configurés avec n'importe quelle date d'expiration.

  • De courte durée ‐ Certificats d'une durée de validité maximale de sept jours.

Amazon ECS prend en charge les deux modes, mais nous vous recommandons d'utiliser des certificats de courte durée. Par défaut, les certificats sont renouvelés tous les cinq jours, et leur utilisation en mode éphémère permet de réaliser des économies importantes par rapport à un usage général.

Service Connect ne prend pas en charge la révocation des certificats et utilise plutôt des certificats de courte durée avec une rotation fréquente des certificats. Vous avez le droit de modifier la fréquence de rotation, de désactiver ou de supprimer les secrets à l'aide de la rotation gérée dans Secrets Manager, mais cela peut avoir les conséquences suivantes.

  • Fréquence de rotation plus courte ‐ Une fréquence de rotation plus courte entraîne des coûts plus élevés en raison AWS Private CA de l'augmentation de la charge de travail liée à la rotation entre Secrets Manager et Auto Scaling. AWS KMS

  • Fréquence de rotation plus longue ‐ Les communications de vos applications échouent si la fréquence de rotation dépasse sept jours.

  • Suppression du secret ‐ La suppression du secret entraîne l'échec de la rotation et a un impact sur les communications des applications clientes.

En cas d'échec de votre rotation secrète, un RotationFailed événement est publié dans AWS CloudTrail. Vous pouvez également configurer une CloudWatch alarme pourRotationFailed.

Important

N'ajoutez pas de répliques de régions aux secrets. Cela ECS empêche Amazon de supprimer le secret, car Amazon ECS n'est pas autorisé à supprimer les régions de la réplication. Si vous avez déjà ajouté la réplication, exécutez la commande suivante.

aws secretsmanager remove-regions-from-replication \ --secret-id SecretId \ --remove-replica-regions region-name
Autorités de certification subordonnées

Vous pouvez en apporter n'importe quel AWS Private CA, root ou subordonné, à Service Connect TLS pour délivrer des certificats d'entité finale pour les services. L'émetteur indiqué est considéré comme le signataire et la source de confiance partout. Vous pouvez émettre des certificats d'entité finale pour différentes parties de votre application auprès de différents subordonnésCAs. Lorsque vous utilisez le AWS CLI, fournissez le nom de ressource Amazon (ARN) de l'autorité de certification pour établir la chaîne de confiance.

Autorités de certification locales

Pour utiliser votre autorité de certification locale, vous devez créer et configurer une autorité de certification subordonnée dans. AWS Private Certificate Authority Cela garantit que tous les TLS certificats émis pour vos ECS charges de travail Amazon partagent la chaîne de confiance avec les charges de travail que vous exécutez sur site et sont en mesure de se connecter en toute sécurité.

Important

Ajoutez le tag requis AmazonECSManaged : true dans votre AWS Private CA.

Infrastructure en tant que code

Lorsque vous utilisez les outils Service Connect TLS with Infrastructure as Code (IaC), il est important de configurer correctement vos dépendances afin d'éviter des problèmes tels que le blocage des services. Votre AWS KMS clé, le cas échéant, votre IAM rôle et vos AWS Private CA dépendances doivent être supprimés après votre ECS service Amazon.

Service Connect et Secrets Manager

Lorsque vous utilisez Amazon ECS Service Connect avec TLS chiffrement, le service interagit avec Secrets Manager de la manière suivante :

Service Connect utilise le rôle d'infrastructure fourni pour créer des secrets dans Secrets Manager. Ces secrets sont utilisés pour stocker les clés privées associées à vos TLS certificats afin de chiffrer le trafic entre vos services Service Connect.

Avertissement

La création et la gestion automatiques de ces secrets par Service Connect rationalisent le processus de mise en œuvre du TLS chiffrement pour vos services. Toutefois, il est important de connaître les implications potentielles en matière de sécurité. IAMLes autres rôles disposant d'un accès en lecture à Secrets Manager peuvent accéder à ces secrets créés automatiquement. Cela pourrait exposer du matériel cryptographique sensible à des parties non autorisées, si les contrôles d'accès ne sont pas correctement configurés.

Pour atténuer ce risque, suivez les bonnes pratiques suivantes :

  • Gérez et limitez soigneusement l'accès à Secrets Manager, en particulier pour les secrets créés par Service Connect.

  • Auditez régulièrement IAM les rôles et leurs autorisations afin de garantir le respect du principe du moindre privilège.

Lorsque vous accordez un accès en lecture à Secrets Manager, pensez à exclure les clés TLS privées créées par Service Connect. Vous pouvez le faire en utilisant une condition dans vos IAM politiques pour exclure les secrets ARNs qui correspondent au modèle :

"arn:aws:secretsmanager:::secret:ecs-sc!"

Exemple IAM de politique qui refuse l'GetSecretValueaction à tous les secrets avec le ecs-sc! préfixe :

{ "Version": "2012-10-17", "Statement": [ { "Effect": "Deny", "Action": "secretsmanager:GetSecretValue", "Resource": "arn:aws:secretsmanager:*:*:secret:ecs-sc!*" } ] }
Note

Il s'agit d'un exemple général qui devra peut-être être ajusté en fonction de votre cas d'utilisation spécifique et de la configuration de votre AWS compte. Testez toujours vos IAM politiques de manière approfondie pour vous assurer qu'elles fournissent l'accès prévu tout en préservant la sécurité.

En comprenant comment Service Connect interagit avec Secrets Manager, vous pouvez mieux gérer la sécurité de vos ECS services Amazon tout en tirant parti des avantages du TLS chiffrement automatique.

Service Connect et AWS Key Management Service

Vous pouvez l'utiliser AWS Key Management Servicepour chiffrer et déchiffrer vos ressources Service Connect. AWS KMS est un service géré par AWS lequel vous pouvez créer et gérer des clés cryptographiques qui protègent vos données.

Lorsque vous utilisez AWS KMS Service Connect, vous pouvez choisir d'utiliser une clé AWS détenue qui AWS gère pour vous ou de choisir une AWS KMS clé existante. Vous pouvez également créer une nouvelle AWS KMS clé à utiliser.

Fournir votre propre clé de chiffrement

Vous pouvez fournir vos propres éléments clés ou utiliser un magasin de clés externe via AWS Key Management Service Importer votre propre clé dans AWS KMS, puis spécifier le nom de ressource Amazon (ARN) de cette clé dans Amazon ECS Service Connect.

Voici un exemple de AWS KMS politique. Remplacez le user input valeurs associées aux vôtres.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "id", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:role/role-name" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey", "kms:GenerateDataKeyPair" ], "Resource": "*" } ] }

Pour de plus amples informations sur les stratégies de clé, veuillez consulter Création d'une stratégie de clé dans le Guide du AWS Key Management Service développeur.

Note

Service Connect prend uniquement en charge les AWS KMS clés de chiffrement symétriques. Vous ne pouvez utiliser aucun autre type de AWS KMS clé pour crypter vos ressources Service Connect. Pour savoir si une AWS KMS clé est symétrique, consultez Identification de clés asymétriques KMS.

Pour plus d'informations sur les clés de chiffrement AWS Key Management Service symétriques, consultez la section AWS KMS Clés de chiffrement symétriques dans le manuel du AWS Key Management Service développeur.