Dossier d’Architecture Technique

L'objet de ce document est de d'écrire en profondeur l’implémentation technique de la solution : technologies, algorithmes (notamment de signature et hashs utilisés pour la sécurisation des données), frameworks, protocoles utilisés et architecture détaillée du système (avec nature des flux entre les différents composants du système), modalités de sauvegarde.

Physiquement le serveur est situé dans un datacenter toulousain, dans une baie louée par la société Prosoluce qui est l'un de nos partenaires privilégiés. Il s'agit d'une VPS, gérée sous proxmox qui simule “windows server 2019” 2 cœurs.
L'ensemble des informations est disponible sur notre intranet.
Pour des raisons de sécurité, le contenu détaillé n'est disponible que sur demande écrite justifiée.
Le schéma générique du serveur est Cette image est dupliquée sur la page suivante

Pour répondre au mieux aux contraintes des installations sur les postes professionnels et sur les systèmes non gérés par LoGeAs (comme Linux ou Mac), nous avons choisi de livrer la nouvelle version sous la forme d’un simple fichier (compressé ou non). Les fichiers secondaires utilisés pour le paramétrage sont maintenant stockés en base de données et téléchargés à la demande. Ceci permettra aussi de les faire évoluer sans avoir besoin de faire une nouvelle version. C’est en particulier le cas des états. Il est donc possible de mettre l’exécutable de LoGeAs sur une clef USB 3 et de le transporter d’ordinateur en ordinateur.

Lors du lancement, à côté de l’exécutable LoGeAs, est créé un dossier « LoGeAsUserData » dans lequel sont stockés :

• les informations de connexion (qui peuvent être régénérées facilement si besoin)
• des dossiers temporaires à LoGeAs, vidés régulièrement automatiquement
• les états « personnalisés » que vous ne partagez pas avec vos collègues. Il est alors de votre responsabilité d’en faire des sauvegardes.
• des sauvegardes des états modifiés

On trouvera la spécification technique des postes sur lesquels LoGeAs peut fonctionner à la page “Sur quel ordinateur peut-on utiliser LoGeAs ?“

Nous aborderons ici le thème de la supervision et son intégration dans le processus de gestion des incidents au sens ITIL du terme. Commençons tout d’abord par rappeler ce qu’est un incident dans un contexte ITIL. Un incident est une interruption inattendue d'un service. Il perturbe les opérations normales et affecte donc la productivité de l'utilisateur final. Un incident peut être provoqué par le mauvais fonctionnement d’un actif ou par une panne de réseau, en exemple : l’indisponibilité d’une imprimante.

Le lien entre la supervision et la gestion des incidents s’appuie particulièrement sur deux points :

• La génération automatique d’incident pour les alertes critiques fonctionnelles remontées par l’outil de supervision.
• La liaison directe avec la base de connaissance de la gestion des incidents.

Ainsi, la supervision permet de :

• Prévenir certains incidents par des systèmes de suivi d’indicateurs clefs et des alertes préventives adaptées.
• Ordonnancer les incidents selon une classification adaptée aux services ou aux besoins de l’entreprise.
• Optimiser la détection des incidents par un système d’alertes optimisées.
• Optimiser la résolution des incidents par la mise en place de procédure optimisées et en amélioration continue (mise à jour régulière de la base de connaissance afin de la faire correspondre aux nouvelles problématiques rencontrées).

Les bilans fournis par un outil de supervision sur l’état et la disponibilité des services permettent également de valider ou d’invalider une CNS (Contrats de Niveau de Service) ou SLA pour reprendre un terme ITIL (Service Level Agreement).

Le choix de l’entreprise s’est finalement porté sur Zabbix. En effet, outre la possibilité d’intégrer Zabbix à notre logiciel de support de façon simple, il s’avère que Zabbix dispose d’un template permettant de superviser les sauvegardes gérées par le logiciel Ipérius Backup, nous offrant ainsi la possibilité de nous alerter par sms, et de créer un ticket de support sur OTRS lorsqu’une sauvegarde est en statut d’échec ou terminée avec des erreurs, en sus des courriels. De plus, la possibilité de créer et de customiser simplement les déclencheurs et donc d’affiner la supervision des services déterminés comme étant critique est un réel avantage.

Dans le cadre de la certification NF552 un audit de robustesse à été réalisé sur le progiciel en octobre 2021. On trouvera les grandes lignes et les points d'évolution ainsi que les actions mené à la page Constat de l'audit de robustesse 2021

On trouvera sur le page Partie cryptologie de LoGeAs (chaine aléatoire, cryptage, signature...) l'ensemble des informations liées à la signature des fichiers dans LoGeAs (FEC, Sauvegarde, Archive fiscale)

On pourra ce reporter à la page Partie cryptologie de LoGeAs (chaine aléatoire, cryptage, signature...) pour avoir des informations sur la technique utilisée par LoGeAs pour signer les fichiers et les enregistrements

A partir de la version 9.5, la structure de la piste d'audit évolue pour se mettre en conformité avec la nouvelle version 4.0 du du R19.

N°	Version initiale du logiciel	Schéma explicatif	Commentaires
01	Non référencé (buggée)
02	A partir de la version 9.5		la structure de la piste d'audit évolue pour se mettre en conformité avec la nouvelle version 4.0 du du R19 La signature de chaque enregistrement est constituée avec la suite des champs : * “ID” : Identifiant de l'événement * “Code” : Code de l'événement * “Intitule” : Intitulé du code / Description de l'événement * “GDHDate” : Horodatage GDH (sous la forme AAAAMMJJHHMMSS) * “CreatedUserSUID” : Code opérateur * “Champ vide” correspondant au code de caisse (non utilisé dans LoGeAs) * “N” s'il existe une signature sur l'enregistrement précédent “O” sinon * “Signature de l'enregistrement précédent”
03	A partir de la version 10.0

Bien que complétée par un texte en clair, chaque ligne d'entrée dans ce journal (JET) est taguée, conformément à la NF203, par un code dont vous trouverez la signification ci-dessus.