Technischer Überblick über die Plattform

Für wen das gedacht ist

Lösungsarchitekten, Security-Reviewer, Plattformingenieure und IT-Betrieb, die vor einem tieferen Engagement ein glaubwürdiges Mentalmodell brauchen. Vertragliche Diagramme oder mandantenspezifische Topologie gehören in einen kontrollierten Kanal—nicht auf eine öffentliche Seite.

Große Bausteine (konzeptuell)

Endnutzer arbeiten über eine standardskonforme Browser-Sitzung mit einem Webportal für Authentifizierung, policybewusste Navigation und Startflächen für zugewiesene Ressourcen. Dahinter liegen Mandantenlogik, Identity-Lifecycle und Orchestrierung zu Remote-Pfaden. Eine separate Secure-Access-Schicht beendet browserorientierte Protokolle, prüft Zuweisungen und Policy beim Verbindungsaufbau und überspannt Büro-PCs, gehostete Desktops, Cloud-Workloads oder Anwendungsebenen—ohne diese Welten in die Vertrauensdomäne des Portals zu ziehen.

Modell der Arbeitsumgebung

Zugewiesene Ressourcen erscheinen im Mandantenportal als verwaltete Startziele, nicht als rohe Netzwerkziele. Administratoren knüpfen Nutzer an konkrete Angebote—häufig modelliert als Work Apps, Einstiege in den Remote-Arbeitsbereich, Büro-PCs, gehostete Desktops, Betriebssystemumgebungen oder interne Anwendungen. Startet ein Nutzer einen Launch, bleibt die Workload-Ausführung mit dem freigegebenen Ziel verknüpft, während die Interaktion dort über eine im Browser gekapselte Session-Oberfläche verläuft, wo das so konfiguriert ist. Erfordern Policy und Integration ein anderes Bereitstellungsmodell, kann dasselbe Zuweisungsmodell an einen genehmigten Client-Pfad übergeben werden, statt vollständig im Browser zu bleiben. Die wichtige Grenze: Das Endgerät ist eine Zugriffsfläche, nicht die Ausführungsumgebung selbst. Diese Trennung erlaubt es Organisationen, Windows-, Linux-, macOS-, Server-, Cloud- oder Hybridziele über ein Portal und Zuweisungsmodell bereitzustellen, ohne Nutzergeräte in die interne Netzwerk-Vertrauensgrenze zu ziehen.

Startablauf auf hoher Ebene

1. Anmeldung am mandantenbezogenen Portal (MFA, wenn die Policy es verlangt).
2. Mandantenkontext wird für die Sitzung aufgelöst, damit Folgeprüfungen auf die richtige Konfiguration und Datenpartition zielen.
3. Zuweisungen und Autorisierung werden serverseitig bewertet, bevor ein Remote-Pfad vorbereitet wird.
4. Zulässige Ressourcen—z. B. zugewiesene Work Apps und der Remote-Arbeitsbereich—werden in der Portal-UI angezeigt.
5. Der Nutzer startet eine Launch-Aktion für die gewählte Zuweisung.
6. Die Secure-Access-Schicht vermittelt einen autorisierten Sitzungspfad gemäß Zuweisung und Mandantenregeln.
7. Die Zielumgebung wird über die browserorientierte Oberfläche oder den konfigurierten Client-Übergang erreichbar—je nach Launch-Typ.
8. Der Zugriff bleibt auf die freigegebene Zuweisung begrenzt und impliziert keinen breiten Netzzugang vom Endpunkt.

Was läuft wo

Umgebungstypen

MyWorkspace ist auf zugewiesene Umgebungen ausgelegt, nicht auf einen einzigen Desktop-Typ. Je nach Mandantenkonfiguration können Nutzer mit vollständigen Desktopumgebungen, anwendungsorientierten Workspaces, Einstiegen auf Bürogeräten, servergestützten Umgebungen oder im Browser gekapselten Betriebsoberflächen interagieren—alles über dasselbe Zugriffsmodell.

• Büro-PCs
• Windows-Desktopumgebungen
• Windows-Server-Umgebungen
• Linux-Umgebungen
• macOS-Umgebungen
• Cloud-Workspaces
• Interne Anwendungen

Laufzeitpfad auf einen Blick

Identität, Sitzungen und Autorisierung

Nutzer authentifizieren sich am mandantenbezogenen Portal. Sitzungen folgen modernen Webmustern (kurzlebige Credentials am Edge, serverseitige Validierung privilegierter Aktionen). Rollen- und Zuweisungsprüfungen werden serverseitig vor einem Remote-Pfad entschieden; die UI ist nicht die Vertrauenswurzel für Remote-Konnektivität. MFA ist integriert, wenn die Policy es verlangt; Recovery- und Admin-Flows sind von Standardnutzerpfaden getrennt.

Mandantenisolation

Betriebsdaten sind pro Mandant in Persistenz und Konfiguration getrennt. Mandantenübergreifende Pfade werden in Control-Plane-APIs strukturell abgewiesen; Laufzeitstarts lösen nur im Mandantenkontext des Aufrufers auf. Bei geteilter Infrastruktur basiert Isolation auf expliziter Applikations-Mandantentrennung und Grenzen—nicht auf Obskurität.

Transport und Edge-Haltung

Traffic nutzt verschlüsselte Transporte zwischen Clients und Diensten. Die Browser-Schicht setzt keinen Legacy-VPN-Client voraus; Verbindungen zu internen oder hybriden Zielen werden über ausgehend initiierte, authentifizierte Sitzungen vermittelt—nicht durch breites Netz-Flattening. Cipher-Suites und TLS-Versionen folgen Produktions-Baselines und ändern sich in Wartungsfenstern.

Datenhandling (überblicksweise)

Das Portal speichert Mandanten-Metadaten, Zuweisungen, auditrelevante Admin-Ereignisse und Integrationskonfiguration passend zur Produktfläche. Geheimnisse für Dritt-Connectoren liegen in kontrollierten Speichermustern—nicht in Client-Bundles. Remote-Sitzungsnutzdaten laufen über dedizierte Pfade; Ziel-Credentials bleiben in der Remote-Sitzungsgrenze und werden nicht systematisch ins Web-Tier gespiegelt.

Observability und Betrieb

Plattformbetreiber nutzen strukturierte Logs, Health-Endpoints und Kapazitätssignale für Enterprise-Monitoring. Kundensichtbare Vorfälle laufen über vereinbarte Kanäle; tiefere operative Diagnostik erfolgt über kontrollierte Support- und Review-Kanäle.

Erweiterbarkeit

Integrationen bevorzugen stabile HTTP-APIs und Standard-Identitätsprotokolle, wo Kunden Interoperabilität erwarten (z. B. Verzeichnis- oder SSO-orientierte Strömungen auf hoher Ebene). Feature-Flags und gestaffelte Rollouts erlauben Mandanten, Fähigkeiten zu übernehmen, ohne Isolationsgarantien zu verwässern.

Grenze der öffentlichen Seite

Diese Seite beschreibt die Plattform auf Fähigkeits- und Grenzebene. Mandantenspezifische Topologie, Integrationsdetails, Deployment-Diagramme und sensible Betriebspfade werden in kontrollierten Kanälen besprochen.