Objectif

Décrit 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 ; architecture détaillée du système (schéma avec nature des flux et les différents composants du système). Ce dossier doit couvrir tous les traitements effectués sur les données à sécuriser, notamment leur transport, sauvegarde, export, impression et affichage.

Préambule

Ouvretaferme est un logiciel ouvert dont le code source est disponible sur Github sur le présent repository : https://github.com/vingtcent123/ouvretaferme

Processus de développement

Table des matières

1. Exigence 3 : Données à enregistrer
2. Exigence 4 : Corrections
3. Exigence 5 : Mode démo
4. Exigence 6 : Clôture TODO
5. Exigence 7 : Données cumulatives et récapitulatives TODO
6. Exigence 8 : Inaltérabilité des données
7. Exigence 9 : Sécurisation des justificatifs TODO
8. Exigence 10 : Archivage des données TODO
9. Exigence 11 : Périodicité d'archivage TODO
10. Exigence 12 : Intégrité des archives TODO
11. Exigences 13 & 14 : Purge et Purge partielle
12. Exigence 15 : Traçabilité des opérations TODO
13. Exigence 16 : Conservation des données TODO
14. Exigence 17 : Conservation des archives TODO
15. Exigence 18 : Système centralisateur
16. Exigence 19 : Accès de l'administration fiscale aux données TODO
17. Exigence 20 : Identification du périmètre fiscal TODO
18. Exigence 21 : Identification des versions majeures et mineures TODO

Le développement du logiciel

Gestion du code source

Nomenclature des versions

Pas de sous-traitance

Identification et traçabilité de la distribution

• comment on assure la traçabilité du système distribué
• comment on fait une mise à jour / nouvelle installation
• comment on s’assure que la dernière version majeure est certifiée et dispo pour déploiement
• comment on s’assure d’avoir notifié les clients finaux de la dispo de la dernière version majeure certifiée

Communication avec les clients (docs dispo 3 ans après la date de fin de distribution de chaque version)

• documents nécessaires au bon fonctionnement du système d’encaissement (mode d’emploi etc.)
• procédure de support / formation
• engagement de responsabilité des clients vis à vis de la loi des finances pour 2016 (obligation e réaliser les clôtures, conservation des données etc.)
• description du moyen d’accès aux données d’encaissement par l’administration finale + la documentation + comment vérifier l’intégrité des données
• le certificat

Exigence 3 : Données à enregistrer

Architecture

• Les données sont enregistrées sur le disque dur (dans un serveur MySQL). Une interruption d'électricité ne provoquera pas de perte de données.
• Le système d'encaissement ne permet pas l'émission de justificatifs.

Données de vente

Le système d'encaissement enregistre les données suivantes :

• Un identifiant unique de vente (Sale::$id)
• Un identifiant unique de ferme utilisant le système (Sale::$farm)
• La date et l'heure de la création de la vente (Sale::$createdAt)
• Le montant TTC de la transaction (Sale::$priceIncludingVat)
• Le mode de règlement (Sale::$paymentMethod), si plusieurs modes de règlement sont employés, ils sont listés dans la table Payment, référencés par l'identifiant de la vente
• La date de paiement et de la clôture de la vente (Sale::$statusDeliveredAt)

Aucun numéro de TPV n'est enregistré car non applicable.

Détails d'une vente : les produits

Les produits sont listés dans la table SellingItem. Pour chaque ligne de produit, sont enregistrées les données suivantes :

• Le libellé (SellingItem::$name)
• La quantité (SellingItem::$number)
• Le prix unitaire (SellingItem::$unitPrice)
• Le total HT de la ligne (SellingItem::$priceExcludingVat)
• Le taux de TVA associé (SellingItem::$vatRate)

Traçabilité des opérations : l'historique

Les opérations sur la vente sont tracées dans la table History. Les événements qui sont tracés sont :

• Pour la vente : Création / Annulation / Livraison / Prête à préparer / Prête à livrer / Livraison annulée / En brouillon
• Pour le paiement : Ouvert / En échec / Validé

Exigence 4 : Corrections

• Dans le système d'encaissement, les corrections (modifications / annulations) sont possibles uniquement si la vente concernée n'est pas clôturée.

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/107

Exigence 5 : Mode démo

Architecture

• L'environnement de démonstration se trouve sur une base de données séparée de l'environnement de production
• Les systèmes d'enregistrement et de sécurité employés sur l'environnement de démonstration sont les mêmes qu'en environnement de production.
• Il n'y a aucun système d'archivage : l'environnement est réinitialisé tous les jours avec des données factices et anonymisées et à jour de la dernière version du logiciel.

Documentation / Information

• Tous les fichiers PDF générés dans l'environnement de démonstration présentent un filigrane "Démo" :

• Le logiciel de caisse présente à l'utilisateur qu'il se trouve sur un environnement de démonstration :

Exigence 6 : Clôture

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/109

Exigence 7 : Données cumulatives et récapitulatives

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/110

Vérifier que l'intégrité et l’authenticité des données cumulatives et récapitulatives repose sur un mécanisme robuste.

Exigence 8 : Inaltérabilité des données

• Différents niveaux de sécurité sont mis en place sur le système d'encaissement :
  • Au niveau utilisateur : Un droit en écriture sur la ferme pour un utilisateur authentifié
  • Au niveau des ventes : Une vente modifiable (brouillon, en préparation, non réglée et non clôturée)
• Techniquement, ces vérifications sont faites sur l'interface utilisateur ET au niveau serveur lors de toute tentative d'écriture.
• Les utilisateurs n'ont aucun moyen de restaurer une version antérieure du système.
• L'accès en écriture est donc parfaitement maîtrisé.

Exigence 9 : Sécurisation des justificatifs

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/112

Exigence 10 : Archivage des données

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/113

Vérifier que l’intégrité et l’authenticité des données de la date de création de l’archive est protégée par un mécanisme robuste, tel que décrit à l’exigence n°8.

Exigence 11 : Périodicité d’archivage

cf. 10

Exigence 12 : Intégrité des archives

Documenter la non-altérabilité des archives (stockage etc.)

Exigence 13 : Purge / Exigence 14 : Purge partielle

• Aucune purge de données du système d'encaissement n'est effectuée
• Ces deux exigences ne s'appliquent donc pas sur le système d'encaissement d'Ouvretaferme.

Décrire ce qui est fait (ou non) ici : https://github.com/vingtcent123/ouvretaferme/issues/114

Exigence 15 : Traçabilité des opérations

• Aucune opération de purge n'est possible sur Ouvretaferme.
• Aucune opération de restauration des données n'est possible sur Ouvretaferme.
• TODO : tracer les archivages Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/115

Exigence 16 : Conservation des données

Dans le cas où la conservation des données est assurée par le système et non par les archives, vérifier l'aptitude du système d‘encaissement à conserver les données d’encaissement pendant une durée de 6 ans. Vérifier que cette aptitude repose, par exemple, sur l'utilisation d'un mécanisme assurant le niveau de disponibilité adéquat au niveau du système de stockage (RAID-1 matériel ou logiciel) ou au niveau du système de fichiers (redondance des fichiers sur plusieurs unités de stockage, journalisation et capacité d'autoréparation, etc.). Vérifier que la configuration des mécanismes mis en œuvre permet de s’assurer la bonne conservation et disponibilité des données d’encaissement pendant 7 ans.

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/116

Exigence 17 : Conservation des archives

cf. 16

Exigence 18 : Système centralisateur

Ouvretaferme est un système avec une architecture client-serveur où l'interface client n'est qu'une interface graphique : il n'y a pas de stockage temporaire des données. Le présent système d'encaissement n'est donc pas considéré comme un système centralisateur, l'utilisation de l'interface sans connexion étant impossible.

Cette exigence n'est donc pas applicable.

Exigence 19 : Accès de l’administration fiscale aux données

• Créer un manuel utilisateur de l’administration fiscale et la procédure pour récupérer les données

Décrire ce qui sera fait ici : https://github.com/vingtcent123/ouvretaferme/issues/118

Exigence 20 : Identification du périmètre fiscal

La définition exhaustive du périmètre fiscal peut prendre la forme d’un tableau de corrélation entre les 21 exigences du présent référentiel et la liste tous les éléments du code source impliqués. Sont par exemple inclus dans le périmètre fiscal toutes les fonctions d’enregistrement des données d’encaissement ; de correction/annulation d’une transaction ; les fonctions liées à l’enregistrement et à la sécurisation des données générées par le mode école ; les fonctions de clôture (journalière, mensuelle et annuelle) ; de calcul, d’enregistrement et de sécurisation des données cumulatives et récapitulatives ; de sécurisation et d’inaltérabilité des données d’encaissement ; de sécurisation des justificatifs ; d’archivage ; de sécurisation des archives ; de purge ; de traçabilité des opérations (archivage, purges, clôtures) ; de conservation des données et des archives ; d’accès de l’administration fiscale et de toute autre fonctionnalité/module/pilote/librairie impactant le respect des exigences du présent référentiel. Il est possible de définir le périmètre fiscal comme étant l’entièreté du code source du système d’encaissement

Exigence 21 : Identification des versions majeures et mineures

Décrire ce qui est fait ici : https://github.com/vingtcent123/ouvretaferme/issues/119

Vérifier que le mécanisme permettant de générer l’identification du système via les numéros de version majeure et mineure a intégré toutes les parties du système concernées et que celui-ci est fiable, c’est-à-dire qu’il suit les critères de l’annexe B1 du RGS, ou, a minima, est résistant à une attaque par collision (c’est-à-dire qu’il n’est pas possible de forger deux sources distinctes produisant la même empreinte). Vérifier que les mesures prises pour éviter la falsification sont appropriées par rapport à l'état de l'art. Vérifier par échantillonnage à partir du journal des versions (« changelog ») ou au différentiel en termes de code entre deux versions que les modifications mineures n’ont pas d’impact sur le respect des exigences du présent référentiel. Vérifier qu’une empreinte réalisée par l’évaluateur sur le code certifié produit la même empreinte que celle délivrée par l’éditeur.