Część VIII. Co jeszcze widzi Imperva?

Jaw­no­ść me­ta­da­ny­ch JSON w KSeF i jej kon­se­kwen­cje

  W po­przed­niej czę­ści do­kład­nie opi­sa­łem, ja­kie tech­nicz­ne me­ta­da­ne pro­to­ko­łu HTTPS wi­dzi Im­pe­rva ja­ko war­stwa po­śred­nia przy ter­mi­na­cji TLS: ad­res IP nadaw­cy, na­głów­ki HTTP, pa­ra­me­try trans­por­tu, roz­mia­ry pa­kie­tów, cza­sy od­po­wie­dzi etc. To da­je ogrom­ny cień dzia­ła­nia sys­te­mu, ale cień ten mo­że być uży­tecz­ny sam w so­bie ja­ko źró­dło wie­dzy wy­wia­dow­czej.

  W tej czę­ści idę krok da­lej. Wy­kazuję, iż Im­pe­rva wi­dzi tak­że peł­ne me­ta­da­ne biz­ne­so­we prze­sy­ła­ne przez API KSeF w od­po­wie­dzia­ch JSON, oraz opi­suję kon­se­kwen­cje ta­ki­ch in­for­ma­cji.

  Zrobiłem dodatkowy au­dyt tech­nicz­ny, któ­ry na pod­sta­wie te­stów łą­cze­nia się z API KSeF wy­ka­zał jaw­no­ść me­ta­da­ny­ch JSON po ter­mi­na­cji TLS przez Im­pe­rvę i wy­pi­sał kon­kret­ne po­la, któ­re są wi­docz­ne w od­po­wie­dzia­ch ser­we­ra: ]]>Audyt techniczny: jawność metadanych JSON w KSeF przy terminacji TLS przez Imperva]]>

Im­pe­rva wi­dzi me­ta­da­ne biz­ne­so­we w JSON w od­po­wie­dzia­ch API KSeF

  Tre­ść fak­tu­ry XML je­st szy­fro­wa­na (E2E), niemniej ana­li­za API po­ka­zu­je coś ciekawego: od­po­wie­dzi end­po­in­tów zwra­ca­ją roz­sze­rzo­ny JSON z me­ta­da­ny­mi fak­tur. Te me­ta­da­ne:

• nie są czę­ścią za­szy­fro­wa­ne­go blo­bu XML,
• są od ra­zu do­stęp­ne w od­po­wie­dzi JSON,
• mo­gą za­wie­rać da­ne iden­ty­fi­ku­ją­ce trans­ak­cje.

  Do­kład­na li­sta pól jaw­nie zwra­ca­ny­ch przez ser­wer i wi­docz­ny­ch dla Im­pe­rvy obej­mu­je (we­dług spe­cy­fi­ka­cji API ana­li­zo­wa­nej w au­dy­cie).

Wi­docz­ne w JSON me­ta­da­ne fak­tur:

• NIP sprze­daw­cy – iden­ty­fi­ka­tor po­dat­ko­wy wy­staw­cy fak­tu­ry,
• iden­ty­fi­ka­tor na­byw­cy – NIP / VAT UE / in­ny iden­ty­fi­ka­tor od­bior­cy,
• na­zwa sprze­daw­cy i na­byw­cy – peł­ne na­zwy pod­mio­tów,
• kwo­ty net­to, VAT i brut­to – fi­nan­so­we war­to­ści trans­ak­cji,
• wa­lu­ta – w ja­kiej opła­co­no fak­tu­rę,
• nu­mer fak­tu­ry – uni­kal­ny iden­ty­fi­ka­tor do­ku­men­tu,
• da­ty ope­ra­cyj­ne – da­ta wy­sta­wie­nia, da­ta przy­ję­cia do sys­te­mu,
• typ fak­tu­ry – VAT, ko­rek­ta, za­licz­ka etc.

  Me­ta­da­ne te nie są za­szy­fro­wa­ne w apli­ka­cyj­nym blo­bie — są zwra­ca­ne bez­po­śred­nio w JSON ja­ko od­po­wie­dź na za­py­ta­nia o me­ta­da­ne (/in­vo­ices/qu­ery/me­ta­da­ta). To ozna­cza, iż me­ta­da­ne te są jaw­ne dla war­stwy, któ­ra ter­mi­nu­jąc TLS, od­szy­fro­wu­je ru­ch, czy­li w prak­ty­ce dla Im­pe­rvy. Au­dyt tech­nicz­ny po­twier­dza jaw­no­ść ty­ch da­ny­ch,

  Peł­ny au­dyt tech­nicz­ny pt. „Jaw­no­ść me­ta­da­ny­ch JSON w KSeF przy ter­mi­na­cji TLS przez Im­pe­rva” do­ku­men­tu­je to ob­ser­wa­cyj­nie:

• ru­ch do API KSeF prze­cho­dzi przez in­fra­struk­tu­rę Im­pe­rva (na­głó­wek X-CDN: Im­pe­rva, DNS, IP),
• war­stwa ta ter­mi­nu­je szy­fro­wa­nie TLS, czy­li od­czy­tu­je ca­ły ru­ch HTTP/HTTPS,
• od­po­wie­dzi API za­wie­ra­ją me­ta­da­ne biz­ne­so­we w pla­in­te­xt JSON,
• te me­ta­da­ne są więc tech­nicz­nie wi­docz­ne dla Im­pe­rvy.

  Au­dyt za­wie­ra kon­kret­ne ko­men­dy te­sto­we, przy­kła­do­we od­po­wie­dzi JSON oraz ana­li­zę pól me­ta­da­ny­ch. Dla­cze­go to ma zna­cze­nie? Tech­nicz­na moż­li­wo­ść od­czy­tu me­ta­da­ny­ch JSON z API ma wy­miar zna­czą­co więk­szy niż tyl­ko tech­nicz­ny. Po­ni­żej opi­su­ję naj­waż­niej­sze kon­se­kwen­cje.

Peł­ny ob­raz biz­ne­so­wej ak­tyw­no­ści

  Me­ta­da­ne fak­tur to nie tyl­ko bez­piecz­ne pod­pi­sy i tech­nicz­ne iden­ty­fi­ka­to­ry — to rdzeń ob­ra­zu dzia­łal­no­ści go­spo­dar­czej:

• kie­dy ja­kie fir­my wy­sta­wia­ją fak­tu­ry,
• z kim i w ja­kiej kwo­cie do­ko­nu­ją trans­ak­cji,
• ja­kie bran­że są ak­tyw­ne w da­nym okre­sie,
• któ­re sek­to­ry go­spo­dar­ki ma­ją wy­so­ką ro­ta­cję.

  To ze­staw in­for­ma­cji, któ­ry w kla­sycz­ny­ch śro­do­wi­ska­ch ana­li­tycz­ny­ch da­je moż­li­wo­ść bu­do­wy ma­py prze­pły­wów go­spo­dar­czy­ch, tren­dów, za­leż­no­ści mię­dzy pod­mio­ta­mi oraz roz­po­zna­nia wzor­ców ak­tyw­no­ści ryn­ko­wej — bez ko­niecz­no­ści od­czy­ty­wa­nia tre­ści fak­tur.

Ana­li­za ryt­mu i tren­dów trans­ak­cyj­ny­ch

  Im­pe­rva wi­dzi rów­nież:

• czę­sto­tli­wo­ść za­py­tań o me­ta­da­ne,
• ilo­ść żą­dań we­dług NIP,
• ti­me­stam­py ope­ra­cji,
• roz­kład cza­so­wy trans­ak­cji.

  To po­zwa­la wy­ło­nić tem­po ob­ro­tu go­spo­dar­cze­go, in­ten­syw­no­ść dzia­ła­nia pod­mio­tów oraz se­zo­no­wo­ść ryn­ko­wą — bez ko­niecz­no­ści od­czy­tu da­ny­ch ukry­ty­ch w XML.

Ana­li­za geo­lo­ka­li­za­cja i ak­tyw­no­ści sie­cio­wej

  Dzię­ki wi­docz­no­ści ad­re­sów IP i ich wła­ści­wo­ści (ope­ra­tor sie­ci, re­gion, ho­sting) moż­li­we je­st:

• łą­cze­nie dzia­łal­no­ści go­spo­dar­czej z geo­lo­ka­li­za­cją pod­mio­tów,
• śle­dze­nie zmian ak­tyw­no­ści we­dług re­gio­nów,
• iden­ty­fi­ko­wa­nie źró­deł za­py­tań agre­go­wa­ny­ch (np. plat­form księ­go­wy­ch czy ma­so­wy­ch in­te­gra­to­rów).

  To nie je­st kryp­to­gra­ficz­ne od­czy­ta­nie tre­ści — to ana­li­za za­cho­wań i wzor­ców ko­mu­ni­ka­cyj­ny­ch.

Moż­li­wo­ści ana­li­ty­ki bez­pie­czeń­stwa i nad­użyć

  Wi­docz­no­ść me­ta­da­ny­ch da­je tak­że po­ten­cjał:

• bu­do­wa­nia pro­fi­li ry­zy­ka pod­mio­tów na pod­sta­wie ak­tyw­no­ści trans­ak­cyj­nej,
• iden­ty­fi­ko­wa­nia ano­ma­lii (np. na­gły wzro­st za­py­tań o okre­ślo­ne NIP),
• wy­kry­wa­nia po­ten­cjal­ny­ch bo­tów lub au­to­ma­tycz­ny­ch sys­te­mów ma­so­wy­ch ope­ra­cji.

  To wszyst­ko bez do­stę­pu do za­szy­fro­wa­nej tre­ści XML.

Pod­su­mo­wa­nie

  Im­pe­rva ja­ko WAF i re­ver­se pro­xy, ter­mi­nu­jąc TLS, wi­dzi znacz­nie wię­cej niż tyl­ko na­głów­ki po­łą­czeń, do­kład­nie to, co zo­sta­ło opi­sa­ne w po­przed­niej czę­ści VII. Do­dat­ko­wo mo­że ob­ser­wo­wać i ana­li­zo­wać wszyst­kie me­ta­da­ne JSON zwra­ca­ne przez API KSeF, w tym: NIP sprze­daw­cy i na­byw­cy, na­zwy pod­mio­tów, kwo­ty net­to/VAT/brut­to, wa­lu­tę trans­ak­cji, nu­mer fak­tu­ry, da­ty ope­ra­cyj­ne i typ fak­tu­ry.

  Ta jaw­no­ść me­ta­da­ny­ch otwie­ra dro­gę do bu­do­wy kom­plek­so­wy­ch ana­liz go­spo­dar­czy­ch, be­ha­wio­ral­ny­ch i sie­cio­wy­ch, któ­re nie wy­ma­ga­ją zna­jo­mo­ści tre­ści fak­tur, a jed­no­cze­śnie po­zwa­la­ją od­two­rzyć ob­raz te­go, co dzie­je się w go­spo­dar­ce.

Grzegorz GPS Świderski
]]>Kanał Blogera GPS]]>
]]>GPS i Przyjaciele]]>
]]>X.GPS65]]>

PS. Poprzednie części:

• Czę­ść I. ]]>KSeF nie po­sze­rza in­wi­gi­la­cji. KSeF zwięk­sza roz­dziel­czo­ść.]]>
• Czę­ść II. ]]>Prak­ty­ka KSeF: Hurt­Pol kon­tra Ko­wal­ski i Sy­no­wie.]]>
• Czę­ść III. ]]>Ad­mi­ni­stra­tor KSeF. Czy­li gdzie na­praw­dę le­ży wła­dza.]]>
• Czę­ść IV. ]]>Tech­no­lo­gia KSeF – su­we­ren­no­ść koń­czy się tam, gdzie koń­czy się ka­bel!]]>
• Część V. ]]>Część V. KSeF i ciągłość decyzji. Imperva, czyli suwerenność sprzedana na raty!]]>
• Część VI. ]]>KSeF – wyjaśnienie technicznych i praktyczne przykłady]]>
• Część VII. ]]>Jakie metadane widzi Imperva?]]>

Tagi: gps65, KSeF, finanse, gospodarka, podatki, biznes, państwo, wywiad