Architectures de référence pour Cloud External Key Manager

Lorsque vous activez Cloud Key Management Service (Cloud KMS) avec Cloud External Key Manager (Cloud EKM), vous pouvez utiliser les clés que vous gérez avec un partenaire externe de gestion de clés pour protéger les données dansGoogle Cloud. Ce document décrit les architectures destinées aux clients Google Cloud qui souhaitent déployer un service de gestion de clés externes (EKM) à disponibilité élevée avec Cloud KMS et Cloud EKM.

L'utilisation de Cloud EKM avec votre service EKM implique un compromis explicite entre la fiabilité des charges de travail cloud et les contrôles de protection des données. Le chiffrement des données au repos dans le cloud à l'aide de clés de chiffrement hors cloud ajoute de nouveaux risques d'échec qui peuvent rendre les données des services Google Cloud inaccessibles. Pour faire face à ces risques, vous devez intégrer la haute disponibilité et la tolérance aux pannes dans l'architecture Cloud EKM.

Présentation

Cloud EKM vous permet d'utiliser des éléments clés qui restent en dehors de Google Cloud pour contrôler l'accès à vos données stockées dans les services Google Cloudcompatibles. Les clés Cloud EKM sont des clés de chiffrement gérées par le client (CMEK). Cloud EKM vous permet de créer et de gérer des ressources de clés Cloud KMS avec les niveaux de protection EXTERNAL et EXTERNAL_VPC. Lorsque vous activez Cloud EKM, chaque demande d'opération de chiffrement entraîne une opération de chiffrement sur la clé externe. Le succès de l'opération de requête initiale dépend de manière critique du résultat de l'opération cryptographique sur la clé externe.

Cloud KMS demande des opérations sur des clés externes à l'aide d'une API à usage spécifique qui s'intègre à votre système de gestion de clés externe. Ce document fait référence à un service qui fournit cette API en tant que service EKM.

Si un service EKM devient indisponible, les lectures et les écritures à partir des plans de données pour les services Google Cloud intégrés peuvent échouer. Ces échecs s'affichent de la même manière que lorsque la clé Cloud KMS dépendante est inutilisable (par exemple, lorsqu'elle est désactivée). Le message d'erreur décrit la source de l'erreur et la marche à suivre. De plus, les journaux d'audit des accès aux données Cloud KMS incluent un enregistrement de ces messages d'erreur ainsi que des types d'erreur descriptifs. Pour en savoir plus, consultez la documentation de référence sur les erreurs Cloud EKM.

Bonnes pratiques pour les architectures Cloud EKM

Le livre de Google sur l'ingénierie de la fiabilité des sites décrit les bonnes pratiques qui vous aideront à développer et à gérer des systèmes fiables. Cette section décrit certaines de ces pratiques dans le contexte de l'intégration de votre service EKM à Google Cloud. Les bonnes pratiques suivantes s'appliquent aux architectures de référence Cloud EKM :

• Configurer une connectivité réseau fiable à faible latence
• Activer la haute disponibilité
• Détecter et atténuer rapidement les défaillances

Configurer une connectivité réseau fiable à faible latence

Cloud KMS se connecte aux services EKM à l'aide d'un réseau de cloud privé virtuel (VPC) ou d'Internet. Les solutions VPC utilisent souvent une connectivité hybride pour héberger le service EKM dans un centre de données sur site. La connexion entreGoogle Cloud et le centre de données doit être rapide et fiable. Lorsque vous utilisez Internet, vous avez besoin d'une accessibilité stable et ininterrompue, ainsi que d'une résolution DNS rapide et fiable. Du point de vue de Google Cloud, toute interruption peut entraîner l'indisponibilité du service EKM et l'impossibilité d'accéder aux données protégées par EKM.

Lorsque le plan de données d'un service Google Cloud communique avec le service EKM, chaque appel lié au service EKM dispose d'un délai d'expiration défini (150 millisecondes). Le délai avant expiration est mesuré à partir du service Cloud KMS dans l'emplacement Google Cloud de la clé Cloud KMS. Si l'emplacementGoogle Cloud est une multirégion, le délai commence dans la région où Cloud KMS reçoit la requête, qui est généralement celle où l'opération sur la ressource de données protégée par CMEK a eu lieu. Ce délai est suffisant pour permettre à un service EKM de traiter les requêtes dans une régionGoogle Cloud proche de celle d'où proviennent les requêtes.

Le délai d'expiration permet d'éviter les défaillances en cascade dans les services en aval qui dépendent de la clé externe. Les problèmes de latence de queue qui pourraient normalement entraîner une mauvaise expérience utilisateur dans les applications de niveau supérieur peuvent en fait se manifester par des échecs d'accès à la clé externe, ce qui entraîne l'échec de l'opération logique de niveau supérieur.

Pour minimiser la latence et créer des réseaux fiables, tenez compte des points suivants :

• Réduisez la latence de la communication aller-retour avec Cloud KMS : configurez le service EKM pour qu'il traite les requêtes aussi près que possible des emplacements Google Cloud correspondant aux clés Cloud KMS configurées pour utiliser le service EKM. Pour en savoir plus, consultez Bonnes pratiques pour la sélection des régions Compute Engine et Régions et zones.
• Utilisez Cloud Interconnect lorsque cela est possible : Cloud Interconnect crée une connexion à disponibilité élevée et à faible latence entre Google Cloudet votre centre de données à l'aide d'un réseau VPC, et permet de supprimer les dépendances sur Internet.
• Déployez Google Cloud des solutions de mise en réseau dans la région la plus proche du service EKM, si nécessaire : idéalement, les clés Cloud KMS sont stockées dans la région la plus proche du service EKM. S'il existe une régionGoogle Cloud plus proche du service EKM que la région contenant les clés Cloud KMS, utilisez des solutions de mise en réseau Google Cloud , telles que Cloud VPN, dans la région la plus proche du service EKM. Cette option permet de s'assurer que le trafic réseau utilise l'infrastructure Google lorsque cela est possible, ce qui réduit la dépendance à Internet.
• Utilisez les réseaux de niveau Premium lorsque le trafic EKM transite par Internet : Le niveau Premium achemine le trafic sur Internet à l'aide de l'infrastructure de Google dans la mesure du possible pour améliorer la fiabilité et réduire la latence.
• Utilisez un délai client approprié : si vous appelez directement l'API Cloud KMS pour les clés Cloud EKM, configurez un délai client d'au moins 10 secondes pour laisser suffisamment de temps aux opérations de clé externe pour se terminer.

Activer la haute disponibilité

L'existence d'un point de défaillance unique dans le service EKM réduit la disponibilité des ressources Google Cloud dépendantes à celle du point de défaillance unique. Ces points de défaillance peuvent se trouver dans les dépendances critiques du service EKM, ainsi que dans l'infrastructure de calcul et de réseau sous-jacente.

Pour activer la haute disponibilité, tenez compte des points suivants :

• Déployez des répliques dans des domaines de défaillance indépendants : déployez au moins deux répliques du service EKM. Si vous utilisez des emplacements multirégionaux Google Cloud, déployez EKM dans au moins deux emplacements géographiques distincts avec au moins deux répliques chacun. Assurez-vous que chaque réplica ne représente pas uniquement un plan de données répliqué du service EKM en minimisant et en renforçant les vecteurs de défaillance inter-réplicas. Voici quelques exemples :
  • Configurez les modifications de production, y compris les envois binaires et de configuration du serveur, pour ne modifier qu'un seul réplica à la fois. Vérifiez que toutes les modifications sont effectuées sous supervision, avec des rollbacks testés et facilement disponibles.
  • Comprendre et minimiser les modes de défaillance inter-répliques de l'infrastructure sous-jacente. Par exemple, assurez-vous que les répliques dépendent d'alimentations indépendantes et redondantes.

• Rendez les répliques résilientes aux pannes de machines individuelles : vérifiez que chaque réplique du service se compose d'au moins trois appliances, machines ou hôtes de VM. Cette configuration permet au système de diffuser du trafic lorsqu'une machine est hors service pour des mises à jour ou en cas de panne inattendue (provisionnement N+2).

  Remarque : Les clés externes dans un emplacement multirégional Cloud KMS doivent utiliser Internet, car le service EKM ne peut pas accéder aux emplacements multirégionaux à l'aide du cloud privé virtuel. Pour en savoir plus, consultez Gestionnaires de clés externes et régions.

• Limitez la zone concernée par les problèmes liés au plan de contrôle : configurez le plan de contrôle (par exemple, la création ou la suppression de clés) du service EKM pour répliquer la configuration ou les données sur les répliques. Ces opérations sont généralement plus complexes, car elles nécessitent une synchronisation et affectent toutes les répliques. Les problèmes peuvent se propager rapidement et affecter l'ensemble du système. Voici quelques stratégies pour réduire l'impact des problèmes :

  • Contrôlez la vitesse de propagation : par défaut, assurez-vous que les modifications se propagent aussi lentement que possible pour la facilité d'utilisation et la sécurité. Configurez des exceptions si nécessaire, par exemple pour autoriser l'accès à une clé afin qu'elle se propage rapidement et qu'un utilisateur puisse annuler une erreur.
  • Partitionnez le système en fragments : si de nombreux utilisateurs partagent l'EKM, partitionnez-les en fragments logiques complètement indépendants, de sorte que les problèmes déclenchés par un utilisateur dans un fragment ne puissent pas affecter les utilisateurs d'un autre fragment.
  • Prévisualisez l'effet des modifications : si possible, laissez les utilisateurs voir l'effet des modifications avant de les appliquer. Par exemple, lors de la modification d'une règle d'accès aux clés, l'EKM peut confirmer le nombre de requêtes récentes qui auraient été refusées en vertu de la nouvelle règle.
  • Implémentez le canarying de données : commencez par transférer les données vers un petit sous-ensemble du système. Si le sous-ensemble reste opérationnel, transférez les données au reste du système.

• Implémentez des vérifications d'état holistiques : créez des vérifications d'état qui mesurent le fonctionnement de l'ensemble du système. Par exemple, les vérifications de l'état qui ne valident que la connectivité réseau ne sont pas utiles pour répondre à de nombreux problèmes au niveau de l'application. Dans l'idéal, la vérification de l'état reflète fidèlement les dépendances du trafic réel.

• Configurez le basculement entre les répliques : configurez l'équilibrage de charge dans les composants de votre service EKM de sorte qu'il consomme les vérifications de l'état et draine activement le trafic des répliques non opérationnelles, puis bascule de manière sécurisée vers les répliques opérationnelles.

• Incluez des mécanismes de sécurité pour gérer la surcharge et éviter les défaillances en cascade : les systèmes peuvent être surchargés pour différentes raisons. Par exemple, lorsque certaines répliques ne sont plus opérationnelles, le trafic redirigé vers les répliques opérationnelles peut les surcharger. Face à un nombre de requêtes supérieur à ce qu'il peut traiter, le système doit essayer de traiter ce qu'il peut de manière sûre et rapide, tout en rejetant le trafic excédentaire.

• Assurez-vous d'avoir une stratégie de durabilité robuste : les données dans Google Cloud chiffrées avec une clé externe dans le service EKM sont irrécupérables sans la clé externe. La durabilité des clés est donc l'une des exigences de conception centrales du service EKM. Configurez le service EKM pour sauvegarder de manière sécurisée des copies redondantes de matériel de clé dans plusieurs emplacements physiques. Configurez des mesures de protection supplémentaires, telles que des sauvegardes hors connexion, pour les clés de grande valeur. Assurez-vous que vos mécanismes de suppression prévoient un délai de récupération en cas d'accident ou de bug.

Détecter et atténuer rapidement les défaillances

Chaque minute d'indisponibilité du service EKM peut rendre inaccessibles les ressources dépendantes Google Cloud, ce qui peut augmenter le risque de défaillance en cascade d'autres composants dépendants de votre infrastructure.

Pour détecter et atténuer rapidement les échecs, tenez compte des points suivants :

• Configurez le service EKM pour qu'il génère des rapports sur les métriques qui signalent les incidents menaçant la fiabilité : configurez des métriques telles que les taux d'erreur de réponse et les latences de réponse pour détecter rapidement les problèmes.
• Mettez en place des pratiques opérationnelles pour la notification et l'atténuation rapides des incidents : quantifiez l'efficacité des pratiques opérationnelles en suivant les métriques de temps moyen de détection (MTTD) et de temps moyen de récupération (MTTR), et définissez des objectifs mesurés par ces métriques. Grâce à ces métriques, vous pouvez identifier les tendances et les lacunes dans les processus et systèmes actuels afin de pouvoir réagir rapidement aux incidents.

Architectures de référence pour Cloud EKM

Les architectures suivantes décrivent quelques façons de déployer le service EKM à l'aide des produits de mise en réseau et d'équilibrage de chargeGoogle Cloud .

Connexion directe via Cloud VPN ou Cloud Interconnect

Une connexion directe entre Google Cloud et votre centre de données sur site est recommandée lorsque vous exécutez des applications à haut débit surGoogle Cloud et que le service EKM s'exécute dans un seul centre de données. Le schéma suivant illustre cette architecture.

Dans cette architecture, Cloud EKM accède au service EKM situé dans un centre de données sur site via une connectivité hybride dans la région sans équilibrage de charge intermédiaire dans Google Cloud.

Dans la mesure du possible, déployez la connexion de service Cloud EKM vers EKM à l'aide de la configuration de disponibilité à 99,9% pour les applications à une seule région. La configuration de disponibilité à 99,99% nécessite d'utiliser Cloud Interconnect dans plusieurs régions Google Cloud, ce qui peut ne pas répondre à vos besoins si votre entreprise nécessite une isolation régionale. Si la connexion au centre de données sur site utilise Internet, utilisez VPN haute disponibilité au lieu de Cloud Interconnect.

Le principal avantage de cette architecture est qu'il n'y a pas de sauts intermédiaires dans Google Cloud, ce qui réduit la latence et les éventuels goulots d'étranglement. Si vous souhaitez configurer une connexion directe lorsque votre service EKM est hébergé dans plusieurs centres de données, vous devez configurer des équilibreurs de charge dans tous les centres de données qui utilisent la même adresse IP (anycast). Si vous utilisez cette configuration, l'équilibrage de charge et le basculement entre les centres de données sont limités à la disponibilité des routes uniquement.

Si vous configurez un réseau VPC, les clés externes accessibles via le réseau VPC doivent utiliser un emplacement régional dans Cloud KMS. Les clés ne peuvent pas utiliser d'emplacement multirégional. Pour en savoir plus, consultez Gestionnaires de clés externes et régions.

Équilibrage de charge depuis Internet dans Google Cloud

Il est recommandé d'utiliser un équilibreur de charge dans Google Cloud avec une connexion Internet lorsque vous avez besoin de clés Cloud KMS multirégionales. Le schéma suivant illustre cette architecture.

Dans cette architecture, l'EKM comporte des répliques dans deux sites sur site. Chaque backend est représenté dans Google Cloud à l'aide d'un groupe de points de terminaison du réseau (NEG) de connectivité hybride. Le déploiement utilise un équilibreur de charge réseau proxy externe pour transférer le trafic directement vers l'un des réplicas. Contrairement aux autres approches, qui s'appuient sur la mise en réseau VPC, l'équilibreur de charge réseau proxy externe possède une adresse IP externe et le trafic provient d'Internet.

Chaque NEG de connectivité hybride peut contenir plusieurs adresses IP, ce qui permet à l'équilibreur de charge réseau proxy externe d'équilibrer le trafic directement vers les instances du service EKM. Un équilibreur de charge supplémentaire n'est pas nécessaire dans le centre de données sur site.

L'équilibreur de charge réseau proxy externe n'est pas lié à une région spécifique. Il peut rediriger le trafic entrant vers la région opérationnelle la plus proche, ce qui le rend adapté aux clés Cloud KMS multirégionales. Toutefois, l'équilibreur de charge ne permet pas de configurer des backends principaux et de secours. Le trafic est réparti de manière égale entre plusieurs backends d'une région.

Équilibrage de charge dans un réseau VPC dans Google Cloud

Il est recommandé d'utiliser un équilibreur de charge dans Google Cloud avec un réseau VPC pour la plupart des services EKM où vous déployez votre EKM. Le schéma suivant illustre cette architecture.

Dans cette architecture, Cloud EKM accède au service EKM répliqué entre deux centres de données sur site via une connectivité hybride avec des couches d'équilibrage de charge intermédiaire dans la région Google Cloud . Si la connexion au centre de données sur site utilise Internet, vous pouvez utiliser VPN haute disponibilité au lieu de Cloud Interconnect.

L'équilibreur de charge réseau passthrough interne fournit une adresse IP unique que les ressources peuvent utiliser pour envoyer du trafic à l'aide de la mise en réseau virtuelle. L'équilibreur de charge bascule vers le centre de données de sauvegarde en fonction de l'état des backends.

Le groupe d'instances de VM est nécessaire pour le trafic proxy, car l'équilibreur de charge interne ne peut pas router le trafic directement vers les backends sur site. Vous pouvez déployer des proxys d'équilibreur de charge pour exécuter des images Docker Nginx à partir de la place de marché Cloud dans des groupes d'instances. Vous pouvez utiliser Nginx comme équilibreur de charge TCP.

Étant donné que cette approche utilise des équilibreurs de charge dans Google Cloud, vous n'avez pas besoin d'un équilibreur de charge sur site. Les équilibreurs de charge Google Cloud peuvent se connecter directement aux instances du service EKM et répartir la charge entre elles. L'élimination de l'équilibreur de charge sur site simplifie la configuration, mais réduit la flexibilité disponible dans le service EKM. Par exemple, un équilibreur de charge L7 sur site peut relancer automatiquement les requêtes si une instance EKM renvoie une erreur.

Si vous configurez un réseau VPC, les clés externes accessibles via le réseau VPC doivent utiliser un emplacement régional dans Cloud KMS. Les clés ne peuvent pas utiliser d'emplacement multirégional. Pour en savoir plus, consultez Gestionnaires de clés externes et régions.

Comparaison des architectures de référence

Le tableau suivant compare les options d'architecture de référence pour Cloud EKM. Le tableau comprend également une colonne pour l'architecture EKM gérée par le partenaire. Dans ce scénario, le partenaire est responsable du déploiement et de la gestion d'EKM, et fournit EKM en tant que service aux clients.

Option	Connexion directe	Équilibrage de charge depuis Internet	Équilibrage de charge dans un réseau VPC	EKM entièrement géré fourni par un partenaire
Internet ou réseau VPC	VPC	Internet	VPC	Internet
Équilibreur de charge dans Google Cloud	Non	Oui	Oui	Non
Équilibreur de charge sur site requis	Oui	Non	Non	Oui (gérée par un partenaire)
Compatible avec les emplacements multirégionaux Cloud KMS	Non	Oui	Non	Oui
Recommandations	Applications à haut débit où le service EKM s'exécute sur un seul site.	Quand des clés Cloud KMS multirégionales sont requises	La plupart des services EKM où vous déployez votre propre EKM.	Vous pouvez utiliser l'EKM d'un partenaire au lieu de déployer le vôtre.

Étapes suivantes

• En savoir plus sur la sécurité de Cloud KMS
• Créez une connexion EKM sur un réseau VPC.
• Configurez Cloud EKM sur Internet.