corriger ou d’apporter toutes les précisions nécessaires.
Droits applicatifs insuffisants : lorsque l’utilisateur final ne procède pas lui-même
aux tests, il est important de vérifier que l’agent chargé de tester dispose des droits
applicatifs nécessaires. Trop souvent, on oublie que telle ou telle fonctionnalité
applicative ne peut être invoquée qu’en disposant de droits étendus. Le testeur se
retrouve donc bloqué lors de l’exercice. Là aussi, une vérification préalable et
méticuleuse évite ce problème au moment du test.
Oubli de ressources stratégiques : malgré toutes les précautions qui auront été prises
lors de la phase de préparation, il n’est pas impossible que certaines ressources
critiques aient été oubliées. Certes, personne n’oubliera d’intégrer dans la plate-forme
de test l’annuaire interne, le serveur central de fichiers ou le serveur DHCP.
Cependant, d’autres éléments pourront être oubliés. Par exemple, certaines
applications nécessitent de joindre un serveur de licences avant de se lancer. Il est
clair que ce n’est pas ce type de ressource auquel on pense au moment de
l’identification des ressources nécessaires. Pourtant, si aucun serveur de licences n’est
installé dans la plate-forme de tests, aucune application s’en servant ne pourra
démarrer.
Clients lourds antédiluviens : certaines applications historiques nécessitent
l’installation d’un client lourd. Il faut vérifier que ces clients sont bien installés dans
les postes de travail destinés aux tests. En effet, on oublie régulièrement de les
installer et, lorsqu’on s’aperçoit de leur absence au moment de l’exercice, on dispose
rarement de l’unique personne dans la DSI sachant paramétrer ce client lourd.
Poste de travail de test : pour tester le comportement des applications lors de
l’exercice de PRI, on construit généralement plusieurs postes de travail destinés à
simuler le poste de travail des utilisateurs. Il ne faut pas oublier d’y installer les clients
lourds nécessaires pour accéder à certaines applications (comme vu dans le point
précédent). De plus, un traitement de texte permettra la rédaction du rapport de
l’exercice au fur et à mesure des tests. Des outils d’enregistrement de session seront
bien utiles pour garder des traces vivantes des tests. Pour terminer, n’oublions pas tout
ce qu’il faut pour accéder aux serveurs (client SSH, client RDP, etc.). L’expérience
montre que l’on oublie souvent au moins un de ces éléments.
Une fois de plus, il ne s’agit ici que d’exemples. D’autres oublis de ce type peuvent
rendre plus difficile la réalisation de l’exercice. Le RSSI est bien placé pour aider les
équipes à vérifier que rien n’a été oublié.
Droits applicatifs insuffisants : lorsque l’utilisateur final ne procède pas lui-même
aux tests, il est important de vérifier que l’agent chargé de tester dispose des droits
applicatifs nécessaires. Trop souvent, on oublie que telle ou telle fonctionnalité
applicative ne peut être invoquée qu’en disposant de droits étendus. Le testeur se
retrouve donc bloqué lors de l’exercice. Là aussi, une vérification préalable et
méticuleuse évite ce problème au moment du test.
Oubli de ressources stratégiques : malgré toutes les précautions qui auront été prises
lors de la phase de préparation, il n’est pas impossible que certaines ressources
critiques aient été oubliées. Certes, personne n’oubliera d’intégrer dans la plate-forme
de test l’annuaire interne, le serveur central de fichiers ou le serveur DHCP.
Cependant, d’autres éléments pourront être oubliés. Par exemple, certaines
applications nécessitent de joindre un serveur de licences avant de se lancer. Il est
clair que ce n’est pas ce type de ressource auquel on pense au moment de
l’identification des ressources nécessaires. Pourtant, si aucun serveur de licences n’est
installé dans la plate-forme de tests, aucune application s’en servant ne pourra
démarrer.
Clients lourds antédiluviens : certaines applications historiques nécessitent
l’installation d’un client lourd. Il faut vérifier que ces clients sont bien installés dans
les postes de travail destinés aux tests. En effet, on oublie régulièrement de les
installer et, lorsqu’on s’aperçoit de leur absence au moment de l’exercice, on dispose
rarement de l’unique personne dans la DSI sachant paramétrer ce client lourd.
Poste de travail de test : pour tester le comportement des applications lors de
l’exercice de PRI, on construit généralement plusieurs postes de travail destinés à
simuler le poste de travail des utilisateurs. Il ne faut pas oublier d’y installer les clients
lourds nécessaires pour accéder à certaines applications (comme vu dans le point
précédent). De plus, un traitement de texte permettra la rédaction du rapport de
l’exercice au fur et à mesure des tests. Des outils d’enregistrement de session seront
bien utiles pour garder des traces vivantes des tests. Pour terminer, n’oublions pas tout
ce qu’il faut pour accéder aux serveurs (client SSH, client RDP, etc.). L’expérience
montre que l’on oublie souvent au moins un de ces éléments.
Une fois de plus, il ne s’agit ici que d’exemples. D’autres oublis de ce type peuvent
rendre plus difficile la réalisation de l’exercice. Le RSSI est bien placé pour aider les
équipes à vérifier que rien n’a été oublié.