Bezpieczne udostępnianie plików PDF bez przesyłania ich na zewnętrzne serwisy: Przewodnik krok po kroku dla zespołów prawnych
6.02.2026

Bezpieczne udostępnianie plików PDF bez przesyłania ich na zewnętrzne serwisy: Przewodnik krok po kroku dla zespołów prawnych

Jak zespoły prawne mogą przeglądać pliki PDF we własnym portalu .NET zamiast na zewnętrznej stronie, przy zachowaniu szyfrowania, tokenów i logowania audytu tam, gdzie powinny być: w Twojej aplikacji.

Działy prawne zajmują się umowami, plikami dowodowymi i innymi wysoce poufnymi dokumentami. Typowy przepływ pracy polegający na przesyłaniu PDF‑a do usługi udostępniania w chmurze natychmiast tworzy ryzyko bezpieczeństwa: plik znajduje się poza granicami Twojej korporacji i tracisz szczegółową kontrolę nad tym, kto może go zobaczyć i jak długo.

Co by było, gdybyś mógł osadzić bezpieczną, zaszyfrowaną przeglądarkę PDF bezpośrednio w swoim portalu .NET, gwarantując, że dokument nigdy nie dotknie serwera zewnętrznego?

W tym przewodniku przeprowadzimy Cię przez praktyczną architekturę opartą na Doconut Viewer, SDK przeglądarki dokumentów .NET. Jest ona instalowana w Twojej własnej aplikacji i nie wykonuje żadnych wywołań do serwerów Doconut, więc dokument nigdy nie opuszcza Twojej infrastruktury.

Dwie rzeczy, które należy wyjaśnić przed pierwszym krokiem, ponieważ reszta przewodnika od nich zależy. Doconut.app to darmowa przeglądarka internetowa — strona internetowa, a nie komponent, i nie jest tym, co instalujesz tutaj. A szyfrowanie, tokeny i log audytu poniżej są Twoje do zbudowania: SDK renderuje dokumenty, nie dostarcza programu zgodności. Doconut nie posiada certyfikatu ISO 27001, raportu SOC 2 ani atestacji HIPAA, więc argument zgodności, który możesz przedstawić regulatorowi, jest architektoniczny — plik pozostał w granicach, które już kontrolujesz.


Dlaczego tradycyjne udostępnianie w chmurze nie spełnia oczekiwań

RyzykoTypowa usługa w chmurzeCo robi ta architektura zamiast tego
Eksport danych - plik przechowywany na zewnętrznych serwerachPliki są przechowywane w magazynie dostawcy, często w regionach, których nie możesz kontrolować.PDF pozostaje w Twojej własnej infrastrukturze. SDK renderuje go tam i nie wywołuje nikogo.
Utrata kontroli nad okresem dostępuLinki udostępniające mogą być przekazywane w nieskończoność.Wydajesz krótkotrwałe, jednorazowe tokeny. To jest kod, który piszesz, a nie przełącznik, który przestawiasz.
Luki w zgodnościLogi audytu są często ograniczone do zdarzeń „pobrania”.Logujesz każde żądanie podglądu, ponieważ żądanie trafia do Twojego własnego punktu końcowego.
Zależność od wtyczekWiele przeglądarek wymaga Flash, ActiveX lub rozszerzeń przeglądarki.Nic nie jest instalowane na komputerze czytelnika; przeglądarka otrzymuje renderowane strony.

Przegląd rozwiązania

  1. Zainstaluj Doconut Viewer w swoim projekcie .NET.
  2. Szyfruj pliki PDF w spoczynku przy użyciu klucza po stronie serwera, korzystając z własnej kryptografii .NET.
  3. Osadź przeglądarkę na stronie Razor lub w widoku MVC, za tokenem wydanym przez Twoją aplikację.
  4. Loguj każde żądanie podglądu w celu tworzenia ścieżek audytu i wykrywania anomalii.

Kroki 2, 3 i 4 to praca Twojej aplikacji. Częścią SDK jest krok 1 i renderowanie; wszystko, co chroni w tym projekcie, to kod, który posiadasz, co jest także powodem, dla którego może być audytowany przez Twój własny zespół.

Poniżej znajduje się szczegółowy przewodnik po każdym kroku, zawierający zalecenia najlepszych praktyk dotyczące zarządzania kluczami, bezpieczeństwa tokenów i logowania zgodności.


Krok 1 – Przygotowanie środowiska .NET

  1. Otwórz rozwiązanie w Visual Studio (zalecane 2022 lub nowsze).
  2. Wybierz docelowy framework. Doconut Viewer obsługuje ASP.NET, MVC, .NET Core, .NET 6+ i Blazor. Zanotuj wersję, którą wybierzesz — szczegóły integracji są zależne od wersji.
  3. Zainstaluj SDK ze strony pobierania Doconut, używając pakietu i dokumentacji pasującej do wybranej wersji. Pobierz nazwę pakietu i kroki instalacji z tej dokumentacji, a nie z artykułu; oba uległy zmianie w kolejnych wydaniach.

Trzymaj konfigurację licencji poza kontrolą wersji, dopóki pracujesz nad tym. To najczęstszy element, który wycieka z działającego prototypu.

Dodatkowe wskazówki

  • Przechowuj odwołanie do pakietu w pliku Directory.Packages.props w celu scentralizowanego zarządzania wersjami w wielu usługach.

Krok 2 – Przechowywanie plików PDF z silnym szyfrowaniem

2.1 Wybór algorytmu szyfrowania

To jest twoja decyzja i twój kod. System.Security.Cryptography w .NET udostępnia AES-256-GCM, który zapewnia szyfrowanie uwierzytelnione — poufność i integralność jednocześnie — i jest uzasadnionym domyślnym rozwiązaniem dla dokumentów w spoczynku.

Żaden algorytm szyfrowania nie sprawia, że system jest zgodny z GDPR, HIPAA czy ISO 27001. Te ramy regulacyjne dotyczą procesów, kontroli dostępu, przechowywania i dowodów. Szyfrowanie jest jedną z wielu kontroli, a biblioteka przeglądarki nie może zapewnić pozostałych.

2.2 Implementacja bezpiecznego zarządzania kluczami

  • Nigdy nie zakodowuj kluczy na stałe. Użyj Azure Key Vault, AWS KMS lub HashiCorp Vault, aby pobrać klucz szyfrowania w czasie wykonywania.
  • Regularnie rotuj klucze — co 90 dni to powszechna praktyka. Zaplanuj zadanie ponownego szyfrowania zanim będzie potrzebne; odkrycie, że nie masz możliwości zmiany klucza, jest nieprzyjemnym doświadczeniem w trakcie incydentu.

Krok 3 – Generowanie tokenu o ograniczonym czasie, jednorazowego

Token podglądu działa jak jednorazowy identyfikator, który wygasa automatycznie. Zawiera:

  • User ID – Kto ma prawo wyświetlić dokument.
  • PDF ID – Który zaszyfrowany plik strumieniować.
  • Expiration – Zazwyczaj 5–10 minut, konfigurowalne według polityki.
  • Signature – Podpis HMAC lub RSA, aby zapobiec manipulacji.

3.1 Rozważania dotyczące bezpieczeństwa

  • TLS wszędzie – Zawsze dostarczaj token przez HTTPS.
  • Zasada najmniejszych przywilejów – Koduj tylko dane niezbędne do podglądu; unikaj osadzania dodatkowych roszczeń.
  • Unieważnianie tokenu – Prosta „czarna lista” w Redis umożliwia natychmiastowe unieważnienie, jeśli zmienią się prawa dostępu użytkownika.

Krok 4 – Osadzenie przeglądarki DoconutApp

4.1 Punkt końcowy strumieniowania po stronie serwera

  • Deszyfruj w pamięci, jeśli Twój model zagrożeń tego wymaga, aby tekst jawny nigdy nie trafiał na dysk. To jest Twój punkt końcowy, więc to Twój wybór i Twój kod do przeglądu.
  • Renderowanie odbywa się na Twoim serwerze, a nie w przeglądarce czytelnika. To pozwala przeglądarce wyświetlić dokument bez otrzymywania pliku źródłowego — i jest także powodem, aby sprawdzić, gdzie SDK zapisuje tymczasowy wynik renderowania i co go usuwa.

4.2 Nie wymaga wtyczek

Czytelnik otrzymuje renderowane strony za pomocą standardowych technologii webowych, więc przeglądarka działa w Chrome, Edge, Firefox i Safari bez żadnych wtyczek, kontrolki ActiveX ani zależności od Flash. Nic nie jest instalowane na laptopie prawnika, co zazwyczaj stanowi różnicę między przeglądem bezpieczeństwa, który zostaje zakończony, a tym, który nie zostaje.


Krok 5 – Audyt i logowanie dostępu dla zgodności

Zespoły prawne często potrzebują śladu odpornego na manipulacje wskazującego, kto oglądał który kontrakt i kiedy. Zaimplementuj strukturalny potok logowania:

PoleOpis
UserIdIdentyfikator żądającego profesjonalisty prawnego
PdfIdWewnętrzne odniesienie do zaszyfrowanego dokumentu
TimestampCzas UTC żądania podglądu
IpAddressAdres IP źródła (przydatny przy sprawdzaniu geolokalizacji)
UserAgentCiąg znaków przeglądarki do analizy forensic
ResultSukces / Niepowodzenie (np. nieprawidłowy token, błąd deszyfrowania)

Najlepsze praktyki

  • Przechowuj logi w magazynie danych tylko do dopisywania, niezmiennym (np. Azure Log Analytics, Splunk lub jednorazowo zapisywanym bucketcie S3).
  • Włącz alerty dla nieprawidłowych wzorców — np. ten sam token użyty z dwóch różnych IP w ciągu kilku sekund.
  • Polityka retencji: Przechowuj logi przez okres wymagany przez Twoją jurysdykcję (zwykle 7 lat dla dokumentacji prawnej).

Szybkie podsumowanie

  1. Zainstaluj Doconut Viewer w swoim projekcie .NET, korzystając z dokumentacji dla swojej wersji.
  2. Szyfruj pliki PDF przy zapisie przy użyciu AES-256-GCM z własnej biblioteki kryptograficznej .NET; zarządzaj kluczami za pośrednictwem usługi vault.
  3. Wydaj krótkotrwały, jednorazowy token podglądu gdy użytkownik żąda podglądu.
  4. Renderuj na swoim serwerze i osadź przeglądarkę na stronie Razor. Dokument nigdy nie trafia do podmiotu trzeciego, i nic nie jest instalowane na maszynie czytelnika.
  5. Loguj każdy podgląd w celu audytowalności, z alertami dla podejrzanych wzorców.

Punkty 2, 3 i 5 to Twój kod. To uczciwy podział obowiązków i warto to jasno zaznaczyć w własnej dokumentacji bezpieczeństwa, ponieważ recenzent ostatecznie zapyta, która strona jest odpowiedzialna za co.

Podsumowanie

Bezpieczne udostępnianie plików PDF nie musi wymagać usługi zewnętrznej. Dzięki Doconut Viewer w Twoim własnym portalu .NET, dział prawny może prezentować poufne umowy, materiały dowodowe w postępowaniach sądowych i wewnętrzne polityki, nie pozwalając, aby plik opuścił Twoją infrastrukturę.

To, co daje Ci SDK, to ta ostatnia część: renderowanie w Twoim środowisku, bez połączenia z zewnętrznymi serwerami. Szyfrowanie end‑to‑end, kontrola dostępu i ścieżka audytu należą do Ciebie — o to właśnie chodzi, ponieważ przeglądarka, która twierdziłaby, że je zapewnia, zmuszałaby Cię do zaufania zgodności dostawcy zamiast własnej.

Gotowy, aby wypróbować? Odwiedź doconut.com — licencja próbna jest darmowa, a demo na żywo to najszybszy sposób, aby sprawdzić, czy renderowanie wytrzyma najtrudniejszy materiał dowodowy, zanim napiszesz jakikolwiek kod powyżej.

Wdrożenie tych kroków zapewni pracownikom ds. zgodności spokój, zmniejszy powierzchnię ataku i utrzyma Twoje pliki PDF bezpiecznie wewnątrz firmowej zapory — dokładnie taką postawę bezpieczeństwa potrzebuje każdy zespół prawny.

Pozostań bezpieczny, zachowaj zgodność i trzymaj te zapieczętowane koperty tam, gdzie powinny być: w własnym sejfie.