L'authentification multifacteur, souvent appelée MFA, est un contrôle supplémentaire en plus d'un mot de passe : un code provenant d'une application, un SMS ou une clé physique. La question de savoir si cela est obligatoire pour une entreprise de logiciels ne peut pas être répondue par un simple oui ou non, car la directive NIS2 ne prescrit aucune technique spécifique. L'article 21 oblige les organisations soumises à l'obligation de diligence à prendre des mesures appropriées pour la sécurisation de l'accès et l'authentification multifacteur, et les autorités de surveillance examinent où le risque est le plus élevé.
Pour une entreprise de logiciels, c'est en pratique deux endroits très différents : la chaîne de développement avec laquelle vous travaillez vous-même, et le logiciel que vous livrez aux clients. Les deux exigent une évaluation distincte, et cette évaluation n'est pas aussi stricte partout.
Deux endroits où l'authentification multifacteur joue un rôle
Le premier endroit est interne : l'environnement dans lequel vos développeurs travaillent. Code source, chaîne de développement, consoles cloud et systèmes avec lesquels vous déployez en production. Le deuxième endroit se trouve dans le produit lui-même : si le logiciel que vous créez ou livrez dispose d'un écran de connexion, l'authentification multifacteur est également un sujet là, tant pour vos propres utilisateurs que pour les utilisateurs finaux de votre client. Un questionnaire de sécurité d'un client demande presque toujours les deux, souvent dans des questions distinctes formulées différemment de ce que vous attendriez.
Pour l'accès à votre chaîne de développement
C'est ici que l'attente est la plus forte. Qui peut accéder au code source, qui peut déployer en production, et qui dispose de droits d'administrateur sur l'environnement cloud, représente le risque le plus élevé si un mot de passe est simplement volé ou réutilisé. Pour ces comptes, l'authentification multifacteur est considérée comme une mesure fondamentale dans presque tous les cadres de sécurité, et c'est aussi ce que les autorités de surveillance et les clients attendent en premier. La gestion de versions, la chaîne de développement elle-même, et en particulier tout compte ayant le droit de déployer du code en production, doivent en pratique sans exception être protégés par une deuxième étape.
Cela inclut également un examen de qui a réellement encore besoin de cet accès. Un dossier indiquant par système qui peut y accéder et pourquoi facilite la réponse à cette question dans un questionnaire avec une réponse concrète plutôt qu'une hypothèse. comment la gestion de l'accès et l'authentification multifacteur sont expliquées par sujet fournit un point de départ pour cela.
Pour le logiciel que vous livrez
Le deuxième niveau est le logiciel lui-même. Si votre produit dispose d'une fonction de connexion, la question de savoir si vous offrez l'authentification multifacteur revient presque toujours dans un questionnaire de sécurité, et parfois même comme condition contractuelle. C'est une évaluation différente de celle de votre propre chaîne de développement : il ne s'agit pas ici de ce que vous utilisez vous-même, mais de ce que vous livrez à votre client. Un client qui est lui-même soumis à l'obligation de diligence doit également, selon l'article 21, évaluer sa chaîne d'approvisionnement, et la question de savoir si votre produit supporte l'authentification forte en fait partie.
La réponse n'a pas besoin d'être que c'est obligatoire partout. Souvent, il suffit de montrer que la possibilité existe, que les utilisateurs y sont encouragés, et que vous avez un plan pour l'étendre là où le risque le justifie.
Où ce n'est pas aussi évident
Tous les comptes et tous les environnements ne nécessitent pas le même niveau de sécurité. Un environnement de test sans données clients réelles, un système de documentation interne en lecture seule, ou un outil isolé utilisé occasionnellement par un seul développeur méritent un traitement différent d'un compte disposant d'un accès à la production. Les mesures de gestion des risques exigées par la directive doivent être proportionnées aux risques, et non appliquer partout une protection uniformément lourde. Les autorités de surveillance évaluent cela en fonction du principe de proportionnalité, ce qui signifie qu'une décision bien justifiée de ne pas mettre en place l'authentification multifacteur quelque part peut tout aussi bien faire partie d'un dossier que les endroits où elle est effectivement en place.
La justification est ici le mot clé. Une décision sans explication ressemble vite à une omission dans un questionnaire, tandis que la même décision accompagnée d'une brève justification correspond souvent précisément à la réponse que recherche un client.
Ce que cela signifie pour la discussion avec un client
Un client qui envoie un questionnaire ne souhaite généralement pas savoir si vous respectez chaque détail, mais si vous connaissez vos risques et les gérez consciemment. Pour l'authentification multifacteur, cela signifie : pouvoir montrer ce qui est mis en place dans la chaîne de développement, ce qui est mis en place dans le produit, et pourquoi le reste est organisé différemment. Celui qui a documenté cela par système avec un statut et un responsable n'a pas besoin de refaire la recherche chaque fois qu'un nouveau questionnaire arrive.
Le fait que cela et comment cela vous touche précisément dépend de votre rôle dans la chaîne logistique et des exigences spécifiques de vos clients ; en cas de doute, consultez le texte de la directive lui-même ou un conseiller. Si vous voulez d'abord savoir où vous en êtes, le contrôle gratuit en quelques questions donne une première indication, et une explication sur la provenance des informations montre comment cette indication a été établie.
Si vous souhaitez lire plus largement comment ce sujet s'articule avec les autres mesures de gestion des risques, vous le trouverez dans l'aperçu des sujets selon votre situation. L'outil de diagnostic rapide et la base de connaissances sont librement accessibles, sans que vous ayez besoin de créer un compte.