Podpisany elektronicznie PDF nie powinien być „ulepszany” przez system DMS w miejscu. To najprostsza zasada, a jednocześnie jedna z najczęściej łamanych. Dokument wpływa do systemu, silnik OCR rozpoznaje tekst, moduł archiwizacyjny chce przygotować PDF/A, wyszukiwarka potrzebuje pełnotekstowego indeksu, interfejs generuje miniatury. Technicznie wszystko działa. Problem zaczyna się wtedy, gdy któraś z tych operacji nadpisuje plik, który faktycznie podpisała druga strona.
DMS powinien więc rozdzielać dwie role. Podpisany plik źródłowy jest dowodem i obiektem podlegającym walidacji podpisu. OCR służy do pracy z dokumentem. To nie są zamienne wersje tego samego pliku.
Najbezpieczniejszy model jest prosty: po odebraniu dokumentu system zapisuje źródłowy ciąg bajtów bez zmian, nadaje mu trwały identyfikator i wylicza skrót kryptograficzny. Dopiero od tego obiektu tworzy kolejne pochodne: tekst OCR, PDF/A, miniaturę, plik podglądowy czy dane do indeksu wyszukiwarki. Każda pochodna musi wskazywać, z którego oryginału powstała.
Oryginał trzeba zachować bit po bicie, a nie tylko „w tej samej treści”
Dwa pliki PDF mogą wyglądać na ekranie identycznie, a mimo to być różnymi plikami. Konwersja, optymalizacja, ponowny zapis czy OCR mogą zmienić strukturę obiektów PDF, metadane, kompresję obrazów, kolejność elementów albo zapis fontów. Użytkownik nadal widzi tę samą fakturę czy umowę, ale podpis elektroniczny nie operuje na wyglądzie strony. Operuje na danych zapisanych w pliku.
Dlatego po wpływie podpisanego PDF-u system powinien wykonać operacje w następującej kolejności:
- zapisać odebrany plik bez modyfikacji;
- nadać mu wewnętrzny, niezmienny identyfikator;
- zapisać rozmiar pliku, typ MIME, datę i kanał wpływu;
- obliczyć skrót, np. SHA-256;
- uruchomić walidację podpisów na pliku źródłowym;
- dopiero później tworzyć OCR, PDF/A, miniatury i indeks wyszukiwarki.
SHA-256 daje skrót długości 256 bitów, czyli 32 bajtów, najczęściej prezentowany jako 64 znaki szesnastkowe. Taki hash jest bardzo przydatny do kontroli, czy przechowywany obiekt zmienił się od chwili przyjęcia. Nie zastępuje jednak podpisu elektronicznego. Sam skrót nie potwierdza tożsamości osoby podpisującej, ważności jej certyfikatu ani tego, jaki był status certyfikatu w odpowiednim momencie.
Praktyczny przykład: do spółki wpływa podpisana kwalifikowanym podpisem umowa o wartości 480 tys. zł. DMS automatycznie przepuszcza wszystkie PDF-y przez moduł OCR, który zapisuje dokument ponownie jako „searchable PDF”. Wizualnie strony są takie same. Jeżeli jednak system zachował wyłącznie plik wynikowy, a oryginał usunął, podczas sporu nie można po prostu założyć, że jest to ten sam elektroniczny dokument, który kontrahent podpisał.
Poprawna architektura wygląda inaczej:
DOC-2026-001847
- oryginał:
source.pdf; - SHA-256 oryginału;
- wynik walidacji podpisu;
- pochodna OCR;
- pochodna PDF/A;
- miniatura;
- tekst indeksowany;
- relacje wszystkich pochodnych do identyfikatora oryginału.
Największy priorytet ma niezmienność oryginału. Mechanizm przechowywania typu WORM, immutable object storage albo blokada modyfikacji na poziomie repozytorium może być przydatny, ale nie jest jedynym sposobem osiągnięcia celu. W mniejszym DMS wystarczy poprawnie zaprojektowana warstwa obiektów, brak operacji „save over source”, kontrola wersji, audyt i ograniczenie uprawnień.
Nie ma natomiast sensu wymuszać kosztownego, specjalizowanego storage’u tylko dlatego, że dokument ma podpis, jeśli system potrafi technicznie zagwarantować, że oryginalny blob jest nieedytowalny, wersjonowany i objęty audytem. Wybór zależy od wymagań dowodowych, regulacyjnych, retencji, liczby administratorów oraz ryzyka celowej lub przypadkowej modyfikacji.
Szczególnie niebezpieczna jest funkcja DMS opisana niewinnie jako „normalizacja PDF”. Jeśli uruchamia się przed zapisaniem źródła, należy ją wyłączyć albo przenieść za etap archiwizacji oryginału.
Integralność pliku, ważność certyfikatu i wynik walidacji podpisu to trzy różne informacje
Najczęstszy błąd w interfejsach DMS wygląda tak: przy dokumencie pojawia się zielona ikona „podpis poprawny”, ponieważ hash pliku zgadza się z wartością zapisaną wcześniej. To za mało.
Integralność obiektu w repozytorium oznacza jedynie, że przechowywany plik nie zmienił się względem znanej wersji. Walidacja podpisu elektronicznego wymaga szerszej oceny: danych podpisanych, certyfikatu, łańcucha zaufania, statusu certyfikatu, czasu oraz reguł wynikających z rodzaju podpisu i zastosowanej polityki walidacji.
W środowisku eIDAS przy walidacji znaczenie ma między innymi to, czy certyfikat był odpowiedniego rodzaju i pozostawał ważny w momencie podpisywania, czy dane walidacyjne odpowiadają danym otrzymanym przez stronę ufającą oraz czy integralność podpisanych danych została zachowana. W praktyce dochodzi do tego sprawdzanie łańcucha certyfikatów, informacji o unieważnieniu, np. z OCSP lub CRL, oraz znacznika czasu, jeżeli podpis go zawiera.
To prowadzi do ważnej zasady projektowej: DMS nie powinien przechowywać jednego pola:
signature_valid = true
Lepiej zapisać przynajmniej:
- identyfikator podpisu;
- osobę lub podmiot wynikający z certyfikatu;
- wystawcę i numer seryjny certyfikatu;
- deklarowany czas podpisania;
- informację o zaufanym znaczniku czasu;
- wynik kontroli integralności;
- wynik walidacji certyfikatu;
- status końcowy walidacji;
- datę i czas wykonania walidacji;
- nazwę i wersję komponentu walidującego;
- zastosowaną politykę walidacji;
- komunikaty ostrzegawcze;
- raport techniczny pozwalający później wyjaśnić wynik.
Przydatne statusy operacyjne to na przykład VALID, INVALID, INDETERMINATE i NOT_VALIDATED. Nazewnictwo może być inne, ale najważniejsze jest to, aby „nie udało się potwierdzić” nie zostało zapisane jako „podpis nieważny”. Brak aktualnych danych o unieważnieniu, problem z łańcuchem certyfikatów albo niedostępność usługi walidacyjnej mogą prowadzić do wyniku wymagającego dalszej analizy, a nie automatycznie do stwierdzenia fałszerstwa.
Trzeba też uważać z popularnym uproszczeniem: „każda zmiana jednego bajtu unieważnia wszystkie podpisy PDF”. PDF obsługuje podpisy kolejnych osób i aktualizacje przyrostowe. Oryginalnie podpisany zakres danych może pozostać zachowany, mimo że do dokumentu później dodano kolejne elementy. Podpis certyfikujący może również określać, jakie późniejsze operacje są dopuszczalne.
Przykład z praktyki: dział zakupów otrzymuje umowę podpisaną przez dostawcę. Następnie pełnomocnik spółki dodaje drugi podpis. Końcowy PDF nie jest bitowo identyczny z wersją po pierwszym podpisie, ale nie oznacza to automatycznie, że pierwszy podpis stał się nieważny. Walidator powinien odtworzyć historię zmian i sprawdzić, jakie dane obejmował dany podpis oraz czy późniejsze modyfikacje były dopuszczalne.
Z tego samego powodu nie wolno zastępować profesjonalnej walidacji zwykłym porównaniem hashy. Hash jest świetnym mechanizmem kontroli repozytorium. Nie jest silnikiem walidacji podpisów.
Wybór rozwiązania zależy od charakteru dokumentów. Jeżeli DMS przechowuje głównie zwykłą dokumentację wewnętrzną, wystarczający może być walidator uruchamiany przy wpływie i na żądanie. Przy umowach wysokiej wartości, dokumentacji regulowanej lub długiej retencji trzeba uwzględnić możliwość późniejszej walidacji, dane o statusie certyfikatów i znaczniki czasu. Problem polega na tym, że certyfikat, który dziś działa, za kilka lat może być wygasły, a odpowiednie usługi sieciowe mogą wyglądać inaczej. Projektowanie DMS wyłącznie pod „zielony znacznik w dniu wpływu” jest zbyt krótkowzroczne.
OCR ma być warstwą roboczą. Jego błędy nie mogą zmieniać dokumentu dowodowego
OCR jest potrzebny, bo bez niego skan umowy czy faktury pozostaje dla wyszukiwarki głównie zbiorem obrazów. Problem pojawia się wtedy, gdy system zaczyna traktować rozpoznany tekst jak prawdziwą treść źródłowego dokumentu.
OCR nie jest bezbłędny. Najwięcej problemów sprawiają słabe skany, małe fonty, pieczęcie nachodzące na tekst, tabele, formularze wielokolumnowe, odręczne dopiski oraz podobne znaki. W polskich dokumentach łatwo pomylić między innymi:
0iO;1,Iorazl;- przecinek dziesiętny i kropkę;
- cyfry w numerach NIP, PESEL, REGON czy IBAN;
- kwoty znajdujące się w ciasnych tabelach;
- daty zapisane drobnym drukiem;
- polskie znaki w słabej jakości skanach.
To nie jest drobiazg. Jeśli system odczyta numer rachunku bankowego, termin płatności albo kwotę brutto i przekaże tę wartość dalej do workflow, błąd OCR może przestać być błędem wyszukiwarki, a zacząć być błędem biznesowym.
Przykład: faktura zawiera kwotę 18 450,00 zł. OCR powinien pozwolić księgowej znaleźć dokument po tej kwocie i może zaproponować wartość do formularza dekretacyjnego. Nie powinien jednak bez kontroli zamieniać wartości rozpoznanej automatycznie w daną wiążącą dla płatności, jeśli proces nie przewiduje dodatkowej walidacji.
Dobry model DMS rozdziela więc:
1. Oryginał
Niezmieniony plik odebrany od nadawcy.
2. Pochodne dokumentowe
Na przykład PDF/A do celów archiwalnych lub podglądowy PDF zoptymalizowany do szybkiego wyświetlania.
3. Pochodne techniczne
Miniatury stron, obrazy podglądowe, tekst OCR.
4. Dane indeksowe
Słowa i pola wykorzystywane przez wyszukiwarkę.
5. Dane biznesowe
Kwota, NIP kontrahenta, numer umowy, data płatności czy numer rachunku, jeżeli są używane przez workflow.
Każda z tych warstw powinna posiadać własny identyfikator i wskazywać parent_original_id. Wtedy można bez problemu przeliczyć OCR nowym silnikiem, wygenerować nową miniaturę albo poprawić indeks, nie dotykając podpisanego źródła.
Przykładowo po migracji z jednego silnika OCR na drugi system nie powinien tworzyć „nowej wersji umowy”. Powinien utworzyć nową wersję pochodnej OCR, np.:
OCR-001847-v1 – silnik A
OCR-001847-v2 – silnik B
Obie wersje nadal odnoszą się do tego samego ORIGINAL-001847.
To ważne również przy PDF/A. Konwersja do PDF/A może wymagać przebudowy pliku, np. w zakresie metadanych, fontów, profili barwnych albo innych elementów zgodności. Dlatego PDF/A utworzony z podpisanego PDF-u powinien być traktowany jako pochodna, a nie nowy oryginał. Próba stworzenia „lepszego archiwalnego oryginału” przez konwersję pliku po podpisaniu jest błędem koncepcyjnym.
Podobnie należy traktować dodawanie informacji służących długoterminowej walidacji. Niektóre narzędzia potrafią po podpisaniu dołączyć do PDF dodatkowe dane walidacyjne, np. informacje o unieważnieniu certyfikatów. Taki zapis może być prawidłowym elementem obsługi podpisanego PDF-u, ale w systemie DMS nadal warto zachować dokładny plik w postaci, w której wpłynął, oraz osobno kolejną wersję techniczną dokumentu. Dzięki temu zawsze wiadomo, co faktycznie odebrano, a co system dopisał później.
Osobnym problemem jest kontrola dostępu do OCR. Administratorzy często dobrze zabezpieczają oryginalny PDF, a zapominają o pełnotekstowym indeksie. Tymczasem tekst OCR może zawierać dokładnie te same dane osobowe, finansowe i handlowe co dokument. Co więcej, wyszukiwarka potrafi ujawnić fragment danych użytkownikowi, który nie ma prawa otworzyć samego pliku.
Uprawnienia powinny więc obejmować nie tylko source.pdf, lecz także:
- tekst OCR;
- indeks pełnotekstowy;
- miniatury;
- wyodrębnione metadane;
- wyniki klasyfikacji;
- pliki eksportowe i cache podglądu.
Jeżeli pracownik nie ma dostępu do umowy, nie powinien dostać jej treści w wynikach wyszukiwania tylko dlatego, że silnik indeksujący działa w innym modelu uprawnień.
W praktyce pierwsza rzecz do sprawdzenia w istniejącym DMS-ie jest bardzo konkretna: co dokładnie dzieje się z bajtami podpisanego PDF-u w pierwszych sekundach po jego wpływie. Należy przesłać kontrolny, podpisany dokument, pobrać z systemu obiekt oznaczony jako „oryginał” i porównać SHA-256 z plikiem wysłanym.
Jeżeli skróty są różne, najpierw trzeba znaleźć proces, który modyfikuje plik — OCR, konwersję PDF/A, optymalizację, antywirus zapisujący plik ponownie, moduł podglądu lub inną „normalizację”. Dopiero po usunięciu tego błędu ma sens dopracowywanie kolejnych etapów obiegu.
FAQ
Czy podpisany PDF można wysłać do OCR?
Tak. OCR powinien jednak pracować na kopii roboczej albo strumieniu odczytanym z oryginału, a jego wynik powinien zostać zapisany jako osobna pochodna. Źródłowy PDF pozostaje bez zmian.
Czy po OCR można zapisać wynik z powrotem jako ten sam PDF?
Nie powinno się tego robić dla dokumentu traktowanego w DMS jako podpisany oryginał. Nawet jeżeli wynik wygląda identycznie, operacja może zmienić strukturę pliku. Zapisz wynik jako osobny obiekt powiązany z oryginałem.
Czy PDF/A powinien zastępować podpisany PDF?
Nie. Jeśli organizacja potrzebuje wersji PDF/A, powinna ona powstać jako pochodna. Oryginałem pozostaje plik odebrany od nadawcy.
Czy zgodność SHA-256 oznacza, że podpis jest ważny?
Nie. Zgodność skrótu potwierdza, że porównywane dane są identyczne. Nie sprawdza certyfikatu podpisującego, statusu jego unieważnienia, łańcucha zaufania, znacznika czasu ani reguł walidacji podpisu.
Czy zmiana jednego bajtu zawsze unieważnia każdy podpis w PDF?
Nie można przyjąć takiej reguły. PDF pozwala na podpisy wielokrotne i zapisy przyrostowe. Walidacja musi sprawdzić zakres objęty konkretnym podpisem, historię zmian i uprawnienia dotyczące późniejszych modyfikacji.
Co zapisywać razem z wynikiem walidacji?
Co najmniej wynik, moment walidacji, dane certyfikatu i podpisującego, informacje o integralności, znaczniku czasu i statusie certyfikatu oraz wersję komponentu i politykę używaną do walidacji. Sam napis „podpis poprawny” jest zbyt ubogi do późniejszego audytu.
Czy tekst OCR może mieć inne uprawnienia niż PDF?
Technicznie może, ale zazwyczaj nie powinien. Jeśli użytkownik nie może czytać oryginału, wynik OCR i fragmenty indeksu również nie powinny ujawniać jego treści.
Od czego zacząć poprawę istniejącego DMS-u?
Od testu identyczności pliku. Oblicz SHA-256 przed importem i po pobraniu „oryginału” z DMS. Jeżeli wartości się nie zgadzają, usuń automatyczne modyfikowanie źródła przed zajmowaniem się jakością OCR, PDF/A czy wyszukiwarką.
