ContentLIBRE — strona główna

BEZPIECZEŃSTWO I EKSPLOATACJA

Wyraźne granice.
Świadome wdrożenie.

Strzeżona granica żądania to jeden z elementów bezpiecznego wdrożenia — a nie zamiennik poświadczeń, kontroli sieciowych i kompozycji przejrzanej pod kątem jej środowiska.

Zobacz przewodnik po konfiguracji lokalnej Sprawdź status projektu

Różne mechanizmy. Różne odpowiedzialności.

Bramka dopuszczania

Bramka odrzuca ruch, gdy brakuje wymaganych komponentów granicy. Jej profil utwardzony (hardened) odrzuca również blokery produkcyjne zgłaszane przez komponenty.

CORS i CSRF

CORS reguluje przeglądarkowe zezwolenia międzyźródłowe; nie jest autoryzacją. Mechanizmy CSRF chronią zapisy, które mogą nieść poświadczenia odtworzone przez przeglądarkę.

Budżet żądań anonimowych

Limity częstotliwości i współbieżności ograniczają żądania bez poświadczeń. To granica przeciw nadużyciom, a nie zamiennik tożsamości ani uprawnień aplikacyjnych.

Strażnik serializacji

Ogólna serializacja węzłów jest odmawiana wywołującym anonimowo, podczas gdy celowo renderowane strony i rzeczywiste pliki mogą pozostać czytelne.

Tożsamość wywołującego

Operacje typowanego API korzystają z resolvera wywołującego. Publiczne DTO musi być celowo ukształtowane do publikacji, a nie skopiowane z odpowiedzi zarządczej.

Mechanizmy kontroli provisioningu

Kanały instalacji z plików mogą instalować działający kod. Udokumentowana blokada utwardzona odrzuca ruch, dopóki instalator plików jest aktywny; nie wyłącza tego instalatora.

Granica, po kolei.

Granica żądania w kolejności: bramka dopuszczania, klasyfikacja hosta, budżet anonimowy, CORS i CSRF, a następnie Sling i uprawnienia repozytorium, które faktycznie decydują.
Każdy mechanizm ma jedno zadanie. Żaden z nich nie zastępuje uprawnienia repozytorium, które decyduje, czy wywołujący może odczytać lub zapisać węzeł.

LISTA KONTROLNA OPERATORA

Zanim wdrożenie stanie się publiczne.

  1. Zastąp deweloperskie poświadczenia i źródła

    Skonfiguruj poświadczenie administratora i przejrzyj listę dozwolonych źródeł CORS. Trzymaj poświadczenia i sekrety podpisujące poza plikami funkcji, logami i przykładami.

  2. Przejrzyj granicę sieci i ruchu przychodzącego

    Ogranicz nasłuch na źródle, zakończ TLS i zweryfikuj obsługę nagłówków proxy w wybranym wdrożeniu. Adres localhost nie dowodzi, że nasłuch działa wyłącznie na pętli zwrotnej.

  3. Usuń zbędne kanały administracyjne

    Przejrzyj dostęp do konsoli, instalację przez JCR i instalację z plików w faktycznym agregacie. Przebuduj i przetestuj rozruch po zmianach zależności; usunięcie funkcji nie daje automatycznie bezpiecznej kompozycji.

  4. Używaj trybu utwardzonego — i weryfikuj więcej niż sam tryb

    Bramka raportuje tylko to, co mogą zaobserwować jej komponenty. Osobno przetestuj politykę dostępu, tożsamości usług, kopie zapasowe, odtwarzanie, monitorowanie i proces łatania obowiązujący w organizacji.

Liveness to nie readiness.

Udokumentowana trasa /health/live pozostaje dostępna, gdy bramka dopuszczania jest zamknięta. Pomaga to operatorowi odróżnić działający proces, który celowo odrzuca ruch, od procesu, który przestał odpowiadać. Nie jest to stwierdzenie, że każda usługa jest gotowa.

Zgłaszanie potencjalnej podatności.

Zweryfikowany prywatny kanał zgłoszeń nie został jeszcze opublikowany. Właściciel projektu musi opublikować i przetestować ten kanał przed startem. Nie publikuj szczegółów exploitów, poświadczeń ani wrażliwych informacji o wdrożeniu w publicznym zgłoszeniu. Ta strona nie deklaruje zobowiązania co do czasu reakcji.

Zrozum podstawę przed wdrożeniem.

Zacznij od udokumentowanej architektury i granic wybranego wydania.

Przeczytaj o architekturze