Sie benötigen neue Geräte, die automatisch bereitgestellt werden — Image, Pakete, ein KI‑Agent — aber die Richtlinie (oder der gesunde Menschenverstand) verlangt genau eine menschliche Freigabe, bevor der Agent Kontrolle erhält. Diese Anleitung führt Sie durch einen zuverlässigen, prüfbaren Ablauf, den Sie Ende-zu-Ende skripten und in großem Maßstab betreiben können.

Warum ein einzelnes Genehmigungstor wichtig ist

Automatisierte Geräteeinrichtung ohne jeglichen menschlichen Kontrollpunkt spart Zeit, erhöht aber die Risiken: versehentliche Aktivierung des Agenten, kompromittierte Images oder während der Bereitstellung ausgelaufene Zugangsdaten. Eine gut platzierte Einzelgenehmigung balanciert Automatisierung und Kontrolle. Sie hält die Hände von der Masse der Installationen fern und macht eine einzige Person verantwortlich für einen kontrollierten Break‑Glass‑Punkt.

Architekturübersicht: Provisioning plus Genehmigungstor

Das Muster ist einfach und wiederholbar:

Vorstaging der Maschine: OS‑Image, Festplattenverschlüsselung, lokale Konten, Basiskonfiguration.
Installieren Sie den Remote‑Agent‑Client in einem deaktivierten oder eingeschränkten Modus (Agent vorhanden, kann aber noch keine Fernsteuerung annehmen).
Senden Sie eine signierte Genehmigungsanfrage (Host‑Metadaten, Installer‑Hash, Build‑ID) an einen menschlichen Prüfer über Ihr Workflow‑Tool (Slack, PagerDuty, Ticketing‑System).
Der Prüfer überprüft die Metadaten und klickt auf einen Link oder führt einen kleinen signierten Befehl aus, der den Agenten in den voll funktionsfähigen Modus schaltet.
Nach der Genehmigung: Agent meldet sich beim Relay an, Audit‑Logs dokumentieren die Genehmigung und für zukünftige Sitzungen können weitere Richtlinien oder 2FA gelten.

Welche Komponenten Sie brauchen (konkret)

Eine Image/Build‑Pipeline, die eine Build‑ID und die SHA256 des Installers ausgibt (CI‑Runner, Packer, etc.).
Ein vorinstalliertes Remote‑Client‑Paket, das einen deaktivierten/gestoppten Modus und eine kleine Aktivierungs‑API oder einen Token‑Endpunkt unterstützt.
Einen Genehmigungsdienst: das kann ein minimaler Web‑Endpunkt hinter SSO sein oder ein vorhandenes Ticketing/ChatOps‑Tool, das einen signierten Aktivierungsbefehl ausführt.
Audit‑Logging — speichern Sie die Identität des Prüfers, Zeitstempel, Build‑ID und Installer‑Hash. Siehe Remote Desktop Audit Logging für empfohlene Felder und Aufbewahrungsrichtlinie.
Ein Relay für NAT‑Traversal — das von Tenvo verwaltete Relay ist die empfohlene Standardoption, weil es On‑Call für Relay‑Verfügbarkeit, Zertifikatserneuerung und Multi‑Region‑Failover entfernt. Hosten Sie nur selbst, wenn Ihre Compliance oder Netzwerkisolation das erfordert; ansonsten übersteigen die betrieblichen Kosten des Selbsthostings meist den Anschaffungspreis. Siehe Self-Hosted Remote Desktop: Why, How, and What Breaks.

Sicherheitsnotizen, denen Sie zustimmen müssen

Praktische Sicherheitsrealität: Der Client verwendet TLS mit einem gerätespezifischen Zertifikat für Verbindungen. Eine direkte Peer‑to‑Peer‑Verbindung ist End‑to‑End zwischen den beiden Geräten; fällt der Verkehr jedoch auf ein Relay zurück, terminiert TLS an diesem Relay. Das bedeutet, dass der Betreiber des Relay in der Lage ist, Sitzungsverkehr einzusehen. Gestalten Sie Ihren Genehmigungsablauf und Ihre Audit‑Kontrollen entsprechend — gehen Sie nicht davon aus, dass das Relay ein nicht beobachtender Zwischenknoten ist.

Detaillierter Workflow und Timing (Operator‑Sicht)

Der Image‑Build schließt ab und schreibt Metadaten: build‑id, Image‑SHA256, Paketliste, Installer‑Checksumme. Speichern Sie die Metadaten in Ihrem Build‑Artefakt‑Store.
Die Maschine bootet, führt First‑Boot‑Skripte aus, wendet das Image an, erzeugt lokale Konten und installiert den Agenten im 'gesperrten' Modus (Agentenprozess installiert, akzeptiert aber noch keine Remotesitzungen).
Das First‑Boot‑Skript erzeugt ein Genehmigungsanfrageobjekt mit host‑id, build‑id, Agent‑Installer‑Hash, IP (falls bekannt), Fingerabdruck des Host‑Zertifikats und einer kurzlebigen HMAC unter Verwendung eines Provisioning‑Schlüssels.
Die Genehmigungsanfrage wird an den Prüferkanal gepostet (Ticket, Slack‑Nachricht mit Genehmigungsbutton oder ein sicheres Web‑Dashboard). Der Prüfer kann die Build‑Metadaten und den Installer‑Hash prüfen. Die Genehmigungsaktion veranlasst Ihren zentralen Genehmigungsdienst, ein Aktivierungs‑Token auszugeben, das protokolliert und signiert wird.
Die Maschine pollt den Aktivierungsendpunkt mit dem ursprünglichen Request‑Nonce und der kurzlebigen HMAC. Wenn ein gültiges Aktivierungs‑Token zurückgegeben wird, wechselt der Agent in den 'aktivierten' Modus, meldet sich beim Relay an und beginnt, Remotesitzungen zu akzeptieren. Das Aktivierungsereignis wird mit Prüferidentität und Zeitstempel in Ihrem Audit‑Store protokolliert.

Praktisches Beispiel: Linux First‑Boot‑Skript

#!/bin/bash
# /usr/local/bin/first-boot-provision.sh
set -e
BUILD_ID=$(cat /etc/build-id || echo unknown)
AGENT_PATH=/opt/tenvo-agent
PROVISION_KEY=/etc/provision.key
HOST_ID=$(hostname -f)-$(cat /etc/machine-id)
CHECKSUM=$(sha256sum ${AGENT_PATH}/installer.tar.gz | awk '{print $1}')
NONCE=$(uuidgen)
JSON=$(jq -n --arg h "$HOST_ID" --arg b "$BUILD_ID" --arg c "$CHECKSUM" --arg n "$NONCE" '{host:$h,build:$b,checksum:$c,nonce:$n}')
HMAC=$(echo -n "$JSON" | openssl dgst -sha256 -hmac "$(cat $PROVISION_KEY)" | awk '{print $2}')
# Post to approval service (HTTPS with SSO in front)
curl -s -X POST -H "Content-Type: application/json" -d "{\"payload\":$JSON,\"hmac\":\"$HMAC\"}" https://approvals.example.com/requests
# poll for activation token (short interval)
for i in {1..60}; do
  TOKEN=$(curl -sS "https://approvals.example.com/activation?host=$HOST_ID&nonce=$NONCE")
  if [ -n "$TOKEN" ] && [ "$TOKEN" != "pending" ]; then
    /opt/tenvo-agent/bin/tenvo-activate --token "$TOKEN"
    systemctl enable tenvo-agent && systemctl start tenvo-agent
    logger "Provisioning: activated by approval service"
    exit 0
  fi
  sleep 5
done
logger "Provisioning: activation timed out, leaving agent disabled"

Windows‑Beispiel: PowerShell‑Aktivierungscheck

# FirstBoot-Provision.ps1
$buildId = Get-Content C:\build-id -ErrorAction SilentlyContinue
$agentInstaller = 'C:\Program Files\Tenvo\installer.msi'
$checksum = (Get-FileHash -Path $agentInstaller -Algorithm SHA256).Hash
$hostId = (Get-WmiObject -Class Win32_ComputerSystem).Name + '-' + (Get-Content C:\Windows\System32\config\systemprofile\machine-id)
$nonce = [guid]::NewGuid().ToString()
$payload = @{host=$hostId; build=$buildId; checksum=$checksum; nonce=$nonce} | ConvertTo-Json
$hmacKey = Get-Content C:\provision\provision.key
$hmac = [System.BitConverter]::ToString((New-Object System.Security.Cryptography.HMACSHA256([System.Text.Encoding]::UTF8.GetBytes($hmacKey))).ComputeHash([System.Text.Encoding]::UTF8.GetBytes($payload))).Replace('-','').ToLower()
Invoke-RestMethod -Uri 'https://approvals.example.com/requests' -Method Post -Body (@{payload=$payload; hmac=$hmac} | ConvertTo-Json) -ContentType 'application/json'
for ($i=0; $i -lt 60; $i++) {
  $token = Invoke-RestMethod -Uri "https://approvals.example.com/activation?host=$hostId&nonce=$nonce"
  if ($token -and $token -ne 'pending') {
    # Tenvo activation command
    & 'C:\Program Files\Tenvo\tenvo.exe' activate --token $token
    Start-Service -Name tenvo-agent
    Write-EventLog -LogName Application -Source 'Provision' -EntryType Information -EventId 1000 -Message 'Agent activated'
    break
  }
  Start-Sleep -Seconds 5
}

Genehmigungs‑UX und Integrationsoptionen

Die einfachste humane UX ist eine Slack‑Nachricht mit den Build‑Metadaten und zwei Buttons: Approve oder Reject. Der Approve‑Button trifft Ihren Genehmigungsdienst, der ein kurzlebiges Aktivierungs‑Token signiert und speichert. Ein Web‑Dashboard ist auditierbarer und skaliert besser für größere Organisationen — verlangen Sie SSO und MFA. Was immer Sie wählen: protokollieren Sie den Benutzernamen des Prüfers, die IP und die Artefakthashes; verlassen Sie sich nicht darauf, dass „jemand auf einen Button geklickt hat“ ohne zugeordnete Metadaten.

Audit‑Logging: was zu protokollieren ist

Pro Aktivierungsereignis sollten Sie mindestens diese Felder protokollieren: host‑id, build‑id, Installer‑SHA256, Prüferidentität (SSO‑E‑Mail), Zeitstempel (UTC), Prüfer‑IP, Genehmigungsmethode (UI/API) und Aktivierungs‑Token‑ID. Bewahren Sie Logs unveränderlich für die erforderliche Aufbewahrungsdauer auf und speisen Sie sie in Ihr SIEM. Siehe Remote Desktop Audit Logging für Schema‑Vorschläge und Best Practices zur Aufbewahrung.

Tenvo‑spezifische Hinweise und Empfehlungen

Tenvo bietet native Clients für macOS, Windows und Linux sowie einen Browser‑Client in öffentlicher Beta. Unser verwaltetes Relay ist die Standardempfehlung: Es stellt multi‑regionale Relay‑Endpunkte bereit, übernimmt die Zertifikatsrotation und nimmt Ihnen die operative Last ab, eine Relay‑Flotte gepatcht und online zu halten. Preisstufen sind Free $0, Lite $2.99/mo und Pro $7.99/mo — wählen Sie den Plan, der zu Ihren Sitzungs-, Audit‑ und SLA‑Anforderungen passt.

Operativ: Verwenden Sie das von Tenvo verwaltete Relay, sofern keine schriftliche Vorgabe Drittinfrastruktur verbietet. Hosten Sie nur selbst, wenn Compliance, isolierte Netzwerke oder Datenresidenz es erfordern; ansonsten machen Kosten für Schlüsselverwaltung, TLS‑Zertifikatserneuerung, Failover‑Design und On‑Call für Relay‑Verfügbarkeit das verwaltete Relay langfristig wirtschaftlicher. Wenn Sie Self‑Hosting in Erwägung ziehen, lesen Sie zuvor unseren self-hosting guide.

Test‑ und Validierungscheckliste

Unit‑Test: Die Build‑Pipeline erzeugt korrekte build‑id und SHA256. Verifizieren Sie nach Möglichkeit mit reproduzierbaren Builds.
Integrationstest: Das First‑Boot‑Skript postet korrektes JSON und HMAC und verarbeitet das Aktivierungs‑Token richtig.
Prüfer‑Flow‑Test: Bestätigen Sie, dass der Prüfer vollständige Metadaten sieht (Links zum Build‑Artefakt), die Prüferidentität protokolliert wird und das Aktivierungs‑Token nach der konfigurierten TTL verfällt.
Fehlermodus‑Test: Simulieren Sie Prüfer‑Ablehnung oder Kein‑Antwort und verifizieren Sie, dass die Maschine deaktiviert bleibt und eine Warnung zur manuellen Prüfung auslöst.
Relay‑Test: Bestätigen Sie direkte Peer‑to‑Peer‑Verbindungen, wenn NAT es erlaubt; wenn ein Relay verwendet wird, prüfen Sie, dass Sie das Relay‑Terminierungsmodell akzeptieren und geeignete Kontrollen implementiert haben.

Fehlerbehebung: Kurzanleitung

Agent aktiviert nie: Prüfen Sie die First‑Boot‑Skript‑Logs, HMAC‑Schlüssel‑Mismatch oder Netzwerk‑Erreichbarkeit zum Genehmigungsendpunkt.
Approve‑Button erzeugt kein Aktivierungs‑Token: Untersuchen Sie die Logs des Genehmigungsdienstes auf Signaturfehler oder fehlende SSO‑Assertionen.
Maschine aktiviert, registriert sich aber nicht: Verifizieren Sie ausgehendes TLS zum Relay‑Endpunkt und prüfen Sie Firewall‑Regeln, die Tenvo‑Ports oder DNS‑Auflösung blockieren könnten.
Verdächtige Aktivierung: Wenn die Prüferidentität falsch erscheint oder Hashes nicht übereinstimmen, widerrufen Sie das Gerät sofort (Agent deaktivieren) und starten Sie Incident Response.

Wann selbst hosten vs. verwaltetes Relay (kurzer Entscheidungsleitfaden)

Wählen Sie Self‑Hosting nur, wenn Sie eine schriftliche Vorgabe haben: eine Compliance‑Regel verbietet Dritt‑Infrastruktur, die Maschinen laufen in einem isolierten Netzwerk ohne ausgehendes Internet oder Sie benötigen strikte Datenresidenz. Andernfalls ist das von Tenvo verwaltete Relay in Arbeitsaufwand und Risiko günstiger. Für weiterführende Lektüre zu den Abwägungen siehe How to Set Up Remote Access in 60 Seconds und Remote Desktop Security: What You Need to Know.

Skalierungshinweise

Wenn Sie auf Hunderte oder Tausende Geräte skalieren, verlagern Sie den Genehmigungsschritt in eine Prüfergruppe und nutzen Sie Batching: Die Genehmigungsanfrage kann mehrere host‑ids und Checksums enthalten (ein einzelner Mensch genehmigt ein ganzes Batch, wenn alle Hashes den erwarteten Werten entsprechen). Protokollieren Sie dennoch jeden Host separat. Fügen Sie automatisierte Anomalieprüfungen hinzu, die abweichende Hashes markieren und in diesen Fällen eine pro‑Host‑Genehmigung verlangen.

Edge‑Fälle und Stolperfallen

Uhrabweichung: Kurzlebige Tokens erfordern genaue Systemuhren; stellen Sie sicher, dass NTP vor der Token‑Validierung konfiguriert ist.
Rollback‑Handling: Wenn ein Image zurückgerollt wird, dokumentieren Sie die Rollback‑Aktion im Audit‑Trail und fordern Sie optional eine erneute Genehmigung für betroffene Hosts.
Verlorene Prüferzugänge: Behandeln Sie den Zugriff auf den Genehmigungsdienst wie jede privilegierte Kontrollebene — verlangen Sie MFA und auditieren Sie Sessions.

Dieses Muster — einen Agenten vorzuinstallieren, ihn im gesperrten Zustand zu belassen, signierte Metadaten zu senden, eine explizite menschliche Aktivierung zu verlangen und eine unveränderliche Audit‑Spur zu speichern — gibt Ihnen die Geschwindigkeit der automatisierten Bereitstellung und gleichzeitig ein einziges verantwortliches menschliches Tor. Es funktioniert, egal ob Sie tausend Entwickler‑Laptops oder einen KI‑Agenten auf einer Serverflotte ausrollen.

Für zusätzlichen Kontext zu KI‑gesteuerter Fernsteuerung und Richtlinien lesen Sie ai agent remote desktop: policies, approvals, audit und ai agent audit log: what records must contain. Wenn Sie eine schnelle Checkliste zum Einstieg möchten, ist unser How to Set Up Remote Access in 60 Seconds ein kompakter Begleiter.

Bereit zum Ausprobieren? Laden Sie den Tenvo‑Client herunter und testen Sie den Ablauf zunächst an einer Maschine: Tenvo herunterladen.

Automatisierte Gerätebereitstellung – unbeaufsichtigt mit einer einzigen Genehmigung