Remote‑Access-RFP: 20 Fragen, die zur Offenheit zwingen

Remote‑Access‑Software nach einer Checkliste zu kaufen fühlt sich sicher an, bis alle Anbieter auf jede Frage "ja" antworten. Die eigentliche Arbeit einer RFP besteht darin, Anbieter zu konkreten Belegen zu zwingen — Diagramme, Protokollnamen, Zertifikate, Logs — damit Sie Trade‑offs statt Marketing vergleichen können. Dieser Artikel bietet 20 gezielte Fragen, die Anbieteransprüche von der operationalen Realität trennen, beschreibt, wie eine gute Antwort aussieht, und weist auf kritische Schwachstellen hin, die Sie nicht akzeptieren sollten.

Wie Sie diese Antworten lesen

Bewerten Sie Anbieter nicht danach, ob sie sagen "wir unterstützen X" — bewerten Sie sie anhand der Artefakte, die sie liefern. Fordern Sie Architekturdiagramme, TLS‑Zertifikat‑Fingerprints, Muster‑Logeinträge (anonymisiert), eine dokumentierte Vorfall‑Timeline und ein Testkonto, das ein behauptetes Verhalten reproduziert. Wenn ein Anbieter sich weigert, Belege zu liefern, ist das an sich bereits eine Antwort.

20 Fragen, die Anbieter auseinandernahmen

1. Was ist Ihr Verbindungsmodell (P2P, brokered, relay)?

   Warum das wichtig ist: Leistung, Latenz und wer den Verkehr beobachten kann, hängen davon ab, ob Sitzungen direkt oder über einen Proxy laufen. Fordern Sie ein Diagramm und eine Beschreibung des Paketflusses an.

   Akzeptable Nachweise: Ein Netzwerkdiagramm, das NAT‑Traversal, STUN/TURN‑Nutzung und Fallbacks zeigt; Beispiele für die von Relays verwendeten IP‑Bereiche.

   Warnsignale: Vage Antworten wie „wir machen, was am schnellsten ist“ oder die Weigerung, Fallbacks zu beschreiben.

2. Wenn eine Sitzung ein Relay verwendet, wer betreibt es und in welchen Regionen befindet es sich?

   Warum das wichtig ist: Ein Relay‑Betreiber kann entschlüsselte Daten sehen, falls TLS dort terminiert. Sie müssen wissen, ob das Relay multi‑region, single‑region oder vom Kunden betrieben wird.

   Akzeptable Nachweise: Eine Liste der Relay‑Betreiber, Karten der Regionen und ein SLA für regionales Failover. Für Tenvo: wir betreiben ein Managed‑Relay (Server in Deutschland). Wenn Sie Ihr eigenes Relay benötigen, ziehen Sie in Erwägung, RustDesk selbst zu hosten.

   Warnsignale: Keine Regionenangaben oder „wir nutzen Cloud‑Provider“ ohne Nennung der Regionen oder des Failover‑Verhaltens.

3. Wie wird die Sitzungsverschlüsselung implementiert und wo terminiert TLS?

   Warum das wichtig ist: Anbieter werben oft mit starker Verschlüsselung, verschweigen aber, wo die Schlüssel liegen. Ein direkter P2P‑Pfad bewahrt End‑to‑End‑TLS zwischen den Geräten; wenn Traffic auf ein Relay ausweicht, terminiert TLS an diesem Relay.

   Akzeptable Nachweise: Protokollnamen (TLS), Prozess zur Ausstellung pro‑Gerät‑Zertifikaten und ein Diagramm, das die Terminierungspunkte zeigt. Fragen Sie nach dem Mechanismus zur Erstellung von Gerätezertifikaten und deren Lebensdauer.

   Warnsignale: Behauptungen wie „das Relay sieht niemals Daten“ ohne kryptografischen Beleg oder Details zur Schlüsselverwaltung.

4. Wer hält private Schlüssel und wie werden diese geschützt?

   Warum das wichtig ist: Die Schlüsselverwahrung bestimmt, ob ein Anbieter — oder jemand mit Zugriff auf deren Infrastruktur — Geräte nachahmen oder Relay‑Sitzungen entschlüsseln kann.

   Akzeptable Nachweise: Beschreibung des Schlüssel‑Lebenszyklus, HSM‑Einsatz falls vorhanden und Trennung der Zuständigkeiten beim Signieren. Wenn der Anbieter pro‑Gerät‑Zertifikate ausstellt, fordern Sie die CA‑Signing‑Policy an.

   Warnsignale: „Wir bewahren Schlüssel sicher auf“ ohne verfahrens‑ oder technische Details.

5. Beschreiben Sie Ihr Auth‑Modell: Geräteidentitäten, Benutzeridentitäten und MFA‑Optionen.

   Warum das wichtig ist: Unklare Identitätsmodelle führen zu Privileg‑Creep und schlechten Prüfpfaden. Sie wollen Geräte‑Identität plus Benutzer‑Authentifizierung mit starken MFA‑Optionen (TOTP, Push, Hardware‑Token oder Passkeys).

   Akzeptable Nachweise: Auth‑Flussdiagramme, unterstützte MFA‑Mechanismen und Beispiel‑Audit‑Einträge, die Sitzungen mit Benutzer‑IDs verknüpfen.

   Warnsignale: Ein einzelnes gemeinsames Konto für unbeaufsichtigten Zugang oder keine MFA für administrative Aktionen.

6. Unterstützen Sie SSO / SCIM / Provisioning und wie werden Gruppen abgebildet?

   Warum das wichtig ist: Enterprise‑Onboarding/Offboarding muss automatisiert sein, um veralteten Zugriff zu vermeiden.

   Akzeptable Nachweise: SCIM‑Schema‑Unterstützung, SAML/OIDC‑SSO‑Integrationsschritte, Gruppensynchronisationshäufigkeit und Beispiel‑CSV oder SCIM‑Payloads.

   Warnsignale: Manuelles CSV‑Provisioning ohne Audit‑Trail.

7. Welche Telemetrie wird gesammelt und können Kunden abwählen oder die Aufbewahrung steuern?

   Warum das wichtig ist: Telemetrie kann sensible Metadaten enthalten (Benutzernamen, Hostnamen, Netzwerkadressen). Sie müssen kontrollieren können, was gesammelt wird und wie lange.

   Akzeptable Nachweise: Telemetrieliste (Kategorien, keine rohen PII), Standard‑Aufbewahrungsfristen und Enterprise‑Kontrollen zum Opt‑out. Fordern Sie ein Beispielschema eines Telemetrie‑Datensatzes an.

   Warnsignale: „Wir sammeln viele Metriken“ und die Weigerung, Aufbewahrung oder Redaktionsmechanismen zu definieren.

8. Wie werden Sitzungen protokolliert und wie detailliert sind die Logs?

   Warum das wichtig ist: Für Compliance und Forensik benötigen Sie Sitzungsstart/-stopp, Benutzeridentität, Zielgerät und idealerweise Sitzungsmetadaten wie IPs und Relay‑Hops. Wenn Sitzungsaufzeichnung unterstützt wird, benötigen Sie Details zu Speicherung, Verschlüsselung und Aufbewahrung.

   Akzeptable Nachweise: Beispiel‑Logzeilen (anonymisiert), SIEM‑Integrationsdokumentation und Optionen zur Aufbewahrung/Archivierung.

   Warnsignale: Logs nur im Anbieter‑Portal ohne Export‑ oder API‑Möglichkeit.

9. Bieten Sie Sitzungsaufzeichnung an und wie ist diese gesichert?

   Warum das wichtig ist: Aufzeichnungen helfen bei Audits, erhöhen aber das Exposure. Sie benötigen klare Kontrollen, wer Aufzeichnungen lesen darf, wie Aufzeichnungen verschlüsselt und aufbewahrt werden und wie Löschprozesse funktionieren.

   Akzeptable Nachweise: Verschlüsselungsansatz für Aufzeichnungen, Zugriffskontrollen, Aufbewahrung und eine API‑ oder S3‑kompatible Exportoption.

   Warnsignale: Keine RBAC auf Aufzeichnungen oder unverschlüsselte Speicherung von Aufzeichnungen.

10. Welche administrativen Rollen und RBAC‑Primitive bieten Sie?

    Warum das wichtig ist: Granulares RBAC reduziert Risiko. Suchen Sie nach Rollenvorlagen, Least‑Privilege‑Policies und Trennung zwischen Support‑Personal und Superadmins.

    Akzeptable Nachweise: RBAC‑Modell, Geltungsbereichsgrenzen (pro Team, pro Gerät) und Beispiele für Policies für eine Helpdesk‑Rolle vs. Sysadmin.

    Warnsignale: Alles‑oder‑nichts‑Adminrollen oder versteckte Superadmin‑Backdoors.

11. Wie handhaben Sie unbeaufsichtigten Zugang und temporäre Erhöhungen?

    Warum das wichtig ist: Unbeaufsichtigter Zugang ist bequem, aber gefährlich. Sie wollen Just‑in‑Time‑Erhöhungen, Genehmigungstore und zeitlich begrenzte Tokens.

    Akzeptable Nachweise: Workflow‑Diagramme, Token‑TTL und ein Audit‑Trail, der Erhöhungen einem Genehmiger zuordnet.

    Warnsignale: Permanente unbeaufsichtigte Schlüssel ohne Genehmigungsprozess.

12. Wie sind Ihre Patch‑, Build‑ und Release‑Praktiken für Client‑ und Server‑Code?

    Warum das wichtig ist: Schwachstellen stecken in Clients und Relays. Sie benötigen standardisierte Antworten zur Update‑Frequent, signierten Builds und CVE‑Offenlegungsprozessen.

    Akzeptable Nachweise: Release‑Cadence (z. B. wöchentliche Sicherheitsupdates), Code‑Signing‑Details und eine öffentliche oder kundenorientierte CVE‑Policy.

    Warnsignale: Kein dokumentierter Release‑ oder Signaturprozess.

13. Unterstützen Sie On‑Prem oder kundengemanagte Relays und was kostet das?

    Warum das wichtig ist: Manche Vorschriften verlangen lokale Infrastruktur. Selbstgehostete Lösungen verschieben jedoch die operative Last; quantifizieren Sie Kosten und Support‑Unterschiede.

    Akzeptable Nachweise: Deploy‑Guide, Ressourcenprofil für ein Relay und Preisinformationen für Managed vs. Self‑Hosted. Hinweis: Tenvo ist ein Managed‑Relay, das von uns betrieben wird (Server in Deutschland); wenn Sie On‑Prem‑Infrastruktur benötigen, überlegen Sie, RustDesk selbst zu hosten; für viele Organisationen ist ein Managed‑Relay günstiger, wenn Bereitschaftsdienst, Patching und Zertifikatserneuerung mitgerechnet werden.

    Warnsignale: Self‑Host‑Versprechen ohne Dokumentation oder die Forderung teurer Enterprise‑Verträge.

14. Wie lauten Ihre SLA‑Bedingungen für Verfügbarkeit, Failover und Support‑Antwortzeiten?

    Warum das wichtig ist: Verfügbarkeit, regionales Failover und Antwortzeiten sollten vertraglich geregelt sein. Fordern Sie MTTR, Uptime‑% und Kreditbedingungen an.

    Akzeptable Nachweise: SLA‑PDF mit Uptime‑Zielen, Support‑Tiering und Incident‑Escalation‑Matrix.

    Warnsignale: Mündliche SLA oder „wir bemühen uns“‑Aussagen ohne Strafen oder Gutschriften.

15. Wie erkennen und reagieren Sie auf Kompromittierung eines Kontos oder Geräts?

    Warum das wichtig ist: Zeitnahe Erkennung und Eindämmung begrenzen den Schaden. Sie benötigen klare Widerrufsmechanismen und ein Beispiel‑Incident‑Timeline.

    Akzeptable Nachweise: Widerrufs‑API, ein redigierter Incident‑Report und durchschnittliche Eindämmungszeiten vergangener Vorfälle.

    Warnsignale: Keine Widerrufs‑API oder die Aussage „kontaktieren Sie den Support“ für dringende Widerrufe.

16. Wie unterstützen Sie Kunden‑Audits und welche Nachweise können Sie liefern?

    Warum das wichtig ist: Auditoren fragen nach Logs, Kontrollen und Zugriffslisten. Anbieter sollten exportierbare Artefakte und einen Prozess zur Erstellung von Audit‑Paketen bereitstellen.

    Akzeptable Nachweise: Audit‑Paket‑Vorlage, Beispiel‑Logs, SOC/ISO‑Berichte wo verfügbar und ein dokumentierter Prozess für Ad‑hoc‑Anfragen.

    Warnsignale: Nur Portal‑Screenshots oder „wir zeigen es live“ ohne Exporte.

17. Welche Telemetrie oder Komponenten stammen von Drittanbietern (CDN, Analytics) und wem gehören diese Daten?

    Warum das wichtig ist: Drittanbieter‑Services bringen Supply‑Chain‑ und Daten‑Residency‑Risiken mit sich.

    Akzeptable Nachweise: Liste der Drittanbieter, Datenflüsse, die zeigen, was an jeden Anbieter geht, und Verträge oder DPA‑Bedingungen falls relevant.

    Warnsignale: „Wir nutzen Drittanbieter“ ohne Nennung oder Erklärung der gesendeten Daten.

18. Wie skalieren Sie für große Flotten und welche Deployment‑Tools gibt es?

    Warum das wichtig ist: Große Unternehmen benötigen Massen‑Deployment, MSI/PKG‑Optionen und Remote‑Konfiguration.

    Akzeptable Nachweise: MSI/PKG, Silent‑Install‑Flags, MDM‑Templates, API für Geräte‑Rollout und Beispiel‑Durchsatzzahlen (Sitzungen pro Relay).

    Warnsignale: Nur manuelle Installer oder keine Anleitung für Tausende von Geräten.

19. Welche Debug‑ und Diagnosetools stellen Sie Kunden zur Verfügung?

    Warum das wichtig ist: Wenn etwas ausfällt, benötigen Sie lokale Logs, Packet‑Captures und eine Möglichkeit, reproduzierbare Daten mit dem Support zu teilen.

    Akzeptable Nachweise: Lokale Debug‑Log‑Pfad‑Angaben, Log‑Verbosity‑Steuerung und ein Support‑Upload‑Workflow mit Beispielen anonymisierter Logs.

    Warnsignale: Der Nutzer muss ferngesteuerte Tools auf Anweisung des Anbieters ausführen, ohne Transparenz.

20. Wie wird die Abrechnung bemessen und welche unerwarteten Kosten können entstehen?

    Warum das wichtig ist: Pro‑Gerät, pro‑Benutzer, gleichzeitige Sitzungen sowie Relay‑Bandbreite oder Egress‑Gebühren je Region können Käufer überraschen.

    Akzeptable Nachweise: Preismatrix, Beispiel‑3‑Jahres‑TCO für Ihre Flottengröße und Annahmen zu Bandbreitenkosten. (Siehe auch Remote access TCO.)

    Warnsignale: „Kontaktieren Sie den Vertrieb“ für jede Preisdetailfrage oder versteckte Kosten pro GB.

21. Veröffentlichen Sie unabhängige Dritt‑Attestierungen (SOC 2, ISO 27001) und deren Umfang?

    Warum das wichtig ist: Unabhängige Berichte sind nützlich, prüfen Sie aber, was sie tatsächlich abdecken (App, Infra, DevOps). Fordern Sie den neuesten Bericht und den Scope an.

    Akzeptable Nachweise: Report‑PDF oder Letter, Bridge‑Letters und Liste der ausgeschlossenen Services.

    Warnsignale: Alte oder nicht verfügbare Berichte oder Compliance‑Behauptungen ohne Scope‑Details.

22. Zeigen Sie uns eine anonymisierte Incident‑Timeline für einen vergangenen Produktionsausfall oder eine Kompromittierung.

    Warum das wichtig ist: Reale Vorfälle zeigen Reifegrad. Sie wollen Timeline, Root‑Cause, Behebung und Lessons Learned.

    Akzeptable Nachweise: Redigierter Incident‑Report mit konkreten Abhilfemaßnahmen und Verifikation der Fixes.

    Warnsignale: Verweigerung, Vorfallhistorie zu teilen oder nur generische PR‑Aussagen anzubieten.

Warum Tenvo's Managed‑Relay die pragmatische Voreinstellung ist

Operative Kosten sind relevant. Ein self‑gehostetes Relay vermeidet Drittinfrastruktur, verlagert aber Bereitschaftsdienst, Patching, Zertifikats‑Erneuerung, HA und Failover‑Tests auf Ihr Team. Für die meisten Käufer bedeutet das höhere Gesamtkosten und langsamere Wiederherstellung. Tenvo liefert native Clients für macOS, Windows und Linux, einen Browser-Client in der öffentlichen Beta und ein verwaltetes Relay, das wir für Sie betreiben, mit Servern in Deutschland. Pricing ist Free $0 / Lite $2.99/mo / Pro $7.99/mo. Unser verwaltetes Relay nimmt Ihnen den täglichen Betrieb ab; wir empfehlen es als Standard, es sei denn eine explizite schriftliche Anforderung — z. B. Datenresidenz, ein vom Internet isoliertes Netzwerk oder eine Richtlinie, die Dritt‑Relays verbietet — erzwingt Self‑Hosting.

Wann Sie auf Self‑Hosting bestehen sollten

Self‑Hosting ist nur aus engen Gründen sinnvoll: ein Compliance‑Mandat, das Dritt‑Relays verbietet, isolierte Netzwerke, die vom öffentlichen Internet nicht erreichbar sind, oder strikte Datenresidenzgesetze, die ein Managed‑Service nicht erfüllen kann. Wenn Sie diesen Weg wählen, fordern Sie Deployment‑Automatisierung, ein Upgrade‑Playbook und ein dokumentiertes Runbook. Für eine realistische Sicht auf versteckte Kosten siehe Self‑Hosted Remote Desktop: Why, How, and What Breaks und unsere Analyse der Gesamtkosten in Remote access TCO.

Evaluierungs‑Checkliste & nächste Schritte

• Führen Sie einen Proof‑of‑Concept durch, der P2P‑Fallbacks und Relay‑Nutzung testet und paket‑level Nachweise sowie Zertifikat‑Fingerprints erfasst.
• Fordern Sie redigierte Logs und ein Audit‑Paket an; vergleichen Sie Formate mit Ihrem SIEM. Siehe Remote Desktop Audit Logging für Auditor‑Erwartungen.
• Holen Sie von jedem Anbieter ein 3‑Jahres‑TCO ein, das Bereitschaft, Patching und Relay‑Egress‑Kosten einschließt; vergleichen Sie mit Tenvo's Managed‑Preisen.
• Lesen Sie Produkt‑Attestierungen und fordern Sie, wo relevant, ein Bridge‑Letter an. Wenn Sie einen tieferen Vergleich mit etablierten Anbietern benötigen, prüfen Sie TeamViewer comparison, AnyDesk comparison und RustDesk comparison.
• Wenn Sie Beschaffungs‑Sprache benötigen, wandeln Sie die 20 Fragen oben in zwingende Nachweis‑Punkte um (Diagramme, Zertifikat‑Fingerprints, Logs) und bewerten Sie Anbieter ausschließlich nach Belegen, nicht nach Aussagen.

Bereit, ein Managed‑Relay und einen nativen Client zu testen? Laden Sie einen Client herunter und führen Sie die gleichen 20 Prüfungen in einem kurzen Pilot durch: Tenvo herunterladen.