Ett av de svagaste sätten för att autentisera sig är att enbart använda sig av lösenord. Trots det är detta det vanligaste sättet vi använder för att nå både privata och kritiska arbetsrelaterade tjänster.

Med Azure Active Directory Premium får vi möjlighet att ”förlänga” det lokala AD till Azure för att sköta autentisering där, både för lokala tjänster och molntjänster.
Varför vill vi då flytta ut en så kritisk tjänst som autentisering till en molntjänst och hur skulle det kunna höja säkerheten?

Det finns många svar på den frågan och jag tänker med den här artikeln försöka beskriva några av dem.

Flerfaktorautentisering

För att komma runt den svaga autentiseringsformen lösenord används flerfaktorautentiseringsmetoder med den klassiska kombinationen; någonting som användarna vet (lösenordet) och någonting som användarna har.
För att göra det användarvänligt ser man till vad en användare oftast har med sig. till exempel sin mobiltelefon!
Här finns fler alternativ

• OTP (One-Time-Password) via SMS
  (En kod skickas som SMS och användaren får ange denna kod för att komma vidare.
• Uppringning
  Användarens mobiltelefon rings upp av en automatisk tjänst där man även kan skapa ett unikt meddelande, vilket både ökar användarvänligheten och säkerheten. Användaren blir uppmanad att trycka en tangent för att bekräfta autentiseringen.
• OTP via app till mobiltelefon och/eller platta
  Azure AD har en autentiseringsapp som finns till de vanligaste plattformarna, iOS, Android och Windows.
• Sekundär E-post
  Ett mail skickas till användarens angivna mailadress, där användaren får bekräfta ägandeskapet av E-postadressen genom att klicka på en länk.

I vissa scenarier kan det även vara en bra idé att kombinera två av de ovanstående. Exempelvis vid en lösenordsåterställning där användaren kan bekräfta att den innehar sin mobiltelefon, har tillgång till angiven e-postadress, kombinerat med unika frågor som bara användaren vet svaren på.
Återigen kravet på att nyttja något som användaren har och något som användaren vet, för att bekräfta en inloggning.

För att höja användarvänligheten och anpassa säkerhetsnivån efter känsligheten på den tjänst som autentiseringen går mot, anpassas detta. Ett exempel är att användaren slipper multifaktor när den loggar in från en enhet som organisationen känner till för de flesta tjänsterna och de mest kritiska kräver flerfaktorautentisering. På en främmande enhet är det vanligast att påtvinga flerfaktorautentisering mot alla verksamhetstjänster.

Övervakning/Larm

Då autentiseringstjänsten är en av de absolut mest kritiska tjänster vi har, är också en viktig del att kontrollera om de som ansluter mot tjänsten är legitima. Något som oftast saknas i lokalt publicerade tjänster!
Azuretjänsten validerar alla klienter som ansluter baserat på en mängd olika typer av data.

Sker inloggningar

• från olika geografiska positioner under en orimlig tid, vilket tyder på att fler använder samma konto
• med suspekta beteenden som fel lösenord, utan flerfaktor krav etc. som tyder på att en obehörig försöker logga in

Ansluter klienten från en

• svartlistad IP som har varit känd från tidigare attacker
• okänd källa, där det tyder på att en anonymiseringstjänst används.
• möjligt infekterad enhet

Frågan är hur Azure kan ha koll på all denna fakta utan att ens kräva någon form av lokal agent på anslutna klienter?
Det finns en organisation inom Microsoft kallad ”Microsoft Cybercrime Center” vars uppgift är att identifiera ”Bad guys”. Det här arbetet utförs på många olika sätt. All data som samlas in från Microsofts antivirus, inbyggda skyddet (Smart Screen filtret) i Internet Explorer med mera analyseras bland annat här.

Med avancerade algoritmer identifieras var ifrån attacker och skadlig kod kommer ifrån. Förutom att bevismaterial skickas till myndigheter runt om i världen, används även denna data för att stötta Microsofts egna kunder. Uppgifterna används för identifiera möjliga hot mot din autentiseringstjänst i Azure. Det finns både rapporter och larm för att underrätta din organisation om att något pågår.

Var sker lösenordsautentiseringen?

Det finns idag två alternativ över var lösenordskontrollen sker

1. Ha kvar lösenordsautentiseringen i ditt lokala Active Directory och komplettera med flerfaktorautentisering. Med hjälp av en ADFS-federation mellan lokalt AD och ditt Azure AD styrs lösenordskontrollen mot ditt lokala AD.
   Här är det viktigt att ha en pålitlig ADFS-lösning med redundans, då tjänsten blir extremt kritisk. Som det ser ut i skrivande stund behövs minst fyra servrar för att uppnå detta. Två ADFS servrar som frontas av två Web Application Proxy (WAP, ADFS front-end) servrar. Maskinerna skall även lastbalanseras, vilket genomförs bäst med en dedikerad hårdvara för lastbalansering.
2. Synkronisera användarnas lösenord till ditt Azure AD för att ge möjlighet för användarna att autentisera sig med samma lösenord direkt mot Azure. En av fördelarna är att det inte ställer krav på lokal infrastruktur.
   En vanlig missuppfattning är att användarens lösenord finns läsbart i Azure, vilket INTE är fallet. Det är en avancerad krypteringsfunktion som dels använder den inbyggda hash-funktionen i det lokala AD (som gör att lösenorden inte ens är läsbara av det lokala ADt). Lösenordets hash kommer på nytt omvandlas till en ny hash som synkroniseras till Azure AD. Det här gör att Azure klarar av att autentisera användarens lösenord men kommer aldrig ha varken original lösenordet eller ens den lösenordshashen som används av det lokala ADt. Det här gör att även om någon skulle komma över den lösenordshash som finns i Azure skulle det aldrig gå att använda denna för att till exempel logga in mot lokala tjänster.