Contexte
Mon projet tuteuré s’est déroulé au SICIO (Syndicat Intercommunal pour l’Informatique et ses Outils) du 4 au 29 Juin 2018.
Qu’est-ce que le SICIO ?
Le Syndicat InterCommunal pour l’Informatique et ses Outils créé le 19 juin 1973 sur l’initiative des villes de Choisy-le-Roi, Bonneuil-sur-Marne, Valenton, Orly, Villeneuve-le-Roi et Limeil-Brevannes compte aujourd’hui 5 villes adhérentes (Choisy-le-Roi, Bonneuil-sur-Marne, Valenton, Orly et Villeneuve-le-Roi) et de 5 partenaires sous convention (RIVED, SIREV, SETBO, SIRM, Grand-Godet).
Les missions du SICIO se déclinent en :
- Infrastructures réseau : mise en œuvre, administration et maintenance du réseau
- Infrastructures systèmes : mise en œuvre et, gestion des serveurs, protection, sécurité et sauvegarde des données
- Prise en charge des applications de gestion (progiciels de gestion de financière, des ressources humaines…)
- Gestion de la messagerie et des outils collaboratifs
- Gestion des sessions de formations bureautiques et métier
- Aide, accompagnement et assistance des services métier
- Conduite et animation des projets
- Veille juridique sur l'utilisation des systèmes d'information
- La politique de l'établissement en matière de système d'information est définie par le Président et par le Conseil syndical
Objectifs & cadre du projet
L’objectif de ce projet tuteuré fut de mettre en place un outil permettant le partage de documents de manière simple et sécurisé pour les membres du SICIO et pour les salariés des différentes villes.
Pour réaliser ce projet, une équipe composée de 3 apprentis a travaillé comme “prestataire”. Cette équipe est composé de : Christian Barreto, Kevin Abreu et moi même.
Différentes contraintes furent fixées pour ce projet:
- L’authentification doit se faire via les différents LDAP présents au SICIO
- Synchronisation automatique d’un dossier de l’ordinateur vers la solution (à la manière du Drive de Google)
- Intégration avec la messagerie ZIMBRA déjà en place au sein du SICIO
- Etanchéité des villes, les villes ne doivent pas pouvoir voir ni interagir avec les autres villes
- De mobilité : La solution doit être accessible de n’importe ou et simplement depuis un smartphone, une tablette et un ordinateur
- Le versioning doit être disponible, il est possible de repasser sur une ancienne version d’un document à tout moment
- Si un utilisateur partage avec un document avec quelqu’un de l'extérieur, un mot de passe est nécessaire.
- Solution sécurisé
- Livrables expliquant l’administration de la solution et comment l’utiliser (destiné aux utilisateurs)
Etat de l'art
Une fois les contraintes fixées, nous avons commencé à rédiger le cahier des charges à présenter à notre responsable, Farida Mebtouche.
Nous avons définis les contraintes d’infrastructures (les OS utilisés au sein du SICIO, contraintes de stockages), de budgets et les contraintes humaines (le projet est réalisé par nous trois, nous pouvons demander de l’aide à notre responsable Farida Mebtouche et à deux autres salariés du SICIO, Carol Edom et Rakia Ouachani.)
Les nécessités du contexte font références aux contraintes fixées par le SICIO. Nous avons également du adapter nos choix technologiques en rapport avec le tableau comparatif des solutions que nous avons fais, et par rapport aux contraintes fixées par le SICIO.
Prendre en compte les nécessités du contexte, de l’existant ainsi que les évolutions prévisibles.
La définition du cycle de vie du projet fut importante à déterminer durant la réalisation du cahier des charges. Nous avons définis les phases de tests, de mise en production, de validation par notre responsable et de maintenance.
Après la définition des différents cycles de vie, nous avons réalisé un GANTT pour mettre “au clair” notre plan et les étapes importantes du projet.
Une fois le cahier des charges validé, nous avons commencé à compléter le tableau comparatif des solutions.
Cette phase du projet n’a pas durée longtemps, en effet deux solution (Nextcloud et Owncloud) répondaient aux contraintes fixées par le SICIO.
Nous avons choisis de partir sur la solution Nextcloud étant donné que le projet est plus suivi par la communauté que Owncloud, et qu'aucune fonctionnalité n’est bloquée derrière un abonnement payant.
Nous avons du présenter notre cahier des charges et la solution que nous avons choisis devant Farida Mebtouche et d'autres membres de la direction.
Nous faisons une réunion toutes les semaines avec notre responsable Farida Mebtouche pour faire un bilan sur l’avancement du projet et sur les problèmes que nous rencontrons.
Être force de proposition
Adopter les outils de communication appropriés à la situation
Adapter son positionnement à son interlocuteur
Implémentation de la solution
Il allait falloir intéragir avec les serveurs LDAP pour l'authentification, les serveurs mails pour que l'application puisse envoyer des mails, les serveurs de sauvegarde pour pouvoir faire des backups et restaurer, mais aussi avec les proxy pour pouvoir sortir du réseau interne. Nous avons donc pris contact avec les différents personnels gérant ces outils afin de jauger de la façon dont notre application intéragirait avec eux.
Mesurer et anticiper les interactions avec l’écosystème et les processus
Pour l’installation, nous avons utilisé une machine Red Hat 7 (obligatoire au SICIO) et nous avons installé 6 instances Nextcloud (pour les 5 villes + le SICIO). Cela afin de remplir la contrainte d’étanchéité entre les villes.
Une fois Apache installé, il nous fallait mettre en place les différentes bases de données. Celles-ci sont mises sur une autre machine et tournent sous MariaDB.
Afin de garantir plus de sécurité sur le serveur de base de donnée, des utilisateurs Mariadb avec des droits différents ont été crée selon les actions qu’ils devront effectuer (principe de least privilege). Ainsi, nous avons 6 utilisateurs qui sont chacun administrateurs de leur propre base selon le nextcloud auquel ils sont attachés. Et nous avons 2 utilisateurs avec des droits restreints qui serviront à faire des sauvegardes et des restauration des bases.
Ensuite, Il a fallu tester les différentes possibilités offertes par Nextcloud, les différents plugins qui nous permettent de répondre aux besoins qui ont été exprimés. Les plugins les plus importants sont ceux permettant de gérer la rétention des documents, l’intégration avec ZIMBRA, l’authentification grâce à LDAP.
Ensuite, Il a fallu tester les différentes possibilités offertes par Nextcloud, les différents plugins qui nous permettent de répondre aux besoins qui ont été exprimés.
Après cette période de test validée par notre responsable, nous avons fait les demandes afin de créer les entrées DNS pour que les sites soient accessibles depuis l’extérieur. Pour sécuriser cela, on encrypte les communications du client au serveur via des certificats SSL fourni par Let’s Encrypt et renouvelés automatiquement.
A la fin de notre projet, l'infrastructure Nextcloud ainsi que son écosystème est représenté comme ceci:
Problèmes rencontrés
Le problème le plus important que nous avons rencontré est au niveau de l'étanchéité des villes.
Au départ, nous pensions pouvoir créer un serveur web avec toutes les villes séparées via des groupes.
Il n'existe aucun moyen automatique sur Nextcloud qui permet de regrouper les utilisateurs par villes, il faut le faire manuellement, pour plus de 2000 utilisateurs ce n’est pas possible… Il est possible de scripté ce procédé mais vu qu'il faut modifier des tables dans la base de donnée, nous avons peur qu'après une mise à jour il y ait des soucis de compatibilité et que ce soit complexe à maintenir.
Nous avons donc proposé à Farida Mebtouche de créer un serveur Nextcloud par ville, soit 6 serveur au total. Ce choix ne rajoute que peu de contraintes techniques (6 certificats SSL au lieu de 1, 6 bases de données au lieu de 1) et permet l’étanchéité complète des villes.
Critique Portfolio: Il s’est avéré qu’il n’y a aucun moyen automatique sur Nextcloud permettant de regrouper les utilisateurs par villes, il faut le faire manuellement, pour plus de 2000 utilisateurs ce n’est pas possible…", pas de scripting possible ?
Réponse apportée: Voir paragraphe au dessus, j'ai détaillé pourquoi ce n'était pas possible et peu conseillé de le faire.
- Apache n'utilisait pas la bonne version de php, nous avons du changer le module de php5 vers php7 dans la configuration d’Apache.
- Le module de Nextcloud qui permet de chiffrer les transactions entre le site web et le serveur de base de donnée ne marchait pas, nous n’avons pas trouvé de solution, ce qui fait que seul les transactions pour sauvegarder et restaurer les bases de données sont chiffrées. (cela concerne uniquement les transactions du serveur web au serveur de base donnée, les données transitant de l’utilisateur au serveur web sont elles chiffrées)
- Nous avons également eu un problème au niveau du LDAP, le SICIO utilise un HAPROXY en face de leurs deux serveurs LDAP (l’un réplique sur l’autre). Sur Nextcloud, quand nous rentrons les paramètres du HAproxy, Nextcloud n’arrive pas à récupérer les utilisateurs via le HAProxy, nous en avons parlé à Farida Mebtouche et après réflexion, nous avons directement rentré l’adresse du premier serveur LDAP dans Nextcloud, et le second serveur LDAP est en “secours” dans Nextcloud.
- Ensuite, Il a fallu tester les différentes possibilitées offertes par Nextcloud, les différents plugins qui nous permettent de répondre aux besoins qui ont été exprimés.
Prévenir les problèmes de sécurité
Identifier les éléments pouvant porter atteinte au bon fonctionnement du système d’information de l’entreprise
Après cette période de test validée par notre responsable, nous avons fait les demandes afin de créer les entrées DNS pour que les sites soient accessibles depuis l’extérieur. Pour sécuriser cela, on encrypte les communications du client au serveur via des certificats SSL fourni par Let’s Encrypt et renouvelé automatiquement.
Des scripts de sauvegarde et de restauration ont été créé pour permettre d’avoir une sécurité quant à la disponibilité et la récupération des données. Nous avons tester ces scripts pour nous assurer qu’ils étaient fonctionnels.Nous avons testé ces scripts volontairement et après une erreur de manip plusieurs fois !
Critique portfolio: avez-vous simulé des incidents ? Dans notre esprit, cet indicateur est plutôt relatif à des situations de crise mais on peut l'entendre aussi comme tu le fais.
Solution apportée: Nous avons testés nos scripts après le cassage de notre application/bdd, de manière volontaire.
Organiser et tester la réaction en cas d’incident
Tout au long du projet, nous avons rédigé une doc administration, expliquant l’installation et la maintenance de l’application. Ainsi qu’une doc utilisateur pour expliquer le fonctionnement du Nextcloud destiné aux utilisateurs.
Nous avons donc documenté nos actions individuelles et les problèmes que nous avons résolus pour en faire un guide d'administration.
Documenter des actions individuelles dans une logique de groupe
Enrichir les bases de connaissances: personnelle, de l'entreprise et de la communauté
A la fin de la période du projet, nous avons fait une présentation devant les agents du SICIO sur le fonctionnement du Nextcloud et son intérêt pour le partage de l’information.
Durant notre présentation devant les salariés du SICIO et durant la rédaction du guide utilisateur, nous avons du adapter notre langage et notre lexique. En effet, notre audience n'est pas "technique", nous devons nous faire comprendre.
Adapter son positionnement à son interlocuteur
Critique Portfolio: comment rédiger pour un admin, pour un user
Réponse apportée: J'ai détaillé notre manière de faire en fonction du public visé
Automatisation
Nous avons automatisé le plus de tâches possible.
Nous avons récupéré un script trouvé sur GitHub que nous avons modifié et adapté à notre environnement de travail. Ce script nous permet de sauvegarder les dossiers et fichiers nécessaires au fonctionnement de Nextcloud ainsi que les 6 bases de données.
Ce script est lancé automatiquement toutes les nuits à 01h.
Nextcloud embarque également un script permettant de nettoyer les bases de données ainsi que les fichiers temporaires qui s’accumulent au fil des jours. Nous avons automatisé le lancement de ce script. Ce script se lance toutes les 15 minutes (recommandation de l’équipe Nextcloud).
Le renouvellement automatique des certificats est également scripté, nous utilisons Let’s Encrypt et Certbot couplé à une tâche CRON pour renouveler les certificats tous les 3 mois.
La dernière tâche que nous avons automatisé concerne la sécurité. Les mises à jour de sécurité se télécharge et s’installe automatiquement toutes les nuits à 01h.
Bilan
Ce projet a été très enrichissant sur plusieurs plans.
Sur le plan gestion de projet, nous avons mis en pratique ce que nous avons vu durant l’étude de cas faites à l’IUT. Cela nous a permis de rédiger un cahier des charges clair et précis, de se répartir les tâches et de mettre au point un planning. Le projet aurait été beaucoup plus compliqué à terminer sans l’étape préalable de définir un cahier des charges et la répartition des tâches vue à l’IUT.
Nous avons beaucoup appris sur le plan relationnel.
En effet, quand on arrive dans une entreprise qu’on ne connaît pas, il peut être difficile de s’y retrouver tant sur le plan humain que les outils et l'infrastructure utilisé. Nous avons fait du mieux que nous pouvions pour nous intégrer au SICIO durant notre projet, participer à la vie de l’entreprise, s'intéresser aux différentes problématiques du SICIO.
Les réunions nous ont permis d’être plus à l’aise à l’oral et surtout les deux présentations que nous avons du faire, l’une au tout début pour présenter le déroulement du projet et la solution choisi, l’autre à la fin ou nous devions présenter la solution devant les salariés du SICIO.
Nous avons mis en pratique les enseignements appris à l’IUT, notamment en ce qui concerne la sécurité. A chaque étape du projet, nous avons pensé à la sécurité.
L’application Nextcloud est sécurisée “de base”, il n’y a pas de failles connues, les mises à jours de sécurité sont régulières.Nous faisons du chiffrement de bout en bout du client au serveur via des certificats SSL. Les utilisateurs et les droits sur notre serveur de base de donnée ont été créés avec le principe de “least privilege”, les utilisateurs ne disposent que des droits minimum à leurs bases de données. Les communications entre le serveur de base de donnée et le serveur web sont chiffrées pour les sauvegardes et les restaurations.