Sécuriser les artefacts

Cette page décrit les services et les fonctionnalités Google Cloud qui vous aident à sécuriser les artefacts, ainsi que certaines bonnes pratiques pour protéger vos données.

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 concernant les 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.

Analyse des failles

Container Analysis peut analyser les images de conteneur à l'aide de packages surveillés publiquement.

Les options suivantes sont disponibles :

Analyse automatique des failles
Lorsque cette fonctionnalité est activée, cette fonctionnalité 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 afin d'identifier de nouvelles failles jusqu'à 30 jours après leur transfert.
API à la demande
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 plus tôt dans 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 elle détecte les failles à un niveau de gravité spécifié. Si vous avez également activé l'analyse automatique des failles, Container Analysis analyse également les images que vous importez dans le registre.

Stratégie de déploiement

Vous pouvez utiliserAutorisation binaire pour configurer une stratégie appliquée par le service lorsqu'une tentative de déploiement d'une image de conteneur est enregistréeenvironnements Google Cloud compatibles s'affiche en haut de l'écran.

Par exemple, vous pouvez configurer l'autorisation binaire de sorte qu'elle n'autorise les déploiements que si une image est signée pour la conformité aux règles 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 limiter les risques d'utilisation d'un logiciel plus ancien. Un certain nombre d'outils sont disponibles pour vous aider dans 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

L'intégration des objectifs de sécurité de l'information dans le travail quotidien peut contribuer à améliorer les performances de livraison de logiciels et à concevoir 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 des logiciels (c leftest-à-dire situées à gauche). – Schéma de droite). La migration vers la gauche est l'une des fonctionnalités DevOps identifiées dans le programme de recherche d'état de DORA.

Pour en savoir plus :

  • Découvrez la fonctionnalité Shifting left on security (Faire évoluer vers la sécurité).
  • Consulter le livre blanc Passer à la sécurité , qui décrit les responsabilités, les pratiques, les processus, les outils et les techniques qui augmentent la confiance dans le cycle de développement logiciel (SDLC) et réduisant les risques de sécurité.

Informations spécifiques aux dépôts publics

Réfléchissez attentivement aux cas suivants:

  • Utilisation d'artefacts issus de sources publiques
  • Rendre vos dépôts Artifact Registry publics

Utiliser des artefacts issus de sources publiques

Sources publiques d'artefacts, telles queGitHub Docker Hub ,PyPI, ou Registre public npm fournir des outils que vous pouvez utiliser ou des dépendances pour vos compilations et vos déploiements.

Toutefois, votre organisation peut avoir des contraintes qui affectent 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.

Considérez les approches suivantes pour sécuriser votre chaîne d'approvisionnement logicielle:

  • Configurez des compilations automatiques de sorte que vos artefacts aient un contenu cohérent et connu. Vous pouvez utiliser les 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 d'analyse à la demande pour rechercher les failles des images de conteneurs avant de les stocker dans Artifact Registry. Container Analysis peut également analyser les conteneurs que vous transférez à Artifact Registry.
  • Appliquez vos normes internes sur les déploiements d'images. L'autorisation binaire permet de forcer les déploiements d'images de conteneurs dans les environnements Google Cloud compatibles.

En savoir plus sur les considérations concernant les images publiques

Dépôts du dépôt d'artefacts publics

Vous pouvez rendre un dépôt Artifact Registry public en attribuant le rôle Lecteur d'artefacts à l'identité allUsers.

Si tous vos utilisateurs possèdent des comptes 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 ne présentez pas d'identifiants, de données à caractère personnel ni de données confidentielles.
  • Des sorties de réseau vous sont facturées lorsque les utilisateurs téléchargent des artefacts. Si vous prévoyez un trafic de téléchargement Internet important, prenez en compte les coûts associés.
  • Par défaut, les projets ont un quota illimité par utilisateur. Pour éviter les abus, le plafond par utilisateur dans votre projet.

Conseils pour les applications Web

  • Le Top 10 OWASP répertorie les principaux risques de sécurité des applications Web en fonction du projet OSP (Open Web Application Security Project).

Conseils pour les conteneurs

  • Les bonnes pratiques pour la création de conteneurs incluent des recommandations pour la création de conteneurs.

    Vous pouvez également consulter les bonnes pratiques de Docker concernant la création d'images.

  • Les bonnes pratiques pour l'exploitation de conteneurs incluent des recommandations portant sur la sécurité, la surveillance et la journalisation, pour une exécution plus simple des applications dans Google Kubernetes Engine et des 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.