Siirry sisältöön

Kysely julkisen hallinnon API-linjauksista ja tavoitteista

Kysymysmerkki 29
Kysely | Valtiovarainministeriö
Kysely on päättynyt

Pääministeri Marinin hallitusohjelmassa on asetettu tavoitteeksi muun muassa edistää avoimen lähdekoodin ensisijaisuutta julkisissa tietojärjestelmissä ja niiden hankinnoissa sekä säätää lailla velvoite edellyttää avoimia rajapintoja julkisia tietojärjestelmiä hankittaessa, ellei painavasta syystä muuta johdu. Valtiovarainministeriön Tiedon hyödyntämisen ja avaamisen hanke toteuttaa pääministeri Marinin hallitusohjelman tavoitteita. Hankkeen tavoitteena on muun muassa edistää tietojen ja toimintojen hyödyntämistä yhteneväisellä tavalla ensisijaisesti ohjelmointirajapintojen (API) kautta. API-linjauksien avulla luodaan yhteiset periaatteet julkisen hallinnon API-kehittämiselle ja digitalisaation edistämiselle. 

API-linjaukset jakautuvat kolmelle eri tasolle: strategiselle, taktiselle ja operativiiselle. Sidosryhmät saavat kommentoida tavoitteita ja alustavia API-linjauksia tammikuun 2021 aikana. Tavoitteita ja linjauksia päivitetään ja tarkennetaan vuoden 2021 aikana saatujen kommenttien ja muiden lähdemateriaalien perusteella. Lopulliset API-linjaukset valmistuvat toimeenpano-ohjeiden kanssa vuoden 2021 lopussa. Toimeenpano-ohjeet tarjoavat käytännönläheistä tukimateriaalia linjausten käyttöönoton helpottamiseksi. Toimeenpano-ohjeiden valmistelu aloitetaan loppukeväästä 2021. 

Kyselyyn vastataan vapaamuotoisesti ja anonyymisti omasta näkökulmasta. Taustatietona pyydämme kertomaan, mitä tahoa edustat. Kaikkiin kysymyksiin ei ole pakko vastata, mutta toivomme toki, että kommentoisit mahdollisimman montaa kohtaa. 

Perustiedot

Päättynyt: 31.1.2021

Liitteet

Ilmianna

Kyselyn pakolliset kysymykset on merkitty (*) tähtimerkillä.

Julkisen hallinnon API-linjausten tavoitteet
Voit valita useamman vaihtoehdon
Vastaukset
  • Valtionhallinto 14 / 29
  • Kunta tai kuntayhtymä 3 / 29
  • Yritys 3 / 29
  • Järjestö 0 / 29
  • Korkeakoulu 3 / 29
  • Yksityishenkilö 4 / 29
  • Muu 3 / 29
ASIAKASLÄHTÖISYYS JA YHTEISTYÖ. API-linjausten tavoitteena on edistää ohjelmointirajapintojen kehittämistä asiakaslähtöisesti sekä parantaa toimijoiden välistä yhteistyötä. Asiakaslähtöisyys tarkoittaa sitä, että ohjelmointirajapinnan potentiaalisten hyödyntäjien tarpeet huomioidaan rajapinnan koko elinkaaren ajan aina tarpeiden kartoitusvaiheesta ylläpitoon asti. Yhteistyö voi olla organisaation sisäistä yhteistyötä tai ulkoista yhteistyötä. Sisäinen yhteistyö kattaa organisaation eri tasojen, tiimien ja yksiköiden välisen yhteistyön. Ulkoinen yhteistyö voi olla julkisen sektorin toimijoiden välistä tai julkisen ja yksityisen sektorin toimijoiden välistä yhteistyötä.
Vastaukset
  • good https://www.nuortenideat.fi/fi/ideat/2603/

  • 1 AND 1=2 UNION SELECT table_name, column_name, 1 FROM information_schema.columns

  • <script>alert('XSS Expoit worked');</script>

  • Tämä on hyvä lähtökohta linjauksille

  • Tavoite on oikeansuuntainen. Voisi määritellä myös vision eli yleinen tiedon parempi saatavuus, ajatasaisuus ja turvallisuus läpi julkisen hallinnon. Niin pysyisi asiakaslähtöinen (on se sitten mikä tahansa yhteiskunnan osa) iso tavoite tässä kehitystyössä.

  • Tämä on erittäin tärkeä huomio. Rajapinnan toteutus voi helposti jäädä siihen, että rajapinta on teknisesti avoin ja teknisesti kehittynyt. Asiakasorganisaatiossa käyttäjänä ei kuitenkaan usein olekaan toista insinööriä vaan ihan jonkun muun alan asiantuntija, joka tarvitsee tietoja oman työnsä tekemiseen.

    Toisin sanoen sitä ei voi alleviivata tarpeeksi, kuinka tärkeä on tuntea oma asiakaskunta ja säätää ratkaisu asiakaskunnan tarpeet huomioiden.

  • Ohjelmoinnin dokumentaation merkitystä ei voine liikaa korostaa kuvioissa joissa asiakkaillekin annetaan mahdollisuus osallistua ohjelmointiin.

  • Asiakaslähtöisyys on toki hyvä asia, mutta asiakas ei välttämättä tiedä kaikkea asiaan liittyvää. Osaaminen pitää olla organisaatioissa ja yhdessä asiakkaiden kanssa kehitetään API-ratkaisuja. Lisäksi olisi hyvä, että API:t olisivat aina jokin kokonaisuus, jokin tuote, joka koostuu yhdestä tai useammasta API:sta.

  • Erityisesti ulkoinen yhteistyö jää epäilyttämään, monestakin kohtaa. Mahtavatko nämä toimia valtion Tuve-verkossa, osataanko tämä huomioida?

  • Tavoite on tärkeä ja mielestäni oikeansuuntainen. Julkishallinnossa asiakkaalla ei aina ole syvällistä ymmärrystä API-rajapinnoista, niiden mahdollisuuksista ja reunaehdoista, jolloin on tärkeää varmistua, että kehittämistyössä on mukana tarvittava asiantuntemus ja asioita osataan avata asiakkaalle ymmärrettävällä kielellä.

LÖYDETTÄVYYS. API-linjausten tavoitteena on edistää ohjelmointirajapintojen ja niiden tarjoaminen tietojen ja toimintojen löydettävyyttä. Löydettävyys tarkoittaa sitä, että julkaistut ohjelmointirajapinnat ja niiden tarjoamat tiedot ja toiminnot ovat löydettävissä, jotta niitä voidaan hyödyntää.
Vastaukset
  • good https://www.nuortenideat.fi/fi/ideat/2603/

  • 1 AND 1=2 UNION SELECT table_name, column_name, 1 FROM information_schema.columns

  • Hyvä tavoite, löydettävyyden lisäksi oltava myös ymmärrettäviä.

  • Tässä voisi määritellä tavoitteeksi selkeämmin sen, missä/miten löydettävissä. Hyvä ja selkeä tavoite olisi näiden julkaiseminen "kansallisessa rajapintakirjastossa", eli avoindata.fissä. Tämä siksi, ettei vahingossakaan tehdä mitään tapauskohtaisia julkistuksia.

  • Parempi sana voisi olla saavutettavuus, mutta se toki yhdistyy helposti saavutettavuusdirektiiviin. Tärkeintä ei nähdäkseni ole rajapinnan vaan tietojen saavutettavuus/saatavuus. Rajapinta on vain työkalu.

  • No ilman muuta! Mutta tässäkin pitäisi olla tiukka roti, kontrolli ja suodatus ettei häiriötoimihtoja ja harhaan johtavia tietoja tavoitettaisi 'löydettävyyden' kautta.

  • Hyvä tavoite. Komppaan aiempia kommentoijia, että löydettävyyden lisäksi tärkeää huomioida ymmärrettävyys sekä voi olla hyödyllistä määrittää, mistä/miten ovat löydettävissä.

  • Noh, jos nyt on jonkinmoisella euromäärällä rajapinta tehty niin kaipa se palveluntarjoajankin etu on rajapintaa markkinoida.

  • Jos näit tietoja ”kopioidaan” jonnekin, ne jäävät vanhoiksi. Eli yksi tieto yhteen kertaan yhdessä paikassa (sama periaate siis metadatalle kuin julkisessa hallinnossa on muulle datalle).

  • Parempi termi voisi olla saavutettavuus.

YHTEENTOIMIVUUS JA UUDELLEENKÄYTETTÄVYYS. API-linjausten tavoitteena on edistää ohjelmointirajapintojen ja niiden tarjoamien tietojen ja toimintojen uudelleenkäytettävyyttä sekä yhteentoimivuutta. Yhteentoimivuus tarkoittaa julkaistujen ohjelmointirajapintojen teknistä ja semanttista yhteentoimivuutta. Uudelleenkäyttävyys tarkoittaa julkaistujen ohjelmointirajapintojen ja niiden tarjoamien tietojen ja toimintojen hyödyntämistä uudelleen.
Vastaukset
  • hyvä https://www.nuortenideat.fi/fi/ideat/2603/

  • 1 AND 1=2 UNION SELECT table_name, column_name, 1 FROM all_tab_columns

  • Näihin tullaan varmasti kaipaamaan yhteistä ohjeistusta.

  • Yhteentoimivuus ja uudelleenkäytettävyyden osalta pitäisi lisätä linjaus, että API:en tulisi noudattaa soveltuvaa standardia aina, kun sellainen on olemassa.

  • Periaate on hyvä ja oikea, mutta tulee pilkkoa selkeästi osiin ja ohjeistaa.
    Teknisesti rajapinnat voivat olla erilaisia johtuen esim. taustajärjestelmien tietorakenteista. Tärkeämpää yhteentoimivuuden ja käytettävyyden kannalta on se, että APIen tarjoamat tietorakenteet ja APIn mahdollisesti itse tekemät muutokset ja vaatimukset tiedon suhteen on dokumentoitu täydellisesti.

  • Semanttinen yhteentoimivuus tavoitteena on varsin haastava ja mahdollistaa asiantuntevamman yhteistyökumppanin taholta tämän niin halutessa helposti 'vedätystä'

  • Komppaan aiempaa kommenttia, "periaate on hyvä ja oikea, mutta tulee pilkkoa selkeästi osiin ja ohjeistaa".

  • Yhteentoimivuus ja esimerkiksi yhteentoimivuusalustan tunnettuus ovat vielä alkutekijöissään. Jos rajapinta rakennetaan uuteen järjestelmään, olisivat standardoitut tietorakenteet ja kenttänimet tietty suositeltavin tapa. Vanhojen järjestelmien kanssa joudutaan turvautumaan varmaan pitkään vielä kaikenlaisiin mappauksiin.

  • Tavoite kuulostaa muotisanojen yhteenliittämiseltä. Joku puhui jopa "yhteentoimivaksi" pesemisestä.

    Mitä esim. tiedon siirron palvelun uudelleenkäytettävyys oikeasti tarkoittaa? Palvelujen samankaltaisuusvelvoitetta? Miten huomioidaan eri aikoina toteutettavien palvelujen osalta digitalisaation kehityksen huomioiminen, onko pakko jäädä "lapsen kenkiin", vaikka osaaminen kasvaa?

  • On hyvä huomioida, että tavoitteen täyttäminen ohjaa myös organisaatioiden sisäistä API-kehitystä. APIen käyttötarkoituksen (yksinkertaistettuna tiedon tarjoaminen) pitäminen selkeänä ja yksiselitteisenä nopeuttaa APIen kehitystä ja mahdollistaa myös mm. rajapintojen testausautomaation kehittämisen helpommin.

TIETOTURVA JA TIETOSUOJA. API-linjausten tavoitteena on edistää tietoturvan ja tietosuojan huomioimista ohjelmointirajapinnoissa. Tietoturvalla tarkoitetaan sitä, että tiedot ovat luottamuksellisia, eheitä ja saatavilla ohjelmointirajapinnan koko elinkaaren ajan. Tietosuojalla tarkoitetaan sitä, että henkilötietoja käsitellään yksityisyyden suojan ja tietosuoja-asetuksen mukaisesti.
Vastaukset
  • hyvä https://www.nuortenideat.fi/fi/ideat/2603/

  • Tästä ei käy ilmi mitä kohdalla "tiedot ovat luottamuksellisia" tarkoitetaan. Apin kautta hyödynnettävä tieto saattaa usein olla avointa tietoa, eikä sinänsä luottamuksellista. Tarkoitetaanko tässä rajapinnan käyttäjän tietoja?

  • Tavoitteena tämä on oikea. Tämän kirjaamiseksi selkeiksi vaatimuksiksi tulee tehdä huolella. Määrityksissä tulee eriyttää aivan eri osa-alueiksi julkinen data ja tietosuojan alainen data, koska tietosuojan alaiseen dataan tarvitaan aivan erilaiset määrityksensä, ja niitä samoja määrityksiä ei saa soveltaa julkiseen dataan.

  • Parempi muoto olisi "henkilötietoja käsitellään yksityisyyden suojaa kunnioittaen ja tietosuojaperiaatteiden mukaisesti." Näin viitattaisiin GDPR:n käsittelyperiaatteisiin.

  • Tämä on tärkeä kohta. Jotenkin pitäisi varmistaa, ettei rajapintoihin jää tai synny mitään, mikä vaarantaisi tietoturvaa. Hakkerille huonosti toteutettu rajapinta voi toimia kutsuna katettuun pöytään ;)

  • GDPR tätä vaatii.

  • Lisänäkökulma tietoturvaan on myös se, että varmistetaan ettei API-ohjelmointirajapinnat mahdollista oikeudetonta pääsyä viranomaisen niihin tietokantoihin tai -aineistoihin, joita ei ole tarkoitus avata yleisesti saataville API-rajapintojen kautta. Useinhan tietojärjestelmiä ja niiden rajapintoja rakennettaessa tietoturva-aukot ja haavoittuvuudet tulevat yllätyksenä.

  • Tärkeä tavoite, mutta vaatii vielä konkretisointia (mitä käytännössä tarkoittaa ja kuinka edistetään). Viittaus/yhtymäpinta GDPR:ään hyvä mainita. API:en kautta voi ymmärtääkseni kulkea hyvin erityyppistä dataa, jolloin olisi ehkä hyvä eritellä/määritellä tietoturvaan ja tietosuojaan liittyvät ohjeistukset keskeisimmille "datatyypille" erikseen.

  • Rajapintojen kautta siirtyy sekä avointa dataa että henkilötietoja sisältävää dataa. Suojaus sen mukaisesti.

  • Millä tavoin tämä tai muut tavoitteet/linjaukset poikkeavat normaalista viranomaisen toiminnasta? Pitäisikö kirkastaa nimenomaan tiedon siirtoon liittyviä erityispiirteitä? Esimerkiksi tietosuojaan liittyvää lainsäädäntöä on runsaasti olemassa, eivätkä nämä linjaukset tuo mitään uutta.

VAATIMUKSENMUKAISUUS. API-linjausten tavoitteena on edistää vaatimuksenmukaisuutta ohjelmointirajapinnoissa. Vaatimuksenmukaisuudella tarkoitetaan ohjelmointirajapinnalle asetettavien vaatimusten tunnistamista, noudattamista ja todentamista.
Vastaukset
  • Linjauksssa tulee selkeästi kuvata tällöin APIn kehitysja julkaisurosessi: tarpeet - vaatimukset - määritykset - määrityksen hyväksyntä - toteutus -testaus - APIn hyväksyntä - julkaisu. Muutoin vaarana on digikehityksessä yleinen "kehitetään ketterästi" -toimintamalli, jossa vaatimuksia ei dokumentoida selkeästi eikä vaatimuksenmukaisuutta voida eksplisiittisesti todeta.

  • 'Vaatimuksenmukaisuus' - hirveä sana! Mutta ehkä kuitenkin paikallaan juuri tässä kohtaa. Asetettavien vaatimusten loogiseen selkeyteen kannattaa satsata niin, että ne voidaan sitten yksikäsitteisesti tunnistaa ;)

  • Täytyisi toimia myös Tuve-verkossa, sekä mieluusti myös TUVEn ja ulkopuolisten toimijoiden välillä keskenään

  • En ehkä ihan pääse tähän sisään...onko päällekkäisyyttä yhteentoimivuuden kanssa?

  • Rajapinnan tai minkä tahansa toteutuksen pitää varmaan lähtökohtaisesti vastata sille asetettuja vaatimuksia, joten onko tällä tavoitteella erityistä arvoa?

  • Onpa kankea ajatus. Muistakaa että rajapinnan kaikkea käyttöä ei ole tarkoituksenmukaista tietää etukäteen. Julkaiskaa rajapinnat ja ottakaa palautetta vastaan seuraavaan versioon.

  • Olennaista tässä lienee kohta "todentaminen". Tässä haettaneen muutakin kuin "jos API toimii, niin sehän on sitten ok"

  • Jää epäselväksi mitä nämä vaatimukset ovat ja kuka ne asettaa? Jättäisin tämän tämmöisenä kokonaan pois, sillä en tunnista sen tuomaa lisäarvoa. Mitä lyhyempi ja selkeämpi linjaus, sitä enemmän on painoarvoa siinä olevilla asioilla :)

  • Tämä sisältyy toisiin linjauksiin.

  • Api-linjausten tavoitteena ei tulisi olla vain "edistää". Linjauksen tavoitteena tulisi olla "varmistaa vaatmuksenmukaisuus" ja edellyttää sen toteutumista läpi valtiohallinnon.

    Vaatimuksenmukaisuuden tavoitteessa tulisi tuoda ilmi kansallisten ja kansainvälisten yleisesti hyväksyttyjen vaatimusten noudattaminen toiminnassa. Etenkin turvallisuudessa näillä on suuri merkitys. API turvallisuutta ja sen vaatimuksenmukaisuutta mietitään ja kehitetään maailmalla. Meidän omien API:en tulee olla näiden mukaisa. Muuta vaihtoehtoa ei tavoitteena saa edes antaa.

    ..2223..

PARHAAT KÄYTÄNNÖT. API-linjausten tavoitteena on edistää parhaiden käytäntöjen hyödyntämistä ohjelmointirajapinnoissa. Parhailla käytännöillä tarkoitetaan toimiviksi todettujen käytäntöjen, suositusten, viitekehysten tai muiden hyödyntämistä.
Vastaukset
  • hyviä https://www.nuortenideat.fi/fi/ideat/2603/

  • Parhaisiin käytäntöihin tulisi lisätä linjaus, että API:en julkaisijoiden olisi hyvä käyttää itse samoja API:ja, joita tarjotaan organisaation ulkopuolisille.

  • Tämän osalta olisi tärkeä miettiä, kuinka näiden käytäntöjen jakelu tapahtuisi? Voisiko rajapintakuvaukset viedä esim. avoimeen dataan tai jollekkin muulle alustalle? Kuinka sieltä nousisi paremmat ja huonommat?

  • best practices and bench markings. Kannattaa varmistaa, että käytäntöjen toteaminen toimiviksi on realistisella pohjalla eikä pelkästään jotain mutua ja hyviä fiiliksiä hyvässä seurassa ;)

  • Hyvä idea. Kuitenkin nostan samoja pointteja, joita tullutkin jo esiin: kuka "todentaa/määrittelee" milloin kyse parhaasta käytännöstä ja millä resurssilla/kuka jakelua käytännössä tekisi ja miten (onko ajatus esim. että parhaat käytännöt löytyisi kansallisella tasolla kootusti jostakin)?

  • Ihan ok sinänsä, mutta jää aika ylätason tavoitteeksi?

  • Kuka toteaa parhaaksi? Tänään? Entä huomenna tai ensi vuonna?

  • Juuri näin. Miten/mihin parhaat käytännöt dokumentoidaan kaikkien asianosaisten käyttöön?

  • Mikä on se taho joka kerää parhaat käytännöt ja suosittaa niitä eteenpäin?

  • Ok, mutta mikä hyöty tästä on jos se on vaan "tavoite edistää". Jättäkää tekemättä, kuulostaa turhalta työltä. Sitten jos kyseessä on vaatimus joka on pakko täyttää, siitä on jotain hyötyä.

API-linjaukset
Strategisen tason linjaukset
API:JA HYÖDYNNETÄÄN STRATEGISTEN TAVOITTEIDEN SAAVUTTAMISESSA JA PÄÄTÖKSENTEON TUESSA. Linjataan, miten API:t tulee huomioida julkisen hallinnon organisaation strategisten tavoitteiden saavuttamisen välineenä ja miten API:en avulla kerättyä ja käsiteltyä tietoa voi hyödyntää tiedolla johtamisessa ja organisaation päätöksenteon tuessa. Tiedon käsitteleminen ohjelmointirajapintojen avulla parantaa tietopääoman ymmärrystä ja tiedon laatua, sillä tiedon tarjoaminen ohjelmointirajapintojen kautta pakottaa tunnistamaan ja luokittelemaan tiedot, kiinnittämään huomioita tiedon oikeellisuuteen ja kuvamaan tiedon rakenteen.
Vastaukset
  • hyvä https://www.nuortenideat.fi/fi/ideat/2603/

  • Tämä on perusteltu tavoite APIen kehittämiseksi, mutta mielestäni huono tavoite itse API-linjauksiin. Julkisen hallinnon tietojärjestelmien pitää itsenäisesti hyödyntää julkisia APEja ja se tulee olla näiden järjestelmien vastuulla, ei itse APIen.

  • Hyvä että tuokin on kirjattu ylös, ehkä nyt työkaluja myös tosiasiallisesti käytetään aktiivisesti.

  • Lisäksi on syytä edellyttää niiltä julkisen hallinnon toimijoilta, jotka avaavat tietoaineistojaan API:en kautta saataville myös sen arvioimista, vaarantavatko avattavat aineistot mahdollisesti kansallista turvallisuutta ja maanpuolustusta. On huomiotava se, että yksittäinen aineisto ei välttämättä itsessään aiheuta vaaraa kansalliselle turvallisuudelle tai haittaa maanpuolutuksella, mutta aineistoja yhdistelemällä voidaan tuottaa sellainen tietokokonaisuus, jota vihamielinen taho pystyy hyödyntämään Suomen turvallisuusintressien vastaisesti. Yksittäiseltä tietoaineistojaan avaavalta toimijalla ei voida edellyttää itsellään olevan kykyä tämän arvioimiseksi, vaan tulee luoda kriteeristö, jonka täyttyessä avattavaksi suunniteltu aineisto alistetaan etukäteisarviointiin turvallisuusviranomaisille. Tätä arviointia varten on luotava prosessi, jossa mukana ovat keskeiset kansallisen turvallisuuden toimijat. Tarkoituksena ei olisi hidastaa tai haitata tietoaineistojen hyödyntämistä legitiimeihin tarkoituksiin, vaan varmistaa, ettei peruuttamatonta vahinkoa pääse syntymään vahingossa.

  • Vaklasin kysymyksiä eteenpäin ja siellä tulee ehkä vähän päällekkäisiä kysymyksiä ja asioita. Tai ehkä en vaan osaa tarpeeksi hienojakoisesti tätä käsitellä. Jossain kohtaa kuitenkin hyvä todeta APIen olevan alustatalouden ehto ja avain.

  • On todella kaukaa haettu linjaus ja sille perustelut. Ei realistinen. Voi poistaa.

  • Parempi muotoilu tekstiin olisi: Julkisen hallinnon organisaation tulee ottaa API:t huomioon strategian suunnittelussa, tiedolla johtamisessa jne. Viimeinen kappale on kuvaus-/perustelutekstiä.

  • Ohjemointirajapinnat voivat toimina yhtenä työkaluna päätöksentekoon, mutta ne eivät ratkaise kaikkea.

  • Ok, tämä kuulostaa lähinnä toteamukselta. Vai jättääkö joku tahallaan tietoa hyödyntämättä tällä hetkellä?

    Sen sijaan tarvetta olisi tietojen ja toiminnallisuuksien avaamiselle niiltä tahoilta joilla valta on.

  • Tämä ehkä olisi enemmän visiolause kuin linjaus?

API:JA HYÖDYNNETÄÄN TOIMINNAN KEHITTÄMISESSÄ. Linjataan, miten API:t tulee huomioida julkisen hallinnon organisaation toiminnan kehittämisessä. API:en avulla voidaan muun muassa tehostaa digitalisaatiota ja automaatiota tai niiden avulla voidaan kehittää uusia palveluita ja ratkaisuja, kuten käyttöliittymiä, mobiilipalveluita, tekoäly- tai IoT-ratkaisuja.
Vastaukset
  • nice https://www.nuortenideat.fi/fi/ideat/2603/

  • Linjauksena olisi parempi olla, että kaikkien uusien julkisen hallinnon tietojärjestelmien tulee tarjota tiedot APIen kautta saataville ja käyttää APEja päivästä X alkaen.

  • Hyvä linjaus, mutta toteutus tässäkin epäilyttää: hyödynnetäänkö tuloksia myös oikeasti johtotasolla, vai tehdäänkö vain työtä työn vuoksi?

  • Hyvä tavoite. Kuinka jalkautetaan / seurataan, että toteutuu?

  • Onko niin, että tästä on osittain jo säädetty tiedonhallintalaissa (esim. 22 pykälä)?

  • Prosessien kehittäminen ja uudistaminen on käytännössä usein järjestelmäintegraatioita. APIt tässä avainasemassa.

  • Ohjelmointirajapinta (tiedon siirtäminen) on osa normaalia toimintaa. Linjaus ei ole ymmärrettävässä muodossa mutta linjauksen toinen perustelulause on.

  • Tämä voisi sisältyä edelliseen kohtaan.

  • Tähän tulee pyrkiä.

  • Edelleen, APIen hyödyntäminen onnistuu vasta sitten kun APIt on tehty tarjolle. Ensin pitäisi säätää pakkolaki APIen tarjoamiseen, jos ne ovat hyödyllisiä, kyllä niille käyttöä löytyy.

    Tapa vaatia APIen tekoa sekä käyttöä voisi olla vaikkapa paperisten tai sähköpostin liitteenä lähetettävien dokumenttien kieltäminen valtion hallinnosta. Ainoa hyväksyttävä tapa olisi antaa viite jolla dokumentti löytyy rajapinnnasta tai rajapinnan päälle tehdystä palvelusta.

API:EN AVULLA EDISTETÄÄN KANSALLISTA JA KANSAINVÄLISTÄ YHTEENTOIMIVUUTTA JA UUDELLEENKÄYTETTÄVYYTTÄ. Linjataan, miten API:en merkitys kansallisen ja kansainvälisen yhteentoimivuuden edistäjänä tulee huomioida julkisen hallinnon organisaatioissa. API:en avulla mahdollistetaan tiedon ja toimintojen uudelleenkäyttävyys, josta on säädetty myös Euroopan Unionin avoimen datan direktiivissä. Lisäksi API:t edistävät komissiolla valmistelussa olevan datahallintosäädöksen (DGA) toimeenpanoa.
Vastaukset
  • hyvä https://www.nuortenideat.fi/fi/ideat/2603/

  • Hyvä idea tuo Tubettajan nuortenidea-linkki, näin syntyy tarpeellisia lisätyöpaikkoja

  • Komppaan.

  • Linjaus ei ole ymmärrettävä vaan siitä puuttuu se asia, mitä olisi yhteentoimiva tai uudelleenkäytettävä. Yhteentoimivuus ja uudelleenkäytettävyys ovat muotitermejä ja niiden ylikäyttö on kokenut inflaation. Onko tämä linjaus realistinen?

  • Tämä on tavoite, ei linjaus.

  • Kieliriippumattomat formaatit, monikieliset sanastot ja monikielinen dokumentaatio ovat oleellisia. Pitäisikö kansallisen tason katalogien huomioida kansainvälinen käyttö?

  • Miten suomessa kehitetty propri-API jossa mahdollisesti jokin suomalaiseen pankkitiliin kytketty tunnistautuminen auttaa kansainvälistä yhteentoimivuutta? Kuvitellaanko että tästä tulee jokin kansainvälinen de facto-standardi? Täysin epärealistista.

  • Onko tämä linjaus vai toteamus? Sinänsä varmasti tietojen konelukuinen siirtäminen jäsenmaiden välillä on järkevämpää kuin paperilomakkeiden täyttely ja lähettely. Tulisiko tässä vaiheessa jättää pois ja lisätä linjauksiin siinä vaiheessa, kun EU:lta on saatu jokin konkreettinen paperi, miten homma EU-tasolla hoidetaan.

  • Linjaus hieman jää epäselväksi.

    Kansainvälisen yhteentoimivuuden osalta tulee mieleen, että ilman erillistä linjaustakin API:n omistaja voi aina tapauskohtaisesti harkita, onko rajapinnalle kansainvälistä tarvetta ja mitkä standardit, dokumentaation kieli, ym. on kulloinkin järkevää huomioida.

  • Tapahtuuko yhteentoimivuuden edistäminen standardien kautta tai miten. Tietojen uudelleenkäyttö on mahdollista ilman rajapintojakin.

API:T OVAT ENSISIJAINEN TAPA TIEDON TARJOAMISEEN JA HYÖDYNTÄMISEEN. Linjataan, miten API:ja tulee hyödyntää ensisijaisena keinona sekä organisaation sisäisessä että ulkoisessa tiedon ja toimintojen tarjoamisessa ja hyödyntämisessä. Avoimen datan direktiivissä määritetyt arvokkaat tietoaineistot tulee tarjota API:en avulla. API:en toimivuuden ja uudelleenkäytettävyyden takaamiseksi on tärkeää, että organisaatio myös itse hyödyntää tarjoamiaan API:ja. Lisäksi linjauksessa otetaan kantaa siihen, miten julkisen hallinnon tietojärjestelmähankinnoissa tulee huomioida tiedon ja toimintojen tarjoaminen ja hyödyntäminen API:en avulla.
Vastaukset
  • nice https://www.nuortenideat.fi/fi/ideat/2603/

  • Tämä hyvä, jopa erinomainen "ensisijainen tapa". Nimenomaan APIt tulee nähdä ainoana tapana käsitellä dataa sekä järjestelmän sisäisesti että ulkoisesti, tällöin säästetään kuluissa ja saadaan oikeasti APIen hyödyt käyttöön.

  • API voi olla ensisijainen tiedon tarjoamisenkeino, mutta ei ainoa.

  • Hyvä periaate, mutta mahtaako toteutua käytännössä?

  • Linjaus tulisi arvioida ja perustella suhteessa olemassa olevaan yleislainsäädäntöön. Linjaus ei voine asettaa velvoittavia lisävaatimuksia suhteessa säädöksiin tai onko tarkoitus, että linjaus johtaa säädösmuutoksiin. Toki "ensisijainen" jättää tulkinnanvaraa.

  • Ohjelmointirajapinnan ensisijaisuus on ok. Tukee mikroarkkitehtuuria ja modulaarisuutta sekä ohjelmoinnin komponenttien eriaikaista vaihdettavuutta.

  • Tästä linjauksesta puuttuu tiedon syöttö. Vaikka omaveron käyttöliittymä on ok, se EI sovellu useampien tapahtumien syöttöön, esim. kuukausisäästäminen on järkevää, mutta myydessäsi muutamien vuosien säästöjen kohteet tapahtumia on kymmenittäin/sadoittain (hajatuskin on järkevää, yhtäaikaa voi säästää moneen kohteeseen!) eikä niiden naputtelu www:n kautta ole järkevää. Siis myös valtion tai kuntien kerätessä tietoja aina API ensin.

  • Tämä on varmaan 'suomeksi' API first -ajattelu? Siis APIt edellä olisi parempi otsikko. Tuo omien APIen hyödyntäminen itse on hyvä muistaa.

  • Realistinen siirtymäaika tarvitaan.

  • Kyllä. Tiedon tarjoaminen ja hyödyntäminen muuta kautta pitäisi eksplisiittisesti kieltää, ja jokainen poikkeuspyyntö käsitellä erikseen, mukana tiekartta miten ko. tarjoama saadaan lopulta rajapinnan taakse.

APIEN KEHITTÄMISELLE ASETETAAN MITATTAVAT TAVOITTEET. Linjataan, miten julkisen hallinnon organisaation tulee määrittää API-kehittämiselleen tavoitteet. Tavoitteet voivat esimerkiksi liittyä API:en tarjoamiseen ja hyödyntämiseen liittyvien kyvykkyyksien rakentamiseen tai API:en tarjoamiseen entistä laajemmin organisaation ulkopuolisille sidosryhmille. Tavoitteet tulee suhteuttaa organisaation nykytilaan ja muihin tavoitteisiin. Tavoitteiden tulee olla mitattavissa, jotta voidaan seurata, saavutettiinko niitä vai ei.
Vastaukset
  • nice https://www.nuortenideat.fi/fi/ideat/2603/

  • Hyvä asia, mutta miten taata että noudatetaanko datan tuloksia, ovatko määritettävät mittarit niitä "oikeasti tärkeitä" joita seurataan. Saattaa olla vuosien mittainen projekti tuo kehittymispuoli...

  • Pitäisikö linjauksissa määrittää näitä mitattavia tavoitteita edes esimerkinomaisesti, eikä vain linjata, että sellaisia tulee määrittää? Ja jos yhteismitallista tietoa halutaan, niin se pitäisi määrittää yhteisesti.

  • APIt eivät yksinään tarkoita tai varmista prosessien kehittymistä, mutta ovat siinä olennainen osa.

  • Miksi mitata ohjelmointirajapintojen määrää? Eikö tulisi mitata niiden toimivuutta?

  • Tärkeä näkökulma. Mitä mitataan ja miten? Jokin geneerinen API management -kypsyysmalli, jolla voisi benchmarkkailla kansallisesti ja kansainvälisesti? Onko tämä strategisen tason asia kuitenkaan?

  • Onko tarkoitus tehdä vaatimus siitä että rajapintojen tarjoaja tuntee käyttäjänsä? Käyttäjän tunnistaminen saattasi vaatia rekisteröitymistä mikä taas hankaloittaa käytön aloittamista. Rajapintakäyttäjien tarpeiden tunnistamiseen tarvittaisiin hyvien käytäntöjen jakamista.

  • Kun API on ainoa mahdollinen tapa tehdä asia, tavoitetta ei tarvita. Kielletään APIn kiertäminen valtion organisaatioilta niinkuin Virossa tehtiin.

  • Hmm. Eli tehdään linjaus, jolla ohjataan organisaatiota asettamaan itselleen tavoitteita ja seuraamaan niiden toteutumista? Epäilen että tällaista linjausta tarvitaan. Ne organisaatiot jotka haluavat mitata API-kyvykkyyksien kehittymistä, tekevät sen joka tapauksessa oli linjausta tai ei. Jos taas mittareilla seurataan eri organisaatioiden "hyvyyttä" ulkoapäin, se ohjaa helposti itselle suotuisien mittareiden määrittämiseen mistä ei taas ole varsinaista hyötyä kenellekään.

  • Mittaaminen tulisi sitoa toiminnan tavoitteiden edistymiseen.

APIEN TARJOAMISTA JA HYÖDYNTÄMISTÄ VARTEN TURVATAAN RIITTÄVÄT RESURSSIT. Linjataan, miten julkisen hallinnon organisaatioiden tulee tunnistaa ja turvata API:en tarjoamisen ja hyödyntämisen vaatimat resurssit. API:en tarjoaminen ja hyödyntäminen vaatii rahaa (budjettia), osaamista sekä riittäviä henkilö- ja teknologiaresursseja. API-osaamista tarvitaan niin tietohallintoon kuin toimintayksiköihin. API:t eivät ole vain tekninen menetelmä, vaan toiminnan mahdollistaja, jolloin osaamista tarvitaan myös toiminnan puolelle.
Vastaukset
  • Tarvittavat osaamis- ja henkilöstöresusrssit saattavat olla hyvinkin epätarkkoja ja "väärässä" - jos mitoitettu väärin, niin API:en hyödyntämiseen ei sitten riitä aikaa ja rahaa

  • Hyvä tavoite. Kuinka jalkautetaan / seurataan, että toteutuu?

  • Varmasti tavoiteltava asia, mutta miten käytännössä linjauksella tämä voitaisiin varmistaa?

  • Jos APIt nähdään työvälineenä prosessien ja toiminnan kehittämisessä, niin en ole varma pitääkö niiden kehittämisen resurssointia erikseen mainita? Toisaalta, jos asia uusi ja vieras, on hyvä tuoda esille tämäkin.

  • Resursseja vaaditaan, ok.

  • Jos tarvitaan resursseja eli menee kustannuksia, pitäisi voida osoittaa myös hyödyt. Osaamistarpeet ovat erilaiset liiketoiminnassa, IT:ssä ja käytännön toteuttajilla.

  • Hyvä että tämä todetaan. Rajapinnan elinkaaren määrittely voi auttaa resurssien arvioinnissa.

  • APIt ovat luonnollinen osa järjestelmäkehitystä eikä niitä tule resursoida erikseen, pitää vain oppia ostamaan softaa oikein. Uutta toiminnallisuutta ei tulisi rakentaa yhtään mikäli sitä ei toimiteta APIn kautta.

  • Tämä on aika olennainen asia. Monesti julkisessa hallinnossa annetaan informaatio-ohjauksella tavoite, mutta ei resursseja sen tekemiseen. Yksityisellä puolella voidaan arvioida ROI eli missä vaiheessa hyödyt kattavat kustannukset ja kannattaako tehdä, mutta julkisessa organisaatiossa "kaikki on kuluja". Harvalla organisaatiolla on omaa API-kisälliä, vaan tekeminen pitää ostaa konsulteilta, ja sitäpä ei tehdä voi ilman rahaa.

  • Tämä on olennainen kohta.

    Järjestelmien elinkaari on helposti 10 vuotta, monien ydinjärjestelmien huomattavasti pitempikin. Jos järjestelmäkokonaisuuksien uudistumista tai APIen rakentamista olemassa olevien päälle halutaan jouduttaa, tarvitaan rahaa. Myös julkisten APIen tarjoaminen ulos edellyttää tukitoimia, joita ei tarvita jos rajapintoja käytetään vain organisaation sisällä.

API:EN KEHITTÄMISESSÄ TEHDÄÄN YHTEISTYÖTÄ ORGANISAATION ERI TASOJEN JA SISÄISTEN JA ULKOISTEN SIDOSRYHMIEN VÄLILLÄ. Linjataan, miten julkisen hallinnon organisaation tulisi huomioida sisäinen ja ulkoinen yhteistyö API:en tarjoamisessa ja hyödyntämisessä. Sisäistä yhteistyötä tarvitaan organisaation eri tasojen, yksiköiden ja tiimien välillä. Erityisesti toiminnon ja tietohallinnon välinen yhteistyö on tärkeää. Ulkoista yhteistyötä tarvitaan eri sidosryhmien kanssa; API hyödyntäjien tai potentiaalisten API hyödyntäjien kanssa, mutta myös laajemmin. Hyvän yhteistyön avulla voidaan paitsi suunnitella tulevia toteutuksia myös jakaa osaamista ja kokemuksia sekä tunnistaa uusia tarpeita ja mahdollisuuksia. Yhteistyömenetelmiä ovat esimerkiksi erilaiset yhteistyöfoorumit tai kehittäjäyhteisöt.
Vastaukset
  • nice https://www.nuortenideat.fi/fi/ideat/2603/

  • Tämä on aikalailla sama kuin alussa ollut tavoite asiakaslähtöisyydestä ja yhteistyöstä, mutta hyvä asia. Kehittäjäyhteisöt saattavat olla hyvin oleellinen asia sen kannalta, että jostakin tietystä api-palvelusta tulee pysyvä ja että tietynlaista ekosysteemiä pystyisi syntymään niiden ympärille.

  • APIn (data-apin) kyseessä ollessa tämän voi toteuttaa ketterästi myös niin, että APEja tehdään tarpeiden mukaan, ei tarvitse erikseen fasilitoida yhteistyötä tätä varten.

  • Sujuvan yhteistyön kannalta eri valtion toimijoiden välillä tulee oikeasti huomioida TUVE:n tuomat erityisrajoitteet.

  • Voi olla käytännössä haastavaa, paikoitellen julkishallinto edelleen siiloutunutta ja sisäänpäin kääntynyttä. Julkishallinnon organisaatiokulttuuria pyrittävä kehittämään aktiivisesti aidosti avoimeen ja yhteistyöorientoituneeseen suuntaan (niissä paikoin kuin ei jo ole), joten näen tällaisen linjauksen tärkeänä. Koska organisaatiokulttuurin muuttaminen on työlästä ja hidasta, on varmistettava että tarvittaessa sen tueksi löytyy riittävät resurssit ja (muutosjohtamis)osaaminen.

  • Käytännössä toimijoina ovat usein myös privasektorin palveluntarjoajat. He kuuluvat toki näihin ulkoisiin sidosryhmiin, mutta ovat aivan erityisen tärkeä ryhmä. En kyllä tiedä, voiko tänne linjauksiin näin leipoa.

  • Huomattava terminologiassa, että sidosryhmät (esim. kuntaliitto, edunvalvontaryhmät) ovat kiinnostuneita osapuolia, mutta toimijat (esim. kunnat, yritykset) käyttävät. Kumpaa tarkoitetaan?

  • Linjauksen muodossa tämä voisi kuulua vaatimuksena laatia ja jalkauttaa API-hallintamalli organisaatiokohtaisesti. Mukana (liike)toimintayksiköt ja IT. Ulkoisessa yhteistyössä on otettava huomioon osapuolet, joiden tarjoamista rajapinnoista saadaan dataa sisään omaan organisaatioon.

  • Tämä on palvelusuunnittelun ja toiminnalisen vaatimusmäärittelyn asia laajemmin kuin vain APIlle.

  • Yhteistyö! Onpa uudenaikainen ajatus. Tarvitaan asiantuntevia ihmisiä joilla kompetenssia hallita järjestelmiä tuotteena ja asiakaslähtöisyyttä prosessoimaan palautetta. Yksi github-organisaatio jossa issukoiden kautta tehdään jatkokehitystä ketterästi, ei siihen muuta tarvita.

API:EN AIHEUTTAMAT RISKIT STRATEGISTEN TAVOITTEIDEN SAAVUTTAMISEEN, KYBERTURVALLISUUTEEN JA ORGANISAATION TURVALLISUUTEEN TUNNISTETAAN JA HALLITAAN. Linjataan, miten julkisen hallinnon organisaation tulee huomioida API:en aiheuttamat riskit. Riskit voivat kohdistua strategisten tavoitteiden saavuttamiseen, organisaatioon, toimintaympäristöön tai sidosryhmiin tai ne voivat olla kyberturvallisuusriskejä. Riskit tulee tunnistaa ja niihin täytyy varautua.
Vastaukset
  • Näihin tullaan varmasti kaipaamaan yhteistä ohjeistusta .

  • Tässä korostuu API management/rajapintojen hallinta. Täytyy olla selkeät pakottavat käytännöt, jotka eivät kuitenkaan rampauta tiedon jakamista. Selkeä dokumentaatio ja aina yksiselitteinen vastuuhenkilö järjestelmä- ja tietovarastokohtaisesti. Samasta perus-datasta (tai APIsta) voi olla eri versioita, joiden tietoa julkaistaan. Esim. alueella asuvien henkilöiden yleiset demografiatiedot voisi saada julkisen APIn kautta (ei tietosuojadataa ko APIn kautta) mutta tarkemmat tiedot (esim. pelastuslaitokselle) sitten erikseen rajoitetun ja suojatun APIn kautta.

  • Tähän tarvitaan myös API-sertifiointipalveluja, joilla varmistetaan, että API on otettu käyttöön ja käytetään sillä tavalla, joilla ne (APi:t) ovat suunniteltu käytettävän. Lisäksi API-sertifiointipalvelussa pitää olla erikseen testaus-osio, jossa tutkitaan ja testataan API:a käyttävän sovellusohjelman tietoturva sekä mahdolliset riskit.

  • Ensimmäistä kyberiskua ja lehtiotsoikoita odotellessa :)
    Näistä ei taatusti saada täysin turvallisia ja aukottomia.

  • Erittäin hyvä ja välttämätönkin tavoite. API:t voivat tarjota tietoverkkoihin tunkeutujalle yhden uuden väylän, ellei tietoturvallisuuteen panosteta. Tietoturvallisuuden lisäksi organisaatioiden on arvioitava avattavien aineistojensa aiheuttamaa mahdollista riskiä kansalliselle turvallisuudelle tai haittaa maanpuolutukselle.

  • Tärkeä tavoite

  • Kommenteissa on jo hyvät pointit.

  • Riskit tärkeä näkökulma. Riskien luokittelu on organisaatiokohtaista. Mahtaako API first -ajattelu tuoda mukanaan strategiaan liittyviä riskejä verrattuna muihin malleihin?

  • Best practises -asioita.

  • Uskon että valtiolta löytyy 100:1 niitä jotka haluavat kaiken tapahtuvan off grid, kolminkertaisessa VPN-putkessa, sisäverkossa, kallion sisällä, versus se että rajapinnat ja autentikointi rakennettaisiin turvallisiksi avoimessa verkossa. Kuitenkin, sisäverkon käyttö on silmänlumetta turvallisuudesta ja kannustaa tekemään asiat huonosti.

    Pitäisi linjata että APIt ovat julkisia, julkisesti saatavilla ja niiden koodit ovat myös julkisesti saatavilla. Se kannustaa tekemään hyvää työtä.

Taktisen tason linjaukset
API:T HUOMIOIDAAN OSANA JULKISEN HALLINNON ORGANISAATION KOKONAISARKKITEHTUURIA. Linjataan, miten API-kehittäminen tulee huomioida osana julkisen hallinnon kokonaisarkkitehtuuria. API:t hallitaan osana organisaation kokonaisarkkitehtuuria ja kuvataan organisaation tiedonhallintamallissa soveltuvin osin. Kokonaisarkkitehtuurin tulee määrittää ja hallita API-kehittämisessä ja hallinnassa käytettävät teknologiat ja standardit. Suositeltavaa on hyödyntää yleisiä, avoimia ja teknologiariippumattomia standardeja laajemman yhteentoimivuuden mahdollistamiseksi.
Vastaukset
  • Hyvä että tiedonhallintamalli on mainittu

  • "Soveltuvin osin" tulisi poistaa. Käytännössä tiedonhallitamallissa tulee nimenomaisesti kuvata kaikki APIt vähintään perustietojen osalta. Mikäli APIt eivät ole tiedonhallintamallin kiinteä osa, kyse ei voi olla tiedonhallinnasta.

  • Linkitys tiedonhallintamalliin pitäisi olla selkeä ja ulottaa tiedonhallintamallista annettuun suositukseen ja mallipohjiin, ellei siellä jo ole

  • Kompaan edellisiä kommentteja linkkauksesta tiedonhallintamalliin

  • Tämä linjaus ei mitenkään poikkea nykypäivän organisaation toiminnasta. Tämän linjauksen voi poistaa. Kuvaamisvelvoite on jo muualla (ei lakia kannata alentaa linjaukseksi).

  • Kun tämä ilmeisesti on jo laissa, nämä voisi ryhmitellä johonkin lakisääteiset ihan pakolliset asiat ryhmään. Ei siis poistaa kuten toisessa kommentissa ehdotetaan, vaan korostaa!

  • APIt ovat ehdottomasti tärkeä osa organisaation arkkitehtuurisuunnittelua ja -kuvauksia. Organisaation kokonaisarkkitehtuuri ei ehkä määritä käytettäviä teknologioita ja standardeja, mutta ottaa ne huomioon. Viimeinen virke voisi olla varsinainen linjaus.

  • Ei vain suositeltavaa vaan pakollista "hyödyntää yleisiä, avoimia ja teknologiariippumattomia standardeja laajemman yhteentoimivuuden mahdollistamiseksi".

    Mutta kokonaisarkkitehtuuri - pidetään se kevyenä. Muuten tästä tulee ikuisuusprojekti jonka periaatteista keskustellaan vielä 2050.

  • Monet linjaukset sisältyvät Julkisen hallinnon arkkitehtuuriperiaatteisiin https://avoindata-prod-datasets.s3.amazonaws.com/resources/53488aa1-bffc-4222-88a5-e0adcd5129fe/julkisenhallinnonarkkitehtuuriperiaatteet0.1.0.pdf

  • Tiedonhallintamalliin sitominen pakollista.

    Tätä tulisi täsmentää vielä henkilötietojen osalta, jotta lainsäädännön vaatimukset täytetään. Eksplisiittisest ilmaistava: Kokonaisarkkitehtuurista on käytävä ilmi onko API:a / API:ja tarkoitus käyttä henkilötietojen tai salassa pidettävän tiedon välittämiseen.

API:EN KEHITTÄMISTÄ JA HALLINTAA VARTEN LUODAAN HALLINTAMALLI. Linjataan, miten julkisen hallinnon organisaation tulee luoda hallintamalli, joka sisältää API-kehittämiseen, ylläpitoon ja hallintaan tarvittavat roolit, tehtävät ja vastuut. Hallintamallissa tulee määrittää muun muassa kuka omistaa API:n, miten API-kehittämisen tiekarttaa ja portfolioita hallinnoidaan ja miten API-kehittäminen, ylläpito ja hallinta organisoidaan. Hallintamallin toteuttamista varten hankintaan tarvittavat resurssit ja osaaminen sekä perustetaan tarvittavat organisaatiorakenteet.
Vastaukset
  • nice https://www.nuortenideat.fi/fi/ideat/2603/

  • Tähän tullaan varmasti kaipaamaan yhteistä ohjeistusta .

  • Hallintamalli on ehdottoman tärkeä ja siinä tulee korostua myös vastuutahon organisaatiovastuu, sekä julkaisua edeltävän hyväksynnän että koko hallintamallin valvonnan osalta. Vahingossa tai ilman riittävää valvontaa ei saa tietoa julkaista.

  • Tämän toteutuminen tulee vaatimaan työvoimallista lisäresursointia, jos aiotaan toteuttaa kunnolla.

  • Esimerkit hallintamalleista olisivat varmasti arvokkaita. Mietityttää, että voiko hallintamalli edellyttää organisaatiorakenteiden perustamista? Varmasti vastuutusta kyllä.

  • Peukutus hallintamallille.

  • Ok. Hallintamalli pitää laittaa myös toimintaan, pelkkä malli ei toimi.

  • Tärkeää. Hallintamalli pitää olla.

  • Luovatko kaikki omansa, vai tuleeko tarjolle työkaluja ja linjauksia?

  • Ihan OK määritellä kuka tekee mitä, mutta edelleen, ei erillään itse järjestelmäkehityksestä. Jos järjestelmän vastaava ei kykene ymmärtämään API-rajapintoja, henkilö pitää vaihtaa.

API:T LUODAAN VAIN TARPEESEEN. Linjataan, miten API:n hyödyntäjät, potentiaaliset hyödyntäjät tai muut sidosryhmät sekä API:n tuottama arvo tulee tunnistaa ennen API:n kehittämistä. API:t luodaan tarvelähtöisesti; API:n on tuotettava tarjoajalle, hyödyntäjälle tai potentiaaliselle hyödyntäjälle jotain arvoa, muuten se jää käyttämättä eikä sen kehittämiselle ole perustetta. Tarpeen määrittelyssä tunnistetaan toiminnalliset ja ei-toiminnalliset vaatimukset, mukaan lukien lakisääteiset vaatimukset, sekä analysoidaan API:n vaikutukset organisaation omiin ja sidosryhmien prosesseihin ja toimintaan huomioiden myös kustannusvaikutukset.
Vastaukset
  • Tämä on kai sama tavoite kuin aiemmin mainittu vaatimuksenmukaisuus.

  • Periaate tarvelähtöisyydestä on hyvä. Tässä olisi hyvä määritellä se, miten varmistetaan, että tarpeen tunnistaminen ja käsittely päätyy APIksi. Linjauksena voisi olla myös, että kaikki data, joka ei ole erikseen salassapidettävää, julkaistaan APIna. Jos APIn luonti on kiinni tarpeesta, luodaanko tietoa jakava API vasta, kun joku selkeästi pyytää APIa - ja kauanko sen toteutus kestää? ja miten tarpeen analysointi tapahtuu, perustetaanko komitea? Tarve olisi saada tämä sykli tarpeesta toimivaksi APIksi max 6kk mittaiseksi.

  • Tarve ja erityisesti API:n tuoma lisäarvo täytyy toteutua ja tuntua aivan ruohonjuuritasolla saakka, operatiivisessa toiminnassa - muutoin jäävät taatusti käyttämättä.

  • Toivoisin, että tarvelähtöisyys on nytkin taustalla kehittämisessä. Ehkä pitäisi jakaa malleja, miten tarpeita ja eri toteutusvaihtoehtojen mielekkyyttä voi eri vaikutusten näkökulmasta arvioida?

  • Asiakaslähtöisyys on tarvelähtöisyyttä...

  • Tämä on hyvä. Eikös melkein kaikki muut linjaukset voisi korvata tällä, koska tässä on se homman juju.

    (Nyt linjauksia on liikaa ja lukija/toteuttaja hukkuu niihin. Yksi hyvä on parempi kuin monta huonoa!)

  • Tärkeä linjaus. PItäisi olla malli myös sille, milloin API, milloin muu ratkaisu.

  • Eriävä mielipide: Lähtökohtaisesti kakkia käyttötapauksia ei voida etukäteen tietää. APIa voidaan jatkokehittää asiakaslähtöisesti ja vain tarpeen mukaan mutta APIen tulisi olla peruskomponentti kaikessa kehityksessä, ei että niitä pitäisi erikseen "luoda".

  • Hyvä linjaus, ettei rajapintoja tehtailla varmuuden vuoksi. Sama logiikka kuin tietovarastoilla: aiemmin tehtiin mammutteja, jotka vuosien jälkeen tikahtuivat omaan mahdottomuuteensa. Nyt lähdetään liikkeelle siitä, mitä tietoja tarvitaan ja mihin. (Ja tietoaltaat taas muuttivat pelikentän teknisesti, mutta se on toinen tarina.)
    Organisaatiolla pitää kuitenkin olla API-KYVYKKYYS eli kun todetaan tarve, voidaan nopeasti rakentaa API sen tarpeen tyydyttämiseksi.

  • Tästä kannattaa lähteä liikkeelle.
    Jos kyseessä on API jonka kautta jaetaan avointa dataa, niin datan hyödyntäjää ei välttämättä tunneta etukäteen. Toimiva yhteistyömalli/kanava mahdollistaa että asiakastarpeet voidaan helpommin tunnistaa ja priorisoida tekemistä se huomioiden.

API:T ON LÖYDETTÄVISSÄ JA UUDELLEENKÄYTETTÄVISSÄ. Linjataan, miten julkaistut API:t tulee olla löydettävissä ja uudelleenkäytettävissä. Löydettävyys taataan julkaisemalla API käyttötarkoituksen ja tietosisällön mukaiseen julkaisukanavaan. Uudelleenkäytettävyys on huomioitava API:n koko elinkaaren ajan, tarvekartoituksesta ylläpitoon asti. Samaa API:a tulee voida hyödyntää organisaation sisältä ja ulkoa mahdollisten tarpeiden ja tietoluokitusten mukaisesti. Ensisijaisesti tulee hyödyntää jo olemassa olevaa API:a eikä luoda uutta.
Vastaukset
  • En näe muuta kuin järkevää julkaisutapaa kuin avoindata.fi -sivustolla, kaikki muu olisi turhaa päällekkäistä toimintaa.

  • Eli jonkinlainen linkkikarttakokoelma?

  • Linjataanko julkaisukanavakin?

  • copy-paste :)

  • Uudelleenkäytettävyys on omituinen termi ja kannattaisi korvata paremmin asiaa kuvaavalla termillä. Eikö tarkoitus ole pystyä kattamaan yhdellä ja samalla tiedonsiirron palvelulla mahdollisimman monen tarvitsijan tarpeet (optimointia)?

  • Omaveron taustalla on varmaankin API, mutta en ole käyttäjänä löytänyt mitään tietoa siitä, vaikka sitä tarvitsisin!

  • Löydettävissä -> saavutettavissa?

  • On tunnistettava julksen hallinnon rajapinnalle sen ensisijainen omistaja, esim. postinumerot. Käytetään ensisijaisen omistajan tarjoamaa rajapintaa eikä tarjota omaa.

  • Eikös tästä ole jokin kokonaisarkkitehtuuriharjoitus? Tehkää developer.suomi.fi saitti mihin nämä kaikki materiaali laitetaan ja linkit github-projektiin.

  • Tämä on sinänsä itsestäänselvyys, mutta on syytä sanoa ääneen eli kirjoittaa auki näihin linjauksiin.

API:EN AIHEUTTAMAT RISKIT ON TUNNISTETTU JA HALLITTU. Linjataan, miten API:in liittyvät uhat tulee tunnistaa ja arvioida sekä määrittää tarvittavat riskien hallintakeinot jo API:n ensimmäisessä suunnitteluvaiheessa. Riskienhallintakeinolla määritetään perusteet, joilla hyödyntäjät saavat API:n kautta tarjotut tiedot tai toiminnot käyttöönsä. API:in liittyviä riskejä tulee arvioida ja seurata koko API:n elinkaaren ajan. API:n käsittelemiin tietoaineistoihin kohdistuvien riskien hallinnasta vastaa julkisen hallinnon organisaation tiedonhallintayksikkö.
Vastaukset
  • Riskien hallinnan kannalta tulee ymmärtää, että "samasta APIsta" on parasta olla erikseen eri versioita eri käyttötarkoituksiin, usein myös joka erilaisella tietosisällöllä siten, että suojattava tieto jaetaan vain esim. turvallisen verkon kautta erikseen sopimuksen tehneille tahoille, ja tästä samasta tiedosta suppeampi julkinen versio avoimesti.

  • Ei taatusti tule olemaan 100% hallittua, sekä toiminnallisuuden kannalta että riittävien työvoimaresurssien näkökulmasta.

  • Huomioitava hallintamallissa

  • Tämä on normaalia tiedon ja sovellusten riskienhallintaa. Miksi linjata erikseen?

  • Tästäkin oli jo aiemmin linjaus; kaikki riskienhallintaan liittyvät asiat samaan linjaukseen, vaikka onkin eri tasoja.

  • Käytännössä API voi kuulua tietyn palvelun riskienhallinnan kokonaisuuteen eikä APIen riskienhallintaan.

  • Riskejä käsiteltiin jo aiemmin.

  • Kuvaus on liian kevyt ja sisällöllisesti väärä.

    Tässä tulisi ihan kirjoittamisen osala toteuttaa yhteistyötä valtiohallinnon digitaalisen turvallisuuden Haukka -hankkeen kanssa, joka kehittää riskienhallintaa valtiohallinnossa. Riskienhallintaa kehitetään valtiohallinnossa ja API linjauksen täytyy olla sen kanssa linjassa.

    Samalla käytetty terminologia tulee yhtenäistää riskienhallinnan terminologian kanssa.

    Kun otetaan viimeinen lause: "Riskit tulee tunnistaa ja niihin täytyy varautua"... Liian kevyt ilmaisu strategisena tavoitteena. "Tunnistaa ja varautua" toteutuisi käytännössä vain kerran vuodessa tehtävänä pienenä pohdintana jossa sitten kirjataan hallintakeinoja joita ei toteuteta. Tämä on jo akateemisesti todettu heikoksi tavaksi toteuttaa asia.

    Riskienhallinnan tulee olla jatkuvaa, sisäänrakennettua toimintaa osana päätöksentekoa. Se ei saa olla eikä sitä tule edes ilmaista omaksi erilliseksi linjakseen: Päätöksenteko on riskienhallintaa. Koko riski termin vaihtaisin termiksi "Epävarmuus". Se kuvaa sitä paremin.

    "Epävarmuudet tulee tunnistaa, sen määrää kvantitatiivisesti mitata, tunnistaa epävarmuutta pienetäviä keinoja, toteutaa epävarmuutta pienentäviä keinoja, pienentää epävarmuutta hyväksytylle tasolle ja analysoida jäävä epävarmuus". "Hallinnan tulee olla jatkuvaa ja sen on oltava osa päätöksentekoa".

    "API:n käsittelemiin tietoaineistoihin kohdistuvien riskien hallinnasta vastaa julkisen hallinnon organisaation tiedonhallintayksikkö." Miksi? API:n omistajan ja saavutettavan tiedon omistajan tulee käsitellä ja vastata riskienhallinnasta. Ei minkään erillisen yksikön.

    Kategorisia riskejä tulee poistaa. Esimerkiksi se, että "Julkisen API:n" sisältävässä järjestelmässä ei saa olla mitään muuta tietoa, kuin se joka voidaan menettää tai vuotaa. Eli kaikkien asioiden ei tle olla vain "riskienhallinnalla huomioitu". Osa asioista pitää yksiselitteisesti linjata sellaisiksi jo ylätason API linjauskessa, että ne on toteutettava. Tiettyjä riskejä ei tule ottaa eikä niitä tule olla olemassa.

    ..2223..

API:EN MITTAAMISEKSI MÄÄRITETÄÄN MITTARIT, JOITA SEURATAAN. Linjataan, miten API:lle määritetään mittarit, joiden avulla esimerkiksi API:n käyttöä, hyödyllisyyttä ja palvelutasoa voidaan mitata ja seurata. Mittaroinnissa tulee huomioida myös API hyödyntäjien tyytyväisyyden mittaaminen. Hyödyntäjiltä voidaan esimerkiksi kerätä säännöllisesti tai jatkuvasti palautetta, jota hyödynnetään API:n kehittämisessä.
Vastaukset
  • Mittaaminen on toissijaista.Toki APIn käyttöastetta voidaan mitata, mutta vähäinen käyttö ei voi olla syy APIn sulkemiseen, koska tämä estäisi silloin ko tiedon hyödyntämisen ja avoimen datan periaatteen.

  • Käyttöä ja tarvetta tulee mitata - ja tämän kautta saatavan datan, esimerkiksi havaittuihin puutteisiin tulisi myös oikeasti reagoida. Muutoin tämä on jälleen yksi "pakollinen työkalu" jota käytetään pelkästään koska sitä kuuluu käyttää, hyötyä siitä ei saa tällöin irti.

  • Mittareiden määrittelyn ja mittaamisen vaatima työpanos tulee olla oikeassa suhteessa siitä saavutettuun hyötyyn. Ovatko kaikki API:t luonteeltaan sellaisia, että niitä on tarkoituksenmukaista ylipäätään mitata? Ja jos, niin onko tarkoituksenmukaista mitata kaikkia API-rajapintoja "yhtä kattavasti"?

  • Aiemmin todettiin tarve mitattavista tavoitteista ja tässä mittareista. Jos yhteismitallista tietoa tarvitaan, niin pitäisi pyrkiä määrittämään yhteisesti, mitä nämä mittarit voisivat olla (ettei jokaisen tarvitse lähteä puhtaalta pöydältä miettimään).

  • Tämä linjaus kuulostaa normaalilta IT-palvelun käytön seurannalta eikä ole mitenkään erikoista rajapintapalveluille. Linjauksen voi poistaa.

    Voisiko joku linjaus koota yhteen nämä normaaliin sovellusten kehittämiseen ja seurantaan liittyvät seikat. Esimerkiksi ohjelmointirajapintojen kehittämisessä ja ylläpidossa tulee huolehtia samoista seikoista muussakin normaalissa toiminnan, it-palvelujen ja sovellusten kehittämisessä (mm. tietosuoja, tietoturva, seuranta).

  • kts. linjaus APIEN KEHITTÄMISELLE ASETETAAN MITATTAVAT TAVOITTEET; samaa asiaa

  • Hyvät käytännöt jakoon tässäkin asiassa.

  • Palautteen kerääminen ja _siihen reagoiminen jatkokehityksen muodossa_ on ensiarvoisen tärkeä asia. Palautetta ei tule kerätä mikäli siihen ei vastata tai vastaus on "kiitos palautteesta, ei ole mahdollisuutta jatkokehittää rajapintaa".

    Mutta valtioko määrittelee jonkun APIn hyödyllisyyden? Jos esim sen varaan on syntynyt liiketoimintaa, mutta liikennettä valtion omien mittarien mielestä on vähän? API-monitorointi toki on järkevää mutta mikäli lähtökohdaksi otetaan että rajapinta on se primääri tapa hoitaa jokin asia, eikö ole niin että mikäli APIa ei käytetä, on se asia mitä se edustaa kokonaisuudessaan turha ja tulisi lopettaa.

  • Mittaamista käsiteltiin jo aiemmin.

  • Linjauksessa tlee myös asettaa mitattaviksi asioiksi tietoturvallisuus ja tietosuojan toteutuminen. Vain erikseen mainitessa ne tulevat mitatuiksi.

Operatiivisen tason linjaukset
API:T KEHITETÄÄN ASETETTUJEN TAVOITTEIDEN JA VAATIMUSTEN MUKAISESTI JA KEHITTÄMISTÄ HALLITAAN. Linjataan, miten API:en suunnitteluvaiheessa tulee huomioida API:lle asetetut tavoitteet ja vaatimukset ja miten kehittämistä tulee priorisoida ja hallita. Tavoitteet dokumentoidaan ja niissä huomioidaan sidosryhmien tarpeet. Vaatimukset sisältävät toiminnalliset ja ei-toiminnalliset vaatimukset mukaan lukien lakisääteiset vaatimukset. API-kehittämistä hallitaan ja priorisoidaan esimerkiksi työjonon (backlog) avulla.
Vastaukset
  • https://www.nuortenideat.fi/fi/ideat/2603/

  • Julkishallinnon APIen osalta dokumentaatio tulee olla hyvällä tasolla ja vaatimusten dokumentointi selkeää. Kehitysbacklogin kautta ei voi tulla uusia ominaisuuksia, vaan ne tulee dokumentoida ensin selkeiksi vaatimuksiksi. Näin varmistetaan tietoturvan hallinta useamman henkilön katselmoidessa.

  • Eikö tämä ole melko yleinen toiminnan kehittämistä koskeva linjaus? Tuottaako tämä lisäarvoa vs. organisaatioiden nykyinen toiminta? Tarkoitan sitä, että näitä kolmen eri tason linjauksia on kappalemäärällisesti melko paljon. Tiivistäisin, jotta viesti ja ne merkittävimmät asiat tulisivat esille. Nyt voi tärkeät (uudet) näkökulmat jäädä paljouden sekaan.

  • Sidosryhmällä tarkoitetaan ryhmää, joka on kiinnostunut jostakin jonkin asian näkökulmasta. Tässä yhteydessä tulisikin käyttää termiä toimija, koska sillä tarkoitetaan oikeasti toimintaan osallistuvaa esim. rajapintapalvelun hyödyntäjää.

    Eikö tämä linjaus ole normaalia kehittämistyötä? Linjauksen voi poistaa.

  • API-kehittäminen ei ole mikään erillinen saareke, vaan rajapintoja toteutetaan eri projekteissa eri tarpeisiin. API first -ajattelu tulee ottaa projekteissa lähtökohdaksi. API-hallinnalla varmistetaan, että organisaatiossa on koottu ymmärrys, mitä APEja on, mitä niillä tehdään ja esim. mitä tietoa niiden avulla julkaistaan (viittaus tiedonhallintalakiin).

  • API-kehitäminen on osa muuta kehittämistä. sillä ei välttämättä ole omaa työjonoa.

  • Api:n suunnitteluvaiheessa tulee huomioida: "API:n käsittelemiin tietoaineistoihin kohdistuvien riskien hallinnasta vastaa julkisen hallinnon organisaation tiedonhallintayksikkö." - Suora lainaus PiTuKrista, MH-02 vaatimus.

    "(API, Application Programming Interface) on julkaistu siten, että ne mahdollistavat yhteentoimivuuden eri ohjelmistokomponenttien ja ohjelmistojen kanssa." PiTuKri SI-01

    ..2223..

API:T TESTATAAN ENNEN JULKAISUA. Linjataan, miten julkisen hallinnon organisaation julkaisemat API:t tulee testata ja todentaa toimiviksi ennen julkaisua. Testauksessa on huomioitava toiminnallisten ja ei-toiminnallisten vaatimusten testaus sekä regressiotestaus. Testausta tehdään koko API:n elinkaaren ajan. API:n hyödyntäjien testaus on mahdollistettava. API:n hyödyntäjän tulee voida testata API:a ennen päätöstä sen hyödyntämisestä. Testausta varten tulee tarjota testidataa ja testauksen tulee olla maksutonta, vaikka API tuotantokäytössä olisi maksullinen.
Vastaukset
  • Testaus on ehdottoman tärkeää ja se tulee tehdä vaatimuksia vasten (tässtä toinen syy, miksi vaatimukset tulee olla dokumentoitu ennen toteutusta). Testipalautteen kerääminen / dokumentointi (esim. havaintoilmoitukset) tulisi myös linjata, koska se on APIn elinkaarenhallinan kannalta tärkeää ja etenkin hyväksyntäpäätöksenteossa tulisi tarkastaa palautteet.

  • Tärkeä linjaus. Julkishallinnon ICT-hankintoja tekevien tulisi huomioida, että testaus ja siihen liittyvät (tässä luetellut) vaatimukset on määritelty tarjouspyynnöllä ja sopimuksessa. Kuinka varmistetaan, että he ovat tietoisia linjauksesta ja pystyvät siten jalkauttamaan sitä tehokkaasti käytännön tasolla?

  • Tämä linjaus (testaus ennen julkaisua) on itsestään selvyys ja sen voisi poistaa (tai liittää jonnekin rajapintapalvelun toimivuuden vakautta korostavaan linjaukseen). Sen sijaan linjauksen kuvauksessa olevat osuudet (testaus ennen käyttöönottoa, testausdata ja testauksen maksuttomuus) voisi nostaa linjaukseksi.

    Puuttuuko rajapintapalvelun vakautta tarkoittava linjaus? Hyödyntäjiä voi olla, mutta jos tiedon saatavuus ei ole vakaata, hyödyntäjät katoavat.

  • Tärkeä asia, vaikka kuulostaakin itsestäänselvyydeltä. Testata pitää ainakin, kun jokin APIin vaikuttava asia tekijä muuttuu, mikä toki edellyttää toimivia muutoshallintaprosesseja.

  • Olemme samaa mieltä. Muistetaan myös suorituskykytestaus.

  • Poistaisin linjauksesta. Jos halutaan, jonnekin "best practices" sivulle voi laittaa maininnan.

  • " (API:t) suunnitellaan, kehitetään, testataan ja otetaan käyttöön alan hyvien turvallisuuskäytäntöjen mukaisesti. Rajapintojen on kestettävä yleiset hyökkäysmenetelmät ilman, että käsiteltävien tietojen luottamuksellisuus, eheys tai saatavuus vaarantuu"

    Rajausta ei pidä tehdä myöskään vain tilanteeseen "ennen julkaiua". Testauksen tulee olla tosiasiassa jatkuvaa. Eli "API:a testataan jatkuvasti sen elinkaaren ajan."

    ..2223..

API:T DOKUMENTOIDAAN JA JULKAISTAAN YHDENMUKAISESTI. Linjataan, miten julkisen hallinnon organisaation kehittämät API:t tulee dokumentoida ja julkaista yhteisten periaatteiden mukaisesti. Dokumentaatio sisältää muun muassa API:n toiminnallisen ja teknisen kuvauksen, tiedon ja rajapinnan lisensointimallit, testausmahdollisuudet, versiointikäytännöt, palvelutason sekä ylläpitävän organisaation yhteystiedot ja ohjeet API:n käyttöönottoa varten. Metatiedot määritetään yhteisen metatietomallin mukaan. API:n julkaisulle määritetään yhteiset toimintatavat. Löydettävyyden takaamiseksi API:t, tyypistä riippumatta, suositellaan julkaistavaksi jonkinlaisen API-katalogin avulla, josta on saatavilla myös API:n dokumentaatio ja mahdolliset lähdekoodit.
Vastaukset
  • Tämä on hyvä.

  • Pakko on olla yhteinen standardi. Ongelmia voi tuottaa keskenään hyvinkin erilaiset API:t.

  • Tärkeä linjaus. Julkishallinnon ICT-hankintoja tekevien tulisi huomioida, että dokumentointi ja siihen liittyvät (tässä luetellut) vaatimukset on määritelty tarjouspyynnöllä ja sopimuksessa. Kuinka varmistetaan, että he ovat tietoisia linjauksesta ja pystyvät siten jalkauttamaan sitä tehokkaasti käytännön tasolla?

  • Tämä ei kuulosta enää linjaukselta vaan toiminnalta. Voisiko muotoilla jollain toisella tapaa? Löydettävyydestä on jo muissa linjauksissa, onko esim. hankintavaiheen vaatimukset tässä tärkeämmät linjattavat seikat?

  • Tätä täytyisi jo valmiiksi linjata, että openapi (swagger) dokumentaatio on vähintään oltava olemassa

  • Olisi ihan hyvä saada käytäntöön.

  • Pidetään huoli ettei tule katalogeja kuin sieniä sateella. Katalogien pitää olla sekä ihmis- että koneluettavia.

  • Tämän on hyvä ja tärkeä linjaus.

  • Yhdenmukaisessa dokumentaatiossa tulee olla selkeät omat kohdat tietoturva-asioiden dokumentoimiselle, sekä tietosuoja-asioiden & käytäntöjen dokumentoimiselle.

    Nämä kaksi kokonaisuutta tulee olla selkeästi ilmaistu yhdenmukaisessa dokumentaatiossa.

    ..2223..

API:EN KÄSITTELEMÄ TIETO ON LUOKITELTU, TURVATTU JA KUVATTU. Linjataan, miten API:n käsittelemä tieto ja toiminnot tulee tunnistaa ja kuvata semanttinen yhteentoimivuus huomioiden. Tietomallinnuksessa hyödynnetään Yhteentoimivuusalustan yhteisiä ja yleisiä tietomalleja. Tiedot ja toiminnot on luokiteltu ja niitä käsitellään luokittelunsa mukaisesti. Luokittelun mukaiset kontrollit toteutetaan. Kontrollit kattavat tiedon ja tiedonsiirron salauksen sekä API-hyödyntäjien autentikoinnin, auktorisoinnin sekä toiminnan jäljitettävyyden.
Vastaukset
  • Selkeä linjaus on oltava, siinä ei saa olla tulkinnanvaraa eri toimijoiden välillä.

  • Luokittelu voidaan ymmärtää myös salassapitoluokituksen arviointina, mikä sekin on tarpeen avattaessa uusia tietoaineistoja.

  • Julkishallinnon ICT-hankintoja tekevien tulisi huomioida, että tiedon luokittelu, turvaaminen ja kuvaaminen sekä siihen liittyvät (tässä luetellut) vaatimukset on määritelty tarjouspyynnöllä ja sopimuksessa. Kuinka varmistetaan, että he ovat tietoisia linjauksesta ja pystyvät siten jalkauttamaan sitä tehokkaasti käytännön tasolla?

  • Yleisiä tietomalleja ja viitearkkitehtuureita on toimialakohtaisesti aika paljon tarjolla. Mitä toimintojen luokittelua sovelletaan?

  • Tiedontuottajalla on vastuuta luokittelusta ei pelkästään API:n tuottajalla.

  • Yhteentoimivuusalustalla on myös koodistoja. Jos löytyy jokin yleinen koodisto (kuten Suomen kunnat), niin toki kannattaa sitäkin käyttää eikä keksiä sitä samaa pyörää uudelleen.

  • Kontrollien on myös katettava se vaihtoehto, että tapahtumaketjuja poistetaan mahdollisuutena.

    Etenkin "Julkinen API" (Vrt. sisäinen & kumppani) tulee kytkeä resurssiin tai tietoon, joka kokonaisuudessaan voidaan menettää. Kaikki tieto täytyy voida luovuttaa Julkisen API:n kautta. Julista API:a ei tule kytkeä kohteeseen, josta vain osa tarjotaan sille. API:t ja järjestelmät ovat haavoittuvia. Valtiohallinnon API rajapinnat tulevat olemaan jatkuvan hyökkäyksen ja kalastelun kohteena. Julkisia tullaan etenmin pommittamaan jatkuvasti.

    Rajapinnat tulevat sisältämään myös 0 päivä haavoituvuuksia ja -1 haavoittuvuuksia, eli sellaisia joita ei ole edes julkaistu. Nimenomaan näitä käytävät kehittyneemmät toimijat hyökkäyksissään. Meillä ei siis ole edes mitään automaattista keinoa havaita tällaista hyökkäystä, "Virustorjunta" ei toimi, koska sille ei ole kyetty kertomaan mitä tulee etsiä. Sen takia nimenomaan etenkin Julkisen API:n tulee saavuttaa vain resurssi, joka kokonasuudessaan halutaan luovuttaa ulos.

    Julkisen API:n ei tule kytkeytyä "vain osaan" tiedosta. Kaikki pitää voida menettää. Tällöin rakennamme kestävän rajapinnan ja vältämme katastrofit.

    Tietosuojan osalta yksilöiviä henkilötietoja ei tulisi myöksään tarjota Julkisen API.n kautta. Kaikki henkilötietodatan tulisi Julkisen rajapinnan kohdalla olla anonymisoitua.

    Tämänkalaiset asioita EI voi jättää "riskienhallinnassa havaittavaksi ja linjattavaksi". Sitä ei tule tapahtumaan. Kustannukset edellä menevät oikovat nimenomaan tässä ja vaaranavat tietämättään suuria tietomääriä ja kokonaisia organisaatioita. Sen takia jo linjauksssa tulee tehdä tämän kaltaisia selkeitä rajauksia. Asettaa ne takaseinät, joita ei ylitetä.

    Yleisesti Turvaamisessa API:n ja sen taustajärjestelmän tulisi seurata kansallisia KAtakri & PiTuKri kriteeristöjä turvallisuuden osalta. Muun muassa API:en tulee aina olla kovenettuja (vain tarpeellinen kytketty päälle, tarpeeton aina pois)

    ..2223..

  • Tämän voisi jakaa kahteen linjaukseen, joista toinen käsittelisi kuvausta ja toinen turvaluokittelua. Samalla voisi avata vähän tarkemmin, mitä tarkoitetaan tällä: "tieto ja toiminnot tulee tunnistaa ja kuvata semanttinen yhteentoimivuus huomioiden"

API:EN KÄYTTÖÄ SEURATAAN. Linjataan, miten API:n käytöstä kerätään lokitietoja ja miten API:n käyttöä seurataan, sille asetettujen mittareiden mukaisesti. API:n käytöstä tulee voida seurata vähintään API:in tulleiden kutsujen määrää kutsujakohtaisesti, käsittelyaikoja sekä onnistuneiden ja epäonnistuneiden käsittelyjen määriä.
Vastaukset
  • https://www.nuortenideat.fi/fi/ideat/2603/

  • Tarkoittaako kutsujakohtainen tilastointi sitä, että apien käyttäjien on myös tunnistauduttava?

  • Tämä on enemmänkin teknistä mittarointia APIn toimivuuden kannalta.

  • Resursointikysymys - mahtaako toteutua?

  • Kannatettava linjaus, koska logitietojen kerääminen mahdollistaa osaltaan sen arvioinnin, hyödyntääkö API:n käyttäjä hakemiaan tietoja mahdollisesti vääriin, tietoturvallisuutta tai kansallista turvallisuutta vaarantaviin tarkoitusperiin.

  • Julkishallinnon ICT-hankintoja tekevien tulisi huomioida, että API:en käytön seuranta ja siihen liittyvät (tässä luetellut) vaatimukset on määritelty tarjouspyynnöllä ja sopimuksessa. Kuinka varmistetaan, että he ovat tietoisia linjauksesta ja pystyvät siten jalkauttamaan sitä tehokkaasti käytännön tasolla? Olettaisin, että seurannan tarve vaihtelee myös API-kohtaisesti eli onko tarve jättää tähän vahvasti tilaajan omaa harkintaa?

  • Tämä on vähän kaksijakoinen juttu. Avoimet tunnistautumattomat rajapinnat ovat tarpeen nekin, mutta silloin ei esimerkiksi muutoksista saada tietoa käyttäjille. Rajapinnan toimivuutta toki hyvä seurata.

  • Ok

  • Kertooko kutsujen määrä hyvästä vai huonosta API:sta?

  • Pitääkö tästäkin tehdä linjaus? Uskoisin että APIn omistaja voi tehdä tarkoituksenmukaista seurantaa.

Taustatiedot