Sikkerhet: 2FA og SSO for Windows-applikasjoner i 2025

Denne bloggen dekker omstendighetene der du kan velge å aktivere 2FA, SSO, begge deler eller ingen av delene for å sikre tilgang til Windows-applikasjoner. Diskusjonen dreier seg om hvordan du konfigurerer disse sikkerhetstiltakene med GraphOn GO-Global. GO-Global er et publiseringsverktøy for Windows-applikasjoner som gir sikker tilgang til Windows-applikasjoner uansett hvor brukerne befinner seg, ved hjelp av en hvilken som helst enhet som støtter en nettleser – enten det er en Surface Pro, Dell XPS, MacBook Air, Samsung Galaxy eller en av mange andre typer. (For mer informasjon om GO-Globals innebygde sikkerhetsfunksjoner, se «Designet med tanke på sikkerhet».)

Når du begynner å utforske beste praksis for identitets- og tilgangsstyring (IAM), vil du sannsynligvis finne et overveldende antall anerkjente kilder som tilbyr et vell av anbefalinger. Men du vil også finne noen fellestrekk som gjelder for små og mellomstore bedrifter (SMB-er), bedrifter og leverandører av skytjenester, uavhengig av hvilke eiendeler de beskytter:

• Brukernes digitale kontoer må beskyttes med påloggingsinformasjon som passord. Ideelt sett dikterer retningslinjer kriterier for sterke passord og understreker viktigheten av å holde påloggingsinformasjon hemmelig og sikker.

• Legitimasjon som gir tilgang til applikasjoner som eksponerer sensitiv informasjon, bør bekreftes med en eller annen form for flerfaktorautentisering (MFA), for eksempel tofaktorautentisering (2FA). 2FA bidrar til å bekrefte at brukere (i virkeligheten) er de brukerne legitimasjonen deres representerer.

• Enkel pålogging (SSO) beskytter påloggingsinformasjon bedre mot menneskelige svakheter (som å glemme og gjenbruke passord) og reduserer den opplevde ulempen med 2FA.

Hvilke prinsipper du bruker og når, avhenger av flere variabler. Blant annet må du vurdere informasjonen som eksponeres av applikasjonene brukerne har rettigheter til. Du må også vurdere hvordan brukere får tilgang til disse applikasjonene. Er brukerne på kontoret eller jobber de eksternt? Er applikasjonene i et bedriftsdatasenter eller i skyen? Vil eksterne brukere få tilgang til applikasjonene over Internett? Med eller uten krypteringen som tilbys av et VPN?

Internett vet ikke at du er en hund

Til tross for stadig mer sofistikerte cybersikkerhetstiltak, er den grunnleggende autentiseringsmetoden fortsatt passordet, som bekrefter identitet basert på noe brukerne vet. Enten de bruker telefonene sine, åpner jobb-e-post eller logger seg på forretningskritiske applikasjoner, skriver brukerne inn selvoppfunnede kombinasjoner av bokstaver, tall og spesialtegn for å gjøre det.

Problemet med passord er brukerne. De liker korte passord fordi de er lettere å huske, men korte passord er også lettere å gjette. Med dette i bakhodet insisterer administratorer og applikasjoner på at brukere lager lengre passord, som er vanskeligere å knekke, men som kan være vanskeligere å huske. (Se «Det nye sterke: Lett å huske, vanskelig å knekke».)

Når brukere har dusinvis av kontoer som krever komplekse passord, har de en tendens til å ty til mindre sikre fremgangsmåter: de skriver dem ned, eller enda verre og mer vanlig, bruker dem på nytt. Minst 65 % av brukerne bruker passord på nytt, og 13 % bruker det samme passordet for alle kontoer og enheter.

Ikke overraskende er passord kilden til en notorisk vanlig angrepsvektor: kompromitterte legitimasjonsopplysninger. Faktisk, ifølge en fersk rapport fra IBM og Ponemon, var «kompromitterte legitimasjonsopplysninger» den vanligste første angrepsvektoren i 2021, noe som til slutt førte til 20 % av alle datainnbrudd.

Uansett hvor «sikre» passord er, kan angripere avsløre dem. Selv om SallyB lager et passord som det ville tatt en datamaskin 23 milliarder år å knekke, forblir det bare sant hvis hun holder det hemmelig. (Se figur 1.) Men kanskje SallyB ubevisst gir alle svarene på spørsmålene sine om tilbakestilling av passord på Facebook-kontoen sin. Eller kanskje hun får en e-post og klikker på den innebygde lenken, som tar henne til et dobbeltgjengernettsted for pålogging, hvor en angriper fanger opp påloggingsinformasjonen hennes.

Basert på kun legitimasjon kan ikke systemer vite om «SallyB» faktisk er SallyB. Grunnen høres dum ut, men er likevel sann: datamaskiner kan ikke se.

‍

2FA: Hvis systemer hadde visjon

Å aktivere 2FA er som å gi systemene dine et overblikk. 2FA krever to forskjellige former for identifikasjon for å autentisere. Den første formen er vanligvis noe brukerne vet (f.eks. et passord). Den andre er vanligvis noe brukerne har, for eksempel en kode sendt via tekstmelding eller, for et sikrere alternativ, en kode generert av en autentiseringsapp installert på brukerens telefon.

For å forhindre 2FA som er avhengig av slike koder, trenger angripere ikke bare brukerens påloggingsinformasjon, men også brukerens telefon. Dette ekstra sikkerhetslaget er ekstremt effektivt. Faktisk, ifølge en Google-studie fra 2019, forhindrer bruk av 2FA med en ledetekst på enheten 100 % av automatiserte botangrep, 99 % av masseangrep med phishing og 90 % av målrettede angrep.

Ikke overraskende er 2FA allment ansett som beste praksis for å sikre ekstern tilgang og er et krav for enhver nulltillitsarkitektur.

Når skal man aktivere 2FA

Under hvilke omstendigheter bør du aktivere 2FA? Det enkle svaret er dette: aktiver 2FA for alle systemer som eksponerer sensitiv eller privilegert informasjon.

Å aktivere 2FA for alle systemer er kanskje ikke det beste valget. Brukere kan støte på situasjoner der 2FA kan hindre tilgang – for eksempel hvis mobiltelefonsignalet deres er svakt, eller hvis telefonen deres har blitt mistet eller stjålet. Riktignok har de fleste 2FA-systemer løsninger for slike situasjoner. For eksempel lar GO-Global deg tilbakestille koder fra administrasjonskonsollen, slik at brukere kan få tilgang til 2FA-aktiverte verter selv om de mister telefonen sin. Likevel bør du veie den opplevde ulempen med 2FA mot hva brukerne har tilgangsrettigheter til.

Tenk for eksempel på det vanlige settet med applikasjoner du gjør tilgjengelig for alle (f.eks. Office 365, tidtakingsprogramvare, Adobe-produkter). Hvis disse applikasjonene kjører bak brannmuren din, vil kun påloggingsinformasjon for lokale brukere være tilstrekkelig. Selv for eksterne brukere, forutsatt at de bare har rettigheter til det vanlige settet med applikasjoner med tilgang til ikke-sensitive data, vil påloggingsinformasjon alene uten tvil være tilstrekkelig. Men du må spørre deg selv: «Hvis 'SallyB' ikke er SallyB, men en angriper, hva er i faresonen?»

For applikasjoner som potensielt eksponerer sensitive data, er det verdt å ta opp noen klager over den lille ulempen som 2FA av og til kan forårsake. For eksempel, for denne typen brukere som får tilgang til denne typen applikasjoner, bør du aktivere 2FA:

• Utviklere med tilgang til kodeprogramvare

• Ingeniører med tilgang til nettverkssniffere

• IT-administratorer med tilgang til brannmur og ruterkonfigurasjonsprogramvare

• Regnskapsførere med tilgang til lønnsapper

• Salgsteammedlemmer med tilgang til CRM-systemer (Customer Relationship Management)

• HR-personell med tilgang til HRM-programvare

Hva om brukerne som er oppført ovenfor bruker disse applikasjonene via et VPN? Et VPN oppretter en slags tunnel over Internett, som krypterer informasjonen som utveksles mellom brukere og systemene de bruker. Men et VPN kan ikke avgjøre om enheten som oppga riktig legitimasjon for «SallyB» er SallyB. Derfor, med eller uten et VPN, hvis en brukers rolle tillater tilgang til sensitive data, bør du aktivere 2FA for å beskytte den.

{{CTAEMBED_IDENTIFIER}}

Sette opp 2FA i GO-Global

Det er enkelt å aktivere 2FA på en GO-Global-server som er vert for Windows-applikasjoner. Du begynner med å velge Vertsalternativer fra Verktøy-menyen i administrasjonskonsollen og klikke på Autentisering-fanen. Fra den skjermen klikker du på «Krev tofaktorautentisering». Etter at du har klikket på «OK», er 2FA aktivert. (Se figur 2.)

Hver gang brukere kobler seg til en 2FA-aktivert GO-Global-vert, ber systemet dem først om å oppgi brukernavn og passord via dialogboksen for pålogging. (Se figur 3.) Når brukere klikker på «Logg på» for første gang, ber systemet dem om å registrere seg for 2FA og beskriver de to trinnene som kreves for å gjøre det.

• Trinn 1 ber brukerne om å laste ned en autentiseringsapp på telefonen sin. Brukerne kan installere appen de velger (f.eks. Google Authenticator, Authy, Duo Mobile og LastPass Authenticator).

• Trinn 2 ber brukerne om å åpne appen, klikke på «legg til» eller «+», og deretter skanne den viste QR-koden. (Se figur 4.) Den skannede QR-koden knytter denne brukeren og denne telefonen til GO-Global. (Brukere trenger bare å skanne QR-koden én gang, uavhengig av hvor mange 2FA-aktiverte GO-Global-verter de har tilgang til – så lenge du aktiverer «roamingprofiler» i administrasjonskonsollen.)

Etter å ha mottatt den skannede QR-koden, viser GO-Global-verten en dialogboks som ber brukerne om å skrive inn den 6-sifrede koden fra autentiseringsappen og deretter klikke på «OK». Appen oppdaterer automatisk disse kodene hvert 60. sekund. Når en bruker har skrevet inn riktig gjeldende kode, åpner GO-Global-verten App Controller, som viser de publiserte Windows-applikasjonene.

Selv om det å forklare denne prosessen skriftlig tar noen hundre ord, tar det bare noen få sekunder å gjennomføre prosessen i praksis.

SSO: Kraften til én

Å aktivere 2FA hjelper systemer med å sikre at «SallyB» er personen hennes legitimasjon representerer. Men 2FA hjelper ikke SallyB med å huske passordene sine – og sannsynligheten er stor for at hun har mange av dem.

Ifølge OneLogin, en leverandør av løsninger for tilgangsstyring, bytter 68 % av brukerne mellom ti applikasjoner hver time. Hvis brukerne er grundige med sikkerheten, betyr det at de potensielt skriver inn opptil ti unike passord hver time. Men de fleste brukere er ikke grundige, så de bruker det samme passordet på nytt eller tyr til andre, mindre sikre alternativer.

Løsningen er å aktivere Single Sign-On (SSO). SSO er et brukergodkjenningsverktøy som lar brukere logge på og få tilgang til flere applikasjoner, nettsteder, data og arbeidsstasjoner ved hjelp av bare ett sentralt administrert sett med påloggingsinformasjon. SSO regnes som beste praksis innen tilgangssikkerhet. Faktisk siterer det britiske National Cyber Security Centre (NCSC) en «enkelt sterk kilde til brukeridentitet» som et sentralt prinsipp for nulltillitsarkitektur.

For å implementere SSO samarbeider organisasjoner med en identitetsleverandør (IdP). IdP-er bruker en protokoll, for eksempel OpenID Connect, for å etablere tillit mellom en organisasjons brukere og SSO-integrerte applikasjoner. Brukere logger seg på IdP-en, som deretter genererer et unikt tilgangstoken. IdP-en bruker dette tokenet for å gi brukere tilgang til de integrerte applikasjonene de har rettigheter til.

Det gjør alle fornøyde at brukerne ikke trenger å oppgi forskjellige påloggingsinformasjon for hver applikasjon. Brukerne er fornøyde fordi de vanligvis bare logger seg på IdP-en én gang om dagen. For deg forenkler SSO prosessen med å revidere og administrere brukere. Sikkerhetsteam kan definere og håndheve strengere passordkrav. Og brukerstøtte får færre henvendelser for tilbakestilling av passord.

SSO for Windows-apper

Dessverre har SSO historisk sett bare vært tilgjengelig for nettbaserte applikasjoner – ikke Windows-applikasjoner. Problemet har vært at med Windows logger brukerne direkte på operativsystemet med brukernavn og passord, hvoretter Winlogon laster inn brukerens profil. Fordi Windows-operativsystemet krever brukernavn og passord, kan du vanligvis ikke inkludere Windows-applikasjoner i skybaserte SSO-implementeringer uten en tilpasset legitimasjonsleverandør.

SSO-løsningene for Windows-applikasjoner som er tilgjengelige, som for eksempel Citrix NetScaler Unified Gateway integrert med Citrix Hypervisor, har et rykte for å være både dyre og komplekse.

GO-Global er klar til å endre det omdømmet.

GO-Globals OpenID Connect-autentiseringsfunksjon er tilgjengelig som et tilleggsalternativ og tilbyr SSO med et enkelt oppsett til en brøkdel av kostnaden for andre SSO-løsninger for Windows-apper. GO-Global muliggjør SSO for Windows-applikasjoner gjennom IdP-er som støtter OpenID Connect, inkludert Okta, OneLogin, Microsoft Active Directory Federated Services og Microsoft Azure AD Seamless SSO. Når GO-Global OpenID Connect er konfigurert, lar det brukere som logger seg på en IdP få tilgang til Windows-applikasjoner på GO-Global-verter fra nettleserne sine uten å måtte oppgi påloggingsinformasjonen på nytt.

Sette opp SSO i GO-Global

For å integrere GO-Global-verter med organisasjonens IdP, begynn med å konfigurere IdP-en til å gjenkjenne og fungere med GO-Global. Det spesifikke oppsettet avhenger naturligvis av den spesifikke IdP-en. For eksempel, for Okta, må du blant annet spesifisere protokollen (f.eks. OpenID Connect), omdirigerings-URL-en til GO-Global-verten og i hvilken grad du vil kontrollere tilgangen til verten. (Du kan for eksempel begrense tilgangen til utvalgte grupper eller aktivere tilgang for alle.)

For enkelhets skyld anbefaler GraphOn at du kopierer noen av IdP-innstillingene (for eksempel klient-ID, klienthemmelighet og omdirigerings-URL) til Notisblokk, slik at du kan lime dem inn i GO-Globals administrasjonskonsoll senere. (Se figur 5.)

Når du har konfigurert IdP-en din, konfigurerer du GO-Global-verten. For å gjøre dette, gå til GO-Global-administrasjonskonsollen, velg Vertsalternativer i Verktøy-menyen og klikk på Autentisering-fanen. Herfra krever det lite mer enn å lime inn de ovennevnte innstillingene i de aktuelle feltene for å konfigurere GO-Global-verten til å bruke IdP-en din.

Med GO-Global-verten integrert med IdP-en din, skriver brukerne inn IdP-legitimasjonen sin (når de blir bedt om det) for å få tilgang til verten fra nettleseren sin. Etter at de har skrevet inn legitimasjonen og verts-URL-en, ser brukerne App Controller, som viser de publiserte Windows-applikasjonene.

Når brukere autentiseres via OpenID Connect til IdP-en, autentiseres de automatisk i Windows i henhold til alternativene du velger. Hvis for eksempel IdP-en er integrert med organisasjonens Active Directory, kan du konfigurere GO-Global til å automatisk logge brukere på brukerdomenene deres.

For bedre sikkerhet og enkel tilgang bør du bruke SSO der det er mulig. GO-Global gjør det bare enklere (og billigere) å inkludere Windows-applikasjoner blant SSO-alternativene dine.

Når kan du ønske deg både 2FA og SSO?

Når bør du implementere både 2FA og SSO? Det enkle (men ikke alltid praktiske) svaret er «når det er mulig». Det mer praktiske og alltid kloke svaret er at for å beskytte sensitiv informasjon mot uautorisert tilgang, bør du aktivere 2FA. Når du gjør det, anbefaler NCSC at du også bruker SSO for å redusere «friksjonen» som 2FA introduserer. 2FA hjelper systemer med å sikre at brukerne som prøver å få tilgang, er brukerne deres legitimasjon representerer, og SSO forhindrer slurvete passordpraksis som kan føre til et sikkerhetsbrudd.

Med GO-Global har du muligheten til å aktivere både 2FA og SSO for alle Windows-applikasjoner du publiserer på GO-Global-verter.

For å lære mer, be om en demo her eller last ned en gratis 30-dagers prøveversjon .