Aller au contenu

Prérequis pour une plateforme cyberelements Cleanroom Cluster

Machine

Une machine physique, tout comme une machine virtuelle, peuvent être utilisée pour l'installation de cyberelements Cleanroom.
Aucune virtualisation n'est réalisée par le produit, l'option de virtualisation imbriquée n'a pas à être activée pour les machines virtuelles.

OS

cyberelements Cleanroom exploite des machines Debian 12 (Bookworm) 64 bits.
Il est recommandé d'utiliser des machines sans interface graphique et en limitant les composants installés au serveur SSH.

CPU

Un CPU ayant 4 cœurs permettra de couvrir la plupart des cas d'usages du produit.

RAM

Attention

Les valeurs de RAM données ci-dessous sont à titre indicatif du fait des nombreuses variables pouvant affectées la consommation RAM (fonctionnalités du produit exploitées ou éléments installés en parallèle du produit sur la machine).

La consommation de la RAM dépend généralement du nombre d'utilisateur simultané que peut recevoir la plateforme :

  • Entre 1 et 5 utilisateurs simultanés : 2 Go de RAM minimum, 4 Go restent recommandés.
  • Entre 5 et 20 utilisateurs simultanés : 4 Go de RAM minimum.
  • Pour 20 et plus d'utilisateurs simultanés : 8 Go de RAM minimum.

La consommation de la RAM dépend du nombre de session simultané mais aussi des types d'applications exploitées.

Les valeurs types sont les suivantes :

  • Entre 1 et 5 utilisateurs simultanés : 2 Go de RAM minimum, 4 Go restent recommandés.
  • Entre 5 et 20 utilisateurs simultanés : 4 Go de RAM minimum.
  • Pour 20 et plus d'utilisateurs simultanés : 8 Go de RAM.

A noter qu'une application RDP sans agent ou VNC peut consommer jusqu'à 400 Mo par application lancée.
Dans des contextes à forte utilisation de ces types d'application il est recommandé de surveiller l'usage de la RAM pour adapter le dimensionnement de cette dernière.

La consommation de la RAM dépend du nombre d'applications HTML5 simultanément ouvertes.

Le serveur de base doit posséder 2 Go pour le fonctionnement du système auxquels sont ajoutés 50 Mo par applications HTML5 simultanées.

Si le rôle HTML5 Gateway est cumulé avec un serveur Edge Gateway, alors ajoutez 50 Mo par application HTML5 simultanées prévues à la recommandation de RAM du serveur Edge Gateway.

Disque

Nous recommandons un partitionnement du disque en utilisant LVM pour apporter plus de souplesse si le dimensionnement de la machine devait être révisé au cours de son utilisation.

Les différents type de serveurs ont des usages différents du disque avec des volumes qui eux aussi diffèrent. Ci-dessous les informations par type de serveur :

Ce serveur va avoir une volumétrie augmentant dans les répertoires suivants :

  • /var/log/ : répertoire contenant les différents logs systèmes.
  • /var/lib/postgresql/15/main/ : répertoire contenant les données de la base de données locale.
  • /var/ipdiva/ : répertoire contenant des données propres au produit.

Isoler dans des partitions différentes les différents répertoires n'est pas obligatoire mais recommandé, vous pouvez suivre les instructions suivantes :

Point de montage Options Taille minimale (Go)
/boot nosuid,nodev,noexec 1
/opt nosuid,nodev 1
/tmp nosuid,nodev 4
/srv nosuid,nodev 1
/home nosuid,nodev,noexec 6
/usr nodev 6
/var nosuid 5
/var/log nosuid,nodev,noexec 5
/var/tmp nosuid,nodev,noexec 2
swap Aucune option En fonction de la RAM (moitié moins)
/ Aucune option 2 Go ou plus suivant l'espace disque disponible

Exemple

Pour un serveur ayant 4 Go de RAM (ce qui nécessite 2 Go de swap), l'espace disque nécessaire avec le partitionnement précédent correspond à 35 Go minimum.

Ce serveur va avoir une volumétrie augmentant dans les répertoires suivants :

  • /var/log/ : répertoire contenant les différents logs systèmes.
  • /var/lib/ipdiva/carerecord/recording/ : répertoire contenant les archives en cours d'enregistrement, il s'agit donc d'un répertoire de stockage temporaire.
  • /var/lib/ipdiva/carerecord/archives/ : répertoire par défaut contenant les archives graphiques du produit.
  • /var/ipdiva/care/sshrecord/ : répertoire par défaut contenant les archives non graphiques (SSH) du produit.

Isoler dans des partitions différentes les différents répertoires n'est pas obligatoire mais recommandé, vous pouvez suivre les instructions suivantes :

Point de montage Options Taille minimale (Go)
/boot nosuid,nodev,noexec 1
/opt nosuid,nodev 1
/tmp nosuid,nodev 4
/srv nosuid,nodev 1
/home nosuid,nodev,noexec 6
/usr nodev 6
/var nosuid,nodev 5
/var/log nosuid,nodev,noexec 5
/var/tmp nosuid,nodev,noexec 2
swap Aucune option En fonction de la RAM (moitié moins)
/ Aucune option 2 Go ou plus suivant l'espace disque disponible

Exemple

Pour un serveur ayant 4 Go de RAM (ce qui nécessite 2 Go de swap), l'espace disque nécessaire avec le partitionnement précédent correspond à 35 Go minimum.

Il est toutefois fortement recommandé d'allouer plus d'espace disque pour le temporaire ou à long terme des archives graphiques avec le point de montage /var sauf si les archives sont externalisées.

Ce serveur va avoir une volumétrie augmentant dans les répertoires suivants :

  • /var/log/ : répertoire contenant les différents logs systèmes.
  • /home/systanciahtml5share/ : répertoire de stockage temporaire des fichiers échangés avec des applications HTML5.

Isoler dans des partitions différentes les différents répertoires n'est pas obligatoire mais recommandé, vous pouvez suivre les instructions suivantes :

Point de montage Options Taille minimale (Go)
/boot nosuid,nodev,noexec 1
/opt nosuid,nodev 1
/tmp nosuid,nodev 4
/srv nosuid,nodev 1
/home nosuid,nodev,noexec 6
/usr nodev 6
/var nosuid,nodev 5
/var/log nosuid,nodev,noexec 5
/var/tmp nosuid,nodev,noexec 2
swap Aucune option En fonction de la RAM (moitié moins)
/ Aucune option 2 Go ou plus suivant l'espace disque disponible

Exemple

Pour un serveur ayant 4 Go de RAM (ce qui nécessite 2 Go de swap), l'espace disque nécessaire avec le partitionnement précédent correspond à 35 Go minimum.

Réseau

Une plateforme Cluster cyberelements Cleanroom aura besoin de :

  • 2 adresses IP réelles par serveur Mediation Controller (portées par la même interface réseau)
  • 3 adresses IP virtuelles pour le fonctionnement du cluster
  • 1 adresse IP par machine Edge Gateway ou HTML5 Gateway

Informations complémentaires

Les adresses IP réelles et virtuelles des serveurs Mediation Controller doivent toutes appartenir à un même sous-réseau.

Incompatibilités avec l'utilisation des IP virtuelles

Les IP virtuelles ont une répartition de charge gérée avec IPVS (IP Virtual Server).
La répartition de charge implique plusieurs prérequis pour fonctionner correctement :

  • Désactiver les fonctionnalités du type Reverse Path Forwarding (RPF) pour les Mediation Controller et IP portées par ces machines.
  • Affecter un adaptateur réseau de type E1000E plutôt que VMXNET3 sur VMware pour les serveurs Mediation Controller.

Les serveurs Mediation Controller sont habituellement placés en DMZ, mais il peuvent tout aussi bien être placés dans une DMZ privée ou hébergés sur un cloud public. Cela va dépendre du cas d'usage que remplira la plateforme (par exemples : accès des prestataires à distance ou sécurisation d'accès internes à des zones protégées).

Les serveurs Edge Gateways sont habituellement placés dans le LAN, dans des VLAN leur permettant de pouvoir communiquer avec les ressources cibles.

Les serveurs HTML5 Gateways peuvent être aussi bien placés dans le LAN qu'en DMZ. Cette documentation prévoie l'installation du composant HTML5 Gateway sur les serveurs Edge Gateways, donc dans le LAN.

Pour mieux identifier les différentes adresses des machines, elles seront appelées de la manière suivante dans la documentation :

Nom de l'adresse IP Signification
RIP_MED_WEB_MASTER Adresse IP principale du serveur Mediation Controller MASTER permettant notamment l'accès aux consoles Web.
RIP_MED_WEB_SLAVE Adresse IP principale du serveur Mediation Controller SLAVE permettant notamment l'accès aux consoles Web.
RIP_MED_SSL_MASTER Seconde adresse IP du serveur Mediation Controller MASTER exploitée par le composant Routeur SSL.
RIP_MED_SSL_SLAVE Seconde adresse IP du serveur Mediation Controller SLAVE exploitée par le composant Routeur SSL.
VIP_MED_WEB IP virtuelle du cluster Mediation Controller permettant notamment l'accès aux consoles Web.
VIP_MED_SSL IP virtuelle du cluster Mediation Controller permettant notamment l'accès au Routeur SSL.
VIP_MED_ZEO IP virtuelle du cluster Mediation Controller permettant notamment l'accès à une base de configuration interne au produit.
IP_GW Adresse IP du serveur Edge Gateway.
IP_HTML5_GW Adresse IP du serveur HTML5 Gateway.

Information

Les informations de flux indiquées considéreront que les serveurs Mediation Controller soient placés en DMZ et que les serveurs Edge Gateway, qui auront aussi le rôle HTML5 Gateway, soient placés dans le LAN.

Les adresses IP du Mediation Controller peuvent soit être des adresses IP publiques directement portées par le serveur Mediation Controller ou des IP publiques qui sont natées vers des IP privées (recommandé).

Source Destinataire Port destinataire Commentaires
Poste utilisateur VIP_MED_WEB TCP 443 (si utilisation du port standard) Permettre l'accès aux consoles Web et aux applications fonctionnant directement dans le navigateur.
Poste utilisateur VIP_MED_SSL TCP 443 (si utilisation du port standard) Etablissement d'un tunnel TLS pour chiffrer le flux passant par le client cyberelements Cleanroom.
IP_GW VIP_MED_WEB TCP 443 (si utilisation du port standard) Lorsque la Edge Gateway se situe sur un réseau distant. Connexion au système d'appairage des Edge Gateway.
IP_GW VIP_MED_SSL TCP 443 (si utilisation du port standard) Lorsque la Edge Gateway se situe sur un réseau distant. Connexion au Routeur SSL pour établir un tunnel TLSv1.3 et y faire transiter les communications du produit.
Sources Destinataire Port destinataire Commentaires
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Dépôts Debian TCP 80 Nécessaire pour l'installation des dépendances de cyberelements Cleanroom et du maintien à jour du système. La documentation et les appliances virtuelles utilisent ftp.fr.debian.org et security.debian.org.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 packages.microsoft.com TCP 443 Dépôt Microsoft pour l'installation et le maintien à jour des pilotes MS SQL. Nécessaire seulement si l'accès à une BDD MS SQL est souhaité (les appliances virtuelles possèdent les pilotes MS SQL).
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur de temps NTP UDP 123 Facultatif si le serveur doit synchroniser son horloge avec un serveur présent dans la DMZ. Par défaut ce sont les pool Debian qui sont exploités : 0.debian.pool.ntp.org, 1.debian.pool.ntp.org, 2.debian.pool.ntp.org et 3.debian.pool.ntp.org.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur SMTP TCP 25, 465, 587 Nécessaire si un serveur SMTP doit être utilisé pour l'envoi d'e-mail et qu'il se situe dans le WAN.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur DNS UDP 53 Nécessaire pour la résolution DNS. Il peut se situer dans le WAN ou en DMZ.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 api.neomia.ai TCP 443 (Facultatif) Connexion aux APIs du produit de MFA par biométrie comportementale Neomia Pulse.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 EU : keepersecurity.eu
US : keepersecurity.com
AU : keepersecurity.com.au
CA : keepersecurity.ca
JP : keepersecurity.jp		 TCP 443 (Facultatif) Connexion au coffre-fort Keeper EPM en fonction de sa localisation.
Sources Destinataire Port destinataire Commentaires
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur de temps NTP UDP 123 Si le serveur doit synchroniser son horloge avec un serveur présent dans la DMZ.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur SMTP TCP 25, 465, 587 Nécessaire si un serveur SMTP doit être utilisé pour l'envoi d'e-mail et qu'il se situe dans la DMZ.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur BDD TCP 1433, 5432 ou tout autre port personnalisé Nécessaire si l'utilisation d'une BDD externe placée dans la DMZ est souhaitée.
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 Serveur DNS UDP 53 Nécessaire pour la résolution DNS. Il peut se situer dans la DMZ ou le WAN.

Information complémentaire

Les serveurs Mediation Controller doivent pouvoir communiquer entre eux depuis et vers n'importe laquelle de leurs adresses, peut importe le protocole.

Source Destinataire Port destinataire Commentaires
IP_GW Dépôts Debian TCP 80 Nécessaire pour l'installation des dépendances de cyberelements Cleanroom et du maintien à jour du système. La documentation et les appliances virtuelles utilisent ftp.fr.debian.org et security.debian.org.
IP_GW Serveur DNS UDP 53 Nécessaire pour la résolution DNS. Facultatif si un serveur DNS est disponible dans le LAN ou la DMZ.
IP_GW Serveur de temps NTP UDP 123 Facultatif si le serveur doit synchroniser son horloge avec un serveur présent dans le LAN ou la DMZ. Par défaut ce sont les pool Debian qui sont exploités : 0.debian.pool.ntp.org, 1.debian.pool.ntp.org, 2.debian.pool.ntp.org et 3.debian.pool.ntp.org.
IP_GW Prestataire de SMS TCP 443 (Facultatif) Connexion aux API des prestataires de SMS supportés par cyberelements Cleanroom.
Source(s) Destinataire(s) Port destinataire Commentaires
IP_GW
IP_HTML5_GW		 VIP_MED_WEB
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 TCP 443 (si utilisation du port standard) Connexion au système d'appairage des Edge Gateway.
IP_GW
IP_HTML5_GW		 VIP_MED_SSL
RIP_MED_SSL_MASTER
RIP_MED_SSL_SLAVE		 TCP 443 (si utilisation du port standard) Connexion au Routeur SSL pour établir un tunnel TLSv1.3 et y faire transiter les communications du produit.
Poste client VIP_MED_WEB
RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 TCP 443 (si utilisation du port standard) Connexion aux différentes consoles Web du produit.
Poste client VIP_MED_SSL
RIP_MED_SSL_MASTER
RIP_MED_SSL_SLAVE		 TCP 443 (si utilisation du port standard) Etablissement d'un tunnel TLS pour chiffrer le flux passant par le client cyberelements Cleanroom.
Poste Administrateur RIP_MED_WEB_MASTER
RIP_MED_WEB_SLAVE		 TCP 22 Connexion SSH au serveur Mediation Controller.
Source Destinataire Port destinataire Commentaires
IP_GW Serveur DNS UDP 53 Nécessaire pour la résolution DNS. Facultatif si un serveur DNS est utilisé vers le WAN ou DMZ.
IP_GW Serveurs LDAP ou AD TCP 389 ou 636 Connexion de cyberelements Cleanroom à un serveur LDAP ou AD.
IP_GW Serveurs AD TCP 139 et 445 Rotation de mot de passe de compte AD, utilisé seulement si la rotation par LDAPS est impossible.
IP_GW Serveurs RDP TCP/UDP 3389 (si utilisation du port standard) Connexion de cyberelements Cleanroom vers des serveurs RDP.
IP_GW Serveurs SSH TCP 22 (si utilisation du port standard) Connexion de cyberelements Cleanroom vers des serveurs SSH.
IP_GW Serveurs VNC TCP 5900 (si utilisation du port standard) Connexion de cyberelements Cleanroom vers des serveurs VNC.
IP_GW Serveurs Web TCP 80 ou 443 (si utilisation du port standard) Connexion de cyberelements Cleanroom vers des serveurs Web.
IP_GW Serveurs Citrix Storefront TCP 443 (si utilisation du port standard) Connexion de cyberelements Cleanroom vers des serveurs Citrix Storefront.
IP_GW Serveurs Citrix applicatifs TCP 1494 Connexion de cyberelements Cleanroom vers des serveurs Citrix applicatifs (lancement d'une application ou un bureau avec le client ICA).
IP_GW Serveurs de fichiers TCP 139 et 445 Connexion de cyberelements Cleanroom vers des serveurs de fichiers.
IP_GW Serveur BDD TCP 1433, 5432 ou tout autre port personnalisé Nécessaire si l'utilisation d'une BDD externe placée dans le LAN est souhaitée (par exemple pour le déport de la BDD du Coffre-Fort).
IP_GW Serveurs RDP TCP 139 et 445 Déploiement de l'agent d'enregistrement via la console d'administration.
Poste client IP_GW TCP [port défini par l'administrateur] Connexion en accès direct SSH.
Poste client IP_GW TCP 3389 Connexion en accès direct RDP.
Serveurs RDP IP_GW TCP 8443 Connexion de l'agent d'enregistrement à la Edge Gateway pour remonter l'enregistrement de la session utilisateur.
Poste Administateur IP_GW TCP 22 Connexion SSH au serveur Edge Gateway.

Base de données

cyberelements Cleanroom utilise différentes base de données (BDD) pour son fonctionnement.

  1. Base de données de configuration system. Cette BDD est utilisée pour stocker l'ensemble des paramétrages de l'interface d'administration /system et se nomme obligatoirement default.

    Attention !

    Il est nécessaire de créer la BDD default avant la connexion de cyberelements Cleanroom (elle n'est pas créée automatiquement).

  2. Base de données de configuration des organisations. Chacune des organisations créées sur le serveur Mediation Controller nécessitera une BDD différente pour contenir l'ensemble du paramétrage des organisations ainsi que les logs.

  3. Base de données du Coffre-Fort. Chacune des organisations créées provoque la création d'une BDD spécifique pour le Coffre-Fort du produit qui est stocké par défaut sur le serveur Mediation Controller. Cette BDD peut être externalisée dans le LAN à condition qu'une Edge Gateway puisse y avoir accès.

Lors d'utilisation de BDD externes (cas nominal en Cluster), les types de BDD supportées sont :

Licence

Le serveur Mediation Controller nécessite une licence pour être fonctionnel.
La licence est à récupérer auprès de Systancia via le formulaire de demande de licence suivant : Demander une licence

Certificats

cyberelements Cleanroom utilisant le chiffrement TLS, pour ses communications internes mais aussi avec HTTPS pour la sécurisation des accès Web, il nécessite l'utilisation de différents certificats x509. Les informations données ci-dessous récapitulent les différents certificats nécessaires, leur utilité ainsi que le paramétrage minimal.

Contrainte de sécurité des certificats

Peu importe le certificat utilisé, veillez à ce qu'il respecte le niveau de sécurité 2 d'OpenSSL qui se résume notamment à :

  • Le certificat et les certificats de ses Autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits.
  • La signature du certificat ne doit pas être en MD5 ou SHA-1 (SHA-512 à privilégier).

Ce serveur utilise cinq certificats différents :

  • Un certificat Web pour pouvoir utiliser HTTPS.
  • Un certificat pour le composant Routeur SSL en charge de monter les tunnels TLS et router le traffic entre eux.
  • Un certificat pour le composant Watchdog en charge de surveiller le bon fonctionnement du Routeur SSL.
  • Un certificat pour le client cyberelements Cleanroom pour lui permettre de se connecter au routeur SSL et établir un tunnel TLSv1.3.
  • Un certificat pour les échanges inter-serveurs des Mediation Controller (seulement pour le serveur SLAVE).

Certificat Web

Recommandation

Le certificat Web doit, de préférence, être issu d'une Autorité de Certification (AC) publique et reconnue comme de confiance.
Cela permettra pour les utilisateurs de ne pas avoir d'alerte liée au certificat utilisé (sous réserve qu'il soit valide et couvrant le nom avec lequel l'utilisateur à initié la connexion) sans action complémentaires. L'utilisation d'un certificat émis par une PKI interne nécessitant le déploiement du certificat de l'AC sur les postes utilisateurs.

Le certificat Web doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 398 jours (13 mois).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur le nom DNS (ou wildcard) pour lequel le certificat est prévu.
  • L'attribut Key Usage doit avoir les valeurs critical, digitalSignature et keyEncipherment.
  • L'attribut Extended Key Usage doit avoir la valeur id-kp-serverAuth (OpenSSL utilise la valeur serverAuth).
  • L'attribut Subject Alternative Name doit au moins contenir une entrée correspondant au nom DNS principal, d'autres entrées peuvent être ajoutés pour couvrir d'autres noms DNS ou adresses IP.

Format du certificat accepté : P12 ou PEM (avec deux fichiers, l'un pour le certificat et l'autre pour la clef privée).

Certificat Routeur SSL

Le certificat du Routeur SSL doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur l'adresse IP ou un nom DNS redirigeant vers IP_MED_SSL.
  • L'attribut Key Usage doit avoir les valeurs critical, digitalSignature et keyEncipherment.
  • L'attribut Extended Key Usage doit avoir la valeur serverAuth.

Format du certificat accepté : P12.

Certificat Watchdog

Le certificat du Watchdog doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur un nom d'identification du Watchdog, par exemple "Watchdog".
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12.

Certificat Client cyberelements Cleanroom

Le certificat du client cyberelements Cleanroom doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur un nom d'identification du client, par exemple "cyberelements-cleanroom-client".
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12 avec un mot de passe d'au moins 8 caractères alphanumériques (les caractères spéciaux, lettres avec accent ou tirets ne sont pas supportés).

Certificat Interserver

Le certificat interserver cyberelements Cleanroom doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur un nom d'identification, par exemple "interserver-cleanroom".
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12 avec un mot de passe d'au moins 8 caractères sans caractères spéciaux.

Ce serveur utilise deux certificats différents :

  • Un certificat pour l'authentification du composant Edge Gateway auprès du Routeur SSL.
  • Un certificat pour le service d'enregistrement pour que les agents d'enregistrement puissent s'y connecter.

Information

Un serveur Edge Gateway peut posséder plusieurs instances de Edge Gateway, il faudra autant de certificats que d'instances de Edge Gateway (sauf cas spécifique de l'architecture cluster).

Cependant un serveur Edge Gateway ne possède qu'un seul service d'enregistrement, un seul certificat par machine sera nécessaire.

Certificat Edge Gateway

Le certificat de la Edge Gateway doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur le nom permettant d'identifier la Edge Gateway logique, ce nom prend la forme suivante <GW_NAME>@<ORGANIZATION_NAME> où <GW_NAME> correspond au nom de la Edge Gateway (tel que renseigné dans la console d'administration) et où <ORGANIZATION_NAME> correspond au nom d'organisation vers laquelle la Edge Gateway se connectera.
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12.

Certificat service d'enregistrement

Le certificat du service d'enregistrement doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur le nom FQDN ou à minima le nom de la machine Edge Gateway.
  • L'attribut Key Usage doit avoir les valeurs critical, digitalSignature et keyEncipherment.
  • L'attribut Extended Key Usage doit avoir la valeur serverAuth.

Format du certificat accepté : P12.

Ce serveur utilise un seul certificat : celui pour l'authentification du composant HTML5 Gateway auprès du Routeur SSL.

Information

Un serveur HTML5 Gateway peut posséder plusieurs instances de HTML5 Gateway, il faudra autant de certificats que d'instances de HTML5 Gateway (sauf cas spécifique de l'architecture cluster).

Certificat HTML5 Gateway

Le certificat de la HTML5 Gateway doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur le nom permettant d'identifier la Edge Gateway logique, ce nom prend la forme suivante <HTML5_GW_NAME>@<ORGANIZATION_NAME> où <HTML5_GW_NAME> correspond au nom de la Edge Gateway (tel que renseigné dans la console d'administration) et où <ORGANIZATION_NAME> correspond au nom d'organisation vers laquelle la Edge Gateway se connectera.
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12.

Pour son fonctionnement en accès direct, l'agent d'enregistrement direct utilise un certificat pour s'authentifier auprès du service d'enregistrement d'une Edge Gateway.

Le certificat doit respecter les contraintes suivantes pour ses attributs :

  • La durée de validité du certificat ne doit pas excéder 1095 jours (3 ans).
  • La fonction de hachage utilisée pour la signature doit faire partie la famille SHA-2, nous recommandons SHA-512.
  • Le certificat et les certificats de ses autorités de certification doivent avoir une clef privée d'un minimum de 2048 bits avec les chiffrements RSA, DSA et DH ; pour les clefs à courbe elliptique (ECC), elles doivent être d'un minimum de 224 bits. Nous recommandons une taille de 4096 bits pour RSA et la courbe secp384r1 ECDSA d'une taille de 384 bits.
  • L'attribut Common Name doit avoir pour valeur le nom court ou nom FQDN ou tout autre nom qui permettra d'identifier de manière unique la machine. Ce nom étant utilisé pour identifier et tracer les actions réalisées sur la machine.
  • L'attribut Key Usage doit avoir les valeurs critical et digitalSignature.
  • L'attribut Extended Key Usage doit avoir la valeur clientAuth.

Format du certificat accepté : P12.