Trål og trøbbel?

De fleste organisasjoner i Norge har en eller flere systemer som opererer i sky. For mange er identitetsløsningen et av disse systemene. Når en bruker skal logge på, omdirigeres brukeren til skytjenesten og autentiseres der, før brukeren kommer tilbake med et identitets-token og får tilgang. Lett som en plett.

Hva skjer da den dagen identitetsløsningen ikke lenger er tilgjengelig online og vi ikke får autentisert brukere til systemer som faktisk kjører i eget datasenter? Slik tidene er blitt er det nødvendig å foreta en risikoanalyse på identitetsløsningen og evaluere konsekvensen dersom den er borte.

Et typisk mitigerende tiltak vil da være å etablere lokale løsninger som kan aktiveres raskt dersom den sentrale skytjenesten faller ut for lengre tid. Her kan vi se for oss flere alternativer der de vil passe noe ulikt avhengig av hvordan infrastrukturen for øvrig ser ut:

• Etablere AD-basert autentisering via ADFS eller LDAP.

• Etablere sertifikatbasert autentisering via sertifikat som rulles ut via f.eks. Microsoft Intune.

• Etablere en lokal «Identiy broker» som benyttes av lokale applikasjoner også i normalproduksjon.

De to første punktene over sier lite om hvor mange steder vi må rekonfigurere for å etablere alternativ operasjon, det kan ofte være at alle applikasjoner må rekonfigureres. Ved å etablere en lokal «identity broker» kan vi ha ett enkelt system vi trenger å endre for å benytte alternative identitetskilder. Kildene kan da være en av de to første punktene i listen over.

Det kan være et visst arbeid å etablere en lokale «identity broker». Litt avhengig av hvor mange applikasjoner en har som benytter federerte identiteter. Det skulle imidlertid være lett å se nytten av å konsentrere alle relasjoner mellom lokale applikasjoner og identitetstjenesetene gjennom en lokal tjeneste. Med en slik arkitektur kan også flere applikasjoner dele idp-tjenester.

I normal drift gjøres ofte brukerautentiseringen «online» av AzureAD, Google, Okta eller tilsvarende. Gjerne med SSO (Single Sign-On).

Om vi i tillegg  sørger for å distribuere brukersertifikat til alle enheter mens vi er i normal drift, har vi en ferdig løsning som kan tre inn som plan B dersom det blir nødvendig. Alt vi da trenger å gjøre er å konfigurere aksessløsningene/identity broker til å kjøre sertifikatbasert autentisering foran applikasjonene. SSO vil da fungere som det gjør i normal-situasjon og sertifikatene er gyldige identitetsbevis helt til de utløper. Vi har da kjøpt oss månedsvis med tid til å omgruppere dersom det oppstår hendelser. Sertifikatene kan legges enten på TPM i laptoper eller på type Yubikeys som plugges i USB-porten der de skal brukes.

Den innstendige oppfordringen til alle som benytter sky-identiteter er dermed å foreta en slik risikoanalyse og evaluere behovet for å gjøre klar alternative løsninger som enkelt kan aktiveres. Finner man at det er nødvendig, anbefales det å samtidig etablere en lokal «identity broker» som alle lokale applikasjoner benytter.