Vous consultez la documentation d'Apigee et d'Apigee hybrid.
Consultez la documentation d'Apigee Edge.
Ce document décrit la manière dont Google gère les failles et correctifs de sécurité pour Apigee hybrid. Sauf indication contraire, Apigee inclut à la fois le plan de gestion et le plan de données.
Responsabilité partagée pour les correctifs
La réparation est une responsabilité partagée entre Google et le client. Apigee X et Apigee hybrid ont des responsabilités partagées différentes, car le plan de données pour Apigee hybrid est entièrement géré par le client. Pour en savoir plus sur le partage des responsabilités dans Apigee hybrid, consultez la page Modèle de responsabilité partagée d'Apigee hybrid.
Détection des failles
Google adopte une approche proactive de la sécurité des systèmes logiciels en appliquant des principes de conception avec Sécurisation par défaut et en mettant en œuvre diverses pratiques de renforcement de la sécurité.
Par exemple, des applications en conteneur sont utilisées pour alimenter les différentes fonctionnalités de la plate-forme de gestion d'API Apigee. Les applications conteneurisées sont déployées sur Kubernetes. Les images de conteneur sont basées sur des images de base minimales (par exemple, des images de base distroless) pour une sécurité maximale et des performances améliorées.
Cependant, même les systèmes logiciels les mieux conçus peuvent présenter des failles. Afin de détecter ces failles et de les corriger avant qu'elles puissent être exploitées, Google a effectué des investissements considérables sur plusieurs aspects.
Analyseurs de sécurité
Google identifie et corrige de manière proactive les failles sur différents types d'images de conteneurs :
- Conteneurs propriétaires : images de conteneurs créées et distribuées par Google dans le cadre de la plate-forme Apigee. Il s'agit d'applications propriétaires de Google qui alimentent la plate-forme de gestion d'API Apigee, y compris les principales fonctionnalités telles que le routage du trafic, la gestion des quotas et la gestion des clés.
- Conteneurs tiers : images de conteneurs créées par la communauté Open Source, mais distribuées par Google dans le cadre de la plate-forme Apigee. Il s'agit principalement de composants Open Source utilisés par la plate-forme pour les tâches opérationnelles courantes telles que la journalisation, la surveillance et la gestion des certificats.
Google analyse les conteneurs à l'aide de Container Registry Container Analysis pour détecter les failles et les correctifs manquants dans les conteneurs propriétaires et tiers. Si des correctifs sont disponibles, Google démarre le processus d'application de correctifs et de publication. Ces analyses sont exécutées régulièrement (lorsque de nouvelles images sont publiées), mais aussi à la demande (avant la publication d'une version), afin d'optimiser les chances de détecter de nouvelles failles et donc d'appliquer ou planifier des mesures correctives ou d'atténuation.
Recherches sur la sécurité
En plus de l'analyse automatisée, Google détecte et corrige les failles inconnues des analyseurs de différentes manières :
- Google effectue ses propres audits de sécurité et de conformité, mais aussi des tests d'intrusion sur les réseaux et les applications, des tests de segmentation et une détection des failles de sécurité dans tous les composants Apigee.
Les équipes internes spécialisées de Google et les fournisseurs de sécurité tiers de confiance effectuent leurs propres recherches sur les attaques. - Google collabore avec des partenaires logiciels Open Source et d'autres secteurs, qui partagent des failles, des recherches en sécurité et des correctifs avant que la version publique de ces failles ne soit publiée.
L'objectif de cette collaboration est de corriger des éléments importants de l'infrastructure Internet avant que la faille ne soit annoncée publiquement. Dans certains cas, Google partage les failles détectées dans cette communauté. Par exemple, le projet Zero de Google a permis de détecter et de rendre public les failles Spectre et Meltdown. Par ailleurs, l'équipe de sécurité Google Cloud recherche et corrige régulièrement des failles dans la machine virtuelle basée sur Kernel (KVM).
Programmes de récompense dédiés à la détection de failles (VRP)
Google s'implique activement dans la communauté de recherche en sécurité par la biais de plusieurs programmes de récompense dédiés à la détection de failles ("Vulnerability Reward Programs" ou VRP). Un programme de récompense dédié à la détection des failles Google Cloud offre des primes significatives, notamment une prime 133 337 $ pour la plus grande faille cloud détectée chaque année. Le programme couvre toutes les dépendances logicielles de GKE.
OSS
La collaboration sur la sécurité de Google a de nombreux niveaux. Elle arrive parfois par le biais de programmes où les organisations s'inscrivent pour recevoir des notifications préliminaires concernant des failles logicielles pour des produits tels que Kubernetes et Envoy. La collaboration se fait également de manière informelle en raison de notre engagement auprès de nombreux projets Open Source, tels que le noyau Linux, les environnements d'exécution des conteneurs, la technologie de virtualisation, et bien plus encore.
Bien que les failles moins critiques soient découvertes et corrigées en dehors de ces processus, les failles de sécurité les plus critiques sont signalées en mode privé via l'un des canaux répertoriés précédemment. La création précoce de rapports laisse du temps à Google avant que la faille ne devienne publique afin d'étudier son impact sur Anthos, de développer des correctifs ou des mesures d'atténuation, et de préparer des conseils et des communications pour les clients. Lorsque cela est possible, Google corrige tous les clusters (pour Apigee X) avant la sortie publique de la faille. Pour Apigee hybrid, les versions de correctif sont mises à disposition régulièrement pour résoudre les failles de sécurité dans les images de conteneurs. Les clients sont invités à rester à jour avec les dernières versions de correctif.
Classement des failles
Apigee réalise des investissements importants dans le renforcement de la sécurité sur l'ensemble de la pile, y compris l'image de base, les bibliothèques tierces et les logiciels d'application propriétaires, en plus de définir de manière appropriée les valeurs par défaut, les configurations à sécurité renforcée et les composants gérés. Ces efforts combinés permettent de réduire l'impact et la probabilité des failles.
L'équipe de sécurité Apigee classe les failles en fonction du CVSS (Common Vulnerability Scoring System).
Le tableau suivant décrit les catégories de gravité des failles :
| Gravité | Description |
| Critique | Faille facilement exploitable dans tous les clusters par un pirate informatique non authentifié à distance, qui entraîne un piratage de l'intégralité du système. |
| Élevés | Faille facile à exploiter pour de nombreux clusters qui entraînent une perte de confidentialité, d'intégrité ou de disponibilité. |
| Moyenne | Faille utilisable pour certains clusters où la perte de confidentialité, d'intégrité ou de disponibilité est limitée par des configurations courantes, la difficulté de l'exploitation elle-même, l'accès requis ou l'interaction utilisateur. |
| Faible | Toutes les autres failles. L'exploitation est peu probable, ou les conséquences de l'exploitation sont limitées. |
Communication des failles et des correctifs
L'objectif de Google est de réduire les failles détectées dans un délai approprié en fonction des risques qu'elles représentent. Apigee est inclus dans l'agrément d'exploitation provisoire FedRAMP de Google Cloud, ce qui nécessite la correction des failles connues dans des délais spécifiques en fonction de leur niveau de gravité, comme spécifié dans FedRAMP RA-5d. L'agrément d'exploitation provisoire FedRAMP de Google Cloud n'inclut pas les composants du plan de données Apigee hybrid (gérés par le client), mais nous nous efforçons de conserver les mêmes délais de correction sur ces produits.
Failles détectées par analyse proactive
Google détecte les failles de sécurité via une analyse proactive des binaires et de l'infrastructure sous-jacente qui héberge la plate-forme Apigee. Apigee publie régulièrement des mises à jour de correctif pour corriger ces failles en temps opportun, en fonction de la gravité des CVE sous-jacentes. La correction d'une faille implique la mise à niveau vers une nouvelle version d'Apigee hybrid : une mise à niveau de version mineure ou une mise à niveau de version de correctif, en fonction de la nature de la faille. Ces failles sont principalement corrigées dans le cadre de la version mensuelle des correctifs, dans le cas d'Apigee hybrid, et incluses dans les mises à jour logicielles régulières de notre parc géré, dans le cas d'Apigee X. Les correctifs de sécurité sont communiqués via des notes de version pour Apigee X et Apigee hybrid.
La correction de certaines failles ne nécessite qu'une mise à niveau du plan de contrôle, effectuée automatiquement par Google sur Apigee, tandis que d'autres nécessitent le déploiement de nouveaux binaires dans le plan de données. Dans le cas d'Apigee X, Google se charge de déployer les nouveaux binaires sur l'ensemble du parc. Les clients utilisant Apigee hybrid doivent appliquer la version de correctif à leurs clusters Apigee hybrid afin de déployer les binaires mis à jour.
Pour maintenir les clusters à jour et renforcer la sécurité contre les failles de tous niveaux de gravité, nous vous recommandons d'appliquer la dernière version de correctif pour toute version mineure donnée d'Apigee hybrid. Si vous exécutez Apigee hybrid sur Anthos, Google recommande de mettre à niveau vos composants Anthos au moins une fois par mois.
Failles signalées par les clients
Avec Apigee hybrid, les clients reçoivent des binaires Apigee à exécuter dans leurs centres de données ou sur leurs plates-formes cloud préférées. Dans le cadre des normes de sécurité d'un client pour le lancement de logiciels en production dans ses propres centres de données, il peut exécuter une série de tests de sécurité. Ces tests peuvent inclure des tests de pénétration, l'analyse de conteneurs, l'analyse de code statique, etc… et faire apparaître des failles potentielles dans le logiciel Apigee. Avant d'activer ces packages dans leurs centres de données, les clients doivent déterminer si ces éléments signalés sont exploitables et présentent donc un risque de sécurité.
Failles exploitables avec démonstration de faisabilité ("Proof of Concept")
Si le client identifie une faille exploitable et présente une démonstration de faisabilité sur la manière d'exploiter cette faille, il doit signaler ce problème via le programme de récompense dédié à la détection de failles ("Vulnerabilities Reward Program" ou VRP) de Google à l'adresse goo.gle/vulnz. Le problème est alors signalé à l'équipe de sécurité Google, qui validera la démonstration de faisabilité et déterminera son niveau de gravité ainsi que son impact potentiel. Le problème sera ensuite transmis à Apigee. Le client peut bénéficier d'une récompense via le programme VRP.
Failles identifiées par un outil automatisé
Si le client a généré un rapport sur des failles potentielles dans le produit Apigee sur la base d'une analyse statique ou d'un autre outil ou technique, mais qu'il n'a aucune démonstration de faisabilité sur la manière d'exploiter la ou les failles potentielles, ces éléments peuvent être signalés à l'assistance via le portail d'assistance Google Cloud. En signalant le problème à l'équipe d'assistance, le client dispose d'un numéro de demande de suivi et peut consulter les mises à jour et les réponses au rapport. L'équipe d'assistance transmet ensuite les problèmes signalés en interne, le cas échéant.
Identifiants CVE
Les clients doivent inclure autant d'informations que possible sur la faille, et inclure spécifiquement l'identifiant CVE, le nom de la bibliothèque/du package, le nom de l'image de conteneur, etc… pour chaque élément. Les failles CVE nous permettent de savoir que nous examinons la même faille. Si vous ne fournissez qu'une description du problème ou un autre numéro de suivi propriétaire, il n'est pas possible de corréler le problème sur différents outils de détection ou processus de signalement. Sans identifiant de faille CVE, Google peut ne pas être en mesure de répondre à l'élément spécifique.
Réponse
Pour les articles signalés à l'assistance dont le score de gravité est critique ou élevé, les clients peuvent s'attendre à une réponse via le système de demande d'assistance. Pour les éléments signalés au VRP, veuillez consulter les règles et la documentation fournies par le programme.