Jak rozmawiać z programistą o bezpieczeństwie strony

Masz przed sobą raport z testu strony, maila od firmy hostingowej albo wiadomość od klienta, że coś wygląda dziwnie. Nie wiesz, czy to poważne. Nie chcesz wyjść na kogoś, kto się nie zna, ale nie chcesz też płacić za pracę, która nie była potrzebna.

Do dobrej rozmowy z programistą nie potrzebujesz wiedzy technicznej. Potrzebujesz porządku: jasnej prośby, konkretnego terminu i sposobu, żeby sprawdzić, że rzecz została zrobiona. Poniżej opisuję, jak to poukładać.

Co wysłać w pierwszej wiadomości

Programista pracuje najszybciej, gdy od razu dostaje trzy rzeczy.

Problem słowami źródła. Skopiuj nazwę problemu dokładnie tak, jak podał ją raport albo hosting. Nie streszczaj. „Plik kopii zapasowej dostępny publicznie” mówi programiście więcej niż „coś jest nie tak z kopiami”.

Dokładny adres. Nie „na stronie”, tylko pełny adres podstrony albo pliku, na przykład https://twojadomena.pl/backup.zip.

Dowód. Zrzut ekranu z widoczną datą, pełny raport w załączniku, przekazany mail od hostingu. Dzięki temu nikt nie musi zgadywać, co widziałeś.

Cała wiadomość może wyglądać tak:

Temat: twojadomena.pl, publicznie dostępny plik kopii zapasowej

Cześć Marku, test bezpieczeństwa z 2 września pokazał, że pod adresem https://twojadomena.pl/backup.zip da się pobrać plik kopii strony. W załączniku zrzut ekranu i cały raport. Proszę o potwierdzenie, czy to prawda, wycenę naprawy i termin. Jeśli uznasz, że to fałszywy alarm, napisz proszę w dwóch zdaniach dlaczego.

Jedna rzecz, której nie wysyłaj: hasła w treści maila. Jeśli programista potrzebuje dostępu do panelu, załóż mu osobne konto, które później łatwo usunąć.

Poproś o wycenę i termin, a nie o „zerknięcie”

„Zerknij, jak znajdziesz chwilę” to prośba, która potrafi czekać miesiącami. Poproś o cztery konkretne informacje: co dokładnie zostanie zrobione, ile to kosztuje albo ile zajmie godzin, do kiedy i czy coś może przy tym przestać działać.

Ostatnie pytanie jest ważniejsze, niż wygląda. Aktualizacja starej wtyczki bywa prosta, ale bywa też tak, że pociąga za sobą zmiany w motywie. Lepiej wiedzieć o tym przed, niż odkryć w piątek wieczorem, że formularz zamówień nie działa.

Jeśli masz z programistą abonament, zapytaj, czy naprawa mieści się w nim, czy jest osobnym zleceniem. Przy poważniejszych sprawach poproś też o rozdzielenie dwóch rzeczy: usunięcia skutku i zamknięcia przyczyny. Usunięcie złośliwego pliku bez znalezienia drogi, którą trafił na serwer, to naprawa na tydzień.

Ustalcie, co w tym tygodniu, co w miesiącu, a co później

Nie wszystko jest pilne, a próba naprawienia wszystkiego naraz zwykle kończy się tym, że nic nie jest zrobione porządnie. Dobrze działa podział na trzy terminy.

W tym tygodniu to rzeczy, z których ktoś może skorzystać od razu albo które odsłaniają dane: plik kopii lub konfiguracji do pobrania, wtyczka ze znaną i aktywnie wykorzystywaną luką, ostrzeżenie Google, wygasły certyfikat, konto administratora, którego nikt nie rozpoznaje, formularz wysyłający dane bez szyfrowania.

W tym miesiącu to zaległe aktualizacje bez znanego aktywnego ataku, brak DMARC albo DMARC w trybie p=none, brak nagłówków bezpieczeństwa, stare konta byłych współpracowników.

Później to rzeczy, które podnoszą poziom zabezpieczeń, ale nic się nie stanie, jeśli poczekają kilka tygodni: ukrywanie numerów wersji, dopracowanie polityki bezpieczeństwa treści, przeprowadzka na lepszy hosting.

Programista może mieć inne zdanie o kolejności i warto wysłuchać, dlaczego. Ostatnie słowo należy jednak do Ciebie, bo to Ty ponosisz ryzyko i płacisz za skutki.

Jak sprawdzić, że naprawa została zrobiona

„Zrobione” w mailu to za mało. Poproś o krótką notatkę: co zostało zmienione, gdzie i kiedy. Dwa zdania wystarczą, ważne, żeby zostały na piśmie.

Część rzeczy sprawdzisz sam. Jeśli chodziło o plik kopii, jego adres powinien teraz pokazywać błąd, a nie pobierać plik. Jeśli o certyfikat, kłódka w przeglądarce pokaże nową datę ważności. Jeśli o aktualizacje, na stronie Wtyczki w WordPressie nic nie powinno czekać w kolejce.

Najprostszy sposób to powtórzenie tego samego testu, który znalazł problem, i porównanie wyników. Jeśli problem zniknął z raportu, masz potwierdzenie. Jeśli nie, masz konkretny powód, żeby wrócić do rozmowy.

Całą korespondencję trzymaj w jednym folderze. Przyda się przy kolejnej naprawie, a przy wycieku danych stanowi dowód, że dbałeś o bezpieczeństwo, czego wymaga RODO.

Co powinien obejmować rozsądny abonament

Jednorazowe naprawy gaszą pożary. Żeby nie wybuchały, strona potrzebuje stałej opieki. Rozsądny miesięczny zakres dla strony małej firmy to:

• aktualizacje systemu, motywu i wtyczek przynajmniej raz w miesiącu, a pilne łatki bezpieczeństwa szybciej, zawsze ze sprawdzeniem strony po aktualizacji,
• kopie zapasowe przechowywane poza serwerem, z próbą odtworzenia co jakiś czas,
• monitorowanie, czy strona działa i czy certyfikat nie wygasa,
• przegląd kont z dostępem do panelu,
• okresowy test bezpieczeństwa z zewnątrz,
• krótkie podsumowanie co miesiąc: co zrobiono i co wymaga Twojej decyzji,
• ustalony czas reakcji i kanał kontaktu na wypadek włamania.

Ceny bardzo się różnią, więc porównuj zakres, a nie samą kwotę. Dopilnuj też jednej rzeczy niezależnie od umowy: domena i hosting powinny być zarejestrowane na Twoją firmę, a Ty powinieneś mieć własne konto administratora. Jeśli współpraca się skończy, nie możesz zostać bez dostępu do własnej strony.

Sygnały ostrzegawcze w odpowiedziach

Nie musisz oceniać strony technicznie, żeby wyłapać odpowiedzi, które powinny Cię zaniepokoić:

• „WordPress jest bezpieczny, nic nie trzeba robić.”
• „Nie aktualizujemy, bo coś się zepsuje.” Czasem to prawda, ale wtedy rozwiązaniem jest kopia testowa strony, na której sprawdza się aktualizacje, a nie brak aktualizacji.
• „Kopie są na serwerze.” Jeśli na tym samym, na którym stoi strona, to przy włamaniu albo awarii znikną razem z nią.
• „Podaj mi swoje hasło.” Każdy powinien mieć własne konto.
• „To fałszywy alarm” bez żadnego wyjaśnienia.
• „Zrobi się” bez daty.
• Opór przed przekazaniem Ci dostępu do hostingu, domeny albo panelu.

Dobry programista nie obraża się o pytania, bo wie, że dzięki nim łatwiej ustalić zakres pracy i rozliczyć się za nią. Jeśli odpowiedzi są mgliste albo nerwowe, to też coś mówi, i dobrze mieć to w głowie przed podpisaniem kolejnej umowy.