Skip to content
GoDesk
Zurück zum BlogUnternehmen

Remote Desktop SOC2: Welche Tools es unterstützen und wie man sie bewertet

GoDesk Editorial Team9 Min. Lesezeit
Remote Desktop SOC2: Welche Tools es unterstützen und wie man sie bewertet

Der Kauf eines Remote-Desktop-Tools für eine Umgebung, die SOC 2 erfüllen muss, fühlt sich an wie ein Minenfeld: Procurement verlangt einen SOC 2 Type II-Bericht, die Security will lückenlose Verschlüsselung und unveränderliche Logs, und IT sorgt sich um Support…

Der Kauf eines Remote-Desktop-Tools für eine Umgebung, die SOC 2 erfüllen muss, fühlt sich an wie ein Minenfeld: Procurement verlangt einen SOC 2 Type II-Bericht, Security will lückenlose Verschlüsselung und unveränderliche Protokolle, und die IT sorgt sich um Supportfähigkeit und Verfügbarkeit. Sie benötigen einen pragmatischen Weg, um festzustellen, welche Remote‑Access‑Lösungen Ihnen tatsächlich helfen, SOC 2‑Kontrollen zu erfüllen — und welche Monate an kompensatorischen Kontrollen und zusätzlicher Auditarbeit erzwingen.

Was SOC 2 für Remote‑Access‑Tools bedeutet

SOC 2 ist ein Prüfungsbericht, der beurteilt, ob eine Serviceorganisation Kontrollen entworfen und betrieben hat, die den Trust Services Criteria entsprechen (Security, Availability, Processing Integrity, Confidentiality und Privacy). Für die meisten Organisationen, die Remote‑Desktop‑Software nutzen, sind die Kategorien Security und Confidentiality primär relevant; Availability und Processing Integrity werden relevant, wenn das Tool für geschäftskritischen Support oder Produktionszugriff verwendet wird.

Wesentliche SOC 2‑Realitäten, die Sie beachten sollten:

  • SOC 2 Type I beschreibt das Design von Kontrollen zu einem Zeitpunkt; Type II weist die Wirksamkeit der Betriebsweise über einen Zeitraum nach (üblich 6–12 Monate).
  • Prüfer achten auf den Scope: Der SOC 2‑Bericht eines Anbieters muss explizit den Service abdecken, den Sie nutzen (die Remote‑Access‑Plattform und die gehostete Infrastruktur, falls der Anbieter diese verwaltet).
  • Ein SOC 2‑Bericht entbindet Sie nicht von Verantwortung. Ihre Organisation muss weiterhin zeigen, wie sie die Kontrollen des Anbieters in Ihr eigenes Audit‑System integriert.

    • Welche Klassen von Remote‑Desktop‑Tools für SOC 2 relevant sind

    Nicht alle Remote‑Desktop‑Angebote sind aus Compliance‑Sicht gleich. Es gibt drei grobe Kategorien mit unterschiedlichen Implikationen für SOC 2:

    • SaaS / vendor-hosted Enterprise‑Plattformen. Vom Anbieter verwaltete Stacks bieten in der Regel den einfachsten Weg zu einem SOC 2‑tauglichen Kontrollset — vorausgesetzt, der Anbieter hat tatsächlich einen scoped SOC 2 Type II‑Bericht. Der Kompromiss ist, dass Sie auf die Security‑Haltung, Incident‑Response und Datenverarbeitung des Anbieters angewiesen sind.
    • Self‑hosted/open‑source‑Lösungen. Produkte wie GoDesk (selbst hostbar) oder RustDesk geben Ihnen die Kontrolle. Das ist attraktiv, weil Sie den Service in Ihre Compliance‑Grenze stellen können, verschiebt aber auch die Beweislast für operative Kontrollen — Patchmanagement, Backups, physische Sicherheit und Logging — auf Ihre Organisation.
    • Hybrid / managed‑hosted Angebote. Manche Anbieter hosten, bieten aber isolierte Tenancy oder unterstützen bei Compliance‑Paketen. Das kann ein Mittelding sein: geringerer operativer Aufwand als Self‑Hosting und mehr Kontrolle als multitenante SaaS.

      • Jede Kategorie kann in ein SOC 2‑Programm passen. Die Frage ist, welche Kontrollverantwortungen Sie besitzen wollen und welche Sie auslagern.

      Har­te Kontroll‑Checkliste: Was ein Remote‑Desktop‑Produkt für SOC 2 bereitstellen muss

      Bei der Bewertung eines Remote‑Desktop‑Anbieters oder einer Lösung fordern Sie Nachweise und prüfbare Kontrollen in diesen Bereichen an. Diese Punkte lassen sich direkt auf die SOC 2‑Kriterien abbilden, die Prüfer prüfen.

      • Vendor SOC 2 Type II‑Bericht: Fordern Sie den aktuellen Bericht an, bestätigen Sie den Berichtszeitraum (6–12 Monate) und verifizieren Sie, dass der Scope den Remote‑Access‑Service und ggf. gehostete Infrastruktur einschließt. Kann der Anbieter keinen Type II‑Bericht liefern, rechnen Sie mit einer längeren Prüfung und kompensatorischen Kontrollen.
      • Verschlüsselung in Transit und at‑rest: Transport muss TLS 1.2 oder TLS 1.3 verwenden. Sensible Sitzungs‑Payloads und aufgezeichnete Sitzungen sollten at‑rest mit AES-256 oder gleichwertig verschlüsselt sein. Fragen Sie, wie Schlüssel verwaltet werden — nutzen sie ein KMS oder HSM? Werden Kunden‑Schlüssel unterstützt?
      • Authentifizierung und Identität: Unterstützung für SAML 2.0 oder OIDC für SSO, SCIM für Provisioning und verpflichtende MFA für Admin‑ und privilegierte Konten. Hardware‑basierte MFA (FIDO2/WebAuthn) ist ein Plus für Prüfer.
      • Role‑based Access Control (RBAC): Granulare Rollen (Read‑only Support, Full Control, File Transfer, Session Shadowing) und die Möglichkeit, Least‑Privilege‑Policies auf Benutzer und Gruppen anzuwenden.
      • Audit‑Logging und Manipulationssicherheit: Unveränderliche Audit‑Trails mit Benutzer‑IDs, Zeitstempeln, Sitzungs‑IDs, ausgeführten Aktionen (File Transfer, Clipboard Paste, Remote Commands). Empfohlene Aufbewahrung: 90–365 Tage je nach Risikoprofil. Logs sollten sichere Hashing‑Verfahren verwenden (z. B. SHA‑256) und für forensische Prüfungen exportierbar sein.
      • Sitzungsaufzeichnung und Einwilligung: Möglichkeit, Sitzungen aufzuzeichnen (falls erforderlich), diese verschlüsselt zu speichern und klare Indikatoren zu zeigen, wenn aufgezeichnet wird. Aufbewahrungs‑ und Löschrichtlinien sollten dokumentiert sein.
      • Netzwerkarchitektur und Segmentierung: Anbieter sollten Remote‑Control‑Traffic vom Management‑Plane isolieren, separate Schlüsselverwaltung nutzen und private Link / VPC‑Peering unterstützen, wenn für Enterprise‑Deployments angeboten.
      • Patching & Vulnerability‑Management: Klare SLAs für kritische (empfohlen <=30 days) und hohe (≤90 days) Schwachstellen, öffentliche CVE‑Verfolgung und jährliche Pen‑Tests. Fordern Sie den neuesten Pen‑Test‑Bericht oder zusammenfassende Remediation‑Statements an.
      • Data Residency & Subservice‑Organisationen: Bestätigen Sie, wo Server und Backups resideiren, und verlangen Sie Offenlegung ausgelagerter Subprozessoren. Für HIPAA‑Umgebungen sollten Sie eine BAA schriftlich erhalten.
      • Business Continuity & Backups: RTO/RPO‑Ziele und Nachweise regelmäßiger Backup‑Tests. Für Produktionsbetrieb erwarten Sie in der Regel RTOs im niedrigen Stundenbereich und verschlüsselte Backups mit getesteten Restore‑Prozeduren.
      • Change‑Management: Versionskontrolle, Release‑Notes, Change‑Approval‑Prozesse und Rollback‑Verfahren für Software‑Updates, die Security oder Verfügbarkeit beeinflussen könnten.

        • Wie man Behauptungen verifiziert — konkrete Tests und Fragen

        Ein SOC 2‑Bericht und Marketing‑Dokumente sind ein Anfang. Hier sind praktische Verifikationsschritte, die Ihre Security‑ oder Audit‑Teams vor Vertragsabschluss durchführen sollten:

        1. Fordern Sie den SOC 2 Type II‑Bericht des Anbieters an und verlangen Sie ein Management Letter oder Bridge Letter, falls der Berichtszeitraum Ihr Vertragsbeginn nicht abdeckt.
        2. Führen Sie ein kurzes Pilotprojekt durch, das SSO‑Provisioning, Onboarding und Deprovisioning via SCIM umfasst, und beobachten Sie den Sitzungslebenszyklus sowie die Verschlüsselung aufgezeichneter Sitzungen in der Praxis.
        3. Validieren Sie TLS‑Cipher‑Suites und Zertifikatsbehandlung mit Standardtools (z. B. testssl.sh). Bestätigen Sie TLS 1.2 oder 1.3 und das Fehlen schwacher Ciphers.
        4. Fordern Sie ein Architekturdiagramm vom Anbieter an, das Segmentierung, KMS/HSM‑Einsatz und Netzwerkflüsse zeigt. Verifizieren Sie, dass keine eingehenden Firewall‑Ports geöffnet werden müssen; falls doch, bewerten Sie dies als höheres Risiko und fordern kompensatorische Kontrollen. Siehe unser Guide on remote desktop without port forwarding für sichere Deployment‑Pattern.
        5. Überprüfen Sie Log‑Exporte: exportieren Sie einen 30‑tägigen Audit‑Log und prüfen Sie auf Benutzer‑IDs, Aktionen und kryptografische Integritätsmarker.
        6. Testen Sie Rollentrennung: Erstellen Sie ein Read‑only Support‑Konto und versuchen Sie privilegierte Aktionen, um sicherzustellen, dass RBAC wie dokumentiert funktioniert.
        7. Fordern Sie aktuelle Pen‑Test‑Zusammenfassungen und Remediation‑Tickets an. Weigert sich der Anbieter, zumindest eine Zusammenfassung bereitzustellen, eskalieren Sie an Procurement — Prüfer werden dieselben Fragen stellen.
        8. Wenn Sie self‑hosten planen, bestätigen Sie, dass Sie dokumentierte Kontrollen für physische Sicherheit, Server‑Hardening, Backup‑Verschlüsselung und einen Patch‑Cadence haben, den Ihr Prüfer akzeptieren wird.

          9. Self‑hosted vs. Vendor SOC 2: Wo die Verantwortung liegen sollte

          Es gibt keine universelle Antwort — Ihre Entscheidung sollte auf Control‑Maturity, interner Engineering‑Kapazität und Risikoappetit basieren.

          • SaaS‑Vendor mit SOC 2 Type II: Schneller zu beschaffen aus Audit‑Sicht. Der Anbieter übernimmt Infrastruktur, Schlüsselverwaltung und viele operative Kontrollen. Gut für Teams ohne operative Kapazität für sicheres Hosting. Nachteile: weniger direkte Kontrolle über Konfigurationen und potenziell höhere wiederkehrende Lizenzkosten.
          • Self‑hosted open‑source (GoDesk, RustDesk, etc.): Sie besitzen die Infrastruktur und fügen die Software in Ihre Kontrollumgebung ein. Das ist attraktiv für Organisationen, die volle Kontrolle über Data‑Residency, Custom‑Hardening oder Integration mit On‑Prem KMS benötigen. Die Trade‑offs sind Engineering‑Aufwand und Kosten: Erwarten Sie, Patching, Backups, Monitoring zu betreiben und Budget für Audit‑Readiness einzuplanen. Für Anleitung zum Betrieb self‑hosted Deployments siehe unser self-hosted-remote-desktop-guide.
          • Hybrid/managed‑hosted: Managed Hosting mit dedizierter Tenancy kann Audit‑Reibung reduzieren und gleichzeitig Kontrolle bewahren. Fragen Sie Anbieter, ob diese Hosted‑Tier in ihrem SOC 2‑Bericht scoped ist.

            • Kostensignale, die Sie erwarten sollten: Ein SOC 2‑Audit für ein Produkt liegt üblicherweise im unteren fünfstelligen Bereich (häufig $10k–$40k+), abhängig vom Scope und Auditor; Implementierung und Aufrechterhaltung von Kontrollen (Engineering‑Zeit, Logging‑Infrastruktur, Backups) sind wiederkehrende Betriebskosten. Die Preisgestaltung von Anbietern für Enterprise‑Remote‑Access variiert stark; berücksichtigen Sie Lizenzkosten pro gleichzeitigem Admin/Seat und den Preis für isolierte Tenancy oder Private‑Link‑Optionen. Wenn Sie einen schnellen Vergleich zu kommerziellen Preis‑Trade‑offs möchten, siehe unser godeskflow-vs-teamviewer-pricing‑Artikel.

            Häufige Audit‑Fallen und wie man sie vermeidet

            Teams fallen bei Remote‑Desktop‑Kontrollen häufig aus Gründen durch, die vermeidbar sind:

            • Scope‑Mismatch: Der SOC 2‑Bericht des Anbieters deckt Authentifizierungsdienste ab, nicht aber den eigentlichen Session‑Broker oder die Speicherung von Sitzungsaufzeichnungen. Bestätigen Sie immer die exakt eingeschlossenen Services.
            • Kein Nachweis der Wirksamkeit: Ein Type I‑Bericht oder eine interne Security‑Policy des Anbieters reicht für ein Type II‑Audit nicht aus. Wenn Sie Type II‑Nachweise benötigen, bestehen Sie auf dem Type II‑Bericht des Anbieters oder planen Sie kompensatorische Kontrollen auf Ihrer Seite ein.
            • Unzureichendes Logging oder zu kurze Aufbewahrung: Prüfer erwarten Logs, die den relevanten Untersuchungszeitraum abdecken. Halten Sie standardmäßig mindestens 90 Tage vor, und länger für stark regulierte Workloads.
            • Fehlkonfiguriertes SSO und Provisioning: Wenn User‑Provisioning/Deprovisioning nicht automatisiert über SCIM erfolgt, sind verwaiste Accounts ein häufiger Befund. Automatisieren Sie Provisioning und testen Sie regelmäßig.
            • Unsichere Sitzungsaufzeichnungen: Das Speichern von Sitzungsvideos unverschlüsselt oder auf allgemeinem Storage ohne Zugriffskontrollen fällt häufig bei Vertraulichkeitsprüfungen durch.

              • Praktisches Beispiel: Einen Anbieter in 7 Schritten bewerten

              1. Fordern Sie den aktuellen SOC 2 Type II‑Bericht an und verifizieren Sie Daten und Scope.
              2. Fordern Sie Architektur‑ und Datenflussdiagramme sowie eine Liste der Subprozessoren an.
              3. Führen Sie einen SSO/SCIM‑Pilot durch und testen Sie das Deprovisioning über einen Zeitraum von zwei Wochen.
              4. Exportieren und verifizieren Sie Audit‑Logs auf Inhalt und kryptografische Integrität.
              5. Bestätigen Sie Verschlüsselungsstandards (TLS1.2+/AES-256) und die Schlüsselverwaltungsstrategie.
              6. Prüfen Sie Incident‑Response‑Verfahren und SLA für Sicherheitsvorfälle.
              7. Erhalten Sie eine schriftliche BAA, wenn Sie ePHI verarbeiten, und bestätigen Sie Aufbewahrungs‑ und Löschrichtlinien für Sitzungsartefakte.

                8. Wann ein Anbieter die richtige Wahl ist vs. wann Self‑Hosting sinnvoll ist

                Wählen Sie eine vendor‑gehostete SOC 2‑Lösung, wenn:

                • Sie eine schnelle Beschaffung benötigen und der Anbieter einen aktuellen SOC 2 Type II‑Bericht hat, der auf den Service scoped ist.
                • Sie keine 24/7‑Betriebsabdeckung oder nicht genug Engineering‑Kapazität haben, um gehärtete Infrastruktur zu betreiben.
                • Sie vendor‑verwaltete Updates, On‑Call‑Support und SLA‑unterstützte Verfügbarkeitsgarantien bevorzugen.

                  • Wählen Sie Self‑Hosting, wenn:

                  • Sie alle Infrastruktur aus rechtlichen/regulatorischen Gründen kontrollieren müssen (Data‑Residency, nationale Vorschriften oder interne Richtlinien).
                  • Sie tiefe Integration mit On‑Prem KMS, SIEM oder proprietären Identity‑Providern benötigen, die vendor‑gehostete Modelle nicht erfüllen können.
                  • Sie Engineering‑Kapazität haben, Kontrollen für Audits zu implementieren und nachzuweisen (Patching, Backups, Logging, BCP).

                    • Beide Wege können SOC 2 bestehen. Die Entscheidung betrifft, wo die Kontrollen leben und wer deren Wirksamkeit nachweist.

                    Nützliche Links und Ressourcen

                    Wenn Sie tiefere technische Checklisten und sichere Deployment‑Pattern wünschen, behandelt unser remote-desktop-security‑Artikel Endpunkte und Netzwerkschutz auf Layer‑Ebene. Wenn Sie einen self‑hosted‑Ansatz in Betracht ziehen, konsultieren Sie unser self-hosted-remote-desktop-guide für empfohlene Architekturen und Betriebs‑Playbooks.

                    Schlussfolgerungen und nächste Schritte

                    SOC 2 für Remote‑Desktop dreht sich weniger um Marketing‑Behauptungen als um nachweisbare Kontrollen: Verschlüsselung, Identity‑ und Access‑Management, unveränderliche Logs und Nachweise der Betriebswirksamkeit über die Zeit. Anbieter, die einen scoped SOC 2 Type II‑Bericht veröffentlichen und klare Antworten auf die obige Checkliste geben, sparen Ihnen Zeit in Procurement und reduzieren Prüfungsaufwand. Wenn Sie sich für Self‑Hosting entscheiden, akzeptieren Sie, dass Sie die operativen Verantwortlichkeiten übernehmen und Budget für fortlaufende Audits und Evidenzsammlung einplanen müssen.

                    Wenn Sie ein self‑hosted Remote‑Desktop ausprobieren möchten, das für Inspectability und Integration mit Enterprise‑Kontrollen ausgelegt ist, laden Sie GoDesk herunter und betreiben Sie es in einem Testnetzwerk (oder sehen Sie sich unsere gehosteten Optionen auf /pricing an). Laden Sie die neueste Version auf /download herunter und nutzen Sie sie zusammen mit dem self-hosted-remote-desktop-guide, um eine SOC 2‑freundliche Deployment‑Umgebung aufzubauen.

                    All articlesTry GoDeskFlow Free
                    WEITERE INHALTE

                    Weitere Artikel

                    Technisch

                    Remote Desktop ohne Portweiterleitung: Wie es tatsächlich funktioniert

                    9 Min. Lesezeit

                    Sicherheit

                    Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell

                    10 Min. Lesezeit

                    Vergleich

                    RustDesk vs AnyDesk: Ein Käuferleitfaden 2026 (und die dritte Option, die die meisten Bewertungen auslassen)

                    11 Min. Lesezeit