VPN für 1C und RDP: sicherer Fernzugriff für Buchhaltung und Lager – der komplette Leitfaden

Einleitung: Warum das Thema relevant ist und was Sie erwartet

Fernzugriff auf 1C für Buchhaltung und Lager im Jahr 2026 ist mehr als nur eine einfache RDP-Verbindung über ein beliebiges VPN. Es ist eine technische Disziplin an der Schnittstelle von Netzwerken, Sicherheit und Anwendungsperformance. Remote-Nutzer erwarten, dass 1C in Sekundenschnelle startet, Dokumente nicht verloren gehen und die IT-Sicherheitsabteilung beruhigt schlafen kann: keine Datenlecks, keine geteilten Passwörter, keine Schattenclients. In diesem Leitfaden zeigen wir den kompletten Weg: von den Grundlagen bis zu fortgeschrittenen Mustern, vom Netzwerklayout und der Protokollwahl bis hin zu HA-Architekturen, RD Gateway, MFA, Monitoring, Checklisten und typischen Anwendungsfällen.

Das lernen Sie: Wie Sie die Topologie wählen (RDP vs. leichter 1C-Client über VPN), wie Sie WireGuard, IKEv2 oder OpenVPN passend zu Ihren Risiken und Plattformen einrichten, wie man RD Gateway und NLA/TLS-Richtlinien für RDP konfiguriert, site-to-site-Verbindungen für Filialen und Lager baut, Kanäle und Latenz berechnet, Hochverfügbarkeit für 1C-Cluster und VPN sicherstellt, häufige Fehler erkennt, die Performance und Sicherheit beeinträchtigen, welche Werkzeuge sich in der Praxis bewähren und wie Sie schnell mit einem Pilotprojekt starten können, ohne lange Beschaffungsprozesse.

Grundlagen: Schlüsselkonzepte und Begriffe

1C: Server-Architektur. Eine produktive 1C:Enterprise 8.x-Installation besteht aus dem 1C-Server (Cluster der Arbeitsprozesse), der Datenbank (MS SQL Server oder PostgreSQL), einem Dateispeicher (bei Einsatz von Dateiaustausch), Lizenzservern und Hilfsdiensten (Cluster-Agent, RAS). Der Client kann leicht oder voll installiert sein oder innerhalb einer RDP-Sitzung auf einem Windows Server Terminalserver (RD Session Host) laufen.

RDP vs. leichter Zugriff über VPN. Zwei grundlegende Ansätze: (1) Benutzer verbinden sich per RDP zum Terminalserver mit installiertem 1C-Client; (2) Benutzer installieren den 1C-Client lokal und greifen per VPN auf 1C- und DB-Server zu. Variante 1 reduziert Netzwerktraffic und vereinfacht das Management, Variante 2 spart Terminallizenzen ein, ist aber empfindlicher gegenüber Latenzen und Kanalqualität.

VPN-Protokolle. Für Unternehmenseinsatz 2026 sind WireGuard (Minimalismus, Geschwindigkeit, Einfachheit), IKEv2/IPsec (Windows/iOS/Android-Kompatibilität, Zertifikatsunterstützung), OpenVPN (Flexibilität, Reife), SSTP (TLS über Port 443 zur Umgehung harter Firewalls) und L2TP/IPsec (breite Kompatibilität, aber zunehmend veraltet) entscheidend. Für site-to-site vor allem IPsec/IKEv2 oder WireGuard.

Zero Trust und MFA. Das klassische Modell "Netzwerk ist vertrauenswürdig, Internet nicht" weicht Zero Trust: Jeder Nutzer und jedes Gerät wird bei jedem Zugriff geprüft. Mindestens umgesetzt wird MFA (Einmalcodes/Push), Netzwerksegmentierung, NAC/MDM, Beschränkung von RDP und SMB, Kontrolle der Quell-IP (Allowlist).

Sicherheit bei RDP. NLA aktivieren, TLS 1.2+ nutzen, alte Cipher verbieten, Zugriffsgruppen ausschließlich über AD steuern, RD Gateway oder VPN mit ACL einsetzen, Logging und Monitoring aktivieren, Clipboard- und Laufwerksumleitung bei sensiblen Daten blockieren, Idle-Timeouts und Sessionzeitlimits setzen.

Tieferer Einblick: Performance, Sicherheit, Manageability

Performance von 1C und Netzwerk. 1C-Client ist latenzempfindlich: bis ca. 30–50 ms ist es komfortabel; über 80–100 ms bemerken Nutzer Verzögerungen, besonders bei vielen kleinen Abfragen. RDP verschiebt die Berechnungen auf den Server und überträgt per Netzwerk nur Bitmap-Updates; durchschnittlicher Verbrauch liegt bei 100 bis 300 Kbit/s pro Nutzer im Bürobetrieb, mit Peaks beim Drucken, Kopieren und Video.

RDP auf Terminalserver. Je leistungsfähiger der Server, desto effizienter die Konsolidierung. Richtwerte: Pro vCPU des RD Hosts 8–15 leichte 1C-Sitzungen, abhängig von 1C-Konfiguration und Berichten. Speicherbedarf 1,5–3 GB pro Session bei heavy Office-Anwendungen, 0,8–1,5 GB in minimaler Umgebung. Immer Profile mit Limits, Schriftcache, Visual-Optimierungen (keine Animationen) und SSD/NVMe-Datenträger nutzen.

VPN-Sicherheit. Prinzipien: Minimaler Perimeter (separates VPN-Interface und ACL), kein Split-Tunnel bei sensiblen oder Finanzdaten, starke Authentifizierung (Zertifikate/Keys + MFA), Schlüsselrotation, keine Wiederverwendung von Konfigurationen, Gerätebindung, Clientinventarisierung, Verbindungsprotokollierung, Anomalie-Monitoring (häufige Neuverbindungen, ungewöhnliche Geo-IP, Logins nachts).

Manageability und Skalierung. Zentrale Richtlinien via AD/GPO/Microsoft Intune oder MDM, Konfigurationsvorlagen, automatisches Deployment (MSI/PowerShell), Canary-Updates, regelmäßige Penetrationstests für RDP/VPN, Risikotabellen, RTO/RPO für Datenbanken und 1C-Cluster, regelmäßige DR-Tests.

Praxis 1: Grundszenario „RDP über VPN“ für Buchhaltung

Wann wählen?

Wenn Nutzer remote mit schweren Berichten und Druckaufgaben arbeiten, Kanäle instabil sind oder maximale UI-Reaktionsgeschwindigkeit ohne Latenzsensitivität wichtig ist, empfiehlt sich RDP auf Terminalserver hinter einem Unternehmens-VPN.

Architektur

• Laptop/PC des Anwenders mit VPN-Client
• VPN-Konzentrator (WireGuard/IKEv2/OpenVPN) in DMZ oder separatem Segment
• RD Gateway (optional) und RD Session Host (Terminalserver)
• 1C-Cluster- und DB-Server im geschützten Segment

Implementierungsschritte

1. AD und Gruppen vorbereiten. Erstellen Sie Gruppen „VPN-Users-Accounting“, „RDP-Users-Accounting“, „1C-Users-Accounting“. Zugriffe strikt nach Minimalprinzip trennen.
2. VPN einrichten. Protokoll wählen: WireGuard für Geschwindigkeit und Einfachheit; IKEv2 für native Windows- und Zertifikatsunterstützung; OpenVPN bei heterogenen Betriebssystemen. Server in separates Subnetz auslagern (z.B. 10.60.0.0/24), Standardmäßig Zugriff auf sensitive Segmente verbieten.
3. Terminalserver konfigurieren. Remote Desktop Services Rollen installieren: RD Licensing, RD Session Host, (optional) RD Gateway. NLA aktivieren, direkten RDP-Zugang aus dem Internet sperren. Zugriff ggf. nur aus VPN-Subnetz und über RD Gateway erlauben.
4. RDP-Profile und GPOs. GPOs anlegen, die Laufwerks- und Clipboard-Umleitung für sensible Gruppen deaktivieren. Idle Timeout von 15–30 min, maximale Sessionzeit 8–10 Stunden, erneute Logins begrenzen.
5. 1C-Client und Drucker bereitstellen. 1C auf Terminalserver installieren, Drucker über Easy Print oder native Treiber konfigurieren; für Buchhaltung mit Steuerberichten virtuelle PDF-Drucker nutzen, die in geschützte Verzeichnisse routen.
6. Monitoring einschalten. Performance-Metriken (CPU je Session, RAM, IOPS, Latenz), RDP-Login-Logs, Fehlversuche und Sessions über 8 Stunden erfassen.

Beispiel ACL

Firewall-ACL: UDP 51820 (WireGuard) von extern erlauben zum VPN-Konzentrator; vom VPN-Subnetz 10.60.0.0/24 TCP 3389 nur zu RD Gateway/Host; direkter Zugriff auf DB und 1C-Server von Clients verboten.

Checkliste: Produktionsreife

• NLA und TLS 1.2+ auf RDP aktiviert
• VPN ohne Split-Tunnel für sensible Gruppen
• MFA aktiviert (ADFS/AzureAD/OTP)
• Strenge Passwortregeln und IP-Blocklists
• Logging in SIEM integriert mit Korrelationen
• Backups von Profilen und 1C-Profilen

Praxis 2: Site-to-Site VPN für Lager und Filialen

Wann wählen?

Lager-TSDs, Etikettendrucker, Waagen und Arbeitsplatzsysteme müssen zuverlässig mit 1C und Peripherie funktionieren. Site-to-Site VPN schafft einen dauerhaft geschützten Tunnel zwischen Filiale und Zentrale.

Architektur

• Büro-VPN-Gateway (WireGuard oder IPsec/IKEv2) mit statischer externer IP
• Filialrouter/-gateway mit Unterstützung für gewähltes Protokoll
• Subnetz-Routing: 10.50.0.0/24 (Office-DC, 1C, DB), 10.70.0.0/24 (Lager)

Implementierungsschritte

1. IP-Plan. Einzigartige Subnetze an Filialen vergeben. Routen so definieren, dass Traffic zu 10.50.0.0/24 durch Tunnel läuft, restlicher Traffic ins Internet geht.
2. Protokoll. Für Gateway-zu-Gateway meist IKEv2 mit AES-GCM und PFS oder WireGuard mit Key-Exchange und IP-Beschränkung. Keepalive und Link-Down-Detektion konfigurieren.
3. QoS und Priorisierung. RDP-Sitzungen mit DSCP AF21/AF31 priorisieren; Druckverkehr normal; OS-Updates im Hintergrund mit niedriger Priorität.
4. Peripherie. Ports für Drucker und TSDs nur zwischen entsprechenden Subnetzen öffnen; Broadcast-Protokolle außerhalb Filiale vermeiden.
5. Monitoring. Auf beiden Tunnelenden Metriken erfassen: Latenz, Jitter, Paketverlust, Neuverhandlungen.

Redundanz

Zwei aktive/passive Provider in der Filiale, zwei Tunnel zu unterschiedlichen Rechenzentrums-/Cloud-IP-Adressen, Priorisierung via SLA-Script. WireGuard mit zwei Peers unterschiedlicher Metrik, IPsec mit zwei IKE-SAs zu verschiedenen IPs.

Praxis 3: RD Gateway + MFA und Zero Trust Patterns

Warum RD Gateway?

RD Gateway kapselt RDP in HTTPS (TCP 443) ein, bindet an Zertifikate, ermöglicht Zugriffsrichtlinien auf Nutzer- und Geräteebene und lässt sich mit MFA integrieren. Es ist eine zusätzliche Kontrollinstanz neben VPN und ideal, um RDP-Zugriff über eine Gateway zu steuern.

CAP-/RAP-Richtlinien

• CAP (Connection Authorization Policy): Wer und wie verbinden darf (AD-Gruppen, MFA, Zeitfenster)
• RAP (Resource Authorization Policy): Welche Ressourcen erreichbar sind (Liste der Hosts, Computergruppen)

Schritt-für-Schritt Einrichtung

1. RD Gateway Rolle auf separatem Windows Server installieren, Serverzertifikat (SHA-256, SAN mit FQDN) zuweisen.
2. Nur TLS 1.2/1.3 aktivieren, alte Cipher via GPO oder Registry deaktivieren.
3. CAP konfigurieren: NLA verlangen, Mitgliedschaft in „RDP-Users-Accounting“, MFA via NPS Extension oder Drittanbieter.
4. RAP konfigurieren: Zugriff ausschließlich auf Gruppe „RDSH-Servers-1C“.
5. Zugriff auf RD Gateway nur aus VPN-Subnetz oder Unternehmens-IP-Bereichen erlauben.

Zero Trust Erweiterungen

• Gerätestatus: Zugriff nur von geprüften Geräten mit Firmenzertifikat, Antivirus, Festplattenverschlüsselung
• Just-in-Time: Zugriff zeitlich befristet (2–8 Stunden)
• Just-Enough-Access: Minimale Servermenge im RAP
• Audit: Aufzeichnung von RDP-Sitzungen bei kritischen Rollen

Praxis 4: VPN-Einrichtung – WireGuard und IKEv2 Schritt für Schritt

WireGuard (Linux/Windows)

1. Server. VM in DMZ reservieren, WireGuard installieren, Schlüssel anlegen. Beispiel: Serveradresse 10.60.0.1/24, Port 51820/UDP.
2. ACL. Firewall UDP 51820 von Internet nur zum VPN-Server öffnen, Zugriff aus 10.60.0.0/24 auf 10.55.0.10 (RD Host) TCP 3389 erlauben.
3. Peer-Vorlage. Für Buchhalter: AllowedIPs=10.60.0.10/32 plus Routen für RDP-Subnetz. PersistentKeepalive=25 für Clients hinter NAT einschalten.
4. Clients. Deployment per MSI und PowerShell. Konfigurationen nach Nutzer-UPN benennen. Schlüssel zentral und sicher verwahren mit Zugriffsbeschränkung.
5. Wartung. Schlüsselrotation alle 90–180 Tage. Verbindungen protokollieren (Zeit, IP, Dauer). SIEM-Regeln für häufige Fehlversuche.

IKEv2/IPsec (Windows Server)

1. Zertifikate. Eigenes Unternehmens-CA aufsetzen oder vertrauenswürdiges Serverzertifikat nutzen. Vorlage für EAP-TLS (Clientzertifikate) ausstellen.
2. RRAS. Remote Access Rolle installieren, IKEv2 aktivieren. Verschlüsselungspolicies einstellen: AES-256-GCM, DH Gruppe 14/19, PFS.
3. NPS. Radius-Policen konfigurieren und MFA bei Bedarf anbinden.
4. Routing. Für Buchhaltungsgruppen Split-Tunnel ausschalten; für IT bei Bedarf Split-Tunnel nur zu 1C/DB erlauben.
5. Clients. IKEv2-Profile per GPO/Intune verteilen. BYOD mit EAP-TLS und MDM-Zertifikatsausgabe absichern.

Best Practices für beide Protokolle

• Einheitliche Adressierung und Reserven: Subnetze in Filialen nicht überschneiden
• Gleichzeitige Sitzungen pro Nutzer begrenzen
• Automatisches Abmelden bei Inaktivität, kein mehrfaches Verwenden von Configs
• Segmentierung: RDP-Zugriff ja, DB/1C nur für Server

Typische Architekturen und Vergleich der Ansätze

• RDP über VPN: Beste Nutzererfahrung bei schwachen Leitungen, zentrales Management, RDS CAL notwendig, strikte Sicherheitsrichtlinien für RDP erforderlich.
• Leichter 1C-Client über VPN: Weniger Last auf Terminalservern, aber höhere Anforderungen an Latenz und Kanalqualität, verteilte Client-Version-Kontrolle.
• RD Gateway + VPN: Höchste Zugriffskontrolle und Audit, flexible Segmentierung, ideal für Zero Trust.
• Site-to-Site: Dauerhafte Filial-/Lagerverbindung, einfache Peripherieintegration, erfordert sorgfältige Routenplanung und QoS.

Häufige Fehler: Was Sicherheit und Geschwindigkeit schadet

• Offener RDP-Zugang im Internet. Auch mit NLA risikoreich. Always VPN und/oder RD Gateway benutzen.
• Split-Tunnel bei sensiblen Gruppen. Datenlecks und MITM-Risiken. Abschalten.
• Veraltete Protokolle. L2TP ohne IPsec, PPTP, TLS 1.0 verboten.
• Gemeinsame Hauptkonten. Keine Auditfähigkeit, Compliance-Verstoß. Nur persönliche Konten und MFA nutzen.
• Fehlende Segmentierung. VPN-Clients sehen DB und 1C direkt. Nur über RDS Zugang erlauben.
• Fehlende Planung der RDP-Profile. RAM/IOPS-Engpässe führen zu Abbrüchen. Kapazität kalkulieren, SSD/NVMe verwenden, Hintergrundlasten limitieren.
• Druckverkehr unkomprimiert über WAN. Große Traffic-Spitzen. Universal-Treiber, Kompression und Buffering verwenden.
• Keine Redundanz für VPN/Kanäle. Jede Störung führt zu Ausfall. Provider und Gateway doppelt auslegen.

Tools und Ressourcen: Bewährte Lösungen für die Praxis

Server und Betriebssysteme

• Windows Server (RDS, RRAS, NPS, AD, GPO)
• Linux (WireGuard, StrongSwan, OpenVPN)
• Datenbanken: MS SQL Server, PostgreSQL mit Backup und Monitoring

Clients und Management

• WireGuard Client (Win/macOS/Linux/iOS/Android)
• Integrierte IKEv2-Clients auf Windows/iOS/macOS
• OpenVPN GUI/Connect
• MDM/Intune für Profil- und Zertifikatsverteilung

Monitoring und Sicherheit

• Perfmon/ETW für RDS und 1C
• Windows Event Forwarding oder SIEM-Agent
• NetFlow/IPFIX am Perimeter; Zabbix/Prometheus für Metriken
• EDR/Antivirus auf RDS-Servern und Clients

Schneller Pilot ohne großen Einkauf

Für einen raschen POC sicheren Zugriffs auf 1C und RDP (z.B. Audit oder Büroumzug) ist der Dienst vpn.how praktisch: Persönlicher VPN-Server mit dedizierter IP, unterstützt WireGuard, OpenVPN, IKEv2, L2TP, SSTP (auf passende Infrastruktur und Aufgabe wählbar). Serverstandorte: Moskau, Sankt Petersburg, Amsterdam, Frankfurt, London, New York, San Jose, Chicago, Singapur, Sydney, Madrid, Helsinki, Stockholm, Warschau, Kopenhagen, Stavanger. Zahlungsarten: Russische Karten (Tinkoff, Ozon), SBP, USDT/BTC. Preise ab 490 ₽ pro Tag, ab 2490 ₽ monatlich mit Rabatten bei längerer Laufzeit. Server startet ca. 5 Minuten nach Zahlung. Empfehlung: Als schnellen Einstieg und Testumgebung nutzen, für Produktion eigene Infrastruktur oder zertifizierte Lösungen (z.B. GOST-VPN) einsetzen, dabei die gewählten Zugriffsregeln und Segmentierung beibehalten.

Praxisbeispiele und Ergebnisse: So läuft es in echten Firmen

Fall 1: Buchhaltung mit 60 verteilten Nutzern

Aufgabe: Zugriff auf 1C und Berichte aus 3 Städten gewährleisten, Benutzererfahrung erhalten, Sicherheits-Audit bestehen. Lösung: RD Gateway + WireGuard, RDS auf 2 Servern (je 32 vCPU/128 GB RAM), GPO-Profile ohne Clipboard- und Laufwerksumleitung, MFA via NPS Extension. Ergebnis: Durchschnittliche RDP-Latenz 28–35 ms, Formularöffnungszeiten 40 % schneller als leichter Client über unverschlüsseltes MPLS, 0 Vorfälle in 9 Monaten, erfolgreiches Audit.

Fall 2: Lager und TSD rund um die Uhr

Aufgabe: 5 Lager mit zentralem 1C vernetzen, Etikettendruck und Waagenaustausch ermöglichen. Lösung: Site-to-Site IKEv2 mit Provider-Redundanz, QoS für RDP und Druck, zentrales Tunnel-Monitoring, lokale Druckcaches. Ergebnis: Netz-Ausfallzeiten unter 12 Minuten pro Quartal, SLA 99,9 %, Druckgeschwindigkeit plus 25 %, Nutzerbeschwerden minus 60 %.

Fall 3: Finanzabteilung mit sensiblen Daten

Aufgabe: strenge Datenschutz- und Compliance-Anforderungen, Split-Tunnel-Verbot, Gerätelockdown. Lösung: IKEv2 mit EAP-TLS, MDM-Device-Control, RD Gateway mit CAP/RAP und kritischen Sitzungsaufzeichnungen, SIEM-Korrelationen. Ergebnis: Sicherheitstest bestanden, 12 Monate ohne Zwischenfälle, kontrollierte Betriebskosten.

FAQ: 10 fortgeschrittene Fragen

1. Was ist besser für die Buchhaltung: RDP oder leichter Client über VPN?

In 80 % der Fälle ist RDP via VPN oder RD Gateway passender: Weniger Latenzabhängigkeit, zentralisierte Druck- und Softwarebereitstellung. Leichter Client lohnt bei schnellen, stabilen Kanälen und wenn RDS aus Lizenzgründen unerwünscht ist.

2. WireGuard oder IKEv2?

Für heterogene Umgebungen und hohe Geschwindigkeit WireGuard. Für tiefe AD-Integration, Zertifikate und Compliance IKEv2/IPsec. Beide funktionieren gut bei sinnvoller ACL- und MFA-Konfiguration.

3. Braucht man RD Gateway, wenn VPN vorhanden ist?

Ja, wenn Sie den RDP-Zugriff feingranular steuern, CAP/RAP nutzen, Audits vereinfachen und MFA auf Sessionebene einführen wollen. VPN bleibt wichtig für den Transport und zur Segmentierung.

4. Wie kapazitiert man RDS?

Pilotmetriken sammeln: CPU/RAM/IOPS pro Nutzer in der Hauptzeit. 30–40 % Reserve einplanen, Peaks durch Druck/Reports berücksichtigen. Lasttests durchführen, dann horizontal (weiterer RDSH) oder vertikal (mehr vCPU/RAM) skalieren.

5. Was ist kritisch für RDP-Sicherheit?

NLA, TLS 1.2+, Verbot alter Cipher, RD Gateway oder VPN, MFA, Gruppen-Beschränkungen über AD, IP-Blockierung, Login-Audit, sichere RDP-Redirect-Einstellungen, regelmäßige Updates.

6. Wie verzögert man Latenzen in Filialen?

Site-to-Site mit QoS, RDP-Priorisierung, lokale DNS-/Druckcaches, Kanalredundanz, Minimierung chatty Protocols, Monitoring von Jitter und Paketverlust, ggf. Edge-RDS näher an Filiale.

7. Split-Tunnel verwenden?

Für nicht sensitive Gruppen möglich, um Kanal zu entlasten. Für Buchhaltung und Finanzen besser nicht: Vollständiger Traffic über VPN, um Kontrolle, DLP und Compliance sicherzustellen.

8. Was zum Thema Zertifizierung und Compliance in Russland?

Gesetze wie FZ-152 und interne Standards beachten. In Produktion zertifizierte Kryptografie, segmentierte Netzwerke, Logging und Rev-Response-Pläne einsetzen. Piloten können Standardprotokolle mit MFA und ohne Logging verwenden.

9. Wie sicher drucken aus RDP?

Easy Print mit Einschränkungen, virtuelle PDF-Drucker mit geschützten Shares, lokale Laufwerksumleitung deaktivieren, Kompression und Druckwarteschlange auf lokalem Druckerserver im gleichen Segment aktivieren.

10. Was ist der wichtigste Erfolgsfaktor?

Passende Topologie für Last, klare Segmentierung und ACL, MFA, Monitoring, Pilot mit echten Nutzern und realistische UX-Erwartungen. Und natürlich: Backup-Plan und klar definierte Verantwortlichkeiten.

Fazit: Roadmap und nächste Schritte

Sicherer und schneller Fernzugriff auf 1C entsteht durch die richtigen Entscheidungen: Topologie wählen (meist RDP über VPN), Protokoll (WireGuard/IKEv2), RD Gateway und MFA einführen, Segmentierung und ACL definieren, Monitoring und Redundanz aufbauen. Start mit kleinem Pilot, Metriken und Feedback sammeln, dann skalieren. Praktische Roadmap: (1) Benutzer-Personas und UX-Anforderungen erfassen; (2) VPN-Protokoll und RDP-Architektur wählen; (3) Pilot starten, NLA/TLS/MFA aktivieren; (4) Drucker und Peripherie konfigurieren; (5) Performance und Kapazität messen; (6) Logs in SIEM integrieren und Backup aufsetzen; (7) Richtlinien dokumentieren und Schulungen durchführen; (8) Produktion starten und regelmäßige Recovery-Tests. So sichern Sie planbare Performance, erfüllen regulatorische Anforderungen, erleichtern den Anwendern das Leben – und vor allem: Ihre 1C wird wirklich von überall sicher und unkompliziert zugänglich, nur für berechtigte Nutzer.