Cette page décrit les services et fonctionnalités Google Cloud qui vous aident à protéger vos artefacts.
Chiffrement au repos
Par défaut, Google Cloud chiffre automatiquement les données au repos à l'aide de clés de chiffrement gérées par Google. Si vous avez des exigences réglementaires ou de conformité spécifiques liées aux clés qui protègent vos données, vous pouvez créer des dépôts chiffrés avec des clés de chiffrement gérées par le client (CMEK).
Contrôle des accès
Par défaut, tous les dépôts sont privés. Suivez le principe de sécurité du moindre privilège et n'accordez que les autorisations minimales requises par les utilisateurs et les comptes de service.
Prévenez l'exfiltration de données
Pour empêcher l'exfiltration de données, vous pouvez utiliser VPC Service Controls pour placer Artifact Registry et d'autres services Google Cloud dans un périmètre de sécurité réseau.
Analyse des failles
Artifact Analysis peut rechercher des failles de sécurité dans les images de conteneurs dans les packages surveillés publiquement.
Les options suivantes sont disponibles :
- Analyse automatique des failles
- Lorsque cette fonctionnalité est activée, elle identifie les failles de package dans vos images de conteneurs. Les images sont analysées lors de leur importation dans Artifact Registry et les données sont surveillées en continu pour détecter de nouvelles failles pendant un maximum de 30 jours après le transfert de l'image.
- API On-Demand Scanning
- Lorsque cette option est activée, vous pouvez analyser manuellement les images locales ou les images stockées dans Artifact Registry. Cette fonctionnalité vous permet de détecter et de corriger les failles dès le début de votre pipeline de compilation. Par exemple, vous pouvez utiliser Cloud Build pour analyser une image après sa création, puis bloquer l'importation dans Artifact Registry si l'analyse détecte des failles à un niveau de gravité spécifié. Si vous avez également activé l'analyse automatique des failles, Artifact Analysis analyse également les images que vous importez dans le registre.
Stratégie de déploiement
Vous pouvez utiliser l'autorisation binaire pour configurer une stratégie appliquée par le service lorsqu'une tentative de déploiement d'une image de conteneur est effectuée dans l'un des environnements Google Cloud compatibles.
Par exemple, vous pouvez configurer l'autorisation binaire pour n'autoriser les déploiements que si une image est signée à des fins de conformité avec une règle d'analyse des failles.
Supprimer les images inutilisées
Supprimez les images de conteneurs inutilisées afin de réduire les coûts de stockage et les risques liés à l'utilisation de logiciels plus anciens. Un certain nombre d'outils sont disponibles pour vous aider dans cette tâche, par exemple gcr-cleaner. L'outil gcr-cleaner n'est pas un produit Google officiel.
Intégrer la sécurité dès le départ
L'intégration d'objectifs de sécurité des informations dans le travail quotidien peut aider à améliorer les performances de livraison de logiciels et à créer des systèmes plus sécurisés. Cette idée est également connue sous le nom de shifting left (déplacement à gauche), car les préoccupations, y compris de sécurité, sont traitées plus tôt dans le cycle de développement logiciel (c’est-à-dire à gauche sur un schéma de planning de gauche à droite). Le virage à gauche en matière de sécurité est l'une des fonctionnalités DevOps identifiées dans le programme de recherche DORA sur l'état du DevOps.
Pour en savoir plus :
- Découvrez-en plus sur la fonctionnalité Lever à gauche pour la sécurité.
- Lisez le livre blanc Shifting left on security (Le changement à gauche pour la sécurité) qui décrit les responsabilités, les pratiques, les processus, les outils et les techniques permettant de renforcer la confiance dans le cycle de développement logiciel (SDLC) et de réduire les problèmes de risque pour la sécurité.
Considérations relatives aux dépôts publics
Réfléchissez bien aux cas suivants:
- Utilisation d'artefacts provenant de sources publiques
- Rendre publics vos propres dépôts Artifact Registry
Utiliser des artefacts provenant de sources publiques
Les sources publiques d'artefacts, telles que GitHub, Docker Hub, PyPI ou le registre public npm, fournissent des outils que vous pouvez utiliser ou des dépendances pour vos compilations et vos déploiements.
Cependant, votre organisation peut être soumise à des contraintes qui impactent votre utilisation des artefacts publics. Exemple :
- Vous souhaitez contrôler le contenu de votre chaîne d'approvisionnement logicielle.
- Vous ne voulez pas dépendre d'un dépôt externe.
- Vous souhaitez maîtriser strictement les failles de votre environnement de production.
- Vous voulez le même système d'exploitation de base dans chaque image.
Envisagez les approches suivantes pour sécuriser votre chaîne d'approvisionnement logicielle:
- Configurez des compilations automatiques afin que vos artefacts aient un contenu cohérent et connu. Vous pouvez utiliser des déclencheurs de compilation Cloud Build ou d'autres outils d'intégration continue.
- Utilisez des images de base standardisées. Google fournit des images de base que vous pouvez utiliser.
- Corrigez les failles de vos artefacts. Vous pouvez utiliser l'API On-Demand Scanning pour rechercher des failles dans les images de conteneurs avant de les stocker dans Artifact Registry. Artifact Analysis peut également analyser les conteneurs que vous transférez vers Artifact Registry.
- Appliquez vos normes internes sur les déploiements d'images. L'autorisation binaire assure l'application pour les déploiements d'images de conteneurs dans les environnements Google Cloud compatibles.
En savoir plus sur les éléments à prendre en compte concernant les images publiques
Dépôts Artifact Registry publics
Vous pouvez rendre public un dépôt Artifact Registry en attribuant le rôle Lecteur Artifact Registry à l'identité allUsers.
Si tous vos utilisateurs possèdent un compte Google Cloud, vous pouvez limiter l'accès aux utilisateurs authentifiés à l'aide de l'identité allAuthenticatedUsers.
Tenez compte des consignes suivantes avant de rendre un dépôt Artifact Registry public:
- Vérifiez que tous les artefacts que vous stockez dans le dépôt peuvent être partagés publiquement et qu'ils n'exposent pas d'identifiants, de données à caractère personnel ni de données confidentielles.
- Le transfert de données réseau vous est facturé lorsque les utilisateurs téléchargent des artefacts. Si vous prévoyez un important trafic de téléchargement sur Internet, tenez compte des coûts associés.
- Par défaut, les projets disposent d'un quota par utilisateur illimité. Pour éviter toute utilisation abusive, limitez le quota par utilisateur dans votre projet.
Conseils pour les applications Web
- Le top 10 de l'OWASP recense les principaux risques de sécurité pour les applications Web selon le projet OSWAP (Open Web Application Security Project).
Conseils pour les conteneurs
La page Bonnes pratiques pour la création de conteneurs inclut des recommandations pour la création de conteneurs.
Vous pouvez également consulter les bonnes pratiques Docker pour la création d'images.
La page Bonnes pratiques pour l'exploitation de conteneurs comprend des recommandations en matière de sécurité, de surveillance et de journalisation qui facilitent l'exécution des applications dans Google Kubernetes Engine et dans les conteneurs en général.
Le CIS (Center for Internet Security) dispose d'un benchmark Docker permettant d'évaluer la sécurité d'un conteneur Docker.
Docker fournit un script Open Source appelé Docker Bench for Security. Vous pouvez exécuter ce script pour vérifier qu'un conteneur Docker en cours d'exécution respecte certains critères du benchmark Docker du CIS.
Le script Docker Bench for Security vous permet de vérifier de nombreux éléments dans le benchmark Docker du CIS. Cependant, tous les éléments ne sont pas vérifiables avec le script. Par exemple, le script ne peut pas vérifier si l'hôte du conteneur est renforcé ou si l'image du conteneur inclut des données à caractère personnel. Examinez tous les éléments du benchmark et identifiez ceux qui peuvent nécessiter une validation supplémentaire.
Étapes suivantes
En savoir plus sur la gestion des dépendances