Sikkerhed: 2FA og SSO til Windows-applikationer i 2025

Sidst opdateret:
22. oktober 2025
Direktør for teknik

Sikkerhed: 2FA og SSO til Windows-applikationer i 2025

Denne blog dækker de omstændigheder, hvor du kan vælge at aktivere 2FA, SSO, begge dele eller ingen af delene for at sikre adgang til Windows-applikationer. Diskussionen drejer sig om, hvordan man konfigurerer disse sikkerhedsforanstaltninger med GraphOn GO-Global. GO-Global er et værktøj til udgivelse af Windows-applikationer, som giver sikker adgang til Windows-applikationer, uanset hvor brugerne befinder sig, ved hjælp af en hvilken som helst enhed, der understøtter en browser - det være sig en Surface Pro, Dell XPS, MacBook Air, Samsung Galaxy eller en af mange andre typer. (For mere information om GO-Globals indbyggede sikkerhedsfunktioner, se "Designet med sikkerhed i tankerne").

Når du begynder at udforske bedste praksis for identitets- og adgangsstyring (IAM), vil du sandsynligvis finde et overvældende antal velrenommerede kilder, der tilbyder et væld af anbefalinger. Men du vil også finde nogle få fællesnævnere, som gælder for både små og mellemstore virksomheder (SMB'er), virksomheder og udbydere af cloud-tjenester, uanset hvilke aktiver de beskytter:

- Brugernes digitale konti skal beskyttes med legitimationsoplysninger som f.eks. adgangskoder. Ideelt set dikterer politikker kriterier for stærke adgangskoder og understreger vigtigheden af at holde legitimationsoplysninger hemmelige og sikre.

- Legitimationsoplysninger, der giver adgang til applikationer, der eksponerer følsomme oplysninger, bør verificeres med en form for multifaktorautentificering (MFA), f.eks. tofaktorautentificering (2FA). 2FA hjælper med at bekræfte, at brugerne (i virkeligheden) er de brugere, som deres legitimationsoplysninger repræsenterer.

- Single sign on (SSO) beskytter bedre legitimationsoplysninger mod menneskelige svagheder (som at glemme og genbruge adgangskoder) og mindsker den opfattede ulempe ved 2FA.

Hvilke principper du anvender og hvornår, afhænger af flere variabler. Du skal blandt andet overveje, hvilke oplysninger der eksponeres af de applikationer, som brugerne har rettigheder til. Du skal også overveje, hvordan brugerne får adgang til disse applikationer. Er brugerne på kontoret eller arbejder de eksternt? Er applikationerne i et virksomhedsdatacenter eller i skyen? Vil fjernbrugere få adgang til applikationerne via internettet? Med eller uden den kryptering, som en VPN giver?

Internettet ved ikke, at du er en hund

På trods af stadig mere sofistikerede cybersikkerhedsforanstaltninger er den grundlæggende autentificeringsmetode stadig adgangskoden, som bekræfter identitet baseret på noget, brugerne kender. Uanset om det drejer sig om at komme på telefonen, få adgang til arbejdsmailen eller logge på forretningskritiske applikationer, indtaster brugerne selvopfundne kombinationer af bogstaver, tal og specialtegn for at gøre det.

Problemet med adgangskoder er brugerne. De kan godt lide korte passwords, fordi de er nemmere at huske, men korte passwords er også nemmere at gætte. Derfor insisterer administratorer og programmer på, at brugerne opretter længere passwords, som er sværere at knække, men som også kan være sværere at huske. (Se "Det nye stærke: Let at huske, svært at knække").

Når brugere har dusinvis af konti, der kræver komplekse adgangskoder, har de en tendens til at ty til mindre sikre metoder: De skriver dem ned eller, hvad der er værre og mere almindeligt, genbruger dem. Mindst 65 % af brugerne genbruger adgangskoder, og 13 % bruger den samme adgangskode til alle konti og enheder.

Ikke overraskende er adgangskoder kilden til en notorisk almindelig angrebsvektor: kompromitterede legitimationsoplysninger. Ifølge en nylig rapport fra IBM og Ponemon var "kompromitterede legitimationsoplysninger" faktisk den mest almindelige indledende angrebsvektor i 2021, hvilket i sidste ende førte til 20 % af alle databrud.

Uanset hvor "sikre" passwords er, kan angribere afsløre dem. Selv om SallyB opretter et password, som det ville tage en computer 23 duodecillioner år at knække, gælder det kun, hvis hun holder det hemmeligt. (Se figur 1.) Men måske kommer SallyB uforvarende til at angive alle svarene på sine spørgsmål om nulstilling af adgangskoder på sin Facebook-konto. Eller måske får hun en e-mail og klikker på det indlejrede link, som fører hende til en dobbeltgængerside til login, hvor en angriber fanger hendes legitimationsoplysninger.

Baseret på legitimationsoplysninger alene kan systemer ikke vide, om "SallyB" rent faktisk er SallyB. Årsagen lyder fjollet, men er ikke desto mindre sand: Computere kan ikke se.

2FA: Hvis systemer havde visioner

At aktivere 2FA er som at give dine systemer en vision. 2FA kræver to forskellige former for identifikation for at godkende. Den første form er generelt noget, brugerne kender (f.eks. en adgangskode). Den anden er typisk noget, brugerne har, f.eks. en kode sendt via sms eller, som en mere sikker løsning, en kode genereret af en autentificeringsapp installeret på brugerens telefon.

For at forpurre 2FA, der er afhængig af sådanne koder, skal angriberne ikke kun have brugerens legitimationsoplysninger, men også brugerens telefon. Dette ekstra lag af sikkerhed er ekstremt effektivt. Ifølge en Google-undersøgelse fra 2019 forhindrer brug af 2FA med en prompt på enheden faktisk 100 % af automatiserede bot-angreb, 99 % af masse-phishing-angreb og 90 % af målrettede angreb.

Det er ikke overraskende, at 2FA i vid udstrækning betragtes som en best practice til sikring af fjernadgang og er et krav til enhver zero-trust-arkitektur.

Hvornår skal 2FA aktiveres?

Under hvilke omstændigheder bør du aktivere 2FA? Det enkle svar er: Aktivér 2FA for ethvert system, der eksponerer følsomme eller privilegerede oplysninger.

At aktivere 2FA for alle systemer er måske ikke det bedste valg. Brugere kan løbe ind i situationer, hvor 2FA kan forhindre adgang - deres mobiltelefonsignal er f.eks. dårligt, eller deres telefon er blevet tabt eller stjålet. De fleste 2FA-systemer har dog løsninger til situationer som disse. GO-Global giver dig f.eks. mulighed for at nulstille koder fra administratorpanelet, så brugerne kan få adgang til 2FA-aktiverede værter, selv om de mister deres telefon. Ikke desto mindre bør du veje den opfattede ulempe ved 2FA op mod, hvad brugerne har ret til at få adgang til.

Overvej f.eks. det fælles sæt af applikationer, som du gør tilgængelige for alle (f.eks. Office 365, tidsregistreringssoftware, Adobe-produkter). Hvis disse programmer kører bag din firewall, vil det være tilstrækkeligt med legitimationsoplysninger for lokale brugere. Selv for fjernbrugere, forudsat at de kun har rettigheder til det fælles sæt af applikationer med adgang til ikke-følsomme data, vil legitimationsoplysninger alene uden tvivl være tilstrækkeligt. Men du må spørge dig selv: "Hvis 'SallyB' ikke er SallyB, men en angriber, hvad er så i fare?"

For applikationer, der potentielt eksponerer følsomme data, er den lille ulempe, som 2FA lejlighedsvis kan medføre, værd at tage imod et par klager. For eksempel bør du aktivere 2FA for denne type brugere, der har adgang til denne type applikationer:

- Udviklere med adgang til kodesoftware

- Ingeniører med adgang til netværkssniffere

- IT-administratorer med adgang til software til konfiguration af firewalls og routere

- Revisorer med adgang til lønningsapps

- Medlemmer af salgsteamet med adgang til CRM-systemer (Customer Relationship Management)

- Personale inden for human resource (HR) med adgang til HRM-software

Hvad nu, hvis de ovennævnte brugere tilgår disse applikationer via en VPN? En VPN skaber en slags tunnel på tværs af internettet og krypterer de oplysninger, der udveksles mellem brugere og de systemer, de har adgang til. Men en VPN kan ikke afgøre, om den enhed, der indtastede de korrekte oplysninger for "SallyB", er SallyB. Derfor, med eller uden VPN, hvis en brugers rolle giver adgang til følsomme data, bør du aktivere 2FA for at beskytte dem.

{{CTAEMBED_IDENTIFIER}}

Opsætning af 2FA i GO-Global

Figur 2. For at aktivere 2FA på en GO-Global-vært skal du klikke på "Kræv tofaktorgodkendelse".

Det er en enkel proces at aktivere 2FA på en GO-Global-server, der hoster Windows-applikationer. Du begynder med at vælge Værtsindstillinger i menuen Værktøjer i administratorpanelet og klikke på fanen Godkendelse. På denne skærm klikker du på "Kræv to-faktor-godkendelse". Når du har klikket på "Okay", er 2FA aktiveret. (Se figur 2.)

Figur 3. Du kan tilpasse GO-Global Sign In-dialogen. Du kan blandt andet ændre logoet, sproget og feltmærkerne.

Hver gang brugerne opretter forbindelse til en 2FA-aktiveret GO-Global-vært, beder systemet dem først om at indtaste deres brugernavn og adgangskode via dialogboksen Sign In. (Se figur 3.) Når brugerne klikker på "Log på" for første gang, beder systemet dem om at registrere sig for 2FA og beskriver de to trin, der kræves for at gøre det.

- Trin 1 beder brugerne om at downloade en autentificeringsapp på deres telefon. Brugerne kan installere den app, de vælger (f.eks. Google Authenticator, Authy, Duo Mobile og LastPass Authenticator).

- Trin 2 beder brugerne om at åbne appen, klikke på "tilføj" eller "+" og derefter scanne den viste QR-kode. (Se figur 4.) Den scannede QR-kode knytter denne bruger og denne telefon til GO-Global. (Brugerne behøver kun at scanne QR-koden én gang, uanset hvor mange 2FA-aktiverede GO-Global-værter de har adgang til - så længe du aktiverer "roaming-profiler" i administratorpanelet).

Figur 4. GO-Global-brugere tilmelder sig 2FA i to enkle trin.

Efter at have modtaget den scannede QR-kode viser GO-Global-værten en dialogboks, hvor brugerne bliver bedt om at indtaste den 6-cifrede kode fra autentificeringsappen og derefter klikke på "Okay". Appen opdaterer automatisk disse koder hvert 60. sekund. Når en bruger har indtastet den korrekte aktuelle kode, åbner GO-Global-værten App Controller, som viser de publicerede Windows-applikationer.

Mens det tager et par hundrede ord at forklare denne proces på skrift, tager det kun et par sekunder at gennemføre processen live.

SSO: Kraften i én

Aktivering af 2FA hjælper systemer med at sikre, at "SallyB" er den person, hendes legitimationsoplysninger repræsenterer. Men 2FA hjælper ikke SallyB med at huske sine adgangskoder - og der er gode chancer for, at hun har mange af dem.

Ifølge OneLogin, en leverandør af adgangsstyringsløsninger, skifter 68% af brugerne mellem ti applikationer hver time. Hvis brugerne er grundige med sikkerheden, betyder det, at de potentielt indtaster op til ti unikke adgangskoder hver time. Men de fleste brugere er ikke grundige, så de genbruger den samme adgangskode eller tyer til andre mindre sikre muligheder.

Løsningen er at aktivere Single Sign On (SSO). SSO er et brugergodkendelsesværktøj, der giver brugerne mulighed for at logge ind på og få adgang til flere applikationer, websites, data og arbejdsstationer ved hjælp af ét centralt administreret sæt legitimationsoplysninger. SSO betragtes som en best practice inden for adgangssikkerhed. Faktisk nævner U.K. National Cyber Security Centre (NCSC) en "enkelt stærk kilde til brugeridentitet" som et nøgleprincip i zero-trust-arkitektur.

For at implementere SSO samarbejder organisationer med en identitetsudbyder (IdP). IdP'er bruger en protokol, såsom OpenID Connect, til at skabe tillid mellem en organisations brugere og SSO-integrerede applikationer. Brugere logger ind på IdP'en, som derefter genererer et unikt adgangstoken. IdP'en bruger dette token til at give brugerne adgang til de integrerede applikationer, som de har rettigheder til.

Det gør alle glade, at brugerne ikke behøver at indtaste forskellige legitimationsoplysninger for hver applikation. Brugerne er glade, fordi de typisk kun logger ind på IdP'en en gang om dagen. For dig forenkler SSO processen med at revidere og administrere brugere. Sikkerhedsteams kan definere og håndhæve strengere krav til adgangskoder. Og helpdesken får færre opkald om nulstilling af adgangskoder.

SSO til Windows-apps

Desværre har SSO historisk set kun været tilgængelig for webbaserede applikationer - ikke Windows-applikationer. Problemet har været, at med Windows logger brugerne direkte på operativsystemet med et brugernavn og en adgangskode, hvorefter Winlogon indlæser brugerens profil. Fordi Windows OS kræver et brugernavn og en adgangskode, kan man typisk ikke inkludere Windows-applikationer i SSO-implementeringer i skyen uden en brugerdefineret Credential Provider.

De SSO-løsninger til Windows-applikationer, der er tilgængelige, såsom Citrix NetScaler Unified Gateway integreret med Citrix Hypervisor, har ry for at være både dyre og komplekse.

GO-Global er klar til at ændre det ry.

GO-Globals OpenID Connect-godkendelsesfunktion er tilgængelig som en ekstra mulighed og tilbyder SSO med en nem opsætning til en brøkdel af prisen for andre SSO-løsninger til Windows-apps. GO-Global muliggør SSO for Windows-applikationer via IdP'er, der understøtter OpenID Connect, herunder Okta, OneLogin, Microsoft Active Directory Federated Services og Microsoft Azure AD Seamless SSO. Når GO-Global OpenID Connect er konfigureret, kan brugere, der logger ind på en IdP, få adgang til Windows-applikationer på GO-Global-værter fra deres browsere uden at skulle indtaste deres legitimationsoplysninger igen.

Opsætning af SSO i GO-Global

For at integrere GO-Global-værter med din organisations IdP skal du begynde med at konfigurere IdP'en til at genkende og arbejde med GO-Global. Den specifikke opsætning afhænger naturligvis af den pågældende IdP. For eksempel skal du for Okta blandt andet angive protokollen (dvs. OpenID Connect), omdirigerings-URL'en til GO-Global-værten og i hvor høj grad, du vil kontrollere adgangen til værten. (Du kan f.eks. begrænse adgangen til udvalgte grupper eller give adgang til alle).

For nemheds skyld anbefaler GraphOn, at du kopierer nogle af IdP-indstillingerne (f.eks. klient-id, klienthemmelighed og omdirigerings-URL) til Notesblok, så du senere kan indsætte dem i GO-Globals Admin Console. (Se figur 5.)

Når du har konfigureret din IdP, skal du konfigurere GO-Global-værten. Det gør du ved at gå til GO-Global Admin Console, vælge Host Options i menuen Tools og klikke på fanen Authentication. Herfra kræver konfigurationen af GO-Global-værten til at bruge din IdP ikke meget mere end at indsætte de førnævnte indstillinger i de relevante felter.

Når GO-Global-værten er integreret med din IdP, indtaster brugerne deres IdP-legitimationsoplysninger (når de bliver bedt om det) for at få adgang til værten fra deres webbrowser. Når de har indtastet deres legitimationsoplysninger og værts-URL'en, ser brugerne App Controller, som viser de publicerede Windows-applikationer.

Når brugere godkendes via OpenID Connect til IdP'en, godkendes de automatisk på Windows i henhold til de muligheder, du vælger. Hvis IdP'en f.eks. er integreret med din organisations Active Directory, kan du konfigurere GO-Global til automatisk at logge brugere ind i deres brugerdomæner.

For at få bedre sikkerhed og lettere adgang bør du bruge SSO, hvor det er muligt. GO-Global gør det bare nemmere (og billigere) at inkludere Windows-applikationer blandt dine SSO-muligheder.

Figur 5. For at aktivere SSO for GO-Global-værter skal du begynde med at konfigurere din IdP, såsom Okta (vist her).

Hvornår vil du måske have både 2FA og SSO?

Hvornår kan det være en god idé at implementere både 2FA og SSO? Det enkle (men ikke altid praktiske) svar er "når det er muligt". Det mere praktiske og altid kloge svar er, at du bør aktivere 2FA for at beskytte følsomme oplysninger mod uautoriseret adgang. Når du gør det, anbefaler NCSC, at du også bruger SSO til at mindske den "friktion", som 2FA medfører. 2FA hjælper systemer med at sikre, at de brugere, der forsøger at få adgang, er de brugere, som deres legitimationsoplysninger repræsenterer, og SSO forhindrer sjusket adgangskodepraksis, der kan føre til et sikkerhedsbrud.

Med GO-Global har du mulighed for at aktivere både 2FA og SSO for alle Windows-applikationer, som du udgiver på GO-Global-værter.

Hvis du vil vide mere, kan du anmode om en demo her eller downloade en gratis 30-dages prøveversion.

Vil du gøre din ansøgning sikker og bekvem?

Se, hvordan GO-Global giver en enkel og omkostningseffektiv løsning

Indholdsfortegnelse