Handledning för applikationsägare

Transkript

1 Tjänstebeskrivning Handledning för applikationsägare Version Revisionshantering Vernr Datum Notering Ansvarig Något modifierat dokument Arne Fredholm Korrigeringar efter genomgång Arne Fredholm Korrigeringar Arne Fredholm Korrigeringar efter granskningsmöte Arne Fredholm

2 Innehållsförteckning 1 Sammanfattning Målgrupp Bakgrund Tillgänglig dokumentation Regler Tjänstens innehåll, bastjänst Tilläggstjänster Krav på webbapplikationen Fysisk säkerhet och andra säkerhetsregler Grafiskt gränssnitt Aktiviteter i samband med publicering av ny applikation via ID- portalen Informations- och säkerhetsklassning av applikationen Test av applikationen Produktionssättning, driftavtal och villkor Kostnader och avtal Kostnader för implementering av applikation Driftkostnad infrastruktur Licenskostnader Kostnader för certifikat, hårda och mjuka Kostnader för SMS Systemlogik och Teknik Metoder Webbagent Reverseproxy Val av anslutningsmetod Användaradministration Flera behörighetsnivåer Checklista vid integrering av applikation idportal med Reverse Proxy idportal med Agent (12)

3 1 Sammanfattning Detta dokument beskriver hur en webbserver med webbapplikation bör konfigureras inför en publicering via idportalen. Den policy och de tekniska regler som beskrivs ger applikationstillverkaren vägledning om hur webbsajten ska byggas och konfigureras för att på ett säkert sätt kunna presenteras via idportalen. Ytterst är dokumentets syfte att hjälpa till vid etableringen av en teknisk miljö där besökaren alltid skall kunna lita på att den information som förmedlas är korrekt samt känna ett förtroende för att den personliga integriteten är skyddad i kontakten med Stockholms stad via idportalen. D enna dokum entation bör läsas tillsam m ans m ed S ystem beskrivning idp ortal för att kunna få en inblick i vad som krävs. 1.1 Målgrupp Systemägare inom Stockholms stad Medarbetare inom Stockholms stad och leverantörer till Stockholms stad som önskar orientera sig om tjänstens innehåll. Utvecklare som skall genomföra en integration mot idportalen. 2 Bakgrund idportalen är Stockholms stads system för autentisering och identifiering av användare (per definition sådana som når stadens interna resurser utifrån Internet eller via intranätet). Det är primärt en identifieringslösning (autentisering) via vilken man som användare når skyddade resurser som tillhör Stockholms stad, samtidigt som man spärrar personer som inte har behörighet. IdPortalen kan även användas för behörighetshantering (auktorisering). IdPortalen är ett obligatoriskt system om man vill nå interna applikationer från Internet eller via intranätet. 2.1 Tillgänglig dokumentation All dokumentation rörande idportalen finns tillgänglig på stadens intranät. 3 Regler 3.1 Tjänstens innehåll, bastjänst idportalen stödjer vanlig http trafik, dvs. get, post och put kommandon. idportalen använder s.k. cookies för att ge access och auktorisering till webbklienten. Detta kräver att klienten (webbbrowsern) måste tillåta att dessa cookies sätts. 3 (12)

4 IdPortalen ger kryptering och ett regelverk för att kunna skydda applikationer som presenteras bakom ett webbgränssnitt. IdPortalen använder sig endast av den befintliga användarinformationen som finns i respektive katalog/databas. Vilka regler som skall användas via idportalen bestäms av applikationsägarna i enlighet med Stockholms Stads IT-säkerhetsregler som grund. IdPortalen påverkar aldrig det interna regelverk som finns uppsatt i de webbapplikationer som ska skyddas. IdPortalen kan ge ytterligare skydd och funktioner för att komma fram till en applikation, som t.ex. SSO (Single Sign On). 3.2 Tilläggstjänster idportalen har även fler funktioner. Samtliga dessa är inte i drift idag, men de kan snabbt sättas i drift om det finns ett behov i anslutande applikation. Lösenordservice kan hantera lösenord och även konton som är låsta med centrala felmeddelandesidor. Automatisk självregistrering via e-id. Om användaren har ett certifikat är det klart. idportalen kan skicka med information från användardatabaserna ner till webbservrarna för t.ex. SSO mot webbapplikationen. Informationen kommer ner till webbservern via http-headers eller cookie. Idag används bara http-headers. Man kan via den lokalt installerade agenten för idportalen ställa in ett antal regler redan där som begränsar rättigheterna t.ex. PUT,GET etc... Andra begränsningar/inställningar kan även justeras på agenten. Man kan aktivera många händelser på ett stort urval parametrar t.ex. omdirigering till en annan sida om man gör något som inte är tillåtet. Man kan granulera webbserverns sidor så att vissa sidor kräver bara SMS medan andra kräver en högre autentisering t.ex. hårt certifikat. Användaren blir då omdirigerad till de metoderna automatiskt. Man kan ha flera olika inloggningsmetoder mot samma tjänst för att kunna utöka flexibiliteten för användarna. Har stöd för flera olika webbapplikationer och protokoll. För mer optioner gå till: 4 (12)

5 3.3 Krav på webbapplikationen För att en webbapplikation skall kunna anslutas till idportalen måste följande krav vara uppfyllda. Inga omdirigeringar från webbsajten till annan sajt om denna antingen skall innefattas av idportalens identifiering, eller applikationen inte skall innefattas av idportalen Inga hårt satta länkar internt i webbsajten, dvs endast relativa sökvägar gäller. Istället för att hänvisa till skall man hänvisa till /bilder/inloggning.gif. Sajten bör inte vara SSL-skyddad. Endast vanlig HTTP trafik till och från siten. SSL-förbindelse upprättas högre upp i kedjan. IdPortalen förutsätter att de applikationer som skyddas är konstruerade enligt Stockholms stads tekniska plattform. en måste konfigrueras med FQDN, se Systembeskrivningen 3.4 Fysisk säkerhet och andra säkerhetsregler ID- portalen ställer inga ytterligare krav på fysisk säkerhet för applikationer och applikationsservrar än det som beskrivs i P olicy och regler för inform ationssäkerhet vid S tockholm s stad. B eslutad av kom m unfullm äktige F ysisksäkerhet beskrivs i P olicy och regler för inform ationssäkerhet vid S tockholm s stad. All dokumentation om IT-säkerheten finns på stadens intranät, Grafiskt gränssnitt I de fall en applikation ligger under stockholm.se domänen och vänder sig till en publik målgrupp skall stadens grafiska profil följas. Beskrivande dokument finns att få av Kommunikationsavdelningen på SLK. 4 Aktiviteter i samband med publicering av ny applikation via ID- portalen Detta arbete skall ske i samråd med en implementatör från stadens driftpartner (idag TietoEnator) som har erfarenhet av tidigare installationer. 5 (12)

6 4.1 Informations- och säkerhetsklassning av applikationen Första steget är att göra en informations- och säkerhetsklassning av applikationen med dess innehåll. Klassningen görs av varje förvaltning och bolag. Samråd skall göras med stadens informationssäkerhetschef. Vid klassningen beslutas vilken typ och lägsta nivå av inloggningsmetod som ska användas för åtkomst till applikationen via idportalen. Inloggningsmetoderna kan klassas i olika nivåer. 1 är hög och 3 är lägsta säkerhetsnivån. 1. Biometri, hårt certifikat 2. SMS inloggning, mjukt certifikat 3. Lösenord 4.2 Test av applikationen en ska testas innan produktionssättning. Ett testprotokoll som visar vad som testats och hur det gjorts skall följa med all annan dokumentation före produktionssättning. 4.3 Produktionssättning, driftavtal och villkor Produktionssättningen regleras i en speciell överenskommelse mellan systemägaren och driftleverantören. Av det dokumentet skall det framgå vad som gjorts i applikationen som skall använda idportalen samt hur idportalen konfigurerats för just denna applikation. Driftavtal och SLA-villkor regleras via ett avtal mellan Stadsledningskontoret och driftleverantören. 5 Kostnader och avtal 5.1 Kostnader för implementering av applikation Varje ny webbapplikation har sina unika förutsättningar vid en implementering. Detta beror på en mängd faktorer såsom säkerhetsklassning, uppbyggnad, metod för inloggning mm, vilket gör det svårt att sätta ett fast pris på jobbet. Vid en beställning görs därför alltid en förstudie som tar c:a 16 timmar. Därefter får beställaren ett förslag på fortsatt arbete att ta ställning till. Ca 40 timmar brukar vara ett riktmärke för den tid det fortsatta arbetet tar. Kostnaderna för implementeringen kommer efter genomfört arbete att faktureras av TietoEnator direkt till systemägaren. 5.2 Driftkostnad infrastruktur Driftkostnaden för infrastrukturen tillhörande idportalen ingår i kommunikationskostnaden. 6 (12)

7 5.3 Licenskostnader Kostnader för licenser tillhörande idportalen är centralt finansierad och finns för samtliga medborgare i Sverige som kontaktar staden via idportalen. 5.4 Kostnader för certifikat, hårda och mjuka Kostnader för anskaffning av hårda certifikat och kortläsare med klient står respektive förvaltning/bolag själva för. För närmare information om detta kontakta IT-säkerhetschefen på Utvecklingsavdelningen, SLK. 5.5 Kostnader för SMS Kostnaden för inloggning via idportalen med hjälp av engångslösenord via SMS är idag centralt finansierad. Kostnaden är ca 50 öre/inloggning. Vid en kraftig ökning av användningen av SMStjänsten kommer finansieringen att ses över. 6 Systemlogik och Teknik idportalen bygger på produkten etrust Siteminder från CA. Systemet består av ett flertal komponenter som tillsammans bildar det regelverk som medger/nekar åtkomst till applikation. Se dokum entet S ystem beskrivning idp ortal 6.1 Metoder Det finns två sätt att ansluta sin webbserver/webbapplikation via idportalen Via agenter installerade på IIS (Microsofts webbserver) dvs. stadens standard för webbplattform. Agenter finns för andra plattformar finns, men dessa behandlas inte här. Via reverseproxy Webbagent W ebbagent m etoden innebär att ett program installeras fysiskt på webbservern. Programmet (agenten) reglerar då via en policyserver hur vägen till applikationen definieras och hur applikationen ska skyddas. Installationen av en webbagent görs i samarbete med driftleverantören. Detta görs efter samråd med systemägare om metodval. Webbagenten konfigureras för att ansluta mot de centrala policyservers i idportalen. Webbagenten behöver ett konto för att kunna administrera webbservern. Att tänka på för applikationsägare vid användning av webbagent Skapa konto för administrera webbservern med ett lösenord som inte går ut. Undvik att blanda virtuellaservrar installerade på servern som använder WebAgent med andra som inte använder den.. 7 (12)

8 Ta inte bort default Webbserver, använd istället disable om den inte ska användas av säkerhetsskäl Reverseproxy R everseproxy m etoden innebär att agenten ligger på en s.k. reverseproxy i stadens DMZ. Ingen installation görs på webbservern. Reverseproxy hanterar kontakten med regelverket medan innehållet "speglas" av en server som hämtar sidorna från webbsajten. Ex > revproxy ---> info.stockholm.se Konfigurering av reverseproxy sker av driftleverantören. Ingen programvara installeras på webbservern. Att tänka på för applikationsägare vid användning av reverseproxyy Användning av virtuella kataloger (särskilt om de ändrar rootbeteende) och beroenden av hostheadrar måste diskuteras per applikation av applikationsägare och driftleverantören. 6.2 Val av anslutningsmetod Vid installation av webagent på servern kommer det att medföra att alla interna användare måste använda idportalen för att komma åt tjänsterna. Detta rekommenderas när man har en tjänst som är enbart extern eller om man inte vill skilja på interna och externa användare inloggningskrav. Det är dock möjligt att ha vissa delar av sajten oskyddad. Vill man ha olika inloggningsmetoder på intern (t.ex Lösenord) och externa användare (T.ex. SMS) skyddar man exempelvis sajten internt via webbagent och externt via reverseproxy. Metoden med webbagent rekommenderas. Varianten med reverseproxy används främst om webbsajten av någon anledning inte får röras (drivs i annan regi etc), hanteras på en plattform som SiteMinder saknar agent för eller av annan förkommande anledning. Vid egen webbagent måste dock överenskommelse om hur uppdateringar sker och när de kan ske gås igenom. På reverseproxy lösningen finns det redundans så att man kan uppgradera utan att tjänsten tas ned. Då en intern brandvägg mot stadnätet finns skall följande portar vara öppna: Webbagent: Från stadsnätet till det lokala nätet skall, vanligtvis, port 80 vara öppen (från en specifik ipadress). Från det lokala nätet måste port 44441, och vara öppna för kommunikation till policyservrarna (till specifika ipadresser) Reverseproxy: Från stadsnätet till det lokala nätet skall, vanligtvis, port 80 vara öppen (från specifik ipadress). 8 (12)

9 7 Användaradministration Användarna ligger normalt antingen i stadens metakatalog, där stadens anställda och elever kan ha konto, eller i idportalens användarkatalog, där externa användare får finnas. I metakatalogen hanteras användaradministrationen av varje förvaltning. I idportalskatalogen kan varje applikationsägare få ett eget administratörsgränsnitt som utformas efter de behov som finns för applikationen. I detta är det möjligt att lägga till användare och ändra behörighet till sin applikation samt att byta eventuella lösenord. Dessutom finns det möjlighet att själv få administrera sina användare direkt via LDAP mot idportalens katalog. Detta måste dock utvärderas och testas noga för att undvika att fel uppstår på befintliga användare. 8 Flera behörighetsnivåer En applikation kan ha olika nivåer på behörighet. Beroende på vilken roll som ska nå applikationen bör följande beaktas: Handlar det om flera nivåer? Finns det bara rollerna administratör eller användare? Följande sätt finns att tillgå: idportalen kan beroende på olika attribut i användarkatalogen komma åt låta vissa användare komma åt en applikation, men neka andra. T.ex. om användarnamn börjar med SOT, eller om metaforvaltningsnr är 110, eller om det finns något annat attribut i katalogen som skall användas. Mappa inloggningen mot befintligt behörighetssystem. Det vill säga: låt idportalen ta hand om identifieringen och auktoriseringen men mappa den inkommande personen mot befintligt BKS (behörighetskontrollsystem) för accessbegränsning. Detta är den rekommenderade metoden. Här är det önskvärt att emotta variabler med exempelvis personnummer för att kontrollera mot intern behörighetsdatabas. sspecifika värden kan läggas in i katalogen som sedan läses av inne i applikationen. Lägg upp och skydda två olika sajter. Detta är något mer komplext, särskilt om inte Webbagent används. Ett flertal entries krävs vid Reverse Proxymetoden, vilket gör det mer tidsödande att grundkonfigurera samt mer svårhanterligt i klientens URL- hantering (Det blir de facto två olika adresser att accessa i webbläsaren) 9 Checklista vid integrering av applikation Diskutera skyddsklassning med säkerhetschef Vilken typ av information skall presenteras? Vilken/vilka inloggningsmetoder skall användas? 9 (12)

10 Bestäm IP-adress och ev hostnamn som sajt svarar på Bestäm även om applikation skall nås på port annan än 80. Om intern brandvägg finns, öppna för access på överenskommen port Access behöver bara delas ut till de specifika IP-adresser angiven av driftleverantören. Installera agent I samråd med driftleverantören. Siteminderstrafiken går på TCP som då behövs vara öppna i brandväggen. Skapa ett extern hostnamn Namn skall registreras i stadens DNS-servrar för replikering ut mot Internet. Om man använder en adress med.stockholm.se som domännamn(t.ex. idportalserver.stockholm.se) kan man använda Stockholms Stads certifikat för SSL terminering, annars måste ett eget certifikat beställas och installeras på SSL termineringen. Beställ eventuellt SSL certifikat. Beställs via SLK. 10 (12)

11 10 idportal med reverseproxy RevProxyn ligger här och avslutar siteminder förbindelsen. Till och från webbservern går bara vanlig http trafik. 11 (12)

12 11 idportal med Agent Siteminderagenten är installerad på den lokala webbservern och kontaktar policyserver för kontroll av autenticering och auktorisation. 12 (12)