W ]]>VIII części mojej serii o KSeF]]> opisałem udowodniony audytem fakt, iż bramka WAF widzi jawne dane JSON, które zwraca API systemu. Jednak po co w ogóle te dane są, jeżeli je się da wydobyć z zaszyfrowanego XML-a faktury? Odpowiadam na to pytanie w sposób zrozumiały dla laika.
Wyobraź sobie zwykły list polecony. Koperta jest zaklejona — nikt po drodze nie czyta treści pisma. A jednak na zewnątrz musi być nadawca, adresat, miasto, numer przesyłki. Bez tych kilku jawnych informacji list nie dotrze nigdzie. Kurier widzi te dane nie dlatego, iż państwo chce mu coś ujawnić, ale dlatego, iż inaczej nie da się zbudować systemu doręczania.
Z KSeF jest identycznie, tylko zamiast koperty mamy protokół sieciowy, a zamiast listu fakturę. Sama treść dokumentu może być szyfrowana, podpisywana, pakowana w kolejne warstwy kryptografii. Jednak program księgowy użytkownika i tak musi dostać podstawowe informacje: numer faktury, identyfikatory stron, kwoty, daty, typ dokumentu. Bez tego nie da się wyświetlić listy faktur, policzyć podatku ani zaksięgować operacji. System pozbawiony tych danych byłby bezpieczny, ale bezużyteczny.
Podobnie jest bramką WAF. Nie jest to tajemniczy podsłuch, ale strażnik stojący na drodze między użytkownikiem a serwerem Ministerstwa Finansów. Każde żądanie i każda odpowiedź musi przez nią przejść, tak jak każdy interesant przechodzi przez ochronę przy wejściu do urzędu. Skoro więc dane są konieczne po stronie programu użytkownika, to siłą rzeczy przechodzą przez punkt kontrolny. Strażnik widzi je nie dlatego, iż ktoś postanowił mu je pokazać, ale dlatego, iż stoi w miejscu, przez które przechodzi cała komunikacja.
To nie jest szczególna cecha KSeF. Tak działa współczesny Internet w ogóle. Bankowość elektroniczna, sklepy, administracja publiczna, usługi chmurowe — wszędzie szyfrowanie kończy się na warstwie ochronnej, a wewnątrz systemu dane stają się czytelne, bo muszą zostać przetworzone. Nie da się policzyć podatku na zaszyfrowanych liczbach. Nie da się wyszukać dokumentu, którego numeru system nie widzi.
Dlatego jawny JSON w API 2.0 KSeF nie jest wyjątkiem ani dziurą, ale konsekwencją samego celu systemu. Dane są widoczne dla bramki WAF, bo muszą być widoczne dla aplikacji użytkownika. A skoro między jednym a drugim stoi warstwa ochronna, to widzi je również ona. Cała ta architektura nie jest błędem — ona jest mądra i sensowna, jest zrobiona zgodnie z dobrą praktyką projektowania takich systemów.
Błąd w tym wszystkim jest tylko jeden: pośrednik, strażnik, który tego pilnuje, nie jest systemem należącym do operatora KSeF, ale jest podmiotem zewnętrznym, zagranicznym, wywiadowczym. To tak jakby polskie urzędy zatrudniły strażników pilnujących wejść do rzędów poprzez pośrednika, który zajmuje się wywiadem i ci strażnicy to byliby jego agenci. Cała konstrukcja bramki wejściowej i całej infrastruktury z tym związanej jest poprawna, dobra, mądra. Jedyny mankament jest taki, iż obsługują to agenci obcego wywiadu.
Grzegorz GPS Świderski
]]>t.me/KanalBlogeraGPS]]>
]]>Twitter.com/gps65]]>
PS. Część VIII. Co jeszcze widzi Imperva? Więcej metadanych: ]]>x.com/gps65/status/2023001255132434749]]>
Tagi: GPS65, finanse, gospodarka, podatki, biznes, wywiad
