Bezpieczeństwo danych i procesu raportowania

01

Najpierw ustal, które dane mają być publiczne

Oferta, ceny i historia zmian są danymi roboczymi WordPressa. Dostęp do ich edycji powinien być ograniczony do właściwych ról, podczas gdy publiczna prezentacja pokazuje wyłącznie zatwierdzony zakres.

Raporty udostępnione pod stałymi adresami są przeznaczone do publicznego pobierania w skonfigurowanym procesie. Logowanie, ciasteczko sesyjne albo jednorazowy token mogą uniemożliwić pobranie przez zewnętrzny portal.

• Dane dostępowe do EstiCRM nie mogą trafiać do treści strony, zrzutów ekranu ani publicznych raportów diagnostycznych.
• Klucz licencji i dane aktualizacji należy chronić jak inne dane uwierzytelniające.
• Raport wsparcia trzeba sprawdzić przed wysłaniem pod kątem sekretów i danych osobowych.

02

WordPress jest częścią modelu bezpieczeństwa

Oficjalne zalecenia WordPressa obejmują aktualizacje rdzenia, motywów i wtyczek, mocne hasła, HTTPS, poprawne uprawnienia plików, kopie oraz ograniczenie punktów wejścia. Bezpieczna wtyczka nie naprawi niezaktualizowanego WordPressa ani przejętego konta administratora.

• Używaj wspieranych wersji WordPressa i PHP oraz aktualizuj wszystkie aktywne komponenty.
• Stosuj osobne konta, unikalne hasła i — jeśli organizacja je wdrożyła — uwierzytelnianie wieloskładnikowe.
• Wykonuj kopie bazy i plików oraz okresowo testuj odtworzenie.
• Ogranicz edycję kodu z panelu i monitoruj błędy, harmonogram oraz publiczne pliki.

03

Token integracji nie powinien pojawiać się w logach

Sekret należy udostępniać wyłącznie komponentom i osobom, które go potrzebują. Powinien być możliwy do cofnięcia lub rotacji, a jego jawna wartość nie może trafiać do logów, e-maila ani formularza wsparcia.

Po podejrzeniu ujawnienia token trzeba unieważnić, wygenerować nowy, a następnie przetestować połączenie i synchronizację. Sposób przechowywania należy potwierdzić w dokumentacji aktualnej wersji.

04

WAF powinien chronić stronę, ale nie blokować raportów

Firewall aplikacyjny może zatrzymywać złośliwe żądania przed WordPressem. Zbyt szeroka reguła może jednak blokować publiczny zasób, harmonogram albo połączenie zwrotne.

Nie należy wyłączać całego WAF z powodu jednego błędu. Najpierw identyfikuje się konkretną regułę, ścieżkę, metodę i typ żądania, a następnie tworzy najwęższy możliwy wyjątek.

05

Aktualizacja musi mieć kontrolowane źródło

Publiczny opis Deweloper GOV wskazuje aktualizacje z panelu przy aktywnym uprawnieniu oraz kontrolę podpisu i integralności paczki. Nie należy instalować paczek z niezweryfikowanego źródła ani zastępować aktualizacji ręcznym ZIP-em bez potwierdzenia wersji i pochodzenia.

• Wykonaj kopię bazy i plików przed aktualizacją produkcyjną.
• Sprawdź wymagania nowej wersji i kompatybilność środowiska.
• Po aktualizacji zweryfikuj checkout, formularze, harmonogram, widoki inwestycji oraz dostępność raportów.

06

Bezpieczeństwo jest odpowiedzialnością współdzieloną

Deweloper GOV odpowiada za logikę produktu, walidację obsługiwanych danych, kontrolę uprawnień własnych operacji, aktualizacje produktu i opisane mechanizmy diagnostyczne.

Administrator odpowiada za WordPress, hosting, konta, kopie, HTTPS, WAF, dostęp do EstiCRM i reakcję na alerty. Dostawca hostingu odpowiada za infrastrukturę w zakresie umowy, a właściciel procesu za zakres publikowanych informacji i zgodność organizacji procesu.