Livre blanc Service Manager - On Premise
- Présentation
- Glossaire des produits
- Architecture globale
- Quelques exemples d'architecture
- Interopérabilité technique
- Dimensionnement CPU et RAM des serveurs
- Dimensionnement de l'espace disque des serveurs
- Front Office (Service Apps)
- Back Office (Service Engine)
- Authentification des utilisateurs
- Gestion des autorisations
- Annexes
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 ses habilitations.
- 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.
- Il s'interface avec les ressources de Service Engine : le/les serveur(s) Web Front End et le/les Application Server(s).
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).
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 continuité de service souhaité de la plateforme ? Un taux important 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 ou 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.
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.
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.
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 obtenir la liste à jour des navigateurs compatibles.
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 (>10 MB).
Si vous utilisez le protocole SSL, vérifiez que le cache de la page sécurisé est autorisé.
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
Quatre URL doivent être mises à disposition par plateforme :
- Une pour Service Engine (Back Office).
- Une pour le tenant de l'environnement de démonstration / formation (Front Office) pour les utilisateurs finaux.
- Une pour le tenant de l'environnement de production (Front Office) pour les utilisateurs finaux.
- Une pour le tenant de l'environnement de sandbox (test) (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 multiligne
L'architecture multiligne permet de maîtriser la montée en charge (nombre de lignes de bases) et la continuité de service (une ligne en plus pour un service équivalent, même en perdant une des lignes).
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 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.).
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.
Les e-mails peuvent être protégés par : DMARC / SPF / DKIM.
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.
- Office 365 correspond à IMAP4 en authentification moderne (XOAUTH2).
- Microsoft Graph utilisant l'API REST Outlook avec une authentification moderne OAUTH2.0 en HTTPS.
Dimensionnement CPU et RAM des serveurs
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 Backoffice 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 | 2 vCPU, 4 Go RAM | 2 vCPU, 4 Go RAM | ||
Le serveur sert uniquement pour Service Engine | 4 vCPU, 4 Go RAM | 2 vCPU, 4 Go RAM | ||
Le serveur sert pour Service Engine et Service Apps | 4 vCPU, 8 Go RAM | 2 vCPU, 4 Go RAM |
Application Server
Les dimensionnements sont donnés pour 100 Backoffice 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 | 2 vCPU, 6 Go RAM | 2 vCPU, 4 Go RAM | ||
Le serveur sert de serveur applicatif et de serveur de base de données | 4 vCPU, 8 Go RAM | 4 vCPU, 8 Go RAM |
Database Server
Les dimensionnements sont donnés pour 100 Backoffice utilisateurs en pic d'utilisation, de façon à obtenir une qualité de service optimale.
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 | 4 vCPU, 16 Go RAM | 2 vCPU, 12 Go RAM | ||
Licence de plus de 100 utilisateurs | 8 vCPU, 32 Go RAM | 4 vCPU, 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, 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.) = 20 Go minimum. Peut être plus grand en fonction du nombre de projets, de vos backups, etc. Un espace de 100 Go est habituellement conseillé.
Web Front End - Service Engine
En monoligne : 80 Go d'espace disque libre sur le nœud web Front End
En multiligne :
- 50 Go d'espace disque libre sur chaque nœud web Front End.
- Minimum 100 Go d'espace disque 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.
Application Server - Service Engine
80 Go 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 : 10 Go.
- Base de démo (Config + Data) : 4 Go (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 1 Go 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
Service Apps est déployé sur les mêmes frontaux Web que Service Engine, cependant des serveurs Web peuvent être dédiés à cette partie de la solution (exemple : Service Apps en DMZ).
Tiers | Prérequis |
---|---|
Serveur web |
|
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 Service Apps
Source | Destination | Port | Remarques |
---|---|---|---|
Vos utilisateurs | Reverse proxy Load Balancer (Optionnel) | 443 (https) | |
Reverse proxy Load Balancer (Optionnel) | Serveur web Service Apps | 443 (https) | |
Serveurs web Service Apps | Serveurs web Service Engine | 443 (https) | Flux interrogation de Service Engine vers Service Apps (EZV API) |
Serveurs web Service Engine | Serveurs web Service Apps | 443 (https) | Intégration des portails Service Apps dans Service Engine |
Serveurs web Service Apps | Serveurs applicatifs | 2XXXX – 2XXXX | |
Serveurs web Service Apps | Serveur Fichier | 445 (SMB Windows 2008/2012) | |
Serveurs web Service Apps | Serveur SMTP | 25/465 |
Back Office (Service Engine)
Prérequis techniques
Vue générale
Tiers | Prérequis | |
---|---|---|
Serveur web |
|
|
Serveur applicatif |
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 |
Notes :
|
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 x64.
Le serveur applicatif doit accéder à un des répertoires publiés sur le/les serveur(s) web ou serveur de fichiers (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 Service Engine
Source | Destination | Port | Remarques |
---|---|---|---|
Vos utilisateurs | Reverse proxy Load Balancer (Optionnel) | 443 (https) | |
Reverse proxy Load Balancer (Optionnel) | Serveurs web | 443 (https) | |
Serveurs web Service Engine | Serveurs applicatifs | 2XXXX – 2XXXX | |
Serveurs web Service Engine | URL web Service Apps | 443 (https) | Flux utile pour l'intégration de Service Apps vers Service Engine |
Serveurs web Service Engine | Serveurs Fichier | 445 | |
Serveurs applicatifs | Serveurs web Service Engine | 443 (https) | Flux pilotage REST Service sortants. Chaque serveur applicatif est lié à son frontal web. |
Serveurs applicatifs | Serveur LDAP | 389/636 | |
Serveurs applicatifs | Serveur POP3/IMAP | 110/995 143/993 | |
Serveurs applicatifs | Serveur SMTP | 25/465 | |
Serveurs applicatifs | Serveur SQL Server | 1433 | |
Serveurs web Service Engine | Serveurs web Self Help de présentation | 443 (https) | Si Self Help intégré au projet |
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 Manager
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.
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 ou l'authentification AD LDAP.
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 s’appuie sur les moyens d’authentification configurés pour Service Engine seront utilisés de façon transparente pour Service Apps.
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 Manager - 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.
Service Manager - Authentification par des serveurs ou arbres LDAP/AD
L'authentification Service Engine peut reposer sur plusieurs arbres LDAP/AD différents.
Service Manager - 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.
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.
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
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.
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.
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.
MaxUserPort ->60 000
TcpTimedWaitDelay -> 30
Ils doivent également être configurés au niveau de NETSH.
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
- http
- ssl (Recommandé : 443)
- expires
- dir
- auth_basic
- access_compat
- socache_shmcb (recommandé pour cache SSL)
- reqtimeout
- filter
- deflate
- mime
- log_config
- env
- headers
- unique_id (Pour debug)
- setenvif
- version
- slotmem_shm
- unixd
- alias
- rewrite
- mpm_prefork (Facultatif : si mode=prefork)
- mpm_event (Facultatif : si mode=event)
- mpm_worker (Facultatif : si mode=worker)
- php 8
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.
--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 \
--Facultatif : si besoin de fonctionner en http2
--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
Options -Indexes -FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
Sécurité
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
Timeout 300
AddOutputFilter DEFLATE html php evsa js json htm svg gif tsv png ico css woff ttf eot
KeepAlive On
MaxKeepAliveRequests 500
KeepAliveTimeout 3
BrowserMatch "Mozilla/2" nokeepalive
BrowserMatch ".*MSIE [456].*" nokeepalive
Montée en charge
StartServers 8
MinSpareServers 8
MaxSpareServers 30
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
Define PERFS_PREFORK
</IfModule>
<IfModule event.c>
# ThreadsPerChild 10
ThreadsPerChild 20
ServerLimit 4
AsyncRequestWorkerFactor 2
# MaxRequestWorkers 40
MaxRequestWorkers 80
Define PERFS_EVENT
</IfModule>
Gestion du cache
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\" \"%{local}v:%{local}p\" \"%m\" \"%u\" \"%{X-Forwarded-For}i\" \"%{PHPSESSID}C\" \"%{email}C\" \"%{SSL_PROTOCOL}x\" \"%{SSL_CIPHER}x\" \"%{Cookie}i\"" default_https_debug
SSLSessionCache shmcb:${LOG_PATH}ssl_scache.log
Si vous n'utilisez pas d'accès SSL :
LogFormat "\"%t\" \"%D\" \"%H\" \"%{Referer}i\" \"%{User-Agent}i\" \"%U\" \"%a\" \"%X\" \"%>s\" \"%b\" \"%r\" \"%{local}v:%{local}p\" \"%m\" \"%u\" \"%{X-Forwarded-For}i\" \"%{PHPSESSID}C\" \"%{email}C\" \"-\" \"-\" \"%{Cookie}i\"" default_http_debug
Configuration spécifique à PHP
Modules à charger
- openssl
- zlib
- bcmath
- calendar
- ftp
- gettext
- mbstring
- bz2
- dba=shared
- soap
- sockets
- shmop
- exif
- intl
- unixODBC
- sysvsem
- sysvshm
- sysvmsg
- mhash
- readline
- libedit
- pdo-odbc
- zend-signals
- opcache
- curl
- apxs2
- gd
- jpeg
- png
- freetype
- zip
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 :
--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-bz2 \
--enable-dba=shared \
--enable-soap \
--enable-sockets \
--enable-shmop \
--enable-exif \
--enable-intl \
--with-unixODBC=/usr \
--enable-sysvsem \
--enable-sysvshm \
--enable-sysvmsg \
--with-mhash \
--with-readline \
--with-libedit \
--with-pdo-odbc=unixODBC,/usr \
--enable-zend-signals \
--enable-opcache \
--with-curl=/usr/local/curl \
--with-apxs2=/usr/local/apache2/bin/apxs \
--with-gd \
--with-jpeg \
--with-png \
--with-freetype \
--with-zip \
Paramètres à configurer dans PHP.INI
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 = On
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 à SQL Server
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