Nordlet

← Emuārs

Tādas grāmatvedības API izveide, kas iztur auditu

Praktisks ceļvedis drošības un audita kontrolēm, kas nepieciešamas finanšu API, pirms Nīderlandes uzņēmumi uztic tai savus datus.

Nordlet Team · · 9 min. lasīts

Grāmatvedības API, kas atgriež statusu 200 OK par maksājuma ierakstīšanu, būtībā nesniedz nekādu informāciju. Tā nav apstiprinājusi, ka virsgrāmata ir reģistrējusi šo ierakstu, ka subjektam bija tiesības to veikt, ka summa izturēja pārbaudi vai ka kāds ar attiecīgām pilnvarām to ir apstiprinājis. Uzņēmumiem Nīderlandē, kur nodokļu administrācija sagaida, ka datiem ir jābūt rekonstruējamiem un glabājamiem septiņus gadus, šī pretruna starp "pieprasījumam veicās veiksmīgi" un "dati ir pareizi" ir vieta, kur auditi cieš neveiksmi.

Gatavība auditam ir operatīvā dizaina mērķis, nevis sertifikāts. Tas nozīmē, ka API saglabā pilnu ķēdi: autentificēts subjekts attiecībā pret autorizētu darbību, kas pāriet uz validētu stāvokļa maiņu, apstiprinājumu, virsgrāmatas rezultātu un pret viltošanu drošiem pierādījumiem. Viss turpmāk minētais ir par mērķtiecīgu šīs ķēdes izveidi, nevis paļaušanos uz to, ka autentifikācija un TLS vieni paši visu atrisinās.

Kas padara grāmatvedības API gatavu auditam

Auditoram, kas rekonstruē darījumu, ir jāspēj atbildēt uz konkrētu jautājumu virkni. Kas to iniciēja? Vai viņam bija tādas tiesības? Vai izmaiņas izturēja grāmatvedības validāciju? Kas to apstiprināja? Ko reģistrēja virsgrāmata? Vai šo ierakstu var mainīt pēc fakta, neatstājot pēdas?

Ja jūsu API nespēj atbildēt uz visiem sešiem jautājumiem, izmantojot savus žurnālus un datu modeli, tā nav gatava auditam neatkarīgi no tā, cik tīrs izskatās kods. Lielākā daļa API labi tiek galā ar pirmo jautājumu, bet ar pārējiem slikti.

Kontroles, kas aizpilda šo robu, iedalās vairākās grupās: skaidrs grāmatvedības stāvoklis, slāņveida autorizācija, ierobežotas piekļuves autentifikācija, idemopotenti (idempotent) ieraksti, servera puses validācija, pienākumu sadalījums un pret viltošanu droša žurnālu veidošana. Tās savstarpēji papildina viena otru. Vāja autorizācija grauj spēcīgu audita žurnālu, jo jūs vairs nevarat uzticēties tam, ka reģistrētajam subjektam vispār bija pamats veikt šo darbību.

Modelējiet grāmatvedības stāvokļus pirms galapunktu (endpoint) modelēšanas

Visbiežāk pieļautā dizaina kļūda ir katra finanšu ieraksta uztveršana kā brīvi rediģējama objekta ar funkcijām create, read, update, delete. Grāmatvedība tā nedarbojas, un auditu veicējs uzreiz pamanīs, ja grāmatojumu var nemanāmi pārrakstīt.

Katram finansiāli būtiskajam resursam ir nepieciešams skaidrs galējo stāvokļu automāts (state machine). Žurnāla ieraksts vai maksājums parasti pārvietojas šādi:

draft → submitted → approved → posted → settled

Korekcijas nevirza ceļu atpakaļ. Ieraksts, kurā ir kļūda, saņem saistītu stornēšanas ierakstu (reversal) vai kompensējošu korekciju. Oriģināls paliek neskarts.

Strādājošu noteikumu kopa:

  • Melnrakstus (drafts) var rediģēt pilnvaroti lietotāji.
  • Iesniegtos ierakstus var rediģēt tikai noteiktas lomas vai atgriezt melnraksta statusā.
  • Apstiprinātiem ierakstiem ir nepieciešama kontrolēta grozīšana un jauns apstiprinājums.
  • Grāmatvidos iegrāmatotos ierakstus nevar pārrakstīt vai dzēst, tos var tikai stornēt vai koriģēt.
  • Izmaiņām slēgtajā periodā ir nepieciešama augstāka līmeņa autorizācija, norādīts iemesls un audita notikums.

Mēģinājumam veikt neatļautu pāreju, piemēram, rediģēt iegrāmatotu ierakstu, ir jāatgriež stabila kļūda un vienlaikus jāieraksta audita notikums. Neveiksmīgs mēģinājums arī ir pierādījums.

Šeit nemainīga divkāršā ieraksta (double-entry) virsgrāmata nopelna savu vietu. Nordlet virsgrāmata ir veidota tā, ka katrs darījums nonāk kā sabalansēts, pastāvīgs ieraksts, kura bilanci kommitēšanas brīdī nodrošina datu bāzes trigeris, bet korekcijas notiek, izmantojot stornēšanu, nevis pārrakstīšanu. Šis ierobežojums izstrādes laikā šķiet stingrs, bet auditā tas kļūst par galveno rīku, kuram grāmatvedis uzticas.

Autorizējiet katru pieprasījumu, ne tikai autentificējiet to

Autentifikācija pierāda, kas veic izsaukumu. Tā neko nepasaka par to, vai šis zvanītājs drīkst aiztikt konkrētu rēķinu, žurnālu vai juridisko personu. OWASP API drošības projekts (OWASP API Security Project) liek salauztu objektu līmeņa autorizāciju savu risku saraksta augšgalā tieši tāpēc, ka API atklāj objektu identifikatorus, kas atvieglo piekļuvi starp dažādiem nomniekiem (tenants), ja trūkst pārbaužu.

Katrs pieprasījums uz finanšu API ir jāautorizē, izmantojot vairāku faktoru kombināciju, nevis tikai marķieri (token):

  • autentificēts subjekts;
  • klienta lietotne vai servisa konts;
  • nomnieks (tenant);
  • juridiskā persona;
  • resursa ID;
  • pieprasītā operācija;
  • pašreizējais resursa stāvoklis;
  • summa vai darījuma slieksnis.

Divi praktiski noteiki ir svarīgāki par pārējiem. Pirmkārt, iegūstiet nomnieka un lietotāja kontekstu no autentificētās identitātes un noraidiet jebkuru klienta norādītu nomnieka vai lomas apgalvojumu, kas ar to konfliktē. Zvanītājs nekad nedrīkst pats noteikt, kura uzņēmuma vārdā viņš rīkojas. Otrkārt, izmantojiet principu "noklusējums ir liegums" (deny-by-default). Ja neviena politika nepārprotami nepiešķir darbību, tā cieš neveiksmi.

Testējiet abus virzienus. Horizontālā piekļuve, kur viens nomnieks piekļūst cita nomnieka datiem, un vertikālā piekļuve, kur parasts lietotājs piekļūst apstiprināšanas, grāmatošanas vai eksporta funkcijām. Abas ir izplatītas, un abas ir katastrofālas grāmatvedības datiem.

Nordlet lomu modelis, kurā ietilpst īpašnieks, administrators, grāmatvedis, vadītājs, izstrādātājs un skatītājs vairākiem uzņēmumiem viena konta ietvaros, pastāv tieši tāpēc, lai padarītu šo nodalīšanu obligātu, nevis tikai teorētisku. Izstrādātāja lomai, kas var izveidot rēķinu melnrakstus, nevajadzētu spēt izpildīt maksājumus.

Piešķiriet pilnvaras marķieriem atbilstoši biznesa iespējām, nevis CRUD darbības vārdiem

Delegētai piekļuvei izmantojiet pašreizējās OAuth 2.0 drošības vadlīnijas, nevis atkārtoti izmantojamas paroles vai plašas statiskas API atslēgas. RFC 9700 ir pašreizējā labākā prakse (Best Current Practice), kas nosaka skaidras prasības klientiem un autorizācijas serveriem: validēti pāradresācijas URI, PKCE ( Proof Key for Code Exchange), ja piemērojams, izdevēja un adresāta pārbaudes, īss piekļuves marķieru derīguma termiņš un atsvaidzināšanas marķieru (refresh-token) rotācija ar atsaukšanu.

Lēmums par piekļuves apjomu (scoping) ir vieta, kur parādās grāmatvedībai specifiska domāšana. Vispārīgi apjomi, piemēram, read un write, ir gandrīz bezjēdzīgi pienākumu sadalīšanai. Apjomiem ir jāatbilst iespējām:

  • journal:create un journal:approve ir atsevišķi apjomi.
  • Maksājuma norādījuma izveide nedod tiesības to izpildīt.
  • Eksporta atļauja atšķiras no lasīšanas atļaujas, jo masveida eksports ir datu noplūdes ceļš.

Esiet precīzi attiecībā uz to, kur konkrētais produkts atrodas šajā skalā. Nordlet API atslēgām ir moduļu līmeņa apjomi, piemēram, sales:read un sales:write, kas tiek pārbaudīti katrā darbībā. Tas nodrošina moduļu un lasīšanas/rakstīšanas nošķiršanu, taču neizšķir izveidi no apstiprināšanas. Ja jums šāds smalkāks dalījums ir nepieciešams jau tagad, ieviesiet to savā servisā pirms izsaukuma veikšanas.

Augstas vērtības operācijām ir vērts izvērtēt, vai ir piemērojams FAPI 2.0 drošības profils (FAPI 2.0 Security Profile). Tas tika izstrādāts API, kas aizsargā jutīgus finanšu datus, un piedāvā spēcīgākas garantijas nekā standarta OAuth. Lielākajai daļai MFU (mazo un vidējo uzņēmumu) grāmatvedības integrāciju nebūs nepieciešams viss profils pilnībā, taču maksājumu izpildes un bankas savienojumu plūsmas ir vietas, kur to apsvērt.

Nordlet piekļuve bez parolēm, izmantojot vienreizējās e-pasta saites, novērš atkārtoti izmantojamu paroļu problēmu cilvēka lietotājiem, kas nozīmē par vienu akreditācijas datu kopu mazāk, ko rotēt, nopludināt vai izmantot pikšķerēšanā.

Padariet finanšu ierakstus idemopotentus

Tīkli piedzīvo kļūdas pieprasījuma vidū. Klients nosūta maksājuma norādījumu, savienojums pārtrūkst pirms atbildes saņemšanas, un klients atkārto pieprasījumu. Bez aizsardzības jums tagad ir divi maksājumi.

Idempotences atslēgas atrisina šo problēmu. Klients nosūta unikālu atslēgu ar katru rakstīšanas pieprasījumu; serveris reģistrē atslēgu un tās rezultātu. Atkārtots mēģinājums ar to pašu atslēgu atgriež oriģinālo rezultātu, nevis izveido otru ierakstu. Nordlet pieņem Idempotency-Key galveni (header) katrā mutējošā izsaukumā, atkārtoti atskaņojot saglabāto atbildi mēģinājuma gadījumā ar to pašu datu kopu (payload) un noraidot to pašu atslēgu ar mainītiem datiem. Jebkurš grāmatvedības API, kas izlaiž šo funkciju, agri vai vēlu ģenerēs dubultus virsgrāmatas ierakstus, kurus kādam nāksies šķetināt ar rokām.

Apvienojiet to ar servera puses validāciju. Nekad neuzticieties klientam pārbaudīt, ka debeta summas sakrīt ar kredītu, ka PVN likme ir derīga attiecīgajai valstij un periodam, vai ka konts eksistē. Validācija tiek veikta serverī pirms stāvokļa maiņas, un noraidīts rakstīšanas pieprasījums rada stabilu kļūdu un audita ierakstu.

Pret viltošanu droši audita žurnāli un Nīderlandes datu glabāšanas prasības

Audita žurnāls ir pierādījumu slānis, un tam ir citas prasības nekā parastiem biznesa datiem. Tajā jāreģistrē autorizācijas lēmums, politikas versija, subjekts, objekts, operācija, iepriekšējais un jaunais stāvoklis, kā arī iemesla kods, nekad neierakstot noslēpumus vai pilnus maksājuma datus.

Kritiskā īpašība ir aizsardzība pret viltošanu. Ja administrators var klusītēm labot vai dzēst audita ierakstus, žurnāls neko nepierāda. Šo problēmu risina tikai pievienošanas tipa krātuves (append-only), kriptogrāfiskā saistīšana vai vienreiz rakstāma glabāšana (write-once). Galvenais ir tas, ka jebkurām izmaiņām ir jābūt konstatējamām.

Glabāšanas ilgumam ir nepieciešama pašam sava politika, kas nodalīta no biznesa datu dzēšanas. Nīderlandē vispārējais administratīvo ierakstu glabāšanas periods ir septiņi gadi, savukārt ierakstiem, kas saistīti ar nekustamo īpašumu, tas ilgst desmit gadus. Jūsu parastajām datu dzēšanas un GDPR datu dzēšanas darbplūsmām nedrīkst būt iespējas iznīcināt ierakstus vai audita pierādījumus, uz kuriem attiecas likumā noteiktie glabāšanas noteikumi. Definējiet juridisko aizturēšanu (legal hold), arhivēšanu un dzēšanas noteikumus audita pierādījumiem neatkarīgi un saskaņojiet tos ar jurisdikcijām, kurās darbojaties.

Periodu slēgšana to atbalsta grāmatvedības līmenī. Kad mēnesis ir slēgts, tajā esošos ierakstus nevar mainīt bez augstāka līmeņa autorizācijas un reģistrēta iemesla. Nordlet nodrošina periodu slēgšanu, lai slēgti mēneši paliktu slēgti, noraidot jebkuru grāmatojumu ar datumu slēgtā periodā pat caur API, kas ir viena no pirmajām lietām, ko pārbauda Nīderlandes auditors.

Nodrošiniet drošību malās: tīmekļa āķi (webhooks), eksporti un integrācijas

Pamata API parasti ir vislabāk aizsargātā sistēmas daļa. Malas noplūst.

Tīmekļa āķi ir viltotu pieprasījumu risks. Tādam notikumam kā sale_invoice.paid ir jābūt parakstītam, lai saņēmējs varētu pārbaudīt, ka tas nācis no jums, un saņēmējiem vajadzētu uzskatīt piegādi par notiekošu vismaz vienu reizi (at-least-once) un izmantot notikuma ID dublikātu novēršanai. Nordlet paraksta katru tīmekļa āķa piegādi ar HMAC parakstu virs neapstrādātā pamatteksta un atkārto neizdevušās piegādes ar eksponenciālu aizturi, tāpēc saņēmējam ir jāpārbauda paraksts un jānovērš dublikāti pēc notikuma ID, nevis jāpaļaujas uz precīzi vienu piegādi (exactly-once).

Eksportēšana ir masveida datu noplūdes ceļš. Atskaišu eksportēšana XLSX, PDF vai JSON formātā vienā operācijā izvelk lielu apjomu finanšu datu, tāpēc tai ir nepieciešama sava atļauja, ātruma limiti un audita žurnālu ieraksti. Trešo pušu integrācijas, ko jūs patērējat, ir jāuztver kā neuzticami dati, kas jāvalidē tāpat kā tieši klienta pieprasījumi.

Audita gatavības kontrolsaraksts Nīderlandes grāmatvedības API

Izmantojiet šo sarakstu, pirms apgalvojat, ka integrācija ir gatava auditam:

  • Skaidrs stāvokļu automāts katram finanšu resursam; iegrāmatotus ierakstus nevar pārrakstīt.
  • Objektu līmeņa un juridiskās personas autorizācija katram pieprasījumam, noklusējums ir liegums.
  • Nomnieka un lomas konteksts, kas iegūts no marķiera, nevis klienta apgalvojumiem.
  • OAuth 2.0 saskaņā ar RFC 9700; uz spējām balstīti apjomi; nošķirta izveide un apstiprināšana.
  • Pienākumu sadalījums ieviests lomās, nevis tikai dokumentēts.
  • Idempotences atslēgas visiem finanšu rakstīšanas pieprasījumiem.
  • Servera puses grāmatvedības un PVN validācija pirms stāvokļa pārejām.
  • Pievienošanas tipa, pret viltošanu drošs audita žurnāls ar iemesla kodiem.
  • Glabāšanas un juridiskās aizturēšanas noteikumi, kas pielāgoti Nīderlandes periodiem (septiņi gadi, desmit gadi īpašumam).
  • Periodu slēgšana slēgtajiem mēnešiem.
  • Parakstīti tīmekļa āķi ar dublikātu novēršanu; ierobežota apjoma, ar ātruma limitiem un reģistrēti eksportēšanas dati.

Ko mēs izveidotu vispirms

Ja mēs rīt integrētu grāmatvedību Nīderlandes platformā, mēs sāktu ar stāvokļu modeli un objektu līmeņa autorizāciju, pirms uzrakstīt kaut vienu biznesa galapunktu. Šie divi lēmumi nosaka visu turpmāko, un to ieviešana sistēmā, kas uztvēra virsgrāmatas ierakstus kā rediģējamas rindas, ir patiesi sarežģīta. Idempotence un audita žurnāls seko nākamie, jo tos ir lēti pievienot agri un dārgi vēlāk, kad dati jau plūst.

Pārējais – marķieri ar piekļuves apjomiem, parakstīti tīmekļa āķi, periodu slēgšana – seko vieglāk, kad pamats ir stabils. Visu to var testēt smilšu kastes uzņēmumā (sandbox), pirms tas skar produkcijas datus.

FAQ

Vai audits gatavs API nozīmē, ka uzņēmums ir atbilstošs noteikumiem?

Nē, un ir vērts to precizēt. Gatavība auditam ir sistēmas dizaina īpašība: virsgrāmata, kontroles un pierādījumu ķēde ir veidota tā, lai audits varētu izdoties. Atbilstība konkrētam nodokļu, grāmatvedības vai drošības standartam ir atsevišķs novērtējums, kas sasaista šīs kontroles ar konkrētu standartu. Labi izveidots API atvieglo atbilstības nodrošināšanu, bet tas to neaizstāj.

Cik ilgi grāmatvedības ieraksti ir jāglabā Nīderlandē?

Vispārīgais pienākums ir septiņi gadi administratīvajiem ierakstiem, kas attiecas arī uz desmit gadiem ierakstiem, kuri saistīti ar nekustamo īpašumu. Izveidojiet glabāšanas un juridiskās aizturēšanas noteikumus, kurus jūsu parastās dzēšanas darbplūsmas nevar ignorēt.

Vai statiska API atslēga ir pietiekama finanšu integrācijai?

Serveru savstarpējai automatizācijai ar šaurām pilnvarām tā var darboties, taču atkārtoti izmantojamas statiskas atslēgas ir grūti rotēt un bīstamas noplūdes gadījumā. Delegētai piekļuvei un jebkurai plūsmai, kas saskaras ar cilvēku, OAuth 2.0 ar īslaicīgiem marķieriem, kuru apjomi ir ierobežoti atbilstoši iespējām, ir drošāka izvēle.

Kāpēc idempotence ir tik svarīga tieši grāmatvedībā?

Tāpēc, ka dubultraksts lielākajā daļā sistēmu ir neērtība, bet dubultraksts grāmatvedībā ir nepareizs skaitlis grāmatās, kuru kādam ir jāatrod un jāstornē. Idempotences atslēgas padara atkārtotus mēģinājumus drošus, nevis riskantus.

Papildu lasāmviela