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
Google et le client se partagent la responsabilité de l'application de correctifs. 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 section 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 sécurisée par défaut et en implémentant diverses pratiques de renforcement de la sécurité.
Par exemple, des applications conteneurisées sont utilisées pour alimenter les différentes fonctionnalités de la plate-forme Apigee API Management. 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 de meilleures performances.
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 pour la plate-forme Apigee. Il s'agit d'applications propriétaires de Google qui alimentent la plate-forme Apigee API Management, 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 pour la plate-forme Apigee. Il s'agit principalement de composants Open Source utilisés par la plate-forme pour des 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 de maximiser les chances de détecter de nouvelles failles, et donc d'appliquer ou de planifier au plus tôt 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 des manières suivantes :
- 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 des failles détectées avec 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écompenses pour la détection de failles (VRP)
Google s'implique activement dans la communauté de recherche en sécurité par le biais de plusieurs programmes de récompense pour la détection de failles. Un programme de récompenses pour la détection de failles Google Cloud dédié offre des primes significatives, y compris une prime de 133 337 $ pour la plus grande faille cloud détectée chaque année. Le programme couvre toutes les dépendances logicielles d'Apigee.
OSS
La collaboration sur la sécurité de Google a de nombreux niveaux. Elle a parfois lieu de manière formelle 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 kernel Linux, les environnements d'exécution des conteneurs, la technologie de virtualisation, et bien plus encore.
Bien que les failles moins graves 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é par le biais de l'un des canaux listé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 Apigee, 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 applications 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ée | Faille facile à exploiter pour de nombreux clusters qui entraîne 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 des 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 lors de la publication 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. Le client peut exécuter une série de tests de sécurité si ses normes de sécurité l'exigent pour le lancement de logiciels en production dans ses propres centres de données. Ces tests peuvent inclure des tests d'intrusion, l'analyse des conteneurs, l'analyse du code statique, etc. De plus, ils peuvent 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é
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 par le biais du Programme de récompenses pour la détection de failles 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 grâce au 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, d'un autre outil ou d'une autre 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 par le biais du 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 signalement. 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 indiquer 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 identifiants 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 CVE, il est possible que Google ne puisse pas répondre à l'élément spécifique.
Réponse
Pour les éléments signalés à l'assistance dont le score de gravité est critique ou élevé, les clients peuvent s'attendre à une réponse par le biais du système de suivi des demandes. Concernant les éléments signalés par le biais du VRP, veuillez consulter les règles et la documentation fournies par le programme.