[jarek04]

W KSeF 2.0 użytkownik (osoba fizyczna) może uwierzytelnić się certyfikatem lub podpisem i wybrać „kontekst logowania” (np. NIP podmiotu). Z dokumentacji wynika też, że jeden certyfikat KSeF można wykorzystać do pracy w różnych kontekstach (różnych podmiotach).
(Krajowy System e-Faktur -> https://ksef.podatki.gov.pl/media/jxgjepcn/instrukcja-uwierzytelnienia-w-aplikacji-podatnika-ksef-20-wersja-testowa.pdf)

Mam praktyczny problem bezpieczeństwa o bardzo wysokiej wadze ryzyka, w tym wprost ryzyka dla ochrony danych oraz potencjalnie dla interesu publicznego.

1. Pracownik (np. księgowy) ma nadane uprawnienia w firmie A (np. gmina, elektrownia, podmiot krytyczny, dowolna firma) – może przeglądać i wystawiać faktury.

2. Ten sam pracownik legalnie pracuje dodatkowo na umowie zlecenie popołudniami w firmie X i tam również ma uprawnienia w KSeF.

3. W firmie X, dla celów automatyzacji, certyfikat lub klucz prywatny pracownika bywa zapisany na stałe w programie (żeby nie wgrywać go za każdym razem). Taką formę stosują m.in. programy: #symfonia, #infakt, #wfirma, #comarch, #ifirma.

W takim układzie firma X technicznie może użyć certyfikatu pracownika i zalogować się „jako on” do KSeF, a następnie wybrać kontekst NIP firmy A (np. gmina, elektrownia, podmiot krytyczny, dowolna firma) i uzyskać dostęp do jej dokumentów, ponieważ pracownik ma tam uprawnienia.

Kluczowy problem polega na tym, że jest to scenariusz realny i trudny do wykrycia po stronie podmiotu A. Logowanie następuje prawidłowym, ważnym certyfikatem osoby fizycznej, a następnie wybierany jest inny kontekst (NIP). W efekcie powstaje wysokie ryzyko nieautoryzowanego dostępu do danych (naruszenie poufności), a także ryzyko nadużyć na dokumentach (ryzyko integralności i rozliczalności), bez potrzeby łamania zabezpieczeń systemu, wyłącznie przez wykorzystanie istniejącego mechanizmu „kontekstu” oraz przechowywania klucza prywatnego poza kontrolą podmiotu A.

W wersji demo (screen) widać przykładowego pracownika raz zalogowanego na NIP 6xxxxxxxx8, a poniżej na NIP 6xxxxxxxx9. Na liście certyfikatów widać, że pracownik dla obu firm ma ten sam numer seryjny certyfikatu:
013xxxxxxxxxxx28

Tym samym firma X uzyskuje możliwość użycia certyfikatu pracownika i zalogowania się do KSeF „w kontekście” firmy A (np. gmina, elektrownia, podmiot krytyczny, dowolna firma). Oznacza to, że podmiot trzeci (firma X) może uzyskać dostęp do danych i operacji podmiotu A wyłącznie dlatego, że ta sama osoba ma uprawnienia w obu miejscach, a jej certyfikat lub klucz prywatny został utrwalony w systemie informatycznym firmy X.

Certyfikaty nie posiadają możliwości ograniczenia uprawnień (np. do konkretnego podmiotu lub kontekstu). Jednocześnie nie istnieją przepisy zakazujące pracownikowi pracy w dodatkowej firmie. Zabronienie używania certyfikatu pracownikowi w innych firmach byłoby pogwałceniem jego prawa do pracy w kilku miejscach i byłoby sprzeczne z konstytucją. To powoduje praktyczny brak sensu obecnych certyfikatów imiennych.

Jednocześnie może to stanowić ogromne zagrożenie dla bezpieczeństwa danych firm, ale również państwa, zwłaszcza że w KSeF będą obsługiwane także podmioty krytyczne. W mojej ocenie jest to ryzyko systemowe: pojedynczy pracownik z legalnymi uprawnieniami w dwóch organizacjach oraz przechowywanie jego klucza prywatnego w jednym środowisku może otworzyć drogę do masowego, niejawnego dostępu do danych innego podmiotu, w tym podmiotu wrażliwego.

Czy taki scenariusz jest dopuszczany projektowo (jeden certyfikat osoby fizycznej używany w wielu kontekstach, bez ograniczeń do podmiotu) nikt nie pomyślał o ryzyku?

#ksef #skarbowka #ksiegowosc #polska #bezpieczenstwo

[Ingvarr100th]

@jarek04
Dlatego zamiast zapisywania certyfikatu powinno być logowanie się do KSeF kluczami U2F lub użycie certyfikatu zapisanym na eDowodzie poprzez PKCS#11 i wtedy aplikacja nie ma możliwości zapisania sobie na stałe takiego certyfikatu. Ale no to jest public tutaj wszystko jest merytorycznie słabe i byle jakie, a następnie w taki sposób byle jak implementowane - a takie rozwiązanie jakie ja tu piszę wymaga przeimplementowania po stronie KSeF jak i usług bijącego

[jarek04]

@Ingvarr100th: Programy jak symfonia/infakt/wfirma wręcz wymagają nawet wgrania tego klucza jego hasła i certyfikatu do ich chmury. W sumie wystarczyło by aby zabronić przesyłania klucza i jego hasła i wymagać użycia go lokalnie poza chmurą. Jednak to by uniemożliwiło automatyzację. U2F dużo by nie zmienił nie zmienił też nie możesz go użyć automatycznie, a aktualny system certyfikat klucz hasło jest zbliżony. Jednak powinien on mieć swoje uprawnienia albo być wydawany

[siedze-na-antresoli]

@jarek04 Taktyk. Odpowiem pewnie wieczorem jak odkopie i się wyśpię. Na szybko tylko napiszę, że to co opisałeś w pkt. 3 jest ogólnie złą praktyką i powinno być tępione.

[siedze-na-antresoli]

@jarek04

to by uniemożliwiło automatyzację

To nie jest prawda, chociaż poprawna implementacja podpisywania dokumentów przetwarzanych w chmurze nie jest trywialna.

Jeśli już, klucze prywatne są gdziekolwiek wgrywane, to system powinien mieć odpowiednie metody zarządzania dostępu do nich.

[jarek04]

@siedze-na-antresoli: Jednak wszyscy poszli tą drogą i chcą klucza, cer i hasła. Z wfirma screen w tle, poszczęści rozumiem po co chcą hasło bo bez tego nie dało by się wysyłać i pobierać danych w kolejkach.

[4mja]

Dlatego zamiast zapisywania certyfikatu powinno być logowanie się do KSeF kluczami U2F lub użycie certyfikatu zapisanym na eDowodzie poprzez PKCS#11

@Ingvarr100th: Zakładasz, że faktury wystawiają i pobierają ludzie, którzy mają eDowód czy klucz U2F.
Tymczasem w realnym świecie w dużych firmach faktury wystawiane są automatycznie, pobierane automatycznie, i trzeba gdzieś zapisać klucze/certyfikaty/tokeny żeby to mogło działać.

[XdekHckr]

@4mja: dlatego ten cały ksef o kant d--y możecie sobie...