Dlaczego dane Powermail w TYPO3 nie powinny być zapisane jako plaintext Jak wdrożyć szyfrowanie zgodne z RODO
W skrócie
Problem:
Standardowy Powermail zapisuje dane formularzy w bazie MySQL jako zwykły tekst. Każdy z dostępem do bazy — admin serwera, hosting provider, atakujący po SQL injection — widzi imiona, emaile, telefony, treści zapytań.
Ryzyko prawne:
Art. 32 RODO wprost wymienia szyfrowanie jako środek techniczny. UODO nałożył w 2025 roku kary na łączną kwotę ponad 64 mln PLN — brak szyfrowania to jeden z najczęstszych powodów.
Rozwiązanie:
Nasza wtyczka do TYPO3 13 + Powermail automatycznie szyfruje dane w bazie algorytmem ChaCha20-Poly1305 (AEAD). Redaktor, eksporty i emaile działają bez zmian — szyfrowanie jest przezroczyste.
Wdrożenie:
Instalacja przez Composer, jeden klucz w pliku .env — gotowe. Bez modyfikacji Powermail, bez XCLASS, upgrade-safe.
Następny krok:
Sprawdź szczegóły na stronie produktowej lub skontaktuj się z nami po wdrożenie.
Formularz kontaktowy na stronie firmowej to jedno z najczęstszych miejsc, gdzie organizacja zbiera dane osobowe. Imię i nazwisko, adres email, numer telefonu, treść zapytania — często też dane wrażliwe: informacje medyczne w formularzach rejestracyjnych, dane finansowe w zgłoszeniach reklamacyjnych, dane beneficjentów w formularzach NGO. W CMS TYPO3 najpopularniejszym rozszerzeniem do formularzy jest Powermail — używany na tysiącach instalacji enterprise.
Problem? Standardowy Powermail zapisuje wszystkie te dane w bazie MySQL jako zwykły tekst — plaintext. Otwórz phpMyAdmin, przejdź do tabeli tx_powermail_domain_model_answer i zobaczysz: Jan Kowalski, [email protected], 601 234 567, „Proszę o wycenę projektu na 500 000 PLN”. Wszystko czytelne, dostępne, gotowe do skopiowania. Dla każdego, kto ma dostęp do bazy.
Kto widzi dane Powermail? Dlaczego jest to ryzyko
W typowym wdrożeniu TYPO3 dostęp do bazy MySQL ma więcej osób niż myślisz. Administrator serwera (root) widzi wszystko. Pracownicy hosting providera mają dostęp techniczny do baz klientów — nawet jeśli polityka firmy tego zabrania, technicznie mogą. Developerzy pracujący na środowisku staging często mają kopię produkcyjnej bazy (z pełnymi danymi osobowymi). Backup’y bazy danych leżą na dyskach, w chmurze, na taśmach — każda kopia to pełen zestaw danych w plaintext.
Scenariusze ataku
SQL injection — atakujący uzyskuje dostęp do bazy przez lukę w aplikacji i odczytuje całą tabelę z odpowiedziami formularzy. Ransomware — zanim dane zostaną zaszyfrowane przez atakującego, często są najpierw kopiowane (double extortion). Skompromitowane dane logowania do MySQL — np. hasło w pliku konfiguracyjnym, które wycieka przez niezabezpieczony backup.
W każdym z tych scenariuszy szyfrowanie dysku (BitLocker, LUKS) nie pomaga — bo atakujący działa na poziomie aplikacji, nie fizycznego dostępu do serwera.
Co mówi RODO i co robi UODO?
Artykuł 32 ust. 1 lit. a) RODO wymienia wprost „pseudonimizację i szyfrowanie danych osobowych” jako środek techniczny zapewniający bezpieczeństwo przetwarzania. To nie jest sugestia — to jeden z czterech środków wymienionych z nazwy w treści rozporządzenia. Artykuł 5 ust. 1 lit. f) dodaje zasadę integralności i poufności — dane muszą być chronione przed nieuprawnionym dostępem i przypadkową utratą.
Jest też argument pozytywny. Artykuł 83 ust. 2 lit. c) RODO mówi, że przy wymiarze kary organ nadzorczy bierze pod uwagę „wszelkie działania podjęte w celu zminimalizowania szkody”. Wdrożone szyfrowanie to konkretny dowód, że organizacja poważnie podchodzi do ochrony danych. Co więcej — stanowisko Europejskiej Rady Ochrony Danych (EROD) wskazuje, że utrata danych zaszyfrowanych algorytmem state-of-the-art nie musi być zgłaszana jako naruszenie ochrony danych. To oznacza: jeśli ktoś ukradnie Twoją bazę, ale dane są zaszyfrowane ChaCha20-Poly1305, ryzyko dla osób, których dane dotyczą, jest minimalne.
Polskie realia UODO karze coraz mocniej
W 2025 roku Prezes UODO nałożył kary na łączną kwotę ponad 64 mln PLN — pięciokrotność roku poprzedniego. Najgłośniejsze decyzje: Poczta Polska (27 mln PLN), ING Bank Śląski (18,4 mln PLN), McDonald’s Polska (17 mln PLN). Trend jest jasny: mniej decyzji, ale wyższe kary. UODO zmienił model egzekwowania z edukacyjnego na odstraszający.
Wśród powtarzających się powodów kar pojawia się brak odpowiednich zabezpieczeń technicznych — w tym brak szyfrowania. Przykład: Urząd Gminy w Dobrzyniewie, którego pracownikowi skradziono laptopa bez szyfrowanego dysku (decyzja DKN.5131.8.2022, kara 15 000 PLN). Inna decyzja z 2024 roku: UODO karał administratora za brak szyfrowania danych na komputerach wynoszonych z siedziby, powołując się wprost na art. 32 ust. 1 i 2 RODO.
Kluczowa obserwacja: te decyzje dotyczyły szyfrowania dysków — najniższego poziomu ochrony. Szyfrowanie danych bezpośrednio w bazie na poziomie aplikacji (encryption at rest) to wyższy standard. Organizacja, która go wdrożyła, ma znacząco silniejszą pozycję w przypadku kontroli UODO lub incydentu bezpieczeństwa.
Nasze rozwiązanie Co robi wtyczka?
Stworzyłiśmy wtyczkę do TYPO3 13 + Powermail, która automatycznie szyfruje dane formularzy w momencie zapisu do bazy i deszyfruje je przezroczyście przy odczycie. Redaktor, który ogląda zgłoszenia w module Powermail, eksportuje CSV albo czyta link potwierdzający — widzi dane w normalnej, czytelnej formie. Wysyłane emaile (do klienta i do firmy) pozostają w plaintext — szyfrowanie dotyczy wyłącznie kopii zapisanej w bazie.
Co jest szyfrowane
Dwie tabele Powermail, które zawierają dane osobowe. W tabeli mail: temat, treść, imię i nazwisko nadawcy, adres email. W tabeli answer: wartość każdej odpowiedzi — imię, telefon, treść pytania, wybór z listy, dane uploadu. Po włączeniu wtyczki każdy nowy wpis trafia do bazy jako szyfrogram. W phpMyAdmin zamiast „Jan Kowalski” zobaczysz enc:v1:<ciąg base64> — nieczytelny bez klucza.
Technologia kryptograficzna
Algorytm: ChaCha20-Poly1305 — uwierzytelnione szyfrowanie (AEAD) zgodne z RFC 8439 (standard IETF). To ten sam algorytm, którego używa TLS 1.3 w komunikacji HTTPS. Klucz 256-bitowy przechowywany w pliku .env serwera (nie w bazie, nie w kodzie źródłowym). Każdy zapis używa losowego 96-bitowego nonce — nawet identyczne dane dają różne szyfrogramy. Tag Poly1305 zapewnia ochronę integralności — wykrywa każdą próbę modyfikacji zaszyfrowanych danych (wymagą art. 5 ust. 1 lit. f RODO).
Implementacja opiera się na natywnym libsodium w PHP (dostępnym w każdym PHP 7.2+) — zero zewnętrznych zależności, zero dodatkowych bibliotek do zainstalowania. To jest state-of-the-art w rozumieniu art. 32 RODO.
Przezroczystość dla redakcji
Wtyczka działa na poziomie eventów Extbase — przechwytuje moment zapisu i moment odczytu. Nie modyfikuje klas Powermail (bez XCLASS), nie zmienia szablonów Fluid, nie wymaga zmian w konfiguracji TypoScript. To oznacza: aktualizacja Powermail do nowej wersji nie psuje szyfrowania. Redaktor nie musi wiedzieć, że szyfrowanie istnieje — widzi te same dane co wcześniej. Eksporty CSV i XLSX zawierają odszyfrowane dane. Linki potwierdzające działają normalnie. Jedyna widoczna zmiana: ktoś oglądający bazę przez phpMyAdmin lub inny klient SQL zobaczy szyfrogramy zamiast danych — i dokładnie o to chodzi.
Format zapisu i migracja stopniowa
Każdy zaszyfrowany rekord ma prefix enc:v1: który pełni dwie funkcje. Po pierwsze, pozwala jednoznacznie rozpoznać zaszyfrowane rekordy od starych (plaintext). Po drugie, umożliwia migrację stopniową — nowe zgłoszenia są szyfrowane natychmiast, stare mogą być zaszyfrowane w tle bez przestoju. Kiedy w przyszłości pojawi się nowa wersja algorytmu, prefix v2: pozwoli na płynną rotację klucza bez utraty danych.
Jaki algorytm szyfrowania wybrać? Krótki przewodnik
Nie każde szyfrowanie jest równe. RODO w art. 32 wymaga środków „uwzględniających stan wiedzy technicznej” (state of the art). Wybór algorytmu ma bezpośredni wpływ na to, czy UODO uzna Twoje szyfrowanie za wystarczające. Oto co warto wiedzieć.
Algorytmy, których nie należy używać w 2026 roku
3DES (Triple DES) — oficjalnie wycofany przez NIST w 2023 roku. Jeśli Twój system go używa, to jest pilny sygnał do migracji. Blowfish — solidny algorytm z lat 90., ale 64-bitowy blok jest za krótki dla dużych zbiorów danych. AES-CBC bez uwierzytelnienia — sam AES jest bezpieczny, ale tryb CBC bez dodatkowego tagu uwierzytelniającego jest podatny na ataki padding oracle. Atakujący może odzyskać plaintext manipulując szyfrogramem, bez znajomości klucza. To jest najczęstszy błąd w implementacjach „domowej roboty”.
Dlaczego AEAD, a nie „zwykłe” szyfrowanie?
Nowoczesna kryptografia wymaga uwierzytelnionego szyfrowania — AEAD (Authenticated Encryption with Associated Data). Algorytm AEAD szyfruje dane i jednocześnie generuje tag integralności. Jeśli ktoś zmodyfikuje choćby jeden bajt szyfrogramu, deszyfrowanie zakończy się błędem zamiast zwracać fałszywe dane. Bez AEAD atakujący mógłby podmienić email beneficjenta lub kwotę darowizny w bazie — a system by tego nie wykrył. W kontekście RODO art. 5 ust. 1 lit. f (integralność danych) to jest fundamentalny wymag.
AES-256-GCM vs ChaCha20-Poly1305
W 2026 roku to są dwa jedyne algorytmy spełniające wymogi state-of-the-art. Oba są AEAD, oba oferują 256 bitów klucza, oba są rekomendowane przez IETF. AES-256-GCM to standard NIST, niezwykle szybki na serwerach ze sprzętowym wsparciem AES-NI — obecnym w procesorach Intel i AMD od 2010 roku. Ma jednak dwa problemy: na maszynach bez AES-NI (część hostingów VPS, kontenery Docker, starsze procesory ARM) jest zauważalnie wolniejszy. I krytycznie — ponowne użycie tego samego nonce z tym samym kluczem powoduje katastrofalną utratę bezpieczeństwa (problem nonce-reuse).
ChaCha20-Poly1305 (RFC 8439) nie ma żadnego z tych problemów. Jest równie szybki na maszynach z AES-NI, ale znacznie szybszy na tych bez. Jest odporniejszy na ataki timing side-channel — czas wykonania nie zależy od danych wejściowych. Jest bardziej tolerancyjny na błędy implementacyjne. Natywnie dostępny w libsodium — bibliotece kryptograficznej wbudowanej w PHP od wersji 7.2, rekomendowanej przez PHP core team. Zero zewnętrznych zależności. Używany przez Google (TLS 1.3 w Chrome), Cloudflare (serwery edge), WireGuard (VPN), Signal (komunikator szyfrowany). Dlatego wybraliśmy właśnie ten algorytm.
Najczęściej zadawane pytania
Nie odczuwalnie. ChaCha20-Poly1305 jest jednym z najszybszych algorytmów szyfrowania — overhead na pojedynczy zapis to rząd wielkości 1 milisekundy. Przy typowym formularzu z 5–10 polami użytkownik nie zauważy różnicy.
Dane będą nie do odzyskania — to jest celowa właściwość silnego szyfrowania. Dlatego klucz przechowujemy w pliku .env na serwerze, a jego kopię zapasową należy trzymać offline (np. w sejfie, w menadżerze haseł z backup). Klucz nigdy nie trafia do repozytorium kodu ani do bazy danych.
Tak. Prefix enc:v1: pozwala na współistnienie zaszyfrowanych i niezaszyfrowanych rekordów. Nowe zgłoszenia są szyfrowane natychmiast, a istniejące można zaszyfrować w tle komendą CLI — bez przestoju i bez wpływu na działanie strony.
Nie bezpośrednio — ransomware szyfruje wszystko na serwerze, włącznie z kluczem w .env. Ale chroni przed wyciekiem danych. W modelu double extortion (atakujący najpierw kopiuje dane, potem szyfruje serwer) zaszyfrowane dane formularzy są dla niego bezwartościowe bez klucza. To zmniejsza ryzyko szantażu i — według stanowiska EROD — może eliminować obowiązek zgłoszenia naruszenia.
Szyfrowanie at rest to jeden z najsilniejszych argumentów w analizie ryzyka i przy wymiarze kary. RODO wymaga jednak całościowego podejścia — szyfrowanie to element, nie całość. Powinno być częścią szerszego zestawu środków: kontrola dostępu, logi audytowe, DPA z hosting providerem, szkolenie personelu. Nasza wtyczka pokrywa warstwę techniczną — przy wdrożeniu pomagamy też z dokumentacją i analizą ryzyka.
TYPO3 13 LTS z odpowiednią wersją Powermail. Wymagany PHP 8.1+ z natywnym libsodium (standardowo dostępny). Planujemy wsparcie dla TYPO3 14 LTS po jego stabilizacji.
Następny krok
Szyfrowanie danych formularzy w bazie to nie jest luksus — to środek techniczny wprost wymieniony w RODO, który chroni Twoją organizację przed karami UODO, wyciekiem danych i reputacyjną katastrofą. Nasza wtyczka robi to w sposób przezroczysty dla redakcji, upgrade-safe i oparty na kryptografii state-of-the-art.
Jeśli używasz TYPO3 i Powermail do zbierania danych osobowych — formularz kontaktowy, formularz rejestracyjny, formularz reklamacyjny, zgłoszenie beneficjenta — Twoje dane prawdopodobnie leżą w bazie jako plaintext w tej chwili. Szczegóły wtyczki, cennik i dokumentację znajdziesz na stronie produktowej. Chcesz porozmawić? Telefon: 12 333 44 01. Email: [email protected].