CA partagée, portes séparées : un service par fichier d’admission

Un certificat qui se valide auprès d’une autorité partagée a passé un test de confiance, pas un test d’appartenance. Ces deux décisions sont souvent confondues parce qu’elles ont lieu toutes les deux au moment de la connexion, et la confusion reste invisible jusqu’à ce que soit admise sur un service une personne qui n’aurait pas dû y être. Le remède n’est pas une seconde autorité ; c’est une seconde décision, prise service par service et consignée là où le démon la lit. Gardez les deux séparées et l’essentiel de la confusion dans ce domaine disparaît.

Une chaîne de confiance ne dit rien de l’appartenance au service

Deux services peuvent accepter la même hiérarchie émettrice et avoir pourtant des populations différentes. Un portable appartient au premier et ne doit pas atteindre le second, tandis que d’autres clients de la même hiérarchie y appartiennent bel et bien. Retirer l’autorité de ce service exclurait tous ceux qui l’utilisent légitimement, donc le travail est une admission, pas une question de confiance.

Il est utile d’imaginer deux serrures sur une porte. Le certificat ouvre la serrure extérieure, et une décision par service ouvre l’intérieure ; ni l’une ni l’autre ne remplace l’autre. Un service qui n’a que la serrure extérieure n’applique aucune appartenance, il ne fait qu’authentifier. Écrivez les deux décisions avant de modifier quoi que ce soit, car une politique qui n’existe que sous la forme d’une connexion qui fonctionne ne peut pas être auditée. Ce qui suit concerne la serrure intérieure.

Transformez les substitutions facultatives en porte d’admission

Un répertoire de configuration client est normalement une commodité : les fichiers qu’il contient remplacent les réglages des clients qu’ils nomment, et un client sans fichier fonctionne simplement avec les valeurs par défaut du serveur. Une directive transforme cette commodité en porte, de sorte qu’un fichier manquant signifie que la connexion est refusée.

client-config-dir /etc/openvpn/service-a/clients
ccd-exclusive

L’édition communautaire d’OpenVPN 2.6 ccd-exclusive documente, dans sa page de manuel, exactement cette condition, et la recherche du fichier nommé dépend de l’identité effective du client. D’autres compilations et des serveurs gérés par produit peuvent différer, aussi vérifiez la version installée avant de vous fier à la même sémantique ailleurs.

Traitez le chemin ci-dessus comme un exemple et vérifiez la disposition déployée plutôt que de créer un répertoire inventé par un guide. Laissez les contrôles de certificat, les contrôles d’identité du serveur et l’authentification de compte exactement tels qu’ils étaient, car le fragment ajoute une condition et n’en retire aucune. Préparez le changement avant la production, car un refus soulevé au mauvais endroit ressemble à une défaillance de certificat et envoie l’enquête vers l’autorité. Confirmez ensuite que la ligne de journal d’un client refusé nomme le fichier de configuration manquant et non la chaîne.

Un répertoire par service, pas une liste partagée

L’appartenance revient au service qui l’applique, donc chaque service tient son propre répertoire et ses propres fichiers. Pointer deux services vers une même liste les fait partager l’appartenance que quelqu’un l’ait voulu ou non, et le changement qui en résulte est difficile à rattacher à une décision. L’autorité partagée peut rester partagée ; les fichiers d’admission non. Les garder séparés signifie aussi qu’une erreur dans un service ne peut pas élargir silencieusement un autre.

Une entrée DEFAULT est le cas qui trompe les gens. Elle fournit des réglages de repli lorsqu’aucun fichier nommé n’est trouvé, mais ce n’est pas le fichier nommé qu’exige la porte, donc elle ne peut pas admettre un client à elle seule. Testez un client qui n’a aucune entrée et confirmez le refus ; si ce client est admis, le repli s’applique et ccd-exclusive n’est pas en vigueur dans cette instance.

L’identité effective décide quel fichier est lu

La recherche utilise l’identité sous laquelle le client s’est réellement authentifié, qui est normalement le nom commun du certificat. Lorsque le serveur vérifie aussi un nom d’utilisateur et un mot de passe et mappe ce nom sur le nom commun, le fichier doit plutôt correspondre au nom d’utilisateur authentifié. Une incohérence laisse un répertoire plein de noms de fichiers plausibles qui ne sont jamais sélectionnés.

La lecture est l’autre moitié. Le démon abandonne généralement ses privilèges après le démarrage, donc le compte réduit a besoin d’un accès en lecture au répertoire et à chaque entrée qu’il contient. Les clients ne doivent pas pouvoir créer leur propre entrée par un chemin inscriptible, car une admission en libre-service ruine entièrement le mécanisme. Vérifiez les permissions de montage et de partage et pas seulement le mode du fichier, car un répertoire qui semble fermé pour un compte peut être ouvert pour un autre. Confirmez ensuite quel compte le processus en cours utilise réellement, et non quel compte le fichier d’unité mentionne. Les deux ne coïncident que lorsque rien d’autre ne les a modifiés.

Observez séparément le refus, l’admission et la révocation

Essayez une identité qui appartient au service et confirmez qu’elle se connecte. Essayez un certificat valide sans entrée et confirmez qu’il est refusé. Essayez une identité admise sur l’autre service et confirmez qu’elle n’est pas admise ici. Notez l’instance de service et l’identité effective à côté de chaque résultat, car un résultat sans ce contexte ne peut être reproduit par personne d’autre.

Le retrait est une opération distincte de la révocation. Modifier un fichier d’admission retire un droit sur un service tandis que l’identité reste valide partout ailleurs, alors qu’une clé compromise exige la réponse de révocation de l’organisation. Décidez à l’avance de ce qui arrive aux sessions déjà établies, car ni la modification du répertoire ni la liste de révocation ne les terminent d’elles-mêmes.

L’admission n’est aussi que la première porte. Rejoindre un service ne dit rien des sous-réseaux, des bases de données ou des interfaces d’administration situés derrière, et cette politique de ressources doit être écrite et testée à part.