OpenStack : la check-list SecNumCloud de l’ANSSI

Glance, composant problématique pour construire des infrastructures OpenStack conformes à SecNumCloud ?

Prenez en tout cas garde, avertit l’ANSSI, aux risques résiduels qu’engendre l’absence de mécanismes de chiffrement et de cloisonnement physique des images que ce service stocke et met à disposition des VM.

Il existe, dans une certaine mesure, des palliatifs, explique l’agence. Par exemple, utiliser la capacité de chiffrement du service swift, en combinaison avec le mécanisme de contrôle d’accès oslo.policy commun aux services OpenStack.
Dans ce cas, les chiffrement étant interne au service swift, les données associées aux images circulent en clair entre swift et glance. Ainsi qu’entre glance et nova (service de chiffrement des volumes). On activera donc le chiffrement de tous ces échanges.

Chiffrer les données et les flux

Au-delà du chiffrement des données, construire une infra OpenStack compatible SecNumCloud implique aussi de chiffrer les flux. En premier lieu, on configurera du TLS à l’état de l’art pour les API de tous les services. On y ajoutera du mTLS pour les service de file d’attente de messagerie et de base de données.

L’ANSSI recommande aussi la mise en place de tunnels IPSec entre le cache de jetons du service keystone et les services OpenStack. Il s’agit là de parer à l’absence de support de TLS par la couche oslo.cache.

L’absence de mécanisme de chiffrement des images – y compris via nova – impose un chiffrement des flux entre les services par lesquels transite le contenu des images. Il faut, pour cela, mettre en œuvre TLS sur glance et le configurer afin qu’il s’appuie sur cinder pour le stockage.

Gérer secrets et dépendances de composants

SecNumCloud impose également des exigences en matière de gestion des secrets. Un rôle que remplit, sur OpenStack, le service barbican.
L’ANSSI invite à l’interfacer, via une bibliothèque PKCS#11, avec un HSM ayant fait l’objet d’une certification de sécurité. Elle conseille aussi de ne permettre l’accès à ce HSM que depuis les machines hébergeant barbican. Et de mettre en place des procédures pour automatiser le cycle de vie desdits secrets. OpenStack n’en implémentant pas, on s’appuiera sur des appels à ses API.

La protection des flux de données suppose aussi le cloisonnement des dépendances de composants. On est susceptible d’en retrouver essentiellement sur quatre volets :

– SGBD (souvent MariaDB ou MySQL ; PostgreSQL et MSSQL possibles)
– Cache (tout service conforme au protocole memcache)
– File d’attente (tous service utilisant le standard AMQP)
– Serveur web (Apache HTTPD, Nginx…)

On évitera de mutualiser aussi bien les services de base de données que les services de cache entre différents composants au sein d’un même serveur ou cluster de serveurs. On mettra par ailleurs en œuvre un réseau spécifique pour les services tiers. En première ligne, ceux qui utilisent des comptes applicatifs avec de forts privilèges. Les services utilisant le multicast pourront se voir attribuer plusieurs réseaux spécifiques.

Cloisonner les données d’authentification…

Autre surface, autre cloisonnement : les données d’authentification. Objectif : répondre à l’exigence SecNumCloud selon laquelle « les comptes d’administration sous la responsabilité du prestataire doivent être gérés à l’aide d’outils et d’annuaires distincts de ceux utilisés pour la gestion des comptes utilisateurs sous la responsabilité du commanditaire ».

Le schéma de déploiement le plus simple sur l’utilisation d’une base de données où on stocke les informations sur l’ensemble des utilisateurs de l’infra. Problème : même avec des instances de keystone séparées entre prestataire et commanditaire(s), la base de données reste commune. Solution : configurer keystone pour qu’il délègue l’authentification à un annuaire LDAP.

Pour un degré d’isolation supplémentaire, il est possible d’avoir un annuaire distinct pour la gestion des admins du presta. Cette séparation utilisera la fonction de déploiement en domaines d’OpenStack.

… et les interfaces d’administration

SecNumCloud exige aussi une séparation entre les interfaces d’admin du prestataire et celles des commanditaires.

Pour chaque service, OpenStack permet de définir trois points d’entrée distincts :

– Internal (permettant aux services de communiquer)
– Admin (pour les admins du prestataire)
– Public (pour les admins des commanditaires)

Par défaut, ces trois éléments pointent vers une URL unique. Un premier niveau de séparation consiste à mettr en place des ports TCP distincts pour admin et public. On peut même en envisager trois, mais certaines surcouches ne permettent pas d’attribuer des ports distincts à internal et admin (kolla-ansible, par exemple).

En complément, on placera les API public et admin sur des réseaux distincts.

Les points d’entrée étant accessibles via leur adresse DNS, on est obligé de rendre les API public directement accessibles aux commanditaires. Et donc, dans le cas où ces derniers accèdent à l’infra par un réseau ouvert, à y exposer directement les points d’entrée.
L’ANSSI suggère, en guise de solution, la mise en place d’un serveur mandataire inverse en amont.

Un filtrage applicatif pourra s’avérer un bon complément. En particulier du fait que certaines surcouches de déploiement associent les différents points d’entrée de chaque service à un processus unique. Ce qui expose au risque d’un attaque par déni de service.

SecNumCloud exige que les interfaces d’administration pour le commanditaire ne permettent aucune connexion avec les comptes d’administration qui sont sous la responsabilité du prestataire.
Or, par défaut, si un administrateur du prestataire a un jeton valide avec le rôle admin, il peut se connecter à l’API du commanditaire.

Pour empêcher cela, on peut mettre en place des clés distinctes pour les points d’entrée pulic et admin de l’API identité. Une solution validée expérimentalement, mais très compliquée à industrialiser, souligne l’ANSSI. Surtout si les API internal et admin sont communes.
On peut alors envisager un blocage au niveau du serveur proxy, à l’aide d’un cache de jetons. Dispositif qu’on complétera en assurant une corrélation entre les identités OpenStack et les jetons, afin de se protéger en cas de compromission du serveur – et d’introduction de jetons arbitraires.

Le MFA par les certificats X.509 ou la fédération d’identités

Keystone en tant que fournisseur d’identité ne prend pas en charge l’authentification multifacteur. On peut la déléguer à un fournisseur externe reposant sur SAML 2.0 ou sur OIDC.
Pour l’option SAML 2.0, keystone est compatible avec les profils WebSSO et ESP. Mais le premier n’est utilisable qu’avec l’UI horizon (pas avec le CLI). Quand au second, il ne supporte qu’un nombre réduit de fournisseurs.

Le MFA peut aussi s’appuyer sur le serveur proxy. Si la connexion entre celui-ci et le client OpenStack se fait avec une authentification mutuelle par certificats X.509, les données du certificat peuvent constituer un nouveau facteur d’authentification. À condition de contrôler la cohérence entre le champ DN (Distinguished Name) des certificats et l’identité utilisateur fournie à l’annuaire LDAP.

À partir de là, on peut modifier le mécanisme de mémorisation des jetons. Ce pour stocker non plus seulement leur empreinte, mais y associer les identifiants utilisateurs. Il devient alors possible de faire la vérification pour les deux types de requêtes.

Calcul, stockage, réseau : isoler les clients

Le prestataire doit mettre en œuvre des mesures de cloisonnement appropriées entre ses commandaitaires, selon le référentiel SecNumCloud. Sur OpenStack, cela passe par la mise en place de nœuds de calcul dédiés. Nova dispose d’un mécanisme de sélection basé sur des filtres. L’un d’entre eux force l’exécution des VM d’un projet sur un nœud spécifique (AggregateMultiTenancyIsolation, filter_tenant_id).

Par défaut, le mécanisme de placement des VM sélectionne le nœud le moins chargé. Forcer la création de ressources sur les nœuds dédiés au projet requiert donc de créer des modèles de VM avec les métadonnées qu’utilisent les filtres nova.

Pour la migration à chaud, on sera attentif à configurer nova et la couche libvirt afin qu’ils utilisent QEMU et non ssh. Par défaut, c’est avec cette dernière option que s’effectue la recopie mémoire. Dans les grandes lignes, une telle config peut permettre à qui a compromis le compte root d’un nœud de prendre le contrôle des autres. Passer par QEMU évite cet écueil – à condition qu’on y mettre en œuvre le chiffrement TLS.

Concernant le stockage, on configurera swift pour qu’il dispose de plusieurs rings. Et cinder pour qu’il associe un back-end à chacun. Tout en configuratn ses quotas pour restreindre l’accès des projets à ces back-end.
Sur la partie réseau, l’ANSSI propose de renforcer la segmentation logique native que le service neutron met en œuvre. Levier : l’encapsulation des flux dans des tunnels IPSec.

L’effacement cryptographique, une option

En matière d’effacement sécurisé, SecNumCloud impose un mécanisme de réécriture de motifs aléatoires sur les supports physiques utilisés pour le stockage.

Les services OpenStack ne disposent pas d’un tel mécanisme. Pour les volumes, on peut néanmoins envisager un effacement cryptographique, si nova s’appuie sur l’hyperviseur sous-jacent pour les opérations cryptographiques et sur barbican pour le stockage des clés. Pour les données se trouvant sur des supports amovibles, on pourra adopter une approche similaire… si elles sont chiffrées avec un secret associé au projet et stocké par barbican.

L’ANSSI recommande, en complément, une politique de renouvellement périodique des clés maîtres du HSM. Cela garantit l’effacement cryptographique des clés de projet.

Outre la question des images, OpenStack a ses limites en termes d’effacement sécurisé. Il n’a par exemple pas de fonction permettant l’effacement automatique d’un ensemble prédéfini de ressources virtualisées associées à un utilisateur lorsqu’on supprime son profil.

Illustration principale © Krischam – Fotolia