Ero sivun ”Arkkitehtuuri” versioiden välillä

Kohteesta DigiWiki
Siirry navigaatioon Siirry hakuun
 
(27 välissä olevaa versiota samalta käyttäjältä ei näytetä)
Rivi 1: Rivi 1:
'''Arkkitehtuurivertailu''' tässä yhteydessä tarkoittaa eri asiointiratkaisujen arkkitehtuureiden tarkastelua.
+
'''Arkkitehtuuri''' tässä yhteydessä tarkoittaa eri asiointiratkaisujen perusrakenteen tarkastelua.
* '''palvelukeskeinen''' - pelkkään verkkopalveluun perustuva asiointi
+
* '''palveluarkkitehtuuri''' - pelkkään verkkopalveluun perustuva asiointi
* '''PKI-keskeinen''' - periteisen asiointiin perustuva, sopimus- ja allekirjoituspohjainen asiointi
+
* '''PKI-arkkitehtuuri''' - perinteiseen asiointiin perustuva, sopimus- ja [[allekirjoitus|allekirjoituspohjainen]] asiointi
  
Jos tapahtumassa käytetään tietovarastoja joita ei olisi käytettävissä kuin palvelun kautta, ne voi olla pakko toteuttaa verkkopalveluna. Esimerkiksi jos tietovarastoa ei voi antaa asiakkaan vapaasti selattavaksi vaan käyttö rajoittuu vain tapahtuman tai asioijaan liittyviin tietoihin - esimerkiksi Väestötietojärjestelmä tai luottokelpoisuusrekisteri.
+
Jos tapahtumassa käytetään tietovarastoja joita ei olisi käytettävissä kuin palvelun kautta, ne voi olla pakko toteuttaa verkkopalveluna. Esimerkiksi jos tietovarastoa ei voi antaa asiakkaan vapaasti selattavaksi vaan käyttö rajoittuu vain tapahtuman tai asioijaan liittyviin tietoihin - esimerkiksi [[VTJ|Väestötietojärjestelmä]] tai luottokelpoisuusrekisteri.
  
== Palvelukeskeinen ==
 
'''Palvelukeskeinen arkkitehtuuri''' perustuu verkkopalveluun jota jokin taho tuottaa, ylläpitää ja tarjoaa tietoverkossa jatkuvasti. Arkkitehtuuria ei ole tietoisesti valittu parhaana vaan siihen on päädytty pakosta koska se on ainoa tapa tehdä asiointia jos asiakkalla on vain tunnistuksessa käytettävät salasanat eikä PKI-varmenteita.
 
  
* Sen tapahtumat ovat ennalta ohjelmoitu palvelun ohjelmakoodin toiminnoiksi ja siten '''arkkitehtuurissa määrätty mitä palveluissa voi tehdä ja mitä ei'''.  
+
== Palveluarkkitehtuuri ==
 +
'''Palveluarkkitehtuuri''' perustuu verkkopalveluun jota jokin taho tuottaa, ylläpitää ja tarjoaa tietoverkossa jatkuvasti. Arkkitehtuuria ei ole tietoisesti valittu parhaana vaan siihen on päädytty pakosta koska se on ainoa tapa tehdä asiointia jos asiakkalla on vain tunnistuksessa käytettävät salasanat eikä [[PKI]]-[[varmenne|varmenteita]].
 +
 
 +
* Sen tapahtumat ovat ennalta ohjelmoitu palvelun ohjelmakoodin toiminnoiksi ja siten '''palveluarkkitehtuurin palvelussa on määrätty mitä siellä voi asioida ja mitä ei'''.  
 
* Kaikki asiointitapahtuman tilat ja tiedot ovat tallennettu asioinnin aikana ohjelmakoodin muuttujiin ja osa niistä tallentuu pysyvästi tietokantaan.  
 
* Kaikki asiointitapahtuman tilat ja tiedot ovat tallennettu asioinnin aikana ohjelmakoodin muuttujiin ja osa niistä tallentuu pysyvästi tietokantaan.  
* Asiointitapahtuman lopputuloksia ei allekirjoiteta:
+
* Asioijan ja asioinnin väliltä puuttuu kova [[tekninen sidos]] joka laskee tietoturvaa
 +
* Asiointitapahtuman lopputuloksia ei [[Allekirjoitus|allekirjoiteta]]:
 
** Koska kaikilla asiakkailla ei ole allekirjoitusvarmenteita.
 
** Koska kaikilla asiakkailla ei ole allekirjoitusvarmenteita.
** Suomen tapauksessa '''kukaan ei ole nähnyt tarpeelliseksi tallentaa tapahtuman tuloksia yleisesti tunnettuun ja tunnustettuun tiedostomuotoon jonka voisi allekirjoittaa''' ja jonka luotettavuutta jokainen voisi itsenäisesti tarkastella palvelun ulkopuolella omassa ympäristössään.
+
** Suomen tapauksessa kukaan ei ole nähnyt tarpeelliseksi tallentaa tapahtuman tuloksia yleisesti tunnettuun ja [[Allekirjoitus/Muodot|tunnustettuun tiedostomuotoon]] jonka voisi allekirjoittaa ja jonka luotettavuutta jokainen voisi itsenäisesti tarkastella palvelun ulkopuolella omassa ympäristössään.
** Koska allekirjoituksia ei käytetä, tapahtuman oikeellisuus perustuu teknisen toteuttajan luottamukseen. '''Tapahtuman väärentäminen on mahdollista jälkiä jättämättä'''. Esim sähköinen äänestys vaaleissa.
+
** Koska allekirjoituksia ei käytetä, tapahtuman oikeellisuus perustuu teknisen toteuttajan luottamukseen. '''Tapahtuman väärentäminen on mahdollista jälkiä jättämättä'''. Esim sähköinen [[Äänestäminen|äänestys]] vaaleissa.
* Palvelun toteuttaja (tekninen totetutus) on yleensä asioinnissa ns kolmas osapuoli ja mahdollisesti yksityisen sektorin toimija jonka toimintaa laki ei säätele.
+
* Palveluarkkitehtuurin asiointi mahdollistaa [[rakenteinen tieto|rakenteisen tiedon]] käsittelyn helposti, mikä on iso etu.
 +
* Toteutuksista tulee raskaita: Vaatii sopimuksia [[Digivirasto]]n, pankin ym kanssa, palvelimia, jatkuvia verkkoyhteyksiä joista ja joiden ylläpidosta on kustannuksia.
 +
* Koska toteutukset ovat raskaita, ne soveltuvat vain isoille toimijoille eikä eniten uusia työpaikkoja luovalle PK-sektorille.
 +
* Palvelun toteuttaja (tekninen totetutus) on yleensä asioinnissa ns kolmas osapuoli ja mahdollisesti yksityisen sektorin toimija jonka [[Virkavastuu|toimintaa laki ei säätele]] joka laskee tietoturvaa.
 
* Koska palvelu on ohjelma, sitä pitää tuottaa jatkuvasti, '''se sitoo kolmanteen osapuoleen ja sen kustannuksiin''' niin kauan kuin asiointia tehdään.
 
* Koska palvelu on ohjelma, sitä pitää tuottaa jatkuvasti, '''se sitoo kolmanteen osapuoleen ja sen kustannuksiin''' niin kauan kuin asiointia tehdään.
 +
* Palvelussa on keskeisiä osia kuten tunnistaminen ja sen verkossa näkyvät laitteet. Koko yhteiskuntaan skaalautuva arkkitehtuurin mittakaavassa ne ovat yksittäisiä pisteitä joihin hyökkäämällä koko väestön sähköinen asiointi lamaantuu. Vaikka [[Digivirasto]]n rakentamat järjestelmät ovat vasta osittaisessa käytössä, niiden joutuminen [[palvelunestohyökkäys]]ten (''DoS, denial of service'') kohteeksi on jo ollut jatkuvaa.
 +
 +
Palveluarkkitehtuurin järjestelmän ehkä suurin ongelma on, että se vähentää entisestään vapaaehtoisten PKI-varmenteiden hankkimista. Tämä taas estää kustannussäästöt muissa [[Varmenne#Käyttökohteet|varmenteiden käyttökohteissa]] (mm allekirjoitus, web, meili, VPN) joita ei voida tehdä nykyisillä tunnistusvälineillä ja pysytään tilanteessa joissa yhdellä käyttäjällä on lukuisia eri tunnistusvälineitä ja niiden tunnuslukuja tai salasanoja muistettavana.
  
'''Riitatapauksessa''' asia ratkaistaisiin tuomioistuimessa kuten ennen, mutta koska mitään järjestelmän ulkopuolelle tuotavaa lopputulosta / tiedostoa ei ole, pelkkä asiointitapahtuman todentaminen johtaisi itse asiointijärjestelmän syvälliseen tekniseen analyysiin ja todistajalausuntoihin - tai palvelun tuottajan edustajan lasuntoon ja siihen luottamiseen.
+
Kevyt, ennalta suunnittelematon asiointi kahden loppukäyttäjäosapuolen välillä on vaikeaa, jos sisältö on halutaan pitää salassa kahdenvälisenä, todennäköisesti sitä ei tehdä (työsopimus, yritysten patenttiasikirjat, yhteistyösopimukset tms)
  
== PKI-keskeinen ==
+
'''Riitatapauksessa''' asia ratkaistaisiin tuomioistuimessa kuten ennen, mutta koska mitään järjestelmän ulkopuolelle tuotavaa lopputulosta / tiedostoa ei ole, pelkkä asiointitapahtuman todentaminen johtaisi itse asiointijärjestelmän syvälliseen tekniseen analyysiin ja todistajalausuntoihin ja niiden luotettavuuden tulkintaan - tai palvelun toteuttajan edustajan lasuntoon ja siihen luottamiseen. Pahimmassa tapauksessa oikeustoimien kohteena olevan tapahtuman tuottanutta palvelua ei enää olemassa.
'''Julkisen avaimen infrastruktuuri''' (''Public Key Infrastructure, PKI'') perustuu varmenteiden matemaattisiin avaimiin joilla tehtyjen tapahtumien oikeellisuus voidaan todeta laskemalla. Järjestelmä vaatii varmenteiden myöntämisen ja jakelun kaikille asioijille ja asiointiin liittyvien ohjelmistojen asennuksen asiakkaan tietokoneeseen.  
 
  
Suomessa tämä on yritetty, mutta se on muodostunut ongelmaksi koska varmenteen ja muiden vaatimusten hankinta on perustunut vapaaehtoisuuteen ja vaadittavien ohjelmistojen ja allekirjoitustiedostomuodon puutteeseen.
+
== PKI-arkkitehtuuri ==
 +
'''Julkisen avaimen infrastruktuuri''' (''Public Key Infrastructure, PKI'') perustuu monikäyttöisiin varmenteisiin joita myöntää ja vaadittuja oheispalveuita tarjoaa niiden myöntäjä. Arkkitehtuuri perustuu varmenteiden matemaattisiin avaimiin joilla tehtyjen tapahtumien oikeellisuus voidaan todeta laskemalla. Järjestelmä vaatii varmenteiden jakelun ja asiointiin liittyvien ohjelmistojen asennuksen asiakkaan tietokoneeseen.  
  
* Asiointia '''voi tehdä''' verkkopalvelussa kuten palvelukeskeisessä arkkitehtuurissa, '''sitä ei ole poissuljettu''' teknisesti.
+
* Asiointia '''voi tehdä''' verkkopalvelussa kuten palveluarkkitehtuurissa, '''sitä ei ole poissuljettu''' teknisesti koska varmenteella voi myös tunnistaa.
* Asiointitapahtumia voi tehdä perinteisen paperin ja kynän allekirjoituksen tapaan jos palvelu ei ole rakennettu kyseiseen tapahtumaa varten.
+
* Asiointitapahtumia voi tehdä perinteisen paperin ja kynän allekirjoituksen tapaan jos palvelu ei ole rakennettu kyseiseen tapahtumaa varten.  Tällöin '''palvelua ei tarvita''' ollenkaan.
 
* Tapahtuman tulokset voi tallentaa joko tietokantaan tai '''halutessaan allekirjoitettuun tiedostomuotoon''' - tai molempiin.
 
* Tapahtuman tulokset voi tallentaa joko tietokantaan tai '''halutessaan allekirjoitettuun tiedostomuotoon''' - tai molempiin.
 
* Jos tiedonsiirtokanavaan tai verkkopalvelun tuottajaan ei luoteta, '''tapahtuman oikeellisuus voidaan todeta luotettavasti jälkikäteen  pelkästään tarkastelemalla allekirjoitettua sisältöä''', se miten se on tuotettu, missä ja kenen toimesta on merkityksetöntä.
 
* Jos tiedonsiirtokanavaan tai verkkopalvelun tuottajaan ei luoteta, '''tapahtuman oikeellisuus voidaan todeta luotettavasti jälkikäteen  pelkästään tarkastelemalla allekirjoitettua sisältöä''', se miten se on tuotettu, missä ja kenen toimesta on merkityksetöntä.
* Tapahtuman lopputuloksen oikeellisuuden '''tarkastelun voi tehdä kuka tahansa noviisi koska allekirjoituksia käytetään muutenkin''' arjessa.
+
* Tapahtuman lopputuloksen oikeellisuuden '''tarkastelun voi tehdä kuka tahansa noviisi koska allekirjoituksia käytetään muutenkin''' arjessa (Suomessa tätä ei ole saavutettu).
 +
* Toteutukset ovat kevyitä: Vaatii vain verovaroilla tuotetun maksuttoman [[Varmentaja|varmentajan]] juurivarmenteen ja tuoreen sulkulistan, ei sopimuksia.
 +
* Koska toteutukset ovat kevyitä, ne soveltuvat sekä isoille toimijoille sekä PK-sektorille joka myös luo eniten uusia työpaikkoja.
 +
* Asiointi on käytännössä täysin hajautettua (poislukien [[Aikaleima|aikaleimapalvelu]], [[sulkulista]]t ja [[OSCP]]) ja on yhtä haavoittuvainen kuin sen hyödyntämät perinteiset palvelut kuten sähköposti ja web.
 +
 
 +
 
 +
Suomessa PKI:n käyttöä on yritetty, mutta siinä on epäonnistuttu koska varmenteen ja muiden vaatimusten hankinta on perustunut vapaaehtoisuuteen ja vaadittavien ohjelmistojen puutteisiin. Yhtenäistä allekirjoituksen tiedostomuotoa ei ole haluttu määritellä ja siten allekirjoituksia ei ole voitu tallentaa, siirtää ja tarkastella. On ajateltu, että markkinoiden ohjelmien sisäinen tuki riittää, mutta näin ei ole käynyt.
  
 
'''Riitatapauksissa''' asia ratkaistaisiin tuomioistuimessa kuten ennen paperia ja mustekynää allekirjoituksessa käytettäessä. Koska allekirjoituksen tiedostomuoto on koko väestön käyttämä ja tuntema, sen luotettavuuden kyseenalaistaminen olisi todennäköisesti suurempi asia kuin itse riitatapaus.
 
'''Riitatapauksissa''' asia ratkaistaisiin tuomioistuimessa kuten ennen paperia ja mustekynää allekirjoituksessa käytettäessä. Koska allekirjoituksen tiedostomuoto on koko väestön käyttämä ja tuntema, sen luotettavuuden kyseenalaistaminen olisi todennäköisesti suurempi asia kuin itse riitatapaus.
  
 
[[Luokka:Vertailut]]
 
[[Luokka:Vertailut]]

Nykyinen versio 4. toukokuuta 2022 kello 13.35

Arkkitehtuuri tässä yhteydessä tarkoittaa eri asiointiratkaisujen perusrakenteen tarkastelua.

  • palveluarkkitehtuuri - pelkkään verkkopalveluun perustuva asiointi
  • PKI-arkkitehtuuri - perinteiseen asiointiin perustuva, sopimus- ja allekirjoituspohjainen asiointi

Jos tapahtumassa käytetään tietovarastoja joita ei olisi käytettävissä kuin palvelun kautta, ne voi olla pakko toteuttaa verkkopalveluna. Esimerkiksi jos tietovarastoa ei voi antaa asiakkaan vapaasti selattavaksi vaan käyttö rajoittuu vain tapahtuman tai asioijaan liittyviin tietoihin - esimerkiksi Väestötietojärjestelmä tai luottokelpoisuusrekisteri.


Palveluarkkitehtuuri

Palveluarkkitehtuuri perustuu verkkopalveluun jota jokin taho tuottaa, ylläpitää ja tarjoaa tietoverkossa jatkuvasti. Arkkitehtuuria ei ole tietoisesti valittu parhaana vaan siihen on päädytty pakosta koska se on ainoa tapa tehdä asiointia jos asiakkalla on vain tunnistuksessa käytettävät salasanat eikä PKI-varmenteita.

  • Sen tapahtumat ovat ennalta ohjelmoitu palvelun ohjelmakoodin toiminnoiksi ja siten palveluarkkitehtuurin palvelussa on määrätty mitä siellä voi asioida ja mitä ei.
  • Kaikki asiointitapahtuman tilat ja tiedot ovat tallennettu asioinnin aikana ohjelmakoodin muuttujiin ja osa niistä tallentuu pysyvästi tietokantaan.
  • Asioijan ja asioinnin väliltä puuttuu kova tekninen sidos joka laskee tietoturvaa
  • Asiointitapahtuman lopputuloksia ei allekirjoiteta:
    • Koska kaikilla asiakkailla ei ole allekirjoitusvarmenteita.
    • Suomen tapauksessa kukaan ei ole nähnyt tarpeelliseksi tallentaa tapahtuman tuloksia yleisesti tunnettuun ja tunnustettuun tiedostomuotoon jonka voisi allekirjoittaa ja jonka luotettavuutta jokainen voisi itsenäisesti tarkastella palvelun ulkopuolella omassa ympäristössään.
    • Koska allekirjoituksia ei käytetä, tapahtuman oikeellisuus perustuu teknisen toteuttajan luottamukseen. Tapahtuman väärentäminen on mahdollista jälkiä jättämättä. Esim sähköinen äänestys vaaleissa.
  • Palveluarkkitehtuurin asiointi mahdollistaa rakenteisen tiedon käsittelyn helposti, mikä on iso etu.
  • Toteutuksista tulee raskaita: Vaatii sopimuksia Digiviraston, pankin ym kanssa, palvelimia, jatkuvia verkkoyhteyksiä joista ja joiden ylläpidosta on kustannuksia.
  • Koska toteutukset ovat raskaita, ne soveltuvat vain isoille toimijoille eikä eniten uusia työpaikkoja luovalle PK-sektorille.
  • Palvelun toteuttaja (tekninen totetutus) on yleensä asioinnissa ns kolmas osapuoli ja mahdollisesti yksityisen sektorin toimija jonka toimintaa laki ei säätele joka laskee tietoturvaa.
  • Koska palvelu on ohjelma, sitä pitää tuottaa jatkuvasti, se sitoo kolmanteen osapuoleen ja sen kustannuksiin niin kauan kuin asiointia tehdään.
  • Palvelussa on keskeisiä osia kuten tunnistaminen ja sen verkossa näkyvät laitteet. Koko yhteiskuntaan skaalautuva arkkitehtuurin mittakaavassa ne ovat yksittäisiä pisteitä joihin hyökkäämällä koko väestön sähköinen asiointi lamaantuu. Vaikka Digiviraston rakentamat järjestelmät ovat vasta osittaisessa käytössä, niiden joutuminen palvelunestohyökkäysten (DoS, denial of service) kohteeksi on jo ollut jatkuvaa.

Palveluarkkitehtuurin järjestelmän ehkä suurin ongelma on, että se vähentää entisestään vapaaehtoisten PKI-varmenteiden hankkimista. Tämä taas estää kustannussäästöt muissa varmenteiden käyttökohteissa (mm allekirjoitus, web, meili, VPN) joita ei voida tehdä nykyisillä tunnistusvälineillä ja pysytään tilanteessa joissa yhdellä käyttäjällä on lukuisia eri tunnistusvälineitä ja niiden tunnuslukuja tai salasanoja muistettavana.

Kevyt, ennalta suunnittelematon asiointi kahden loppukäyttäjäosapuolen välillä on vaikeaa, jos sisältö on halutaan pitää salassa kahdenvälisenä, todennäköisesti sitä ei tehdä (työsopimus, yritysten patenttiasikirjat, yhteistyösopimukset tms)

Riitatapauksessa asia ratkaistaisiin tuomioistuimessa kuten ennen, mutta koska mitään järjestelmän ulkopuolelle tuotavaa lopputulosta / tiedostoa ei ole, pelkkä asiointitapahtuman todentaminen johtaisi itse asiointijärjestelmän syvälliseen tekniseen analyysiin ja todistajalausuntoihin ja niiden luotettavuuden tulkintaan - tai palvelun toteuttajan edustajan lasuntoon ja siihen luottamiseen. Pahimmassa tapauksessa oikeustoimien kohteena olevan tapahtuman tuottanutta palvelua ei enää olemassa.

PKI-arkkitehtuuri

Julkisen avaimen infrastruktuuri (Public Key Infrastructure, PKI) perustuu monikäyttöisiin varmenteisiin joita myöntää ja vaadittuja oheispalveuita tarjoaa niiden myöntäjä. Arkkitehtuuri perustuu varmenteiden matemaattisiin avaimiin joilla tehtyjen tapahtumien oikeellisuus voidaan todeta laskemalla. Järjestelmä vaatii varmenteiden jakelun ja asiointiin liittyvien ohjelmistojen asennuksen asiakkaan tietokoneeseen.

  • Asiointia voi tehdä verkkopalvelussa kuten palveluarkkitehtuurissa, sitä ei ole poissuljettu teknisesti koska varmenteella voi myös tunnistaa.
  • Asiointitapahtumia voi tehdä perinteisen paperin ja kynän allekirjoituksen tapaan jos palvelu ei ole rakennettu kyseiseen tapahtumaa varten. Tällöin palvelua ei tarvita ollenkaan.
  • Tapahtuman tulokset voi tallentaa joko tietokantaan tai halutessaan allekirjoitettuun tiedostomuotoon - tai molempiin.
  • Jos tiedonsiirtokanavaan tai verkkopalvelun tuottajaan ei luoteta, tapahtuman oikeellisuus voidaan todeta luotettavasti jälkikäteen pelkästään tarkastelemalla allekirjoitettua sisältöä, se miten se on tuotettu, missä ja kenen toimesta on merkityksetöntä.
  • Tapahtuman lopputuloksen oikeellisuuden tarkastelun voi tehdä kuka tahansa noviisi koska allekirjoituksia käytetään muutenkin arjessa (Suomessa tätä ei ole saavutettu).
  • Toteutukset ovat kevyitä: Vaatii vain verovaroilla tuotetun maksuttoman varmentajan juurivarmenteen ja tuoreen sulkulistan, ei sopimuksia.
  • Koska toteutukset ovat kevyitä, ne soveltuvat sekä isoille toimijoille sekä PK-sektorille joka myös luo eniten uusia työpaikkoja.
  • Asiointi on käytännössä täysin hajautettua (poislukien aikaleimapalvelu, sulkulistat ja OSCP) ja on yhtä haavoittuvainen kuin sen hyödyntämät perinteiset palvelut kuten sähköposti ja web.


Suomessa PKI:n käyttöä on yritetty, mutta siinä on epäonnistuttu koska varmenteen ja muiden vaatimusten hankinta on perustunut vapaaehtoisuuteen ja vaadittavien ohjelmistojen puutteisiin. Yhtenäistä allekirjoituksen tiedostomuotoa ei ole haluttu määritellä ja siten allekirjoituksia ei ole voitu tallentaa, siirtää ja tarkastella. On ajateltu, että markkinoiden ohjelmien sisäinen tuki riittää, mutta näin ei ole käynyt.

Riitatapauksissa asia ratkaistaisiin tuomioistuimessa kuten ennen paperia ja mustekynää allekirjoituksessa käytettäessä. Koska allekirjoituksen tiedostomuoto on koko väestön käyttämä ja tuntema, sen luotettavuuden kyseenalaistaminen olisi todennäköisesti suurempi asia kuin itse riitatapaus.