Список Magento Security Punch

Дуже часто ми беремо сайт у іншої фірми, і зараз ми застрягли в конгломерації коду і потенційно десятках людей, які працювали над сайтом. Я шукаю перелік предметів, щоб попросити охоронця переконатися, що сайт Magento зміцнений. Це знадобиться, якби хтось брав на себе повну відповідальність за весь код і клієнт не хотів відбудовуватися з нуля.

Моє запитання: Чи існує список перших 10 чи 20 найкращих запитань та документації?

З мого досвіду, це важливі речі для отримання інформації про придбання нового магазину з точки зору безпеки. Цей список ще не замовлений та заповнений, я продовжуватиму працювати над цим списком.

Magento Security

1. HTTPS використовується (у всьому магазині, лише для оформлення замовлення)?
2. Спеціальний шлях адміністратора?
3. Доступ до шляху адміністратора обмежений?
4. Скільки адміністраторів? Будь-які непотрібні користувачі активні?
5. Захист облікового запису та шифрування паспорта (для клієнтів та адміністраторів): Стандарт чи налаштування? 2-факторний аут?
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. Магазин специфічних даних для бази даних проти роботи бази даних як корінь?
5. SSH / SFTP доступ? Аутентифікація на основі ключів?
6. SLA з постачальником послуг щодо (звичайних) оновлень ОС, PHP + модулів та оновлень безпеки?

Організація

1. Хто відповідає за оновлення системи (безпеки)?
2. Хто має доступ до живого сервера?
3. Хто має доступ до магазину в прямому ефірі?
4. Де розміщений код? Хто має доступ до голого репо і доступу?
5. Як виглядає сучасний процес розробки програмного забезпечення? Чи проводяться перевірки коду та автоматичні перевірки перед розгортанням коду для постановки / тестування / прямої трансляції?
6. Чи проводиться (регулярно) тестування безпеки чи аудит безпеки?
7. Чи регулярне резервне копіювання? Якщо так, то це зовнішнє?
8. Залежно від розміру магазину / компанії: Чи існують плани безперервної роботи та / або відновлення?

Переконайтесь, що ваш / завантажувач / папка в безпеці. Ви можете мати найдовший пароль у світі, але якщо я весь час у світі змушуватимуть вашу інформацію про користувача на своїй сторінці завантажувача, я згодом отримаю його. Інша справа, щоб переконатися, що ваші серверні каталоги не можуть перераховувати список. Якщо вони є в списку, я можу легко підняти вміст вашого сервера в Google і почати перегляд веб-сторінок. Ви були б вражені кількістю конфіденційної інформації, яку люди зберігають на своїх веб-серверах.

Щоб розширити список Анні Волк, цей список виходить за рамки типового

• Політика безпеки вмісту (При правильному застосуванні робить XSS неможливим)
• HSTS (сувора безпека транспорту HTTP)
• SELinux з правильно встановленими контекстами.
• yum-cron / без нагляду оновлення, встановлені для автоматичних оновлень безпеки системи