Nous avons construit un VPN Control Center pour l'équipe d'une agence.
Une agence multi-marques a demandé du self-service sur l'accès sécurisé que nous exploitons pour elle : ajouter un utilisateur, réinitialiser un mot de passe, retirer quelqu'un qui est parti, tout cela par sa propre équipe. Voici ce que nous avons construit, et pourquoi c'est l'un des gestes de service infogéré les plus forts que nous connaissions.
Dans cet article 4 sections
- Une agence multi-marques a demandé du self-service sur le VPN que nous exploitons pour elle : ajouter un utilisateur, réinitialiser un mot de passe, retirer quelqu'un qui est parti, sans ouvrir de ticket.
- La demande : construisez l'outillage pour mes propres équipes, assez simple pour qu'un opérateur junior le fasse tourner sans rien casser.
- Nous avons transformé notre toolkit opérateur interne en template pour leurs passerelles (une seule source de vérité, générée par passerelle), puis construit un VPN Control Center dans l'espace client : accès par rôles, règles par utilisateur, et un flux de découverte et d'intégration pour les nouvelles passerelles.
- État final : leur équipe gère l'accès sécurisé au quotidien depuis un menu. Nous possédons l'infrastructure en dessous.
Les changements VPN courants pour l'agence nous arrivaient sous forme de demandes. Ajouter un utilisateur. Réinitialiser un mot de passe. Retirer quelqu'un qui est parti. L'agence a demandé l'étape suivante : mettre ces opérations quotidiennes entre les mains de sa propre équipe, pour fixer son propre rythme.
La demande, en bref : construire l'outillage pour que leurs propres personnes le fassent tourner, assez simplement pour que l'opérateur le plus junior l'utilise sans rien casser.
h2 (#why-us): Pourquoi ils nous ont demandé, et non une console
Parce que ce sur quoi ils voulaient du self-service était une infrastructure que nous avons conçue et que nous exploitons : les passerelles, les autorités de certification par tenant, le cycle de vie des identifiants. N'importe qui d'autre aurait d'abord dû faire la rétro-ingénierie de l'installation. Nous pouvions rendre l'abstraction correcte du premier coup, parce que nous avons construit ce qu'elle abstrait.
h2 (#one-toolkit-not-three): Un toolkit, pas un par tenant
Plusieurs tenants, des passerelles séparées, des autorités de certification séparées, et l'outillage devait fonctionner à l'identique sur toutes pour que le client n'apprenne qu'un seul flux de travail. Le geste propre n'était pas d'écrire à la main des scripts par tenant, ce qui signifie une maintenance multipliée et une dérive garantie. Nous avons traité notre propre toolkit opérateur interne comme un template et nous générons le jeu de chaque tenant à partir de lui, en substituant les constantes propres à chaque passerelle.
Concrètement : cinq opérations canoniques (ajouter un utilisateur, réinitialiser un mot de passe, retirer un utilisateur, lister les utilisateurs, faire tourner les identifiants), générées par passerelle, chaque script ne parlant qu'à sa propre passerelle via l'API REST d'OPNsense, avec des identifiants rotatifs et tout fonctionnant localement sans service externe dans la boucle. Puis la couche d'expérience opérateur que le client demandait vraiment : une table de référence principale, un how-to par passerelle, et une bannière de connexion qui indique à chaque opérateur exactement la commande dont il a besoin.
=== secure-access operator toolkit ===
add-user | reset-password | remove-user | list-users | rotate-api-credentials
per-gateway how-to: /etc/<gateway>-howto reference: /etc/vpn-operationsLisible avec cat depuis n'importe quelle connexion. Le filet de sécurité de l'opérateur junior est une bannière, pas une page wiki que personne n'ouvre.
h2 (#the-control-center): Le Control Center dans l'espace client
Puis est venu le moment du « pouvez-vous aussi », et le toolkit est devenu une fonctionnalité produit. Un VPN Control Center dans l'espace client : un module de menu avec contrôle d'accès par rôles, un sélecteur de passerelle, un éditeur de règles d'accès par utilisateur, et un flux d'ajout de passerelle avec découverte automatique. Collez l'URL, la clé et le secret d'une passerelle, cliquez sur découvrir, et le module lit l'autorité de certification et l'instance sur la machine et l'intègre sans nouveau code.
Les changements d'utilisateurs courants étaient faits par notre équipe, sur demande.
Des scripts opérateur générés pour chaque tenant
Leurs opérateurs se servent eux-mêmes. Nous maintenons un seul template.
Un Control Center dans l'espace client
Accès par rôles, et de nouvelles passerelles qui s'intègrent elles-mêmes par découverte.
À chaque étape, le client nous a confié davantage de la construction, pas moins.
h2 (#the-end-state): L'état final
En production. Quand une nouvelle passerelle est arrivée, elle s'est intégrée elle-même par le flux de découverte, sans qu'une ligne de code nouvelle soit écrite pour elle. Leur équipe gère l'accès sécurisé au quotidien depuis un menu, chaque future passerelle s'intègre d'elle-même, et nous possédons l'infrastructure en dessous pendant que le client conduit.
“Nous avons fait tourner le VPN et remis les commandes à votre équipe, et nous avons gardé les clés de la salle des machines.”
Réponses directes
Ma propre équipe peut-elle gérer les utilisateurs VPN sur une infrastructure infogérée ?+
Oui, et cela peut être conçu proprement. Dans cette réalisation, les opérateurs du client ont reçu un outillage généré, puis un module de l'espace client avec accès par rôles, au-dessus de passerelles que nous exploitons.
EuroVPS construit-elle des outils sur mesure pour ses clients ?+
Quand la collaboration le demande. Celle-ci est passée de scripts opérateur à une fonctionnalité de l'espace client en production.
OPNsense peut-il être administré via son API ?+
Oui. Chaque opération de cette réalisation est passée par l'API REST d'OPNsense plutôt que par la console, ce qui est notre règle maison, parce que les opérations scriptées sont répétables et vérifiables.
Qui s'occupe de l'outillage self-service ?+
Nous. Le self-service transfère les opérations courantes à votre équipe, tandis que les passerelles, les autorités de certification et le module lui-même restent sous notre responsabilité.
La gestion des accès en self-service est-elle sûre pour du personnel junior ?+
C'était le cahier des charges, mot pour mot : assez simple pour que l'opérateur le plus junior le fasse tourner sans rien casser. Les garde-fous vivent dans l'outillage (une commande par tâche, accès par rôles dans l'espace client), pas dans un document d'avertissement que personne ne lit.
Vous voulez que votre équipe gère ses propres opérations ?
Dites-nous quelles opérations votre équipe aimerait pouvoir faire tourner elle-même. Si la bonne réponse est de l'outillage, nous construirons les commandes et garderons l'infrastructure en dessous.
Parler à un ingénieurVous êtes arrivé à la fin.
Mettez la lecture en pratique
Que faites-vous tourner ?
Parlez-nous de la charge de travail, du trafic et des exigences de reprise. Commencez par le configurateur de serveur, ou passez en revue les détails avec un ingénieur.
Écrit par les ingénieurs qui construisent et exploitent l'infrastructure qu'il décrit.Parler à un ingénieur