Contrôler l'accès et protéger les artefacts

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ées à l'aide de 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é de le principe du moindre privilège et n'accordez que les autorisations minimales dont sont 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 réseau périmètre de sécurité.

Analyse des failles

Artifact Analysis peut rechercher les failles de sécurité dans les images de conteneurs en se basant sur des packages surveillés publiquement.

Les options suivantes sont disponibles :

Analyse automatique des failles
Lorsqu'elle est activée, cette fonctionnalité identifie les failles des paquets dans votre des images de conteneurs. Les images sont analysées lors de leur importation Artifact Registry. Les données sont surveillées en permanence pour détecter de nouveaux jusqu'à 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 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 l'avoir et ensuite Bloquer l'importation dans Artifact Registry si l'analyse détecte des failles à un niveau de gravité spécifié. Si vous l'analyse automatique des failles, Artifact Analysis analyse les images que vous importez dans le registre.

Stratégie de déploiement

Vous pouvez utiliser l'autorisation binaire pour configurer une stratégie que le service applique en cas de tentative de déploiement d'une image de conteneur dans l'un des environnements Google Cloud compatibles.

Par exemple, vous pouvez configurer l'autorisation binaire pour n'autoriser les déploiements que si est signée pour respecter une règle d'analyse des failles.

Supprimer les images inutilisées

Supprimez les images de conteneur inutilisées pour réduire les coûts de stockage et atténuer les risques liés à l'utilisation de logiciels plus anciens. Plusieurs outils sont à votre disposition pour vous aider cette tâche, y compris gcr-cleaner. L'outil gcr-cleaner n'est pas un produit Google officiel.

Intégrer la sécurité dès le départ

Intégrer les objectifs de sécurité de l'information dans le travail quotidien peut contribuer à améliorer les performances de livraison de logiciels et à créer des systèmes plus sécurisés. Cette approche 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 situées à gauche sur un planning d'exécution de gauche à droite). Le virage à gauche vers la sécurité est l'un des principes du DevOps les fonctionnalités identifiées dans le Programme de recherche DORA sur l'état du DevOps

Pour en savoir plus :

  • En savoir plus sur les Une sécurité renforcée de Google Cloud.
  • Lire le livre blanc Passer à la sécurité suivante, décrit les responsabilités, les pratiques, les processus, les outils et les techniques qui de renforcer la confiance dans le cycle de vie du développement logiciel (SDLC) et de réduire les préoccupations liées aux risques de sécurité.

Remarques concernant les 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 d'artefacts publiques suivantes fournissent des outils que vous pouvez utiliser ou pour vos compilations et déploiements:

Cependant, votre organisation peut avoir des contraintes qui ont un impact sur votre utilisation des 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 pour que vos artefacts aient des valeurs contenus. Vous pouvez utiliser Cloud Build déclencheurs de compilation ou autres les 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 dans vos artefacts. Vous pouvez utiliser l'API On-Demand Scanning pour rechercher les failles des images de conteneurs avant de les stocker dans Artifact Registry. Artifact Analysis peut également analyser les conteneurs que vous transférez vers Artifact Registry.

Dépôts Artifact Registry publics

Vous pouvez rendre un dépôt Artifact Registry public en accordant le rôle de 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 avec l'identité allAuthenticatedUsers.

Tenez compte des consignes suivantes avant de créer un dépôt Artifact Registry public du dépôt:

  • Vérifier que tous les artefacts que vous stockez dans le dépôt peuvent être partagés publiquement et ne divulguez pas d'identifiants, de données à caractère personnel ni de données confidentielles.
  • Par défaut, les projets disposent d'un quota illimité par utilisateur. À empêcher les abus, limiter le quota par utilisateur dans votre projet.
  • Le transfert de données réseau vous est facturé lorsque les utilisateurs téléchargent des artefacts. Si vous prévoyez un débit Internet important le trafic, tenez compte des coûts associés.

Conseils pour les applications Web

  • Top 10 de l'OWASP liste les principaux risques de sécurité pour les applications Web d'après l'OpenWeb Projet de sécurité des applications (OSWAP).

Conseils pour les conteneurs

  • 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.

Étape suivante

En savoir plus sur la gestion des dépendances