Conformité des conteneurs et de Kubernetes

Si vous utilisez des conteneurs, vous avez réfléchi aux risques de sécurité qui en découlent. Que vous ayez adopté une approche DevOps ou mis en place un pipeline CI/CD solide, votre objectif reste le même : protéger vos données sensibles.

Le contrôle d'accès basé sur les rôles est la méthode standard de gestion des autorisations pour les points de terminaison de l'API Kubernetes. Au niveau du cluster Kubernetes, la configuration de cette fonction permet de contrôler les sujets autorisés à exécuter telle ou telle action pour des types de ressources en particulier et dans des espaces de noms spécifiques. En revanche, elle n'impose aucune contrainte s'agissant de la configuration des rôles. C'est là que les cadres de conformité entrent en jeu.

article | what is kubernetes?

Dans de nombreux secteurs, le respect des exigences de conformité fait partie intégrante de l'activité des entreprises. Ces préoccupations pourraient faire obstacle à la création et à l'exécution des applications conteneurisées et cloud-native, mais, fort heureusement, l'évolution rapide des cadres de conformité et des technologies facilite la mise en conformité totale des environnements cloud-native. Voici les principaux cadres de conformité applicables aux applications conteneurisées :

• Benchmarks CIS pour Kubernetes et Docker
• NIST SP 800-190
• PCI
• HIPAA

L'objectif de la mise en conformité est de garantir que vos applications sont sûres. Cependant, protéger les applications ne suffit pas pour respecter les exigences de conformité. Il faut également apporter la preuve, à une tierce partie, que l'application est sécurisée en toutes circonstances et toujours conforme, ce qui nécessite un suivi et un système d'enregistrement des informations.

La mise en conformité demande beaucoup d'efforts, mais le coût financier du non-respect des normes peut peser encore plus lourd. En effet, le montant des amendes qu'engendrent ces violations atteint presque trois fois le budget moyen consacré à la mise en conformité avec les exigences.

Enfin, les normes peuvent aider les entreprises à définir des politiques de gouvernance en matière de sécurité. Même s'ils ne s'appliquent pas spécifiquement à l'entreprise, les cadres de conformité peuvent être envisagés comme un point de départ pour définir les politiques internes, ce qui évite de partir de zéro pour fixer les règles.

Les cadres

Benchmarks CIS : les benchmarks du CIS (Center for Internet Security) fournissent un ensemble de meilleures pratiques liées à Kubernetes et aux conteneurs, en particulier ceux exécutés dans Docker. Toutefois, ils n'ont pas de caractère contraignant pour les entreprises.

NIST 800-190 : le NIST (National Institute of Standards and Technology) publie de nombreux cadres de conformité pour la cybersécurité, dont celui-ci spécialement destiné à la sécurité des conteneurs. Toutes les agences gouvernementales fédérales américaines, ainsi que leurs sous-traitants, sont soumis au NIST 800-190.

PCI : le cadre de l'industrie des cartes de paiement (Payment Card Industry) est le fruit d'un partenariat entre cinq acteurs majeurs du secteur des cartes de crédit. Il s'applique aux entreprises qui stockent, traitent ou transmettent des informations de paiement.

HIPAA : cette loi exige des protections techniques pour la collecte, le traitement ou la transmission des données de santé personnelles protégées au format électronique.

La publication spéciale 800-190 du NIST (National Institute of Standards and Technology) explique quelques-uns des défis liés à la sécurisation des applications conteneurisées et définit les moyens d'action pour améliorer le profil de sécurité des applications.

NIST 800-190 s'adresse aux agences gouvernementales américaines et à leurs sous-traitants, mais n'importe quelle entreprise peut décider de s'y conformer pour renforcer la sécurité de ses applications et faciliter la mise en conformité avec d'autres cadres comme PCI et HIPAA.

Les risques

Le cadre NIST 800-190 met en évidence les principales sources de vulnérabilités pour la sécurité des applications conteneurisées, dont :

• les images compromises ;
• les images de conteneurs mal configurées ;
• les images de conteneurs non approuvées ;
• les secrets mal gérés ;
• les contrôles d'accès mal configurés ;
• les vulnérabilités du système d'exploitation ;
• les surfaces d'attaque trop étendues.

Le cadre NIST 800-190 insiste (à juste titre) sur la nécessité pour les entreprises de repenser l'approche de la sécurité qu'elles appliquaient jusqu'à présent pour les applications traditionnelles. En effet, les applications conteneurisées ne présentent pas les mêmes facteurs de risque que les machines virtuelles, ce qui suppose des pratiques de sécurité différentes.

Voici les obligations imposées par le NIST 800-190 :

• Utiliser des outils dédiés de gestion des vulnérabilités des images dans l'ensemble du cycle de vie des images, depuis la création jusqu'au déploiement et à l'exécution
• S'assurer que les images respectent les meilleures pratiques de configuration
• Protéger les secrets en les stockant en dehors de l'image, les gérer à l'aide de Kubernetes, limiter leur accès aux seuls conteneurs qui en ont besoin et les chiffrer au repos et en transit
• Utiliser une connexion sécurisée lors du transfert ou de l'extraction au niveau du registre
• S'assurer que le conteneur utilise toujours la dernière version de l'image
• Segmenter le trafic réseau, au moins pour isoler les charges de travail sensibles de celles qui ne le sont pas
• Utiliser Kubernetes pour ajouter des nœuds de façon sécurisée et conserver un inventaire des nœuds et de leur statut de connexion
• Contrôler le trafic sortant des conteneurs
• Veiller à la mise en conformité continue avec les normes de configuration liées à l'exécution des conteneurs, notamment les benchmarks CIS
• Utiliser des contrôles de sécurité pour détecter les menaces et les intrusions potentielles au niveau des conteneurs et de l'infrastructure
• Utiliser un système d'exploitation renforcé et spécifique des conteneurs qui présente une surface d'attaque aussi petite que possible
• Empêcher le piratage du système de fichiers hôte en n'accordant que les permissions requises pour l'usage prévu des conteneurs

Les conditions NIST 800-190 offrent un cadre utile pour l'amélioration de la stratégie de sécurité des entreprises, y compris pour celles qui n'y sont pas soumises. Elles permettent d'envisager la sécurité tout au long du cycle de vie (lors de la création, du déploiement et de l'exécution) et ainsi de répondre aux exigences de sécurité propres à chaque phase.

La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) a été développée en 2004 par Visa, MasterCard, American Express, Discover et JCB dans le but de normaliser la sécurité et la protection des données dans ce secteur. Elle a été mise à jour à de nombreuses reprises pour tenir compte de l'évolution des technologies. Cette norme s'applique à toutes les entités de l'environnement des données de titulaires de carte (CDE), lequel est constitué des individus, des processus et des technologies qui stockent, traitent ou transmettent les données de titulaires de carte. Le terme « technologies » couvre le matériel et les logiciels.

La mise en conformité avec les conditions PCI est une tâche complexe qui coûte en moyenne 5,5 millions de dollars aux entreprises chaque année. Cependant, les sanctions financières pour manquement à cette norme sont bien plus lourdes et avoisinent chaque année les 14,8 millions de dollars. Heureusement, avec les processus et les outils adaptés, la mise en conformité devient plus simple.

La norme PCI DSS comprend 12 conditions regroupées autour de six objectifs :

Création et gestion d'un réseau et d'un système sécurisés

1. Installer et gérer une configuration de pare-feu pour protéger les données des titulaires de carte
2. Ne pas utiliser les mots de passe système et autres paramètres de sécurité par défaut définis par le fournisseur

Protection des données de titulaires de carte

1. Protéger les données de titulaires de carte stockées
2. Chiffrer la transmission des données de titulaires de carte sur les réseaux publics ouverts

Gestion d'un programme de gestion des vulnérabilités

1. Protéger tous les systèmes contre les logiciels malveillants et les exploits, et mettre à jour régulièrement les logiciels antivirus
2. Développer et maintenir des systèmes et des applications sécurisés
3. Mise en œuvre de mesures de contrôle d'accès strictes

Restriction de l'accès aux données de titulaires de carte aux seuls individus qui doivent les connaître

1. Identifier et authentifier l'accès aux composants de système
2. Restreindre l'accès physique aux données de titulaires de carte

Surveillance et tests réguliers des réseaux

1. Suivre et surveiller tous les accès aux ressources réseau ainsi qu'aux données de titulaires de carte
2. Tester régulièrement les processus et les systèmes de sécurité

Gestion d'une politique de sécurité des informations

1. Gérer une politique de sécurité des informations pour l'ensemble du personnel

Les conditions de la norme PCI concernant les applications conteneurisées

Sous chacun des six objectifs ci-dessus, plusieurs conditions concernent directement les environnements de conteneurs et Kubernetes. Vérifiez que vos outils de sécurité permettent de remplir ces conditions :

1.1.2 Diagramme du réseau actuel qui identifie toutes les connexions entre l'environnement des données de titulaires de carte et les autres réseaux, y compris tout réseau sans fil

1.1.4 Conditions relatives au pare-feu au niveau de chaque connexion Internet et entre toute zone démilitarisée (DMZ) et la zone de réseau interne

1.2 Créer des configurations de pare-feu et de routeur qui limitent les connexions entre les réseaux non approuvés et tous les composants de système dans l'environnement des données de titulaires de carte

1.2.1 Restreindre le trafic entrant et sortant au trafic nécessaire à l'environnement des données de titulaires de carte et, particulièrement, refuser tout autre trafic

1.3.2 Limiter le trafic Internet entrant aux adresses IP dans la DMZ

1.3.4 Ne pas autoriser le trafic sortant non autorisé de l'environnement des données de titulaires de carte vers Internet

1.3.5 Les connexions « établies » sont les seules autorisées sur le réseau

2.1 Changer systématiquement les paramètres par défaut définis par le fournisseur ou désactiver les comptes par défaut inutiles avant d'installer un système sur le réseau

2.2 Élaborer des normes de configuration pour tous les composants de système. S'assurer que ces normes couvrent toutes les vulnérabilités de la sécurité et sont compatibles avec toutes les normes renforçant les systèmes en vigueur dans le secteur.

2.2.1 N'appliquer qu'une fonction principale par serveur afin d'éviter la coexistence, sur le même serveur, de fonctions exigeant des niveaux de sécurité différents (par exemple, les serveurs web, les serveurs de bases de données et les serveurs DNS doivent être déployés sur des serveurs distincts)

2.2.2 Activer uniquement les services, protocoles, démons, etc., nécessaires pour le fonctionnement du système

2.2.3 Implémenter les fonctions de sécurité supplémentaires pour tout service, protocole ou démon nécessaire et jugé comme non sécurisé

2.2.5 Supprimer toutes les fonctionnalités qui ne sont pas nécessaires, par exemple scripts, pilotes, fonctions, sous-systèmes, systèmes de fichiers et serveurs web superflus

2.3 Crypter tous les accès administratifs non console, à l'aide d'une cryptographie robuste

2.4 Maintenir un inventaire des composants de système qui se trouvent dans le champ d'application de la norme PCI DSS

3.6.2 Sécuriser la distribution des clés cryptographiques

6.1 Établir un processus pour identifier les vulnérabilités de la sécurité, en utilisant des sources externes de bonne réputation pour la sécurité des informations concernant la vulnérabilité et affecter un classement du risque (par exemple « élevé », « moyen » ou « faible ») aux vulnérabilités de sécurité nouvellement découvertes

6.2 S'assurer que tous les logiciels et les composants de système sont protégés de vulnérabilités connues en installant les correctifs de sécurité applicables fournis par le fournisseur Installer les correctifs de sécurité stratégiques dans le mois qui suit leur commercialisation

6.4.1 Séparer les environnements de test/développement des environnements de production et appliquer la séparation à l'aide de contrôles d'accès

6.4.2 Séparation des obligations entre les environnements de développement/test et de production

6.5.1 Attaques par injection, notamment les injections de commandes SQL. Envisager également les attaques par injection OS, LDAP et Xpath ainsi que les autres attaques par injection.

6.5.3 Stockage cryptographique non sécurisé

6.5.4 Communications non sécurisées

6.5.6 Toutes les vulnérabilités à « haut risque », identifiées dans le processus d'identification de vulnérabilité (selon la condition 6.1 de la norme PCI DSS)

10.2.5 Mettre en œuvre des vérifications à rebours automatisées pour tous les composants de système afin de reconstituer l'utilisation et les modifications des mécanismes d'identification et d'authentification, y compris, mais sans s'y limiter, la création de nouveaux comptes et l'élévation de privilèges, et toutes les modifications, additions ou suppressions aux comptes avec des privilèges racines ou administratifs

11.2.1 Effectuer des scans trimestriels de vulnérabilité interne. Résoudre les vulnérabilités et renouveler les scans pour vérifier que toutes les vulnérabilités à « risque élevé » sont résolues conformément à la classe de vulnérabilité de l'entité (selon la condition 6.1). Les analyses doivent être exécutées par un personnel qualifié.

11.5 Déployer des mécanismes de détection des modifications (par exemple, des outils de contrôle de l'intégrité des fichiers) pour alerter le personnel de toute modification non autorisée (y compris des changements, des ajouts et des suppressions) des fichiers critiques du système, des fichiers de configuration ou des fichiers de contenu et configurer le logiciel pour qu'il effectue des comparaisons de fichier critique au moins une fois par semaine

11.5.1 Mettre en œuvre un processus pour répondre à n'importe quelle alerte générée par la solution de détection de changement

La loi HIPAA (Health Insurance Portability and Accountability Act) de 1996 a établi un cadre de conformité qui protège la confidentialité des données de santé des patients. La règle de sécurité, ajoutée en 2003, régit plus spécifiquement les dossiers médicaux numériques. Toute entité qui traite des données de santé personnelles protégées au format électronique (ePHI) doit respecter les exigences de la loi HIPAA. C'est le cas notamment des applications qu'utilisent les professionnels de santé pour les soins aux patients, les communications ou la facturation.

La mise en conformité avec la loi HIPAA est rendue complexe essentiellement parce que le cadre de sécurité fournit des orientations très larges et n'explique pas précisément comment respecter ces dispositions dans les environnements de conteneurs et Kubernetes. En outre, la distinction entre des données de santé protégées et non protégées est souvent moins évidente qu'entre des informations de carte de crédit qui doivent être protégées ou non au regard de la norme PCI.

La loi HIPAA s'applique aux professionnels de santé ainsi qu'aux entreprises qui leur fournissent des services (de stockage ou de facturation, par exemple) dès lors que ces services nécessitent de traiter des données de santé personnelles au format électronique.

La loi HIPAA exige des protections administratives, physiques et techniques. Les protections techniques, qui concernent l'infrastructure informatique, sont les suivantes :

• Contrôle des accès
• Audit des contrôles
• Intégrité
• Authentification
• Sécurité des transmissions

La règle de sécurité de la loi HIPAA, qui ne s'applique pas spécifiquement aux applications conteneurisées, ne donne pas de directives détaillées concernant la sécurisation des ePHI. Le cadre NIST SP 800-190, avec ses consignes et meilleures pratiques en matière de sécurité des conteneurs, constitue souvent un bon point de départ pour la mise en conformité HIPAA. Contrairement à la loi HIPAA, il fournit en effet un cadre spécialement pensé pour les conteneurs. Il est donc plus facile de prouver sa conformité. La loi HIPAA impose cependant des contrôles supplémentaires concernant la séparation des données pour protéger les ePHI et les isoler des autres types de données.

Enfin, les entreprises sont tenues de conserver des sauvegardes des données, mais aussi des fichiers de configuration des applications afin d'apporter la preuve du respect constant de la loi si besoin.