Informatique bancaire : conseils pour la gestion des tests

Depuis la publication de la circulaire "10/2012 (BA) - Exigences minimales en matière de gestion des risques MaRisk" ainsi que des explications 12/2012 par l'Autorité fédérale allemande de surveillance des services financiers (BaFin), l'informatique des banques fait l'objet d'une multitude de mesures à mettre en œuvre, notamment pour satisfaire aux exigences de AT 7.2 et AT 7.3. Les contrôles spéciaux annoncés conformément à l'article 44, paragraphe 1, de la loi allemande sur le crédit (KWG) mettent au défi aussi bien les responsables commerciaux que les responsables informatiques.

De nombreux formalismes et obstacles administratifs doivent être surmontés en plus de la lourde charge des activités quotidiennes. Bien sûr, les exigences réglementaires doivent être respectées, mais il n'est pas rare que les mesures dépassent l'objectif. Il est important de trouver une voie de mise en œuvre appropriée.

Relier le domaine, le développement et l'exploitation

La gestion des tests constitue ici le lien central entre le domaine spécialisé, le développement et l'exploitation. Les mesures prescrites dans le test entraînent des effets de bord considérables dans les domaines susmentionnés.

Ci-dessous sont esquissées des approches pragmatiques et éprouvées dans la pratique tout au long du processus de développement logiciel, qui permettent de satisfaire aux exigences réglementaires du point de vue de la gestion des tests. Une liste de contrôle (voir page suivante) permet de vérifier quels composants doivent encore être mis en œuvre.

Les logiciels nouveaux ou modifiés doivent être testés. L'expression technique des cas de test par les services spécialisés juste avant la phase de test s'avère souvent être un processus difficile. Il est bien plus judicieux de demander une description du scénario de test pour chaque exigence formulée lors de la phase de conception.

Conception : Rôles et autorisations

Le thème des rôles et des autorisations est habituellement traité de manière plutôt négligée. Ici aussi, l'IT devrait insister dès la phase de conception sur une définition correcte et complète, sur la séparation des fonctions ainsi que sur la formulation de scénarios de test correspondants.

Développement : SAP ChaRM

Des directives de développement actuelles et aussi légères que possible, avec des conventions de dénomination, des directives pour l'utilisation de techniques de programmation critiques ainsi que des conseils pour un code de programme optimisé, sont devenues un must.

Il est également recommandé de disposer d'un système intégré de gestion des ordres et des transports. Pour les utilisateurs SAP, le composant SAP Change Request Management (ChaRM) du Solution Manager s'impose ici avec des procédures d'approbation dédiées, des séparations strictes des rôles ainsi qu'une preuve de la chaîne de transport, du développement à la production en passant par les systèmes de test et d'acceptation, de manière à ce qu'elle soit protégée contre les révisions.

Peu de domaines de développement prennent le temps d'effectuer des révisions de code selon le principe du double contrôle. Ici aussi, il existe désormais sur le marché de bons outils qui vérifient le code du programme, entre autres, pour détecter les points faibles en matière de sécurité et, en cas de violation des règles, empêcher le transport vers les systèmes d'assurance qualité ou de production.

Dans l'environnement SAP, le Code Profiler de Virtual Forge et le SAP Code Vulnerability Scanner sont considérés comme des leaders. Les conditions d'entrée pour le test spécialisé sont des tests de modules documentés par le développement ainsi que l'indication des restrictions de test telles que les fonctions non encore terminées ou les erreurs déjà connues.

Là aussi, des outils de soutien sont proposés. La composante ChaRM de SAP Solution Manager permet par exemple de documenter et de prouver les tests de modules.

En premier lieu, il est recommandé de définir clairement les processus de gestion des tests et les rôles dans les processus de test et d'acceptation, ainsi que de mettre à disposition des modèles, par exemple pour les concepts de test ou les descriptions de cas de test. Ici aussi, le principe suivant s'applique : "Moins, c'est plus".

Séparation des rôles

Les longs passages en prose ne sont pas lus. Mieux vaut des listes de contrôle, des tableaux et des graphiques. D'ailleurs, pour répondre aux exigences réglementaires, il est important de séparer strictement les rôles entre le domaine spécialisé, le développement et les tests.

Les procédures de gestion des tests basées sur Excel sont dépassées. Les tests et les écarts doivent être documentés et conservés de manière compréhensible et à l'abri des révisions. L'utilisation d'outils de gestion des tests intégrés tels que le HP Application Lifecycle Management (HP ALM) Quality Center, IBM Rational Quality Manager ou le SAP Solution Manager Test Workbench est obligatoire.

Pour des raisons de sécurité, les données sensibles (notamment les données personnelles) ne doivent pas être utilisées dans les environnements de test qui ne sont pas gérés de manière centralisée. Par exemple, les données des partenaires commerciaux doivent être rendues anonymes. Un processus doit être défini pour l'accès aux données de test par les testeurs (et éventuellement par les développeurs pour l'analyse des erreurs). L'attribution d'ID d'utilisateur et d'autorisations doit être consignée.

Gestion des tests : un risque calculé

La gestion des risques gagne en importance. Ainsi, la banque doit également démontrer que les risques liés aux tests, tels que la mise à disposition tardive du logiciel à tester ou l'absence d'infrastructure de test, sont pris en compte et évalués, et que les mesures de migration correspondantes sont mises en œuvre et suivies.

L'approche de test basée sur les risques a fait ses preuves. Dans ce processus, les processus sont évalués en fonction de leur criticité, comme la fréquence d'appel ou les exigences de sécurité, ainsi qu'en fonction des modifications et des adaptations apportées au projet de test en cours.

L'étendue et la priorité des objets et des cas de test impliqués en découlent. L'accent est ainsi mis sur les tests vraiment importants, en fonction des risques.

Il est de la responsabilité de la gestion des tests de prouver que les types de résultats obligatoires tels qu'un concept de test ou une planification des tests ont été établis, que les tests obligatoires tels que les tests de sécurité ou de reprise après sinistre ont été effectués (ou que la non-exécution a été justifiée) ou que le processus d'acceptation a été effectué correctement. Un système de contrôle interne (SCI) basé sur des listes de contrôle s'impose ici.

Mise en œuvre et fonctionnement

Lors de la mise en œuvre, des procédures de transfert définies sont importantes, avec une stricte séparation des rôles entre le développement et l'exploitation. Pour l'exploitation, il convient de mettre en place et d'exploiter un système de gestion de la sécurité de l'information basé sur des outils. Du point de vue de la gestion des tests, on peut par exemple se référer à des procédures régulières pour une reprise après un sinistre.

Conclusion

Les mesures susmentionnées visant à satisfaire aux exigences réglementaires doivent impérativement être mises en œuvre. Il est recommandé d'adopter une approche globale et de mettre en œuvre des approches pragmatiques et éprouvées dans la pratique.

La liste de contrôle permet de vérifier quels éléments doivent encore être introduits. En outre, il convient de miser sur des normes telles que les normes BSI 100-1 à 100-4, ISO 29119 (test) ou ITIL.

Liste de contrôle

Sur la base de ces points, on obtient un premier aperçu des composants implémentés (non satisfaits/ partiellement satisfaits/complètement satisfaits) :

1. La définition de scénarios de test pour les exigences est-elle obligatoire ?
2. Les modifications apportées aux rôles et aux autorisations sont-elles décrites ?
3. Existe-t-il des directives de développement ?
4. Un système intégré de commandes et de transport est-il mis en place ?
5. Lors du déploiement de logiciels, les rôles sont-ils strictement séparés entre le développement et l'exploitation ?
6. Des revues de code sont-elles effectuées ?
7. Existe-t-il des outils de soutien à l'assurance qualité dans le développement ?
8. Des tests de modules sont-ils effectués et documentés ?
9. Les processus de test et les rôles sont-ils décrits dans la gestion des tests ?
10. Existe-t-il une stricte séparation des rôles entre le domaine, le développement et le test ?
11. Un outil intégré de gestion des tests est-il disponible ?
12. Les données sensibles sont-elles protégées/anonymisées dans les systèmes de test ?
13. Existe-t-il une procédure d'attribution des utilisateurs et des autorisations pour les systèmes de test ?
14. Les risques liés aux tests sont-ils documentés, évalués et suivis ?
15. L'exécution des cas de test est-elle prioritaire ?
16. L'élaboration des types de résultats obligatoires ainsi que des tests obligatoires est-elle systématiquement contrôlée (check-list SCI) ?
17. Existe-t-il un processus défini pour l'accès aux données de test sensibles ?
18. Le processus de transfert vers la production est-il défini ?
19. Un système de gestion de la sécurité de l'information est-il en place ?
20. Des normes telles que ITIL, BSI ou DIN-ISO sont-elles utilisées ?