Bilag 2: Løsningsbeskrivelse. Opgaven vil bestå af at varetage drift af den samlede NemLog-in-løsning.

Transkript

1 Bilag 2: Løsningsbeskrivelse Opgaven vil bestå af at varetage drift af den samlede NemLog-in-løsning. Den nuværende NemLog-in-løsning består af en række forskellige funktionelle komponenter, der indgår i de forskellige applikationer i NemLog-in. En række af komponenterne udgøres af fælles infrastrukturkomponenter til logning, caching, udsendelse af mails mv. Komponenterne er generelt løstkoblede med veldefinerede snitflader imellem, hvilket giver en fleksibel arkitektur. Historisk har dette givet god mulighed for at videreudvikle NemLog-in i løsningens levetid med ny funktionalitet. Nedenstående figur viser et overblik over de forskellige komponenter: Users IT systems Internet Connection Support System (CSS) User Administration System (FBRS) NemLog-in Delegation system Signing Administration Portal Administration Portal NemLog-in Web SSO Delegation Portal Signing Page Health status Enrollment Portal Attribute Service Attribute Query Query web Signing web Provisioning Services Legal Unit web Security Token Service Metadata s Common components Application logging Data cache Mail dispatcher Figur 1: Komponenter i NemLog-in (funktionelt syn) Logisk er infrastrukturen opdelt i en række netværkszoner bestående af Internet zone, DMZ, Applikationszone og Data-zone (back-end). Dette giver mulighed for en traditionel perimeterbeskyttelse ved brug af firewalls og netværkssegmentering efter defense-in-depth princippet. Zone-opdelingen er illustreret på nedenstående figur:

2 Figur 2: Zoneopdeling i infrastrukturen Kernen i NemLog-in er bygget på Windows teknologi, herunder Windows Server, SQL Server og AD FS 2.0 som illustreret nedenfor:

3 Som figuren viser, er der bygget en custom Identity Provider som en web applikation, der håndterer integrationen med NemID (herunder implementering af TU pakkerne). Custom IdP en udsteder efter autentifikation af brugeren tokens til AD FS, som herefter håndterer sessionsstyring med brugerens browser, udstedelse af tokens til tjenester samt logout. Dermed er al integration med den nuværende NemID-løsning isoleret i sit eget modul, hvilket må forventes at lette overgangen til den kommende nationale digitale identitets- og signaturløsning (NDIS, næste generation NemID) betydeligt, idet man blot kan tilføje nye IdP-moduler. AD FS installationen er af sikkerhedsmæssige grunde delt i en proxy i DMZ samt en back-end server i applikationszonen, således at angrebsfladen mod internettet begrænses mest muligt. Back-enden benytter af sikkerhedsmæssige årsager Hardware Security Modules (HSM) fra Thales til at beskytte private signeringsnøgler, herunder nøglen som signerer SAML tokens. Der er bygget en række kundespecifikke moduler til at supplere funktionalitet i AD FS eller omgå begrænsninger. Dette drejer sig om moduler til throttling, SOAP logout, logning mv. Eksempelvis kan ADFS ud af boksen ikke understøtte logningskravene i NemLog-in.

4 Infrastruktur Infrastrukturen i NemLog-in er opbygget omkring en række strenge/ siloer, hvor hver silo er en trio bestående af en front-end server placeret i DMZ, en back-end server i applikationszonen samt en databaseserver i datazonen, der er låst sammen i én enhed. På den måde sker al loadbalancering mellem front-end serverne, så en brugertransaktion behandles fuldt ud inden for en silo. Denne opbygning giver både en simpel infrastruktur i forhold til load-balancering og tilvejebringer samtidig mulighed for opskalering af infrastrukturen i perioder med spidsbelastninger. Historisk har det således været det såkaldte marts peak, hvor SKAT åbner for adgang til borgernes årsopgørelser, der har givet den største belastning af systemet. I disse perioder indkobles efter behov et antal ekstra siloer baseret på virtuelle servere, mens de normale siloer, der står for daglig drift, udgøres af fysiske servere. Belastningstest har vist, at denne opskalering giver en næsten lineær forøgelse af kapaciteten med antallet af siloer, hvilket er ganske fint, og produktionsmiljøet har da også i praksis kørt fuldt tilfredsstillende i perioderne med spidsbelastning. Miljøer Ovenstående diagrammer illustrerer produktionsmiljøet. Der er herudover kravsat to andre miljøer med betydeligt lavere kapacitetsbehov:

5 Et staging miljø, der funktionelt og sikkerhedsmæssigt ækvivalent til produktion, men som kapacitetsmæssigt er nedskaleret. Et integrationstestmiljø som anvendes af tjenesterne i forbindelse med tilslutning. Kapacitet og sikkerhed NemLog-in betragtes som samfundskritisk infrastruktur og er generelt dimensioneret efter dette, idet løsningen er single point of failure for en lang række offentlige selvbetjeningsløsninger (>300). Løsningen er derfor bygget med to-center drift, redundante internetforbindelser, spejling, clustering, fail-over osv. For produktionsmiljøet er de vigtigste mål: Oppetid: 99,9 % på hverdage. Svartider på mindre end to sekunder i 90 % af tilfældene for de fleste brugertransaktioner. Håndtering af logins per time. Spidsbelastning på 170 transaktioner per sekund. I forbindelse med SKAT s årlige udsendelse af årsopgørelser i marts måned (det såkaldte marts peak), er der hård belastning af løsningen med typisk mere end 1 mio. log-ins om dagen. NemLog-in s kritikalitet for selvbetjeningsløsninger gælder både for egenskaben tilgængelighed, da ingen brugere får adgang uden NemLog-in s medvirken, men også konfidentialitet og integritet, idet en kompromittering af NemLog-in kan føre til kompromittering af data i de tilsluttede tjenester. Løsningen drives derfor med høje sikkerhedskrav i forhold til kryptering, firewalls, overvågning, IDS/IPS, beskyttelse mod Denial of Service angreb, løbende sårbarhedsscanninger og penetrations mv. Den mest følsomme del af løsningen udgøres af de private signeringsnøgler, der underskriver SAML Assertions, der giver adgang til andre tjenester. Disse beskyttes i kryptografiske hardwaremoduler (HSM er) som overholder FIPS level 3 standarden suppleret med strenge procedurer omkring nøglehåndteringen. Opsummering på nuværende arkitektur Samlet vurderes den nuværende arkitektur som et godt grundlag for organisk at kunne videreudvikle løsningen til fremtidige behov. Den nuværende arkitektur er forholdsvis veldesignet i form af velafgrænsede og løstkoblede komponenter. Samtidig har infrastrukturen i praksis vist sig som robust, fejltolerant og skalérbar, således at fremtidige behov for øget kapacitet i form af flere brugertransaktioner ikke forventes at give nogen nævneværdige udfordringer. De største potentielle udfordringer vurderes at ligge i brugen af AD FS 2.0 produktet fra Microsoft. Der er her tale om et standardprodukt med lukket kodebase, der i praksis har givet en række problemer og behov for ændringer i løsningens levetid (fx i forbindelse med logning). Således er AD FS s rolle i løsningen blevet mindre og mindre over tid, fordi det i flere situationer har været nemmere at arbejde uden om løsningen end at tilpasse løsningen. Samtidig er den langsigtede strategi for produktet tvivlsom, idet AD FS 3.0 umiddelbart vurderes at være ufleksibelt for tilpasninger, og da

6 kernefunktionaliteten er skabt til andre scenarier (Enterprise brug) end til NemLog-in. Man kan således i værste fald risikere, at nogle ønsker til et fremtidigt NemLog-in kan blive vanskelige at honorere, og i givet fald må man overveje en (evt. gradvis) udskiftning af produktet. På nuværende stadie er der dog ikke noget som tilsiger, at en sådan udskiftning er nødvendig inden for de næste par år, og samlet vurderes der ikke at være væsentlige argumenter for at forkaste en i dag velfungerende løsning og starte forfra med etablering af en ny løsning fra bunden. Væsentlige nye behov som integration med den kommende NDIS-løsning og introduktion af finkornede rettigheder i FBRS og fuldmagt vurderes eksempelvis at kunne håndteres med den nuværende AD FS løsning. En eventuel udskiftning af AD FS vil i givet fald blive udført af udviklingsleverandøren.

7 Forretningsbehov Kunden forestiller sig umiddelbart nærværende behovsopgørelse for kontrakten: Nr. Behov Uddybning 1 Stabil drift NemLog-in er en samfundskritisk infrastrukturløsning, som er single point of failure for borgeres og virksomheders adgang til offentlige løsninger. Det er derfor afgørende, at der sikres en stabil drift og meget høj tilgængelighed, da fejl, nedetid og ustabilitet rammer alle offentlige tjenester på en gang. 2 Skalering Der sker en stadig stigende digitalisering af samfundet, hvor nye løsninger løbende udvikles og tilsluttes NemLog-in, og hvor trafikken på eksisterende løsninger støt vokser. Det er afgørende, at NemLog-in kan skaleres til fremtidens behov og ikke kommer til at udgøre en flaskehals for digitaliseringen. 3 Sikkerhed NemLog-in er en kritisk sikkerhedsløsning, der giver adgang til store mængder følsomme data i andre offentlige, digitale løsninger. En kompromittering af løsningen vil derfor kunne få fatale konsekvenser både for datasubjekterne samt tilliden til digitaliseringen i det hele taget. Det er derfor helt centralt, at sikkerheden i NemLog-in er state-of-the-art, og at der til stadighed og proaktivt følges op på sikkerhedsniveauet. 4 Videreudvikling NemLog-in skal videreudvikles med en række funktioner, der understøtter den videre digitalisering af samfundet. Det er derfor afgørende, at test- og driftsmiljøer smidigt understøtter deployment af nye releases, og at samarbejde mellem drifts- og udviklingsleverandører kan fungere smidigt og effektivt. 5 Migrering Det er et meget stort antal tjenester (>300) tilknyttet den eksisterende NemLog-in løsning, og det er centralt at kunne sikre en så smertefri transition som muligt til den nye løsning - både i et tjenesteudbyder- og slutbrugerperspektiv. 6 Compliance En række reguleringstiltag er på vej (herunder persondataforordning og eidas-forordning fra EU). Det

8 er derfor afgørende, at en ny driftsplatform bygges, så den understøtter overholdelse af de relevante krav fx i forhold til dokumentation, procesmodenhed, sikkerhed, logning, overvågning og afrapportering osv.