IT2: Informationssäkerhet

|| Förutsättningar att uppfylla || Uppfyllnad || || Verksamhetskritiskt IT-stöd designas för att möta verksamhetens krav på tillgänglighet vid frånfall av ett externt beroende. Ju fler beroenden till andra komponenters tillgänglighet, desto lägre egen tillgänglighet. || Axel är infrastrukturellt en självständig instans vars tillgänglighet inte är beroende av andra komponenter för att vara tillgänglig. Däremot ligger det i Axels design som meddelandetjänst att Nationella tjänsteplattformen (NTJP) och extern aktör behöver vara tillgängliga för att skicka eller ta emot synkrona meddelanden via SHS eller SSEK(eftersom meddelandet annars inte har någon som skickar eller tar emot). || || Verksamhetskritiska nationella stödtjänster (t.ex. tillgång till behörighetsstyrande information) erbjuder möjlighet till lokala instanser som med tillräcklig aktualitet hålls uppdaterade med nationell master. || Axel bygger på open source som vem som helst kan ladda ner, men inga lokala installationer är planerade eller supportas. I Intygstjänsters infrastruktur ligger Axel som en central nationell tjänst för kommunikation jämsides med NTJP. || || Krav mellan integrerande parter regleras genom integrationsavtal. Integrationsavtal är det avtal där informationsägaren godkänner att en ett visst system får agera mot information genom ett visst tjänstekontrakt. Exempelvis skall enligt integrationsprocessen för den nationella tjänsteplattformen ett avtalsnummer för ett integrationsavtal registreras i samband med att man "öppnar dörren" för en viss tjänstekonsument mot en viss kombination av informationsägare och tjänstekontrakt. || Axel ligger inom samma miljö som NTJP ligger på, så ett avtal där är inte aktuellt. Vad gäller externa aktörer för SHS och SSEK så kommer avtal slutas med varje ny sådan vid anslutning. || || Arkitekturen måste möjliggöra tillräcklig tillgänglighet vid flera samverkande system. || Redundant infrastruktur är nödvändig för Axel eftersom många tjänster beror av noden. Detta behöver säkerställas genom en väl avvägd infrastrukturdesign för aktuell driftspunkt. || || En sammantagen tolkning av tillämpliga lagar och förordningars konsekvenser för teknisk realisering av informationsfångst, utbyte och lagring. || Axel följer samma principer som NTJP. SSL-anslutning med certifikat mot externa parter. Felaktig data samt asynkrona meddelanden lagras endast tillfälligt. I det administrativa gränssnittet kan endast loggar med ID för meddelanden ses, själva bodyn ges inte åtkomst till. || || Förutsättningar för spårbarhet etableras i form av loggningsregler för komponenter som deltar i säkert informationsutbyte. || Tjänstekonsument och tjänsteproducent ansvarar för att följa de krav som finns på spårbarhet. Axel vidareförmedlar endast meddelanden och för logg över transaktioner för administration. || || Interoperabla, internationellt beprövade och för leverantörer tillgängliga standarder tillämpas för kommunikation mellan parter som har upprättat tillit. || Kommunikation med NTJP följer nationella tjänstekontrakt. Kommunikation externt sker enligt SHS specifikation 1.2 (för vilken Axel har certifierats av Försäkringskassan). SSEK-kommunikationen är uppbyggd på liknande sätt som SHS och som första extern aktör tillkommer Skandia, vilka förvaltar specifikationerna för SSEK. ||

IT3: Nationell funktionell skalbarhet

|| Förutsättningar att uppfylla || Uppfyllnad || || Nationella tjänstekontrakt definieras med nationell täckning som funktionell omfattning. Det är möjligt för ett centraliserat verksamhetssystem som användas av alla verksamheter i Sverige att realisera varje standardiserat tjänstekontrakt. Det får inte finnas underförstådda funktionella avgränsningar till regioner, kommuner, landsting eller andra organisatoriska avgränsningar i nationella tjänstekontrakt. |||| Axel vidareförmedlar meddelanden enligt definierade standarder. Själva noden är skalbar så tillvida att fler aktörer både internt eller externt kan anslutas samt att ett ökat antal meddelanden inom överskådlig framtid kan hanteras. || || SLA ska definieras för varje tjänstekontrakt. Detta SLA ska ta hänsyn till framtida kapacitet för tjänstekontraktet med avseende på transaktionsvolym, variationer i användningsmönster och krav på tillgänglighet, i kombination med förmåga till kontinuerlig förändring. || Ja, SLA ska finnas definierat vid Axels drift. || || Integration ska ske över en integrationsinfrastruktur (t.ex. virtualiseringsplattform) som möjliggör uppföljning av tjänsteproducenters fullföljande av SLA. || Axel är just en sådan integrationsinfrastrukturkomponent i sig själv. || || System och e-tjänster som upphandlas kan utökas med fler organisationer som kunder utan krav på infrastrukturella ingrepp (jämför s.k. SaaS) || System och e-tjänster kan utökas och utnyttja Axel genom NTJP. Det skulle kunna vara aktuellt med vissa infrastrukturella ingrepp i form av t ex routingregler om det beslutas att ansluta en extern aktör som använder en helt ny webservice/standard eller liknande. ||

IT4: Lös koppling

|| Förutsättningar att uppfylla || Uppfyllnad || || Meddelandeutbyte baseras på att kommunikation etableras utgående från vem som äger informationen som ska konsumeras eller berikas, inte vilket system, plattform, datalager eller tekniskt gränssnitt som informationsägaren för stunden använder för att hantera informationen. Genom centralt administrerad förmedlingstjänst skapas lös koppling mellan informationskonsument och informationsägarens tekniska lösning. || Axel är tänkt att underlätta just ett sådant meddelandeutbyte. Routing sker från avsändare till mottagare och innehållet i meddelandet som vidareförmedlas är egalt. Axel breddar NTJP:s informationsutbyte genom att lägga till fler standarder och är liksom NTJP en centralt administrerad förmedlingstjänst. || || En arkitektur som skapar lös koppling mellan konsumenter och producenter, avseende adressering och standarder för kommunikation. || T-boken och RIV-TA 2.1 tillämpas genom att all kommunikation sker via NTJP. || || En nationell integrationspunkt ska kunna erbjudas för varje nationellt standardiserat tjänstekontrakt, som en fasad mot bakomliggande brokiga systemlandskap. || NTJP och Axel erbjuder tillsammans en integrationspunkt för standardiserade tjänstekontrakt, vare sig man kommer från vård, myndigheter eller bank/finans. || || Nationella tjänstekontrakt förvaltas i en nationellt koordinerad förvaltning. || Detta projekt har inte ansvarat för att specificera tjänstekontrakten. Tjänstekontrakten är kravdokument för detta projekts implementation av komponenterna för meddelandeserver. || || För en process inom vård och omsorg kan flera tjänstekontrakt ingå. Därför är det viktigt att alla tjänstekontrakt baseras på en gemensam referensmodell för informationsstruktur. || Detta projekt har inte ansvarat för att specificera tjänstekontrakten. Tjänstekontrakten är kravdokument för detta projekts implementation av komponenterna för meddelandeserver. || || Parter som samverkar i enlighet med arkitekturen integrerar med system hos parter som lyder under annan styrning (t.ex. myndigheter, kunder och leverantörer). Det kan leda till att vård- och omsorgsgivare antingen:• Nationellt bryggar informationen (semantisk översättning) eller• Nationellt införlivar externt förvaltat tjänstekontrakt som standard Observera att semantisk bryggning av information till vårdens referensmodell förutsätter en nationell förvaltning av bryggningstjänster. För att införliva ett externt förvaltat tjänstekontrakt förutsätts en transparent, robust och uthållig tjänstekontraktsförvaltning hos den externa parten. || Samverkan med externa parter genom Axel följer nationella standarder. Själva uppbyggnaden av XML-meddelanden varken bestäms eller valideras i Axel, endast vidareförmedlas. || || Befintliga system behöver anpassas till nationella tjänstekontrakt. Detta kan göras av leverantörer direkt i produkten, eller genom fristående integrationskomponenter (”anslutningar”). En anslutning bör ligga nära (logiskt vara en del av) det system som ansluts, oavsett om det är i rollen som konsument eller producent för anslutningen som genomförs. || Man kan utgå ifrån att nya tjänster anpassas till detta, men det är inget som Axel behöver ta hänsyn till som meddelandetjäst. || || Interoperabla standarder för meddelandeutbyte tillämpas, så att integration med till exempel en Web Service kan utföras utan att anropande system behöver tillföras en för tjänsteproducenten specialskriven integrationsmodul (s.k. agent). || Axel har genomgått interoperabilitetstester mot Försäkringskassan och certifierats. Endast interoperabla standarder används. ||

IT5: Lokalt driven e-tjänsteförsörjning

|| Förutsättningar att uppfylla || Uppfyllnad || || När utveckling av källkod är en del av en tjänsteleverans skall följande beaktas:• Alla leveranser tillgängliggörs under öppen källkodslicens. Valet av licensformer samordnas nationellt genom rekommendationer.• Utvecklingen bedrivs från start i en allmänt tillgänglig (över öppna nätverk) projektinfrastruktur där förvaltningsorganisation kan förändras över tiden inom ramen för en kontinuerligt tillgänglig projektinfrastruktur (analogi: ”Projektplatsen för e-tjänsteutveckling”). • Det innebär full insyn och åtkomst för utvecklare till källkod, versionshantering, ärendehantering, stödforum och andra element i en projektinfrastruktur under projektets och förvaltningens hela livscykel.• Upphandlade e-tjänster fungerar på de vanligaste plattformarna hos vårdgivarna och hos nationella driftspartners (Windows, Linux, Unix) t.ex. genom att vara byggda för att exekvera på en s.k. Java virtuell maskin.• Gemensam referensmodell för e-tjänsters interna uppbyggnad stimulerar och förenklar återanvändning och överföring av förvaltningsansvar mellan organisationer. || Denna lösning är öppen källkod och publicerad på Google Code enligt RIVTA-riktlinjer för detta. Utvecklingen har bedrivits på Google Code från start, med möjlighet till full insyn. https://code.google.com/p/inera-axel/ || || Minsta möjliga – men tillräcklig – mängd standarder och stödjande gemensamma grundbultar för nationella e-tjänstekanaler säkerställer att även utvecklingsenheter i mindre organisationer kan bidra med e-tjänster för en integrerad användarupplevelse och att en gemensam back-office för anslutning av huvudmän till e-tjänster finns etablerad. I den mån etablerade standarder med bred tillämpning i kommersiella e-tjänster finns (t.ex. för single-sign-on), bör de användas i syfte att möjliggöra upphandling av hyllprodukter. || Axel är inte en e-tjänst. || || Utveckling sker mot globalt dominerande portabilitetsstandarder i de fall mellanvara (applikationsservrar) tillämpas. Det är möjliggöraren för nyttjande av free-ware och lågkostnadsverktyg i organisationer som inte orkar bära tunga licenskostnader för komplexa utvecklingsverktyg och driftsplattformar. || Axel är i första hand utvecklat och designat utifrån en OSGi-miljö med Apache Karaf, såsom t.ex. Apache ServiceMix, RedHat JBoss Fuse,Talend ESB etc, så för att få maximal nytta av de komponenter och integrationspriniciper vi utgått ifrån så rekommenderas en sådan miljö. Vissa komponenter (SHS, RIV/SHS-brygga) är också färdigpaketerade i WAR-filer som ska vara färdiga att deploya i Apache Tomcat eller någon annan liknande applikationsserver. Själva Axel kan köras i någon Java applikationsserver/container av följande slag: • Apache Karaf - v2.3.3 • Apache Tomcat - v6.0.37 eller senare. Observera att vi bara testat med dessa varianter. Självklart borde det fungera i andra kompatibla containers. || || Nationell (eller regional – beroende på sammanhang vård/omsorg) förvaltning är etablerad (t.ex. s.k. Portal Governance), med effektiva processer för att införliva lokalt utvecklade e-tjänster i nationella e-tjänstekanaler. Systematisk och effektiv allokering av resurser för drift är en viktig grundförutsättning. || Axel är inte en e-tjänst. || || Genom lokal governance och tillämpning av det nationella regelverket får lokala projekt den stöttning som behövs för att från början bygga in förutsättningar för integration i samordnade (t.ex. nationella) e-tjänstekanaler. || Axel är inte en e-tjänst. ||

IT6: Samverkan i federation

|| Förutsättningar att uppfylla || Uppfyllnad || || Att gemensamma gränssnitt i alla federativa utbyten finns framtagna och beskrivna, vilket möjliggör kostnadseffektiva och leverantörsneutrala lösningar. || RIV-TA, SHS- och SSEK-standarder tillämpas. || || Det behövs organ och processer för att godkänna utgivare av elektroniska identitetsintyg och certifikat som är giltiga i federationen. || SITHS HCC certifikat används i enlighet med T-boken och RIV-TA2.1. Sterias servercertifikat CA2 används för kommunikation externt. || || Aktörer i olika nät, inklusive öppna nät ska vara välkomna i elektronisk samverkan genom att samverkande komponenter är säkra. || Kommunikation sker via nationell tjänsteplattform till/från Sjunet. || || Att Ingående parter i federationen är överens om ett antal gemensamma ståndpunkter: • att stark autentisering likställs med 2-faktors autentisering • att vid samverkan acceptera följande metoder för stark autentisering; eID, PKI med lagring av nyckelpar på SmartCard eller motsvarande och metoder baserade på engångslösenord, antingen genererade i en fysisk enhet eller säkert distribuerad till fysisk enhet • att tillämpa en gemensam certifikat- och utfärdarpolicy, likvärdig med SITHS, som ett minimikrav för egen eller annans PKI • att sträva mot en autentiseringslösning, framför flera olika, för att realisera stark autentisering i den egna organisationen och i federation • att enbart acceptera SAMLv2, eller senare version, vid identitetsfederering samt tydliggöra att det i förekommande fall är det enda sättet att logga in och säkerställa det inte finns någon bakväg in • att tillämpa ett gemensamt ramverk för att ingå i en federation • att tillämpa en gemensam katalogpolicy, med utgångspunkt från HSA policy, som ett minimikrav för egna kataloger • att stäva mot att all gränsöverskridande kommunikation skall vara möjlig både över Sjunet och Internet. Det är den egna organisationen som beslutar vilken tillgänglighet som är tillräcklig för anslutningen • att sträva efter att möjliggöra kontroll av trafik till och från den egna infrastrukturen i en eller få kontrollpunkter • att utgå från att kommunikation över Internet och Sjunet har ett likvärdigt skyddsbehov || Axel erbjuder inte ett användargränssnitt och har därför heller inget behov av att identifiera användare i en SSO-federation. ||