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

27

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

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

brentwpeterson
источник

Ответы:

39

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

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. В зависимости от размера магазина / компании: Существуют ли планы обеспечения непрерывности бизнеса и / или восстановления?
Анна Фёлькл
источник
1
Хороший список @ Анна Волки :)
Амит Бера
4
Один из моих баг-медведей - сторонние модули, объявляющие собственное имя администратора. Они позволяют (если вы знаете, что у магазина есть расширение), чтобы понять, каково якобы секретное имя фронта!
Питер О'Каллаган
3

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

notmyfirstrodeo
источник
Я бы порекомендовал удалить папку загрузчика ... для чего она нужна?
Brentwpeterson
1
Я бы не стал его удалять, а скорее перенаправил бы пользователей, зашедших на загрузчик / * на домашнюю страницу, по правилу htaccess.
Kalpesh
3

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

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