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 de gestion des clés externes pour protéger les données dansGoogle Cloud. Ce document décrit les architectures pour les clients Google Cloud qui souhaitent déployer un service de gestion des 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é de la charge 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 de défaillance pouvant entraîner l'inaccessibilité des données des services Google Cloud . Pour faire face à ces risques, vous devez intégrer la haute disponibilité et la tolérance aux pannes à l'architecture de l'EKM Cloud.
Présentation
Cloud EKM vous permet d'utiliser du matériel de clé qui reste en dehors de Google Cloud pour contrôler l'accès à vos données stockées dans des 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é Cloud KMS à l'aide des niveaux de protection EXTERNAL et EXTERNAL_VPC. Lorsque vous activez Cloud EKM, chaque requête d'opération cryptographique génère une opération cryptographique sur la clé externe. La réussite de l'opération de requête initiale dépend de manière critique du résultat de l'opération de chiffrement sur la clé externe.
Cloud KMS demande des opérations sur des clés externes à l'aide d'une API à usage spécial qui s'intègre à votre système de gestion des clés externe. Dans ce document, un service qui fournit cette API est désigné comme un service EKM.
Si un service EKM devient indisponible, les lectures et les écritures à partir des plans de données des services intégrés Google Cloud peuvent échouer. Ces erreurs apparaissent de la même manière que les erreurs lorsque la clé Cloud KMS dépendante est dans un état inutilisable, par exemple lorsqu'elle est désactivée. Le message d'erreur décrit la source de l'erreur et une procédure à suivre. De plus, les journaux d'audit d'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 sur l'ingénierie en fiabilité des sites de Google décrit les bonnes pratiques qui guident le développement et la maintenance de 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 de l'EKM Cloud:
- Configurer une connectivité réseau fiable et à faible latence
- Activer la haute disponibilité
- Détecter et atténuer rapidement les défaillances
Configurer une connectivité réseau fiable et à 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 la 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 connectivité 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é potentielle 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 avant 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 multirégional, le délai avant expiration commence dans la région où Cloud KMS reçoit la requête, qui est généralement l'emplacement de l'opération effectuée sur la ressource de données protégée par CMEK. Ce délai avant expiration est suffisant pour permettre à un service EKM de gérer les requêtes dans une régionGoogle Cloud à proximité d'où elles proviennent.
Le délai avant 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 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:
- Minimisez la latence de la communication aller-retour avec Cloud KMS:configurez le service EKM pour qu'il réponde aux requêtes aussi près que possible des emplacements Google Cloud qui correspondent aux clés Cloud KMS configurées pour utiliser le service EKM. Pour en savoir plus, consultez les pages Bonnes pratiques pour la sélection des régions Compute Engine et Régions et zones.
- Utilisez Cloud Interconnect dans la mesure du possible:Cloud Interconnect crée une connexion à faible latence et à disponibilité élevée 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:dans l'idéal, 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 qui héberge 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 dans la mesure du possible, ce qui réduit la dépendance à Internet.
- Utilisez des réseaux de niveau Premium lorsque le trafic EKM transite par Internet:le niveau Premium achemine le trafic via Internet à l'aide de l'infrastructure de Google dans la mesure du possible pour améliorer la fiabilité et réduire la latence.
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 réseau et de calcul sous-jacente.
Pour activer la haute disponibilité, tenez compte des points suivants:
- Déployer des réplicas dans des domaines de défaillance indépendants:déployez au moins deux réplicas 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éplicas 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 entre les réplicas. Prenons les exemples suivants :
- Configurez les modifications de production, y compris le binaire du serveur et les transferts de configuration, pour ne modifier qu'un seul réplicateur à la fois. Vérifiez que toutes les modifications sont effectuées sous surveillance, avec des rollbacks testés facilement disponibles.
- Comprendre et minimiser les modes de défaillance entre les réplications de l'infrastructure sous-jacente Par exemple, assurez-vous que les réplicas dépendent de sources d'alimentation indépendantes et redondantes.
Rendez les réplicas résilients aux pannes d'une seule machine:vérifiez que chaque réplica du service se compose d'au moins trois appareils, machines ou hôtes de VM. Cette configuration permet au système de gérer le trafic lorsqu'une machine est en panne pour des mises à jour ou en cas d'indisponibilité inattendue (provisionnement N+2).
Limitez la zone affectée par les problèmes du 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éplicas. Ces opérations sont généralement plus complexes, car elles nécessitent une synchronisation et affectent toutes les réplicas. 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ôler la vitesse de propagation:par défaut, assurez-vous que les modifications se propagent aussi lentement que possible pour une utilisation et une sécurité optimales. Configurez des exceptions si nécessaire, par exemple lorsque vous autorisez la propagation rapide de l'accès à une clé pour permettre à un utilisateur d'annuler une erreur.
- Partitionnez le système en fragments:si de nombreux utilisateurs partagent l'EKM, partitionnez-le en fragments logiques complètement indépendants, afin que les problèmes déclenchés par un utilisateur dans un fragment ne puissent pas affecter les utilisateurs d'un autre.
- Prévisualisez l'impact des modifications:si possible, laissez les utilisateurs voir l'impact des modifications avant de les appliquer. Par exemple, lors de la modification d'une stratégie 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 stratégie.
- Implémentez le canariage de données:commencez par transmettre les données à un petit sous-ensemble du système. Si le sous-ensemble reste opérationnel, transmettez les données au reste du système.
Implémentez des vérifications d'état globales:créez des vérifications d'état qui mesurent si l'ensemble du système fonctionne. Par exemple, les vérifications de l'état qui ne valident que la connectivité réseau ne sont pas utiles pour résoudre de nombreux problèmes au niveau de l'application. Idéalement, la vérification de l'état reflète étroitement les dépendances du trafic réel.
Configurez le basculement entre les réplicas:configurez l'équilibrage de charge dans les composants de service EKM afin qu'il consomme les vérifications de l'état et évacue activement le trafic des réplicas non opérationnels, puis bascule de manière sécurisée vers les réplicas opérationnels.
Inclure 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 diverses raisons. Par exemple, lorsque certains réplicas ne sont plus opérationnels, le trafic redirigé vers les réplicas opérationnels peut les surcharger. Lorsqu'il est confronté à plus de requêtes qu'il ne peut en traiter, le système doit essayer de répondre à celles qu'il peut traiter de manière sécurisée et rapide, tout en rejetant le trafic excédentaire.
Assurez-vous d'une durabilité robuste:les données chiffrées avec une clé externe dans le service EKM de Google Cloud ne sont pas récupérables sans la clé externe. Par conséquent, la durabilité des clés est l'une des principales exigences de conception du service EKM. Configurez le service EKM pour sauvegarder de manière sécurisée des copies redondantes du 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 permettent un temps de récupération en cas d'accidents et de bugs.
Détecter et atténuer rapidement les défaillances
Chaque minute où le service EKM est indisponible, les ressources Google Clouddépendantes peuvent être inaccessibles, ce qui peut encore augmenter la probabilité d'une défaillance en cascade d'autres composants dépendants de votre infrastructure.
Pour détecter et atténuer rapidement les défaillances, tenez compte des points suivants:
- Configurez le service EKM pour générer 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 rapide 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 restauration (MTTR), et définissez les objectifs mesurés par ces métriques. Grâce à ces métriques, vous pouvez identifier des tendances et des 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
Nous vous recommandons d'établir une connexion directe entre Google Cloud et votre centre de données sur site 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 aucun équilibreur de charge intermédiaire dans Google Cloud.
Dans la mesure du possible, déployez la connexion de service Cloud EKM à EKM à l'aide de la configuration de disponibilité à 99,9% pour les applications à région unique. 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 un VPN haute disponibilité au lieu de Cloud Interconnect.
L'avantage principal 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 goulots d'étranglement potentiels. 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 auxquelles vous accédez 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 la section Gestionnaires de clés externes et régions.
Équilibrage de charge depuis Internet dans Google Cloud
Nous vous recommandons 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 dispose de réplications sur 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 reposent sur la mise en réseau VPC, l'équilibreur de charge réseau proxy externe dispose d'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. Aucun équilibreur de charge supplémentaire dans le centre de données sur site n'est nécessaire.
L'équilibreur de charge réseau proxy externe n'est pas associé à une région spécifique. Il peut diriger 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 de backend principal et de backend de basculement. Le trafic est réparti de manière uniforme entre plusieurs backends d'une région.
Équilibré de charge dans un réseau VPC dans Google Cloud
L'utilisation d'un équilibreur de charge dans Google Cloud avec un réseau VPC est recommandée pour la plupart des services EKM dans lesquels vous déployez votre EKM. Le schéma suivant illustre cette architecture.
Dans cette architecture, Cloud EKM accède au service EKM qui est 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 un VPN haute disponibilité au lieu de Cloud Interconnect.
L'équilibreur de charge réseau passthrough interne fournit une seule adresse IP que les ressources peuvent utiliser pour envoyer du trafic à l'aide de la virtualisation réseau. L'équilibreur de charge transfère la charge 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 proxyer le trafic, 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 Cloud Marketplace 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 équilibrer 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 auxquelles vous accédez 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 la section 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 un partenaire. Dans ce scénario, le partenaire est chargé de déployer et de gérer l'EKM, et fournit l'EKM en tant que service aux clients.
| Option | Connexion directe | Équilibrage de charge depuis Internet | Équilibré en 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é par un partenaire) |
Compatible avec les emplacements Cloud KMS multirégionaux |
Non |
Oui |
Non |
Oui |
Recommandé pour |
Applications à haut débit où le service EKM s'exécute sur un seul site. |
Lorsque 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. |
Étape suivante
- 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.