DSI - Pôle Infrastructures

Transcription

1 Département du Système d Information CONTEXTE DSI - Pôle Infrastructures SUJET Architecture cible pour un projet devant intégrer le SI de l'inserm référence PI01091V02V.doc version statut créé le 29/06/2006 par Julio Martins, Laurent Bloch, Gwénaël Dumont, Jean-François Fady, Patrick Lerouge, Romain Suszko mis à jour le 13/07/2006 par Julio Martins validé le 20/07/2006 par Cellule Architecture du SI Péremption, archivage et restriction de diffusion Nature de la restriction : confidentiel, diffusion restreinte, diffusion interne, restriction annulée avertissement Afin de prévenir toute utilisation non intentionnelle de documents périmés, le lecteur est invité à vérifier que l'édition papier du document en sa possession constitue la dernière version en vigueur. Cette vérification peut être effectuée soit en consultant la zone documentaire adéquate du serveur de fichiers, soit en interrogeant l'auteur du document, soit, lorsqu'il existe, l'administrateur du système documentaire. La reprographie ou la rediffusion de ce document, par quelque moyen que ce soit, est strictement déconseillée sans information et autorisation préalable de son auteur ou, lorsqu'il existe, de l'administrateur du système documentaire.

2 Table des mises à jour du document version date objet de la mise à jour V01T 29/06/2006 V02T 13/07/2006 Prise en compte des remarques suite à la réunion de la cellule «Architecture du SI» du 30/06/2006 Table des matières 1 Introduction 3 2 Exigences en matières de plateforme, d outils et de logiciels 3 3 Exigences en matière de sécurité Sécurité des mots de passe Sécurité des accès Sécurité des données 6 4 Exigences en matière de poste client Le web La plateforme et le logiciel client 7 5 Exigences en matière de performance INSERM page 2/7

3 1 Introduction Ce document a pour but de définir les pré-requis et exigences indispensables qui doivent être pris en compte lors de la mise en place d une architecture de production, de développement ou de recette, hébergeant une application informatique devant être prise en charge par les Infrastructures du DSI (Département du Système d Information) de l Inserm. Ces pré-requis et exigences ont été émis par la cellule architecture du SI mise en place à cet effet ; ils seront mis à jour au fur et à mesure des évolutions technologiques dans les différents domaines concernés. 2 Exigences en matières de plateforme, d outils et de logiciels Architecture générale : multi-partite (n- tiers). La séparation des traitements et des données devra être effective dans l architecture physique. Les mandataires ou frontaux web devront être installés en DMZ ; les serveurs applicatifs et base de données seront quant à eux installés en MZ. Les architectures retenues doivent pouvoir s adapter à des montées en charge de façon simple («scalables»). Système d Exploitation : Le système d exploitation de référence à l INSERM est Linux, et plus précisément la distribution RedHat Entreprise. La version choisie doit impérativement être qualifiée «Phase 1 Full support» par l éditeur au démarrage du projet. Il est également nécessaire que cette distribution soit à minima qualifiée «Phase 2 Deployment» à la date de mise en production. Durant la période d exploitation du projet la version doit être au minima en «Phase 3 Maintenance». D autres distributions pourront être utilisées dans des cas particuliers, mais elles devront être validées par la cellule architecture du SI. Maintenance et mises à jour fonctionnelles et de sécurité : Les logiciels «système et applicatif» devront pouvoir être mis à jour régulièrement par les équipes de production en utilisant le système mis en place par l Inserm (apt-get et yum). Paquetages : Ces paquetages sont sous forme RPM (Redhat Package Manager) L application doit utiliser les paquetages fournis par la distribution choisie y compris dans les canaux fils de cette distribution tels «application server, web application stack, developper suite» En cas d impossibilité validée par le pôle infrastructures, un paquetage alternatif doit être livré sous forme RPM source, son origine sera examinée, ce RPM source sera compilé et signé électroniquement par l Inserm pour intégrer le système de mise à jour mis en place par la MSSI. Stockage : découplé des serveurs. Les données seront stockées en RAID 5 sur un dispositif de type SAN ou NAS en fonction des besoins. Ces dispositifs seront bien sûr installés en MZ. Pour les systèmes d exploitation : il seront installés sur des disques durs internes aux serveurs en RAID 1. Base de données : ORACLE, SYBASE, PostgreSQL, MySQL. Une préférence doit être accordée à Oracle ou SYBASE pour des bases de données de volumétrie importante et nécessitant un support reposant sur les services d un éditeur. INSERM page 3/7

4 Pour les bases de données de petite ou moyenne volumétrie, la préférence doit être accordée à PostgreSQL ou MySQL. Les versions déployées doivent correspondre aux versions n ou n-1 certifiées, les versions n devant avoir été certifiées depuis au moins 6 mois. Ceci doit être vrai non seulement en début de projet mais également pendant toute la vie du projet. Le langage de programmation utilisé devra être du SQL standard. Outil de sauvegarde : Time Navigator (pilotage du robot de sauvegarde) installé par les Infrastructures. Outil d administration applicative : mode SSH (putty, WinSCP). Les accès par des procédures de type Telnet ou PC Anywhere sont proscrits. Outil d administration de base de données : l outil choisi par le DSI de l INSERM est Toad. Outil de supervision : l outil choisi par le DSI de l INSERM pour superviser les environnements de production est Sysload. Haute Disponibilité : clustering HeartBeat (monitoring Mon) ou Red Hat Cluster suite. Répartition de charge : ce type de technologie n est pas utilisé actuellement par l Inserm cependant dans la cadre de la haute disponibilité et afin d optimiser le matériel en cluster, la répartition de charge est nécessaire. La technologie utilisée doit être de préférence de type logiciel et portable 3 Exigences en matière de sécurité Toute dérogation aux exigences écrites dans ce chapitre doit impérativement être autorisées conjointement par le directeur du DSI après avis de la cellule sécurité opérationnelle du Pôle infrastructures et le Responsable Sécurité du Système d Information (RSSI). 3.1 Ouverture des comptes et attribution des privilèges L ouverture et l attribution des privilèges doit répondre aux règles 1 à 5 extraites du document rédigé par le RSSI ( mis à jour le 30/06/2006 : Règle n_ 1. : Les droits d accès à tout service ou privilège du système DOIVENT être reliés à une et une seule personne physique que son login identifie sans ambiguïté. Règle n_ 2. : Si deux personnes ont besoin d un même type de droits ces droits sont accordés à ces deux personnes individuellement. Règle n_ 3. : Certains comptes anonymes sont indispensables au fonctionnement du système Unix ou de certains logiciels, tel que root. Ces comptes ne doivent jamais être utilisés directement, sauf lors de la génération du système. Les utilisateurs qui doivent bénéficier des privilèges conférés par un tel compte utiliseront un outil tel que sudo, qui permet de disposer d un fichier de personnes autorisées et d un journal des utilisations. La liste des personnes autorisées sera communiquée au Directeur du DSI sous la forme de fiches comportant les informations suivantes : nom du créateur du privilège ; nom du bénéficiaire du privilège ; liste des programmes, processus ou bases de données concernés. INSERM page 4/7

5 Règle n_ 4. : Dans la mesure où les contraintes techniques le permettent, les comptes anonymes indispensables seront créés de telle sorte qu ils ne permettent pas le login, et sans shell associé. Règle n_ 5. : toute création de compte anonyme doit être signalée au Directeur du DSI. L ensemble des règles citées est applicable à tous types de comptes, exemples : système et bases de données. Les comptes nominatifs sont ouverts pour la durée du besoin d administration, ils sont clôturés impérativement le jour où ce besoin cesse. Il peut leur être affecté les droits et attributions prédéfinis dans un groupe dans lequel ils sont affectés. 3.2 Sécurité des mots de passe L application doit être compatible avec un système de gestion de certificat de clé type X509 V3 et donc à terme s interfacer avec l annuaire LDAP de l Inserm. Cependant l application doit rester compatible avec une connexion standard et pour cela les règles de mot de passe décrites ci-dessous doivent être appliquées. Les mots de passe doivent être cryptés dans la base de données et même les administrateurs techniques (applicatifs, de base de données) ne pourront y avoir accès. Un système permettant de restituer simplement le mot de passe oublié ou un système permettant de générer un nouveau mot de passe pour l utilisateur devra être prévu et seul l utilisateur concerné devra pouvoir le faire Transmission des mots de passe Les mots de passe seront transmis de préférence au titulaire par courrier électronique chiffré et crypté. Dans le cas, à éviter, de l utilisation d un canal non crypté de transmission, les logins et les mots de passe devront être fournis dans deux types différents de support d information (exemple : login envoyé par courrier et mot de passe par mail). Tous les mots de passe doivent être au minimum sur 8 caractères et doivent comporter obligatoirement des caractères alphanumériques et spéciaux (au moins un caractère numérique et un caractère spécial). Les mots de passe sont incessibles. L utilisateur après avoir pris connaissance de ses login et mot de passe doit : 1. Détruire les supports ayant été utilisés pour transmettre ces informations. 2. Acquitter la prise de connaissance de ces informations auprès de l administrateur créant les comptes. 3. Changer dès la première connexion son mot de passe ; l utilisateur doit d ailleurs avoir la possibilité de changer de façon sécurisée son mot de passe à tout moment, une modification régulière étant d ailleurs recommandée. L administrateur créera effectivement ces comptes après s être assuré de l acquittement et de l authenticité du demandeur. 3.3 Sécurité des accès La sécurité des accès doit répondre aux règles 6 à 9 extraites du document rédigé par la MSSI ( mis à jour le 30/06/2006 : INSERM page 5/7

6 Règle n_ 6. : La connexion à une machine distante autrement que par un compte anonyme (ex. : serveur WWW ou ftp public) en traversant l Internet doit se faire par un protocole sécurisé. Telnet et ftp sont prohibés, on leur substituera ssh, scp ou une encapsulation dans SSL ou TLS. Règle n_ 7. : L accès à une machine distante située en zone protégée doit se faire en deux temps : accès préalable à une machine en DMZ, qui effectuera la redirection de port vers la machine du réseau interne. Règle n_ 8. : Assurer le contrôle d accès à un site par l adresse IP source est une méthode définitivement périmée qui doit être abandonnée. L utilisation de certificats électroniques émis par l IGC de l INSERM doit lui être substitué. Règle n_ 9. : Lorsqu'un utilisateur accède à un serveur en zone protégée depuis un site externe, sur l'internet par exemple, il convient de vérifier que le site d'origine de la connexion satisfait les exigences de sécurité du site de destination. La nature de la procédure de vérification, qui devra comporter des éléments techniques et engager la responsabilité de l'utilisateur, sera déterminée en fonction des circonstances ; on peut citer à titre d'exemples les systèmes de mise en quarantaine des accès distants proposés par certains fournisseurs. Règle n_ 10. : Les actions effectuées sur les systèmes et les bases de données sont journalisées avec le nom de l agent qui les a effectuées. Pour les applications web, tout utilisateur (sauf administrateur technique pour des besoins spécifiques) devra accéder à l application uniquement via le protocole https en utilisant un système de session (pas de système de session persistante et définition du délai d expiration de la session de façon appropriée). L accès se fera uniquement sur le serveur web applicatif hébergé sur une machine située en DMZ (Zone DéMilitarisée). Les administrateurs techniques pourront avoir des accès spécifiques aux serveurs (DMZ et zone protégée par un pare-feu) uniquement en protocole SSH. Les administrateurs techniques de l application auront alors des comptes utilisateurs spécifiques avec des droits restreints ne leur permettant que d effectuer des interventions sur l application (et non au niveau système). Ceci doit être pris en compte notamment pour les protocoles de mises à jour, de livraison de corrections et/ou d évolution de l application. Pour tout utilisateur (hors administrateurs techniques), seul le serveur frontal web ou mandataire situé en DMZ est accessible. Toute autre machine située en zone protégée ne pourra être accessible que par les serveurs frontaux ou mandataires en DMZ. Les protocoles et ports utilisés afin que la machine en DMZ accède à la ou les machines en zone protégée devront être clairement spécifiés et validés par le RSSI et la cellule sécurité opérationnelle des infrastructures. Concernant le cas particulier du protocole SQLNet, ce dernier doit être sécurisé. 3.4 Sécurité des données Toutes les données confidentielles et/ou critiques pour le bon fonctionnement de l application devront être stockées en zone protégée. Ces données ne seront accessibles «en direct» que par les serveurs base de données situés en MZ. Au sein même de l application, les données seront accessibles aux utilisateurs selon des droits d accès spécifiques pour chaque type d utilisateur défini. L utilisation des comptes d administration des bases de données ne doit pas permettre de travailler en direct sur les données. INSERM page 6/7

7 4 Exigences en matière de poste client 4.1 Le web Pour des raisons de sécurité, les utilisateurs doivent pouvoir accéder à l application uniquement en protocole HTTPS. De plus, l application devra être accessible en web uniquement sur le port https standard : 80 ou La plateforme et le logiciel client Tout utilisateur doit pouvoir accéder à l application et bénéficier de toutes ses fonctionnalités à l aide de n importe quel navigateur web installé sur n importe quelle plateforme (Unix, Windows, Macintosh). L application devra offrir et garantir toutes ses fonctionnalités en conformité avec la norme standard W3C. Aucun script, module ou plug-in supplémentaires du navigateur (en dehors de ceux installés en standards) ou tout autre élément ne devront être pré-requis ou requis et/ou ne devront s installer automatiquement à la première connexion ou à chaque connexion de l utilisateur à l application. 5 Exigences en matière de performance Les batchs spécifiques et/ou les process spécifiques réservés aux administrateurs fonctionnels et/ou techniques de l application ne doivent faire l objet d une préparation et d une surveillance ciblée de manière à éviter : Toute surcharge inopinée du réseau de production. Tout dysfonctionnement entraînant une perturbation du plan programmé de sauvegarde. INSERM page 7/7