Chapitre 16. Chiffrement des disques en réseau (NBDE)
16.1. À propos de la technologie de cryptage des disques
Network-Bound Disk Encryption (NBDE) permet de chiffrer les volumes racines des disques durs des machines physiques et virtuelles sans avoir à saisir manuellement un mot de passe lors du redémarrage des machines.
16.1.1. Comparaison des technologies de cryptage des disques
Pour comprendre les avantages du chiffrement de disque lié au réseau (NBDE) pour la sécurisation des données au repos sur les serveurs périphériques, comparez le chiffrement de disque avec dépôt de clé et TPM sans Clevis au NBDE sur des systèmes fonctionnant sous Red Hat Enterprise Linux (RHEL).
Le tableau suivant présente quelques compromis à prendre en compte concernant le modèle de menace et la complexité de chaque solution de chiffrement.
| Scénario | Séquestre de clés | Chiffrement du disque par TPM (sans Clevis) | NBDE |
|---|---|---|---|
| Protection contre le vol d'un seul disque | X | X | X |
| Protection contre le vol d'un serveur entier | X | X | |
| Les systèmes peuvent redémarrer indépendamment du réseau | X | ||
| Pas de recomposition périodique de la clé | X | ||
| La clé n'est jamais transmise sur un réseau | X | X | |
| Supporté par OpenShift | X | X |
16.1.1.1. Séquestre de clés
Le dépôt de clés est le système traditionnel de stockage des clés cryptographiques. Le serveur de clés du réseau stocke la clé de chiffrement d'un nœud doté d'un disque de démarrage chiffré et la renvoie lorsqu'il est interrogé. Les complexités liées à la gestion des clés, au cryptage du transport et à l'authentification n'en font pas un choix raisonnable pour le cryptage du disque de démarrage.
Bien que disponible dans Red Hat Enterprise Linux (RHEL), la configuration et la gestion du chiffrement de disque basé sur un dépôt de clés est un processus manuel et non adapté aux opérations d'automatisation d'OpenShift Container Platform, y compris l'ajout automatisé de nœuds, et actuellement non pris en charge par OpenShift Container Platform.
16.1.1.2. Cryptage TPM
Le chiffrement des disques par le Trusted Platform Module (TPM) convient mieux aux centres de données ou aux installations dans des lieux protégés éloignés. Les utilitaires de chiffrement intégral des disques, tels que dm-crypt et BitLocker, chiffrent les disques à l'aide d'une clé de liaison TPM, puis stockent la clé de liaison TPM dans le TPM, qui est attaché à la carte mère du nœud. Le principal avantage de cette méthode est qu'il n'y a pas de dépendance externe et que le nœud est capable de décrypter ses propres disques au démarrage sans aucune interaction externe.
Le chiffrement du disque TPM protège contre le déchiffrement des données si le disque est volé au nœud et analysé à l'extérieur. Toutefois, pour les sites non sécurisés, cette protection peut s'avérer insuffisante. Par exemple, si un attaquant vole le nœud entier, il peut intercepter les données lors de la mise sous tension du nœud, car le nœud déchiffre ses propres disques. Cela s'applique aux nœuds dotés de puces TPM2 physiques ainsi qu'aux machines virtuelles dotées d'un accès Virtual Trusted Platform Module (VTPM).
16.1.1.3. Chiffrement des disques en réseau (NBDE)
Le chiffrement de disque lié au réseau (NBDE) lie effectivement la clé de chiffrement à un serveur externe ou à un ensemble de serveurs de manière sécurisée et anonyme à travers le réseau. Il ne s'agit pas d'un dépôt de clé, dans la mesure où les nœuds ne stockent pas la clé de chiffrement et ne la transfèrent pas sur le réseau, mais le comportement est similaire.
Clevis et Tang sont des composants client et serveur génériques qui fournissent un chiffrement lié au réseau. Red Hat Enterprise Linux CoreOS (RHCOS) utilise ces composants en conjonction avec Linux Unified Key Setup-on-disk-format (LUKS) pour chiffrer et déchiffrer les volumes de stockage racine et non racine afin de réaliser un chiffrement de disque lié au réseau.
Lorsqu'un nœud démarre, il tente de contacter un ensemble prédéfini de serveurs Tang en effectuant une poignée de main cryptographique. S'il parvient à atteindre le nombre requis de serveurs Tang, le nœud peut construire sa clé de déchiffrement de disque et déverrouiller les disques pour poursuivre le démarrage. Si le nœud ne peut pas accéder à un serveur Tang en raison d'une panne de réseau ou de l'indisponibilité du serveur, le nœud ne peut pas démarrer et continue à réessayer indéfiniment jusqu'à ce que les serveurs Tang redeviennent disponibles. La clé étant effectivement liée à la présence du nœud dans un réseau, un pirate tentant d'accéder aux données au repos devrait obtenir à la fois les disques du nœud et l'accès réseau au serveur Tang.
La figure suivante illustre le modèle de déploiement de l'EDNB.
La figure suivante illustre le comportement de l'EDNB lors d'un redémarrage.
16.1.1.4. Cryptage avec partage du secret
Le partage du secret de Shamir (sss) est un algorithme cryptographique qui permet de diviser, de distribuer et de réassembler les clés en toute sécurité. Grâce à cet algorithme, OpenShift Container Platform peut prendre en charge des combinaisons plus complexes de protection des clés.
Lorsque vous configurez un nœud de cluster pour utiliser plusieurs serveurs Tang, OpenShift Container Platform utilise sss pour configurer une politique de déchiffrement qui réussira si au moins un des serveurs spécifiés est disponible. Vous pouvez créer des couches de sécurité supplémentaires. Par exemple, vous pouvez définir une politique dans laquelle OpenShift Container Platform exige à la fois le TPM et l'un des serveurs Tang de la liste donnée pour déchiffrer le disque.
16.1.2. Cryptage des disques du serveur Tang
Les composants et technologies suivants mettent en œuvre le chiffrement des disques liés au réseau (NBDE).
Tang est un serveur permettant de lier les données à la présence du réseau. Il rend un nœud contenant des données disponible lorsque le nœud est lié à un certain réseau sécurisé. Tang est sans état et ne nécessite pas de Transport Layer Security (TLS) ni d'authentification. Contrairement aux solutions basées sur le dépôt fiduciaire, où le serveur de clés stocke toutes les clés de chiffrement et a connaissance de chaque clé de chiffrement, Tang n'interagit jamais avec les clés des nœuds et n'obtient donc jamais d'informations d'identification de la part du nœud.
Clevis est un cadre enfichable pour le déchiffrement automatisé qui permet de déverrouiller automatiquement les volumes LUKS (Linux Unified Key Setup-on-disk-format). Le paquet Clevis s'exécute sur le nœud et fournit le côté client de la fonctionnalité.
Le site Clevis pin est un module d'extension de la structure Clevis. Il existe trois types de broches :
- TPM2
- Lie le chiffrement du disque au TPM2.
- Tang
- Lier le chiffrement du disque à un serveur Tang pour activer l'EDNB.
- Partage du secret de Shamir (sss)
Il permet des combinaisons plus complexes d'autres épingles. Il permet des politiques plus nuancées telles que les suivantes :
- Il doit être possible d'accéder à l'un de ces trois serveurs Tang
- Doit pouvoir atteindre trois de ces cinq serveurs Tang
- Il doit être possible d'atteindre le TPM2 ET au moins l'un de ces trois serveurs Tang
16.1.3. Planification de l'emplacement du serveur Tang
Lorsque vous planifiez votre environnement de serveurs Tang, tenez compte de l'emplacement physique et de l'emplacement du réseau des serveurs Tang.
- Emplacement physique
L'emplacement géographique des serveurs Tang est relativement peu important, pour autant qu'ils soient convenablement protégés contre l'accès non autorisé ou le vol et qu'ils offrent la disponibilité et l'accessibilité nécessaires à l'exécution d'un service critique.
Les nœuds dotés de clients Clevis n'ont pas besoin de serveurs Tang locaux tant que ces derniers sont disponibles à tout moment. La reprise après sinistre nécessite une alimentation redondante et une connectivité réseau redondante pour les serveurs Tang, quel que soit leur emplacement.
- Localisation du réseau
Tout nœud ayant un accès réseau aux serveurs Tang peut décrypter ses propres partitions de disque ou tout autre disque crypté par les mêmes serveurs Tang.
Choisissez des emplacements réseau pour les serveurs Tang qui garantissent que la présence ou l'absence de connectivité réseau à partir d'un hôte donné permet l'autorisation de décryptage. Par exemple, des protections par pare-feu peuvent être mises en place pour interdire l'accès à partir de tout type de réseau invité ou public, ou de toute prise réseau située dans une zone non sécurisée du bâtiment.
En outre, il convient de maintenir une séparation entre les réseaux de production et de développement. Cela permet de définir les emplacements appropriés du réseau et d'ajouter une couche supplémentaire de sécurité.
Ne déployez pas les serveurs Tang sur la même ressource, par exemple le même cluster
rolebindings.rbac.authorization.k8s.io, qu'ils sont chargés de déverrouiller. Toutefois, une grappe de serveurs Tang et d'autres ressources de sécurité peut constituer une configuration utile pour permettre la prise en charge de plusieurs grappes et ressources de grappes supplémentaires.
16.1.4. Exigences en matière de dimensionnement du serveur Tang
Les exigences relatives à la disponibilité, au réseau et à l'emplacement physique déterminent le nombre de serveurs Tang à utiliser, plutôt que la capacité des serveurs.
Les serveurs Tang ne conservent pas l'état des données chiffrées à l'aide des ressources Tang. Les serveurs Tang sont soit totalement indépendants, soit ne partagent que leurs clés, ce qui leur permet de s'adapter facilement.
Les serveurs Tang traitent les documents clés de deux manières différentes :
Plusieurs serveurs Tang partagent les clés :
- Vous devez équilibrer la charge des serveurs Tang partageant des clés derrière la même URL. La configuration peut être aussi simple qu'un DNS round-robin, ou vous pouvez utiliser des équilibreurs de charge physiques.
- Vous pouvez passer d'un serveur Tang unique à plusieurs serveurs Tang. La mise à l'échelle des serveurs Tang ne nécessite pas de nouvelle clé ou de reconfiguration du client sur le nœud lorsque les serveurs Tang partagent le même matériel de clé et la même URL.
- La configuration des nœuds clients et la rotation des clés ne nécessitent qu'un seul serveur Tang.
Plusieurs serveurs Tang génèrent leurs propres clés :
- Vous pouvez configurer plusieurs serveurs Tang au moment de l'installation.
- Vous pouvez faire évoluer un serveur Tang individuel derrière un équilibreur de charge.
- Tous les serveurs Tang doivent être disponibles lors de l'installation des nœuds clients ou de la rotation des clés.
- Lorsqu'un nœud client démarre avec la configuration par défaut, le client Clevis contacte tous les serveurs Tang. Seuls les serveurs Tang n doivent être en ligne pour procéder au décryptage. La valeur par défaut de n est 1.
- Red Hat ne prend pas en charge la configuration post-installation qui modifie le comportement des serveurs Tang.
16.1.5. Considérations relatives à la journalisation
L'enregistrement centralisé du trafic Tang est avantageux car il peut vous permettre de détecter des éléments tels que des demandes de décryptage inattendues. Par exemple :
- Un nœud demandant le déchiffrement d'une phrase d'authentification qui ne correspond pas à sa séquence d'amorçage
- Un nœud demandant le déchiffrement en dehors d'une activité de maintenance connue, telle que le renouvellement des clés
