Zdecyduj, co należy do strony publicznej.

1. Opisz osobę i zadanie.

Dla każdej usługi dokończ zdanie: „Osoba w tej roli musi wykonać tę czynność z tego rodzaju urządzenia”. Czytanie publicznego harmonogramu, edytowanie wewnętrznej procedury i utrzymywanie bazy danych to różne zadania. Nie upubliczniaj usługi tylko dlatego, że jeden wolontariusz potrzebuje okazjonalnego zdalnego dostępu.

Oddziel dostęp sieciowy od autoryzacji aplikacji. Dotarcie do strony logowania nie jest pozwoleniem na czytanie plików członków. I odwrotnie, ukrycie usługi za prywatną siecią nie rozstrzyga, którzy członkowie mogą edytować lub eksportować jej treść. Zapisz obie warstwy oraz proces odbierania dostępu, gdy ktoś odejdzie.

Uwzględnij odzyskiwanie konta w tej samej dyskusji. Prywatna usługa, którą może odblokować tylko jedna osoba, tworzy inny rodzaj awarii, nawet jeśli jej początkowe reguły dostępu wyglądają na restrykcyjne.

2. Wypełnij małą macierz dostępu.

Oto hipotetyczna konfiguracja warsztatu społecznościowego. Wybory są przykładami do dyskusji, a nie gotowym projektem sieci.

Obok każdego wiersza zapisz rzeczywisty mechanizm: konta aplikacji, zatwierdzoną prywatną metodę dostępu lub inną udokumentowaną kontrolę. „Prywatne” bez mechanizmu i testu to tylko etykieta.

3. Przejrzyj ścieżki wokół strony logowania.

Wymień reverse proxy, listenery aplikacji, porty bazy danych i narzędzia administracyjne. Aplikacja może mieć starannie skonfigurowany ekran logowania, podczas gdy inny interfejs pozostaje osiągalny. Sprawdź wdrożoną konfigurację przed jej zmianą i zachowaj ścieżkę odzyskiwania dla wszystkiego, co kontroluje zdalny dostęp.

Docker wymaga osobnej weryfikacji, gdy jest częścią Twojej konfiguracji. Mapowanie portów bez jawnego adresu hosta domyślnie publikuje usługę na wszystkich adresach hosta. Powiązanie z interfejsem loopback ogranicza dostęp w udokumentowanym domyślnym przypadku NAT, ale znaczenie mają tryb sieci, routing bezpośredni i starsze zachowanie Dockera. Przeczytaj dokumentację dotyczącą rzeczywistej topologii, a następnie zweryfikuj osiągalność przez ścieżki IPv4 i IPv6, których używasz. Publikowanie i mapowanie portów Dockera.

4. Sprawdź skuteczne mechanizmy kontroli, a nie uspokajające etykiety.

Sprawdź zaporę sieciową razem z oprogramowaniem, które tworzy reguły sieciowe. Docker dokumentuje, że opublikowany ruch kontenera może zostać przekierowany, zanim zastosują się zwykłe reguły wejściowe UFW. Czysto wyglądający status UFW nie dowodzi więc, że port kontenera jest niedostępny. Nie wyłączaj zarządzania zaporą przez Dockera jako szybkiego rozwiązania; dokumentacja opisuje konsekwencje sieciowe. Filtrowanie pakietów i zapory w Dockerze.

Sprawdź role aplikacji osobno. Na przykład BookStack łączy uprawnienia ról i pozwala na nadpisania na poziomie treści, więc efektywne uprawnienia użytkownika mogą różnić się od nazwy jednej przypisanej roli. Przejrzyj pełne przypisanie i przetestuj reprezentatywne strony oraz załączniki. Reguły uprawnień BookStack.

5. Uwzględnij transport i zaufanie w planie.

Usługa ograniczona do członków nadal zawiera poświadczenia i prywatne treści. Zaplanuj HTTPS i zaufanie do certyfikatów dla rzeczywistych klientów, zamiast uczyć członków ignorowania ostrzeżeń przeglądarki. Utrzymuj odpowiedzialność za odnowienie certyfikatów i sprawdzanie błędów w notatniku razem z dostępem do domeny.

Dokumentacja Caddy odróżnia publiczną walidację certyfikatów od lokalnego urzędu certyfikacji. Klient musi ufać lokalnemu urzędowi, aby używać jego certyfikatów bez ostrzeżeń. W przypadku certyfikatów publicznych walidacja HTTP i TLS-ALPN wymaga odpowiednich ścieżek przychodzących; walidacja DNS jest osobno konfigurowaną alternatywą. Wybierz metodę dopasowaną do zamierzonej granicy dostępu. Automatyczny HTTPS Caddy i lokalne zaufanie.

To krok planowania dostępu, a nie twierdzenie, że sam certyfikat czyni aplikację prywatną lub odpowiednio autoryzowaną.

6. Przetestuj zarówno ścieżki dozwolone, jak i odrzucone.

Użyj osobnych sesji przeglądarki dla wylogowanego odwiedzającego, zwykłego członka i redaktora. Sprawdź zwykłą stronę, bezpośredni lokalny adres URL załącznika, akcję eksportu i trasę administracyjną. Ponów test po usunięciu konta lub zmianie jego roli. Zapisz oczekiwany wynik przed wypróbowaniem akcji, aby nieoczekiwany sukces nie został pomylony z wygodą.

Z sieci, których użycie do testów jest autoryzowane, zweryfikuj, że usługa publiczna jest osiągalna, a zamierzone prywatne interfejsy nie są. Przetestuj odpowiednie rodziny adresów i rzeczywisty punkt końcowy, a nie tylko nazwę hosta, która może rozwiązywać się inaczej. Zapisz datę, sieć źródłową i wynik. Te sprawdzenia należy wykonać w Twojej konfiguracji; żadne nie jest tu zgłoszone jako ukończone.

Przetestuj poufny osadzony obraz przez jego bezpośredni adres URL, będąc wylogowanym i jako nieuprawniony członek. Obrazy BookStack są domyślnie publiczne, w przeciwieństwie do lokalnych załączników; sama ograniczona strona nie wystarcza. Przejrzyj bezpieczeństwo obrazów oraz rozróżnienia dotyczące przechowywania i uprawnień w przewodniku dostępu przed zaakceptowaniem granicy.

7. Nieudaną granicę potraktuj jako decyzję do ponownego rozważenia.

Jeśli nieuprawnione konto może czytać dane, przestań rozszerzać dostęp i sprawdź dziedziczenie ról, udostępnienia i bezpośrednie ścieżki plików. Jeśli prywatny port jest osiągalny, przejrzyj jego powiązanie i reguły sieciowe, zanim dodasz kolejną warstwę metodą zgadywania. Jeśli zamierzony opiekun nie może się połączyć, użyj udokumentowanej ścieżki odzyskiwania, zamiast przyznawać wszystkim szerszy dostęp.

Umieść poprawioną regułę i powtarzalne sprawdzenie w notatniku dostępu. Powiąż go z inwentarzem usług oraz ćwiczeniem odzyskiwania. Te granice ograniczają niechciany dostęp, gdy są prawidłowo wdrożone; nie obiecują anonimowości ani nie usuwają potrzeby aktualizacji i ostrożnego przetwarzania danych.