Revisinsrapprt 2010 Genmförd på uppdrag av revisrerna i Jönköpings kmmun Jönköpings kmmun Granskning av användaradministratinen
Innehåll 1. Bakgrund ch syfte... 3 2. Metd ch avgränsning... 3 3. Begreppsförklaringar... 4 4. Utförd granskning... 6 4.1. Riskklassificering av prcesser / IT-system... 6 4.2. Kraftfulla användare... 6 4.3. Prfiler... 7 4.4. Beställning ch gdkännande av behörighet... 7 4.5. Ansökan av en behörighet... 8 4.6. Inlggning... 8 4.7. Uppföljning... 9 5. Sammanfattande bedömning...10 Källförteckning...11 2
1. Bakgrund ch syfte Jönköpings kmmun ch dess lika förvaltningar har strt behv av lika IT-system i den dagliga verksamheten. Ansvaret för användaradministratinen, avseende många av systemen, finns vanligtvis ute hs förvaltningarna sm använder systemen. IS/ITavdelningen ansvarar för användaradministratinen rörande de centrala nätverken, servrar m.m. Detta innebär att många persner på lika nivåer i kmmunens rganisatin är inblandade. Syftet med granskningen har varit att bedöma m användaradministratinen är ändamålsenlig ch tillräcklig. 2. Metd ch avgränsning Följande system har valts ut tillsammans med IS/IT-avdelningen: - Ett internsystem sm tillhandahåller kraftfulla behörigheter - Helpdesk. - Eknmisystemet Aditr. - Upphandlingssystemet/avtalsdatabasen Tendsign. Dessa system har valts ut p.g.a. - Att de belyser användaradministratin sm sker både på förvaltningsnivå ch på central nivå - Att ett system (eknmisystemet Aditr) finns på servrar i kmmunens regi ch ett system (Tendsign) är ett webbaserat system där drift köps från extern part - Ett system (Helpdeskfunktinen) är centraliserat till användare enbart IS/IT-avdelningen, medan främst Aditr är ett system där många användare finns på de lika förvaltningarna inm kmmunen. Systemen har valts ut för att kunna visa m det finns skillnader i rutiner ch kntrller då de lika systemen har lika förutsättningar. Följande granskningsmment har genmförts för vanstående system: - Identifiering ch verifiering av fem användarkntn sm skapats under 2010. Granskning har skett av dkumentatin sm styrker att användarkntt skall skapas, m aktuell behörighet är relevant, att gdkännande finns från behörig persn sv. - Identifiering av vilka persner sm har de kraftfullaste användarkntna i respektive system. Det kan förekmma persner sm har begränsade behörigheter i systemen. Bedöma m dessa är rimliga vad gäller antal persner, deras funktiner sv. - Urval av tre behörighetsprfiler i systemet. Analysera behörigheternas mfattning ch verifiera att de följer riktlinjer/beslut. 3
3. Begreppsförklaringar Nedanstående figur beskriver ett antal begrepp sm används i rapprten. Risknivå Hög Låg Behörighet Verksamhetsmråde/prcess 1 2 3 4 5 Hög ADMIN x x x x x (tillgång till alla funktiner) Hantering register/fasta data x x x x x Löpande drift x x x x x Låg Titta x x x x x Användare I en rganisatin finns ett antal verksamhetsmråden/prcesser t.ex. löneprcess, inköpsprcess m.m. Verksamhetsmrådena/prcesserna kan delas in utifrån lika risknivåer. En högre risknivå bör fastställas när det gäller känsliga system sm hanterar ex. sekretessbelagd infrmatin (t.ex. inm scialtjänsten). Det kan ckså vara system sm hanterar funktiner sm kan påverka mycket, t.ex. stänga ner ett värmekraftverk eller flytta begränsat med pengar till externa kntn. En lägre risknivå kan fastställas för exempelvis kmmunens anläggningsregister. Riskklassificeringen bör utgå från den skada sm kan uppstå m behöriga får tillgång till infrmatin/funktiner i systemet. För verksamhetsmrådena/prcesserna används lika IT-stöd (system). Ovanstående figur utgår från antagandet att det endast är ett IT-stöd sm används för varje verksamhetsmråde. För att nå en hög säkerhet inm IT-systemen är det en grundläggande förutsättning att systemstrukturen byggs på ett säkert sätt så att det finns klara skiljelinjer mellan de lika systemen, dvs. det får inte finnas möjlighet att nå ett system via en behörighet i ett annat system. Systemstrukturen mellan kmmunens lika IT-system har inte behandlats i denna granskning. I det enskilda systemet finns lika behörigheter, dessa beskriver vilken infrmatin ch vilka funktiner användaren har tillgång till. Den lägsta nivån är tittarbehörigheten. I det fallet kan användaren inte ändra någt i den infrmatin sm finns lagrad i systemet. Mtsatsen är ADMIN-behörigheten, sm innebär att användaren har tillgång till samtliga funktiner ch infrmatin i systemet. Denna behörighet bör begränsas i så str utsträckning sm möjligt. 4
Användare sm har tillgång till denna behörighet eller har mtsvarande behörigheter sm är mycket mfattande kallas i rapprten kraftfulla användare. Inm varje system finns lika delsystem. Nedanstående figur visar delsystem inm ett eknmisystem. Delsystem Kundreskntra ADMIN x x x (tillgång till alla funktiner) Hantering register/fasta data x x x Löpande drift x x x Titta x x x Leverantörsreskntra Anläggningsregister Prfil Användare Delsystemen kan delas upp ytterligare i ett antal funktiner/arbetsuppgifter. I leverantörsreskntran ingår nrmalt bl.a. att registrera leverantörsuppgifter, registrera fakturr ch utföra betalningar. En användare kan få tillgång till lika behörigheter i delsystemen. Man kan t.ex. ha tittarbehörighet i ett delsystem ch ADMIN behörighet i ett annat. Kmbinatinen av behörigheter kallas i rapprten för prfil. 5
4. Utförd granskning I detta avsnitt presenteras de väsentligaste iakttagelserna sm nterats i granskningen. 4.1. Riskklassificering av prcesser / IT-system Det nteras att det saknas rutiner för att på ett systematiskt sätt riskklassificera IT-system inm kmmunen. Kmmentar: Rutiner för tilldelning av behörigheter, lösenrd, uppföljningar m.m. bör utgå från varje enskilt systems identifierade risknivå. Kmmunen har nu inlett ett arbete med att klassificera systemen utifrån ett riskperspektiv. Hänsyn måste tas till att det finns system med känslig infrmatin (t.ex. system på scialförvaltningen) ch att systemen måste vara tillgängliga (t.ex. system sm styr dricksvattentillförsel). Förbättringsmråde: Sm nämns van har kmmunen startat ett arbete med att klassificera system. Vi rekmmenderar att det fastställs rutiner för att riskklassificera varje enskilt IT-system sm kmmunen använder. Riskklassificeringen bör uppdateras med en viss frekvens, t.ex. årligen, för att säkerställa att inga väsentliga förändringar skett av verksamheten sm påverkar risknivån för aktuellt system. Fastställd risknivå bör påverka all hantering av systemet, hur fta lösenrd ska bytas, vilka kntrller sm skall utföras vid tilldelning av nya behörigheter, vilka kntrller sm skall utföras vid systemuppdatering m.m. 4.2. Kraftfulla användare Ett urval av användare i berörda system har granskats för att få en bild av vilka sm kan klassificeras sm kraftfulla användare. Granskning har även skett av dessa användares funktiner i rganisatinen samt mfattningen av antalet kraftfulla användare. Det nteras att det finns ett antal persner inm den perativa verksamheten sm kan definieras sm kraftfulla användare. Dessa persner använder systemen i sitt dagliga arbete för att utföra löpande arbetsuppgifter. Vissa av dessa persner har nyckelbefattningar i rganisatinen. Det nterades även en persn sm slutat sin anställning inm kmmunen. Kmmentar: Kraftfulla användare bör så långt det är möjligt vara avgränsade från den perativa verksamheten. Förbättringsmråde: Det är väsentligt att det på ett tydligt sätt framgår för varje enskilt system vilka persner sm identifierats sm kraftfulla användare. Om det inte är möjligt att avskilja kraftfulla användare från den perativa verksamheten bör kmpletterade kntrller fastställas. 6
4.3. Prfiler I vissa av systemen är behörigheterna detaljanpassade efter användarna, medan andra system har mer standardiserade behörigheter. I granskningen har det nterats att ansökan m behörigheter till en ny användare ibland önskas utifrån en medarbetares befintliga behörighetsstruktur. Det nteras även att många av de prfiler sm skapats utgår enbart från vad en användare behöver ha tillgång till för att sköta det dagliga arbetet. Det saknas en dkumenterad riskbedömning sm utgår från vad sm är lämpligt utifrån ett intern kntrllperspektiv. Kmmentar: Det är svårare att upprätthålla en gd kntrll på användarna ch deras behörigheter m de är för detaljerat uppsatta till specifika tjänster. Om nya behörigheter begärs utifrån en annan användare, finns det en risk att den persnen har kraftfullare behörigheter än vad den nya persnen verkligen behöver. Förbättringsmråde: Behörigheter bör standardiseras ch följa en enhetlig struktur. Behörigheter ska tilldelas utifrån ansvarsmråden men även utifrån systemets riskklassificering. Vid beställning ch gdkännande av behörigheter är det väsentligt att analys ch bedömning sker av både medarbetarens ansvarsmråde ch m det är rimligt ur ett internkntrll perspektiv (stödjer två-persnshantering, dvs. en persn ska inte ensam hantera alla mment i verifieringskedjan). I de fall tilldelning av en behörighet innebär en ökad risk ur internkntrll synpunkt är det väsentligt att identifiera detta ch täcka in eventuella riskmråden med ex. manuella kntrller. 4.4. Beställning ch gdkännande av behörighet De granskade systemen skiljer sig åt vad gäller struktur ch antal användare. Det finns en tydlig huvudägare till behörighetstilldelningen på IS/IT-avdelningen, men det saknas tydliga regler för vem sm har rätt att beställa behörigheter ute i förvaltningsrganisatinen. I de flesta fall är det en avdelningschef eller mtsvarande sm gör beställningen till IS/ITavdelningen. Kmmentar: Det finns en risk att persnal erhåller en felaktig behörighet m det finns tveksamheter kring vem sm har rätt att beställa nya behörigheter/förändra villkren i befintliga behörigheter. Förbättringsmråde: Det bör finnas fastställda rutiner där det tydligt framgår vem sm har rätt att: gdkänna behörigheter beställa nya behörigheter alternativt/förändra befintliga behörigheter begära brttagning av behörigheter när de inte längre är aktuella Det är väsentligt att den persn sm har rätt att beställa behörigheter är väl insatt i vad medarbetaren har för ansvarsmråden ch arbetsuppgifter. Den persn sm har rätt att gdkänna behörigheter bör har gd kunskap m hur behörigheterna är strukturerade i det aktuella systemet. 7
4.5. Ansökan av en behörighet Det finns ingen gemensam plicy avseende användaradministratinen inm kmmunen. Det nteras att det även saknas systemspecifika plicys/riktlinjer för de system sm ingår i granskningen. Det finns inget fastställt dkument sm anger vilka uppgifter sm krävs vid en beställning av en ny behörighet/förändring av en befintlig behörighet. Kmmentar: Avsaknad av riktlinjer kring användaradministratinen ökar risken för likartad hantering ch att det är den enskilda persnens riskmedvetande sm styr vilka kntrller sm utförs i samband med behörighets- ch lösenrdstilldelning. Förbättringsmråde: En mall för behörighetsansökan bör tas fram. Den kan med fördel vara webbaserad ch innehålla följande uppgifter: vem ansökan gäller vem sm är ansvarig för ansökan aktuellt system datum för ansökan startdatum ch i vissa fall även slutdatum (slutdatum ska alltid anges gällande känsliga behörigheter. I dessa fall ska en begäran m förnyelse ske efter viss fastställd perid. en tydlig struktur för vilka system, behörigheter m.m. sm avses vem sm gdkänt ch utfört behörigheten m ansökan gäller en känslig behörighet kan ev. ytterligare gdkännande krävas 4.6. Inlggning Sm nämnts tidigare finns det ingen generell plicy sm fastställer gemensamma rutiner avseende användaradministratinen för kmmunens system. Det förekmmer system sm har tvingande lösenrdsbyte varje månad men det förekmmer även system sm saknar denna rutin. Det nteras att lösenrd till ett nytt system skickats till ansvarig chef. Det finns även fall där standardlösenrd använts. Kmmentar: Lösenrdet till inlggningen, sm skall vara persnligt ch hemligt, skall säkerställa att det är rätt användare sm lggar in i systemet/på kntt. Om det saknas riktlinjer för inlggning ökar risken för felaktig hantering ch behörig åtkmst. Förbättringsmråde: Det finns en mängd terier kring säker inlggning ch byte av lösenrd. Ett sätt är att ha enkla lösenrd ch byta fta ch ett alternativ är att ha mycket kmplicerade lösenrd med byte mer sällan. Branschstandarden rekmmenderar att standardsystem har lösenrd sm består av minst åtta tecken ch att byte sker var 90:e dag. För system sm kräver en ökad säkerhet bör det krävas kmplicerade lösenrd, dvs. innehålla minst ett specialtecken, en siffra ch en bkstav. 8
Byte av lösenrd sm sker mer frekvent än var 90:e dag, kan resultera i att lösenrdet skrivs ner, vilket minskar säkerheten. Vidare bör det inte vara möjligt att byta tillbaka till tidigare använt lösenrd ch det bör finnas krav på att ha lösenrdet ska innehas minst en dag. Efter ett fastställt antal misslyckade inlggningsförsök bör kntt låsas ch endast kunna låsas upp med hjälp av Helpdesk. Det är viktigt att någn annan part blir medveten m rsaken till låsningen. Lösenrdet bör alltid lämnas direkt till aktuell användare. 4.7. Uppföljning Det saknas rutiner för peridiska uppföljningar sm säkerställer att rätt användare ch rätt behörigheter är kpplat till kmmunens system. Vid vår granskning nterades kntn sm brde låsts eller plckats brt p.g.a. att användaren slutat sin anställning eller bytt arbetsuppgifter. Kmmentar: När en medarbetare slutar eller byter arbetsuppgifter ch ansvarsmråden ch erhåller nya behörigheter är det viktigt att det finns rutiner för att de gamla behörigheterna plckas brt. Detta kan resultera i icke önskade kmbinatiner av behörigheter sm inte är förenat med gd intern kntrll. Förbättringsmråde: Rutiner för systematiska uppföljningar av samtliga IT-system bör fastställas. Det är väsentligt att fastställa en tidplan för uppföljningarna sm bör vara kpplade till systemets fastställda risknivå. 9
5. Sammanfattande bedömning I vår granskning har det nterats ett par gamla kntn ch behörigheter sm inte avslutats på krrekt sätt. I övrigt görs bedömningen att det finns en infrmell kntrllstruktur avseende användaradministratinen. Det saknas dck skriftliga rutiner ch dkumentatin sm gör det möjligt att i efterhand verifiera att kntrller utförts. Vår sammanfattande bedömning är att användaradministratinen kan utvecklas för att bli mer ändamålsenlig ch enhetlig inm kmmunen. Följande utvecklingsmråden har identifierats i granskningen: Ett system för att på ett systematiskt sätt riskklassificera samtliga system/prcesser sm används inm kmmunen bör införas. Fastställd risknivå bör mprövas enligt fastställd tidsplan för att ta hänsyn till ev. förändringar i verksamhet m.m. Det är väsentligt att det på ett tydligt sätt framgår för varje enskilt system vilka persner sm identifierats sm kraftfulla användare. Om det inte är möjligt att avskilja kraftfulla användare från den perativa verksamheten bör kmpletterade kntrller fastställas. Behörigheter bör standardiseras ch följa en enhetlig struktur. Behörigheter ska tilldelas utifrån ansvarsmråden men även utifrån systemets riskklassificering. Det ska finnas tydliga riktlinjer sm anger vem i rganisatinen sm har rätt att beställa nya/förändra befintliga behörigheter samt vem/vilken funktin sm har rätt att gdkänna behörigheter. Vid beställning ch gdkännande av behörigheter är det väsentligt att det finns kntrllmment sm beaktar rimligheten i behörigheten utifrån medarbetarens ansvarsmråden ch fastställda krav på intern kntrll. En mall för ansökan m ny behörighet/förändrig av befintlig behörighet bör tas fram för att säkerställa ett likfrmigt arbetssätt. Riktlinjer kring lösenrdstilldelning bör fastställas. Dessa bör kpplas till systemets fastställda risknivå. Det bör fastställas riktlinjer sm anger hur lösenrd för lika typer av system ska utfrmas ch hur fta byte av lösenrd ska ske. Även här bör kppling till systemets risknivå ske. Rutiner för systematiska uppföljningar av samtliga IT-system bör fastställas. Uppföljningar bör ske med viss fastställd frekvens. Jönköping 24 februari 2011 Per Magnussn 10
Källförteckning Intervjuer har skett med följande befattningar: IS/IT- chef Infrmatinssamrdnare Upphandlingschef Systemägare för Aditr eknmisystem Systemförvaltare för Aditr eknmisystem Teknikgruppschef inm IS/IT-avdelningen Dkument avseende användare i berörda system ch servrar Dkument över behörigheter för ett urval av användare Skärmbilder sm visar exempel på inlggning ch lösenrdslängder 11