ISO 27001 Fernzugriff: Kontrollen aus Anhang A zugeordnet

Sie benötigen ein Fernzugriffs‑Tool, das ein ISO 27001‑Audit besteht — keine Marketingversprechen. Dieser Leitfaden geht Kontrolle für Kontrolle (ISO/IEC 27001:2013) durch und erklärt, welche Nachweise, Konfigurationen und betrieblichen Kontrollen ein Auditor für ein Fernzugriffsprodukt und die von ihm erzeugten Sitzungen erwartet.

Welche Kontrollen aus Anhang A für Fernzugriff relevant sind

• A.6: Organisation der Informationssicherheit — Verantwortlichkeiten, Trennung von Aufgaben, Rollen für Genehmigung und Eskalation von Fernzugriffen.
• A.7: Personalsicherheit — Hintergrundprüfungen, Schulungen und Zugriffsvereinbarungen für Benutzer und Betreiber.
• A.8: Asset‑Management — Inventar der Remote‑Clients, Server und Anmeldeinformationen, die vom Tool verwendet werden.
• A.9: Zugriffskontrolle — Benutzerbereitstellung, Prinzip der geringsten Rechte, Sitzungssteuerung, privilegierter Zugriff.
• A.10: Kryptographie — zugelassene TLS‑Konfiguration, Zertifikats‑ und Schlüsselverwaltung.
• A.11: Physische Sicherheit — physisch sicherer Zugang zu Endpunkten, die Fernsitzungen ermöglichen.
• A.12: Betriebssicherheit — sichere Konfiguration, Patch‑Management, Malware‑Schutz und Änderungssteuerung für das Tool.
• A.13: Kommunikationssicherheit — Netzwerkkontrollen, NAT/Relay‑Verhalten, Firewall‑Regeln und Segmentierung.
• A.15: Lieferantenbeziehungen — Drittanbieter‑(Relay)‑Verträge, SLA, Prüfungsrechte.
• A.16: Informationssicherheits‑Vorfallmanagement — Erkennung, Eskalation und Aufzeichnung von Vorfällen mit Remote‑Sitzungen.
• A.18: Compliance — Protokollierung, Aufbewahrung, gesetzliche und regulatorische Verpflichtungen, Datenresidenz.

Identität, Authentifizierung und Zugriffskontrolle (A.9)

Zugriffskontrolle ist der Kern jedes Fernzugriffs‑Audits. Für jede Kontrolle in A.9 erwartet ein Auditor dokumentierte Richtlinien und messbare Durchsetzung. Praktisch bedeutet das:

• Benutzerbereitstellung & -entzug: dokumentierter Account‑Lifecycle, verknüpft mit HR oder IAM. Das Tool muss zeigen, wie Konten erstellt, wie Berechtigungen vergeben und wie Zugriff widerrufen wird (z. B. automatisches Deaktivieren bei Beendigung in AD).
• Prinzip der geringsten Rechte: Rollenabbildungen oder Gruppen, die einschränken, wer interaktive Sitzungen starten darf, wer auf bestimmte Zielhosts zugreifen kann und wer auf administrative Kontrolle eskalieren kann. Legen Sie Zugriffsmatrizen und Beispiele vor.
• Starke Authentifizierung: Multi‑Factor‑Authentifizierung für Controller und für den Zugriff auf Management‑Konsolen. Unterstützte Methoden sollten aufgelistet werden (TOTP, Push, Hardware‑Token, SSO). Testnachweis: MFA für 10 Beispielkonten aktiviert.
• Sitzungssteuerung: erzwungene Sitzungs‑Timeouts, ausdrückliche Einwilligung für unbeaufsichtigten Zugriff und Sitzungsbestätigung, wenn erforderlich. Nachweis = Konfigurations‑Screenshots und Sitzungsrichtlinien.
• Privilegierter Zugriff: zusätzliche Genehmigungen oder Just‑in‑time‑Erhöhungen für administrative Sitzungen, dokumentierte Genehmigungen und Trennung von Überwachungs‑ und Steuerungsberechtigungen.

Kryptographie und Schlüsselverwaltung (A.10)

Anhang A erwartet, dass kryptographische Kontrollen angemessen und dokumentiert sind. Beim Fernzugriff liegt der Fokus auf TLS, Zertifikatshandling und Schlüsselverwahrung.

Worauf Auditoren achten:

• TLS‑Konfiguration: Das Produkt sollte moderne TLS‑Versionen und Ciphers verwenden. Dokumentieren Sie die unterstützten TLS‑Versionen und den erzielten Mindeststandard. Legen Sie einen Scan vor, der zeigt, dass Relay‑ und Client‑Endpoints nur TLS 1.2+ (oder den von Ihrer Organisation vorgeschriebenen Mindeststandard) akzeptieren.
• Geräte‑Anmeldeinformationen: Das eingesetzte Modell (Gerätezertifikate, Schlüssel oder lang lebende Tokens) muss beschrieben und dessen Lifecycle abgedeckt sein — Ausstellung, Rotation, Sperrung. Bei Tenvo verwendet der Transport TLS mit einem gerätespezifischen Zertifikat; beachten Sie, dass bei Proxying über ein Relay TLS am Relay terminiert, sodass der Relay‑Betreiber Sitzungen einsehen kann.
• Schlüsselspeicherung: Wo private Schlüssel liegen (HSM, OS‑Keystore, TPM) und wer Zugriff hat. Nachweise: Screenshots, Schlüsselrotations‑Richtlinie und Beispiele für abgelaufene/gesperrte Zertifikate.
• Behaupten Sie nicht, dass das Relay "nicht entschlüsseln kann": Seien Sie in Ihrer Risikobewertung explizit, ob Relays TLS terminieren und welche vertraglichen sowie technischen Minderungsmaßnahmen (z. B. dedizierter Relay, geprüfter Betreiber) Sie implementiert haben.

Netzwerk und Kommunikation (A.13)

Fernzugriffs‑Tools transportieren Daten über Firmen‑Netzwerke, Heimnetzwerke und das öffentliche Internet. Die Erwartung aus Anhang A ist dokumentierte Netzwerkkontrollen, Segmentierung und eine Begründung für eingesetzte Dritt‑Relay‑Pfade.

• Topologie‑ und Flussdiagramme: Zeigen Sie direkte Peer‑to‑Peer‑Verbindungen vs. NAT‑Traversal vs. Relay‑Flows. Kennzeichnen Sie, welche Pfade Ihr Perimeter durchlaufen und welche über Dritte geleitet werden.
• Firewall‑ und Port‑Policy: Begründen Sie offene Ports und bevorzugen Sie ausgehende Verbindungen von Endpunkten. Beispielnachweise: Firewall‑Regeln, Netzdiagramme und ein Test, der zeigt, dass bei Nutzung des managed Relay keine eingehenden Ports geöffnet werden müssen.
• Segmentierung: Endpunkte für Fernzugriff sollten in einem segmentierten Netzwerk oder einer Jump‑Host‑Zone platziert werden. Legen Sie ACLs oder Microsegmentierungsregeln vor, die einschränken, was eine Remote‑Sitzung erreichen kann.
• Relay‑Auswahl und Resilienz: Wenn Sie ein Drittanbieter‑Relay verwenden (häufig für Internet‑Erreichbarkeit), fügen Sie Vertragsklauseln, Geo‑Standorte der Relays und Multi‑Region‑Failover nach. Tenvo’s managed relay ist die Standardempfehlung: native Clients für Windows/macOS/Linux, ein Browser‑Client (Public Beta) und ein Multi‑Region managed Relay. Die Tenvo‑Preismodelle sind Free $0 / Lite $2.99/mo / Pro $7.99/mo — berücksichtigen Sie SLA und Betriebskosten in Ihrer Lieferantenentscheidung.
• Wann Self‑Hosting sinnvoll ist: Self‑Hosting ist nur dann die richtige Wahl, wenn eine schriftliche Vorgabe dies zwingend fordert (Datenresidenz, isoliertes Netzwerk oder eine Compliance‑Regel, die Drittinfrastruktur verbietet). Dokumentieren Sie in der Dokumentation explizit, warum Sie managed Relay gegenüber Self‑Hosting gewählt haben, und fügen Sie einen Vergleich der Betriebskosten (Patching, Schlüsselverwaltung, Zertifikats‑Erneuerung, Failover) bei.

Betrieb, Protokollierung und Monitoring (A.12 und A.16)

Auditoren erwarten vollständige, manipulationsresistente Logs für Remote‑Sitzungen — wer verbunden war, von wo, was getan wurde und wie lange. Das Tool muss sich in Ihre Logging‑ und SIEM‑Prozesse integrieren lassen.

• Ereignistypen: Sitzungsstart/-stopp, verbindende Benutzeridentität, Zielhost, Quell‑IP, Relay‑Knoten, Sitzungsdauer, Dateiübertragungen, Zwischenablage‑Ereignisse und Kommando‑Elevation. Ordnen Sie diese Ihrem SIEM‑Ereignis‑Namen zu.
• Aufbewahrung & Integrität: Definieren Sie Aufbewahrungsfristen zur Erfüllung gesetzlicher und interner Vorgaben und zeigen Sie, wie Logs vor Manipulation geschützt sind (write‑once‑Speicherung, Aufbewahrungsrichtlinien, Zugriffskontrollen). Nachweise: exportierte Beispiel‑Logs, Aufbewahrungs‑Konfiguration und Screenshots von S3‑ oder SIEM‑Aufbewahrungsrichtlinien.
• Sitzungsaufzeichnung: Wenn Sie Video oder Tastenanschläge aufzeichnen, dokumentieren Sie Einwilligung, Speicherort, Verschlüsselung im Ruhezustand und Zugriffsprüfungen. Sitzungsaufzeichnung hat Datenschutzimplikationen — berücksichtigen Sie das in HR‑ und Rechtsfreigaben.
• Alerting & Incident Response: Definieren Sie Erkennungsregeln (z. B. unerwartete Admin‑Sitzungen außerhalb der Geschäftszeiten, Sitzungen aus neuen IP‑Bereichen) und verknüpfen Sie diese mit Incident‑Response‑Playbooks. Nachweis = Beispiel‑Alertregel, Incident‑Ticket und Post‑Mortem einer Übung.
• Siehe auch: Protokollierung von Remote‑Desktop‑Audits für Templates und SIEM‑Mappings.

Lieferantenmanagement & rechtliche Compliance (A.15 und A.18)

Die Nutzung eines managed Relay oder eines kommerziellen Fernzugriffs‑Anbieters macht Lieferantenkontrollen verpflichtend. Anhang A verlangt, dass Sie den Relay/Operator als Lieferanten behandeln und Due‑Diligence durchführen.

• Verträge & SLAs: Schließen Sie Vertraulichkeitsklauseln, Auftragsverarbeitungsbedingungen, Fristen für Incident‑Meldungen und Prüfungsrechte ein. Für regionale Compliance geben Sie Relay‑Geo‑Standorte an oder wählen dedizierte Relay‑Regionen.
• Drittanbieter‑Absicherung: Holen Sie SOC 2, ISO 27001‑Zertifikate oder Äquivalente ein und fügen Sie den Bericht bei. Wenn der Relay TLS terminiert, bestätigen Sie schriftlich die Zugriffsgrenzen und Kontrollen des Betreibers.
• Datenresidenz: Wenn Regulierer verlangen, dass Sitzungsverkehr im Land bleibt, sind nur Self‑Hosting oder ein regionaler Relay akzeptabel. Dokumentieren Sie die Entscheidung und die kompensierenden Kontrollen, falls Sie Relays außerhalb der Jurisdiktion einsetzen.
• Vertraglicher Ausstieg: Definieren Sie, wie Logs exportiert und Anmeldeinformationen bei Vertragsbeendigung entfernt werden.
• Für Hinweise zu Hosting‑Entscheidungen und Abwägungen siehe Self‑Hosted Remote Desktop: Warum, wie und was dabei kaputtgeht.

Menschliche Faktoren, Endpunkte und Geräteverwaltung (A.7, A.8, A.11)

Fernzugriff ist nur so sicher wie die Endpunkte und die Personen, die ihn nutzen. Anhang A erwartet, dass HR‑ und Geräte‑Kontrollen implementiert sind.

• Onboarding & Schulung: Nehmen Sie rollenbezogene Schulungen für Mitarbeitende auf, die Fernzugriff nutzen oder unterstützen. Nachweis: Schulungsprotokolle, Testergebnisse und unterschriebene Nutzungsvereinbarungen.
• Härtung der Endpunkte: Inventarisieren Sie alle Geräte, die Remote‑Sitzungen hosten dürfen; stellen Sie EDR/AV, Festplattenverschlüsselung, OS‑Patching und Sperrbildschirm‑Richtlinien sicher. Legen Sie Beispielberichte zur Geräte‑Compliance vor.
• Unbeaufsichtigter Zugriff: Erfordern Sie eine dokumentierte Genehmigung für unbeaufsichtigte Sitzungen und getrennte administrative Anmeldeinformationen für Remote‑Access‑Software (keine geteilten lokalen Admin‑Passwörter ohne Rechtfertigung).
• Bring‑your‑own‑device (BYOD): Wenn BYOD erlaubt ist, legen Sie MDM‑Profile, Conditional‑Access‑Regeln und die Mindestkonfiguration vor, die erfüllt sein muss, bevor ein Gerät für Remote‑Sitzungen genutzt werden darf.

Implementierungs‑Checkliste — was Sie für ein Audit vorbereiten sollten

• Richtlinien & Verfahren: eine Fernzugriffsrichtlinie, die erlaubte Nutzung, Genehmigungsworkflows, MFA, Trennung der Aufgaben und Vorfallbearbeitung abdeckt.
• Konfigurationsnachweise: Screenshots oder Exporte, die aktiviertes MFA, konfigurierte Sitzungs‑Timeouts, erzwungene TLS‑Versionen und den Zeitplan für Zertifikatsrotation zeigen.
• Protokollnachweise: 90 Tage Sitzungslogs (oder die Aufbewahrungsfrist Ihrer Organisation), eine Beispiel‑SIEM‑Alertmeldung, die mit einem Testvorfall verknüpft ist, und Nachweis der Log‑Integrität.
• Lieferantendokumentation: Verträge, SOC/ISO‑Berichte und Liste der Relay‑Geo‑Standorte.
• Zugriffsüberprüfungen: Nachweise über abgeschlossene vierteljährliche Zugriffsprüfungen für Stichproben privilegierter Konten (zeigt Änderungen und Genehmigungen).
• Penetrationstest oder Vulnerability‑Scan: aktueller Scan‑Bericht der Remote‑Access‑Endpoints und Relays mit nachverfolgter Behebung.

Betriebliche Kompromisse: managed Relay vs. Self‑Hosting — die Compliance‑Perspektive

Aus Compliance‑ und Betriebssicht ist ein managed Relay oft mit geringerem Gesamtaufwand und niedrigerem Risiko verbunden. Sie vermeiden den Betrieb der Relay‑Software, das Erneuern globaler Zertifikate, das Pflegen von Multi‑Region‑Failover und 24/7‑On‑Call‑Verpflichtungen für Relay‑Verfügbarkeit. Tenvo’s managed relay wird als Standardempfehlung für die meisten Organisationen positioniert, weil es Multi‑Region‑Failover und Client‑Updates bündelt; die Preismodelle (Free $0 / Lite $2.99/mo / Pro $7.99/mo) spiegeln unterschiedliche Support‑/SLA‑Level wider.

Self‑Hosting ist jedoch angemessen und gerechtfertigt, wenn eine schriftliche Vorgabe Dritt‑Infrastruktur verbietet (z. B. bestimmte öffentliche Auftraggeber‑Regeln, strenge Datenresidenzgesetze oder ein physisch isoliertes Netzwerk). Wenn Sie Self‑Hosting wählen, dokumentieren Sie die zusätzlichen betrieblichen Aufgaben, die Sie übernehmen: Hochverfügbarkeit, Zertifikatsmanagement, Patching und forensischer Zugriff auf Relay‑Logs.

Tests und Evidenzerhebung — praktische Schritte

• Discovery‑Test: Erstellen Sie ein Netzwerkflussdiagramm von einem Client zum Ziel, das zeigt, ob die Sitzung direkt P2P ist oder über einen Relay‑Proxy geleitet wird.
• Log‑Sampling: Exportieren Sie 30–90 Tage Sitzungslogs und prüfen Sie die von der Richtlinie geforderten Felder (Benutzer, Quell‑IP, Ziel, Dauer, Relay‑Knoten).
• Konfigurationsaudit: Führen Sie eine Basis‑Konfigurationscheckliste gegen Client‑ und Server‑Builds aus, um TLS‑Einstellungen, durchgesetztes MFA und Sitzungsrichtlinien nachzuweisen.
• Incident‑Übung: Simulieren Sie eine unautorisierte Sitzung und führen Sie Ihre Erkennungs‑ und IR‑Prozesse durch; bewahren Sie das Post‑Mortem und das Ticket als Audit‑Nachweis auf.
• Zugriffsüberprüfung: Führen Sie eine vierteljährliche Prüfung privilegierter Zugänge durch und speichern Sie Genehmigungen in Ihrem IAM‑ oder Ticketingsystem.

Quellen und weiterführende Lektüre

Diese internen Artikel bieten tiefere operative Anleitung, die Sie in Ihrem ISMS wiederverwenden können: Ist Remote Desktop sicher? Ein ehrliches Bedrohungsmodell, Protokollierung von Remote‑Desktop‑Audits und Remote Desktop ohne Port‑Weiterleitung erklärt. Wenn Sie Hosting‑Modelle abwägen, lesen Sie auch Self‑Hosted Remote Desktop: Warum, wie und was dabei kaputtgeht.

Abschließende Hinweise und kurze Checkliste

ISO 27001‑Auditoren prüfen kein Marketing: Sie prüfen Richtlinien, Konfigurationen, Logs, Verträge und den Betrieb. Behandeln Sie Ihr Remote‑Access‑Tool als eine kritische Kontrolle — ordnen Sie es den oben genannten Kontrollen aus Anhang A zu, liefern Sie Konfigurationsnachweise, führen Sie Zugriffsüberprüfungen durch und beziehen Sie den Relay‑Betreiber in die Lieferantendue‑diligence ein. Setzen Sie standardmäßig auf ein managed Relay, sofern keine schriftliche Compliance‑Vorgabe Self‑Hosting erzwingt; berücksichtigen Sie bei der Gegenüberstellung der Optionen die betrieblichen Kosten für den Betrieb von Relays.

Sind Sie bereit, ein Remote‑Access‑Setup anhand Ihrer Anhang‑A‑Checkliste zu testen? Laden Sie Tenvo herunter und probieren Sie es mit dem managed Relay aus (oder prüfen Sie Self‑Host‑Optionen, wenn Ihre Compliance dies verlangt): Tenvo herunterladen.