Säkerhet: 2FA och SSO för Windows-applikationer 2025

Den här bloggen behandlar de omständigheter under vilka du kan välja att aktivera 2FA, SSO, båda eller ingendera för att säkra åtkomst till Windows-applikationer. Diskussionen kretsar kring hur man konfigurerar dessa säkerhetsåtgärder med GraphOn GO-Global. GO-Global är ett verktyg för publicering av Windows-applikationer som möjliggör säker åtkomst till Windows-applikationer var användarna än befinner sig, med hjälp av alla enheter som stöder en webbläsare - oavsett om det är en Surface Pro, Dell XPS, MacBook Air, Samsung Galaxy eller någon av många andra typer. (För mer information om GO-Globals inbyggda säkerhetsfunktioner, se "Utformad med säkerhet i åtanke").

När du börjar utforska bästa praxis för identitets- och åtkomsthantering (IAM) kommer du sannolikt att hitta ett överväldigande antal välrenommerade källor som erbjuder en mängd rekommendationer. Men du kommer också att hitta några gemensamma nämnare som gäller för små och medelstora företag (SMB), företag och molntjänstleverantörer, oavsett vilka tillgångar de skyddar:

- Användarnas digitala konton måste skyddas med referenser som t.ex. lösenord. I idealfallet dikterar policyer kriterier för starka lösenord och understryker vikten av att hålla referenser hemliga och säkra.

- Legitimationer som ger åtkomst till applikationer som exponerar känslig information bör verifieras med någon form av multifaktorautentisering (MFA), t.ex. tvåfaktorsautentisering (2FA). 2FA hjälper till att bekräfta att användarna är (i verkligheten) de användare som deras referenser representerar.

- SSO (Single Sign On) skyddar bättre mot mänskliga svagheter (som att glömma och återanvända lösenord) och minskar det upplevda besväret med 2FA.

Vilka principer du använder och när beror på flera variabler. Du måste bland annat ta hänsyn till den information som exponeras av de applikationer som användarna har rättigheter till. Du måste också ta hänsyn till hur användarna kommer åt dessa applikationer. Är användarna på kontoret eller arbetar de på distans? Finns applikationerna i ett företags datacenter eller i molnet? Kommer fjärranvändare att komma åt applikationerna via Internet? Med eller utan den kryptering som ett VPN ger?

Internet vet inte att du är en hund

Trots alltmer sofistikerade cybersäkerhetsåtgärder är lösenordet fortfarande den grundläggande autentiseringsmetoden, som bekräftar identiteten baserat på något som användarna känner till. Oavsett om det handlar om att komma åt sin telefon, komma åt jobbmejlen eller logga in i affärskritiska applikationer anger användarna självpåhittade kombinationer av bokstäver, siffror och specialtecken för att göra detta.

Problemet med lösenord är användarna. De gillar korta lösenord eftersom de är lättare att komma ihåg, men korta lösenord är också lättare att gissa. Därför insisterar administratörer och program på att användarna ska skapa längre lösenord, som är svårare att knäcka men också svårare att komma ihåg. (Se "Det nya starka: Lätt att komma ihåg, svårt att knäcka.")

När användare har dussintals konton som kräver komplexa lösenord tenderar de att ta till mindre säkra metoder: de skriver ner dem eller, vilket är värre och vanligare, återanvänder dem. Minst 65% av användarna återanvänder lösenord och 13% använder samma lösenord för alla konton och enheter.

Det är inte förvånande att lösenord är källan till en ökänt vanlig attackvektor: komprometterade referenser. Enligt en färsk rapport från IBM och Ponemon var "komprometterade referenser" faktiskt den vanligaste initiala attackvektorn 2021, vilket i slutändan ledde till 20% av alla dataintrång.

Oavsett hur "säkra" lösenorden är kan angripare avslöja dem. Även om SallyB skapar ett lösenord som det skulle ta en dator 23 duodecillioner år att knäcka, gäller det bara om hon håller det hemligt. (Se figur 1.) Men SallyB kanske oavsiktligt lämnar alla svar på frågorna om återställning av lösenord på sitt Facebook-konto. Eller så kanske hon får ett e-postmeddelande och klickar på den inbäddade länken, som tar henne till en dubbelgångarsida för inloggning, där en angripare fångar upp hennes inloggningsuppgifter.

Baserat enbart på referenser kan system inte veta om "SallyB" faktiskt är SallyB. Anledningen låter fånig men är ändå sann: datorer kan inte se.

‍

2FA: Om systemen hade en vision

Att aktivera 2FA är som att ge dina system en vision. 2FA kräver två olika former av identifiering för att autentisera. Den första formen är i allmänhet något som användarna känner till (t.ex. ett lösenord). Den andra är vanligtvis något som användarna har, till exempel en kod som skickas via sms eller, som ett säkrare alternativ, en kod som genereras av en autentiseringsapp som är installerad på användarens telefon.

För att motverka 2FA som bygger på sådana koder skulle angripare inte bara behöva en användares inloggningsuppgifter utan också användarens telefon. Detta extra säkerhetslager är extremt effektivt. Enligt en Google-studie från 2019 förhindrar användning av 2FA med en uppmaning på enheten 100 % av automatiserade botattacker, 99 % av bulkphishingattacker och 90 % av riktade attacker.

Det är inte förvånande att 2FA allmänt anses vara en bästa praxis för att säkra fjärråtkomst och är ett krav för alla nollförtroendearkitekturer.

När ska 2FA aktiveras?

Under vilka omständigheter bör du aktivera 2FA? Det enkla svaret är följande: aktivera 2FA för alla system som exponerar känslig eller privilegierad information.

Att aktivera 2FA för alla system kanske inte är det bästa valet. Användare kan stöta på situationer där 2FA kan hindra åtkomst - deras mobiltelefonsignal är till exempel skissartad eller deras telefon har tappats bort eller stulits. De flesta 2FA-system har visserligen lösningar för situationer som dessa. Med GO-Global kan du till exempel återställa koder från adminkonsolen så att användare kan få åtkomst till 2FA-aktiverade värdar även om de tappar bort sin telefon. Du bör dock väga den upplevda olägenheten med 2FA mot vad användarna har rätt att komma åt.

Tänk till exempel på den gemensamma uppsättning applikationer som du gör tillgängliga för alla (t.ex. Office 365, programvara för tidsregistrering, Adobe-produkter). Om dessa program körs bakom din brandvägg räcker det med inloggningsuppgifter för lokala användare. Även för fjärranvändare, förutsatt att de endast har rättigheter till den gemensamma uppsättningen applikationer med åtkomst till icke-känsliga data, skulle det förmodligen räcka med enbart autentiseringsuppgifter. Men du måste fråga dig själv: "Om 'SallyB' inte är SallyB utan en angripare, vad är det då som är i fara?"

För applikationer som potentiellt exponerar känsliga data är det lilla besväret som 2FA ibland kan orsaka värt att ta emot några klagomål. Till exempel bör du aktivera 2FA för dessa typer av användare som har åtkomst till dessa typer av applikationer:

- Utvecklare med tillgång till kodningsprogram

- Ingenjörer med tillgång till nätverkssniffare

- IT-administratörer med tillgång till programvara för brandväggs- och routerkonfiguration

- Revisorer med tillgång till löneprogram

- Medlemmar i säljteamet med tillgång till CRM-system (Customer Relationship Management)

- HR-personal med tillgång till HRM-programvara

Vad händer om användarna ovan har åtkomst till dessa applikationer via ett VPN? Ett VPN skapar en slags tunnel över Internet och krypterar den information som utbyts mellan användare och de system de har åtkomst till. Men ett VPN kan inte avgöra om den enhet som angav korrekta autentiseringsuppgifter för "SallyB" är SallyB. Om en användares roll ger åtkomst till känsliga data, med eller utan VPN, bör du därför aktivera 2FA för att skydda dem.

{{CTAEMBED_IDENTIFIERARE}}

Konfigurera 2FA i GO-Global

Att aktivera 2FA på en GO-Global-server som är värd för Windows-program är en enkel process. Du börjar med att välja Host Options på menyn Tools i Admin Console och klicka på fliken Authentication. På den skärmen klickar du på "Kräv tvåfaktorsautentisering". När du har klickat på "Okej" aktiveras 2FA. (Se figur 2.)

Varje gång användare ansluter till en 2FA-aktiverad GO-Global-värd uppmanas de först att ange sitt användarnamn och lösenord via dialogrutan Logga in. (Se figur 3.) När användarna klickar på "Logga in" för första gången uppmanar systemet dem att registrera sig för 2FA och beskriver de två steg som krävs för att göra detta.

- I steg 1 uppmanas användarna att ladda ner en autentiseringsapp på sin telefon. Användarna kan installera den app de väljer (t.ex. Google Authenticator, Authy, Duo Mobile och LastPass Authenticator).

- I steg 2 uppmanas användarna att öppna appen, klicka på "lägg till" eller "+" och sedan skanna den QR-kod som visas. (Se figur 4.) Den skannade QR-koden knyter den här användaren och den här telefonen till GO-Global. (Användare behöver bara skanna QR-koden en gång oavsett hur många 2FA-aktiverade GO-Global-värdar de har åtkomst till - så länge du aktiverar "roamingprofiler" i Admin Console).

Efter att ha tagit emot den skannade QR-koden visar GO-Global-värden en dialogruta där användarna uppmanas att ange den sexsiffriga koden från autentiseringsappen och sedan klicka på "Okej". Appen uppdaterar automatiskt dessa koder var 60:e sekund. När en användare har angett rätt aktuell kod öppnar GO-Global-värden App Controller, som visar de publicerade Windows-applikationerna.

Att förklara denna process i skrift tar några hundra ord, men att genomföra processen live tar bara några sekunder.

SSO: Den enda kraften

Att aktivera 2FA hjälper system att säkerställa att "SallyB" är den person som hennes referenser representerar. Men 2FA hjälper inte SallyB att komma ihåg sina lösenord - och oddsen är att hon har många av dem.

Enligt OneLogin, en leverantör av lösningar för åtkomsthantering, växlar 68% av användarna mellan tio applikationer varje timme. Om användarna är noggranna med säkerheten betyder det att de potentiellt anger upp till tio unika lösenord varje timme. Men de flesta användare är inte noggranna, så de återanvänder samma lösenord eller använder andra mindre än säkra alternativ.

Lösningen är att aktivera Single Sign On (SSO). SSO är ett verktyg för användarautentisering som gör det möjligt för användare att logga in på och få åtkomst till flera applikationer, webbplatser, data och arbetsstationer med hjälp av en enda centralt hanterad uppsättning autentiseringsuppgifter. SSO anses vara en bästa praxis för åtkomstsäkerhet. Faktum är att brittiska National Cyber Security Centre (NCSC) nämner en "enda stark källa till användaridentitet" som en viktig princip för en arkitektur med nolltolerans.

För att implementera SSO samarbetar organisationer med en identitetsleverantör (IdP). IdP:er använder ett protokoll, till exempel OpenID Connect, för att skapa förtroende mellan en organisations användare och SSO-integrerade applikationer. Användarna loggar in på IdP:n, som sedan genererar en unik åtkomsttoken. IdP:n använder denna token för att ge användarna åtkomst till de integrerade applikationer som de har rättigheter till.

Alla blir nöjda när användarna slipper ange olika inloggningsuppgifter för varje applikation. Användarna är nöjda eftersom de vanligtvis bara loggar in en gång om dagen till IdP:n. För er förenklar SSO processen med att granska och hantera användare. Säkerhetsteamen kan definiera och genomdriva strängare lösenordskrav. Och helpdesken får färre samtal om återställning av lösenord.

SSO för Windows-appar

Tyvärr har SSO historiskt sett bara varit tillgängligt för webbaserade applikationer - inte för Windows-applikationer. Problemet har varit att med Windows loggar användare direkt in på operativsystemet med ett användarnamn och lösenord, varefter Winlogon laddar användarens profil. Eftersom Windows OS kräver ett användarnamn och lösenord kan du vanligtvis inte inkludera Windows-applikationer i SSO-implementeringar i molnet utan en anpassad Credential Provider.

De SSO-lösningar för Windows-applikationer som finns tillgängliga, till exempel Citrix NetScaler Unified Gateway integrerad med Citrix Hypervisor, har rykte om sig att vara både dyra och komplexa.

GO-Global är redo att ändra på det ryktet.

GO-Globals OpenID Connect-autentiseringsfunktion finns som ett tilläggsalternativ och erbjuder SSO med en enkel installation till en bråkdel av kostnaden för andra SSO-lösningar för Windows-appar. GO-Global möjliggör SSO för Windows-applikationer via IdP:er som stöder OpenID Connect, inklusive Okta, OneLogin, Microsoft Active Directory Federated Services och Microsoft Azure AD Seamless SSO. När GO-Global OpenID Connect är konfigurerad kan användare som loggar in på en IdP få åtkomst till Windows-applikationer på GO-Global-värdar från sina webbläsare utan att behöva ange sina referenser igen.

Konfigurera SSO i GO-Global

För att integrera GO-Global-värdar med din organisations IdP börjar du med att konfigurera IdP:n så att den känner igen och arbetar med GO-Global. Den specifika inställningen beror naturligtvis på den specifika IdP. För Okta måste du till exempel bland annat ange protokollet (dvs. OpenID Connect), URL-adressen för omdirigering till GO-Global-värden och i vilken grad du vill kontrollera åtkomsten till värden. (Du kan t.ex. begränsa åtkomsten till utvalda grupper eller ge alla åtkomst).

För enkelhetens skull rekommenderar GraphOn att du kopierar några av IdP-inställningarna (till exempel Client ID, Client Secret och Redirect URL) till Notepad så att du senare kan klistra in dem i GO-Globals Admin Console. (Se figur 5.)

När du har konfigurerat din IdP konfigurerar du GO-Global-värden. Detta gör du genom att gå till GO-Global Admin Console, välja Host Options i menyn Tools och klicka på fliken Authentication. Därefter är det bara att klistra in de tidigare nämnda inställningarna i lämpliga fält för att konfigurera GO-Global-värden så att den använder din IdP.

När GO-Global-värden är integrerad med din IdP anger användarna sina IdP-autentiseringsuppgifter (när de uppmanas till det) för att komma åt värden från sin webbläsare. Efter att ha angett sina autentiseringsuppgifter och webbadressen till värden ser användarna App Controller, som visar de publicerade Windows-programmen.

När användare autentiseras via OpenID Connect till IdP:n autentiseras de automatiskt i Windows enligt de alternativ du väljer. Om IdP:n är integrerad med din organisations Active Directory kan du till exempel konfigurera GO-Global så att användarna automatiskt loggas in i sina användardomäner.

För bättre säkerhet och enkel åtkomst bör du utnyttja SSO när det är möjligt. GO-Global gör det enklare (och billigare) att inkludera Windows-applikationer bland dina SSO-alternativ.

När kan du vilja ha både 2FA och SSO?

När kan du vilja implementera både 2FA och SSO? Det enkla (men inte alltid praktiska) svaret är "när det är möjligt". Det mer praktiska och alltid kloka svaret är att du bör aktivera 2FA för att skydda känslig information från obehörig åtkomst. När du gör det rekommenderar NCSC att du också utnyttjar SSO för att minska den "friktion" som 2FA medför. 2FA hjälper system att säkerställa att de användare som försöker få åtkomst är de användare som deras referenser representerar, och SSO förhindrar slarviga lösenordsmetoder som kan leda till intrång.

Med GO-Global har du möjlighet att aktivera både 2FA och SSO för alla Windows-applikationer som du publicerar på GO-Global-värdar.

Om du vill veta mer kan du begära en demo här eller ladda ner en kostnadsfri 30-dagars testversion.