Lista wykrojników Magento Security

Bardzo często pobieramy witrynę z innej firmy, a teraz utknęliśmy z konglomeratem kodu i potencjalnie dziesiątkami osób, które pracowały nad witryną. Szukam listy dziurkaczy, o którą prosi ochroniarz, aby upewnić się, że witryna Magento jest zahartowana. Byłoby to wymagane, gdyby ktoś wziął pełną odpowiedzialność za cały kod, a klient nie chciał odbudowywać od zera.

Moje pytanie: Czy istnieje lista 10 najlepszych lub 20 najlepszych pozycji, o które można zadać i udokumentować?

Z mojego doświadczenia wynika, że ​​są to ważne rzeczy, aby uzyskać informacje na temat przejęcia nowego sklepu z punktu widzenia bezpieczeństwa. Ta lista nie jest jeszcze zamówiona i kompletna, będę nadal pracować nad listą.

Magento Security

1. Używany HTTPS (w całym sklepie, tylko przy kasie)?
2. Niestandardowa ścieżka administratora?
3. Dostęp do ścieżki administratora jest ograniczony?
4. Ilu administratorów? Czy są jacyś niepotrzebni użytkownicy?
5. Ochrona konta i szyfrowanie haseł (dla klientów i administratorów): Standard czy personalizacja? Autoryzacja 2-czynnikowa?
6. (Najnowsza) Używasz wersji Magento?
7. Czy zastosowano poprawki bezpieczeństwa Magento?
8. Niestandardowe foldery / skrypty na poziomie głównym, które są potrzebne, aby uzyskać do nich dostęp zdalnie?
9. Czy dostęp do systemu testowego / testowego (jeśli jest dostępny) jest ograniczony?
10. Czy używane są usługi sieciowe, import / eksport?
11. Ile ról usługi sieciowej? Czy są jakieś aktywne role?
12. Lista zainstalowanych rozszerzeń
13. Zainstalowane rozszerzenia są aktualne?
14. PCI-DSS, zaufane sklepy, jakaś inna etykieta?
15. Okres ważności sesji / plików cookie?
16. Uruchom tylko Magento. (Brak Wordpress lub jakiegokolwiek innego oprogramowania)
17. Przechowywane dane: Jakie dane klienta i zamówienia (a także dane z zewnętrznych i niestandardowych rozszerzeń) są przechowywane? Dane bankowe, dane karty kredytowej (patrz PCI-DSS)?

Bezpieczeństwo systemu

1. Wersja PHP: najnowsza czy stara?
2. Uprawnienia do plików: działa jako użytkownik www-data / apache lub root?
3. Czy ustawione są odpowiednie uprawnienia do plików?
4. Kup dane uwierzytelniające do bazy danych a baza danych działa jako root?
5. Dostęp SSH / SFTP? Uwierzytelnianie na podstawie klucza?
6. SLA z dostawcą usług hostingowych w zakresie (zwykłych) aktualizacji systemu operacyjnego, PHP + i aktualizacji bezpieczeństwa?

Organizacja

1. Kto jest odpowiedzialny za aktualizacje systemu (bezpieczeństwa)?
2. Kto ma dostęp do serwera na żywo?
3. Kto ma dostęp do sklepu na żywo?
4. Gdzie hostowany jest kod? Kto ma dostęp do samego repozytorium i dostępu push?
5. Jak wygląda obecny proces tworzenia oprogramowania? Czy przed wdrożeniem kodu w wersji testowej / testowej / na żywo wykonywane są przeglądy kodu i automatyczne kontrole?
6. Czy przeprowadzane są (regularnie) testy bezpieczeństwa lub audyty bezpieczeństwa?
7. Czy istnieje regularna kopia zapasowa? Jeśli tak, to czy jest zewnętrzne?
8. W zależności od wielkości sklepu / firmy: Czy istnieją plany ciągłości działania i / lub plany naprawcze?

Upewnij się, że twój folder / downloader / jest bezpieczny. Możesz mieć najdłuższe hasło na świecie, ale jeśli mam cały czas na świecie, aby brutalnie wymusić informacje o użytkowniku na stronie pobierania, w końcu je otrzymam. Inną sprawą jest upewnienie się, że lista katalogów serwerów nie jest w stanie. Jeśli są na liście, mogę łatwo pobrać zawartość twojego serwera w Google i rozpocząć przeglądanie. Byłbyś zaskoczony ilością poufnych informacji, które ludzie przechowują na swoich serwerach internetowych.

Aby rozwinąć listę Anny Volk, ta lista wykracza poza to, co typowe

• Polityka bezpieczeństwa treści (gdy właściwie wdrożona, uniemożliwia XSS)
• HSTS (HTTP Strict Transport Security)
• SELinux z odpowiednio ustawionymi kontekstami.
• Zainstalowano yum-cron / aktualizacje nienadzorowane do automatycznych aktualizacji bezpieczeństwa systemu