Przejdź do głównej zawartości

Centrum zaufania

To centrum zaufania rdzenia NextPDF. Zacznij od czterech dokumentów: model zagrożeń silnika, model bezpieczeństwa podpisu i szyfrowania, zachowanie przy przetwarzaniu danych i danych umożliwiających identyfikację osoby (PII) oraz polityka ujawniania podatności. Każda strona opisuje konkretny wycinek zachowania biblioteki oraz granicę między odpowiedzialnością biblioteki a odpowiedzialnością wdrożenia.

Granica. Ta strona oraz strony, do których prowadzi, opisują postawę inżynierską decyzje projektowe, ustawienia domyślne i środki zaradcze wbudowane w rdzeń oraz zweryfikowane przez jego zestaw testów. Nie stanowią certyfikacji, raportu z audytu ani gwarancji prawnej. Żadne zawarte tu stwierdzenie nie zapewnia, że biblioteka jest „bezpieczna” we wdrożeniu. Bezpieczeństwo jest właściwością całego systemu: sposobu przechowywania kluczy, polityki weryfikatora, sieci i praktyk operacyjnych, a nie jednej zależności.

Opisane tutaj podejście do zaufania dotyczy rdzenia:

Okno terminala
composer require nextpdf/core:^3

Aby przeczytać te strony, nie trzeba instalować żadnego dodatkowego pakietu. Zestaw testów rdzenia dostarczany w tym samym pakiecie weryfikuje opisane zachowania.

Centrum zaufania opiera się na prostej zasadzie: strona dokumentacji musi określać, co silnik robi i czego nie obiecuje. Cztery podstrony dzielą ten zakres:

  • Model zagrożeń — klasy ataków, które silnik uwzględnia (fałszowanie żądań po stronie serwera (SSRF), przetwarzanie zewnętrznych encji XML (XXE), bomby dekompresyjne, przechodzenie po ścieżkach oraz wstrzykiwanie treści), postawę domyślnego odrzucania oraz zabezpieczenia w kodzie, które łagodzą każdą klasę. Dokumentuje rozważane zagrożenia. Nie twierdzi, że podatności nie występują.
  • Model bezpieczeństwa — powierzchnia kryptograficzna: 256-bitowe szyfrowanie dokumentów standardem Advanced Encryption Standard (AES-256), zależny od współpracy czytnika charakter bitów uprawnień formatu Portable Document Format (PDF) oraz ścieżka podpisywania Cryptographic Message Syntax (CMS)/PDF Advanced Electronic Signatures (PAdES) B-B i B-T. Wyjaśnia, dlaczego obsługa mechanizmu nie jest tym samym co bezpieczeństwo wdrożenia.
  • Przetwarzanie danych — jakie dane biblioteka odczytuje, przechowuje w pamięci i zapisuje; transformacja usuwania danych PII stosowana do pakietów audytowych; oraz opcjonalna, niewprowadzająca narzutu ścieżka telemetrii. Opisuje zachowanie biblioteki, a nie rezydencję danych na poziomie wdrożenia.
  • Ujawnianie — skoordynowany proces ujawniania podatności: prywatne kanały zgłaszania, docelowe terminy reakcji oraz model embarga. To zobowiązanie procesowe, a nie gwarancja rezultatu.

Każda strona przedstawia normatywne stwierdzenia w tabeli stwierdzenie → identyfikator klauzuli + reference_id, pochodzącej z bloku citations: w jej frontmatterze. Dzięki temu można prześledzić podstawę normatywną każdego stwierdzenia.

Nie dotyczy. Centrum zaufania to dokumentacja. Interfejsy programowania aplikacji (API), które odpowiadają za opisane zachowanie, omówiono na stronach referencyjnych modułów (/modules/core/security/, /modules/core/audit/) i nie są tutaj ponownie wymieniane. Ta strona prowadzi do aspektów zaufania, a nie do symboli.

Nie dotyczy. To strona indeksu. Nie udostępnia żadnego uruchamialnego zachowania. Podstrony opisujące zachowanie w czasie działania zawierają przykłady kodu tam, gdzie rdzeń może zademonstrować dane zachowanie.

Nie dotyczy. Zobacz podstrony.

  • Strona zaufania nie jest umową. Przeczytanie tych stron nie tworzy gwarancji. Obowiązuje licencja (Apache-2.0), a zawarte w niej zastrzeżenie braku gwarancji obowiązuje w pełnym zakresie.
  • Postawa jest wersjonowana. Opisane tutaj ustawienia domyślne i zabezpieczenia pochodzą z bieżącej stabilnej wersji głównej. Starsza wersja główna może mieć słabsze ustawienie domyślne. Polityka bezpieczeństwa odnotowuje, które wersje główne otrzymują poprawki.
  • „Obsługa” to powracająca pułapka. W całym centrum zaufania obsługa profilu lub mechanizmu nigdy nie jest tym samym co zgodność z tym profilem ani co bezpieczeństwo wdrożenia. Każda strona przedstawia tę granicę ponownie, własnymi słowami.

Nie dotyczy. Dokumentacja nie wiąże się z żadnym kosztem w czasie działania. Odpowiednie strony modułów dokumentują charakterystyki wydajnościowe bazowych operacji bezpieczeństwa.

Centrum zaufania ujawnia granice bezpieczeństwa, zamiast pozostawiać je w sferze domysłów. Do każdej strony mają zastosowanie dwie przekrojowe granice:

  1. Ustawienia domyślne są fail-closed, a nie niezawodne. Każdy obiekt polityki w silniku jest dostarczany z najbardziej restrykcyjnym ustawieniem, na jakie pozwala publiczne API. Jego rozluźnienie wymaga jawnej zgody wywołującego. Ustawienie domyślne typu fail-closed zmniejsza ryzyko przypadkowego ujawnienia. Nie zwalnia to z odpowiedzialności za przejrzenie wybranej konfiguracji. Odzwierciedla to zasadę konfiguracji bazowej z dokumentu National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53 Rev. 5 CM-7 (nist_sp_800_53r5#x4.x182.p14): zminimalizowana konfiguracja bazowa jest punktem wyjścia. Każde rozluźnienie jest jawną, odnotowaną decyzją.
  2. Udokumentowane wymagania, a nie ogólne zapewnienie. Centrum zaufania weryfikuje zachowanie względem udokumentowanych wymagań bezpieczeństwa, w duchu Open Worldwide Application Security Project (OWASP) Application Security Verification Standard (ASVS) 5 (owasp_asvs_5#x165): standard weryfikacji mierzy zgodność z wyszczególnionymi wymaganiami. Nie poświadcza, że niczego nie pominięto.

Nie dotyczy jako profil. Ten indeks nie implementuje profilu zgodności. Tam, gdzie podstrona odnosi się do standardu (International Organization for Standardization (ISO) 32000-2 dla szyfrowania i podpisów, ISO/IEC 29147/30111 wraz z International Electrotechnical Commission (IEC) dla ujawniania, European Union (EU) General Data Protection Regulation (GDPR) / ISO/IEC 29100 dla przetwarzania danych), przytacza konkretną klauzulę i reference_id we własnym frontmatterze. Sama renderuje tabelę stwierdzenie → klauzula.