Comment les équipes financières testent les parcours utilisateurs sécurisés sans compromettre la sécurité

Dans les applications financières, les éléments les plus importants — l'authentification, le contrôle d'accès et les flux de travail sécurisés — sont aussi les plus difficiles à tester.

Ce ne sont pas des couches optionnelles. Elles définissent la manière dont les utilisateurs interagissent avec l'application.

Et elles introduisent des contraintes que les approches de test standard ne gèrent pas toujours bien.

La sécurité fait partie intégrante de l'expérience utilisateur.

Dans une application financière, le processus de connexion ne se résume pas à un nom d'utilisateur et un mot de passe.

Cela peut inclure l'authentification biométrique, l'authentification multifactorielle, la validation de session et les contrôles au niveau de l'appareil.

Chacune de ces étapes peut se comporter différemment selon l'appareil, le système d'exploitation et l'environnement.

Dans le même temps, de nombreuses applications sont distribuées via des systèmes d'entreprise et régies par des politiques qui influencent leur fonctionnement.

Les tests doivent prendre en compte tout cela, et pas seulement vérifier si la fonctionnalité sous-jacente fonctionne.

Pourquoi les équipes simplifient les tests

En pratique, de nombreuses équipes adaptent leur approche de test pour gérer la complexité.

• L'authentification peut être contournée pour accélérer l'exécution.
• Les fonctions de sécurité peuvent être désactivées afin d'éviter toute instabilité.
• Des versions distinctes peuvent être utilisées pour isoler les fonctionnalités.

Ces décisions sont souvent prises pour des raisons pratiques. Elles permettent de poursuivre les tests sans engendrer de frais supplémentaires.

Mais elles modifient également les conditions de validation de la demande.

Une part importante des efforts de test est consacrée à l'analyse des défaillances plutôt qu'à l'exécution des tests eux-mêmes. Lorsque les tests ne reflètent pas les conditions réelles, cette analyse devient encore plus difficile.

Le rôle des environnements gérés (MDM)

Un aspect souvent négligé est celui des tests en environnements gérés.

De nombreuses applications financières sont déployées via des systèmes de gestion des appareils mobiles tels que Microsoft Intune ou VMware Workspace ONE. Ces systèmes appliquent des politiques, configurent les appareils et contrôlent l'accès.

Cela influe sur le comportement de l'application.

Par exemple, des certificats peuvent être requis pour l'authentification, certaines fonctionnalités peuvent être restreintes en fonction de la politique en vigueur et les configurations réseau peuvent différer des configurations standard.

Tester ces variations en dehors de ce contexte peut les faire passer à côté.

Dans de nombreux cas, les plateformes de test utilisent des appareils non gérés, qui ne tiennent pas compte de ces contraintes. Par conséquent, les comportements qui n'apparaissent que dans les environnements gérés ne sont pas validés avant la mise en production.

Tester les applications durcies est devenu une véritable contrainte.

Un autre défi qui est devenu plus fréquent dans les applications financières consiste à tester les logiciels qui incluent des protections d'exécution ou une obfuscation.

Ces protections sont conçues pour empêcher toute falsification, rétro-ingénierie et accès non autorisé, et elles sont obligatoires dans de nombreuses organisations financières.

Le problème, c'est qu'ils interfèrent souvent avec la façon dont les outils de test interagissent avec l'application.

Pour contourner ce problème, les équipes peuvent désactiver les protections, utiliser des versions spécifiques ou se contenter d'une validation partielle. Mais une fois les protections supprimées, l'application ne se comporte plus comme en production.

Cela introduit un autre type de risque, celui où les problèmes liés aux couches de sécurité ne sont jamais validés avant la mise en production.

À mesure que de plus en plus d'organisations intègrent le renforcement des applications à leur stratégie de sécurité, cela devient une contrainte standard dont les tests doivent tenir compte.

Pour une analyse plus approfondie de la manière dont ce défi peut être relevé en pratique, voir comment Digital.ai l'ont abordé dans Tests automatisés et renforcement de la sécurité des applications : résoudre un problème DevSecOps Dilemme.

À quoi ressemble une approche plus réaliste

Une approche plus efficace consiste à aligner les conditions de test sur les conditions de production.

• Les flux d'authentification sont exécutés au fur et à mesure de leur utilisation, y compris la biométrie et l'authentification multifacteur.
• Les applications sont testées avec les protections activées, plutôt que de s'appuyer sur des versions modifiées ou non sécurisées qui ne reflètent pas le comportement en production.
• Les appareils sont configurés avec les mêmes politiques et contraintes que celles rencontrées par les utilisateurs, y compris les contrôles MDM.
• Des tests sont exécutés sur une gamme d'appareils et d'environnements afin de capturer la variabilité.

Cela n'augmente pas nécessairement le nombre de tests. Cela modifie ce que ces tests représentent réellement.

Pourquoi cela améliore la prise de décision

Lorsque les tests reflètent les conditions réelles, les résultats deviennent plus exploitables.

• Les défaillances sont plus faciles à interpréter car elles surviennent dans des scénarios réalistes, notamment des flux sécurisés et des environnements gérés.
• Le temps d'investigation diminue car le contexte est déjà disponible.
• Release Les décisions peuvent être fondées sur des preuves qui correspondent au comportement de l'application en production.

Améliorer la qualité de ce signal a un impact direct sur la rapidité avec laquelle les équipes peuvent comprendre les défaillances et prendre des décisions de mise en production.

Concilier sécurité et testabilité

On suppose souvent que tester des applications sécurisées implique des compromis.

Soit la sécurité est maintenue et les tests sont limités, soit les tests sont étendus en réduisant les contraintes de sécurité.

En pratique, ce compromis est souvent dicté par des limitations au niveau des outils ou de la configuration de l'environnement plutôt que par une contrainte fondamentale.

Tester des applications sécurisées, gérées et protégées est possible sans compromettre leur intégrité, mais cela nécessite une approche qui tienne compte de la manière dont ces applications fonctionnent réellement en production.

👉 Vous rencontrez déjà ces difficultés ? Parlez à un expert en tests pour analyser votre environnement et les prochaines étapes. 

👉 Vous n'êtes pas sûr de la pertinence de votre approche actuelle ? Prenez une Questionnaire de préparation aux tests mobiles.