L'ANSSI a publié guide est destiné aux équipes chargées de la mise en œuvre d’un IaaS reposant sur la plateforme cloud open source OpenStack répondant aux exigences de conformité du référentiel SecNumCloud 3.2. "Les éléments de configuration nécessaires à la mise en oeuvre de ces fonctionnalités pouvant varier selon la solution de déploiement retenue, le détail de la configuration des services ne sera pas présenté", prévient l'agence. A noter que ce guide porte sur les exigences relatives aux API d’administration, à l’authentification des administrateurs, au chiffrement des données et des flux, ainsi qu’au cloisonnement entre les commanditaires (aka clients).

Les recommandations émises par l'Anssi sont réparties en plusieurs catégories : cloisonnement des accès et des données d'authentification entre prestataires et clients, authentification multifacteurs, protection des flux et des données, protection des données des clients, et mise en oeuvre de la journalisation sur les services OpenStack.

Cloisonnement des accès et des données d'authentification entre prestataires et clients

L'objectif est de se protéger contre le vol des données d’authentification d’un administrateur du prestataire faisant suite à une compromission des API utilisées par les clients. Un tel vol pouvant conduire à une utilisation illégitime des interfaces dédiées aux administrateurs du prestataire. Pour contrer cela, il faudra se montrer particulièrement vigilant sur le service Keystone d'OpenStack en charge de la gestion des identités et des rôles. Il est recommandé de le configurer pour qu’il délègue l’authentification des utilisateurs à un annuaire LDAP géré par un serveur LDAP pour lequel les mécanismes de sécurité sont à l’état de l’art.

L'Anssi recommande également de décomposer le déploiement OpenStack en domaines. Le domaine racine Default utilisé par les administrateurs du prestataire sera alors configuré pour utiliser un annuaire LDAP dédié. Le ou les autres domaines seront configurés pour utiliser un ou plusieurs annuaires dédiés aux commanditaires. Parmi les autres préconisations : utiliser des ports TCP distincts pour les points d'entrée admin et public des services, placer les API public et admin sur des réseaux distincts, mettre en place un serveur mandataire inverse en amont des API à destination des commanditaires et un filtrage applicatif en amont. Sans oublier un mécanisme de de blocage des jetons admin pour les API à destination des clients et des jetons publics pour les prestataires.

Authentification multifacteur

Pour se protéger contre l’utilisation frauduleuse des données d’authentification d’un administrateur qui lui auraient été préalablement dérobées, l'agence privilégie le déploiement d'une authentification mutuelle basée sur des certificats X.509 entre le client OpenStack et le serveur mandataire inverse placé en amont des API public. Mais aussi d'un contrôle de cohérence entre le champ Distinguished Name des certificats X.509 reçus et l’identité utilisateur fournie à l’annuaire LDAP, et de mémoriser des paires constituées du champ Distinguished Name des certificats X.509 reçus et de l’empreinte des tokens retournés par l’API Keystone. Vérifier les associations de tokens envoyés par les clients OpenStack et des certificats X.509 utilisés est également poussé.

Protection des flux et des données

Contre le vol ou la modification du logiciel ou des données mises en oeuvre par les commanditaires dans leurs infrastructures virtualisées, l'Anssi a aussi ses recettes. A savoir : activer le chiffrement des volumes du service Nova (pilotage des hyperviseurs exécutant des VM), de Swift (service de stockage objet), des échanges entre les services Swift et Glance (service de stockage global et de mise à disposition d'images utilisées par les VM), et entre Glance et Nova. Sans oublier de protéger les clés de chiffrement par un mécanisme ad hoc. "Il est recommandé de configurer l’ensemble des API OpenStack pour qu’elles mettent en œuvre du chiffrement TLS à l’état de l’art", fait aussi savoir l'Anssi. "Il est recommandé de configurer le service de file d’attente de messages et le service de base de données pour qu’il mette en œuvre du chiffrement TLS avec authentification mutuelle". Implémenter des tunnels IPsec entre le cache de jetons et les services OpenStack, configurer le service Glance pour qu'il s'appuie sur le service Cinder (service de stockage bloc) et s'assurer de son chiffrement TLS aussi.

La gestion des secrets n'est pas laissée de côté, avec là encore plusieurs recommandations à suivre : configurer le service Barbican (gestionnaire des clés) pour qu’il utilise le module p11_crypto_plugin afin de s’interfacer avec un HSM via une librairie PKCS#11, se servir un HSM ayant fait l’objet d’une certification de sécurité, ainsi qu'un mécanisme de contrôle d’accès oslo.policy pour restreindre l’accès aux secrets conformément au principe de moindre privilège. "Il est recommandé de ne permettre l’accès aux interfaces du HSM qu’aux machines hébergeant le service Barbican et de mettre en place des procédures basées des appels aux API OpenStack afin d’automatiser le cycle de vie des secrets", avance également l'agence. Il est recommandé en outre de mettre à disposition des clients, des procédures d’audit et de gestion des droits d’accès aux secrets, de journaliser les accès aux secrets et de mettre à leur disposition des procédures d’effacement des secrets lorsqu’ils ne sont plus utilisés ou en fin de contrat. Il est incité de ne pas mutualiser les services de bases de données pour des composants différents au sein d’un même serveur ou au sein d’un même cluster de serveurs, de caches pour des composants différents au sein d’un même serveur ou au sein d’un même cluster de serveurs. Sans oublier de créer un réseau spécifique pour les services tiers (hébergement, données, caches et messaging) et un réseau dédié pour les services tiers faisant usage de protocole multicast comme Pacemaker et Corosync.

Protection des données des clients

L'utilisation des filtres pour le service Nova est privilégiée afin de permettre la création d’agrégats de nœuds de calculs dédiés pour les clients. Et aussi d’intégrer aux modèles de VM proposées aux clients, des métadonnées utilisables par les filtres Nova pour sélectionner les agrégats de nœuds de calcul sur lesquels instancier les machines virtuelles. Sans oublier de configurer les aspects suivants : 

- La migration à chaud des machines virtuelles pour qu'elle s'appuie sur QEMU ;
- QEMU pour mettre en œuvre du chiffrement TLS à l'état de l'art lors de la migration des VM ;
- Le service Swift pour qu'il dispose de plusieurs ensembles de stockage ;
- Le service Cinder pour qu'il associe un backend à chaque ensemble de stockage ;
- Les quotas Cinder pour restreindre l'accès des projets aux backends.

En termes de cloisonnement réseau l'Anssi conseille de configurer le service Neutron (network as a service) pour encapsuler les échanges entre les nœuds de calcul dans des tunnels IPSec, mettre en place une politique de renouvellement périodique des clés maitres du HSM ainsi qu'une procédure d'effacement sécurisé des données du client présentes sur le serveur LDAP. "Il est recommandé de mettre en œuvre un Linux Security Module sur les hyperviseurs ou un système de cloisonnement similaire [...] de supprimer le compte administrateur par défaut (guest). Pour le cas où un compte d’administrateur est nécessaire, le nom de ce compte doit être différent. Enfin une ACL d’accès restrictive doit être réalisée afin de contrôler les accès des comptes aux « topics »", recommande l'agence.

Mise en oeuvre de la journalisation sur les services OpenStack

La mise en place d’un niveau de journalisation correcte est une étape importante lors de la mise en place d’un environnement OpenStack. Autant pour la détection des comportements malveillants que pour suivre le bon fonctionnement des différents services, la mise en place d’un système de journalisation est nécessaire. Les points de vigilance à suivre seront les suivants : 

- Veiller à la synchronisation des horloges ;
- Auditer les accès aux fichiers de configuration des services OpenStack ;
- Activer la journalisation essentielle à la détection de compromission ;
- Activer la journalisation importante pour la détection de compromission ;
- Activer l'ensemble des systèmes de journalisation.