Concevoir des pipelines de déploiement sécurisés

Last reviewed 2023-09-28 UTC

Un pipeline de déploiement est un processus automatisé qui prend le code ou les artefacts prédéfinis et les déploie dans un environnement de test ou de production. Les pipelines de déploiement sont couramment utilisés pour déployer des applications, une configuration ou une infrastructure cloud (infrastructure en tant que code), et peuvent jouer un rôle important dans l'état de sécurité global d'un déploiement cloud.

Ce guide est destiné aux ingénieurs DevOps et de sécurité et décrit les bonnes pratiques concernant la conception de pipelines de déploiement sécurisés en fonction de vos exigences en termes de confidentialité, d'intégrité et de disponibilité.

Architecture

Le schéma suivant illustre le flux de données dans un pipeline de déploiement. Il montre comment transformer vos artefacts en ressources.

L'artefact circule dans un pipeline de déploiement et génère une ressource.

Les pipelines de déploiement font souvent partie d'un workflow d'intégration continue/de déploiement continu (CI/CD) plus important et sont généralement mis en œuvre à l'aide de l'un des modèles suivants :

Modèle push : Dans ce modèle, vous mettez en œuvre le pipeline de déploiement à l'aide d'un système CI/CD central tel que Jenkins ou GitLab. Ce système CI/CD peut s'exécuter sur Google Cloud, sur site ou dans un autre environnement cloud. Souvent, le même système CI/CD est utilisé pour gérer plusieurs pipelines de déploiement.

Le modèle push conduit à une architecture centralisée avec quelques systèmes CI/CD qui gèrent un grand nombre de ressources ou d'applications. Par exemple, vous pouvez utiliser une seule instance Jenkins ou GitLab pour gérer l'intégralité de votre environnement de production, y compris tous ses projets et applications.
Extraire le modèle : Dans ce modèle, le processus de déploiement est mis en œuvre par un agent déployé avec la ressource, par exemple, dans le même cluster Kubernetes. L'agent extrait les artefacts ou le code source d'un emplacement centralisé et les déploie localement. Chaque agent gère une ou deux ressources.

Le modèle pull engendre une architecture plus décentralisée avec un nombre potentiellement élevé d'agents à usage unique.

Par rapport aux déploiements manuels, l'utilisation cohérente des pipelines de déploiement peut offrir les avantages suivants :

Efficacité accrue, car aucun travail manuel n'est requis.
Fiabilité accrue, car le processus est entièrement automatisé et reproductible.
Traçabilité accrue, car vous pouvez suivre tous les déploiements jusqu'aux modifications de code ou aux artefacts d'entrée.

Pour fonctionner, un pipeline de déploiement doit avoir accès aux ressources qu'il gère :

Un pipeline qui déploie une infrastructure à l'aide d'outils tels que Terraform peut avoir besoin de créer, de modifier ou même de supprimer des ressources telles que des instances de VM, des sous-réseaux ou des buckets Cloud Storage.
Un pipeline qui déploie des applications peut avoir besoin d'importer de nouvelles images de conteneurs dans Artifact Registry et de déployer des nouvelles versions d'application sur App Engine et Cloud Run. ou Google Kubernetes Engine (GKE).
Un pipeline qui gère les paramètres ou déploie les fichiers de configuration peut avoir besoin de modifier les métadonnées des instances de VM, les configurations Kubernetes ou les données dans Cloud Storage.

Si vos pipelines de déploiement ne sont pas correctement sécurisés, leur accès aux ressources Google Cloud peut devenir un point faible dans votre stratégie de sécurité. Une sécurité faible peut entraîner plusieurs types d'attaques, y compris les suivants :

Attaques par empoisonnement du pipeline : au lieu de s'attaquer directement à une ressource, un acteur malintentionné peut tenter de compromettre le pipeline de déploiement, sa configuration ou son infrastructure sous-jacente. En tirant parti de l'accès du pipeline à Google Cloud, l'acteur malintentionné peut faire en sorte que ce pipeline effectue des actions malveillantes sur les ressources cloud, comme illustré dans le schéma suivant :
Attaques de chaîne d'approvisionnement : au lieu d'attaquer le pipeline de déploiement, un acteur malintentionné peut tenter de compromettre ou de remplacer l'entrée du pipeline, y compris le code source, les bibliothèques ou les images de conteneur, comme illustré dans schéma suivant :

Pour déterminer si vos pipelines de déploiement sont correctement sécurisés, il ne suffit pas d'examiner les stratégies d'autorisation et de refus des ressources Google Cloud en isolement. Vous devez plutôt examiner l'ensemble du graphe des systèmes qui accordent directement ou indirectement l'accès à une ressource. Ce graphe contient les informations suivantes :

Le pipeline de déploiement, son système CI/CD sous-jacent et son infrastructure sous-jacente.
Le dépôt de code source, ses serveurs sous-jacents et son infrastructure sous-jacente.
Les artefacts d'entrée, leurs emplacements de stockage et leur infrastructure sous-jacente.
Les systèmes qui produisent les artefacts d'entrée et leur infrastructure sous-jacente.

Les graphes d'entrée complexes compliquent l'identification des accès utilisateur aux ressources et aux faiblesses systémiques.

Les sections suivantes décrivent les bonnes pratiques pour concevoir des pipelines de déploiement de manière à vous aider à gérer la taille du graphe et à réduire le risque de mouvement latéral et d'attaques sur la chaîne d'approvisionnement.

Évaluer les objectifs de sécurité

La sensibilité de vos ressources sur Google Cloud est susceptible de varier. Certaines ressources peuvent être très sensibles, car elles sont critiques pour l'entreprise ou confidentielles. D'autres ressources peuvent être moins sensibles, car elles sont éphémères ou uniquement destinées à des tests.

Pour concevoir un pipeline de déploiement sécurisé, vous devez d'abord comprendre les ressources auxquelles le pipeline doit accéder, ainsi que leur niveau de sensibilité. Plus vos ressources sont sensibles, plus vous devez vous concentrer sur la sécurisation du pipeline.

Les ressources accessibles par les pipelines de déploiement peuvent inclure les éléments suivants :

Les applications, telles que Cloud Run ou App Engine.
Les ressources cloud, telles que les instances de VM ou les buckets Cloud Storage.
Les données, telles que les objets Cloud Storage, les enregistrements BigQuery ou les fichiers.

Certaines de ces ressources peuvent avoir des dépendances sur d'autres ressources, par exemple :

Les applications peuvent accéder aux données, aux ressources cloud et à d'autres applications.
Les ressources cloud, telles que les instances de VM ou les buckets Cloud Storage, peuvent contenir des applications ou des données.

Comme le montre le schéma précédent, les dépendances affectent la sensibilité d'une ressource. Par exemple, si vous utilisez une application qui accède à des données très sensibles, vous devez généralement traiter cette application comme très sensible. De même, si une ressource cloud, telle qu'un bucket Cloud Storage, contient des données sensibles, vous devez généralement traiter le bucket comme sensible.

En raison de ces dépendances, il est préférable d'évaluer d'abord la sensibilité des données. Une fois vos données évaluées, vous pouvez examiner la chaîne de dépendance et évaluer la sensibilité de vos ressources et applications Cloud.

Catégoriser la sensibilité de vos données

Pour comprendre la sensibilité des données dans votre pipeline de déploiement, considérons les trois objectifs suivants :

Confidentialité : vous devez protéger les données contre tout accès non autorisé.
Intégrité : vous devez protéger les données contre toute modification ou suppression non autorisée.
Disponibilité : vous devez vous assurer que les personnes et les systèmes autorisés peuvent accéder aux données de votre pipeline de déploiement.

Pour chacun de ces objectifs, demandez-vous ce qui se passerait si votre pipeline était compromis :

Confidentialité : Quel est l'impact d'une divulgation de données à un acteur malintentionné ou d'une fuite publique ?
Intégrité : Quel est l'impact d'un acteur malintentionné sur vos données ?
Disponibilité : Quel est l'impact d'un acteur malintentionné sur votre accès aux données ?

Pour rendre les résultats comparables entre les ressources, il est utile d'introduire des catégories de sécurité. La norme FIPS-199 (Standards for Security Categorization) suggère d'utiliser les quatre catégories suivantes :

Élevé : les dommages seraient graves ou catastrophiques.
Modéré : les dommages seraient graves.
Faible : les dommages seraient limités.
Non applicable : la norme ne s'applique pas.

Selon votre environnement et le contexte, un autre ensemble de catégories peut être plus approprié.

La confidentialité et l'intégrité des données du pipeline s'inscrivent sur un spectre, qui est basé sur les catégories de sécurité que nous venons d'aborder. Les sous-sections suivantes contiennent des exemples de ressources avec différentes mesures de confidentialité et d'intégrité :

Ressources présentant une faible confidentialité, mais une intégrité faible, modérée ou élevée

Les exemples de ressources suivants présentent tous une faible confidentialité :

Intégrité faible : données de test.
Intégrité modérée : contenu de serveur Web public et contraintes liées aux règles pour votre organisation.
Intégrité élevée : images de conteneurs, images disque, configurations d'application, règles d'accès (listes d'autorisation et de refus), privilèges, données de niveau d'accès.

Ressources présentant une confidentialité moyenne, mais une intégrité faible, modérée ou élevée

Les exemples de ressources suivants présentent tous une confidentialité moyenne :

Intégrité faible : contenu interne du serveur Web.
Intégrité modérée : journaux d'audit.
Intégrité élevée : fichiers de configuration de l'application.

Ressources présentant une confidentialité élevée, mais une intégrité faible, modérée ou élevée

Les exemples de ressources suivants présentent tous une confidentialité élevée :

Intégrité faible : données d'utilisation et informations permettant d'identifier personnellement l'utilisateur.
Intégrité modérée : secrets.
Intégrité élevée : données financières, clés KMS.

Classer les applications en fonction des données auxquelles elles accèdent

Lorsqu'une application accède à des données sensibles, l'application et le pipeline de déploiement qui gère l'application peuvent également devenir sensibles. Pour qualifier cette sensibilité, examinez les données auxquelles l'application et le pipeline doivent accéder.

Une fois que vous avez identifié et classifié toutes les données auxquelles une application accède, vous pouvez utiliser les catégories suivantes pour classer l'application dans un premier temps avant de concevoir un pipeline de déploiement sécurisé :

Confidentialité : catégorie la plus élevée parmi toutes les données consultées.
Intégrité : catégorie la plus élevée parmi toutes les données consultées.
Disponibilité : catégorie la plus élevée parmi toutes les données consultées.

Cette évaluation initiale fournit des conseils, mais il existe d'autres facteurs à prendre en compte, par exemple :

Deux ensembles de données peuvent présenter une faible confidentialité de manière isolée. Toutefois, en les combinant, ils peuvent révéler de nouveaux insights. Si une application a accès aux deux ensembles de données, vous devrez peut-être la classer comme ayant un niveau de confidentialité moyen ou élevé.
Si une application a accès à des données à haute intégrité, vous devez généralement classer celle-ci comme étant de haute intégrité. Toutefois, si cet accès est en lecture seule, une catégorisation d'intégrité élevée peut s'avérer trop stricte.

Pour en savoir plus sur une approche formelle pour la classification des applications, consultez le Guide des types de mappage entres informations/systèmes d'information et catégories de sécurité (NIST SP 800-60, Vol. 2 Rev1).

Catégoriser les ressources cloud en fonction des données et des applications qu'elles hébergent

Toutes les données ou applications que vous déployez sur Google Cloud sont hébergées par une ressource Google Cloud :

Une application peut être hébergée par un service App Engine, une instance de VM ou un cluster GKE.
Vos données peuvent être hébergées sur un disque persistant, un bucket Cloud Storage ou un ensemble de données BigQuery.

Lorsqu'une ressource cloud héberge des données ou des applications sensibles, la ressource et le pipeline de déploiement qui les gèrent peuvent également devenir sensibles. Par exemple, vous devez considérer un service Cloud Run et son pipeline de déploiement comme étant aussi sensibles que l'application qu'ils hébergent.

Après avoir catégorisé vos données et vos applications, créez une catégorie de sécurité initiale pour l'application. Pour ce faire, déterminez un niveau parmi les catégories suivantes :

Confidentialité : catégorie la plus élevée parmi toutes les données ou applications hébergées.
Intégrité : catégorie la plus élevée parmi toutes les données ou applications hébergées.
Disponibilité : catégorie la plus élevée parmi toutes les données ou applications hébergées.

Ne soyez pas trop strict dans votre évaluation initiale, par exemple :

Si vous chiffrez des données hautement confidentielles, traitez la clé de chiffrement comme étant hautement confidentielle. Toutefois, vous pouvez utiliser une catégorie de sécurité inférieure pour la ressource contenant les données.
Si vous stockez des copies redondantes de données ou exécutez des instances redondantes des mêmes applications sur plusieurs ressources, vous pouvez réduire la catégorie de la ressource à celle des données ou de l'application qu'elle héberge.

Limiter l'utilisation des pipelines de déploiement

Si votre pipeline de déploiement doit accéder à des ressources Google Cloud sensibles, vous devez tenir compte de sa stratégie de sécurité. Plus les ressources sont sensibles, plus vous devez essayer de sécuriser le pipeline. Toutefois, vous pouvez rencontrer les limites pratiques suivantes :

Lorsque vous utilisez une infrastructure existante ou un système CI/CD existant, cette infrastructure peut limiter le niveau de sécurité que vous pouvez atteindre de manière réaliste. Par exemple, votre système CI/CD peut n'accepter qu'un ensemble limité de contrôles de sécurité ou s'exécuter sur une infrastructure que vous considérez comme moins sécurisée que certains de vos environnements de production.
Lorsque vous configurez une nouvelle infrastructure et des systèmes pour exécuter votre pipeline de déploiement, la sécurisation de tous les composants de manière à répondre à vos exigences de sécurité les plus strictes peut ne pas être rentable.

Pour gérer ces limitations, il peut être utile de définir des contraintes sur les scénarios qui doivent et ne doivent pas utiliser des pipelines de déploiement et un système CI/CD spécifique. Par exemple, les déploiements les plus sensibles sont souvent mieux gérés en dehors d'un pipeline de déploiement. Ces déploiements peuvent être manuels, avec un système de gestion de session utilisant des privilèges, un système de gestion d'accès privilégié ou un autre système (proxys d'outil, par exemple).

Pour définir vos contraintes, définissez les contrôles d'accès que vous souhaitez appliquer en fonction de vos catégories de ressources. Tenez compte des conseils fournis dans le tableau suivant :

Catégorie de ressource	Contrôle des accès
Faible	Aucune approbation requise
Moyenne	Le responsable d'équipe doit approuver la demande
Élevée	Plusieurs prospects doivent être approuvés et les actions doivent être enregistrées

Comparez ces exigences aux capacités de vos systèmes de gestion de code source et CI/CD en posant les questions suivantes (et d'autres) :

Vos systèmes SCM ou CI/CD prennent-ils en charge les contrôles d'accès et les mécanismes d'approbation nécessaires ?
Les contrôles restent-ils effectifs si des acteurs malintentionnés attaquent l'infrastructure sous-jacente ?
La configuration qui définit les contrôles est-elle correctement sécurisée ?

En fonction des capacités et des limitations imposées par vos systèmes SCM ou CI/CD, vous pouvez définir vos contraintes de données et d'applications pour vos pipelines de déploiement. Tenez compte des conseils fournis dans le tableau suivant :

Catégorie de ressource	Contraintes
Faible	Vous pouvez utiliser des pipelines de déploiement et les développeurs peuvent approuver eux-mêmes les déploiements.
Moyenne	Les pipelines de déploiement peuvent être utilisés, mais un responsable d'équipe doit approuver chaque commit et déploiement.
Élevée	N'utilisez pas les pipelines de déploiement. Les administrateurs doivent utiliser un système de gestion des accès privilégié et enregistrer les sessions.

Maintenir la disponibilité des ressources

L'utilisation d'un pipeline de déploiement pour gérer les ressources peut avoir un impact sur la disponibilité de ces ressources et présenter de nouveaux risques :

Causer des pannes : un pipeline de déploiement peut transférer du code ou des fichiers de configuration défectueux, mettre hors service un système précédemment opérationnel ou rendre des données inutilisables.
Prolonger des pannes : pour résoudre une panne, vous devrez peut-être réexécuter un pipeline de déploiement. Si le pipeline de déploiement est interrompu ou indisponible pour d'autres raisons, cela peut prolonger la panne.

Un pipeline pouvant provoquer ou prolonger des interruptions de service présente un risque de déni de service : un acteur malintentionné peut utiliser le pipeline de déploiement pour provoquer intentionnellement une panne.

Créer des procédures d'accès d'urgence

Lorsqu'un pipeline de déploiement est le seul moyen de déployer ou de configurer une application ou une ressource, la disponibilité du pipeline peut devenir critique. Dans les cas extrêmes, où un pipeline de déploiement est le seul moyen de gérer une application critique, vous devrez peut-être également envisager de considérer le pipeline de déploiement comme stratégique.

Étant donné que les pipelines de déploiement sont souvent composés de plusieurs systèmes et outils, il peut être difficile ou coûteux de maintenir un haut niveau de disponibilité.

Vous pouvez réduire l'influence des pipelines de déploiement sur la disponibilité en créant des procédures d'accès d'urgence. Par exemple, créez un autre chemin d'accès qui peut être utilisé si le pipeline de déploiement n'est pas opérationnel.

La création d'une procédure d'accès d'urgence nécessite généralement la plupart des processus suivants :

Gérer un ou plusieurs comptes utilisateur avec un accès privilégié aux ressources Google Cloud concernées.
Stocker les identifiants des comptes utilisateur avec accès d'urgence dans un endroit sûr ou utiliser un système de gestion des accès avec privilèges pour obtenir l'accès.
Établir une procédure que les employés autorisés peuvent suivre pour accéder aux identifiants.
Auditer et examiner l'utilisation des comptes utilisateur avec accès d'urgence.

S'assurer que les artefacts d'entrée répondent à vos exigences de disponibilité

Les pipelines de déploiement doivent généralement télécharger le code source à partir d'un dépôt de code source central avant de pouvoir effectuer un déploiement. Si le dépôt de code source n'est pas disponible, l'exécution du pipeline de déploiement risque d'échouer.

De nombreux pipelines de déploiement dépendent également d'artefacts tiers. Ces artefacts peuvent inclure des bibliothèques provenant de sources telles que npm, Maven Central ou NuGet Gallery, des images de base de conteneurs, des .deb et des packages .rpm. Si l'une des sources tierces n'est pas disponible, l'exécution du pipeline de déploiement risque d'échouer.

Pour maintenir un certain niveau de disponibilité, vous devez vous assurer que les artefacts d'entrée de votre pipeline de déploiement répondent tous aux mêmes exigences de disponibilité. La liste suivante peut vous aider à garantir la disponibilité des artefacts d'entrée :

Limiter le nombre de sources pour les artefacts d'entrée, en particulier les sources tierces.
Conserver un cache d'artefacts d'entrée que les pipelines de déploiement peuvent utiliser si les systèmes sources ne sont pas disponibles.

Traiter les pipelines de déploiement et leur infrastructure comme des systèmes de production

Les pipelines de déploiement servent souvent de tissu conjonctif entre les environnements de développement, de préproduction et de production. Selon l'environnement, ils peuvent mettre en œuvre plusieurs étapes :

Dans un premier temps, le pipeline de déploiement met à jour un environnement de développement.
À l'étape suivante, le pipeline de déploiement met à jour un environnement de préproduction.
Au cours de la dernière étape, le pipeline de déploiement met à jour l'environnement de production.

Lorsque vous utilisez un pipeline de déploiement dans plusieurs environnements, assurez-vous qu'il répond aux exigences de disponibilité de chaque environnement. Étant donné que les environnements de production présentent généralement les exigences de disponibilité les plus élevées, vous devez traiter le pipeline de déploiement et son infrastructure sous-jacente comme un système de production. En d'autres termes, appliquez les mêmes normes de contrôle d'accès, de sécurité et de qualité à l'infrastructure qui exécute vos pipelines de déploiement qu'à celle de vos systèmes de production.

Limiter le champ d'application des pipelines de déploiement

Plus le pipeline de déploiement peut accéder à des ressources, plus les dommages potentiels sont importants si le pipeline est compromis. Un pipeline de déploiement compromis qui a accès à plusieurs projets, voire à l'ensemble de votre organisation, pourrait, dans le pire des cas, causer des dommages durables sur toutes vos données et applications sur Google Cloud.

Pour éviter ce pire scénario, limitez le champ d'application de vos pipelines de déploiement. Définissez le champ d'application de chaque pipeline de déploiement, afin qu'il n'ait besoin d'accéder qu'à un nombre relativement réduit de ressources sur Google Cloud :

Au lieu d'accorder l'accès au niveau du projet, accordez uniquement aux pipelines de déploiement l'accès à des ressources individuelles.
Évitez d'accorder l'accès aux ressources sur plusieurs projets Google Cloud.
Divisez les pipelines de déploiement en plusieurs étapes s'ils doivent accéder à plusieurs projets ou environnements. Ensuite, sécurisez les étapes individuellement.

Maintenir la confidentialité

Un pipeline de déploiement doit maintenir la confidentialité des données qu'il gère. L'un des principaux risques liés à la confidentialité est l'exfiltration de données.

Un acteur malintentionné peut tenter d'utiliser un pipeline de déploiement de plusieurs manières pour exfiltrer des données de vos ressources Google Cloud. Ces manières incluent :

Exfiltration directe : un acteur malintentionné peut modifier le pipeline de déploiement ou sa configuration afin d'extraire les données de vos ressources Google Cloud et de les copier ailleurs.
Exfiltration indirecte : un acteur malintentionné peut utiliser le pipeline de déploiement pour déployer du code compromis, qui vole ensuite des données depuis votre environnement Google Cloud.

Vous pouvez réduire les risques liés à la confidentialité en minimisant l'accès aux ressources confidentielles. Cependant, il peut être difficile de supprimer tous les accès à des ressources confidentielles. Par conséquent, vous devez concevoir votre pipeline de déploiement de façon à répondre aux exigences de confidentialité des ressources qu'il gère. Pour déterminer ces exigences, vous pouvez utiliser l'approche suivante :

Déterminer les données, les applications et les ressources auxquelles le pipeline de déploiement doit accéder, puis les catégoriser.
Rechercher la ressource avec la catégorie de confidentialité la plus élevée et l'utiliser comme catégorie initiale pour le pipeline de déploiement.

À l'instar du processus de catégorisation pour les applications et les ressources cloud, cette évaluation initiale n'est pas toujours appropriée. Par exemple, vous pouvez utiliser un pipeline de déploiement pour créer des ressources qui contiendront à terme des informations hautement confidentielles. Si vous limitez le pipeline de déploiement de sorte qu'il puisse créer ces ressources (mais pas les lire), une catégorie de confidentialité inférieure peut être suffisante.

Pour maintenir la confidentialité, le modèle Bell–LaPadula suggère qu'un pipeline de déploiement ne doit pas :

Utiliser des artefacts d'entrée de confidentialité plus élevée.
Écrire des données dans une ressource de confidentialité plus faible.

Le modèle Bell-LaPadula.

Selon le modèle Bell-LaPadula, le schéma précédent montre comment les données doivent circuler dans le pipeline pour assurer la confidentialité des données.

Ne pas laisser les pipelines de déploiement lire les données dont ils n'ont pas besoin

Souvent, les pipelines de déploiement ont accès à des données dont ils n'ont pas besoin. Un tel octroi d'accès excessif peut entraîner les conséquences suivantes :

Accorder des autorisations d'accès incorrectes. Par exemple, un pipeline de déploiement peut disposer d'un accès à Cloud Storage au niveau du projet. Par conséquent, le pipeline de déploiement peut accéder à tous les buckets Cloud Storage du projet, même si l'accès à un seul bucket peut être suffisant.
Utiliser un rôle trop permissif. Un pipeline de déploiement peut se voir attribuer un rôle fournissant un accès complet à Cloud Storage, par exemple. Toutefois, l'autorisation de créer des buckets peut être suffisante.

Plus le pipeline peut accéder à des données, plus le risque de vol de vos données est élevé. Pour réduire ce risque, évitez d'accorder aux pipelines de déploiement l'accès à des données dont ils n'ont pas besoin. De nombreux pipelines de déploiement n'ont pas du tout besoin d'accès aux données, car leur seul but est de gérer les déploiements de configuration ou de logiciels.

Ne pas laisser les pipelines de déploiement écrire dans des emplacements dont ils n'ont pas besoin

Pour supprimer des données, un acteur malintentionné a besoin d'un accès et d'un moyen de transférer les données hors de votre environnement. Plus le réseau et les emplacements de stockage auxquels un pipeline de déploiement peut envoyer des données sont nombreux, plus il est probable qu'un acteur malintentionné puisse utiliser l'un de ces emplacements pour exfiltrer des données.

Vous pouvez réduire les risques en limitant le nombre d'emplacements réseau et de stockage vers lesquels un pipeline peut envoyer des données :

Révoquer l'accès en écriture aux ressources dont le pipeline n'a pas besoin, même si elles ne contiennent aucune donnée confidentielle.
Bloquer l'accès Internet ou limiter les connexions à un ensemble d'emplacements réseau sur liste d'autorisation.

Limiter l'accès sortant est particulièrement important pour les pipelines que vous avez classés comme moyennement confidentiels ou hautement confidentiels, car ils ont accès à des données confidentielles ou au contenu de clés cryptographiques.

Utiliser VPC Service Controls pour empêcher les déploiements compromis de voler les données

Plutôt de laisser le pipeline de déploiement effectuer l'exfiltration de données, un acteur malintentionné peut tenter d'utiliser le pipeline de déploiement pour déployer du code compromis. Ce code compromis peut ensuite voler des données depuis votre environnement Google Cloud.

Vous pouvez réduire le risque de telles menaces de vol de données avec VPC Service Controls. VPC Service Controls vous permet de restreindre l'ensemble des ressources et des API accessibles depuis certains projets Google Cloud.

Maintenir l'intégrité

Pour sécuriser votre environnement Google Cloud, vous devez protéger son intégrité. Cela inclut :

D'empêcher la modification ou la suppression non autorisées de données ou de configurations.
D'empêcher le déploiement de code ou de configurations non approuvés.
De s'assurer que toutes les modifications sont clairement consignées et auditables.

Les pipelines de déploiement peuvent vous aider à maintenir l'intégrité de votre environnement en effectuant les opérations suivantes :

Mettre en œuvre des processus d'approbation, par exemple sous la forme d'examens de code.
Appliquer un processus cohérent pour toutes les modifications de configuration ou de code.
Exécuter des tests automatisés ou des vérifications rapides avant chaque déploiement.

Pour être efficace, vous devez vous assurer que les acteurs malintentionnés ne peuvent pas compromettre ni contourner ces mesures. Pour éviter une telle activité, vous devez protéger l'intégrité des éléments suivants :

Le pipeline de déploiement et sa configuration.
L'infrastructure sous-jacente.
Toutes les entrées utilisées par le pipeline de déploiement.

Pour empêcher le pipeline de déploiement de devenir vulnérable, veillez à ce que les normes d'intégrité du pipeline de déploiement soient supérieures ou égales aux exigences d'intégrité des ressources qu'il gère. Pour déterminer ces exigences, vous pouvez utiliser l'approche suivante :

Déterminer les données, les applications et les ressources auxquelles le pipeline de déploiement doit accéder, puis les catégoriser.
Rechercher la ressource avec la catégorie d'intégrité la plus élevée et utiliser cette catégorie pour le pipeline de déploiement.

Pour maintenir l'intégrité du pipeline de déploiement, le modèle Biba suggère que :

Le pipeline de déploiement ne doit pas consommer d'artefacts d'entrée d'intégrité inférieure.
Le pipeline de déploiement ne doit pas écrire de données sur une ressource d'intégrité plus élevée.

Le modèle d'intégrité Biba.

Selon le modèle Biba, le schéma précédent montre comment les données doivent circuler dans le pipeline pour garantir leur intégrité.

Vérifier l'authenticité des artefacts d'entrée

De nombreux pipelines de déploiement consomment des artefacts provenant de sources tierces. Ces artefacts peuvent inclure :

Images de base Docker
Packages .rpm ou .deb
Bibliothèques Maven, .npm ou NuGet

Un acteur malintentionné peut tenter de modifier votre pipeline de déploiement afin qu'il utilise des versions compromises d'artefacts tiers de plusieurs manières :

Compromettre le dépôt qui stocke les artefacts.
Modifier la configuration du pipeline de déploiement pour utiliser un dépôt source différent.
Importer des packages malveillants avec des noms similaires ou des noms contenant des fautes de frappe.

De nombreux gestionnaires de packages vous permettent de vérifier l'authenticité d'un package en prenant en charge la signature de code. Par exemple, vous pouvez utiliser PGP pour signer les packages RPM et Maven. Vous pouvez utiliser Authenticode pour signer des packages NuGet.

Vous pouvez utiliser la signature de code pour réduire le risque d'être victime de packages tiers compromis de plusieurs manières :

Exiger que tous les artefacts tiers soient signés.
Gérer une liste organisée de certificats ou de clés publiques d'éditeur.
Laisser le pipeline de déploiement vérifier la signature des artefacts tiers par rapport à la liste des éditeurs de confiance.

Vous pouvez également vérifier les hachages d'artefacts. Vous pouvez utiliser cette approche pour les artefacts qui ne sont pas compatibles avec la signature de code et qui changent rarement.

Veiller à ce que l'infrastructure sous-jacente réponde à vos exigences d'intégrité

Au lieu de compromettre le pipeline de déploiement lui-même, les acteurs malintentionnés peuvent tenter de compromettre son infrastructure, par exemple :

Le logiciel CI/CD qui exécute le pipeline de déploiement.
Les outils utilisés par le pipeline (par exemple, Terraform, kubectl ou Docker).
Le système d'exploitation et tous ses composants.

Étant donné que l'infrastructure sous-jacente aux pipelines de déploiement est souvent complexe et peut contenir des composants provenant de divers fournisseurs ou sources, ce type de violation de sécurité peut être difficile à détecter.

Vous pouvez réduire le risque que votre infrastructure soit compromise en procédant comme suit :

Appliquer à l'infrastructure et à tous ses composants les mêmes normes d'intégrité qu'au pipeline de déploiement et aux ressources Google Cloud qu'il gère
Vérifier que les outils proviennent d'une source fiable et vérifier leur authenticité.
Recréer régulièrement l'infrastructure à partir de zéro.
Exécuter le pipeline de déploiement sur des VM protégées.

Appliquer des contrôles d'intégrité dans le pipeline

Bien que les acteurs malveillants soient une menace, ils ne constituent pas la seule source possible de modifications logicielles ou de configuration pouvant nuire à l'intégrité de votre environnement Google Cloud. Ces modifications peuvent également provenir de développeurs et être tout simplement accidentelles, en raison d'un manque de connaissances, de fautes de frappe et d'autres erreurs.

Vous pouvez réduire le risque d'application accidentelle de modifications risquées en configurant les pipelines de déploiement pour appliquer des contrôles d'intégrité supplémentaires. Ces contrôles peuvent inclure les éléments suivants :

Effectuer une analyse statique du code et de la configuration.
Exiger que chaque modification respecte un ensemble de règles (règle en tant que code).
Limiter le nombre de modifications pouvant être effectuées simultanément.

Étapes suivantes

Découvrez nos bonnes pratiques pour utiliser des comptes de service dans les pipelines de déploiement.
Consultez nos bonnes pratiques pour sécuriser les comptes de service.
Découvrez comment examiner et contrer les menaces.
Pour découvrir d'autres architectures de référence, schémas et bonnes pratiques, consultez le Centre d'architecture cloud.