Différences

Ci-dessous, les différences entre deux révisions de la page.

--- certif:dat [2021/11/24 16:15]
nicolas [Robustesse]
+++ certif:dat [2021/11/26 14:44] (Version actuelle)
nicolas [Suivi du document]
@@ Ligne 2: / Ligne 2: @@
 ===== Suivi du document =====
 ^Version^Date^Auteurs^Objet de la mise à jour^
+|1.1|Nov 2021|Nicolas MARCHAND|Déplacement des chapitres Jet, FEC, Sauvegarde, Archives fiscales, RGPD vers le DCF|
 |1.0|30/06/2021|Nicolas MARCHAND|Création du document|
 ===== Définition du document =====
@@ Ligne 45: / Ligne 46: @@
 ===== 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
+On trouvera les grandes lignes et les points d'évolution ainsi que les actions mené à la page [[certif:dat:robustesse2021]]
-^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 =====
@@ Ligne 110: / Ligne 99: @@
 |01|A partir de la version 10.0|{{:certif:signaturetablepersonne.jpg?200|}}|
-===== 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 ===
-à 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 [[clientlourd:administration:fec]] les informations liées au FEC.
-===== Sauvegarde d'une base LoGeAs =====
-On trouvera à la page [[clientlourd:administration:transversal:sauvegarde]] de la documentation utilisateur les informations sur les sauvegardes.
-===== Archive fiscale =====
-On trouvera à la page [[clientlourd:compta:transversal:archivefiscal#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 **[[:certif:technique:saisie|"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 **[[:certif:technique:ecriture|"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

Fichier	Comptabilité	Autres	Administration	Certification