L’implémentation de la sécurité dans les systèmes d’information est une nécessité dans le paysage technologique actuel. Les organisations et les individus dépendent de plus en plus de la technologie pour stocker, traiter et transmettre des données sensibles. Les risques liés à la sécurité informatique sont plus préoccupants que jamais.
Protéger un système d’information sans le restreindre de manière excessive est un équilibre délicat. Il est possible d’adopter des approches efficaces pour garantir la sécurité tout en maintenant la flexibilité et la fonctionnalité du système. C’est le rôle des experts cybersécurité. Or ces contraintes limitent ou perturbent notre mission de testeur logiciel.
Dans la Qualité Logicielle, notre énergie est focalisée sur la validation du comportement de l’application, des traitements associés, de l’interface « homme-machine », etc. Dans tout projet de test, nous sommes naturellement confrontés à des contraintes influant défavorablement sur notre capacité à tester et à la mise en place de règles de sécurité, comme n’importe quel utilisateur.
La mise en place de tests automatisés met en exergue ces contraintes. La cybersécurité rejetant par essence tout usage des automates, perçus comme des menaces ; nous faisons face à davantage de limitations, étant exclus les contournements ou dérogations possibles.
Alors, comment adresser tout cela en assurant la validation fonctionnelle des applications de la manière la plus efficiente possible ?
Un client engagé dans la cybersécurité et la protection de ses données
Considérons notre client et son application de gestion MAGESTION. Celle-ci contient des données sensibles – notamment de santé – et ne doit être accessible que dans des conditions drastiques de sécurité. MAGESTION est une application en SaaS hébergée par l’éditeur – qui administre l’application et gère les montées de version.
Les utilisateurs de MAGESTION peuvent se connecter uniquement depuis leur poste dédié – protection BitLocker & VPN – avec une procédure de sécurité établie. L’accès à l’application comprend les étapes de connexion suivantes :
- Le déverrouillage physique du poste de travail (disque) par un mot de passe
- Une connexion O 365 au poste de travail contrôlée par l’AD Azure ;
- Une ouverture de VPN confirmée par une double authentification qui permet d’accéder à la procédure de connexion dédiée à MAGESTION ;
- Une connexion SSO (« Single Sign-on Authentication ») pour accéder à la connexion à MAGESTION.
Contrairement au cas le plus permissif (connexion avec un compte et un mot-de-passe « simples » depuis n’importe quel poste de travail), le système de sécurité mis en place vise à autoriser exclusivement les connexions de personnes physiques parfaitement identifiées avec des conditions bien balisées.
L’authentification étant gérée par le SSO, nous excluons de notre stratégie de test cette part initiale des tests. Nous focalisons alors nos travaux sur les tests de régression, évolution, confirmation (nos grands classiques) avec une vision des processus métier et les autorisations liées, l’accès ou non aux données, les possibilités d’import/export, etc.
Une fois connectés avec un profil unique (déclaré dans l’application), et en qualité d’une personne physique, nous sommes en mesure de qualifier MAGESTION. Le choix du profil le plus privilégié, celui d’« administrateur fonctionnel »,nous permettra de couvrir le plus grand périmètre fonctionnel.
Données et profils : le casse-tête standard du testeur logiciel
Sur la base de cette configuration, le profil du testeur « administrateur » assure une couverture presque « sans limites » des cas de test et la vérification sans restriction du bon fonctionnement des processus métier. Cependant, il existe d’autres profils actifs, définis par l’organisation et modélisés dans MAGESTION, avec un accès plus ou moins restreint aux données et processus, conformément aux règles de l’organisation.
C’est le cas du gestionnaire. Dans notre exemple, nous allons le limiter dans la valeur de ses engagements : il détient un seuil de remboursement santé ou capital décès à hauteur de 3 000 Euros. Lorsqu’il effectue des actions au-delà de ce seuil, l’application génère un blocage de ces actes. L’alerte levée auprès de son responsable (qui détient un seuil de remboursement de jusqu’à 20 000 Euros) entraîne vers celui-ci une action à traiter.
Prenons maintenant le rôle du VIP (Very Important Person). Cette fonction, souvent présente chez nos clients et généralement attribuée à quelques décideurs, accorde l’accès à un nombre important de données, sans toutefois avoir le droit de modifier (il peut devenir source d’erreur !) Le VIP accède à une couverture plus large que le gestionnaire ou son responsable. Il a même un profil « spé-ci-fi-que ».
Ces différents profils décrits, et leurs capacités d’usage, soulèvent plusieurs questions : Pour mener à bien ses tests, le testeur doit-il se mettre à la place du gestionnaire avec des droits limités, de son responsable, ou choisir le profil d’un VIP ? Ou bien doit-il « jouer » le rôle de plusieurs utilisateurs tout en conciliant cette obligation d’être connecté en qualité d’une seule personne physique (rappelez-vous, le SSO !) ?
Panel des solutions applicables dans la Qualité Logicielle
Notre expérience dans le test logiciel, sur la base de différents outils, nous amène à plusieurs approches courantes :
ACTION | CONTRAINTE | RESOLUTION/CONTOURNEMENT |
Se connecter sur plusieurs comptes MAGESTION ayant chacun leur profil | L’authentification via SSO nous l’interdit puisque notre compte MAGESTION est hérité de notre session Windows | Faire créer autant de compte applicatifs / windows que nécessaires – avec les profils adéquats – attachés à la personne physique du testeur |
Modifier le profil de notre compte dans MAGESTION afin de commencer le processus avec un profil et le terminer avec un autre | Outre les nombreuses (dé/re)connexions que cela impose, il faudrait composer les deux profils « gestionnaire » et « responsable » pour que chacun d’eux aient le droit de changer leur profil (ou avoir une méthode non applicative pour changer le profil à la demande) | Exécuter les tests suivant un profil déterminé (assez permanent) et demander à l’administrateur de MAGESTION de modifier notre profil en fonction des besoins (agent, responsable, etc.) et de revenir au profil standard |
Bénéficier de plusieurs comptes applicatifs MAGESTION différents | Cela implique naturellement autant de comptes windows sous gestion du SSO à traiter au travers différents comptes windows sur un même PC (se (dé/re)connectant à windows de plusieurs PC ayant chacun leur compte windows / authentification SSO propre au profil visé. Dans ce cas, nous enfreignons la règle première d’une personne physique ayant un seul compte applicatif ! | Utiliser plusieurs postes de travail (physique ou VM) connectés avec des comptes adaptés |
Modifier les profils des comptes via des procédures externes (API, par exemple) dans l’un ou les systèmes liés ; | Une procédure restreinte en usage et sécurisée permet de modifier les profils sans cette interface soumise aux contraintes. | Instancier un Web Service dédié de changement de profil, utilisable depuis un environnement / machine, avec une double authentification et des fonctionnalités extrêmement limitées (en fonctionnement en boîte noire) |
Répartir les rôles entre plusieurs testeurs fonctionnels (des testeurs logiciels professionnels ou des référents métier inclus dans les tests) | La mise en conformité réelle des rôles de production dans un environnement de test par l’inclusion des métiers s’avère la solution la plus simple théoriquement ; les métiers verront leur application en mode cible, avec les mêmes droits et limites ; les données protégées ne seront pas visibles des testeurs par exemple. | Inclure dans la démarche de test autant de personnes physiques avec chacune un rôle adéquat que de profils nécessaires. Il peut s’agir de testeurs ou utilisateurs métiers momentanément détachés. |
Négocier avec le RSSI (Responsable de la Sécurité Informatique) de ne pas être soumis à certaines contraintes. | La dérogation des règles standards peut être négociée avec le responsable de la Sécurité. Cette démarche est documentée, revue régulièrement dans le temps ; son champ d’application est extrêmement limité. | Une connexion dans des conditions drastiques sans le SSO est demandée ; cela est valable pour quelques testeurs, mais aussi pour un automate de test ou un outil de mesure de performance… |
Voici comment un simple sujet de partage et d’accès de données, devient un véritable casse-tête débordant d’alternatives, contournements ou négociations. L’expert en Qualité Logicielle jongle entre les différents rôles existants pour répondre aux spécifications fonctionnelles et respecter les règles imposées par la Cybersécurité !
Stratégie retenue par l’expert Qualité
Prenons en compte les différentes exigences de sécurité citées ci-dessus. Dans le cadre d’une phase de test interne à l’équipe de test, nous aurions pu adopter la solution la plus classiquement envisagée : « Sous la supervision d’un administrateur de droits dans MAGESTION, deux ou trois testeurs auraient occupé, chacun son tour, les rôles & profils attendus ».
Dans le cas présent de MAGESTION, la stratégie retenue, en accord avec les directives de la Direction Générale, a privilégié l’implication des gestionnaires dans la réalisation des tests. Cela se traduit par :
- Inclure autant d’utilisateurs type dans la campagne que de profils ;
- Définir les scénarios de test (de bout en bout) incluant ces ensembles d’utilisateur, avec cette dépendance chronologique dans les actions et points de contrôles au sein de MAGESTION ;
- Assurer le suivi et la coordination inter-utilisateurs pour évaluer les accès et usages (cas passants et non passants) ;
Par expérience, le point critique réside dans l’attention que l’expert en Qualité Logicielle porte à la formation et coordination de tous ces « testeurs non professionnels » pour arriver rapidement et sereinement à la décision de livraison. Cela demande une organisation assurée et une maturité pour amener une population hétérogène à un résultat homogène !
Cette approche n’est évidemment valide que pour ce client pour plusieurs raisons :
- Sa capacité à mobiliser des gestionnaires, détachés pour de plus ou moins longues périodes, pour réaliser des tests et non des actions en production ;
- Les gestionnaires de cette entreprise, souvent le cas des sociétés allemandes, participent aux activités de test (pendant les phases de test, des intérimaires assurent la continuité des activités courantes.
Conclusion
« Confidentialité » et « Authentification » sont les aspects premiers de la cybersécurité que rencontrent de plus en plus les testeurs logiciels. Pour les appréhender et avoir la capacité de valider le fonctionnement adéquat du système d’information, la stratégie de test doit prendre en compte ces contraintes légitimes.
Se limiter à la seule vision fonctionnelle est une erreur grave. Nos clients attendent une autonomie dans la compréhension des éléments architecturaux de base.
ALDEMIA acculture ses collaborateurs à ce pan nouveau et évolutif qui apparaît souvent hors nécessité de connaissance de la part des testeurs logiciels au travers de :
- Ces contraintes d’accès aux processus et données ;
- L’évocation de la cybersécurité (à vision de la stratégie de test, mais aussi abordant des points techniques de certificat, (pseudo/ano)-nymisation, cryptographie, authentification, etc.
- La culture des contraintes techniques basiques applicables sur les outils de base : accès à une base de données (sans mot de passe explicite), les tests de Webservices (OATH2, etc.), API Key, etc.
Et WEB3.0 va nous apporter de nouvelles approches…