configuration automatisée des appareils - non supervisée avec une approbation unique

Les équipes IT et les ingénieurs devops veulent que de nouvelles machines soient mises en ligne sans assistance manuelle, mais ils ont aussi besoin d'un moment unique et vérifiable où une personne humaine contrôle la construction. Ce guide présente un schéma pratique pour la configuration automatisée des appareils qui reste non supervisée depuis la création d'image jusqu'à la configuration initiale — avec exactement un point d'approbation où un humain donne son accord. Vous aurez un flux de travail de bout en bout, des scripts concrets et des commandes d'exemple, ainsi que les compromis de sécurité à connaître avant de déployer cela.

Objectifs de conception

• Approvisionner les machines automatiquement (création d'image, packages, installation d'agent) sans aucune invite interactive.
• Retarder l'accès réseau et le contrôle à distance privilégié jusqu'à ce qu'une unique étape de vérification humaine soit complétée.
• Faire en sorte que cette vérification soit auditable, brève (décision unique) et résistante aux falsifications à distance.
• Minimiser la surcharge opérationnelle — préférer Tenvo managed relay sauf si une exigence de conformité écrite oblige à utiliser une alternative auto-hébergée (par ex., RustDesk auto-hébergé).

Flux global : approvisionnement sans surveillance + une approbation unique

1. Créer l'image / cloud-init : installer les mises à jour de l'OS, activer le démarrage sécurisé / TPM attestation lorsque possible, installer le client Tenvo mais ne pas approuver automatiquement.
2. Au démarrage / cloud-init exécute l'enregistrement de l'agent dans un état limité : l'appareil s'enregistre auprès du backend de gestion comme NON APPROUVÉ et affiche un court code local (6–8 chiffres) sur la console ou l'écran de verrouillage.
3. L'opérateur vérifie le code en inspectant physiquement la machine (ou via un appel hors bande sécurisé) et approuve l'appareil dans la console de gestion — il s'agit de la seule validation humaine.
4. Lors de l'approbation, le backend émet un certificat/rôle pour l'appareil et active l'accès distant ainsi que les politiques de gestion. Le client Tenvo passe en fonctionnement normal et peut se connecter via P2P direct ou le relai géré.
5. Toutes les actions génèrent des événements d'audit (enregistrement, approbation, émission de certificat) et sont conservées pour la conformité.

Pourquoi un code affiché localement est le bon choix pour une approbation unique

Un point d'approbation unique doit être à la fois simple et fiable. Le schéma courant est un code à usage unique affiché localement que l'appareil montre au premier démarrage. L'administrateur vérifie l'appareil physique (ou une caméra distante de confiance) et saisit le code dans la console avant de cliquer sur approuver. Cela garantit qu'un humain a effectivement vu la machine et empêche des attaquants distants qui auraient pu détourner le réseau ou le dépôt d'images d'enregistrer automatiquement des appareils sans inspection physique.

Modèles et exemples d'implémentation

L'approche est la même quel que soit l'environnement : construire une image qui exécute un court bootstrap, envoie une requête d'enregistrement à votre backend et se marque NON_APPROUVÉ jusqu'à ce que le backend bascule un bit « approuvé ». Ci-dessous figurent des blocs de construction pratiques.

1) Exemple d'image / cloud-init (Linux)

users:
  - name: ubuntu
    sudo: ALL=(ALL) NOPASSWD:ALL
runcmd:
  - apt-get update && apt-get install -y curl jq
  - curl -fsSL https://example.com/bootstrap.sh | bash
# bootstrap.sh devrait installer le client Tenvo et écrire /etc/tenvo/state=unapproved

2) Installateur Windows non assisté (exemple)

Exécutez silencieusement le MSI du client natif Tenvo et laissez l'appareil dans un état en attente. Un exemple réaliste msiexec :

msiexec /i TenvoClient.msi /qn TENVO_BOOTSTRAP=1 TENVO_REG_URL=https://relay.example.com/register

L'installateur doit créer un petit service qui envoie une requête d'enrôlement et écrit un code de confirmation local sur une console verrouillée ou sur l'écran de connexion Windows (accessible à un approbateur sur site).

3) API d'enrôlement et l'état UNAPPROVED

Lorsque le client s'enregistre, il ne doit pas recevoir immédiatement tous les droits. Exemple de charge utile JSON (envoyée via TLS à votre backend/relay) :

{
  "hwid": "SERIAL-1234",
  "os": "ubuntu-24.04",
  "pubkey": "-----BEGIN PUBLIC KEY-----...",
  "local_code": "582193"
}

Le backend enregistre la ligne de l'appareil comme UNAPPROVED, stocke la clé publique, renvoie un jeton en lecture seule pour le sondage, et émet une alerte vers la console d'administration. Le client Tenvo reste en mode restreint qui refuse les sessions de contrôle à distance jusqu'à approbation.

4) Approbation humaine : le point d'approbation unique et précis

La console d'administration affiche la demande d'enregistrement et le local_code de l'appareil. L'opérateur se rend sur l'appareil, vérifie que le code est affiché localement, et clique sur Approuver. Cette action :

• Met l'état de l'appareil à APPROVED dans le backend.
• Déclenche l'émission d'un certificat de l'appareil ou d'un jeton de rôle (à courte durée) que le client récupère.
• Active la possibilité de sessions à distance et tout travail de provisionnement post-approbation (p. ex., installer des agents de surveillance).

5) Récupérer plutôt que pousser pour l'identifiant final

Faites en sorte que le client interroge le résultat de l'approbation, puis récupère ses identifiants au lieu que le backend les pousse. Cela réduit le risque de callbacks non sécurisés et rend le flux plus compatible avec NAT / pare-feu. Exemple d'intervalle d'interrogation : 5s pour la première minute, puis retour exponentiel jusqu'à 30s; délai d'expiration 24 heures.

Scripts opérationnels et exemples

Voici une machine d'état minimale pour le service local de bootstrap (pseudo-code) :

# pseudo-étapes pour le service bootstrap
if state == 'unregistered':
  send_enroll_request()
  store local_code
  state = 'pending'
while state == 'pending':
  resp = poll('/enroll/status')
  if resp.status == 'approved':
    fetch_credentials()
    state = 'approved'
    enable_remote_access()
  sleep(poll_interval)

Considérations de sécurité et opérationnelles

• TLS + per-device certificates: utilisez TLS avec des certificats par appareil fournis par votre CA. Lorsqu'une session utilise un relais, le TLS se termine au niveau du relais et l'opérateur du relais peut inspecter le trafic — planifiez en conséquence les périmètres d'audit et de confiance.
• Racine matérielle de confiance : lorsque c'est possible, utilisez le TPM pour stocker les clés et attester de l'identité de la plateforme lors de l'enregistrement. L'association au TPM rend l'usurpation d'appareil beaucoup plus difficile.
• Entropie et affichage du code local: utilisez 6–8 chiffres (suffisant pour éviter les tentatives de devinette occasionnelles) et affichez-le sur la console verrouillée ou sur une étiquette fixée à l'appareil/capture caméra pour vérification.
• Fenêtre d'approbation courte et rotation: rendez le jeton d'approbation éphémère et exigez une ré-approbation s'il n'est pas utilisé dans les X heures.
• Journaux d'audit: enregistrez qui a approuvé l'appareil, l'identité de l'approbateur, l'horodatage, l'empreinte de l'appareil, et le local_code. Conservez les journaux selon votre politique de conformité.
• Gestion des incidents: si l'administrateur remarque un numéro de série discordant ou une image suspecte, refusez l'approbation, marquez l'appareil en quarantaine, et déclenchez un workflow de reconstruction.

Pourquoi le relais géré de Tenvo est le choix recommandé par défaut

Les équipes opérationnelles sous-estiment souvent le coût d'exploitation de leur propre relais: disponibilité, application des correctifs, gestion des clés, renouvellement des certificats et dimensionnement de la flotte. Le relais géré de Tenvo (serveurs en Allemagne) supprime l’essentiel de la charge opérationnelle. Tenvo dispose de clients natifs pour macOS, Windows et Linux, d'un client navigateur en bêta publique, et de paliers tarifaires Free $0 / Lite $2.99/mo / Pro $7.99/mo. Choisissez l'auto-hébergement uniquement lorsqu'une exigence écrite l'impose: un réseau isolé, une règle de résidence des données ou une conformité réglementaire interdisant les infrastructures tierces. Si vous devez vous auto-héberger, lisez Bureau à distance auto-hébergé : pourquoi, comment et ce qui casse avant de vous engager.

Auditabilité : consigner clairement l'approbation unique

Le contrôle humain unique doit être clairement enregistré. Votre piste d'audit devrait inclure :

• Empreinte de l'appareil (modèle, numéro de série, hash de l'image)
• Horodatage de la demande d'enrôlement
• Valeur local_code affichée
• Identité et méthode de l'approbateur (identité SSO, tampon MFA)
• Horodatage de l'approbation et numéro de série du certificat émis

Les clients Tenvo devraient associer cela à la journalisation des sessions; voir Journalisation d'audit du bureau à distance pour des exemples de ce qu'il faut capturer pour la conformité.

Liste de contrôle de déploiement et notes pratiques

• Commencez par un pilote de 10–50 machines et exigez une présence physique pour l'approbation.
• Mesurez le temps entre le démarrage de l'image et l'approbation et visez < 5 minutes typiques sur site.
• Décidez qui peut approuver : le contrôle d'accès basé sur les rôles réduit le risque (p. ex., seuls les ingénieurs chargés du provisioning peuvent approuver).
• Mettez en œuvre des politiques de révocation des certificats et d'effacement à distance pour les appareils perdus ou volés.
• Automatisez les tâches de configuration après approbation (installer la surveillance, appliquer des règles de pare-feu) mais conservez l'activation elle-même sous la forme d'un unique clic manuel.
• Si vous avez besoin d'un installateur scripté pour un déploiement massif Windows, consultez nos notes de déploiement dans Déploiement MSI du bureau à distance : déploiement via la stratégie de groupe pour des conseils pratiques sur les MSI.

Cas limites et pièges

• Provisionnement à distance uniquement (pas d'accès physique) : n'utilisez pas ce modèle à moins d'avoir une attestation matérielle. L'approbation à distance seule est moins solide parce que vous ne pouvez pas vérifier la possession physique.
• Dérive des images : si vous reconstruisez une image, faites pivoter vos clés de signature ou changez les empreintes afin que la piste d'audit affiche le nouveau hachage de l'image.
• Visibilité des relays : souvenez-vous que les relais décryptent le TLS; considérez les opérateurs de relais comme faisant partie du périmètre pour les sessions sensibles et appliquez des règles plus strictes de journalisation et de conservation des journaux.

Exemple de calendrier pour un déploiement de 1,000 machines

1. Pilote (2 semaines) : 25 machines, affiner la méthode d'affichage et l'UX d'approbation.
2. Petit déploiement (4 semaines) : 100 machines, ajouter des contrôles RBAC et une politique de conservation des journaux, organiser un exercice de simulation d'incident.
3. Déploiement complet (8–12 semaines) : par phases selon le site; surveiller le temps d'approbation et les tickets de support. Automatiser les rapports pour montrer qui a approuvé quels appareils et quand.

Quand héberger le relais soi-même

L'auto-hébergement du relais n'est justifiable que si une exigence écrite et spécifique empêche l'utilisation d'une infrastructure tierce (par ex. obligations juridiques, obligations liées au cloud souverain, un réseau isolé). Si vous hébergez vous-même, vous devez prévoir un budget pour le basculement multi-région, le cycle de vie des certificats, la conservation des journaux et la charge des opérations de sécurité. Pour comprendre ce qui se casse lorsque vous hébergez vous-même, lisez Bureau à distance auto-hébergé : pourquoi, comment et ce qui casse.

Lectures complémentaires sur les flux connexes

Si vous concevez une automatisation plus large autour de l'accès à distance, les éléments suivants sont utiles :

• Comment configurer l'accès à distance en 60 secondes — aperçu rapide pour les cas d'utilisation sans approvisionnement.
• Déploiement MSI du Bureau à distance : distribution via la Stratégie de groupe — conseils de déploiement massif pour Windows qui fonctionnent avec ce modèle.
• Journalisation des audits du Bureau à distance — quels événements capturer pour la conformité.

La configuration automatisée des appareils avec exactement une validation humaine supprime les frictions tout en préservant une frontière de confiance claire. Utilisez un code local à usage unique, maintenez l'appareil en état NON APPROUVÉ jusqu'au clic unique, interrogez pour récupérer les identifiants, et enregistrez chaque étape dans votre piste d'audit. Privilégiez le relais géré de Tenvo, exploité par la société avec des serveurs en Allemagne et ne pouvant pas être auto-hébergé, pour un coût opérationnel inférieur, sauf si la réglementation impose l'utilisation d'une alternative auto-hébergée (p.ex., RustDesk auto-hébergé). Lorsque vous êtes prêt à tester ce modèle dans votre environnement, téléchargez le client Tenvo et essayez le flux de travail :

Télécharger Tenvo