Sikrere banktjenester med filoverføring på steroider

Kanskje lurt å sette seg inn i hva dette er først som sist? Vil du ha et innblikk i hva standarden er og brukes til, les videre! Du vil også få nyttige knagger til å starte å jobbe med Enhanced PEPPOL.

Kontekst

La oss begynne med å sette konteksten. Vi skal her snakke om Enhanced PEPPOL, som er en utvidelse og spesialisering av vanlig PEPPOL. Vanlig PEPPOL er en europeisk standard for sikker filoverføring, som strengt tatt kan brukes til å overføre nær sagt hva som helst. Men Digitaliseringsdirektoratet har vurdert at vanlig PEPPOL ikke er sikkert nok til følgende bruksområde: Overføring av betalingsfiler fra ERP-systemer til nettbanker. Disse betalingsfilene kan ses på som en integrasjon mellom ERP-systemene og bankene, slik at både regnskap og faktiske betalinger sett fra en brukers ståsted kan gjennomføres i ERP-systemene. Betalingsfilene følger standarden ISO-20022.

Tradisjonelt har betalingsfiler kunnet bli lastet opp manuelt i nettbank når det er snakk om liten skala, mens man gjerne har brukt SFTP for større skala og/eller når det må gjøres automatisk. Så utbroderer man med ulike mekanismer for forsegling og synkronisering av meldinger. Dette har sine utfordringer, og det er også mulig å finne bedre sikkerhetsløsninger. Enhanced PEPPOL er ment å bli den nye standarden, og er allerede påkrevd å bruke i forbindelse med SKKO, Statens konsernkontoordning. Det er forventet at også øvrige aktører på sikt vil begynne å støtte Enhanced PEPPOL.

Vanlig PEPPOL er for øvrig her i Norge mest kjent fra EHF, Elektronisk handelsformat. Når det gjelder elektroniske fakturaer anses vanlig PEPPOL fortsatt som sikkert nok.

I teorien skulle ingenting hindre bruk av Enhanced PEPPOL til overføring av hva som helst, men i skrivende stund ligger kun ISO-20022-betalingsfiler definert i standarden. Det er dog å anta at standarden på sikt vil utvides til å omfatte flere andre typer filer, etterhvert som behov og ønsker melder seg.

Oversikt

Enhanced PEPPOL

Enhanced PEPPOL

For å forklare Enhanced PEPPOL benytter vi modellen med fire hjørner. Det er alltid hjørne 1 som er avsender av meldinger, mens hjørne 2 er avsenders aksesspunkt - se neste kapittel. Videre på figuren, hjørne 3 er mottakers aksesspunkt og hjørne 4 er endelig mottaker av meldingen. Når meldinger eller kvitteringer skal sendes tilbake, så bytter aktørene nummer, slik at den som tidligere mottok en fil som hjørne 4 nå blir et hjørne 1 som avsender.

Noe av sikkerheten i Enhanced PEPPOL ligger i at kun aksesspunktene trenger å kunne aksesseres fra internett, hjørne 1 og 4 kan ligge trygt og godt i beskyttede nettverkssoner, om man ønsker dette. Et ytterligere sikkerhetskonsept, er at meldingene som sendes er krypterte fra ende til ende, og signerte av avsender.

Standarden Enhanced PEPPOL er bygd opp av mange kjente konsepter og byggeklosser. Heller enn å finne opp hjulet på nytt, har man valgt å benytte seg av standarder som allerede er etablerte. Dette muliggjør gjenbruk, kunnskap finnes tilgjengelig på internett, og andre fordeler.

Aksesspunkt

Så, hva er et aksesspunkt? Dette er noe som er arvet fra vanlig PEPPOL. Eller, mer presist, Enhanced PEPPOL benytter seg av samme infrastruktur for aksesspunkter som vanlig PEPPOL gjør. Man kan faktisk godt benytte samme aksesspunkt for EHF som for betalingsfiler. I denne sammenheng kan man se aksesspunkter som et nettverk av servere eller noder som kan snakke med hverandre. Det er et lukket økosystem, der hvilket som helst aksesspunkt kan snakke med et hvilket som helst annet aksesspunkt, men ingen andre har lov til å sende meldinger til aksesspunktene. Derimot har hvert aksesspunkt avtaler med andre aktører i hver ende av kommunikasjonen. En aktør er avsender, og gjør klar en melding, som så på avtalt vis oversendes til aksesspunktet, som i sin tur sørger for å sende meldingen til mottakers aksesspunkt. Dette aksesspunktet har også kontroll på hvilke aktører som skal kunne motta meldinger, og sørger for å overføre eller tilgjengeliggjøre den på avtalt vis.

Alle aksesspunkter har vært gjennom en sertifiseringstest, og må oppfylle formelle tekniske og forvaltningsmessige kriterier. Det er OpenPEPPOL som står for godkjenning, og det er kun OpenPEPPOL som har anledning til å godkjenne sertifikatbestilling for aksesspunktet. Ethvert aksesspunkt trenger et PEPPOL-sertifikat å identifisere seg med, dette er enda en sikkerhetsmekanisme.

Melding

Så hva er det faktisk aksesspunktene sender, og hvordan vet de hvor meldingene skal? Kjernen i en ordinær melding som overfører en fil er en ASiC-E. Kort fortalt er dette en dokumentkontainer som er kryptert, signert og zippet. Denne skal gå kryptert fra ende til ende. Dermed må det også finnes ytterligere informasjon, tilgjengelig ukryptert, om innholdet og hvem meldingen sendes fra og til. Det er da definert et Standard Business Document, et XML-format som inneholder en Standard Business Document Header, og ASiC-E i et payload-element.

Headeren angir blant annet en kode for hva slags fil som sendes, landkode og organisasjonsnummer for avsender og tilsvarende for mottaker. Dette gjelder da for norske aktører, for utenlandske aktører vil andre identifikasjoner kunne gjelde.

Koden for filtype må naturligvis matche filen som er pakket inn i ASiC-E. I tillegg angis noe som kalles profile, som er ment å være en større kontekst filen passer inn i - dette kan gå på tvers av filtype, og kan ha betydning for håndtering av filen. Som så mye annet, så er profiler og koder definert i det som kalles Rulebook - vi kommer tilbake til denne.

Sertifikatoppslag, kryptering og signering

ASiC-E er allerede nevnt, men en viktig detalj er faktisk at en melding har både en indre og en ytre ASiC. I den indre legges payload, og den signeres før den zippes. Deretter blir denne ASiC’en lagt i en ytre ASiC, som også signeres før den krypteres og zippes.

Kryptering skjer med offentlig del av mottakers sertifikat. Dette betyr at kun mottaker, som sitter på privatnøkkelen, kan dekryptere meldingen og lese innholdet i ASiC’ene. For å slippe utfordringene med kontinuerlige manuelle utvekslinger av sertifikater mellom aktører, så er konseptet Business Certificate Publisher tatt inn i Enhanced PEPPOL. En BCP er et register man kan slå opp i, og få i retur et sertifikat. Man spør på en mottakers organisasjonsnummer, og legger på enkelte øvrige detaljer om meldingstype. Det er teknisk mulig å bruke ulike sertifikater i ulike settinger.

Merk at Digitaliseringsdirektoratet godkjenner sertifikatutstedere, kun disse kan utstede sertifikater til bruk i Enhanced PEPPOL. Ved bestilling må man oppgi bruksområde, slik at riktig type sertifikat blir laget, og at det tilgjengeliggjøres med riktige profiler i sertifikatutstederens BCP. En godkjent sertifikatutsteder må også drifte sin egen BCP.

Den årvåkne leser har nå lagt merke til at det finnes flere BCP’er. Dermed har Digitaliseringsdirektoratet laget en BCL - Business Certificate Locator - som rapporterer korrekt BCP-URL for faktisk oppslag av sertifikat, slik at avsender ikke er nødt til å sjekke alle BCP’er i tur og orden.

Signeringer skjer med avsenders eget virksomhetssertifikat. På sikt er tanken at signeringssertifikater, offentlig del, kan tilgjengeliggjøres automatisk på linje med krypteringssertifikatene, men inntil videre må disse enten utveksles manuelt med mottakere, eller mottaker må validere meldinger basert på informasjonen i selve signaturen.

Routing

I meldingers header er, som tidligere nevnt, mottaker angitt via landkode og organisasjonsnummer. Dette brukes til å lokalisere mottaker. PEPPOL, her både Enhanced og vanlig, benytter seg av en såkalt Service Metadata Locator for å finne ut hvilken Service Metadata Provider det skal slås opp i for routingregler - se på dette som et register, en slags telefonkatalog. Her i Norge er provideren som benyttes ELMA, Elektronisk mottaker- og adresseregister. Det er opp til hver enkelt aktør å registrere seg selv i ELMA, komplett med aksesspunkt og mottakerkapabilitet. Dette betyr altså at aksesspunktet som skal sende en melding (hjørne 2) ender opp med å slå opp mottaker i ELMA, og får URL til aksesspunktet mottaker har avtale med (hjørne 3). Mens mottakerkapabilitet betyr hva en mottaker ønsker/kan ta imot - det er fullt mulig at man forsøker å sende filtyper som mottaker ikke ønsker å ta imot, og i så tilfelle vil dette ikke tillates. Merk at ELMA også kjenner til og rapporterer PEPPOL-sertifikatet til aksesspunktene, og dersom hjørne 2 ser at hjørne 3 sitt faktiske sertifikat ikke matcher, så vil overføring av sikkerhetsårsaker avbrytes.

Inn under routing kan vi også kort nevne et ytterligere tema: Hva skal hjørne 4 gjøre etter mottak? I noen tilfeller vil hjørne 4 selv være endelig mottak, i andre tilfeller vil hjørne 4 basert på filtype og profil kunne måtte velge mellom ulike endelige mottakssystemer. Dette kan for eksempel være to ulike banksystemer, for håndtering av ulike filer, eller på kundesiden kan det være to ulike ERP-systemer. Det finnes for eksempel de som benytter et system for regnskap og et annet for lønn. Uten å komplisere for mye, kan det nevnes at det kryptert inne i ASiC-E også kan finnes en metadatafil med enkelte parametre relevante for denne routingen, samt at det er forventet en utvidelse av Rulebook med en åpen header-parameter kalt Routing ID, som på sikt vil kunne ta over mye av ansvaret for routing fra hjørne 4.

Kvitteringer

Et viktig konsept i Enhanced PEPPOL er at alle meldinger skal medføre en kvittering tilbake. Alle ledd skal gi kvittering til foregående ledd i kommunikasjonen. Kvittering fra endelig mottaker, hjørne 4, skal også gå helt tilbake til opprinnelig avsender, hjørne 1. Dersom kvittering ikke kommer innen forventet tidsfrist, så har hjørne 1 anledning til å generere en ny melding med samme payload og forsøke på nytt. Merk at det er nødvendig å generere ny melding, da hver melding skal ha en unik ID.

En detalj å legge merke til, er at kvitteringer fra hjørne 4 (“RC4” - Receipt Corner 4) ikke er responser i vanlig request-response-forstand. De er faktisk helt nye meldinger, med egen meldingsID, generert av mottaker - som nå blir avsender, og som sender kvitteringen som separat melding. Meldingen inneholder referanse til original meldingsID, slik at mottaker (det vil si avsender av orignal melding med original payload) kan vite at original melding er kommet frem. Kvitteringer er ren tekst, som hverken trenger å krypteres eller signeres. Dermed er ikke BCP-oppslag nødvendig for å sende en kvittering.

Dersom noe går galt ved prosessering av en mottatt melding, så har hjørne 4 anledning til å sende en negativ kvittering. Dette er igjen en helt frittstående melding. Mottar opprinnelig avsender en negativ kvittering, så vet man at noe var galt med meldingen - kvitteringen skal også angi hvilken type feil som oppsto. Et forvaltningsregime skal i slike tilfeller sette i gang undersøkelser av hva som gikk galt, og dynamisk forbedre systemet.

En kilde til forvirring er hva positiv og negativ kvittering faktisk betyr, og hvordan de brukes. Positiv kvittering er i praksis bare en “ACK, melding mottatt”. Dette er ingen endelig bekreftelse på at alt gikk bra. I praksis blir det fravær av negativ kvittering som er tydeligste indikator på suksess. Negativ kvittering sendes uavhengig av om det lyktes å levere den positive kvitteringen - original avsender har da heller ingen garanti for hvilken rekkefølge de mottas i.

Enkelt oppsummert kan man si at:

• “Ingen kvittering mottatt innen tidsfrist” = generer ny melding og prøv på nytt
• “Positiv kvittering mottatt, ingen negativ kvittering mottatt innen tidsfrist” = antar alt vel
• “Negativ kvittering mottatt, uavhengig av eventuell positiv kvittering” = teknisk feil, må undersøke underliggende årsak

Lage selv eller finne tjenestetilbyder?

Dersom Enhanced PEPPOL er relevant, så er et viktig spørsmål om man skal lage egen implementasjon, eller benytte seg av tjenestetilbyderne som finnes. Svært mange har allerede implementert aksesspunkter, og i skrivende stund er to av de Enhanced PEPPOL-kompatible aksesspunktene også kommersielt tilgjengelige, nemlig de to levert av Nets og Evry. Ved ønske om å drifte sitt eget aksesspunkt, så er det lurt å vite at svært mange leverandører har valgt å basere seg på open source-implementasjonen Oxalis. Denne kan da hvem som helst installere hos seg selv.

For hjørne 1 og hjørne 4 finnes foreløpig ingen komplett implementasjon åpent tilgjengelig, men det finnes en del byggeklosser. Digitaliseringsdirektoratet har flere open source-prosjekter, og noen av disse er relevante for å lage og å pakke opp Enhanced PEPPOL-meldinger. Banker har foreløpig ingen kjente kommersielle alternativer tilgjengelige, men på kundesiden har ERP-leverandører startet å implementere støtte for Enhanced PEPPOL i sine systemer. Dette gjelder blant annet Agresso og SAP.

Selve PEPPOL-nettverket er i og for seg gratis å bruke, det er i utgangspunktet ingen pris knyttet til å sende en melding. Men aksesspunkter må betale en årlig avgift til OpenPEPPOL, og alle involverte aktører kan ta betalt for tjenestene de leverer. Dette omfatter sertifikatutstedere, ERP-leverandører, aksesspunkter og banker.

Rulebook

Definisjonen av standarden Enhanced PEPPOL ligger i regelboken, enkelt og greit kjent som Rulebook. Denne er åpent tilgjengelig for alle å lese, og å komme med innspill til. Som del av et offentlig forvaltningsregime må man forholde seg til datofrister for innspill, foreslåtte revideringer og faktiske endringer. Samt da relativt romslige tidsfrister for justeringer av egne implementasjoner dersom Rulebook endrer seg på slik måte at det også krever oppdatering av kode.

For å sikre at alle aktører kan utveksle meldinger med alle aktører, er det viktig at alle faktisk følger Rulebook, så det vil da være viktig å være følge med når det annonseres endringer.

Alt dette for å overføre en fil?

Dette var da litt av et regime, og bare for å overføre en fil? Helt riktig, her har man satt i gang et meget stort apparat for å legge til rette for en svært sikker filoverføring - kanskje du nå skjønner betegnelsen “filoverføring på steroider”? Om den ekstra innsatsen er verdt det blir vel opp til hver enkelt å vurdere, men visse filer ønsker man virkelig ikke skal komme på avveie. Da er en sikker filoverføring naturligvis å foretrekke! I tillegg må man huske på at Enhanced PEPPOL er en standard som kan komme til å bli svært utbredt, og i så fall er gjenbruksverdien stor etter en initiell oppstartskostnad.

Appendix

Begrepsforklaringer:

PEPPOL: Pan European Public Procurement Online. (Vanlig) PEPPOL er en europeisk standard for sikker filoverføring, som strengt tatt kan brukes til å overføre nær sagt hva som helst. Mottaker av filer må dog definere sine såkalte mottakerkapabiliteter, som angir hvilke filtyper man aksepterer å få tilsendt. Disse må velges fra en forhåndsdefinert liste, og er således begrenset. Men det er meningen at listen skal kunne utvides ved behov. PEPPOL styres av OpenPEPPOL.

OpenPEPPOL: PEPPOL styres av OpenPEPPOL, som er en ideell organisasjon - det vil si en organisasjon som ikke er ute etter profitt, eventuelle overskudd reinvesteres. OpenPEPPOL godkjenner aksesspunkter og er eneste myndighet til å bestille PEPPOL-sertifikater til aksesspunktene.

Enhanced PEPPOL: Beskrevet i hovedartikkelen her. En utvidelse og spesialisering av vanlig PEPPOL. Introduserer flere nivåer med sikkerhet, og begrenser seg foreløpig til betalingsfiler på format ISO-20022. Det regnes med fremtidige utvidelser med flere tiltyper.

ISO-20022: En internasjonal meldingsstandard for betalingsfiler. Gjennom et sett obligatoriske og et sett valgfrie elementer åpnes det for regionale og nasjonale spesifikasjoner av standarden. I Norge er det Bits som står som ansvarlig for den nasjonale spesifikasjonen. Standarden definerer filer for for eksempel opprettelse av en utbetaling, kansellering av en betaling, bekreftelse på gjennomført betaling, rapport om mislykkede betalingsforsøk, kontoutskrift med mer. Filene er på XML-format. ISO-20022 er ment å erstatte Telepay og andre eldre formater for betalingsfiler.

ERP: Enterprise Resource Planning. System som gjerne brukes til mange av en bedrifts områder, deriblant økonomi, som er det relevante her. Kan brukes til regnskap og lønn, og kan integrere mot banker via betalingsfiler.

SKKO: Statens konsernkontoordning. Gjelder all betaling i statlige virksomheter. Arbeidskonti i banker må være knyttet opp mot oppgjørskonti i Norges Bank, med daglig overføring. Dette sørger for at alle statens midler daglig samles i Norges Bank

EHF: Elektronisk handelsformat. Et XML-format som her i Norge er mest kjent for å bli brukt til overføring av elektroniske fakturaer mellom virksomheter. Det er et krav at EHF skal brukes når fakturaer sendes til statlige virksomheter. I Norge er det også EHF det mest kjente bruksområdet til (vanlig) PEPPOL.

ASiC-E: ASiC står for Associated Signature Containers, E for Extended. Zip-fil som inneholder signerte dataobjekter og metadata. Kan ha multiple signaturer. Krypteres.