Аудит безпеки Magento 2: повна перевірка уразливостей

Аудит безпеки Magento 2: де ламається захист магазину

Аудит безпеки Magento 2 починається не з автоматичного сканера, а з карти точок входу атакуючого. У типового магазину їх чотири-п’ять, і кожна або закрита за замовчуванням, або залишається відкритою роками — бо про неї забули під час оновлення.

Перевірка захищеності сайту показує: частіше ламається не ядро платформи, а те, що до нього добудували.

Перше — розширення й теми зі сторонніх джерел. Модуль, занедбаний автором, залишає робочі шляхи до файлів і запитів, які ніхто не відстежує. Атакуючому достатньо однієї такої діри, щоб читати таблиці замовлень або завантажити власний код.

Звідси правило: звірити список модулів з їхнім актуальним станом і прибрати все, що не оновлювалося або дублює штатну можливість.

Друге — права адміністратора. Коли вся команда працює під одним обліковим записом із повним доступом, компрометація панелі віддає каталог, ціни й платіжні налаштування. Розмежування ролей за зонами відповідальності та персональні облікові записи обмежують збитки однією ділянкою.

Третє — службові розділи: панель за передбачуваною адресою, тестові копії магазину, доступні файли конфігурації, точки обміну даними без перевірки прав. Кожна така адреса — готовий вхід, який не потрібно шукати.

Окремо — захист від підбору паролів: без обмеження спроб і другого фактора вхід до панелі стає питанням часу.

Розбираємо нижче, як ці уразливості інтернет-магазину закриваються — від інвентаризації до налаштування сервера й правил доступу.

Результат аудиту: які вектори атак закриваються

Звіт зі списком знахідок — половина роботи. Цінність з’являється, коли закриті уразливості не відтворюються під час повторної перевірки: кожну знахідку підтверджуємо повторним прогоном сценарію атаки на Magento і фіксуємо результат у звіті.

Права адміністратора магазину

Повні права залишаємо одному-двом обліковим записам, решті видаємо ролі за завданнями: контент, замовлення, звіти.

Спільні входи «на всіх» і облікові записи звільнених співробітників видаляємо — обсяг зайвих доступів скорочується, а дії кожного адміністратора відстежуються персонально.

Захист від підбору паролів

Обмеження спроб входу, двоетапна перевірка для адмінки, повідомлення про вхід з нової адреси. Перебір перестає бути практичним: він упирається в блокування, а не в пропускну здатність з’єднання.

Захист даних покупців

Персональні дані шифруємо в сховищі, вивантаження обмежуємо роллю й строком, у журналах маскуємо. Навіть за часткового інциденту обсяг розкритих записів залишається мінімальним, а не «вся база цілком».

Закриті уразливості в коді та розширеннях

Сторонні модулі оновлюємо до підтримуваних гілок, невикористовувані вимикаємо, обробку форм і вивантажень закриваємо перевіркою вхідних даних і правами на файли.

Зникають типові вектори: впровадження коду через форми, читання чужих замовлень за прямою адресою, доступ до службових файлів.

Результат вимірюємо трьома числами: частка закритих і переперевірених знахідок, термін реакції на нове повідомлення про уразливість, кількість облікових записів із надлишковими правами. Заміри на старті й у кінці показують не «стало спокійніше», а скорочення поверхні атаки.

Формати перевірки: разова, регулярна, перед запуском

Аудит безпеки Magento 2 вирішує різні завдання, тому формат обирають від мети, а не за звичкою «раз на рік просканували». Разова перевірка показує стан на конкретну дату: відкриті точки входу, застарілі залежності, слабкі права доступу. Що з’явиться після наступного релізу, вона вже не зловить.

Далі — вибір між глибиною та частотою. Нижче формати, які ми застосовуємо на практиці: що кожен закриває, коли доречний і чим обмежений.

Порівняння форматів робіт

Формати доповнюють один одного, а не конкурують: повна перевірка задає базову лінію, регулярний контроль тримає її актуальною, а точкові прогони закривають ризик, який приносять конкретні доопрацювання.

Порядок робіт: від інвентаризації до передачі звіту

Порядок робіт однаковий для магазину на Magento 2 будь-якого розміру — змінюється лише глибина розбору. Починаємо з фіксації поточного стану, бо без інвентаризації будь-яка знахідка висить у повітрі: незрозуміло, що саме її породило і як перевірити, чи зникла вона.

1. Інвентаризація конфігурації та розширень. Збираємо склад ядра, список сторонніх модулів із джерелами, правки в базових файлах, налаштування середовища. Окремо позначаємо модулі без підтримки й кустарні доопрацювання — на них припадає основна частка знахідок.

2. Схема перевірки та межі. Узгоджуємо контур: тестова копія, дані, вікно робіт, що чіпаємо і що не чіпаємо. Без цього ручний розбір упирається в обмеження щодо навантаження й доступів.

3. Ручний розбір коду й логіки. Перевіряємо власні модулі, шаблони, обробники форм і завантаження файлів — автоматика ці місця або не бачить, або позначає хибними спрацюваннями.

4. Перевірка прав доступу та інтеграцій. Ролі в адмінці, ключі інтеграцій, права на файли й базу, платіжні та складські шлюзи. Тут найчастіше знаходяться зайві привілеї у підрядників і старих облікових записів.

5. Повторна перевірка після правок. Кожне виправлення відтворюємо на тому самому сценарії, що й знахідку, і проганяємо суміжні шляхи: закрита уразливість не повинна відкрити сусідню.

6. Звіт щодо уразливостей. Ранжуємо за критичністю, для кожної — умова відтворення, причина в коді та конкретне виправлення, а не загальна рекомендація.

7. Передача знань команді. Розбираємо звіт із вашими розробниками, виносимо правила безпечної розробки та чек-ліст для майбутніх релізів, щоб повторний аудит починався не з нуля.

Що залишається у вас: конфігурації, схеми, регламенти

Аудит завершується не звітом, а набором артефактів, за якими команда працює далі самостійно. Усі зміни фіксуємо в конфігурації платформи та в репозиторії проєкту, а не в листуванні — щоб у разі зміни підрядника або розробника нічого не довелося відновлювати з пам’яті.

• Карта уразливостей із пріоритетами. Що закрито в ході робіт, що залишилося, у якому порядку та з якою терміновістю це брати — із прив’язкою до конкретних файлів і налаштувань.
• Параметри захищеності. Режими роботи середовища, політики сесій і cookies, обмеження на завантаження файлів — приведені до безпечних значень і зафіксовані в конфігурації.
• Схема прав доступу. Ролі адміністраторів із розподілом на розробника, контент-менеджера й аналітика; на кожну — мінімально необхідний набір прав замість спільних облікових записів.
• Правила роботи з розширеннями. Звідки допустимо встановлювати модулі, що перевіряємо перед підключенням, як виводимо з експлуатації занедбані розширення і хто за це відповідає.
• Документація щодо інтеграцій. Які зовнішні сервіси підключені, які дані передаються, де зберігаються ключі доступу і як вони змінюються за регламентом.
• Регламент регулярних перевірок. Періодичність і обсяг перевірок, відповідальний, дії в разі виходу оновлення безпеки — щоб захист не застарівав між аудитами.
• Порядок дій в разі інциденту. Кому повідомляти, як ізолювати ділянку, з якої резервної копії та за який час відновлюємося.

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

Кейс: магазин із відкритою панеллю адміністратора

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

Повні права були в чотирьох підрядників і ще кількох колишніх співробітників, журнал дій ніхто не збирав, резервні копії лежали на тому самому сервері. Розбираємо кейс аудиту безпеки: що знайшли, у якому порядку закривали і як змінилися метрики.

Що показав розбір

Застаріле розширення віддавало вивантаження замовлень за передбачуваною адресою без перевірки прав — дані можна було забирати, не входячи в систему.

До панелі адміністратора вів один пароль без другого фактора, із 14 облікових записів із повними правами шість були невикористовуваними, а частина паролів збігалася з попередніми контурами.

Оскільки журнал не збирався, інцидент виявили не за оповіщенням, а за скаргою клієнта, і термін реакції вимірювався добами.

Порядок закриття та результат

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

Потім розвели ролі за принципом мінімальних прав, скоротивши кількість облікових записів із повними правами з 14 до 3, і увімкнули збір журналу з оповіщеннями.

Відновлення після інциденту перевірили на тестовій копії: копії винесли на окремий контур, прогнали розгортання цілком і переконалися, що дані замовлень і залишки складу збігаються.

За підсумком термін реакції на інцидент скоротився з кількох діб до 15 хвилин за оповіщенням, час відновлення — з 9 годин до 40 хвилин, а повторний аудит через пів року не дав жодної критичної знахідки.

Усунення уразливостей ішло пакетами з щотижневою звіркою: кожна знахідка отримувала власника й дату перевірки, тому захист інтернет-магазину перестав залежати від того, чи згадає хтось про старе розширення.

Чим відрізняється перевірка на проникнення від розбору конфігурації?

Перевірка на проникнення відповідає на питання «що досяжно». Інженер іде за зовнішнім периметром так само, як це робив би атакуючий: вивчає публічні точки входу, пробує обійти авторизацію, підняти права від звичайного покупця до адміністратора, витягнути дані чужих замовлень.

Результат — відтворювані ланцюжки, а не список абстрактних ризиків: кожна знахідка підтверджена й показує, чим вона закінчується для бізнесу.

Розбір конфігурації та коду пояснює причину.

Перевіряють не «чи вийшло», а «чому вийшло»: права на файли й каталоги, режим роботи адміністративної панелі, налаштування сесій і cookie, шифрування службових даних, ліміти на частоту запитів, політики безпеки контенту, а також нестандартні модулі й теми — найчастіше незакриті місця живуть саме там.

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

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

Що входить у перевірку: підтверджені сценарії експлуатації, конкретні налаштування й файли, які їх допустили, і пріоритети виправлення — спочатку те, що дає прямий доступ до даних або адмінки.

Часті технічні сумніви перед початком робіт

Перед стартом аудиту безпеки Magento 2 замовники ставлять майже ті самі питання: які доступи потрібні, чи не постраждає робочий магазин, що робити зі знахідками, які видно роками. Нижче — короткі відповіді, які зазвичай знімають половину листування.

Чи безпечна перевірка на працюючому сайті?

Активні перевірки на робочому контурі не запускаємо: каталог і оформлення замовлень не повинні деградувати. Сканування йде в щадному режимі, а все, що пов’язано з упровадженням коду, обходом авторизації та підбором, відпрацьовуємо на копії зі знеособленими даними.

Копія має повторювати конфігурацію робочого сайту, інакше частина висновків виявиться нерелевантною.

Що робити зі знахідками, відомими давно?

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

Хто вносить правки — ви чи наша команда?

Закриваємо уразливості самі, якщо у вас немає своєї команди на підтримці. Якщо правки на вашому боці — віддаємо опис зміни, точне місце в коді та сценарій перевірки, за яким видно, що знахідку закрито.

Як часто повторювати перевірку?

Базовий ритм — раз на квартал, плюс позапланово після великих оновлень, підключення нових модулів та інтеграцій. Магазини з активним доопрацюванням каталогу перевіряємо частіше: кожне розширення приносить свій код і свої точки входу.

Обговоримо завдання й повернемося з оцінкою та планом

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

Що варто підготувати до розмови:

• Адреса магазину та перелік контурів — робочий, тестовий, передпродуктивний: за ними звіряємо, де можна вести активні перевірки без ризику для замовлень.
• Список установлених розширень та їхні джерела: сторонні модулі дають основну частку уразливостей, особливо ті, що не оновлювалися з моменту встановлення.
• Схему інтеграцій — платіжні шлюзи, служби доставки, склад, зовнішні системи обліку: за нею видно, які дані виходять за периметр і де проходить межа довіри.
• Склад адміністраторів і ролі: хто має доступ до панелі керування, чи є спільні облікові записи і як видаються права підрядникам.
• Історію інцидентів і звернень: підозрілі замовлення, сплески навантаження, листи клієнтів — найінформативніші сліди реальних спроб входу.
• Конфігурацію середовища: гілка PHP, веб-сервер, кешування, розміщення файлів і медіа, параметри сесій і cookies.
• Регламент оновлень і порядок викладки: як ставите виправлення безпеки, хто погоджує, чи є швидкий відкат на попередній реліз.

Цей набір закриває підготовку до перевірки майже повністю — решту уточнимо по ходу. У відповідь повертаємося з планом робіт із захисту: черговість правок, що закриваємо першим, що можна відкласти без зростання ризику. Опишіть завдання — повернемося з оцінкою та планом.