Version 1.0.0
La chaîne de confiance
Les liaisons chiffrées en TLS entre les composants, qui vérifie le certificat de qui sur chacune, et les réglages qui désignent les autorités reconnues.
Les flux entre les composants de Lemniscate sont chiffrés en TLS (livre blanc sécurité V3, sections 3.3 et 6.2). Sur chaque liaison, un composant vérifie le certificat de l’autre. Cette page décrit qui vérifie qui, et les réglages qui désignent les autorités de certification reconnues.
Aucun réglage ne désactive la vérification d’un certificat, et aucun algorithme propriétaire n’est utilisé.
Les liaisons
Section intitulée « Les liaisons »Sur ce dessin, une flèche se lit « vérifie le certificat de ». Elle part de celui qui contrôle et pointe vers celui qui est contrôlé.
Ces liaisons sont celles de la matrice de flux (livre blanc sécurité V3, section 3.3). Le poste n’en a qu’une : il ne connaît que l’adresse de la passerelle.
Ce que ce diagramme ne montre pas
Section intitulée « Ce que ce diagramme ne montre pas »- Le canal de contrôle que la passerelle ouvre vers l’hôte d’exécution. C’est le seul flux entre ces deux hôtes, et l’hôte d’exécution n’en ouvre aucun (livre blanc sécurité V3, section 3.3).
- La console d’administration. Elle parle à la base avec sa propre chaîne de connexion, donc sa propre vérification.
- Ce qui n’est pas du certificat. L’authentification du développeur auprès de votre annuaire, la révocation et les droits sont un autre mécanisme, décrit dans Le rôle de la passerelle.
Du poste à la passerelle
Section intitulée « Du poste à la passerelle »Le flux du poste vers la passerelle est chiffré en TLS, et c’est le seul flux du poste lié à Lemniscate (livre blanc sécurité V3, section 3.3). Le poste vérifie le certificat de la passerelle comme tout client vérifie un serveur.
Deux réglages agissent sur cette liaison, dans la configuration du poste :
| Réglage | Ce qu’il fait |
|---|---|
caBundlePath | ajoute une autorité de certification à celles reconnues |
clientCertificate | présente un certificat client, avec sa clé et sa phrase de passe |
Quand le certificat de la passerelle est signé par votre autorité interne,
caBundlePath la désigne. L’autorité s’ajoute à celles du système, elle ne les
remplace pas.
La passerelle n’identifie pas le poste par certificat. Le développeur est authentifié auprès de votre annuaire, et sa session est liée à son identité et à un projet (livre blanc sécurité V3, section 6.1).
La passerelle en écoute
Section intitulée « La passerelle en écoute »La passerelle termine TLS elle-même. Elle reçoit son certificat et sa clé par
deux variables d’environnement : TLS_CERT_FILE et TLS_KEY_FILE. Elle est la
seule interface exposée aux postes (livre blanc sécurité V3, section 6.2).
De la passerelle au moteur d’inférence
Section intitulée « De la passerelle au moteur d’inférence »La passerelle vérifie le certificat du moteur d’inférence. Aucune variable d’environnement, aucun drapeau, aucun mode de mise au point ne désactive cette vérification : le réglage n’existe pas dans le code.
Deux choses se règlent : l’autorité reconnue et ce que la passerelle présente.
| Variable | Ce qu’elle règle |
|---|---|
NODE_EXTRA_CA_CERTS | une autorité interne, ajoutée aux autorités du système |
UPSTREAM_TLS_CA_FILE | une autorité propre au trajet vers le moteur |
UPSTREAM_TLS_CLIENT_CERT_FILE, UPSTREAM_TLS_CLIENT_KEY_FILE | le certificat client, quand le moteur en exige un |
Les autorités supplémentaires s’ajoutent, elles ne remplacent pas. Une autorité déclarée pour le trajet vers le moteur ne retire ni les autorités du système ni celle de l’entreprise.
Le chiffrement ne remplace pas le filtrage réseau : le moteur n’écoute que sur le réseau interne du serveur d’inférence, et votre filtrage n’autorise que l’hôte de la passerelle à le joindre (livre blanc sécurité V3, sections 3.3 et 8.2).
De la passerelle à la base
Section intitulée « De la passerelle à la base »La liaison entre la passerelle et la base est chiffrée en TLS, et le certificat du
serveur de base est vérifié. Aucun réglage ne rend la vérification facultative.
L’autorité qui signe le certificat du serveur de base s’ajoute par l’une de deux
entrées : le chemin de son fichier PEM (DATABASE_CA_CERT_PATH) ou le contenu de
ce PEM (DATABASE_CA_CERT), selon que la plateforme sait monter un volume ou
seulement passer des variables d’environnement. Les deux entrées mènent à la même
résolution ; les poser toutes les deux fait refuser le démarrage. Le certificat
d’une autorité n’est pas un secret : c’est la moitié publique d’une paire de clés.
Un paramètre de chiffrement écrit dans la chaîne de connexion de la base est
refusé. Un sslmode, un sslrootcert ou l’un de leurs voisins dans
DATABASE_URL empêche la passerelle de démarrer, avec la marche à suivre : la
bibliothèque de connexion laisserait ce paramètre écraser la vérification posée
par ailleurs.
Les configurations refusées au démarrage
Section intitulée « Les configurations refusées au démarrage »Sur toutes ses liaisons, la passerelle refuse de démarrer quand la configuration de chiffrement est incomplète ou illisible. Les cas refusés :
- une seule des deux variables de certificat posée, à l’écoute comme vers le moteur ;
- un fichier de certificat, de clé ou d’autorité illisible ;
- une paire certificat-clé qui ne va pas ensemble, un fichier au format invalide, une clé privée protégée par une phrase de passe.
Chacun de ces cas arrête le démarrage avec un message qui nomme la variable en cause.