BTS SIO1 PPE2
Projets pratiques encadrés : GSB
PPE
 PPE GSB
PROJET ARCHI-SITE
Architecture pour l'accueil du site de suivi de Compte-Rendus et frais de remboursement Sous partie A
Fiche descriptive
Propriétés
|
Description
|
Intitulé
|
Mise en place d'une architecture technique et des fonctions de sécurisation pour l'application de suivi des comptes-rendus et des frais de remboursement
|
Présentation
Rapide
|
Le projet consiste à mettre en place la solution technique sur le réseau de l'entreprise, en intégrant les différents serveurs et en activant les différentes techniques de sécurisation : authentifications, cryptage sur le serveur web
|
Positionnement
|
>>>>
|
Durée estimée
en heures
|
16 heures
|
Savoir-faire SI mobilisés en priorité
|
Les savoir-faire de la phase d'étude du projet, auxquels s'ajoutent :
SI5 - Installer un composant matériel et un composant logiciel
SI5 - Installer, configurer et administrer un système d'exploitation
SI5 - Exploiter les fonctions de base d’un langage de commandes
SI5 - Installer, configurer et administrer un service
SI5 - Mettre en œuvre un protocole sécurisé associé à un service
SI5 - Valider et documenter un service
|
Notions EDM
|
D5.1 – L'obligation de sécuriser les données numériques
EM4.5 – Le système d'information et les risques organisationnels
|
Documents joints
|
Cahier des charges, schéma de réseau
|
Modalités de
réception
|
Présentation d'un système opérationnel – recette
Documentation technique, mode opératoire et compte-rendu d’installation
|
Équipes
|
Par équipe de 4
|
Planning
|
Du 22 janvier au 28 mai
|
CAHIER DES CHARGES Définition du besoin Définition de l'objet
Le laboratoire désire mettre à disposition des visiteurs médicaux une application Web permettant de centraliser les comptes-rendus de visite et la gestion des frais engagés.
L'entreprise a choisi d'héberger en interne les serveurs exécutant l'application.
L'achat de nouveaux équipements peut-être envisagé si le besoin le justifie.
Forme de l'objet
On souhaite une application en ligne, sécurisée, accessible par le FQDN visite.gsb.coop. Le système doit donc être accessible depuis un navigateur. L'application sera répartie sur plusieurs serveurs (physiques ou virtualisés).
Accessibilité/Sécurité
L'environnement doit être accessible aux seuls acteurs de l'entreprise.
Les données ne doivent pas être accessibles directement de l'extérieur mais uniquement par des interrogations réalisées par le serveur Web.
Le système sera accessible pour plusieurs usages :
application de gestion des suivis (CR et Remboursement de frais) accessible à l'ensemble de la force commerciale,
mise à jour des pages du site par les équipes du service développement,
actualisation des données de traitement des frais par les personnels du service comptabilité
Une authentification préalable sera nécessaire pour l'accès au contenu.
Les échanges avec l'extérieur ne doivent pas être interceptés.
Contraintes Environnement
L'environnement des serveurs est à déterminer : Linux, Windows Server, autre..
Les utilisateurs sont sous Windows XP, Vista ou Windows 7.
Services
Pour chaque service, on précise les fonctionnalités à mettre en œuvre.
Pour le service de gestion des rapports:
Un serveur Web sécurisé (HTTPS, SSL/TLS) exécutant des pages de script côté serveur (PHP, ASP.net, JSP, autre)
Une base de données relationnelle, éventuellement administrable par interface Web.
Les deux serveurs sont distincts
On ne veut pas d'outils pré-configurés (LAMP, WAMP, EasyPHP, etc) mais des modules indépendants de manière à pouvoir changer l’environnement de l’un ou l’autre des modules.
Pour la mise à jour des pages Web
un service FTP avec authentification (par base de données, annuaire ou autre gestion d'utilisateurs) limitant l'accès aux seuls développeurs de l'entreprise.
Ce service FTP est limité à un accès interne. Il ne doit pas être ouvert à l'extérieur.
Pour la gestion des frais
les visiteurs alimentent les frais engagés par le biais du serveur web de gestion des rapports
le service comptable met à jour la base de données par une page Web intégrée à l'intranet ou par un module de traitement automatique suite aux enregistrements comptables réalisés sur le PGI.
Contraintes
Les fichiers de configuration spécifiques au besoin seront épurés de tout commentaire inutile et d'options non retenues. Ils doivent être commentés sur les valeurs significatives retenues.
On externalisera les manipulations dans des fichiers autonomes auxquels on fera appel (script SQL, commandes de création de certificat et de clés, etc).
Sécurité
On préfèrera une authentification des visiteurs par certificat à celle par nom d'utilisateur et mot de passe mais ce n'est pas une obligation première.
Filtrage
On a décidé d’organiser l’application Web selon la structure suivante :
le Serveur Web sera en DMZ. Il héberge le serveur HTTP, le module d’interprétation des scripts (PHP, ASP, JSP, etc) et un serveur FTP.
La base de données est présente sur le réseau local. Seul le serveur Web est autorisé à y accéder depuis la DMZ, toute autre entrée vers ce serveur depuis la DMZ ou le WAN est interdit.
Les informaticiens du laboratoire mettent à jour les pages sur le serveur Web grâce à un client FTP. Ils doivent être authentifiés par leur compte présent dans l’annuaire de l’entreprise. Le service FTP n’est pas autorisé depuis l’extérieur.
Les visiteurs accèderont au site Web grâce à une identification (zone de saisie du nom et du mot de passe), qui sera contrôlée avant de donner accès aux pages de saisie. L’ensemble des interactions sera crypté (SSL/TLS).
Aspect réseau
Le schéma fourni (Annexe et fichier GSB.schArchiSite.vsd) présente la solution à obtenir. Le nombre de machines représenté peut être adapté (recours à de la virtualisation, hébergement de plusieurs services sur une seule machine, etc).
Documentation
La documentation complète, rédigée et mise en forme sera à rendre sous format électronique éditable.
Une fiche reprendra tous les éléments de configuration sans rédaction (paramétrages des services, adressage IP, comptes et mots de passe, etc.)
Responsabilités
Le commanditaire fournira à la demande toute information sur le contexte nécessaire à la mise en place de l'infrastructure.
Le commanditaire fournira une documentation et des sources exploitables pour la phase de test : base de données exemple, modélisation, schéma réseau,...
Le prestataire est à l'initiative de toute proposition technique. Notamment, il proposera des noms pertinents pour l'accès aux services (enregistrements DNS).
Le prestataire fournira un système opérationnel, une documentation technique permettant un transfert de compétence, une documentation de description de l'architecture (matériel, services et code) et des options particulières retenues dans le contexte.
ANNEXE : architecture de l'application et des échanges attendus
Page sur
|
