Teknisk oversigt over platformen

Hvem er den til

Løsningsarkitekter, sikkerhedsreviewere, platformsingeniører og IT-drift, der har brug for en troværdig mental model før dybere engagement. Kontraktlige diagrammer eller tenantspecifik topologi hører hjemme i en kontrolleret kanal—ikke på denne offentlige side.

Store byggesten (konceptuelt)

Slutbrugere arbejder via en standard browsersession mod en portal med godkendelse, policestyret navigation og startflader for tildelte ressourcer. Bagved ligger tenancy-logik, identitetslivscyklus og orkestrering mod fjernudførselsstier. Et separat sikkert adgangslag afslutter browserorienterede protokoller, validerer tildelinger og politik ved forbindelse og forbinder kontor-PC’er, hostede skriveborde, cloud-arbejdsbyrder eller applikationslag—uden at opsluge disse miljøer i portalens tillidsdomæne.

Model for hvordan arbejdsmiljøet vises

Tildelte ressourcer vises i tenantportalen som styrede startmål frem for rå netværksdestinationer. Administratorer knytter brugere til konkrete tilbud — typisk arbejdsapps, indgange til fjernarbejdsområdet, kontor-PC’er, hostede skriveborde, OS-miljøer eller interne applikationer. Når en bruger starter et forløb, forbliver arbejdsbyrdens udførelse knyttet til det godkendte mål, mens interaktionen går gennem en browser-indkapslet sessionsoverflade, når det er den konfigurerede vej. Kræver politik og integration en anden leveringsmodel, kan samme tildelingsmodel overdrages til en godkendt klientsti i stedet for fuld præsentation i browseren. Den vigtige grænse er, at endepunktet er en adgangsoverflade snarere end selve udførelsesmiljøet. Den adskillelse gør det muligt at eksponere Windows-, Linux-, macOS-, server-, cloud- eller hybridmål via én portal- og tildelingsmodel uden at brugerenes enheder kollapser ind i det interne netværks tillidsgrænse.

Startflow på højt niveau

1. Brugeren logger på tenantportalen (MFA når politikken kræver det).
2. Tenantkontekst fastlægges for sessionen, så efterfølgende kontroller rammer den rigtige konfiguration og datapartition.
3. Tildelinger og autorisation vurderes på serveren før enhver fjernsti forberedes.
4. Berettigede ressourcer—tildelte arbejdsapps og fjernarbejdsoplevelsen—vises i portal-UI’et.
5. Brugeren igangsætter en starthandling for den valgte tildeling.
6. Det sikre adgangslag formidler en autoriseret sessionssti i overensstemmelse med tildeling og tenantregler.
7. Målmiljøet bliver tilgængeligt via den browserorienterede overflade eller den konfigurerede klientoverdragelse—afhængigt af starttypen.
8. Adgangen forbliver begrænset til den godkendte ressource og antyder ikke generel netværksadgang fra endepunktet.

Hvad kører hvor

Miljøtyper

MyWorkspace er bygget omkring tildelte miljøer i stedet for én fast skrivebordstype. Afhængigt af tenantkonfigurationen kan brugere interagere med fulde skrivebordsmiljøer, applikationsorienterede arbejdsområder, indgange på kontorenheder, serverunderstøttede miljøer eller browser-indkapslede operative overflader — alt via samme adgangsmodel.

• Kontor-PC’er
• Windows-skrivebordsmiljøer
• Windows Server-miljøer
• Linux-miljøer
• macOS-miljøer
• Cloud-arbejdsområder
• Interne applikationer

Runtime-sti på et øjeblik

Identitet, sessioner og autorisation

Brugere godkendes mod tenantportalen. Sessioner følger moderne webpraksis (kortlivede legitimationsoplysninger ved kanten, servervalidering af privilegerede handlinger). Roller og tildelinger afgøres på serveren før fjernsti gives; UI er ikke tillidsroden for fjernkonnektivitet. MFA er integreret når politikken kræver det; gendannelses- og admin-flows er adskilt fra standardbrugerflows.

Tenant-isolation

Operative data partitioneres pr. tenant i persistens og konfiguration. Kryds-tenant-stier afvises i kontrolplans-API’er; kørselstidsstarter løses kun i den kaldende tenants kontekst. Hvor infrastruktur deles, hviler isolation på udtrykkelige grænser—ikke på obskuritet.

Transport og kant-holdning

Trafik bruger krypterede transporter til servicepunkter. Browserlaget antager ikke en ældre VPN-klient på endepunktet; forbindelse til interne eller hybride mål formidles via komponenter til udgående, godkendte sessioner—ikke til at flade hele netværket. Chiffer-suites og TLS-versioner følger produktionssikkerhedsbaseline og ændres i vedligeholdelsesvinduer.

Databehandling (overblik)

Portalen gemmer tenantmetadata, tildelinger, audit-orienterede hændelser til administration og integrationskonfiguration der passer til produktfladen. Hemmeligheder til tredjepartsforbindelser håndteres via kontrollerede lagringsmønstre—ikke indlejret i klientbundter. Fjernsessionsnyttelast går dedikerede veje; målmiljøernes legitimationsmateriale forbliver inden for fjernsessionens grænse og duplikeres ikke bevidst til weblogs.

Observabilitet og drift

Platformoperatører bruger strukturerede logs, sundhedstjek og kapacitetssignaler til virksomhedsovervågning. Kundesynlige hændelser kommunikeres via aftalte kanaler; dybere operationel diagnostik håndteres gennem kontrollerede support- og gennemgangskanaler.

Udvidelsesmuligheder

Integrationer foretrækker stabile HTTP-API’er og standardidentitetsprotokoller, hvor kunder forventer interoperabilitet (f.eks. katalog- eller SSO-orienterede flows på højt niveau). Feature flags og trinvise udrulninger lader tenants adoptere kapabiliteter uden at undergrave isolationsgarantier.

Grænse for den offentlige side

Siden beskriver platformen på kapabilitets- og grænseniveau. Tenantspecifik topologi, integrationsdetaljer, implementeringsdiagrammer og følsomme driftspørgsmål gennemgås i kontrollerede kanaler.