Cette page décrit les services et les fonctionnalités qui vous aident à protéger vos artefacts. Cloud de Confiance
Chiffrement au repos
Par défaut, Cloud de Confiance by S3NS 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 (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 le minimum d'autorisations requises par les utilisateurs et les comptes de service.
Prévenez l'exfiltration de données
Pour éviter l'exfiltration de données, vous pouvez utiliser VPC Service Controls pour placer Artifact Registry et d'autres services Cloud de Confiance by S3NS dans un périmètre de sécurité réseau.
Supprimer les images inutilisées
Supprimez les images de conteneurs inutilisées pour réduire les coûts de stockage et atténuer les risques liés à l'utilisation d'anciens logiciels. Plusieurs 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é des informations dans le travail quotidien peut contribuer à améliorer les performances de livraison des 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 pour la sécurité fait partie des capacités DevOps identifiées dans le programme de recherche sur l'état du DevOps de DORA.
Pour en savoir plus :
- En savoir plus sur la fonctionnalité Intégrer la sécurité dès le départ
Éléments à prendre en compte pour les dépôts publics
Soyez très attentif aux points suivants :
- Utilisation d'artefacts provenant de sources publiques
- Rendre vos propres dépôts Artifact Registry publics
Utiliser des artefacts provenant de sources publiques
Les sources publiques d'artefacts suivantes fournissent des outils que vous pouvez utiliser ou des dépendances pour vos compilations et déploiements :
Toutefois, votre organisation peut avoir des contraintes qui ont un impact sur 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.
Voici quelques approches à envisager pour sécuriser votre chaîne d'approvisionnement logicielle :
- Utilisez des images de base standardisées. Google fournit des images de base que vous pouvez utiliser.
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 disposent de comptes Cloud de Confiance , vous pouvez limiter l'accès aux utilisateurs authentifiés avec l'identité allAuthenticatedUsers.
Tenez compte des consignes suivantes avant de rendre public un dépôt Artifact Registry :
- Vérifiez que tous les artefacts que vous stockez dans le dépôt sont partageables publiquement et n'exposent pas d'identifiants, de données personnelles ni de données confidentielles.
- Par défaut, les projets ont des quotas par utilisateur illimités. Pour éviter tout abus, limitez les quotas par utilisateur dans votre projet.
Conseils pour les applications Web
- Le Top 10 de l'OWASP liste les principaux risques de sécurité pour les applications Web selon l'Open Web Application Security Project (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.