Pourquoi Google Cloud Compute?
La plupart des entreprises utilisent des centres de données car ils offrent une prévisibilité des coûts, une certitude matérielle et un contrôle. Cependant, l'exécution et la maintenance des ressources dans un centre de données nécessitent également beaucoup de frais généraux, notamment:
-
Capacité : suffisamment de ressources pour s'adapter aux besoins et une utilisation efficace de ces ressources.
-
Sécurité : sécurité physique pour protéger les actifs, ainsi que la sécurité au niveau du réseau et du système d'exploitation.
-
Infrastructure réseau : composants tels que le câblage, les commutateurs, les routeurs, les pare-feu et les répartiteurs de charge.
-
Support : employés qualifiés pour effectuer l'installation et la maintenance et résoudre les problèmes.
-
Bande passante : bande passante adaptée à la charge maximale.
-
Installations : infrastructure physique, y compris l'équipement et l'alimentation.
Les plateformes cloud entièrement fonctionnelles telles que Cloud Platform contribuent à éliminer une grande partie des frais généraux liés à ces préoccupations physiques, logistiques et liées aux ressources humaines, et peuvent contribuer à réduire de nombreux coûts commerciaux associés dans le processus. Parce que Cloud Platform est construit sur l'infrastructure de Google, il offre également des avantages supplémentaires qui seraient généralement prohibitifs dans un centre de données traditionnel, notamment:
Un réseau mondial
Redondance intégrée à plusieurs régions
Plusieurs régions et zones de centres de données à travers le monde garantissent une redondance et une disponibilité solides. Cela est particulièrement crucial lorsqu'il y a un besoin spécifique d'expansion/développement international et géographique dans plusieurs zones.
Mise à l'échelle rapide et fiable
La plateforme Cloud est conçue pour se mettre à l'échelle comme les propres produits de Google, même en cas de pic de trafic important. Des services gérés tels que Google App Engine, l'autoscaler de Google Compute Engine et Google Cloud Datastore vous offrent une mise à l'échelle automatique qui permet à votre application de croître et de réduire sa capacité selon les besoins.
Capacité et bande passante
Dans un centre de données traditionnel, vous devez planifier vos besoins en ressources, acquérir suffisamment de ressources à l'avance pour vous mettre à l'échelle selon les besoins, et gérer soigneusement votre capacité et la répartition de votre charge de travail dans ces limites de ressources. En raison de la nature des ressources préprovisionnées, peu importe à quel point vous gérez soigneusement votre capacité, vous pouvez vous retrouver avec une utilisation sous-optimale :
Figure 1 : Utilisation des ressources préprovisionnées au fil du temps
De plus, cette préprovision des ressources signifie que vous avez une limite stricte sur les ressources. Si vous avez besoin de vous mettre à l'échelle au-delà de cela, vous êtes malchanceux.
La plateforme Cloud résout bon nombre de ces problèmes d'utilisation et de seuils de mise à l'échelle. Vous pouvez augmenter et réduire la taille de vos instances de machines virtuelles selon vos besoins. Comme vous payez en fonction de ce que vous utilisez, à la seconde près, vous pouvez optimiser vos coûts sans avoir à payer pour une capacité excédentaire dont vous n'avez pas besoin tout le temps, ou dont vous avez seulement besoin aux heures de pointe du trafic.
Sécurité
Le modèle de sécurité de Google est un processus de bout en bout, basé sur plus de 18 ans d'expérience axée sur la protection des clients sur les applications Google telles que Gmail et Google Apps. De plus, les équipes d'ingénierie de la fiabilité des sites de Google supervisent les opérations des systèmes de la plateforme pour garantir une disponibilité élevée et prévenir les abus des ressources de la plateforme.
Infrastructure réseau
Dans un centre de données traditionnel, vous gérez une configuration réseau complexe, comprenant des racks de serveurs, du stockage, plusieurs niveaux de commutateurs, des équilibreurs de charge, des routeurs et des pare-feu. Vous devez configurer, maintenir et surveiller les logiciels et les configurations détaillées des appareils. De plus, vous devez vous préoccuper de la sécurité et de la disponibilité de votre réseau, et vous devez ajouter et mettre à niveau du matériel en fonction de vos besoins en matière de réseau.
En revanche, la plateforme Cloud utilise un réseau défini par logiciel (SDN) modèle, vous permettant de configurer entièrement votre réseau via les API de service et les interfaces utilisateur de la plateforme Cloud. Vous n'avez pas à payer ni à gérer le matériel réseau du centre de données. Pour plus de détails sur la pile SDN de Google, Andromeda, consultez la zone Andromeda .
Installations et support
Lorsque vous utilisez la plateforme Cloud, vous n'avez plus à vous soucier de l'installation ou de la maintenance du matériel physique du centre de données, ni de disposer de techniciens qualifiés pour le faire. Google s'occupe à la fois de la couche matérielle et des techniciens, vous permettant de vous concentrer sur l'exécution de votre application.
Conformité
Google fait régulièrement l'objet d'audits indépendants de tiers pour vérifier que la plateforme Cloud est conforme aux contrôles de sécurité, de confidentialité et de conformité. La plateforme Cloud fait régulièrement l'objet d'audits pour des normes telles que ISO 27001, ISO 27017, ISO 27018, SOC 2, SOC 3 et PCI DSS.
Mise en avant des avantages en matière de sécurité
L'économie mondiale subit chaque année des pertes de plusieurs milliards de dollars en raison de violations de données, de vols ou de destructions. Pour cette raison, les principaux acteurs de l'industrie du Cloud et de GCP s'efforcent de se conformer à des normes réputées telles que :
-
FIPS 140-2
-
ISO/CEI 27001
-
PCI DSS
-
ISO 27017
-
ISO 27018, SOC 2, SOC 3
Chiffrement de toutes les données au repos et en transit
Google Cloud Computing a investi des millions de dollars au cours de ces dernières années afin de se conformer au niveau 1 FIPS, comme vous pouvez le vérifier ici et ici .
Pour rappel, FIPS signifie Federal Information Processing Standard , qui est l'un des plus exigeants au monde, initialement mis en place par l'administration américaine pour protéger leurs secrets et leurs infrastructures.
Les éléments suivants sont mis en œuvre par GCP et très probablement NON mis en œuvre au niveau du réseau local des installations « sur site » :
| Technologie | Google Cloud Compute |
Implémentation d'entreprise DIY standard
|
|
Le produit de stockage SSD local est automatiquement chiffré avec des chiffres approuvés par le NIST.
|
Appliqué à tous les stockages
|
RAREMENT mis en œuvre |
|
Chiffrement automatique du trafic entre les emplacements de données internes et externes à l'aide d'algorithmes de chiffrement approuvés par le NIST.
|
Appliqué à toutes les transferts de données
|
RAREMENT mis en œuvre
|
|
Lorsque les clients se connectent à l'infrastructure, leurs clients TLS doivent être configurés pour exiger l'utilisation d'algorithmes sécurisés conformes à FIPS ; si le client TLS et les services TLS du propriétaire de l'infrastructure s'accordent sur une méthode de chiffrement incompatible avec FIPS, une implémentation de chiffrement non validée sera utilisée.
|
Appliqué à toutes les connexions
|
TRÈS RAREMENT mis en œuvre |
|
Les applications que vous créez et exploitez sur l'infrastructure de production peuvent inclure leurs propres implémentations cryptographiques ; afin que les données qu'elles traitent soient sécurisées avec un module cryptographique validé par FIPS, vous devez intégrer une telle implémentation vous-même.
|
Prêt à l'emploi
|
TRÈS RAREMENT mis en œuvre
|
Environnement Google Cloud et chiffrement au repos
Niveau CIO
| Technologie | Google Cloud Compute | Implémentation locale standard |
|
Google utilise plusieurs couches de chiffrement pour protéger les données des clients au repos dans les produits de la plateforme Google Cloud.
|
Appliqué en tant que standard
|
Rarement mis en œuvre
|
|
Google Cloud Platform chiffre le contenu du client stocké au repos, sans aucune action requise de la part du client, en utilisant un ou plusieurs mécanismes de chiffrement. Il existe quelques exceptions mineures, notées plus loin dans ce document.
|
Appliqué en tant que standard
|
Rarement mis en œuvre
|
|
Les données de stockage sont divisées en morceaux, et chaque morceau est chiffré avec une clé de chiffrement de données unique. Ces clés de chiffrement de données sont stockées avec les données, chiffrées avec des clés de chiffrement de clé ("enveloppées" par) qui sont exclusivement stockées et utilisées à l'intérieur du service de gestion des clés central de Google. Le service de gestion des clés de Google est redondant et distribué à l'échelle mondiale.
|
Réalisé en tant que standard
|
Très rarement mis en œuvre
|
|
Les données stockées dans Google Cloud Platform sont chiffrées au niveau du stockage en utilisant soit AES256, soit AES128.
|
Réalisé en tant que standard
|
Très rarement mis en œuvre
|
|
Google utilise une bibliothèque cryptographique commune, Tink, pour implémenter de manière cohérente le chiffrement dans presque tous les produits de la plateforme Google Cloud. Étant donné que cette bibliothèque commune est largement accessible, seule une petite équipe de cryptographes doit implémenter et maintenir ce code étroitement contrôlé et examiné.
|
Réalisé en tant que norme
|
TRÈS RAREMENT mis en œuvre
|
Couches de chiffrement
Google utilise plusieurs couches de chiffrement pour protéger les données. L'utilisation de plusieurs couches de chiffrement ajoute une protection redondante des données et nous permet de sélectionner l'approche optimale en fonction des exigences de l'application.
Chaque fragment est réparti dans les systèmes de stockage de Google et est répliqué sous forme chiffrée pour la sauvegarde et la récupération après sinistre. Une personne malveillante souhaitant accéder aux données des clients devrait connaître et pouvoir accéder à (1) tous les fragments de stockage correspondant aux données qu'elle souhaite, et (2) les clés de chiffrement correspondant aux fragments.
Google utilise l'algorithme de chiffrement Advanced Encryption Standard (AES) pour chiffrer les données au repos. AES est largement utilisé car (1) à la fois AES256 et AES128 sont recommandés par l'Institut national des normes et de la technologie (NIST) pour une utilisation à long terme (en mars 2019), et (2) AES est souvent inclus dans les exigences de conformité des clients.
Les données stockées dans Google Cloud Storage sont chiffrées au niveau du stockage à l'aide d'AES, en mode Galois/Counter (GCM) dans presque tous les cas. Cela est mis en œuvre dans la bibliothèque BoringSSL que Google maintient. Cette bibliothèque a été dérivée d'OpenSSL à des fins internes, après que de nombreuses failles ont été exposées dans OpenSSL. Dans certains cas, AES est utilisé en mode Cipher Block Chaining (CBC) avec un code d'authentification de message haché (HMAC) pour l'authentification ; et pour certains fichiers répliqués, AES est utilisé en mode Counter (CTR) avec HMAC. (Des détails supplémentaires sur les algorithmes sont fournis plus loin dans ce document.) Dans d'autres produits de la plateforme Google Cloud, AES est utilisé dans une variété de modes.
| Technologie |
Google Cloud Compute
|
Implémentation locale standard
|
|
Chiffrement natif multicouche
|
Appliqué en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Chiffrement AES natif avec mode CTR
|
Appliqué en tant que norme
|
TRÈS RAREMENT atteint
|
| GCM natif |
Appliqué en tant que norme
|
TRÈS RAREMENT atteint
|
Chiffrement au niveau du dispositif de stockage
En plus du chiffrement au niveau du système de stockage décrit ci-dessus, dans la plupart des cas, les données sont également chiffrées au niveau du dispositif de stockage, avec au moins AES128 pour les disques durs (HDD) et AES256 pour les nouveaux disques à semi-conducteurs (SSD), en utilisant une clé de niveau dispositif distincte (qui est différente de la clé utilisée pour chiffrer les données au niveau du stockage). Au fur et à mesure que les anciens dispositifs sont remplacés, seul AES256 sera utilisé pour le chiffrement de niveau dispositifChiffrement des sauvegardes
Le système de sauvegarde de Google garantit que les données restent chiffrées tout au long du processus de sauvegarde. Cette approche évite d'exposer inutilement les données en clair.De plus, le système de sauvegarde chiffre chaque fichier de sauvegarde indépendamment avec sa propre clé de chiffrement des données (DEK), dérivée d'une clé stockée dans le service de gestion des clés (KMS) de Google, plus une graine générée de manière aléatoire par fichier au moment de la sauvegarde. Une autre DEK est utilisée pour toutes les métadonnées des sauvegardes, qui sont également stockées dans le KMS de Google.
| Technologie | Google Cloud Compute | Implémentation locale standard |
|
Chiffrement du flux de sauvegarde en temps réel
|
Atteint en tant que norme
|
TRÈS RAREMENT mis en œuvre
|
|
Chiffrement de sauvegarde de stockage
|
Atteint en tant que norme
|
TRÈS RAREMENT mis en œuvre
|
Gestion des clés par GCP
La clé utilisée pour chiffrer les données dans un fragment est appelée clé de chiffrement des données (DEK). En raison du grand nombre de clés chez Google, et de la nécessité d'une faible latence et d'une disponibilité élevée, ces clés sont stockées près des données qu'elles chiffrent. Les DEK sont chiffrées avec (ou "enveloppées" par) une clé de chiffrement des clés (KEK). Une ou plusieurs KEK existent pour chaque service de la plateforme Google Cloud. Ces KEK sont stockées de manière centralisée dans le service de gestion des clés (KMS) de Google, un référentiel spécialement conçu pour stocker les clés. Le fait d'avoir un nombre plus réduit de KEK que de DEK et d'utiliser un service de gestion des clés centralisé permet de gérer le stockage et le chiffrement des données à l'échelle de Google, et nous permet de suivre et de contrôler l'accès aux données à partir d'un point central.
Pour chaque client de la plateforme Google Cloud, les ressources non partagées sont divisées en fragments de données et chiffrées avec des clés distinctes des clés utilisées pour les autres clients. Ces DEK sont même distinctes de celles qui protègent les autres parties des mêmes données appartenant à ce même client.
Les DEK sont générées par le système de stockage à l'aide de la bibliothèque cryptographique commune de Google. Elles sont ensuite envoyées à KMS pour être enveloppées avec la KEK de ce système de stockage, et les DEK enveloppées sont renvoyées au système de stockage pour être conservées avec les fragments de données. Lorsqu'un système de stockage a besoin de récupérer des données chiffrées, il récupère la DEK enveloppée et la transmet à KMS. KMS vérifie ensuite si ce service est autorisé à utiliser la KEK, et si c'est le cas, dévoile et renvoie la DEK en texte clair au service. Le service utilise ensuite la DEK pour déchiffrer le fragment de données en texte clair et vérifier son intégrité.
La plupart des KEK pour le chiffrement des fragments de données sont générées au sein de KMS, et le reste est généré à l'intérieur des services de stockage. Pour garantir la cohérence, toutes les KEK sont générées à l'aide de la bibliothèque cryptographique commune de Google, en utilisant un générateur de nombres aléatoires (RNG) développé par Google. Ce RNG est basé sur NIST 800-90Ar1 CTR-DRBG et génère une KEK AES256. Ce RNG est alimenté par le RNG du noyau Linux, qui lui-même est alimenté par plusieurs sources d'entropie indépendantes. Cela inclut des événements entropiques de l'environnement du centre de données, tels que des mesures fines des recherches de disque et des temps d'arrivée inter-paquets, et l'instruction RDRAND d'Intel lorsqu'elle est disponible (sur les processeurs Ivy Bridge et plus récents).
Les données stockées dans la plateforme Google Cloud sont chiffrées avec des DEK utilisant AES256 ou AES128, comme décrit ci-dessus ; et toutes les nouvelles données chiffrées dans les disques persistants de Google Compute Engine sont chiffrées à l'aide d'AES256. Les DEK sont enveloppées avec des KEK utilisant AES256 ou AES128, selon le service de la plateforme Google Cloud. Nous travaillons actuellement à la mise à niveau de toutes les KEK pour les services Cloud vers AES256.
Le KMS de Google gère les KEK, et a été construit uniquement dans ce but. Il a été conçu en tenant compte de la sécurité. Les KEK ne peuvent pas être exportées du KMS de Google par conception ; tout chiffrement et déchiffrement avec ces clés doit être effectué à l'intérieur du KMS. Cela contribue à prévenir les fuites et les abus, et permet au KMS d'émettre une piste d'audit lorsque les clés sont utilisées.
| Technologie | Google Cloud Compute | Implémentation locale standard |
|
Intégration KMS
|
Appliqué en tant que standard
|
Implémenté TRÈS RAREMENT
|
|
AES256 KEK
|
Appliqué en tant que standard
|
RAREMENT atteint
|
Réseau et communication
Avantages de la catégorie Premium
La possession complète du réseau d'un emplacement à un autre est quelque chose que la plupart des entreprises ne peuvent pas se permettre. Pourtant, Google Cloud Compute est capable d'atteindre une propriété et un contrôle complets de bout en bout.
| Technologie | Google Cloud Compute |
Implémentation d'entreprise DIY standard
|
|
Possession complète du réseau de bout en bout
|
Atteint en tant que standard
|
TRÈS RAREMENT mis en œuvre
|
|
Plus de 100 PoPs dans le monde entier pour offrir une couverture étendue et une redondance / résilience du réseau
|
Atteint en tant que norme
|
TRÈS RAREMENT mis en œuvre
|
Stabilité opérationnelle / Sérénité / SLA
Des normes élevées au niveau SLA
Google Cloud Compute fait partie des rares fournisseurs de Cloud capables de se vanter d'un SLA vérifié supérieur à 99% sur l'ensemble de ses services .
|
Service couvert
|
Pourcentage de disponibilité mensuel
|
|
Instances dans plusieurs zones
|
>= 99.99%
|
|
Une seule instance
|
>= 99.5%
|
|
Équilibrage de charge
|
>= 99.99%
|
Si Google ne respecte pas l'objectif de niveau de service (SLO) et si le client respecte ses obligations en vertu de cet accord de niveau de service (SLA), le client sera éligible pour recevoir les crédits financiers décrits ci-dessous. Cet accord de niveau de service (SLA) constitue le seul et unique recours du client en cas de non-respect par Google de l'objectif de niveau de service (SLO). Les termes en majuscules utilisés dans cet accord de niveau de service (SLA), mais non définis dans cet accord de niveau de service (SLA), ont la signification indiquée dans l'accord. Si l'accord autorise la revente ou la fourniture de la plateforme Google Cloud dans le cadre d'un programme de partenariat ou de revente de Google Cloud, alors toutes les références au client dans cet accord de niveau de service (SLA) désignent le partenaire ou le revendeur (selon le cas), et tout crédit financier s'appliquera uniquement aux commandes du partenaire ou du revendeur concerné en vertu de l'accord.
|
Technologie
|
Google Cloud Compute
|
Implémentation locale standard
|
|
Implémentation d'une seule instance/serveur avec un SLA de 99,5% (ce qui signifie 354,5 jours de disponibilité par an)
|
Atteint en tant que standard
|
Atteint RAREMENT
|
|
Implémentation de plusieurs instances (équilibrées en charge et redondantes) / serveur avec un SLA de 99,5% (ce qui signifie 364,96 jours de disponibilité par an)
|
Atteint en tant que standard
|
Atteint TRÈS RAREMENT
|
|
SLA à vie
|
Atteint en tant que standard
|
Atteint TRÈS RAREMENT
|
Normes de haute disponibilité
Atteindre les objectifs de disponibilité à 100% implique que votre infrastructure soit capable d'atteindre les normes suivantes :
| Technologie |
Google Cloud Compute
|
Implémentation locale standard
|
|
Capacité matérielle auto-gérée
|
Atteint en tant que norme
|
RAREMENT atteint
|
|
Auto-évolutivité
|
Atteint en tant que norme
|
TRÈS RAREMENT atteint
|
|
Approvisionnement automatisé des ressources
|
Atteint en tant que norme
|
TRÈS RAREMENT atteint
|
|
Redondance multiple (stockage)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Redondance multiple (Instances informatiques / Serveurs)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Redondance multiple (Sources d'alimentation)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Redondance multiple (Sources d'alimentation)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Redondance multiple (stockage)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Technologie de répartition de charge
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Réplication des données en temps réel sur un stockage passif (données/fichiers)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
|
Réplication des données en temps réel sur un stockage dynamique (bases de données)
|
Réalisé en tant que norme
|
TRÈS RAREMENT réalisé
|
Port Cities - Vous aide à sélectionner la solution d'hébergement la plus adaptée à votre entreprise
Port Cities collabore avec les meilleurs fournisseurs de services cloud au monde, y compris Google Cloud Platform, pour s'assurer que votre ERP est accessible à tout moment, de n'importe où. Nous nous assurons également que nos solutions d'hébergement répondent aux critères les plus exigeants de votre système ERP, en termes de sécurité, de capacité ou de stabilité opérationnelle. Dans tous les cas,
notre équipe de serveurs est prête à discuter avec vous
la solution d'hébergement de serveur la plus adaptée à votre entreprise.
.