Palvelulle

Kohteesta DigiWiki
Versio hetkellä 17. toukokuuta 2018 kello 09.17 – tehnyt TUOMALA JUHA 10000350X (keskustelu | muokkaukset)
Siirry navigaatioon Siirry hakuun

Palvelun omistajalle (henkilö, yritys, yhdistys tms yhteisö) digitalisaatio asettaa isoja haasteita teknologian kehitysnopeuden ja käyttöönottotahdin ollessa muita teollisuudenaloja nopeampi. Monen yhteisön päättäjälle tietotekniikka vain sivuaa itse yhteisön ydintoimintaa - mutta silti sähköisten palveluiden tarjoamiselle kasvaa paineita ja niiden suunnittelu ja rakentaminen vaatii paljon perehtymistä ja asiantuntijaresursseja joita ei välttämättä ole käytettävissä. Vääriä valintoja tehdessä investointi saattaa vaatia uudelleen rakentamista ennen aikojaan ja väärälle valitulle teknologialle sopivan toimittajan löytäminen myöhemmin saattaa olla vaikeaa ja kallista.

Yhteisön johdolle yksi, joskin työläs vaihtoehto tehdä oikeita valintoja vähillä resursseilla on itse perehtyä verkkopalveluiden ratkaisuihin ja analysoida paras vaihtoehto eri arkkitehtuureista, tekniikoista ja kehityksen trendeistä. Huolimatta toteuttajasta, palvelun omistajan tulisi ainakin tietää millä ja miten palvelu on toteutettu ja mitkä vaikutukset valinnoilla on palveluun ja sen elinkaareen.

Sivulle on koottu yhteenveto eri osa-alueista auttamaan päätöksenteossa ja herättämään ajatuksia. Sisältö ei käsittele avaimet-käteen palveluita joissa kaikki edelläoleva on jo sivuutettu ulkoistettuna.


Kohderyhmät

Kohderyhmä ja sen suhde palveluun yleensä määrittelee palvelun toteutustavan ja arkkitehtuurin. Arkkitehtuurivalintoja on viime aikoina muokannut mobiililaitteiden suosion kasvu ja toisaalta web-käyttöliittymien ulkoasun ja vasteellisuuden kehittyminen, jonka myötä sen kehitysmalleja on kopioitu henkilökohtaisten tietokoneiden käyttöliittymien kehityksestä.

Komponenttien ja arkkitehtuurin valinta perustuu usein kohderyhmän käyttöprofiilista ja siihen investoitujen kehitys- ja ylläpitokustannusten kompromissista. Jos palvelua/palvelu:

  • käyetään satunnaisesti
  • käytetään toistuvasti
  • käytetään eri päätelaitteilta kuten tietokoneelta ja mobiililaitteesta
  • käytetään päätelaitteeseen asennetulla sovelluksella
  • käsittelee tekstiä monimutkaisempia aineistoja kuten karttoja, videota tai ääntä

Käytetään satunnaisesti

Jos käyttö on satunnaista, enimmäkseen tekstin ja kuvien käsittelyä ja tapahtuu tietokoneelta - yleinen tapa on toteuttaa se web-selaimessa ja valittavana on useita eri sovelluskehyksiä ja arkkitehtuureita.

Tyypillinen esimerkki on henkilön rekisteröinti palveluun, jossa syötetään henkilö- ja yhteystiedot.

Käytetään toistuvasti

MVC mielekäs

Käytetään eri päätelaitteilta

MVC raskas, applikaatioserveri kevyempi, eri alustojen jaettu koodi kustannustehokkaampi

Käytetään päätelaitteeseen asennetulla sovelluksella

Käsitellään tekstiä monimutkaisempia aineistoja

kartat, multimedia -> app

Arkkitehtuurit

Templaattipohjaiset

Esimmäisen sukupolven palveluita kehitettiin enimmäkseen templaatti-järjestelmien avulla. Yksinkertaisimmillaan kaikki tietokantakyselyt tehtiin käsin suoraan käyttöliittymän templaateista ja niiden kehittäminen ja ylläpito oli hidasta ja kallista. Teknologia ei sinänsä rajoita hyviä kehitystapoja ja kehitykseen käytetyn ajan sekä kehityskulujen hallinta on silti mahdollista. Ratkaisu voi olla sopiva pienien kehitysresurssien tarpeeseen vielä nykyäänkin.

Asiakas-palvelin ympäristöt

Toisen sukupolven arkkiehtuuriksi voidaan kutsua asiakas-palvelin arkkiehtuuria jossa itse sovellus muodostuu palvelimessa jatkuvasti pyörivästä sovelluksesta tietokantoineen ja käyttäjän päässä on käyttöliittymä joka ladataan kerran alussa ja kommunikoi käytön edetessä kevyesti sovelluspalvelimessa pyörivän sovelluksen kanssa. Arkkitehtuurin etu on sovelluksen jatkuva käynnissäolo joka ainakin periaatteessa näkyy käyttäjälle nopeutena koska samoja käynnistyksen alussa tehtäviä rutiineja ei ajeta käyttäjän jokaisesta toimesta käyttöliittymässä. Haittana on sovelluspalvelimen tai sovelluksen kaatuminen virhetilanteessa(?) ja sen näkyminen käyttäjälle jos tilanteesta toipumista ei ole huolehdittu. Suosittu ja tyypillinen esimerkki asiakas-palvelin arkkitehtuurista on tomcat.apache.org - Apache Tomcat

Malli-Näkymä-Käsittelijä (MVC)

Kolmannen sukupolven palvelut noudattavat usein MVC (Model view controller, malli-näkymä-käsittelijä) arkkiehtuuria jota on jo pitkään käytetty henkilökohtaisen tietokoneiden graafisissa ohjelmistoissa. Tässä käytetty sovellus on toteutettu yleensä javascriptillä (aiemmin saattoi olla myös Java) ja se pyörii kokonaisuudessaan käyttäjän päätelaitteen selaimessa. Koko käyttöliittymän ulkoasu ja sovelluksen ohjelmakoodi ladataan kerran, jonka jälkeen käyttöliittymää päivitetään kevyellä liikenteellä palvelun palvelimelta käytön edetessä.

Arkkitehtuurissa on toisen sukupolven edut, etäyhteyden liikennemäärät ovat huomattavasti pienemmät kuin aiemmissa sukupolvissa. Muita selkeitä etuja ovat palvelun palvelimien ja tietoliikenneyhteyksien vähentynyt kuormitus, toteutuksen mahdollistama visuaalinen näyttävyys ja käyttökokemus sekä läheinen suhde tietokoneiden ja mobiililaitteiden täysimittaisiin sovelluksiin jotka hyödyntävät samoja palvelimien rajapintoja.

Haittana kasvaneet vaatimukset selaimien yhteensopivuuksissa monimutkaistuneen asiakaspään toteutuksen takia ja kaikista raskaimmat kehitysvaatimukset taitojen ja ajankäytön kannalta joka johtaa hitaaseen aikatauluun ja korkeisiin kuluihin.


Java ja applikaatioserverit, Frameworkit, RESTful, rikkaat asiakaat

Teknologiat

html5

Palvelimen sovelluskehykset

Drupal on selainpohjainen sisällönhallintajärjestelmä (CMS) sovelluskehys (framework), jonka avulla luot, hallitset ja julkaiset sisältöä verkkosivuille ilman teknistä osaamista verkkosivujen toteuttamisesta. Drupal soveltuu pienten verkkosivujen toteutuksesta aina laajoihin ja haastaviin verkkototeutuksiin.

Wordpress wordpress.org, lyhyesti WP on sisällönhallintajärjestelmä (content management system, CMS) joka on nykyään suosituin sovelluskehys yhteisöjen web-sivujen tai blogien alustaksi jos sisältö on pääasiassa tekstiä. Wordpress on ohjelmoitu php:llä ja käyttää MySQL RDBMS-tietokantaa. WP tukee laajaa valikoimaa vaihdettavia ulkoasuja, liitännäisiä (yli 40k), sillä julkaistuun sisältöön löytyy mobiilisovellukset.

WP:ssä on XMLRPC-rajapinta joka on tunnettu ongelmistaan, sitä on käytetty mm DDoS-hyökkäysten proxynä peittämään ja monistamaan todellisen hyökkääjän liikenne[1] - eli saada WP:tä käyttävä taho näyttämään hyökkääjältä.

Joomla

Django on suosittu ja harvoja Python-ohjelmointikielellä tehtyjä sovelluskehyksiä. Sille löytyy mm sisällönhallintajärjestelmä django-cms. djangoproject.com

Apache Struts on JavaEE-ohjelmointikielellä sovelluskehys joka kannustaa käyttämään MVC-arkkitehtuuria. struts.apache.org

Palvelimen sovellukset

Verkkokauppasovelluksia, täydellinen lista löytyy wikipediasta. Suurimmat valintaan vaikuttavat tekijät ovat elinkaarikustannukset, paikallisten, skandinavisten maksurajapintojen tuki ja yleiset ominaisuudet.

Magneto on suosittu web-kauppa alusta magneto.com.

OpenCart avoimen lähdekoodin verkkokauppaohjelmisto opencart.com

osCommerce oscommerce.com

Odoo sisältää monta toimintoa kuten asiakkuudenhallinan (CRM), tuotannonohjauksen (ERP) ja web-kaupan. Sen toteutuskieli on Python ja Javascript ja se käyttää Postgresql-tietokantaa. lisää...

PrestaShop prestashop.com

VirtueMart on verkkokauppasovellus Joomla CMS-sovelluskehykselle. Ohjelmointikieli on PHP ja tuettu tietokanta MySQL/MariaDB. virtuemart.net

Woo Commerce on web-kauppa plugin Wordpressille. woocommerce.com.

Zen Cart on osCommercin vuonna 2003 tehty forkki. zen-cart.com

Magneto on tilastojen perusteella suosituin (2017-05). Magneto ja PrestaShop poikkeavat toisista OSL-3.0 lisenssillään, kun muut on julkaistu GNU GPL-lisenssillä.

Palvelimen tietokannat

MySQL / MariaDB (mariadb.org)

PostgreSQL (postgresql.org)

Elastic (elasticsearch)

Firebird (firebirdsql.org) on etenkin Microsoft Windows käyttäjäyhteisössä suosittu valinta relaatiotietokannaksi. Toisaalta Windows ei ole suosittu valinta Internetin palveluiden alustaksi.

Käyttöliittymän Javascript

Arkkitehtuureita:

jQuery (jquery.com) on selainriippumaton, modulaarinen (core, ui/mobile ja 3. osapuolen pluginit) abstraktiokirjasto joka helpottaa javascript-toteutuksen toteuttamista (dom-model, ajax, käyttöliittymän elementit - widgetit jne). Kummatkin - sekä jquery-ui, että jquery-mobile käyttävät perus jquery-kirjastoa ja tukevat ulkoasun teemoja jotka ovat sivustokohtaisesti räätälöitävissä.

Mobiiliversion on tarkoitus toimia myös työpöytäselaimilla, mutta sen toteutustapa poikkeaa merkittävästi jqueury-ui mallista teknisesti. Mobiilissa eri sivut rakennetaan samaan tiedostoon eri lohkoihin ja ladataan kerralla päätelaitteeseen ja sivunvaihdot tapahtuvat mobiilikirjaston suorittamana. Olemassaolevan sivuston muuttaminen mobiilikirjastolla toteutetuksi todennäköisesti vaatisi työlästä uudelleenorganisointia toteutustasolla edellä mainitussa lohkorakenteissa kuin sen toimintatavan eroavaisuuksissa ja siten sen toteuttamista suositellaan aloittamaan tyhjästä käyttämättä vanhaa, esimerkiksi jquery-ui sivustoa. Eroista vaadittava osaaminen vaatii myös toteuttajalta omaksumista tai kokonaan siihen perehtyneitä henkilöitä.

Mobiilikirjastolla tehdyt käyttöliittymät tuntuvat työpöydällä kärsivän mobiililaitteille tyypillisestä elemettien koko ruudun/selaimen leveydestä mikä ei toimi työpöydällä - siitäkin huolimatta, että tätä on pyritty huomioimaan kirjastossa. Ulkoasun poikkeavuudet ja edellä mainitut toteutustavan eroavaisuuksista johtuen näyttäisikin, että markkinoilla olevat saitit käyttävät mobiilikirjastoa ainoastaan mobiililaitteiden tukemiseen ja sivut ovat omassa m.example.com urlissa (m dot site). Lupaus yhtenäisestä teknisestä alustasta ei ole ainakaan vielä lyönyt itseään läpi. Tämä taas johtaa kahden eri järjestelmän ylläpitoon ja niiden kustannuksiin.

Mobiiliwebin vaihtoehto on toteuttaa palvelu työpöydälle optimoituna webinä ja mobiililaitteille tehdyllä mobiilisovelluksella.

Dojo mobile dojotoolkit.org

JQ.Mobi jqmobi.com

Sencha Touch sencha.com - touch

AngularJS angularjs.org.

React reactjs.com.

MEAN (mean.io)

Lisää aiheesta omalla sivullaan: Javascript

Mobiiliapplikaatiot

Dominoivat ekosysteemit, Applen iOS ja Googlen Android mobiilikäyttöjärjestelmät eivät ole keskenään yhteensopivia. Halutessaan tukea molempia, molemmille tulee tehdä sovelluksestaan omat versiot. Niiden omat kehitysympäristöt käyttävät eri ohjelmointikieliä joka voi asettaa omat vaatimuksensa kehittäjille. Poikkeuksena tästä on mm Qt jota käytettäessä lopputulokset syntyvät molempiin käyttöjärjestelmiin.


Googlen Android sovellukset kehitetään Android Studio kehitysympäristössä Java-kielellä. Halutessaan voi käyttää myös natiivia, C- tai C++ -kieliä Android NDK ympäristöllä joka mahdollistaa mm OpenGL grafiikkakirjastojen käytön.

Applen iOS mobiililaitteiden sovellukset kehitetään Applen Xcode työkalulla joka toimii vain Mac OS X käyttöjärjestelmässä. Kehitteillä olevan sovelluksen voi asentaa omaan laitteeseensa kierrättämättä sitä Applen sovelluskaupan kautta, mutta jaellakseen sitä sovelluskaupassa pidempään, tästä tulee maksaa erikseen Applelle.

Microsoft Windows Phone käyttää mm DirectX-kirjastoja OpenGL:n sijasta.

Qt-kehitysympäristöllä voi tuottaa samasta C++-lähdekoodista suoraan Android, iOS, Windows Phone, BlackBerry ja Sailfish sovellukset ylläpitämättä eri versioita eri alustoille. Käyttöliittymä tehdään Qt:n Quick tekniikalla. Kehitysympäristöön voi tutustua ilmaiseksi 30 päivän ajan.

Käyttöliittymän Python

Python on kielenä kasvattanut suosiota tietojenkäsittelyssä käyttökohteesta riippumatta ja yrityksiä käyttää sitä web-palveluissa on ollut jo pitkään, sitä on lähinnä jarruttanut selaivalamistajien tuen puute. Javascript-kieli hallitsee webiä, mutta sen ulkopuolella sitä ei juurikaan käytetä. Tästä johtuen Python kielen osaajia on huomattavasti enemmän ja loogisesti ajateltuna sen käyttö olisi perusteltua kun raskasta ajattelumallin- ja kielen vaihtoa ei tarvita kun kieli on kaikkialla yksi ja sama. Tämä säästää aikaa ja rahaa.

Jotkut toteutukset ovat vaatineet selaimen laajennoksia joita ei ole ollut kaikkiin yleisesti käytössä oleviin selaimiin saatavilla ja tämä on myös vaatinut käyttäjältä laajennoksen asentamista jota ei voida pitää kohtuullisena vaatimuksena. Viimeisimmät toteutukset pohjautuvat Javascriptiin jolloin laajennuksen asentamista ei tarvita ja palvelut toimivat suoraan vaikka ne olisi ohjelmoitu Python-kielellä. Tämä on ollut yllättävä ja mullistava kehityssuunta.

Jos Pythonin käyttö lisääntyy, Javascriptiin pohjautuvat toteutukset saattavat olla vain välivaihe ja lopulta puhdas Python-kielen tuki alkaa yleistyä selaimissa ja palveluiden suoritusnopeudet paranevat. Vaikka näin ei tapahtuisi, mikään ei estä siirtymästä Pythonin käyttöön jos se todetaan toimivaksi kyseisessä käyttötarkoituksessa.

Selaimen Python toteutuksia:

Artikkeleita ja vertailuja:

Verkkotunnus ja varmenne

Verkkotunnus

Suomalaisen .fi-päätason verkkotunnuksen (TLD, top-level domain) omistaa valtio ja sitä hallinnoi Viestintävirasto. Sen alta löytyviä tietoja voi tarkastella domain.fi -verkkopalvelussa. Tunnuksen anominen on kilpailutettu EU:n laajuisesti eri verkkotunnusvälittäjille joilta tunnuksia voi rekisteröidä ja hankkia siihen liittyviä palveluita.

Tunnuksella voi olla eri omistaja ja siihen liittyvän tekniikan hoitamiseen erikoistunut taho (haltija). Anottaessa tunnusta, loppukäyttäjän tulee varmistua, että rekisteriin merkitään oikea omistaja eikä palveluntarjoajaa koska tällöin täysi omistus- ja määräysvalta ei ole tunnuksen käyttäjällä.

Ennen 5.9.2016 anottuja verkkotunnuksia saattaa olla vieläkin Viestintäviraston rekisterissä, josta ne piti siirtää kaupalliselle välittäjälle ennen hallintakäyttöliittymän sulkemista. Verkkotunnuksen myöntämisen yhteydessä annetut valtuutusavaimet on mitätöity em päivänä eikä niitä saa enää uusia itsepalvelun kautta vaan tulee asioida Viestintäviraston kanssa uuden saamiseksi. Palvelun sulkemisen yhteydessä suljettiin myös tunnuksen voimassaolon päättymisestä muistuttavien sähköpostien lähettely, joten riski menettää oma verkkotunnus hallinnan laiminlyönnin takia on suuri ja niitä on jo tapahtunut monelle suomalaiselle tunnuksen käyttäjälle.

Varmenne

Palvelu voi tarvita varmenteen, jotta kävijä tietää varmasti asioivansa oikeassa palvelussa eikä petosta yrittävällä näköiskopiolla. Varmennetta käytetään aloittamaan suojattu (salattua) SSL-yhteys joka näkyy WWW-selaimessa https linkin yhteystapana. Varmentajia on sekä kaupallisia ja valtioita. Niiden myöntämät varmenteet ovat sidottu verkkotunnuksen nimeen, maksullisia ja määräaikaisia.

Lait, selosteet ja sertifikaatit

Mediakortti

Käyttöehdot

Rekisteriseloste

Henkilötietolain 10 §:n mukaan Rekisterinpitäjän on laadittava henkilörekisteristä rekisteriseloste, josta ilmenee:

1) rekisterinpitäjän ja tarvittaessa tämän edustajan nimi ja yhteystiedot;

2) henkilötietojen käsittelyn tarkoitus;

3) kuvaus rekisteröityjen ryhmästä tai ryhmistä ja näihin liittyvistä tiedoista tai tietoryhmistä;

4) mihin tietoja säännönmukaisesti luovutetaan ja siirretäänkö tietoja Euroopan unionin tai Euroopan talousalueen ulkopuolelle; sekä

5) kuvaus rekisterin suojauksen periaatteista.

Rekisterinpitäjän on pidettävä rekisteriseloste jokaisen saatavilla. Tästä velvollisuudesta voidaan poiketa, jos se on välttämätöntä valtion turvallisuuden, puolustuksen tai yleisen järjestyksen ja turvallisuuden vuoksi, rikosten ehkäisemiseksi tai selvittämiseksi taikka verotukseen tai julkiseen talouteen liittyvän valvontatehtävän vuoksi[2].

Tietoturvaseloste

Henkilötietolaki

Henkilörekisterilaki

Sähköisen viestinnän tietosuojalaki

EU direktiivit ja asetukset

Tietosuoja-asetus

Euroopan parlamentti ja neuvosto sääti 27. hutikuuta 2016 asetuksen 2016/679 luonnollisten henkilöiden tietosuojasta (General Data Protection Regulation, GDPR) - luonnollisten henkilöiden suojelusta henkilötietojen käsittelyssä sekä näiden tietojen vapaasta liikkuvuudesta. Asetus tulee voimaan jo 26. toukokuuta 2018, kahden vuoden transitiovaiheen jälkeen, suoraan ilman jäsenvaltioiden kansallista ratifiointia.


Maksupalveludirektiivi PSD2

Maksupalveludirektiivi (PSD2) on vietävä kansalliseen lainsäädäntöön Euroopan unionin jäsenmaissa, Suomessa se tapahtui 13. tammikuuta 2018.

Viranomaisvaatimukset

KATAKRI

Asioijan tunnistaminen ja tiedot

Palvelun luonteesta riippuu riittääkö pelkkä henkilön tunnistaminen koko asiointiin vai tarvitseeko tapahtuma tietoa myös tunnistetun henkilön oikeuksista eri rooleihin ja valtuuksiin sekä asiojan henkilötietoja. Suurin osa tunnistusmenetelmistä ei sisällä roolitietoa ja palvelun toteuttaminen vaatii tällöin yhteydet taustajärjestelmiin joiden tiedot on tyypilisesti suojattu lailla ja siten yhteys vaatii sopimuksen rekisterinpitäjään ja sen käyttö on maksullista ja valvottua.

Henkilöasioijan tietoja:

  • nimi
  • syntymäaika-, -paikka ja -valtio
  • yksilöivät tunnukset: HETU, SATU
  • kansalaisuus
  • kotipaikka
  • asioijan elossaolon tarkastus
  • ikä ja täysi-ikäisyys
  • oikeudellisen toimikelpoisuuden rajoitukset
  • avioliitto- tai rekisteröity parisuhde
  • sukulaissuhteet
  • huollettavat (lapset)
  • äänioikeus eduskunta-, kunnallis-, presidentti- ja EU-parlamentin vaaleissa.

Yhteisöasioijan tietoja

Asiointikohteen tietoja:

  • alaikäisen tai edunvalvonnan alaisen edustajan valtuutus
  • yhteisöt: yhdistykset, säätiöt, kunnat, seurakunnat, valtio - ja nämä ulkomaalaisina
    • edustetun yhteisön nimenkirjoitusoikeus - toimivalta, kelpoisuus (Kaupparekisteri)
    • edustetun yhteisön päätösvaltaisuus - riittävä määrä allekirjoittajia
  • käsitellyn asian omistusoikeudet, panttaukset, tms ja valtakirjat


Osa näistä tiedoista saadaan nykyään Väestörekisterikeskuksen västötietojärjestelmästä (VTJ), verohallinnon rekisteriin tallennetuista KATSO-tunnusten välisisistä valtuutuksista ja Patentti- ja rekisterihallituksen Kaupparekisteristä. Jatkossa Palveluväylän rooli- ja valtuutuspalvelu RoVa yhdistää ja korvaa kaikki edellämainitut julkis- ja yksityissektorin yhteisöjen osalta.


Pankkitunnukset

Pankkitunnukset eli TUPAS-tunnistuspalvelu on Suomen laajimassa käytössä oleva lain tarkoittama vahva tunnistusväline. Siihen liittyminen vaatii sopimuksen kaikkien eri tuettavien pankkien kanssa. Sopimuksista veloitetaan perusmaksu joka kuukausi ja joka tunnistustapahtumasta noin 0,50 euroa. Verkkopalvelun liittäminen TUPAS-järjestelmään on myös haastavaa teknisesti koska sen dokumentaatio on salaista, avoimia liityntäkirjastoja tai julkista keskustelua ongelmanratkomisesta ei ole.

Palvelulle/Pankkitunnukset

Mobiilivarmenne

Mobiilivarmenne on

Henkilökortti

Moni Euroopan maista on lisännyt henkilökortteihinsa sähköisen sirun jolla on varmenne asioijan tunnistamista varten (poikkeuksena Saksa). Verkkopalvelussa varmenteella tunnistaminen ei maksa palvelun tarjoajalle mitään. Takaajien juurivarmenteet ja estettyjen tunnisteiden sulkulistat ovat ilmaiseksi saatavilla. Varmenteita käyttävä tunnistustapahtuma (Client Side Certificate) on tietotekniikassa laajalti tunnettu toimenpide ja siten sen lisääminen palveluun kehityskustannuksiltaan on kohtuullinen, toisiin kehysohjelmistoihin löytyy valmiit komponentit sitä varten.

Suomen tapauksessa tunnistustapahtumassa palveluntarjoaja saa henkilökorttia ja Mobiilivarmennetta käyttävän asioijan erittelevän SATU-tunnisteen HETU:n sijasta. Väestörekisterikeskus myy erikseen kk-laskutettua VTJ-kyselypalvelua jolla SATU-HETU sidos voidaan haluttaessa tehdä.

Varmennehierarkiaa tarjoavien EU-maiden lista löytyy TSL-tilasivulta.

Suomi.fi

Suomi.fi-tunnistus on julkishallinnon yhteinen tunnistuspalvelu, yksityisen sektorin toimijat eivät voi liittyä siihen. Sen avulla julkishallinnon asiointipalvelut saavat kaikki suomalaiset vahvat tunnistusvälineet käyttöönsä yhden rajapinnan kautta. Lisäksi palvelu sisältää mahdollisuuden hyödyntää myös KATSO-tunnistautumista.

Palvelu tarjotaan julkishallinnon asiointipalveluille SAML-rajapintaan perustuen. Palvelun lähdekoodi on vapaasti saatavilla.

Palveluväylä

Palveluväylä on Virossa kehitetyn yhteiskunnan taustaväylä X-Road:n suomalainen instanssi jolla voi myös tunnistaa ja jossa välittyy asioijien metatietoja joita ei lyödy tunnisteesta. Liittyminen vaatii liittymäsopimuksen, oman liityntäpalvelimen ja siitä on ?? kustannuksia kuukausittain.

PEPS

Euroopan Unioni toteuttaa eIDAS-direktiivin mukaista kertakirjautumispalvelua PEPS-palvelinverkostolla johon eri palveluntarjoajien on tarkoitus liittyä. Hanke on monella tapaa päällekkäinen Palveluväylän kanssa, mutta keskittyy ainoastaan tunnistamiseen ja allekirjoittamiseen. Vaikka PEPS-palvelun tunnisteina on yleensä henkilökortti, erona suoraan PKI-tunnistukseen on asioijan metatiedot joita eri jäsenvaltioiden lainsäädännön ja toteutuksen takia ei ole tallennettu kortille, eikä enintä osaa tiedoista edes välitetä HTTPS/SSL-yhteyden mukana.

Suomessa PEPS-palveluntarjoaja tulee olemaan Väestörekisterikeskus.

Muu maailma

Jos on tarve tunnistaa koko maailman verkon käyttäjät, asia menee monimutkaisemmaksi.

Kolmannen osapuolen sisällöt / Avoin data

Jos palvelu käyttää hyväkseen esimerkiksi karttoja verkkosivuillaan, mistä niitä saa ja millä ehdoilla?

Kartat

Tapahtuman käsittely

Tapahtuman elinkaaren eri vaiheisiin löytyy asiointia edistäviä teknisiä ratkaisuja.

Muodot

Tapahtuman muodot ovat yleisesti tehtyjen tapahtumien spesifisiä muotoja, formaatteja joilla saadaan koneluettava automaatio toteutettua helpommin. Klassinen esimerkki yleisestä tapahtuman muodosta on laskutus, mutta ostotapahtuman muihin vaiheisiin löytyy määrityksiä ja niitä kehitellään lisää mm EU-tasolla.

Allekirjoitus

Allekirjoitus sitoo osapuolet tapahtuman todistavaan dokumenttiin. Aihe on ollut vaikea Suomessa pitkään eikä siitä ole vieläkään laajalle levinnyttä, vaikiintunutta käytäntöä joka olisi kaikkien osapuolien hyväksymä ja tunnustama. Epäselvyyttä on lähes kaikesta: takaajasta, käytännön toteutuksesta (tavasta, allekirjoitusmuodosta, tallennuspaikoista jne).

Maksaminen

Perintä

Käyttäjätilastot

Google Analytics (analytics.google.com)

Chartbeat (chartbeat.com)

Woopra (woopra.com)

Pilvipalvelut

Sopimukset

Palvelun toteutusta tilattaessa kannattaa miettiä sen eri elinkaaren vaiheita ja palvelun osien ja siihen syötetyn sisällön oikeuksia. Automaattisesti tulee ajateltua, että ainakin sisältö on palvelun omistajan omaisuutta. Miten toimia tilanteessa jos järjestelmä lakkaa toimimasta tai se tulee rakentaa uudelleen - joko saman toteuttajan tai nykyisen kilpailijan avustamana? Onko se mahdollista ja mielekästä? Mitä se kaikki maksaa ja kauanko se kestää? Onko halvempaa ja nopeampaa aloittaa tietojen syöttö alusta? Onko se edes mahdollista jos järjestelmä on tuottanut osan tiedosta?

Monet palvelut sisältävät tietokannan joka yleensä on SQL-tyyppinen relaatiotietokanta. Tietokanta koostuu tauluista, sen sarakkeista, taulujen välisistä sidoksista ja monesta muusta yksityiskohtaisesta määrittelystä jonka tekeminen on vaativaa ja aikaa vievää. Tietokannan rakenteen kuvaus on siis itsessään jo arvokas ja voi täyttää immateriaalisen teoksen tunnusmerkit.

Omistaja yleensä haluaa palvelustaan säännölliset varmuuskopiot (eng database dump) kaiken varalle. Tietokannasta - tai vastaavasta tehtynä se paljastaa tekotavan ja mahdollistaa ratkaisun monistamisen rajatta. Immateriaalinen teos siis siirtyy toteuttajalta asiakkaalle. Mitkä ovat sen käyttö- ja levitysoikeudet? Saako sillä tai sitä hyödyntäen rakentaa palvelun uudelleen? Toisen toteuttajan, kolmannen osapuolen avustamana? Käyttäen samoja - tai kilpailevan toteuttajan komponentteja? Koskevatko oikeudet vain palvelun nykyistä omistajaa vai myös kolmatta osapuolta joka osti palvelun tai sen nykyisen omistajan?

Mitä jos omistaja ei saa, tai ei ole saanut vuosikausiin kopiota tiedoistaan? Niistä on otettu varmuuskopiot, mutta ne ovat toteuttajan hallussa. Mitä jos osapuolet riitaantuvat, esimerkiksi nousseista hinnoista - tai syötetyn sisällön omistajuudesta keskustellessa - ja palvelusopimus lakkaa, pahimmassa tapauksessa palvelu sammuu verkosta samalla?

Omistajan syöttämien tietojen hallitseminen - olivat ne sitten toteuttajan tai omissa tiloissa, on mahdollista jos niiden normaalia käyttöä laajempi hyödyntäminen on estetty teknisellä muodolla (ei esimerkiksi luovuteta tekstimuotoista tms luettavaa tietokannan varmuuskopiota) tai pääsynestolla. Hallinnan menetys nostaa lähtökynnystä (barrier to exit) ja saattaa laskea kynnystä kovempaan hinnoitteluun tai muihin sopimusehtoihin kun tiedetään, että toteutuksen kilpailuttaminen on vaikeaa tai mahdotonta ilman toteuttajan suostumusta.

Kummankin osapuolen näkemys on ymmärrettävä:

  • Tietokantasuunnittelu on kallista ja helposti monistettavaa/väärinkäytettävää arvoa, sitä halutaan suojella. Toisaalta alan kilpailu on kovaa ja kokonaisuuden oikeuksista, riitapykälistä ja yhteistyön lopettamisen yksityiskohtia ei haluta tuoda esille hankinta/tarjousvaiheessa.
  • Voisi olettaa, että tiedon tuottaja ja lähde omistaa - sekä hallitsee tietonsa täysin. Näin ei kuitenkaan aina ole, koska asia ei ole tullut mieleen hankinta/kilpailutusvaiheesa. Jälkikäteen asiaa on enää vaikea sopia jos oma tieto on jo ulkopuolisen kontrollissa ja tyydyttävään sopimukseen ei olisi päässyt hankintavaiheessakaan.

Tärkeintä olisi, että molemmille osapuolille on selvää alusta asti:

  • kenen omaisuutta sisältö on
  • kenen omaisuutta palvelun mahdollinen ohjelmakoodi on
  • kenen omaisuutta palvelun visuaalinen suunnittelu ja toteutus on (ulkoasu)
  • kenen omaisuutta sen tekninen kuvaus on (esim tietokannan rakenne)
  • mitkä edelläolevien käyttöoikeudet ovat
  • missä muodossa tiedot on tallennettu (jokin tunnettu relaatiotietokanta ja/tai yhdistelmä tms)
  • missä sisällön tallennus sijaitsee fyysisesti (omistajan, toteuttajan vai kolmannen osapuolen tiloissa)
  • kenellä on rajoittamattomat pääsyoikeudet (tai kopiot) palvelun osiin (ulkoasu, ohjelmakoodi) ja sisältöön (tietokanta, tiedostot)
  • kuka ottaa eri osista varmuuskopiot, missä muodossa (tietokannan varmuuskopio, XML-kuvaus tms) ja mihin
  • saako omistaja säännöllisen varmuuskopion jota voi itse - tai palkattu kolmas osapuoli tulkita ja millä ehdoin
  • jos varmuuskopio ohjelmakoodeista ja sisällöstä luovutetaan, onko niiden toimivuutta / pystyttämistä kokeiltu säännöllisesti

Kaikka ylläolevaa olisi hyvä miettiä jo ennen hankintapäätöstä. Kannattaa miettiä mitä tapahtuu jos osapuolet riitaantuvat ja keskeyttääkö riitaantuminen / sopimuksen tulkinta esim oikeudessa palvelun toiminnan tai sen kehittämisen / siirtämisen uuteen palvelimeen, ohjelmointikieleen, tietokantaan jne. Missä maassa ja missä sen instanssissa erimielisyydet ratkotaan? Mitkä ovat osapuolien vaitolovelvollisuudet? Onko yllämainittuja kohtia mainittu sopimuksessa ja mitä niiden rikkomisesta seuraa? jne yleiset sopimusasiat.

Aiheesta muualla:

Katso myös

Lähteet

  1. ↑ More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack
  2. ↑ finlex.fi - Henkilötietolaki 523/1999 Viitattu: 2016-03-07

Aiheesta muualla

Noudettu kohteesta ”http://digisaatio.fi/mediawiki/index.php?title=Palvelulle&oldid=5902”