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.

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.

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.

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.

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).

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

Back Office (Service Engine)

Prérequis techniques

Vue générale

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

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 :

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.

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.

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

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

Sécurité

Performances

Montée en charge

Gestion du cache

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 :

Si vous n'utilisez pas d'accès SSL :

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 :

Paramètres à configurer dans PHP.INI

Configuration spécifique à SQL Server