Punch List для безопасности Magento

Очень часто мы берем сайт у другой фирмы, и теперь мы застряли в конгломерате кода и, возможно, десятки людей, которые работали над сайтом. Я ищу краткий список пунктов, которые можно попросить у охранника, чтобы убедиться, что сайт Magento защищен. Это потребуется, если кто-то возьмет на себя полную ответственность за весь код, а клиент не захочет перестраивать с нуля.

Мой вопрос: есть ли топ-10 или топ-20 пунктов, которые нужно задавать и документировать?

Исходя из моего опыта, это важные вещи, о которых нужно знать при захвате нового магазина с точки зрения безопасности. Этот список еще не упорядочен и не завершен, я продолжу работу над списком.

Magento Security

1. Используется HTTPS (по всему магазину, только для оформления заказа)?
2. Пользовательский путь администратора?
3. Доступ к административному пути ограничен?
4. Сколько админов? Активные ненужные пользователи?
5. Защита учетной записи и шифрование паролем (для клиентов и администраторов): стандарт или индивидуальная настройка? Двухфакторная аутентификация?
6. (Последняя) версия Magento используется?
7. Патчи безопасности Magento применены?
8. Пользовательские корневые папки / скрипты, которые необходимы для доступа с удаленного компьютера?
9. Доступ к тестовой / промежуточной системе (если есть) ограничен?
10. Веб-сервисы, функции импорта / экспорта используются?
11. Сколько ролей в веб-сервисе? Активные ненужные роли?
12. Список установленных расширений
13. Установленные расширения в актуальном состоянии?
14. PCI-DSS, доверенные магазины, любая другая этикетка?
15. Время жизни сессии / Cookie?
16. Только запустить Magento. (Нет Wordpress или любого другого стороннего программного обеспечения)
17. Хранимые данные. Какие данные о клиентах и ​​заказах (а также данные сторонних и пользовательских расширений) хранятся? Банковские данные, данные кредитной карты (см. PCI-DSS)?

Система безопасности

1. Версия PHP: последняя версия или старая?
2. Права доступа к файлам: Запуск от имени пользователя www-data / apache или root?
3. Правильно ли установлены права доступа к файлам?
4. Магазин конкретных учетных данных базы данных против базы данных, запущенной от имени пользователя root?
5. SSH / SFTP доступ? Проверка подлинности на основе ключей?
6. SLA с хостинг-провайдером по поводу (обычной) ОС, обновлений модуля PHP + и обновлений безопасности?

организация

1. Кто отвечает за обновления системы (безопасности)?
2. У кого есть доступ к live-серверу?
3. У кого есть доступ к live-магазину?
4. Где размещен код? У кого есть доступ к голому репо и push-доступу?
5. Как выглядит текущий процесс разработки программного обеспечения? Проводятся ли проверки кода и автоматические проверки перед развертыванием кода в staging / test / live?
6. Проводится ли какое-либо тестирование безопасности или аудит безопасности (регулярно)?
7. Есть ли регулярное резервное копирование? Если так, это внешний?
8. В зависимости от размера магазина / компании: Существуют ли планы обеспечения непрерывности бизнеса и / или восстановления?

Убедитесь, что ваша / загрузчик / папка в безопасности. У вас может быть самый длинный пароль в мире, но если у меня будет все время в мире грубая информация о ваших пользователях на странице загрузчика, я в конечном итоге получу ее. Другое дело, чтобы убедиться, что список каталогов вашего сервера не может быть. Если они есть в списке, я могу легко найти содержимое вашего сервера в Google и начать просмотр. Вы будете поражены количеством конфиденциальной информации, которую люди хранят на своих веб-серверах.

Чтобы расширить список Анны Волк, этот список выходит за рамки того, что типично

• Политика безопасности контента (при правильном применении делает XSS невозможным)
• HSTS (HTTP Strict Transport Security)
• SELinux с правильно установленными контекстами.
• yum-cron / unattended-updates установлен для автоматического обновления системы безопасности