Livre blanc Service Manager - On Premise


Sommaire

         Download icon.png  Téléchargez le fichier PDF

Présentation

L’objectif de ce livre blanc est de vous aider à comprendre comment ev|Service Manager pourra s’intégrer dans votre environnement technique.

Chaque infrastructure client étant unique par ses contraintes et choix technologiques, chaque projet fera l’objet d’une étude spécifique lors des phases d’avant-vente et/ou d’installation.

Glossaire des produits

ev|Service Manager repose sur :

  • un service Front Office (Service Apps) : Fourniture d’un portail de services, paramétrable, à vos utilisateurs finaux ;
  • un service Back Office (Service Engine) : Fourniture d’une interface métier plus complète à vos équipes Back Office en charge de traiter les incidents, les changements, etc.

En fonction de votre projet, et notamment en fonction de la répartition de travail entre vos utilisateurs finaux (Portail) et vos équipes techniques, la partie Front Office peut dominer, ou bien la partie Back Office. L’architecture cible et l’intégration dans votre infrastructure devra tenir compte de cette répartition.

Architecture globale

Composants des différents services

Service Engine

  • Web Front End : En charge de traiter les requêtes http des utilisateurs et de retourner les pages web HTML.
  • Application Server : En charge de traiter les requêtes métier et de fournir les données nécessaires au serveur web, en tenant compte du compte connecté et de ce qu’il a le droit de faire et de voir.
  • Database Server : En charge de stocker les données.

Service Apps

  • Web Front End : En charge de traiter les requêtes http des utilisateurs et de retourner les pages web HTML.
  • Database Server : En charge de stocker les données.

Adaptabilité à vos contraintes

Une mise à l’échelle progressive

L’architecture de ev|Service Manager est évolutive ; elle peut être revue et modifiée en fonction de l’évolution de vos besoins. Vous pourrez ainsi démarrer votre projet sur un premier niveau d’architecture, puis revoir cette dernière si le nombre d’utilisateurs simultanés augmente, si vos règles de sécurité changent ou si vous ajoutez des fonctionnalités au périmètre initial de votre projet.

Chacune des couches peut être dimensionnée séparément avec plus ou moins de ressources en fonction des besoins identifiés.

Le schéma ci-dessous présente quelques exemples des architectures possibles (positionnement des frontaux web uniquement, les serveurs applicatifs et de bases de données se trouvant en LAN habituellement).

         Architecture.png

Montée en charge

Nos services peuvent aller de plateformes simples avec deux serveurs (un web et un applicatif/SQL), jusqu’à des configurations comprenant plusieurs dizaines de lignes, éventuellement réparties dans des zones de sécurité différentes.

Le premier critère de dimensionnement est lié à la montée en charge, l’objectif étant d’utiliser les deux dimensions qui sont à votre disposition :

  • Scale IN : Ajout de ressources CPU ou MEMOIRE sur les machines existantes pour leur permettre de soutenir une plus grande charge. Si cette méthode est intéressante financièrement (moins de VMs à gérer, moins de licences, etc.), elle atteint rapidement ses limites car certaines ressources internes aux systèmes ne sont pas extensibles (thread, etc.).
  • Scale OUT : Ajout de nouvelles machines qui assumeront une part de la charge. Cette solution est la plus souple mais elle impose de complexifier l’architecture en intégrant un load balancer pour répartir les utilisateurs sur les différents serveurs, un filer pour partager les ressources, etc.

Quelle que soit l’architecture, et sans autre contrainte que celle de la montée en charge, il est toujours intéressant d’utiliser au maximum le SCALE IN avant d’ajouter de nouvelles machines.

Résilience

Quel est le taux de disponibilité souhaité de la plateforme ? Un taux important (24/7 par exemple) impliquera une architecture plus complexe, intégrant des lignes supplémentaires par rapport aux conditions souhaitées de montée en charge.

Ces plateformes supplémentaires absorberont la charge en cas de panne d’une des lignes de base définies comme nécessaires pour soutenir la charge visée.

La solution technique dépendra de la tolérance que vous souhaitez, et donc de la dégradation du service ou de sa perte temporaire totale. Voici quelques exemples :

  • Perte temporaire d’une ligne EasyVista (web et/ou applicatif) : Ajouter une ligne supplémentaire.
  • Perte temporaire d’un serveur de base de données : Le serveur de base de données doit être monté en cluster pour une plus grande disponibilité. Mais si une perte de quelques heures est tolérable, une remontée de VM et un restore de base de données peuvent être suffisants.
  • Perte temporaire du load balancer : Mise en cluster du Load Balancer.load.

Nous vous conseillons d’intégrer ces ressources supplémentaires en permanence dans la chaîne de production plutôt que de les conserver éteintes et prêtes à être démarrées. Même si le coût d’une machine démarrée est supérieur à celui d’une machine éteinte, cela garantira totalement la bonne configuration / mise à jour de ces machines quand vous en aurez besoin.

Maintenabilité

Si votre politique sécurité vous impose une mise à jour régulière des systèmes d’exploitation, nous vous conseillons d’intégrer une ligne supplémentaire à ce qui a été déjà dimensionné pour la montée en charge.

Cette ligne supplémentaire, non intégrée dans le besoin en charge, va vous permettre de réaliser des mises à jour tournantes sur vos systèmes d’exploitation, sans pour autant impacter la production.

Voici un exemple avec trois lignes A, B et C (C ayant été ajoutée alors que seules A et B sont nécessaires pour la charge) :

  • A et B en production, C est sortie de production + mise à jour + retour en production.
  • A et C en production, B est sortie de production + mise à jour + retour en production.
  • B et C en production, A est sortie de production + mise à jour + retour en production.

A chaque étape, deux lignes sont disponibles, ce qui ne pénalise pas vos utilisateurs.

Ségrégation des accès Front Office / Back Office

Pour répondre à vos contraintes de sécurité, les tiers Front Office et Back Office sont séparables, ce qui vous permet de positionner par exemple une ou plusieurs lignes Front Office en DMZ (pour qu’elles soient accessibles de l’extérieur de votre réseau), alors que les lignes Back Office (voire certaines autres lignes Front Office) se trouveront en LAN (pour accès par vos équipes internes.

Pour rappel, et à moins qu’ils ne se connectent via un VPN à votre réseau, les utilisateurs d’applications mobiles produites avec Service Apps se trouvent en dehors de votre réseau LAN et devront passer par la DMZ pour accéder à l’application.

Load balancer

Nos services peuvent être placés derrière un load balancer, notamment pour équilibrer la distribution des utilisateurs qui souhaitent se connecter sur les différentes lignes disponibles.

Votre load balancer doit permettre la "persistance des sessions", c’est-à-dire qu’un utilisateur déjà authentifié via une des lignes doit revenir sur cette ligne tant qu’il reste connecté. Dans le cas contraire, l’authentification précédente de l’utilisateur ne sera pas trouvée et le service lui demandera de se reloguer.

Reverse proxy

Nos services peuvent être placés derrière un reverse proxy. Le reverse proxy peut, entre autres, modifier le type de la requête (https en entrée vers http sur le frontal web), mais il ne doit pas :

  • modifier les paramètres passés ;
  • modifier l’URL en elle-même (en ajoutant des répertoires, changeant le domaine, etc.).

Si le reverse proxy intègre des fonctionnalités de contrôle du contenu (WAF, antivirus, etc.), il ne doit pas modifier le contenu qui le traverse (paramètre, content, etc.) en dehors des paramètres HEADERS qui lui sont propres.

Sécurité de vos données en transit

Pour des raisons de confidentialité et d’intégrité des échanges, nous vous conseillons vivement de protéger les frontaux web Service Apps et Service Engine par des certificats SSL.

Nous vous préconisons de plus les points suivants :

  • Utilisez les certificats fournis par un tiers reconnu. Les certificats privés fonctionnent mais généreront beaucoup d’erreurs lors des accès en mobilité hors de votre réseau (téléphones portables, etc.).
  • Configurez votre couche SSL pour ne pas accepter les protocoles, ciphers, etc., connus comme faillibles :
    • SSL v2, SSL v3, TLS v1.0, TLS v1.1
    • RC4, 3DES, etc.
       

Voici un exemple sur lequel vous baser pour la configuration de la couche SSL.

SSLProtocol all -SSLv2 -SSLv3 -TLSv1 -TLSv1.1
SSLCompression off
SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK

Besoin d’autres environnements

En plus de l’environnement de production, vous pouvez monter des environnements complémentaires pour répondre à vos contraintes d’organisation.

Nous vous recommandons de monter et de maintenir au moins un environnement supplémentaire qui vous permettra de tester des changements avant de les appliquer sur votre environnement de production. Notamment :

  • les fix ou les évolutions majeures de nos produits ;
  • les changements de configuration des composants des serveurs (Apache, PHP, SSL, etc.) ;
  • les montées de version ou les fix des systèmes d’exploitation ou des composants des serveurs

Navigateurs

Fournisseurs

Le marché des navigateurs étant en constante évolution, merci de vous référer à notre page wiki Navigateurs web pris en charge pour la liste à jour de compatibilité des navigateurs.

Configuration

Pop-up et JavaScript doivent être activés et autorisés pour Service Apps.

Le cache local et les fichiers temporaires doivent avoir une limite suffisante (>10MB).

Si vous utilisez le protocole SSL, vérifiez que le cache de la page sécurisé est autorisé.

Pour Internet Explorer, l'option Options de sécurité/Téléchargements doit être réglée sur Demander confirmation pour les téléchargements de fichiers.

Antivirus

Sur le poste (PC) client, l’antivirus local ne doit pas systématiquement vérifier les fichiers .JS (JavaScript) pour éviter des problèmes de performances durant l’affichage des pages.

Autres

Nos services ne requièrent pas d’APPLET ou d’ActiveX sur le navigateur client.

Cookies

Nos services utilisent des cookies dans le but d’améliorer les fonctionnalités du site et l’expérience des utilisateurs. Les cookies ne contiennent aucune donnée personnelle ou critique.

Le navigateur doit autoriser nos services à créer des cookies.

Format des URL

3 URL doivent être mises à disposition par plateforme :

  • une pour Service Engine (Back Office) ;
  • une pour le tenant d’administration (Front Office) ;
  • une pour le tenant (Front Office) pour les utilisateurs finaux.
     

La racine xxxxx de l'URL https://xxxxx.yyyy.domaine doit être unique pour chaque plateforme et correspondre aux entrées des Virtual Host d’Apache sur les frontaux Web.

Zone de stockage accessible entre les serveurs

Zone de stockage partagée entre les serveurs web

En architecture multiligne, il est nécessaire de disposer d’une zone de stockage de fichiers accessible par les différents serveurs web afin qu’ils partagent des fichiers communs (ressources uploadées, styles, etc.).

Des liens symboliques sont créés sur les serveurs web pour pointer vers les ressources partagées en NFS (4.0 et supérieures) sur le "filer".

Zone d’échange de fichier entre le web Front End Service Engine et le serveur applicatif Service Engine

Cette zone sert lors des processus d’intégration de données.

En monoligne, elle se trouve habituellement sous la forme d’un répertoire sur le serveur web Front End Service Engine (SAMBA).

En multiligne, elle se trouve dans le "filer" partagé entre les différents serveurs web (SAMBA).

Quelques exemples d’architecture

Architecture monoligne en LAN ou en DMZ

Une seule ligne réduit les coûts d’hébergement, mais ne permet pas de garantir une disponibilité maximale.

Les serveurs "Application server" et "Database server" peuvent être regroupés sur une même machine, en dimensionnant en conséquence les ressources disponibles (CPU, RAM, Disque).
         Architecture - Monoline LAN or DMZ.png

Architecture multiligne

L’architecture multiligne permet de maîtriser la montée en charge (nombre de lignes de bases) et la haute disponibilité (une ligne en plus pour un service équivalent, même en perdant une des lignes).
         Architecture - Multiline.png

Architecture monoligne avec Front Office en DMZ et Back Office en LAN

Cette architecture permet d’améliorer la sécurité en n’autorisant l’accès Back Office qu’aux utilisateurs connectés au réseau de la société alors que l’accès au portail est disponible depuis Internet (éventuellement avec des limitations par IP, VPN, etc.).
         Architecture - Monoline BO LAN and FO DMZ.png

Architecture multiligne avec Front Office en DMZ et Back Office en LAN

Cette architecture permet d’allier disponibilité et sécurité en n’autorisant l’accès Back Office qu’aux utilisateurs connectés au réseau de la société alors que l’accès au portail est disponible depuis Internet (éventuellement avec des limitations par IP, VPN, etc.).
         Architecture - Multiline BO LAN and FO DMZ.png

Interopérabilité technique

REST

Fournisseur REST et SOAP 1.2

Nous produisons des services accessibles en REST et SOAP 1.2.

Client REST et SOAP 1.2

Les services peuvent consommer des services REST ou SOAP 1.2 externes.

Messagerie

Envoi d'e-mails

Service Engine et Service Apps doivent accéder à votre serveur de messagerie pour envoyer des e-mails à vos utilisateurs dans le cadre du traitement des incidents / changements.

Les protocoles suivants sont supportés : SMTP / SMTPS / SMTPS with TLS

Création automatique de tickets par e-mails

Service Engine doit pouvoir accéder à des boîtes de messagerie fonctionnelles auxquelles vos utilisateurs pourront envoyer des messages qui seront automatiquement transformés en tickets dans l’application.

Les protocoles suivants sont supportés :

  • POP3 / POP3S
  • IMAP4 / IMAP4S / IMAP + TLS / IMAPS +TLS

Dimensionnement CPU et RAM des serveurs

Attention : Ces chiffres sont donnés à titre indicatif car, en plus du nombre d’utilisateurs, les ressources nécessaires vont varier en fonction du nombre d’incidents/demandes créés quotidiennement, de l’activité web service et du type d’utilisation (Front Office, Back Office). Les abaques fournis ont été déterminés sur la base de notre expérience en SaaS.

Pour rappel, votre architecture cible sera constituée d’un ou plusieurs serveurs décrits ci-dessous.

Web Front End

Les dimensionnements sont donnés pour 100 utilisateurs en pic d’utilisation, de façon à obtenir une qualité de service optimale.

Le serveur est dédié à l’application Service Engine. La mutualisation n’est pas supportée. 

Un chiffre minimum est donné également et représente les ressources minimales à mettre en œuvre, même si le nombre d’utilisateurs est très inférieur à 100.

Cas d’usage Optimal Minimal
Le serveur sert uniquement pour Service Apps 2vCPU, 4Go RAM 2vCPU, 4Go RAM
Le serveur sert uniquement pour Service Engine 4vCPU, 4Go RAM 2vCPU, 4Go RAM
Le serveur sert pour Service Engine et Service Apps 4vCPU, 8Go RAM 2vCPU, 4Go RAM

Application Server

Les dimensionnements sont donnés pour 100 utilisateurs en pic d’utilisation, de façon à obtenir une qualité de service optimale.

Le serveur est dédié à l’application Service Engine. La mutualisation n’est pas supportée. 

Un chiffre minimum est donné également et représente les ressources minimales à mettre en œuvre, même si le nombre d’utilisateurs est très inférieur à 100.

Cas d’usage Optimal Minimal
Le serveur sert uniquement de serveur applicatif 2vCPU, 6 Go RAM 2vCPU, 4 Go RAM
Le serveur sert de serveur applicatif et de serveur de base de données 4vCPU, 8 Go RAM 4vCPU, 8 Go RAM

Database Server

Les ressources dépendent principalement de la taille de votre base de données, de façon que les données soient montées en mémoire le plus souvent (optimisation des requêtes) et que le nombre de CPU soit suffisant pour traiter les requêtes.

Une fois encore, ce dimensionnement ne peut que donner une idée générale de la cible et non une vision précise, du fait des nombreux paramètres qui entrent en œuvre.

L’instance SQL Server est dédiée à l’application Service Engine. Le serveur SQL Server peut supporter le multi-instances. Cependant les ressources appropriées (CPU, RAM, espace disque) doivent être allouées au serveur.

Cas d’usage Optimal Minimal
Licence de moins de 100 utilisateurs 4vCPU, 16 Go RAM 2vCPU, 6 Go RAM
Licence de plus de 100 utilisateurs 8vCPU, 32 Go RAM 4vCPU, 20 Go RAM

Dimensionnement de l’espace disque des serveurs

Web Front End - Service Apps

Cette section vous propose une configuration pour les ressources utiles au fonctionnement de Service Apps. Elle ne traite pas des volumes supplémentaires en fonction de vos contraintes d’exploitation comme :

  • les sauvegardes en local avant externalisation ;
  • le stockage des fichiers de session en fonction du projet ;
  • les composantes des socles Apache, PHP, MySQL, etc. ;
  • les fichiers de session PHP.
     

Espaces nécessaires pour le fonctionnement :

  • Noyau Service Apps sur chaque serveur Linux = 4 Go
  • Partage (Ressource partagée entre tous les frontaux web pour le design des applications, etc.) = 20Go minimum. Peut être plus grand en fonction du nombre de projets, de vos backups, etc. Un espace de 100Go est habituellement conseillé.
  • Bases MySQL (Sur le serveur où se trouve MySQL) = 4Go

Web Front End - Service Engine

En monoligne : 80Go libre sur le nœud web Front End

En multiligne :

  • 50Go sur chaque nœud web Front End libre
  • Minimum 100Go libre sur le répertoire partagé "filer". Cet espace variera notamment en fonction du nombre et de la taille des documents attachés aux incidents / changements ouverts par vos utilisateurs.
     

Remarque : Si le serveur joue également le rôle de "Web Front End" Service Apps, ajoutez l’espace disque propre à ce type de serveur.

Application Server - Service Engine

80Go d’espace disque libre

Database Server - Service Engine

Les groupes de bases suivants sont installés sur le serveur de base de données :

  • Bases du noyau Service Engine : 1Go
  • Base de démo (Config + Data) : 2Go (9 000 utilisateurs, 40 000 matériels)
  • Base de production + base de Sandbox : Livrées vides, ces bases peuvent varier :
    • linéairement par rapport à la base de démonstration sur les parties employés et matériels ;
    • en fonction de votre activité concernant la gestion des incidents, des changements, etc. Nos statistiques donnent habituellement 1Go pour 2 000 incidents / changements avec une pièce jointe en moyenne par requête.

Front Office (Service Apps)

Vocabulaire

Instance : Moteur Apps Builder indépendant qui sera utilisé dans le cadre des montées de versions, recette, retour arrière.

Tenant : Cage sécurisée sur Service Apps, qui contient les applications.

Apps Connector pour Service Engine : Jeu de fichiers qui doivent être placés sur les frontaux web Service Engine.

  • Ils seront utilisés pour réaliser l’interface entre les deux applications.
  • Ils incluront des clés dédiées comme signature entre les plateformes.

Trusted Identity Provider (TIP) : Systèmes externes (LDAP, SSO, ...) qui seront utilisés pour l’authentification des utilisateurs Service Apps.

Prérequis techniques

MySQL version 5.7

Sécurisation des échanges entre les plateformes

Protection contre les URL modifiées

Lors des échanges, Service Apps vérifie l’authenticité de la demande, notamment à travers l’utilisation de jetons uniques entre les questions et les réponses.

Protection contre la capture des paquets

Les échanges dans les deux sens sont signés avec une paire de clés SSL (2 048 bits).

Les données sont cryptées en AES256, avec un jeu de clés privées spécifique à la plateforme Service Apps.

Matrice de flux

Source Destination Ports UDP / TCP
Vos utilisateurs Serveur web 443 (https) TCP
Serveur web Service Apps Serveur web Service Engine 443 (https) TCP
Serveur web Service Apps MySQL 3306 TCP
Serveur web Service Apps Serveur Fichier 445 (SMB Windows 2008/2012) TCP

Back Office (Service Engine)

Prérequis techniques

Vue générale

Tiers Prérequis
Serveur web
  • Type : Physique ou virtuel
  • OS : Linux
  • Apache Apache 2.4.6 et supérieurs
  • PHP : 7.2, 7.3
Serveur applicatif
  • Type : Physique ou virtuel
  • OS : Windows Windows 2012 Server et supérieurs avec les derniers services pack installés. Version 64 bits obligatoire
  • Client SQL : Un client SQL Server complet doit être installé sur le serveur, dans la version de SQL Server correspondant à votre serveur de base de données, avec notamment les outils SQLCMD et BCP
Serveur SQL Server
  • Type : Physique ou virtuel
  • OS : Tous ceux supportés par la version des bases de données
  • SQL Server : SQL Server Windows 2016 SP2
  • Notes :
    • Les versions supérieures ne sont pas encore validées. Les versions LINUX ne sont pas encore supportées, quelle que soit la version.
    • FILESTREAM doit être activé dans l'instance SQL Server.
    • Full-Text doit être activé dans l'instance SQL Server.
    • Le niveau de licence doit être adapté à vos besoins. Nous vous recommandons vivement d’utiliser au minimum la version WEB EDITION pour une utilisation classique, et une version STANDARD si vous disposez de plus de 150 utilisateurs connectés simultanément.
    • Le niveau de licence utilisé doit correspondre à vos besoins sur 5 ans. Par exemple, la version Express de SQL Server ne permet pas d’utiliser des bases de plus de 10Go.

Web Front End

L’installation et la maintenance du système d’exploitation ainsi que des composants Apache et PHP sont de votre responsabilité.

Nous fournissons des fichiers de configuration par défaut, qui correspondent aux bonnes pratiques que nous recommandons en termes de sécurité, résilience et maintenabilité. Les points techniques les plus importants sont décrits dans les annexes suivantes (Configuration Apache, Configuration PHP).

Application Server

Le serveur applicatif ne fonctionne que sur des processeurs x86.

Le serveur applicatif doit accéder à un des répertoires publiés sur le ou les serveurs web (Samba, etc.).

L’installation et la maintenance du système d’exploitation est de votre responsabilité.

Database Server

L’installation et la maintenance du système d’exploitation ainsi que de SQL Server sont de votre responsabilité.

Matrice de flux

Source Destination Ports UDP / TCP
Vos utilisateurs Serveur web 443 (https) TCP
Serveur applicatif Serveur SQL Server 1433 TCP

Authentification des utilisateurs

Répartition des rôles

Authentification et autorisation

Pour Service Engine et Service Apps, on distingue :

  • l’authentification : Confirmation de l’identité de la personne qui cherche à se connecter ;
  • l’autorisation : Qu’est-ce que la personne qui a été identifiée a le droit de faire sur Service Engine et Service Apps.

Authentification des utilisateurs dans Service Engine

Service Engine dispose des moyens d’authentification suivants :

  • Authentification par la base des employés internes de l’application
  • Authentification reposant sur votre (ou vos) annuaire(s) LDAP/AD
  • Authentification reposant sur un SSO compatible avec nos services
     

L’ordre de traitement des autorisations est le suivant :

1. Identification basée sur SSO
2. Si l’étape 1 n’est pas réussie, authentification par Login/Mot de passe basée sur votre (ou vos) annuaire(s) LDAP/AD
3. Si l’étape 2 n’est pas réussie, authentification par Login/Mot de passe basée sur l’annuaire interne Service Engine

         User authentication - SE.png

L’authentification interne Service Engine peut être désactivée. Toutefois, cette désactivation n’est pas possible si vous utilisez Service Engine comme fournisseur de services REST car, dans ce cas, l’authentification se fait par l’annuaire interne Service Engine.

Vous pouvez utiliser plusieurs annuaires (ou branches du même annuaire) pour authentifier vos utilisateurs. Dans ce cas, les authentifications seront réalisées en testant les annuaires dans l’ordre déclaré.

Authentification des utilisateurs dans Service Apps

Service Apps dispose des moyens d’authentification suivants :

  • Authentification par la base des employés internes de l’application
  • Authentification à travers de Service Engine (Trusted Provider). Dans ce cas, les moyens d’authentification configurés pour Service Engine seront utilisés de façon transparente pour Service Apps.

         User authentication - SA.png

Autorisation des utilisateurs

Une fois identifié, la détermination de ce que l’utilisateur a le droit de faire et sur quoi se fera sur :

  • Service Engine : les profils (ce que l’utilisateur peut faire) et les domaines (ce que l’utilisateur peut voir) ;
  • Service Apps : les groupes d’application qui définiront les applications accessibles et le rôle associé à l’utilisateur sur chacune de ces applications.

Service Engine - Authentification interne

Les mots de passe sont hashés puis stockés (non réversible).

Une politique de taille et de structure des mots de passe peut être définie.
         User authentication - SE Internal.png

Service Engine - Authentification par des serveurs ou arbres LDAP/AD

L’authentification Service Engine peut reposer sur plusieurs arbres LDAP/AD différents.
         User authentication - SE Multi servers.png

Service Engine - SSO (Single Sign On)

Présentation

Service Engine peut authentifier les utilisateurs à travers la fourniture d’une information d’identité par vos systèmes. Les systèmes suivants sont supportés :

  • SAML et ADFS 
  • CAS

SSO par SAML/ADFS ou CAS

Votre fédérateur d’identité est configuré dans nos services pour que l’identification de l’utilisateur soit fournie lors de la première connexion à nos services.
         User authentication - SE SSO.png

Systèmes supportés mais non conseillés

Si vous disposez quelque part dans votre réseau d’un serveur IIS, il peut être utilisé pour porter l’identité de votre utilisateur vers nos services.

Attention : Il ne s’agit en aucun cas de SSO, mais bien de "portage d’identité" (On récupère comme on peut l’identité de l’utilisateur, et on la transfère à nos services par le biais d’un header encrypté). Vous devez considérer cette fonctionnalité comme une facilité de connexion pour vos utilisateurs, mais en aucun cas comme une solution totalement sécurisée, en comparaison de vrais systèmes de SSO comme SAML/ADFS ou CAS qui intègrent de multiples protections comme :

  • l'unicité par token de chaque transaction ;
  • les échanges de clés ;
  • le refus des réponses non sollicitées ;
  • l'impossibilité de se placer en "man in the middle" ;
  • la restriction des systèmes autorisés à réaliser des authentifications, et la limite du périmètre d’information accessible ;
  • la traçabilité et les alertes.
     

De plus, ces systèmes reposent sur le fait que l’utilisateur a déjà été identifié au niveau du réseau. Par conséquent, cela ne peut pas fonctionner si nos services doivent être accédés via un réseau public (ce qui est notamment le cas des applications mobiles, à moins d’utiliser un VPN pour simuler une présence réseau interne).

Système d’authentification propre à votre entreprise

Tout système d’identification propre à votre entreprise pourra être étudié afin de voir comment il peut être utilisé par nos services (notamment en termes de disponibilité, accessibilité et sécurité).

En fonction de leur complexité, l’étude, le développement spécifique et l’implémentation de ce type d’authentification pourra faire l’objet d’une facturation spécifique.

Systèmes non supportés et non maintenus

Note : Cette partie concernent tous les modes d’identification non cités précédemment.

S’il est toujours possible techniquement d’utiliser des modes d’authentification basés sur une récupération de l’identité de l’utilisateur qui accède aux ressources (sspi, kerberos, etc.) via un module Apache, ces techniques ne sont pas supportées, et ce pour les raisons suivantes (en plus des raisons déjà évoquées pour IIS dans la section précédente) :

  • les modules APACHE que vous trouverez (mod sspi, mod auth kerb, etc.) ne disposent pas de mise à jour depuis plusieurs années et présentent de nombreuses failles de sécurité ;
  • il est difficile de mettre en œuvre ce type d’identification avec des systèmes déportés (Office 365, etc.) ou de natures différentes (Windows, Linux, versions anciennes, etc.).
     

Vous ne recevrez pas d’assistance ni de maintenance si vous utilisez ce type d’authentification.

Nous vous engageons à utiliser de préférence des systèmes récents de SSO comme SAML/ADFS ou CAS qui garantissent à la fois la sécurité et l’accessibilité des authentifications.

Service Apps - Authentification interne

Les mots de passe sont stockés sous la forme d’un hash (non réversible).

Dans l’annuaire Service Apps, les utilisateurs sont désignés par leur adresse e-mail qui sert d’identifiant de connexion pour Service Apps. Par conséquent, chaque adresse e-mail ne peut être utilisée qu’une seule fois par tenant et pour identifier un seul et même utilisateur.

Une fois identifié par un fournisseur d’identité approuvé EasyVista, l’utilisateur peut être retrouvé dans l’annuaire Service Apps à partir de l’adresse e-mail associée à sa fiche Employé dans l’annuaire Service Engine.

Si plusieurs utilisateurs Service Engine partagent la même adresse e-mail, ils accèdent au même compte d’utilisateur dans Service Apps.
         User authentication - SA Internal.png

Service Apps - Trusted Provider reposant sur Service Engine

Service Apps peut utiliser Service Engine pour authentifier l’utilisateur et faire un premier niveau d’autorisation.

Dans ce cas :

  • L’authentification est gérée par Service Engine suivant les méthodes configurées (Interne, Multi LDAP/AD, SSO).
  • Service Engine réalise également un premier niveau d’autorisation (l’utilisateur est connu et actif, il dispose d’une langue, etc.).
  • Une fois l’utilisateur validé par Service Engine, Service Apps accepte l’utilisateur et l’ajoute dans sa base locale si besoin.
     

Les informations suivantes sont transmises par Service Engine pour que Service Apps puisse alimenter automatiquement son annuaire interne et sa gestion des droits :

  • Nom complet de l’employé
  • Adresse e-mail de l’employé
  • Une ou plusieurs des valeurs suivantes :
    • Nom des groupes (en anglais) dont l’employé fait partie
    • Nom de profil (en anglais) associé à l’employé
    • Un champ issu de la fiche de l’employé
       

Un seul Trusted Provider peut-être associé à un tenant Service Apps.

Gestion des autorisations

Service Engine

Dans Service Engine, un utilisateur se voit attribuer :

  • un profil unique : Il détermine ce que l’utilisateur a le droit de faire sur l’ensemble de données auquel il a accès ;
  • un ou plusieurs domaines : Ils déterminent les périmètres de données auxquels l’utilisateur a le droit d’accéder (par exemple une zone géographique, un type de machine de quelques entités, etc.).

Service Apps

Comment les droits d’accès à une application sont-ils accordés ?

Un utilisateur Service Apps peut être membre de plusieurs groupes et avoir accès à :

  • des applications directement, car il en est le propriétaire ou qu’on lui a donné le droit de les utiliser ;
  • des applications par l’intermédiaire d’équipes dont il est membre et qui disposent des droits d’accès requis.

         User authentication - SA Application access.png

Comment les équipes sont-elles identifiées dans l’annuaire Service Apps ?

Dans l’annuaire Service Apps, les équipes sont identifiées par leur nom.

Ces noms d’équipes Service Apps sont liés au nom ANGLAIS des groupes Service Engine.

Annexes

Configuration spécifique aux serveurs Windows

Système

Le codepage de “cmd” doit être 850 (utilisez la commande "chcp" sous "cmd" pour vérifier l’état actuel du paramètre).

Network

IPV6 n’est pas utilisé et vous pouvez désactiver cette couche si besoin sur vos serveurs.

Les paramètres SOCKET de la couche IPV4 doivent être configurés dans la base de registre pour absorber les échanges entre les différents composants.


HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
MaxUserPort ->60 000
TcpTimedWaitDelay -> 30

Ils doivent également être configurés au niveau de NETSH.


netsh int ipv4 set dynamicportrange tcp start=32767 num=32768

Antivirus

L’antivirus local doit être configuré pour ne pas scanner les répertoires suivants :

  • Répertoire de stockage des logs applicatifs (fichiers au format XML)
  • Répertoire de stockage des bases SQL Server, des logs SQL Server

.NET

La version 4.5 ou supérieure doit être installée sur le serveur (en fonction de la configuration et de la version de SQL Server ; une version inférieure peut également être nécessaire en complément).

Configuration spécifique aux serveurs Linux

Network

IPV6 n’est pas utilisé et vous pouvez désactiver cette couche si besoin sur vos serveurs.

Sécurité

SELinux en mode Permissive est supporté (Certaines opérations manuelles comme la création de compte avant l’installation pourra cependant être nécessaire). En mode ENFORCING, une analyse complémentaire et spécifique est nécessaire.

Configuration spécifique à Apache

Modules à intégrer

  • core
  • so
  • headers
  • deflate or filter
  • reqtimeout
  • mime
  • log_config
  • env
  • auth_basic
  • setenvif
  • version
  • slotmem_shm
  • ssl
  • mpm_prefork
  • unixd
  • alias
  • rewrite
  • http
  • access_compat
  • autoindex
  • dir
  • php7
     

Si vous souhaitez intégrer le module server-status (optionnel) pour intégrer la surveillance d'Apache dans votre outil de sur surveillance interne, intégrez également les modules suivants :

  • status
  • lbmethod_byrequests
  • lbmethod_bytraffic
  • lbmethod_bybusyness
  • lbmethod_heartbeat

Pour compiler Apache

Inspirez-vous de la commande suivante, notamment pour intégrer SOCKET dans la compilation.

./configure --prefix=/usr/local/apache2
               --exec-prefix=/usr/local/apache2
               --sysconfdir=/usr/local/apache2/conf
               --with-suexec-bin=/usr/local/apache2/bin/suexec
               --enable-authnz-fcgi
               --enable-mods-shared=most
               --enable-mpms-shared=all
               --enable-suexec=shared
               --with-apr=/usr/local/apr/bin/apr-1-config
               --with-apr-util=/usr/local/apr/bin/apu-1-config
               --with-suexec-docroot=/var/www
               --with-suexec-uidmin=120
               --with-suexec-gidmin=120
               --enable-ssl
               --enable-ssl-staticlib-deps
               --with-sslport=443
               --with-ssl=/usr/local/openssl
               --with-mpm=prefork
               --enable-static-rotatelogs
               --enable-so
               --enable-info
               --enable-dir
               --enable-mime-magic
               --enable-expires
               --enable-headers
               --enable-rewrite
               --enable-cgi
               --enable-cgid
               --enable-cache
               --enable-disk-cache
               --enable-mem-cache
               --enable-slotmem-plain
               --enable-slotmem-shm
               --enable-proxy            
               --enable-lbmethod-byrequests
               --enable-lbmethod-bytraffic
               --enable-lbmethod-bybusyness
               --enable-lbmethod-heartbeat
               --enable-proxy-scgi
               --enable-proxy-http
               --enable-proxy-ftp
               --enable-proxy-fdpass
               --enable-proxy-fcgi
               --enable-proxy-express
               --enable-proxy-connect
               --enable-proxy-balancer
               --enable-proxy-ajp
               --enable-dav
               --enable-dav-fs
               --enable-dav-lock
               --enable-deflate
               --with-deflate
               --with-pcre=/usr/local/pcre
               --with-nghttp2=/usr/local/nghttp2
               --enable-http2
               --enable-proxy-http2

Sécurité des accès aux répertoires

Pour sécuriser les accès au répertoire qui contient les sources


<Directory "EasyVista_document_root">
Options -Indexes -FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>

Sécurité

Header edit Set-Cookie "(?i)^((?:(?!;\s?HttpOnly).)+)$" "$1; HttpOnly"
Header edit Set-Cookie "(?i)^((?:(?!;\s?Secure).)+)$" "$1; Secure"
ServerTokens Prod
ServerSignature Off
TraceEnable Off
SetEnvIfNoCase Request_URI \.(?i:gif|jpg|jpeg|pngi|jar)$ no-gzip
FileETag none
<IfModule mod_headers.c>
Header unset Server
Header unset ETag
Header set X-Frame-Options: "sameorigin"
Header append Vary User-Agent env=!dont-vary
Header set X-Content-Type-Options "nosniff"
Header set X-XSS-Protection "1; mode=block"
</IfModule>

Performances

HostnameLookups OFF
TimeOut 300
KeepAlive on
MaxKeepAliveRequests 500
KeepAliveTimeout 3
HostnameLookups off
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch ".*MSIE [456].*" nokeepalive
AddOutputFilter DEFLATE html php evsa js json htm svg gif tsv png ico css woff ttf eot

Montée en charge

<IfModule prefork.c>
StartServers 8
MinSpareServers 8
MaxSpareServers 30
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 100000
</IfModule>

Gestion du cache

ExpiresActive On
ExpiresByType image/jpg "access plus 86400 seconds"
ExpiresByType image/jpeg "access plus 86400 seconds"
ExpiresByType image/png "access plus 86400 seconds"
ExpiresByType image/gif "access plus 86400 seconds"
ExpiresByType image/ico "access plus 86400 seconds"
ExpiresByType image/icon "access plus 86400 seconds"
ExpiresByType image/x-icon "access plus 86400 seconds"
ExpiresByType text/css "access plus 86400 seconds"
ExpiresByType text/javascript "access plus 86400 seconds"
ExpiresByType text/html "access plus 86400 seconds"
ExpiresByType application/xhtml+xml "access plus 86400 seconds"
ExpiresByType application/javascript "access plus 86400 seconds"
ExpiresByType application/x-javascript "access plus 86400 seconds"
ExpiresByType application/x-shockwave-flash "access plus 86400 seconds"

Configuration des URL

L’accès doit être direct au répertoire qui contient "index.php", sans utiliser de sous-niveaux.

Autorisé : https://easyvista.mycompany.com

Interdit : https://projects.mycompany.com/easyista

Format des logs

Si ce n‘est pas obligatoire, le respect de notre standard de format des logs d’accès permettra de simplifier les analyses au support.

Dans certains cas, ce format devra impérativement être mis en place, notamment lorsque l’analyse en masse des fichiers est nécessaire. Nous vous conseillons donc de le mettre en place dès le début du projet.

Si vous utilisez un accès SSL :

LogFormat "\"%t\" \"%D\" \"%H\" \"%{Referer}i\" \"%{User-Agent}i\" \"%U\" \"%a\" \"%X\" \"%>s\" \"%b\" \"%r\""

Si vous n’utilisez pas SSL :

LogFormat "\"%t\" \"%D\" \"%H\" \"%{Referer}i\" \"%{User-Agent}i\" \"%U\" \"%a\" \"%X\" \"%>s\" \"%b\" \"%r\" \"%{SSL_PROTOCOL}x\" \"%{SSL_CIPHER}x\""

Configuration spécifique à PHP

Modules à charger

  • session
  • sockets
  • curl
  • json
  • libxml
  • iconv
  • zlib
  • dom
  • filter
  • OPcache
  • Openssl
  • Gd
  • Simplexml
  • mysqli
  • mbstring

Note : Les options Hash et Fileinfo ne doivent pas être désactivées au niveau du noyau PHP.

Modules à charger si vous utilisez SSO par SAML/ADFS ou CAS

  • Xml
  • XmlReader
  • XmlWriter

Pour compiler PHP

Vous pouvez vous inspirer de la commande suivante si vous souhaitez compiler PHP sur votre serveur :

./configure --prefix=/usr/local/php
            --with-fpm-user=www-run
            --with-fpm-group=www   
            --with-openssl=/usr/local/openssl
            --with-zlib
            --enable-bcmath
            --enable-calendar
            --enable-ftp
            --with-gettext
            --enable-mbstring
            --with-mysql
            --with-mysqli
            --with-pdo-mysql
            --with-bz2
            --enable-dba=shared
            --enable-soap
            --enable-sockets
            --enable-shmop
            --enable-exif
            --with-gd
            --enable-intl
            --with-unixODBC=/usr
            --enable-zip
            --enable-wddx
            --enable-sysvsem
            --enable-sysvshm
            --enable-sysvmsg
            --with-mhash
            --with-readline
            --with-libedit
            --with-pdo-odbc=unixODBC,/usr
            --enable-zend-signals
            --with-mssql=/usr/local/freetds
            --enable-opcache
            --with-pcre-dir=/usr/local/pcre
            --with-curl=/usr/local/curl
            --with-apxs2=/usr/local/apache2/bin/apxs
            --with-jpeg-dir
            --with-png-dir
            --with-freetype-dir

Paramètres à configurer dans PHP.INI

open_basedir must be commented out
zend_extension="/[YourFolderName]/opcache.so" short_open_tag = Off
precision = 14
zend.enable_gc = On
Expose_php = Off
error_reporting = E_ALL & ~~E_NOTICE
display_errors = Off
log_errors = On
log_errors_max_len = 1024
track_errors = On
error_log = should be set
variables_order = GPCS
request_order = GP
auto_globals_jit = On
default_charset = UTF-8
file_uploads = On
default_socket_timeout = 60
max_execution_time = 300
max_input_time = 300
memory_limit = 512M
post_max_size = 800M
upload_max_filesize = 800M
max_file_uploads = 20
max_input_vars = 5000
session.save_handler = files
session.save_path = should be filled in
Session.use_cookies = Off
Session.name = PHPSESSID
Session.auto_start = Off
Session.cookie_lifetime = Off
Session.serialize_handler = php
Session.gc_probability = 1
Session.gc_divisor = 1000
Session.gc_maxlifetime = 18000
Session.cache_expire = 180
Session.use_trans_sid = Off Session.hash_function = Off
Session.hash_bits_per_character = 5

Configuration spécifique à MySQL

MySQL doit être en mode "No_engine_substitution". Pour ce faire il faut ajouter la ligne suivante dans le fichier /etc/my.cnf.

sql_mode = ‘NO_ENGINE_SUBSTITUTION’

Configuration spécifique à SQL Server

Sort order = Latin1_General_CI_AS
Mixed mode authentication required
Automatic growing of tempdb or at least 1GB
Database configured with READ_COMITTED_SNAPSHOT
FullText search must be installed and available
Max Degree of Parallelism must be 1
Tags:
Modifié par Utilisateur inconnu le 2020/04/10 17:50
Créé par Administrator XWiki le 2018/11/20 16:32

Raccourcis

L'actualité mensuelle
•  Newsletter

Tous les changements
•  Service Manager
•  Service Apps
•  Self Help

Glossaire

Powered by XWiki ©, EasyVista 2020