8.3
Ytterligare funktionalitet
Båda produkterna tillhandahåller Windowsinloggning med certifikat samt skyd- dad lagring av ytterligare certifikat på enheterna. Produkten iKey har ingen yt- terligare funktionalitet utöver detta men löser uppgiften som utlovat. Passage har däremot funktioner utöver certifikathanteringen, bland annat lagring av lösenord som beskrivits ovan. Dessutom kan enheterna användas tillsammans med mjuk- varuenheter för att ersätta SD600-enheter vid färrinloggning. En översikt över detta finns i tabell 8.2. Utöver detta stöder Passage-enheterna Javaapplikationer, vilket ger näst intill obegränsade möjligheter för ytterligare användning av enhe- terna.
Tabell 8.2.Jämförelse av tekniska specifikationer
Specifikation Rainbow iKey RSA Passage Kapacitet för certifikat 4 st 3 st
Konton för domäninloggning – 3 st Lösenord för single sign-on – 15 st Kapacitet för mjukvaruenheter – 3 st
Typ av enheter USB Smartkort eller USB
Kapitel 9
Rekommendationer och
slutsatser
9.1
Rekommendationer
I detta kapitel presenteras de rekommendationer jag kan ge, baserat på de lär- domar jag dragit under projektet. Målet med projektet är att ge underlag för val av produkt för att ersätta lösenordsinloggning. Utöver detta pekar jag på några punkter som bör övervägas innan en sådan lösning införs.
9.1.1
Val av produkt
Den produktutvärdering jag har gjort utmynnade i en jämförelse mellan iKey 2032 från Rainbow Technologies och Passage från RSA Security. Det övergripande in- trycket är att iKey är en mer mogen produkt som fungerar utan uppenbara pro- blem, medan Passage erbjuder funktionalitet som kan ge företaget stora mervär- den i framtiden.
Min rekommendation till företaget är att överväga de krav, som denna utvär- dering utgått från, och fatta beslut om hur de ska prioriteras. Om endast ett säk- rare alternativ för autentisering önskas, anser jag att iKey är den produkt som bör väljas med motivering att den löser uppgiften utan att tillföra ytterligare funk- tionalitet, som ökar produktens komplexitet. Utöver inloggning med certifikat er- hålls även möjligheten att använda iKey-enheter för säker lagring av certifikat för andra ändamål.
Om företaget anser att funktionalitet utöver certifikathantering är önskvärt är iKey mindre lämplig. Passage medger här istället större flexibilitet vad gäller au- tentisering och ger dessutom möjlighet att använda hårdvaruenheterna till fler ändamål i framtiden. Eftersom företaget idag använder andra lösningar från RSA, skulle Passage komplettera dessa och kanske även minska den totala kostnaden för licenser. Dock ger inte Passage ett lika stabilt helhetsintryckintryck som iKey
på grund av några mindre fel som inträffat och är idag inte möjlig att använda för certifikatinloggning på grund av den långa fördröjning som uppstår. Den ver- sion av Passage som jag testat var helt ny och jag anser att den släppts för tidigt eftersom den är behäftad med fel. Dock är uppdateringar som åtgärdar bristerna utlovade. Min uppfattning är därför att om dessa löser problemen är Passage en produkt som både uppfyller företagets behov idag och ger stora möjligheter till framtida tillämpningar.
Min rekommendation för val av produkt för säker autentisering är följdaktli- gen att välja iKey om endast inloggning och certifikatlagring önskas och att avvak- ta uppdateringar av Passage om dess funktionalitet önskas. I händelse att denna funktionalitet önskas och Passage inte kan förbättras inom rimlig tid, kan det vara aktuellt att utvärdera ytterligare produkter som erbjuder liknande funktionalitet och som kanske befinner sig i ett mer moget tillstånd av utveckling.
9.1.2
Införande av certfikatinloggning och PKI
Om PKI-baserad autentisering införs, bör det även utredas vilka användargrup- per som ska använda certifikatinloggning och tilldelas hårdvaruenheter. Jag ser inte att man uppnår ett tillstånd av total säkerhet enbart genom att tilldela alla företagets användare smartkort och inte tillåta dem att logga in med lösenord. På grund av begränsningar i Windows hantering av PKI-autentisering måste teknisk personal tillåtas att autentisera sig med lösenord även i framtiden. Bland annat kräver vissa administrativa uppgifter, som till exempel att lägga till nya datorer i domänen, att behörigheten styrks med lösenord. Detta eftersom det inte finns stöd i nuvarande versioner av Windows för att göra detta med certifikat. Det ad- ministrativa verktyget CCM medför ytterligare krav på att lösenord finns kvar.
Vidare kan det finnas risker förknippade med att kräva att administratörer ska autentiseras med hårdvaruenheter. Om det uppstår problem med hårdvaran eller PKI:n kanske det i så fall inte finns någon som kan logga in och åtgärda pro- blemen. Av denna anledning måste ändå administratörer med ansvar för certifi- kathanteringen tillåtas logga in med lösenord. Den stora vinsten anser jag därför kommer att finnas för den största delen av företagets användare, vilka endast har en behörighet i nätverket och inte utför administratörsuppgifter. Genom att krä- va att dessa användare autentiseras med hårdvaruenheter och certifikat, minskas hanteringen av lösenord markant och risken att inloggningsuppgifter lämnas åt- komliga vid arbetsstationer eller är kända av flera användare minimeras.
Grunden för inloggning med certifikat är en PKI baserad på en CA för utfär- dande av certifikaten. För att detta ska fungera utan problem bör en långsiktig strategi utarbetas först och införandet genomföras med stor eftertanke. Riskerna är annars att förtroendet hos användarna för den nya tekniken äventyras om den medför problem för dem eller om lösningen måste revideras i efterhand. Vidare finns en risk att förtroendet för företagets certifikat och företagets säkerhetsarbete skadas om eventuella certifikat för signering måste återkallas på grund av en oge- nomtänkt lösning. Min rekommendation är att en välfungerande PKI bör införas innan certifikatinloggning kan vara aktuell, åtminstone om företaget önskar utöka