Sähköisen asioinnin arkkitehtuuri

Transkriptio

1 Sähköisen asioinnin arkkitehtuuri Kuvaus sovellustoimittajille v

2 KUVAUS 2/16 Sisällysluettelo 1 Johdanto... 4 Dokumentin tarkoitus ja kohderyhmä... 4 Tekninen kehikko: Ylätason kuvaus... 4 Kehikon looginen rakenne Kehikon tekninen rakenne... 4 Kehikon teknologiapino... 4 Suositellut teknologiat... 5 Käyttöliittymä Yleistä Käyttöliittymä Kehikon viitekehys Asiointipalveluiden ulkoasu Käyttöliittymän tietoturva... 6 Mikropalveluarkkitehtuuri Yleistä Kehikon viitekehys Palvelukomponentit-Uudelleen käytettävät palvelut... 7 Tunnistautuminen Ulkoverkko... 8 Kielen valinta...10 API Gateway Asiointipalveluiden toimitusmalli Paketointi Container Image Jakelu Konttirekisteri Tietoturva Yleiset käytännöt ModSecurity-sovelluspalomuuri Dokumentaatiot Järjestelmäratkaisut Järjestelmärakenne...13 Ympäristöt Palvelimet (Kehikon toteuttavat) Käyttöjärjestelmät (Kehikon toteuttavat) Kehikon omat sovellukset Kehikkoon liittyvät muut OM sovellukset Kehikkoon liittyvät ulkoiset sovellukset... 14

3 KUVAUS 3/ Operatiiviset sovellukset Varusohjelmistot, joita tämä järjestelmä tarvitsee Integraatioratkaisut Sisäiset liittymät (sisäverkossa) Järjestelmän turvaaminen...16 Tietojen luokittelu ja turvaaminen...16 Teknisen alustan ja ympäristön turvallisuusvaatimukset...16 Lisätiedot...16 Asiakirjan tiedot Projekti: Sähköisen asioinnin arkkitehtuuri Laatija: Versio: 0.1 Otsikko: Kuvaus sovellustoimittajille Päiväys: Katselmoija: Katselmoinnin päiväys: Toimenpiteet * Päiväys Toimenpide Suorittaja * Toimenpiteitä: hyväksyntä, katselmointi, tiedoksianto, päätös, kokous, muu (mikä) Versiohistoria Versio Päiväys Muokkaaja Kuvaus Tiedosto MLe Koostettu suunnittelumateriaaleista SA-arkkitehtuuri.docx

4 KUVAUS 4/16 1 JOHDANTO Dokumentin tarkoitus ja kohderyhmä Ylätason tavoitteena on luoda sekä ylläpitää OM:n sähköisen asioinnin teknistä kehikkoa. Kehikko on osa sähköisen asioinnin teknistä ohjausmallia, jolla eri IT-toimittajia ohjeistetaan toimimaan OM:n ympäristössä valittujen arkkitehtuurimallien sekä teknisten ratkaisuiden puitteissa. Kehikko antaa puitteet ja ohjeistukset miten toimia. OM:n kokonaisarkkitehtuuri linjaukset ja reunaehdot ohjaavat kehikon raameja. Kehikkoa sekä ohjausmallia kehitetään tarpeen mukaan OM:n organisaation tietohallinnon ja sidosryhmien avulla. Tekninen kehikko: Ylätason kuvaus Ylätason tavoitteena on luoda sekä ylläpitää OM:n sähköisen asioinnin teknistä kehikkoa. Kehikko on osa sähköisen asioinnin teknistä ohjausmallia, jolla eri IT-toimittajia ohjeistetaan toimimaan OM ympäristössä valittujen arkkitehtuurimallien sekä teknisten ratkaisuiden puitteissa. Kehikko antaa puitteet ja ohjeistukset miten toimia. OM:n kokonaisarkkitehtuuri linjaukset ja reunaehdot ohjaavat kehikon raameja. Kehikkoa sekä ohjausmallia kehitetään tarpeen mukaan OM:n organisaation tietohallinnon ja sidosryhmien avulla. Kehikon arkkitehtuuri perustuu mikropalvelumalliin hyödyntäen mikroarkkitehtuuriin liittyvillä teknologisilla osilla. Kehikon looginen rakenne 2 KEHIKON TEKNINEN RAKENNE Kehikon teknologiapino Komponentti Käyttötarkoitus Selite RHEL 7.x Käyttöjärjestelmä K&K-ympäristössä käytössä muutenkin Docker / Docker compose Konttipohjainen kokoonpanon ja toimitusten hallinta Toimitusten / asennusten yksinkertaistaminen Yhteisten komponenttien jakelu eri sovellustoimittajille De facto standardi ModSecurity + Apache/Nginx Sovelluspalomuuri Käytössä asiointi.oikeus.fi-portaalissa Laajasti käytössä Ajoalusta Apache vs. Nginx riippuu muista valinnoista

5 KUVAUS 5/16 F5 Load Balancer Kuormanjakaja, TLS-termination Käytössä K&K-ympäristössä JJWT JSON Web Token -kirjasto Toteuttaa standardin RFC 7519 Spring FrameWork (Tomcat) HashiCorp Consul Palveluosuuden sovelluskehys / sovelluspalvelin (API Gateway, sovelluksen mikropalvelut, kirjautuminen) Palvelurekisteri, konfiguraationhallinta Mikropalveluihin hyvin soveltuva, erittäin käytetty. MongoDB Asiointipalvelun tilapäistietovarasto Jos käyttötarkoitus vaatii dokumenttitietokantaa MySQL Asiointipalvelun tilapäistietovarasto Jos käyttötarkoitus vaatii relaatiotietokantaa Redis Asiointipalvelun tilapäistietovarasto / välimuisti Välimuisti, key-value store, muu suorituskykyoptimointi Angular (2+) Angular Material (Google Material Design) Käyttöliittymäosuuden sovellusviitekehys Käyttöliittymäosuuden komponenttikirjasto / standardi Ks. erillinen kuvaus (Google) Ks. erillinen kuvaus (Google) Suositellut teknologiat Komponetti / teknologia Selite Huomiot

6 KUVAUS 6/ Yleistä Käyttöliittymä OM:n pilottihankeen käyttöliittymätoteutukseen suositellaan SPA (single page application) -tyylistä ratkaisua. SPA -ratkaisussa ajatuksena on se, että sovelluksen tieto tarjotaan yhdeltä sivulta, mutta sivun sisältöä päivitetään käyttäjän toimenpiteiden perusteella. Tällaisen ratkaisun hyötynä on se, ettei sivun liittyviä yleisiä resursseja tarvitse hakea uudestaan. Tämä myös vähentää palvelupyyntöjen määrä edustapalvelimille. Lisäksi selaimen koko sivua ei pidä rendata uudestaan käyttäjän selaimessa vaan voidaan päivittää ainoastaan tarvittavaa osaa käyttöliittymästä Käyttöliittymä Kehikon viitekehys Vaikka käyttöliittymän javascript viitekehysten vaihtelu on ollut nopea viime aikoina, niin silti isojen yritysten tukemat viitekehykset ovat pysyneet suosiossa. Tällä hetkellä Facebookin tukema ReactJS -viitekehys ja Googlen tukema AngularJS -viitekehys ovat olleen yleisimmät käytössä olevat ratkaisut. Molemmat tarjoavat hyvin samanlaisen komponenttimaisen lähestymistavan käyttöliittymän rakentamiseen. Lisäksi ratkaisut ovat hyvin tuettuja laajoilla yhteisöillä ja ei näytä siltä, että nämä teknologiat vanhentuvat lähiaikana Asiointipalveluiden ulkoasu Asiointisovelluksille jaetaan graafisesta ilmeestä seuraavat: Lyhyt kuvaus käytännöistä, suosituksista Material Design standardiin perustuva CSS-paketti Malli-HTML:t muutamasta perusnäytöstä Käyttöliittymän tietoturva Käyttöliittymän pitää ehdottomasti salata HTTPS -protokollan avulla, jotta saadaan suojattua liikenne selaimen ja palvelimen välillä. Lisäksi suositellaan siirtämään autentikointitietoa JWT (JSON Web Token) headerissa, joka tavallisesti sisältää käyttäjän tiedot, roolit ja mahdollisesti session vanhentumisajan. JWT on kuvattu RFC 7519 asiakirjassa. JWT -tieto on allekirjoitettu, jolloin voidaan todeta, että vastaus on tullut muuttamattomana palvelimelta.

7 KUVAUS 7/16 Mikropalveluarkkitehtuuri Yleistä OM:n sähköisen asiointipalveluiden toteutukseen käytetään mikropalvelu arkkitehtuurimallia. Mikropalveluratkaisussa periaatteena on, että jokainen kokonaisuuteen kuuluva palvelu toteutetaan itsenäisenä, toisista riippumattomana palvelunaan. Tästä on kaksi selkeää hyötyä esitellyssä ratkaisussa. Ensinnäkin koska kyseessä on monitoimittajaratkaisu, niin näin eri toimittajat voivat toteuttaa omia osuuksiaan mahdollisimman paljon toisistaan riippumatta. Toisekseen erillisten osuuksien toimitus ja käyttöönotto helpottuvat, koska mikropalvelun riippumattomuuteen kuuluu myös mahdollisuus asentaa palveluita ilman vaikutusta muihin palveluihin. Huomattava on kuitenkin myös se, että vaikka kokonaisuus muodostaa mikropalveluarkkitehtuurin, voivat yksittäiset asiointipalvelut koostua vapaasta määrästä palveluita, eli olla itsessään joko monoliitteja tai mikropalveluarkkitehtuureita Kehikon viitekehys Koska mikropalveluarkkitehtuuri on enemmän lähtökohta ratkaisun suunnittelulle kuin tiukasti määritelty standardi, niin ratkaisuun ei ole olemassa vain yhtä viitekehystä. Myös mikropalveluiden riippumattomuus tarkoittaa sitä, että yksittäisten palveluiden teknologioita ei ole tarpeettomasti syytä rajata Sovelluskehys Kehykseksi suositellaan käytettäväksi Spring FrameWork pohjaisia ratkaisuja Ajoalusta Palveluiden toimittamiseen ja ajoalustaksi suositellaan Docker Palvelurekisteri Suositellaan käytettäväksi HashiCorp Consul. mm. selkeät liittymät (DNS, REST/JSON). 3 PALVELUKOMPONENTIT-UUDELLEEN KÄYTETTÄVÄT PALVELUT Palvelukomponentit osiossa on listattu eri palvelukomponentit Palvelun nimi Kuvaus Uudelleenkäytettävä Osa-alue palvelu Tunnistautuminen Tunnistetaan ulkoverkon kautta tulevat Kyllä Perustoiminnallisuus (Vahva) asiointi verkkopalvelun käyttäjät.

8 KUVAUS 8/16 Tunnistautuminen Ulkoverkko Tunnistautuminen toteutetaan vasten suomi.fi-identiteettipalvelua. Tunnistautuminen tarjotaan omana palvelunaan, jota asiointisovellukset eivät tosin suoraan käytä. Asiointisovelluksille annetaan oma URL-avaruus, joita se voi käyttää. Tämä jaetaan vielä kahteen osaan, julkiseen ja kirjautumista vaativaan. Tunnistautumispalvelu huolehtii, jos sovellus tekee kirjautumista vaativan kutsun, niin kutsu menee perille vain jos käyttäjällä on voimassa oleva tunnistautuminen (JWT-token). Jos tunnistautuminen puuttuu tai on virheellinen, niin tunnistautumispalvelu palauttaa virheen asiointisovellukselle, ja asiointisovelluksen tehtävä on ohjata käyttäjän selain tunnistautumispalvelun tarjoamaan osoitteeseen. Tämän jälkeen tunnistautumispalvelu tekee tunnistautumisen suomi.fi-palvelun kanssa ja onnistuneessa tapauksessa luo uuden JWT-tokenin asiointisovellukselle/käyttäjälle. Asiointisovellus lähettää tästä eteenpäin JWT-tokenin API-kutsuissaan HTTP-headerina.

9 KUVAUS 9/ Kirjautuminen-kuvaus sd Kirjautuminen 1.1: API-kutsu() API Gateway 1.2: JWT fail() SPA-sovellus 1.11: API-kutsu 2() 1.12: API-vastaus() 1.3: Siirry kirjautumiseen() 1: Avataan näyttö X() 1.10: Avataan näyttö X 2() 1.4: Siirry kirjautumiseen() Selain 1.5: Kirjautuminen redirect() 1.8: Kirjauduttu() 1.9: Uusi JWT redirect() Kirjautuminen UI 1.6: Kirjaudu() 1.7: Kirjautuminen ok redirect() suomi.fi kirjautuminen Käyttäjä

10 KUVAUS 10/16 Kielen valinta Asiointisovellus toteuttaa omaan käyttöliittymäänsä, sovittuun paikkaan, käyttöliittymäkielen valinnan. Asiointisovellus tallentaa kielisyystiedon evästeeseen / cookieen, joka on merkitty koko asiointi.oikeus.fidomainille, ja tätä kautta kielisyystieto välittyy myös muille asiointisovelluksille. Lisäksi asiointisovellus lähettää kielisyystiedon API-kutsuissa HTTP-headerina. API Gateway API Gateway on yhteinen piste, jota kautta kaikki asiointisovellusten API-kutsut tehdään. Jos kyseessä on tunnistautumista vaativa kutsu, niin Gateway tarkistaa ensin, että kutsussa on mukana voimassa oleva JWTtoken. Tämän jälkeen Gateway ohjaa kutsun oikeaan palveluun, yhteiseen tai yksittäisen asiointisovelluksen palveluun. Lisäksi Gateway tekee lokikirjaukset kaikista kutsuista ja vastauksista. Palvelu Url 4 ASIOINTIPALVELUIDEN TOIMITUSMALLI OM:n ympäristössä on käytössä konttipohjainen malli eli Service Instance per Container Pattern.

11 KUVAUS 11/16 Paketointi Container Image

12 KUVAUS 12/16 Jakelu Konttirekisteri Tietoturva Tietoliikenteen salaus HTTPS-protokollalla puretaan kuormantasaajalla, jonka jälkeen käytetään httpprotokollaa. Vastaavaa ratkaisua on käytetty myös nykyisessä Oikeusministeriön asiointiportaalissa. Palveluiden autentikaatioon käytetään JSON Web Token standardilla. Kaikki palvelukutsut kulkevat yhden pisteen, API Gateway:n, kautta, joka tarkistaa onko kutsujalla voimassa oleva ja onnistunut istunto olemassa. Jos istuntoa ei ole, ohjataan asiointisovellus yhteiseen kirjautumispalveluun, joka on toteutettu omana mikropalvelunaan Yleiset käytännöt Tunniste OWASP TOP 10 Kommentti Käytännöt mod_security Katso mikropalveluarkkitehtuuri-kohta

13 KUVAUS 13/ ModSecurity-sovelluspalomuuri ModSecurity-sovelluspalomuuri, joko Apache- tai Nginx-pohjaisena Dokumentaatiot Yhteinen asiointisovelluksille jaettava materiaali jaetaan OM:n tarjoaman Wiki-pohjaisen ratkaisun kautta (esim. Atlassian Confluence). 5 JÄRJESTELMÄRATKAISUT Järjestelmärakenne deployment Asiointipilotti Selain / internet HTTPS Kuormanjakaja HTTP «device,container» Sovelluspalomuuri Asiiointipalvelin «device,container» API Gateway «device,container» Kirjautuminen «Graylog» Lokienhallinta Apache / mod_security Tunnistautuminen / JWT-token Reititys Kirjautuminen UI palvelut SAML2 Muu palvelin «device,container» Palvelu X1 NodeJS «device,container» Vakuutusoikeuden UI palvelut Spring Boot «device,container» Liitteet palvelut Spring Boot «device,container» Palvelu X2.NET VIA ESB Taustajärjestelmät Ympäristöt Järjestelmästä on tuotanto, sekä testiympäristöt. Testiympäristö pitäisi vastata tuotantoa. Kummatkin ympäristöt sijaitsevat asiakkaan olemassa olevissa palvelinympäristöissä Palvelimet (Kehikon toteuttavat) Palvelimen nimi Tuotanto / Testi IP osoite Vastuu

14 KUVAUS 14/ Käyttöjärjestelmät (Kehikon toteuttavat) Palvelimen nimi Tuotanto / Testi Vastuu Kehikon omat sovellukset Alla olevaan taulukkoon on koottu tietojärjestelmän omat sovellukset ja niiden rooli osana kokonaisuutta. Sovelluksen nimi Sovelluksen rooli / vastuu Tietojärjestelmä, johon kuuluu Kehikkoon liittyvät muut OM sovellukset Alla olevaan taulukkoon on koottu tietojärjestelmään liittyvät muut OM:n sovellukset ja niiden rooli osana kokonaisuutta. Nämä sovellukset kuuluvat jonkin muun tietojärjestelmän ytimeen ja niitä voidaan kehittää erillisenä tässä dokumentissa kuvattavasta tietojärjestelmästä. Sovelluksen nimi Sovelluksen rooli / vastuu Tietojärjestelmä, johon kuuluu Kehikkoon liittyvät ulkoiset sovellukset Alla olevaan taulukkoon on koottu tietojärjestelmään liittyvät yhteydet ulkoisiin tietojärjestelmiin ja niiden rooli osana kokonaisuutta. Sovelluksen nimi Sovelluksen rooli / vastuu Omistaja

15 KUVAUS 15/ Operatiiviset sovellukset Palvelimen nimi Tuotanto / Testi Vastuu Varusohjelmistot, joita tämä järjestelmä tarvitsee Nimi Palvelimen nimi Vastuu Integraatioratkaisut Integraatio- palvelu Kansallinen palveluväylä Sanomavälitys RESTful-api ldap API GateWay Vastuu Kansallinen palveluväylä ja sen kautta käytettävät sidosryhmien palvelut (esim. VTJ, KTJ). Tietojen tarjoaminen mahdollisimman automaattisesti sekä olemassa olevan tiedon tarkistuksen tukeminen. VIA Sisäiset rajapinnat Sisäiset käyttäjät Katso API GateWay kohta Sisäiset liittymät (sisäverkossa) Yhteys Esitystapa Protokolla GRAYLOG Json gelf

16 KUVAUS 16/16 Järjestelmän turvaaminen Tietojen luokittelu ja turvaaminen Teknisen alustan ja ympäristön turvallisuusvaatimukset Lisätiedot