La sécurité dans le Cloud: les bonnes pratiques

Quelques mots pour commencer

#

Le Cloud…

Cela fait un moment que je vous en parle, que ce soit à travers la CI/CD, l’infrastructure as code, les conteneurs et autres…

En tant que consultant, il est de mon devoir de faire en sorte que les différents clients que j’accompagne dans leur transition vers le Cloud soient les plus sensibilisés sur différents sujets, les deux qui reviennent le plus souvent aujourd’hui sont le FinOps et la sécurité.

Cette dernière bien que souvent prise en compte au démarrage d’une migration ou d’une transition vers le Cloud, n’est pas forcément présente sur toutes les couches de ce qui sera, plus tard, déployé.

De manière récurrente, la sécurité est vue comme un ensemble de configurations à déployer ou d’outils à installer dans l’objectif d’arriver jusqu’à l’audit final et de le réussir.

Évidemment la partie outillage est essentielle mais ce n’est pas la seule partie !

Comme le dit Bruce Schneier qui est un expert renommé en sécurité informatique :

Security is a process, not a product

Autrement dit, la sécurité doit être vue comme un état d’esprit à adopter dès le démarrage, quelle que soit l’équipe dans laquelle vous vous trouvez, vous êtes responsables des ressources déployées et des configurations que vous réalisez. Cette démarche se veut itérative, il faut donc partir avec le minimum indispensable et ajouter certains concepts au fur et à mesure.

C’est aussi une approche, appelée DevSecOps qui vise à promouvoir la sécurité du développement de l’application à la mise en place de l’infrastructure sous-jacente.

À travers cet article, il était important pour moi de vous partager les différents points que je recommande avant ou pendant une phase de transition vers le Cloud. Pour cela, j’ai sélectionné les trois plus grands fournisseurs de Cloud du moment, j’ai nommé : AWS, Azure et Google Cloud.

Ces conseils ne sont bien sûr pas exhaustifs, mais peuvent vous donner un avant-goût des bonnes pratiques à mettre en place en fonction des domaines cités.

Ce qu’évoque le mot sécurité…

#

Il est évident que la sécurité est un vaste concept que l’on peut traiter à différents niveaux de l’infrastructure. Néanmoins, certaines notions reviennent assez souvent :

Réduire la surface d’attaque

#

Ce point consiste à minimiser les points d’entrée potentiels pour les attaquants qui souhaiteraient mettre à mal votre infrastructure. Cela implique :

• Ouvrir uniquement les ports nécessaires ;
• Limiter les accès publics des services, notamment ceux de type Platform as a Service (PaaS) qui contiennent ce genre d’option par défaut ;
• Mettre en place une politique de durcissement des machines virtuelles, conteneurs, voire binaires ;
• Appliquer le principe du moindre privilège pour les permissions des utilisateurs ou comptes de service.

Se protéger contre les vulnérabilités

#

Quand on parle de protections contre les vulnérabilités, cela laisse sous-entendre :

• Maintenir à jour l’ensemble des composants ;
• Disposer d’outils permettant de remonter les vulnérabilités au plus tôt dans la phase de développement en les testant, c’est ce que met en évidence l’approche Shift Left ;
• Garder un œil, même une fois vos applications déployées, grâce à des outils de scan journalier ;
• Intégrer la sécurité comme un élément essentiel avant de démarrer un projet en adoptant la démarche DevSecOps ;
• Se tenir informé sur les dernières menaces et patchs de vulnérabilités critiques.

Empêcher la fuite de données

#

Pour cela plusieurs points sont à définir, notamment en fonction de la criticité du ou des cas d’utilisation :

• Utiliser le chiffrement au repos, en transit et même à l’exécution ;
• Gérer ses clés de chiffrement et informations sensibles (secrets) ;
• Appliquer des contrôles d’accès stricts ;
• Anonymiser les données et les informations sensibles ;
• Classifier les données pour les appliquer des politiques de sécurité appropriées.

Partitionnement, filtrage et traçage des flux

#

Lors de la phase d’architecture, la segmentation du réseau et la surveillance des flux sont essentiels pour détecter et prévenir les activités malveillantes :

• Définir les réseaux et sous-réseaux ;
• Utiliser des équipements réseaux permettant de filtrer les accès en sortie comme les systèmes de détection d’intrusion IDS/IPS, mais aussi en entrée avec pourquoi pas des Web Application Firewall (WAF) ;
• Implémenter une journalisation et une analyse des logs sur vos composants réseaux (Flow Logs, Firewall Logs, etc.).

Comme dit plus haut, cette liste ne représente que quelques points essentiels quand on parle du concept de sécurité. Cependant, il est évident que rien qu’avec ces quatre premiers points, il y a beaucoup de chose à construire notamment lors du démarrage d’un projet Cloud ou d’une migration.

Les bonnes pratiques à adopter au démarrage

#

Dans cette section, je souhaitais vous présenter quelques points fondamentaux sur lesquels il est grandement conseillé de réfléchir avant même de déployer votre premier service Cloud.

Choisir sa convention de nommage

#

Bien que sans rapport direct avec la sécurité, une convention de nommage propre vous permettra d’identifier rapidement vos ressources Cloud et vous donner une visibilité accrue lors de l’analyse de logs et métriques afin de détecter les comportements anormaux.

Pour cela, je vous conseille de vous référer aux directives de chaque fournisseur Cloud dans un premier temps. Par exemple, au sein de son Cloud Adoption Framework, Azure vous donne une démarche claire si vous manquez d’idée.

Une bonne convention de nommage à adopter doit contenir à minima :

• Des informations essentielles sur la ressource en question :
  • Le type de ressource ;
  • Le nom de l’application ;
  • L’environnement (dev, test, prod, etc.) ;
  • La région ;
  • Un incrément si plusieurs ressources sont présentes avec le même nom (optionnel) ;
• La mise en place d’abréviations compréhensibles pour réduire la taille du nom, il est assez commun de réduire le type de ressource ou le nom de la région. Par exemple: switzerland-north deviendra chn (Azure) ou europe-west6 deviendra ew6 (Google Cloud) ;
• L’utilisation de tiret (-) pour séparer les différentes informations quand cela est possible.

À vous, bien évidemment, d’ajouter vos propres caractéristiques en fonction de vos besoins.

Par exemple sur Azure, il peut-être intéressant d’adopter ce format :

Au sein de cet exemple, le type de la ressource correspond à une public ip pour l’application du Silicon Chalet, ce dernier est un projet de production localisé dans la région Switzerland North. Enfin, l’incrément indique que c’est la première ressource possédant ce format.

Définir ses tags ou labels

#

Les tags (AWS et Azure) ou labels (Google Cloud) peuvent vous aider à identifier vos ressources avec un ensemble d’attributs clé/valeur.

La gestion de ces derniers peut également vous aider, dans une démarche FinOps, dans l’objectif d’augmenter la visibilité sur l’aspect facturation jusqu’à la mise en place d’alertes sur la surveillance des comportements anormaux.

En effet, il est intéressant de suivre ces données et comprendre les baisses ou hausses de consommation de ressources en fonction des types d’environnement.

Par exemple, une hausse de la consommation excessive pourrait signifier qu’une personne non autorisée à potentiellement accès à vos environnements. Tout comme une baisse de la consommation donnerait comme indication qu’une personne de l’équipe a peut-être supprimé des ressources essentielles au bon fonctionnement d’une application.

Vous l’aurez compris, la dimension financière permet de détecter les gaspillages, améliorer la visibilité mais peut participer également à la sécurité globale de vos environnements.

En plus de cette dimension, les tags et labels sont des atouts majeurs pour l’observabilité de votre plateforme et la gestion de votre infrastructure, tout comme vos applications.

De manière classique, trois tags ou labels sont fortement recommandés :

• environment : type d’environnement
• application : nom de l’application
• owner ou team : responsable de la ressource

Bien évidemment, il est important de respecter cette convention à travers l’ensemble de vos ressources et donc d’automatiser le plus possible ce processus pour conserver une homogénéité.

Dans le cas d’AWS, voici un exemple de tags :

En complément de ce qui est mis plus haut, le Name est essentiel sur AWS pour le nom de la ressource, le CostCenter peut vous donner une indication sur la partie facturation. Il peut aussi être intéressant d’ajouter d’autres tags notamment pour indiquer celui qui a créé la ressource, la date de création de cette dernière, la confidentialité des données associées, etc.

Petit point intéressant, dans cet exemple, le tag AutoShutdown peut être lié à l’exécution d’une lambda pour éteindre vos instances EC2 en fonction d’une expression CRON.

Gérer les utilisateurs et permissions

#

Cette partie est souvent sous-estimée par la plupart des utilisateurs, mais elle est cruciale dans une démarche de mise en place d’une stratégie de sécurité. Notamment en utilisant le principe du moindre privilège qui demande d’appliquer uniquement les permissions nécessaires aux plus proches des ressources dont à besoin l’utilisateur.

Quelques bonnes pratiques viennent compléter ce point :

• Utiliser des groupes plutôt que de définir des rôles au niveau utilisateur pour une meilleure maintenabilité ;
• Lier des rôles prédéfinis avec un périmètre restreint en fonction des besoins des utilisateurs. En effet, l’utilisation de rôles personnalisés ne doit être considérée qu’en dernier recours car vous allez devoir gérer la maintenance de ces derniers ;
• Faire des revues régulières de permissions accordées et utiliser des services pour l’élévation de privilèges temporaires si besoin d’intervenir très rapidement sur ue ressource :
  • Privileged Identity Management (PIM) pour Azure ;
  • TEAM with IAM Identity Center pour AWS ;
  • Privileged Access Manager (PAM) pour Google Cloud.
• Mettre en place les mécanismes appropriés pour donner des permissions entre services et éviter de stocker des identités en dur :
  • Managed Identity pour Azure ;
  • IAM Roles pour AWS ;
  • Service account pour Google Cloud.

Le dernier point est illustré dans cet exemple :

Un compte de service a été créé puis attaché à la machine virtuelle pour qu’elle soit capable via le rôle roles/storage.objectViewer de récupérer un ou plusieurs éléments dans le bucket Google Cloud Storage sans monter au sein de la machine des informations sensibles comme des informations d’identification au format JSON.

Séparer les projets les uns des autres

#

Dans l’objectif d’isoler vos ressources, il est important de définir une organisation, la fameuse partie qui sert de socle pour la partie Landing Zone.

Ces fondations doivent avoir deux avantages : évolutive et modulaire. Notamment parce que c’est à cet endroit que vous pourrez définir vos permissions IAM, stratégies (ce point sera évoqué plus tard), budgets (pour surveiller vos coûts), quotas (pour définir des limites de création de ressources), etc. au plus proche de vos besoins.

Il est aussi important de considérer d’isoler vos environnements de production de ceux de hors production. Tout comme avoir un nœud de l’organisation dédié pour vos services partagés par exemple pour le réseau, ou votre plateforme d’observabilité.

Voici un exemple d’organisation Azure qui fait partie du Cloud Adoption Framework recommandé par Microsoft. Celle-ci se compose de différents Management Groups et Subscriptions pour répartir les ressources.

Cela permet de garantir une certaine évolutivité tout en séparant les responsabilités de chaque ressource.

Désactiver des services ou fonctionnalités

#

Autre caractéristique très importante, après avoir défini son organisation, le fait d’activer des stratégies de sécurité. En effet, il peut s’avérer utile de verrouiller certains comportements à travers les différents nœuds de la hiérarchie établie.

Cela se matérialise sous différents formats selon le fournisseur Cloud :

• AWS : Service Control Policies (SCPs)
• Azure : Azure Policy
• Google Cloud : Organization Policy

L’idée étant de faire respecter les standards en matière de sécurité et conformité ainsi que de limiter la surface d’attaque dans le cas où un attaquant aurait un pied dans votre organisation.

Un point important est le mécanisme d’héritage qui est implémenté par défaut, ainsi que la logique de restriction dans les nœuds enfants, comme dans cet exemple sur AWS :

Au sein de l’Organizational Unit Production, une SCP vient d’appliquer un Deny par rapport à un nœud supérieur, ce qui fait que l’Account X est donc privé de la fonctionnalité.

Voici quelques exemples de stratégies avec différents comportements :

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:DeleteFlowLogs",
        "logs:DeleteLogGroup",
        "logs:DeleteLogStream"
      ],
      "Resource": "*"
    }
  ]
}

Sur AWS, cette SCP empêche les utilisateurs de supprimer les VPC Flow Logs.

{
  "properties": {
    "displayName": "Disable public network access for Azure Key Vault",
    "policyType": "BuiltIn",
    [...]
    "version": "1.1.0",
    "parameters": {
      "effect": {
        "type": "String",
        "metadata": {
          "displayName": "Effect",
          "description": "Enable or disable the execution of the policy"
        },
        "allowedValues": [
          "Audit",
          "Deny",
          "Disabled"
        ],
        "defaultValue": "Audit"
      }
    },
    "policyRule": {
      "if": {
        "allOf": [
          {
            "field": "type",
            "equals": "Microsoft.KeyVault/vaults"
          },
          {
            "not": {
              "field": "Microsoft.KeyVault/vaults/createMode",
              "equals": "recover"
            }
          }
          [...]
        ]
      },
      "then": {
        "effect": "[parameters('effect')]"
      }
    }
  },
  "id": "/providers/Microsoft.Authorization/policyDefinitions/405c5871-3e91-4644-8a63-58e19d68ff5b/versions/1.1.0",
  "type": "Microsoft.Authorization/policyDefinitions/versions",
  "name": "1.1.0"
}

Sur Azure, cette Policy ne permet pas de déployer un Key Vault avec un accès public.

name: organizations/01234567890/policies/gcp.resourceLocations
spec:
  rules:
  - values:
      allowedValues:
      - in:europe-locations

Sur Google Cloud, cette Organization Policy restreint le nombre de régions sur lesquelles on peut déployer en prenant en compte uniquement les régions européennes.

Ces stratégies doivent continuellement être testées et ces tests doivent être réalisés sur des nœuds différents de là où sont vos applications de production. Il est souvent conseillé d’avoir une organisation dédiée pour tester cette partie ou de dupliquer vos nœuds.

Chiffrement et protection des données

#

Il est temps de parler des données et des différentes fonctionnalités permettant de protéger les parties sensibles de votre infrastructure :

• Activer le chiffrement au repos, en transit mais aussi à l’exécution si nécessaire à l’image du Confidential Computing chez Google Cloud ;
• Stocker vos informations sensibles dans les services dédiés comme AWS Secrets Manager, Azure Key Vault ou Google Cloud Secret Manager ;
• Utiliser vos propres clés de chiffrement notamment si vous avez des contraintes légales ou des données dont la criticité vous oblige à utiliser ce mécanisme ;
• Ne pas oublier de faire une rotation des clés de chiffrement et de vos secrets en fonction d’un rythme défini. Sans oublier de paramétrer vos applications pour prendre en compte ces nouveaux secrets !

Observabilité

#

Vous ne pouvez pas comprendre ce que vous ne voyez pas ! L’observabilité est donc la clé !

L’idée étant de pouvoir suivre l’ensemble des actions que vous allez réaliser dans le Cloud :

• Activer la journalisation complète des actions (CloudTrail pour AWS, Azure Monitor, Cloud Audit Logs pour Google Cloud) ;
• Utiliser les outils intégrés pour faire de la remontée d’alertes ou centraliser les logs dans un SIEM (Security Information and Event Management) ;
• Déployer des agents de monitoring et de logs sur l’ensemble de vos services ;
• Concevoir des tableaux de bord pour surveiller votre infrastructure jusqu’à vos applications ;
• Mettre en place des services de remédiation pour contourner les menaces aussi bien extérieures que des répercussions liées à une mauvaise configuration.

Cette partie remédiation peut être notamment effectuée par AWS Config qui peut venir supprimer une règle SSH d’un Security Group si cette dernière ne respecte pas les contraintes de sécurité élaborées par l’entreprise :

Architecture réseau

#

Une étape importante d’un projet Cloud est la définition d’une architecture réseau qui sera capable de répondre à vos besoins, que ce soit en matière de maintenance ou d’évolutivité. Je vous propose de faire le tour des différentes architectures les plus utilisées chez les trois fournisseurs de Cloud principaux.

Chez AWS

#

Depuis quelque temps déjà, AWS propose la Transit Gateway comme le composant central pour faire communiquer vos VPC entre eux en enlevant les limitations du peering, ce service a aussi la capacité d’être une sorte de routeur associant vos connexions avec Direct Connect ou VPN via l’on-prem ou d’autres réseaux.

Son avantage est la possibilité de configurer des routes et de mettre en place au besoin un VPC pour gérer l’inspection du trafic qui peut est administrée par le Network Firewall.

Pour ajouter une couche de sécurisation entre les VPC, il est intéressant de configurer les Network ACLs au niveau des sous-réseaux mais aussi les Security Groups pour les services qui les supportent.

À noter que dans AWS, vous avez la possibilité d’avoir des sous-réseaux privés ou publics en fonction de votre besoin.

Pour augmenter la visibilité des flux et du trafic, l’action des VPC FLow Logs est indispensable.

Chez Azure

#

Dans le même état d’esprit que AWS, Azure propose le Virtual WAN notamment pour interconnecter vos Virtual Networks entre eux, surtout dans le cas d’une volonté de faire du multi-région. Il est aussi possible de lier des connexions VPN ou Express Route pour ajouter une dimension hybride.

L’Azure Firewall aura la responsabilité de filtrer les flux en entrée mais aussi en sortie. Vous aurez la possibilité d’écrire trois types de règle des couches 3 à 7 du modèle OSI (règles réseaux jusqu’au filtrage avec des noms de domaine). La version Premium permet aussi d’ajouter l’inspection TLS ainsi que la détection et de prévention d’intrusion (IDPS).

Dans ce type d’architecture, les tables de routage sont des éléments essentiels notamment pour rediriger l’ensemble du trafic vers le Firewall.

La partie Network Watcher vous offrira la visibilité dont vous avez besoin pour votre trafic mais aussi pour diagnostiquer les problèmes de configuration.

Enfin, les Network Security Groups (NSG) agiront comme des pare-feux aussi bien à la maille des sous-réseaux que au niveau des interfaces réseau de vos services.

Chez Google Cloud

#

On termine avec Google Cloud dans une configuration différente. Le Shared VPC associé ou non à un Hub dans le cas d’une architecture Hub & Spoke permettra de déléguer un ou plusieurs sous-réseaux à une équipe au sein de son propre projet Google Cloud. Cela permet notamment d’avoir une équipe dédiée qui s’occupe de la partie réseau et sécurité du réseau hôte (configuration des règles de pare-feu, routage, etc.) et de donner l’autonomie nécessaire aux équipes souhaitant déployer des ressources à l’intérieur.

Dans le cas où vous souhaitez filtrer le trafic sortant en HTTP/S, le service Secure Web Proxy sera d’une grande utilité.

Service très spécifique sur Google Cloud mais d’une grande complexité, le VPC Service Controls permet de restreindre les communications entre des périmètres définis, comme une sorte de pare-feu d’API.

Le VPC Flow Logs donnera toute la capacité d’observation du trafic que ce soit depuis une machine virtuelle Compute Engine à un cluster Google Kubernetes Engine (GKE).

Pour finir, la segmentation à l’intérieur de vos VPC mais aussi entre VPC pourra être réalisée avec les Firewall Rules notamment en utilisant les Firewall Policies si besoin d’appliquer ça au niveau de l’organisation.

Exposition Internet

#

Un point qui revient assez souvent quand on parle architecture est la manière dont on expose ses services à travers internet. Un des enjeux est de conserver une connectivité privée entre l’ensemble des services et de n’exposer que le nécessaire tout en ajoutant une couche de sécurité.

Dans cet exemple sur Azure, Front Door est la porte d’entrée de l’infrastructure. Celui-ci agit comme un Content Delivery Network (CDN) et un passe-plat dans le cas d’une architecture multi-région. Ce dernier peut être complété par un Web Application Firewall (WAF) pour se protéger des menaces courantes.

L’Application Gateway fonctionne comme un équilibreur de charge de la couche 7 du modèle OSI permettant d’exposer sur internet et en interne les applications. Il est aussi primordial de sécuriser les connexions entre Front Door et l’Application Gateway pour éviter que vos utilisateurs atteignent vos services sans passer par Front Door. Pour cela, vous pouvez ajouter une règle WAF qui regardera que la requête a bien été transférée en utilisant l’identifiant de votre Front Door.

Dans le cas d’un Firewall Premium, il sera possible d’inspecter le trafic et de se protéger des menaces.

Autre fonctionnalité très importante, les Private Endpoints permettront de consommer les services par défaut public en mode privé uniquement. Ce qui évite d’exposer inutilement des services sur internet et de conserver les capacités de visualisation du trafic offerte par l’utilisation de Network Watcher.

Comment mettre en place tout ça ?

#

Une chose est sûre, les concepts sont bien définis et il est maintenant temps de les configurer et déployer. Forcément l’Infrastructure as Code (IaC) rentre en jeu !

Peu importe l’outil utilisé, de Terraform à Crossplane en passant par OpenTofu et Pulumi, l’IaC possède plusieurs avantages :

• Auditabilité : Suivi simplifié des changements et des modifications grâce au contrôle de version (Git) ;
• Minimisation des erreurs : Réduction des erreurs humaines dues aux actions manuelles ;
• Cohérence : Déploiement uniforme d’un environnement à l’autre ;
• Conformité : Application des meilleures pratiques de sécurité comme le principe du moindre privilège et le chiffrement à travers toute l’infrastructure ;
• Analyse de sécurité : Détection des vulnérabilités au sein des scripts d’infrastructure as code, telles que les créations d’IP publiques ou les configurations non sécurisées.

Ces outils sont donc les candidats idéaux pour déployer votre infrastructure.

Pour compléter le tout, une chaîne automatisée CI/CD aura l’avantage de tester de façon récurrente aussi bien les bonnes pratiques du langage que l’indentation, sans oublier les outils de sécurité que l’on peut associer comme TerraScan, checkov ou encore Trivy (anciennement Tfsec).

En complément de l’aspect sécurité, il est recommandé de faire des tests unitaires et de non-régression avec un outil comme Terratest.

Pour terminer sur ce sujet, une bonne pratique surtout quand on automatise au maximum son infrastructure, est d’empêcher les actions manuelles en laissant uniquement des droits de lecture aux utilisateurs de la plateforme. Seule la chaîne automatisée a le droit de créer, mettre à jour ou supprimer des ressources.

Bien sûr, il sera toujours possible d’intervenir avec des privilèges temporaires comme évoqué plus haut lors d’un plantage ou d’une erreur d’exécution.

Cela a pour but d’éviter les dérives entre votre code et l’infrastructure réelle sans l’objectif de faire en sorte que ce qu’il y a dans votre code est l’infrastructure réellement déployée (approche GitOps). De plus, cette façon de faire permet de promouvoir les revues de code entre collègues avant déploiement.

Déploiement des applications

#

Assez parlé de l’infrastructure et de son déploiement, il est maintenant l’heure de discuter des différentes méthodes de déploiement et des services associés.

Dans le Cloud, il est possible de déployer différents formats :

• Code source : pour être déployé dans des services de type Functions (Serverless) ;
• Binaire : très utilisé pour un déploiement sur une machine virtuelle ou de nombreux services de type PaaS comme App Engine ;
• Conteneur : l’unité la plus portable, convient à une très grande majorité de service Cloud de la machine virtuelle au cluster Kubernetes.

Vous l’aurez compris, quel que soit votre format, vous aurez le choix entre une vaste majorité de services. Ces derniers doivent être déterminés en fonction de vos connaissances, les capacités de l’équipe pour l’opérer au quotidien mais aussi vos restrictions en matière de sécurité.

Si vos politiques de sécurité exigent un durcissement de la couche du système d’exploitation alors la machine virtuelle est peut-être plus appropriée pour votre cas d’utilisation.

Cela reprend les rôles de chacun avec le modèle de responsabilité partagé entre le fournisseur de Cloud et vous. Plus vous choisirez un produit de type Infrastructure as a Service (IaS), plus vous aurez à sécuriser l’ensemble des couches du système d’exploitation aux données de votre application.

En parlant de durcissement, il peut être utile d’aller la mise en place d’une usine à image sous forme de chaîne automatisée pour construire ces dernières en fonction de vos besoins.

L’idée derrière ce concept est d’utiliser les images publiques fournies par les fournisseurs Cloud et de créer par itération, avec des outils comme Packer et Ansible, une image durcie correspondant aux politiques de sécurité de l’entreprise comme l’application du CIS Benchmark sans oublier la couche d’observabilité correspondante. Cette première image aura pour objectif de servir comme image de base pour ensuite injecter ce que l’on souhaite déployer avec.

Sur l’exemple ci-dessus, deux images sont générées à travers cette image durcie : une pour servir de worker au sein d’un cluster Kubernetes et une autre pour déployer GitLab.

Dans l’objectif d’avoir un patching régulier, il serait intéressant de recréer ces images à une fréquence définie (par exemple: tous les mois).

Ce concept permet d’obtenir une véritable bibliothèque où les équipes IT utilisent ces images comme source au lieu de prendre celle par défaut.

Dans le cas des conteneurs, l’objectif est le même.

À partir d’un ou plusieurs fichiers Dockerfile, une chaîne d’intégration continue enchaînera les actions suivantes :

• Vérification syntaxique : analyse des bonnes pratiques d’optimisation des couches de l’image ;
• Phase de build : utilisation de Kaniko à la place du Docker in Docker pour éviter les élévations de privilèges et problématiques de sécurité ;
• Analyse de sécurité : Trivy effectue un scan de vulnérabilité au sein de l’image ;
• Signature de l’image : CoSign permet de s’assurer que lors d’un futur déploiement, l’image déployée est bien l’image signée par cet outil ;
• Déplacement dans un registre : la dernière étape consiste à pousser l’image dans un registre de conteneur pour la mettre à disposition des équipes.

Sans rentrer dans plus de détail, ce serait à peu près la même chose avec la création d’un binaire.

L’objectif étant à chaque fois d’adopter l’approche Shift Left et de se prémunir de ce que l’on appelle la Supply chain attack en vérifiant les dépendances et librairies que vous utilisez au sein d’applications ou infrastructures.

Dernier point que je souhaitais évoquer : les clusters Kubernetes. En effet, Kubernetes est un écosystème captivant, il n’en reste pas moins que sa mise en place est un monde à part entière.

Plusieurs points doivent être mis en évidence :

• Utiliser des clusters privés dans l’objectif d’éviter de rendre les nœuds du cluster ou le point de terminaison accessibles ;
• Mettre en place un outil de Policy as Code comme Kyverno pour déployer des ClusterPolicy, par exemple, pour empêcher l’utilisation de l’utilisateur root ;

• Utiliser une couche réseau (CNI) permettant l’utilisation de NetworkPolicy ou CiliumNetworkPolicy pour filtrer les connexions réseaux et isoler les applications les unes des autres ;
• Automatiser la détection des vulnérabilités des conteneurs même durant leur exécution avec, par exemple, le Trivy Operator.

La dernière partie est essentielle, une image qui ne contient pas de vulnérabilités aujourd’hui ne veut pas dire qu’elle n’en contiendra pas dans le futur. Vous devez constamment veiller sur l’inventaire de vos images et définir des alertes en cas de failles critiques ou élevées.

Un mot pour conclure

#

Je souhaitais, à travers cette présentation et cet article, vous donner un état de l’art de l’application de la sécurité dans le Cloud même si plusieurs parties peuvent très bien s’appliquer dans un monde on-premise aussi. Comme vous avez pu le remarquer cette dernière s’applique à tous les niveaux, sans exception, du développement de votre application à la mise en place de votre infrastructure.

Trop souvent oubliée, trop souvent négligée, la sécurité est pourtant essentielle pour garantir la pérennité de ce que vous déployez et conserver la confiance auprès de vos clients. Pensez donc à son application au plus tôt pour faire éviter de faire croître votre dette technique.

Évidemment le risque zéro n’existant pas, cela vous force à rester en éveil sur les dernières actualités et pratiques à mettre en œuvre, même si c’est globalement du bon sens.

Gardez à l’esprit que cette démarche se met en place de manière itérative, le plus important étant de rendre visible vos actions et de rendre crédible vos futurs travaux.

Pour conclure, la sécurité est donc bien plus qu’un ensemble d’outils, c’est un véritable état d’esprit !