Magento audit trail: kto zmienił cenę lub usunął produkt?

Dlaczego w standardowym Magento 2 Open Source nie widać, kto zmienił cenę?

W czystym Magento 2 Open Source (wersje 2.4.6, 2.4.7 na PHP 8.3) nie sprawdzisz bezpośrednio z poziomu panelu, kto zmienił cenę z 499 PLN na 49 PLN ani kto skasował kluczowy produkt. Domyślna baza danych platformy przechowuje wyłącznie aktualny stan encji EAV w tabeli catalog_product_entity_decimal, nadpisując poprzednie wartości bez pozostawiania identyfikatora admin_user_id. Aby rejestrować pełną historię takich zdarzeń wraz z wartością przed i po edycji, wdrożyliśmy w SISL dedykowane narzędzie SISL Time Machine — audit log dla Magento, które monitoruje mutacje modeli i operacje w repozytoriach bez obciążania warstwy bazodanowej.

Standardowa instalacja Magento loguje jedynie autoryzację do panelu w tabeli admin_user_session oraz błędy systemowe w var/log/system.log. Oznacza to, że jeśli pięciu pracowników ma konto z rolą Administratora, a zewnętrzny integrator z Subiekt GT lub Comarch ERP Optima korzysta z tokenu integracji REST API (Bearer token), platforma nie powiąże konkretnego żądania modyfikacji rekordu z człowiekiem lub skryptem, chyba że wdrożysz dedykowany mechanizm śledzenia zdarzeń (Audit Trail).

Jakie realne straty w polskich realiach e-commerce generuje brak audytu zmian?

Błąd ludzki lub źle skonfigurowana synchronizacja stanów magazynowych potrafi w kilkanaście minut wywołać lawinę problemów prawno-finansowych. Typowy scenariusz z polskiego rynku: pracownik omyłkowo zmienia stawkę VAT z 23% na 8% dla kategorii elektroniki użytkowej albo obniża cenę flagowego ekspresu do kawy z 3499 PLN na 349 PLN. Zanim ktokolwiek zorientuje się w panelu, oferta zostaje zaciągnięta przez dwukierunkowy integrator na Allegro.

Klienci kupują 80 sztuk w ramach Allegro Smart, płacąc przez BLIK lub szybki przelew Przelewy24. Zamówienia trafiają natychmiast do Comarch ERP Optima lub Subiekt nexo, gdzie generowany jest dokument, a następnie przesyłany do Krajowego Systemu e-Faktur (KSeF). Odkręcenie tego procesu to koszmar księgowy: korekty faktur w KSeF, niezgodności w pliku JPK_V7, spory konsumenckie przed UOKiK o odmowę realizacji z powodu oczywistego błędu (art. 84 Kodeksu cywilnego) oraz zablokowane środki na bramkach płatniczych. Gdy właściciel pyta: „Kto za to odpowiada?”, w panelu Magento widzi jedynie datę updated_at bez żadnego nazwiska.

Czym różni się śledzenie akcji w Adobe Commerce od Magento Open Source?

Płatna wersja Adobe Commerce (dawniej Magento Enterprise, której licencja zaczyna się od około 22 000 USD rocznie) posiada wbudowany moduł Magento_Logging. Rejestruje on akcje w panelu w dedykowanych tabelach magento_logging_event oraz magento_logging_event_changes. System ten zbiera:

• Identyfikator administratora (admin_id), adres IP oraz znacznik czasu akcji.
• Nazwę modyfikowanej akcji (np. catalog_product_save, adminhtml_customer_save).
• Diff danych: starą wartość (old value) i nową wartość (new value) zapisaną w formacie zserializowanym.

Adobe Commerce nie rozwiązuje jednak problemu całkowicie. Moduł potrafi drastycznie zwolnić zapis przy masowych operacjach (np. aktualizacja 50 000 produktów przez harmonogram zadań cron). Ponadto domyślnie pomija część zapytań wysyłanych przez GraphQL oraz endpointy asynchroniczne RabbitMQ. W darmowej edycji Open Source modułu Magento_Logging nie ma wcale — jego instalacja poprzez kopiowanie plików z wersji Commerce narusza licencję Adobe.

Moduły audit trail od dostawców trzecich (Amasty, Mirasvit, MageWorx) — gdzie tkwią pułapki?

Większość sklepów ratuje się gotowymi wtyczkami dostępnymi na rynku komercyjnym. Moduły takie jak Amasty Admin Actions Log, Mirasvit Action Log czy MageWorx Admin Activity Kosztują zazwyczaj między 149 a 299 USD za licencję. Choć na papierze wyglądają kompletnie, podczas realnego wdrożenia na produkcji w Magento 2.4.7 wychodzą ich ograniczenia architektoniczne:

1. Puchnięcie bazy danych: Wtyczki zapisują pełny zrzut obiektu modelu przed i po zapisie w formie JSON w MySQL. Przy sklepie posiadającym 40 000 SKU i częstych aktualizacjach z ERP (stany magazynowe aktualizowane co 10 minut), tabela logów potrafi urosnąć o 15 GB w 3 miesiące, blokując operacje I/O na dyskach NVMe.
2. Brak wsparcia dla asynchroniczności: Rejestrowanie diffu następuje w tym samym procesie PHP, co zapis produktu. W efekcie zapis produktu w panelu zamiast 400 ms trwa 2,5 sekundy.
3. Konflikty z kompilacją Dependency Injection: Po przejściu na PHP 8.3 i wykonaniu bin/magento setup:di:compile nieaktualizowane regularnie moduły potrafią rzucić błędem typu Fatal error: Declaration of ... must be compatible with ... w pluginach przechwytujących metody save() repozytoriów.
4. Kompatybilność z nowymi interfejsami: Jeśli panel admina korzysta z niestandardowych nakładek lub headless API pod Hyvä Theme / Hyvä Checkout, niektóre zdarzenia interfejsu (UI components) nie są w ogóle rejestrowane.

Jak namierzyć sprawcę usunięcia produktu bez zainstalowanego modułu audytu?

Jeśli produkt zniknął ze sklepu wczoraj, a Ty nie masz żadnego narzędzia audit log, nie wszystko jest stracone. Śledztwo wymaga jednak dostępu do serwera przez SSH i bezpośredniej analizy logów systemowych oraz bazy danych.

Krok 1: Analiza access logów Nginx / Apache

Usunięcie produktu z panelu generuje żądanie HTTP POST na trasę administracyjną. Przeszukaj logi serwera Nginx za pomocą polecenia grep:

grep -E "catalog/product/delete|catalog_product/delete" /var/log/nginx/magento_access.log

W odpowiedzi otrzymasz linię zawierającą:

• Dokładny znacznik czasu (timestamp).
• Publiczny adres IP, z którego wykonano akcję.
• Identyfikator usuwanego produktu (np. /id/14892/).
• Status odpowiedzi HTTP (np. 302 przekierowanie po udanym usunięciu).
• User-Agent przeglądarki.

Krok 2: Powiązanie adresu IP z kontem administratora

Mając adres IP oraz dokładną godzinę żądania, przeanalizuj tabelę admin_user_session lub logi logowania, aby sprawdzić, który użytkownik miał aktywną sesję z tego konkretnego IP w danym przedziale czasowym:

SELECT user_id, ip, login_at, logout_at, status FROM admin_user_session WHERE ip = '195.136.25.14' AND '2024-10-14 11:25:00' BETWEEN login_at AND logout_at;

Następnie odpytaj tabelę admin_user o identyfikator user_id, aby uzyskać imię, nazwisko oraz adres e-mail pracownika.

Krok 3: Analiza binarnego logu MySQL (MySQL Binlog)

Gdy rekord został usunięty kaskadowo ze wszystkich tabel EAV (catalog_product_entity, catalog_product_entity_varchar, itp.), a brakowało wpisu w logach Nginx (ponieważ usunięcie nastąpiło przez skrypt CLI lub bezpośrednie zapytanie SQL), jedynym ratunkiem jest binlog bazy danych. Za pomocą narzędzia mysqlbinlog możesz wyodrębnić operacje DELETE:

mysqlbinlog --base64-output=DECODE-ROWS -v /var/log/mysql/mysql-bin.000123 | grep -B 5 -A 10 "DELETE FROM catalog_product_entity"

Dzięki temu dowiesz się, czy usunięcia dokonał proces PHP-FPM (żądanie webowe), worker kolejki (cron bin/magento cron:run), czy bezpośrednie połączenie z bazą przez klienta typu DBeaver/HeidiSQL.

Jak zaprojektować wydajny audyt zmian w architekturze Magento 2?

U nas w projektach wychodzimy z założenia, że mechanizm audytu nie może obciążać głównej bazy transakcyjnej sklepu. Skuteczna architektura audit trail w Magento 2 powinna spełniać cztery kryteria techniczne:

• Wykorzystanie pluginów typu 'around' lub 'after' na interfejsach Repozytoriów: Zamiast nasłuchiwać na przestarzałe zdarzenia EAV (catalog_product_save_after), system rejestruje wywołania Magento\Catalog\Api\ProductRepositoryInterface::save oraz delete. Daje to pewność przechwycenia zmian realizowanych zarówno z panelu, jak i przez REST API, GraphQL czy procesy CLI.
• Zapis diffu jako JSON w oddzielnej strukturze: Zmiany powinny trafiać do dedykowanej tabeli zoptymalizowanej pod kątem zapisu (append-only) lub bezpośrednio do klastra OpenSearch 2.x / Elasticsearch, co odciąża silnik InnoDB od kosztownych przeszukiwań tekstowych.
• Automatyczna retencja i czyszczenie danych: Logi starsze niż 60 lub 90 dni muszą być agregowane lub bezwzględnie usuwane za pośrednictwem dedykowanego harmonogramu cron, aby baza danych nie traciła wydajności indeksów.
• Rozróżnianie kontekstu wykonania: System musi jasno flagować, czy modyfikacja została wywołana przez kliknięcie w panelu przez administratora Jan Kowalski, czy przez masowy import cennika z Comarch Optima przez API z użyciem klucza integracji.

Jeśli mierzysz się z powtarzającymi się błędami asortymentu, niewyjaśnionymi zmianami cen na marketplace'ach lub problemami z wydajnością zewnętrznych wtyczek śledzących — napisz do nas. Przeanalizujemy konfigurację Twojego środowiska Magento i dobierzemy rozwiązanie, które zabezpieczy operacje w sklepie bez spowalniania panelu administracyjnego.