Nordlet

← Blogi

Selline raamatupidamise API, mis peab auditi vastu

Praktiline juhend turva- ja auditikontrollide kohta, mida finants-API vajab, enne kui Hollandi ettevõtted saavad oma raamatupidamise sellele usaldada.

Nordlet Team · · 8 min lugemist

Raamatupidamise API, mis tagastab maksekande tegemisel koodi 200 OK, ei ütle teile peaaegu midagi. See ei ole kinnitanud, et pearaamat salvestas kande, et toimingu tegijal oli selleks õigus, et summa läbis valideerimise või et keegi volitatud isik kiitis selle heaks. Hollandi ettevõtete jaoks, kus maksuhaldur ootab dokumentide rekonstrueeritavust ja säilitamist seitsme aasta jooksul, tekib just nõude „päring õnnestus“ ja „raamatupidamine on korrektne“ vahele see lünk, mille tõttu auditid ebaõnnestuvad.

Auditivalmidus on operatiivne disainieesmärk, mitte sertifikaat. See tähendab, et API säilitab täieliku ahela: autentitud toimija kuni volitatud tegevuseni, valideeritud olekumuudatus, kinnitus, pearaamatu tulemus ja tõendeid säilitav logi. Alljärgnev räägib selle ahela teadlikust ehitamisest, selle asemel et loota autentimisele ja TLS-ile.

Mis teeb raamatupidamise API auditikindlaks

Audiitor, kes tehingut rekonstrueerib, peab saama vastused kindlale küsimuste järjestusele. Kes selle algatas? Kas tal oli selleks luba? Kas muudatus läbis raamatupidamisliku valideerimise? Kes selle heaks kiitis? Mida pearaamat salvestas? Kas seda kirjet saab tagantjärele muuta ilma jälgi jätmata?

Kui teie API ei suuda kõigile kuuele küsimusele oma logide ja andmemudeli põhjal vastata, ei ole see auditikindel, olenemata sellest, kui puhas kood välja näeb. Enamik API-sid käsitleb esimest küsimust hästi ja ülejäänuid kehvasti.

Kontrollmehhanismid, mis selle lünga täidavad, jagunevad mitmesse rühma: selge raamatupidamislik olek, mitmekihiline autoriseerimine, piiritletud autentimine, identsed (idempotentsed) kirjutised, serveripoolne valideerimine, tööülesannete eraldatus (segregation of duties) ja võltsimiskindel logimine. Need toetavad üksteist. Nõrk autoriseerimine õõnestab tugevat auditilogid, sest te ei saa enam usaldada, et logitud toimijal oli üldse õigus seda toimingut teha.

Modelleerige raamatupidamislikud olekud enne lõpp-punktide modelleerimist

Kõige levinum disainiviga on kõigi finantskirjete käsitlemine vabalt redigeeritavate objektidena, millel on funktsioonid create, read, update ja delete. Raamatupidamine ei tööta nii ja audiitor märkab kohe, kui sisestatud the kande saab salaja üle kirjutada.

Iga finantsiliselt oluline ressurss vajab selget olekumasinat (state machine). Journal entry ehk pearaamatu kanne või makse liigub tavaliselt järgmiselt:

draft → submitted → approved → posted → settled

Parandused ei vii seda teed tagasi. Vigane postitatud kanne saab lingitud paranduskande või kompenseeriva korrigeerimise. Originaal jääb puutumatuks.

Toimiv reeglistik:

  • Mustandeid (draft) saavad volitatud kasutajad redigeerida.
  • Esitatud kirjeid saavad redigeerida ainult lubatud rollid või need saab suunata tagasi mustandiks.
  • Kinnitatud kirjed nõuavad kontrollitud muutmist ja uut heakskiitu.
  • Postitatud kirjeid ei saa üle kirjutada ega kustutada, vaid ainult tühistada või korrigeerida.
  • Suletud perioodi muudatused vajavad kõrgemat autoriseerimist, põhjendust ja audtisündmust.

Katse teha ebaseaduslik üleminek, näiteks redigeerida postitatud kirjet, peaks tagastama stabiilse vea ja kirjutama siiski auditikirje. Ebaõnnestunud katse on samuti tõendusmaterjal.

Siin teenib muutumatu ehk immutaabelne kahekordse kirjendamisega pearaamat oma koha välja. Nordlet's ledger on ehitatud nii, et iga tehing jõuab pärale tasakaalustatud püsikandena, kusjuures tasakaalu tagab andmebaasi käivitaja (trigger) toimumise hetkel ning parandused tehakse ümberpööramiste, mitte ülekirjutamiste kaudu. See piirang tundub arenduse ajal piirav, kuid muutub millekski, mida teie raamatupidaja auditi ajal usaldab.

Autoriseerige iga päring, mitte ainult ärge autentige seda

Autentimine tõestab, kes teeb päringu. See ei ütle midagi selle kohta, kas see helistaja võib puudutada konkreetset arvet, päevikut või juriidilist isikut. OWASP API Security Project seab katkenud objekti tasemel autoriseerimise (broken object-level authorization) oma riskinimekirja tippu just seetõttu, et API-d avaldavad objektide identifikaatoreid, mis teevad üürnikevahelise (cross-tenant) ligipääsu lihtsaks, kui kontrollid puuduvad.

Iga finants-API päringut tuleks autoriseerida tegurite kombinatsiooni, mitte ainult žetooni (token) alusel:

  • autentitud toimija
  • klientrakendus või teenusekonto
  • tenant (rentnik)
  • juriidiline isik
  • ressursi ID
  • taotletud toiming
  • ressursi praegune olek
  • summa või tehingu lävi

Kaks praktilist reeglit on ülejäänutest olulisemad. Esiteks, tuletage tenanti- ja kasutajakontekst autentitud identiteedist ning lükake tagasi kõik kliendi esitatud tenanti- või rollinõuded, mis sellega vastuolus on. Helistaja ei tohiks kunagi ise otsustada, millise ettevõtte nimel ta tegutseb. Teiseks, kasutage vaikimisi keelamise põhimõtet (deny-by-default). Kui ükski reegel ei anna selgesõnaliselt tegevusluba, siis see ebaõnnestub.

Testige mõlemat suunda. Horisontaalne juurdepääs, kus üks tenant pääseb ligi teise tenanti andmetele, ja vertikaalne juurdepääs, kus tavakasutaja pääseb ligi kinnitamis-, postitamis- või eksportfunktsioonidele. Mõlemad on levinud ja raamatupidamisandmetes katastroofilised.

Nordlet'i rollimudel – mis hõlmab omaniku, administraatori, raamatupidaja, juhi, arendaja ja vaataja rolle mitme ettevõtte vahel ühe konto all – on loodud selleks, et muuta see eraldatus jõustatavaks, mitte vaid heaks sooviks. Arendaja roll, mis saab luua arvemustandeid, ei tohiks saada makseid vabastada.

Piirake žetoonid ärivõimekuste, mitte CRUD-verpide järgi

Delegeeritud juurdepääsu jaoks kasutage OAuth 2.0 praeguseid turvajuhiseid, mitte korduvalt kasutatavaid paroole või laiu staatilisi API-võtmeid. RFC 9700 on kehtiv parim praktika (Best Current Practice), mis seab klientidele ja autoriseerimisserveritele selged nõuded: valideeritud ümbersuunamisaadressid, vajaduse korral PKCE, emitendi ja sihtrühma (audience) kontroll, lühike juurdepääsužetooni eluiga ning värskendusžetooni rotatsioon koos tühistamisega.

Õiguste ulatuse (scope) määramine on koht, kus avaldub raamatupidamisspetsiifiline mõtlemine. Üldised õigused nagu read ja write on tööülesannete eraldamiseks peaaegu kasutud. Õigused peaksid vastama konkreetsetele võimekustele:

  • journal:create ja journal:approve on eraldi õigused.
  • Maksekorralduse loomine ei anna luba selle vabastamiseks.
  • Ekspordiõigus erineb lugemisõigusest, kuna hulgieksport on andmelekkekanal.

Olge täpsed selle suhtes, kus konkreetne toode sellel skaalal asub. Nordlet'i API-võtmetel on moodulipõhised õigused, näiteks sales:read ja sales:write, mida kontrollitakse igal toimingul. See eraldab moodulid ning lugemise kirjutamisest, kuid mitte loomist kinnitamisest – kui vajate täpsemat eristust, rakendage see enne päringu tegemist oma teenuses.

Kõrge väärtusega toimingute puhul tasub hinnata, kas kehtib FAPI 2.0 Security Profile. See on loodud tundlikke finantsandmeid kaitsvate API-de jaoks ja pakub tugevamaid tagatisi kui tavaline OAuth. Enamik VKE-de raamatupidamisintegratsioone ei vaja kogu profiili, kuid maksete vabastamise ja pangaga ühenduse loomise vood on kohad, kus seda kaaluda.

Nordlet'i paroolivaba sisselogimine ühekordsete e-posti linkide kaudu kõrvaldab korduvkasutatava parooli probleemi inimkasutajate jaoks, jättes ühe mandaadi vähemaks, mida saaks pöörata, lekkida või õngitseda.

Muutke finantskirjutised identseks (idempotentseks)

Võrgud kukuvad keset päringut kokku. Klient saadab maksekorralduse, ühendus katkeb enne vastuse saabumist ja klient proovib uuesti. Ilma kaitseta on teil nüüd kaks makset.

Identse päringu võtmed (idempotency keys) lahendavad selle. Klient saadab iga kirjutusega unikaalse võtme; server salvestab võtme ja selle tulemuse. Korduskatse sama võtmega tagastab algse tulemuse teise kirje loomise asemel. Nordlet aktsepteerib igal muutval päringul päist Idempotency-Key, esitab korduskatse korral uuesti salvestatud vastuse sama sisuga ja lükkab sama võtme muudetud sisuga tagasi. Iga raamatupidamise API, mis selle funktsiooni vahele jätab, tekitab varem või hiljem topeltkandeid, mida keegi peab käsitsi harutama.

Siduge see serveripoolse valideerimisega. Ärge kunagi usaldage klienti, et ta kontrolliks debetite ja kreeditite võrdsust, KM-määra kehtivust riigi ja perioodi jaoks või konto olemasolu. Valideerimine toimub serveris enne olekumuutust ja tagasilükatud kirjutamine tekitab stabiilse vea ning auditikirje.

Võltsimiskindlad auditilogid ja Hollandi säilitusnõuded

Auditilogi on tõendite kiht ja sellel on tavapäraste äriandmetega võrreldes erinevad nõuded. See peaks salvestama autoriseerimisotsuse, reeglite versiooni, toimija, objekti, toimingu, eelmise ja uue oleku ning põhjenduse koodi, salvestamata kunagi saladusi või täielikke maksemandaate.

Kriitiline omadus on võltsimiskindlus (tamper-evident). Kui administraator saab auditikirjeid vaikselt muuta või kustutada, ei tõesta logi midagi. Lisamispõhine (append-only) salvestusruum, krüptograafiline aheldamine või kirjutuskaitstud (write-once) säilitamine lahendavad selle. Oluline on see, et muudatus peab olema tuvastatav.

Säilitamine väärib oma reeglistikku, mis on ärikirjete kustutamisest eraldi. Hollandis on haldusdokumentide üldine säilitustähtaeg seitse aastat ja kinnisvaraga seotud dokumentide puhul kümme aastat. Teie tavapärased andmete kustutamise ja GDPR-i eemaldamise töövood ei tohi hävitada kirjeid või audtitõendeid, mida seaduslik säilitusreegel endiselt katab. Määrake audititõendite jaoks õiguslikud säilitamis-, arhiveerimis- ja kustutamisreeglid eraldi ning siduge need jurisdiktsioonidega, kus te tegutsete.

Perioodi lukustamine (period locking) toetab seda raamatupidamiskihis. Kui kuu on suletud, ei saa selles olevaid kirjeid muuta ilma kõrgema taseme autoriseerimise ja logitud põhjenduseta. Nordlet jõustab perioodi lukustamist, nii et suletud kuud jäävad suletuks, lükates tagasi kõik lukustatud perioodi sisse kuupäevastatud kanded isegi API kaudu, mis on üks esimesi asju, mida Hollandi audiitor kontrollib.

Kaitske ääri: veebikonksud, ekspordid ja integratsioonid

Põhi-API on süsteemi parimal viisil kaitstud osa. Ääred lekivad.

Veebikonksud (webhooks) kujutavad endast võltsitud päringu riski. Selline sündmus nagu sale_invoice.paid tuleks allkirjastada, et vastuvõtja saaks kontrollida selle päritolu, ning vastuvõtjad peaksid käsitlema edastust vähemalt üks kord (at-least-once) põhimõttel ja kasutama sündmuse ID-d dubleerimise vältimiseks. Nordlet allkirjastab iga veebikonksu edastuse HMAC-allkirjaga toorandmete põhjal ja teeb ebaõnnestunud edastustele eksponentsiaalse tagasipöördumise (exponential backoff) katseid, nii et vastuvõtja peab allkirja kontrollima ja dubleerimise eemaldama sündmuse ID järgi, mitte eeldama täpselt üks kord (exactly-once) edastust.

Ekspordid on hulgimüügi andmelekkekanal. Aruannete eksport XLSX-, PDF- või JSON-vormingus tõmbab ühe toiminguga sisse suure hulga finantsandmeid, mistõttu vajavad need oma õigusi, kiiruspiiranguid (rate limits) ja auditilogi. Kolmandate osapoolte integratsioone tuleks käsitleda ebausaldusväärse sisendina, mida valideeritakse samamoodi nagu otseseid kliendipäringuid.

Auditivalmiduse kontroll-leht Hollandi raamatupidamise API jaoks

Kasutage seda enne väitmist, et integratsioon on auditivalmis:

  • Selge olekumasin igal finantsressursil; postitatud kirjeid ei saa üle kirjutada
  • Objekti ja juriidilise isiku tasemel autoriseerimine igal päringul, vaikimisi keelamine
  • Žetoonist tuletatud tenanti- ja rollikontekst, mitte kliendi väited
  • OAuth 2.0 vastavalt standardile RFC 9700; võimekuspõhised õigused; eraldi loomine ja kinnitamine
  • Rollides jõustatud tööülesannete eraldatus, mitte ainult dokumentatsioonis
  • Identsed päringuvõtmed kõigil finantskirjutistel
  • Serveripoolne raamatupidamise ja KM valideerimine enne olekumuutusi
  • Lisamispõhine, võltsimiskindel auditilogi põhjenduskoodidega
  • Hollandi perioodidega seotud säilitus- ja hoidmisreeglid (seitse aastat, kinnisvara puhul kümme)
  • Perioodi lukustamine suletud kuudel
  • Allkirjastatud veebikonksud dubleerimise vältimisega; piiratud ulatuse ja kiirusega ning logitud ekspordid

Mida me ehitaksime esimesena

Kui me homme manustaksime raamatupidamise Hollandi platvormi sisse, alustaksime olekumudelist ja objekti tasemel autoriseerimisest enne ühegi äripoole lõpp-punkti kirjutamist. Need kaks otsust piiravad kõike allpool olevat ja nende tagantjärele lisamine süsteemi, mis kohtles pearaamatu kirjeid redigeeritavate ridadena, on tõeliselt valus. Identsed päringud ja auditilogi tulevad järgmisena, sest neid on odav varakult lisada ja kallis lisada siis, kui andmed juba liiguvad.

Ülejäänu – piiritletud žetoonid, allkirjastatud veebikonksud, perioodi lukustamine – järgneb kergemini, kui vundament püsib. Kõike seda saab testida liivakastis (sandbox company) enne, kui miski puudutab toodanguandmeid.

FAQ

Kas auditikindel API tähendab, et ettevõte vastab nõuetele?

Ei, ja seda tasub täpselt mõista. Auditivalmidus on süsteemi disainiomadus: pearaamat, kontrollmehhanismid ja tõendite ahel on ehitatud nii, et audit saab õnnestuda. Konkreetsele maksu-, raamatupidamis- või turvaraamistikule vastavus on eraldi hinnang, mis kaardistab need kontrollid nimelisele standardile. Hästi ehitatud API teeb nõuetele vastavuse töö lihtsamaks, kuid see ei asenda seda.

Kui kaua tuleb raamatupidamisdokumente Hollandis säilitada?

Üldine kohustus on haldusdokumentide puhul seitse aastat, mis ulatub kinnisvaraga seotud dokumentide puhul kümne aastani. Looge säilitus- ja hoidmisreeglid, mida teie tavapärased kustutamistöövood ei saa alistada.

Kas staatilisest API-võtmest piisab finantsintegratsiooni jaoks?

Serveritevahelise kitsa ulatusega automatiseerimise jaoks võib see toimida, kuid korduvalt kasutatavaid staatilisi võtmeid on raske pöörata ja need on lekkimise korral ohtlikud. Delegeeritud juurdepääsu ja inimeste jaoks mõeldud voogude jaoks on lühiajaliste, võimekuspõhiste žetoonidega OAuth 2.0 tugevam valik.

Miks on identne päring (idempotency) just raamatupidamise jaoks nii oluline?

Kuna topeltkirjutis on enamikus süsteemides tüütus, kuid raamatupidamises tähendab topeltkirjutis raamatupidamises vale numbrit, mille keegi peab leidma ja ümber pöörama. Identse päringu võtmed muudavad korduskatsetused riskantse asemel turvaliseks.

Lisalugemist