ПОЛІТИКА БЕЗПЕКИ PHP2GO
Сервіс побудований навколо безпечної обробки чужого PHP-коду: архіви перевіряються, команди обмежуються, доступ до даних має бути мінімальним.
Це робочий публічний текст для продукту. Перед реальними міжнародними платежами і рекламою його потрібно перевірити з юристом під вашу юрисдикцію, компанію, платіжних провайдерів і податкові правила.
Ця Політика безпеки описує організаційні, технічні та процедурні заходи, які застосовуються або можуть застосовуватися в сервісі php2go для захисту акаунтів, проєктів, вихідного коду, артефактів збірки, технічних логів та інфраструктури сервісу.
Політика застосовується разом з Користувацькою угодою, Політикою конфіденційності, Правилами допустимого використання, Політикою оплати та повернень, Політикою видалення даних та іншими документами, опублікованими на сайті.
Документ не розкриває внутрішні технічні деталі, які можуть послабити безпеку сервісу. Конкретний набір заходів може змінюватися з урахуванням розвитку продукту, інфраструктури, загроз і вимог законодавства.
Перед публікацією рекомендується перевірити документ у юриста та переконатися, що фактична інфраструктура php2go відповідає заявленим заходам безпеки.
1. Мета та сфера дії
1.1.Цей розділ встановлює правила та підходи до захисту: дані, проєкти, акаунти, артефакти, платіжні операції, технічні логи та інфраструктуру сервісу.
1.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: документування правил, розмежування відповідальності, контроль доступу та регулярне оновлення процедур.
1.3.Користувач зобов’язаний: дотримуватися цієї Політики, Користувацької угоди, документації та застосовного законодавства.
1.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: обмежити доступ, призупинити обробку, запросити інформацію, видалити небезпечні матеріали або застосувати інші заходи захисту.
2. Основні принципи безпеки
2.1.Цей розділ встановлює правила та підходи до захисту: хмарну обробку PHP-проєктів, роботу з вихідним кодом, генерацію артефактів і взаємодію з платіжними провайдерами.
2.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: мінімізацію доступу, розподіл ролей, контроль дій, моніторинг подій і постійне вдосконалення захисних механізмів.
2.3.Користувач зобов’язаний: розуміти, що безпека є спільною відповідальністю, і самостійно захищати свій акаунт, проєкт, секрети та артефакти.
2.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: тимчасово обмежити функції, змінити ліміти, посилити перевірки або припинити небезпечну активність.
3. Модель спільної відповідальності
3.1.Цей розділ встановлює правила та підходи до захисту: межі відповідальності між Адміністрацією та користувачем під час використання php2go.
3.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: захист серверної інфраструктури, систем авторизації, механізмів завантаження, середовища збірки та внутрішніх адміністративних інструментів.
3.3.Користувач зобов’язаний: використовувати надійні облікові дані, мати права на завантажений проєкт, не зберігати зайві секрети в архівах і перевіряти результати збірки.
3.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: відмовити в обробці проєкту, якщо ризик виник через дії користувача або порушення правил сервісу.
4. Безпека акаунта
4.1.Цей розділ встановлює правила та підходи до захисту: акаунт користувача, email, пароль, сесії, токени та способи авторизації.
4.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: обмеження спроб входу, перевірку підозрілої активності, email-підтвердження, керування сесіями та примусове скидання пароля при ризику компрометації.
4.3.Користувач зобов’язаний: використовувати надійний пароль, не передавати доступ третім особам і негайно повідомляти про підозру на злам.
4.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: заблокувати сесію, скинути пароль, тимчасово обмежити акаунт або запросити додаткове підтвердження.
5. Керування доступом і внутрішній доступ
5.1.Цей розділ встановлює правила та підходи до захисту: адміністративні функції, інфраструктуру, користувацькі проєкти та службові дані.
5.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: розмежування ролей, окремі облікові записи, контроль привілеїв, журналювання адміністративних дій і періодичний перегляд прав доступу.
5.3.Користувач зобов’язаний: не намагатися отримати доступ до чужих акаунтів, проєктів, артефактів або внутрішніх систем сервісу.
5.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: призупинити акаунт, видалити токени, заблокувати запити та зберегти відомості для розслідування.
6. Безпека завантаження проєктів
6.1.Цей розділ встановлює правила та підходи до захисту: ZIP-архіви, вихідний код, залежності, конфігурації та інші файли, що завантажуються в сервіс.
6.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: перевірку формату, розміру, структури, кількості файлів, технічних лімітів і ознак небезпечної поведінки.
6.3.Користувач зобов’язаний: завантажувати лише законні проєкти, на які він має права, і виключати зайві секрети, дампи баз даних та production-конфігурації.
6.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: відхилити завантаження, зупинити обробку, видалити файл, заблокувати проєкт або обмежити акаунт.
7. Вихідний код, секрети та чутливі дані
7.1.Цей розділ встановлює правила та підходи до захисту: вихідний код, приватні ключі, токени, паролі, платіжні ключі, персональні дані та інші чутливі відомості.
7.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: обмеження доступу, службове журналювання, тимчасову обробку, видалення тимчасових файлів і процедури виявлення небезпечних секретів.
7.3.Користувач зобов’язаний: не включати до проєкту секрети, які не потрібні для збірки, а при випадковому завантаженні негайно замінити або відкликати їх.
7.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: видалити небезпечні файли, зупинити збірку, запросити підтвердження прав або рекомендувати замінити ключі та токени.
8. Середовище збірки та ізоляція процесів
8.1.Цей розділ встановлює правила та підходи до захисту: середовище збірки, тимчасові файли, кеш, проміжні дані, системні команди та ресурси виконання.
8.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: обмеження доступу до файлової системи, мережі, системних команд, часу виконання, пам’яті, диска, процесів та інших ресурсів.
8.3.Користувач зобов’язаний: не завантажувати код, призначений для виходу із середовища, експлуатації вразливостей, доступу до чужих даних або втручання в інфраструктуру.
8.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: негайно зупинити збірку, видалити артефакти, обмежити акаунт і за потреби передати відомості компетентним органам.
9. Інфраструктурна та мережева безпека
9.1.Цей розділ встановлює правила та підходи до захисту: сервери, домени, мережеві з’єднання, бази даних, черги завдань, системи зберігання та адміністративні панелі.
9.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: оновлення програмного забезпечення, обмеження мережевого доступу, міжмережеві екрани, контроль портів, сегментацію та моніторинг доступності.
9.3.Користувач зобов’язаний: не проводити сканування, навантажувальні тести, атаки або дослідження інфраструктури без попереднього письмового дозволу.
9.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: обмежити IP-адреси, запити, функції, акаунти або збірки, що загрожують стабільності чи безпеці.
10. Передача даних і шифрування
10.1.Цей розділ встановлює правила та підходи до захисту: передачу даних між користувачем і сайтом, особистим кабінетом, формами завантаження, платіжними сторінками та іншими інтерфейсами.
10.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: захищені канали зв’язку, HTTPS/TLS, захист токенів, обмеження доступу до службових даних і додаткові механізми захисту там, де вони передбачені архітектурою.
10.3.Користувач зобов’язаний: використовувати актуальний браузер, захищене з’єднання, довірений пристрій і не передавати проєкти через небезпечні мережі.
10.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: призупинити небезпечні операції, анулювати токени або вимагати повторну авторизацію.
11. Журнали, моніторинг і виявлення зловживань
11.1.Цей розділ встановлює правила та підходи до захисту: технічні логи, події акаунта, статуси збірок, помилки, платіжні події та дії в інтерфейсі.
11.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: ведення журналів, моніторинг підозрілої активності, аналіз спроб обходу лімітів, виявлення шкідливих проєктів і розслідування помилок.
11.3.Користувач зобов’язаний: розуміти, що логи можуть зберігатися для безпеки, діагностики, обліку, захисту прав, виконання закону та вирішення спорів.
11.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: зберігати необхідні відомості, блокувати підозрілі дії, скасовувати операції або обмежувати доступ.
12. Резервне копіювання, зберігання та видалення
12.1.Цей розділ встановлює правила та підходи до захисту: резервні копії, проєкти, артефакти, тимчасові файли, кеш, логи та службові дані.
12.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: резервне копіювання окремих компонентів, відновлення після збоїв, контроль строків зберігання та автоматичне видалення застарілих матеріалів.
12.3.Користувач зобов’язаний: самостійно зберігати вихідні проєкти та необхідні артефакти поза сервісом, не використовуючи сервіс як єдине сховище.
12.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: видаляти дані за строками зберігання, при перевищенні лімітів, за запитом користувача або з причин безпеки.
13. Виявлення шкідливого коду та забороненої активності
13.1.Цей розділ встановлює правила та підходи до захисту: шкідливий код, фішинг, майнери, експлойти, backdoor-компоненти, спам, DDoS та іншу заборонену активність.
13.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: фільтри, евристики, сигнатури, ручний аналіз, автоматичні перевірки та заходи реагування на зловживання.
13.3.Користувач зобов’язаний: не використовувати сервіс для незаконної, шкідливої, шахрайської або небезпечної діяльності.
13.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: зупинити збірку, видалити проєкт, заблокувати акаунт, відмовити в обслуговуванні та зберегти відомості для розслідування.
14. Сторонні постачальники та зовнішні сервіси
14.1.Цей розділ встановлює правила та підходи до захисту: хостинг-провайдери, дата-центри, платіжні провайдери, поштові сервіси, моніторинг, аналітику та системи авторизації.
14.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: вибір постачальників з урахуванням надійності, доступності, безпеки, репутації, технічних можливостей і застосовних вимог.
14.3.Користувач зобов’язаний: враховувати, що окремі операції можуть регулюватися правилами сторонніх провайдерів, особливо при оплаті, авторизації або email-сповіщеннях.
14.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: змінити постачальника, обмежити функцію, призупинити інтеграцію або повідомити користувача про суттєві зміни.
15. Реагування на інциденти
15.1.Цей розділ встановлює правила та підходи до захисту: події, які можуть призвести до несанкціонованого доступу, втрати, зміни, розкриття даних, порушення доступності або загрози інфраструктурі.
15.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: підтвердження події, локалізацію, усунення причини, відновлення роботи, аналіз наслідків і запобігання повторенню.
15.3.Користувач зобов’язаний: негайно повідомляти про підозрілі події та надавати розумно необхідну інформацію для перевірки звернення.
15.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: обмежити доступ, відключити функції, відкликати токени, скинути паролі, зупинити збірки або повідомити затронутих користувачів.
16. Повідомлення про вразливості
16.1.Цей розділ встановлює правила та підходи до захисту: вразливості сайту, особистого кабінету, API, завантаження проєктів, середовища збірки, авторизації та інших компонентів сервісу.
16.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: прийом повідомлень на security@p2g.dev або admin@p2g.dev, перевірку фактів, пріоритизацію виправлень і безпечну взаємодію з дослідником.
16.3.Користувач зобов’язаний: не використовувати знайдену вразливість для доступу до чужих даних, порушення роботи сервісу, підвищення привілеїв або публічного розкриття до виправлення.
16.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: припинити взаємодію з дослідником, якщо тестування порушує закон, правила сервісу або безпеку третіх осіб.
17. Обов’язки користувача щодо безпеки
17.1.Цей розділ встановлює правила та підходи до захисту: поведінку користувача під час завантаження проєктів, запуску збірок, скачування артефактів і використання результатів компіляції.
17.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: роз’яснення правил, документацію, технічні обмеження, підтримку та інструменти видалення або обмеження проєктів.
17.3.Користувач зобов’язаний: перевіряти залежності, ліцензії, конфігурацію, змінні середовища, артефакти та результати збірки перед використанням у production-середовищі.
17.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: обмежити використання сервісу при порушенні обов’язків або створенні загрози для сервісу, користувачів чи третіх осіб.
18. Обмеження та відсутність абсолютної гарантії
18.1.Цей розділ встановлює правила та підходи до захисту: залишкові ризики хмарної обробки вихідного коду, мережеві ризики, помилки конфігурації, людський фактор і дії зовнішніх провайдерів.
18.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: розумні заходи захисту, але без гарантії повної відсутності загроз, помилок, атак, вразливостей, витоків або збоїв.
18.3.Користувач зобов’язаний: розуміти ризики хмарного сервісу та самостійно оцінювати придатність php2go для своїх проєктів і вимог безпеки.
18.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: обмежувати відповідальність у межах Користувацької угоди та застосовного законодавства.
19. Зміна Політики
19.1.Цей розділ встановлює правила та підходи до захисту: оновлення цієї Політики у зв’язку з розвитком сервісу, зміною інфраструктури, появою нових загроз або зміною законодавства.
19.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: публікацію нової редакції на сайті, зазначення дати набрання чинності та додаткове повідомлення користувачів при суттєвих змінах.
19.3.Користувач зобов’язаний: самостійно відстежувати актуальну редакцію документів і припинити використання сервісу при незгоді зі змінами.
19.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: застосовувати оновлену редакцію після набрання нею чинності, якщо інше не вимагається обов’язковими нормами закону.
20. Контакти та пріоритет редакції
20.1.Цей розділ встановлює правила та підходи до захисту: звернення з питань безпеки, повідомлення про інциденти, вразливості та захист даних.
20.2.Адміністрація може застосовувати розумні технічні, організаційні та процедурні заходи, зокрема: прийом звернень через security@p2g.dev або admin@p2g.dev, запит додаткових відомостей і перевірку повноважень заявника.
20.3.Користувач зобов’язаний: зазначати email акаунта, опис проблеми, дату й час події, ідентифікатор проєкту або збірки, технічні деталі та безпечні кроки відтворення.
20.4.У разі порушення вимог, підозри на інцидент або загрози безпеці Адміністрація має право: застосовувати російську редакцію як пріоритетну при розбіжностях перекладів, якщо інше не вимагається обов’язковими нормами застосовного законодавства.
У разі розбіжностей між перекладами та російською редакцією цієї Політики переважну силу має російська редакція, якщо інше не вимагається обов’язковими нормами застосовного законодавства.
Якщо потрібна копія умов, запит щодо даних, скарга на авторські права або питання щодо оплати, напишіть у підтримку.
mailЗвернутися в підтримку