DAT DOC DEPOT

• Historique
• Description générale
  • Présentation générale
  • Niveaux de services attendus
• Urbanisme, architecture fonctionnelle et applicative
  • Urbanisme
  • Architecture fonctionnelle et applicative
  • Flux et traitement applicatifs
  • Sécurité applicative
• Architecture technique
  • Choix généraux d'architecture technique
  • Description des données
  • Infrastructure technique
  • Echanges avec SI partenaires
  • Evolution de la solution jusqu'à la cible

---

Historique

Version	Description
2.0	Version initiale du nouveau modèle

---

[doc de reference](D:\Profiles\fgontier\Documents\DPI\DAT CASTOR V2.0 - COMPOSANT M01 - V0.10.doc)

notes d'architecture

---

Description générale

Présentation générale

Contexte et enjeux

Contexte d'émergence

Doc-Depot est un coffre-fort numérique destinée aux personnes en situation de précarité. Cela consiste en une solution web pour offrir un hébergement des documents des personnes faisant partie de population en difficulté.

La solution Doc-Depot est déployée grâce à l'action de l'association ADILEOS.

L'hébergement en production a été assurée jusqu'en 2016 par OVH. Depuis 2017, l'hébergement des services principaux de la solution devait être assuré par la direction des services d'informations de la société SopraSteria. Cependant, il a été décidé de ne pas migrer les services existants dessus pour éviter de mettre en péril le déploiement actuel de la solution dans les nouvelles structures. Cet environnement devra accueillir la nouvelle version de Doc-Depot. Cette fondation a assuré un soutien aussi financier que matériel au développement de la solution Doc-Depot.

Enjeux

La solution Doc-Depot est déployée uniquement sur l'environnement de production cité. Cependant, la solution a pour vocation d'être déployée sur n'importe quelle solution d'hébergement supportant la technologie PHP.

La solution Doc-Depot fait l'objet d'une expérimentation à l'échelle du territoire français commanditée par le ministère des affaires sociles et de la santé.

Enjeux de perenisation

Passage en open source

La solution fait l'objet d'un passage à une licence open-source. Ce passage est motivé par plusieurs raisons :

• la solution a été développée par un petit noyau de personnes. Les besoins en développement se font croissant et demandent une forte réactivité. Un passage en open-source facilitera le recrutement d'un plus grand nombre de développeurs.
• l'état du code actuel ne permet pas un déploiement à grande échelle, il doit subir une refonte profonde pour permettre un déploiement modulaire. Cette refonte nécessite un recrutement massif et rapide.
• un passage en licence open-source permettrait à la fois la pérennité du projet et son amélioration par l'apport de la communauté.

fonctionnalités annexes

La solution s'adresse à un public non averti avec les outils de communication des projets à code ouvert : la solution proposera des fonctionnalités où l'utilisateur pourra saisir des propositions d'évolutions via un formulaire. Le systèmde se chargera de prévenir ces personnes de l'activation ou non de la focntionnalité demandée.

Enjeux liés au stockage

Un des objectifs de la solution est de s'appuyer sur des solutions robustes et populaires de stockage de documents, un interfaçage avec ce type de services sera mis en place. Cet interfaçage permettrait de soulager les gestes d'exploitations liés à la sauvegarde massive de documents.

La solution proposera aussi sa propre solution de stockage de documents.

Extrait du communiqué de presse

Communiqué de presse le 03/03/2016

Cette expérimentation sera pilotée par la Direction Générale de la Cohésion Sociale (DGCS) en partenariat avec l’Union nationale des centres communaux d’action sociale (UNCCAS). Elle sera mise en oeuvre au cours de l’année 2016 pour une période de 6 mois et fera l’objet d’une évaluation des situations réelles d’usage (par les travailleurs sociaux et les personnes concernées) portant sur :

• l’utilité d’un « coffre-fort » numérique pour l’accès aux droits des personnes concernées,
• les besoins d’accompagnement des personnes dans l’autonomie d’usage aussi de ce type d’outils,
• les besoins de formation des travailleurs sociaux en vue dans l’accompagnement des personnes.

L’expérimentation débouchera sur l’élaboration de recommandations destinées à favoriser le déploiement de solutions de coffres-fort numériques adaptés à la prise en compte des besoins des personnes en situation de précarité.

Dans cette perspective, la DGCS lance un appel à candidatures auprès des fournisseurs de solutions techniques de coffre-fort numérique, qui devront, pour être retenus, répondre aux caractéristiques suivantes :

• l’usage du coffre-fort devra être gratuit pour l’usager et pour les collectivités pendant la durée de l’expérimentation ;
• le coffre-fort devra permettre de stocker ET de partager avec des tiers (sous réserve de l’accord de la personne) des pièces justificatives nécessaires aux démarches administratives,
• le coffre-fort devra offrir des garanties de sécurisation des données à caractère personnel.

Enjeux de la solution

La licence adoptée protégeant de fait d'une utilisation commerciale, de fait, il n'y a pas d'objets commerciaux.

L'ensemble des services de la solution n'est pas figé, en effet, différents services pourront se greffer à la solution doc-dépot : des services équivalent ont été développés à l'initiatives d'organismes différents, nous pouvons cités :

• la solution de coffre-fort du CCAS de la ville de Nice ....

La solution actuelle proposera dans une perspective à plus ou moins long terme, un ensemble d'API de services qui pourront être utilisés par ces autres solutions. Une inscription sera faite par un administrateur afin d'activer l'accès à ces services. Les solutions extérieures seront considérés comme des organismes de confiance.

Contraintes majeures

La solution s'adresse potentiellement à tout le monde. Cependant, elle ne sera diffusée qu'auprès d'un public ciblé : les différentes associations qui utiliseront la solution inscrieront les personnes qui le souhaitent.

La volumétrie cible n'impose pas de contraintes majeures. Cependant, la solution hébergent des données très personnelles de natures privées et administratives.

Les solution de stockage et de chiffrement se doivent de respecter ces contraintes.

De même, l'accès par les personnes liées à l'exploitation de la personne ne doit pas permettre un déchiffrage des documents persistés.

TODO: vérrifier si toutes les conditions sont réunies.

Contraintes d'exploitation

La solution a pour contraintes majeures une haute disponibilité en termes d'accessibilité.

Cette contrainte est dûe au déploiement à l'échelle du territoire français qui connait plusieurs fuseux horaires (DOM-TOM).

Contraintes réglementaires ou légales

ODO: se renseigner sur exigences CNIL

Contraintes de sécurité

Les clés de cryptage sont symétriques elle doivent faire l'objet d'une protection particulièree car elle peut être utilisée pour consulter des documents personnels.

Idéalement, cette clé ne devrait pas être accédée par les exploitants qui réalisent des taches courantes.

De plus, le moindre changement de clé implique un décrypage avec l'ancienne clé pour être recrypté avec la nouvelle.

Evolution souhaitable

Un système externe de cryptage serait souhaitable afin d'hébergement sur la même machine les moyens de cryptage et décryptage.

Contraintes réalisés par l'application

Ces fonctionnalités seront assurées par l'application elle-même.

Les documents stockés sur la solution de stockage doivent faire l'objet d'une sécurité qui répond à de fortes exigences de confidentialité et d'accessibilité. Les documents stockés sont donc cryptées avec une clé globale du type algorithique RIJNDAEL 256 bits. Le cryptage sera assuré par l'utilitaire mcrypt.

Les accès aux fonctionnalités réservées à certains types de profil devront être tracées par l'envoi d'un mail à l'administrateur.

Une deconnexion systématique de certains profils devreont être mis en place au dela d'un temps défini (30 minutes).

Dans la version actuelle de l'application, les mises à jour des schémas de base de données sont assurées par un script accessible via une url une fois l'exploitant connecté à l'application.

Ce moyen d'exploitation sera évincé à terme, car il représente une mauvaise pratique en terme de gestion de vie applicative ainsi qu'un risque de création de failles de sécurité.

Expression des besoins

Expression des besoins au niveau réseau

Le serveur frontal de la solution Doc Dépot devra être située en DMZ.

Planning

T1 2017 : migration de la solution au sein de la DSI Sopra Steria.

T3 2017 : refonte de l'application actuelle en Symfony

T4 2017 : mise en production de la colution refondue

Acteurs

DSI Sopra Steria : les sponsors auprès de la DSI SOpra Steria sont Laurent Eyraud.

DIT : Le sponsor côté Direction Technique de SOpra Steria est Fraçois Bessaguey.

Fondation Sopra Steria / Institut de France : Sponsor Domanique Lambert

Parrrain de Doc Dépot : Frédéric Gontier (architecte)

Porteur du projet : Jean-Michel Cot via l'association ADILEOS.

Le porteur du projet est l'initiateur de la solution. Il est le créateur de la solution et le responsable de son déploiement sur le territoire. Il a sollicité Sopra Steria (son employeur) pour un soutien en expertise, matériel et financier.

Niveaux de services attendus

Objectifs de qualité de service (DICT)

TODO : demander les niveaux de services défini au sein de la DSI SopraSteria

Disponibilité

Plage de servive

Plage horaire du service ouvert aux utilisateurs ou à d’autres applications ou services d’infrastructure

La solution doit être accessible 7 jours sur 7 et 24h sur 24 (hors sauvegardes).

Plage de service garantie

Plage horaire du service à garantir par des moyens techniques et huma

Secours sur un incident d’impact limité (applicatif et panne matérielle)

Délai de reprise inférieur à 4h

PDMA RE

Au vu de l'architecture technique de la solution actuelle il est établi à : Perte de Données Maximum Admissible en Régime Etabli = 24 heures

Cependant, cet état de fait risque de ne pas être adminssible à terme. Dans les procccchaines évolutions un service dédiés au stockage des documents dans une zzoné en dehors de la DMZ sera mis en oeuvre.

DIMA

Durée d’Indisponibilité Maximale Admissible en Régime Etabli = 4 heures

Intégrité de l'information

Niveau 2
Contrôles renforcés d'accès aux données . La détection de la perte d'intégrité est possible : 1. mécanismes d'alerte suite à une modification anormale (audit et supervision) 2. vérification fonctionnelle de l'authenticité des données. La correction des anomalies est possible (rejeu, redolog...).

Confidentialité

Sensibilité

Niveau 3 Données confidentielles. Protection forte des données par chiffrement, les données ne devant être connues que par les personnes autorisées à les connaître .

Tracabilité

Niveau 3 Traces applicatives nécessaires dans le cas de données sensibles pour connaître les actions effectuées sur elles et par qui.

Perfomances ciblées

Les temps de réponse peuvent être vairables selon les fonctionnalités. En effet, du fait des fonctionnalités de cryptage et décryptage des documents les temps de réponse ne doivne tpas exccéder les 30 secondes. Pour les autres fonctionnalités le temps de réponse doivent être inférieurs à 2 secondes.

Niveau d'accessibilité numérique ciblé

TODO: vérirfier le référentiel utilisé : ACCESS WEB?

La solution doit suivre les directives et préconisations du WCAG 2.0. Un des objetifs de la solution étant d'être au moins au niveau AA

L'interface doit toujours suivre une alternative textuelle pour les images où les éléments de navigations proposés.

---

Urbanisme, architecture fonctionnelle et applicative

Urbanisme

Schemas d'urbanismes

Le projet Doc-Depot n'est pas inscrit dans une politique d'urbanisme de SI.

L'application Doc-Depot n'est pas liée à la stratégie d'entreprise de la socitée qui l'héberge. Elle n'est pas liée non plus à des briques d'urbanisme du SI de l'hébereur.

L'application nécessite d'être incluse dans une DMZ, car elle offre des services diffusés sur Internet.

Etude d'urbanisme

N/A

Dossier d'urbanisation

N/A

Architecture fonctionnelle et applicative

Schemas d'Architecture fonctionnelle et applicative

Schemas d'Architecture logicielles

TODO: reprendre les termes de JMC sur TTT_mail ainsi que les autres fonctionnalités (FISSA? etc...)

Description du schéma

Une distinction doit être menée entre les modules applicatifs et les plugins : les modules applicatifs sont des briques non optionnels composant la solution finale, sans ces briques les fonctionnalité de base de l'application n'auraient pas d'appui. Les plugins sont par contre, des modules qui viennent enrichir le métier de l'application. Ces modules viennent s'appuyer sur les modules applicatifs.

Note : le rôle d'exploitatn applicatif n'est pas à confondre avec celui de l'exploitant de la solution d'hébergement : l'exploitation applicatif a pour seul rôle la bonne gestion des processus applicatif. Il gère les alarmes applicatives (et non pas les alarmes issues de l'infrastructurer) et des problèmes inhérents à la qualité des données.

Briques applicatives

Interface utilisateur (A)

Cette brique assure les fonctions d’affichage des données et de navigation au sein des objets de l’application :

• Affichage : sous forme d'images les liens vers les documents
• Gestion des textes traduits,
• Affichage de l’aide en ligne

Pour répondre aux exigences de performance de l’IHM, la technologie AJAX est utilisée afin d’éviter de recharger une page HTML pour un simple rafraîchissement de valeurs.

Serveur Apache (B)

Le serveur a pour rôle :

• de mettre à disposition les ressource statiques de l'application.
• d'assurer le traitements de requ^^etes et de les addresser au moteur PHP

Application Front Office Doc-Depot (C)

Le moteur PHP exécute les fichiers PHP et se charge de faire le rendu HTML.

Module Gestion documents (D)

Ce module fonctionnel est un regroupement des fonctionnalités de chiffrement, de gestion des droits, des méta données des documents ainsi que de leur stockage sur disque.

Application Sendmail (F)

Cette applicatif assure le service de mise en file d'attente des mails sortants. Il doit être disponible pour le bon fonctionnement du module E.

Entrepot de données d'administration (G)

Entrepose toutes les données relatives aux comptes utilisateurs, données de structure sociales et paramétrage de l'application

Entrepot de méta-données de documents (H)

Entrepose les méta-données liés aux document déposés via l'application doc-depot. Ces méta-données consistent à la définition des droits associés aux document, aux références de stockage, aux natures des documnets (type MIME).

Application Back Office (I)

Entrepose les méta-données liés aux document déposés via l'application doc-depot. Ces méta-données consistent à la définition des droits associés aux document, aux références de stockage, aux natures des documnets (type MIME).

Module Exploitation applicative (E)

Ce module fonctionnel est un regroupement des fonctionnalités de services témoins à la bonne tenue des services liés aux SMS et Emails . il comprend aussi les fonctionnalités de qualité de données et de mise à jour de celles-ci.

Données de référence et données échangées

Volumétrie utilisateur

Le niveau de traffic sera à fin 2017 en pointe

• 100 utilisateurs simultanés
• 2 transactions par seconde

Flux et traitement applicatifs

Description des flux entrants et sortants de l'application.

Certains flux internes sont présenté ici, au cas où l'hébergement des bases de données est séparé de celui de la solution web.

Cartographie des flux

Nom du flux	Protocole	Sens	Volumetrie par jour	plage de service	Chiffrement	Type de contenu
F1	HTTP(S)	IN	48	7j/7 24h/24	SSL	Text
F2	HTTP(S)	IN	172800	7j/7 24h/24	SSL	Text / octet-stream
F3	SMTP	IN	??	7j/7 24h/24	SSL	Text
F4	SMTP	IN	??	7j/7 24h/24	SSL	Text/html
F5	TCP	IN	> 1 000 000	7j/7 24h/24	SSL	binaire
F6	TCP	IN	> 1 000 000	7j/7 24h/24	SSL	binaire
F7	IPC	IN	??	7j/7 24h/24	SSL	binaire
F8	POP3/IMAP	OUT	??	7j/7 24h/24	SSL	binaire
F9	HTTP	OUT	??	7j/7 24h/24	SSL	binaire

Flux d'administration technique F1

Ce flux est un moyen d'exploitation pour sonder et superviser l'écosystème technique de la solution. En effet, les solutions de supervision proposées par les offres des fournisseurs d'accès n'étaient ni à la portée financière de l'association ni une priroté dans la mobilisation des ressources.

L'exploitant applicatif doit pouvoir accèder en http et https à certaines fonctionnalités d'exploitatio applicatives. Ces fonctionnalités sont assurées par l'application même et non pas d'autres composant ou services liés à la solution d'hébergement.

Flux F2

Le flux des utilisateurs de la solution web.

Le flux de pointe sont

• 100 utilisateurs simultanés
• 2 transactions par seconde

Flux F3

Le flux des notifications SMS de la solution utilise une solution proposée par un fournisseur d'accès qui convertie les mails en SMS envoyé au porteur du numéro de l'objet du mail.

Flux F4

description du flux (principe, acteurs)

Le flux des envois de mail.

Ces mails touchent tous les types d'utilisateurs de la solution

TODO : question à poser

est le cas ? comment sont envoyés ces mails ? par traitement par lot ? la fonction mail() utilisée en PHP n'est pas faite pour les traitements d'envoi de masse (non optimisation des sockets de connexion)

Volumétrie des envois de mails selon usage

Usage	Public cible	Nb par jour	Niveau de service
mail de notification de connexion ?	Tous ?	??	7/7 24/24
mail de notification de rdv ?	beneficiaire, personnel structure	??	7/7 24/24
mail de notification d'email administratifs	beneficiaire, personnel structure	??	7/7 24/24

Flux F5

Flux de données vers les structures de données liées au méta-données des documents (chemin, droits, ????)

Flux F6

Flux de données vers les structures de données liées au référentiel des utilisateurs, structures, éléments de configuration de la solution, habilitations

Flux F7

Flux technique entre l'interpréteur PHP et le serveur local SMTP? Ce flux se charge lui-même de la mise en file d'attente et du formattage des emails.

Flux F8

Flux de récupération des mails des boites personnelles ou professionnels des personnes (bénéficiaire ? , personnel de structure), afin de notifier l'utilisateur de l'arrivée d'un email de nature administrative.

TODO : question à poser :

les fournisseurs sont ils fixés à l'avance ? quelle fréquence de scan ?

Flux F9

Ce flux est un moyen d'exploitation pour sonder et superviser la bonne tenue des services liés aux SMS envoyés aux bénéficiaires.

Ce flux doit pouvoir accèder aux services de l'application.

Traitement applicatifs (batch)

Les traitements applicatif de type batch sont assurés par l'utilisation d'URL émises par l'exploitant applicatif.

Ces traitements consistent à l'envoi de mails et de SMS.

Il n'y a pas de traitements de prévus concernant la bonne tenue de la base de données.

TODO : a étudier s'il ne devrait en avoir

Editions, impressions

N/A

Sécurité applicative

TODO: a voir avec SSG sur les normes appliqués dans la DSI sur le sujet.

Référentiel d'authentification

L'authentification est assurée par un référentiel interne hébergé sur la base de données. Il n'y a pas d'autres composants à l'heure actuelle qui assure l'authentification ou d'autres types d'authentification.

Gestion des comptes techniques

Description des comptes systeme

N°	Type de compte Système	N° flux utilisant le compte	Description simple	Droits restreints sur (fichiers, batchs, …)	Compte utilisé par	Sécurisation des authentifiants (identifiant / mot de passe) dans l’application	Connexion distante	Format et gestion des mots de passe

Description des comptes applicatifs

N°	Type de compte applicatif	N° flux utilisant le compte	Description simple	Droits restreints sur (fichiers, batchs, …)	Compte utilisé par	Sécurisation des authentifiants (identifiant / mot de passe) dans l’application	Connexion distante	Format et gestion des mots de passe

Tracabilité et audit applicatifs

Déclaration CNIL

TODO: à compléter

Guide de sécurisation des produits

TODO: voir avec SSG si de telles références existent au sein de la DSI

Revues de vulnérabilités

TODO: voir avec SSG la politique d'application des patchs correctifs

Certificats utilisés

TODO: voir avec SSG comment le sujet est traité.

la cas ééchéant se renseigner sur les certificats gratuits

---

Architecture technique

Choix généraux d'architecture technique

Schemas d'Architecture technique

Schemas d'Architecture technique de secours à froid

Il n'y a pas de schéma pour une solution de secours à froid.

Les machines virtuelles utilisées seront backupés tous les jours.

D'où une PDMA de 24 heures maximum.

Choix techniques généraux

Les choix techniques ont été guidés par l'existence de la solution. Cette solution évoluera vers un système plus modulaire et robuste.

Dans l'immédiat une simple pile LAMP est mise en oeuvre.

Normes et stadards appliqués

Accès à l'application ou au service d'infrastructure

TODO : à définir avec SSG

Supervision applicative

TODO : à définir avec SSG

Mutualisation applicative

La solution êst candidate à la mutualisation à la condition suprème que l'accès aux ressources sensibles (cls de chiffrement et aux documents) soit assuré.

Autres choix générauux

Nommage des composants applicatifs

Description des données

Données en base

Volumétrie

Securisation

Protection des données sensibles (hors mots de passe)

Les fichiers correspondants aux documents déposés dans Doc Depot sont chiffrés avec une clé à chiffrement syméttrique et unique de 256 bits.

Garantie d'intégrité des données assurée.

Les principales exigences de garantie sur les données sont les suivantes :

• garantie de confidentialité : seules les personnes autorisées explicitmeent dans l'application aront accès aux documents mentionnés
• garantie de traçabilité : les accès aux fichiers seront tracés dans un fichier de log.
• la garantie de zéro pertes sur les documents n'est pas pleinement assurée par l'architecture actuelle. Pour cela il faudrait un serveur de documents dédiés et protégé dans une zone réseau hors DMZ
• la grantie de zéro perte sur les données en bases de données devrait être assurée.

utilisation hors-production des données de production

Les données issues de la production ne doivent

• ni être mise à disposition à un autre environnement
• ni être copiées pour une autre utilisation qu'à but de sauvegarde.

Performance et tuning

Données hors base (stockées sous forme de fichiers)

Description

Volumétrie

Securisation

Protection des données sensibles (hors mots de passe)

Garantie d'intégrité des données assurée ?

utilisation hors-production des données de production

Les fichiers sotckées touchent à des données personnelles. Elles ne doivent être en aucun être exposéés

Infrastructure technique

Serveurs

Postes de travail

Autres matériel utilisé

Téléphone portable

Le téléphone est branché en permanence

• par un câble USB alimenté
• avec le wifi activé et connecté
• sur le réseau GSM de FREE ;

Compte ANDROID : [PW18]

Pas de code PIN

Pas de mise à jour automatique des applications

Logiciels installés

• SMS2mail
• Boomerang sms [PW21]
• Phoneleash

Le message du répondeur doit indiquer : « Bonjour. Bienvenue au support de doc-depot.com géré par l’association ADILEOS , le site qui permet de Sauvegardez gratuitement de façon sécurisée vos documents, photos et informations essentielles . Vous pouvez déposer directement votre demande sur le site en cliquant sur le lien « Nous contacter » en bas de page d’accueil. Sinon déposer votre demande sur le répondeur en précisant bien vos noms et vos coordonnées pour que nous puissions vous répondre. A vous »

1. Toutes les heures, envoi d’un mail via TTT_mail avec mot clé
2. « Email to SMS » sur réception du mot clé le téléphone se renvoie un SMS
3. Le mécanisme standard renvoie le SMS vers la boite mail traitée par TTT_mail.php
4. Le mail de retour est reçu et tracé dans le log technique
5. Si réception u delà de 10 minute 30 un mail d’alerte est envoyé à l’exploitant

Telephone envoi SMS

Le téléphone est branché en permanence

• par un câble USB alimenté
• avec le wifi activé et connecté
• sur le réseau GSM de FREE ;

Pas de mise à jour automatique des applications

Logiciels installés

• SMS gateway
• Boomerang sms [PW21]

Compatibilité avec protocole IP (v4, v6)

Echanges avec SI partenaires

Evolution de la solution jusqu'à la cible

TODO: Très important à remplir pour donner la roadmap d'évolution de doc-depot (NoSQL, Micro Services, architecutre haute dispo)

Tenue en charge

Besoin en ressources lors de la MEP