Objectifs 2002/2003

	Sécurité

Tous les outils pour centraliser la gestion des utilisateurs ont été installés. Reste à se concentrer sur un certains nombre de points visant à améliorer la pérennité et la perméabilité du réseau du Trésor:

1. affiner les stratégies systèmes de manière à empêcher l'accès à certains paramètres système/réseau sur les postes de travail,
2. mettre en place une politique de changement de mots de passes: définir des durées de validité et des contraintes de structure,
3. adopter une politique de suivi des comptes utilisateurs: heures d'ouverture de session, durée de validité des comptes,
4. utiliser un programme d'audit sur la sécurité des principaux serveurs, installation d'un programme de detection d'intrusion sur les serveurs Unix,
5. sensibilisation des utilisateurs à leur responsabilité par la définition et l'adoption d'une charte d'utilisation du réseau du Trésor,
6. mise en place d'un système de détection/fermeture automatique des sessions Aster et système restées ouvertes.

	Antivirus

Des antivirus sont installés sur la plupart des postes de travail Windows, mais faute d'abonnement à un service de mise à jour, la gestion centralisé, installée il y a plus d'un an, est devenue caduque:

Il faut donc:

1. souscrire un abonnement à un système antivirus,
2. reconfigurer le serveur de mise à jour, et redéployer les clients,
3. configurer l'intégration des alertes virales à OpenNMS.

	HACMP

HACMP devait servir à l'origine a reprendre l'exécution d'Aster sur le deuxième serveur resté en veille, en cas de panne sur le premier serveur. Aujourd'hui, les besoins d'Aster en puissance de calcul ont pris le pas sur les nécessités de la haute disponibilité pour l'application. Il a donc été décidé d'abandonner HACMP de manière à utiliser conjointement les deux serveurs Unix. En cas de problème, c'est une restauration manuelle qui sera faite.

Actuellement HACMP est partiellement désactivé, et impose toujours des contraintes sur l'utilisation et l'évolution des deux systèmes Unix:

1. Pour être indépendants, il est nécessaire que Tresor01 et Tresor02 disposent chacun de leur grappe de disques, en plus de leurs disques internes. Or actuellement, leurs grappes respectives sont l'image d'un seul et même système de fichier monté en miroir et géré par HACMP de manière exclusive (Seul un des deux systèmes peut accéder au disque..) Les deux bases de Tresor02 occupent actuellement la totalité de l'espace des disques internes ce qui anéanti tout espoir de montée en charge. Il faut désolidariser les grappes.
2. la mise à jour d'Oracle (voir le rapport d'audit d'Oracle) est conditionnée par la mise à du système AIX 4.1.3 ou AIX 5, elle même conditionné par l'annihilation d'HACMP. En effet, même si AIX 4.1.3 nous a été livré, c'est AIX 4.1.2 qui est installé à cause d'une incompatibilité avec HACMP.

	OpenNMS

OpenNMS est un logiciel de gestion d'un réseau Open Source qui intègre les dernières technologies en termes d'application web: JAVA, JSP et XML. Il est destiné à se retrouver au coeur de l'organisation de la cellule d'assistance et de maintenance de la SDI puisqu'il enregistre en permanence un certain nombre d'évènements concernant:

• les systèmes: l'arrêt des serveurs, l'arrêt d'une base oracle ou tout autre service, la présence d'un virus sur un poste, un problème sur une imprimante, une faille sécuritaire au niveau des serveurs,
• le réseau: extinction, indisponibilité et pannes matérielles sur les éléments actifs du réseau, localisation précise de la panne.

Il les transforme ensuite, selon un schéma entièrement paramétrable, en alertes (messagerie ou cellulaire) destinées a l'utilisateur en charge de ce type de problème.

Partiellement opérationnel, il reste à:

1. enregistrer tous les éléments actifs auprès d'OpenNMS, de manière à rendre les chiffres de disponibilité plus significatifs,
2. intégrer les alertes virales (voir [sub:Antivirus]), les alertes de saturation des disques, les alertes de surcharge processeur, et les alertes de detection d'intrusion,
3. peupler la base contenant les informations sur chaque système géré, comme la limite de garantie, et les utiliser dans les procédures de maintenance,
4. installer et/ou activer des agents SNMP sur les postes Windows pour permettre, entre autres, la traçabilité de l'allumage et de l'extinction des postes,
5. publier et suivre régulièrement les chiffres de disponibilité systèmes/réseaux, de manière à doter la SDI d'un outil d'auto-évaluation lui permettant:
   • de mesurer sa réactivité en cas de panne système/réseau,
   • de mesurer la qualité globale des ses systèmes/réseaux,
   • d'expliquer les dysfonctionnements.

	Préparation au déploiement

Par soucis d'économie, il a été décidé d'utiliser les liaisons spécialisées de SIGFIP vers les villes de Bouake, Aboisson, San-Pedro, plutôt que les liaisons RTC prévues initialement et qui ont déjà été installées. Il faut caractériser et résoudre les problèmes techniques liées à cette nouvelle solution.

	Système d'information

Les échanges d'informations au sein du Trésor sont pour l'instant cantonnés à une messagerie locale Microsoft, et à une messagerie internet fournie par la SNDI pour les quelques utilisateurs enregistrés auprès de la SNDI. Afin d'améliorer l'efficacité des échanges d'information, et pour marquer son indépendance, la SDI se doit de disposer de sa propre messagerie respectant les standards d'internet. Il faudrait au préalable:

1. enregistrer le nom de domaine cp.finances.gouv.ci,
2. mettre en place la messagerie (POP3) avec son portail WEB sur un serveur Unix,
3. intégrer la création d'un compte de messagerie à la procédure de création d'un compte utilisateur.

	Cellule d'assistance

Un système de téléphonie sur IP ainsi qu'un outil de prise de contrôle à distance sont partiellement déployés sur le réseau. Il conviendra à termes:

1. de les déployer sur tous les postes de manière à permettre à la cellule d'assistance de recevoir les appels et intervenir à distance sur les stations,
2. d'assurer une courte formation des utilisateurs et des assistants.

	Sauvegardes des bases de données

Il faut mettre en place une procédure de sauvegarde ne nécessitant pas l'arrêt des basesvoir le rapport sur les performances du système informatique Aster en Côte d'Ivoire - 9 juillet 2002 afin de disposer de sauvegardes consistantes sans avoir a interrompre les traitements.

	Tests CP3E

De nombreux indices et preuves nous laissent penser que l'état des systèmes et des réseaux est étranger aux mauvaises performances d'Aster. Les bases de données, quant à elles, sont nettoyées et réindexées régulièrement pas Émery NIABA sans constater d'améliorations dans les performances. Des optimisations visant à réorganiser complètement les espaces de travail temporaires des bases sont à tenter, en préalable aux tests de performance du SI.

Pour mettre les systèmes et Oracle définitivement hors de cause et avancer dans la recherche de l'origine du problème, il convient de doter CP3E d'un environnement système/oracle similaire à celui d'Abidjan, et d'effectuer des comparaisons sur le profil à l'exécution de certains traitements Aster.

Il faut donc au préalable:

1. sauvegarder les bases de production et de paramétrage, et envoyer les images des bases à CP3E,
2. sélectionner des traitements lourds et des traitements en anomalies en définissant les procédures permettant de les tester par les deux parties.

	Exploitation

Echange des fichiers interfaces

Les procédures d'intégration et de rejet des fichiers interfaces se doivent d'être définies afin d'être automatisés au maximum, de manière à pouvoir faire face au flot continu de dépêches qui interviendront en période d'exploitation.

AsteroH

AsteroH est un outil qui facilite/automatise/centralise l'exploitation d'Aster en la mettant à la porté d'un comptable, au contraire des procédures fournies par SEMA qui demandent trop de manipulations et trop de connaissances informatiques. Ce programme permettrait de faire face au problème de compétences que nous risquons de rencontrer lors du déploiement d'Aster à l'intérieur de la Côte d'Ivoire.

Faute de ressources, le développement s'est actuellement arrêté au stade des tests et du deboguage. Il faudrait:

1. finaliser AsteroH,
2. le déployer sur les postes autonomes,
3. former les exploitants.

Impression

Il faut définir une politique d'impression/consultation des états Aster. Les états sont systématiquement imprimés et seule une petite partie est vérifié. On est en mesure de fournir les états au niveau des postes de travail des comptables ou au niveau de la messagerie. Reste à définir la stratégie.

Clients "légers"

Oracle peu s'interfacer à un serveur WEB et permettre à n'importe quel client "léger" d'accéder à l'application via un simple navigateur au lieu de passer par FORMS. La faisabilité de cette alternative peut être examinée par l'équipe DBA, car elle pourrait faciliter dans le futur, la maintenance et le déploiement des clients.