przechowywanie zgłoszeń z formularza w czystym tekście

Przechowywanie zgłoszeń z formularza w czystym tekście naraża dane wrażliwe na ujawnienie w razie wycieku.

Co oznacza zapis zgłoszenia w czystym tekście

Przechowywanie zgłoszeń z formularza w czystym tekście oznacza zapisanie ich w postaci bezpośrednio czytelnej dla osoby lub programu, który uzyska dostęp do pliku, tabeli bazy danych, kopii zapasowej albo eksportu. Jeżeli formularz zawiera imię i nazwisko, numer telefonu, adres e-mail, opis awarii, dane logowania, adres zamieszkania lub informacje o konfiguracji komputera, wszystkie te wartości mogą zostać odczytane bez dodatkowego klucza deszyfrującego. Samo ukrycie strony formularza za logowaniem nie zmienia sposobu przechowywania danych.

Czysty tekst nie jest tym samym co format tekstowy, taki jak UTF-8, JSON, CSV czy zwykły dokument tekstowy. Format określa sposób zapisu znaków i struktury danych, natomiast bezpieczeństwo zależy od tego, czy zawartość została zaszyfrowana, kto może ją odczytać oraz gdzie znajdują się jej kopie. Plik JSON z zaszyfrowanymi wartościami może być chroniony, a tabela bazy danych zawierająca jawne dane pozostaje narażona, nawet jeśli aplikacja działa poprawnie i korzysta z nowoczesnego silnika bazodanowego.

Drogi ujawnienia danych zapisanych jawnie

Jawne zgłoszenia mogą zostać ujawnione przez nieograniczony dostęp do panelu administracyjnego, błędne uprawnienia systemu plików, podatność aplikacji, wyciek kopii zapasowej albo przypadkowe dołączenie pliku do zgłoszenia serwisowego lub wiadomości e-mail. Ryzyko dotyczy również logów aplikacyjnych. Jeśli program zapisuje całe żądanie HTTP, obiekt formularza lub treść wyjątku, dane mogą trafić do dziennika, który jest przechowywany dłużej niż właściwa baza i bywa dostępny większej liczbie osób.

Problem pogłębiają kopie robocze, migawki dysków, eksporty do arkuszy kalkulacyjnych oraz pliki tymczasowe tworzone podczas diagnostyki. Usunięcie rekordu z głównej tabeli nie musi usunąć go z kopii zapasowej, dziennika transakcji, pamięci podręcznej ani systemu monitoringu. W praktyce należy więc sprawdzić cały przepływ: odebranie formularza przez serwer, walidację, zapis, wyświetlanie w panelu, wysyłkę powiadomienia, archiwizację i usuwanie. Każdy etap może utworzyć osobny jawny egzemplarz tej samej treści.

Rozdzielenie szyfrowania od kontroli dostępu

Ochrona zgłoszeń powinna obejmować szyfrowanie danych w miejscu przechowywania oraz szyfrowanie transmisji między przeglądarką a serwerem. Szyfrowanie połączenia HTTPS chroni dane podczas przesyłania, ale nie zabezpiecza automatycznie rekordów zapisanych na dysku. Z kolei szyfrowanie dysku lub nośnika nie chroni treści przed użytkownikiem aplikacji, który ma poprawnie przyznany dostęp do odszyfrowanych rekordów. Te mechanizmy rozwiązują różne problemy i powinny być stosowane łącznie z ograniczeniem uprawnień.

Nie wszystkie pola wymagają identycznego sposobu ochrony. Dane potrzebne do obsługi kontaktu, takie jak numer telefonu, mogą być szyfrowane tak, aby uprawniony operator mógł je odczytać. Informacje, które służą wyłącznie do sprawdzenia zgodności, mogą być zastąpione skrótem kryptograficznym lub tokenem, o ile aplikacja nie musi odzyskać oryginalnej wartości. Hasła i inne sekrety uwierzytelniające nie powinny być przechowywane odwracalnie ani zapisywane w zgłoszeniu; jeżeli użytkownik podał je w formularzu, należy ograniczyć ich dalsze przetwarzanie i usunąć je z treści oraz logów.

Klucze szyfrujące muszą być przechowywane oddzielnie od danych, z kontrolą dostępu i możliwością wymiany. Umieszczenie klucza w tym samym katalogu co zaszyfrowany eksport lub wpisanie go na stałe do kodu aplikacji nie zapewnia właściwego rozdzielenia. Warto także rejestrować dostęp administracyjny do zgłoszeń, ograniczać zakres widocznych pól i stosować zasadę minimalnych uprawnień. Test zabezpieczeń powinien obejmować próbę odtworzenia danych z kopii zapasowej, sprawdzenie uprawnień plików oraz wyszukanie treści formularzy w logach i plikach tymczasowych.

Bezpieczny obieg zgłoszenia w serwisie komputerowym

Formularz powinien przyjmować tylko informacje niezbędne do kontaktu i opisania usterki, a pola tekstowe muszą być walidowane pod kątem długości, kodowania oraz nieoczekiwanych znaków. Walidacja nie zastępuje szyfrowania, ale ogranicza ryzyko zapisania niekontrolowanych danych i ataków na panel prezentujący zgłoszenia. Przy wyświetlaniu treści należy stosować kodowanie kontekstowe, aby tekst wpisany przez użytkownika nie został potraktowany jako kod HTML lub skrypt. Powiadomienia e-mail powinny zawierać minimalną informację, na przykład identyfikator zgłoszenia, zamiast pełnej treści formularza.

Podczas przyjmowania laptopa lub komputera PC serwisant powinien rozdzielać dane potrzebne do diagnozy od danych kontaktowych i nie kopiować całej zawartości formularza do lokalnych notatek. Pliki diagnostyczne, zrzuty ekranu i raporty sprzętowe mogą ujawniać nazwy użytkowników, ścieżki katalogów, adresy sieciowe lub fragmenty dokumentów. Takie materiały należy przechowywać w kontrolowanym miejscu, ograniczać czas ich przechowywania i usuwać zgodnie z ustaloną procedurą. Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i ich podzespołów, dlatego przy przekazywaniu urządzenia warto wcześniej usunąć z formularza hasła oraz inne sekrety.

Kontrola nie kończy się na wdrożeniu formularza. Należy okresowo sprawdzać, czy nowe wersje aplikacji nie zapisują danych w logach, czy kopie zapasowe są chronione, czy konta personelu mają aktualne uprawnienia oraz czy mechanizm usuwania obejmuje wszystkie miejsca przechowywania. Pomocne jest testowe zgłoszenie zawierające jednoznaczny znacznik, na przykład unikalny ciąg znaków, a następnie wyszukanie go w bazie, logach, załącznikach i kopiach roboczych. Taki przegląd pozwala potwierdzić rzeczywisty przepływ danych zamiast zakładać, że zabezpieczenie działa wyłącznie na podstawie konfiguracji.