Ceci est une ancienne révision du document !
Dossier d’Architecture Technique
Suivi du document
Version | Date | Auteurs | Objet de la mise à jour |
---|---|---|---|
1.0 | 30/06/2021 | Nicolas MARCHAND | Création du document |
Définition du document
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.
Architecture technique des serveurs applicatifs
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
Architecture technique des postes clients
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.
Utilisateur avancé
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
Sur quels postes utiliser LoGeAs ?
On trouvera la spécification technique des postes sur lesquels LoGeAs peut fonctionner à la page “Sur quel ordinateur peut-on utiliser LoGeAs ?“
Architecture de supervision
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.
Robustesse
Dans le cadre de la certification NF552 (en cours) un audit de robustesse à été réalisé sur le progiciel en octobre 2021. En voici les grandes lignes et les points
Chapître | Constats | Actions demandées | Action menées |
---|---|---|---|
Exigences fonctionnelles Sécurité des données à caractères personnelles | Le développeur est une petit organisation qui assure également l'exploitation. Le référent Sécurité est le développeur (également gérant de la société). Il y a eu jusqu'à trois développeurs sur le projet. Même si cette désignation n'est pas explicite, le gérant est le référent de facto donc il semble que cela soit acceptable. Point d'attention sur la continuité d'activité, le gérant étant proche d'une passation de compétences nécessaire. Le serveur qui stocke les données appartient à la société du logiciel évalué. Montage en VM avec ProxMox et l'applicatif serveur tourne dans ProxMox. Le support documentaire du logiciel est disponible via un wiki. Le registre de traitement des données personnelles est établi, et le référent Sécurité est également DP. Il est connaisseur de la règlementation et a identifie la notion de criticité des données stockées, y compris celles qui ne seraient que courantes, étant donné la nature de certaines associations utilisatrices du logiciel (religion). Ainsi, la plupart des données courantes de ce logiciel est de facto considérée comme sensible et non juste courante. Les seules données chiffrées (hashées+salées) sont les mots de passe. Les données personnelles traitées par le logiciel ne sont pas chiffrées/anonymisées. | ||
Exigences fonctionnelles : Procédures de sécurité pour minimiser les risques | L'organisme évalué a géré le risque sécurité sur la partie Exploitation du logiciel, ainsi que sur la gestion des credentials des utilisateurs, via un PIA. Les traitements sont étayés via des fonctions de sécurité et leur nature technique. Le traitement des données des utilisateurs : les bases de données sont chiffrées AT REST (protection contre le scénario de vol de disque dans le centre d'hébergement mais pas de dump de BDD en live via l'interface exposée du logiciel). Pas d'interconnexions in/out avec d'autres produits. | Action organisme : préciser dans la documentation de traitement que la nature de certains de ses clients induit que les données personnelles soient courantes deviennent sensibles. | |
Authentification : Fonctionnement proposé par le logiciel | Les accès utilisateur sont protégés par mot de passe. Pas de captcha ni de nombre limité de tentatives. Les comptes utilisateur et modérateur ne sont pas protégés par double facteur. Le service général (monespace.logeas.fr) est mutualisé pour tous les clients. Les interfaces du logiciel de chaque client sont ensuite dédiées à chaque client. Les bases de chaque client sont montées sur des sous-serveurs Web. Il y a plusieurs services par client, chacun sur un port différent de la boucle locale derrière l'interface accessible en HTTP(S). Les mots de passe sont limités à 8 caractères minimum, renouvelés tous les 2 ans. | Action organisme : mettre en place un nombre de tentatives limitées sur les comptes utilisateur et modérateur + règles de construction des mots de passe avec minuscule, majuscule, nombres, et quelques caractères spéciaux et 10 caractères mini. | |
Authentification : Utilisé une bibliothèque public | La fonction de hachage est en PKBF2 avec salage des mots de passe dans la base mais il a été vu que le sel est fixe, donc deux mots de passe identiques de deux utilisateurs différents seront similaires. La fonction de hachage est en SHA256, via une bibliothéque propriétaire éditée par SynOps, en DELPHI (SynCrypto). La gateway d'authentification met en oeuvre un paramétrage de déconnexion après une durée d'utilisation (Peut-être 1h? à confirmer par l'organisme, à confirmer par l'organisme, voir à implémenter dans le code si besoin pour disposer de cette fonctionnalité de limitation du temps des sessions) | Action organisme : paramétrer un sel spécifique à chaque compte utilisateur (minimum), il ne doit pas être prédictible et accessible par les utilisateurs. Idéalement : une chaine aléatoire par compte utilisateur. Utiliser une méthode de génération aléatoire telle que celles dans les bibliothèques cryptographiques. | |
Authentification : Stockage des mots de passe | Stockage des clés de chiffrement des bases : actuellement une clé est utilisée de manière unique pour toutes les bases. | Action organisme : spécifier une clé unique (à partir d'un générateur élatoire) à chaque client pour le chiffrement des bases. Séparer la clé du code source, avec a minima un fichier différent à chaque client, pour le stockage de sa clé, droits d'accès restreints en lecture seule à ce fichier et seulement pour le compte ayant besoin d'accéder à cette clé pour déchiffrer la base. Voir (sur proposition de l'organisme) créer un serveur dédié pour les clés avec accès seulement interne par les autres serveurs. | |
Authentification : Dimension des clefs | Le choix des algorithmes constatés (SHA256) est en ligne avec le RGS de l'ANSSI. En revanche le mécanisme de génération des clés (pour le moment une seule clé stockée en dur dans le code source pour déchiffrer tous les bases) doit être amélioré. La fonction de chiffrement est AES-OFB avec une clé de 128 bits, ce qui est acceptable vis à vis des recommandations de l'ANSSI. | ||
Contrôle d'accès Fonctions de gestion de droit | Le logiciel permet de gérer une hiérarchies de structures auxquelles sont associées des groupes dans lesquels on assigne des utilisateurs. Le droit d'import de données permet d'ajouter des listes de membres (données de la base de chaque organisme/association qui est client du logiciel. Les droits possibles sont la consultation (authentifiée) des journaux, l'import de lignées pour la base des membres, la gestion des champs personnalisés Le compte “par défaut” de chaque base est initialisé manuellement par l'organisme, (le login est donc unique par base puisqu'il correspond au mail paramétré par l'organisme et communiqué à l'établissement du contrat par le client). La création de compte se fait via un lien envoyé à l'adresse mail du compte en cours de création, avec une clé d'activation acceptable. En revanche la durée de vie minimale du lien d'activation n'est pas spécifiée. Il n'y a par conséquent pas de mots de passe par défaut. Il n'y a pas non plus de compte par défaut dans la mesure où l'assistance de l'organisme paramètre des comptes spécifiques nominatifs via la même procédure que celle permettant aux utilisateurs de créer leurs comptes. Bon niveau de maturité organisationnel : l'organisme possède une charte informatique qu'elle a fait signer à ses membres, et qui spécifie les règles de gestion des mots de passe. La gestion de suppression des comptes et données personnelles se fait via une intervention manuelle de l'assistance (contrairement aux bases de membres où dans ce cas les administrateurs peuvent facilement supprimer les données nécessaires) | Action de l'organisme : ajouter un timeout de durée de vie des liens d'activation, et dans le cas d'une sauvegarde de mot de passe précédent, une durée de vie minimale de mot de passe (par exemple 1 journée). | |
Contrôle d'accès Journalisation des tentatives d'accès | Le logiciel possède une fonctionnalité de journalisation de l'activité, qui est protégée en intégrité et authenticité via un chainage des signatures de chaque ligne du journal. Mécanisme de signature des journaux : la fonction passe par une signature RSA sans padding acceptable (PKCS#1 2.1 OAEP ou PSS) L'accès aux journaux est seulement permis en lecture et via un droit paramétrable par un administrateur. Pas d'accès en lecture possible sur les journaux depuis les interfaces utilisateur/administrateur | Action de l'organisme : mettre à jour la fonction de signature soit en ajoutant un padding acceptable à RSA, soit en utilisant un autre mécanisme permettant d'assurer authenticité/intégrité (ECDSA / empreinte à clé HMAC-SHA256, …). NB : attention si HMAC SHA256, le même secret est utilisé pour signer et vérifier l'authenticité donc attention à ne pas compromettre le secret dans ce cas-là (aucun problème si biclé RSA/ECDSA puisque seule la partie publique est publiée). Action de l'organisme : Journalisation des tentatives de connexion (via l'interface de connexion classique ou via le lien envoyé par mail → à mettre dans la piste d'audit) |
Signature des fichiers
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)
Signature des enregistrements dans la base
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
Signature des enregistrements de la table "Saisie"
Signature des enregistrements de la table "Ecriture"
Signature des enregistrements de la table "PisteAudit"
Formatage de la signature
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.
Correspondance des champs entre les labels FIDELE et le format historique de LoGeAs
Champ | Label FIDELE | Champ LoGeAs | Ajout 9.5 |
---|---|---|---|
Identifiant de l'événement | JET-NID | ID | |
Code de l'événement | JET-EVT-NUM | Code | |
Intitulé du code / Description de l'événement | JET-EVT-LIB | Intitule | |
Code opérateur | JET-OPE-NID | CreatedUserSUID | X |
Horodatage GDH | JET-GDH | GDHDate | X |
Information complémentaire contextuelle à l'événement | JET-INF | Data | |
Signature Electronique | JET-TAG-SIG | Signature | X |
Type d'action enregistrée sur la piste d'audit | Action | ||
Identifiant du lot de données pour la piste d'audit | Batchid | ||
Date de création de l'enregistrement pour la piste d'audit | CreatedDate | ||
Code opérateur sous forme de son adresse courriel | CreatedUser | ||
Description de l'enregistrement pour la piste d'audit | Description | ||
Exercice de référence de l'enregistrement | Exercice | ||
Indique la table et l'enregistrement concernés | Identifiant | ||
Blocage de l'information par exemple suite à une demande RGPD (à venir) | IsDataConsultable | ||
Interne à mORMot | Version |
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.
Signature des enregistrements de la table "Famille"
Signature des enregistrements de la table "Personne"
Pistes d'audit et JET
Détail de la signification des codes du journal des événements
Fonctions "normalisées"
Référence : Journal des Evénements Techniques (JET) / RECOMMANDATIONS INFOCERT 2018 - FORMAT FIDELE INTEROPERABILITE [R19] - Edition Edition 4 du 24 juillet 2020
En gras les codes utilisés par LoGeAs Web
Code | Descriptif Définition | Sous code LoGeAs | Complément |
---|---|---|---|
10 | Changement du mode de gestion de la séquence continue | ||
20 | Archivage fiscal de période | ||
30 | Archivage fiscal d'année ou d'exercice | “a” demande d'une archive fiscale faite par un utilisateur (mais non encore réalisé) “b” archive fiscale enregistrée dans MonEspace.fr “c” erreur lors de la réalisation d'une archive fiscale | TPAExportFiscal |
40 | Arrêt du terminal, déconnexion, fermeture de session | “a” déconnexion depuis le client lourd “b” déconnexion sur le serveur de la base “c” déconnexion de l'interface client léger | TPAUserLogout |
50 | Clôture de période (Jour/Mois) | TPACloturePeriode | |
60 | Clôture annuelle ou d’exercice | TPAClotureExercice | |
70 | Début de mode dégradé (hors connexion, …) | ||
80 | Démarrage du terminal, connexion, ouverture de session | “a” connexion depuis le client lourd “b” connexion sur le serveur de la base “c” connexion de l'interface client léger | TPAUserLogin |
90 | Détection d’un défaut d’intégrité dans les données sécurisées ou dans une archive fiscale Remarque : Après une détection la signature est corrigé (sauf dans la piste d'audit du fait du chainage) | “a” version de signature incorrect “b” signature incorrect | TPADataDefautIntegrite |
95 | Détection d'une rupture de la séquence continue | ||
100 | Début de l'exécution d'une fonction spéciale | Fonctions uniquement accessibles par l'assistance | TPADebutFonctionSpeciale |
105 | Fin de l'exécution d'une fonction spéciale | TPAFinFonctionSpeciale | |
110 | Exportation de données | TPADataExport | |
120 | Fin de mode dégradé | ||
123 | Renvoi forcé de données vers le système central | ||
125 | Centralisation des données après la fin du mode dégradé | ||
126 | Rajout d’un point de vente ou d’un poste utilisateur | ||
127 | Suppression d’un point de vente ou d’un poste utilisateur | ||
130 | Habilitation d’utilisateur/Gestion des droits | “a” changement des droits “b” changement de mot de passe “c” ajout d'un utilisateur à la base “d” suppression d'un utilisateur de la base | TPAUserServeur |
140 | Importation de données externes | TPADataImport | |
150 | Imprimante indisponible | ||
155 | Duplicata d’une note | ||
160 | Enregistrement des écritures en comptabilité | ||
170 | Traitement de fond de caisse | ||
180 | Génération d'un fichier d'exportation des écritures comptables | “a” Export au format Koala | TPADataExportCompta |
190 | Annulation de pièce justificative ticket | ||
200 | Purge des données | ||
205 | Purge Partielle du JET | ||
210 | Reprise de données d’autres logiciels suite à changement de systèmes | ||
220 | Restauration d’une base de données | TPARestaure | |
230 | Sauvegarde d’une base de données | “a” demande de sauvegarde faite par un utilisateur (mais non encore réalisé) “b” sauvegarde enregistrée dans MonEspace.fr “c” erreur lors d'une sauvegarde | TPASauvegarde |
240 | Suivi des interventions de maintenance | ||
250 | Installation d’une nouvelle version majeure du logiciel | A partir de la version 9.4 “rio”, le client lourd est passé en version portable, sous forme d'un seul fichier. Cet événement ne peut donc être pisté que lors de mise à jour à partir d'une version installée D'autre part la base est accessible depuis de nombreux postes … | |
255 | Installation d’une nouvelle version mineure du logiciel | ||
260 | Initialisation des données | TPAInitBase | |
270 | Evolution de paramètre de conformité aux règles | ||
280 | Début/fin d’opération de contrôle fiscal | ||
290 | Echange avec un expert-comptable (envoi du FEC ou du Z de caisse) | ||
295 | Transfert de fichier à la demande de l'administration | ||
300 | Activation de paramètre autorisé et documenté | ||
320 | Abandon d’une opération de vente (transaction) commerciale non encore enregistrée | ||
323 | Annulation d’une ligne d’article | ||
324 | Abandon d'une note validée | ||
325 | Annulation(s) d’article(s) après commande | ||
326 | Retour(s) d'article(s) après une émission d’une note | ||
327 | Passage en note « offerte » | ||
328 | Passage d’article en « offert » | ||
329 | Non édition d’une note [1] | ||
330 | Initialisation de la clôture de fin de période | ||
400 | Changement de la durée de l’exercice | Accessible uniquement à l'assistance | TPAChangeDureeExercice |
410 | Changement de données affectant l’identification de l’assujetti ou du mandataire | ||
420 | Changement du mode de règlement, après émission du ticket | ||
430 | Changement de table (en restauration) affectée à une note | ||
440 | Transfert des archives fiscales sur support externe |
Fonctions "spécifiques" à LoGeAs
900 à 999 Fonctions éditeur L’événement concerne le suivi des codes libres définis par l’éditeur
Code | Descriptif Définition |
---|---|
900 | Code pour pister l’accès à la piste d'audit Remarque : avant 9.4.5 cet accès était pisté en 10 (ancienne norme..) |
901 | Modification des plans comptables |
999 | Autres pistages détaillés dans les compléments |
Fichier des Ecritures Comptables
On trouvera à la page Livre blanc sur LoGeAs et le FEC les informations liées au FEC.
Sauvegarde d'une base LoGeAs
On trouvera à la page Réaliser une Sauvegarde ou une Archive Fiscale de la documentation utilisateur les informations sur les sauvegardes.
Archive fiscale
On trouvera à la page qu_est_ce_que_l_archive_fiscale les informations concernant l'archive fiscale produite par LoGeAs.
Gestion des séquences continues comptables dans LoGeAs
Rappel du fonctionnement de LoGeAs
LoGeAs étant destiné à des petites et moyennes structures, et la plupart du temps utilisé par des non-comptables, il fonctionne en mode “brouillard permanent”. L'utilisateur réalise des saisies qui sont transformées par un algorithme interne en écritures comptables en mode brouillard. Ce n'est qu'au moment de la clôture comptable que ces écritures sont réellement ordonnées dans une séquence continue chronologique. Il est à noter que nos utilisateurs, même si le logiciel permet un clôture mensuelle, n'utilisent que la clôture annuelle.
Gestion des séquences continues sur les saisies
Toutes les saisies sont regroupées dans une même table "Saisie".
Cette table contient un identifiant unique de séquence nommé “ID”:
- il est non modifiable
- il est associé à une double chronologie sur la date de création
- “DateCreation”, géré en haut niveau
- “Created”, géré au plus bas niveau directement par l'ORM
- une ligne ne peut pas être effacée de la table, seul son Status peut être changé :
- Brouillard : Saisie temporaire mais prise en compte
- Supprimée : Saisie supprimée
- Approuvée : Saisie Validée (au sens comptable du terme)
- Clôturée : Saisie clôturée
A noter que cette séquences chronologique est inter-exercices et n'est valide que pour les saisies faites en version WEB (champ created)
Gestion des séquences continues sur les écritures
Toutes les écritures sont regroupées dans une même table "Ecriture".
Cette table contient un identifiant unique nommé “ID”, mais contrairement à la table de saisies, ce numéro peut être remis en cause lors de chaque modification de la saisie dont il est issu. Il ne faut donc pas le considérer comme un numéro de séquence.
Gestion des séquences continues lors de la "clôture comptable"
La réelle séquence continue chronologique est faite lors de la clôture d'une période comptable. A ce moment-là les écritures sont numérotées dans le champ “NumeroCloture” dans l'ordre “DateOperation”, “ID”. La séquence est sur l'exercice (à compter de la version 9.2.5). Remarque : bien évidemment cette série étant liée à la clôture, elle n'est pas modifiable par la suite.
Gestion des séquences continues lors de l’émission d'un "FEC"
Lors de l’émission d'un FEC, celui-ci a sa propre séquence continue au travers du champ “NumeroFec”, ce choix a été fait car même si normalement l’émission d'un FEC est réservé à une période clôturée, il est possible de d'utiliser le FEC comme échange de données entre logiciels.
Gestion des séquences continues sur les numéros de pièces des saisies
La marque NF Logiciel fait l'obligation d'associer chaque saisie à un numéro de pièce ; ce critère est en place depuis la sortie de la version Web (bien que des imports puissent ne pas en posséder). Après échange, le système automatique retenu est celui de la numérotation mensuelle par exercice. L'utilisateur étant libre de modifier la valeur automatique s'il remplace la valeur automatique par une autre. Pour proposer un système plus systématique et plus conforme, les principes sont les suivants :
- à chaque saisie doit correspondre un numéro de pièce justificative, celle-ci pouvant être une facture, un bordereau de remise en banque ou simplement le relevé bancaire.
- une multi-lignes sera considérée comme une seule saisie, donc associée à une seule pièce (mais rien n'empêche que cette pièce soit constituée de plusieurs sous-pièces)
- les pièces sont numérotées selon la norme suivante Paa-x où
- P indique pièce ou paiement
- aa est le numéro du mois de la date de la pièce justificative (actuellement date d'opération) écrite sur deux digits
- x est le numéro de rang dans le mois
cette numérotation est générée automatiquement dans tous les écrans
- les écriture liées à des factures émises seront numérotées selon la norme Fxxxx où
- F indique facture
- xxxx est le numéro de rang des factures depuis la création de la structure sur 4 digits